<shepazu> trackbot, this will be SVG
<trackbot> Sorry, shepazu, I don't understand 'trackbot, this will be SVG'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
<ed__> scribe: erik
<ed__> scribeNick: ed__
<heycam> 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
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
<ed__> http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0209.html
DS: any feedback from mozilla?
<jwatt> 8.1.2.3 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. HTML SVG:
<jwatt> XML SVG : getAttributeNS('http://www.w3.org/1999/xlink', 'href')
<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 SVG.
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, 8.1.2.3, could be changed to treat ":" as a special character
... 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
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 prefix
... 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 then
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 support
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 prefixes
... 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 provisional
<ed__> 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?
<ed__> 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].
DS: the reason i raised this is that it's causing problems for the validator
<shepazu> 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].
AG: i can fix those
http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A61A231F970@mailkeeper.mdigitalm.com
<scribe> ACTION: Anthony to fix up the duplicated IDs in the slides, http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A61A231F970@mailkeeper.mdigitalm.com
<trackbot> Created ACTION-2488 - Fix up the duplicated IDs in the slides, http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A61A231F970@mailkeeper.mdigitalm.com [on Anthony Grasso - due 2009-03-16].
so for this topic i just wanted to check where we are with errata actions
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
<shepazu> http://lists.w3.org/Archives/Public/www-validator/2009Mar/0018.html
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
<shepazu> 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 SVG+RDF DTD?
JW: don't know
... seems a shame to put resources on a non-forwards-looking solution
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> http://www.w3.org/Graphics/SVG/WG/track/actions/2066