standard Xhtml- div vs li - html

I need ur suggestion in the following scenario.
Lets say I have an UI something like
Col1 Col2
A D
B E
C F
Now to get this right now in my HTML I am using ..like
<div class="col1">
<div>A</div>
<div>B</div>
..........
</div>
<div class="col2">
<div>D</div>
<div>E</div>
..........
</div>
But here I am using too much div..is it OK as per standard XHTML or should I use <li>?
Can somebody suggest with proper explanation, or maybe something else?
Note: No use of Table
Thanks.

It looks to me like you are trying to display tabular data which the table element works great for and is the intended use.
<table>
<tr>
<th>Col1</th>
<th>Col2</th>
</tr>
<tr>
<td>A</td>
<td>B</td>
</tr>
</table>
If you really don't want to use table, I'd use the div element like you did in your example. But in the end you will realize that what you are trying to accomplish is simulating an element that already exists - table.
You should keep in mind that when you are using div as a table it won't look well when you disable CSS or viewing it with an older mobile browser (that don't support floats well).

You could maybe use a definition list, although that is more suited for key / value pair data, though that could be the case in your situation, I can't tell.
If not, like Manticore says, just use tables: http://giveupandusetables.com/

I would second Manticore's statement. Tables should also be used for tabular data (data displayed with rows and columns). Everybody gets up on their high horse about using divs for layout instead of tables, but that doesn't mean that tables should be abandoned. What you are doing is NOT layout; it is structuring a particular segment of content, and thus you should use a table tag. Plus, some advantages:
You can use around the s that contain tags to create a table header. If the user prints the table and it extends beyond one page, the content in the will be printed at the top of every new page. The same is also true of the tag. One slight difference with the though: Content inside should be in the format of Content of cell 1 - don't use the tag inside of s except for those in the .
Divs are practically impossible to layout in a table format. They are useful for page design layout, but not necessarily for tabular data. Plus, if you're creating an interactive page in which the user will be adding more data, you will find yourself having a very difficult time figuring out what the placements of the divs are.

The 'semantic standard' would definitely be to use tables. As others have said, this is your basic tabular data. That's what they're for, end of story.
However, if you can't use tables, then I would say the next most semantically meaningful structure would be a list, because it allows you to define relationships between the elements, like so:
<ul>
<li>Col1
<ul>
<li>A</li>
<li>B</li>
<li>C</li>
</ul></li>
<li>Col2
<ul>
<li>D</li>
<li>E</li>
<li>F</li>
</ul></li>
</ul>
Then, worst of all would be divs. 'Worst' because they have no semantic meaning. Tag-soup, basically.

Related

Definition list vs. Unordered list with headings - which makes more semantic sense?

Let's say you had something like a TV show listing, where you had a show title, and a show description. You want the listing to be accessible for people with disabilities as well.
Would it make more sense to use a definition list:
<dl>
<dt>...title...</dt><dd>...description...</dd>
...
</dl>
Or an unordered list with headings?
<ul>
<li><h3>...title...</h3><p>...description...</p></li>
...
</ul>
Which makes more semantic sense and will respond better to screen readers? (knowing that they can both be styled the same way)
If you are using HTML 4.01, you shouldn't use dl as it's defined as "definition list" (and your example does not consist of terms and their definitions). If you are using HTML5, the use of dl is fine, because the definition of dl changed.
Using headings inside of li might be a bit problematic regarding the document outline. The scope of a heading would include the start of the next li: <li><!--scope start--><h3>title</h3><p>description</p></li><li><!--scope end--><h3>…. By using section (resp. article), this could be avoided.
So, for HTML5, I think the following ways are possible:
dl
<dl>
<dt>Title1</dt>
<dd>Description1</dd>
<dt>Title2</dt>
<dd>Description2</dd>
</dl>
That would be my favorite, if you only want to provide title and description for each show (if not, see the last example).
ul + section
<ul>
<li>
<section>
<h1>Title1</h1>
<p>Description1</p>
</section>
</li>
<li>
<section>
<h1>Title2</h1>
<p>Description2</p>
</section>
</li>
</ul>
I don't like that very much. The list isn't adding much here, so why not omit it? (see next example)
headings only
<section>
<h1>Title1</h1>
<p>Description1</p>
</section>
<section>
<h1>Title2</h1>
<p>Description2</p>
</section>
Instead of section the article element might be possible, too.
You could also omit section (or article) and use headings only (in the case of section it wouldn't change the meaning); in that case you'd need to apply the correct heading level.
headings + dl
If you want to provide additional metadata (maybe in the future), I'd go with the following markup:
<section>
<h1>Title1</h1>
<dl>
<dt>Description</dt>
<dd>…</dd>
<dt>Rating</dt>
<dd>…</dd>
<dt>Time</dt>
<dd>…</dd>
<dt>Length</dt>
<dd>…</dd>
</dl>
</section>
I prefer the former. First, it seems to make more sense to me just based on the content.
But that's me. I think the markup should reflect the document structure, and since (as you say) the CSS can style it either way, why not make the markup reflect the content? A list containing items that contain a header for a title, followed by a description seems a bit of overkill to me.
But, hey. You know what they say about opinions.
In this case using a Definition list makes much more sense. Aside from this though, is it really necessary to use a list at all? It may make more sense just to use your Heading tags appropriately on the page wit a tag (x= 2-6) and have everything apply under the header of that. TV Shows in specific it may not make sense to use a "List" to display them with definitions or anything else. Again, they can be styled however, so i'm only worried about sematics with this.
Hope this helps
Zach

Why shouldn't / doesn't <caption> get recognised as a section title in document outlines?

At the moment, HTML5 standards create titles/headings automatically from the first heading it finds in the article/section/nav etc. The problem I have is seeing why <caption> shouldn't be treated the same way as headings (for the purpose of the outline).
Take the below code for example. It's what you have to resort to in order to have a titled section in the document outline:
<table>
<caption>Results from zombie duck experiment</caption>
<h2 style="display: none;">Results from zombie duck experiment</h2>
<tr>
<td>FAILURE</td>
<td>FAILURE</td>
</tr>
</table>
(Which produces this outline: http://gsnedders.html5.org/outliner/process.py?url=http%3A%2F%2Froncya.com%2Ftransfer%2FHTML5CaptionDocumentOutline2.htm)
I understand why that works; HTMLDoctor go so far as to say that it is the recommended way of doing things:
For accessibility reasons, we recommend each sectioning element have a heading, even <aside> and <nav>. If you don’t want these headings to be visible, you can always hide them with CSS. --http://html5doctor.com/outlines/
Sure, but why not this?:
<table>
<caption>Results from zombie duck experiment</caption>
<tr>
<td>FAILURE</td>
<td>FAILURE</td>
</tr>
</table>
(Which produces this failed outline: http://gsnedders.html5.org/outliner/process.py?url=http%3A%2F%2Froncya.com%2Ftransfer%2FHTML5CaptionDocumentOutline1.htm)
I'm assuming that the W3C made a conscious decision and the only ideas I have are that:
Tables, while they do have an ending tag, aren't really used as 'wrappers' like div, span, article, section, nav and similar. So in that sense, they don't define a 'surrounded section'
Headings are headings and captions are not headings (...which doesn't answer much)
Typical captions don't make for suitable titles (I disagree with this)
As for number 3, I think that a typical caption would still be useful as a title in a document outline. Regardless of wether they're on top of the table or below. Heck, I can't even see why it would be worse than nothing. Take these possible captions for example- I reckon they would all be appropriate document outline section titles:
Results from zombie duck experiment
Figure 3b
Windows 8 Region Pricing
Which brand contains what?
Cheat codes
Colours
Abraham Lincoln's attire at different periods of history
It would sure make sense to me.
In HTML5, it's intended that the caption contains not just a brief title, but descriptive prose explaining the table. The spec provides one example of use of caption:
<caption>
<p>Table 1.
<p>This table shows the total score obtained from rolling two
six-sided dice. The first row represents the value of the first die,
the first column the value of the second die. The total is given in
the cell that corresponds to the values of the two dice.
</caption>
This would not make for a good title for the document outline.
I would suggest that you put the <h?> inside the caption if you want it to appear in the document outline. In the example above, this would be suitable:
<caption>
<h2>Table 1.</h2>
<p>This table shows the total score obtained from rolling two
six-sided dice. The first row represents the value of the first die,
the first column the value of the second die. The total is given in
the cell that corresponds to the values of the two dice.
</caption>
or in your example:
<table>
<caption><h2>Results from zombie duck experiment</h2></caption>
<tr>
<td>FAILURE</td>
<td>FAILURE</td>
</tr>
</table>

Should a calendar by represented using a table? Why does Google Calendar only use a table for the columns?

This is not another general 'tables versus div elements for general layout' type question, like the "why not use tables for layout" question.
I'm working on a timetable/calendar project and I have always assumed that a calendar would be an example of when to use to a use a table. Although, after a quick look at Google Calendar's structure, it seems it consists of a table, containing a <td> for each column and within each column, an event is a <div> with definition list inside.
Why is this beneficial?
My own ideas:
Tables may be more troublesome to style, nicely & compactly, when there are multiple varying length events beginning at the same time (beginning in the same <td>). Possibility of unwanted whitespace.
Harder to update tables when user adds event after the page is loaded, e.g. with JavaScript (because the row/colspan of the table headers might have to change)
If tables were used, the width of x-axis/top headers & cells, and the height of y-axis/left headers and cells, would be matched automatically. Could be tough to manage this without tables.
Does any of this matter? Should tabular data always be stored in actual tables?
The following is a simplified example of a Google Calendar column:
<td> <!-- column -->
<div> <!-- start event -->
<dl>
<dt>START TIME – END TIME </dt>
<dd>EVENT TITLE</dd>
</dl>
</div> <!-- end event -->
</td> <!-- end column -->
The following is a full example:
<td class="tg-col"> <!-- column td -->
<div id="tgCol0" class="tg-col-eventwrapper" style="height:1008px;margin-bottom:-1008px;"> <!-- column div -->
<div class="tg-gutter">
<div class="ca-evp130 chip " style="top:588px;left:-1px;width:100%;"> <!-- start event div -->
<dl class="cbrd" style="height:35px;border-color:#9FC6E7;background-color:#E4EFF8;color:#777777;">
<dt style="background-color:;">START TIME – END TIME <i class="cic cic-dm cic-rcr" title="Recurring event"> </i></dt>
<dd><span class="evt-lk ca-elp130">EVENT TITLE</span></dd>
<div><!-- start masks -->
<div class="mask mask-top" style="border-color:#9FC6E7;background-color:#E4EFF8;"> </div>
<div class="mask mask-bottom" style="border-color:#9FC6E7;background-color:#E4EFF8;"> </div>
<div class="mask mask-left" style="height:38px;border-color:#9FC6E7;background-color:#E4EFF8;"> </div>
<div class="mask mask-right" style="height:38px;border-color:#9FC6E7;background-color:#E4EFF8;"> </div>
</div><!-- end masks -->
<div class="resizer"> <!-- start resizer -->
<div class="rszr-icon"> </div>
</div> <!-- end resizer -->
</dl>
</div> <!-- end event div -->
</div>
</div> <!-- end column td -->
<div id="tgOver0" class="tg-col-overlaywrapper"></div> <!-- column overlay div -->
</td> <!-- end column td -->
Edit:
Don't forget to include why Google Calendar is structured as it is, e.g. why does Google Calendar have a table but only use it for the columns?
Personally, I'd go with div's instead of tables. That's not to say table's are entirely wrong, it's just that div's can be much more flexible when it comes to styling them, especially if you're adding other elements (such as a meeting that might span 2 dates) etc.
Div's would also help in a fluid layout more so than a table might.
It both is and isn't tabular data, I guess it depends on how far you're taking it's functionality, and layout.
I think there are two main reasons to use a table for displaying calendars:
Rows with variable height cells are simpler in tables, though the same thing can be accomplished with floats and clearfixes. The table approach is more likely to not break (and certainly more compatible with ancient browsers), and is probably more efficient for the browser to render.
The flow of multi-day events is very hard to manage with CSS, but it's pretty simple through the use of colspan (even if it does produce relatively hideous and non-semantic markup).
(I'm asking a question elsewhere on StackOverflow wondering whether there's a reasonably robust and elegant way to achieve these ends without tables. See: HTML markup for multi-day calendar events)
Adam, that's a fantastic question.
I think a calendar is the perfect use for tables actually. You're right, tables are harder to style in most senses, but when you think about the real issue, it's what you prefer. Sure, you could technically build a lot of modern websites with tables rather than divs and it'd be really tough, but there's a time and a place for everything. It comes down, in my opinion, to preference and if you can write something with less markup, then that's what you should use... even if it's considered bad practice by modern standards.
My vote is for something as square and unchanging as a calendar... go with tables if that's the cheaper solution.

What's a good way to handle this simple example in CSS?

Let's say I have the following layout on some pages:
Title: Some Title
Author: Some Author
Author Date of Birth: Date of birth
Notes:
Left side text is right-aligned and bold.
Used on several different pages.
The right side can contain input controls at some point.
What would be the most appropriate method to apply in this situation? I can think of a few options (assume CSS applied in external style sheet):
Table
Simple, easy, but I'm not sure this would be considered a good use of tables.
<table>
<tr>
<td>Title</td>
<td>Some Title</td>
</tr>
</table>
Div + Classes
I feel like this is a case of divitis and classitis rolled into one.
<div class="information">
<div class="title">Title</div><div class="value">Some Title</div>
</div>
Container Div
This feels more like the right path but I'm not sure.
<div class="information">
<strong>Title</strong> <span>Some Title</span>
</div>
Suggestions?
I think a good semantic choice here is the dl (description list) element.
http://developers.whatwg.org/grouping-content.html#the-dl-element
<dl>
<dt>Title</dt>
<dd>Some Title</dd>
<dt>Author</dt>
<dd>Some Author</dd>
<dt>Author Date of Birth</dt>
<dd>Date of birth</dd>
</dl>
Use a table, this is one of the few instances where using a table actually isn
't all that wrong. You're not using it for layout but text markup.
Then apply a class to every first column and in css make that class have text-align: right; which applies to that column.
I think you're right in you saying you want to use a table, but don't want to use. In this case i don't think a table is correct either. I personally only use tables if i need to organize data nicely. Because you have so much, a bunch of floated divs everywhere is more of a hassle then just using a table.
Because this is only two columns I would say use use two divs with floats or use two spans, instead of strong use a span and then style it with css.
This is clearly a good example of when to use tables.
It's tabular data.
Use ths for the first columns cells to be able to style it.
I even think ths are bold by default. Not sure about all browsers though so wouldn't hurt to style them bold to be sure :).
A table is a means of arranging data in rows and columns.
And this is what you are doing.
Definition list would be semantically correct.
<dl>
<dt>Title:</dt>
<dd>Some Title<dd>
<dt>Author:</dt>
<dd>Some Author</dd>
<dt>Author Date of Birth:</dt>
<dd>Date of birth</dd>
</dl>
See W3C for more details - http://www.w3schools.com/tags/tag_dl.asp

Semantically marking up translations

I'm in the process of marking up an historical manuscript which has been translated from German into English. On the web page I will be providing both languages side by side. Is there an accepted way to markup such a scenario?
I was thinking of splitting the translation blocks using the section tag and providing each with a lang attribute. However semantically this fails at communicating that one section roughly equates to the other.
Any thoughts on this would be greatly appreciated.
Without an example of the data it's hard to say; but is there a reason that you couldn't section them together, and provide the languages within sibling blockquotes; these then carry the context correctly, and can be styled to appear side by side.
<section>
<blockquote lang="en">English</blockquote>
<blockquote lang="de">Deutsch</blockquote>
</section>
I think that table could be used here to relate the original text to its translation:
<table lang="en">
<tr>
<th>Original/English</th>
<th>Translation/German</th>
</tr>
<tr>
<td><blockquote>…</blockquote></td>
<td lang="de"><blockquote>…</blockquote></td>
</tr>
</table>
(assuming that both versions are actually quoted from a different source)
It would be possible to divide the original and the translation into sections or pages or paragraphs (or whatever), if useful, each represented by a separate row (tr).
See also my answer to a similar question.
Note that by using blockquote the headings of the manuscript (and the translation) are not part of the document outline.