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