20:26:28 RRSAgent has joined #svg 20:26:28 logging to http://www.w3.org/2015/10/08-svg-irc 20:26:30 RRSAgent, make logs public 20:26:30 Zakim has joined #svg 20:26:32 Zakim, this will be GA_SVGWG 20:26:32 I do not see a conference matching that name scheduled within the next hour, trackbot 20:26:33 Meeting: SVG Working Group Teleconference 20:26:33 Date: 08 October 2015 20:28:57 Chair: Cameron 20:29:02 Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Oct/0025.html 20:29:21 present+ Cameron 20:29:58 present+ ed 20:30:55 fantasai has joined #svg 20:31:37 present+ tav 20:31:57 present+ amelia 20:32:09 passcode? 20:32:22 present+ nikos 20:32:48 present+ fantasai 20:34:32 present+ stakagi 20:35:17 Scribe: Nikos 20:35:20 scribenick: nikos 20:35:29 Topic: writing modes 20:35:38 present+ shepazu 20:36:01 fantasai: I think we came to a bunch of conclusions at the F2F and I tried to edit them in 20:36:23 ... then there was an issue about whethter the old values should compute to each other, or if they needed to be maintained separately in the layout engine just for SVG 20:36:33 ... seems discussion on the list is that it's ok to compute them to new values 20:36:36 ... so overall looks good 20:36:47 ... Amelia may have wanted some clarifications? 20:37:04 AmeliaBR: just for text-orientation. I think the way you've approached it is great 20:37:10 ... shorthand translates to new property 20:37:18 ... but making sure all existing valid values are translated properly 20:37:27 ... as an angle value rather than a string value 20:37:59 AmeliaBR: it's tricky that no units at all doesn't map to a css angle 20:38:09 fantasai: there's a question of whether that's accepted in the css syntax as well 20:38:22 ... there was discussion about unitess values and supporting them in css but there was push back on that 20:38:32 AmeliaBR: it currently works in the limited number of browsers that support that property 20:38:38 ... that's consistent with svg 11 20:38:48 ... you can leave off units if it's a property that was introduced for svg 20:38:53 ... as this one was 20:39:02 ... but as far as mapping, it's probably easiest to just describe it as two different ways 20:39:09 ... a number and an angle option 20:39:12 ... and map them both 20:39:16 https://svgwg.org/svg2-draft/types.html#syntax 20:39:24 heycam: at the moment we have text in svg 2 about how to parse presentation attributes 20:39:37 ... which effectively does a search and replace on the grammar to insert number at a ppropriate places 20:39:51 ... so thats what let them accept zero 20:40:16 ... for ones that aren't svg specific (come from css) we insert it into the grammar 20:40:33 fantasai: that's going to get confusing when moving properties back and forth 20:40:45 ... but suppose you need to do that for backwards compat. Don't think it's a practice we should take forward 20:40:58 heycam: would you prefer we limit that to the set of properties that we already support - new svg properties don't get that ? 20:41:10 fantasai: think that would be a good idea - we are seeing cases where we're taking properties from svg 20:41:18 ... and there really shouldn't be a distinction for the author 20:41:46 heycam: that's reasonable - I can come up with the list of properties to allow that for 20:42:01 fantasai: as far as glyph orientation vertical, the question is if we ignore other values 20:42:13 ... current recommendation is to ignore and treat as unsupported 20:42:25 ... unless you think there's content out there that relies on the weird values 20:42:35 heycam: I agree - I keep hearing dirk mention output from illustrator 20:42:42 ... afaik it was using text-orientation: 0 20:42:51 ... so it could do it's own glyph layout 20:43:05 fantasai: zero gets mapped to upright which does the same thing 20:43:09 ACTION: Cameron to come up with a list of properties to explicitly allow unitless values in 20:43:09 Created ACTION-3822 - Come up with a list of properties to explicitly allow unitless values in [on Cameron McCormack - due 2015-10-15]. 20:43:42 AmeliaBR: only other comment I had was somewhere adding a comment about the html direction properties 20:43:46 fantasai: it's handled in the bidi section 20:44:01 AmeliaBR: I found in testing that IE responds to those things but it doesn't set the css in a way that will inherit into svg 20:44:14 ... so if you say direction=rl on html or body it's not inherited into inline svg 20:44:24 ... the way the css direction property would 20:44:38 fantasai: we had an appendix that had mapping rules for html4 but some html people asked us to take it out 20:44:47 ... html5 defines this already in it's rendering section 20:45:16 fantasai: I can add a reference to that section if there isn't one already, but it is required by the HTML spec that you map to the CSS properties 20:45:33 AmeliaBR: I haven't tested in Edge - it may be fixed there. Pretty sure everyone else inherits as expected 20:46:08 fantasai: I just have to make a few clarifications regarding writing-mode - add some mappings, but don't know if anyone actually needs that 20:46:12 ... what do you do for radian? 20:46:24 ... it's not a rational number so don't know how you'd do that mapping 20:46:31 AmeliaBR: has to be exactly that value 20:46:52 fantasai: if svg wg wants me to specify radians and gradients as well I can do that, but please let me know what you want to do for radians 20:47:03 ... if you don't need them we can drop that 20:47:15 ... you'll have to tell me what range is accepted as 90 degrees, etc 20:47:23 AmeliaBR: yeah that was something that wasn't defined in the svg spec 20:47:37 s/gradients/gradians/ 20:47:38 Tav: it says they're restricted to 0, 90, 270, 180 20:47:43 ... doubt anyone would use gradians 20:48:05 AmeliaBR: unitless numbers are out there in the real world, radians less likely 20:48:07 Tav: I'd ignore radains 20:48:13 heycam: that'd be fine with me 20:48:17 s/radains/radians 20:49:13 shepazu: Just one point - you were saying Amelia (meow) that IE doesn't inherit 20:49:24 ... that's probably juts a bug 20:49:52 heycam: I think fantasai was referring to ua stylesheet where it maps 20:50:01 ... I could see there may be ua style rules that reset those properties on svg elements 20:50:19 ... It's unlikely the spec says that so I'd agree with Doug that it's probably a bug 20:51:01 Topic: Path stroking for paths that end with tight curves 20:51:07 Yes, it's in HTML 5 here, so no change required in CSS Writing Modes: http://www.w3.org/TR/html5/rendering.html#bidi-rendering 20:51:11 Tav: I just had a question of whether we want to define how you do stroking 20:51:13 heycam: we do 20:51:27 http://tavmjong.free.fr/SVG/STROKING/ 20:51:34 Tav: I looked at how stroking is implemented while looking at the stroke alignment property 20:51:53 ... there's one place where theres inconsistency between FF and other browsers and Postscript and PDF 20:52:17 ... if you have a very tight curve at the end of the line you sometimes see this ugly behaviour and it surprises people 20:52:41 https://svgwg.org/svg2-draft/painting.html#StrokeShape 20:52:43 heycam: I did add a section on what the exact shape of a stroke should be 20:52:56 ... that describes it in the form of what set of points should be in the stroke 20:53:15 ... so that matches the 'move a line of stroke width around the path' method 20:53:41 ... I showed this to one of our graphics guys and he was a bit unhappy because it was too precisely defined 20:53:49 ... because we're at the mercy of underlying graphics libraries 20:54:04 ... theres no way we can change our implementation without creating a whole new renderer 20:54:18 ... and as we move to using more os and gfx card libraries that will get even harder 20:54:28 ... so he would have preferred some leway 20:54:35 ... not sure how to do that - whether we allow two methods or what 20:54:42 ... but practically we have to allow something like that 20:54:56 Tav: it would be nice to have some consistency, if you scroll down on the link and look at the dash pattern 20:55:06 ... you can see the dash pattern is doing more what I would expect 20:55:26 shepazu: might have to consider hardware implementations also 20:55:48 ... we should check with khronos about what hw is likely to do 20:55:54 Tav: good idea 20:56:11 Tav: another consideration is the sweeping a perpendicular line around 20:56:18 ... doesn't work with inside/outside 20:56:27 ... you get things outside the area you would expect them in 20:56:39 ... talking with the khronos guys might be a good idea 20:56:55 AmeliaBR: if the long term result is to get these features hw accelerated we want consistency with specs and whatever hw is calcaulating 20:57:09 Tav: my guess is they can probably do it either way 20:57:32 shepazu: I think they probably have some way they have chosen to do it 20:58:09 heycam: Tav do you you agree we should change the svg 2 spec wrt covering the various strategies 20:58:19 ... should we make it a 'should' or what? 20:58:35 Tav: I'd prefer to take FFs approach but agree it may be hard if people rely on underlying libraries 20:59:11 nikos: what does PDF do? 20:59:14 Tav: matches FF 21:00:17 Tav: as soon as you add a dash pattern you can see that they're doing something different 21:00:28 AmeliaBR: at that point each dash becomes it's own path 21:00:31 ... so the rules change 21:01:15 heycam: you're probably seeing Cairos behaviour if you're testing FF on linux 21:01:26 ... you might see different behaviour on other platforms 21:01:41 shepazu: underlying libraries can also change - that's not a totally inflexible requirement 21:02:11 ... we should talk to khronos and library vendors etc and get agreement 21:03:12 nikos: Cairo implements PDF model so I think it would difficult to change 21:03:28 AmeliaBR: well that's the one it would be nice to fix upon 21:04:01 ... but what are we going to do with SVG 2 for now, knowing other engines do things differently? 21:04:10 heycam: agree that option is the ideal 21:04:31 ... I'd be happy with the spec saying here's the ideal stroke shape but you may differ in some particular ways 21:04:54 Tav: one way you may be able to make them look closer is if you connect the point where it goes in the opposite direction to the path itself 21:05:03 ... at the end point 21:05:15 would be interesting to hear what the skia people have to say about this 21:07:30 action: Nikos to look into implementation of path stroking in various libraries with view to what recommendations svg 2 spec should make 21:07:30 Created ACTION-3823 - Look into implementation of path stroking in various libraries with view to what recommendations svg 2 spec should make [on Nikos Andronikos - due 2015-10-15]. 21:08:08 Topic: Declarative animation and conformance 21:08:13 ed: this was raised as an issue on github 21:08:28 https://github.com/w3c/svgwg/issues/23 21:08:30 ... Brian responded but I'm not sure if we need to update the conformance chapter to say something about SMIL and declarative animations 21:08:48 AmeliaBR: it comes up in this case where teh chapter distinguishes between static and dynamic viewers 21:08:59 ... in describing a dynamic viewer it mentions declarative animation and script 21:09:19 ... in my sense, that is written as descriptive rather than prescriptive 21:09:28 ... further on we have some more text about requirements 21:09:46 ... maybe we need to clean up to say 'for example, dynamic content could be achieved in either of these ways' 21:09:50 ... does that make sense? 21:10:00 heycam: think so and I think you're right about why it's mentioned there 21:10:21 ... not meant to include or exclude SMIL explicitly, just that that was the only declarative method around at the time the spec was written 21:10:23 Here's SVG 1.1 text http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers 21:10:28 ... conformance appendix hasn't had much attention yet 21:10:32 ... could do with some reviews 21:10:55 Latest SVG 2: https://svgwg.org/svg2-draft/conform.html#ConformingSVGViewers 21:10:55 ... maybe someone should rewrite - probably a lot of conformance classes we don't need are included 21:11:39 heycam: if no one has an interest at the moment, we should probably add an issue saying conformance class wording needs to be reviewed 21:12:04 ... as for the result of the issue, I agree and we should comment in the github issue to that effect 21:12:12 AmeliaBR: I can do that and add the issue to the spec 21:12:39 s/and add/if Cam will add/ 21:12:45 summary is, add gradiens and integers to glyph-orient, otherwise spec is okay? 21:12:56 or other edits/concerns? 21:13:03 action: heycam to add an issue to conformance appendix noting that it needs review/rewriting 21:13:04 Created ACTION-3824 - Add an issue to conformance appendix noting that it needs review/rewriting [on Cameron McCormack - due 2015-10-15]. 21:13:08 fantasai, that sounds right. 21:14:22 Topic: back to writing modes 21:14:36 heycam: probably don't need to bother about gradiens, it's very unlikely anyone is using them 21:14:44 stakagi has joined #svg 21:14:44 fantasai: works for me 21:14:48 shepazu: we can always add them later 21:15:04 fantasai: so conslusion is to add integers to represent unitless values 21:15:09 ... gradiens and radians get mapped 21:15:53 s/gradiens and radians get mapped/gradiens and radians get dropped 21:16:05 fantasai: clarify that they are not part of the glyph orientation property going forwards 21:16:17 ... clarifying the spec that values other than 0,90,180,270 are not supported 21:16:24 heycam: that sounds like what we agreed on 21:16:40 fantasai: I'll make those edits and take the spec back to CSS for a resolution to publish CR 21:16:57 ... concludes what I need from you guys wrt writing modes 21:18:04 Topic: Anchor tag nesting and HTML harmonization 21:18:15 https://github.com/w3c/svgwg/issues/26 21:18:17 ed: two questions in this issue 21:18:27 ... first, we disallow nesting of anchor tag in svg 2 21:18:38 AmeliaBR: that's something that should have been disallowed anyway 21:18:44 ... but it maybe wasn't clearly stated before 21:18:57 ... right now we've got a content model that is generic and it should not allow that 21:19:16 ed: i think it would be good to have a small note explaining why we did this and why it wasn't disallowed before 21:19:24 heycam: to be clear, this is just about author conformance requirements right? 21:19:44 ed: yeah - not quite sure what implementations do right now. They may differ in how they handle the case. 21:19:58 AmeliaBR: theoretically if they were just a elements with anchors and not links they might not break anything 21:20:11 ... but otherwise things are not going to work properly, and I think HTML explicitly disallows it 21:20:25 heycam: I would probably put it down to a mistake when I was generating those blue boxes 21:20:46 ... it's difficult to construct nested a elements because of how the html parser work 21:20:50 ... but you can do it in the dom 21:20:59 html: https://html.spec.whatwg.org/multipage/semantics.html#the-a-element "Content model: Transparent, but there must be no interactive content descendant." 21:20:59 ... hope the HTML spec says something about that, and we can do something similar 21:22:07 ed: we might want to clarify what happens if you have nested links in svg 2 21:22:13 ... which link is clicked 21:22:21 heycam: agree we should write that up 21:22:29 ... whos the owner of the linking chapter? 21:22:35 AmeliaBR: it's been myself and Bogdan 21:22:49 heycam: is it something you'd be willing to work on Amelia? 21:23:07 AmeliaBR: I can tidy that up. Will do some quick tests to see what happens 21:23:27 ... do people like Erik's idea of which link should be active? 21:23:28 heycam: yes 21:23:36 AmeliaBR: do we have a preference ? 21:23:43 ed: I'd like it to be the same as HTML 21:24:06 action: Amelia to investigate behaviour of nested links in SVG and HTML 21:24:07 Created ACTION-3825 - Investigate behaviour of nested links in svg and html [on Amelia Bellamy-Royds - due 2015-10-15]. 21:24:41 ed: that covers the first question, second question is whether we should add additional attributes that HTML defines 21:24:45 AmeliaBR: I like that idea 21:25:13 heycam: doesn't sound like those three would be problematic 21:25:13 For reference, here's the HTML 5 spec: http://www.w3.org/TR/html5/text-level-semantics.html#the-a-element 21:25:23 ... we've already decided to have the same set of attributes for style and script 21:25:32 ... so I think it makes sense to have the same set of attributes on a 21:25:36 ed: agree 21:25:46 AmeliaBR: there's about eight different attributes in HTML 21:25:53 ... all of which would be applicable 21:26:21 heycam: would we want to add the corresponding DOM properties? 21:26:40 ... so duplicate what's on HTML anchor elements? 21:27:10 AmeliaBR: I'd opt for consistency unless there's some issue. There may be accessibility interfaces that use these extra attributes 21:27:17 ... would make it much easier if SVG supports them as well 21:27:44 heycam: let's assume we will have the same attributes and DOM properties then and if we find anything that will be problematic then we can discuss skipping 21:27:48 ... but I think it should all be fine 21:28:05 AmeliaBR: right now the only special dom property we have is for target, and I'm pretty sure that's consistent with the HTML one 21:28:27 ed: for href we have an svg animated string as the interface 21:28:42 AmeliaBR: same with target, listed as animated string rather than simple strg 21:28:45 so it's aElement.href.baseVal = "#foo" 21:28:46 s/strg/string 21:28:56 AmeliaBR: which is inconsistent with the html interface 21:29:12 ... so if we bring new things in, are we consistent to the existing svg dom or the html dom? 21:29:26 heycam: for non animated thing I think we tend to do something similar to the html spec already 21:29:38 ... so I think in a way it would be consistent with existing things in html if we took the idl from html 21:29:43 ... for everything other than href 21:30:31 action: amelia to look at adding extra html attributes onto svg a element 21:30:31 Created ACTION-3826 - Look at adding extra html attributes onto svg a element [on Amelia Bellamy-Royds - due 2015-10-15]. 21:30:46 AmeliaBR: to be clear, href and target are animated string and the rest are just dom strings? 21:30:52 https://svgwg.org/svg2-draft/linking.html#InterfaceSVGAElement 21:30:56 heycam: yes 21:31:09 ... I'm surprised target is an animated strings 21:31:19 s/animated strings/animated string 21:40:24 rrsagent, make minutes 21:40:24 I have made the request to generate http://www.w3.org/2015/10/08-svg-minutes.html nikos 23:28:13 jdaggett has joined #svg