[whatwg] some issues

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 
Section A.4:

"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 
deception here.

 > 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 
with sXBL/XBL2.

 > - 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 
significantly reduced.

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
 > committing.

    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"?

 > The
 > 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
 > yourselves.

    Excluding XHTML from consideration does not sound like impartiality 
to me.

    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
 > thereof).

    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
 >>then...
 >
 > 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 
frighten me.

 > 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.

Received on Monday, 5 July 2004 12:19:28 UTC