20:59:05 <RRSAgent> RRSAgent has joined #svg
20:59:05 <RRSAgent> logging to http://www.w3.org/2012/08/30-svg-irc
20:59:07 <trackbot> RRSAgent, make logs public
20:59:07 <Zakim> Zakim has joined #svg
20:59:09 <trackbot> Zakim, this will be GA_SVGWG
20:59:09 <Zakim> ok, trackbot, I see GA_SVGWG(SVG1)5:00PM already started
20:59:10 <trackbot> Meeting: SVG Working Group Teleconference
20:59:10 <trackbot> Date: 30 August 2012
20:59:26 <krit> Zakim, who is on the phone
20:59:26 <Zakim> I don't understand 'who is on the phone', krit
20:59:40 <heycam> Zakim, who is on the phone?
20:59:40 <Zakim> On the phone I see +1.415.832.aaaa, ??P3
20:59:56 <krit> Zakim: aaaa is me
20:59:59 <birtles> Zakim, ??P3 is me
20:59:59 <Zakim> +birtles; got it
21:00:00 <Zakim> +nikos
21:00:07 <krit> Zakim, aaaa is me
21:00:07 <Zakim> +krit; got it
21:00:20 <Zakim> +??P19
21:00:33 <ed> Zakim, ??P19 is me
21:00:33 <Zakim> +ed; got it
21:00:41 <Tav> Tav has joined #svg
21:00:44 <Zakim> +[IPcaller]
21:00:45 <heycam> Zakim, [ is me
21:00:45 <Zakim> +heycam; got it
21:01:12 <heycam> Chair: Cameron
21:01:15 <heycam> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSep/0179.html
21:02:25 <heycam> Zakim, who is on the call?
21:02:25 <Zakim> On the phone I see krit, birtles, nikos, ed, heycam
21:03:33 <Zakim> + +33.9.80.39.aabb
21:04:02 <cyril_> cyril_ has joined #svg
21:05:19 <nikos> scribenick: nikos
21:05:30 <Zakim> +Rich
21:05:38 <nikos> Topic: CSS4 image type as paint value
21:05:42 <heycam> http://www.w3.org/mid/FBBDBDBC-F3CD-404E-AFC1-0369A75DAA89@adobe.com
21:05:44 <cyril_> zakim, who is here?
21:05:44 <Zakim> On the phone I see krit, birtles, nikos, ed, heycam, +33.9.80.39.aabb, Rich
21:05:52 <cyril_> zakim, +33 is me
21:05:52 <Zakim> +cyril_; got it
21:06:05 <nikos> krit: Doesn't matter about the version. I'd just like to use CSS image
21:06:13 <nikos> ... then we get linear gradient and other gradients
21:06:30 <Zakim> + +33.9.53.77.aacc
21:06:58 <nikos> ... If we use CSS image as a paint server then it's possible to use images or filters or anything that is defined by CSS image
21:07:03 <Tav> zakim, +33.9.53 is me
21:07:03 <Zakim> +Tav; got it
21:07:39 <nikos> birtles: What about making paint servers part of images?
21:07:59 <nikos> ... a lot of CSS specs refer to image values, why not do it the other way around
21:08:04 <nikos> ... then you could use an SVG gradient in CSS
21:08:11 <nikos> krit: That is in CSS4 image
21:08:13 <ed> so <rect fill="linear-gradient(bottom, rgb(149,227,138) 47%, rgb(179,255,166) 74%)" .../> for example
21:08:40 <Zakim> +Doug_Schepers
21:08:44 <nikos> ... we need to figure out how it works because it could lead to circular dependency
21:09:37 <nikos> krit: The element function can reference paint servers from SVG
21:10:03 <nikos> heycam: Do you want paint server references just inside that element or do you allow urls?
21:10:20 <krit> http://dev.w3.org/csswg/css3-images/#image-values
21:10:22 <nikos> krit: I am just asking if we can use the css image type in SVG fill and stroke properties
21:10:52 <cyril_> q+
21:11:01 <nikos> ... in the beginning I'd be fine with gradient
21:11:17 <heycam> ack
21:11:25 <nikos> ... image would be cool but if we just have gradient that would be good
21:11:55 <nikos> cyril_: for gradients or patterns you have the gradient limits that tells you how the gradient space maps to the image space
21:11:59 <nikos> ... how would you do that
21:12:11 <nikos> krit: you need to define how the bounding box is defined for svg and it would maybe be object bounding box
21:12:37 <nikos> cyril_: would the svg objects crop the image or would the image be entirely contained in the svg object?
21:12:51 <nikos> krit: you mean referencing an image with a url?
21:13:03 <nikos> cyril_: any image. css3 image fills an object with an image
21:13:23 <nikos> ... you might end up with an image size different from the svg object size so you need to crop, or reflect, or something
21:13:33 <nikos> krit: at the beginning we might just define gradient. its easier
21:13:48 <krit> http://dev.w3.org/csswg/css3-images/#gradient-type
21:14:05 <heycam> Zakim, who is making noise?
21:14:19 <Zakim> heycam, listening for 12 seconds I heard sound from the following: cyril_ (47%)
21:14:23 <nikos> Zakim, who is noisy?
21:14:38 <Zakim> nikos, listening for 13 seconds I heard sound from the following: krit (3%), cyril_ (7%), Tav (22%)
21:14:56 <heycam> Zakim, mute Tav
21:14:56 <Zakim> Tav should now be muted
21:15:37 <nikos> cyril_: Using percentages or integers or fixed values, you can say the image will take more or less than the bounding box of the object
21:15:44 <nikos> ... you have to define if you crop, or what you do
21:15:48 <nikos> krit: I agree with that
21:16:06 <nikos> ... At the beginning I'd be fine to just use gradients as this isn't a problem for them
21:16:16 <nikos> ... you just need to define a box, and we'd just use the object bounding box
21:16:35 <nikos> heycam: I think cyrils concern was that it's not clear whether gradients cover the entire box or whether you pad or repeat
21:17:24 <nikos> heycam: I think we need a way to specify whether you repeat in horizontal or vertical directions
21:17:47 <nikos> nikos: I think dirk is saying you use the object bounding box so the dimensions always match up
21:18:10 <nikos> cyril_: in css gradients I don't think you can specify where the 2 end points of the vector definining the gradient are - except for top or bottom
21:18:16 <nikos> heycam: you can give a length value
21:18:25 <nikos> s/definining/defining
21:18:36 <nikos> cyril_: I'm seeing left, right, top, bottom, thats it
21:18:48 <nikos> ... you can't say I want the points to be 10% inside
21:18:55 <nikos> ... then you don't have to specify pad or repeat
21:19:12 <nikos> cyril_: there is a repeating linear gradient
21:19:27 <nikos> krit: that's a limitation in css gradients in general, why is it a problem for svg?
21:19:40 <nikos> cyril_: I'm just saying it needs to be specified how the object is filled when the gradient is not big enough
21:19:48 <nikos> heycam: from what I can see it will always be big enough
21:19:57 <nikos> ... you have stops that go from 0 to 100% 
21:20:13 <nikos> cyril_: Yeh with gradient it seems you will always fill the object
21:20:29 <nikos> heycam: With images I think you're right about fitting. 
21:20:47 <nikos> heycam: Are the only types images and gradients?
21:20:53 <nikos> cyril_: url image_list and gradient
21:21:20 <nikos> heycam: I'm sure we could define how the image renders without adding more controls like various background repeat properties
21:21:27 <nikos> ... I don't know how useful it is to solve that here
21:21:37 <nikos> ... maybe in that case you need to use a pattern for example
21:21:57 <nikos> krit: Can we resolve for linear gradient and solve the other problems later?
21:22:03 <nikos> heycam: I'm happy with it
21:22:07 <nikos> ed: I agree
21:22:16 <nikos> cyril_: what would be the benefit compared to using svg gradient?
21:22:22 <nikos> krit: you can apply a linear gradient to a class of object
21:22:33 <nikos> ... and use the same gradient for html and svg content
21:22:40 <nikos> cyril_: ok
21:22:59 <nikos> heycam: it's also an easier way to specify a gradient
21:23:37 <nikos> Resolution: Paint values will allow gradients from CSS3 image
21:23:58 <nikos> krit: CSS image 3 is already a REC
21:24:10 <heycam> http://dev.w3.org/csswg/css3-images/#repeating-gradients
21:24:11 <nikos> heycam: I see you can do repeating gradient styles in CSS
21:24:24 <nikos> cyril_: in any case it's going to fill the whole object
21:24:55 <nikos> krit: will it be in the SVG2 FPWD or is it for the future?
21:25:08 <nikos> heycam: I think we've discussed this before in the context of referencing as many CSS specs as possible
21:25:13 <nikos> krit: so SVG 2 then
21:25:26 <nikos> ... next draft release
21:25:28 <nikos> heycam: If you have time
21:25:54 <nikos> Action: Dirk to edit SVG 2 draft to add CSS 3 gradients as a paint value
21:25:54 <trackbot> Created ACTION-3346 - Edit SVG 2 draft to add CSS 3 gradients as a paint value [on Dirk Schulze - due 2012-09-06].
21:26:10 <nikos> Topic: Filter subregion clipping
21:26:30 <nikos> ed: I sent my comments to the public mailing list
21:26:37 <nikos> ... I think it addressed both discussions
21:26:46 <nikos> ... feOffset and how to define input and output clipping
21:27:04 <ed>  http://lists.w3.org/Archives/Public/www-svg/2012Aug/0143.html
21:28:09 <nikos> ed: so in Opera we treat feOffset not exactly as the spec tells us to, because if you consider the example in the mail, feOffset itself doesn't specify a primitive subregion - doesn't have x, y and width. Intuitively for me I wouldn't expect it to clip, I'd expect it to move the previous primitive
21:29:26 <nikos> krit: I would agree that we don't need to clip the offset, we move it around
21:30:08 <nikos> krit: Do you clip if you move a primitive to the outside of filter regions then bring it back in?
21:30:22 <nikos> heycam: do you clip at each step or just once at the end?
21:30:52 <nikos> ed: Could you post an example?
21:30:59 <krit> <filter id="feoffset1" primitiveUnits="objectBoundingBox" x="0%" y="0%"  
21:30:59 <krit> width="100%" height="100%">
21:30:59 <krit>    <feFlood width="100%" height="100%" flood-color="lime"/>
21:30:59 <krit>    <feOffset dx="0.1" dy="0.2"/>
21:30:59 <krit> </filter>
21:31:59 <nikos> ed: So you move the result out and back again?
21:32:04 <nikos> ... what would you expect in that case?
21:32:09 <nikos> krit: I think the spec says it's clipped away
21:32:16 <nikos> ... when you move it back you are just moving transparent black back
21:32:44 <nikos> ed: I'm not really sure what I'd expect in that case
21:32:51 <nikos> ... I think I might expect to be able to move the result back
21:33:03 <nikos> ... it would be interesting to see what the implementations do
21:33:15 <nikos> krit: it would be interesting to see what gaussian blur does
21:34:01 <nikos> ed: I think it would be interesting to have some way of letting the user agent find out what the filter region is automatically, but we'd have to be careful not to break content
21:34:31 <nikos> krit: In this case we definitely should clip, the question is does opera clip
21:34:45 <nikos> krit: Do you clip the input or the output?
21:34:52 <nikos> ... that's a general question
21:35:00 <nikos> ed: I think we do input clipping
21:35:25 <nikos> krit: filter effects spec requires input and output clipping, which is not useful in my eyes
21:35:37 <nikos> ed: So do we want to control this, or do we require one particular way?
21:35:44 <nikos> krit: I think both input and output is not useful
21:35:50 <nikos> ... I don't care if we go with input or output
21:36:11 <nikos> heycam: what might break if we switched? if we specified just output
21:36:23 <nikos> krit: we are really discussion an edge case so I wouldn't expect much to break
21:36:32 <nikos> heycam: it only matters to primitives that do things outside their region
21:37:03 <nikos> heycam: most filter primitives say their input and output regions are the same
21:37:07 <nikos> ... is that right?
21:37:31 <nikos> krit: by default, firefox's subregion depends on the previous subregion so if you have 2 filters of different size, it is the union of both
21:37:44 <nikos> ... when you specify x, y, w and h what should be clipped, the input or the output?
21:38:19 <nikos> ed: do you have a test case?
21:38:31 <nikos> krit: I have posted something to the mailing list
21:38:43 <nikos> ed: I'm looking for something that doesn't use feOffset
21:38:48 <nikos> krit: it's difficult without feOffset
21:39:07 <nikos> ed: We treat it differently, we don't take the union of the inputs, we use the filter region itself if you don't specify
21:39:55 <nikos> heycam: apart from whether you do clipping on input or output. Dirk, do you think it makes sense to special case feOffset?
21:40:04 <nikos> krit: if you don't have input clipping it doesn't matter
21:40:18 <nikos> ... in that case the subregion depends on the clipregion of the feOffset filter
21:40:45 <nikos> ... I'd have to think about it some more
21:41:10 <nikos> krit: right now the specification wants to clip to the region always
21:41:17 <nikos> heycam: the spec only says clip the input and output both
21:41:36 <nikos> ... to make feOffset more useful, would we need to change it to only output or only input? or is that a separate issue
21:41:40 <nikos> krit: I think it's separate
21:41:55 <nikos> ed: I think it would be nice to have an analysis of where and when it's useful to have each clipping method
21:42:09 <nikos> heycam: I think it would be good too, I find it hard to visualise why you'd take one or the other
21:42:20 <nikos> ed: There's one example in the spec but I don't think it uses feOffset
21:42:29 <nikos> ... There's also the example from the mail and the bug report
21:42:39 <nikos> ... but apart from that I don't think we have many tests for this
21:43:51 <nikos> Action: Dirk to investigate and expand on the proposal of sub region clipping for Filter Effects
21:43:51 <trackbot> Created ACTION-3347 - Investigate and expand on the proposal of sub region clipping for Filter Effects [on Dirk Schulze - due 2012-09-06].
21:44:17 <nikos> heycam: what about for the other issue of whether feOffset behaviour should be special?
21:44:22 <nikos> krit: I'll look into that as well
21:44:28 <nikos> ed: They're similar but not quite the same
21:44:43 <krit> nikos: great, thanks. Let us share the examples next week
21:44:52 <krit> haha
21:45:26 <nikos> heycam: i imagine you could construct the filter to avoid the problem - don't shift outside the region
21:46:32 <nikos> ed: not many people write advanced filters
21:46:45 <nikos> heycam: we'll pick up the discussion once dirk has had a look
21:46:56 <nikos> Topic: Behaviour of feOffset dx/dy values with percentages
21:47:17 <ed> s/people write advanced filters/people write such advanced filters that they would run into this issue/
21:47:25 <nikos> heycam: does anyone support percentage values for dx and dy?
21:47:57 <nikos> krit: if you use 50% then it is treated as 50
21:48:06 <nikos> ... on webkit
21:48:17 <Zakim> -cyril_
21:48:36 <nikos> heycam: we should make percentages work or disallow them
21:48:49 <nikos> krit: We already support percentage - but indirectly
21:48:57 <Zakim> +cyril_
21:49:05 <nikos> heycam: why is it that dx and dy unitless values are treated as unit bounding box values and not ...
21:50:17 <nikos> heycam: if you have unit less values they are just user units
21:50:40 <nikos> heycam: there's nothing weird and I'd expect percentages to be percentages of the viewport
21:50:53 <nikos> ... if you have primitive space = user space on use, dx and dy should be percentages of the viewport?
21:51:02 <nikos> krit: if you supported percentages, but we don't
21:51:12 <nikos> heycam: do we have other primitives that take percentages?
21:51:16 <nikos> krit: no
21:51:41 <nikos> heycam: my feeling is that we should make percentages work
21:51:53 <nikos> krit: and for other cases?
21:52:02 <nikos> ... where percentages could work?
21:53:08 <nikos> heycam: so the issue with standard deviation is it's a number not a length right?
21:53:10 <krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterFunction
21:53:26 <nikos> ... in the corresponding shorthand if we are going to support lengths, we should take lengths in the element
21:54:32 <Zakim> -Tav
21:54:36 <nikos> heycam: I'm thinking whether it would be more consistent in general to support that, but I'm not sure that it's important
21:54:52 <nikos> ed: is there any particular examples?
21:54:59 <nikos> ... I'm looking for some kind of testcase to try out
21:55:03 <nikos> ... just wondering if you had one handy
21:55:20 <Zakim> +Tav
21:55:47 <nikos> heycam: I think dx and dy look like they go with width and height, you might expect them to take the same kinds of value
21:56:00 <nikos> krit: I agree
21:56:23 <nikos> heycam: I would be happy to say dx and dy take lengths and percentages and forget about the other things like standard deviation
21:56:35 <nikos> ed: I'd like to see an example before we make any changes
21:57:08 <nikos> Action: Dirk to provide examples of percentages with dx and dy in Filter Effects
21:57:08 <trackbot> Created ACTION-3348 - Provide examples of percentages with dx and dy in Filter Effects [on Dirk Schulze - due 2012-09-06].
21:57:27 <nikos> Topic: Commas vs spaces in SVG View fragment identifiers
21:58:13 <krit> http://dev.w3.org/csswg/css4-images/#image-fragments
21:58:13 <nikos> heycam: Robert brought up in the mailing list some text in the linking chapter that talks about how you must use commas rather than spaces in the viewbox part of an svg fragment. You can use %20 to encode spaces but it's easier to use commas.
21:58:36 <nikos> heycam: there's a similar issue in preserve aspect ratio, because you can have the slice value after the xMinyMin part
21:58:45 <nikos> ... and that normally takes a space between them
21:58:58 <nikos> ... I think viewbox also would normally take a space, so there's no issue saying just use a comma
21:59:13 <nikos> ... I think Robert was asking for a clarification on the grammar
21:59:39 <nikos> krit: I don't like spaces in iri
21:59:54 <nikos> ... I pasted a link to css image fragments, they comma separate
22:00:07 <nikos> ... I don't have a really strong opinion but I feel its more natural
22:00:15 <nikos> heycam: I agree, you don't really want to url encode
22:00:37 <nikos> ed: I agree with the comma, even though I don't like the svg view syntax.
22:00:43 <nikos> nikos has joined #svg
22:01:18 <nikos> krit: the css specifications use uri and svg uses iri
22:01:28 <nikos> ... in theory there's a difference but in practice there's not
22:01:39 <nikos> ... do we have a strong opinion that we should use iri?
22:02:01 <nikos> heycam: I raised something on the mailing list about the differences.  I didn't get a clear idea in the end whether one or the other should change or whether we ignore the situation
22:02:24 <nikos> krit: Filter Effects uses iri and the discussion on exclusions they want to use parts of svg that use iri
22:02:34 <nikos> ... it would be good to harmonise the specifications
22:02:48 <heycam> http://lists.w3.org/Archives/Public/www-style/2012May/0772.html
22:02:49 <Zakim> -birtles
22:03:13 <nikos> heycam: here's the mail where I asked how things in brackets are parsed, because I think the spec doesn't really say.
22:03:18 <nikos> ... I didn't really get a satisfactory answer
22:03:34 <nikos> ed: The Filter Effects spec uses iri because SVG 1 used IRI
22:03:40 <nikos> s/IRI/iri
22:04:15 <nikos> heycam: If you look at the data url in the email I linked to
22:04:41 <nikos> krit: iri just supports more characters right?
22:04:50 <nikos> heycam: yes, you can use non ascii characters
22:05:09 <nikos> heycam: for uri you would have to escape them somehow
22:05:18 <nikos> ... the test uses a css background image that has some non ascii characters
22:05:33 <nikos> ... and that seems to work everywhere so I assume browsers are interpreting as iri
22:05:40 <nikos> krit: you tested locally?
22:05:44 <nikos> heycam: no it's on a server
22:05:54 <nikos> ... if you view my example and 'view source'
22:06:21 <nikos> krit: it doesn't work in Safari
22:06:36 <nikos> ed: It doesn't seem to wokr in Opera either
22:06:49 <nikos> heycam: It may be because I left a bracket out of the example
22:07:34 <nikos> heycam: I think the issue is that the css spec needs to define how things inside the url brackets are parsed and interpreted
22:07:46 <heycam> http://lists.w3.org/Archives/Public/www-style/2012May/0824.html
22:08:09 <heycam> http://räksmörgås.josefsson.org/raksmorgas.jpg
22:08:16 <nikos> heycam: That's the test I meant to do... oh wait it doesn't have the brackets either
22:08:22 <nikos> ... I tried to link to that url in background-image
22:08:47 <nikos> ... I think the css spec needs to say that the things in the brackets are interpreted as iris or whatever they need to do to take non ascii characters
22:08:57 <nikos> krit: Can you bring it up with the css group?
22:09:04 <nikos> heycam: well I sent the mail, I think if you want to bring it up you can
22:09:48 <nikos> heycam: back to the topic. I think the question is whether we allow commas or spaces
22:09:58 <heycam> https://svgwg.org/svg2-draft/linking.html#SVGFragmentIdentifiers
22:10:25 <nikos> heycam: if you look at the grammar, you can see that the part of the grammar that refers to preserve aspect ratio, aspect params is defined in the list beneath and it's not defined properly
22:11:02 <nikos> ... given that spaces are said to be not allowed, we need to define it so that spaces are allowed or we can allow a comma
22:11:17 <nikos> ... I don't have a strong preferences
22:11:24 <nikos> s/preferences/preference
22:11:40 <nikos> ed: i was wondering about another issue, url escaping, firefox did allow the url escaped spaces to work
22:11:49 <nikos> ... I couldn't find anything in the spec but it would be nice to have it clarified
22:11:56 <nikos> heycam: I'm not sure what what level it should do that
22:12:08 <nikos> ... is suspect if we look at the html spec it will define it
22:12:19 <nikos> ... there was meant to be a new url spec, but I don't think it progressed much
22:12:27 <nikos> ... I think it was going to define this sort of thing
22:12:30 <nikos> shepazu: is anyone working on it?
22:12:36 <nikos> heycam: I think so but I don't know
22:12:50 <nikos> ... I suspect that that spec would define how to encode the fragments and decode them
22:12:59 <nikos> ... that's the level it should be at
22:13:35 <nikos> ... I agree it would be nice to have a link to somwhere that defines how to parse these fragments
22:13:41 <nikos> s/somwhere/somewhere
22:14:06 <nikos> Action: Cameron to look at the url spec or find out what we need to reference to make sure url fragments have a well defined encoding and decoding
22:14:07 <trackbot> Created ACTION-3349 - Look at the url spec or find out what we need to reference to make sure url fragments have a well defined encoding and decoding [on Cameron McCormack - due 2012-09-06].
22:14:38 <nikos> heycam: Erik or anyone do you have an opinion on what to do with the preserve aspect ratio part?
22:14:55 <nikos> ... I don't have a strong opinion
22:15:05 <nikos> ed: this is a special case, I'd prefer if parsing was the same as the attributes
22:15:12 <nikos> ... might not be possible
22:15:15 <nikos> heycam: we can make it possible
22:15:20 <nikos> ed: that would be easier implementation wise
22:15:44 <nikos> ... it's not hard anyway but consistency would be nice
22:15:53 <nikos> shepazu: consistency means a better experience for everyone
22:16:07 <nikos> heycam: are there any other examples?
22:16:13 <nikos> shepazu: any attribute can have keywords
22:16:43 <ed> requiredFeatures is space-separated I think
22:17:10 <ed> http://www.w3.org/TR/SVG11/struct.html#ConditionalProcessingRequiredFeaturesAttribute
22:17:13 <nikos> heycam: I think you can't just have an arbitrary name in there or the property would fail to parse
22:17:20 <nikos> ... I was wondering about non property attributes
22:17:54 <nikos> ... I don't know any off the top of my head
22:18:12 <nikos> ... I'm concerned whether we allow commas in preserve aspect ratio whether that will lead to it happening elsewhere
22:18:19 <nikos> ... there may not be any other cases
22:18:32 <nikos> shepazu: there's the text, they're not keywords, they're values. Like x or y for text
22:18:36 <nikos> heycam: we do allow commas there
22:18:54 <nikos> shepazu: there was a kerfuffle with stroke dash array because it wasn't specified
22:18:57 <nikos> ... we fixed that
22:19:01 <shepazu> http://www.w3.org/TR/SVG/attindex.html
22:19:15 <nikos> heycam: Unfortunately the type of value isn't in that table
22:19:45 <nikos> heycam: there's things that take number-space-number and they don't take commas
22:19:55 <nikos> shepazu: number-delimited-number should allow anything
22:20:11 <nikos> ... should allow comma or space or a combination rather
22:20:35 <nikos> shepazu: oh transforms!
22:20:53 <nikos> ... you can have a space separated list of values and I don't think you can use a comma there
22:20:56 <nikos> heycam: I think you're right
22:21:06 <nikos> krit: they can be comma or space separated
22:21:16 <nikos> heycam: they can in the attribute but not in the property
22:22:12 <nikos> viewbox and zoomAndPan are the only ones I can see
22:23:06 <nikos> heycam: let me, suggest we allow commas in preserveApsectRatio
22:24:16 <richardschwerdtfe> have to drop
22:24:19 <nikos> Resolution: preserveAspectRatio will allow commas in the attribute and that part of the view specification
22:24:36 <Zakim> -Rich
22:25:01 <nikos> Action: Cameron to update preserveApsectRatio in view specification to allow commas
22:25:02 <trackbot> Created ACTION-3350 - Update preserveApsectRatio in view specification to allow commas [on Cameron McCormack - due 2012-09-06].
22:26:37 <nikos> Topic: maskType, and camel case elements/attributes more generally
22:26:42 <Zakim> -Tav
22:26:45 <nikos> heycam: We might need to discuss this at the F2F
22:27:00 <nikos> shepazu: I think that we should not capitalise anything
22:27:05 <nikos> heycam: I think that's what Simon wanted
22:27:10 <nikos> ... at least on new things
22:27:21 <shepazu> CAPITALIZE NONE OF THE THINGS!
22:27:34 <nikos> heycam: Maybe allowing lowercase everywhere might be the cleanest solution
22:27:52 <nikos> shepazu: I'm struggling to think of a place where caplitalisation would matter if we had error correction
22:28:18 <nikos> shepazu: is there anywhere where capitalisation would matter?
22:28:28 <nikos> heycam: it matters from the perspective of making a dom call
22:28:40 <nikos> ... you need to use the correct capitalisation there
22:29:20 <nikos> heycam: I want to think about this more deeply
22:29:26 <nikos> ... it might tie in with switching modes in the SVG DOM
22:29:33 <nikos> ... like switching to no namespace
22:29:43 <nikos> ... and in that case everything is in lower case, for example.
22:29:58 <nikos> ... I do think it's an issue that we need to resolve.
22:30:11 <nikos> ... or if we keep inventing camel case names we need to make a concious decision to go that way
22:30:29 <nikos> ... we'll continue the discussion at a later point
22:30:35 <Zakim> -krit
22:30:38 <Zakim> -cyril_
22:30:39 <Zakim> -Doug_Schepers
22:30:41 <Zakim> -nikos
22:30:41 <Zakim> -heycam
22:30:43 <Zakim> -ed
22:30:44 <Zakim> GA_SVGWG(SVG1)5:00PM has ended
22:30:44 <Zakim> Attendees were +1.415.832.aaaa, birtles, nikos, krit, ed, [IPcaller], heycam, +33.9.80.39.aabb, Rich, cyril_, +33.9.53.77.aacc, Tav, Doug_Schepers
22:30:49 <nikos> RRSAgent, make minutes
22:30:49 <RRSAgent> I have made the request to generate http://www.w3.org/2012/08/30-svg-minutes.html nikos
23:02:26 <birtles> birtles has joined #svg
23:21:28 <cabanier> cabanier has joined #svg
23:22:20 <krit> krit has joined #svg
23:39:38 <krit> krit has joined #svg
23:46:34 <krit> krit has joined #svg