Re: [WSG] "DOM" created table markup [was: Accessible Multi-Column List]

[Al Sparber]

From: "Thierry Koblentz" <[EMAIL PROTECTED]>

True, but as I told Christian, nothing beats a table when it comes 
to make

the layout behave like a table.


I'm going to save that in my quotations archive :-) 





***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] "DOM" created table markup [was: Accessible Multi-Column List]

[Thierry Koblentz]

Paul Novitski wrote:
> At 10/26/2006 06:31 PM, Thierry Koblentz wrote:
>> IMO, the goal should be to deliver the *cleanest* document possible,
>> with the least amount of structural hack, hook, etc.
>
> You mean like 40 lines of JavaScript to morph the markup of a 16-item
> list?

Paul,
I just did the Maths; the CSS solution (example 5) vs. the script solution
(after removing whitespace in both).
The difference is less than 80 bytes (944 vs. 1017), so I don't think that's
really significant ;-)

>> In the example I posted, one can't get cleaner than that. The only
>> issue I see is that screen-readers end up with a table.

> Oops.  Isn't accommodating non-visual user agents one of the primary
> reasons we're trying to drag the world wide web off that old table
> jones?

What about the aural media type (ACSS)? And the speech module? I agree that
support is sketchy but the idea is there. We should be able to use such
mechanism. For example, with the script, rather than removing the List from
the DOM after creating the Table I could leave both in there, then hide one
from screen-readers and the other one from visual browsers. The idea is to
use media="aural" to hide the table {display:none} and the script itself to
hide the UL (obj.style.display="none").

> To be fair, though, using JavaScript to change semantic markup into
> arbitrary glop for the sake of presentation doesn't necessitate the
> use of tables; that was just the way you built this particular
> demo.  You could have simply split the list into two pieces and
> floated them left.

True, but as I told Christian, nothing beats a table when it comes to make
the layout behave like a table. AFAIK, there is nothing wrong with using
tables in *visual* browsers. And again, the idea here is to generate that
markup *only* for JS-enabled *visual* browsers.

>> http://www.tjkdesign.com/test/
>> on top of that, it is possible to make the list display across
>> different number of columns without having to edit the markup nor
>> the stylesheet; actually, there is *no* stylesheet ;)

> It gets better!  No more pesky separation of structure from
> presentation from behavior!  Now we can have them all neatly combined
> in a single file.  How... compact!

Is that really behavior? Is it because it is JS that it is - de facto -
behavior?
There is no user interaction. It's not like a JS rollover or a show/hide DIV
thing. Here, it is purely presentational. No?
What about using document.write() to plug a stylesheet? Would/should that be
considered "behavior"?...
But most important, is it that bad? My take on this is that if it fits the
bill. Then why not using it?

>> Disabling the script is all what is needed for screen-readers to
>> speak the links in the proper sequence.

> So Jaws users have to disable your tool and all other JS helpers on
> the page in order to read the content in the proper sequence?  I'm
> sorry, but how is this a step ahead?

Not *all* other JS helpers, only the ones that fall into this category (not
for screen-readers).
And users would have to disable them only because the supposed built-in
mechanism (ACSS) fails... The problem is not with the script per se, it is
with the fact that we can't really "target" screen-readers, but we should be
able to...

BTW, I mentionned "behavior" switchers before but forgot we've implemented
them already for "accesskeys" [1] [2].

>> Think about it... ;-)

> ...  ingenuity.

Thanks ;-)

[1]:
http://juicystudio.com/displayarticle.php/user-defined-accesskeys.php?page=user-defined-accesskeys.php
[2]: http://www.tjkdesign.com/articles/user_defined_accesskeys.asp

---
Regards,
Thierry | www.TJKDesign.com



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] "DOM" created table markup [was: Accessible Multi-Column List]

[Paul Novitski]

At 10/26/2006 06:31 PM, Thierry Koblentz wrote:

IMO, the goal should be to deliver the *cleanest* document possible, with
the least amount of structural hack, hook, etc.


You mean like 40 lines of JavaScript to morph the markup of a 16-item list?


In the example I posted, one can't get cleaner than that. The only issue I
see is that screen-readers end up with a table.


Oops.  Isn't accommodating non-visual user agents one of the primary 
reasons we're trying to drag the world wide web off that old table jones?


To be fair, though, using JavaScript to change semantic markup into 
arbitrary glop for the sake of presentation doesn't necessitate the 
use of tables; that was just the way you built this particular 
demo.  You could have simply split the list into two pieces and 
floated them left.




http://www.tjkdesign.com/test/
on top of that, it is possible to make the list display across different
number of columns without having to edit the markup nor the stylesheet;
actually, there is *no* stylesheet ;)


It gets better!  No more pesky separation of structure from 
presentation from behavior!  Now we can have them all neatly combined 
in a single file.  How... compact!




Disabling the script is all what is needed for screen-readers to speak the
links in the proper sequence.


So Jaws users have to disable your tool and all other JS helpers on 
the page in order to read the content in the proper sequence?  I'm 
sorry, but how is this a step ahead?




Think about it... ;-)


I'm thinking mostly that you are one of the brighter lights in our 
firmament, and I love your ingenuity.


Paul

At 10/26/2006 07:19 PM, Christian Montoya wrote:

3. How does this expect to deal with user agents that look at
*generated source* and not original source?




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] "DOM" created table markup [was: Accessible Multi-Column List]

[Thierry Koblentz]

Christian Montoya wrote:
> On 10/26/06, Thierry Koblentz <[EMAIL PROTECTED]> wrote:
>> I don't agree :-)
>> IMO, the goal should be to deliver the *cleanest* document possible,
>> with the least amount of structural hack, hook, etc.
>> In the example I posted, one can't get cleaner than that. The only
>> issue I see is that screen-readers end up with a table.
>> But I have an idea about this: what about going one step further
>> than styles switchers, why not implementing *behavior* switchers? I
>> mean, any fail-safe solution that targets visual browsers could be
>> turned off. I'd say that would be more valuable for many users than
>> giving them a choice between different "skins" or "text-size" ;-)
>> This document is semantic and has nothing extra to parse:
>> http://www.tjkdesign.com/test/
>> on top of that, it is possible to make the list display across
>> different number of columns without having to edit the markup nor
>> the stylesheet; actually, there is *no* stylesheet ;)
>> Disabling the script is all what is needed for screen-readers to
>> speak the links in the proper sequence.
>> Think about it... ;-)
>
> Oh, I've been thinking about it. I've been wondering three things:

> 1. Can't you get the same result by using display:table? (granted, it
> would be hard)

To begin with, IE is "display:table"-challenged (actually, that's what got
me started [1]). And the problem would be the same, with a CSS solution one
would have to plug hooks depending on the number of lists/columns to
display.

> 2. Wouldn't it be better to use the dom to split the list into two
> lists and display them side by side? (how does the table work if there
> is an odd number of items?)

But that's the whole problem. Why trying to generate something half decent?
I think it is better to implement a solution that is perfect for visual
browsers (what is more cross-browsers friendly than a table?) and implement
some "switch" mechanism to disable the script when needed (screen-readers).

Regarding the table with odd number of items, it is just a matter of doing
more Maths to create empty cells to the left of the last ones. This is just
something I quickly put together, I don't think there is any real use for
it... yet ;-)

> 3. How does this expect to deal with user agents that look at
> *generated source* and not original source?

I know, I mentionned this in my previous message. But as a side note, table
for layout is not always a problem [1] (see checkpoints 5.3 and 5.4) .
Anyway, what I'm saying is that we have "skip" links, "increase contrast"
links, "increase text-size" links, why not adding a "turn-off visual
enhancement" kind of link ;-)

[1]:
http://www.tjkdesign.com/articles/make_an_html_list_look_like_a_table.asp

---
Regards,
Thierry | www.TJKDesign.com



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] "DOM" created table markup [was: Accessible Multi-Column List]

[Christian Montoya]

On 10/26/06, Thierry Koblentz <[EMAIL PROTECTED]> wrote:

Christian Montoya wrote:
> On 10/26/06, Paul Novitski <[EMAIL PROTECTED]> wrote:
>> At 10/26/2006 04:06 PM, Thierry Koblentz wrote:
>>> Paul Novitski wrote:
 If you haven't already, please read my List Apart article
 .  I'd love it if
 you could improve on any of those techniques or come up with ones I
 hadn't considered.
>>>
>>> Hi Paul,
>>> What about this one?: http://www.tjkdesign.com/test/
>>> ;-)
>>
>> Table-based markup!  How ingenious!  You're a regular pioneer of the
>> untrod realms, Thierry.
>
> I highly doubt that the idea of using tables for layout will ever
> catch on =)

I don't agree :-)
IMO, the goal should be to deliver the *cleanest* document possible, with
the least amount of structural hack, hook, etc.
In the example I posted, one can't get cleaner than that. The only issue I
see is that screen-readers end up with a table.
But I have an idea about this: what about going one step further than styles
switchers, why not implementing *behavior* switchers? I mean, any fail-safe
solution that targets visual browsers could be turned off. I'd say that
would be more valuable for many users than giving them a choice between
different "skins" or "text-size" ;-)
This document is semantic and has nothing extra to parse:
http://www.tjkdesign.com/test/
on top of that, it is possible to make the list display across different
number of columns without having to edit the markup nor the stylesheet;
actually, there is *no* stylesheet ;)
Disabling the script is all what is needed for screen-readers to speak the
links in the proper sequence.
Think about it... ;-)


Oh, I've been thinking about it. I've been wondering three things:

1. Can't you get the same result by using display:table? (granted, it
would be hard)

2. Wouldn't it be better to use the dom to split the list into two
lists and display them side by side? (how does the table work if there
is an odd number of items?)

3. How does this expect to deal with user agents that look at
*generated source* and not original source?

--
--
Christian Montoya
christianmontoya.com ... portfolio.christianmontoya.com


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***