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.fihttp://hsivonen.iki.fi/