10 Mar 2009



erik, Cameron


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

telcon times

<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

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

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

Clamping of rx/ry values on <rect>

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

SVG 1.1 Basic DTD issue

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

Duplicate IDs of some test slides in 1.2T

AG: i can fix those


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

Update on various other SVG 1.1 errata actions

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

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

<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

Summary of Action Items

[NEW] ACTION: Anthony to fix up the duplicated IDs in the slides, http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A61A231F970@mailkeeper.mdigitalm.com
[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
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/03/10 05:21:11 $