Re: Removal of other semantic elements

Hi Shelley,

> My change proposals primarily responded from accessibility
> perspective because that's how the HTML5 editor styled his rationales
> for rejection--based purely on accessibility.

Accessibility as rationale for existence of the interactive elements
might be a red herring. Did the accessibility community help with the
design of any of the interactive elements? Were they ever consulted?
Have the elements been tested in AT?

> Would it help if I edited the change proposal to put more of the
> emphasis on custom UI libraries as compared to native elements?

It might Shelley. It might even be bigger than that. Some items that I
am wondering about with the interactive elements:

What ever happened to the Zeldman type three-leggged stool approach to
web standards? Separating structure, presentation, AND
behavior...Where HTML is for structuring content. CSS is for
presentation. JavaScript and the like are for behavior. This gets back
to modularity and separate layers.

What is the criteria for of interactive elements as a set? Have they
been looked at holeisicaly and not piecemeal? Patrick made an astute
comment on Bruce's blog:

"personally, i don't like this because it's so strangely specific to
one single effect. why not define another element for an accordion
menu? and another one for a dropdown menu? or an image carousel?
it seems arbitrary that the spec should have a baked-in effect like
this little expando-thing...unless i'm missing the point
completely..."
http://www.brucelawson.co.uk/2010/html5-details-element-built-in-and-bolt-on-accessibility/#comment-666275

Best Regards,
Laura

-- 
Laura L. Carlson

Received on Sunday, 4 April 2010 23:54:50 UTC