W3C home > Mailing lists > Public > public-html@w3.org > May 2008

RE: HTML Action Item 54 - ...draft text for HTML 5 spec to require producers/authors to include @alt on img elements.

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>
Message-ID: <03e601c8b3ea$5e48fd20$1adaf760$@com>

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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:54 UTC