RE: Request for Volunteers: Polyglot spec

I had suggest something like "equally well".

I think "cannot tell the difference" is too high a bar, because
a document which behaves slightly differently when served as
text/html and as application/xhtml+xml but not in any important
ways would still be a useful "polyglot" document.

While it might be a little harder to define, it's clear that
the implications of "cannot tell the difference" and "identical" 
are hard too.

-----Original Message-----
From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf
Of Sebastien Lambla
Sent: Saturday, April 03, 2010 5:44 PM
To: Sam Ruby; Philip Taylor
Cc: Jonas Sicking; HTML WG; Technical Architecture Group
Subject: RE: Request for Volunteers: Polyglot spec

May I request clarification for something that troubles me.

By "work identically" is the meaning "one cannot tell the difference
between a page served as Xhtml and one served as Html" or "one does
not care about such difference".

I have plenty of users of iphone browsers on my blog, and none of them
have complained about the fact that my layout breaks their browsers
horribly, I'm not sure how much of this is to be taken into account?



 
-----Original Message-----
From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf
Of Sam Ruby
Sent: 02 April 2010 00:33
To: Philip Taylor
Cc: Jonas Sicking; HTML WG; Technical Architecture Group
Subject: Re: Request for Volunteers: Polyglot spec

On 04/01/2010 02:41 PM, Philip Taylor wrote:
> 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?
>> [...]
>> 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>
>
> This one would also render differently:
>
> <html xmlns="http://www.w3.org/1999/xhtml">
> <head><title>example document</title></head>
> <body>
> <pre>
> Arbitrary example text</pre>
> </body>
> </html>
>
> and this one will also cause data corruption depending on the
content-type:
>
> <html xmlns="http://www.w3.org/1999/xhtml">
> <head><title>example document</title></head>
> <body>
> <form>
> Edit your comment:
> <textarea name="comment">
> Your previous text</textarea>
> </form>
> </body>
> </html>
>
> (because the text/html parser strips a leading newline character in
> pre/textarea/listing elements), which seem like more serious issues
than
> the <tbody>, since (unless I'm missing something) it's impossible to
> safely use these elements in polyglot documents, unless you do
>
> <pre><!---->
> text
> </pre>
>
> which is a horrid hack and won't work for textarea anyway. So I
think a
> true polyglot subset would have to exclude the textarea element,
which
> limits its usefulness further. (Maybe the remaining subset is still
> large enough to be worth specifying in detail.)

I have a textarea on my individual blog entry pages.  I serve those 
pages as text/html to IE (including the current Platform Preview), and

as application/xhtml+xml to pretty much everyone else.

To date, I have not had a single complaint on this issue you describe.

And have had comments left by plenty of people using a diverse variety

of browsers.

It is my hope that the document produced can avoid superlatives like 
"serious", "impossible" and "horrid" when discussing this limitation.

- Sam Ruby

Received on Sunday, 4 April 2010 23:00:43 UTC