Fwd: HTML5 and XHTML2 combined (a new approach)

2009/1/22 Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>

> On 22/1/09 18:55, Giovanni Campagna wrote:
>
>>    How does modularization of XHTML help content producers, user agent
>>    developers, or end-users in practice?
>>
>>
>> It helps W3C WG in defining a new languages using previous content
>> (XHTML3 won't need a Structure Module, HTML6 will).
>>
>
> If XHTML3 resists the urge to change how elements and attributes in a
> namespace behave in the way that XHTML2 is changing how elements behave from
> XHTML1 then that might be true, though it's not modularization that
> facilitates that but rather refusing to change the specified behaviour of
> elements and attributes in a given namespace.
>
> However, W3C WGs are not part of the set "content producers, user agent
> developers, or end-users": they are specification creators.
>
>
>  It helps the
>> implementors, because all modules have strict defined dependencies, so
>> changes don't affect other modules.
>>
>
> I'm not an implementor. But the impression I have from talking to
> implementors is that formal distinctions between modules by spec writers
> make little practical difference to how difficult it is to introduce changes
> such as adding hyperlinking capability to every element.

If I want to implement XHTML Lists, I don't need to implement XHTML
Metainformation Attributes. This is modularization.
Btw, hyperlinking can be "easily" achieved in Gecko using currently
available technology (XBL1.0), without adding any feature to the browser.


>
> But what implementors do you think modularization has helped in this way?
>
>     How would modularization of XHTML help achieve the stated goals of
>>    the HTML WG?
>>
>>    I've yet to be persuaded that modularization of XHTML actually works
>>    or that, if it did work, it would make the Web better.
>>
>>
>> The point is: what modularization supposed to do? It is supposed to
>> create an extensibility framework for future enhancements of XHTML.
>>
>
> Hmm.
>
>
> http://www.w3.org/TR/xhtml-modularization/introduction.html#s_intro_xhtml_mods
>
> states two goals:
>
> 1. Enable user agent developers to specify what bits of XHTML they support
> so that content producers can deliver suitable content. It's already failed
> to achieve that goal as far as I can see (witness OMA's XHTML Mobile
> Profile, never mind the tattered variation of real-world implementations
> that don't in the least conform to neat modules). Does anyone accurately
> declare support in terms of modules not features? Does anyone deliver
> content that matches modules not features?
>
> 2. Extend XHTML's "layout and presentation capabilities". This is a rather
> odd goal, given the existence of SVG, SMIL, and most importantly CSS (and it
> seems directly counter to the design aims of XHTML2 which mention removing
> the layout and presentation capabilities of XHTML!). I'm not really clear
> how modularization would help with adding layout and presentational features
> to XHTML anyhow.
>
>     The core idea of modularization, as far as I can gather, was that
>>    user agent developers could declare the modules they support and
>>    that content producers could match their content to that support
>>    profile:
>>
>>    http://www.w3.org/TR/1999/WD-html-in-xml-19990224/#mods
>>
>>
>> Yes. More important, if UA get markup they cannot handle, you're quite
>> sure they'll process only features in supported modules and ignore the
>> rest, without breaking it all.
>>
>
> That's more the result of a process for handling unrecognized features than
> XHTML modularization:
>
>    * insert unknown attributes into the DOM
>    * insert unknown elements into the DOM
>    * apply CSS to unknown elements
>    * render content of unknown elements

No. DOM (and DOM depending models, like CSS rendering model or XPath data
model) is not created after XHTML processing, it is created after Infoset
Generation (that is, pure XML parsing). You don't need to know about XHTML
to successfully build a DOM (but you need to know about HTML and its
extendend interfaces, quirks, etc.)


>
> That works just as well (or badly) for new XML elements that are not part
> of modules, like the "canvas" element from HTML5.
>
>     Whether this sort of fragmentation of the Web is remotely desirable
>>    is open to debate; personally I want access to _the_ Web on my phone
>>    (and my TV and my fridge and my cyborg cat), not lots of little
>>    walled garden webs.
>>
>> The fact is that you cannot, because not all UA can (or feel even
>> useful) support the same things:
>>
>
> I think that's basically true of purely presentational and aesthetic
> aspects and basically false when its comes to communicating information or
> providing user interactions. No fragmentation of the web is required for the
> later; the same information and interactivity can be restyled as required
> with CSS or XBL2.
>
> There are some UAs that are not designed for interactivity at all (e.g. a
> printer), but I'm not persuaded the world is crying out for alternate
> content for such UAs or that their needs couldn't be mostly met the existing
> mechanisms (stylesheets) or by modifying content on their end (with
> automation, transformations, scripts, and stylesheets).
>
> Being able to author content and interactivity usable on multiple devices
> is one of the express goals of XHTML2:
>
> "More device independence: new devices coming online, such as telephones,
> PDAs, tablets, televisions and so on mean that it is imperative to have a
> design that allows you to author once and render in different ways on
> different devices, rather than authoring new versions of the document for
> each type of device."
>
> http://www.w3.org/MarkUp/2009/ED-xhtml2-20090121/introduction.html#aims
>
> It's also a goal for HTML5, of course:
>
> http://www.w3.org/TR/html-design-principles/#media-independence
>
>  that's why some modern technologies
>> defined different conformance levels (profiles).
>>
>
> Why would listing supported features (e.g. elements and attributes) be
> insufficient for such purposes? Seems to work fine in practice:
>
> http://www.opera.com/docs/specs/presto211/
>
> And does grouping features into XHTML modules actually allow defining
> profiles? For example, if I were a developer of the text browser ELinks, how
> would I report that ELinks supports the "color" attribute but not the "face"
> attribute? They're both in the same module ("Legacy").
>
>  What is the use for  XForms on a TV not connected to the telephone?
>>
>
> I'm not really clear how telephone connectivity is relevant?


At least in Italy, when watching Digital TV, you need a telephone connection
to send data back.

>
> TV sets were one of the devices originally envisaged as using XForms:
>
> http://www.w3.org/MarkUp/Forms/2000/Charter.html
>
>  Or images and image maps in Lynx?
>>
>
> Lynx works fine with images. You can view the alternative text with the
> mechanism provided by HTML 4.01, download them, manipulate them, and open
> them in your client of choice. Lynx works fine with clientside image maps
> because HTML 4.01 provides a mechanism for providing text equivalents for
> your navigation. Text alternative interfaces can be provided for many of the
> potential uses of serverside image maps too. (Look at T. V. Raman's work
> with an Emacspeak interface to Google Maps, for example.)
>
Yes, but it doesn't work with image maps (and will never work). Similarly
printers will never work with scripting


>
>
>  Or audio in a purring cyborg cat?
>>
>
> I want to play online audio books from Gutenberg on _my_ cyborg cat. You
> can do what you want with yours. ;)
>
I don't know what is a cyborg cat, I thought it was just a rethoric
invention. (and cats usally don't read books at loud)


>
> Anyhow, I don't think content authors trying to author documents matching
> different groups of XHTML modules is a good approach to catering towards
> differing user agents compared to approaches like:
>
>   * Media types.
>   * Media-independent events (e.g. DOMActivate).
>   * Text alternatives.
>   * Stylesheets.
>   * XBL2 layers on top of essential content and functionality.
>   * Providing APIs to get and post data.
>   * KISS.
>

If I don't use Scripting, why should I care of Dom / Scripting execution
context (window object) / script elements?
If I don't use XBL, why should I care of XBL elements and PIs?

>
>
>  That's a fault of OMA, not modularization idea.
>>
>
> Is it? Are you blaming the user without assessing whether XHTML
> modularization met their needs? What's wrong with specifying what features
> you support, rather than what groups of features?
>
>

>  What features does not a correctly set up SGML application support
>> of "real" html?
>>
>
> Well for one thing, an SGML compliant processor would have to interpret
> "<br />" in HTML 4.01 documents according to HTML 4.01's SGML declaration
> (that is, as equivalent to "<br>&gt;") - sprinkling the web corpus with
> misplaced "greater than" signs. Being incompatible with the Web in that way
> is not viable for software attempting to compete with rival browsers or
> search engines.
>
No: setting up correctly SGML, <br/ becames a NET-enabling start tag, and >
its corresponding end tag. Don't forget that XML can be expressed in SGML,
but without the needing of DTD.


>
>     How does defining the content models of elements in one document and
>>    the implied opening/closing tags of the same elements in another
>>    document allow "modularization and extensibility" in a way that
>>    defining them in same document does not?
>>
>>
>> You define "Another serialization of XHTML" in one specification, then
>> define "SGML serialization of SVG" containing only handling for
>> opening/closing SVG tags. The same for MathML, RDF/XML, OWL, InkML,
>> XSL:FO: any language that CDF WG will find usefult to serialize without
>> XML draconian error handling. You could even think of "Namespaces in
>> SGML".
>>
>
> Hmm. This doesn't really answer my question; how does putting these
> serialization definitions into separate documents allow additional
> "modularization and extensibility"? (I don't have any particular bias
> against the proliferation of technical documents - I just don't see any
> necessary connection between this and allowing modularization or allowing
> extensibility.)
>
Documents after REC cannot be modified other than errata-ed. If you need a
new language, you need a new spec. Better to define a new spec only for that
language, than for all language implemented so far, isn't it?


>
>  XHTML2 is not specifically targeted to documents
>>
>
> Except that the draft states it is, whereas the HTML5 draft expresses
> pitches it at web applications too.
>
>  and even if it was,
>> we could extend it to web applications, and this only beacuse it is
>> modularized.
>>
>
> I disagree with the "only". You could also "extend it" by just adding
> features, just like all the other languages that are extended without
> anything analogous to XHTML modularization. HTML WG is adding features to
> HTML, yet HTML isn't modularized.
>
> --
> Benjamin Hawkes-Lewis
>

Yes, the fact is that they needed HTML5, a completely new and huge
specifications, to add few new features (on the core vocubulary side): video
- audio - canvas - datalist - section - etc.
If HTML4 had been modularized, HTML5 would have used HTML4's table module,
text module (b-i-span-strong..), metainformation module
(html-head-body-meta) etc.

Giovanni