Minutes SVG F2F Seattle 2014 Day 2



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

                                - DRAFT -

                        SVG F2F Seattle 2014 Day 2

31 Jan 2014


       [2] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2014/Agenda

    See also: [3]IRC log

       [3] http://www.w3.org/2014/01/31-svg-irc


           Thomas, Chris, Cameron, Brian, Doug, Rossen, Dirk, Rik,
           Satoru, Sylvain, Erik, Tav


           Brian, Cameron


      * [4]Topics
          1. [5]animation of values with different types
          2. [6]Allowing CSS outline and background on SVG elements
          3. [7]use cases for technical diagrams
          4. [8]intrinsic sizing of SVG
          5. [9]Deprecating/redefining symbol element
          6. [10]pointer events and background colors
          7. [11]non-scaling objects
          8. [12]Shadow DOM in SVG
          9. [13]getClippedBBox()
         10. [14]Illustrator output
         11. [15]RelaxNG schema validation
         12. [16]Publishing another WD of SVG 2
         13. [17]SVG selection
      * [18]Summary of Action Items

    <birtles> scribenick: birtles

    <scribe> scribe: Brian

animation of values with different types

    ed: I added this because someone wrote a blog about
    inconsistencies about animation



    krit: the problem is the attribute should be animated as
    SVGAnimatedNumber but percentages are also allowed by the
    attribute syntax

    <heycam> ScribeNick: heycam

    <scribe> Scribe: Cameron

    birtles: I think we can make it more clear that when it says
    "attribute type", that refers to the datatype of the attribute,
    not the IDL type
    ... it doesn't mean SVGAnimatedNumber, it means the datatype,
    which is either number or percent I think

    krit: in Blink/WebKit, we really take the object,
    SVGAnimatedWhatever, and animate this type

    birtles: I don't think that's right

    krit: I think the spec implies that

    birtles: CSS Animations/Transitions is clearer about this
    ... it says "animate this as length or percentage"
    ... that's the intent of SVG, but it's not as clear as it could
    ... we should fix this, in Web Animations
    ... as for the DOM, that's up to Cameron

    krit: it's the same with animations of transforms
    ... in the past if you had <animate attributeName="transform">
    then you can't say from="translate(...0)"

    birtles: animate attributeName="transform" in general is never
    possible, since the transform attribute was never animatable
    with <animate>

    krit: it is now

    birtles: yes, but SVG doesn't define that

    krit: we have the same problem with filters
    ... you can give a list of filters, but the type would be
    ... according to the SVG animation model
    ... you want the CSS interpolation

    ChrisL: I think at the time, when SVG was using SMIL, each
    datatype needed its own definition for interpolation
    ... they were really looking on the syntax level, and if they
    didn't match you couldn't interpolate between them

    birtles: it leaves you with interesting things like you can't
    do <setTransform> e.g.
    ... which is frustrating
    ... shouldn't have made different elements for for different
    ... but I understand the history

    ChrisL: also it had a lot less developer input at that time
    ... it was mostly input from a few SMIL player people

    birtles: so this will get fixed with Web Animations anyway, so
    no specific actions needed here
    ... I posted a comment on the blog post and it hasn't appeared

    shepazu: in general your approach with animation, all the
    features apart from animateColor are going to be possible with
    Web Animations?

    birtles: yes
    ... we map what we've already defined in SVG onto the
    primitives we're defining in Web Animations

    <birtles> scribenick: birtles

Allowing CSS outline and background on SVG elements

    shepazu: previously we talked about various use cases
    ... for having an outline
    ... I don't think anyone thinks those use cases don't exist
    ... I think we had consensus on the use case for outline for
    hover etc.
    ... we want to be able to allow the outline property on SVG
    ... so that you can have :hover and the outline will hover
    ... one assumes it is the bounding box of the element

    krit: SVG does not disallow the outline property and CSS does
    not restrict it to HTML therefore it applies to SVG

    shepazu: but we haven't defined what is means for SVG

    heycam: there are lots of properties like that but we need to
    define which box

    shepazu: since we don't have a box model it doesn't just fall
    out of the model

    Rossen_f2f: text-wrapping is a pain
    ... how does the box model apply to SVG?

    shepazu: it doesn't, but for things like outline the question
    is do we want to allow the padding property?
    ... in this case it would simply increase the size of the
    ... but would not affect text-wrapping at all

    heycam: it wouldn't be difficult

    Rossen_f2f: have you looked at shape-margin, shape-padding

    shepazu: I haven't, we might do that instead

    heycam: they are for text in non-rectangular shapes

    Rossen_f2f: it applies to an element and an element's shape
    ... it is meant for mapping the meaning of margin/padding in
    CSS to non-rectangular shapes

    heycam: what happens when you apply it to a rectangular shape
    ... what is the difference between margin/padding

    Rossen_f2f: one difference is you can only specify one value
    ... since you don't have four sides
    ... so it is meant to follow stroking rather than boxes
    ... if you have a 10px margin and it is a shape that has
    corners then it will round those corners

    shepazu: let's consider that for the future, but not for now
    ... use case: we have a shape and you want to add an outline on
    mouse over
    ... this already works since outline applies to all elements
    ... can we agree that it uses the bounding box of the element?

    krit: which bounding box?

    shepazu: the one we discussed yesterday (stroke bounding box,
    decorated bounding box, whatever we call it)
    ... the same one for filters, masking etc.
    ... I just think we align it to some pre-existing definition of
    a bounding box

    krit: we decided already filters, masking, and clipping do not
    affect outline
    ... so the problem is that the CSSWG defines it as: draw shape,
    stroke, fill, then filters, then mask/clip
    ... then if you clip an element outline will be clipped away
    ... on HTML it is based on the current rendering model that
    browsers implement

    ChrisL: the default clip is going to always clip away the

    heycam: is that right, if you have overflow:auto?

    krit: the default is auto where you don't clip

    shepazu: can we resolve we'll have outline and the outline will
    resolve to whatever bounding box we deem is appropriate
    ... of the ones we discussed yesterday
    ... one of the characteristics of outline is that it doesn't
    affect the box model


    RESOLUTION: outline will resolve to our definition of stroke
    bounding box

    shepazu: the second issue is, can we have the background
    property apply as well
    ... this would resolve to exactly the same area, it would just
    be the background
    ... it also apply to elements
    ... in terms of performance characteristics it is the same as
    ... it is the same area
    ... we have already resolved to have a viewport-fill using

    heycam: on the outer SVG element it would cover the whole
    viewport but for inner SVG it would cover the bounding box area
    ... since we decided not to do viewport-fill but just to
    support background

    shepazu: how do we feel about having background apply to SVG

    heycam: I think it's fine

    krit: I don't see the value in the extra work
    ... I think it slows down implementations
    ... I don't think the use case is strong enough

    heycam: I think it's useful for text

    Rossen_f2f: what will the background be clipped to?

    shepazu: the same as outline

    Rossen_f2f: so if I have a path, what will be filled?
    ... the area around the path?

    <Tavmjong> SVG 2 Text currently refers to a "content area" that
    is the same as defined in CSS.

    shepazu: yes

    RRSAgent: what is the use case for that?

    Rossen_f2f: what is the use case for that?
    ... outlines are not hit-testable
    ... but background is
    ... and background is often used for hit-testing

    shepazu: that is another use case where you use the background
    to enlarge the hit-test region

    heycam: we already solved this with pointer-events: bounding

    shepazu: we could also say that background in SVG is not
    ... it's simply visual, not hit-testable

    heycam: that would be ok with me

    Rossen_f2f: so you mean background images etc?

    shepazu: no, not images

    Rossen_f2f: why not?

    shepazu: the use case is having a visual indicator that
    something is in focus which applies to both outline and

    Rossen_f2f: in order to get around this, if all you need is
    selection, can't you specify your outline to have fill or
    ... that way if you specify this fill, it fills in this area
    ... you're specifying an outline and you want to indicate that
    something is selected

    shepazu: how is that different to background

    Rossen_f2f: it doesn't open the door to everything else that is
    in background
    ... which is very complicated

    heycam: why shouldn't you be able to use backgrounds like

    krit: when you do that you have to work out sizing

    heycam: once we work out the size of the box, that is solved

    shepazu: I have heard many times from developers that they
    expected to be able to set the background on SVG elements
    ... right now if you want to have this effect you compose it
    yourself using rect
    ... if you want to have something highlightable you need
    transform a container group

    ed: I've heard the same but only for text and elements that
    establish viewports

    shepazu: personally, I've done this many times

    Thomas: we've used this many times
    ... you mouse over something and a background box highlights
    ... we do this manually using javascript
    ... it would be so much easier if it was directly supported

    shepazu: and it would also be more intuitive to people who are
    used to CSS

    birtles: does the shape you highlight correspond to the
    bounding box of the text

    Thomas: we actually generate the box from some data mining
    software... the box might actually be slightly larger than the
    text bounding box

    krit: is the shape always rectangular?

    Thomas: it often is

    shepazu: I'm just looking for the simplest possible thing that
    makes sense to developers

    krit: I'd like to see the concrete use case

    Rossen_f2f: I understand the use case but I'm not sure if this
    is the right approach

    <Tavmjong> We are moving to CSS based text layout. Hasn't CSS
    already figured this out?

    krit: do you use something other than a color for highlighting?

    Thomas: generally it's a solid color but I could see people
    using gradients

    heycam: if we are going to restrict it to color, then we should
    be able to expand it to other paints later

    ChrisL: this is how we ended up with viewport-fill, so we could
    expand it later

    shepazu: I don't think the use case supports having images
    ... since it's about highlighting things
    ... but perhaps they could have a subtle stippled image

    krit: if it is background-color, this doesn't allow lists of

    shepazu: I think we should support background but only support

    heycam: I think we should specifically just support
    background-color and then later we can support background if
    ... then people don't use background to mean only

    Rossen_f2f: if we support background only, the shorthand, then
    we have to support everything in background

    shepazu: I would be happy with background-color

    heycam: my argument against outline-fill is that it's hard to
    extend later

    shepazu: I also don't think we should add a property
    ... the other thing to talk about is hit-testing

    heycam: whether the background is hit-testable or not?
    ... with pointer-events: auto?

    shepazu: we could say that background is not hit-testable in

    Rossen_f2f: in the previous use case where the outline is used
    to indicated that the shape has been hit-testable
    ... the background you use to indicate that it has been
    hit-tested also changes what gets hit-tested

    ed: I wanted to mention the difference between the outline and
    the background box
    ... I expect the outline to be axis-aligned but not the
    ... for example, if you transform some text

    heycam: you can achieve that effect

    <heycam> <g transform="..."><text>...</text></g>

    <heycam> g:hover { outline: ... }

    <heycam> g:hover text { background-color: ... }

    shepazu: another use case is when something is selected by
    keyboard etc.

    krit: my question is what happens if you apply a clip path
    ... in the HTML world the background would be clipped
    ... do you want the background to be clipped here as well?

    shepazu: it should match CSS

    krit: so it would be clipped

    heycam: in that case you'd need a containing group to stop the
    background from being clipped

    shepazu: is background-color hit-testable in CSS?

    Rossen_f2f: yes

    heycam: the box is hit-testable

    Rossen_f2f: if the background is transparent it didn't used to
    be hit-testable

    heycam: is that right? now that we have pointer-events?
    ... in CSS if the background is transparent, the box is still
    hit-testable these days

    shepazu: (draws some shapes with boxes around them)
    ... suppose the backgrounds have alpha
    ... where does it stack

    everyone: with the element

    shepazu: how does it blend? is it a problem?

    (generally seems to be ok)

    krit: we still didn't clarify hit-testing
    ... or padding

    shepazu: I think hit-testing is characteristic of the box and
    not the background
    ... we should decide that later

    krit: for the highlighting use case you don't want backgrounds
    to be hit-testable

    shepazu: we can solve that later

    krit: do we want padding??

    heycam: I think we do, particularly for Thomas' use cases

    shepazu: you could solve that with a background and thick
    outline of the same color
    ... so we don't *have* to have padding

    heycam: I think that's problematic if rendering is not
    pixel-aligned since you'll get seams

    shepazu: so do we want shape-padding or regular padding

    heycam: I think it's better to have padding if we're talking
    about a box

    shepazu: I think it makes most sense to allow padding

    krit: padding would also affect outline

    shepazu: yes

    krit: what about border?

    heycam: we can live without that

    shepazu: what about outline-radius?

    Rossen_f2f: there's no outline-radius

    heycam: interestingly, it's border radius that controls the
    rounding of the background

    shepazu: let's boil this lobster

    krit: how does padding work for outer SVG?

    shepazu: we special case that

    RESOLUTION: add outline, background-color, and padding to SVG2
    with hit-testing to be determined later

    <heycam> -- 15 minute break --

    <cabanier> scribenick: cabanier

use cases for technical diagrams



    Smailus: here's a pdf
    ... there's a paper in there that contains features that we
    think is important

    heycam: cgm vs SVG?

    Smailus: yes
    ... the text has to fill the space between the wires
    ... ... the author generates a diagram and it's important that
    it looks the same everywhere
    ... ... so stylesheets should not affect

    shepazu: how important is that?

    Smailus: it's not that is important
    ... if the diagram looks different, that is very bad
    ... there can be font differences
    ... we have ataa and faa requirements
    ... ... we have outstanding issues with non-scaling patterns
    and dashse
    ... ... if you zoom out, it would be very busy
    ... ... when you see the diagram as a whole, the user has to
    zoom in
    ... ... the author makes it with certain patterns, you want the
    line thickness to stay the same
    ... ... right not the lines get thicker which is a problem
    ... the paper talks about the issues
    ... line types and line styles are problems
    ... it would be easier if there was a table of line styles

    shepazu: you could do that with a class
    ... what's a line style?

    Smailus: dash patterns, diamond

    shepazu: are these predefined or conventions?

    Smailus: I think they are conventions

    shepazu: it would be useful to know that


      [21] http://www.cgmopen.org/technical/cgm-svg-20030508-2.htm

    Smailus: the paper talks about this

    Rossen_f2f: wrt non-scaling pattern. do you have requirements
    for corners?

    Smailus: CGM has this and some people use that

    Rossen_f2f: so it has meaning in the diagram?

    Smailus: yes, whitespace at the corner could be confusing




      [23] http://lists.w3.org/Archives/Public/www-svg/2013Jan/0009.html

    ChrisL: is there an iso standard for the dashing or is it for

    Smailus: I will look that up
    ... size matters too for us
    ... it's important to keep it as small as possible
    ... but not as important as it was in the past

    shepazu: one of the things they do, is that they generate the
    bounding box at document creation time
    ... so having this will reduce the filesize dramatically

    Smailus: yes, at authoring time, we put a transparent rectangle
    at the front
    ... similarly for wires

    shepazu: so this could change the authoring tools?

    Smailus: yes
    ... preserving authoring intent is key

    <ChrisL> catia-authored cgm

    shepazu: could SVG replace CGM?

    <heycam> [24]https://en.wikipedia.org/wiki/CATIA

      [24] https://en.wikipedia.org/wiki/CATIA

    smailus: maybe eventually

    Rossen_f2f: corner preservation is important?

    smailus: people have told me that it sometimes matters. unsure
    how big of a deal it is?

    krit: do you want the dash array to be always the same when you
    zoom in/out?

    smailus: I don't think that really matters

    krit: is zooming perserving aspect ratio

    smailus: yes
    ... non-scaling lines would stay the same

    ChrisL: the paper that is referenced here, is the second
    ... one of the particular things he picks, is bitonal images
    ... SVG only has png and jpeg
    ... his article uses an illustrator svg file that encodes a pdf
    file in the metadata

    <ChrisL> base64 data uri 16,613 iv-base64.txt

    <ChrisL> data uri compressed 12,623 iv-base64.txt.gz

    <ChrisL> original png 15,228 Saito_bwStucki.png

    <ChrisL> optimised png 12,438 Saito_bwStucki-iv.png

    <ChrisL> svg with data uri 16,759 svg-iv-base64.svg

    <ChrisL> svg compressed 12,746 svg-iv-base64.svgz

    ChrisL: I redid the file so it just contains the svg data

    shepazu: what should we be looking for?

    ChrisL: the optimized png is 12.6 k and the svg is 12k

    Smailus: in our diagrams we have switches that have a hot spot
    ... you can click on parts or the whole

    heycam: hierarchical regions?

    smailus: yes

    shepazu: in that case, you'd still use a rect as a hotspot

    smailus: in that case, we would probably use that all the time

    <ChrisL> the cad generation and the hotspot addition are done
    at separate stages in the workflow, typically

    smailus: the artwork is spread over the artwork and the hotspot
    ... often the artwork is sorted for plotting (arcs that are

    shepazu: you could do rectangles in certain area but for text
    you could relay on the SVG

    heycam: have you looked at hatch fills that Tav proposed?

    smailus: no

    heycam: not sure if they're non-scaling

    <ChrisL> [25]http://www.w3.org/TR/SVG2/pservers.html#Hatches

      [25] http://www.w3.org/TR/SVG2/pservers.html#Hatches

    Tavmjong: I assume that we'd eventually do that

    krit: what about if the aspect ration changes?

    heycam: not sure yet. Maybe we don't have to care about that

    <ChrisL> also, svg2 has non-scaling stroke

      [26] http://www.w3.org/TR/SVG2/painting.html#NonScalingStroke

    krit: what if you use percentages?
    ... if you do, the viewport is not square and is difficult to
    ... but this is only an issue for relative lengths

    <scribe> ACTION: smailus to break his presentation out into
    specific issues that need to be addressed and take it to the
    mailing list [recorded in

    <trackbot> Created ACTION-3572 - Break his presentation out
    into specific issues that need to be addressed and take it to
    the mailing list [on Thomas Smailus - due 2014-02-07].

    <scribe> ACTION: ChrisL to work with Smailus to create examples
    of the issues [recorded in

    <trackbot> Created ACTION-3573 - Work with smailus to create
    examples of the issues [on Chris Lilley - due 2014-02-07].

intrinsic sizing of SVG

    ed: responsize images and svg
    ... auto width and height gives you the size you need
    ... it's issue 3 on the wiki page


      [29] https://www.w3.org/Graphics/SVG/WG/wiki/Intrinsic_Sizing

    <krit> <svg width="200px" height="200px" style="width: 300px;
    height: 300px;" viewBox="0 0 250 250">

    krit: there are different opinions. maybe we want to do it like
    ... widht and height properties and attributes control
    resolution and size

    heycam: do you know if this is only for inline out svg?

    <ed> <svg width="50%" viewBox="0 0 100 100">

    <ed> <rect width="100" height="100" fill="blue"/>

    <ed> </svg>

    krit: webkit does presentational attribute mapping (sort of)

    heycam: we define that the intrinsic aspect ration comes from
    the viewbox?

    ed: I believe so

    <ed> [30]http://jsfiddle.net/M445V/

      [30] http://jsfiddle.net/M445V/

    krit: (drawing diagram)

    heycam: it seems webkit's interpretation makes more sense

    <ed> <div style="width: 100px; height: 100px">

    <ed> <svg style="background:blue"></svg>

    <ed> </div>

    <ed> [31]http://jsfiddle.net/3dy9U/

      [31] http://jsfiddle.net/3dy9U/

    ed: I pasted a fiddle in

    krit: IE and firefox seem to agree
    ... [32]http://jsfiddle.net/M445V/1/
    ... firefox doesn't scale height

      [32] http://jsfiddle.net/M445V/1/

    <birtles> there's a long discussion about this:

      [33] https://bugzilla.mozilla.org/show_bug.cgi?id=668163

    <ed> another long discussion here:

      [34] https://code.google.com/p/chromium/issues/detail?id=308992

    heycam: we had a bug with bing maps

    krit: with/height: 100% seems to make a different for firefox
    ... we can say that if you leave them off, it should go to 100%

    heycam: what we want to say, if the presentation is there it
    maps to the style property.
    ... but if it's not, it's treated as auto

    krit: I suggest that auto is 300/150
    ... I think we need more tests

    ed: we have a lot of tests

    krit: IE used to have strange behavior in the case there was
    ... I suggest we follow IE (and webkit)
    ... what happens if there's a div with no sizing

    Rossen_f2f: in CSS, auto goes to 150
    ... if the containing block has a resolvable height, we use

    <birtles> the reason we wanted not to map default values for
    width/height to style is: "The fact that our old behavior did
    apply to such default values was one of the most confusing
    things about using SVG in HTML -- for example, SVG elements
    that *do* have a viewBox used to have that viewBox's intrinsic
    ratio ignored when they were inside a container with a fixed

    <birtles> height (such that percentage heights were
    meaningful), but the intrinsic ratio was honored if they were
    in an auto-height container."

    <birtles> it seems like webkit/blink don't face this issue
    because % heights are resolved against the document viewport
    (unlike a div with % height) according to David Vest:

      [35] http://lists.w3.org/Archives/Public/www-svg/2013Dec/0095.html

    heycam: [36]http://jsfiddle.net/M445V/4/

      [36] http://jsfiddle.net/M445V/4/

    krit: webkit is not looking at the containing block
    ... it seems IE is the most reasonable

    Rossen_f2f: 10.3.2

    <ed> (the numbers refer to CSS 2.1 sections, right?)

    Rossen_f2f: if the width is not specified, it should go to
    auto. What is auto on an SVG element with display: block
    ... if we follow SVG as a replaced element, 10.3.4 it should go
    to intrinsic
    ... but we are computing as non-replaced
    ... BUT if you require a shrink-to-fit such as a float, then we
    use 300 by 150
    ... is SVG replaced element?

    heycam: is image replaced?


    krit: x/y/width/height should be presentation attributes

    heycam: sure

    resolution: width and height attributes are presentation on the
    svg element

    heycam: I would like to see what the issue was

    <scribe> ACTION: heycam to investigate why firefox needs to
    treat SVG as a replaced element [recorded in

    <trackbot> Created ACTION-3574 - Investigate why firefox needs
    to treat svg as a replaced element [on Cameron McCormack - due

    <scribe> ACTION: ed to create inline SVG sizing tests [recorded
    in [38]http://www.w3.org/2014/01/31-svg-minutes.html#action04]

    <trackbot> Created ACTION-3575 - Create inline svg sizing tests
    [on Erik Dahlström - due 2014-02-07].

    <scribe> ACTION: krit to make width and height attributes
    presentation attributes on the svg element [recorded in

    <trackbot> Created ACTION-3576 - Make width and height
    attributes presentation attributes on the svg element [on Dirk
    Schulze - due 2014-02-07].

Deprecating/redefining symbol element

    heycam: shepazu do you have ideas?

    <Tavmjong> [40]http://tavmjong.free.fr/SVG/SYMBOL/symbol.html

      [40] http://tavmjong.free.fr/SVG/SYMBOL/symbol.html

    Tavmjong: I would be against this
    ... it was mentioned that browsers were not ignoring this. but
    that seems not to be the case
    ... I didn't check chrome or ie
    ... but all others did
    ... it is used quite a bit, especially Illustrator
    ... Andreas is also against removal
    ... inkscape uses it to populate a dialog

    shepazu: I think you misunderstood
    ... I was saying that Symbol should be defined as a special
    case of the SVG root

    Tavmjong: I thought you wanted to deprecate the symbol element

    shepazu: I take deprecation back.
    ... they are not defined as being non-displayed SVG roots

    Tavmjong: according to ???, what is missing is alignment
    ... markers have that possibility. Symbols don't

    shepazu: we should define marker and symbol the same way
    ... a marker should behave like a nested svg root
    ... so there's only 1 model that developers and browsers have
    to understand

    heycam: we already allude that they are similar

    krit: I have nothing against it but don't see the improvement

    Tavmjong: markers also have an orientation

    shepazu: I would like to see in the spec, "these are the
    differences between markers and symbols"

    Tavmjong: they are in different sections

    shepazu: let's go over that in the coming week

    resolution: we will not deprecate symbol and make it clear in
    the spec what their differences and similarities are.
    ... we will not deprecate symbol and make it clear in the spec
    what their differences and similarities are.
    ... feature freeze for SVG in june and last call in January

    <heycam> -- lunch time --

    <heycam> Scribe: Cameron

    <heycam> ScribeNick: heycam

pointer events and background colors

    krit: I just want to make sure the default behaviour is always

    shepazu: what's reasonable?

    krit: background-color:transparent should not influence hit
    ... but if it has a color, it would be strange by default if it
    doesn't affect hit testing

    ChrisL: if you're not doing hit testing you can't do :hover

    shepazu: you can, you just have to change pointer-events

    birtles: Rossen had a point, that if you have a background that
    is transparent, and therefore not getting hit testing, and you
    mouse over and fill it in, it's unusual for it then become hit
    ... so I think it makes more sense to never hit test, but you
    can still use pointer-events:bounding-box

    krit: ok

    RESOLUTION: background-color on SVG elements will never
    influence hit testing area

    krit: I suggest we look at CSS UI to see if there are other
    keywords to use for pointer-events


      [41] http://www.w3.org/wiki/User:Tantekelik/pointer-events

    krit: the only difference there is the new 'auto' value

    heycam: so you're proposing a new 'background' keyword for

    krit: yeah we could have that
    ... it would mean the background area

    heycam: is that different from bounding-box?

    krit: yes because it does not include padding

    heycam: so getBBox() would return the plain geometry bounding
    box, and we could use the other version of getBBox() that takes
    a dictionary to select which parts to include

    krit: yes
    ... we need to decide effectively what the content box

    shepazu: I think it should be the stroked bbox
    ... actually the decorated bounding box

    heycam: so including markers

    RESOLUTION: The effective content box of an SVG element is the
    decorated bounding box.

    <scribe> ACTION: Doug to make background-color, padding-*,
    outline-* apply to SVG elements. [recorded in

    <trackbot> Created ACTION-3577 - Make background-color,
    padding-*, outline-* apply to svg elements. [on Doug Schepers -
    due 2014-02-07].

non-scaling objects


      [43] http://svg2.mbsrv.net/devinfo/devstd/non-scaling-objects-2/

    stakagi: this is an issue that came up in 2011
    ... I tried to standardise non-scaling features for SVG 2
    ... I've found that SVG Tiny 1.2 has such a feature, ref(svg)
    ... based on this specification, SVG 2 should have such
    ... but I found issues, listed in that document
    ... one is that is somewhat difficult and has a special
    ... other is that it doesn't consider nested documents

    ChrisL: I don't think the restriction to non-nested documents
    is inherent in the feature, but SVG Tiny 1.2 doesn't support
    nested documents

    stakagi: the issue with nested documents is described in the
    last section "Fixed object for nested documents" on that page
    ... this section shows that non-scaling characteristics will be
    transmuted when nested document embedding is performed

    shepazu: does this account for all transforms, including those
    that are in CSS?

    stakagi: yes

    shepazu: what about 3D transforms?

    ChrisL: no, you'd need to change the formulae here to take into
    account 3D

    shepazu: does it need to?

    ChrisL: I don't see 3D being used here, it's more for local 3D
    inclusions in a 2D world

    shepazu: what does this do for zoom?
    ... is that defined as a transform?

    ChrisL: you do all your transforms up to the root, then an
    additional one for the zoom, that's where it comes in

    shepazu: I think it should take into account zooming, though
    not necessarily panning

    birtles: that page does talk about using the CTM for zooming
    ... the very last point it mentions browser chrome
    transformations, which further touches on zoom

    shepazu: is this the syntax we want?
    ... instead of doing vector-effects="...", a CSS property that
    says non-scaling with parameters to that?

    heycam: either is better than ref(svg)

    ed: yes ref(svg) made it hard to integrate with CSS Transforms

    shepazu: I would expect this to be a CSS property

    birtles: vector-effect is a CSS property

    ChrisL: people like non-scaling-stroke keyword
    ... I'm not seeing traction for vector effects more broadly

    shepazu: if we promoted more it would, but that's another

    heycam: I don't think I'd like vector-effect being used for
    non-scaling stroke and then a separate property for non-scaling
    other things

    shepazu: maybe "non-scaling" as the property name

    <birtles> scaling="fixed-stroke fixed-coordinate"

    stakagi: [translated from brian] normally with the
    transform:ref you only have one CTM, but in the case of nested
    documents, where you can nest to any depth, you can have a
    whole series of CTMs which stack up
    ... for that case, you'd need a different property value

    heycam: so "stop at the current document" or "go all the way"?

    stakagi: yes

    ChrisL: the "ref" bit means to walk up to where I'm
    referencing, so skip up to the specified element

    birtles: there's no way of indicating of the reference with
    this syntax
    ... four property values in this proposal

    ChrisL: one you can give numerical values
    ... one you can point to an ID
    ... one you can count <svg>s from the root, if you know you're
    nested 5 times
    ... (you could say to skip 2 of them)
    ... (and the default would be 1)

    shepazu: I'm uneasy about the syntax for saying how many levels
    to go up
    ... maybe I'm misunderstanding; which transformation contexts
    it's skipping is at the nested <svg> barrier
    ... I think one nesting barrier or all is probably as much as
    you need
    ... by default it might be only the current nesting context,
    and the other value would be all nesting contexts
    ... maybe in the case of widgets...

    ChrisL: my concern is composability
    ... if you take an existing application that uses
    non-transform-up-to-the-root, and you embed that somehwere, now
    your widget could break

    shepazu: I don't disagree, I don't see in practice people doing
    ... I suggest we keep it simple, so one context or all

    ChrisL: I think the composability is important

    shepazu: so one place I use that kind of composability is
    presentation slides
    ... I'll use levels of nested SVGs there
    ... I'm trying to think of a case where I'd want non-scaling
    whatever that is only within a certain context; I'm not
    thinking of one

    heycam: [describes an example]

    shepazu: it seems brittle to describe it in terms of levels

    heycam: I agree

    ChrisL: IDs would be easier

    heycam: I think I'd rather solve the number-of-levels issue
    later if we need to, but keep it simple to start

    <ChrisL> so it should aleways refer to the rootmost svg element

    birtles: to clarify the four different keywords from the
    proposal document
    ... the additional-fixed-coordinates corresponds to
    ref(svg,100,100) ; that's for example for an icon on the map,
    which can change its location, its translation, but not its
    ... whereas fixed-coordinates means that it stays at the same
    position; for example for a UI for the map
    ... then what is it relative to? the coordinate space of the
    root of the document, but then the final two keywords,
    additional-fixed-coordinates-root and fixed-coordinates-root,
    are the coordinate system of the "browser" so to speak

    ChrisL: I understand the four things now, but maybe the names
    could be improved

    birtles: you want the property values to be like "fixed-scale",
    "fixed-position", ...

    ChrisL: since you have two types of things, one that can move
    its position and one not, the "no-pan" thing included the no

    shepazu: you could have separate keywords

    <ChrisL> nopan-root nopan-viewport noscale-root

    thomas: does that take into account rotation too?
    ... your map legend might not want to rotate when you rotate
    your map contents

    shepazu: my current thinking is to say a single property,
    whatever it's named -- maybe transform-limit -- and a bunch of
    parameters to say which things you're limit
    ... the auto value is no transform limit
    ... among them would be no-rotate, no-scale-stroke, no-scale,
    ... and then there are the scoping things

    ChrisL: those, followed by either a keyword that means viewport
    or root element, with an initial value that would mean

    stakagi: I'm not fussed about syntax
    ... regarding no-rotate, previous SVG's transform(ref) couldn't
    do that, so I didn't consider it
    ... but might be convenient, provided the math isn't convenient

    thorton: with a compass rose, you want that to rotate, but the
    map legend not to rotate

    stakagi: I'm looking for permission to write up the stuff from
    SVG Tiny 1.2 in a better syntax for SVG 2, mostly concerned
    about bringing across the current functionality

    birtles: I think if there are parts that are difficult to
    specify, like math for no-rotate, he might like to defer that
    ... but at least he wants to cover the two cases for

    stakagi: if someone wants to think about it I'm happy for you
    to do so

    shepazu: to get started, let's accept accept Takagi-san's
    proposal, he puts it into the spec, and we go from there

    RESOLUTION: We will accept the new transform(ref) proposal but
    with different syntax for SVG 2.

    <scribe> ACTION: stakagi to add the new transform(ref)
    functionality to SVG 2 [recorded in

    <trackbot> Created ACTION-3578 - Add the new transform(ref)
    functionality to svg 2 [on Satoru Takagi - due 2014-02-07].

    birtles: we mentioned non-scaling hatching
    ... we'd address that with the same property?

    ChrisL: I think we need to look at that

    shepazu: the flip invariant text could be handled here too

    heycam: yeah, a new value to snap non-rotation to 90 degrees?

    <ed> don't see why we should necessarily restrict it to n*90
    degrees, let it be author controlled

    ISSUE: Consider allowing non-rotation, non-scaling/rotation of
    fill hatch/pattern options to the new non-transform

    <trackbot> Created ISSUE-2453 - Consider allowing non-rotation,
    non-scaling/rotation of fill hatch/pattern options to the new
    non-transform functionality. Please complete additional details

      [45] http://www.w3.org/Graphics/SVG/WG/track/issues/2453/edit%3E.

    ISSUE-2453: Also non-scaling rotation of stroke (in case it
    includes a hatch pattern too).

    <trackbot> Notes added to ISSUE-2453 Consider allowing
    non-rotation, non-scaling/rotation of fill hatch/pattern
    options to the new non-transform functionality.

Shadow DOM in SVG

    krit: the shadow tree has things where you can isolate style
    ... and you can explicitly inherit style into the tree
    ... is that something we care about for the <use> element?

    ed: I guess
    ... if it's something you can control
    ... one part that was requested was to add <shadow> to SVG


      [46] http://lists.w3.org/Archives/Public/www-svg/2014Jan/0018.html

    <ed> [47]http://www.w3.org/TR/shadow-dom/#shadow-element

      [47] http://www.w3.org/TR/shadow-dom/#shadow-element

    heycam: this is pdr's review of web components for SVG
    ... seems like it makes sense to allow <shadow> in SVG as he

    krit: what about removing the instance tree?

    ed: everyone on the mailing list agreed but we haven't resolved
    ... so that would be removing SVGElementInstance etc.

    krit: groups within Adobe would like to extend the instance
    tree rather than removing it

    heycam: I think knowing the correspondence between template and
    shadow tree elements isn't critical
    ... you can work it out yourself if you need

    krit: I think most people agreed about the removal of the SVG
    instance tree

    RESOLUTION: SVG 2 will remove the SVG instance tree for <use>.

    krit: next is basing <use> on the Shadow DOM
    ... which is now in CR, or at least LC

    cabanier: so if it's a shadow tree you have a copy per instance

    ChrisL: yes

    shepazu: if I have a <use> element, and I change the thing it
    refers to, does it no longer update?

    cabanier: yes

    heycam: but I think maybe we want to keep the auto-updating

    krit: that is how Blink implements <use> in terms of shadow
    ... updates to the original cause the tree to get recreated

    heycam: that's how it works internally in Firefox now anyway

    [discussion of allowing inherited styles into shadow trees]

    RESOLUTION: SVG 2 will base <use> on shadow tree spec.

    heycam: pdr's first point in his mail, is that about the HTML

    ed: there are two things defined in Shadow DOM
    ... <shadow> and <content>
    ... they're both inheriting from HTMLElement

    krit: should they inherit from Element so we can use it?

    heycam: not sure about that.
    ... don't want to lose all the HTMLElement things in HTML

    <ed> [48]http://w3c.github.io/webcomponents/spec/shadow/

      [48] http://w3c.github.io/webcomponents/spec/shadow/


      [49] http://w3c.github.io/webcomponents/spec/shadow/#content-element


      [50] http://w3c.github.io/webcomponents/spec/shadow/#shadow-element

    <scribe> ACTION: Erik to ask somebody what to do about
    content/shadow inheriting from HTMLElement [recorded in

    <trackbot> Created ACTION-3579 - Ask somebody what to do about
    content/shadow inheriting from htmlelement [on Erik Dahlström -
    due 2014-02-07].

    ACTION-3413 is cyril's action to make <use> use Shadow DOM


    <trackbot> ACTION-3413 -- Cyril Concolato to Investigate
    describing use in terms of the shadow DOM -- due 2013-02-10 --


      [52] http://www.w3.org/Graphics/SVG/WG/track/actions/3413

    <scribe> ACTION: Erik to remove <use> element instance tree.
    [recorded in

    <trackbot> Created ACTION-3580 - Remove <use> element instance
    tree. [on Erik Dahlström - due 2014-02-07].

    -- break --


    stakagi: our use case is lazy loading according to clipped
    bounding boxes



    stakagi: this URL describes it
    ... at first, we should have an API getClippedBBox()

    heycam: I think we should have an API with a single bbox
    function (maybe in addition to getBBox(), or maybe exactly
    getBBox()) that takes options indicating which parts to include
    ... so stroke, fill, etc.
    ... and this function you could also indicate whether the
    clip-path is taken into account
    ... element.getBBox({ fill: true, stroke: true, clipped: true,
    markers: false })
    ... and they'd have some default values

    ed: getStrokeBBox() is already implemented in Blink

    krit: but probably behind a flag
    ... it is in the spec now, and I think the spec says to include
    markers, even though the name is Stroke

    ed: it's not behind a flag

    heycam: I doubt anyone is using it yet

    krit: I want to use getBBox() on HTML content too

    ChrisL: what would it give you?

    krit: the boundaries of the element without its transform

    ChrisL: and which boundary would that be?
    ... content bounding box?

    krit: border boxes

    RESOLUTION: SVG 2 will extend getBBox with a dictionary
    parameter, including whether clip-path is included, and
    getStrokeBBox will go away.

    <scribe> ACTION: Cameron to add the extended getBBox to SVG 2.
    [recorded in

    <trackbot> Created ACTION-3581 - Add the extended getbbox to
    svg 2. [on Cameron McCormack - due 2014-02-07].

    krit: clip-path should be applied last

    heycam: we maybe should talk to CSSOM people, if we want it to
    apply to both HTML and SVG, and have CSS box keywords

Illustrator output

    shepazu: for accessibility you need to make it possible/easy to
    add title/desc to each element, and to the document root
    ... second thing is, in general, consider the case for adding
    content for animation and apps, not just static output
    ... third thing was, be careful how much you use features like
    filters, clip-paths (especially), because it hurts performance
    ... the other thing is, an SVG file should be scalable by
    default, so have the viewBox be specified and width/height 100%

    krit: I think we just added that last one
    ... there is an option, responsive image, which should allow

    ChrisL: the blog post said it didn't give you a fixed
    width/height, but it didn't say how it did it

    shepazu: and get rid of the xml prelude
    ... the comment about creator:adobe should put it in the
    document root

    heycam: are internal entities in DTDs gone?

    krit: I think so

    shepazu: add the ability to add a metadata license
    ... for the web case, it otherwise is ambiguous. allow having a
    CC-BY license mentioned in there.

RelaxNG schema validation

    shepazu: for the validator, we don't have an rng schema
    ... SVG 2 should have one
    ... I asked around different people, and everyone wanted to
    charge to do it
    ... or charge to train us to do it

    ChrisL: who's asking for this?

    shepazu: hsivonen, MikeSmith, for the validator

    ChrisL: it's not just making a subset for a subset of rng that
    is valid, but mixing it up with html5 schema, arbitrary
    combinations of these
    ... a composable schema
    ... sounds like a lot of work

    shepazu: if we want SVG to validate I think we need to do this
    ... or at least confirm that this needs to happen

    <scribe> ACTION: Doug to ask Mike whether we need an RNG schema
    for SVG to validate in the validator [recorded in

    <trackbot> Created ACTION-3582 - Ask mike whether we need an
    rng schema for svg to validate in the validator [on Doug
    Schepers - due 2014-02-08].

Publishing another WD of SVG 2

    krit: anyone object?

    ChrisL: publishing just what's in there right now? or waiting
    for people to do edits first?

    krit: I want to do my stroke edits

    ChrisL: do we have a complete list of changes since the last

    krit: I think everyone did add to changes.html

    shepazu: how about Tuesday Feb 11

    ChrisL: ok

    krit: ok

    RESOLUTION: We will publish a WD of SVG 2 on Tuesday Feb 11.

    <scribe> ACTION: Cameron to prepare SVG 2 for publication on
    Tuesday Feb 11. [recorded in

    <trackbot> Created ACTION-3583 - Prepare svg 2 for publication
    on tuesday feb 11. [on Cameron McCormack - due 2014-02-08].

SVG selection

    shepazu: we have a chapter that describes how we select text
    ... we should also say how we select other items, like
    graphical items
    ... and there's some implications to selection because
    selection is a prelude to copy and paste
    ... when you copy and paste what are you copying and pasting
    ... just the text, or maybe a png of the section you selected
    ... if you're copying the tree, do you copy all the things that
    the tree references, do you copy the original thing or do you
    expand it?
    ... do you copy css styles with the fragment you selected?

    ChrisL: I can argue for or against for each of those

    shepazu: HTML says when something is selected, it doesn't have
    a good copy and paste spec
    ... Clipboard API

    ChrisL: that's an API though so needs to be triggered by some

    shepazu: I'll talk to the editor of Clipboar API about these

    <ChrisL> Clipboard API and events

    <ChrisL> W3C Working Draft 11 April 2013

    <ChrisL> Hallvord R. M. Steen, Opera Software

    <ChrisL> [58]http://www.w3.org/TR/clipboard-apis/

      [58] http://www.w3.org/TR/clipboard-apis/

    shepazu: we've wanted to have a way of exporting a PNG of the
    SVG, has anything happened on that?

    ChrisL: [mumbles about people bringing up security]

    [talk about some use cases for getting a rendering of an SVG

    shepazu: I will find out more about what HTML does
    ... another consideration is if you select two elements, and if
    they are visually close together but in different DOM tree
    positions, how much of the tree do you export?
    ... we should have something on the SVG root, or somewhere, a
    method that says give me the selection
    ... we'll deal with this in whichever spec defines ranges and

    <shepazu> [59]http://www.w3.org/TR/SVG2/text.html#TextSelection

      [59] http://www.w3.org/TR/SVG2/text.html#TextSelection

    [discussion about selection]

    shepazu: I will talk with DOM people about setting the
    Selection object when clicking SVG elements

    RESOLUTION: SVG WG will request selection of non-text elements
    in DOM Range/Selection/whereever is appropriate.

    heycam: I wonder ::selection relates to this

    ChrisL: once you've defined that selection works on this, it
    should just fall out

    -- meeting adjourned --

Summary of Action Items

    [NEW] ACTION: Cameron to add the extended getBBox to SVG 2.
    [recorded in
    [NEW] ACTION: Cameron to prepare SVG 2 for publication on
    Tuesday Feb 11. [recorded in
    [NEW] ACTION: ChrisL to work with Smailus to create examples of
    the issues [recorded in
    [NEW] ACTION: Doug to ask Mike whether we need an RNG schema
    for SVG to validate in the validator [recorded in
    [NEW] ACTION: Doug to make background-color, padding-*,
    outline-* apply to SVG elements. [recorded in
    [NEW] ACTION: ed to create inline SVG sizing tests [recorded in
    [NEW] ACTION: Erik to ask somebody what to do about
    content/shadow inheriting from HTMLElement [recorded in
    [NEW] ACTION: Erik to remove <use> element instance tree.
    [recorded in
    [NEW] ACTION: heycam to investigate why firefox needs to treat
    SVG as a replaced element [recorded in
    [NEW] ACTION: krit to make width and height attributes
    presentation attributes on the svg element [recorded in
    [NEW] ACTION: smailus to break his presentation out into
    specific issues that need to be addressed and take it to the
    mailing list [recorded in
    [NEW] ACTION: stakagi to add the new transform(ref)
    functionality to SVG 2 [recorded in

    [End of minutes]

Received on Saturday, 1 February 2014 00:50:04 UTC