SVG Working Group Teleconference -- 07 Jun 2012

<trackbot> Date: 07 June 2012

<scribe> scribenick: nikos

Dropping CSS paint color keywords

<ed> http://lists.w3.org/Archives/Public/www-svg/2012May/0092.html

shepazu: these are all handled in css now right?

ed: yep

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

Drop SVG paint interface

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> https://svgwg.org/svg2-draft/painting.html#InterfaceSVGPaint

shepazu: We would still do that but drop the list and reference CSS

ChrisL: So only have new stuff in there?

shepazu: yep

ChrisL: I was trying to make it self contained

<ChrisL> http://dev.w3.org/cvsweb/~checkout~/SVG/modules/color/master/SVGColor.html?rev=1.23;content-type=text%2Fhtml

ChrisL: Has everything that SVG1 and CSS3 Color had plus new stuff

shepazu: May change our decision
... This duplicates stuff that's in CSS?

ChrisL: yes

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 place
... 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 have everything
... 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

<ed> http://lists.w3.org/Archives/Public/www-svg/2012May/0093.html

<shepazu> https://svgwg.org/svg2-draft/painting.html#InterfaceSVGPaint

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

Status of Shepherd integration

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

Should non-scaling-stroke affect marker rendering?

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 same thing
... 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 width=10
... 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?

<birtles> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping

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?

[general agreement]

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

SVG 2 status update

ed: I don't know if there's much to discuss
... 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

Making suspendRedraw, unsuspendRedraw, and forceRedraw optional in SVG

<ed> http://www.w3.org/mid/CAJgFLLv2TvH0xhruyHQCY=ozj6WFw20AAVrDdzwOH7Wf9CoBWw@mail.gmail.com

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?

ed: yes

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 ?

ed: yes

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 that
... 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 cases
... 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?

Resolution: suspendRedraw, unsuspendRedraw will be stubbed out - return value must be specified
... 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 forceRedraw
... it seems like it's disconnected from the others

birtles: Firefox flushes styles
... on forceRedraw

ed: it says in svg 1.1 that in forces user agents to redraw all regions of the viewport that require updating
... 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

- DRAFT -

SVG Working Group Teleconference

07 Jun 2012

Attendees

Contents