00:10:39 RRSAgent has joined #svg 00:10:40 logging to http://www.w3.org/2013/06/03-svg-irc 00:10:41 RRSAgent, make logs public 00:10:42 Zakim has joined #svg 00:10:43 Zakim, this will be GA_SVGWG 00:10:44 I do not see a conference matching that name scheduled within the next hour, trackbot 00:10:44 Meeting: SVG Working Group Teleconference 00:10:45 Date: 03 June 2013 00:10:49 RRSAgent, this meeting spans midnight 00:16:42 nikos has joined #svg 00:28:06 Tav has joined #svg 00:28:33 Hrm. I got confused and came up to Mori tower for some reason. Is the best way to fix this to head back down and use the subway again? 00:29:15 TabAtkins, no, but it is about 15 minutes walk 00:29:20 scribenick: cabanier 00:29:22 Cyril has joined #svg 00:29:29 TabAtkins, (Mori tower is right where my hotel is) 00:29:35 krit has joined #svg 00:30:08 TabAtkins, do you have a map? it's a reasonably straightforward route 00:30:11 kk 00:30:18 shans__ has joined #svg 00:30:20 i have google maps? 00:30:24 kinda? 00:30:35 TabAtkins: I can come get you if you want 00:30:47 heh, sure 00:30:49 <3 00:31:19 birtles: Yeah, I have that up, but it doesn't stop me from being dumb. 00:31:25 TabAtkins: OK, I'll meet you at the bottom of the mori tower? 00:31:32 yeah, i'm at the starbucks 00:31:42 TabAtkins: alright, be there in 10 00:31:56 yay! 00:33:11 Chair: Cameron 00:33:14 Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Tokyo_2013/Agenda 00:35:07 thorton has joined #svg 00:35:15 konno has joined #svg 00:35:16 konno_ has joined #svg 00:38:02 topic: agenda 00:38:12 heycam: are there missing topics? 00:38:25 … don't worry about scribing 00:40:10 stakagi has joined #svg 00:41:11 Shane has found me! Coming in. 00:45:02 topic: should fill-rule apply to text elements? 00:45:17 heycam: in svg 1.0, it applies to shapes and text 00:45:22 … but does it make sense? 00:45:37 Tav: maybe for SVG in OpenType? 00:45:56 heycam: does it make sense to control how the path data is interpreted? 00:46:09 krit: per glyph or the whole word? 00:46:11 jun has joined #svg 00:46:18 heycam: my feeling is that it's not very useful 00:46:31 … so wanted to see if other people feel the same way 00:46:47 jun has joined #svg 00:46:57 … I discovered because a site was using 00:47:07 cabanier: yes, it should have no effect 00:47:42 thorton has joined #svg 00:47:53 … you are supposed to define them so that are unaware of the fill rule 00:48:29 … outlining glyphs should be unaware of winding rules 00:48:46 heycam: our implementation was slower for even odd 00:49:05 krit: we rely on the rendering engine so it doesn't affect the winding 00:49:26 nikos: so, subpixel-aa is also turned off 00:49:28 heycam: yes 00:50:27 heycam: what if the glyphs overlap? 00:50:48 cabanier: they should paint separately and not interact with each other anyway 00:51:07 heycam: so, should they work? 00:51:16 everyone: no 00:51:57 heycam: so we'll change the text so it doesn't aooky 00:52:45 Cyril: maybe this is for SVG fonts? 00:52:51 heycam: that's possible 00:53:16 heycam: for SVG in OpenType, there's no way either 00:53:35 resolution: fillrule does not apply to text 00:53:47 topic: marker orientation issues 00:53:55 tav: I added it 00:54:08 TabAtkins has changed the topic to: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Tokyo_2013/Agenda 00:54:10 … basically there are inconsistencies between browsers 00:54:22 … you can look at the examples 00:54:31 http://paullebeau.com/svg2/markers/ 00:55:03 … and there's also the question of rectangles 00:55:17 … what do you do with rounded corners 00:55:37 heycam: I remember making a test for this 00:55:49 … I have a feeling that the spec should define this 00:56:06 … ie angle coming from 2 different directions 00:56:21 krit: is there a spec issue of is it just implemenation 00:56:32 Tav: it might be just implementaion 00:57:37 … for 2 subpath, they should not be treated as 1 00:58:32 … I think 00:58:37 (looking over the examples) 01:02:15 heycam: looks like rendering issue 01:02:28 tav: what with the double point? 01:02:51 heycam: I wonder what the spec says? 01:03:51 … (reading) it seems that you get 2 markers for double points 01:06:18 krit: why would you draw points on top? 01:06:30 tav: maybe in animations 01:07:12 krit: I would expect the markers over each other 01:07:27 tav: you always get the discontinuity 01:07:55 krit: I'm more talking about transparent markers 01:08:38 heycam: taking a look at the 'correct' version, I think he is right 01:09:19 krit: do we need to change the spec 01:09:38 heycam: yes, it should be make clearer. for instance the orientation shouldn't be in an appendxi 01:09:50 … it could benefit from being rewritten 01:10:06 … orientation is also used for motion path orientation 01:10:14 krit: text on a path 01:10:25 heycam: yes when the glyph is on the point 01:10:39 … it sounds like we agree with his findings 01:10:58 TabAtkins: we can't use his exact wording 01:11:38 … because he wants to use coincident points to be ignorder 01:11:49 heycam: he may be talking about the orientation 01:12:08 … do we all agree that there should be rendering for each point? 01:12:13 tav: yes 01:12:51 AlexD has joined #svg 01:13:00 resolution: we agree with his finding to determine the orientation of the marker and we should paint a marker for each vertex even if they coincide 01:13:23 heycam: he also suggest a new value for the orient attribute 01:13:44 TabAtkins: that seems to make easy double arrows 01:14:03 heycam: given that you need to duplicate marker elements 01:14:44 TabAtkins: no, it will flip it around. the name is unclear 01:15:01 … start or reverse seem better names 01:15:30 heycam: I like the idea but not the name 01:16:36 tav: autoreverse? 01:16:52 TabAtkins: 'auto-reverse' 01:18:13 … could it be multi-value 01:18:22 heycam: not sure. let me check 01:18:38 (discussed that 'auto-reverse' is used on animateMotion's rotate attribute with different meaning so it could be confusing) 01:18:52 … currently the value for marker orient is exposed as IDL attributes 01:19:03 … orient type which is an animated enumeration 01:19:10 — and the angle value 01:21:02 … maybe we can resolve on this new value 01:21:41 resolution: we'll have a new value for orient attribute to do the right thing for arrow heads 01:23:04 TabAtkins: there's an issue where there are begin and end markers on closed paths 01:23:40 heycam: I find it odd that the open subpaths don't have an end 01:24:23 TabAtkins: that's what the spec said. It's on path element itself 01:24:47 heycam: closed subpaths should only have marker mids? 01:24:53 all: yes 01:25:46 heycam: markers on rects and ellipses 01:27:20 (previous topic) 01:29:45 (discussion on just moveto's creating markers) 01:30:02 krit: we have patches to make that happen 01:31:37 heycam: I thought we had tests for all this 01:32:03 … but I can't find it 01:32:23 … so we should decide something 01:33:16 … I think it would be most consistent to paint both 01:33:32 krit: this is strange 01:35:16 TabAtkins: the problem is that this is a spec change 01:36:07 heycam: looking at subpaths makes more sense but it seems that most implementations already agree on the just looking per path element 01:36:45 … I'd be most happy with the small change 01:38:54 thorton has joined #svg 01:39:05 TabAtkins: it all seems broken 01:39:22 TabAtkins: All the existing renderings are broken. >_< 01:40:21 krit: we should add a note that it may change in the future 01:40:53 resolution: we'll keep start and end markers apply to the whole path 01:41:40 Hey shepazu, WRITE STAR. 01:42:05 Alternately, send me your notes and I'll write it. 01:43:15 TabAtkins, I'll write star 01:43:32 or at least start it 02:09:20 Cyril has joined #svg 02:10:06 heycam: there was 1 remaining topic on markers 02:10:15 … rectangles, ellipses, etc 02:10:40 tav: what about rounded corners? 02:11:02 TabAtkins: all the remaining elements should define the equivalent path 02:11:41 Zakim has left #svg 02:13:16 heycam: you'd probably want to use marker pattern 02:13:22 … should that be doable 02:13:25 TabAtkins: yes 02:15:01 birtles: it would be useful to have path equivalents for the rect and ellipse 02:15:12 (for variable-width stroke) 02:16:02 resolution: closed subpaths should get no start or end markers 02:16:23 +1 to that 02:19:36 heycam: I already have an action to come up with equivalent paths for rects and ellipses 02:20:41 Make sure ellipses use ellipse segments, not beziers! 02:22:25 cabanier: yes 02:22:41 TabAtkins: Canvas already defines this 02:23:00 … it uses it as 4 arc paths 02:23:08 Nice 02:23:50 heycam: I have the action so we can draw the dashes correctly 02:24:10 Canvas doesn't define it as 4 arc paths - it does it as one continuous arc. But still, its start point is the rightmost point. 02:24:19 So we should match. 02:24:40 … maybe we can copy rect over from svg tiny 1.2 02:24:52 We already have tests for dashing around rects & Arcs so should be easy to check they match 02:25:05 Ellipses, sorry 02:25:09 TabAtkins: yes, canvas has it with the start in upper left and going clockwise 02:25:17 AlexD, good point 02:26:47 e.g. shapes-ellipse-03-t.svg 02:28:38 resolution: we need to have markers on rect, circle and ellipse and all basic shapes (in case of starts) 02:28:49 s/starts/stars/ 02:29:59 resolution: rounded rects start at straight horizontal line of the top left 02:30:44 resolution: rounded rects wind clockwise and include 0% line segments 02:31:29 s/0% line segments/0 length segments when the rounder corner is 50% 02:33:28 resolution: for ellipses and circles, the path starts at right-most point and consists of 4 arcs going clockwise and each are 90 degrees 02:34:14 action: heycam to integrate the marker resolutions in the spec 02:34:14 Created ACTION-3496 - Integrate the marker resolutions in the spec [on Cameron McCormack - due 2013-06-10]. 02:34:52 ScribeNick: TabAtkins 02:35:32 Topic: feBlend issues 02:36:39 cabanier: feBlend as defined today does blending an compositing. 02:36:56 cabanier: This is usually fine today, but if you blend with backgroundIMage, you'll get double compositing, and there's no way to avoid it. 02:37:52 http://tavmjong.free.fr/INKSCAPE/MANUAL/images/FILTERS/Filters_Background.svg 02:38:04 cabanier: We can either change feBlend (seems to be the only way) 02:38:14 cabanier: We can add an attr to feBlend, so it doesn't do the compositing. 02:38:38 cabanier: That is, do the "normal" compositing only. 02:40:04 krit: [draws an example] 02:41:32 cabanier: There's too much existing content out there for us to change the default behavior. 02:41:46 cabanier: And if you don't use backgroundImage, it's not bad, and sometimes good, to composite eagerly. 02:42:27 cabanier: So choices are add an attribute that stops compositing, or try to detect when backgroundImage is the input, and don't composite. 02:42:44 krit: I like the attribute, because it might sometimes be useful to do the extra composite. 02:44:10 [some side discussion about naming] 02:45:57 TabAtkins: So it looks like just dropping backgroundImage compositing would be web-compatible? 02:46:08 heycam: Anything else with this problem? 02:46:17 cabanier: feComposite, but that's much more intentional. 02:48:25 krit: There are more use-cases that might want only blending, so doing the attr seems better. 02:48:51 ACTION krit to define a new attribute (nocomposite?) on feBlend that turns off the compositing effect. 02:48:52 Created ACTION-3497 - Define a new attribute (nocomposite?) on feBlend that turns off the compositing effect. [on Dirk Schulze - due 2013-06-10]. 02:51:03 RESOLUTION: Keep feBlend's current behavior (where it blends and composites), but add an attribute that turns off compositing. 02:51:21 Topic: enable-background issues 02:51:34 cabanier: Today, e-b has a really long description. 02:51:42 cabanier: I think IE implemented it, and Opera, but nobody else. 02:52:03 TabAtkins: I think roc is against it, and we (blink) have similar concerns. 02:52:08 cabanier: Yeah, it's really expensive. 02:52:24 cabanier: The way it's defined today you have to render twice - once to use as the background. 02:52:31 cabanier: Nice for authors, but hard/slow to implement. 02:52:44 cabanier: Adobe apps do something similar under the hood, which we can add in the future. 02:52:59 heycam: Isn't there a trick to keep you from double-rendering? 02:53:14 cabanier: Yes, but there are still issues where you have to keep two sets of pixels, and that kills performance. 02:53:43 double rendering? Isn't it just a backing store that you bitblt as the second pass? Blts are fast:-) 02:53:46 http://www.svgopen.org/2005/papers/abstractsvgopen/ 02:54:42 heycam: I think e-b isn't explained well in the spec, and if impls have a trick that can make it not so slow, the spec should define this. 02:55:03 heycam: But you're saying that even with that trick, due tto the arch. of accel. compositors, it'll still be slower. 02:55:20 cabanier: Yeah. We can revisit this in the future, but we should get the basics right now. 02:56:12 cabanier: We can define similar things to HTML's "stacking contexts" - if you ahve a with opacity, it's a stacking context. 02:56:20 The requirements to support e-b are the same as supporting filters. So if you can accelerate filters you should be able to accelerate e-b. Need hard data to falsify this claim:-) 02:56:35 No, it's not the same. 02:56:51 You can do filters with one copy of the data in a single gpu pass. 02:56:59 with opacity already requires some intermediate thing - however you can do it with a pixel sequential renderer and no backing store. 02:57:01 You don't have to go retrieve data from a different gpu pass in order to render them. 02:57:26 [some discussion about transforms and stacking contexts] 02:57:29 agreed Tab, and you can model e-b in a similar way 02:57:44 backing stores can be a last resort fallback 02:57:49 cabanier: So I think we should get rid of e-b, and say that certain elements create a fresh background. 02:58:38 krit: e-b can still be used to create an isolation group for filters. 02:58:48 krit: That's what's done in Opera/IE. 02:58:51 If we get rid of e-b, then it should be replaced by something better, like PDFs transparency groups which are a better model 02:59:09 cabanier: It can also be used to make non-isolated groups. 03:00:01 krit: Some properties need to create isolated groups by default anyway. For example, opacity needs to be an isolated group independently of e-b. 03:00:43 krit: We already have some impls of e-b, and I'm not keen ot have it removed without asking the impls about it. 03:00:59 cabanier: In the current spec langauge, it says you *must* use e-b for blending to work. We don't want that either. 03:01:22 krit: e-b gets less necessary with the definition that some other properties make isolation groups. 03:01:29 I agree, haven't seen a strong argument that it's not implementable. Current architectures for H/W accelerate shouldn't degrade the model... 03:01:36 cabanier: If we can just change e-b without breaking the web, that's fine too. 03:02:44 cabanier: To summarize, everything that creates a stacking context, creates an isolated group. 03:03:03 heycam: So what's the use of e-b outside of that? 03:04:29 [something about the effects of removing e-b from the spec] 03:05:06 heycam: So when do you want e-b? Somewhere when there's not already an isolated group? 03:05:29 cabanier: Yeah, but there are several proeprties which can make isolation without any other effects, and the 'isolation' property specifically for that. 03:05:53 heycam: Okay, so it sounds easy to get rid of e-b, use 'isolation' or stackign contexts when you want to turn off background blending. 03:06:17 heycam: As long as people don't think there's strong use-cases for people using the more complicated e-b stuff. 03:07:30 Maybe we can try to get some data about how much it's used in the wild. Does Inkscape support it to isolate layers, etc. 03:08:19 [rehashing of previous conversation] 03:08:51 krit: To be clear, e-b is implementable, just not with the perf characteristics we want. 03:09:51 Then you need to write better code krit:-) GPUs are so slow... 03:10:53 [discussion of the values that 'isolate' has and their meanings] 03:11:08 AlexD: yeah, that is why I wrote everything for the CPU :P 03:11:31 cabanier: the issue is not GPU performace, the problem is that you need at least 2 extra readbacks from the backbuffer and 3 writes to the input buffer 03:11:45 heycam: Regardless of discussion over ease of implementation, because current impls dont' do it and don't want to do it, the spec should leave it out for the moment. 03:12:27 Again we need to get hard data on whether it's used. Currently it acts as a spot to run your filter chain back to. So we need to at least address that case. 03:12:39 cabanier: which accesses the memory a lot more which will drain your battery 03:12:43 heycam: If Alex can convince people later, we can add it. 03:13:26 krit: [wants a value for 'isolate' that prevents isolation of descendants even with stacking contexts. Pointed out that we can add this later and have 'auto' respond to it] 03:14:00 RESOLUTION: Remove e-b from this level of Filters. 03:14:35 For the record I'm not for or against, just want to make sure we don't break existing content in the field 03:15:36 krit: Should I remove e-b silently, or have a note? 03:15:48 several: Seems useful to have a note pointing back to the old definition. 03:15:53 Topic: What makes a stacking context? 03:16:12 cabanier: Anything in CSS that makes a stacking context - transforms, filters, etc. 03:16:54 heycam: Do you really want every transform attr to make a stacking context? 03:17:03 NOOOO! 03:17:15 cabanier: No, but we want to be simple and consistent with CSS. ;_; 03:18:16 krit: We all agree that SVG transforms are oftne just used for moving things around, and are quite basic, rather than something that requires stacking contexts. 03:18:31 krit: But impls all do normal CSS stuff. 03:18:51 cabanier: Maybe we can say that 2d transforms in SVG dont' make a stackign context? 03:19:04 heycam: If you want the same kinds of optimizations, maybe you do want stacking contexts. 03:19:10 cabanier: Like smooth transitions, yes. 03:20:15 krit: Does FF do transform transitions in hardware? WebKit doesn't do it yet (all software for SVG), but we want to change that. 03:20:17 heycam: Same. 03:20:38 RRSAgent, pointer 03:20:38 See http://www.w3.org/2013/06/03-svg-irc#T03-20-38 03:20:59 heycam: Seems like this will suck. 03:21:02 cabanier: It will. 03:21:05 RRSAgent, draft minutes 03:21:05 I have made the request to generate http://www.w3.org/2013/06/03-svg-minutes.html Cyril 03:21:25 krit: Rik tried to specify it around whether you're animating or not, but it didn't gain consensus - ugly flash when you change. 03:22:23 cabanier: So maybe we can just differentiate 2d vs 3d - 2d doesn't make a stacking context in SVG. 03:23:06 heycam: What if authors definitely want a separate layer, but ar ejust using 2d transforms? 03:23:15 TabAtkins: Use a null 3d transform, or just use 'isolate'. 03:23:22 heycam: Ah, I think I might be okay with that. 03:24:19 Cyril: That seems to make sense. 03:25:04 s/with that/with using 'isolate' to get the stacking context/ 03:25:06 I like isolate better than the 3d transform hack 03:27:57 krit: I think in practice implementors are going to use the same code as in HTML/CSS, so 2d transforms will be isoalting as well. 03:29:09 krit: I think we should add an agenda for Wed to ask the other CSS implementors. 03:30:56 cabanier: Back to the original context, also filters and opacity cause stacking contexts. 03:32:56 Cyril: z-index also makes a stacking context? 03:33:02 heycam: Yes, just like CSS. 03:33:22 Tav: Question about that - we have someone wanting to implementing connectors in Inkscape. 03:33:34 Tav: You have symbols for the components, want connectors on different layers, etc. 03:34:31 Tav: Suppose my symbol has things with different levels. 03:37:34 Tav: And I want to have multiple symbols sometimes interleave? 03:37:41 [explanation of how stacking contexts work] 03:38:02 [conclusion is - it'll work, but making the symbol itself a stacking context will prevent it] 03:39:24 Cyril: [discussion of a layer use-case] 03:39:37 heycam: BAck to main discussion, are people expecting blending to work through opacity? 03:39:42 cabanier: Probably, but it's hard to make work. 03:39:52 krit: We make them isolated groups, and I think FF does too. 03:41:53 krit: Also masks and clips are stacking contexts. 03:41:57 cabanier: Why are clips? 03:42:18 TabAtkins: They're basically inverses of each other. 03:42:45 heycam: Simple clips can be done simpler than masks, but complex clips (with overlapping curves, or text, etc.) might use the same code path. 03:44:05 krit: Remember, this is the firsst level of blending. In the next level, we can do "real" blending, so it can go through stackign contexts, etc. 03:44:10 Topic: buffered rendering 03:44:17 Cyril: It's a hint. 03:44:29 krit: That's the problem. Blink is looking to implement it. 03:45:07 krit: So it can make a stackign context sometimes - "auto" is determined by the engine. 03:45:20 krit: So we should change "auto" to mean "don't make an image buffer". 03:45:47 Topic: Stacking contexts, cont. 03:46:00 [I meant that 'buffered-rendering' also causes stackign contexts. 03:46:36 RESOLUTION: buffered-rendering:auto/dynamic never create a stacking context; "static" does. 05:07:40 cabanier has joined #svg 05:09:24 stakagi has joined #svg 05:09:34 jun has joined #svg 05:10:13 shans__ has joined #svg 05:10:53 ys-uchida has joined #svg 05:11:28 krit has joined #svg 05:13:40 scribe: Cyril 05:13:45 scribeNick: Cyril 05:14:03 heycam: someone should actually note those things that create a stacking context in the spec 05:14:17 ACTION: Rik to note those things that create a stacking context in the spec 05:14:17 Created ACTION-3498 - note those things that create a stacking context in the spec [on Rik Cabanier - due 2013-06-10]. 05:14:40 heycam: the rendering model chapter should reference the compositing/blending 05:14:51 nikos: I did start updating it 05:15:18 https://svgwg.org/svg2-draft/render.html 05:16:26 cabanier: the CSS compositing spec references that and extends it 05:17:08 https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#module-interactions 05:18:25 cabanier: we believe that CSS Blending and CSS Filters currently extend SVG 1.1 and don't need to reference SVG 2 05:18:51 krit: it depends on when SVG 2 goes to CR state 05:19:06 cabanier: there needs to be a link back from SVG 2 to those 2 specs 05:19:20 cabanier: does this mean those 2 specs need to be at CR stage ? 05:19:26 krit: no 05:19:40 Topic: review of hatches 05:19:49 konno has joined #svg 05:19:49 https://svgwg.org/svg2-draft/pservers.html#Hatches 05:20:03 Tav: I'd like people to review it and tell me if it is ok 05:20:29 krit: how would you implement hatches ? 05:20:48 tav: creating a pattern on the fly could work 05:20:58 krit: hatch as a dimension 05:21:05 tav: inifinite in one direction 05:21:24 ... you can go to one tile but need to be carefull at tile boundary 05:21:35 ... I would make the tile the size of the whole thing 05:21:58 ... as long as you take car of the boundaries, it should work 05:22:06 heycam: can you summarize the new elements 05:22:12 Take a look at my open source hatching that I emailed ages ago - it's really easy to hatch. You generate the bound box of the thing being filled, generate the lines and clip them against the polygon. 05:22:22 tav: the hatch element copied from the pattern element 05:22:37 AlexD, but does that work if you want to use the hatch in the stroke of a shape? 05:22:54 (unless you have good stroke-to-path routines) 05:22:58 Yes - you have to generate the outline of the stroke of course 05:23:25 .... the hatch has a pitch to repeat 05:23:33 http://www.ishtek.com/hpgl2.htm 05:23:49 ... the hatch has a path which defaults to a line 05:23:56 ... and an offset from the origin 05:24:09 heycam: can you choose the origin ? 05:24:20 tav: yes, that's copied from patterns 05:24:26 Source code is http://www.ishtek.com/gl2-0_1.zip 05:24:47 (isn't the problem with patterns a matter of implementation, not an inherent problem with the spec?) 05:25:13 tav: the fdifference between a normal path and a hatch path, you don't have to provide the original move to 05:25:29 ... if not, the y is 0 and x is that last x value 05:25:47 ... that's how you get the continuous 05:25:53 heycam: why y = 0 ? 05:26:05 tav: because you're repeating in the x direction 05:26:25 ... look at the 1st squiggle example 05:26:44 s/in the x/in the y/ 05:27:08 krit: why do you need to introduce a hatch path element? why not reuse the path element? 05:27:15 Tav: no initial move to 05:27:27 ... it's necessary to repeat 05:27:40 ... examples 9 and 10 show the difference between having the initial move to or not 05:28:32 krit: why do you need the angle attribute since you have the transform attribute ? 05:28:45 tav: maybe not needed then ... 05:29:34 krit: it can be confusing in which order they apply 05:29:41 tav: I have to think about it 05:30:10 s/hatch path/hatchPath/ 05:30:21 nikos: should the d attribute be called differently ? 05:30:33 krit: I'm worried about the transform attribute 05:30:43 ... we already have the gradientTransform ... 05:31:13 tav: that's fine with me, I just copied over from pattern 05:31:25 heycam: this brought the issue of capitalization of elements 05:31:33 ... we did not resolve firmly on it 05:31:53 ... especially given the HTML parsing algorithm 05:32:14 ... each new mixedCase name that we introduce we need to update the HTML parser 05:32:26 krit: I think we should continue with our naming 05:32:36 heycam: and update the HTML spec ? 05:32:48 ... otherwise the casing will not be preserved 05:33:12 ... I'm pretty sure there will be a problem if we don't do anything 05:33:25 ... we could say that both names work in the DOM 05:34:03 krit: is it only when SVG elements are not used in an SVG subtree ? 05:34:26 heycam: no, even if in an SVG subtree because the HTML parser won't know that new element 05:34:33 Tav: that must be trivial to fix 05:34:57 heycam: yes, but that could create problem between parsing and DOM manipulations 05:35:13