Re: Preparing to launch the Forms Task Force ...

Ok, not to say that I agree with everything on that xhtml.com article, 
because I don’t, but replying anyway…

Matthew Raymond schreef:
>    Here's my review of the "uncool" features in HTML5:
>
> Implementation Of Sectioning Elements:
>
> I view the |role| attribute as extremely harmful. To give an example:
>
> | <div role="aside"> [...] </div>
>
> ...Versus...
>
> | <aside> [...] </aside>
>   

Please, make that <section role="aside">, not div.

>    How is the use of |role| better than simply having <aside> element?
>   

I think that the WHATWG spec is currently quite inconsistent, some of 
the structure being created with predefined classnames, and other 
structure with elements. They should either just all be using role, or 
otherwise the predefined classnames (I have nothing against them per se, 
and they’re easier to use in CSS). Different elements just makes things 
more complex than they really are, because they’re just sections of 
different kinds.

Also, people are doing this effectively *right now* with class names, 
and I don’t see them complaining that it’s too long. I don’t see the 
problem with that.

>    Furthermore, how is it better than a "aside" attribute?
>
> | <div aside> [...] </div>
>   

An aside attribute would not be extensible. The role attribute is not 
limited to the predefined set of values. See the previous 
meta-attributes argument, which is similar.

>    The real problem with the |role| attribute, however, come in when you
> want to add attributes to refine semantics. With an element, you just
> add some element-specific attributes. With |role|, you have to add more
> global attributes.
>   

I don’t see it being a problem in practice. Besides, all those elements 
encode implicitly that it’s all a section, so in a way you could say 
that the WHATWG elements are doing just that what you say you dislike 
about role!

What I like about role (or class or whatever) is that the section is 
explicit. A section is an important structural document element, and I 
shouldn’t have to create rules like 
section|nav|header|footer|aside|article to match all different types of 
sections, or determine their heading levels, etc. It gets worse when you 
add in that you also have to match h1|h2|h3|h4|h5|h6 because sections 
may contain headers of any rank. But that only applies to sections, and 
not to the other five section types, so apparantly they are second-rank 
citizens.

That is why I’m very much in favour of <section> and <h>. Retain 
<h1>...<h6> for backwards compatibility where necessary. And skip that 
whole HUUUGE section on the exact semantics of implicit sections with 
the latter. Which is of course pretty much what XHTML2 did.

>    In my view, |role| is anarchy masquerading as utility.
>   

Some people call the fact that everyone can create his own website, and 
link to any other, anarchy. <sarcasm> It can never work!! Oh wait. 
</sarcasm> :)

>    The fate of the <acronym> element is still being debated, and many
> WHATWG contributors believe it should be kept.
>   

No, begone <acronym>. That’s one of the good things in XHTML2 that I’m 
glad HTML5 also has.

> WYSIWYG Signature:
>
>    I would tend to agree that this should be a "SHOULD" rather than a
> "MUST".
>   

Yah, I don’t see the point in the spec saying anything about that at all.

> Support For Predefined Class Names:
>
>    Predefined classes were purely put into the WA1 spec to encourage a
> dialog about the subject. Many contributors to WHATWG oppose them, and I
> wouldn't be surprised to see them removed at a later date.
>   

To me they seem like a CSS-friendly version of the role attribute. I 
like the concept, as mentioned above, but would prefer role.

> HTML 5 Versus XHTML 5:
>
>    The following is indeed contained in the WA1 spec:
>
> | Generally speaking, authors are discouraged from trying to use XML on
> the Web, because
> | XML has much stricter syntax rules than the "HTML5" variant described
> above, and is
> | relatively newer and therefore less mature.
>
>    So long as XHTML uses the "application/xhtml+xml" MIME type, I'm not
> sure this is appropriate. There is a valid argument for it, but I think
> it's more of an opinion than a fact.
>
>    At any rate, the section it's in says "This section is non-normative"
> right at the top.
>   

The spec should not make any statement on this matter. It is a 
controversial subject has no rights or wrongs. Basically, there are two 
camps on this subject, and this reflects the perspective of one of them.

No programming language (including JavaScript) gets away without strict 
error checking. Yet people are perfectly fine to understand and use 
them. So saying that stricter type checking is something that should 
discourage you is very subjective, it is merely something to get 
accustomed to, just like HTML also had to be learned in the first place, 
and in the end it will help you make less mistakes. Continueing to make 
vague claims about the ‘maturity’ of XML on the web is also not doing 
much good. My website is served according to the XHTML appendix C, with 
Accept header detection, and does so perfectly fine. This is the realm 
of opinions and different levels of skill, and it is not up to the spec 
to make these kind of statements.

Whether or not the section says it is normative or not, it has no place 
in this specification.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.