W3C

- DRAFT -

SVG Working Group Teleconference

05 Mar 2009

Agenda

See also: IRC log

Attendees

Present
Doug, Erik, Cameron, Anthony, Jonathan
Regrets
Chris
Chair
Erik
Scribe
Cameron

Contents


 

 

<trackbot> Date: 05 March 2009

<jwatt> gah

<jwatt> skype credit takes 15 minutes to go through

<jwatt> Zakim: I'm me

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

Telcon time change

ED: has everyone updated their entries?

<ed_> http://lists.w3.org/Archives/Member/w3c-svg-wg/2009JanMar/0002.html

<ed_> http://mcc.id.au/2007/03/telcon/?op=impossible

[much discussion, we'll take it to the list]

SVG in text/html

ED: have the HTML WG had their telcon this week?

CM: no it's been cancelled this week

ED: there are a bunch of comments on the wiki page

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

<ed_> http://krijnhoetmer.nl/irc-logs/whatwg/20090304#l-310

<ed_> http://krijnhoetmer.nl/irc-logs/whatwg/20090304#l-464

ED: we could go over each of the XXX comments in the wiki page
... the first one, should we say that this is "some feedback" on their proposal?

JW: personally, i'm not entirely comfortable with the whole SVG in text/html thing yet
... but i'm willing to go along with the proposal, and look at how it would work, and work on problems we find with it
... next, about parse errors
... someone was saying in some email that "parse error" means that the user agent can just abort parsing
... wondering if we should use the term "non-conforming"

ED: parse error is the term used for "abort or follow the steps in the spec"
... it's mostly meant for validators, i guess

CM: i think it is that browser would continue, but other tools could abort if they wanted

JW: do we know what happens when we get non-<svg> SVG open tags outside foreign content?

DS: i think they'll be placed in the svg namespace but with a lowercased name

http://livedom.validator.nu/

ED: if you put a <circle> as a child of the <body>, it gets put in the HTML namespace

<ed_> http://livedom.validator.nu/?%3C!DOCTYPE%20html%3E%0D%0A%3Chtml%3E%0D%0A%3Cbody%3E%0D%0A%3Ccircle%20id%3D%22c%22%3E%0D%0A%3Cscript%3Ealert(document.getElementById(%22c%22).namespaceURI)%3B%0D%0A%3C%2Fscript%3E

http://livedom.validator.nu/?%3C!DOCTYPE%20html%3E%3Cbody%3E%3Ccircle%3E%3Cscript%3Edocument.write(document.body.firstChild.namespaceURI)%3C%2Fscript%3E

ED: i think it would be similar if you find HTML elements inside SVG, unless it was one of those that break out of foreign content mode
... i.e., it would be put in the SVG namespace

JW: but it's nearly all HTML elements will break out?

DS: the list of elements that break out are the ones with no overlap
... the spec lists which elements break out

ED: is this something we need as an open point?
... i'll remove that and the "some feedback" point
... there's an XXX point about the camel case attributes

JW: we were talking about making, in future, all attribute names lowercase
... but looking at the attributes, there are lots that have mixed case currently
... if html5 and css are going to have to deal with those anyway, we just lose internal consistency with out spec
... if html5 and css have to deal with our mixed case attributes, i'm wondering what the value is

DS: many people mistype viewBox as viewbox
... we could say that either case is allowed for existing attributes

AG: and then slowly deprecate mixed case?

JW: we'll be stuck with mixed case

DS: i don't have a strong opinion either way
... we have stroke-width, that's not camel cased
... what do we lose by not camel casing attributes?

ED: those we have without camel casing is because of feedback from csswg (properties have to be consistent)
... don't see why attributes couldn't be consistent in the same fashion

JW: i think camel casing makes it easier to remember to type, if things are consistent

DS: so that would argue for making them all lowercase

AG: unless you wanted to distinguish between svg attributes and properties

ED: that makes it harder for us to use css for some of those

DS: the only thing i can think of is that by using camel casing we're avoiding name clashes with css/html

CM: i agree that making future attributes lowercase and leaving the current ones mixed case would be confusing

JW: i'm not sure we're all going to agree on this at the moment

ED: the point that we decided on doesn't exactly say what we're going to do, just that it would be preferable, for integration with css/html, if everything were lowercase
... and we can come back later to decide about mixed case attributes in svg

JW: ok i'll take the XXX point out and reword the paragraph before it
... one of the other XXXs i added was about entities

CM: think that is in there just because i pointed out that html entities would work in my summary email

JW: if we're going to say that we recognise that entities won't work, why aren't we saying that we also recognising that svg with elements with the wrong case won't work when copied out, etc.

DS: you could say that we'd like to strive for consistency in how entities are treated
... e.g. svg authoring tools sometimes generate entities, and html defines its own entities
... we could strive for common processing of them

JW: for us, that would mean accepting html entities. what would it mean for html?

DS: maybe html could define a way that it could parse and allow entities from a DOCTYPE inserted into the middle of a document. i think it's ugly, but...
... but it would make it easier for people importing content from an svg authoring tool
... there should be some consistent balance so that authors know what to expect when using entities

JW: agreed [on the balance]
... so doug'll remove that XXX and add some text?

ED: one last one, does parse error imply non-conforming?

JW: i was just saying the second sentence was redundant, so can be removed

ED: i'll do that
... so that's all XXX points

CM: then there are the points on the mailing list

WAI ARIA spec review

ED: it's going to last call, they're asking for comments before march 24

DS: i think it's april 15 now
... but we should review it and get back to them

ED: yes, i'll take an action to review it

DS: yes

<scribe> ACTION: Erik to review WAI specs [recorded in http://www.w3.org/2009/03/05-svg-minutes.html#action01]

<trackbot> Created ACTION-2484 - Review WAI specs [on Erik Dahlström - due 2009-03-12].

<scribe> ACTION: Doug to review WAI specs [recorded in http://www.w3.org/2009/03/05-svg-minutes.html#action02]

<trackbot> Created ACTION-2485 - Review WAI specs [on Doug Schepers - due 2009-03-12].

Summary of Action Items

[NEW] ACTION: Doug to review WAI specs [recorded in http://www.w3.org/2009/03/05-svg-minutes.html#action02]
[NEW] ACTION: Erik to review WAI specs [recorded in http://www.w3.org/2009/03/05-svg-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/03/05 21:12:08 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Found Scribe: Cameron
Found ScribeNick: heycam
Default Present: Shepazu, ed_, heycam, anthony
Present: Doug Erik Cameron Anthony Jonathan
Regrets: Chris
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0195.html
Found Date: 05 Mar 2009
Guessing minutes URL: http://www.w3.org/2009/03/05-svg-minutes.html
People with action items: doug erik

[End of scribe.perl diagnostic output]