Re: ISSUE-37 - html-svg-mathml - suggest closing on 2009-08-20

On Aug 19, 2009, at 11:12 PM, Cameron McCormack wrote:

> Hi Maciej.
>
> Maciej Stachowiak:
>> SVG and MathML have in fact been integrated. I don't think there is
>> a proposal for further change on the table - but if there is a
>> requested concrete syntax change, I believe it should go in its own
>> issue. Suggest closing.
>
> Thanks for bringing this one up again.  Discussions on syntax issues
> did seem to peter out a while ago, and while I am not certain, I think
> that most of the issues surrounding casing, conformance, xmlns-ish
> things, etc. of the syntax were acceptable to the SVG WG in the  
> end.  I
> don’t think all issues related to the integration of SVG were resolved
> to the satisfaction of the SVG WG, though.  The following in  
> particular
> were brought up in our telcon yesterday:

Thanks for the feedback.

> * Lack of requirements to process SVG in any particular way
>
>  We agree with DanC’s comment that it’s a strange middle ground to  
> have
>  an implementation parse SVG elements in a text/html document and for
>  them to be placed in the DOM but not processed any further (apart
>  from a couple of selected things, like running <svg:script> elements
>  according to the SVG spec) be a conforming implementation.

I can see how this seems a little weird. I don't think it's completely  
illogica on the face of itl. Here's my thinking on this. HTML5 defines  
several things:

A) A serialization independent vocabulary defined in terms of DOM  
elements and attributes.
B) Scripting interfaces for the resulting DOM.
C) A serialization form that can handle this vocabulary, plus a few  
select others (MathML, SVG), specifically the text/html serialization.

I think it's plausible to include C without necessarily requiring  
implementation of the behavior for all parsed vocabularies. An  
analogous situation is XML - an XML parser has to put the appropriate  
elements into the HTML or SVG namespace

What I think could make sense is a requirement that IF a UA supports  
SVG at all, it MUST also implement SVG behavior for SVG elements  
parsed from text/html. I am not sure if such a requirement exists today.

I think this should be raised as a separate bugzilla bug or issue  
tracker issue. SVG folks, do you think my proposed approach above is  
sound? I think HTML5 requiring full implementation of some version of  
SVG might be a bridge too far, but there should be at least a clear  
conditional requirement to hook the parsing up to whatever  
implementations do exist.

>
> * Element and attribute case fixup tables
>
>  We are still of the opinion that the element and attribute name case
>  fixup tables should be specified somewhere else that is more easily
>  updatable, in order not to be an impediment to the SVG WG minting new
>  names.  Now, while we will have a Good Hard Look at ourselves with
>  respect to name case and conflicts with existing HTML element names,
>  it may be that for consistency with the other parts of the SVG
>  language we decide to introduce new mixed case names.
>
>  The SVG WG intends to produce a small spec detailing issues  
> pertaining
>  to integrating SVG in other contexts, one of which would be HTML.
>  This seems like a good place to put that table.
>
>  An alternative solution would be for the HTML spec to provide a spec
>  hook that allows other specs to define case mappings for use by the
>  text/html parser.
>
>  Note that the element name case fixup table currently omits two
>  entries from SVG Tiny 1.2, which should be added: (the poorly named)
>  textArea and solidColor.

Filed <http://www.w3.org/Bugs/Public/show_bug.cgi?id=7378> for the  
obvious oversight.

I can see how the case mappings being in the HTML5 spec might be a  
problem as SVG progresses. My theory on this: newer versions of SVG  
should just include their own updated version of the table if HTML is  
not updated in time. My expectation is that browsers will want to  
support new SVG features in text/html, and that HTML5 will in fact be  
updated in time, so this may not be necessary but it's always an out.  
I think it would be worth raising an ISSUE if anyone wants to make a  
concrete proposal that would involve changing HTML5.


>
> * Foreign content parsing miscellany
>
>  The following rule in foreign content:
>
>    A start tag whose tag name is "font", if the token has any
>    attributes named "color", "face", or "size"
>
>  while not likely to cause any problem for SVG content at the moment,
>  doesn’t seem worth having on the face of it.  (Note that
>  <font color=""> is conforming in SVG, color="" being the presentation
>  attribute for the ‘color’ property.)

I think the idea here is to avoid breaking legacy text/html which has  
improperly nested SVG followed by HTML including <font> tags. This  
turned out to be surprisingly common. Can you think of a better way to  
differentiate likely HTML <font> elements from likely SVG <font>  
elements? I think just dropping the funny rule about <font> entirely  
is not viable for compatibility reasons, but it may be possible to  
make adjustments.

>
> * SVG in a CSS context
>
>  It needs to be specified what sort of CSS box <svg> creates in
>  text/html.

Isn't this an issue for SVG and/or CSS? HTML layout is almost  
completely defined by CSS, and <svg> should create the same kind of  
box in a CSS-rendered parent, even if that parent is a generic XML  
element. I think the CSS WG and/or SVG WG (or perhaps a joint task  
force) should make a spec for mixed SVG and CSS content rendering. I  
would be willing to personally help such an effort by researching what  
browsers do currently.

>
> * User interaction with mixed HTML and SVG
>
>  It needs to be specified somewhere what how, for example, pointer
>  events get dispatched when there is SVG content overlaying HTML
>  content, or vice versa.

Isn't this also an issue for SVG and/or CSS? Those are the specs that  
deal with hit testing, and again I do not believe there is an HTML- 
specific issue, rather CSS hit testing vs. SVG hit testing. One  
additional difficulty here is that SVG hit testing is pretty well  
defined per spec, but CSS hit testing is not very well defined. I  
think the first step here should be for the CSS WG to produce a spec  
for CSS hit testing.

>
> * Reference
>
>  The spec currently has a normative reference on SVG Tiny 1.2, but
>  includes entries in the case fixup table for SVG 1.1 elements.  In
>  reality, browsers are targetting SVG 1.1 rather than 1.2T.  Shouldn’t
>  there be a normative reference to SVG 1.1 too?  (Note that SVG 1.1
>  Second Edition will be published in the coming months.)

I believe browsers are targeting 1.1 plus some 1.2T extensions. I  
agree about the reference. Filed <http://www.w3.org/Bugs/Public/show_bug.cgi?id=7379 
 >.

>
>
> Whether ISSUE-37 is kept open for these, or if it is closed and  
> separate
> issues for the above raised, I don’t particularly mind.  This isn’t
> necessarily an exhaustive list.  It’s also not clear either whether  
> all
> of the above need to be solved in HTML 5 rather than some other spec.
>
> It has been some months since we (SVG WG) have looked at SVG in
> text/html; we’ve been caught up with other work.  I will make sure  
> that
> we take a detailed look at the current state of the SVG stuff in  
> HTML 5
> soon and report back with any other issues that arise.

My personal preference would be to close ISSUE-37 (since the actual  
integration task is done), and to fie separate bugs or issues for any  
remaining details. I think bugzilla bugs are best what seem like minor  
technicalities, and an ISSUE would be best if there seems to be a  
philosophical disagreement. I filed bugzilla bugs for what seem to be  
the obvious cases. And as I said above, I think some of these issues  
are really CSS/SVG integration issues, not HTML/SVG. Thoughts?

Regards,
Maciej

Received on Thursday, 20 August 2009 06:49:53 UTC