Re: SVG in HTML Review Comments

On Fri, 23 May 2008, Cameron McCormack wrote:
> Jeff Schiller:
> > > b) Is attributeName missing from [2] ?
> Ian Hickson:
> > I didn't include it because it wasn't in:
> > 
> >
> > 
> > Is that list incomplete?
> So it would seem!  From a quick look, the following attributes are
> missing from that appendix:
>   additive
>   attributeName
>   begin
>   id
>   requiredFeatures
>   space
>   string

Added attributeName and requiredFeatures to the list of attributes to map.

> And a number shouldn’t be in there, because they’re actually element
> names:
>   animate
>   feColorMatrix
>   feComposite
>   feGaussianBlur
>   feMorphology
>   feTile

Removed the last five from the mapping list.

> Also note that the presentation attributes that correspond to CSS 
> properties are not listed in that appendix (but in propidx.html).

Yeah, but they're all lowercase so they don't need any special handling. 
Only the camelCase ones are an issue (that's a feature unique to SVG).

On Thu, 22 May 2008, Jeff Schiller wrote:
> It's entirely possible that I'm forgetting something - but SVG 1.1 
> already overlaps with HTML (<a>, <font>, <script>, <title>), so I'm not 
> sure why <textArea> would be any different in that respect.

There are a number of element names that clash in SVG 1.1: <a>, <font>, 
<image>, <script>, <style>, and <title>. (SVG 1.2 adds <textArea> and 
HTML5 adds <audio> and <video>. I won't discuss these here; we should 
first wait to see how things go with SVG 1.1 before running ahead with SVG 
1.2, especially given the problems that 1.2 has.)

<font> isn't allowed in SVG-in-text/html because of the name clash. <font> 
is used too much in HTML to run the risk of pages breaking because of it 
being interpreted as part of SVG if it happens to be preceeded by an <svg> 

<a>, <script>, and <style> do basically the same thing in the two 
languages, so we are tentatively allowing them in SVG-in-text/html. 
Implementation experience will let us know how big a problem they are.

<title> is theoretically only allowed in <head> in HTML, and so stray 
<title> elements wouldn't have much effect, so we're tentatively allowing 
that one as well.

I don't have any data on <image>. I did some studies to examine the other 
elements to determine how common and how problematic they would be in 
practice on existing legacy content, but due to the weird handling of 
<image> in regular HTML, I didn't end up collecting any data for it. At 
the moment I'm taking a risk on it and allowing it in SVG-in-text/html, 
but we'll see. We may be forced to treat it as a bailing-out element.

All of this is academic of course since this has all since been commented 
out while we wait for the SVGWG to come back with their better proposal 
for how to do all this.

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

Received on Saturday, 24 May 2008 10:00:10 UTC