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

Hi Maciej.

The following are personal comments; other SVG WG members please pipe up
if you disagree.

Maciej Stachowiak:
> >* 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

OK, I can understand having the parsing the SVG content and actually
implementing the SVG rendering being independent.

I think that there should be wording in the spec that requires for
example that the DOM object created when parsing an <svg> start tag is
an SVGSVGElement object if the implementation supports SVG.  How about
when the implementation doesn’t support SVG, though?  Should it just be
Element?  Should it be SVGSVGElement but throwing when calling its
methods?

> 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.

Yes I agree that such a requirement should be added if it doesn’t
already exist.

The few requirements on processing SVG that are in the document at the
moment, for example the <svg:script> one when parsing, would need to be
bracketed with if (implementation supports SVG) conditions.

> 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.

Personally I am OK with this.  I think not a small number of people were
under the misapprehension that a UA that implements HTML 5 will then
necessarily support SVG and MathML, however.  I think also that some
people believe that having HTML 5 require the UA support SVG would help
convince some vendors to implement SVG if they haven’t yet done so, and
thus would rather HTML 5 did so.

How about the semantics of a document that includes SVG or MathML
though?  If I write

  <p>Today we learnt that <math><msup><mi>a</mi><mn>2</mn></msup>
  <mo>+</mo> <msup><mi>b</mi><mn>2</mn></msup> <mo>=</mo> 
  <msup><mi>c</mi><mn>2</mn></msup></math>.</p>

I don’t want the meaning of that document to change depending on whether
the UA supports MathML or not.

> >* Element and attribute case fixup tables
…
> Filed <http://www.w3.org/Bugs/Public/show_bug.cgi?id=7378> for the
> obvious oversight.

Thanks.

> 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.

Of the suggestions, I like the one about adding a hook for other specs
to add entries to the table the most.  I will make a concrete proposal
for this soon.

> >* Foreign content parsing miscellany
…
> 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.

Do you have a pointer to the statistics/URLs demonstrating this?  I
can’t find it right now, and I agree that if it is common it is
surprising.

> Can you think of a better way to differentiate likely HTML <font>
> elements from likely SVG <font> elements?

I think it’s an OK way to distinguish them, I’m just wondering if it’s
possible to do without this rule altogether.

> >* 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?

Probably.

> 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.

That’d be swell.  I know that Erik Dahlström in particular is interested
in having this defined somewhere.  Perhaps it can go in the SVG
Integration spec that we want to work on.

> >* User interaction with mixed HTML and SVG
…
> 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.

It probably needs to involve DOM Events, too.  Does HTML 5 defer to DOM
Events to determine when/where, for example, mouseover events are
dispatched?

> >* Reference
…
> 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>.

Thanks.  I would incidentally be interested to know what 1.2T features
WebKit and Firefox are targetting.

> 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.

OK.  My only concern would be that it might be harder to open a new
issue (if, for example, the bugzilla bugs are resolve unsatisfactorily
from my perspective) than it is to close it now.

> 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?

I’m happy for the moment regarding those CSS/SVG integration issues not
being HTML issues.  As noted in IRC yesterday, the SVG WG will be
meeting in Mountain View in late September, and I’ll ensure that we
review the HTML spec then and send in any final comments.

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 27 August 2009 02:24:50 UTC