minutes, 06 March 2014 SVG WG telcon

Minutes from this week's telcon are below.

http://www.w3.org/2014/03/06-svg-minutes.html


    [1]W3C

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

                                - DRAFT -

                     SVG Working Group Teleconference

06 Mar 2014

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/public-svg-wg/2014JanMar/0118.html

    See also: [3]IRC log

       [3] http://www.w3.org/2014/03/06-svg-irc

Attendees

    Present
    Regrets
    Chair
           Cameron

    Scribe
           nikos

Contents

      * [4]Topics
          1. [5]Shipping paint-order
          2. [6]Reference box keywords for 'clip-path' and 'mask'
          3. [7]Renaming 'fill' and 'stroke' keywords to 'fill-box'
             and 'stroke-box'
          4. [8]Bounding box of <path> without d=""
      * [9]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 06 March 2014

    <scribe> scribe: nikos

    <scribe> scribenick: nikos_

Shipping paint-order

    heycam: last week Dirk brought up the issue of whether we
    should discuss things in the WG to ship new SVG 2 features in
    browsers
    ... I'm interested in paint-order
    ... do people think the definition of that property is stable
    enough for FF to ship in release build?

    ed: I recently enabled it in stable releases for Blink

    krit: you said it's up to each implementation

    heycam: I thought it would be nice to bring up in the WG before
    we decide those things

    krit: thought we'd decided for paint-order

    heycam: I think paint-order is ready anyway

    Tav: can we get notified of status? How can I try it out

    heycam: available in Chrome Canary and FF nightly
    ... Webkit, dirk?

    krit: patch in but not reviewed yet

    Tav: I'd like to see announcements to the WG
    ... give a week or so to try it before we agree to release

    krit: I wrote 11 reftests and some JS tests. I can upload the
    reftests

    nikos: It would be good for non browser people to know in
    general when features are being added

    Tav: I was thinking of what to add to InkScape

    heycam: I don't need to ship it urgently in FF so if you want
    another week to play around that's fine

    ed: Blink change hasn't trickled down to stable release yet,
    but it will at some point
    ... it's been in Canary for a couple of months behind a flag

    heycam: sounds like there is time to test paint-order before it
    hits stable builds

    Tav: I'm not too worried about paint-order but other features

    heycam: I think we can keep trying to do this where we bring it
    up in the group

Reference box keywords for 'clip-path' and 'mask'

    krit: simple one first...

    <krit> [10]http://dev.w3.org/fxtf/masking/#the-clip-path

      [10] http://dev.w3.org/fxtf/masking/#the-clip-path

    krit: if you open link, you'll see we have two types of value
    for clip-path
    ... clip-source and geometry-box
    ... the question is, do we want to have these reference boxes
    for clip source as well?
    ... for instance, you have clip-path and clip path units object
    bounding box
    ... we may want to have a keyword for fill stroke view box that
    allows you to reference a different box
    ... fill would be redundant, but stroke or something would be
    interesting

    heycam: may have discussed this before in the context of
    another element
    ... I feel the choice of which box is intrinsic to the
    definition of the resource element
    ... so having something in the property value where you are
    referencing it maybe isn't useful

    krit: do we want new keywords for HTML elements and new
    keywords for SVG elements?
    ... I wouldn't add it to this level, but I think it needs
    discussing

    heycam: the spec allows new keyword values to be specified in
    the property

    krit: just allows for basic shapes

    heycam: basic shapes don't support paths?
    ... paths were deferred?

    krit: yes
    ... it got deferred

    heycam: if we don't allow new values in clip-path-units it will
    be relevant to border box
    ... I don't know if we need to do this now

    krit: I think this should be deferred until the next level
    anyway, but should be discussed now
    ... the behaviour should be consistent for all elements -
    gradient, clips, filters, etc

    heycam: agree
    ... my feeling would be yes to adding new values to the
    attributes in general
    ... but might need to think about it more

    krit: maybe we can discuss at the F2F
    ... anyone object to not having this in the first level of the
    spec?
    ... not being able to choose which reference box you use. SVG
    is always object bounding box or user space
    ... we agreed that we want it eventually
    ... but level 1 or later?
    ... later allows us to come up with a solution for all SVG
    elements

    Tav: doesn't matter to me
    ... current bounding box doesn't include stroke?

    heycam: no
    ... I don't think it's urgent enough to do in level 1 right now
    ... think we should decide more generally how to treat this

    krit: anyone object?

    ed: what is the default behaviour for HTML?
    ... what would be the equivalent?

    krit: would be border-box for HTML elements

    ed: that kind of is the same as the stroke bounding box

    krit: not really, but if you want to compare SVG to HTML then
    yes

    ed: trying to think of cases where you'd want to use the same
    thing. Taking a basic-shape and apply same box to HTML and SVG
    and have it behave the same

    heycam: the keywords on the property at the moment, we decided
    that if you use an SVG specific keyword (e.g. fill) then that
    means the default box for HTML content?

    krit: that's correct

    heycam: would we be adding additional keywords for the HTML
    specific ones?
    ... in the geometry-box bit of the clipPath?

    krit: we would use the same reference box

    heycam: is that in the definition of shape-box?

    krit: for polygon, inset, circle, ellipse

    heycam: what about border-box, patter-box, margin-box? are they
    already supported in the property?

    krit: yes

    heycam: as Erik was pointing out. If you want to define a basic
    shape and have it apply to SVG and HTML

    krit: it means the SVG or the HTML would fall back to the
    default
    ... you can only specify one

    heycam: is that a problem?

    krit: I haven't thought about that yet
    ... it's an interesting point
    ... don't know if it would be a problem

    heycam: in practice, maybe using stroke-box in SVG and
    border-box in HTML is what you want 90% of the time

    krit: if you don't want default values for both, then you need
    to have two classes

    heycam: seems like something we could add later without
    problems
    ... if you think we should go that way
    ... coming back to your initial question of whether we should
    decide now

    krit: we don't need to decide now, but if we don't I'd like to
    defer to next level

    heycam: didn't hear anyone say that we need to solve it now

    RESOLUTION: we will handle new box keywords in units attributes
    in level 2 of Masking

Renaming 'fill' and 'stroke' keywords to 'fill-box' and 'stroke-box'

    krit: we discussed during the F2F
    ... decided we don't want -box at the end
    ... because what is a box, block, element, etc
    ... Erik brought up that it might make sense for usability
    ... we have box at the end of many things already
    ... CSS WG decided they want box at the end
    ... and it's up to the SVG WG to agree or reject the decision

    heycam: I think one of the reasons I like fill and stroke as
    they are is that it matches the names of the properties you
    pass to extended getBBox()
    ... but not sure that needs to outweigh the issue

    krit: it's always good to align the keywords
    ... can we use fill-box and stroke-box on getBBox?

    heycam: possible, but would need to be camelCase
    ... the other thing, we have markers as a value in there

    krit: even markers we'd have -box

    heycam: I'd lean towards making it -box in the property and
    leave box off on getBBox

    krit: agree

    ed: I think it's fine as well

    krit: do we rename property keywords to fill-box,stroke-box,
    etc?

    RESOLUTION: fill and stroke keyword values in clip-path and
    mask property get renamed to fill-box and stroke-box

Bounding box of <path> without d=""

    heycam: we brought discussion to the mailing list
    ... seemed like we had agreement

    krit: so should path element without d attribute have a
    bounding box, and should it contribute to it's parent?

    nikos: think we had consensus on what model to use
    ... just need to decide what happens for path without d

    krit: do they render or not? A d attribute can have invalid
    syntax and it will draw up to that invalid point

    heycam: the discussion went a bit into invalid or empty
    attributes would invoke some lacuna value
    ... which would be the way that something gets rendered

    ed: think they're all a bit special with regards to lacuna
    values
    ... because broken paths do render up to last good data

    krit: but for both you render right?

    ed: unless the error is so early you don't render anythying

    heycam: it doesn't make sense to have a lacuna value for d that
    causes rendering

    all: agree

    heycam: i don't think it makes sense to make a lacuna value an
    invalid value

    nikos: an empty d is not invalid, it just doesn't render.
    There's a special bit of text

    krit: can we change that?

    nikos: I would have thought it might be too late

    heycam: as long as it doesn't change the rendering behaviour

    krit: to make things more confusing. the canvas path syntax
    doesn't require a moveto
    ... if you start with a lineto, it will behave as a moveto
    ... empty strings will not render anything

    heycam: we can decide the issue of omitting the inital moveto
    separately
    ... do you think having an empty string and is analogous to a
    zero width/height rect ?
    ... I think everyone agrees that an empty path shouldn't render

    nikos: so should a M0,0 render?

    krit: a rect with zero width height shouldn't render

    heycam: I have a feeling implementations render markers in that
    case

    RESOLUTION: path/polygon/polyline with no data set (empty or
    zero valid commands) should not render

    heycam: the next issue is what getBBox should return on
    path/polygon/polyline with empty or zero valid commands
    ... everyone in agreement that it should be [0,0,0,0] I think?
    ... would it be useful to distinguish a real empty bbox from an
    invalid one?
    ... I have a feeling we would need to return an actual box
    ... I think [0,0,0,0] is probably safer

    ed: think that's what implementations do

    RESOLUTION: getBBox for path/polygon/polyline with no data set
    (empty or zero valid commands) should return [0,0,0,0]

    heycam: final thing is whether the [0,0,0,0] box contributes to
    ancestor getBBox calls

    nikos: don't think it should

    all: agree

    heycam: I think this is similar to when display:none is set

    RESOLUTION: Bounding box for path/polygon/polyline with no data
    set (empty or zero valid commands) should not contribute to
    ancestor bounding box

    ed: when you have a d attribute which is broken half way
    through I think the bbox should represent the valid part of the
    path
    ... don't think we define that in the spec

    krit: are you sure there's no error handling in the appendix?

    ed: doesn't talk about the bbox. Just says you render up to
    that point

    nikos: I think the bounding box should cover what is rendered

    heycam: agree

    RESOLUTION: bounding box for path with some invalid data
    following some valid data will include the data which is
    rendered

    <scribe> ACTION: nikos to update specification with
    path/polyline/polygon resolutions regarding bounding box for
    missing data [recorded in
    [11]http://www.w3.org/2014/03/06-svg-minutes.html#action01]

    <trackbot> Created ACTION-3599 - Update specification with
    path/polyline/polygon resolutions regarding bounding box for
    missing data [on Nikos Andronikos - due 2014-03-13].

Summary of Action Items

    [NEW] ACTION: nikos to update specification with
    path/polyline/polygon resolutions regarding bounding box for
    missing data [recorded in
    [12]http://www.w3.org/2014/03/06-svg-minutes.html#action01]

    [End of minutes]


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, 6 March 2014 22:51:26 UTC