Minutes SVG F2F Seattle 2014 Day 2 from Cameron McCormack on 2014-02-01 (www-svg@w3.org from February 2014)

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 31 Jan 2014 16:49:19 -0800
To: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <52EC448F.6050008@mcc.id.au>

http://www.w3.org/2014/01/31-svg-minutes.html

[1]W3C

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

- DRAFT -

SVG F2F Seattle 2014 Day 2

31 Jan 2014

[2]Agenda

[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

Attendees

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

Regrets
Chair
Cameron

Scribe
Brian, Cameron

Contents

* [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

[19]http://www.broken-links.com/2014/01/29/animating-offset-val
ue-svg/

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

[20]
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>
[21]http://www.cgmopen.org/technical/cgm-svg-20030508-2.htm

[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

<stakagi>
[22]https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_I
nput#Skeleton_frames

[22]
https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Skeleton_frames

<stakagi>
[23]http://lists.w3.org/Archives/Public/www-svg/2013Jan/0009.ht
ml

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

[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
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
[27]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
[28]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>
[29]https://www.w3.org/Graphics/SVG/WG/wiki/Intrinsic_Sizing

[29] 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> [30]http://jsfiddle.net/M445V/

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

krit: (drawing diagram)

heycam: it seems webkit's interpretation makes more sense

<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

[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

[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
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:
[35]http://lists.w3.org/Archives/Public/www-svg/2013Dec/0095.ht
ml

[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
[37]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 [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
[39]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> [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
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>
[41]http://www.w3.org/wiki/User:Tantekelik/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
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
[42]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>
[43]http://svg2.mbsrv.net/devinfo/devstd/non-scaling-objects-2/

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

[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
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>
[46]http://lists.w3.org/Archives/Public/www-svg/2014Jan/0018.ht
ml

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

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

<ed>
[49]http://w3c.github.io/webcomponents/spec/shadow/#content-ele
ment

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

<ed>
[50]http://w3c.github.io/webcomponents/spec/shadow/#shadow-elem
ent

[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
[51]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>
[52]http://www.w3.org/Graphics/SVG/WG/track/actions/3413

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

<scribe> ACTION: Erik to remove <use> element instance tree.
[recorded in
[53]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>
[54]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/ResourceP
riorities_for_SVG#ClippedBBox

[54]
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
[55]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
[56]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
[57]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> [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
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> [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
[60]http://www.w3.org/2014/01/31-svg-minutes.html#action10]
[NEW] ACTION: Cameron to prepare SVG 2 for publication on
Tuesday Feb 11. [recorded in
[61]http://www.w3.org/2014/01/31-svg-minutes.html#action12]
[NEW] ACTION: ChrisL to work with Smailus to create examples of
the issues [recorded in
[62]http://www.w3.org/2014/01/31-svg-minutes.html#action02]
[NEW] ACTION: Doug to ask Mike whether we need an RNG schema
for SVG to validate in the validator [recorded in
[63]http://www.w3.org/2014/01/31-svg-minutes.html#action11]
[NEW] ACTION: Doug to make background-color, padding-*,
outline-* apply to SVG elements. [recorded in
[64]http://www.w3.org/2014/01/31-svg-minutes.html#action06]
[NEW] ACTION: ed to create inline SVG sizing tests [recorded in
[65]http://www.w3.org/2014/01/31-svg-minutes.html#action04]
[NEW] ACTION: Erik to ask somebody what to do about
content/shadow inheriting from HTMLElement [recorded in
[66]http://www.w3.org/2014/01/31-svg-minutes.html#action08]
[NEW] ACTION: Erik to remove <use> element instance tree.
[recorded in
[67]http://www.w3.org/2014/01/31-svg-minutes.html#action09]
[NEW] ACTION: heycam to investigate why firefox needs to treat
SVG as a replaced element [recorded in
[68]http://www.w3.org/2014/01/31-svg-minutes.html#action03]
[NEW] ACTION: krit to make width and height attributes
presentation attributes on the svg element [recorded in
[69]http://www.w3.org/2014/01/31-svg-minutes.html#action05]
[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
[70]http://www.w3.org/2014/01/31-svg-minutes.html#action01]
[NEW] ACTION: stakagi to add the new transform(ref)
functionality to SVG 2 [recorded in
[71]http://www.w3.org/2014/01/31-svg-minutes.html#action07]

[End of minutes]
__________________________________________________________

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