W3C home > Mailing lists > Public > public-html-xml@w3.org > October 2011

Re: Friction and cross pollination

From: Henri Sivonen <hsivonen@iki.fi>
Date: Thu, 13 Oct 2011 20:01:24 +0300
Message-ID: <CAJQvAudcjQnRUHWqyAxNmZZBRK+P++pVH1xXYzXJkNtQ13JakA@mail.gmail.com>
To: public-html-xml@w3.org
On Tue, Oct 4, 2011 at 2:34 PM, Robin Berjon <robin@berjon.com> wrote:
> A suggested list of such smaller projects, which may or may not proliferate best in a standards setting, could for instance include:

I'm uncomfortable with naming smaller projects that the TF hasn't
discussed previously when the Report is almost ready to be published.

Still, comments on the points below.

>    • Defining an XSLT and XQuery serialisation for polyglot HTML. Usage: make it trivial to produce it with a regular XML tool chain. [ed. I thought that this had been done, but I can't seem to find it anywhere]

I think it makes sense to have a new HTML5-aware HTML output method
for XSLT, but I think making it polyglot would be an unfortunate
distraction. You can't serialize the text content of HTML script and
style element polyglottally in the general case, but it would be silly
not to support the output of text content of HTML script and style
elements when the text content can be serialized as either HTML or as

>    • Help define an improved, more interoperable, and more usable version of DOM level 3 XPath for use from Javascript inside an HTML document. Usage: a number of queries (e.g. for text nodes, or certain axes) are impossible to achieve with the Selectors API, but using DOM level 3 XPath is unwieldy at best.

How would a new API be more interoperable than the API that multiple
vendors already support? Also, big rathole warning about XPath

>    • CSS Fragment IDs based on XPointer as described in http://simonstl.com/articles/cssFragID.html. Usage: links that target fragments more powerfully, in a manner that browsers understand (http://open.blogs.nytimes.com/2011/01/11/emphasis-update-and-source/ is a good example).

Seems out of scope for this TF.

>    • A Javascript and/or CSS based transformation and templating language that would reuse the best of XSLT (notably its processing model) and apply equally to HTML or JSON. One potential starting point may be http://www.w3.org/TR/NOTE-STTS3. Usage: Javascript templating libraries are proliferating like rabbits but they tend to be limited to simple variable interpolation. Support for more powerful HTML production pipelines would benefit from a more powerful approach.

Seems out of scope for this TF.

>    • [ed. please don't shoot me] Making sure that one can fully render XSL FO using nothing but Javascript and CSS, as done with pdf.js (http://andreasgal.com/2011/06/15/pdf-js/). Usage: FO is nicer to produce than PDF.

Totally out of scope for this TF. This TF is about HTML and XML--not
about XSL-FO and CSS.

>    • Despite its name, EXI is a compression technology that is designed to apply to any tree. Investigating whether it can be applied to HTML or JSON could yield sizeable gains. Usage: performance is increasingly a concern in the HTML family. Enabling faster serving in general, and supporting lighter-weight devices without the need for an intermediate proprietary acceleration proxy would improve the ecosystem.

A vendor-independent system for Opera Turbo-like features using gzip,
EXI-like techniques and SPDY would be an interesting project but seem
to be out of scope for this TF.

>    • Collaborating in the ongoing work on a Web component model to ensure that it applies across the board. Usage: open a door that actually works on distributed extensibility.

Seems out of scope for this TF.

Henri Sivonen
Received on Thursday, 13 October 2011 17:02:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 October 2011 17:02:04 GMT