[whatwg] some issues
mattraymond at earthlink.net
Mon Jul 5 12:19:28 PDT 2004
C Williams wrote:
>>The mime type "text/html" is not appropriate for XHTML. The
>>only reason it's even in the W3C specs is because the W3C is
>>bowing to pressure from people who want to use XHTML in
>>browsers that don't actually support it, but instead treat
>>it as if it were HTML code soup. This encourages hybrid
>>XHTML/HTML code that doesn't conform to standards. (I've
>>actually seen this happen.)
> Which, whilst undoubtedly both correct and beautifully erudite,
> has absolutely *nothing* to do with my point. I have no
> complaints with that at all. If you read it again, however,
> you'll notice that I was referring to Web Forms 2.0 over-ruling
> of the W3C's assertion that XHTML documents MUST have a doctype.
After going back an review your previous email and the latest WF2
draft, I figured out what the issue is. The WF2 draft modifies XHTML to
bring it in line with RFC3023 (http://www.ietf.org/rfc/rfc3023). From
"Sniffing XML also isn't as simple as it might seem. DOCTYPE
declarations aren't required, and they can appear fairly deep into a
document under certain unpreventable circumstances. (E.g., the XML
declaration, comments, and processing instructions can occupy space
before the DOCTYPE declaration.) Even sniffing the DOCTYPE isn't
completely reliable, thanks to a variety of issues involving default
values for namespaces within external DTDs and overrides inside the
internal DTD. Finally, the variety in potential character encodings
(something XML provides tools to deal with), also makes reliable
sniffing less likely."
> If it isn't html or xhtml, it can hardly pretend to advertise
> itself as such, can it? - unless, of course, you envision these
> elements as proposed revisions of HTML itself, which I believe I
> suggested, although you seem to ...
I'm confused. How can a group claiming to be extending HTML and
XHTML not be working on an HTML/XHTML spec? I fail to see the element of
> That doesn't change the pollution issue one iota.
Could you be more specific as to that you mean by "pollution"?
>>How do you determine interdependency based on a single
>>specification (Web Forms 2.0)??? Right now, the other two
>>specifications are just shells with a few notes in them. It
>>may be a good suggestion to limit dependencies between the
>>specs, but that hardly means such dependencies
>>exist when two of them aren't even written yet.
> It was my observation, from perusing the last few weeks of
> traffic on this mailing list, that many people had mentioned
> ideas which bore a direct relevance to Web Forms 2.0 - feature
> requests, implementation details etc. - only to be told that
> they would definitely be in Web Controls 1.0, Web Apps 1.0 etc.
If there was a feature I truly felt should be in
> I would imagine that the Web Forms 2.0 proposals would look more
> complete if they were part and parcel of the same specification
> as Web Controls 1.0, no?
No. Web Forms 2.0 can be added with minimal effort to most
HTML-compliant user agents. Web Controls 1.0, by contrast, will probably
depend heavily on XBL2, CSS, DOM and other technologies that have
nothing to do with HTML. WF2 presents a limited set of new features and
widgets specifically to make certain common types of forms easier to
make. Web Controls 1.0, by contrast, has nothing specifically to do with
forms and probably won't even be released until the W3C gets finished
> - given that Web Controls 1.0 is
> described as "Some DOM and CSS extensions to create *new form
> controls* and widgets".
Web Controls 1.0 may just be powerful enough to implement a subset
of XAML on, so of course it can be used to create new form controls.
> The W3C have been getter further and further away from how
> *web-page* elements themselves should been represented (both
> presentation and model) and more concerned with the semantic web
> and data modeling / transformation. WHATWG seems like a
> concerted attempt by the actual UA developers to redress the
> balance. It wouldn't suffer if it were released as one
> specification, and might gain.
On the contrary, a monolithic proposal would be a disaster. It
creates an "eggs in one basket" scenario where the W3C could reject the
entire specification. It also makes for a tougher read because of its
size, and the specification will be less focused because it will need to
include WF2 + WA1 + WC1.
WHAT WG has wisely elected to take a modular approach to these
drafts. By having separate drafts for each group of extensions, it
allows the following:
1) The time it takes to get feedback from a standards organization is
2) The length of time it takes to get developer-related feedback on a
spec is also reduced. Developers may actually finish a implementing one
specification before the next even reaches a final draft.
3) Problems encountered during the submission of earlier drafts can be
addresses in later drafts.
4) People specifically interested in certain topics will review the
shorter, individual specification of their choice and give advice based
on their area of expertise. This is less likely with a monolithic spec,
because the more general topic may not attract their attention.
> As it stands, the fact that the proposals over-ride W3C
> recommendations on HTML/XHTML is almost a guarantee that no
> standards committee aside from the W3C itself could ever ratify
> them, as they wouldn't wish to be seen to be redefining the
> W3C's own specs, especially given the highly politicized nature
> of the browser wars.
I seriously doubt that the W3C will throw out the entire Web Forms
2.0 proposal over a disagreement over DOCTYPE.
> The W3C, otoh, won't ratify them as
> anything other than an evolution of HTML/XHTML, precisely
> because they tread directly on those technologies. I'm making an
> attempt at political realism.
Who's to say they won't just treat them as individual modules of
HTML 5.0? The W3C isn't stupid enough to reject a proposal because it
doesn't have "HTML5" on it.
>>Web Forms 2.0 deals with extending form functionality. Web
>>Apps 1.0 will deal with new widgets intended for web
>>applications. Web Controls 1.0 will involve creating a system
>>by which web developers can easily create custom widgets.
>>All of these sound like separate extensions to me.
> Yet with plenty of common ground to make more coherent sense in
> united specification.
About the only common ground they have is that they're extensions to
existing web standards.
>>>Get them *all* ready, and submit them *all* as an
>>>extension to HTML, dropping the XML component.
>>Why? Why create one incredibly long specification that
>>will put people off by its mere size? Why drop XHTML support
>>when the browser vendors that have employees as members of
>>WHAT WG all support XHTML?
> I'm thinking more about adoption, generally. You can't very well
> offer the "Well, we're all here so that's all that matters"
> argument. Anyone else contemplating adoption, or even getting to
> know the specs, at the client programmer end, will more likely
> wait until they know the complete picture before fully
Why? Most browser developers aren't implementing the complete specs
as it is. If they were to implement a monolithic specification, they'd
just throw out the parts they didn't want to support anyway. The
difference is that the smaller the specification, the more difficult it
becomes to justify not supporting the whole thing.
> Imagine *another* browser vendor wanting to implement your spec.
> Why would they commit to web forms until they know the big
> picture? Perhaps, between the three of you, IE, NS (who'd adopt
> the mozilla code) and Konqueror, the desktop is fully catered
> for, but what about development for handhelds and pda's.
[Matthew coughs in a manner that sound remarkably like "Opera".]
Let's not also forget that there are some browsers out there on
handheld devices that ONLY support XHTML. Look at the User's Guide for
the Nokia N-Gage QD:
"Various service providers maintain pages specifically designed for
mobile devices. To access these pages, press [page-looking icon] and
select Web. These pages use the Wireless Markup Language (WML) or
Extensible Hypertext Markup Language (XHTML). Pages using the Hypertext
Markup Language (HTML) cannot be viewed on your device."
So do we tell everyone with web-enabled phones "tough luck"?
> best application model would suggest knowing how the parts fit
> together before designing the architecture. If you claim to be
> developing a standard, you have to not only be impartial, you
> have to be seen to be impartial. This element is at risk.
> Piecemeal development will be seen as nothing but a benefit to
Excluding XHTML from consideration does not sound like impartiality
As for application architecture, if developers are really concerned
about it, they can simply wait for all three specs are done. Remember,
having a single specification won't make it take one third the time,
since in theory the same materials would be included in both situations,
so a developer would end up waiting the same amount of time anyways. If
the developer isn't worried about implementing each of the three
specifications one at a time, I'm not going to worry about it either.
>>You may not wish to directly criticize the policy
>>decisions of WHAT WG, then make editorial suggestions IN THE
>>SAME MESSAGE. Annoying the very people you're asking to make
>>corrections IMMEDIATELY before suggesting them is not wise.
> This list has been told repeatedly that this is an open process.
> Any suggestions I have should be taken on merit (or lack
In an ideal world, sure, but here in the real world, if you get
people angry by going on and on at length about how you think they're
wrong and then turn around and start talking about technical materials
that require one's full attention in the first place, you're not going
to get very far.
> Nobody is forcing you to read. Whether it annoys you
> or not should not be relevant.
One would think that whether WHAT WG participants read your ideas or
not IS relevant. Otherwise, why bother posting? I'm simply trying to
make you aware of the psychology of the situation.
>>Another thing is that this email is a perfect example of why
>>we should NOT submit all three specifications as one. This
>>email could have easily been divided up over several emails
>>by topic, but instead you send one really long email and I
>>got tired of reading half way through.
> If I'd sent 5, 6, 7 separate emails I'd have been accused of
> spamming the list.
I've posted two major suggestions (Web-IE6 and XUL Basic) that are
WAAAAAY out side the WHAT WG charter, and I've never heard complaint one
about spamming. I seriously doubt you would even receive a complaint
about posting seven different emails. For the love of Lassie, there's
probably about a thousand messages in the archives right now, and that's
since the beginning of June.
>> I suppose they should just wait until Longhorn ships
> I fully understand that this is a project to lay down a marker
> before the MS juggernaut fires itself up, but if you hurry this
> through, and it be a "spec for yourselves", you open yourselves
> to the same issues.
With all of the top browser developers except for Microsoft being
represented in WHAT WG, and the fact that any browser developer can
contribute to the specifications if they so choose, the possibility of
these specs only being used by the companies of WHAT WG members doesn't
> Surely getting it done correctly is more
> important than getting it done asap?
Microsoft would disagree with you, and they have the business
success to back it up.
>>>Leaking these specs and UAs as and when they are ready,
>>>in small segments, does nobody any good.
>>How is this "leaking"? If Microsoft submits XAML to the
>>W3C, is their XAML documentation a "leak"? This is an open
>>process. How can it "leak" anything?
> Leak as in drips and drops. Are Microsoft going to present XAML
> piecemeal too?
You're not making any sense. The word "leak" implies secrecy. This
is an open process where anyone can contribute. You certainly can't make
the same for Microsoft. As for piecemeal specs, do you honestly think
that what Microsoft has released so far on XAML will be identical to
what they release with Longhorn? Microsoft moving-target technologies
that haven't even been released yet are no less piecemeal, and they
aren't nearly as open.
More information about the whatwg