07:01:47 RRSAgent has joined #svg 07:01:47 logging to http://www.w3.org/2012/09/17-svg-irc 07:01:49 RRSAgent, make logs public 07:01:49 Zakim has joined #svg 07:01:51 Zakim, this will be GA_SVGWG 07:01:51 I do not see a conference matching that name scheduled within the next hour, trackbot 07:01:52 Meeting: SVG Working Group Teleconference 07:01:52 Date: 17 September 2012 07:03:04 Meeting: SVG WG Switzerland F2F Day 1 07:03:07 Chair: Cameron 07:03:45 birtles has joined #svg 07:04:22 Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Agenda 07:06:06 krit has joined #svg 07:06:31 Zakim, krit is me :D 07:06:31 I don't understand 'krit is me :D', krit 07:09:22 Tav has joined #svg 07:10:39 nikos has joined #svg 07:11:11 scribenick: nikos 07:11:49 Topic: Pass Path object to SVG path 07:11:49 stakagi has joined #svg 07:12:22 krit: It would be better to discuss this when Tab is here 07:12:26 Topic moved 07:13:12 Topic: Linking to external style sheets — should we have ? 07:13:38 heycam: I was wondering, in the spec at the moment (1.1), it says if you want to reference external stylesheets you should use xml processing instruction 07:13:42 ... we should have another way as well 07:13:47 ... we at least need to say @import works 07:13:55 ... referencing css should get that for free 07:14:23 krit: Is it not possible currently? 07:14:27 heycam: You can 07:15:32 s/can/can't/ 07:16:18 heycam: you can't use the xml stylesheet processing instruction in html so we should decide what is the prefered way to link to external stylesheets 07:16:27 ... one option is to have link in svg, just like in html 07:16:35 birtles: yes 07:16:57 ed: What would happen if you copy pasted svg with link element into html5 07:17:30 ... link is current an html element so if you pasted svg that is using it into html would it go back to html? 07:17:40 ... you can create it with the dom or put it in a foreignObejct 07:17:51 s/foreignObejct/foreignObject 07:17:58 heycam: it seems to work in firefox 07:18:57 heycam: I was testing whether the parser breaks out into html 07:19:01 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Csvg%3E%3Clink%3E%3Cscript%3Ew(document.getElementsByTagName(%27link%27)%5B0%5D.namespaceURI)%3C%2Fscript%3E 07:19:13 shepazu: Isn't there a white listing of svg elements? or is that just for changing case? 07:19:22 heycam: Yes, just changing case 07:19:47 krit: what happens if you move the node in the DOM? 07:20:02 heycam: I think the link element in the html namespace doesn't have any effect at the moment 07:20:29 ... if you try and reference some stylesheet would it work? 07:20:48 ... it looks like the way it behaves is - you can have it anywhere in the document 07:21:00 ... if we want it to work we specify it the same way except it's in the svg namespace 07:21:29 andreas has joined #svg 07:21:40 victor has joined #svg 07:21:42 ... I think we are eventually going to have a bunch of these elements that either share or that can work in both svg and html namespaces 07:21:57 krit: I'm just testing safari, if you put a link elements it's in the svg namespace 07:22:55 heycam: what do you think of the idea dirk? 07:23:11 krit: I like it but I'm wondering what happens when you move nodes in the DOM 07:23:41 ... I'm a bit afraid the namespace won't change if you move it in the DOM 07:23:48 heycam: nothing changes automatically when you move it 07:23:52 krit: and is that ok? 07:24:11 shepazu: henry will complain about changes to the parser - are there any? 07:24:18 heycam: not for this because it's already in the svg namespace 07:24:25 ... maybe it would be a problem if it broke out 07:24:30 s/henry/henri/ 07:24:32 krit: I wish to have the link element 07:24:40 heycam: it gets put in the html namespace 07:24:59 ... you can't declare namespaces explicitly but the dom nodes get created in the namespace 07:25:20 shepazu: I think the reason for doing it this way is to allow authors to do it without thinking about it - they already know how to do it in html 07:25:28 heycam: I think it would work nice and obviously 07:26:07 cabanier: it works in Chrome 07:27:06 shepazu: if that's true, we should match that user agent 07:28:01 heycam: I couldn't get it work in Chrome 07:28:48 cabanier: I know it loads the sheet (can see it in the debugger) but I don't know if it applies it 07:28:56 ... so it's like half implemented 07:30:04 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Csvg%3E%3Clink%20rel%3Dstylesheet%20href%3D%22data%3Atext%2Fcss%2Ccircle%20%7Bfill%3Agreen%7D%22%20type%3D%22text%2Fcss%22%20%2F%3E%3Ccircle%20cx%3D50%20cy%3D50%20r%3D20%20fill%3Dred%20%2F%3E 07:30:09 heycam: anyone think it's bad idea 07:30:12 all: no 07:30:20 shepazu: we should ask the html working group 07:30:28 heycam: we should ask them if there is anything we haven't thought of 07:30:54 Resolution: We will add a link element to SVG that behaves in the same way as HTML 07:32:00 Action: Cameron to email the HTML and WhatWG working groups to ask if there any problems related to adding the HTML link element into SVG 07:32:00 Created ACTION-3351 - Email the HTML and WhatWG working groups to ask if there any problems related to adding the HTML link element into SVG [on Cameron McCormack - due 2012-09-24]. 07:32:21 konno has joined #svg 07:33:23 Topic: enable-background naming in relation to compositing and blending 07:33:35 cabanier: The name is a bit confusing 07:33:44 ... it doesn't match what users are familiar 07:33:50 ... in the compositing spec it was replaced with isolation 07:34:16 ... so we have the existing enable-background keyword, we can't get rid of it or it will break content 07:34:22 ... we were thinking of having it shadow 07:34:26 ... like an alias 07:34:35 krit: css wg tries to define shadowing properly 07:34:47 ... they have the same problem for some text properties 07:35:37 andreas has joined #svg 07:36:01 nikos: we are thinking that the property should apply to compositing and blending and filter effects 07:36:08 ... you shouldn't be able to specify different modes for each 07:36:28 heycam: so there's 2 issues really, having the property apply to both and the naming 07:36:37 heycam: do you have an example of css shadowing? 07:36:56 krit: not yet, we don't have a specification, but the css wg have expressed an interest in the idea 07:37:05 heycam: what about if you use the css om to look up property values? 07:37:18 ... like there's a single variable underneath but there's 2 properties 07:37:30 krit: the question is which takes effect if both are specified 07:37:34 cabanier: I think the last one wins 07:39:24 ... what happens currently if you say 'opacity=1 opacity=0.5'? 07:39:51 heycam: what happens currently for prefixed and not when you support them both? 07:40:03 krit: they are both in the style declaration as far as I know 07:40:08 heycam: with one underlying variable? 07:40:17 krit: I'll have to check 07:40:30 heycam: I assume the css working group wants to define how this works and not us 07:40:37 cabanier: so are we ok combining them? 07:40:47 heycam: I think so - as long as enable-background works for existing things 07:40:59 ... so enable-background has numbers when you specify new? or did we get rid of that 07:41:03 krit: we got rid of that 07:41:35 krit: looking at the source code - we treat them as different properties 07:42:09 ... for box-shadow and webkit-box-shadow we have two different style declarations 07:42:23 ... you can set box-shadow and webkit-box-shadow and they can be different 07:42:36 ... when rendering one will win but I'm not sure which 07:42:47 heycam: I think that as long as it is worked out then I'm ok with it 07:43:01 cabanier: do we know who is working on the shadowing? 07:43:08 krit: no, we'll have to ask 07:44:07 Resolution: We want isolation property to shadow enable-background and we will ask the CSS working group about the details 07:44:19 Action: Rik to ask CSS WG about how shadowing will work for enable-background 07:44:19 Created ACTION-3352 - Ask CSS WG about how shadowing will work for enable-background [on Rik Cabanier - due 2012-09-24]. 07:45:02 krit: I think we will put both properties in Filter Effects and mark one as preferable 07:45:24 nikos: So is it ok for one property to control both filter-effects and compositing and blending? 07:45:28 all: yes that's ok 07:46:03 Resolution: The enable-background/isolation will apply to both Filter Effects and Compositing and Blending 07:46:34 Topic: Filter Effects - keep new fe*elements that lack description ATM? 07:47:04 https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feUnsharpMaskElement 07:47:17 https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feDiffuseSpecularElement 07:47:35 krit: We have different filter effects that lack definition and I would like to know if we want to keep them and add description or is it not neccesary? 07:47:54 ... I'm just talking about filter primitives and not the shorthands 07:48:15 cabanier: does anybody implement these? 07:48:17 krit: no 07:48:28 krit: we are about to implement feCustom 07:48:33 heycam: who wanted them ? 07:48:48 ed: diffuse specular was meant to be an optimisation to give better performance 07:48:58 ... I'm not sure if it's really needed as the filter chain does the optimisation 07:49:08 heycam: would it make it better for authors? 07:49:11 ed: probably not 07:49:17 heycam: I say get rid of them then 07:49:31 ed: I don't mind removing them if they don't seem to be useful 07:50:37 ed: you could do feUnsharpMaskElement with scripting and other filter effects 07:50:41 ... but we don't have a shorthand for it 07:50:46 Resolution: Remove feUnsharp and feDiffuseSpecular from Filter Effects specification for now - may be added again in future 07:50:54 https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterFunction 07:51:05 Topic: Filter Functions 07:51:19 are other shorthands needed? 07:51:36 krit: The question is do we put in a bug report on Safari for functions that are not implemented? 07:52:07 s/filter chain does the optimisation/implementation can analyze the filter chain and do the same optimisation 07:52:25 krit: I had suggestions for other filter functions that we could have, but I have not had any feedback 07:52:31 ... so I'm wondering if we can remove the issue 07:53:02 heycam: it doesn't hurt to keep it in, but if you're wanting to finalise and go to last call then you can remove it 07:53:10 krit: there's no problem adding new shorthands in the later version 07:53:17 ... the question is do we freeze what we have now? 07:53:28 heycam: I think the set that is there currently is a reasonable set 07:54:20 Resolution: Remove filter function suggestions (issue 5) from Filter Effects spec 07:55:03 Action: Dirk to file a bug and track filter functions (issue 5) removed from Filter Effects spec 07:55:04 Created ACTION-3353 - File a bug and track filter functions (issue 5) removed from Filter Effects spec [on Dirk Schulze - due 2012-09-24]. 07:55:53 Topic: Removing pixelUnitToMillimeter{X,Y} and screenPixelToMillimeter{X,Y} 07:56:06 heycam: I didn't know this existed and I'm not sure anyone would use these API functions 07:56:09 krit: Is anyone using them? 07:56:14 heycam: I'm not sure, I can check. 07:56:30 andreas: is there an alternative way to get at the pixel size? 07:56:48 heycam: I think not but I think it's been discussed in the CSS WG whether you should access the real DPI and do something based on that 07:56:57 cabanier: you mean the HD stuff? 07:56:59 heycam: I'm not sure 07:57:03 krit: so why do you want to remove it? 07:57:17 heycam: our implementation returns a constant value assuming 96 dpi. 07:57:22 cabanier: what does webkit do? 07:57:25 krit: the same thing 07:57:58 cabanier: it could be implemented to not be constant in the future - for HD devices 07:58:26 krit: the idea is that we want to know how many mm it is on the screen 07:58:36 shepazu has joined #svg 07:58:40 heycam: I remember people objecting to that in some other context 07:59:00 cabanier: how do you know what the screen size is? 07:59:44 krit: Firefox used to expose that information in an API but removed it. 07:59:54 heycam: now everyone has converged on CSS units being a fixed number of pixels 08:00:08 krit: the problem is that some platforms don't give you the exact DPI, so it could not be implemented on some platforms 08:01:00 heycam: I think one of the problems with physical units is you want to know it for different reasons - like touch events (finger size) and font size (but how far away are they from the screen) 08:01:16 krit: I don't know how they would be used 08:01:45 shepazu: you'd be surprised - some people implement for one browser and if it's implemented in one browser it gets used 08:02:04 ed: Opera is hard coded also 08:02:28 ... I think it's the same value as other implementations 08:03:04 krit: the css working group is looking into ways to get screen pixels per CSS pixel. 08:03:15 heycam: but it doesn't tell you the physical size 08:03:35 cabanier: are you going to remove pixels per inch as well? 08:03:43 heycam: yep there's not 4 methods 08:03:59 cabanier: I think somebody somewhere is using them 08:04:05 ed: I'd be surprised to see them used 08:05:09 heycam: I just googled screenPixelToMillimeterX and got no hits 08:05:14 ... with svg file types 08:05:34 cabanier: I wonder if they will become more useful 08:05:39 ... in future 08:08:01 heycam: I would like to ask the CSS WG what they think about units 08:08:23 krit: the question is how to get the physical size, but I don't think the CSS WG is working on that 08:08:39 heycam: the topic about mm not being real mm anymore comes up often and I'd like to know the details 08:08:55 ... is it because it's probably not what authors want 08:09:15 krit: if I say 2cm but then project it on the wall I don't want it to be 2 cm 08:10:59 heycam: I'll ask Chris 08:12:51 Topic: How to internationalize "title"? 08:13:05 Tav: This came up at SVG open. Someone was asking whether it could be done. 08:13:21 heycam: My first suggestion would be to allow system language on the title element. 08:13:25 ed: that's already done isn't it ? 08:13:30 heycam: I'll look 08:13:42 ... The question is how to internationalise the title 08:13:50 shepazu: how about we use switch? 08:14:33 Tav: how would it work? 08:14:44 shepazu: you would have the switch element with different copies of the titles 08:15:02 heycam: what is switch a child of ? 08:15:13 shepazu: how about we change switch to allow text content ( if it doesn't already) 08:15:36 ... I think switch only works at an element level now and not at a text level 08:15:41 ... I think we should change it to text 08:15:51 ... then you would switch on the actual text content rather than on the element 08:15:57 ... title would be a child element 08:16:27 krit: can you change paragraphs in HTML to change content based on the language? 08:16:31 shepazu: there is no mechanism for doing that 08:16:57 ... since we are changing switch anyway, we could add something like a span that is basically meaningless? We have tspan - it's not a child of title 08:17:10 ... we have a few options 08:17:18 ... we can change switch to have text content, but what is the child element of the switch 08:17:33 ... we can change title apply to the parent of the switch 08:17:50 ... if title is encased in a switch element it jumps up one level - the switch is transparent in regards to the title 08:18:11 Tav: what about the desc element? 08:18:19 shepazu: or tooltip, or whatever 08:18:27 ... they'd be the same 08:18:45 heycam: on switch you can have all the group attributes. 08:18:56 shepazu: people shouldn't use switch for that - you can but you shouldn't 08:19:01 ... switch should be transparent 08:19:12 heycam: I think you should be able to do multiple title elements 08:19:37 ... like 08:19:52 <nikos> ... or have language tags which are subsets 08:20:11 <nikos> ... we could resolve that the first title element that matches the conditional processing attributes is used 08:20:20 <nikos> ... if you want a fallback you have a title without conditional attributes 08:20:25 <ed> just playing a bit with the systemLanguage: http://jsfiddle.net/YueKQ/ 08:20:31 <nikos> ... and resolve that only one title applies to an element 08:20:46 <nikos> shepazu: that's good. So we'd be getting rid of the switch element for this case 08:21:02 <nikos> ... we should tell people, for legacy reasons, always put the default first 08:21:15 <nikos> krit: and instead of systemLanguage can we just use lang? 08:21:30 <nikos> shepazu: it might not be the system language it might just be the language of preference, so that sounds like a good idea 08:21:37 <nikos> ... we can change it in switch as well 08:21:52 <nikos> ... anything camel cased needs to die, die, die, die, die! 08:22:14 <nikos> ... I agree with something short but we'd be overloading lang then 08:22:18 <nikos> ... but that's actually useful 08:22:35 <nikos> ... the problem is, what happens if you do 08:22:57 <nikos> <text><tspan lang="de">Hallo</tspan><tspan lang="en">he said.... 08:23:11 <nikos> heycam: I would be fine with allowing lang on title as a special thing 08:23:14 <nikos> shepazu: it seems strange 08:23:27 <nikos> krit: in general you can just display one title 08:23:38 <nikos> shepazu: are we going to generalise this and get rid of the switch element in other circumstances? 08:23:45 <nikos> heycam: I don't think it would work in other cases 08:24:05 <nikos> shepazu: ok I'm fine with it for any meta element (description also) 08:24:28 <nikos> shepazu: we are giving special characteristics to title with respect to what the language is 08:24:31 <nikos> heycam: I'm ok with that 08:24:54 <nikos> ... I think systemLanguage makes more sense with the current functionality but lang looks nicer 08:25:18 <nikos> shepazu: lets leave lang as a special meta data thing that is a special case of switch 08:25:52 <nikos> ed: for title it works not sure about desc 08:26:01 <nikos> Tav: how is title as an attribute different from title as an element? 08:26:14 <nikos> ... do the browsers treat it differnet? 08:26:20 <nikos> s/differnet/differently 08:26:25 <nikos> shepazu: We just hint what you should do 08:26:45 <nikos> heycam: one of the arguments of having title as an element is good for languages which require disambiguation of direction 08:27:02 <nikos> ... svg doesn't have the elements to control that so I think it's a moot issue for us 08:27:42 <nikos> heycam: what about if we had title as a property? 08:27:59 <nikos> shepazu: that would promote poor practice for internationalisation 08:28:11 <nikos> heycam: I don't know if you'd want to download a big file with lots of languages 08:28:36 <nikos> shepazu: I quite like using many languages in SVG. it wasn't designed to be text heavy. 08:29:09 <nikos> ... one thing we didn't talk about is - a common workflow for skins is to point to an external resource for the languages 08:29:27 <nikos> ... it looks up the value and inserts it. We could enable something like that for SVG 08:29:37 <nikos> ... people could point off to their text file that contains different languages 08:29:45 <nikos> heycam: I think you could already do that for text other than title 08:29:52 <nikos> shepazu: we should define how that happens 08:29:56 <nikos> heycam: it's defined. 08:30:13 <nikos> shepazu: We should give examples of how it works to promote best practices 08:30:43 <nikos> ... it could be an href like tref and if it's defined you go and retrieve it and thats where all the switching stuff is done. 08:30:57 <nikos> ... if it doesn't get the file then it could use the default of what you put in the <text> 08:31:22 <nikos> ... I think it would allow people to customise these things more easily - it's just a proposal 08:31:36 <nikos> Tav: allowing lang on title solves the use case that was put to be at SVG open 08:33:04 <nikos> krit: so the first title doesn't need a lang but the rest do? 08:33:27 <nikos> heycam: current implementations look at the first title only, so if you are happy having that as a fallback that will always work you need to put it first 08:33:38 <nikos> and then you could still put lang on it if that's what you want for the default 08:35:15 <nikos> heycam: the issue is, I think, if you have the first title and it has an obscure language, you don't want that to be the default in the new system if other languages are provided 08:35:19 <nikos> krit: I don't agree, 08:35:50 <nikos> shepazu: for implementations that support this it will check every language and display the first match 08:35:54 <nikos> ... so it has the behaviour you want 08:36:01 <nikos> ... it's just for legacy purposes the default is the first 08:36:06 <nikos> krit: that's ok 08:36:20 <nikos> heycam: the only downside is the order checking is different from switch 08:36:30 <TabAtkins> TabAtkins has joined #svg 08:36:31 <nikos> shepazu: it's not switch though it's something different 08:36:44 <nikos> Resolution: Add lang to title and desc 08:36:53 <TabAtkins> Ugh, I slept straight through my alarm, wow. Where are we? Like, physically? 08:37:27 <TabAtkins> kk 08:38:19 <nikos> Action: Tav to add lang to tile and desc 08:38:20 <trackbot> Created ACTION-3354 - Add lang to tile and desc [on Tavmjong Bah - due 2012-09-24]. 08:41:09 <nikos> Topic: Removing pixelUnitToMillimeter{X,Y} and screenPixelToMillimeter{X,Y} 08:41:18 <nikos> andreas: I did some reasearch 08:41:43 <nikos> ... there's a property you can create in Javascript called window.devicePixelRatio 08:41:57 <nikos> ... Opera supports it but it has a different value than WebKit 08:42:04 <nikos> ... that's all I've really found that does that 08:42:17 <nikos> Tab: It's a proprietary webkit thing right now 08:42:28 <andreas> http://www.quirksmode.org/blog/archives/2012/06/devicepixelrati.html 08:42:56 <nikos> Tab: I think if they're useful remove them but they could be useful since we have the possibility of non-square pixels 08:43:23 <nikos> s/I think if they're useful remove them but they could be useful since we have the possibility of non-square pixels/I think if they're use-less remove them but they could be useful since we have the possibility of non-square pixels 08:43:59 <nikos> nikos: would it be more useful to just get the ratio and not worry about the size? 08:44:10 <TabAtkins> TabAtkins has joined #svg 08:44:24 <nikos> Tab: I think getting the X width is the most useful and then Y could either be an actual height or a ratio 08:45:03 <nikos> heycam: this seems to be a bit different since the SVG functions relate to a specific size on the screen rather than a ratio 09:12:29 <ed> scribeNick: ed 09:12:42 <ed> topic: passing path object to svg path 09:12:44 <krit> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path 09:12:52 <nikos> nikos has joined #svg 09:13:01 <cabanier> cabanier has joined #svg 09:13:06 <ed> DS: in html canvas we have an interface to build a path object 09:13:18 <ed> ... would be good if we could get the path and pass it to the svgdom 09:13:30 <ed> ... to append to the svg path 09:13:42 <ed> CM: can it serialize to the svg pathstring? 09:13:55 <ed> DS: no, there are some differences 09:14:03 <ed> ... arcto for example 09:14:21 <ed> ... suggest we leave it up to the browser to normalize the path 09:14:34 <ed> ... and not specify exactly how 09:14:47 <ed> CM: i think it should be specified 09:15:58 <ed> RC: if you draw a circle it stores a bunch of bezier curves 09:16:08 <ed> ... so if you read the path out it looks ok, but it's no longer a circle 09:16:35 <ed> doug: so if I do a circle in skia and a circle in cairo i would get the same result? 09:16:52 <ed> DS: might be different, but should look the same 09:17:10 <ed> doug: is this exposed to the user? 09:17:30 <ed> TA: the UA would need to remember the original commands, doesn't do this atm 09:17:54 <ed> DS: i'd prefer the first version to not specify the normalization 09:17:59 <ed> CM: i don't like it 09:18:14 <ed> TA: if you're doing it in script you're going to have to do it anyway 09:18:43 <ed> BB: scripts handle one segments produces in one browser, that's how most authors work 09:19:28 <ed> Doug: experienced that with freaky mouth example, didn't work in opera due to how path normalization worked there 09:19:37 <ed> CM: we could require one or more beziers 09:19:43 <ed> ... not knowing how many you get 09:19:59 <ed> Doug: doesn't help the author at all 09:20:19 <ed> CM: the predictable thing is that you'll get a number of beziers 09:20:34 <ed> doug: think about animation 09:20:58 <ed> DS: we could specify how arc is normalized, as quadratic curves 09:21:36 <ed> TA: all implementations support cubic beziers 09:22:00 <ed> CM: why not have a configurable thing to store the original path commands? 09:22:36 <ed> TA: we should specify how many beziers an arc gets turned into 09:23:24 <ed> BB: is there a concrete usecase for this? or is this just about the procedural api for creating the path? 09:23:32 <ed> TA: i think the api is a use-case 09:23:51 <ed> BB: we could just support the canvas path api in svg 09:25:14 <ed> TA: the path is a toplevel global api, so you can create the path object without having a canvas 09:26:34 <ed> ... will break paper.js, but that's fine, will just shadow the native interface 09:27:06 <ed> CM: there's an interface CanvasPathMethods that we could inherit 09:27:27 <ed> ... to have them directly on the <path> element 09:27:56 <ed> DS: but then you can't use this to create a canvas path, and reuse the path object 09:28:23 <ed> RC: you can contruct it with an svg path string 09:29:13 <ed> TA: we could also make it serialize out to something that works in svg path@d attribute 09:29:33 <ed> DS: like that idea 09:29:56 <ed> ...but it doesn't make sense that it has to serialize and then reparsed by svg 09:30:00 <ed> ED: agree 09:30:31 <ed> Doug: element.addPath(obj) to append that path 09:30:49 <ed> ... you might want to animate and reuse and so on 09:31:16 <ed> CM: how would you get arcs? 09:31:30 <ed> ... with the procedural api 09:31:44 <ed> DS: you can't, you'd get cubics back 09:32:10 <ed> Doug: everybody hates the arc syntax in svg 09:32:50 <ed> ... with catmull-rom we thought to translate that into beziers anyway 09:33:05 <ed> ... you should be able to find out what it converted to 09:33:35 <shepazu> shepazu: and you could chain commandas 09:33:46 <shepazu> s/commandas/commands/ 09:33:50 <ed> CM: would like the native api to be able to create the native path commands, like arc, catmull-rom etc 09:34:58 <ed> ... so if I create an arc with the API and put it into an svg <path> element that the arc is still an arc 09:35:12 <ed> DS: but then the mapping isn't 1:1 09:36:30 <ed> CM: you can't tweak everything afterwards if it's normalized 09:37:36 <ed> ... but the arc syntax might be different betweent the api and the svg commands 09:39:20 <ed> doug: there should be a way to get the non-normalized path out, you should be able to get both that and the normalized variant 09:40:44 <ed> TA: we want to normalize (which needs to be specified) lineto,moveto, cubic beziers and close path 09:41:09 <ed> CM: i want to be able to say .arc and have that turn into arc command 09:41:20 <ed> TA: why? the syntax is different 09:42:44 <ed> CM: if we have the nicer path syntax in svg then we could have a direct mapping 09:43:31 <ed> TA: so taking the path commands and adding it to svg, plus extending the api? 09:43:47 <andreas> andreas has joined #svg 09:44:12 <ed> CM: as long as it's possible procedural things and get the actual path commands 09:45:50 <ed> (discussion on spec stability) 09:47:53 <ed> TA: the path object stringifies to a normalized path string 09:48:21 <ed> CM: how many beziers does an arc get turned into? 09:48:26 <ed> TA: needs to be specified 09:49:52 <ed> RESOLUTION: we want to add a stringifier on the path object that returns a string using normalized svg path syntax 09:52:25 <ed> RESOLUTION: svg path elements gains a addPath method that appends path to the path 09:52:53 <ed> s/appends path to the path/appends path object to the path 09:53:07 <ed> CM: does canvas paths need to start with a moveto? 09:53:22 <ed> TA: not required, starts at 0,0 09:53:37 <ed> ... some things start implicit subpaths 09:53:48 <ed> ... e.g the rect command 09:55:09 <heycam> String(new Path("M … A …")) 09:55:29 <heycam> normalizes the path back to an SVG path segment list 09:56:58 <ed> RESOLUTION: it will be possible to normalize explicitly and stringify the result 09:57:07 <TabAtkins> (new Path().addPath("M... A...")+'' 09:57:13 <TabAtkins> (new Path()).addPath("M... A...")+'' 09:58:03 <ed> RESOLUTION: there will be a method that normalizes any svg shape into a path object 09:59:26 <ed> BB: so adding the canvas api methods to the svgpath elements 09:59:43 <ed> TA: if we put it on the path element id' expect it to be normalized 09:59:43 <birtles> s/svgpath elements/svgpathseglist/ 10:00:02 <ed> ... but if we put it on the svgpathseglist then i'd expect non-normalized 10:00:28 <ed> CM: where you put the interface is just baout how much you want to help the authors 10:00:54 <ed> TA: so seglists could be smarter 10:00:59 <ed> CM: seems confusing 10:01:34 <ed> BB: i do want a simple api, but avoiding duplication is maybe better 10:01:53 <ed> CM: e.d.arcTo(...) 10:02:02 <ed> CM: e.arcTo(...) 10:02:26 <ed> ... think the second one is not necessary 10:02:42 <ed> RC: if you do addPath it works 10:03:09 <ed> CM: i'd like to be able to set the svg path from a string directly 10:03:45 <ed> BB: think it should be on the seglist interface 10:04:26 <ed> CM: so adding addPath to the svgpathseglist 10:04:40 <ed> DS: i think it should be on the path element 10:05:08 <ed> CM: think it makes sense to have all path manipulations on the svgpathseglist interface 10:06:08 <ed> DS: what's on the svgpathseglist api now? 10:06:14 <ed> TA: path manip methods 10:06:21 <ed> DS: doesn't quite fit tehre IMO 10:06:50 <ed> CM: BB thinks it'd be more useful to have retained pathseglists 10:07:03 <ed> ... without having it attached to a path element 10:07:05 <ChrisL> ChrisL has joined #svg 10:08:02 <ed> ... so the worry is that we'll have two such path object representations (svgpathseglist and the path object) 10:09:20 <ed> BB: who's going to revise the path apis in svg? 10:09:28 <ed> CM: i think i have an action to do that 10:09:51 <ed> ... new SVGPathSegList(canvaspath) 10:10:34 <ed> Andreas: does addPath start a new subpath? 10:10:59 <ed> Doug: you can use clear to clear out the path so that you can have a blank canvas to draw on 10:11:56 <ed> ... addPath will add a new moveto, but what if you want to add commands to that? 10:12:08 <ed> ... to a existing path 10:12:25 <ed> CM: you could stringify and strip out the movetos 10:12:58 <ed> Doug: couldn't we just have addSegment to just append/continue the path? 10:13:56 <ed> ... could we make addSegment strip out the implicit path API moveto? 10:14:58 <ed> ... usecase: to append segments to an existing path 10:15:31 <ed> TA: you don't know if the moveto was explicit or implicit 10:15:45 <ed> ...due to normalization 10:16:41 <ed> TA: i want addPath and extendPath 10:16:59 <ed> ... extendPath cuts off the first moveto 10:18:43 <ed> RESOLUTION: add extendPath - which acts as addPath but trims off the initial moveto 10:19:16 <ed> doug: so are we adding arcTo? 10:20:04 <ed> ... and what do we do with catmull-rom? 10:21:07 <ed> CM: these new commands should be on the canvas path api so both can use them? 10:21:14 <ed> doug: yes, sounds useful for both 10:22:36 <ed> RESOLUTION: add new procedural methods for catmull-rom and add canvas-like arc commands in svg path syntax 10:23:10 <ed> CM: there are arc and arcto, and ellipse 10:23:47 <ed> TA: arc and ellipse use startangle,endangle 10:25:45 <ed> RESOLUTION: add a 'd' property to the svg path element for accessing the pathseglist 10:26:26 <ed> BB: allow svgpathseglists to be created independent of the svg path element 10:27:06 <ed> ... allow assigning a pathseglist object ot the path element (pathelm.d = seglist) 10:27:52 <ed> doug: should have a json serialization of the path, in addition to the stringification 10:28:25 <ed> CM: someone has requested toJSON for passing objects around, e.g for web workers 10:28:40 <ed> BB: to be able to set and get an array of floats 10:28:57 <ed> ... you already have normalization for moveto, lineto, closepath 10:29:46 <ed> ... faster with float arrays than to use pathseglist 10:31:02 <ed> CM: so, stringifier, jsonifier, and pointifier? 10:31:16 <ed> BB: there are a number of ways you could do this 10:31:39 <ed> ... there are libs that work on arrays of points directly 10:33:49 <ed> ... you're really working on arrays of arrays 10:34:14 <ed> CM: for subpaths you could flag it somehow 10:34:57 <ed> TA: boolean at the end? 10:35:24 <ed> BB: needs to be there when you set it back again 10:35:51 <ed> CM: alternative is to have a function isSubpathClosed, and pass in the subpath 10:36:20 <ed> BB: that's a bit less flexible 10:37:11 <ed> ... want to just read out the point array, manipulate and set it back 10:37:54 <ed> TA: so you have an array of points per subpath 10:38:16 <ed> BB: and you have array of subpaths, which each have an array of points 10:39:07 <ed> TA: so defer until we get some feedback on this, on the list? 10:39:44 <ed> CM: the json thing then... 10:40:08 <ed> TA: not quite ready to resolve on that yet, but similar to the array one, should probably be discussed on the list 10:40:25 <ed> -- 1h break for lunch -- 11:58:01 <stakagi> stakagi has joined #svg 11:59:17 <TabAtkins> TabAtkins has joined #svg 11:59:57 <birtles> birtles has joined #svg 12:00:12 <birtles> scribenick: birtles 12:01:04 <birtles> topic: new arc command 12:01:32 <birtles> heycam: problem is the existing arc is unintuitive and you often want to animate the angles of arc rather than the endpoints 12:01:49 <birtles> ... it's really hard with declarative animation 12:01:54 <nikos> nikos has joined #svg 12:01:55 <birtles> ... you have to do all the trig yourself 12:02:11 <birtles> ... which of the canvas arc commands let you specify the angle? 12:02:53 <birtles> TabAtkins: arc and ellipse are basically the same... 12:03:30 <birtles> ... arc(x, y, radius, startAngle, endAngle, acw) 12:03:42 <birtles> ... coordinates are absolute 12:03:56 <birtles> ... ellipse is the same but the radius has x and y and a rotation argument 12:04:07 <birtles> ... arc2 is a separate command that takes... 12:04:16 <birtles> s/arc2/arcTo/ 12:04:51 <birtles> heycam: is the implicit start point on the circle? 12:05:40 <birtles> cabanier: no, it automatically draws a line to the start of the arc 12:05:51 <birtles> TabAtkins: arcTo is a little more interesting... 12:06:09 <birtles> ... it does a straight line segment but it provides C1 continuity 12:06:33 <birtles> ... arcTo(x1, y2, x2, y2, radius) 12:07:25 <birtles> ... (draws a diagram explaining how arcTo works) 12:07:49 <birtles> shepazu: I'd like to add a rounding algorithm to SVG based on this mechanism 12:08:17 <birtles> TabAtkins: there is no rounded rect, you just use four arcTo commands 12:08:27 <birtles> ... there are the two arc commands in canvas 12:08:56 <birtles> krit: but are we running over the letters in the alphabet in the SVG path syntax? 12:09:10 <birtles> TabAtkins: but we could allow identifiers that are more than a single letter 12:09:51 <birtles> shepazu: we could just say "arc" 12:10:21 <birtles> heycam: is it useful to have both? 12:10:27 <birtles> everyone: yes 12:10:46 <birtles> TabAtkins: we could just have "arc" and "arcTo"? 12:10:55 <birtles> heycam: are you sure we don't want to use single letters? 12:11:05 <birtles> ... what about "e"? 12:11:06 <glenn> glenn has joined #svg 12:11:14 <birtles> krit: that conflicts with scientific notation 12:11:52 <birtles> (which is now in CSS by the way) 12:12:04 <birtles> TabAtkins: I don't think we can continue with single letters 12:12:16 <birtles> heycam: what about leading punctuation? 12:13:02 <birtles> ChrisL: we've talked about having longhand before 12:13:10 <birtles> shepazu: it's also better for compression 12:13:47 <birtles> (talking about using expanded elements for path commands) 12:14:21 <birtles> heycam: so use "arc" and "arcTo" as the commands? 12:15:10 <birtles> TabAtkins: I'd be inclined to call them "circle", "ellipse" and "arcTo" 12:15:38 <birtles> ... so that we can use "arc" later as a longform for the existing arc command 12:16:02 <birtles> heycam: it might be more important to match the command name with the method 12:16:12 <birtles> ... rather than accommodating the existing arc command 12:16:19 <birtles> ... we could give it some other name in the future 12:16:36 <birtles> ChrisL: do we want to deprecate the existing arc command? 12:16:42 <birtles> TabAtkins: no, it's sometimes useful 12:16:50 <birtles> ChrisL: ok 12:17:14 <andreas> andreas has joined #svg 12:17:40 <birtles> TabAtkins: ok, let's keep consistency with the canvas method names for now 12:17:59 <birtles> ChrisL: we should have a resolution about whether we want the longhand form or not 12:18:21 <birtles> TabAtkins: need to decide priorities (when you have both) 12:18:44 <cyril> cyril has joined #svg 12:18:57 <birtles> heycam: it seems like a lot of duplication when sometimes it's probably easier just to separate out paths of the path string, rather than having 10 new elements 12:19:08 <birtles> ed: like having a fragment of the path as a separate element 12:19:17 <birtles> ChrisL: I think we'll probably have that too 12:19:33 <birtles> ... but we've often been asked for the verbose form 12:21:27 <birtles> ... the two big advantages are (a) better compression, (b) adding IDs / event handlers to specific parts 12:22:04 <birtles> (discussion about whether we could stroke sections differently) 12:22:37 <birtles> krit: what about adding length (units) to the path data 12:23:06 <birtles> ChrisL: when we originally considered that there was feedback that said that was really difficult 12:23:40 <birtles> heycam: what about percentages? 12:23:49 <birtles> krit: percentages are difficult, just lengths would be enough 12:23:54 <birtles> heycam: percentages would be useful 12:24:12 <birtles> TabAtkins: what measure do you resolve against for a diagonal line 12:24:22 <birtles> heycam: depends which coordinate of the command 12:24:40 <birtles> ... if it's the y coord it is resolved against the height 12:25:06 <birtles> ... since unit identifiers are currently more than one letter there shouldn't be clashes with the path commands? 12:25:24 <birtles> shepazu: using units in paths has often been requested 12:25:38 <birtles> ... sometimes this is because people don't understand how to set units at the root 12:25:46 <birtles> ... but percentages are often valid 12:26:54 <birtles> krit: when are percentages are resolved? 12:27:09 <birtles> TabAtkins: if it's created in JS, what do you resolve the percentages against? 12:27:20 <birtles> heycam: it's similar to creating SVGLength objects 12:27:29 <birtles> ... what do they get resolved against? 12:27:41 <birtles> ... using createSVGLength 12:28:05 <birtles> ... we never really resolved how that should work 12:30:25 <birtles> RESOLUTION: We will add arc, ellipse, and two forms of arcTo to the SVG path syntax based on the canvas methods of the same names 12:31:17 <birtles> TabAtkins: the only remaining command on canvas that's not available with the d attribute is "rect" 12:32:01 <birtles> ChrisL: what do we need to spec out with regards to that resolution 12:32:08 <birtles> heycam: DOM API etc. 12:32:49 <birtles> TabAtkins: it would be nice to make the "d" attribute of the SVGPathElement return a sane version of SVGPathSegList 12:33:09 <birtles> ... (and not just an alias of pathSegList) 12:33:34 <birtles> krit: does this work for repeated commands? 12:33:50 <birtles> ... since the number of arguments to arcTo varies 12:34:01 <birtles> TabAtkins: arcTo comes in a 5 arg and a 7 arg version 12:34:12 <birtles> ChrisL: we could solve it by giving them different names 12:34:24 <birtles> ... or just say you have to repeat the command 12:35:25 <birtles> TabAtkins: what if we have ellipseTo 12:35:40 <birtles> ChrisL: and just document what ellipseTo equates to in canvas terms 12:35:55 <birtles> ... then you wouldn't have to have an exception where these commands can't be repeated 12:36:48 <birtles> heycam: we should look into adding ellipseTo to canvas (as an alias to the equivalent arcTo command) 12:36:56 <birtles> TabAtkins: I'll propose it 12:37:45 <birtles> ACTION: Tab to propose to the HTML WG that the 7 argument form of arcTo be replaced with an ellipseTo method 12:37:45 <trackbot> Created ACTION-3355 - Propose to the HTML WG that the 7 argument form of arcTo be replaced with an ellipseTo method [on Tab Atkins Jr. - due 2012-09-24]. 12:38:13 <birtles> (this is because the elliptical version of arcTo is not implemented anywhere so we are still free to change the name) 12:38:51 <birtles> heycam: I'll try to write this up in the spec since my name is down next to this item in the requirements list 12:39:10 <birtles> ChrisL: what about lengths and percentages in paths? 12:39:29 <birtles> krit: I'm still not sure about how you resolve percentages 12:40:38 <birtles> TabAtkins: let's defer percentages to further discussion on the list and just stick to lengths for now 12:40:44 <birtles> heycam: em units still need a context 12:40:56 <birtles> TabAtkins: you can resolve against a default font size 12:41:01 <birtles> heycam: what about calc? 12:41:09 <birtles> TabAtkins: it's not problematic by itself 12:41:27 <birtles> ... only if one of its components is a length we can't resolve 12:41:45 <birtles> heycam: more discussion is needed on lengths 12:42:05 <birtles> ... particularly for what to do when you don't have a context for resolving against 12:42:10 <birtles> ... what about points on a polyline? 12:42:17 <birtles> krit: yes, since we have that for shapes in CSS 12:43:05 <birtles> ACTION: Dirk to tell the CSS WG that we changed the SVG path syntax 12:43:06 <trackbot> Created ACTION-3356 - Tell the CSS WG that we changed the SVG path syntax [on Dirk Schulze - due 2012-09-24]. 12:43:43 <birtles> ACTION: Dirk to prepare a proposal for supporting lengths/percentages in paths and polylines 12:43:43 <trackbot> Created ACTION-3357 - Prepare a proposal for supporting lengths/percentages in paths and polylines [on Dirk Schulze - due 2012-09-24]. 12:43:56 <birtles> ChrisL: what about element syntax for paths? 12:44:14 <birtles> TabAtkins: I think it's useful 12:46:06 <birtles> ACTION: Chris to produce a proposal for expanded element syntax for paths (including finding the results of testing improved compression ratios with the expanded syntax) 12:46:07 <trackbot> Created ACTION-3358 - Produce a proposal for expanded element syntax for paths (including finding the results of testing improved compression ratios with the expanded syntax) [on Chris Lilley - due 2012-09-24]. 12:47:12 <birtles> cyril: I think it's good to be able to break paths into fragments but not necessarily an element per point 12:47:23 <birtles> ChrisL: it wouldn't be per point but per command 12:48:05 <birtles> heycam: sometimes you don't want to go down to individual commands but just fragments 12:48:16 <birtles> ... it would be nice to use the same mechanism for that 12:48:52 <birtles> shepazu: it would be nice to refer to segments and include them reversed etc. 12:51:34 <birtles> ChrisL: if you have multiple paths and you want to combine those to make one path you sometimes need to reverse a segment 12:51:39 <birtles> shepazu: it would be nice to be able to get the geometry of the reversed version 12:54:21 <birtles> cyril: if we have elements for each command, you'd end up with a lot of DOM nodes 12:54:29 <birtles> ... is it worth having the parse collapse them? 12:54:50 <birtles> TabAtkins: no, you don't want the parser doing that kind of special magic 12:54:54 <birtles> everyone: no magic 12:55:18 <birtles> andreas: what about polar coordinates? 12:55:36 <birtles> heycam: we rejected the request for polar coordinates in transforms 12:56:51 <birtles> ... in place of that we have proposed the turtle graphics which solves many of the cases but not all 12:57:17 <birtles> ChrisL: it reminds me of the syntax used in Raphael which provides a SVG path-like syntax for describing transforms 12:58:30 <birtles> krit: polar coordinates are definitely useful... 12:58:44 <birtles> ... but then the whole coordinate system should be in polar coordinates 12:58:50 <birtles> ... otherwise you have to map them 13:00:27 <birtles> andreas: sometimes you have a series of survey results that are best described using polar coordinates, like a cave 13:00:34 <birtles> ... everything is relative to the last position 13:01:12 <birtles> ... it's typically a series of straight line segments and rotations 13:01:29 <birtles> heycam: that should be possible using the turtle graphics command 13:02:08 <birtles> ... but polar coordinates in general are difficult and we rejected that requirement 13:02:43 <birtles> (description of turtle graphics proposal, the 'r' and 'R' commands) 13:04:15 <birtles> (now talking about Catmull-Rom curves) 13:04:47 <birtles> shepazu: adding a segment affects the previous segment 13:05:06 <birtles> ... and you need two endpoints 13:05:33 <birtles> ... so if you start with a P command (the Catmull-Rom command) you can't draw the curve until you get a second point 13:06:51 <birtles> ChrisL: with regards to the issue of segments affecting the previous segment, if you duplicate the points of the last segment (i.e. a zero-length segment which degenerates to a straight line segment) it won't affect the previous segment 13:07:16 <cabanier> cabanier has joined #svg 13:07:47 <birtles> topic: <image> as paint server for SVG (already resolved to have <gradient>) 13:08:07 <birtles> krit: we already allow <gradient> 13:08:15 <birtles> ... and we resolved how it applies to path elements 13:08:25 <birtles> ... and it's not limited to gradient box (as defined in CSS) 13:09:11 <birtles> TabAtkins: in CSS gradients are infinite 13:09:16 <birtles> ... but they get chopped to their box 13:09:26 <birtles> ... but SVG can define gradients so that extend to infinity 13:09:36 <birtles> ... but other image types can't be trivially extended in the same way 13:10:01 <birtles> ChrisL: in SVG 2 we could also have a painted bounding box (aka decorated bounding box) 13:10:09 <birtles> ... we could use that instead 13:10:30 <birtles> shepazu: i.e. use that instead of the gradient bounding box 13:10:56 <birtles> cyril: but with an image you can say that it only fills 50% of the box 13:11:01 <birtles> ... how do you fill the rest of the object? 13:11:06 <birtles> krit: not at all 13:11:11 <birtles> ChrisL: transparent black 13:11:36 <birtles> TabAtkins: CSS lets you specify repetition etc. 13:11:51 <birtles> ... if we wanted to do that in SVG we'd have to make fill etc. a shorthand 13:12:20 <birtles> ... or we could specify those properties when specifying a paint server (e.g. a pattern) 13:12:33 <birtles> ChrisL: there's another consequence of this painted bounding box 13:12:37 <glenn> glenn has joined #svg 13:12:59 <birtles> ... previously if you had a gradient on a horizontal line you'd end up with nothing unless you special case it 13:13:09 <birtles> ... but if you use the painted bounding box you can get around that 13:13:32 <birtles> krit: what if you have a rectangle that you stroke 13:13:42 <birtles> ... you stroke it with an image 13:13:57 <birtles> ... if you use the geometric bounding box only half the stroke gets painted 13:14:50 <birtles> TabAtkins: what about backwards compatibility about using the painted bounding box 13:15:28 <birtles> shepazu: you'd use the geometric bounding box for existing SVG gradient elements, and the painted bounding box for CSS gradients 13:16:10 <birtles> (discussion about providing a new keyword like objectBoundingBox when defining an SVG gradient so it can use the painted bounding box) 13:16:47 <birtles> TabAtkins: that's important since we also want to be able to use SVG gradients in CSS 13:17:09 <birtles> (discussion about the definition of the decorated bounding box) 13:17:56 <birtles> TabAtkins: when using a CSS gradient function in SVG, do we want stroke to use the painted bounding box and the fill to use the geometric? 13:18:05 <birtles> ChrisL: I'd like to have the flexibility to use both 13:18:21 <birtles> TabAtkins: I think fill should default to geometric and stroke to painted 13:18:48 <birtles> TabAtkins: in summary, we want to expose the ability to switch between geometric and painted bounding boxes 13:19:08 <birtles> ... we will add an optional keyword to the fill/stroke properties to allow switching between the two 13:19:23 <birtles> ... with appropriate defaults for each (specifically fill = geometric, stroke = painted) 13:19:31 <birtles> heycam: what about markers? 13:21:44 <birtles> ... are they included in the calculation of the decorated bounding box (as they are in the DOM method)? it might be less useful when stroking to include markers 13:21:52 <birtles> ... it needs more thought 13:23:52 <birtles> TabAtkins: for stroke, the default is the painted bounding box 13:24:23 <birtles> ... but when referring to an SVG gradient element it will defer to an attribute on the gradient specifying which bounding box to use 13:24:35 <birtles> ... and *that* will default to the geometric bounding box for backwards compatibility 13:24:40 <birtles> ... just like we're doing with maskign 13:24:46 <birtles> s/maskign/masking/ 13:25:13 <birtles> ... for the more general issue of the CSS <image> type... 13:25:38 <birtles> ... if you draw a gradient using the geometric bounding box 13:25:56 <birtles> ... it will size itself using the inner bounding box but it still can extend beyond that box 13:26:13 <birtles> ... the gradients are defined such that they extend infinitely 13:26:18 <birtles> ... then CSS just clips that result 13:26:26 <birtles> ... but SVG might not do that 13:26:59 <birtles> ... what do we do outside the box for other CSS image types 13:27:06 <birtles> ... do we just paint them as transparent black? 13:27:38 <birtles> (other CSS image types being all those other than gradient functions) 13:27:49 <birtles> ... if you want it to repeat, put it in a pattern and use that 13:29:15 <birtles> ... CSS just defines that outside the box you're transparent black unless you use background properties to repeat the image 13:30:08 <birtles> heycam: the alternative is to introduce background-repeat etc. into SVG 13:30:17 <birtles> ... and I'd rather not do that 13:30:28 <birtles> TabAtkins: me too, use patterns for repeating 13:31:54 <glenn> glenn has joined #svg 13:32:45 <birtles> RESOLUTION: We will add a control to fill and stroke to determine which bounding box (geometric or decorated) to use for sizing paint servers 13:33:13 <cyril> for sizing and positioning too 13:33:23 <birtles> RESOLUTION: We will add attribute to the existing paint servers in SVG defaulting to the geometric bounding box (like the maskType attribute) 13:34:09 <birtles> RESOLUTION: When using CSS image types that are finite in extent are expanded to infinity by using transparent black (not by repeating the result) 13:34:31 <birtles> s/extent are/extent, they are/ 13:35:13 <birtles> ACTION: Tab to amend the definition of fill,stroke in SVG to allow the CSS <image> type 13:35:13 <trackbot> Created ACTION-3359 - Amend the definition of fill,stroke in SVG to allow the CSS <image> type [on Tab Atkins Jr. - due 2012-09-24]. 13:36:23 <birtles> heycam: is there a clash since fill,stroke already take a URL but so does the <image> type 13:36:42 <birtles> ... are the mechanics for how you interpret it different? 13:38:00 <birtles> TabAtkins: it should be ok 13:38:06 <birtles> birtles: it's the same for masks 13:38:24 <birtles> ... you have one behavior when you refer to a whole document (a.svg) vs an element within a document (a.svg#mask) 14:03:41 <cabanier> cabanier has joined #svg 14:03:45 <TabAtkins__> TabAtkins__ has joined #svg 14:03:51 <andreas> andreas has joined #svg 14:03:59 <TabAtkins__> ScribeNick: TabAtkins__ 14:04:09 <TabAtkins__> Topic: color interpolation filters for shorthands 14:04:27 <TabAtkins__> krit: Currently we have the color-interpolation property for all filters. 14:04:32 <TabAtkins__> krit: How do we apply it to the shorthand functions? 14:04:56 <TabAtkins__> heycam: Would you normally want to apply it to specific filter primitives? 14:05:33 <TabAtkins__> chrisl: In general you want to do linear, but there are cases where you want to stay in the sRGB as you pass values between, to avoid loss. 14:05:58 <TabAtkins__> krit: For shorthands, we're okay with just using the default colorspace. If you want different shorthands, use the SVG <filter> element. 14:06:31 <nikos> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#ShorthandEquivalents 14:06:34 <krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterFunction 14:07:19 <ChrisL> ChrisL has joined #svg 14:07:24 <TabAtkins__> krit: [lists the shorthand functions] 14:09:20 <TabAtkins__> krit: So, first question, are we okay with saying that the filter shorthands just use the default colorspace? 14:10:11 <TabAtkins__> RESOLVED: Filter shorthands only use the default colorspace (*not* the current value of 'color-interpolation-filters' on the element, either). 14:11:05 <TabAtkins__> krit: Note, obviously, that you can use an SVG <filter> (with color-interpolation set on the <filter> element or the subfilters) and then reference it with url(). 14:11:38 <TabAtkins__> Topic: Perlin noise 14:12:05 <TabAtkins__> krit: Do we want to add a new type of noise function that is easier to hardware-accelerate? 14:12:18 <TabAtkins__> ChrisL: In addition to existing turbulence, or replacement? 14:12:47 <TabAtkins__> TabAtkins__: Addition - too much content already relying on it. 14:12:55 <ChrisL> ok good 14:12:58 <TabAtkins__> ChrisL: Is there a definition for the algorithm that's free? 14:13:21 <TabAtkins__> krit: We need to decide on the new algorithm, with discussion or further research. 14:13:28 <TabAtkins__> ed: I think we discussed Simplex noise before. 14:14:03 <ChrisL> http://www.eng.utah.edu/~cs6965/papers/noise.pdf 14:14:29 <ChrisL> http://reality.sgiweb.org/olano/s2002c36/ch02.pdf Noise Hardware - Ken Perlin 14:14:47 <TabAtkins__> RESOLVED: Add a new type of noise algorithm to the filters spec, for easier hardware acceleration. (Further research for what type, possibly Simplex noise.) 14:16:11 <TabAtkins__> Topic: Need a new filter shorthand for noise? 14:16:31 <TabAtkins__> krit: Often the noise functions are not used standalone - they're used with other filter primitives. 14:17:21 <ChrisL> https://github.com/ashima/webgl-noise/wiki glsl implementation of Perlin and simplex noise 14:20:33 <ed> here's an example using a bit of turbulence: http://dahlström.net/svg/presentations/svgopen2012/presentation/introimage-static-grain-toothpaste.svg 14:20:34 <TabAtkins__> TabAtkins__: The use-case I care about is usually solved by taking an initial background-image or background-color, and layering a "noise image" on top to give it some irregularity. You cannot do this with the 'filter' property unless you define a <filter> element and refer to it. 14:22:13 <TabAtkins__> ChrisL: I've come across an impl of both classic and simplex noise in glsl, and it says explicitly that both algorithms can be done fine even on low-end (e.g. phone) GPUs. 14:22:55 <TabAtkins__> ChrisL: So why is this a problem that we need to solve? 14:23:24 <TabAtkins__> krit: Based on list discussion, Simplex is a smaller O() complexity, which is of concern with the often-large images that will be used in CSS. 14:23:25 <konno_> konno_ has joined #svg 14:23:33 <ChrisL> ok 14:24:25 <ChrisL> demo http://alteredqualia.com/three/examples/webgl_shader_copper.html 14:25:10 <heycam> ScribeNick: heycam 14:25:39 <ed> the demo chrisl pasted demos 3d-perlin noise I believe 14:25:39 <heycam> TabAtkins__: the filter function in filter effects is of type CSS <image> 14:25:48 <heycam> s/TabAtkins__/krit/ 14:25:56 <TabAtkins__> s/filter function/filter() function/ 14:26:21 <heycam> TabAtkins__: so you can introduce a noise filter shorthand and then use it in the filter function 14:26:40 <TabAtkins__> s/TabAtkins__/krit/ 14:26:54 <heycam> TabAtkins__: my argument is that the filter function as written still takes an <image> as an argument 14:26:56 <heycam> krit: that would change 14:27:01 <heycam> TabAtkins__: if you make that optional it's less troublesome 14:27:07 <heycam> ... I think it's weird that we have no-input filters 14:27:09 <cabanier> filter function: https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterCSSImageValue 14:27:12 <heycam> … I think that was a hack in the original SVG 14:27:29 <heycam> … and instead just said "these are not paint servers but some filter primitives" 14:27:45 <heycam> … I am somewhat opposed to extending that confusion into the CSS version of the syntax 14:27:52 <heycam> … if we are producing an image, I would want to produce an <image> directly 14:28:02 <heycam> krit: then you can put this <image> as input to the filter function 14:28:13 <heycam> ed: if you want the same number of parameters that the SVG turbulence has? 14:28:18 <heycam> TabAtkins__: I don't know what's needed 14:28:53 <heycam> TabAtkins__: you would have "filter: noise(…) ..." 14:28:59 <heycam> krit: wouldn't the parser get confused? 14:29:03 <heycam> TabAtkins__: no 14:29:11 <heycam> … the filter function takes the first argument is an image, the next is filter list 14:29:40 <heycam> s/filter: noise(…) .../background-image: filter(noise(…), …)/ 14:29:55 <heycam> krit: you could use this as an input to custom filter primitives too 14:30:03 <heycam> TabAtkins__: so this seems fine to me 14:30:07 <heycam> krit: do we still want to have a shorthand noise function? 14:30:15 <heycam> … and is that in Images or Filter Effects? 14:30:28 <heycam> TabAtkins__: I don't think we do, because it's only a generation 14:30:34 <heycam> … and we can't do tree-based filter chains in the filter property 14:30:51 <heycam> … if we do do that, we can allow <image>s as well as inputs to compositing filters for example 14:31:40 <heycam> … I think making feTurbulence a filter primtiive and not a paint server was a mistake 14:31:56 <heycam> krit: in the end it probably doesn't matter, but yes where do we put it logically 14:32:05 <heycam> TabAtkins__: we should only allow pass through filters in the filter property 14:32:11 <heycam> krit: I agree 14:32:37 <heycam> ed: would we have a corresponding element in SVG filters? 14:32:42 <heycam> … we have feTurbulence 14:32:46 <heycam> krit: deprecate but not drop it 14:32:55 <heycam> TabAtkins__: for filters do we want to correct this historical mistake? 14:33:03 <heycam> … you can't just take a paint server directly, you need to specify bounds to fill 14:33:13 <heycam> krit: we could use feImage taking CSS <image> as well 14:33:18 <heycam> ed: I think it would be handy to have in SVG filters too 14:33:59 <heycam> ed: I don't mind if it's a new primitive or an 'image' referenced from <feImage> 14:34:10 <heycam> ed: a new in="" value? 14:34:18 <heycam> TabAtkins__: you just need to combine a paint server with a rect 14:34:36 <heycam> krit: in general, we need to redefine in and in2 14:34:45 <heycam> … to have CSS <image>s as input in there is fine 14:35:58 <heycam> TabAtkins__: you can't use colors in there 14:36:04 <heycam> .. because "blue" might be a name of a result 14:36:22 <heycam> … the <image> function in CSS can produce solid colors 14:36:27 <heycam> … image(blue) 14:36:44 <Cyril> Cyril has joined #svg 14:36:57 <heycam> krit: feImage still has subregion clipping 14:37:49 <heycam> … you could use media fragments for selecting the region, but there's no way to do preserveAspectRatio 14:38:01 <heycam> krit: a question about the noise function, how do you define the size of it? 14:38:05 <heycam> TabAtkins__: I would do the same as gradients 14:38:13 <heycam> … it's sized into the box it's drawn into 14:38:19 <heycam> … it has no intrinsic size 14:38:27 <heycam> … in SVG's case, it can still do an extension out to infinite case 14:38:40 <heycam> ed: one complication is having tiling 14:38:50 <heycam> … if you tile the noise function without stitchTiles you can see the tile edges 14:39:40 <heycam> TabAtkins__: any primitive tiling mechanisms will cause discontinuities at the edges of tiling 14:39:47 <heycam> … unless you tell the noise algorithm to stitch the edges 14:39:56 <heycam> ChrisL: we shouldn't be padding noise out, just which region we really want to cover 14:40:05 <ed> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feTurbulenceStitchTilesAttribute 14:41:12 <heycam> krit: primitives are always clipped to the filter region 14:41:19 <heycam> … if you have feOffset you can reach the edge of the noise function 14:41:42 <heycam> TabAtkins__: we should just generate noise at whichever pixels are going to be touched 14:42:48 <heycam> ACTION: Dirk to look into allowing CSS <image> values in in="" and in2="" 14:42:48 <trackbot> Created ACTION-3360 - Look into allowing CSS <image> values in in="" and in2="" [on Dirk Schulze - due 2012-09-24]. 14:43:00 <heycam> ACTION: Tab to work with Dirk to spec out a noise() <image> value 14:43:00 <trackbot> Created ACTION-3361 - Work with Dirk to spec out a noise() <image> value [on Tab Atkins Jr. - due 2012-09-24]. 14:43:37 <heycam> TabAtkins__: some things need the size you're drawing into 14:43:50 <heycam> … CSS gradients need to know how big their box is before drawing 14:44:05 <heycam> … media fragments don't apply to most CSS <image>s, just url() images 14:45:13 <heycam> ed: for SVG I would like to have 3D noise and to be able to connect the time domain to the third dimension 14:45:18 <heycam> … so you can have continuous effects 14:45:29 <heycam> … with feTurbulence it can move things in x and y, but you can't really have a fire/plasma effect 14:45:34 <heycam> krit: I'd suggest using shaders for that 14:45:38 <heycam> ed: you couldn't implement it that way 14:45:45 <heycam> …but it would be nice to have filter primitives for that 14:45:52 <heycam> krit: do we really want 3d noise? maybe, don't know. 14:45:57 <heycam> … is simpled 2d or 3d? 14:46:05 <heycam> ed: you can extend it to how many ever dimensions 14:46:13 <heycam> … I think that would be really nice to have 14:46:24 <heycam> … I want to allow that when we go with <image> generation, so we can animate the timing 14:46:57 <heycam> TabAtkins__: the CSS <image> type is now animatable, in Images 4 14:47:02 <heycam> … there's a generic animation type that does a cross-fade 14:47:10 <heycam> … but cross-fade and gradients animate argument-wise 14:47:16 <heycam> … so that's fine to have animation of noise() 14:47:34 <heycam> ed: Chris' link earlier shows the 3d noise animation 14:49:34 <heycam> shepazu: when we're talking about stitching, does this also apply to Tiling & Layering? 14:49:54 <heycam> TabAtkins__: just if you're using a noise function of a certain noise, or inside a pattern element that ends up being repeated, you need to tell the algorithm to make sure the edges tile well 14:51:09 <heycam> Topic: Masking issues 14:51:16 <heycam> krit: we said we wanted to have attribute maskType for <mask> 14:51:31 <heycam> … that says you specifically want to use this mask with alpha or luminance 14:51:35 <heycam> … do we want to make this a presentation attribute 14:51:55 <heycam> ed: why would you want to? 14:52:06 <heycam> krit: we already define mask-type for CSS masking 14:52:44 <heycam> heycam: so this would just use the same attribute/property on both the <mask> and the thing being masked 14:52:45 <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-type 14:52:45 <heycam> krit: yes 14:53:05 <heycam> krit: second question is if you use maskType="" as we currently defined it, it's camel case 14:53:15 <heycam> … which HTML editors don't want, because they need to special case it for the parser 14:53:21 <heycam> … I have no problems if they need to special case it 14:53:52 <heycam> ChrisL: the reason we had camel case was we originally had hyphenation, and the DOM people requested camel casing 14:54:42 <heycam> shepazu: if I'm converting from a property name to a DOM name, removing the hyphen is trivial, adding the camel-cased letter is kind of trivial with regex, but... 14:54:44 <heycam> krit: still trivial 14:54:50 <heycam> … the only problem is HTML is not case sensitive 14:55:02 <heycam> shepazu: could we go to all lower case? 14:55:56 <heycam> TabAtkins__: you would need to define what happens if you accept both camel case and lower case 14:56:05 <heycam> TabAtkins__: I'm fine with all lower case or keeping camel case in attributes 14:56:09 <heycam> … updating the list isn't a big deal 14:56:37 <heycam> … given every implementation just has a list of attribtues with cases, it's easy to update 14:57:42 <heycam> heycam: I'm slightly concerned that the case in the DOM changes after the parser is updated 14:58:16 <heycam> TabAtkins__: that's only a problem if people try to use the feature before implementations add the feature 14:58:32 <heycam> … you could define that with conflicting case names, just use the last one … that's what the HTML parser does 14:59:46 <heycam> TabAtkins__: maybe we should keep camel case, because when you are using the property with CSS, you use camel case in the DOM 15:00:08 <heycam> heycam: have the presentation attribute be camel case for a hyphenated property name? 15:01:22 <heycam> TabAtkins__: dashes are hard for the DOM, but we could accept hyphens too 15:02:09 <heycam> krit: it's easy in WebKit to have the dashed version of the presentation attribute 15:02:13 <heycam> …we just pass that to the CSS engine 15:02:31 <heycam> heycam: if it's going to become a presentation attribute, it should be mask-type not maskType 15:02:40 <heycam> krit: so do we want it to become a presentation attribute / property? 15:02:47 <heycam> TabAtkins__: I think we do 15:03:17 <heycam> birtles: just wondering when you'd want to set mask-type on <mask> with a style sheet 15:03:27 <heycam> TabAtkins__: you could set all <mask> elements to alpha with a style rule 15:03:28 <heycam> birtles: ok 15:04:36 <heycam> heycam: is it confusing that mask-type means slightly different thinks applied to <mask> and masked elements? 15:08:40 <heycam> TabAtkins__: we could merge in the "alpha" or "luminance" back into mask-image 15:08:44 <heycam> … instead of the separate mask-type 15:08:51 <heycam> … and just use mask-type to apply to <mask> 15:09:45 <heycam> birtles: I'd rather this 15:09:53 <heycam> TabAtkins__: and I think it's fine to think of the alpha-ness of luminance-ness as part of the image 15:11:21 <heycam> [discussion about changes to serizliation and computed values for -webkit-mask] 15:12:10 <heycam> RESOLUTION: mask-type now only applies to <mask>, and the [ alpha | luminance | auto ] goes in the mask-image value 15:12:31 <heycam> krit: next problem is related 15:12:38 <heycam> … mask-image has syntax like background-image 15:12:40 <heycam> … so it clips to a region 15:12:57 <heycam> … we have a predefined clipping regions border-box, content-box and padding-box 15:13:01 <heycam> s/have a/have/ 15:13:15 <heycam> … I would suggest defining for SVG that border-box means painted rectangle 15:13:28 <heycam> heycam: what's the default? 15:13:46 <heycam> TabAtkins__: border-box 15:14:23 <heycam> ed: if you ahve an SVG inline in HTML, you might want the actual border-box of the outer <svg> 15:14:28 <heycam> TabAtkins__: yes it should mean that on the outer <svg> 15:14:30 <heycam> s/ahve/have/ 15:16:14 <heycam> TabAtkins__: padding-box should map to normal bounding box 15:16:18 <heycam> krit: that's what it is currently 15:17:05 <heycam> RESOLUTION: {border-box, content-box, padding-box} should map to {painted bbox, normal bbox, normal bbox} for mask-clip 15:17:17 <heycam> ed: would you ever want to have a box that includes the filters? markers? 15:17:19 <heycam> krit: we need to discuss this 15:17:28 <heycam> … I'd rather no, because we would do this masking on the gpu 15:17:43 <heycam> heycam: markers are already included in border-box 15:21:59 <heycam> TabAtkins__: if you have a drop shadow applied to an element, then using mask-clip will clip that away 15:22:59 <heycam> krit: the old mask property still works the same way 15:23:16 <heycam> … the url() references <mask> and can still have x/y/width/height on it 15:26:18 <shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Path_toJSON 15:26:49 <ed> RRSAgent, make minutes 15:26:49 <RRSAgent> I have made the request to generate http://www.w3.org/2012/09/17-svg-minutes.html ed 15:37:26 <cabanier> cabanier has joined #svg 15:42:17 <cabanier> cabanier has joined #svg 15:44:43 <konno_> konno_ has joined #svg 16:04:39 <shepazu> shepazu has joined #svg 16:09:10 <krit> krit has joined #svg 16:15:02 <jet> jet has joined #svg 16:30:31 <jarek> jarek has joined #svg 16:31:18 <Zakim> Zakim has left #svg 16:56:09 <konno> konno has joined #svg 17:32:35 <cabanier> cabanier has joined #svg 18:21:10 <thorton> thorton has joined #svg 19:00:45 <victor> victor has joined #svg 20:56:12 <shepazu> shepazu has joined #svg 21:50:20 <cabanier> cabanier has joined #svg 21:52:27 <krit> krit has joined #svg 23:39:41 <glenn> glenn has joined #svg