Re: What namespace features popular SVG tools really emit (ISSUE-37)

On Sep 3, 2008, at 19:45, Dailey, David P. wrote:

> Hi Henri, I hate to quote out of context (and particularly where I  
> confess not to really understand the context), but something about ...
>
> "Yes. Firefox, Safari and Chrome fail to render "SVG" content that is
> not in the SVG namespace after parsing without external DTD
> processing, so developers of other SVG-enabled browsers seem to accept
> this level of incompatibility with legacy content in the case of SVG."
>
> .... worries me.
>
> a) Opera right now has by far (according to Jeff Schiller's tests  
> against the test suite) the most extensive SVG support. Lot's of  
> stuff just doesn't work in the other browsers because they don't yet  
> support the spec.

This isn't an issue in the code that implements SVG. It's on the XML  
parsing layer, and the problem is well known and understood by  
implementors, so this is not an accidental bug.

The root cause of this problem is that the definers of XML weren't  
able to settle their arguments but threw their can of worms over the  
fence onto implementors and authors by leaving DTD processing in XML  
as an optional feature. (Optional spec features are much worse  
preference pane entries in software, but both tend to be  
manifestations of unsettled arguments.)

The problem is that the optional feature is not feasible to implement  
but authors ask for it, so browsers have faked parts of it. When Gecko  
added faked support for character entities in certain situations, the  
result was not nice for WebKit and Opera. Now that Opera fakes support  
for a #FIXED attribute declaration in a certain situation, the result  
is not nice for WebKit and Gecko.

In my personal opinion, we should standardize the exact DTD faking in  
XML processing in browsers and then agree to freeze that area of the  
open Web platform. Frankly, the Math and XHTML2 WGs are now making  
things worse by minting new public IDs for DTDs that define entities.  
I'm glad that the HTML and SVG WGs aren't minting new public IDs.

> b) You've forgotten to mention IE/ASV, which (though not completely  
> standards compliant -- probably since it was built before the spec  
> was finished) does render a very sizable chunk of SVG1.1.

I didn't mention it, because I thought ASV (together with the behavior  
or the W3C Validator) was known to be the enabler of this type of SVG  
authoring error in the first place.

> I guess it sounds a bit like "don't break the web unless it's only  
> SVG" though I'm sure that is not the intent.

The intent is to say that it doesn't make sense to be inconsistent  
about the level of SVG breaking.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 4 September 2008 08:53:25 UTC