20:26:06 RRSAgent has joined #svg 20:26:06 logging to http://www.w3.org/2015/02/26-svg-irc 20:26:08 RRSAgent, make logs public 20:26:08 Zakim has joined #svg 20:26:10 Zakim, this will be GA_SVGWG 20:26:10 ok, trackbot, I see GA_SVGWG()3:30PM already started 20:26:11 Meeting: SVG Working Group Teleconference 20:26:11 Date: 26 February 2015 20:26:15 Chair: Cameron 20:26:23 Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Feb/0049.html 20:26:27 Regrets: Chris, Brian 20:26:35 Tav has joined #svg 20:28:31 +[IPcaller] 20:28:33 Zakim, [ is me 20:28:33 +heycam; got it 20:28:41 Zakim, who is on the call? 20:28:41 On the phone I see Thomas_Smailus, heycam 20:28:47 I'm going to be late... I will respond to Tab about text width and height via email. I don't think we should revert. 20:30:07 +[IPcaller] 20:30:17 Zakim, [IP is me 20:30:17 +ed; got it 20:31:15 +??P11 20:31:27 zakim, ??P11 is me 20:31:27 +AmeliaBR; got it 20:32:25 -ed 20:35:45 +[IPcaller] 20:35:55 Zakim, [IP is me 20:35:55 +ed; got it 20:36:07 Zakim, who is on the call? 20:36:07 On the phone I see Thomas_Smailus, heycam, AmeliaBR, ed 20:36:21 richardschwerdtfeger has joined #svg 20:36:40 scribeNick: ed 20:37:00 +??P12 20:37:04 topic: SVG 2 WD publication date 20:37:09 zakim,??P12 is me 20:37:09 +stakagi; got it 20:37:27 AmeliaBR: heycam, were there any particular updates you wanted to get in before the publication? 20:37:53 heycam: yes, splitting out some things into new specs... to ensure publication is synchronized 20:37:54 +Doug_Schepers 20:38:16 heycam: I propose we aim for March 12 for the publication 20:38:21 AmeliaBR: sounds sensible 20:38:31 -Doug_Schepers 20:38:37 ... anything else that we're waiting for? 20:38:53 +??P13 20:38:53 heycam: nothing in particular, but we assigned many actions at the f2f 20:39:03 Zakim, ??P13 is me 20:39:03 +nikos; got it 20:39:15 topic: deprecating target=replace 20:39:19 http://www.w3.org/mid/CAFDDJ7xYOq-pTdVWpyU86X1z6kRVog=zs+Rg-GHRD_kx46QHWQ@mail.gmail.com 20:39:26 +Doug 20:39:45 AmeliaBR: this list of items came up because some things didn't make sense 20:39:50 ... the last update of svg 1.1 20:39:55 ... it introduced link targets 20:40:03 ... have a special keyword "replace" 20:40:11 ... it's svg specific 20:40:18 ... no equivalent in html 20:40:28 ... for when svg is embedded in 20:40:39 ... the distinction is no longer relevant 20:40:51 ... most browsers treated it as the name for a new tab 20:41:05 ... proposal: deprecate this and recommend authors to not use it 20:41:20 ... and for browsers to still recognize it 20:41:32 +1 20:41:36 q+ 20:41:48 ... think it's fairly straightforward 20:41:51 ack 20:41:54 ack shepazu 20:42:08 shepazu: don't think there are any complications we need to worry about, support AmeliaBR's proposal 20:42:20 heycam: I'm in favor of deprecating 20:42:30 s/for browsers to still recognize it/for browsers to still recognize it and treating it as "_self" 20:42:38 ... but i'm wondering if it's sufficiently unused so that we can remove it entirely 20:42:58 ... if there's only one browsers supporting this case then authors can't rely on it anyway 20:43:05 q+ 20:43:12 ... given the opportinity to remove it I'd like to take it 20:43:42 shepazu: so, "to hell with the people that use this keyword"? 20:43:46 ack shepazu 20:43:59 heycam: pretty much, but don't think it's much used at all 20:44:13 shepazu: do you mean depreacte or remove in the spec? 20:44:25 heycam: I'd like to remove from spec directly 20:44:42 shepazu: by not saying anything it leads to confusion 20:45:04 ... would prefer a section in the spec that lists all deprecated and obsoleted features 20:45:30 ... would provide clarity for anyone wondering 20:45:41 +1 for a section listing deprecated/obsoleted stuff 20:45:42 TS: agree 20:46:19 heycam: one difference to html5 obsoleted features are that those are usually in use 20:46:33 ... this feature here otoh only has two search results on the web 20:46:42 ... so might argue for taking a different approach 20:47:08 shepazu: I'm looking for less author perspective and more implementor perspective 20:47:52 ... I looked at svg tiny 1.2, and I don't think we should be recommend it any more 20:48:26 ... we should recind it, it confuses people 20:48:47 ... a major complication is that 1.2T was standardised and ratified by JIS 20:49:18 q+ 20:49:23 ... so we should explain why we did that 20:49:47 ... don't want to put a note in the spec where it used to be, because that's a distraction 20:50:01 ack AmeliaBR 20:50:04 ... better with a chapter/appendix with removed and deprecated things 20:50:25 nikos: doesn't the changes section cover this already? 20:50:32 shepazu: sure 20:50:56 AmeliaBR: I like the idea of having a formal place for removed features 20:51:15 ... don't agree with shepazu about not having notes where things were removed 20:52:05 ... on heycam's question on whether we should have any fallback for this keyword, would that be complex? 20:52:15 ... we should try to not break content if possible 20:52:50 heycam: for a feature like this if we list it as deprecated/removed... should a new implementation bother implementing it? 20:53:11 ... I don't think we should encourage implementation of things we want to drop 20:53:28 AmeliaBR: ok, so we can take it out and add a comment saying why it was taken out 20:53:41 ... in my testing only IE recognized the keyword 20:53:57 ... so probably not much content that would break 20:54:13 -nikos 20:54:31 shepazu: ok, I agree that we shouldn't recommend implementing deprecated/obsolete features 20:54:37 +??P1 20:54:46 Zakim, ??P1 is me 20:54:46 +nikos; got it 20:55:04 q+ 20:55:11 ack Smailus 20:55:26 RESOLUTION: make the '_replace' keyword for @target obsolete and add a note explaning why it was removed 20:56:15 Smailus: there may be companies using these features, content not searchable online 20:57:03 shepazu: we're not changing what's valid for svg 1.1, so nothing stops an implementor from doing an svg 1.1 engine... this is for svg2 in particular 20:57:36 can you be an SVG 1.1 and SVG 2 conforming implementation simultaneously? 20:57:47 ... we don't forbid people from doing SMIL, but it's not part of svg2 20:58:13 heycam: ok, probably not important to discuss this right now 20:59:31 ACTION: Amelia to make the '_replace' keyword for @target obsolete and add a note explaning why it was removed 20:59:31 Created ACTION-3760 - Make the '_replace' keyword for @target obsolete and add a note explaning why it was removed [on Amelia Bellamy-Royds - due 2015-03-05]. 20:59:42 +Rich_Schwerdtfeger 20:59:55 topic: #svgView(transform(...))) behavior 21:00:00 https://lists.w3.org/Archives/Public/www-svg/2014Dec/0015.html 21:00:05 AmeliaBR: somethign that came up in email discussion 21:00:20 ... where we discussed adding transform attr to 21:00:45 ... so conclusion was that the transform applies to the parent coordinate system 21:00:53 ... complexity with the svgView spec syntax 21:01:13 ... said transform applies the same way as elements... so that raises questions for what was meant 21:01:28 ... the testsuite is clear that the transform applies at the child level 21:02:26 ED: pretty sure that test was a draft (as in: not part of the offical testsuite, and not guaranteed to be correct) 21:02:51 AmeliaBR: ok... right now implementations are not consistent 21:04:00 This is the draft test: http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObject/linking-frag-01-f.html 21:04:40 ED: I recall that we agreed on how the trasnforms shopudl apply on but I've only added issues in the spec for now 21:04:55 ... we never discussed the svgView syntax issue though 21:05:24 heycam: ok, I'd imagine that users when linking to some svg... they want to override something to look at a paricular part of the svg 21:05:32 ... say want to look at some path 21:05:50 ... easier to reason about what transform to apply if the transform is on the very outside of the stack 21:06:13 AmeliaBR: I'm leaning towards making it consistent with the transform on the , easier that way 21:06:24 ed: I'd agree with that 21:06:38 heycam: what happens when you have transforms on both, combine or replace? 21:06:50 AmeliaBR: the way the svgView syntax works is that they replace the attribute 21:07:03 Oh, that's weird. 21:07:04 ... so would prefer to be consistent with that 21:07:32 TabAtkins: don't think it's that weird, e.g for viewBox 21:07:54 Yeah, replacing viewBox seems fine, but replacing transform seems odd to me. Maybe not that odd. 21:08:56 ed: I'd agree with tab that it's a bit strange to not stack the transforms 21:09:27 heycam: it'd be odd if the transform was replaced since it might affect the origianl document quite a lot 21:09:40 AmeliaBR: not sure how often ppl would use transformations on the root element 21:09:58 -nikos 21:10:10 ed: right now don't think there's any content since transforms on roots was not permitted in svg 1.1 21:10:25 AmeliaBR: right, so we wouldn't break content here 21:10:32 +??P0 21:10:42 Zakim, ??P0 is me 21:10:42 +nikos; got it 21:10:49 heycam: ok, changing my mind to go with the append the transformation 21:12:19 RESOLUTION: svgView(transform()) will apply on as an additional transform outermost transform on the transform stack 21:13:16 ACTION: AmeliaBR to add text to say that svgView(transform()) will apply on as an additional transform outermost transform on the transform stack 21:13:16 Created ACTION-3761 - Add text to say that svgview(transform()) will apply on as an additional transform outermost transform on the transform stack [on Amelia Bellamy-Royds - due 2015-03-05]. 21:13:36 topic: should viewTarget match :target 21:13:45 s/outermost transform on/on the root element, outermost to/ 21:13:48 https://lists.w3.org/Archives/Public/www-svg/2015Feb/0042.html 21:14:03 AmeliaBR: changes were made in 1.1 21:14:20 ... viewTarget names which specific element is the focus of a given 21:14:33 ... original SVG 1 say it should highlight these elements 21:14:47 ... in the update it said authors should use the :target pseudoclass 21:14:55 ... to describe how things should be highlighted 21:15:06 ... but this doesn't work for the view element 21:15:29 q+ 21:15:40 ack shepazu 21:15:42 ... so I think the target pseudoclass shoudl apply .... 21:16:02 shepazu: the way I understand svgView... 21:16:15 ... ppl are trying to use it for spritesheets 21:16:36 ... it may or may not be desireable for the :target to be highlighter in that context 21:16:47 s/should apply ..../to all the elements mentioned in the viewTarget attribute / 21:16:49 AmeliaBR: it would be up to the author to do that 21:17:09 shepazu: if you can style things with :target then... 21:17:27 ... if you want some interacation based on :hover... is having that being the :target... 21:17:43 ... invocting the target state in css, does that have negative implications? 21:18:02 ... if using the :target pseudoclass you can still do things with :hover 21:18:22 AmeliaBR: to be clear: nothing would change for the author 21:18:37 ... you can still add a hover state 21:18:55 ... you can use :target to add styles to your svg when someone links to your svg 21:18:59 ... to trigger styling 21:19:09 ... but you cannot do things when you use a 21:19:34 shepazu: think we should ask the css wg about this 21:20:17 ... they may not think of an svg also being a target (in addition to viewTarget) 21:20:50 is just a level of indirection, not sure it's worth it IMHO 21:21:16 s/ AmeliaBR: view only applies to embedded images or objects, not in documents 21:21:54 shepazu: want to confirm with css people if this is a good idea 21:22:02 heycam: two things might be good to bring up 21:22:19 ... 1) the thing that gets targetted is NOT the thing with the id 21:22:39 ... 2) multiple elements matching that pseudoclass, since currerntly only one match is there 21:23:01 ... AmeliaBR, you asked if multiple matches are easy to support 21:23:11 ... I looked in gecko, shoudln't be that hard to support 21:23:30 -ed 21:24:18 ACTION: Cameron to email www-style about :target and view fragments 21:24:19 Created ACTION-3762 - Email www-style about :target and view fragments [on Cameron McCormack - due 2015-03-05]. 21:25:45 AmeliaBR: I had two other issues relating to view fragments 21:25:48 -nikos 21:26:03 AmeliaBR: they are maybe less interesting to discuss, so I can just draft some spec text and discuss them then 21:26:17 shepazu: there's only 5 minutes, so we can wait 21:26:25 +??P0 21:26:28 Zakim, ??P0 is me 21:26:28 http://www.w3.org/blog/news/archives/4442?pk_campaign=feed&pk_kwd=first-public-working-draft-svg-accessibility-api-mappings-1-0-svg-aam 21:26:28 +nikos; got it 21:26:33 shepazu: I have some news; the FPWD of the SVG Accessibility mapping has been published 21:26:39 SVG Accessibility API Mappings 1.0 (SVG-AAM) was published today 21:26:47 +[IPcaller] 21:27:21 richardschwerdtfeger++ for driving that 21:30:50 -Thomas_Smailus 21:30:51 -Rich_Schwerdtfeger 21:30:52 -stakagi 21:30:52 -heycam 21:30:53 -[IPcaller] 21:30:54 -Doug 21:31:01 -AmeliaBR 21:31:03 -nikos 21:31:03 GA_SVGWG()3:30PM has ended 21:31:03 Attendees were Thomas_Smailus, [IPcaller], heycam, ed, AmeliaBR, stakagi, Doug_Schepers, nikos, Doug, Rich_Schwerdtfeger 21:31:54 trackbot, end telcon 21:31:54 Zakim, list attendees 21:31:54 sorry, trackbot, I don't know what conference this is 21:32:02 RRSAgent, please draft minutes 21:32:02 I have made the request to generate http://www.w3.org/2015/02/26-svg-minutes.html trackbot 21:32:03 RRSAgent, bye 21:32:03 I see 3 open action items saved in http://www.w3.org/2015/02/26-svg-actions.rdf : 21:32:03 ACTION: Amelia to make the '_replace' keyword for @target obsolete and add a note explaning why it was removed [1] 21:32:03 recorded in http://www.w3.org/2015/02/26-svg-irc#T20-59-31 21:32:03 ACTION: AmeliaBR to add text to say that svgView(transform()) will apply on as an additional transform outermost transform on the transform stack [2] 21:32:03 recorded in http://www.w3.org/2015/02/26-svg-irc#T21-13-16 21:32:03 ACTION: Cameron to email www-style about :target and view fragments [3] 21:32:03 recorded in http://www.w3.org/2015/02/26-svg-irc#T21-24-18