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

Sierk Bornemann wrote:
> 
> Am 14.03.2007 um 16:07 schrieb Laurens Holst:
> 
>> I am having doubts how this W3C - WHATWG relationship can work  
>> properly without the WHATWG giving in, even though Ian listed some  
>> instances where it apparantly has. I think you made a good point  
>> that having two separate places for discussion being less than  
>> ideal, to say the least. Plus that all those people on the WHATWG  
>> list haven’t signed the patent policy. Can the W3C copy a feature  
>> in the WHATWG’s spec if the person who proposed it didn’t join the  
>> W3C HTML WG? It seems to me that any new idea proposed on the  
>> WHATWG list could potentially be one idea less that can make it  
>> into the W3C specification, even if it’s really good. The person  
>> who originally proposed it could file a patent, because he(/she) is  
>> not bound by the policy. The only thing you could do is to track  
>> him down and get him to sign the patent policy separately, which  
>> seems like a lot of trouble. Or am I missing something here?
>>
>> It also sounds doesn’t sound like an efficient use of Ian’s time if  
>> he is constantly keeping both specs in sync (although it of course  
>> is his time to spend), and we would easily get into a situation  
>> where every new feature introduced in one working group is  
>> separately reviewed by the other before it is accepted. And what if  
>> it’s not… Ian says that he will keep the WHATWG spec a strict  
>> superset, but what if the WHATWG members are against a certain and  
>> the W3C members in favour? Say, a <h> element for headers within  
>> sections, something that never got into the WHATWG spec. Does the  
>> W3C take precedence? In that case, why is the WHATWG still there?
>>
>> To me it seems that it would be so much easier if the WHATWG handed  
>> over their entire effort to the W3C, then everyone could work  
>> together on this instead of getting two (possibly diverging)  
>> specifications. I’m sure that this does not sound like a happy idea  
>> to everyone, especially those who have put a lot of time in  
>> organising the WHATWG effort, but people have shown enthusiasm for  
>> the W3C picking this up, now they should allow the W3C to really do  
>> so and not complicate matters unnecessarily, but just move from the  
>> WHATWG to the W3C as the location for discussion and spec development.
>>
>> I just ask you, given the W3C HTML working group that is now  
>> starting, what is the purpose of the WHATWG?
> 
> 
> I totally agree with you, Laurens.
> Especially the issues of HTML5, named on http://xhtml.com/en/future/x- 
> html-5-versus-xhtml-2/#x5-uncool should be solved.

   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>

   How is the use of |role| better than simply having <aside> element?
In order to get the semantics of an "aside", you still have to remember
the name. It takes more characters to type. There's also the chance that
the role may be placed on an element were either the semantics of an
"aside" have no real meaning or the semantics actively conflict with
those of the element.

   Furthermore, how is it better than a "aside" attribute?

| <div aside> [...] </div>

   Even that's shorter. Sure, it's a little longer in XHTML...

| <div role="aside"> [...] </div>
| <div aside="aside"> [...] </div>

   ...but even then, at least you can define what elements the attribute
can be placed on, thus having some control over the attribute being
placed on inappropriate elements.

   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.

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


HTML 4 And XHTML 1 Faults Are Perpetuated Into A Future Spec:

   If it works in HTML 4.01 Strict and XHTML 1.0 Strict, it would work
in (X)HTML 5. To do otherwise will prevent most developers from making
the switch. The <small> element has a good use case for "fine print"
contexts, and it would be suicide to get rid of <iframe>, as much as you
may not like it. The <font> element already faces strong resistance on
the WHATWG mailing list.

   Please remember that Web Apps 1.0 is not a stable draft like Web
Forms 2.0. (Although some parts are far more stable than others.)


X/HTML 5 Does Not Comply With The X/HTML 5 Charter:

   I disagree. HTML5 redefines semantics for presentational elements to
make them less presentational and more semantic, but that has no
practical effect on user agent compatibility. Indeed, it allows these
elements to have alternate presentations in future user agents.

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

   The <tt> element is presentational without having any real semantics.
Unlike <i> and <b>, it has much weaker use cases for communicating any
real semantic information. Thus, it makes sense to obsolete this
element, and many browser can already style unknown elements anyways, so
we really don't loose anything.

   The <u> element was deprecated in HTML 4.01, and it makes sense to
drop it at this point, especially in light of the fact that it causes
confusion as the result of links commonly being underlined.

   Nutshell: There is no practical loss of compatibility with HTML 4.01
markup.


WYSIWYG Signature:

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


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.


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.


A Too Hasty Process:

   Web Apps 1.0 has not been submitted to the W3C specifically because
it is neither completed nor stable. The draft itself says "This is a
work in progress!", and it should be treated as such. Thus, I don't
understand the haste that the author is concerned about.

> I am personally confident with XHTML, it should get extended by the  
> goodies of HTML5, the issues and not-so-cool properties of HTML5  
> shouldn't make their way into the new HTML WG/Spec.

   In all likelihood, a significant number of those "not-so-cool"
properties of the WA1 spec would have been dropped or changed anyways,
even if the HTML WG had never been created. As for the remaining issue,
those still need to be discussed.

> Ian's honourable engagement in the WHATG and the rest of the WHATG  
> maintainers/contributors should completely merge into this new W3C  
> HTML WG to bundle all energy to one common shared goal.

   Given that this working group is largely a reaction to WHATWG, I
don't see how the dissolution of the WHATWG would encourage the
continued incremental development of HTML, nor would there be any real
way to make the W3C take current WHATWG specifications seriously without
its continued existence. The mention of XForms Transitional (formerly
XForms Tiny) in the charter is good evidence of this.

Received on Thursday, 15 March 2007 00:22:52 UTC