- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 6 Mar 2009 08:13:20 +1100
- To: public-svg-wg@w3.org
http://www.w3.org/2009/03/05-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
05 Mar 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0195.html
See also: [3]IRC log
[3] http://www.w3.org/2009/03/05-svg-irc
Attendees
Present
Doug, Erik, Cameron, Anthony, Jonathan
Regrets
Chris
Chair
Erik
Scribe
Cameron
Contents
* [4]Topics
1. [5]Telcon time change
2. [6]SVG in text/html
3. [7]WAI ARIA spec review
* [8]Summary of Action Items
_________________________________________________________
<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_>
[9]http://lists.w3.org/Archives/Member/w3c-svg-wg/2009JanMar/0002.ht
ml
[9] http://lists.w3.org/Archives/Member/w3c-svg-wg/2009JanMar/0002.html
<ed_> [10]http://mcc.id.au/2007/03/telcon/?op=impossible
[10] 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_>
[11]http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html_2009
[11] http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html_2009
<ed_> [12]http://krijnhoetmer.nl/irc-logs/whatwg/20090304#l-310
[12] http://krijnhoetmer.nl/irc-logs/whatwg/20090304#l-310
<ed_> [13]http://krijnhoetmer.nl/irc-logs/whatwg/20090304#l-464
[13] 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
[14]http://livedom.validator.nu/
[14] http://livedom.validator.nu/
ED: if you put a <circle> as a child of the <body>, it gets put in
the HTML namespace
<ed_>
[15]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%3
Ealert(document.getElementById(%22c%22).namespaceURI)%3B%0D%0A%3C%2F
script%3E
[15] 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
[16]http://livedom.validator.nu/?%3C!DOCTYPE%20html%3E%3Cbody%3E%3Cc
ircle%3E%3Cscript%3Edocument.write(document.body.firstChild.namespac
eURI)%3C%2Fscript%3E
[16] 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
[17]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
[18]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
[19]http://www.w3.org/2009/03/05-svg-minutes.html#action02]
[NEW] ACTION: Erik to review WAI specs [recorded in
[20]http://www.w3.org/2009/03/05-svg-minutes.html#action01]
[End of minutes]
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 5 March 2009 21:14:04 UTC