IRC log of svg on 2014-01-31

Timestamps are in UTC.

16:54:39 [RRSAgent]
RRSAgent has joined #svg
16:54:39 [RRSAgent]
logging to
16:54:48 [heycam]
RRSAgent, make logs world-readable
16:54:57 [heycam]
RRSAgent, this meeting spans midnight
16:55:16 [heycam]
Meeting: SVG F2F Seattle 2014 Day 2
16:55:18 [heycam]
Chair: Cameron
16:55:22 [heycam]
17:00:33 [Rossen_f2f]
Rossen_f2f has joined #svg
17:08:22 [rossen____]
rossen____ has joined #svg
17:09:07 [AdobeSeattle]
AdobeSeattle has joined #svg
17:10:00 [stakagi]
stakagi has joined #svg
17:12:53 [Smailus]
Smailus has joined #svg
17:14:34 [birtles]
scribenick: birtles
17:14:45 [birtles]
scribe: Brian
17:16:04 [birtles]
topic: animation of values with different types
17:16:22 [birtles]
ed: I added this because someone wrote a blog about inconsistencies about animation
17:16:30 [birtles]
17:17:03 [birtles]
krit: the problem is the attribute should be animated as SVGAnimatedNumber but percentages are also allowed by the attribute syntax
17:17:04 [heycam]
ScribeNick: heycam
17:17:11 [heycam]
Scribe: Cameron
17:17:40 [heycam]
birtles: I think we can make it more clear that when it says attributeType, that refers to the datatype of the attribute, not the IDL type
17:18:03 [heycam]
... it doesn't mean SVGAnimatedNumber, it means the datatype, which is either number or percent I think
17:18:57 [heycam]
s/attributeType/"attribute type"/
17:19:29 [heycam]
krit: in Blink/WebKit, we really take the object, SVGAnimatedWhatever, and animate this type
17:19:33 [heycam]
birtles: I don't think that's right
17:19:36 [heycam]
krit: I think the spec implies that
17:19:42 [heycam]
birtles: CSS Animations/Transitions is clearer about this
17:19:50 [heycam]
... it says "animate this as length or percentage"
17:20:00 [heycam]
... that's the intent of SVG, but it's not as clear as it could be
17:20:14 [heycam]
... we should fix this, in Web Animations
17:20:20 [heycam]
... as for the DOM, that's up to Cameron
17:20:27 [heycam]
krit: it's the same with animations of transforms
17:20:55 [heycam]
... in the past if you had <animate attributeName="transform"> then you can't say from="translate(...0)"
17:21:05 [heycam]
birtles: animateTransform in general is never possible, since the transform attribute was never animatable with <animate>
17:21:07 [heycam]
krit: it is now
17:21:10 [heycam]
birtles: yes, but SVG doesn't define that
17:21:17 [heycam]
krit: we have the same problem with filters
17:21:24 [heycam]
... you can give a list of filters, but the type would be string
17:21:28 [heycam]
... according to the SVG animation model
17:21:31 [heycam]
... you want the CSS interpolation
17:21:48 [heycam]
ChrisL: I think at the time, when SVG was using SMIL, each datatype needed its own definition for interpolation
17:22:01 [heycam]
... they were really looking on the syntax level, and if they didn't match you couldn't interpolate between them
17:22:11 [heycam]
birtles: it leaves you with interesting things like you can't do <setTransform> e.g.
17:22:15 [heycam]
... which is frustrating
17:22:26 [heycam]
... shouldn't have made different elements for for different datatypes
17:22:30 [heycam]
... but I understand the history
17:22:39 [heycam]
ChrisL: also it had a lot less developer input at that time
17:22:40 [shepazu]
shepazu has joined #svg
17:22:46 [heycam]
... it was mostly input from a few SMIL player people
17:23:29 [heycam]
birtles: so this will get fixed with Web Animations anyway, so no specific actions needed here
17:23:52 [heycam]
birtles: I posted a comment on the blog post and it hasn't appeared yet
17:24:03 [birtles]
s/animateTransform in general/animate attributeName="transform" in general/
17:24:43 [heycam]
shepazu: in general your approach with animation, all the features apart from animateColor are going to be possible with Web Animations?
17:24:44 [heycam]
birtles: yes
17:24:57 [heycam]
... we map what we've already defined in SVG onto the primitives we're defining in Web Animations
17:26:59 [birtles]
scribenick: birtles
17:27:10 [birtles]
topic: Allowing CSS outline and background on SVG elements
17:27:18 [birtles]
shepazu: previously we talked about various use cases
17:27:27 [birtles]
... for having an outline
17:27:40 [birtles]
... I don't think anyone thinks those use cases don't exist
17:28:13 [birtles]
... I think we had consensus on the use case for outline for hover etc.
17:28:27 [birtles]
... we want to be able to allow the outline property on SVG elements
17:28:37 [birtles]
... so that you can have :hover and the outline will hover
17:28:45 [birtles]
... one assumes it is the bounding box of the element
17:29:05 [birtles]
krit: SVG does not disallow the outline property and CSS does not restrict it to HTML therefore it applies to SVG
17:29:17 [birtles]
shepazu: but we haven't defined what is means for SVG
17:29:40 [birtles]
heycam: there are lots of properties like that but we need to define which box
17:29:54 [birtles]
shepazu: since we don't have a box model it doesn't just fall out of the model
17:32:30 [birtles]
Rossen_f2f: text-wrapping is a pain
17:32:44 [birtles]
... how does the box model apply to SVG?
17:33:00 [birtles]
shepazu: it doesn't, but for things like outline the question is do we want to allow the padding property?
17:33:16 [birtles]
... in this case it would simply increase the size of the outline
17:33:22 [birtles]
... but would not affect text-wrapping at all
17:33:26 [birtles]
heycam: it wouldn't be difficult
17:33:36 [birtles]
Rossen_f2f: have you looked at shape-margin, shape-padding
17:33:48 [birtles]
shepazu: I haven't, we might do that instead
17:33:58 [birtles]
heycam: they are for text in non-rectangular shapes
17:34:05 [birtles]
Rossen_f2f: it applies to an element and an element's shape
17:34:20 [birtles]
... it is meant for mapping the meaning of margin/padding in CSS to non-rectangular shapes
17:34:29 [birtles]
heycam: what happens when you apply it to a rectangular shape
17:34:37 [birtles]
... what is the difference between margin/padding
17:34:46 [birtles]
Rossen_f2f: one difference is you can only specify one value
17:34:50 [birtles]
... since you don't have four sides
17:34:59 [birtles]
... so it is meant to follow stroking rather than boxes
17:35:48 [birtles]
... if you have a 10px margin and it is a shape that has corners then it will round those corners
17:35:55 [birtles]
shepazu: let's consider that for the future, but not for now
17:36:21 [birtles]
... use case: we have a shape and you want to add an outline on mouse over
17:36:35 [birtles]
... this already works since outline applies to all elements
17:36:47 [birtles]
... can we agree that it uses the bounding box of the element?
17:37:40 [birtles]
krit: which bounding box?
17:37:58 [birtles]
shepazu: the one we discussed yesterday (stroke bounding box, decorated bounding box, whatever we call it)
17:38:15 [birtles]
... the same one for filters, masking etc.
17:38:31 [birtles]
... I just think we align it to some pre-existing definition of a bounding box
17:39:03 [birtles]
krit: we decided already filters, masking, and clipping do not affect outline
17:39:27 [birtles]
... so the problem is that the CSSWG defines it as: draw shape, stroke, fill, then filters, then mask/clip
17:39:41 [birtles]
... then if you clip an element outline will be clipped away
17:39:54 [birtles]
... on HTML it is based on the current rendering model that browsers implement
17:40:05 [birtles]
ChrisL: the default clip is going to always clip away the outline
17:40:18 [birtles]
heycam: is that right, if you have overflow:auto?
17:40:25 [birtles]
krit: the default is auto where you don't clip
17:40:42 [ChrisL]
ChrisL has joined #svg
17:41:01 [birtles]
shepazu: can we resolve we'll have outline and the outline will resolve to whatever bounding box we deem is appropriate
17:41:08 [birtles]
... of the ones we discussed yesterday
17:41:38 [birtles]
... one of the characteristics of outline is that it doesn't affect the box model
17:41:54 [birtles]
17:42:37 [birtles]
RESOLUTION: outline will resolve to our definition of stroke bounding box
17:43:04 [birtles]
shepazu: the second issue is, can we have the background property apply as well
17:43:17 [birtles]
... this would resolve to exactly the same area, it would just be the background
17:43:39 [birtles]
... it also apply to elements
17:43:57 [birtles]
... in terms of performance characteristics it is the same as outline
17:44:02 [birtles]
... it is the same area
17:44:16 [birtles]
... we have already resolved to have a viewport-fill using background
17:45:16 [birtles]
heycam: on the outer SVG element it would cover the whole viewport but for inner SVG it would cover the bounding box area
17:45:26 [birtles]
... since we decided not to do viewport-fill but just to support background
17:45:48 [birtles]
shepazu: how do we feel about having background apply to SVG elements?
17:45:56 [birtles]
heycam: I think it's fine
17:46:03 [birtles]
krit: I don't see the value in the extra work
17:46:08 [birtles]
... I think it slows down implementations
17:46:13 [birtles]
... I don't think the use case is strong enough
17:46:18 [birtles]
heycam: I think it's useful for text
17:46:27 [birtles]
Rossen_f2f: what will the background be clipped to?
17:46:33 [birtles]
shepazu: the same as outline
17:46:47 [birtles]
Rossen_f2f: so if I have a path, what will be filled?
17:46:51 [birtles]
... the area around the path?
17:46:53 [Tavmjong]
SVG 2 Text currently refers to a "content area" that is the same as defined in CSS.
17:46:53 [birtles]
shepazu: yes
17:46:58 [birtles]
RRSAgent: what is the use case for that?
17:46:58 [RRSAgent]
I'm logging. Sorry, nothing found for 'what is the use case for that'
17:47:07 [birtles]
Rossen_f2f: what is the use case for that?
17:47:38 [birtles]
... outlines are not hit-testable
17:47:41 [birtles]
... but background is
17:47:51 [birtles]
... and background is often used for hit-testing
17:48:09 [birtles]
shepazu: that is another use case where you use the background to enlarge the hit-test region
17:48:18 [birtles]
heycam: we already solved this with pointer-events: bounding box
17:48:29 [birtles]
shepazu: we could also say that background in SVG is not hit-testable
17:48:35 [birtles]
... it's simply visual, not hit-testable
17:48:39 [birtles]
heycam: that would be ok with mee
17:48:46 [birtles]
s/with mee/with me/
17:48:56 [birtles]
Rossen_f2f: so you mean background images etc?
17:49:00 [birtles]
shepazu: no, not images
17:49:05 [birtles]
Rossen_f2f: why not?
17:49:55 [birtles]
shepazu: the use case is having a visual indicator that something is in focus which applies to both outline and background
17:50:12 [birtles]
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?
17:50:33 [birtles]
... that way if you specify this fill, it fills in this area
17:50:53 [birtles]
... you're specifying an outline and you want to indicate that something is selected
17:51:02 [birtles]
shepazu: how is that different to background
17:51:13 [birtles]
Rossen_f2f: it doesn't open the door to everything else that is in background
17:51:22 [birtles]
... which is very complicated
17:51:41 [birtles]
heycam: why shouldn't you be able to use backgrounds like gradients?
17:51:52 [birtles]
krit: when you do that you have to work out sizing
17:52:00 [birtles]
heycam: once we work out the size of the box, that is solved
17:52:15 [birtles]
shepazu: I have heard many times from developers that they expected to be able to set the background on SVG elements
17:52:27 [birtles]
... right now if you want to have this effect you compose it yourself using rect
17:52:45 [birtles]
... if you want to have something highlightable you need transform a container group
17:52:52 [birtles]
ed: I've heard the same but only for text
17:53:05 [birtles]
shepazu: personally, I've done this many times
17:53:17 [birtles]
Thomas: we've used this many times
17:53:29 [ed]
s/only for text/only for text and elements that establish viewports
17:53:41 [birtles]
... you mouse over something and a background box highlights
17:53:47 [birtles]
... we do this manually using javascript
17:53:59 [birtles]
... it would be so much easier if it was directly supported
17:54:11 [birtles]
shepazu: and it would also be more intuitive to people who are used to CSS
17:54:48 [birtles]
birtles: does the shape you highlight correspond to the bounding box of the text
17:55:23 [birtles]
Thomas: we actually generate the box from some data mining software... the box might actually be slightly larger than the text bounding box
17:55:44 [birtles]
krit: is the shape always rectangular?
17:55:53 [birtles]
Thomas: it often is
17:56:16 [birtles]
shepazu: I'm just looking for the simplest possible thing that makes sense to developers
17:56:47 [birtles]
krit: I'd like to see the concrete use case
17:57:22 [birtles]
Rossen_f2f: I understand the use case but I'm not sure if this is the right approach
17:57:33 [Tavmjong]
We are moving to CSS based text layout. Hasn't CSS already figured this out?
17:58:03 [birtles]
krit: do you use something other than a color for highlighting?
17:58:13 [birtles]
Thomas: generally it's a solid color but I could see people using gradients
17:59:53 [birtles]
heycam: if we are going to restrict it to color, then we should be able to expand it to other paints later
18:00:07 [birtles]
ChrisL: this is how we ended up with viewport-fill, so we could expand it later
18:00:32 [birtles]
shepazu: I don't think the use case supports having images
18:00:46 [birtles]
... since it's about highlighting things
18:00:55 [birtles]
... but perhaps they could have a subtle stippled image
18:01:13 [birtles]
krit: if it is background-color, this doesn't allow lists of colors
18:01:31 [birtles]
shepazu: I think we should support background but only support colors
18:01:50 [birtles]
heycam: I think we should specifically just support background-color and then later we can support background if necessary
18:02:01 [birtles]
... then people don't use background to mean only background-color
18:02:35 [birtles]
Rossen_f2f: if we support background only, the shorthand, then we have to support everything in background
18:02:48 [birtles]
shepazu: I would be happy with background-color
18:03:00 [birtles]
heycam: my argument against outline-fill is that it's hard to extend later
18:03:07 [birtles]
shepazu: I also don't think we should add a property
18:03:17 [Smailus_]
Smailus_ has joined #svg
18:03:21 [birtles]
... the other thing to talk about is hit-testing
18:03:30 [birtles]
heycam: whether the background is hit-testable or not?
18:03:44 [birtles]
... with pointer-events: auto?
18:03:45 [ed]
q+ re the outline alignment vs userspace coordinate system for backgrounds
18:04:27 [birtles]
shepazu: we could say that background is not hit-testable in SVG
18:06:02 [Smailus]
Smailus has joined #svg
18:06:11 [birtles]
Rossen_f2f: in the previous use case where the outline is used to indicated that the shape has been hit-testable
18:06:57 [birtles]
... the background you use to indicate that it has been hit-tested also changes what gets hit-tested
18:07:32 [birtles]
ed: I wanted to mention the difference between the outline and the background box
18:07:47 [birtles]
... I expect the outline to be axis-aligned but not the background
18:08:05 [birtles]
... for example, if you transform some text
18:08:27 [birtles]
heycam: you can achieve that effect
18:08:38 [heycam]
<g transform="..."><text>...</text></g>
18:08:42 [heycam]
g:hover { outline: ... }
18:08:49 [heycam]
g:hover text { background-color: ... }
18:09:39 [birtles]
shepazu: another use case is when something is selected by keyboard etc.
18:09:48 [birtles]
krit: my question is what happens if you apply a clip path
18:09:54 [birtles]
... in the HTML world the background would be clipped
18:10:06 [birtles]
... do you want the background to be clipped here as well?
18:10:11 [birtles]
shepazu: it should match CSS
18:10:16 [birtles]
krit: so it would be clipped
18:10:42 [birtles]
heycam: in that case you'd need a containing group to stop the background from being clipped
18:10:49 [birtles]
shepazu: is background-color hit-testable in CSS?
18:10:54 [birtles]
Rossen_f2f: yes
18:11:02 [birtles]
heycam: the box is hit-testable
18:11:28 [birtles]
Rossen_f2f: if the background is transparent it is not hit-testable
18:11:39 [birtles]
heycam: is that right? now that we have pointer-events?
18:12:28 [Rossen_f2f]
s/is not hit-testable/didn't used to be hit-testable/
18:12:55 [birtles]
... in CSS if the background is transparent, the box is still hit-testable these days
18:13:44 [birtles]
shepazu: (draws some shapes with boxes around them)
18:14:03 [birtles]
... suppose the backgrounds have alpha
18:14:07 [birtles]
... where does it stack
18:14:11 [birtles]
everyone: with the element
18:14:36 [birtles]
shepazu: how does it blend? is it a problem?
18:14:48 [birtles]
(generally seems to be ok)
18:15:05 [birtles]
krit: we still didn't clarify hit-testing
18:15:08 [birtles]
... or padding
18:15:23 [birtles]
shepazu: I think hit-testing is characteristic of the box and not the background
18:15:27 [birtles]
... we should decide that later
18:15:49 [birtles]
krit: for the highlighting use case you don't want backgrounds to be hit-testable
18:15:57 [birtles]
shepazu: we can solve that later
18:16:04 [birtles]
krit: do we want padding??
18:16:14 [birtles]
heycam: I think we do, particularly for Thomas' use cases
18:16:35 [birtles]
shepazu: you could solve that with a background and thick outline of the same color
18:16:42 [birtles]
... so we don't *have* to have padding
18:17:05 [birtles]
heycam: I think that's problematic if rendering is not pixel-aligned since you'll get seams
18:17:18 [birtles]
shepazu: so do we want shape-padding or regular padding
18:17:30 [birtles]
heycam: I think it's better to have padding if we're talking about a box
18:18:10 [birtles]
shepazu: I think it makes most sense to allow padding
18:18:23 [birtles]
krit: padding would also affect outline
18:18:25 [birtles]
shepazu: yes
18:18:33 [birtles]
krit: what about border?
18:18:39 [birtles]
heycam: we can live without that
18:18:50 [birtles]
shepazu: what about outline-radius?
18:18:59 [birtles]
Rossen_f2f: there's no outline-radius
18:19:17 [birtles]
heycam: interestingly, it's border radius that controls the rounding of the background
18:19:25 [birtles]
shepazu: let's boil this lobster
18:20:18 [birtles]
krit: how does padding work for outer SVG?
18:20:24 [birtles]
shepazu: we special case that
18:21:40 [birtles]
RESOLUTION: add outline, background-color, and padding to SVG2 with hit-testing to be determined later
18:26:52 [heycam]
-- 15 minute break --
18:44:51 [Smailus]
Smailus has joined #svg
18:48:47 [cabanier]
scribenick: cabanier
18:48:56 [cabanier]
topic: use cases for technical diagrams
18:48:57 [Smailus]
18:49:04 [cabanier]
Smailus: here's a pdf
18:50:04 [cabanier]
Smailus: there's a paper in there that contains features that we think is important
18:50:14 [cabanier]
heycam: cgm vs SVG?
18:50:18 [cabanier]
Smailus: yes
18:50:39 [cabanier]
Smailus: the text has to fill the space between the wires
18:51:04 [cabanier]
Smailus: ... the author generates a diagram and it's important that it looks the same everywhere
18:51:14 [cabanier]
Smailus: ... so stylesheets should not affect
18:51:23 [cabanier]
shepazu: how important is that?
18:51:37 [cabanier]
Smailus: it's not that is important
18:51:52 [cabanier]
Smailus: if the diagram looks different, that is very bad
18:52:21 [cabanier]
Smailus: there can be font differences
18:52:34 [Zakim]
Zakim has joined #svg
18:52:36 [heycam]
Zakim, room for 2?
18:52:37 [Zakim]
ok, heycam; conference Team_(svg)18:52Z scheduled with code 26631 (CONF1) for 60 minutes until 1952Z
18:52:43 [Zakim]
Team_(svg)18:52Z has now started
18:52:50 [Zakim]
+ +1.206.675.aaaa
18:53:38 [cabanier]
Smailus: we have ataa and faa requirements
18:54:01 [Zakim]
18:54:34 [cabanier]
Smailus: ... we have outstanding issues with non-scaling patterns and dashse
18:55:05 [cabanier]
Smailus: ... if you zoom out, it would be very busy
18:55:19 [cabanier]
Smailus: ... when you see the diagram as a whole, the user has to zoom in
18:55:54 [cabanier]
Smailus: ... the author makes it with certain patterns, you want the line thickness to stay the same
18:56:09 [cabanier]
Smailus: ... right not the lines get thicker which is a problem
18:56:35 [cabanier]
... the paper talks about the issues
18:56:48 [cabanier]
... line types and line styles are problems
18:56:58 [cabanier]
... it would be easier if there was a table of line styles
18:57:10 [cabanier]
shepazu: you could do that with a class
18:57:18 [cabanier]
... what's a line style?
18:57:42 [cabanier]
Smailus: dash patterns, diamond
18:57:59 [cabanier]
shepazu: are these predefined or conventions?
18:58:10 [cabanier]
Smailus: I think they are conventions
18:58:29 [cabanier]
shepazu: it would be useful to know that
18:58:36 [shepazu]
18:58:37 [cabanier]
Smailus: the paper talks about this
18:59:17 [cabanier]
Rossen_f2f: wrt non-scaling pattern. do you have requirements for corners?
18:59:57 [cabanier]
Smailus: CGM has this and some people use that
19:00:06 [cabanier]
Rossen_f2f: so it has meaning in the diagram?
19:00:20 [cabanier]
Smailus: yes, whitespace at the corner could be confusing
19:00:40 [stakagi]
19:00:46 [stakagi]
19:01:02 [cabanier]
ChrisL: is there an iso standard for the dashing or is it for pay?
19:01:08 [cabanier]
Smailus: I will look that up
19:01:16 [cabanier]
.... size matters too for us
19:01:26 [cabanier]
.... it's important to keep it as small as possible
19:01:40 [cabanier]
... but not as important as it was in the past
19:02:09 [cabanier]
shepazu: one of the things they do, is that they generate the bounding box at document creation time
19:02:22 [cabanier]
.... so having this will reduce the filesize dramatically
19:03:02 [cabanier]
Smailus: yes, at authoring time, we put a transparent rectangle at the front
19:03:40 [cabanier]
... similarly for wires
19:03:53 [cabanier]
shepazu: so this could change the authoring tools?
19:04:04 [cabanier]
Smailus: yes
19:04:33 [thorton]
thorton has joined #svg
19:04:34 [cabanier]
... preserving authoring intent is key
19:04:41 [ChrisL]
catia-authored cgm
19:04:59 [cabanier]
shepazu: could SVG replace CGM?
19:05:03 [heycam]
19:05:06 [cabanier]
smailus: maybe eventually
19:05:10 [thorton]
thorton has joined #svg
19:06:58 [cabanier]
Rossen_f2f: corner preservation is important?
19:07:19 [cabanier]
smailus: people have told me that it sometimes matters. unsure how big of a deal it is?
19:07:51 [cabanier]
krit: do you want the dash array to be always the same when you zoom in/out?
19:08:09 [cabanier]
smailus: I don't think that really matters
19:08:37 [cabanier]
krit: is zooming perserving aspect ratio
19:08:44 [cabanier]
smailus: yes
19:08:55 [cabanier]
... non-scaling lines would stay the same
19:09:20 [cabanier]
ChrisL: the paper that is referenced here, is the second revision.
19:09:44 [cabanier]
... one of the particular things he picks, is bitonal images
19:09:59 [cabanier]
... SVG only has png and jpeg
19:10:56 [cabanier]
... his article uses an illustrator svg file that encodes a pdf file in the metadata
19:11:04 [ChrisL]
base64 data uri 16,613 iv-base64.txt
19:11:04 [ChrisL]
data uri compressed 12,623 iv-base64.txt.gz
19:11:04 [ChrisL]
original png 15,228 Saito_bwStucki.png
19:11:04 [ChrisL]
optimised png 12,438 Saito_bwStucki-iv.png
19:11:04 [ChrisL]
svg with data uri 16,759 svg-iv-base64.svg
19:11:06 [ChrisL]
svg compressed 12,746 svg-iv-base64.svgz
19:11:26 [cabanier]
ChrisL: I redid the file so it just contains the svg data
19:11:48 [cabanier]
shepazu: what should we be looking for?
19:12:06 [sgalineau]
sgalineau has joined #svg
19:12:23 [cabanier]
ChrisL: the optimized png is 12.6 k and the svg is 12k
19:13:07 [thorton_]
thorton_ has joined #svg
19:13:26 [cabanier]
Smailus: in our diagrams we have switches that have a hot spot
19:13:54 [cabanier]
... you can click on parts or the whole
19:14:06 [cabanier]
heycam: hierarchical regions?
19:14:15 [cabanier]
smailus: yes
19:15:34 [cabanier]
shepazu: in that case, you'd still use a rect as a hotspot
19:15:47 [cabanier]
smailus: in that case, we would probably use that all the time
19:15:47 [ChrisL]
the cad generation and the hotspot addition are done at separate stages in the workflow, typically
19:16:36 [cabanier]
smailus: the artwork is spread over the artwork and the hotspot
19:17:15 [cabanier]
... often the artwork is sorted for plotting (arcs that are together)
19:18:26 [cabanier]
shepazu: you could do rectangles in certain area but for text you could relay on the SVG
19:18:51 [cabanier]
heycam: have you looked at hatch fills that Tav proposed?
19:18:58 [cabanier]
smailus: no
19:19:10 [cabanier]
heycam: not sure if they're non-scaling
19:19:18 [ChrisL]
19:19:29 [cabanier]
Tavmjong: I assume that we'd eventually do that
19:20:00 [cabanier]
krit: what about if the aspect ration changes?
19:20:17 [cabanier]
heycam: not sure yet. Maybe we don't have to care about that
19:20:24 [ChrisL]
also, svg2 has non-scaling stroke
19:20:27 [cabanier]
krit: what if you use percentages?
19:21:07 [cabanier]
... if you do, the viewport is not square and is difficult to implement
19:21:25 [cabanier]
... but this is only an issue for relative lengths
19:22:52 [cabanier]
action: smailus to break his presentation out into specific issues that need to be addressed and take it to the mailing list
19:22:52 [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].
19:23:21 [cabanier]
action: ChrisL to work with Smailus to create examples of the issues
19:23:21 [trackbot]
Created ACTION-3573 - Work with smailus to create examples of the issues [on Chris Lilley - due 2014-02-07].
19:23:58 [cabanier]
topic: intrinsic sizing of SVG
19:24:12 [cabanier]
ed: responsize images and svg
19:24:44 [cabanier]
.... auto width and height gives you the size you need
19:24:53 [cabanier]
.... it's issue 3 on the wiki page
19:24:55 [ed]
19:25:02 [krit]
<svg width="200px" height="200px" style="width: 300px; height: 300px;" viewBox="0 0 250 250">
19:25:35 [cabanier]
krit: there are different opinions. maybe we want to do it like canvas
19:26:06 [cabanier]
.... widht and height properties and attributes control resolution and size
19:26:33 [cabanier]
heycam: do you know if this is only for inline out svg?
19:26:59 [ed]
<svg width="50%" viewBox="0 0 100 100">
19:27:00 [ed]
<rect width="100" height="100" fill="blue"/>
19:27:00 [ed]
19:27:03 [cabanier]
krit: webkit does presentational attribute mapping (sort of)
19:27:48 [cabanier]
heycam: we define that the intrinsic aspect ration comes from the viewbox?
19:27:52 [cabanier]
ed: I believe so
19:27:55 [ed]
19:28:02 [cabanier]
krit: (drawing diagram)
19:28:36 [Smailus]
Smailus has joined #svg
19:29:32 [cabanier]
heycam: it seems webkit's interpretation makes more sense
19:29:39 [ed]
<div style="width: 100px; height: 100px">
19:29:39 [ed]
<svg style="background:blue"></svg>
19:29:39 [ed]
19:29:40 [ed]
19:29:43 [cabanier]
ed: I pasted a fiddle in
19:30:13 [cabanier]
krit: IE and firefox seem to agree
19:35:07 [cabanier]
19:35:19 [cabanier]
... firefox doesn't scale height
19:35:56 [birtles]
there's a long discussion about this:
19:37:00 [ed]
another long discussion here:
19:37:29 [cabanier]
heycam: we had a bug with bing maps
19:38:02 [cabanier]
krit: with/height: 100% seems to make a different for firefox
19:39:23 [cabanier]
krit: we can say that if you leave them off, it should go to 100%
19:39:48 [cabanier]
heycam: what we want to say, if the presentation is there it maps to the style property.
19:40:00 [cabanier]
... but if it's not, it's treated as auto
19:40:21 [cabanier]
krit: I suggest that auto is 320/150
19:41:02 [heycam]
19:41:29 [cabanier]
krit: I think we need more tests
19:41:44 [cabanier]
ed: we have a lot of tests
19:42:21 [cabanier]
krit: IE used to have strange behavior in the case there was viewbox
19:42:34 [cabanier]
... I suggest we follow IE (and webkit)
19:42:54 [cabanier]
... what happens if there's a div with no sizing
19:43:56 [cabanier]
Rossen_f2f: in CSS, auto goes to 150
19:44:15 [cabanier]
... if the containing block has a resolvable height, we use that
19:47:19 [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
19:47:19 [birtles]
height (such that percentage heights were meaningful), but the intrinsic ratio was honored if they were in an auto-height container."
19:50:18 [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:
19:50:33 [Zakim]
19:52:44 [Zakim]
- +1.206.675.aaaa
19:52:45 [Zakim]
Team_(svg)18:52Z has ended
19:52:45 [Zakim]
Attendees were +1.206.675.aaaa, Tav
19:52:58 [heycam]
Zakim, room for 2?
19:52:59 [Zakim]
ok, heycam; conference Team_(svg)19:52Z scheduled with code 26631 (CONF1) for 60 minutes until 2052Z
19:53:05 [Zakim]
Team_(svg)19:52Z has now started
19:53:11 [Zakim]
+ +1.206.675.aaaa
19:53:41 [Zakim]
19:55:34 [cabanier]
19:57:45 [cabanier]
krit: webkit is not looking at the containing block
19:57:58 [cabanier]
.. it seems IE is the most reasonable
19:58:46 [cabanier]
Rossen_f2f: 10.3.2
19:59:07 [ed]
(the numbers refer to CSS 2.1 sections, right?)
19:59:11 [cabanier]
... if the width is not specified, it should go to auto. What is auto on an SVG element with display: block
19:59:42 [cabanier]
... if we follow SVG as a replaced element, 10.3.4 it should go to intrinsic
20:00:05 [cabanier]
... but we are computing as non-replaced
20:00:32 [cabanier]
... BUT if you require a shrink-to-fit such as a float, then we use 300 by 150
20:01:10 [cabanier]
... is SVG replaced element?
20:01:31 [cabanier]
heycam: is image replaced?
20:01:33 [cabanier]
20:02:26 [cabanier]
krit: x/y/width/height should be presentation attributes
20:02:33 [cabanier]
heycam: sure
20:03:01 [cabanier]
resolution: width and height attributes are presentation on the svg element
20:03:55 [cabanier]
heycam: I would like to see what the issue was
20:04:41 [cabanier]
action: heycam to investigate why firefox needs to treat SVG as a replaced element
20:04:41 [trackbot]
Created ACTION-3574 - Investigate why firefox needs to treat svg as a replaced element [on Cameron McCormack - due 2014-02-07].
20:10:20 [cabanier]
action: ed to create inline SVG sizing tests
20:10:20 [trackbot]
Created ACTION-3575 - Create inline svg sizing tests [on Erik Dahlström - due 2014-02-07].
20:11:10 [cabanier]
action: krit to make width and height attributes presentation attributes on the svg element
20:11:10 [trackbot]
Created ACTION-3576 - Make width and height attributes presentation attributes on the svg element [on Dirk Schulze - due 2014-02-07].
20:11:36 [cabanier]
topic: Deprecating/redefining symbol element
20:11:54 [cabanier]
heycam: shepazu do you have ideas?
20:12:06 [Tavmjong]
20:12:08 [cabanier]
Tavmjong: I would be against this
20:12:40 [cabanier]
... it was mentioned that browsers were not ignoring this. but that seems not to be the case
20:12:55 [cabanier]
.... I didn't check chrome or ie
20:13:02 [cabanier]
... but all others did
20:13:18 [cabanier]
... it is used quite a bit, especially Illustrator
20:13:37 [cabanier]
... Andreas is also against removal
20:14:03 [cabanier]
... inkscape uses it to populate a dialog
20:14:30 [cabanier]
shepazu: I think you misunderstood
20:14:54 [cabanier]
... I was saying that Symbol should be defined as a special case of the SVG root
20:15:15 [cabanier]
Tavmjong: I thought you wanted to deprecate the symbol element
20:15:50 [cabanier]
shepazu: I take deprecation back.
20:16:15 [cabanier]
.... they are not defined as being non-displayed SVG roots
20:16:38 [cabanier]
Tavmjong: according to ???, what is missing is alignment
20:16:53 [cabanier]
... markers have that possibility. Symbols don't
20:17:13 [cabanier]
shepazu: we should define marker and symbol the same way
20:17:28 [cabanier]
... a marker should behave like a nested svg root
20:17:55 [cabanier]
... so there's only 1 model that developers and browsers have to understand
20:18:08 [cabanier]
heycam: we already allude that they are similar
20:18:34 [cabanier]
krit: I have nothing against it but don't see the improvement
20:18:47 [cabanier]
Tavmjong: markers also have an orientation
20:19:21 [cabanier]
shepazu: I would like to see in the spec, "these are the differences between markers and symbols"
20:19:30 [cabanier]
Tavmjong: they are in different sections
20:19:42 [cabanier]
shepazu: let's go over that in the coming week
20:21:09 [cabanier]
resolution: we will not deprecate symbol and make it clear in the spec what their differences and similarities are.
20:21:32 [cabanier]
RESOLUTION: we will not deprecate symbol and make it clear in the spec what their differences and similarities are.
20:23:45 [cabanier]
RESOLUTION: feature freeze for SVG in june and last call in January 2015
20:26:45 [Zakim]
Team_(svg)19:52Z has ended
20:26:47 [Zakim]
Attendees were +1.206.675.aaaa, Tav
20:28:03 [heycam]
-- lunch time --
21:36:15 [heycam]
Scribe: Cameron
21:36:18 [heycam]
ScribeNick: heycam
21:37:07 [heycam]
Topic: pointer events and background colors
21:37:25 [heycam]
krit: I just want to make sure the default behaviour is always reasonable
21:37:29 [heycam]
shepazu: what's reasonable?
21:37:34 [heycam]
krit: background-color:transparent should not influence hit testing
21:37:46 [heycam]
... but if it has a color, it would be strange by default if it doesn't affect hit testing
21:37:57 [heycam]
ChrisL: if you're not doing hit testing you can't do :hover
21:38:05 [heycam]
shepazu: you can, you just have to change pointer-events explicitly
21:38:40 [heycam]
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 not to become hit testable
21:38:58 [heycam]
... so I think it makes more sense to never hit test, but you can still use pointer-events:bounding-box
21:39:00 [heycam]
krit: ok
21:39:19 [heycam]
s/not to/then/
21:40:01 [heycam]
RESOLUTION: background-color on SVG elements will never influence hit testing area
21:40:19 [heycam]
krit: I suggest we look at CSS UI to see if there are other keywords to use for pointer-events
21:41:21 [krit]
21:42:01 [heycam]
krit: the only difference there is the new 'auto' value
21:44:26 [heycam]
heycam: so you're proposing a new 'background' keyword for pointer-events?
21:44:29 [heycam]
krit: yeah we could have that
21:44:34 [heycam]
... it would mean the background area
21:44:39 [heycam]
heycam: is that different from bounding-box?
21:44:43 [heycam]
krit: yes because it does not include padding
21:45:00 [heycam]
heycam: so getBBox() would return the padding box, and we could use the other version of getBBox() that takes a dictionary to select which parts to include
21:45:01 [heycam]
krit: yes
21:46:30 [heycam]
s/would return the padding box/would return the plain geometry bounding box/
21:47:32 [heycam]
krit: we need to decide effectively what the content box
21:47:38 [heycam]
shepazu: I think it should be the stroked bbox
21:49:42 [heycam]
shepazu: actually the decorated bounding box
21:49:47 [heycam]
heycam: so including markers
21:50:13 [heycam]
RESOLUTION: The effective content box of an SVG element is the decorated bounding box.
21:51:40 [heycam]
ACTION: Doug to make background-color, padding-*, outline-* apply to SVG elements.
21:51:41 [trackbot]
Created ACTION-3577 - Make background-color, padding-*, outline-* apply to svg elements. [on Doug Schepers - due 2014-02-07].
21:51:59 [heycam]
Topic: non-scaling objects
21:52:03 [stakagi]
21:52:32 [Smailus]
Smailus has joined #svg
21:52:52 [heycam]
stakagi: this is an issue that came up in 2011
21:53:19 [heycam]
stakagi: I tried to standardise non-scaling features for SVG 2
21:53:36 [heycam]
... I've found that SVG Tiny 1.2 has such a feature, ref(svg)
21:53:54 [heycam]
... based on this specification, SVG 2 should have such functionality
21:54:12 [heycam]
... but I found issues, listed in that document
21:54:42 [heycam]
... one is that is somewhat difficult and has a special description
21:54:49 [heycam]
... other is that it doesn't consider nested documents
21:55:19 [heycam]
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
21:56:03 [heycam]
stakagi: the issue with nested documents is described in the last section "Fixed object for nested documents" on that page
21:56:27 [heycam]
... this section shows that non-scaling characteristics will be transmuted when nested document embedding is performed
21:56:37 [heycam]
shepazu: does this account for all transforms, including those that are in CSS?
21:57:00 [heycam]
stakagi: yes
21:57:04 [heycam]
shepazu: what about 3D transforms?
21:57:18 [heycam]
ChrisL: no, you'd need to change the formulae here to take into account 3D
21:57:20 [heycam]
shepazu: does it need to?
21:57:38 [heycam]
ChrisL: I don't see 3D being used here, it's more for local 3D inclusions in a 2D world
21:57:46 [heycam]
shepazu: what does this do for zoom?
21:57:50 [heycam]
... is that defined as a transform?
21:58:06 [heycam]
ChrisL: you do all your transforms up to the root, then an additional one for the zoom, that's where it comes in
21:58:18 [heycam]
shepazu: I think it should take into account zooming, though not necessarily panning
21:58:24 [heycam]
birtles: that page does talk about using the CTM for zooming
21:58:35 [heycam]
... the very last point it mentions browser chrome transformations, which further touches on zoom
21:59:04 [heycam]
shepazu: is this the syntax we want?
21:59:18 [heycam]
... instead of doing vector-effects="...", a CSS property that says non-scaling with parameters to that?
21:59:30 [heycam]
heycam: either is better than ref(svg)
21:59:38 [heycam]
ed: yes ref(svg) made it hard to integrate with CSS Transforms
22:00:02 [heycam]
shepazu: I would expect this to be a CSS property
22:00:07 [heycam]
birtles: vector-effect is a CSS property
22:00:30 [heycam]
ChrisL: people like non-scaling-stroke keyword
22:00:34 [heycam]
... I'm not seeing traction for vector effects more broadly
22:00:42 [heycam]
shepazu: if we promoted more it would, but that's another matter
22:02:13 [heycam]
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
22:02:37 [heycam]
shepazu: maybe "non-scaling" as the property name
22:03:21 [birtles]
scaling="fixed-stroke fixed-coordinate"
22:05:15 [heycam]
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
22:05:23 [heycam]
... for that case, you'd need a different property value
22:05:40 [heycam]
heycam: so "stop at the current document" or "go all the way"?
22:05:41 [heycam]
stakagi: yes
22:05:57 [heycam]
ChrisL: the "ref" bit means to walk up to where I'm referencing, so skip up to the specified element
22:06:06 [heycam]
birtles: there's no way of indicating of the reference with this syntax
22:06:23 [heycam]
... four property values in this proposal
22:06:36 [heycam]
ChrisL: one you can give numerical values
22:06:39 [heycam]
... one you can point to an ID
22:06:50 [heycam]
... one you can count <svg>s from the root, if you know you're nested 5 times
22:06:57 [heycam]
... (you could say to skip 2 of them)
22:07:08 [heycam]
... (and the default would be 1)
22:07:39 [heycam]
shepazu: I'm uneasy about the syntax for saying how many levels to go up
22:08:21 [heycam]
... maybe I'm misunderstanding; which transformation contexts it's skipping is at the nested <svg> barrier
22:08:32 [heycam]
... I think one nesting barrier or all is probably as much as you need
22:08:46 [heycam]
... by default it might be only the current nesting context, and the other value would be all nesting contexts
22:08:53 [heycam]
... maybe in the case of widgets...
22:09:02 [heycam]
ChrisL: my concern is composability
22:09:24 [heycam]
... if you take an existing application that uses non-transform-up-to-the-root, and you embed that somehwere, now your widget could break
22:09:38 [heycam]
shepazu: I don't disagree, I don't see in practice people doing that
22:10:08 [heycam]
... I suggest we keep it simple, so one context or all
22:10:14 [heycam]
ChrisL: I think the composability is important
22:10:24 [heycam]
shepazu: so one place I use that kind of composability is presentation slides
22:10:30 [heycam]
... I'll use levels of nested SVGs there
22:11:05 [heycam]
... 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
22:12:30 [heycam]
heycam: [describes an example]
22:12:42 [heycam]
shepazu: it seems brittle to describe it in terms of levels
22:12:43 [heycam]
heycam: I agree
22:12:49 [heycam]
ChrisL: IDs would be easier
22:14:20 [heycam]
heycam: I think I'd rather solve the number-of-levels issue later if we need to, but keep it simple to start
22:14:58 [ChrisL]
so it should aleways refer to the rootmost svg element
22:15:15 [heycam]
birtles: to clarify the four different keywords from the proposal document
22:15:45 [heycam]
... 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
22:16:03 [heycam]
... whereas fixed-coordinates means that it stays at the same position; for example for a UI for the map
22:16:37 [heycam]
... 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
22:17:09 [heycam]
ChrisL: I understand the four things now, but maybe the names could be improved
22:17:54 [heycam]
birtles: you want the property values to be like "fixed-scale", "fixed-position", ...
22:19:08 [heycam]
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
22:19:14 [heycam]
shepazu: you could have separate keywords
22:19:43 [Zakim]
Zakim has left #svg
22:20:30 [ChrisL]
nopan-root nopan-viewport noscale-root noscale-viewport
22:21:06 [heycam]
thomas: does that take into account rotation too?
22:21:19 [heycam]
... your map legend might not want to rotate when you rotate your map contents
22:21:36 [heycam]
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
22:21:42 [heycam]
... the auto value is no transform limit
22:22:41 [heycam]
... among them would be no-rotate, no-scale-stroke, no-scale, no-pan
22:22:51 [heycam]
shepazu: and then there are the scoping things
22:23:15 [heycam]
ChrisL: those, followed by either a keyword that means viewport or root element, with an initial value that would mean
22:25:09 [heycam]
stakagi: I'm not fussed about syntax
22:25:23 [heycam]
... regarding no-rotate, previous SVG's transform(ref) couldn't do that, so I didn't consider it
22:25:34 [heycam]
... but might be convenient, provided the math isn't convenient
22:26:00 [heycam]
thorton: with a compass rose, you want that to rotate, but the map legend not to rotate
22:29:33 [heycam]
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
22:30:01 [heycam]
birtles: I think if there are parts that are difficult to specify, like math for no-rotate, he might like to defer that
22:30:09 [heycam]
... but at least he wants to cover the two cases for transform(ref)
22:30:40 [heycam]
stakagi: if someone wants to think about it I'm happy for you to do so
22:30:52 [heycam]
shepazu: to get started, let's accept accept Takagi-san's proposal, he puts it into the spec, and we go from there
22:31:29 [heycam]
RESOLUTION: We will accept the new transform(ref) proposal but with different syntax for SVG 2.
22:31:43 [heycam]
ACTION: stakagi to add the new transform(ref) functionality to SVG 2
22:31:43 [trackbot]
Created ACTION-3578 - Add the new transform(ref) functionality to svg 2 [on Satoru Takagi - due 2014-02-07].
22:31:56 [heycam]
birtles: we mentioned non-scaling hatching
22:32:02 [heycam]
... we'd address that with the same property?
22:32:05 [heycam]
ChrisL: I think we need to look at that
22:34:00 [heycam]
shepazu: the flip invariant text could be handled here too
22:34:23 [heycam]
heycam: yeah, a new value to snap non-rotation to 90 degrees?
22:35:27 [ed]
don't see why we should necessarily restrict it to n*90 degrees, let it be author controlled
22:35:52 [heycam]
ISSUE: Consider allowing non-rotation, non-scaling/rotation of fill hatch/pattern options to the new non-transform functionality
22:35:52 [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 <>.
22:36:50 [heycam]
ISSUE-2453: Also non-scaling rotation of stroke (in case it includes a hatch pattern too).
22:36:50 [trackbot]
Notes added to ISSUE-2453 Consider allowing non-rotation, non-scaling/rotation of fill hatch/pattern options to the new non-transform functionality.
22:38:12 [heycam]
Topic: Shadow DOM in SVG
22:38:22 [heycam]
krit: the shadow tree has things where you can isolate style inheritance
22:38:30 [heycam]
... and you can explicitly inherit style into the tree
22:38:34 [heycam]
... is that something we care about for the <use> element?
22:38:35 [heycam]
ed: I guess
22:38:39 [heycam]
... if it's something you can control
22:38:52 [heycam]
... one part that was requested was to add <shadow> to SVG
22:39:37 [ed]
22:40:23 [ed]
22:41:02 [richardschwerdtfeger]
richardschwerdtfeger has joined #svg
22:41:06 [heycam]
heycam: this is pdr's review of web components for SVG
22:41:26 [heycam]
heycam: seems like it makes sense to allow <shadow> in SVG as he suggests
22:41:55 [heycam]
krit: what about removing the instance tree?
22:42:02 [heycam]
ed: everyone on the mailing list agreed but we haven't resolved yet
22:42:10 [heycam]
... so that would be removing SVGElementInstance etc.
22:42:29 [heycam]
krit: groups within Adobe would like to extend the instance tree rather than removing it
22:43:04 [heycam]
heycam: I think knowing the correspondence between template and shadow tree elements isn't critical
22:43:09 [heycam]
... you can work it out yourself if you need
22:43:17 [heycam]
krit: I think most people agreed about the removal of the SVG instance tree
22:43:34 [heycam]
RESOLUTION: SVG 2 will remove the SVG instance tree for <use>.
22:43:40 [heycam]
krit: next is basing <use> on the Shadow DOM
22:43:44 [heycam]
... which is now in CR, or at least LC
22:45:35 [heycam]
cabanier: so if it's a shadow tree you have a copy per instance
22:45:36 [heycam]
ChrisL: yes
22:46:42 [heycam]
shepazu: if I have a <use> element, and I change the thing it refers to, does it no longer update?
22:47:29 [heycam]
cabanier: yes
22:47:35 [heycam]
heycam: but I think maybe we want to keep the auto-updating behaviour
22:47:52 [heycam]
krit: that is how Blink implements <use> in terms of shadow trees
22:47:57 [heycam]
... updates to the original cause the tree to get recreated
22:48:03 [heycam]
heycam: that's how it works internally in Firefox now anyway
22:51:40 [heycam]
[discussion of allowing inherited styles into shadow trees]
22:58:37 [heycam]
RESOLUTION: SVG 2 will base <use> on shadow tree spec.
22:59:57 [heycam]
heycam: pdr's first point in his mail, is that about the HTML parser?
23:00:08 [heycam]
ed: there are two things defined in Shadow DOM
23:00:11 [heycam]
... <shadow> and <content>
23:00:17 [heycam]
... they're both inheriting from HTMLElement
23:00:58 [heycam]
krit: should they inherit from Element so we can use it?
23:01:05 [heycam]
heycam: not sure about that.
23:01:15 [heycam]
... don't want to lose all the HTMLElement things in HTML
23:01:22 [ed]
23:01:38 [florian]
florian has joined #svg
23:02:00 [ed]
23:02:09 [ed]
23:02:10 [heycam]
ACTION: Erik to ask somebody what to do about content/shadow inheriting from HTMLElement
23:02:10 [trackbot]
Created ACTION-3579 - Ask somebody what to do about content/shadow inheriting from htmlelement [on Erik Dahlström - due 2014-02-07].
23:04:30 [heycam]
ACTION-3413 is cyril's action to make <use> use Shadow DOM
23:04:32 [heycam]
23:04:33 [trackbot]
ACTION-3413 -- Cyril Concolato to Investigate describing use in terms of the shadow DOM -- due 2013-02-10 -- OPEN
23:04:33 [trackbot]
23:05:30 [heycam]
ACTION: Erik to remove <use> element instance tree.
23:05:30 [trackbot]
Created ACTION-3580 - Remove <use> element instance tree. [on Erik Dahlström - due 2014-02-07].
23:05:54 [heycam]
-- break --
23:32:52 [heycam]
Topic: getClippedBBox()
23:37:05 [heycam]
stakagi: our use case is lazy loading according to clipped bounding boxes
23:37:18 [stakagi]
23:37:27 [heycam]
... this URL describes it
23:38:03 [heycam]
... at first, we should have an API getClippedBBox()
23:39:56 [heycam]
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
23:40:00 [heycam]
... so stroke, fill, etc.
23:40:12 [heycam]
... and this function you could also indicate whether the clip-path is taken into account
23:40:27 [heycam]
... element.getBBox({ fill: true, stroke: true, clipped: true, markers: false })
23:40:31 [heycam]
... and they'd have some default values
23:40:57 [heycam]
ed: getStrokeBBox() is already implemented in Blink
23:41:01 [heycam]
krit: but probably behind a flag
23:41:36 [heycam]
krit: it is in the spec now, and I think the spec says to include markers, even though the name is Stroke
23:43:22 [heycam]
ed: it's not behind a flag
23:43:25 [heycam]
heycam: I doubt anyone is using it yet
23:44:48 [heycam]
krit: I want to use getBBox() on HTML content too
23:45:00 [heycam]
ChrisL: what would it give you?
23:45:07 [heycam]
krit: the boundaries of the element without its transform
23:45:11 [heycam]
ChrisL: and which boundary would that be?
23:45:17 [heycam]
... content bounding box?
23:45:24 [heycam]
krit: border boxes
23:46:08 [heycam]
RESOLUTION: SVG 2 will extend getBBox with a dictionary parameter, including whether clip-path is included, and getStrokeBBox will go away.
23:46:17 [heycam]
ACTION: Cameron to add the extended getBBox to SVG 2.
23:46:18 [trackbot]
Created ACTION-3581 - Add the extended getbbox to svg 2. [on Cameron McCormack - due 2014-02-07].
23:47:24 [heycam]
krit: clip-path should be applied last
23:48:57 [heycam]
heycam: we maybe should talk to CSSOM people, if we want it to apply to both HTML and SVG, and have CSS box keywords
23:55:13 [heycam]
Topic: Illustrator output
23:55:33 [heycam]
shepazu: for accessibility you need to make it possible/easy to add title/desc to each element, and to the document root
23:56:05 [heycam]
... second thing is, in general, consider the case for adding content for animation and apps, not just static output
23:56:27 [heycam]
... third thing was, be careful how much you use features like filters, clip-paths (especially), because it hurts performance
23:56:56 [heycam]
... the other thing is, an SVG file should be scalable by default, so have the viewBox be specified and width/height 100%
23:57:08 [heycam]
krit: I think we just added that last one
23:57:19 [heycam]
krit: there is an option, responsive image, which should allow that
23:57:33 [heycam]
ChrisL: the blog post said it didn't give you a fixed width/height, but it didn't say how it did it
23:58:18 [heycam]
shepazu: and get rid of the xml prelude
23:58:52 [heycam]
shepazu: the comment about creator:adobe should put it in the document root
00:00:15 [heycam]
heycam: are internal entities in DTDs gone?
00:00:17 [heycam]
krit: I think so
00:01:19 [heycam]
shepazu: add the ability to add a metadata license
00:01:40 [heycam]
... for the web case, it otherwise is ambiguous. allow having a CC-BY license mentioned in there.
00:02:47 [heycam]
Topic: RelaxNG schema validation
00:03:06 [heycam]
shepazu: for the validator, we don't have an rng schema
00:03:11 [heycam]
... SVG 2 should have one
00:03:33 [heycam]
... I asked around different people, and everyone wanted to charge to do it
00:03:37 [heycam]
... or charge to train us to do it
00:03:47 [heycam]
ChrisL: who's asking for this?
00:03:59 [heycam]
shepazu: hsivonen, MikeSmith, for the validator
00:04:45 [heycam]
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
00:04:48 [heycam]
... a composable schema
00:04:51 [heycam]
... sounds like a lot of work
00:05:55 [heycam]
shepazu: that's all the feedback I have right now
00:06:27 [heycam]
s/that's all the feedback I have right now/if we want SVG to validate I think we need to do this/
00:06:33 [heycam]
... or at least confirm that this needs to happen
00:06:46 [heycam]
ACTION: Doug to ask Mike whether we need an RNG schema for SVG to validate in the validator
00:06:46 [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].
00:07:52 [heycam]
Topic: Publishing another WD of SVG 2
00:08:02 [heycam]
krit: anyone object?
00:08:17 [heycam]
ChrisL: publishing just what's in there right now? or waiting for people to do edits first?
00:08:23 [heycam]
krit: I want to do my stroke edits
00:09:11 [heycam]
ChrisL: do we have a complete list of changes since the last WD?
00:09:15 [heycam]
krit: I think everyone did add to changes.html
00:14:37 [heycam]
shepazu: how about Tuesday Feb 11
00:14:38 [heycam]
ChrisL: o
00:14:44 [heycam]
s/: o/: ok/
00:14:47 [heycam]
krit: ok
00:15:53 [heycam]
RESOLUTION: We will publish a WD of SVG 2 on Tuesday Feb 11.
00:16:25 [heycam]
ACTION: Cameron to prepare SVG 2 for publication on Tuesday Feb 11.
00:16:25 [trackbot]
Created ACTION-3583 - Prepare svg 2 for publication on tuesday feb 11. [on Cameron McCormack - due 2014-02-08].
00:17:34 [heycam]
Topic: SVG selection
00:17:50 [heycam]
shepazu: we have a chapter that describes how we select text
00:17:57 [heycam]
... we should also say how we select other items, like graphical items
00:18:23 [heycam]
... and there's some implications to selection because selection is a prelude to copy and paste
00:18:37 [heycam]
... when you copy and paste what are you copying and pasting
00:18:59 [heycam]
... just the text, or maybe a png of the section you selected
00:19:20 [heycam]
... 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?
00:19:28 [heycam]
... do you copy css styles with the fragment you selected?
00:19:38 [heycam]
ChrisL: I can argue for or against for each of those
00:20:03 [heycam]
shepazu: HTML says when something is selected, it doesn't have a good copy and paste spec
00:20:05 [heycam]
... Clipboard API
00:20:14 [heycam]
ChrisL: that's an API though
00:20:25 [heycam]
shepazu: I'll talk to the editor of Clipboar API about these questions
00:20:46 [ChrisL]
Clipboard API and events
00:20:46 [ChrisL]
W3C Working Draft 11 April 2013
00:20:55 [ChrisL]
Hallvord R. M. Steen, Opera Software
00:21:02 [ChrisL]
00:21:29 [ChrisL]
s/though/though so needs to be triggered by some gesture
00:21:51 [heycam]
shepazu: we've wanted to have a way of exporting a PNG of the SVG, has anything happened on that?
00:22:00 [heycam]
ChrisL: [mumbles about people bringing up security]
00:24:08 [heycam]
[talk about some use cases for getting a rendering of an SVG fragment]
00:24:14 [heycam]
shepazu: I will find out more about what HTML does
00:24:36 [heycam]
... 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?
00:24:56 [heycam]
... we should have something on the SVG root, or somewhere, a method that says give me the selection
00:25:20 [florian]
florian has joined #svg
00:26:37 [Smailus]
Smailus has joined #svg
00:27:01 [heycam]
... we'll deal with this in whichever spec defines ranges and selections
00:28:18 [shepazu]
00:32:03 [heycam]
[discussion about selection]
00:32:32 [heycam]
shepazu: I will talk with DOM people about setting the Selection object when clicking SVG elements
00:36:46 [heycam]
RESOLUTION: SVG WG will request selection of non-text elements in DOM Range/Selection/whereever is appropriate.
00:37:59 [heycam]
heycam: I wonder ::selection relates to this
00:38:38 [heycam]
ChrisL: once you've defined that selection works on this, it should just fall out
00:43:24 [heycam]
-- meeting adjourned --
00:43:29 [heycam]
RRSAgent, make minutes
00:43:29 [RRSAgent]
I have made the request to generate heycam
00:44:19 [heycam]
Present: Thomas, Chris, Cameron, Brian, Doug, Rossen, Dirk, Rik, Satoru, Sylvain, Erik
00:44:22 [heycam]
RRSAgent, make minutes
00:44:22 [RRSAgent]
I have made the request to generate heycam
00:44:36 [heycam]
Present+ Tav
00:44:38 [heycam]
RRSAgent, make minutes
00:44:38 [RRSAgent]
I have made the request to generate heycam
01:19:06 [thorton_]
thorton_ has joined #svg
01:40:38 [ed]
"SVG is the new standard for vector images in the browser."
01:40:49 [ed]
when an article starts like that...
01:52:18 [heycam]
ACTION: Cameron to try to get attributes auto marked up for Shepherd
01:52:18 [trackbot]
Created ACTION-3584 - Try to get attributes auto marked up for shepherd [on Cameron McCormack - due 2014-02-08].
02:58:53 [thorton]
thorton has joined #svg
05:40:40 [florian]
florian has joined #svg
06:21:25 [florian]
florian has joined #svg
06:47:25 [shepazu]
shepazu has joined #svg