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

Re: New HTML/XML Task Force Report published

From: Robin Berjon <robin@berjon.com>
Date: Thu, 30 Jun 2011 12:59:02 +0200
Cc: public-html-xml@w3.org
Message-Id: <2C571BE6-CB4A-4079-A3EA-51FF1158D161@berjon.com>
To: Norman Walsh <ndw@nwalsh.com>
Hi,

On Jun 28, 2011, at 17:28 , Norman Walsh wrote:
>>   "As the HTML5 ecosystem grows, it's easy to imagine a day when
>> HTML5 toolchains are widespread and popular." I think we're there
>> already :) I'd just go with "HTML tool chains are widespread and
>> popular."
> 
> Ok. What tools besides browsers and Henri's validator exist that
> accept HTML5 as input?

I've been playing with PhantomJS (http://www.phantomjs.org/) a fair bit recently, it's very useful. Granted, it's essentially a headless browser. There's a growing number of parsing libraries out there, and it's quite useful to be able to manipulate the same thing server-side that you're using client-side. There's also EnvJS (http://www.envjs.com/). Finally, don't forget that a large part of the "HTML5 toolchain" is the same as the (very large) HTML toolchain that's been around for ages, including the indefatigable string concatenation.

>> Do we have a plan for reaching some kind of collective conclusion?
> 
> We have a goal to do that, but not yet a plan :-/

Personally I think that we don't have that much of a problem to solve. HTML and XML are both alive, well, and useful. Both communities should probably talk more to one another and spend less time assuming the "other side" is doing something stupid, but I don't know how much of the requisite social engineering we can do here.

Beyond that, I think that there are two areas in which we can make recommendations, and perhaps investigate solutions:

     Points of friction easily removed, e.g. producing HTML5 from XSLT (including 1.0). This list is likely quite short, the use cases rather obvious, and the solutions quite simple.

     Good ideas that exist in one environment but not in the other so that we may get cross-pollination, e.g. http://simonstl.com/articles/cssFragID.html (yes I'm counting CSS and much of the browser stack as part of "HTML5", and I don't much care if people mind :). This list can get wilder (a Javascript/CSS/whatever-based variant of XSLT  remember http://www.w3.org/TR/NOTE-STTS3?  binary HTML5, Selector axes that could be used with the Selector API but not in CSS (for performance reasons)) and I doubt that this group can provide solutions directly but we can at least get the discussion going. My reason for including this discussion here is because a lot of people complain that HTML5 is too browser oriented and doesn't address their non-browser needs, but that is something that can only be addressed through direct contribution to the production technology that would take care of those other needs. It seems to me that that's a message which this group could perhaps help spread.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Thursday, 30 June 2011 11:06:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 30 June 2011 11:06:51 GMT