SVG F2F Seattle 2014 Day 2 -- 31 Jan 2014

<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

http://www.broken-links.com/2014/01/29/animating-offset-value-svg/

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 be
... 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 string
... 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 datatypes
... 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 yet

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 elements
... 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 outline
... 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 outline

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

REO

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 outline
... it is the same area
... we have already resolved to have a viewport-fill using background

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 elements?

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 box

shepazu: we could also say that background in SVG is not hit-testable
... 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 background

Rossen_f2f: in order to get around this, if all you need is selection, can't you specify your outline to have fill or stroke?
... 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 gradients?

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 colors

shepazu: I think we should support background but only support colors

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

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 SVG

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 background
... for example, if you transform some text

heycam: you can achieve that effect

<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> https://www.w3.org/Graphics/SVG/WG/wiki/images/7/78/Boeing_-_Vector_Drawing_Capabilities_of_Interest.pdf

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

<shepazu> 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

<stakagi> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Skeleton_frames

<stakagi> http://lists.w3.org/Archives/Public/www-svg/2013Jan/0009.html

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

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> 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 revision.
... 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 together)

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> 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 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 implement
... 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 http://www.w3.org/2014/01/31-svg-minutes.html#action01]

<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 http://www.w3.org/2014/01/31-svg-minutes.html#action02]

<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

<ed> https://www.w3.org/Graphics/SVG/WG/wiki/Intrinsic_Sizing

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

heycam: do you know if this is only for inline out 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> http://jsfiddle.net/M445V/

krit: (drawing diagram)

heycam: it seems webkit's interpretation makes more sense

<ed> http://jsfiddle.net/3dy9U/

ed: I pasted a fiddle in

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

<birtles> there's a long discussion about this: https://bugzilla.mozilla.org/show_bug.cgi?id=668163

<ed> another long discussion here: 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 viewbox
... 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 that

<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: http://lists.w3.org/Archives/Public/www-svg/2013Dec/0095.html

heycam: 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 http://www.w3.org/2014/01/31-svg-minutes.html#action03]

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

<scribe> ACTION: ed to create inline SVG sizing tests [recorded in 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 http://www.w3.org/2014/01/31-svg-minutes.html#action05]

<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> 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 2015

<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 reasonable

shepazu: what's reasonable?

krit: background-color:transparent should not influence hit testing
... 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 explicitly

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

<krit> 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 pointer-events?

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 http://www.w3.org/2014/01/31-svg-minutes.html#action06]

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

non-scaling objects

<stakagi> 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 functionality
... but I found issues, listed in that document
... one is that is somewhat difficult and has a special description
... 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 matter

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 that
... 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 scale
... 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 scaling

shepazu: you could have separate keywords

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

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, no-pan
... 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 transform(ref)

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 http://www.w3.org/2014/01/31-svg-minutes.html#action07]

<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 functionality

<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 at <http://www.w3.org/Graphics/SVG/WG/track/issues/2453/edit>.

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

<ed> http://lists.w3.org/Archives/Public/www-svg/2014Jan/0018.html

<ed> 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 suggests

krit: what about removing the instance tree?

ed: everyone on the mailing list agreed but we haven't resolved yet
... 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 behaviour

krit: that is how Blink implements <use> in terms of shadow trees
... 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 parser?

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> http://w3c.github.io/webcomponents/spec/shadow/

<ed> http://w3c.github.io/webcomponents/spec/shadow/#content-element

<ed> 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 http://www.w3.org/2014/01/31-svg-minutes.html#action08]

<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

ACTION-3413?

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

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/3413

<scribe> ACTION: Erik to remove <use> element instance tree. [recorded in http://www.w3.org/2014/01/31-svg-minutes.html#action09]

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

-- break --

getClippedBBox()

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

<stakagi> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/ResourcePriorities_for_SVG#ClippedBBox

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 http://www.w3.org/2014/01/31-svg-minutes.html#action10]

<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 that

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 http://www.w3.org/2014/01/31-svg-minutes.html#action11]

<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 WD?

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 http://www.w3.org/2014/01/31-svg-minutes.html#action12]

<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 gesture

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

<ChrisL> Clipboard API and events

<ChrisL> W3C Working Draft 11 April 2013

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

<ChrisL> 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 fragment]

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 selections

<shepazu> 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 --

- DRAFT -

SVG F2F Seattle 2014 Day 2

31 Jan 2014

Attendees

Contents