W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

Minutes, Mar 5, 2009 telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 6 Mar 2009 08:13:20 +1100
To: public-svg-wg@w3.org
Message-ID: <20090305211319.GA29917@arc.mcc.id.au>


      [1] http://www.w3.org/

                               - DRAFT -

                   SVG Working Group Teleconference

05 Mar 2009


      [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


          Doug, Erik, Cameron, Anthony, Jonathan





     * [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?


      [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


     [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/

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


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

   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

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

   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

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

   <scribe> ACTION: Doug to review WAI specs [recorded in

   <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
   [NEW] ACTION: Erik to review WAI specs [recorded in

   [End of minutes]

Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 5 March 2009 21:14:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:41 UTC