Re: Prevalence of ill-formed XHTML

Hi Philip,

On Sep 1, 2007, at 3:51 PM, Philip Taylor wrote:

>
> Robert Burns wrote:
>> On Sep 1, 2007, at 8:32 AM, Philip Taylor wrote:
>>> http://www.w3.org/TR/xhtml1/guidelines.html doesn't say anything  
>>> about not using CDATA sections.
>> Yes it is true that appendix C does not say do not use CDATA  
>> sections, however, in best-practice circles that is how it is   
>> commonly interpreted. That is authors keep both scripts and  
>> stylesheets external and therefore have no reason to use CDATA  
>> sections.
>>> The checked, disabled, readonly, etc attributes can't be used at  
>>> all in a document that follows Appendix C's advice to work in old  
>>> UAs.
>> I'm not aware of any browsers that do not support unminimized  
>> boolean attributes. How widespread is that issue?
>
> If you don't actually follow Appendix C, and instead use some new  
> rules (like never using CDATA) and ignore some old irrelevant rules  
> (like boolean attributes) so that you're following an unwritten set  
> of guidelines to produce documents with XHTML markup that work as  
> text/html, then documents following that are going to work as text/ 
> html, by definition :-)

The only difference I'm suggesting here from Appendix C is just make  
all scripts and style sheets externally linked. That is the common  
best-practice advice I hear out there for using XHTML 1.0. If  
changing that one thing from Appendix C means we can't find any  
problems, then that suggests to me that there were never the serious  
problems many claim that there were. Perhaps the author of Appendix C  
did not know how inconsistently browsers were handling these CDATA  
sections (though as you know, the other common best-practice for  
those that just can't do externally linked scripts and stylesheets is  
to just comment out the CDATA start and end tags in the syntax of the  
element's contents).

>>> XHTML code like:
>>>   <textarea>
>>>   Text</textarea>
>>> in Firefox results in "Text" on the second line of the text area.  
>>> (Opera and Safari disagree. I think XHTML5 agrees with Firefox).  
>>> When you send that as text/html, the leading newline will be  
>>> ignored, so you will get data loss when submitting the form.
>> If I understand you correctly, this is an issue with XHTML  
>> interoperability and not an issue with serving XHTML as text/html.
>
> It's an issue with writing "valid and well-formed XHTML 1.0 that  
> also adhere[s] to the appendix C guidelines", with just markup and  
> no scripts or styles, then having it break when you send it as text/ 
> html. You need an extra step to convert the XHTML into not-quite- 
> XHTML before it can be sent as text/html safely.

Here I must be misunderstanding what issue you're raising. Do all of  
the browsers handle this consistently as application/xhtml+xml? Do  
all of the browsers handle this consistently as text/html? If both of  
those answers are 'yes', then I guess there is an issue with an extra  
newline that could constitute a significant data loss when moving  
between text/html and application/xhtml+xml. If the answer to either  
of those questions is 'no', then we have an interoperability problem  
that would plague anyone who needs this information using that  
particular media type where the answer is 'no'. However, I'm trying  
this in live DOM viewer and I can't figure out where you're running  
into a problem, so I can't understand what the issue is that you're  
raising.

Take care,
Rob

Received on Saturday, 1 September 2007 22:25:30 UTC