Re: [XHTML 2] 24.2 Position of param elements (PR#7753)

On Wed, 25 Jan 2006 13:12:37 +0100, Shane McCarron <shane@aptest.com>  
wrote:
>>> I need to apologize.  I did not mean that I was looking for text for   
>>> this one small section of the document. I could think of many  
>>> perverse  situations for every element (what should a browser do when  
>>> it finds a  div inside of a span?  a div inside of a p?).
>>
>> Given that creating a DOM for XML is more or less well defined that is  
>> not  really a problem. At least, not from a visual point of view.
>
> No.  The problem, just like PCDATA before a param element in an object  
> element, is that it is invalid and therefore nonsense.  I know the XML  
> processor could build a DOM tree.  You can build a DOM tree for anything  
> that is well formed. But it remains invalid, and therefore wrong.

I was just pointing out that XHTML doesn't suffer from some of the  
problems HTML has problems with.


>>> The point I was trying and failing to make earlier is that it is   
>>> impractical to attempt to address all of these.  Actually, I maintain  
>>> it  is by definition impossible.
>>
>> In my opinion it is possible. It is quite possible to define clear   
>> processing rules that are both easy to implement and easy to write.  
>> For  example, you could define that attributes that do not match the  
>> production  that is defined for the attribute value MUST be ignored. So  
>> that, UAs can  not by any means interpretid <div role="bogus"> as <div  
>> role="navigation">.
>
> The recommendation has rules for this already.  See the conformance  
> section.  Here is an excerpt:
>
>     If a user agent encounters an attribute it does not recognize, it
>     must ignore the entire attribute specification (i.e., the attribute
>     and its value).
>
>     If a user agent encounters an attribute value it doesn't recognize,
>     it must use the default attribute value.

What if there is no default attribute value? This sounds good though. It  
just need to be made more complete.


>> It is already shown by for example CSS 2.1 that this is not impossible  
>> to  do. SVG Tiny 1.2 will eventually (and does already for a bit) show  
>> the  same. I'm not sure why you think it is impossible given that it is  
>> already  being done and appreciated a lot by implementors.
>>
>> No clear error handling is exactly what brought the web at the point it  
>> is  today.
>
> Fascinating.  And here I always thought it was lack of conformance to  
> standards.

Well, at some point browsers implemented error recovery because it was not  
specified what should be done upon encountering errors. This led to people  
rely on these errors as people don't build against specifications, but  
against implementations. This led implementors to have to reverse engineer  
the market leader for said error recovery.

This happened with HTML. This happened with CSS.  This happened with SVG.  
The CSS WG is working on fixing the CSS problem. The SVG WG is working on  
fixing the SVG problem. A couple of browser vendors are working on fixing  
the HTML problem. The HTML WG introduces a new problem, bluntly said.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Wednesday, 25 January 2006 12:23:18 UTC