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

Re: Friction and cross pollination

From: Robin Berjon <robin@berjon.com>
Date: Fri, 14 Oct 2011 11:03:27 +0200
Cc: public-html-xml@w3.org
Message-Id: <58E5106E-0E6F-4DB9-B2F7-D99963B3B38B@berjon.com>
To: Henri Sivonen <hsivonen@iki.fi>
On Oct 13, 2011, at 19:01 , Henri Sivonen wrote:
> 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.

They are really just meant to be suggestions, definitely not endorsements.

>>     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
> X(HT)ML.

Sure, I certainly don't think that it's worth trying too hard. But HTML output can be improved, and polyglot is likely a good source of inspiration.

>>     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
> versions.

See the discussion on WebApps about how consecutive text nodes are returned.

>>     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.

[several times]

All of these ideas are completely out of scope for this TF: we do not have the remit to produce a Rec-track document anyway. All of these paths are work for other groups, new (community) groups, or even just open source projects.

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Friday, 14 October 2011 09:03:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:28 UTC