Re: Removal of other semantic elements

On Sun, Apr 4, 2010 at 6:54 PM, Laura Carlson
<laura.lee.carlson@gmail.com> wrote:
> 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.

In the positive effects,  I provided the following:

For progress:

"Removes another new element in the rather large pool of new HTML5
elements. This reduces the burden on all user agents, including
browsers, editors, and so on. It's important for the HTML WG not to
introduce new elements that are redundant considering the state of
supporting technologies today, such as CSS for styling, JavaScript for
behavior, and ARIA for both semantics and accessibility (and even
Canvas and SVG, if we want to get fancy with graphics). We shouldn't
be creating single-purposed elements unless there is no existing
functionality that can serve the purpose of the element, and that's
definitely not true with progress bars."

For meter:

"Removing meter removes another element from the fairly large number
of elements and attributes added with HTML5. In addition, it removes
an element whose sole purpose and seemingly sole use case, is to
ensure that another element was not used incorrectly. This, to me, is
not a strong case for adding an element to HTML5, especially
considering how much work each new element generates for browsers,
HTML editors, and so on.

In addition, not creating a new element encourages people to use any
number of the existing libraries and packaged widgets already
available for use, and that have been available for use for many
years. The meter element welds structure, behavior, and style into a
single purposed element. Such single purposed elements are counter to
the direction the web has been going for the last decade. Especially
now, when we have so many new graphical possibilities, with the new
support for SVG inline in HTML, and increased support for the Canvas
element. It's better to encourage people to use existing graphical
technologies such as CSS, SVG, and Canvas, and existing semantics and
accessibility technologies, such as ARIA, RDFa, Microformats, and
Microdata, and leave the structure to HTML. "

For hidden:

"This removes an inconsistent approach for hidden content that can
cause confusion to developers about which direction to follow for
accessibility. This also removes a redundant attribute, helping to
simplify the HTML5 specification. It also prevents establishing a new
precedent of replacing the currently encouraged separation of
presentation and structure, with single purposed attributes/elements.

For browser developers and other user agents, this change reduces the
need to support an HTML5 attribute, in addition to CSS and ARIA states
that perform the exact same behavior. HTML editors will have one less
new HTML5 entity to worry about implementing. Authors, developers, and
designers will have a clear direction to follow for element display
and visibility

For Details:

"By continuing the trend that has been established for the last decade
when it comes to widget (dynamic application) development, we have a
much greater control over every last aspect of how this widget
behaves. Moreover, this control does not come at the cost of
accessibility. If anything, with recent efforts related to WAI-ARIA,
we're seeing a greater integration of accessibility into dynamic
effects.

So, the details element is not superior to the current
state-of-the-art for this type of functionality. In addition,
implementing a well defined and well understood JavaScript/CSS/ARIA
behavior as declarative animation built into the HTML specification
introduces the potential for explosive growth in HTML.

Earlier, I listed several forms of web space widgets: tabbed pages, an
accordion, and a collapsible section. Only the last option is an
equivalent JS/CSS behavior comparable to the Details element. However,
it is feasible to list all three because if there's justification for
adding a declarative equivalent for one, there's equal justification
for adding a declarative equivalent for the other two...or for the
dozens of other commonly used, packaged JavaScript/CSS behaviors.

Once we've opened this declarative element door, it becomes
increasingly difficult to justify shutting it, again. This action
could lead to a never ending set of behaviors being integrated into
the existing and future versions of HTML—incorporating as elements
that which was gracefully handled by JavaScript and CSS. Taking this
action impacts not only browser makers, but also HTML editors, Content
Management Systems, validators, and other tools, which have to
increasingly expand and add new items, new objects, new behaviors.

More importantly, there is no graceful way of integrating this new
declarative elemental behavior in with existing JavaScript/CSS
application development. The existence of a Details element fractures
the clean separation between behavior, style, and structure that had
existed to this point, and has served us well, as witness the many and
sophisticated applications we use today. "

And also stated:

"Removing the details element allows us to continue to progress with
our use of JavaScript, CSS, and ARIA to create interesting, diverse,
and accessible dynamic behaviors. It also prevents a possible
explosion of such declarative animations in the existing and future
versions of HTML, which will adversely impact on browsers, HTML
editors, tools, and so on."

For figure:

"This alternative to figure I've provided in this change proposal is a
frugal one that serves the same purpose for multiple user agents,
multiple audiences, and uses available technology and specifications.
It allows people to create any form of illustration, and ensures
they're accessible.

Removing the figure element and associated figcaption element, helps
trim down the overlarge number of elements that have been added with
HTML5. Each new element we add to the specification has a related cost
when it comes to implementation—not only across browsers, but also
other tools, such as HTML editors, and HTML generation tools.

In addition, encouraging the use of existing HTML, CSS, and ARIA
properties and attributes also encourages reuse over creating new,
which should be a fundamental goal of this group. If there is a strong
rationale for creating something new, and there really isn't a good
alternative, then we can feel justified in creating new elements.
However, in the case of figure, as both Michael and Simon have pointed
out, we've made do with what we have today. We can improve what we
have with the addition of the ARIA states and roles, and ensure both a
semantic and an accessible solution."

For aside:

"Removing the aside element removes a element that has generated
confusion since its first release—a confusion that doesn't seem to
lessen over time. The element provides little in the way of semantics,
because it's more or less based on a construct from the print world,
and doesn't really have much application in a web environment.
Structurally, it provides nothing useful.

Removing the element reduces the confusion, but is also a cost saver
in the future for HTML tool builders. Though browsers can more or less
treat aside like a div element, HTML editors and other tools cannot.
If there was a genuine purpose for the existence of the element, the
cost would be justified. But the element's definition is now so
general that we might as well consider it a synonym for the div
element. "

I can add more, if your points aren't covered. Let me know.


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

Yes, I believe I mentioned that in a couple of the change proposals.

Interesting, but I've been reading the history and roots of the
current specification. When the WhatWG created a web site and forum,
it had already created a specification for what it called Web Forms
2.0. When it started the WhatWG, it asked for comments. Peter-Paul
Koch responded with an email[1] titled "Why not JavaScript?" In it, he
wrote:

"JavaScript turns up regularly in this discussion, so I though I'd state a
few obvious points and ask a few questions that nobody else seems to have
asked as yet.

First of all, when I read the (very interesting) position paper, it struck
me that every described feature can be implemented in JavaScript *right
now*, maybe except for the server sent events and the clipboard api (but
even in those cases it might be possible).

Therefore I wondered why we'd have to invent a wholly new language to do
what can already be done, especially when we'd have to wait about three to
five years before browsers start to support it, and with the extreme
likelihood that IE won't support it anyway.

As far as I'm concerned we have the choice of using JavaScript right now, or
waiting for (probably buggy and incompatible) browser implementations of as
yet unknown techniques in the distant future.

Of course using JavaScript has a downside, too. My current personal
guesstimate is that about 2 to 3 % of the Web users have JavaScript
disabled, voluntarily or by Sysadmin Decree. It may be somewhat more or
less, but that's not the point. The point is that JavaScript is not 100%
reliable.

Therefore the question becomes how important JavaScript's imprecise
reliability is. This depends on the *purpose* of the Web application, and I
haven't yet seen a single mention of this purpose, neither in the position
paper nor on this mailing list.

I'm confused by the paper's mention of eBay and Amazon as examples of web
applications. To me, these are not applications but web sites, and they can
function without JavaScript (I'm not saying they do, I'm just saying they
can). The core tasks of these sites (bidding on items and buying books)
don't require richer widget sets, window-based state management, predefined
HTML editors or server-sent events.

Any web application that enhances these sites is therefore not critical but
a nice extra. Hence the use of JavaScript to program them is quite allowed.
Noscript browsers can still perform the core tasks.

HTML editors and such are very valuable for content management systems and
such, but these applications run in a controlled environment where it is
permissible to require a JavaScript enabled browser. So here, too, the use
of JavaScript is quite allowed.

Can someone please give an example of an application where richer widget
sets, window-based state management, predefined HTML editors or server-sent
events are *absolutely required*, an application that, when created in
JavaScript, *cannot* be designed to degrade gracefully in noscript browsers?

I feel that any web application must have a strong server side component, to
store the data and to allow  people to add, change or delete data. These
tasks can be performed in the absence of a rich web application and/or
JavaScript, simply by entering the data in a form and clicking "Submit".

In short, I don't see any reason *not* to use JavaScript to create a richer
client environment. Can somebody please explain why we need a new language?"

This issue has been around from the very beginning. What's interesting
was a response[2]:

"JavaScript is all powerful, but one good example in regards to forms is
accessibility - by putting it all in markup, screen readers can gain
semantic knowledge of what the form wants to do.  Now it could be
possible to make JavaScript more accessible, but no one seems to want to
try :)"

But between then and now, much has changed. New ECMAScript specs and
implementations that provide even more powerful functionality.
Improvements in CSS. Increased support for canvas and SVG. Wonderful
new libraries that are not built into environments, such as weblogging
tools and other Content Management Systems.

And ARIA.

And even a new browser, and something other than IE6.

It's as if we're operating on a design principle based on the state of
the web and other technologies--including accessibility-- that existed
in the beginning months of 2004. And that the intervening six years
don't exist.

This is such a different world now.

Anyway, if what I provided isn't sufficient to make the points you
brought up, Laura, I'll make additional edits.

I still would like the co-chairs to call for counter-proposals, though...

> Best Regards,
> Laura
>

Thanks,

Shelley
> --
> Laura L. Carlson
>

Received on Monday, 5 April 2010 00:24:55 UTC