[whatwg] Re: Is this introducing incompatibilities with future W3C work

[Ian Hickson]

On Thu, 24 Jun 2004, Jim Ley wrote:
>>
>> The WHATWG principles are laid out here:
>>
>>   http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html
>
> So you're now conceding that this is an Opera thing, not 7 guys who
> don't recognise companies?

Eight guys.


> We've still not had any patent etc. info.

Still working on that.


>>   * The core features of an XML vocabulary should require the use of
>>     elements from only one namespace.
>
> You never really explained why this constraint existed

I think Micah Dubinko explained it best, in his position paper to the
W3C's recent Web Apps workshop:

| Namespace proliferation is a problem. Even fairly modest documents now
| require a huge raft of declarations at the top. As the author of an
| O'Reilly book on XForms, I can report that 90% of the technical
| questions from readers involve confusion related to namespaces.
 - http://www.w3.org/2004/04/webapps-cdf-ws/papers/verity.html


> IE does support multiple namespaces (regardless of the legality in
> authoring such docs) so it's not based on an IE6 legacy requirement,
> which is what I understood the main motivation of WF2 was.

IE6 is only a concern because compatibility with IE6 is a concern of Web
authors. The main motivation of WF2 (and all of WHATWG) is authors.


>> The net effect of these two points, both of which underpin all WHATWG
>> work, is that anything added to HTML4 must be added to XHTML1, and that
>> anything added to XHTML1 must not require namespaces to be used.
>
> Rather depressing.

If you say so.


> no-one's yet explained how HTML 4 and XHTML 1 really create a migration
> path, could you explain now perhaps?

XHTML 1.0 appendix C claims to describe such a migration path. But that's
a question for the W3C, WHATWG is merely making extensions apply to both
so that if someone wants to use one instead of the other, they can. Since
as far as UAs go they are mostly equivalent, it's no big deal.


>>> The XMLHttpRequest object is NOT a DOM extension, it's part of the
>>> Application Object Model provided by the UA.
>>
>> You can call it that if it makes you feel better, but it still polutes
>> the same namespace.
>
> No it doesn't, well it may do in Mozilla's implementation, but for IE
> it's just a normal object available to javascript in all its script
> hosts, it's got nothing to do with HTML or other documents.

Fair enough. In that case innerHTML/outerHTML/clientWidth/clientHeight
and so forth. There are plenty of examples of extensions to the DOM that
polute the DOM namespace.


>>> I expected a much better argument from the WHATWG to have been agreed
>>> on, than "we don't care much about internet standards".
>>
>> Don't forget that all this WHATWG work is intended to be submitted to a
>> standards organisation; like PNG was, for instance.
>
> Yes, but you've still not told us the roadmap

* Publish WF2 snapshot this weekend.
* Iterate WF2 until we agree it is as good as we're going to get it
  without real-world experience.
* Create WF2 test suite.
* Create WF2 experimental implementations, to obtain implementation
  feedback.
* Update the spec based on implementation feedback.
* Submit WF2 to standards organisation as basis for HTML extensions.
* Publish WA1 requirements.
* Make new roadmap.


> perhaps if you made all that clearer you might get a little more
> support.

We're getting quite enough feedback as it is! ;-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'