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 http://www.w3.org/2012/09/17-svg-irc

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]

Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Agenda

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]

s/can/can't/

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]

s/foreignObejct/foreignObject

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]

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 [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]

s/henry/henri/

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]

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 [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]

https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feUnsharpMaskElement

07:47:17 [krit]

https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feDiffuseSpecularElement

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]

https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterFunction

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: 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