IRC log of svg on 2012-09-17

Timestamps are in UTC.

07:01:47 [RRSAgent]
RRSAgent has joined #svg
07:01:47 [RRSAgent]
logging to
07:01:49 [trackbot]
RRSAgent, make logs public
07:01:49 [Zakim]
Zakim has joined #svg
07:01:51 [trackbot]
Zakim, this will be GA_SVGWG
07:01:51 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
07:01:52 [trackbot]
Meeting: SVG Working Group Teleconference
07:01:52 [trackbot]
Date: 17 September 2012
07:03:04 [heycam]
Meeting: SVG WG Switzerland F2F Day 1
07:03:07 [heycam]
Chair: Cameron
07:03:45 [birtles]
birtles has joined #svg
07:04:22 [heycam]
07:06:06 [krit]
krit has joined #svg
07:06:31 [krit]
Zakim, krit is me :D
07:06:31 [Zakim]
I don't understand 'krit is me :D', krit
07:09:22 [Tav]
Tav has joined #svg
07:10:39 [nikos]
nikos has joined #svg
07:11:11 [nikos]
scribenick: nikos
07:11:49 [nikos]
Topic: Pass Path object to SVG path
07:11:49 [stakagi]
stakagi has joined #svg
07:12:22 [nikos]
krit: It would be better to discuss this when Tab is here
07:12:26 [nikos]
Topic moved
07:13:12 [nikos]
Topic: Linking to external style sheets — should we have <link>?
07:13:38 [nikos]
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 [nikos]
... we should have another way as well
07:13:47 [nikos]
... we at least need to say @import works
07:13:55 [nikos]
... referencing css should get that for free
07:14:23 [nikos]
krit: Is it not possible currently?
07:14:27 [nikos]
heycam: You can
07:15:32 [heycam]
07:16:18 [nikos]
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 [nikos]
... one option is to have link in svg, just like in html
07:16:35 [nikos]
birtles: yes
07:16:57 [nikos]
ed: What would happen if you copy pasted svg with link element into html5
07:17:30 [nikos]
... 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 [nikos]
... you can create it with the dom or put it in a foreignObejct
07:17:51 [nikos]
07:17:58 [nikos]
heycam: it seems to work in firefox
07:18:57 [nikos]
heycam: I was testing whether the parser breaks out into html
07:19:01 [heycam]!DOCTYPE%20html%3E%0A%3Csvg%3E%3Clink%3E%3Cscript%3Ew(document.getElementsByTagName(%27link%27)%5B0%5D.namespaceURI)%3C%2Fscript%3E
07:19:13 [nikos]
shepazu: Isn't there a white listing of svg elements? or is that just for changing case?
07:19:22 [nikos]
heycam: Yes, just changing case
07:19:47 [nikos]
krit: what happens if you move the node in the DOM?
07:20:02 [nikos]
heycam: I think the link element in the html namespace doesn't have any effect at the moment
07:20:29 [nikos]
... if you try and reference some stylesheet would it work?
07:20:48 [nikos]
... it looks like the way it behaves is - you can have it anywhere in the document
07:21:00 [nikos]
... if we want it to work we specify it the same way except it's in the svg namespace
07:21:29 [andreas]
andreas has joined #svg
07:21:40 [victor]
victor has joined #svg
07:21:42 [nikos]
... 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 [nikos]
krit: I'm just testing safari, if you put a link elements it's in the svg namespace
07:22:55 [nikos]
heycam: what do you think of the idea dirk?
07:23:11 [nikos]
krit: I like it but I'm wondering what happens when you move nodes in the DOM
07:23:41 [nikos]
... I'm a bit afraid the namespace won't change if you move it in the DOM
07:23:48 [nikos]
heycam: nothing changes automatically when you move it
07:23:52 [nikos]
krit: and is that ok?
07:24:11 [nikos]
shepazu: henry will complain about changes to the parser - are there any?
07:24:18 [nikos]
heycam: not for this because it's already in the svg namespace
07:24:25 [nikos]
... maybe it would be a problem if it broke out
07:24:30 [birtles]
07:24:32 [nikos]
krit: I wish to have the link element
07:24:40 [nikos]
heycam: it gets put in the html namespace
07:24:59 [nikos]
... you can't declare namespaces explicitly but the dom nodes get created in the namespace
07:25:20 [nikos]
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 [nikos]
heycam: I think it would work nice and obviously
07:26:07 [nikos]
cabanier: it works in Chrome
07:27:06 [nikos]
shepazu: if that's true, we should match that user agent
07:28:01 [nikos]
heycam: I couldn't get it work in Chrome
07:28:48 [nikos]
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 [nikos]
... so it's like half implemented
07:30:04 [ed]!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 [nikos]
heycam: anyone think it's bad idea
07:30:12 [nikos]
all: no
07:30:20 [nikos]
shepazu: we should ask the html working group
07:30:28 [nikos]
heycam: we should ask them if there is anything we haven't thought of
07:30:54 [nikos]
Resolution: We will add a link element to SVG that behaves in the same way as HTML
07:32:00 [nikos]
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 [trackbot]
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]
konno has joined #svg
07:33:23 [nikos]
Topic: enable-background naming in relation to compositing and blending
07:33:35 [nikos]
cabanier: The name is a bit confusing
07:33:44 [nikos]
... it doesn't match what users are familiar
07:33:50 [nikos]
... in the compositing spec it was replaced with isolation
07:34:16 [nikos]
... so we have the existing enable-background keyword, we can't get rid of it or it will break content
07:34:22 [nikos]
... we were thinking of having it shadow
07:34:26 [nikos]
... like an alias
07:34:35 [nikos]
krit: css wg tries to define shadowing properly
07:34:47 [nikos]
... they have the same problem for some text properties
07:35:37 [andreas]
andreas has joined #svg
07:36:01 [nikos]
nikos: we are thinking that the property should apply to compositing and blending and filter effects
07:36:08 [nikos]
... you shouldn't be able to specify different modes for each
07:36:28 [nikos]
heycam: so there's 2 issues really, having the property apply to both and the naming
07:36:37 [nikos]
heycam: do you have an example of css shadowing?
07:36:56 [nikos]
krit: not yet, we don't have a specification, but the css wg have expressed an interest in the idea
07:37:05 [nikos]
heycam: what about if you use the css om to look up property values?
07:37:18 [nikos]
... like there's a single variable underneath but there's 2 properties
07:37:30 [nikos]
krit: the question is which takes effect if both are specified
07:37:34 [nikos]
cabanier: I think the last one wins
07:39:24 [nikos]
... what happens currently if you say 'opacity=1 opacity=0.5'?
07:39:51 [nikos]
heycam: what happens currently for prefixed and not when you support them both?
07:40:03 [nikos]
krit: they are both in the style declaration as far as I know
07:40:08 [nikos]
heycam: with one underlying variable?
07:40:17 [nikos]
krit: I'll have to check
07:40:30 [nikos]
heycam: I assume the css working group wants to define how this works and not us
07:40:37 [nikos]
cabanier: so are we ok combining them?
07:40:47 [nikos]
heycam: I think so - as long as enable-background works for existing things
07:40:59 [nikos]
... so enable-background has numbers when you specify new? or did we get rid of that
07:41:03 [nikos]
krit: we got rid of that
07:41:35 [nikos]
krit: looking at the source code - we treat them as different properties
07:42:09 [nikos]
... for box-shadow and webkit-box-shadow we have two different style declarations
07:42:23 [nikos]
... you can set box-shadow and webkit-box-shadow and they can be different
07:42:36 [nikos]
... when rendering one will win but I'm not sure which
07:42:47 [nikos]
heycam: I think that as long as it is worked out then I'm ok with it
07:43:01 [nikos]
cabanier: do we know who is working on the shadowing?
07:43:08 [nikos]
krit: no, we'll have to ask
07:44:07 [nikos]
Resolution: We want isolation property to shadow enable-background and we will ask the CSS working group about the details
07:44:19 [nikos]
Action: Rik to ask CSS WG about how shadowing will work for enable-background
07:44:19 [trackbot]
Created ACTION-3352 - Ask CSS WG about how shadowing will work for enable-background [on Rik Cabanier - due 2012-09-24].
07:45:02 [nikos]
krit: I think we will put both properties in Filter Effects and mark one as preferable
07:45:24 [nikos]
nikos: So is it ok for one property to control both filter-effects and compositing and blending?
07:45:28 [nikos]
all: yes that's ok
07:46:03 [nikos]
Resolution: The enable-background/isolation will apply to both Filter Effects and Compositing and Blending
07:46:34 [nikos]
Topic: Filter Effects - keep new fe*elements that lack description ATM?
07:47:04 [krit]
07:47:17 [krit]
07:47:35 [nikos]
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 [nikos]
... I'm just talking about filter primitives and not the shorthands
07:48:15 [nikos]
cabanier: does anybody implement these?
07:48:17 [nikos]
krit: no
07:48:28 [nikos]
krit: we are about to implement feCustom
07:48:33 [nikos]
heycam: who wanted them ?
07:48:48 [nikos]
ed: diffuse specular was meant to be an optimisation to give better performance
07:48:58 [nikos]
... I'm not sure if it's really needed as the filter chain does the optimisation
07:49:08 [nikos]
heycam: would it make it better for authors?
07:49:11 [nikos]
ed: probably not
07:49:17 [nikos]
heycam: I say get rid of them then
07:49:31 [nikos]
ed: I don't mind removing them if they don't seem to be useful
07:50:37 [nikos]
ed: you could do feUnsharpMaskElement with scripting and other filter effects
07:50:41 [nikos]
... but we don't have a shorthand for it
07:50:46 [nikos]
Resolution: Remove feUnsharp and feDiffuseSpecular from Filter Effects specification for now - may be added again in future
07:50:54 [krit]
07:51:05 [nikos]
Topic: Filter Functions
07:51:19 [nikos]
are other shorthands needed?
07:51:36 [nikos]
krit: The question is do we put in a bug report on Safari for functions that are not implemented?
07:52:07 [ed]
s/filter chain does the optimisation/implementation can analyze the filter chain and do the same optimisation
07:52:25 [nikos]
krit: I had suggestions for other filter functions that we could have, but I have not had any feedback
07:52:31 [nikos]
... so I'm wondering if we can remove the issue
07:53:02 [nikos]
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 [nikos]
krit: there's no problem adding new shorthands in the later version
07:53:17 [nikos]
... the question is do we freeze what we have now?
07:53:28 [nikos]
heycam: I think the set that is there currently is a reasonable set
07:54:20 [nikos]
Resolution: Remove filter function suggestions (issue 5) from Filter Effects spec
07:55:03 [nikos]
Action: Dirk to file a bug and track filter functions (issue 5) removed from Filter Effects spec
07:55:04 [trackbot]
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 [nikos]
Topic: Removing pixelUnitToMillimeter{X,Y} and screenPixelToMillimeter{X,Y}
07:56:06 [nikos]
heycam: I didn't know this existed and I'm not sure anyone would use these API functions
07:56:09 [nikos]
krit: Is anyone using them?
07:56:14 [nikos]
heycam: I'm not sure, I can check.
07:56:30 [nikos]
andreas: is there an alternative way to get at the pixel size?
07:56:48 [nikos]
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 [nikos]
cabanier: you mean the HD stuff?
07:56:59 [nikos]
heycam: I'm not sure
07:57:03 [nikos]
krit: so why do you want to remove it?
07:57:17 [nikos]
heycam: our implementation returns a constant value assuming 96 dpi.
07:57:22 [nikos]
cabanier: what does webkit do?
07:57:25 [nikos]
krit: the same thing
07:57:58 [nikos]
cabanier: it could be implemented to not be constant in the future - for HD devices
07:58:26 [nikos]
krit: the idea is that we want to know how many mm it is on the screen
07:58:36 [shepazu]
shepazu has joined #svg
07:58:40 [nikos]
heycam: I remember people objecting to that in some other context
07:59:00 [nikos]
cabanier: how do you know what the screen size is?
07:59:44 [nikos]
krit: Firefox used to expose that information in an API but removed it.
07:59:54 [nikos]
heycam: now everyone has converged on CSS units being a fixed number of pixels
08:00:08 [nikos]
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 [nikos]
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 [nikos]
krit: I don't know how they would be used
08:01:45 [nikos]
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 [nikos]
ed: Opera is hard coded also
08:02:28 [nikos]
... I think it's the same value as other implementations
08:03:04 [nikos]
krit: the css working group is looking into ways to get screen pixels per CSS pixel.
08:03:15 [nikos]
heycam: but it doesn't tell you the physical size
08:03:35 [nikos]
cabanier: are you going to remove pixels per inch as well?
08:03:43 [nikos]
heycam: yep there's not 4 methods
08:03:59 [nikos]
cabanier: I think somebody somewhere is using them
08:04:05 [nikos]
ed: I'd be surprised to see them used
08:05:09 [nikos]
heycam: I just googled screenPixelToMillimeterX and got no hits
08:05:14 [nikos]
... with svg file types
08:05:34 [nikos]
cabanier: I wonder if they will become more useful
08:05:39 [nikos]
... in future
08:08:01 [nikos]
heycam: I would like to ask the CSS WG what they think about units
08:08:23 [nikos]
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 [nikos]
heycam: the topic about mm not being real mm anymore comes up often and I'd like to know the details
08:08:55 [nikos]
... is it because it's probably not what authors want
08:09:15 [nikos]
krit: if I say 2cm but then project it on the wall I don't want it to be 2 cm
08:10:59 [nikos]
heycam: I'll ask Chris
08:12:51 [nikos]
Topic: How to internationalize "title"?
08:13:05 [nikos]
Tav: This came up at SVG open. Someone was asking whether it could be done.
08:13:21 [nikos]
heycam: My first suggestion would be to allow system language on the title element.
08:13:25 [nikos]
ed: that's already done isn't it ?
08:13:30 [nikos]
heycam: I'll look
08:13:42 [nikos]
... The question is how to internationalise the title
08:13:50 [nikos]
shepazu: how about we use switch?
08:14:33 [nikos]
Tav: how would it work?
08:14:44 [nikos]
shepazu: you would have the switch element with different copies of the titles
08:15:02 [nikos]
heycam: what is switch a child of ?
08:15:13 [nikos]
shepazu: how about we change switch to allow text content ( if it doesn't already)
08:15:36 [nikos]
... I think switch only works at an element level now and not at a text level
08:15:41 [nikos]
... I think we should change it to text
08:15:51 [nikos]
... then you would switch on the actual text content rather than on the element
08:15:57 [nikos]
... title would be a child element
08:16:27 [nikos]
krit: can you change paragraphs in HTML to change content based on the language?
08:16:31 [nikos]
shepazu: there is no mechanism for doing that
08:16:57 [nikos]
... 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 [nikos]
... we have a few options
08:17:18 [nikos]
... we can change switch to have text content, but what is the child element of the switch
08:17:33 [nikos]
... we can change title apply to the parent of the switch
08:17:50 [nikos]
... 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 [nikos]
Tav: what about the desc element?
08:18:19 [nikos]
shepazu: or tooltip, or whatever
08:18:27 [nikos]
... they'd be the same
08:18:45 [nikos]
heycam: on switch you can have all the group attributes.
08:18:56 [nikos]
shepazu: people shouldn't use switch for that - you can but you shouldn't
08:19:01 [nikos]
... switch should be transparent
08:19:12 [nikos]
heycam: I think you should be able to do multiple title elements
08:19:37 [nikos]
... like <rect><title systemLanguage="..." />
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:
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]
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]
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]
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]
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]
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]
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]
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]
14:06:34 [krit]
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]
14:14:29 [ChrisL] 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] glsl implementation of Perlin and simplex noise
14:20:33 [ed]
here's an example using a bit of turbulence: http://dahlströ
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]
14:24:25 [ChrisL]
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]
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__]
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:
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]
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]
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]
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]
15:26:49 [ed]
RRSAgent, make minutes
15:26:49 [RRSAgent]
I have made the request to generate 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