Re: Request for Volunteers: Polyglot spec

On Thu, Apr 1, 2010 at 11:17 AM, Sam Ruby <> wrote:
> On 04/01/2010 01:44 PM, Jonas Sicking wrote:
>> On Fri, Mar 26, 2010 at 1:52 PM, Sam Ruby<>  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="">
>>   <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.

By the way, I assume it's not *just* rendering that matters, but
semantic meaning too. So the following document would not qualify even
though it renders the same:

<html xmlns="">
   <style> tbody { background: green } </style>
   <title>example document</title>
   Nothing here
   <div style="display:none"><![CDATA[> Hello ]]></div>

Granted, I'm not sure if it's possible to create such a document
without having parse errors in either form of serving. But I'd imagine
it is.

/ Jonas

Received on Thursday, 1 April 2010 19:33:53 UTC