W3C home > Mailing lists > Public > www-svg@w3.org > June 2012

minutes, 7 June 2012 SVG WG telcon

From: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au>
Date: Fri, 8 Jun 2012 07:57:39 +1000
Message-ID: <4FD123D3.7030006@cisra.canon.com.au>
To: <public-svg-wg@w3.org>
Hi,

Minutes from today's SVG WG telcon are at
http://www.w3.org/2012/06/07-svg-minutes.html

and below as text.

    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                     SVG Working Group Teleconference

07 Jun 2012

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/public-svg-wg/2012AprJun/0080.html

    See also: [3]IRC log

       [3] http://www.w3.org/2012/06/07-svg-irc

Attendees

    Present
           Doug_Schepers, ed, birtles, nikos, ChrisL

    Regrets
    Chair
           SV_MEETING_CHAIR

    Scribe
           nikos

Contents

      * [4]Topics
          1. [5]Dropping CSS paint color keywords
          2. [6]Drop SVG paint interface
          3. [7]Status of Shepherd integration
          4. [8]Should non-scaling-stroke affect marker rendering?
          5. [9]SVG 2 status update
          6. [10]Making suspendRedraw, unsuspendRedraw, and
             forceRedraw optional in SVG
      * [11]Summary of Action Items
      __________________________________________________________

    <trackbot>  Date: 07 June 2012

    <scribe>  scribenick: nikos

Dropping CSS paint color keywords

    <ed>
    [12]http://lists.w3.org/Archives/Public/www-svg/2012May/0092.ht
    ml

      [12] 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>
    [13]https://svgwg.org/svg2-draft/painting.html#InterfaceSVGPain
    t

      [13] 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>
    [14]http://dev.w3.org/cvsweb/~checkout~/SVG/modules/color/maste
    r/SVGColor.html?rev=1.23;content-type=text%2Fhtml

      [14] 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
    [15]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>
    [16]http://lists.w3.org/Archives/Public/www-svg/2012May/0093.ht
    ml

      [16] http://lists.w3.org/Archives/Public/www-svg/2012May/0093.html

    <shepazu>
    [17]https://svgwg.org/svg2-draft/painting.html#InterfaceSVGPain
    t

      [17] 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
    [18]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>
    [19]http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Map
    ping

      [19] 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
    [20]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>
    [21]http://www.w3.org/mid/CAJgFLLv2TvH0xhruyHQCY=ozj6WFw20AAVrD
    dzwOH7Wf9CoBWw@mail.gmail.com

      [21] 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
    [22]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

Summary of Action Items

    [NEW] ACTION: ChrisL Trim out content which is in CSS3 colour
    and reference CSS3 colour instead [recorded in
    [23]http://www.w3.org/2012/06/07-svg-minutes.html#action01]
    [NEW] ACTION: ed to ask the CSS WG what's happening with the
    object model [recorded in
    [24]http://www.w3.org/2012/06/07-svg-minutes.html#action02]
    [NEW] ACTION: ed will stub out suspendRedraw, unsuspendRedraw,
    unsuspendRedrawAll - return value must be specified [recorded
    in [25]http://www.w3.org/2012/06/07-svg-minutes.html#action04]
    [NEW] ACTION: heycam Specify that non-scaling stroke applies to
    markers also [recorded in
    [26]http://www.w3.org/2012/06/07-svg-minutes.html#action03]

    [End of minutes]
      __________________________________________________________


     Minutes formatted by David Booth's [27]scribe.perl version
     1.136 ( [28]CVS log)
     $Date: 2012/06/07 21:55:00 $
      __________________________________________________________

      [27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [28] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43
Check for newer version at
[29]http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

      [29] 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:
[30]http://lists.w3.org/Archives/Public/public-svg-wg/2012AprJun/0080.h
tml

      [30] 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:
[31]http://www.w3.org/2012/06/07-svg-minutes.html
People with action items: applies chrisl ed heycam non-scaling specify
stroke that

      [31] http://www.w3.org/2012/06/07-svg-minutes.html


    End of [32]scribe.perl diagnostic output]

      [32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm


The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Thursday, 7 June 2012 21:58:37 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:51 GMT