[whatwg] several messages about XML syntax and HTML5

[Alexey Feldgendler]

On Tue, 12 Dec 2006 02:53:50 +0600, Ian Hickson <ian at hixie.ch> wrote:

>> They will, and old browsers will show either fallback content, if
>> provided, or nothing at all in place of the <new-feature>. I don't see
>> how is this rendering "better" than showing an error message for
>> malformed <new-feature> content.

> Based on my experience, nothing at all is better than an error message in
> so far as what users think. Nothing at all, they ignore. An error message,
> they say "why is the browser broken? My old browser wasn't broken. I'm
> going back to my old browser".

Case 1. The embedding is invalid.

Old browser: "Here is the sketch I drew yesterday:" (and no sketch).
New browser: "Here is the sketch I drew yesterday: <ERROR>".

In this case, the page is equally broken in both browsers. The new browser is even more informative because it at least explains that there should have been an image, and probably the reasons why it can't be displayed.

Case 2. The embedding is valid.

Old browser: "Here is the sketch I drew yesterday:" (and no sketch).
New browser: "Here is the sketch I drew yesterday: <ACTUAL SKETCH>".

In this case, the rendering of the new browser is undoubtedly better.

To summarize: in either case, the rendering of the new browser is *not worse* than that of the old browser.

>> You won't be able to manipulate the SVG DOM in this case.

> Your use case didn't mention manipulating the DOM. Moving targets are hard
> to hit -- that's why we try to list the use cases before designing the
> solution.

The use case wasn't mine. :-)

>> These are actually two independent aspects:
>>  1. Native support vs. plugins.
>> 2. External resources vs. inline data.
>>  Native support + external resources --> e.g. JPEG <img href="http://...">
>> Plugins + external resources --> e.g. Flash
>> Native support + inline data --> e.g. JPEG <img href="data:...">
>> Plugins + inline data --> no examples yet, but why not?

> "Why not" is not a design process, sorry.

The "why not" is for implementations, not for the spec. Using native support or a plugin is completely up to the implementation. There can even be a third way: for example, add-on support for embedded MathML is avaliable as a UserJS for Opera -- this works somewhat like a plugin but is written in JS.


-- 
Alexey Feldgendler <alexey at feldgendler.ru>
[ICQ: 115226275] http://feldgendler.livejournal.com