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

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:

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

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

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

* SVG in a CSS context

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

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

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


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.

Thanks,

Cameron
http://www.w3.org/Graphics/SVG/WG/track/actions/2652

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

Received on Thursday, 20 August 2009 06:12:59 UTC