SVG WG Meeting Minutes 2014-02-20

Minutes from the 20 February 2014 meeting are below.

http://www.w3.org/2014/02/20-svg-minutes.html

    [1]W3C

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

                                - DRAFT -

                     SVG Working Group Teleconference

20 Feb 2014

    [2]Agenda

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

    See also: [3]IRC log

       [3] http://www.w3.org/2014/02/20-svg-irc

Attendees

    Present
           heycam, ed, krit, birtles, stakagi, cabanier_, Tav,
           Doug_Schepers, Rich_Schwerdtfeger

    Regrets
    Chair
           Cameron

    Scribe
           birtles

Contents

      * [4]Topics
          1. [5]Update on Leipzig meeting venue
          2. [6]Should linking.html#processingIRI allow references
             to elements not in the document tree?
          3. [7]Define if attribute values are allowed to have
             leading and/or trailing whitespace (ISSUE-2447)
          4. [8]paint-order
      * [9]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 20 February 2014

    <scribe> scribenick: birtles

Update on Leipzig meeting venue

    krit_: I spoke with the director of the faculty of computer
    science
    ... it won't be possible to get the venue for free
    ... because it's not an event of the university
    ... I looked if there was space after the LGM meeting
    ... but it's not possible because classes start after that
    ... I checked before the meeting but no reply

    Tav: I checked as well

    krit_: there may be a response in a few days but I don't think
    the response will be any different
    ... there was another venue?

    Tav: some sort of hackerspace
    ... but I'm not sure it's suitable enough, may not be large
    enough

    heycam: do you have a name for it?

    krit_: I didn't check yet if there would be a hotel with a room

    <Tav> [10]http://sublab.org/raeume

      [10] http://sublab.org/raeume

    krit_: but then we'd need to rent it if there was a room

    Tav: it's more a place for mucking around with electronics
    ... doesn't look suitable from the pictures

    heycam: what should we do then

    krit_: I can check some hotels but it won't be free

    Tav: how much do you think?

    krit_: not sure
    ... university would be EUR100 per day

    heycam: that's for accommodation not meeting space?

    krit_: it was for the meeting space + Internet etc.

    heycam: that's not too bad, but if it's not available

    krit_: yes, it's not available after LGM

    nikos: what about Mozilla in Paris?

    heycam: yes, we have an office in Paris and a small space in
    Berlin
    ... I'm not sure how big it is but I can look into it

    Tav: Paris would be convenient for Cyril and I
    ... but the cost of moving between Leipzig and Paris greater
    than the cost of renting a space

    nikos: I'm not going to LGM so it wouldn't affect me

    heycam: who's going?

    Tav: I'm going, Chris...

    ed: not sure yet

    heycam: it might be good to hear from Chris then since we want
    to limit trips for him
    ... so it might depend if meeting in Paris counts as a second
    trip or not

    Tav: getting from Leipzig to Paris by train is a day's travel

    krit_: there's a non-stop flight

    heycam: is it worth looking into Berlin or Paris?

    krit_: I'll look into getting a hotel room in Leipzig then we
    can compare next week

Should linking.html#processingIRI allow references to elements not in
the document tree?

    <ed>
    [11]https://svgwg.org/svg2-draft/linking.html#processingIRI

      [11] https://svgwg.org/svg2-draft/linking.html#processingIRI

    ed: this came up in a bug report recently
    ... I think someone was saying it's not clear if you have a
    <rect> that references a gradient and that gradient is removed
    from the document... does that rect still have the gradient
    fill?
    ... or is it removed when the gradient is removed from the
    document
    ... the link itself might still be there since the gradient is
    reference

    krit_: is the link internal/external

    ed: either but I was thinking about internal

    heycam: what about the other way, if you start off with a
    gradient that is not in the document that you add an ID to and
    reference?

    <shepazu> (+1 to heycam)

    ed: in that part of the spec, does "a node doesn't exist" mean
    elements that are outside the document?
    ... I'm guessing it should but this should be more clear

    krit_: do you mean an element that is not in the DOM tree?
    ... how do you compute the style then if it is not in the DOM?
    ... I think that was an issue in the past

    <ed> <rect fill="url(#foo)"> then remove the #foo element

    heycam: I have a feeling that specs now define the computed
    style for an element that is outside the tree
    ... it's not just a null

    krit_: what do implementations do? do they allow referencing
    elements that are outside the tree?

    ed: I didn't do cross-browser testing but I think it would make
    sense to break reference when you remove elements from the
    document tree

    krit_: so you would like elements to be valid only if they are
    in the DOM tree?

    shepazu: in the past SVG allowed you to reference external
    resources

    <ed> and equally, when inserting a #foo element into the
    document, the fill=url(#foo) would magically be resolved... and
    if there are duplicate ids it would still be recomputed
    according to the normal getElementByID behavior

    shepazu: but I think Mozilla didn't allow that for a long time,
    has that changed

    heycam: yes, you can do that... as long as it's from an iframe

    birtles: you have been able to do that for a long time

    shepazu: where does that document live?
    ... but it's not available for scripting etc.
    ... if I were defining it today I would say it imports the
    external document into some resource shadow dom for resources
    ... so you're not relying on some external document
    ... but it's in a shadow document

    krit_: how does that help?

    shepazu: it unifies the behavior, it demystifies what is going
    on
    ... I think it's relevant to the conceptual idea of what is
    going on
    ... once a resource is removed from the document...

    krit_: there's a reason we load it in this way... for security,
    so there are no references from other domains

    shepazu: I don't think we want to change those things but just
    to define how those things are done
    ... with regards to simple document without external resources
    where you're referencing an internal gradient, the only gotcha
    is, what if that fragment is moved?
    ... I assume that would behave the same

    heycam: I suspect that things aren't define to this level of
    detail to know if during the small amount of time during with
    the element is moved would create a visible result

    shepazu: is it worth defining that?

    heycam: I suspect not since I think UAs will repaint at the end
    of the script block
    ... so do we agree about whether the link is broken...
    ... if an element that is referenced as a gradient (and
    similar) is removed from the document, it is no longer able to
    be referenced

    RESOLUTION: if an element that is referenced as a gradient (and
    similar) is removed from the document, it is no longer able to
    be referenced

    heycam: did someone want to look into HTML imports to see if
    that can be re-used to define this?
    ... who had the action for looking into shadow dom?

    krit_: I had the action but I'm not sure what you mean

    heycam: you'll find out

    ed: for element insertion, can we define the same so that you
    re-resolve all references with some given ID?

    heycam: I think that's fine

    RESOLUTION:
    ... upon element insertion, elements with IDs become
    referenceable

    <scribe> ACTION: update the spec to clarify behavior of
    references to elements when they are removed/added from the
    document [recorded in
    [12]http://www.w3.org/2014/02/20-svg-minutes.html#action01]

    <trackbot> Error finding 'update'. You can review and register
    nicknames at
    <[13]http://www.w3.org/Graphics/SVG/WG/track/users>.

      [13] http://www.w3.org/Graphics/SVG/WG/track/users%3E.

    <scribe> ACTION: ed to update the spec to clarify behavior of
    references to elements when they are removed/added from the
    document [recorded in
    [14]http://www.w3.org/2014/02/20-svg-minutes.html#action02]

    <trackbot> Created ACTION-3594 - Update the spec to clarify
    behavior of references to elements when they are removed/added
    from the document [on Erik Dahlström - due 2014-02-27].

Define if attribute values are allowed to have leading and/or
trailing whitespace (ISSUE-2447)

    ed: I think we've discussed this previously, I was hoping we
    could resolve on this

    <ed> ISSUE-2447?

    <trackbot> ISSUE-2447 -- Define if attribute values (in
    particular numerical attributes) are allowed to have leading
    and/or trailing whitespace (e.g x=" 10" interpreted as 10 and
    not as an error) -- raised

    <trackbot>
    [15]http://www.w3.org/Graphics/SVG/WG/track/issues/2447

      [15] http://www.w3.org/Graphics/SVG/WG/track/issues/2447

    ed: I had a look at what HTML5 does for this
    ... it seems that for numeric values leading/trailing
    whitespace is allowed
    ... for most attributes it is allowed but is stripped out
    ... some attributes don't allow it: enumerated values and
    boolean values
    ... but most other attributes do allow it

    heycam: we previously resolved that for presentation attributes
    we will use the CSS parser to parse the attributes
    ... so whitespace would be allowed in those ones

    ed: that's probably right but I don't think we have anything in
    the spec to say that
    ... and that wouldn't define what we do for numeric attributes

    <ed>
    [16]http://www.w3.org/html/wg/drafts/html/master/infrastructure
    .html#keywords-and-enumerated-attributes

      [16] 
http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#keywords-and-enumerated-attributes

    shepazu: what is an example of an enumerated attribute?
    ... why does HTML not allow whitespace for that?

    ed: I don't know
    ... if you follow the link above you'll find lots of parsing
    rules

    shepazu: for example, wouldn't stroke-linecap be an enumerated
    value?
    ... aren't most of our values enumerated?

    ed: the most frequently used are numerical

    heycam: stroke-linejoin would be enumerated but if we've
    decided they are parsed with the CSS parser then whitespace
    would be allowed

    krit_: could someone find out why whitespace is not allowed in
    HTML?

    ed: one example is the "dir" (bidi) attribute

    shepazu: on the whole I'd rather follow what HTML does but in
    this case that seems overly respective

    krit_: but there might be a good reason for that

    ed: one example is the "dir" (bidi) attribute

    <ed>
    [17]http://www.w3.org/html/wg/drafts/html/master/index.html#att
    ributes-1 - the list of html attributes and how they parse
    their value(s)

      [17] 
http://www.w3.org/html/wg/drafts/html/master/index.html#attributes-1

    heycam: I agree it seems strange that numbers allow whitespace
    but keywords wouldn't

    shepazu: at the same time, I'd rather defer to HTML
    ... not sure it's worth our deviating

    ed: it would be nice to use the exact same number parsers as
    the HTML ones
    ... unless we have a strong reason otherwise

    heycam: we don't have many attributes that only take a number,
    except some in filters
    ... I would be fine with not allowing whitespace for enumerated
    values in order to align with HTML

    ed: I think this came up from a bug report about one of the SVG
    attributes that takes a bunch of different values including a
    matrix
    ... sometimes it's easier to markup the content by adding extra
    whitespace
    ... might have been feConvolveMatrix|values ?

    heycam: for this attribute you need to allow whitespace to
    separate the values

    ed: but it's not defined if you allow whitespace at the
    start/end

    Tav: I like to line up values by adding spaces
    ... e.g. <rect width=" 50"... >, <rect width="150" ... >

    <ed> <feConvolveMatrix values=" 0 1 1 0 0 ... linebreak ...
    more values"/>

    heycam: I think attributes that are white-space separated, it
    should allow whitespace at the start and end

    Tav: that doesn't cover the width attribute
    ... and I think Firefox and Chrome don't allow that

    krit_: we've had bug reports about this
    ... for the opposite, making it more conformant to the spec

    heycam: apart from the enumerated types, any others in HTML
    that don't allow start/end whitespace

    ed: boolean
    ... don't think we have anything quite the same in SVG
    ... URLs in html attributes always allow surrounding whitespace

    heycam: that's tricky because URLs can contain space

    ed: if we want to allow HTML5, everything should allow
    whitespace except the enumerated values

    birtles: I think when I implemented animation I allowed
    whitespace before/after enumerated values because I think I was
    looking at XML whitespace normalization which said to do that

    heycam: I'd like to see a list of the attributes we have and
    see what kind of attributes we have

    <scribe> ACTION: ed to summarise the kinds of attributes we
    have and proposed handling of leading/trailing whitespace
    [recorded in
    [18]http://www.w3.org/2014/02/20-svg-minutes.html#action03]

    <trackbot> Created ACTION-3595 - Summarise the kinds of
    attributes we have and proposed handling of leading/trailing
    whitespace [on Erik Dahlström - due 2014-02-27].

paint-order

    krit_: I wrote a mail...
    ... I was looking at implementing it and came up with 3 issues,
    2 of which are resolved
    ... the remaining issue is the order of specifying key values

    <heycam>
    [19]http://lists.w3.org/Archives/Public/www-svg/2014Feb/0042.ht
    ml

      [19] http://lists.w3.org/Archives/Public/www-svg/2014Feb/0042.html

    krit_: right now it's stroke, fill, markers
    ... this is the opposite order of other properties we have
    ... I think this is confusing

    heycam: I find the background layer order confusing

    krit_: I don't disagree
    ... but I think we should be compatible
    ... not just background but also masking
    ... and fill and stroke

    heycam: all of those things are modeled after background layers

    krit_: I think they are comparable but...

    heycam: they do all specify things that need to get painted in
    a particular order
    ... do we have any other properties that define things that
    need to get painted

    ed: the filter property in filter effects
    ... it can take a list of filters and follows the order you
    specify it

    krit_: that's more chain order, but yes, there is inconsistency
    with other properties

    ed: my opinion is that the current order is fine, it's the most
    logical

    Tav: I agree

    nikos: I also agree

    krit_: then we need to note that this is the opposite order to
    background, and give an example too

    ed: but I don't see how they are connected... they don't relate
    to the background

    krit_: I meant the fill and stroke

    heycam: I agree with Erik that they are different enough
    things: paint-order and background layers
    ... so we don't need to use the same ordering
    ... so since the current ordering, left-to-right, is more
    sensible, we should keep that
    ... krit_, what do you think?

    krit_: I don't think there needs to be a consensus... if there
    is a majority
    ... I guess I can live with it

    RESOLUTION: Keep the current order of paint-order even though
    it is different to background layers

    krit_: with regards to implementing features
    ... how can implementations move forward if the specification
    of SVG2 does not

    heycam: I would be fine with bringing up features in telcon
    meetings
    ... to see if people think a given feature is mature and if its
    ok to ship it
    ... I don't think we have to wait for the whole spec to reach
    CR before shipping any of it
    ... we don't need a formal consensus, but informally seeing if
    there any objections should be enough

    krit_: what if the feature still has issues

    heycam: if there are issues in the spec that affect the
    behavior of the feature
    ... I would expect people to take that into account when
    deciding if they should ship something
    ... I think we should rely on people acting in good faith when
    they decide if they should ship something or not

    shepazu: especially since we can't enforce this process anyway

    heycam: I don't think we've seen examples of SVG2 features
    being shipped prematurely yet
    ... if people want to ship features, bring them up in a telcon
    and get a feel for what other people think
    ... were you ok with the other issues in that thread about
    future-proofing?

    krit_: I think I'm ok with that

    Tav: I'd be interested in knowing what parts of SVG2 people are
    working on

    heycam: yeah, that would be interesting to know
    ... I implemented some small stuff, started working on markers
    but then moved on

    krit_: for me its filters, transforms

    <krit_> masking

    RRSAgent: make minutes

Summary of Action Items

    [NEW] ACTION: ed to summarise the kinds of attributes we have
    and proposed handling of leading/trailing whitespace [recorded
    in [20]http://www.w3.org/2014/02/20-svg-minutes.html#action03]
    [NEW] ACTION: ed to update the spec to clarify behavior of
    references to elements when they are removed/added from the
    document [recorded in
    [21]http://www.w3.org/2014/02/20-svg-minutes.html#action02]
    [NEW] ACTION: update the spec to clarify behavior of references
    to elements when they are removed/added from the document
    [recorded in
    [22]http://www.w3.org/2014/02/20-svg-minutes.html#action01]

    [End of minutes]

Received on Thursday, 20 February 2014 22:56:58 UTC