- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sat, 7 Nov 2009 21:58:57 -0800
- To: John Foliot <jfoliot@stanford.edu>
- Cc: Richard Schwerdtfeger <schwer@us.ibm.com>, HTMLWG WG <public-html@w3.org>, public-html-request@w3.org, W3C WAI-XTECH <wai-xtech@w3.org>
On Sat, Nov 7, 2009 at 6:41 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Sat, Nov 7, 2009 at 11:36 AM, John Foliot <jfoliot@stanford.edu> wrote: >> Jonas Sicking wrote: >>> Richard Schwerdtfeger wrote: >>>> >>>> All we are doing is allowing the author to convey their intent. Do I >>> wish >>>> authors would use html elements for their purpose? Of course. That is >>> not >>>> the world we live in. Whether we believe something is a cowpath is >>> really >>>> irrelevant. Industry thought HTML was only for documents in 1998 too. >>> >>> Do you have any reason to believe that we'll be more successful in >>> asking authors to add a role attribute to the <a> than in asking them >>> to change to use a more appropriate element? >> >> Hi Jonas, >> >> We really have no reason to believe any given author will do anything >> right *or* wrong; experience tells us to expect both. The real question >> is, why impose limits when we don't really need to? Think inclusive, not >> restrictive. > > So the theory is that if we give people more tools they are bound to > use one of them? > > This to me feel similar to the philosophy of Perl: "There's more than > one way to do it". I personally favor the approach that python is > taking, which is "keep it clean and simple". > > However, comparisons with programming languages don't necessarily > carry over to accessibility features. It's quite possible that for > accessibility features having more ways to do the same thing is > advantageous. > >> We can see JS libraries do that (add a role attribute to the <a>) for the >> author if/when required (as one use-case: ARIA is/was designed primarily >> for "DHTML / AJAX"). Moreover, what real harm is caused by allowing to do >> so? > > The harm that I see is loosing the ability to have a clear message for > what the right way to do things is. > >> We can't envision all uses that authors might dream up moving >> forward: look at Bespin and Canvas - nobody really envisioned Bespin like >> use when Canvas was spec'd, yet here we are today. > > I'll note that what Bespin did is not valid HTML 5. The spec says: > > "Authors should not use the canvas element in a document when a more > suitable element is available" > > There is definitely more appropriate elements in this case, thus > Bespin is not valid HTML 5. Hmm.. actually given that the spec says "should not" rather than "must not" I guess it's still conforming according to the spec. / Jonas
Received on Sunday, 8 November 2009 05:59:55 UTC