- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 10 Mar 2009 16:24:35 +1100
- To: public-svg-wg@w3.org
http://www.w3.org/2009/03/09-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SV_MEETING_TITLE
10 Mar 2009
[2]Agenda
[2] http://www.w3.org/mid/20090309003206.GA3558@arc.mcc.id.au
Attendees
Present
DS, ED, CM, JW
Regrets
Chair
SV_MEETING_CHAIR
Scribe
erik, Cameron
Contents
* [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
<heycam>
[13]http://www.w3.org/mid/op.uqdgb7kvgqiacl@gnorps.linkoping.osa
[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
<shepazu>
[14]http://www.timeanddate.com/worldclock/meetingdetails.html?year=2
009&month=3&day=11&hour=6&min=30&sec=0&p1=239&p2=240&p3=188&iv=1800
[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
<ed__>
[15]http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/020
9.html
[15] 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('[16]http://www.w3.org/1999/xlink',
'href')
[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
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
[17]http://www.whatwg.org/specs/web-apps/current-work/multipage/tree
-construction.html#adjust-foreign-attributes
[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
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__>
[18]http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/014
7.html
[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?
<ed__>
[19]http://dev.w3.org/csswg/css3-background/#the-border-radius
[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
validator
<shepazu>
[20]http://lists.w3.org/Archives/Public/www-svg/2007May/0011.html
[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
[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
[22] http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A61A231F970@mailkeeper.mdigitalm.com
<trackbot> Created ACTION-2488 - Fix up the duplicated IDs in the
slides,
[23]http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A61A231F970
@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
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>
[24]http://lists.w3.org/Archives/Public/www-validator/2009Mar/0018.h
tml
[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
<shepazu>
[25]http://lists.w3.org/Archives/Public/www-validator/2009Mar/0019.h
tml
[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
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> [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,
[27]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
[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