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]
*******************************************************************
