- From: Justin James <j_james@mindspring.com>
- Date: Mon, 12 May 2008 00:40:56 -0400
- To: "'Robert J Burns'" <rob@robburns.com>
- Cc: "'Ian Hickson'" <ian@hixie.ch>, "'John Foliot'" <foliot@wats.ca>, <public-html@w3.org>
Except from Robert Burns: > Are you simply saying you want > the element type names to only distinguish technical differences > (content models for example), and that the attributes should be used > to differentiate the more heuristic and human perceivable > [distinctions? I'm not sure why a markup specification should make such > a distinction. You phrased my thoughts much more precisely than I did, thank you! The reasoning behind this is that it provides a clear and consistent mechanism for applying semantics (always an attribute, as opposed to sometimes being a tag like <p> and sometimes being an attribute like ARIA uses). It also (finally) fully separates form from content from function. With <p> for example, it is extraordinarily difficult for someone to really "get" where to use it appropriately. Imagine a new HTML author writing a table of information. Do they choose to put the text contained within the <td> in <p> as well? What if the contents of the cell are just the letter "X" (to mark, say, a product having a feature in a feature comparison). The text is not a paragraph and certainly not intended to be one. So why does the paragraph of text explaining the feature a few columns later get a <p>? See how hard this is? Finally, the #1 biggest problem with the "semantic" elements is that browsers (reasonably enough) support default styling of them. As a result, they are misused and abused. By eliminating the "semantic" elements, and forcing each element to have a semantic purpose chosen, one that is wholly and utterly divorced from any kind of styling, we accomplish the following with one fell swoop: * Make using the right tag (or tag + attribute) for every situation have the exact same level of difficulty as using the wrong one. * Remove all benefits to using the wrong tag. For example, if <h1> is replaced with <span role="header1">, but without @class, @ID, @style, etc., it is un-styled, there is suddenly no reason at all to be making something a header unless the author truly wants to make something a header. * Force authors and their authoring tools to actively select the appropriate element + attribute combination, and not just throw a lot of junk out there by default. * Finally make it more work to write a table for layout that to not use it (yes, I am proposing <div role="table">, <div role="row">, and <div role="cell">). > [However, I will say that given the constrains of existing browsers and > other UA implementations in parsing HTML, we are much better off > introducing new attributes than introducing new elements. New elements > such as VIDEO, FIGURE, SECTION etc. will not parse correctly with > existing, recent and legacy UAs. However, using <div role='section'> > [will parse correctly with existing UAs and HTML5 aware UAs can apply > the proper presentation and treatment of such elements. Likewise > adding the markup content attributes for video and audio (time-based, > spatial and audible properties) to the OBJECT element instead of > introducing new elements would be more in keeping with the Design > Principles of the WG. However, I sense you're saying something else in > the abstract in this element/ attribute distinction. Actually, this never occurred to me at all, but you are absolutely right. My proposed approach is incredibly non-breaking of previous HTML; older browsers will still render it right (since I divorce role from style). Not to toot my own horn here (especially since all I am really pushing for is a stripped down version of HTML, with ARIA baked in), but this is the only way to accomplish (that I have seen proposed): * Finally working towards a machine parsable "semantic web", as opposed to the historic trend of providing new elements for browsers to conjure up what they assume the correct default styling should be * Enforceable accessibility and usability * Allows even older browsers to display it perfectly, all they "lose" is the semantic stuff they are not using anyways * Encourages authors (and creators of authoring tools) to use good practices, and makes their code invalid (in a machine checkable way) when they don't J.Ja
Received on Monday, 12 May 2008 04:41:48 UTC