Which also deals with how most browsers don't use the same size/appearance bullets, and would let you get a little more fancy with their appearance. It would also be cached across pages as opposed to the SPAN or P inside the markup.

Shame we can't rely on generated content yet -- a td:before { content:"·"; } would also be a nice solution.

r937
—
2011-06-06T09:57:10Z —
#5

deathshadow60 said:

a single word is NOT a paragraph...

<p>Bullpoop.</p>

PaulOB
—
2011-06-06T10:19:37Z —
#6

deathshadow60 said:

A-- a single word is NOT a paragraph...

You know we disagree here

It depends on the context but a single word can be a paragraph. The shortest sentence can be one word.

shortest possible complete sentence is something like "Go!"

A paragraph is defined as one or more sentences expressing a single train of thought so the one word can be a paragraph.

system
—
2011-06-06T10:33:52Z —
#7

Paul_O_B said:

It depends on the context but a single word can be a paragraph.

Context being the important part -- you already have a semantic tag saying that it's table data, the extra semantics applied by the paragraph tag is redundant/pointless and possibly damaging to accessibility.

Semantics isn't just about slapping P around anything that happens to be CDATA.

ralphm
—
2011-06-06T10:54:42Z —
#8

I know this will come across as pedantic, but I'm even more liberal in my definition of a 'paragraph'. If you go back to the Greek origins of the word, the 'graph' part applies not only to writing but to drawing, painting etc. Para means 'along side' or 'beside'. So I'm happy to wrap an image in <p> tags with no associated text, as it's still consistent with 'something drawn or written beside (something else)'. I know that's not actually the reason why the word ‘paragraph’ came into English, and I'm sure that's not what people had in mind when they established the <p> element, but it works for me (when I'm trying to justify non-standard uses of that element).

deathshadow60 said:

the extra semantics applied by the paragraph tag is … possibly damaging to accessibility.

What problems might it cause?

system
—
2011-06-06T11:12:46Z —
#9

ralph_m said:

What problems might it cause?

Well it often breaks column and row scope in screen readers if you don't explicitly state them. I've had that more than once where using block level containers inside TD often "lose the association" to their parent TH on the row or in relation to TH inside the THEAD. (assuming you are even building the table PROPERLY). It can be fixed by stating either "headers=" on the TD or "scope=" on the associated TH, but why use extra markup if you don't have to?

But again, with most developers not even knowing that CAPTION, TBODY, THEAD, TFOOT, COLGROUP, COL or TH even exist(much less Mozilla still not even supporting COL properly some thirteen years after the bugzilla entry was made), much less the concept of the SCOPE, AXIS or HEADERS attributes it's probably why so many people think that tables are always broken in screen readers-- when in general they're just not using them right.

the extra semantics the paragraph tag is redundant/pointless and possibly damaging to accessibility.

Incorrect. None. Infact it might be better since the p is the jump paragraph hotkey. So instead of dealing with the table, they can read the words.

ralph_m said:

What problems might it cause?

None, other than the table itself.

deathshadow60 said:

It can be fixed by stating either "headers=" on the TD or "scope=" on the associated TH, but why use extra markup if you don't have to?

A screen reader is not smart. It will only guess so much before it says "Heck I don't know my header, here is my value." Thus why scope or headers are NEEDED not just bloat code.

system
—
2011-06-06T17:10:13Z —
#16

rguy84 said:

A screen reader is not smart. It will only guess so much before it says "Heck I don't know my header, here is my value." Thus why scope or headers are NEEDED not just bloat code.

They ARE smart enough to realize a TH inside THEAD should have scope=col and that TH inside TBODY should have scope=row by default... which makes perfect sense. Unfortunately that breaks if you put block level containers inside the TD.... necessitating the extra elements.

Just part of why I'd prefer an inline-level element that adds no extra semantic meaning to the content -- as applying the wrong semantics can be worse than having none at all.

You know, thinking on this, I probably would go with:

td:before {
content:"\\2022";
}

Doesn't work in IE7 or earlier -- oh well. Oh, and that's unicode, for utf-8 you'd want to swap 2022 for E280A2 I think...

Off Topic:

I just love how :before actually puts it INSIDE the element... that makes sense.

Normally I dislike the mere idea of generated content, but those bullets are presentational in nature so...

rguy84
—
2011-06-06T18:00:18Z —
#17

deathshadow60 said:

They ARE smart enough to realize a TH inside THEAD should have scope=col and that TH inside TBODY should have scope=row by default... which makes perfect sense. Unfortunately that breaks if you put block level containers inside the TD.... necessitating the extra elements.

Sorry Jason, still incorrect. You need to provide proof. All the stuff I am seeing does not say what are saying. If I understand you correctly, you are saying

<table>
<tr>
<th>heading</th>

is the same as

<table>
<tr>
<th scope='col'></th>

Looking at the spec, it says a value must be given, and there is no default value. So that would lead me to say it may be announced as a header, but not to what, which is the opposite what you said. I would say some screen readers might be able to grab the header by force (hotkeys), but would not rely on that method.

Maybe read [Tables with JAWS and MAGic and [url=http://www.freedomscientific.com/Training/Surfs-up/Table_Reading_Commands.htm]Table Reading Commands for JAWS and [url=http://www.eramp.com/david/tablesample2.htm]Table examples](http://www.freedomscientific.com/Training/Surfs-up/Tables.htm)

by screen readers like Jaws, webbIE, etc... Which last time I checked did work. It makes sense for them to be treated that way since pretty much THEAD is going to be the headings for the body area -- that's what THEAD and TBODY are FOR. The associations are retained. Simply adding a DIV inside that row TH breaks the association. If I remember right Jaws also broke TBODY ones if you had more than one TH... makes sense since it makes no sense for multiple TH per row! I think it also doesn't form that association if you don't have a THEAD and explicit TBODY. (the assumed automatic one most browsers don't usually even bother making in their DOM)

THEAD and TBODY, check 'em out. NOT what they are actually for by the spec, but it is how they are often treated. (while TFOOT languishes as pointless in most cases)

rguy84
—
2011-06-06T18:49:08Z —
#19

<THEAD> has no implicit value as you suggest. All Thead does is if you put headers in, and your table hits a page break, the headers are reprinted.

"This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data." Tables in HTML documentsTherefore scope is not applied by default. A DIV breaks association because THEAD, TBODY and TFOOT are basically a div (as quoted above).

If I remember right Jaws also broke TBODY ones if you had more than one TH... makes sense since it makes no sense for multiple TH per row!)

... uhm multi-level/layer tables.

THEAD and TBODY, check 'em out. NOT what they are actually for by the spec, but it is how they are often treated

Guessing you are seeing this because thead,body and foot are rarely used and when they are it is usually incorrectly. So screen reader manufacturers script it so it reads correctly. Screen readers have to fix code more than people think to make it read correctly.Take a minute and think, if thead really did what you are thinking I bet money various people would say use thead to solve the issue(s), versus scope or headers/id. Seeing that nobody doesn't should show that thead is just for layout.

system
—
2011-06-06T19:03:29Z —
#20

rguy84 said:

So screen reader manufacturers script it so it reads correctly. Screen readers have to fix code more than people think to make it read correctly.

That's actually what I've been SAYING. I'm not saying that's what it does by the spec -- I'm saying it makes sense and it's how some UA's handle it.

Though I don't know if I'd call it "fixing code" so much as behaving to the original intent of HTML. Remember, the reason HTML is so vague on appearance of tags (in fact you'll be hard pressed to even find it say "must" look a certain way for ANY tag) is that the entire original point of HTML is for saying what things ARE -- then letting the user agent best figure out how to handle presenting that to the user.

It was only during the browser wars with the endless extra crap that came to be known as HTML 3.2 (and is now being revived with the HTML 5 idiocy) that we got away from that concept -- the point of HTML 4 STRICT and CSS2 being to drive us back to that original point making separation of presentation from content a reality. A really nice reality.

But like anything else, it goes in cycles. By the time of HTML 6 (or whatever they'll call it by then with the "let's get rid of versioning lunacy) we'll probably see 90% of the new tags in 5 dropped as redundant just as they were for 4 Strict when everyone realizes how malfing mind-blowingly STUPID HTML 5 really is... or as I'm starting to call it, HTML 3.25.