W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2006

[whatwg] several messages about XML syntax and HTML5

From: Alexey Feldgendler <alexey@feldgendler.ru>
Date: Sat, 09 Dec 2006 20:55:56 +0600
Message-ID: <op.tkarriya1h6og4@localhost>
On Thu, 07 Dec 2006 11:44:05 +0600, Ian Hickson <ian at hixie.ch> wrote:

> Here's an example. If this:
>
>    ...text...
>    <new-feature><erroneous content></new-feature>
>    ...text...
>
> ...displays like this:
>
>    ...text... ...text...
>
> ...in existing browsers, but like this:
>
>    ...text... ERROR ...text...
>
> ...in new browsers, then it looks worse in new browsers than old ones.
> Thus, new browsers will want to go back to the way that old browsers
> handled it, so that they don't handle it worse than the (old)  
> competition.

I disagree with you here.

The above is only true if <new-feature> is actually an existing element  
which has been given new meaning, i.e. there are legacy documents on the  
web containing <new-feature> but using it in some other (old) meaning, or  
without a meaning at all (example: xmlns attribute in text/html). That  
way, browsers introducing new feature will have to back out because they  
would break existing documents. There was an example of this when Gecko  
tried to interpret xmlns in text/html.

However, if the <new-feature> is completely new, such as the proposed  
<xmldata>, then the only documents containing <new-feature> would be those  
that target the new browsers which support it. These documents would use  
<new-feature> in the proper sense, and they would only contain errors due  
to reak mistakes made by human authors, not because of introduced  
incompatibilities. For these documents, ...text... ERROR ...text... is  
actually a better rendering than ...text... ...text... because it helps to  
locate and fix the error.


-- 
Alexey Feldgendler <alexey at feldgendler.ru>
[ICQ: 115226275] http://feldgendler.livejournal.com
Received on Saturday, 9 December 2006 06:55:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:31 UTC