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

Minutes, 9 March 2009 telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 10 Mar 2009 16:24:35 +1100
To: public-svg-wg@w3.org
Message-ID: <20090310052435.GA7286@arc.mcc.id.au>


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

                               - DRAFT -


10 Mar 2009


      [2] http://www.w3.org/mid/20090309003206.GA3558@arc.mcc.id.au


          DS, ED, CM, JW



          erik, Cameron


     * [3]Topics
         1. [4]telcon times
         2. [5]SVG in text/html
         3. [6]Clamping of rx/ry values on <rect>
         4. [7]SVG 1.1 Basic DTD issue
         5. [8]Duplicate IDs of some test slides in 1.2T
         6. [9]Update on various other SVG 1.1 errata actions
         7. [10]More validator stuff
     * [11]Summary of Action Items

   <shepazu> trackbot, this will be SVG

   <trackbot> Sorry, shepazu, I don't understand 'trackbot, this will
   be SVG'. Please refer to [12]http://www.w3.org/2005/06/tracker/irc
   for help

     [12] http://www.w3.org/2005/06/tracker/irc

   <ed__> scribe: erik

   <ed__> scribeNick: ed__

telcon times


     [13] http://www.w3.org/mid/op.uqdgb7kvgqiacl@gnorps.linkoping.osa

   CM: some suggestions in this mail
   ... three slots mentioned there

   DS: what about an hour later (from the current time)?

   JW: can't, meeting conflict

   DS: I would rather stay up til 3am than get up 7am
   ... how would that work for you, JW?

   ED: 5.30utc doesn't work that well
   ... for me
   ... an hour later would be fine with me though

   DS: we could try that for a while
   ... JW would that work for you? 8.30 european, 6.30utc
   ... monday and wednesday

   <shepazu> Monday, Wednesday, 0630UTC

   CM: that's 4.30pm for eastern AU


     [14] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=3&day=11&hour=6&min=30&sec=0&p1=239&p2=240&p3=188&iv=1800

   JW: so can we agree on those times?

   <heycam> somebody after the call can work out what it means for this
   intervening 3 weeks

   DS: can we keep it at this current time for a week or two more?

   <heycam> the europeans will change in 1 week or 2

   <heycam> Scribe: Cameron

   <heycam> ScribeNick: heycam

   ED: so we're deciding to keep this time until europe changes to DST
   ... we will try to decide a new time at the end of march, or do we
   want to decide on the times we have now?

   DS: we'll leave it until then

   ED: take it to the mailing list

SVG in text/html


     [15] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0209.html

   DS: any feedback from mozilla?

   <jwatt> Attributes

   <jwatt> This section does not treat ":" as a special character. As a
   result, it seems to me that the way to get or set the value of e.g.
   the 'xmlns:href' attribute is going to be different in XML SVG vs.

   <jwatt> XML SVG : getAttributeNS('[16]http://www.w3.org/1999/xlink',

     [16] http://www.w3.org/1999/xlink'

   <jwatt> HTML SVG : getAttributeNS('null', 'xlink%3Ahref')

   <jwatt> Yet another headache for authors of protean documents, or
   anyone copying scripted SVG between the XML and HTML dialects of

   attributes named xlink:href will get fixed up to a proper
   namespaceURI/localName combination though

   <ed__> well...you could encourage people to use elm.href.baseVal

   so you should be able to uniformly use the "XML SVG" method, AIUI

   JW: i don't think you can according to the spec right now
   ... i think suggesting elm.href.baseVal is a bit crappy,
   getAttribute/setAttribute is very common
   ... from my reading the spec, i'm not sure that xlink:href is
   treated correctly, and it'd be very weird for the spec to say that
   the attribute name is "xlink:href" and yet it's called "href" in the
   xlink namespace
   ... perhaps HTML could predefine some namespaces and prefixes

   DS: i think that's something they've talked about anyway
   ... magic prefixes
   ... an HTML parser would understand that if you preface it with
   "svg:" it would understand that it would be the svg namespace,
   regardless or overriding any declarations

   JW: i think that's unncessary because in general people writing HTML
   SVG will be not declaring the namespaces
   ... and anyone writing polyglot documents, or pure SVG, will have to
   be declaring them correctly
   ... so i see no point in the HTML spec overriding
   ... i don't mind them predefining some prefixes

   DS: i think w3c in general should have a registry of prefixes

   JW: the implications of this is that basically HTML would have a
   "Namespaces in HTML" and not "Namespaces in XML"
   ... without the "draconian" processing of strict namespaces
   ... so, author friendly namespaces
   ... therefore that section about attributes that i talked about
   initially,, could be changed to treat ":" as a special
   ... 8.1 is the writing html section, 8.2 is the parsing section

   that seems like a grander idea for how to process foreign namespace
   stuff in html

   i.e. decentralised extensibility

   which some in the HTML WG seem to be somewhat against

   but others are for

   DS: so jonathan you like the idea of decentralised extensibility?

   JW: yes i think so
   ... i don't like the problems associated with Namespaces in XML
   ... but i think HTML could go a long way to fixing that and making
   it authoring friendly

   DS: agreed, Namespaces in XML has some flaws
   ... a good thing to come out of this could be fixing those flaws
   ... i don't think it would harm decentralisation to have a registry,
   if you also provide a mechanism for overriding that registry

   JW: everything who's been writing Namespaces in XML content will
   have defined their namespaces, and it would be no problem to define
   defaults, so their declarations would override it

   DS: so all the content out there that missed the SVG namespace
   declaration in the root would be conformant, if we had a new
   Namespaces spec
   ... which i'm all for
   ... i think we should take this to XML, as well as the HTML WG


     [17] http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#adjust-foreign-attributes

   DS: it's backwards compatible
   ... some people will write parsers that don't treat overridden
   namespace prefixes correctly
   ... but i think that's a relatively small risk

   so at that section, it says to change attributes named "xlink:href"
   into an attribute with namespace uri XLINKNS and local name "href"

   JW: perhaps that does work, but i don't think it's done the way it
   should be

   ED: that could make it easier for us to transition to just "href" in
   the future

   DS: this is just magic prefixing, not sure why you have a problem
   with it?

   JW: my problem is that it's effectively putting veto power in the
   HTML spec

   DS: so this is just for HTML 5, not for all future languages
   ... it's possible HTML 6 could introduce a way to override the
   ... it could still even happen in HTML 5

   JW: that's what i'm proposing

   DS: so you don't have a problem with magic prefixes, nor with
   assuming xlink prefix defaults to the xlink namespace
   ... just that there's no way of overriding it?

   JW: yes, this is hard coding the prefixes rather than providing
   defaults for them

   DS: there's no reason that HTML shouldn't consider your solution

   JW: it's not a fully thought through solution, but it seems better
   on the face of it
   ... to me the problem with hard coding as opposed to defaulting is
   that it's unnecessarily restricting of future evolution of languages
   ... plus, it unncessarily introduces incompatibility with HTML and
   XHTML and adding to the problems of polyglot document authors

   ED: are we asking for namespace support?

   DS: they already provide namespace support

   JW: sort of, not arbitrary prefixes

   DS: no, we wouldn't ask for that
   ... just asking that it not close the door on future namespace

   JW: the problem is the word "namespaces" has a lot of negative
   connotations for people
   ... i think it's purely because of it not having defaults for
   ... writing svg:circle or html:p is not hard
   ... i think most people's headaches with namespaces would disappear

   DS: making it the default, rather than hard coding it, actually
   keeps the door open for us to have a registry that are defaulted
   ... without needing the HTML spec to add them

   ED: without having studied the exact section you quoted, i won't say
   anything about it
   ... i would say that this seems like an ok solution to me
   ... i would be ok with giving it as feedback

   JW: i haven't read the HTML spec sufficiently to make a judgement
   call about it just yet

   ED: i wonder what the reasons would be for special handling of the
   ":" character in that section

   JW: i will look at this in detail tomorrow, and firm up my feelings
   on it

   DS: any feedback from other moz people?

   JW: no

   jwatt, if you could firm up your proposal and mail it to the list
   tomorrow (or whenever), i will comment on it there

   <jwatt> ack

   DS: let's try to send something on thursday, even if it's

Clamping of rx/ry values on <rect>


     [18] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0147.html

   ED: i had an action to propose clarifying wording for edge cases
   with rx/ry on <rect>
   ... in that mail i given an algorithm and proposed text
   ... jonathan and cameron sent replies
   ... one thing mentioned is that css3 borders&backgrounds defines
   clamping in a different way
   ... the way it's specified, i don't think it's compatible
   ... and the alg i specify is also different from the css3 alg
   ... so we can decide if we want to align or not; might be a good
   idea to do that

   DS: do you have a link to the css spec?


     [19] http://dev.w3.org/csswg/css3-background/#the-border-radius

   DS: i think going for alignment is a good idea, but this is an
   editors draft
   ... i think we could coordinate

   i think they may have implementations of border-radius

   JW: svg implementations seem to do different things
   ... it seems a minor point the way you do the clamping

   DS: but it does have visible effects

   JW: i'm not saying it's a non-issue, just that it's minor
   ... there should be compatibility
   ... the way i implemented it in mozilla is just to put priority on
   making both rx/ry the same
   ... which seems to be what the css3 draft does as well

   ED: i don't mind changing

   JW: neither do it, just want it to be consistent

   ED: every implementation was different
   ... for these edge cases there is no interop

   DS: iirc, cairo does one thing and openvg does another thing
   ... and other libraries do it another way, and it might not be in
   control of the UA

   ED: i think you do control those corners, i don't think there's a
   problem with that
   ... you can build a path if you have to

   AG: breaking down to a path takes some time
   ... not expensive, but

   DS: did you look at what openvg defines?

   ED: no, the reasoning i took was to try to extract sense from the
   current spec sense
   ... and this was an arbitrary way to make the text more clear
   ... it does make sense to keep corner radii the same
   ... i'd be ok with doing that
   ... possibly we should still check with the css wg to see that it's
   compatible with their algorithm for corners

   DS: send a mail to them?

   ED: sure

   <scribe> ACTION: Erik to send mail to the CSS WG asking about their
   border-radius clamping algorithm

   <trackbot> Created ACTION-2486 - Send mail to the CSS WG asking
   about their border-radius clamping algorithm [on Erik Dahlström -
   due 2009-03-16].

SVG 1.1 Basic DTD issue

   DS: the reason i raised this is that it's causing problems for the


     [20] http://lists.w3.org/Archives/Public/www-svg/2007May/0011.html

   DS: so xml:space is double defined
   ... and the content model for SVG.clipPath.content is ambiguous
   ... who wants to fix it?

   ED: we could fix this in the 2ed spec
   ... or we could replace it with the RNG version

   CM: easiest thing seems to me to be to just fix the DTD

   JW: can we just silently fix it?

   DS: i can find out

   JW: what happens if we do? and what's the worst that would happen,
   vs the time taken to create a 2ed?

   <scribe> ACTION: Doug to determine the feasibility of changing the
   SVG 1.1 Mobile/Basic DTD inplace

   <trackbot> Created ACTION-2487 - Determine the feasibility of
   changing the SVG 1.1 Mobile/Basic DTD inplace [on Doug Schepers -
   due 2009-03-16].

Duplicate IDs of some test slides in 1.2T

   AG: i can fix those


     [21] http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A61A231F970@mailkeeper.mdigitalm.com

   <scribe> ACTION: Anthony to fix up the duplicated IDs in the slides,

     [22] http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A61A231F970@mailkeeper.mdigitalm.com

   <trackbot> Created ACTION-2488 - Fix up the duplicated IDs in the
   @mailkeeper.mdigitalm.com [on Anthony Grasso - due 2009-03-16].

     [23] http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A61A231F970@mailkeeper.mdigitalm.com

Update on various other SVG 1.1 errata actions

   so for this topic i just wanted to check where we are with errata

   JW: for my part, i'm focussing on the HTML stuff at the moment,
   since i think that's the super important and urgent thing
   ... so no updates

   all: same here


     [24] http://lists.w3.org/Archives/Public/www-validator/2009Mar/0018.html

More validator stuff

   DS: currently there's a lot of svg content on wikipedia
   ... which has rdf in it
   ... and it can't be validated by our validator


     [25] http://lists.w3.org/Archives/Public/www-validator/2009Mar/0019.html

   DS: i'm not saying we need every validation combination of languages
   ... but SVG and RDF seems to be a real case that we should cater for
   ... we could do a DTD, or a schema (which would need work from the
   RDF folk)

   JW: is there some nice generic way we can handle any namespaces and
   it validates?

   DS: for dtds it's not possible
   ... if there were an RDF DTD, how hard would it be to make an

   JW: don't know
   ... seems a shame to put resources on a non-forwards-looking

   DS: but the stopgap solution might not be that hard
   ... if all it is is saying "RDF is allowed anywhere in SVG" and
   appending the RDF DTD to the SVG DTD, and that's it, then that'd be
   an easy solution
   ... that solves the problem today
   ... while we wait for the generic NVDL solution

   JW: do we really think it's that easy?

   DS: no idea, haven't looked into it

   <scribe> ACTION: Doug to look into allowing RDF in the SVG DTD

   <trackbot> Created ACTION-2489 - Look into allowing RDF in the SVG
   DTD [on Doug Schepers - due 2009-03-16].

   <anthony> [26]http://www.w3.org/Graphics/SVG/WG/track/actions/2066

     [26] http://www.w3.org/Graphics/SVG/WG/track/actions/2066

Summary of Action Items

   [NEW] ACTION: Anthony to fix up the duplicated IDs in the slides,
   [NEW] ACTION: Doug to determine the feasibility of changing the SVG
   1.1 Mobile/Basic DTD inplace
   [NEW] ACTION: Doug to look into allowing RDF in the SVG DTD
   [NEW] ACTION: Erik to send mail to the CSS WG asking about their
   border-radius clamping algorithm

     [27] http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A61A231F970@mailkeeper.mdigitalm.com

   [End of minutes]

Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 10 March 2009 05:25:18 UTC

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