W3C home > Mailing lists > Public > www-html@w3.org > January 2009

Re: Fwd: HTML5 and XHTML2 combined (a new approach)

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Mon, 26 Jan 2009 00:15:40 +0000
Message-ID: <497D00AC.1070400@googlemail.com>
To: Giovanni Campagna <scampa.giovanni@gmail.com>
CC: www-html@w3.org

On 25/1/09 17:17, Giovanni Campagna wrote:
>         It helps the
>         implementors, because all modules have strict defined
>         dependencies, so
>         changes don't affect other modules.

[snip]

> Why? Meta-Attributes changes don't change List features. Obviously, for
> the sake of performance, you could hardcode everything inline, but this
> is an implementation issue.

What we're discussing is helping implementers, isn't it? If so, then 
implementation issues are relevant.

> Href-on-any-element in Gecko could be implemented with code changes or
> with XBL.

How does having an implementation of XBL count as implementing 
href-on-any-element for XHTML 2? Authors being able to fake 
href-on-any-element with XBL isn't the same thing. Therefore, it would 
require code changes.

> (Btw, XBL2 is
> a W3C Candidate Recommendation, so all UA are asked to implement it,
> sooner or later)

UAs aren't required to implement any W3C Recommendations.

> You said that XHTML needs to define how to handle unknown elements.

Hmm, no. What I was saying is that the predictable handling of 
unrecognised elements and attributes in the XHTML namespace has nothing 
to do with whether they are defined in modules or not. (Whether this 
predictable handling derives from an XML spec or an HTML spec or an 
XHTML spec or no spec isn't crucial to this point.)

> I asked a different question: why an author that doesn't rely on script
> (or an implementation that cannot, for various reason, implement
> scripts) should learn a plenty of DOM interfaces and APIs?

DOM is the abstract model that serializations express. So if an 
implementation is parsing a serialization, it's producing a DOM, 
regardless of whether it supports scripting.

What is a UA that does not implement scripting required to implement by 
(unmodularized) HTML5 that you believe such a UA should not be required 
to implement? Note the differing conformance requirements for differing 
types of user agent noted in:

http://www.whatwg.org/specs/web-apps/current-work/#conformance-requirements

As for authors, I don't understand your concern. Authors are free to 
read the parts of documents they are interested in, just as they are 
free to read the documents they are interested in.

> I'm not asking to get SGML back. I'm asking to separate syntax from
> vocabulary, and possibly apply this new syntax to any W3C or externally
> defined language based on XML, providing an appropriate way to switch
> between languages (the old DTD)

The DOM - the abstract document model - into which serialization is 
parsed, separates syntax from vocabulary in HTML5. Consequently, HTML5 
has a text/html serialization, an XML serialization, and could (if one 
wanted to design one) have additional serializations, including a 
non-XML SGML serialization. It just wouldn't be realistic to serve them 
as text/html.

Putting the processing rules for text/html in a separate specification 
from the HTML5 DOM and vocabulary would not really make it technically 
easier to reuse text/html processing for new vocabularies.

>     How do ten new RECs allow "modularization and extensibility" than
>     one new REC?
>
> Because not all ten RECs must be released at the same time. Actually,
> the most important part is CR: implementation should wait till CR to add
> new features, otherwise they risk to have them changed at any time (or
> they block changes because they already have implemented). This means
> that if a feature is dubious or has lots of discussion in course cannot
> block other features.

So make smaller releases containing new features that are sensible, 
settled, and implemented, rather than giant new releases with lots of 
features. No need for separate specifications to unblock new features.

> Well maybe Image module or Table module needed a new version, but I'm
> sure that there are features just copied from HTML4 / XHTML1 / DOM2HTML etc.

Leaving aside the algorithms for how to parse text/html streams into a 
DOM, do you have any example of a module in XHTML1.x that is totally 
unaltered - other than not being modularized - in HTML5?

Do you have any example of a module in XHTML1.x that is unaltered in XHTML2?

If most of the modules have been altered in both cases, was 
modularization worth it?

--
Benjamin Hawkes-Lewis
Received on Monday, 26 January 2009 00:16:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:15 GMT