W3C home > Mailing lists > Public > public-html@w3.org > April 2010

Re: Request for Volunteers: Polyglot spec

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 1 Apr 2010 11:29:37 -0700
Message-ID: <t2h63df84f1004011129s2ea585bcp43f62c128e808151@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Cc: HTML WG <public-html@w3.org>, Technical Architecture Group <tag@w3.org>
On Thu, Apr 1, 2010 at 11:17 AM, Sam Ruby <rubys@intertwingly.net> wrote:
> On 04/01/2010 01:44 PM, Jonas Sicking wrote:
>>
>> On Fri, Mar 26, 2010 at 1:52 PM, Sam Ruby<rubys@intertwingly.net>  wrote:
>>>
>>> I took an action item from the TAG yesterday to convey the following
>>> request:
>>>
>>>    The W3C TAG requests there should be in TR space a document
>>>    which specifies how one can create a set of bits which can
>>>    be served EITHER as text/html OR as application/xhtml+xml,
>>>    which will work identically in a browser in both bases.
>>>    (As Sam does on his web site.)
>>>
>>> This request requires a lot of explanation.  To start, it is recognized
>>> up
>>> front that this will be a subset of the set of possible documents that
>>> can
>>> be expressed as HTML5.  This is entirely OK.  For example, if it were to
>>> be
>>> the case that such a subset were to entirely disallow scripts of any
>>> kind,
>>> that would be acceptable as there exists a substantial class of documents
>>> which do not require scripting of any kind.
>>
>> Out of curiosity, what does "work identically" encompass? Do they have
>> to have the same DOM? Or just render the same when the default UA
>> stylesheet is applied? Or just be semantically equivalent?
>>
>> Even if the page itself doesn't contain any scripts, if the page is
>> contained in an iframe then scripts in another page might trip over
>> differences if the two pages produce different DOMs.
>>
>> I believe a document served as text/html and one served as
>> application/xhtml+xml will always have different DOMs since the former
>> will have nodes with upper case nodeNames, whereas the latter will
>> have nodes with a lower case nodeName.
>>
>> If DOMs aren't important, only rendering is, I assume that this
>> document won't qualify:
>>
>> <html xmlns="http://www.w3.org/1999/xhtml">
>>   <head>
>>     <style>  tbody { background: green }</style>
>>     <title>example document</title>
>>   </head>
>>   <body>
>>     Integer values for true/false.
>>     <table>
>>       <tr><td>true</td><td>1</td></tr>
>>       <tr><td>false</td><td>0</td></tr>
>>     </table>
>>   </body>
>> </html>
>>
>> Since if this document is served as text/html the table will have a
>> green background, but if served as application/xhtml+xml it will not.
>
> I'll answer this in reverse order.
>
> I agree that the document you cited won't qualify.  There are two ways to
> address this: treat tables without explicit tbody's as non-conforming, or
> treat style rules that produce different results based on the existence of
> tbody elements to be non-conforming.  As luck would have it, I had an
> opportunity to observe this exact discussion. DanC and PLH preferred it when
> tbody elements were included, TimBL preferred to not include tbody elements
> when they were not necessary.  I didn't express an opinion in that venue,
> but I will say that while I don't currently routinely use tbody elements, I
> do think it would be better approach if this document were to suggest that
> they were required.
>
> I don't believe the correct question is a binary "are DOM's important: yes
> or no".  In general DOMs are important, but there may be specific cases
> where the differences are containable.
>
> Overall I do believe that rendering (including the ability to be styled with
> stylesheets) is a primary consideration.  My biggest problem with Appendix C
> is that is makes it sound easy.  My biggest problem with the WHATWG wiki
> page on this topic is that it makes it sound darn near impossible.
>
> A document that states indicates that while it is possible it is more
> difficult than it would appear to be would be worthwhile.

Thanks, that explains it well.

I don't really see the usefullness of such a draft (but then, I'm less
of an XML fan than the target audience I suspect, which is funny given
how much effort I've spent making firefox support it), but at least I
understand its requirements.

/ Jonas
Received on Thursday, 1 April 2010 18:30:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:07 GMT