00:01:16 <jdaggett> jdaggett has joined #svg
00:09:49 <tantek_> tantek_ has joined #svg
06:39:29 <jdaggett_> jdaggett_ has joined #svg
06:51:08 <heycam> krit, FX topics will be right after the agenda rearrangement discussion this morning
06:58:42 <tkonno> tkonno has joined #svg
07:05:02 <freenode> freenode has joined #svg
07:09:32 <tantek> tantek has joined #svg
07:23:47 <krit> heycam: will call in around 10am
07:24:07 <krit> heycam: will there be a video conference?
07:24:26 <heycam> krit, there will -- you'll need to use the link that simon provided in his mail, rather than the link I gave
07:24:49 <krit> K, thanks
07:25:43 <heycam> krit, FX is moving to Thursday morning now, sorry
07:25:49 <heycam> so that Dean can be here
07:26:09 <heycam> so we'll be in the usual room after all
07:33:42 <ed_work_> ed_work_ has joined #svg
07:33:50 <SimonSapin> krit: ping me when you want to call in
07:34:16 <tkonno_> tkonno_ has joined #svg
07:34:28 <birtles> I'm waiting to see what the agenda is for CSS for today before I decide if I should stay or not
07:34:45 <birtles> I also realised I didn't send the minutes from yesterday
07:35:24 <heycam> birtles, ok
07:36:02 <birtles> RRSAgent, make minutes public
07:36:02 <RRSAgent> I'm logging. I don't understand 'make minutes public', birtles.  Try /msg RRSAgent help
07:36:58 <birtles> RRSAgent, make minutes
07:36:58 <RRSAgent> I have made the request to generate http://www.w3.org/2015/08/25-svg-minutes.html birtles
07:37:13 <heycam> there is a special url to go to generate a previous day's minutes
07:37:35 <birtles> heycam: cheers
07:37:37 <BogdanBrinza> BogdanBrinza has joined #svg
07:38:03 <heycam> birtles, yeah so you go to say http://www.w3.org/2015/08/24-svg-irc,minutes
07:38:10 <heycam> so the IRC log url plus ",minutes"
07:38:38 <heycam> I don't know whether that will upload the generated minutes to the expected URL though
07:39:45 <ed_work_> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/svg/SVGSVGElement.cpp&l=102 (for SVGSVGElement.viewport)
07:48:15 <birtles> yeah, I can't manage to get the minutes to be uploaded
07:49:38 <heycam> birtles, ok; maybe just attach the HTML to the mail, then, so it still has some URL
07:53:06 <birtles> heycam, I can't get the regular plain text version so I was just going to make up my own plain text version that is similar to the usual one... but is that going to break your tool that scrapes the minutes emails?
07:53:28 <heycam> birtles, no it'll be fine
07:53:30 <ed_work_> just add ,text to the end of the minutes url, should work?
07:53:48 <heycam> but good point; the tool will expect the normal minutes url so I guess it'll miss them
07:53:52 <heycam> I'll do something manual to add it after you send it
07:54:03 <birtles> yeah, adding ,text doesn't work
07:59:06 <krit> SimonSapin: ping
07:59:27 <SimonSapin> krit: Do you wanna join CSS or SVG?
07:59:35 <krit> no FX today?
07:59:42 <heycam> krit, it got moved to Thursday
07:59:52 <krit> ok, SVG then
08:02:14 <krit> birtles: Do you know what Animations 2 will be?
08:02:24 <krit> birtles: on the agenda of CSS WG tomorro
08:02:26 <krit> birtles: on the agenda of CSS WG tomorrow
08:03:07 <birtles> krit: I think it ended up being Wednesday afternoon
08:03:30 <krit> birtles: yes, but what is it? WebAnimation 2 or CSS Animations 2?
08:03:34 <birtles> krit: https://wiki.csswg.org/planning/paris-2015#wednesday
08:03:38 <birtles> krit: CSS Animations 2
08:03:49 <krit> birtles: who suggested it? Is there a draft?
08:03:59 <birtles> krit: Shane and I. Yes.
08:04:12 <birtles> krit: https://rawgit.com/shans/csswg-drafts/animations-2/css-animations-2/Overview.html
08:04:17 <BogdanBrinza> BogdanBrinza has joined #svg
08:04:21 <TabAtkins> https://drafts.csswg.org/css-animations-2/
08:04:27 <krit> thanks
08:05:00 <shane> krit: Tab's link is wrong.
08:05:02 <birtles> TabAtkins: the one we want to ask about tomorrow is a later version than that
08:05:21 <krit> k
08:05:44 <TabAtkins> birtles: You should be pushing it!
08:05:55 <birtles> TabAtkins: pushing it?
08:05:59 <TabAtkins> To the repo
08:06:00 <cyril> cyril has joined #svg
08:06:24 <birtles> TabAtkins: I want to get the ok that this approach is ok
08:06:39 <birtles> (also I don't have write access to the css repo)
08:06:57 <TabAtkins> Shane does!
08:07:19 <shane> we wanted to talk about whether we could stop being a delta specification first, I think?
08:07:52 <birtles> yeah, I wanted to ask how I should write it with regards to linking to Web Animations
08:09:33 <krit> birtles: shane: So version 2 will mostly be set up CSS Animations on top of WebAnimation and ass animation-composite
08:09:59 <krit> s/ass/add/
08:10:02 <birtles> krit: yeah, basically + animationcancel I think
08:10:12 <shane> birtles: were we going to propose a simple exposure of groups too?
08:10:30 <birtles> and any other features that get added along the way... e.g. there are some discussions about extending timing-functions recently
08:10:31 <shane> or hmm I guess not as that isn't in a WebAnim WD yet...
08:10:45 <birtles> yeah, maybe not, depends on the timeframe for animations-2
08:11:10 <krit> could you add a simple example for 4.5. Animation composite order please?
08:11:15 <krit> (to the draft)
08:11:31 <birtles> krit: yes, of course
08:12:34 <krit> looks great. Not necessarily easy to understand right away from reading it but this is editorial
08:15:33 <heycam> (krit, you can call in whenever you want)
08:16:24 <krit> heycam: is there an agenda for today?
08:16:42 <heycam> krit, yes there are a few topics on the wiki
08:16:48 <heycam> krit, we can discuss them whenever
08:19:46 <Tav> Tav has joined #svg
08:21:59 <heycam> trackbot, start telcon
08:22:01 <trackbot> RRSAgent, make logs public
08:22:01 <Zakim> Zakim has joined #svg
08:22:03 <trackbot> Zakim, this will be GA_SVGWG
08:22:03 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
08:22:04 <trackbot> Meeting: SVG Working Group Teleconference
08:22:04 <trackbot> Date: 25 August 2015
08:23:56 <heycam> Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Paris_2015/Agenda
08:23:59 <heycam> Chair: Cameron
08:24:03 <heycam> Scribe: Cameron
08:24:05 <heycam> ScribeNick: heycam
08:24:17 <heycam> Topic: SVGSVGElement.viewport
08:24:24 <ed_work_> https://svgwg.org/svg2-draft/struct.html#issue62
08:24:40 <heycam> ed: issue 62 in the structure chapter is about SVGSVGElement.viewport
08:24:56 <heycam> ... currently Blink is just returning an SVGRect filled with zeroes
08:25:00 <heycam> ... Firefox does not implement it
08:25:05 <heycam> ... my proposal would be to drop the attribute
08:25:29 <heycam> krit: did you check the usage of it?
08:25:46 <heycam> krit: I thought I saw it was used
08:25:57 <heycam> ed: I've seen people try to use it but then use fallbacks to get the information another way
08:26:01 <heycam> ... using innerHeight etc.
08:26:21 <heycam> Tav: if it were implemented, would it be useful?
08:26:40 <heycam> heycam: it's never been clear to me what viewport should return, so I don't know
08:26:52 <heycam> ed: yes, so figuring out what it's supposed to return is a question
08:27:01 <heycam> ... the problem in Blink was that it was hard to get the right values at the right time
08:27:10 <heycam> ... so you could return something but it might not be the correct values
08:28:01 <heycam> heycam: Edge does return a rectangle with some values in it
08:28:34 <heycam> BogdanBrinza: if it were useful I think we would have heard about it
08:28:50 <ed_work_> https://code.google.com/p/chromium/issues/detail?id=395838
08:29:02 <ed_work_> https://bugzilla.mozilla.org/show_bug.cgi?id=503855
08:29:24 <heycam> krit: not implemented in WebKit
08:30:01 <heycam> cyril: if you animate the viewBox would you expect to see the values in .viewport?
08:30:08 <heycam> heycam: I think it's an open question what viewport was intended to return
08:30:11 <heycam> ... it's not clear
08:33:32 <heycam> [some discussion about what viewport might mean]
08:33:41 <heycam> Tav: so is this related to pAR?
08:33:49 <heycam> krit: with pAR the viewBox size is different from the viewport size
08:35:06 <heycam> krit: I think the point where it would be useful is if you want to put say a background rectangle covering the window
08:38:53 <heycam> heycam: testing in Edge, the .viewport.{width,height} just return whatever value would be returned by .{width,height}.baseVal
08:41:55 <krit> https://www.irccloud.com/pastebin/38EnSIQu/
08:43:08 <heycam> krit: what does Edge return for .viewport for the inner <svg>?
08:45:14 <BogdanBrinza> http://jsfiddle.net/boggydigital/mh0tgwn7/2/
08:48:40 <heycam> heycam: so currently you can get all this information by looking up x/y/width/height property in the SVG DOM
08:48:58 <heycam> ... and for exposing the size of the window that the outer <svg> is fit into, you can look up window.innerWidth/innerHeight
08:49:08 <heycam> ... and I can't think of any other useful values to return. so I suggest just removing it.
08:49:38 <heycam> RESOLUTION: We will remove SVGSVGElement.viewport.
08:50:11 <heycam> ACTION: Erik to remove SVGSVGElement.viewport.
08:50:11 <trackbot> Created ACTION-3815 - Remove svgsvgelement.viewport. [on Erik Dahlström - due 2015-09-01].
08:50:17 <heycam> Topic: Filtering elements when creating use shadow trees
08:50:19 <ed_work_> https://svgwg.org/svg2-draft/struct.html#issue58
08:50:38 <heycam> ed: right now, you can point a <use> to pretty much anything, and it will just clone that subtree with anything that's in it
08:50:49 <heycam> ... Blink is currently filtering out some elements from when it builds the shadow trees
08:50:55 <heycam> ... so foreignObject is not included, for example
08:51:05 <heycam> ... my question is should this be something that we specify?
08:51:11 <heycam> Tav: so you can't have clones of video playing
08:51:26 <heycam> ed: right now I know if you have video inside foreignObejct, you get the wrong position
08:51:56 <heycam> heycam: what's the reason for disallowing these elements?
08:52:05 <heycam> ed: first, not all aspects of what cloning means is still not clear
08:52:10 <heycam> ... whether the clones are "linked" somehow
08:52:16 <heycam> ... and the spec was not clear on what should happen
08:52:36 <heycam> ed: if you have some kind of interaction, would that update all instances?
08:53:05 <heycam> heycam: I think this will fall out of how we define use in terms of shadow trees
08:53:18 <heycam> ... so it will be clear what's meant to happen, though not sure if that will be the desirable behaviour or not
08:53:47 <heycam> ed: Blink builds the cloned tree, then strips out the disallowed elements
08:54:03 <heycam> heycam: so that could affect how CSS selectors match things in the tree?
08:54:04 <heycam> ed: yes
08:54:42 <heycam> heycam: so maybe force them display:none instead?
08:56:17 <heycam> heycam: when we define in terms of web components it's very likely these will be independent cloned subtrees
08:56:29 <heycam> ... since shadow dom doesn't support the kind of unified tree that SVG tried to have
08:56:47 <heycam> ... if that's the case, then the videos etc. will all be independent, and there should be no problems
08:58:46 <heycam> ed: ok. in that case I'll just remove the issue, and reword it to mention expected behaviour with independent clones
08:59:23 <heycam> cyril: I saw a small issue about unknown elements -- in embedded content it has a mention of not rendering unknown elements
09:00:36 <heycam> Topic: Media fragments issues
09:00:42 <BogdanBrinza> sample: http://jsfiddle.net/boggydigital/gcthq51u/show/
09:01:07 <heycam> BogdanBrinza: I'd like to discuss each of these issues
09:01:10 <BogdanBrinza> chapter: https://svgwg.org/svg2-draft/linking.html
09:01:36 <heycam> BogdanBrinza: no discussion needed for issues 4 and 5 in the chapter
09:01:42 <BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue6
09:02:06 <heycam> ... currently transforms on svgView does something weird
09:02:17 <heycam> ... in Chrome/Edge it's consistent, and looks like it's scaling from the 0,0 of the original image
09:02:27 <heycam> ... in Firefox it looks like it's applying from the 0,0 point of the viewBox transformed image
09:02:36 <heycam> ... in the sample I've pasted, it's the third picture
09:03:09 <heycam> heycam: the question then is what's the order of the viewBox transform and transform attribute transform?
09:03:10 <heycam> BogdanBrinza: yes
09:04:01 <heycam> heycam: I would expect the order to be the same as if you had <svg viewBox="..." style="transform: ..."> in the document itself
09:04:06 <heycam> BogdanBrinza: I think Firefox's behaviour makes more sense
09:04:28 <heycam> ... the spec also doesn't mention anything about transform-origin
09:04:38 <heycam> ... that's issue 7
09:04:38 <BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue7
09:04:52 <heycam> ... without transform-origin, the usefulness of this is limited
09:04:56 <heycam> ... harder to get the transform you want
09:05:17 <heycam> ... so I think we should support transformOrigin at least in the view spec
09:06:49 <heycam> ... if we do want to continue allowing transform(), I suggest we should bring along those other features like transform-origin
09:08:09 <heycam> heycam: if you don't specify in transform-origin, would it be relative to 50% 50%
09:08:18 <heycam> BogdanBrinza: yes I would say it should match what happens on the root <svg> element, so 50% 50%
09:09:22 <heycam> BogdanBrinza: the other one is perspective
09:09:41 <heycam> ... I would say either add transform-origin/perspective, or remove transform
09:11:04 <heycam> heycam: supporting perspective here sounds a bit more complex
09:21:56 <heycam> BogdanBrinza: with my implementor hat on, I would be worried about that complexity
09:25:10 <heycam> ... I would be fine with the current set of view spec features, so not adding transform-origin/perspective for now
09:25:18 <heycam> ... unless we hear demand for it
09:29:35 <heycam> RESOLUTION: We won't add transform-origin/perspective values for view specs.
09:29:38 <heycam> yet
09:30:17 <heycam> RESOLUTION: viewspec's transform applies after performing the viewbox transform
09:30:32 <BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue8
09:31:04 <heycam> BogdanBrinza: this says spaces are not allowed, and semicolons separate fragments "may" be URL escaped
09:31:09 <heycam> ... it looks like spaces are accepted in the browsers
09:31:19 <heycam> ... at least in Firefox/Blink/Edge
09:31:38 <heycam> ... for URL escaping, it doesn't work in Blink but does in Firefox and Edge
09:32:40 <heycam> heycam: I think we don't need to talk about escaping
09:32:46 <heycam> ... that happens at a layer before the spec cares about it
09:33:00 <heycam> ... I'm fine with allowing spaces since everyone does
09:36:01 <tkonno_> tkonno_ has joined #svg
09:36:52 <BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue8
09:37:01 <heycam> scroll down from that to the second issue 5
09:37:18 <heycam> BogdanBrinza: xywh allows pixels (default) or percents
09:37:24 <heycam> ... how do these map to SVG units?
09:38:45 <heycam> heycam: I think xywh applies at the CSS image level
09:39:10 <heycam> ... so percentages should resolve against whatever size of image that CSS is going to tile/position/etc. from the background-* properties
09:39:14 <heycam> ... not sure what the right term is
09:39:24 <BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue9
09:39:51 <heycam> BogdanBrinza: when referencing a specific view, the spec talks about getting the view of the closest ancestor SVG element displayed in the viewport
09:40:05 <heycam> ... what is the expected effect if the closest ancestor svg is not the root element?
09:42:38 <heycam> heycam: I'm not sure just updating the inner <svg>'s viewBox etc. attributes gives you useful behaviour
09:47:17 <heycam> BogdanBrinza: it's a bit confusing that it applies to the inner <svg>. the position of the <view> element in the document would affect what's happening
09:56:33 <heycam> RESOLUTION: The view element always applies to the outermost <svg>, even when inside an inner <svg>.
09:56:34 <BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue10
09:58:11 <heycam> heycam: this about whether missing viewspec values get set to their initial value, or whether the document's value is used
09:59:19 <heycam> ed: I think you get strange results if you blow away everything
09:59:23 <heycam> ... I think you don't want to do that usually
09:59:28 <heycam> ... and you just want to override one of them
09:59:36 <heycam> ... if you blow off the viewBox for example it's going to be very strange
09:59:45 <heycam> BogdanBrinza: looks like we agree that it should override specific attributes then
10:00:00 <heycam> RESOLUTION: Missing viewspec values use the values specified in the document, not resetting them back to their defaults.
10:10:42 <BogdanBrinza> BogdanBrinza has joined #svg
10:20:01 <ed> ed has joined #svg
10:26:33 <Zakim> Zakim has left #svg
11:30:26 <jdaggett> jdaggett has joined #svg
11:57:34 <ed_work_> http://xn--dahlstrm-t4a.net/svg/structure/base/base.svg
11:58:59 <tkonno> tkonno has joined #svg
11:59:05 <ed_work_> http://xn--dahlstrm-t4a.net/svg/structure/xmlbase/xmlbase.svg
12:11:13 <heycam> TabAtkins, where is it defined that url() values in properties are resolved against the document's base (as given by <base>)? and does this apply to every property that takes a url()?
12:13:37 <BogdanBrinza> http://pastebin.com/vpYSzfZm
12:15:24 <heycam> ScribeNick: heycam
12:15:33 <heycam> Topic: zoom media features
12:18:20 <tkonno> http://rawgit.com/satakagi/mediaQueryZoom/master/index.html
12:18:56 <heycam> tkonno: this presentation will udpate you on the proposal for zoom features for media queries
12:19:25 <heycam> ... Takagi-san sent an email to www-style with this draft spec
12:19:40 <TabAtkins> heycam: https://drafts.csswg.org/css-values/#relative-urls
12:19:57 <heycam> ... for changing style and contents according to zoom ratio
12:20:01 <heycam> ... we've written a polyfill
12:20:48 <heycam> ... we'd like to bring this initial draft to an editor's draft
12:20:52 <heycam> ... let's go through some use cases
12:21:07 <heycam> ... two use cases here: mapping, and high resolution photos
12:21:12 <heycam> ... at KDDI we're interested in mapping using SVG
12:21:28 <tantek> tantek has joined #svg
12:21:28 <heycam> ... for mapping, when the map is zoomed out, the user wants to know only the overview of that area
12:21:44 <heycam> ... otoh, when the map is zoomed in, the user wants to know the detail of the area, such as some landmarks
12:22:01 <heycam> ... as you know, map content is made up from different layers
12:22:06 <heycam> ... base map, plus other layers on top
12:22:22 <heycam> ... if the content layers are switched according to zoom, the user can get the appropriate information
12:22:30 <heycam> ... the function to switch the content layer is essential for mapping
12:22:44 <heycam> ... second use case is high resolution photos
12:22:49 <heycam> ... here's an example from MS
12:23:02 <heycam> ... this is a smoothly zoomable high resolution image
12:23:20 <heycam> ... when zoomed in, it uses a high resolution image
12:23:46 <heycam> ... currently, these use cases are realized by massive.js or standards other than web standards
12:23:52 <heycam> ... so we'd like to realize these use cases using web standards
12:24:10 <heycam> ... so how can we do this?
12:24:24 <heycam> ... the min-zoom feature is a new media feature
12:24:39 <heycam> ... its value (ZoomRatio) is a threshold
12:25:03 <heycam> [see presentation for example code]
12:25:32 <heycam> ... I'll explain what's meant by "zoom" here
12:25:51 <heycam> ... zoom functionality is divided into two types: one is the UA native zoom, and the other is the web app's zoom
12:26:15 <heycam> ... UA native page zoom affects the initial viewport size
12:26:35 <heycam> ... pinch zoom is also something controlled by the UA, but this doesn't affect the viewport size
12:26:40 <heycam> ... it behaves like a magnifying glass
12:26:56 <heycam> ... as for the web app's zoom, CSS Transforms can control the scale of the contents
12:27:17 <heycam> ... so the zoom should be represented as a combination of UA's zoom and the web app's zoom
12:27:37 <heycam> [formula in the presentation relating the device pixel size and all these zooms]
12:28:16 <heycam> I'm not sure whether all 6 of the types of zooms I've listed in the presentation are useful
12:28:24 <heycam> s/I'm/tkonno: /
12:28:36 <heycam> ... for the mapping use case, document-zoom is the useful one
12:29:03 <heycam> ... for the other zoom types depends on the use cases
12:29:09 <heycam> heycam: and for the high resolution image use case?
12:29:15 <heycam> tkonno: document-zoom too
12:29:39 <heycam> ... the zoom property has already been included in the CSS Device Adaptation spec
12:30:24 <cyril> http://www.w3.org/TR/css-device-adapt/
12:31:06 <heycam> heycam: not sure if people implement CSS Device Adaptation, so not sure I would worry about compatibility with it
12:31:17 <heycam> tkonno: so I think only document-zoom is needed for our use case
12:31:34 <heycam> ... so that includes pinch zoom and CSS Transforms
12:32:14 <heycam> cyril: what about currentScale?
12:32:24 <heycam> heycam: I imagine that, viewBox transform, etc. would all be included, since you're including transform property
12:32:35 <heycam> tkonno: so why do we need document-zoom feature?
12:33:00 <heycam> ... a web page might have map content in an iframe. the user might zoom in the whole web site, not just transform the embedded element
12:33:16 <heycam> ... but the user could also just scale the iframe's contents
12:33:52 <heycam> tkonno: so I'd like to know if the concept is acceptible, and whether the document-zoom feature proposal specifically is acceptable?
12:34:27 <heycam> BogdanBrinza: at the last F2F, we had some private discussions about the use cases here. we agree the use cases are valuable.
12:34:34 <heycam> ... the way we've been thinking about this is focussed on the performance
12:34:43 <heycam> ... for the zoom features, you want to have this as late in the pipeline as possible
12:34:47 <heycam> ... at the display level, if possible
12:35:22 <heycam> ... in terms of types of zoom feature, I'm not sure I agree we need more than one type
12:35:29 <heycam> ... the resulting content, in any form, would have the transform available on it
12:35:51 <heycam> ... either you transform the whole document, or an iframe, or just one element -- the content you care about will have a transform available
12:35:56 <heycam> ... so I don't think we need many zoom types
12:36:08 <heycam> ... so selecting the zoom for a specific element itself
12:36:56 <heycam> birtles: in the proposal, document-zoom is the only one needed
12:37:15 <heycam> ... the only reason for proposing (1) was for consistency with CSS Device Adaptation, but per discussion, that's not important
12:37:26 <heycam> BogdanBrinza: the other comment is that there are various other display time conditions you might want to target
12:37:40 <heycam> ... inertia of scroll, for example; hide elements based on the speed you're panning currently
12:37:49 <heycam> birtles: that'd be an orthogonal media feature?
12:37:52 <heycam> BogdanBrinza: yes. there might be others.
12:38:10 <heycam> ... but yes, we find it acceptable to discuss this further
12:39:00 <heycam> birtles: konno-san previously summarised discussion up to now in a wiki page, at TPAC 2 years ago there was an action on someone to think about all the different types of zooming
12:41:22 <nikos> scribenick: nikos
12:41:26 <nikos> Scribe: Nikos
12:41:37 <nikos> Topic: Behaviour of getCTM on root svg element
12:41:54 <nikos> heycam: one of the two remaining open issues in types chapter is what getCTM should do whne called on root svg element
12:42:04 <nikos> and what getScreenCTM should do altogether
12:42:08 <nikos> ... it's really the same issue
12:42:23 <nikos> ... getCTM gives transform from current element to closest ancestor svg or viewport establishing element (maybe)
12:42:34 <nikos> ... though not clear what happens if you call it on outermost svg element
12:42:50 <nikos> ... you have viewbox, transform property, etc
12:43:01 <nikos> ... all of these things may or may not be intended to be included in the result
12:43:06 <nikos> ... I made some test cases
12:43:14 <nikos> ... linked on the agenda page
12:43:22 <nikos> ... first is when svg element has no attributes
12:43:32 <heycam> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Paris_2015/Agenda
12:43:36 <heycam> http://mcc.id.au/temp/ctm.svg
12:43:39 <heycam> http://mcc.id.au/temp/ctm-viewbox.svg
12:43:43 <heycam> http://mcc.id.au/temp/ctm-transform.svg
12:43:47 <heycam> http://mcc.id.au/temp/ctm-currentScale.svg
12:43:58 <nikos> ... FF returns null when you call getCTM on root element
12:44:06 <nikos> ... all others return something, but differ on what transforms are included
12:44:47 <nikos> ... first example in Chrome returns identity, in IE11 identity, same in Safari I think
12:44:57 <nikos> ... that's the simple case - no features that would have a transform
12:45:04 <nikos> ... so at least we're getting a reasonable result there
12:45:12 <nikos> ... second example - with viewBox attribute
12:45:38 <nikos> ... Chrome appears to give transform that implements the viewBox - incorporates pAR
12:46:30 <nikos> ... Safari also gives useful values
12:46:41 <nikos> ... so I think all the browsers that implement it are including the viewBox
12:46:49 <nikos> ... next one is with the transform property applied
12:47:01 <nikos> ... I think some browsers don't do transform as a presentation attribute on svg elements
12:47:13 <nikos> ... Chrome doesn't included it, Edge is the same
12:47:19 <nikos> ... Safari is also identity matrix
12:47:24 <nikos> ... so no one is including the transform property
12:47:35 <nikos> ... but the transform property is kind of new and getCTM is old
12:47:48 <nikos> ... finally, the currentScale value, Chrome also doesn't included that
12:47:55 <nikos> ... but Edge and IE11 do
12:48:04 <nikos> ... Safari does not
12:48:22 <nikos> ... are there any other transforms that I've forgotten about? that work on the root element?
12:48:30 <nikos> ... perhaps the ones that come from the view fragment.
12:48:38 <nikos> BogdanBrinza: CSS zoom property?
12:48:49 <nikos> heycam: don't think we implement that
12:49:01 <nikos> ... thought it wasn't clear what zoom was supposed to do
12:49:13 <nikos> BogdanBrinza: legacy IE and Chrome supports it
12:49:40 <nikos> heycam: So what thing should be included in the getCTM?
12:49:44 <nikos> ... is the answer all of these things?
12:50:04 <nikos> ... if you think about what getCTM means for other elements in the document. It means give me the transform up to some thing
12:50:21 <nikos> ... so my feeling is that including all of the viewBox and transform properties would make sense
12:50:40 <nikos> ... transform is the one that no one includes currently, but I think it makes sense to include it
12:50:50 <nikos> BogdanBrinza: doesn't make sense to include all others but not transform
12:51:34 <nikos> cyril: I guess you want it to be consistent if you copy the SVG into another file
12:51:47 <nikos> ... there's localisation of the transform
12:52:07 <heycam> https://svgwg.org/svg2-draft/types.html#__svg__SVGGraphicsElement__getCTM
12:53:46 <nikos> heycam: One way I was considering dealing with getScreenCTM was to take all the transforms from viewport establishing elements and multiply them together to give the screenCTM
12:54:27 <nikos> BogdanBrinza: when would you want to use this?
12:55:10 <nikos> heycam: one thing might be with mouse events - transform clientX,clientY by getScreenCTM should give you window co-ordinates right?
12:55:17 <nikos> BogdanBrinza: that's done by screenX,screenY
12:55:44 <nikos> BogdanBrinza: I really can't imagine a scenario
12:56:02 <nikos> heycam: one thing I've done before is create some UIs
12:56:18 <nikos> ... and have some content that is at a fixed size and position in the window irrespective of zoom and pan, etc
12:56:29 <nikos> ... these days you'd probably take that out of the svg document and use position:fixed
12:57:44 <nikos> BogdanBrinza: I can't see why you would want to keep something in the SVG file that must be relative to the screen
12:58:05 <nikos> ... any scenarios in InkScape?
12:58:14 <nikos> Tav:
12:58:21 <nikos> Tav: can't think of anything
12:59:45 <nikos> heycam: I think the only two viable options are to return a matrix that includes all the transforms, or none of the transforms
13:00:04 <nikos> ... talking about getCTM here
13:00:12 <nikos> ... getScreenCTM has a more clear meaning
13:00:25 <nikos> ... I haven't done testing with getScreenCTM to ensure all these transforms are included
13:00:42 <nikos> BogdanBrinza: I would argue for having all of the transforms
13:01:08 <nikos> ... the transforms have meaning and that's what would be expected from getCTM
13:01:10 <nikos> heycam: I agree
13:01:57 <heycam> RESOLUTION: getCTM will return a matrix with viewBox, transform property and currentScale/currentTranslate included
13:02:54 <nikos> cyril: If you take an svg element with a viewBox and nest it within another svg element with the same attributes, the CTM is the same for the inner and outer SVG
13:02:59 <nikos> ... I just tested this
13:03:04 <nikos> ... in Chrome
13:03:51 <heycam> ScribeNick: heycam
13:03:53 <heycam> Scribe: Cameron
13:04:00 <heycam> Topic: changing overflow behaviour of markers in UA style sheet
13:04:12 <heycam> nikos: as much as I hate bringing up old conversations.
13:04:26 <heycam> ... previously we said marker { overflow:hidden } would be removed from the UA style sheet
13:04:38 <heycam> ... creating markers around (0,0) seems useful
13:04:53 <heycam> ... the issue is how much content would that break? do we want to go ahead with this?
13:05:01 <heycam> Tav: I think the decision was a bit wishy-washy
13:05:30 <heycam> heycam: and overflow:hidden is uniformly applied to markers in implementation?
13:05:31 <heycam> nikos: yes
13:05:51 <heycam> heycam: perhaps let's not tempt fate then
13:06:15 <heycam> nikos: so keeping overflow:hidden for markers and symbol, not the nicest option, but should be the one to go with
13:06:35 <heycam> ... we talked about this for symbols recently -- since we have refX/refY, that helps
13:06:45 <heycam> heycam: and you can always stick overflow:visible on
13:06:55 <heycam> Tav: Chris was for it, at the time
13:07:07 <heycam> heycam: I'm happy to leave it as it is
13:07:44 <heycam> RESOLUTION: We will leave overflow:hidden in the UA style shet for marker and symbol
13:08:33 <heycam> Topic: initial clipping path
13:08:48 <heycam> nikos: there's a section in the Rendering chapter defining the "initial clipping path", as being on the <svg> element as a result of overflow:hidden
13:08:53 <heycam> ... the term doesn't get used anywhere really
13:08:59 <heycam> ... there's one reference to it in the coords chapter
13:09:03 <heycam> ... but it doesn't say much
13:09:24 <heycam> Tav: was that to avoid a huge clipping path?
13:09:29 <heycam> nikos: no, it's just a term that's defined that isn't used
13:09:37 <heycam> heycam: just get rid of it
13:11:08 <heycam> Topic: base and xml:base
13:11:16 <ed_paris> http://xn--dahlstrm-t4a.net/svg/structure/base/base.svg
13:11:28 <heycam> ed: here's an example showing HTML <base> element applying inside an SVG file
13:11:35 <heycam> ... it shows a selection of SVG element using some kind of URL resource
13:11:48 <heycam> ... we have <image>, the first example
13:11:55 <heycam> if it says "base" it is using the base to resolve the url
13:12:31 <heycam> ... for the textPath example, it will show upside down text if base is applied
13:12:53 <heycam> ... for the a element, just look at the URL if it has "resources" in it it's using base
13:13:03 <heycam> ... for the last one, green means using base
13:13:49 <heycam> ed: so Firefox support <base> for all of these cases
13:14:15 <heycam> ... for Blink, it works in some cases, not all -- textPath is not using base
13:14:28 <heycam> ... there might be a bug for the fills, it should show red if base is not applied, but it's showing blank
13:15:00 <heycam> https://drafts.csswg.org/css-values/#relative-urls
13:16:14 <heycam> heycam: so according to the spec, all url() values resolve against the document's base (if inline style sheet), or the style sheet url (if external style sheet)
13:18:31 <TabAtkins> No, against the *element's* base (for inline)
13:18:41 <TabAtkins> (which usually is the document's base)
13:19:01 <heycam> ok. yeah, considering xml:base.
13:19:08 <TabAtkins> yeah
13:25:06 <heycam> TabAtkins, does CSS have any value syntax that means "reference to element with an ID in the document"?
13:25:12 <heycam> to use in place of url(#x)?
13:25:15 <heycam> like element(x)?
13:26:25 <TabAtkins> element() takes an id selector in the first place
13:26:28 <TabAtkins> element(#x)
13:26:33 <heycam> ooh
13:26:33 <heycam> ok
13:27:48 <TabAtkins> But it's an <image> value.
13:27:52 <TabAtkins> Not for arbitrary usage.
13:27:54 <heycam> oh
13:28:24 <ed_paris> http://stackoverflow.com/questions/1889076/is-it-recommended-to-use-the-base-html-tag/1889898#1889898
13:41:24 <cyril> https://tools.ietf.org/html/rfc3986#page-28
13:41:51 <cyril> the important section is section 5
13:41:52 <heycam> BogdanBrinza: does anybody disagree with just following the existing CSS rules for resolving relative URLs?
13:42:05 <heycam> heycam: no, that's the behaviour I would prefer. I don't want special behaviour for SVG properties.
13:46:29 <ed_paris> https://svgwg.org/svg2-draft/struct.html#issue61
13:52:26 <heycam> [Bogdan shows an example of background-image:url(#) resolving against a base URL that points to a PNG]
13:52:46 <heycam> RESOLUTION: fill:url(#something) is resolved against the base URL, just like other CSS properties.
13:53:29 <heycam> ACTION: Erik to add a note to the spec for authors to beward of url(#localid) resolving against the base URL.
13:53:29 <trackbot> Created ACTION-3816 - Add a note to the spec for authors to beward of url(#localid) resolving against the base url. [on Erik Dahlström - due 2015-09-01].
13:53:39 <heycam> ed: next is xml:base
13:53:51 <ed_paris> http://xn--dahlstrm-t4a.net/svg/structure/xmlbase/xmlbase.svg
13:54:05 <heycam> ed: this is more inconsistent across browsers
13:54:14 <heycam> ... Blink doesn't seem to apply xml:base anywhere
13:55:05 <heycam> BogdanBrinza: Edge is the same as Chrome
13:55:15 <heycam> ed: Firefox is applying it everywhere
13:56:42 <birtles> https://code.google.com/p/chromium/issues/detail?id=341854
13:56:46 <heycam> heycam: I would be happy to remove it
13:58:35 <heycam> birtles: from Anne's comments in there, since Blink has already removed it, it sounds like it should be removed from DOM/HTML
13:58:47 <birtles> specifically comment 12
13:59:15 <heycam> RESOLUTION: Remove xml:base.
14:06:40 <TabAtkins> +1
14:06:47 <ed_paris> RRSAgent, pointer?
14:06:47 <RRSAgent> See http://www.w3.org/2015/08/25-svg-irc#T14-06-47
14:15:39 <BogdanBrinza> pasting example we've used to check CSS # resource resolution: http://pastebin.com/AZmNc7EC (uncomment placehold.it and comment svg to switch between the two)
14:15:42 <BogdanBrinza> http://pastebin.com/AZmNc7EC
14:20:55 <ed_paris> https://css-tricks.com/tight-fitting-svg-shapes/
14:34:02 <Zakim> Zakim has joined #svg
14:35:39 <birtles> Zakim, remind me to ask, "Is it Fika Nu?" in 23 hours
14:35:40 <Zakim> I don't understand you, birtles
14:36:07 <birtles> Zakim, remind me in 23 hours to ask, "Is it Fika Nu?"
14:36:07 <Zakim> ok, birtles
14:47:45 <heycam> RRSAgent, make minutes
14:47:45 <RRSAgent> I have made the request to generate http://www.w3.org/2015/08/25-svg-minutes.html heycam
14:48:02 <heycam> Meeting: SVG Working Group Paris F2F 2015, day 2
14:48:04 <heycam> Chair: Cameron
14:48:09 <heycam> Scribe: Cameron, Nikos
14:48:16 <heycam> RRSAgent, make minutes
14:48:16 <RRSAgent> I have made the request to generate http://www.w3.org/2015/08/25-svg-minutes.html heycam
14:48:37 <heycam> Present: Cameron, Tomo, Tav, Nikos, Brian, Cyril, Erik, Bogdan
14:48:38 <heycam> RRSAgent, make minutes
14:48:38 <RRSAgent> I have made the request to generate http://www.w3.org/2015/08/25-svg-minutes.html heycam
14:49:51 <heycam> ACTION-3724: see discussion in http://www.w3.org/2015/08/25-svg-minutes.html#item05
14:49:51 <trackbot> Notes added to ACTION-3724 Do testing around currentscale, ctm, transform, viewport, etc. on 'svg' element.
14:49:56 <heycam> trackbot, close ACTION-3724
14:49:57 <trackbot> Closed ACTION-3724.
14:53:10 <BogdanBrinza> http://pastebin.com/kE2nK1bV
15:04:29 <ed_work_> ed_work_ has joined #svg
15:28:56 <BogdanBrinza_css> BogdanBrinza_css has joined #svg
15:52:37 <BogdanBrinza> BogdanBrinza has joined #svg
16:02:27 <BogdanBrinza> BogdanBrinza has joined #svg
16:14:22 <heycam> BogdanBrinza: we will go for a drink somewhere close to the office, but not yet decided where. text me when you are ready on +61438006735 and I'll let you know.
16:19:36 <BogdanBrinza> BogdanBrinza has joined #svg
16:27:19 <tantek> tantek has joined #svg
16:40:21 <nikos> BogdanBrinza: we are in cafe Indiana, 2 doors down from the office
16:43:36 <Tav> Tav has joined #svg
17:30:46 <tantek> tantek has joined #svg