See also: IRC log
<trackbot> Date: 07 June 2012
<scribe> scribenick: nikos
shepazu: these are all handled in css now right?
shepazu: So we don't need them - let's drop them
nikos: seems reasonable
ed: as long as we refrence css color spec, that's fine
nikos: css spec says it's an exact copy
shepazu: has both spellings of gray (grey)
Resolve: Reference CSS color keywords and drop them from SVG
Resolution: Reference CSS color keywords and drop them from SVG
shepazu: in favor of what?
ed: that's the question
... The closes thing is something out of the CSS object model spec
... CSS doesn't currently have a way to expose paint
... they probably have a way to expose string valus but not individual colour values and such
shepazu: svg interface doesn't have a way of exposing things like css colour values
ChrisL: regarding the previous
topic, we agreed we'd add the colour module as chapter, which
includes the colour keywords and also has some new stuff
... How does the decision affect that?
shepazu: We would still do that but drop the list and reference CSS
ChrisL: So only have new stuff in there?
ChrisL: I was trying to make it self contained
ChrisL: Has everything that SVG1 and CSS3 Color had plus new stuff
shepazu: May change our
... This duplicates stuff that's in CSS?
shepazu: Is it possible that we could do this as a CSS module instead?
ChrisL: We already did, it was
called CSS colour.
... it's a Rec
shepazu: what's the benefit?
ChrisL: all the syntax is in one
... About 50% is new content - compared to what the CSS spec says
... I'm not opposed to trimming down
<fantasai> Actually, it's REC
ChrisL: At the end there's a
complete grammar for colour values and stuff - but if people
want to reference CSS colour that's fine
... A lot of the stuff from CSS colour was in SVG 1
shepazu: When we review, I think
that we are going to have an easier time if we don't duplicate
stuff and only have original material
... where we've gotten pushback in the past is when we duplicate CSS
... one thing I noticed - you're using xlink:href, can we just use href
ChrisL: Bear in mind this was
edited about a year ago
... I'm slightly concerned referencing CSS makes it harder to understand as you have to follow links
shepazu: Could we all reference one location?
ChrisL: Then it gets even more confusing
shepazu: I was thinking of a primer. Ok I withdraw the suggestion
ChrisL: It would be nice to get
rid of the big list becaues people use a small subset
... We resolved a while ago it's going to be a new chapter called SVG colour
... lots of people go to the chapter in SVG 1 and then have to go to other sections to find what they need
shepazu: Might be more
informative to name this colour management
... but not too important to me
ChrisL: I'd push back on that
birtles: Is there anything in the CSS colour that's not in the SVG?
ChrisL: The idea is that it would
... I'd still like the syntax summaries to have everything
shepazu: I think that's reasonable
<scribe> ACTION: ChrisL Trim out content which is in CSS3 colour and reference CSS3 colour instead [recorded in http://www.w3.org/2012/06/07-svg-minutes.html#action01]
<trackbot> Created ACTION-3304 - Trim out content which is in CSS3 colour and reference CSS3 colour instead [on Chris Lilley - due 2012-06-14].
Back to SVG paint interface
shepazu: What Erik was saying,
this provides some things that CSS doesn't and CSS provides
some things this doesn't
... If people find the functionality useful, maybe we could request it be added to CSS OM
ChrisL: It's not clear whether the CSS OM is being worked on
shepazu: It's not
... we should raise it with them
ed: I think it makes more sense to have it in the CSS OM
ChrisL: Be aware that's opening a
whole can of works about who's maintaing the CSS OM, etc.
... what happens if there's a gradient on the div and you ask for it's RGB colour?
... is there a way to find out it has a gradient?
... I suspect the answer is 'we don't know, it's not supported yet'.
<scribe> ACTION: ed to ask the CSS WG what's happening with the object model [recorded in http://www.w3.org/2012/06/07-svg-minutes.html#action02]
<trackbot> Created ACTION-3305 - Ask the CSS WG what's happening with the object model [on Erik Dahlström - due 2012-06-14].
ChrisL: I don't have anything to
report on this. Tav and I were supposed to work on a manifest
that could be imported but I don't know if that's used in
... W3C has a very old version on the test side and the version that the CSS WG is using is more recent
... don't know if that's a problem at this stage
... I need to talk to Peter Linss
shepazu: We are doing Test the Web forward next Friday
ChrisL: I'll talk to Peter asap
shepazu: Could I join in, I'd like to get up to speed
shepazu: My thought is yes, it
would be weird if we didn't
... maybe we could add a new property that says don't scale the marker
nikos: I was thinking exactly the
... is it useful to scale the marker but not the stroke?
shepazu: I can see a use - let's say the marker is my current location or is something significant on a map
ed: default should be that non-scaling-stroke applies to the markers too
shepazu: let's say we have circle
and triangle alternating, circle has r=5 triangle has
... if you scale down the line, these things closer and they'd bump into one another
... if you don't scale the marker
brian: I'm thinking of the use case mentioned, I'm wondering if that's a separate feature?
brian: when we talked about
requirements for mapping we talked about a feature where you
can have a fixed size object that doesn't scale - for things
like current location
... maybe if you want an object not to scale you should use the feature proposed in the requirements for mapping
ChrisL: We're trying to down play markers in SVG 2 - the single marker of 'you are here' on a map doesn't have to be done with a marker
shepazu: So in general do we think that markers should follow the values of non-scaling stroke?
shepazu: Maybe we could have an option for changing that but we need to examine the use cases to see if it makes sense
ChrisL: There's a lot of issues and we don't want to get into that right now for this
<scribe> ACTION: heycam Specify that non-scaling stroke applies to markers also [recorded in http://www.w3.org/2012/06/07-svg-minutes.html#action03]
<trackbot> Created ACTION-3306 - Specify that non-scaling stroke applies to markers also [on Cameron McCormack - due 2012-06-14].
ed: I don't know if there's much
... most edits are by Dirk and Cameron and they're not here
... Dirk updated some parts of the transform section
... Cameron made some small general changes
ChrisL: So these were added on
the understanding that it would be faster to switch off
rendering, do updates, then switch rendering back on
... Implementations can handle that on their own and this makes it slower now. is that right?
shepazu: You might have the author making assumptions about how particular systems will optimise and that's bad long term
ChrisL: Do we need to make it a stub so content works - will that give any surprises?
ed: suspendRedraw says you can't suspend for an infinite about of time
ChrisL: So you don't know when it will kick back in ?
ChrisL: So if we make it a stub will it work?
ed: it'll work as well as it does
in Firefox and ie - that's what they have already
... I've been looking at doing the same in Opera
... we should define what value the stub returns
ChrisL: if we remove it completely that might mean that older content will break
<scribe> ... unknown error methods and such
UNKNOWN_SPEAKER: so we can't do
... we can specify it's a stub that doesn't do anything
... and say not to use it in new content
shepazu: what about forceRedraw?
ed: that's still being discussed on the list - there might be a usecase
shepazu: Tab was saying there's
no way to flush the style
... so it might be useful
... not clear that it does collect everything together and redraw
ed: I think we should continue to
discuss foreceRedraw and see if there are any more possible use
... in any case we need to define what it does - flushing style for example
... for the other methods are we in agreement that they can be stubbed out?
unsuspendRedraw will be stubbed out - return value must be
... unsuspendRedrawAll will be stubbed out - return value must be specified
<scribe> ACTION: ed will stub out suspendRedraw, unsuspendRedraw, unsuspendRedrawAll - return value must be specified [recorded in http://www.w3.org/2012/06/07-svg-minutes.html#action04]
<trackbot> Created ACTION-3307 - Will stub out suspendRedraw, unsuspendRedraw, unsuspendRedrawAll - return value must be specified [on Erik Dahlström - due 2012-06-14].
ed: We can come back to
... it seems like it's disconnected from the others
birtles: Firefox flushes
... on forceRedraw
ed: it says in svg 1.1 that in
forces user agents to redraw all regions of the viewport that
... I don't know if that's specific enough for testing
... to me it doesn't sound like it has to be a synchronous operation
... I think it should be defined in more detail if we want it to something specific
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/grey (gray)/gray (grey)/ Succeeded: s/favour/favor/ Succeeded: s/explose/expose/ Succeeded: s/that CSS 1/that SVG1 and CSS3 Color/ Succeeded: s/a CR/a Rec/ Succeeded: s/default should be markers scale/default should be that non-scaling-stroke applies to the markers too/ Found ScribeNick: nikos Inferring Scribes: nikos Default Present: Doug_Schepers, ed, birtles, nikos, ChrisL Present: Doug_Schepers ed birtles nikos ChrisL Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012AprJun/0080.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 07 Jun 2012 Guessing minutes URL: http://www.w3.org/2012/06/07-svg-minutes.html People with action items: applies chrisl ed heycam non-scaling specify stroke that[End of scribe.perl diagnostic output]