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

Re: ISSUE-41/ACTION-97 decentralized-extensibility

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 05 Oct 2009 06:56:54 -0700
Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Shelley Powers <shelleyp@burningbird.net>, "public-html@w3.org WG" <public-html@w3.org>, Adrian Bateman <adrianba@microsoft.com>, Sam Ruby <rubys@intertwingly.net>
Message-id: <DFABEEFC-C5EA-4229-91A9-F3D189328C38@apple.com>
To: Henri Sivonen <hsivonen@iki.fi>

On Oct 5, 2009, at 6:09 AM, Henri Sivonen wrote:

> On Oct 5, 2009, at 15:53, Leif Halvard Silli wrote:
>> Henri Sivonen On 09-10-05 14.09:
>>> On Oct 3, 2009, at 02:45, Shelley Powers wrote:
>>>> I can speak for an SVG editor, Inkscape, which uses namespaced   
>>>> elements and attributes to record information about the SVG it   
>>>> produces. And before you mention using HTML comments, you should   
>>>> spend time with an Inkscape SVG file, to see how extensive the  
>>>> use  of namespaced elements and attributes are in an Inkscape  
>>>> managed SVG  file.
>>> Inkscape is indeed a good example.
>>> It isn't clear to me why Inkscape couldn't serialize its state  
>>> using a  proprietary key-value syntax inside comment nodes instead  
>>> of using  attributes as the key-value syntax.
>> Another version of IE Conditional Comments, you mean? Can even be  
>> used to hack a "namespace" solution ... HTML as we are forced to  
>> speak it ... Doesn't sound lovely.
> Not at all. I'm not suggesting that comments change tree building in  
> any way. I'm suggesting that authoring tools could locate their own  
> comments in the parsed tree and parse the contents of the comments.
> (This would of course be highly inappropriate for any other kind of  
> application except authoring tools storing data strictly for  
> themselves. For example, I think putting RDF/XML in comments for  
> Trackback is a bad design pattern.)

Comments have the downside that they may no be properly round tripped  
by generic markup processing tools, where other markup constructs  
(elements, attributes) would be. I'm not sure if this is an absolute  
requirement for authoring tool design-time data, but it seem plausible  
that it is.

Received on Monday, 5 October 2009 13:57:29 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:52 UTC