<trackbot> Date: 02 March 2009

Zakim: ??P1 in me

so sad

ah, ta

<heycam> Scribe: Jonathan

<heycam> ScribeNick: jwatt

SVG in text/html

<heycam> http://www.w3.org/mid/20090225231009.GD22306@arc.mcc.id.au

CM: I misread part of the text in HTML5 in that email
... about the xmlns attribute
... I thought you needed to include the xmlns attribute to make it conforming
... but actually you can omit it, or else specify it with the correct value
... only then is in conformisg

<heycam> s/then.*/then is it conforming/

CM: to be consistent with our comments on the xmlns:xlink, we would want it to be a parse error if omitted

JW: yeah, I think that would be better

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html_2009

<ed_> http://www.w3.org/Graphics/SVG/WG/wiki/Talk:SVG_in_text-html_2009

ED: I added a bunch of comments on the wiki talk page
... one on the xlink

<ed_> There are SVG images with xmlns:xlink="&ns_XLink;" commonly produced by Illustrator, do we want to break those? Relates to the point about xmlns:xlink and breaking on bogus values.

DS: but that's not bogus
... if it treats it as a macro, the parser never sees that

ED: but you'd need to define it in the HTML code

DS: okay in this case it is bogus, right

CM: I don't think that newer versions of Illustrator do that

DS: I think that's right, it's an old practice

<ed_> first point on http://www.w3.org/Graphics/SVG/WG/wiki/Talk:SVG_in_text-html_2009

ED: we may not need to ask for unquoted attributes etc. to be non-conforming, since authors could just validate their content as XHTML+SVG to get those warnings

DS: I don't think that solves the problem - what if their is some HTML that doesn't validate as XHTML but that has some SVG in it
... it also implies two different tokenizing models
... I guess I'm wordering since the tokenizer in HTML5 does case-folding, but I guess in XHTML it does not

CM: yes

DS: are we going to see the case where inline SVG doesn't work because of whether the HTML is served as text/html or XHTML?

CM: as long as you use the XML compatible syntax in HTML, I can't think of anything specific that would break like that

DS: if you're serving documents for IE as text/html, but serving to everyone else as XML, then you may not be able to predict that your content will work
... maybe scripts will break due to changes to the HTML parts of the DOM tree?
... I'm not sure this is something we can solve
... we maybe need to just keep talking to the HTML WG about this

ED: so are we going to still ask for the xmlns attributes to be required for conformance?

DS: I think we should

ED: so moving on, should we go with all lowercase attributes in future?

DS: I think we should for two reasons
... it makes writing SVG as XML or text/html easier
... and since CSS and SVG are converging on a number of features, we should be as CSS friendly as we can

ED: yes
... we should add that to our email

CM: for element names that don't clash, case insensitivity of CSS selectors shouldn't be a problem
... I worry about consistency though - e.g. if we introduce a new filter primitive element
... it would be a pain to remember which are lowercase and which are uppercase

DS: I think we should certainly do it for attributes

ED: so the third point

<shepazu> for casing elements, I don't have a strong opinion, but we should definitely avoid name clashes... even though namespaces can solve the technical part, it can still be confusing for authors

<shepazu> I also think that going forward, we should consider allowing geometric attributes to be styled (and animated) by CSS... things like x, y, width, and height

ED: ...
... fifth point: not parsing the contents of SVG <title> as HTML

CM: we are agreed on just having plain text inside

ED: so sixth point: xml declaration encoding detection when the root element is <svg>
... I was asked for numbers on the number of SVG documents that that have characters outside the win-1252 range

CM: so you're saying that people won't have the xml declaration if it's UTF-8

<ed_> <svg><b>foo

<ed_> <svg></svg>foo

ED: seventh point: non-SVG in SVG, when SVG is the root, but with our changes to say that there is no implied <html> and <body> inserted in - the non-SVG would break out back to the HTML, but there would then be no HTML to break to

<heycam> <svg><b>foo</b></svg>

CM: you can still have well formed XML
... but you'd still need somewhere for it to be a child of
... I think we're going to have to take some of these to the mailing list to discuss further
... we should get other things done just now

<heycam> ACTION: Erik to move his seven points to the main text/html proposal wiki page [recorded in http://www.w3.org/2009/03/02-svg-minutes.html#action01]

<trackbot> Created ACTION-2483 - Move his seven points to the main text/html proposal wiki page [on Erik Dahlström - due 2009-03-09].

CSS transforms

<anthony> http://www.w3.org/Graphics/SVG/WG/wiki/CSS-Transforms-Review

<heycam> DS: i'll send that in today

This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/in/is/
FAILED: s/then.*/then is it conforming/
Succeeded: s/fourth point/fifth point/
Succeeded: s/fifth/seventh/
Succeeded: s/CM/Topic/
Found Scribe: Jonathan
Found ScribeNick: jwatt
Default Present: ed_, heycam, jwatt, Shepazu
Present: ed_ heycam jwatt Shepazu
Regrets: Chris
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0186.html
Found Date: 02 Mar 2009
Guessing minutes URL: http://www.w3.org/2009/03/02-svg-minutes.html
People with action items: erik