W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2006

Re: [WebAIM] More data on accesskeys (New article written Nov. 1)

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Tue, 21 Nov 2006 15:07:20 +1100
Message-ID: <45627B78.1090302@lachy.id.au>
To: Alastair Campbell <ac@nomensa.com>
CC: w3c-wai-ig@w3.org, John Foliot <foliot@wats.ca>

Alastair Campbell wrote:
> Lachlan Hunt wrote wrt validation:
>> HTML 5 dispenses with useless DTD based validity.
> 
> For those who haven't memorised the latest specs (99.9% of the web 
> development population?), being able to validate your markup is very 
> re-assuring, especially when being produced by a complex system. It is 
> for me at least. Is that what you meant, or can you check for 
> well-formedness regardless of DOCTYPE?

You seem to be mixing concepts.  Well-formedness constraints apply to 
all XML documents with or without a DOCTYPE and regardless of whether or 
not they are valid.  Validity is simply the assertion that the document 
conforms to the grammatical rules expressed in a DTD or other schema.

There are several major problems with DTDs, one of them being that they 
pollute the document with schema-specific syntax.

http://hsivonen.iki.fi/validator-about/#faq

That creates an unnecessary link between the document and the schema. 
The important question is not simply whether a document conforms to the 
rules it expresses for itself, but whether or not it conforms to the 
rules and requirements expressed by the one asking the question.

Validation, conformance checking and DTDs have been discussed a little 
more in this recent blog entry, and a few others that go into more 
technical details.

http://blog.whatwg.org/html-vs-xhtml
http://blog.whatwg.org/category/conformance-checking/

> I followed the set-up of WHAT-WG, but I have to admit that the setting 
> up new elements like <nav> and <article> was news to me. Functionality 
> wise it would overlap considerably with the proposed use of the role 
> attribute.

I think the reason for introducing the new elements was because they're
easier for authors to use.

>>>> <label for="...">Foo <a href="#help-foo" 
>> rel="help">(help)</a></label>
> 
> Interesting, I guess a little bit of unobtrusive JavaScript could call
> the content up without moving off the form.

That's exactly what I was thinking.

http://juicystudio.com/article/form-help-without-popups.html

> In terms of ease of implementation for a site, and maintainability, 
> using aspects you are already including in the markup is great, +1 for 
> HTML5's new elements. With regards to site navigation, I'm not overly 
> happy with having to declare site-wide navigation on a per-page basis 

I don't understand.  Regardless of whether you put the site navigation 
in the page content or use links in the head, the links still need to be 
present in every page.  However, for practical reasons, every navigation 
link you include as a <link> in the head would have to be duplicated in 
the body anyway, so using link elements for such purposes is practically 
redundant in the real world anyway.

> Could we use a link in the head that goes to a static (cacheable) file
> for site-wide navigation? I know you could use a server side include,
> but it seems kludgy, as you are still sending (potentially) quite a lot
> of HTML with every page.

There are at least 2 major problems with using technique like that.
1. Backwards compatibility.
2. Such a major conceptual change in the way pages are linked is 
unlikely to catch on significantly in the real world.

> With regards to <link>s under-use, unless someone makes a pluggin for IE 
> or it supports it natively, it is unlikely to change. Unless of course 
> Opera or Firefox become the defacto browsers for people with 
> accessibility issues ;)

But there's still the issue that the functionality provided by any use 
of <link> as a navigation link can be done equally well, if not better, 
with a regular <a href="" rel=""> link.

-- 
Lachlan Hunt
http://lachy.id.au/
Received on Tuesday, 21 November 2006 04:07:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:31 UTC