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

On Thu, 20 Aug 2009, Cameron McCormack wrote:
> 
> * 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've changed the spec so that the <svg:script> requirement only applies to 
SVG UAs.

In general, my intention was to leave the MathML and SVG requirements up 
to the MathML and SVG specs, so that conformance to MathML or SVG did not 
imply or require that the UA implement HTML, and vice versa.


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

I would be concerned with parser implementors having to look at two 
separate specifications to implement HTML parsing rather than just having 
the one place to go. However, we can always change this later.


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

It seems that both of these options would make it too easy to update the 
list.


>   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.
> [...]
> * 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 agree that most HTML UA implementors who have indicated an interest in 
implementing SVG in text/html have only indicated a desire to support the 
SVG 1.1 feature set at this time. (<textArea> in particular seems very 
controversial -- it was published over formal objections.) The references 
to SVG Tiny 1.2 are needed because 1.1 leaves many things undefined which 
were only defined in 1.2; if it wasn't for that, I'd have only referenced 
1.1. Since there's no requirement that the HTML UA implement SVG, there's 
no need for a reference to the actual SVG Full feature set anywhere.


> * 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 agree that the attribute checks don't seem worth it, but the alternative 
(not having SVG <font> in text/html at all) wasn't popular either.


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

Why would this differ from SVG in XML?


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

Why would this differ from SVG in XML?


On Wed, 19 Aug 2009, Maciej Stachowiak wrote:
> 
> 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.

That requirement is, I would hope, in the SVG spec -- it should be the 
same requirement that says that if you have a script-created DOM and start 
poking SVG elements into it, they have SVG semantics.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'