Re: Removal of other semantic elements

Oops, forgot link in last email

PPK's email can be found at
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2004-June/000112.html.

Shelley


On Sun, Apr 4, 2010 at 7:24 PM, Shelley Powers <shelley.just@gmail.com> wrote:
> 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:45:23 UTC