- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Mon, 26 Jan 2009 00:15:40 +0000
- 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 UTC