IRC log of svg on 2012-05-07

Timestamps are in UTC.

06:48:35 [RRSAgent]: RRSAgent has joined #svg
06:48:35 [RRSAgent]: logging to http://www.w3.org/2012/05/07-svg-irc
06:50:49 [Zakim]: Zakim has joined #svg
06:52:04 [heycam]: Zakim, code?
06:52:04 [Zakim]: sorry, heycam, I don't know what conference this is
06:56:20 [nikos]: nikos has joined #svg
06:57:55 [Cyril]: Cyril has joined #svg
06:58:19 [ed]: hi Cyril
06:58:25 [Cyril]: hi Erik
06:58:28 [nikos]: g'day Cyril
06:58:31 [ed]: dialing in today?
06:58:31 [Cyril]: hi all
06:58:42 [Cyril]: if possible?
06:59:16 [heycam]: we are still waiting on a couple of people, so let's aim to start in 15 minutes
06:59:22 [heycam]: I'll set up a bridge then
07:01:50 [cabanier]: cabanier has joined #svg
07:01:57 [Cyril]: or if one of you has Skype
07:02:26 [heycam]: there is a microphone system in the room here, not sure how easy it would be to hook skype up to it
07:02:50 [Cyril]: then I'll call
07:03:04 [Cyril]: I might have to call back every hour
07:04:53 [heycam]: Zakim, room for 5?
07:04:54 [Zakim]: ok, heycam; conference Team_(svg)07:04Z scheduled with code 26631 (CONF1) for 60 minutes until 0804Z
07:04:57 [heycam]: Zakim, code?
07:04:57 [Zakim]: the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam
07:05:28 [shepazu]: what telcon is this?
07:05:34 [shepazu]: oh!
07:05:41 [shepazu]: are you starting the SVG f2f?
07:05:47 [heycam]: yes
07:06:15 [Zakim]: Team_(svg)07:04Z has now started
07:06:23 [Zakim]: + +33.1.75.06.aaaa
07:06:40 [Cyril]: zakim, aaaa is me
07:06:40 [Zakim]: +Cyril; got it
07:09:56 [Tav]: Tav has joined #svg
07:10:10 [Cyril]: zakim, mute me
07:10:10 [Zakim]: sorry, Cyril, muting is not permitted when only one person is present
07:10:12 [Tav]: Hi
07:13:17 [Tav]: yes
07:15:21 [Tav]: code?
07:15:26 [heycam]: Zakim, code?
07:15:26 [Zakim]: the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam
07:16:28 [Zakim]: + +49.403.063.68.aabb
07:17:11 [Zakim]: +Tav
07:18:13 [cabanier]: cabanier has joined #svg
07:18:22 [vhardy_]: vhardy_ has joined #svg
07:18:24 [cabanier]: connect url: https://my.adobeconnect.com/_a295153/vhardy
07:19:31 [jet]: jet has joined #svg
07:21:21 [heycam]: Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Hamburg_2012/Agenda
07:23:05 [cabanier]: yes
07:23:07 [krit]: krit has joined #svg
07:27:20 [tabatkins__]: tabatkins__ has joined #svg
07:29:01 [vhardy_]: ScribeNick: vhardy
07:29:08 [vhardy_]: Topic: SVG2
07:29:17 [vhardy_]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page
07:29:25 [vhardy_]: heycam: we are running behind on our schedule.
07:29:45 [vhardy_]: … we wanted to have subsections in the spec. for all the new things people had signed up for.
07:29:54 [vhardy_]: … I am guilty as well. But everybody is behind.
07:30:03 [vhardy_]: …. what can we do to make sure that we make progress?
07:30:14 [vhardy_]: tav: I have put 40% of them in. It takes time.
07:30:28 [vhardy_]: .. who is supposed to be responsible. The requirements, the link to the resolution.
07:30:41 [vhardy_]: heycam: a few of them are at the top of the chapter.
07:30:49 [vhardy_]: tav: some I can figure out.
07:31:04 [vhardy_]: heycam: I am getting the impression that people do not have a lot of time to allocate to spec. editing.
07:31:27 [vhardy_]: … this is the reason why I wanted to assign 1 or 2 people as primary editors of the spec. So that they can allocate more time.
07:31:33 [vhardy_]: … not just 1 or 2 features.
07:31:41 [vhardy_]: … we have not selected any people yet for that.
07:31:50 [vhardy_]: … anybody feels that they have the time to do that?
07:31:59 [vhardy_]: tab: I would love to, but cannot.
07:32:08 [vhardy_]: jet: who is there on the editor list now?
07:32:26 [vhardy_]: heycam: in the SVG 1.1 spec., we did not have a main editor. Everybody was pitching in.
07:32:42 [vhardy_]: … there was no primary editor. We need 1 or 2 main editors for this version.
07:32:48 [vhardy_]: tav: yes, it is very inconsistent.
07:33:10 [vhardy_]: heycam: tav you have already done a lot of work on the spec., can you become the main editor?
07:33:35 [vhardy_]: tav: I have asked Mozilla and Google for support, but this is not their current priority.
07:33:49 [vhardy_]: heycam: there is a lot of CSS high priority items.
07:34:50 [Zakim]: +Doug_Schepers
07:35:20 [heycam]: ScribeNick: heycam
07:35:27 [heycam]: VH: this is close to my concern about the spec editing
07:35:32 [heycam]: … SVG 2 is large, rewriting it is a big effort
07:35:40 [heycam]: … especially if we have constraints on editorship, this is a question for the group
07:35:57 [heycam]: … should we focus on particular efforts that are critical? integration work, animation, etc.?
07:36:05 [heycam]: … we know there is a big issue on the web with animation, it's a big thing to sort out
07:36:13 [heycam]: … we know that better canvas integration in svg would improve things
07:36:23 [heycam]: … my question is shouldn't we focus on smaller specs
07:36:37 [heycam]: … even the web animation is going to be a large effort, but still much smaller than SVG2 as a whole
07:36:49 [heycam]: … since we have people motivated for these pieces, it's more likely we can pull it off
07:36:55 [heycam]: TA: modularisation like CSS
07:37:08 [heycam]: VH: we're still needing implementations to get up to speed with SVG 1.1
07:37:23 [heycam]: … we could have SVG DOM improvements as a separate spec
07:37:31 [heycam]: ED: some things would be easier to write up in modules than others
07:37:50 [heycam]: Dirk: paint servers could be split out
07:38:06 [heycam]: BB: I'm in favour of modularisation
07:38:15 [heycam]: ED: I think identifying small parts, standalone modules
07:38:23 [heycam]: VH: do we think the highest priority things can be done as modules?
07:38:43 [vhardy_]: heycam: we can have a look at the list of things we have signed up for and see what can be modularized.
07:38:52 [vhardy_]: … for example, SVG DOM improvements may be hard to split out.
07:38:58 [vhardy_]: … canvas integration can be easy to split out.
07:39:07 [vhardy_]: dirk: should we make a list now of what could be a module?
07:39:13 [vhardy_]: heycam: yes, we can do that list now.
07:39:23 [vhardy_]: … and we could get people to sign up as separate specs.
07:39:29 [vhardy_]: dirk: ok.
07:39:41 [heycam]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments
07:40:11 [vhardy_]: heycam: let's look at the one for which someone signed up for.
07:40:22 [vhardy_]: z-index http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#z-index
07:40:28 [Cyril]: could be good if the tick in the table had a link to the spec
07:40:36 [vhardy_]: dirk: that could be combined with something else.
07:40:46 [vhardy_]: heycam: this is fundamental, changes the painting model.
07:40:59 [vhardy_]: dirk: should it be in the new definition of the rendering model?
07:41:11 [vhardy_]: heycam: we could split out the rendering model in a separate spec.
07:41:20 [shepazu]: q+
07:41:35 [vhardy_]: .. I am concerned about splitting out because that was the plan for SVG Tiny where we were going to add modules on top of it.
07:41:44 [vhardy_]: … stitching specs together is going to be hard.
07:42:16 [vhardy_]: tab: what we have done in CSS, we have turned pieces of the core spec. into new modules of the spec.
07:42:33 [vhardy_]: brian: so you do not need a full SVG 2.0 spec. at all?
07:42:51 [vhardy_]: tab: yes, possibly. CSS 2.1 is still a reference for things that are not redefined in a module.
07:42:59 [vhardy_]: heycam: does that work well?
07:43:09 [vhardy_]: tav: yes, because we did not have to redo a lot of low level work.
07:43:24 [vhardy_]: … we still have to do things like the box model.
07:43:39 [heycam]: ScribeNick: vhardy
07:43:56 [vhardy_]: vhardy: I thnk that while not perfect, this is a pretty good option.
07:44:12 [vhardy_]: shepazu: I do not agree at all. It took CSS a decade to do that.
07:44:22 [vhardy_]: tav: it took a decade to get CSS 2.1 good.
07:44:48 [vhardy_]: shepazu: I think that trying to find the parts of SVG to split out and then doing their own spec is difficult.
07:45:00 [vhardy_]: … unless we see a plan to see which parts can be split out.
07:45:14 [vhardy_]: … we have already split out filters, transforms, etc… What is left is core functionality.
07:45:26 [vhardy_]: dirk: paint servers is something that could be done independent of SVG.
07:45:36 [vhardy_]: … it could be a module of its own.
07:45:54 [vhardy_]: ed: it was suggested as a module in the past. Andrew Emonds was supposed to take that module.
07:46:06 [ed]: s/Emonds/Emmons/
07:46:26 [vhardy_]: shepazu: the other thing is that we have individual people who might take on individual specs. All these things depend on one another.
07:46:42 [vhardy_]: … I do not think that we face the same problems as CSS faces. We do not have the same number of people.
07:47:00 [vhardy_]: tav: we can identify things that are independent and can be carved out as new modules.
07:47:16 [vhardy_]: shepazu: we already decided about what goes into SVG 2.0.
07:47:32 [heycam]: VH: I think it's clear it's hard to put together a big monolithic spec
07:47:37 [heycam]: … and we're behind schedule
07:47:56 [heycam]: … whereas I think the CSS experience shows when we have motivated editors for portions of the spec, it's more realistic to see those modules make progress
07:48:33 [vhardy_]: shepazu: I strongly disagree. We have made a lot of preparation work. I think we should just start on SVG 2.0 and get people to start doing the work.
07:49:02 [vhardy_]: tav: we do not need to do this top down. Let's pull off module as people have interest. No need to decide now for everything upfront.
07:49:07 [vhardy_]: dirk: how do we do that?
07:49:18 [vhardy_]: tav: we have a collection of things that are SVG.
07:49:22 [vhardy_]: s/tav/tab
07:49:35 [Cyril]: if people don't have time to edit the current spec, I don't think they'll have time to edit modules
07:50:10 [vhardy_]: (discussion about how modules would be split out or not and what would constitute SVG 2.0)
07:50:47 [vhardy_]: tav: if the monolithic spec is not great yet, then the feature that is split out needs to be removed from the 'main' spec.
07:51:02 [vhardy_]: …. CSS modules just augment the CSS 2.1 spec.
07:51:10 [vhardy_]: …. we also collect errata for CSS 2.1
07:51:19 [vhardy_]: .. SVG 2.0 is not near that point.
07:51:31 [vhardy_]: … if someone wanted to pull a module out, we could do that.
07:51:42 [Cyril]: q+
07:51:43 [vhardy_]: … this could be decided piecemeal.
07:51:46 [shepazu]: q-
07:52:00 [vhardy_]: cyril: I do not see how modules can help.
07:52:29 [vhardy_]: … there are already many chapters and they are quire independent. Looking at how annotations have been made, they are quite independent. Editing should be pretty straightfoward.
07:52:39 [vhardy_]: … I do not see how modules would help.
07:52:52 [Cyril]: q-
07:52:54 [vhardy_]: heycam: what would make it easier to edit if things are independent specs.
07:52:56 [shepazu]: q+
07:53:01 [vhardy_]: brian: easier to find editors.
07:53:11 [vhardy_]: heycam: people own the separate features.
07:54:05 [Cyril]: an editor of a module is the same as an editor of a part of the spec, no?
07:54:37 [tabatkins__]: Cyril: Basically, yeah. It's just an organization/semantic thing.
07:56:20 [vhardy_]: heycam: originally, we wanted to do a lot of clean-up. I would still be happy if people just added their new features in the SVG 2 spec. and not needing to do clean-up of other things. The SVG 1.1 spec. is not terrible. I do not think we need to spend time doing clean up or rewriting to get new features in. I do not think this should be stopping us.
07:56:46 [vhardy_]: dirk: I think tab's proposal, we could increase our ability to split out modules as needed.
07:57:15 [vhardy_]: heycam: I am happy that if people want to have it in a separate spec., I am fine with it if the people doing the work want that.
07:57:23 [vhardy_]: dirk: can we agree that we want to use this model?
07:57:57 [vhardy_]: shepazu: do we need a new resolution on that? We have been doing this for years now.
07:58:24 [vhardy_]: … we should work on spec. and technical work.
07:58:27 [Cyril]: +1
07:58:44 [vhardy_]: dirk: it seems that you just agreed to tab's proposal.
07:58:58 [vhardy_]: heycam: If people want to break things out, they can ask the group and we can agree to do that or not.
07:59:42 [vhardy_]: tav: we could annotate, along the way, what is solid and what is not, like in the HTML5 work.
07:59:46 [vhardy_]: heycam: that sounds right.
07:59:49 [vhardy_]: shepazu: yes
08:00:04 [vhardy_]: … and it should be backed up with tests.
08:00:16 [vhardy_]: … they'll ensure that we get interoperability.
08:00:30 [vhardy_]: … tests are needed before we can mark things as stable.
08:00:40 [vhardy_]: heycam: we do not need to go through the list at this point.
08:01:56 [vhardy_]: So if someone in the group who is working on the spec. and a particular feature wants to work on it as a separate module, they should bring that proposal to the group and ask for a separate module. Decisions will be made on a case by case basis.
08:02:26 [vhardy_]: heycam: there were mixed feelings whether we need somebody as a full editor of the spec. Perhaps we can consider that as another thing someone will sign up for?
08:02:58 [vhardy_]: … I think this mixes well with what Tab suggest to keep SVG 1.1 as the reference. We can keep the old text.
08:03:05 [vhardy_]: … as the reference.
08:03:23 [vhardy_]: dirk: don't we need a global editor to organize and keep the overall consistency?
08:03:28 [vhardy_]: shepazu: what would be the role?
08:03:52 [vhardy_]: heycam: coherence, bug fixing for things that do not fall into features, insuring the document as a whole is reasonnable.
08:05:20 [vhardy_]: vhardy: in the SVG 1.0 and 1.1 1rst edition, the editors did a tremendous amount of coherence checking etc....
08:05:38 [vhardy_]: heycam: having to rewrite sections was an impediment to making progress.
08:05:46 [vhardy_]: … for SVG tiny.
08:06:22 [vhardy_]: shepazu: the spec. as it stands has holes and consistencies, we are continuing the inconsistencies.
08:06:35 [vhardy_]: heycam: I do not think it is completely terrible.
08:06:43 [vhardy_]: shepazu: I do not want to argue about this anymore.
08:06:54 [vhardy_]: heycam: realistically, nobody is going to put the time into this.
08:07:16 [vhardy_]: … we can just continue to aim at our milestone page and follow that plan.
08:08:04 [vhardy_]: tav: the list of requirements is not sorted. It is one long list. I'd like to sort it by chapter.
08:08:11 [vhardy_]: heycam: that would be fine.
08:08:23 [vhardy_]: cyril: the numbers would have to change.
08:08:30 [vhardy_]: tav: is that a problem?
08:08:38 [vhardy_]: heycam: I do not think people rely on those numbers.
08:08:46 [vhardy_]: … tav: go and do that if you want.
08:09:05 [vhardy_]: cyril: a long time ago, I sent an email with a sorting/categorization of the requirements.
08:09:22 [vhardy_]: heycam: would it be beenficial to do some work on the spec. during the F2F?
08:09:26 [vhardy_]: tav: yes, that would be good.
08:09:33 [vhardy_]: ed: +1
08:09:58 [vhardy_]: tav: requirements, resolution, etc… short summary and responsible person would help.
08:09:58 [Cyril]: making sure everyone has the right environement for editing
08:10:19 [vhardy_]: tab: I am afraid some people will end up clocking out.
08:10:36 [vhardy_]: heycam: I think it might help getting people started if they have not done it yet.
08:10:41 [shepazu]: agenda+ report on Web Components and <use>
08:11:31 [vhardy_]: heycam: ok, we'll do that at the end of the day today.
08:11:41 [vhardy_]: (before 5:15pm)
08:12:04 [vhardy_]: heycam: we are done with the SVG 2.0 discussion then.
08:12:15 [vhardy_]: heycam: we can talk about the web components now.
08:12:45 [vhardy_]: Topic: Web Component
08:12:53 [vhardy_]: shepazu: it just happened last week.
08:13:08 [vhardy_]: … we have been talking for a while about the <use> and the resulting shadow tree.
08:13:33 [vhardy_]: … pretty unpopular. We have been talking about using the Web component model that Dmitry Glaskov has been writing.
08:13:48 [vhardy_]: … at TPAC, when we talked, he was not sure how it would work with the <use> element.
08:14:10 [vhardy_]: … the goal of having <use> be an instanciation of the shadow DOM model would be easier.
08:14:27 [vhardy_]: … with SVG as it stands, it is more complicated and not very performant (as I understand it).
08:15:01 [vhardy_]: … at TPAC, he said that each instance of the component would be identical. There would be no way to style each instance. In the current <use> element, you can inherit the fill color, for example.
08:15:07 [vhardy_]: … so there is some differnece.
08:15:22 [vhardy_]: … in his old model, that would not work. In the new model, it would work.
08:15:36 [vhardy_]: … you could have a separate styling for each instance of the component.
08:15:56 [vhardy_]: … so in other words, we can go ahead and use the component model to mimic the <use> element.
08:16:07 [vhardy_]: dirk: that is what we do in WebKit now.
08:16:16 [vhardy_]: … was done in the last couple months.
08:16:27 [vhardy_]: tav: does that change anything, is it fully compatible?
08:16:37 [vhardy_]: dirk: the use element now works a lot better in WebKit/
08:17:32 [vhardy_]: shepazu: there are some DOM methods for the <use> element (like ElementInstance) that would need to be deprecated.
08:17:43 [vhardy_]: … not impelmented consistently.
08:17:52 [vhardy_]: … modern SVG content does not use that.
08:18:03 [vhardy_]: …. it was implemented in the ASV viewer.
08:18:30 [vhardy_]: tab: we would need to re-write the <use> DOM.
08:19:09 [vhardy_]: shepazu: I will rewrite the <use> section to describe the model in the shadow DOM model and rewrite the DOM model and/or deprecate APIs if/where needed.
08:19:16 [Zakim]: -Tav
08:19:19 [vhardy_]: heycam: I have not looked at the shadow DOM for a while.
08:19:29 [vhardy_]: …. there are methods to get to the shadow tree?
08:19:35 [vhardy_]: tab: yes, the element.shadow.
08:19:42 [vhardy_]: heycam: is there event retargeting.
08:19:54 [vhardy_]: tab: it is a closer rewrite of the XBL2 event model.
08:20:53 [Tav]: The conference code has expired... can't call back in.
08:20:55 [vhardy_]: ACTION: shepazu to edit the <use> section in terms of Shadow DOM model and rewrite the DOM model and deprecate / change APIs where needed.
08:20:56 [trackbot]: Created ACTION-3271 - Edit the <use> section in terms of Shadow DOM model and rewrite the DOM model and deprecate / change APIs where needed. [on Doug Schepers - due 2012-05-14].
08:21:21 [vhardy_]: heycam: shepazu, can you explain how the style can be inherited from the <use> element on the instance.
08:22:11 [vhardy_]: tab: I think this is a todo in the shadow DOM spec. to allow inheritance.
08:22:33 [vhardy_]: shepazu: the <use> will be syntactic sugar for regular shadow tree.
08:23:42 [vhardy_]: (discussion about event retargeting, see the Shadow DOM proposal).
08:23:59 [vhardy_]: shepazu: there were only some classes of content that was doing this. I am not worried about breaking that content.
08:24:10 [vhardy_]: brian: would that be useful for markers as well?
08:24:40 [vhardy_]: shepazu: I think we could safely state that markers are <use> instances and we could add functionality to markers.
08:24:59 [vhardy_]: heycam: we should be able to describe markers in terms of shadow tree.
08:26:29 [vhardy_]: vhardy: I think markers could be modeled with the shadow DOM, but they may have a memory footprint consequence.
08:26:41 [vhardy_]: heycam: implementations can be smart about it and lazily create the DOM.
08:27:34 [vhardy_]: vhardy: there was a discussion about shadow DOM and regions and memory was shown to be an issue.
08:27:48 [vhardy_]: shepazu: may be markers do not have to be modeled with the shadow DOM.
08:28:20 [vhardy_]: heycam: describing markers in terms of shadow tree may not be that useful. I have proposals for markers in the section about this in the afternoon.
08:28:42 [vhardy_]: shepazu: another problem with markers is simply that the ability to position them is very limited.
08:28:54 [vhardy_]: … I do not think it is a particularly good model.
08:29:02 [vhardy_]: heycam: I have proposals for that.
08:29:35 [vhardy_]: heycam: so the web component model will be good for the <use> element. Anything else on this?
08:29:42 [vhardy_]: shepazu: done.
08:30:02 [vhardy_]: heycam: break for 15mn
08:30:16 [Zakim]: -Doug_Schepers
08:31:25 [heycam]: Zakim, who is on the call?
08:31:25 [Zakim]: On the phone I see Cyril, +49.403.063.68.aabb
08:32:00 [Zakim]: - +49.403.063.68.aabb
08:33:27 [Zakim]: -Cyril
08:33:29 [Zakim]: Team_(svg)07:04Z has ended
08:33:29 [Zakim]: Attendees were +33.1.75.06.aaaa, Cyril, +49.403.063.68.aabb, Tav, Doug_Schepers
08:58:52 [heycam]: Zakim, room for 5?
08:58:53 [Zakim]: ok, heycam; conference Team_(svg)08:58Z scheduled with code 26631 (CONF1) for 60 minutes until 0958Z
08:59:43 [tabatkins__]: Here's the Web Component Explainer, for easy explanation of several of the shadow dom concepts: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html
08:59:52 [tabatkins__]: Explains the CSS and events interaction really easily.
08:59:55 [Zakim]: Team_(svg)08:58Z has now started
09:00:01 [Zakim]: +Tav
09:01:04 [Zakim]: + +49.403.063.68.aaaa
09:01:53 [tabatkins__]: ScribeNick: tabatkins__
09:01:57 [tabatkins__]: Topic: Painting order
09:01:59 [heycam]: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Paint_order
09:02:17 [tabatkins__]: heycam: I wrote up a short proposal for something I wanted to do for a long time, which is change the order that fill/stroke get painted in for shapes.
09:02:32 [tabatkins__]: heycam: Especially for text, you sometimes want the stroke *underneath* the text, rather than on top.
09:02:57 [tabatkins__]: krit: How does this relate to Vector Effects?
09:03:15 [jet]: jet has joined #svg
09:03:24 [tabatkins__]: heycam: We originally thought to solve this with VE, but I don't want to have to wait for VE for this simple thing, and I don't want authors to have to write a big VE just for this simple effect.
09:03:44 [tabatkins__]: heycam: Even if this is just a shorthand for VE stuff, I don't think the right effect is to jam it into the vector-effect property.
09:04:05 [heycam]: Zakim, who is on the call?
09:04:05 [Zakim]: On the phone I see Tav, +49.403.063.68.aaaa
09:04:25 [tabatkins__]: heycam: So I think it's better to have it as a separate property, and later define how it interacts with VE.
09:04:57 [Zakim]: +Cyril
09:06:31 [tabatkins__]: [somewhat confusing discussion about repeated use of keywords]
09:06:39 [tabatkins__]: [resolved by explaining the syntax better]
09:07:15 [tabatkins__]: birtles: How does this interact with stroke-inner/outer?
09:07:33 [tabatkins__]: vhardy_: It adjust the shape of the stroke, not the painting order.
09:08:36 [tabatkins__]: tabatkins__: One of heycam's usecases was a stroke outside of text by drawing the fill on top, which seems to be the same as just stroking outside. Are there other use-cases?
09:09:15 [tabatkins__]: vhardy_: Ideally it would work the same for the text use-case, but seaming isn't good on this sort of thing in most applications.
09:10:12 [tabatkins__]: birtles: fill-opacity makes a difference between the two cases,
09:10:51 [tabatkins__]: tabatkins__: stroke-outside is what you want with partially-transparent fill.
09:11:13 [tabatkins__]: vhardy_: I think that some rendering engines dont' do this well.
09:11:21 [tabatkins__]: krit: You can just clip around the text.
09:11:30 [tabatkins__]: vhardy_: Still potentially pixel-level rendering issues.
09:11:38 [tabatkins__]: tabatkins__: So it's a QoI issue.
09:12:02 [tabatkins__]: krit: So if we had good stroke-outside, is there still a good reason to have this?
09:12:19 [tabatkins__]: ed: Moving markers around is still a useful effect, and can't be done otherwise.
09:12:41 [tabatkins__]: heycam: It also lets you get the stroke-outside effect in opaque cases without us having to wait for stroke-outside.
09:13:19 [tabatkins__]: krit: [discussion about offsetting strokes more powerfully with the proposals about stroke-outside/offset/whatever]
09:14:09 [tabatkins__]: birtles: Is there a strong use-case besides the one that can be done with a stroke offset?
09:14:36 [tabatkins__]: tabatkins__: Markers moving their painting order is still something else.
09:15:47 [tabatkins__]: [discussion about spec path for stroke-offset, maybe just starting with inside/outside/middle, and later use more powerful stuff]
09:16:06 [tabatkins__]: vhardy_: I'm in favor of this proposal. It's simple, and can be useful for authors.
09:16:23 [tabatkins__]: ed: I'm not particularly happy with the name.
09:17:43 [tabatkins__]: vhardy_: Yeah, 'paint-order' reminds me of z-order.
09:17:53 [tabatkins__]: heycam: Naming suggestions welcome.
09:18:21 [tabatkins__]: heycam: And if you don't specify all the keywords, presumably the rest get applied in the normal order, after the specified ones.
09:18:34 [tabatkins__]: heycam: So if more layers show up in the future, it doesn't invalidate the existing content.
09:18:56 [tabatkins__]: krit: What about controlling the order of clipping/masking/etc?
09:19:06 [tabatkins__]: heycam: Not right now. That might be something to look at in the future.
09:19:18 [tabatkins__]: heycam: It might be getting into the realm of something you want to write a whole VE definition for.
09:20:10 [krit]: http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.html
09:21:01 [tabatkins__]: birtles: I'd be happier if there was an explicit strong use-case, but I'm okay with the property.
09:21:52 [vhardy__]: vhardy__ has joined #svg
09:21:54 [tabatkins__]: heycam: I think usually I've wanted something like this to make "stroke outside", but that's an incomplete solution.
09:22:03 [tabatkins__]: krit: What about hit-testing?
09:22:49 [tabatkins__]: ed: I think pointer-events defines how that should work, more or less.
09:23:37 [tabatkins__]: vhardy: I think pointer-events is just about the geometry of the pieces.
09:23:41 [ed]: http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
09:23:47 [tabatkins__]: vhardy: In which case the painting order doesn't matter.
09:23:48 [krit]: https://developer.mozilla.org/en/CSS/pointer-events
09:24:55 [tabatkins__]: heycam: If stroke is on top, and I say "pointer-events:fill", it still hit-tests on the part of the fill underneath the stroke. It's just geometry.
09:25:43 [tabatkins__]: RESOLVED: Add heycam's "paint-order" proposal, though possibly with a different name.
09:27:25 [ed]: http://www.w3.org/TR/SVG11/render.html#PaintingShapesAndText
09:28:40 [tabatkins__]: tabatkins__: [mentioned that CSS now automatically includes the global keywords (inherit, initial, etc) in all properties, so it shouldn't be explicitly included in the definitions]
09:28:41 [ed]: s/RESOLVED:/RESOLUTION:/
09:28:53 [tabatkins__]: [some naming discussion for 'paint-order']
09:29:24 [Cyril]: to which reqs does the paint-order proposal correspond ?
09:29:41 [heycam]: Cyril, none, it's a new one. (sorry!)
09:29:55 [birtles]: other options suggested: painting-order, draw-order, painting-operation-order, shape-order
09:30:24 [Cyril]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Stroke_position
09:31:14 [tabatkins__]: Cyril: Maybe link to that requirement when talking about paint-order.
09:31:35 [krit]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments
09:31:47 [Cyril]: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_position
09:32:01 [heycam]: http://lists.w3.org/Archives/Public/www-svg/2011Sep/0057.html
09:32:48 [tabatkins__]: tabatkins__: The two aren't actually related, except that one use-case can be done with either.
09:32:58 [tabatkins__]: krit: Note that stroke-position *would* affect hit-testing.
09:33:29 [heycam]: ScribeNick: heycam
09:33:33 [heycam]: Topic: SVG DOM
09:33:41 [heycam]: TA: we've discussed fixing the SVG DOM generally
09:33:52 [heycam]: … like throwing away animVal/baseVal, in favour of a way of retrieving those things separately
09:33:56 [heycam]: … obviously that's a breaking change
09:34:10 [heycam]: BB: we have a proposal for deprecating that at the same time as introducing compact syntax
09:34:16 [heycam]: TA: if we can do this compatibly, that'd be awesome
09:34:24 [heycam]: … but if not, we need to think about version switching
09:34:34 [heycam]: … we'd need to do this in such a way that's usable in SVG and HTML as well
09:34:51 [heycam]: … the version switch for example can't be based on doctype
09:34:58 [heycam]: … since that wouldn't work for inline SVG-in-HTML
09:35:28 [Cyril]: Commitments page modified
09:36:11 [heycam]: TA: one thing I've been talking about is switch SVG over into the HTML namespace, so we don't have to care about namespaces any more
09:36:18 [heycam]: RC: so for inline SVG, all the APIs change?
09:36:26 [heycam]: TA: well you would use createElement instead of createElementNS
09:37:11 [heycam]: … one problem is style/script/font/a
09:37:24 [heycam]: … we want a context free parsing mode in HTML, but to do that properly it needs to know context
09:37:39 [heycam]: … we want that to work for SVG too
09:37:46 [heycam]: … if the markup string starts with "<g>" then it should know it's SVG
09:37:57 [heycam]: … if the first element you see is style/script/font/a, then it'll think that it's HTML instead
09:38:09 [heycam]: … if we switched it all over to the HTML namespace it's ok
09:38:39 [heycam]: … the only sane way to do the parsing is to look at the start tag
09:38:42 [heycam]: … to determine the context
09:39:36 [heycam]: Dirk: there's also different DOM APIs for SVG/HTML script and style
09:40:01 [heycam]: TA: if there is a fragment that starts with <a> then it's very likely to be HTML
09:40:12 [heycam]: ED: people have been suggesting innerSVG instead of innerHTML
09:40:19 [heycam]: … which is one way of switching, but it's not great
09:40:32 [birtles]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Make_it_easier_to_read_and_write_to_attributes_in_the_DOM
09:40:38 [birtles]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM
09:40:50 [birtles]: rectElt.x.px = 20
09:41:33 [heycam]: TA: className works differently between SVG and HTML, so that's weird
09:41:39 [heycam]: … it would be good to have no differences between these accessors
09:41:48 [Cyril]: zakim, mute me
09:41:48 [Zakim]: Cyril should now be muted
09:41:54 [tabatkins__]: zakim, who is noisy?
09:41:55 [Cyril]: zakim, who is noisy
09:41:55 [Zakim]: I don't understand 'who is noisy', Cyril
09:42:08 [Cyril]: zakim, who is noisy?
09:42:13 [Zakim]: tabatkins__, listening for 18 seconds I heard sound from the following: Tav (97%), +49.403.063.68.aaaa (2%)
09:42:19 [Cyril]: zakim, mute Tav
09:42:19 [Zakim]: Tav should now be muted
09:42:29 [Zakim]: Cyril, listening for 14 seconds I heard sound from the following: Tav (31%), +49.403.063.68.aaaa (62%)
09:43:38 [heycam]: TA: the proposal linked to there is better than baseVal.value, but it's still not the same as HTML
09:44:40 [heycam]: CM: I think the fragment parsing and SVG DOM improvemnets are mostly separate issues
09:44:49 [heycam]: TA: yes but it would make it easier if they are all in the HTML namespace
09:45:18 [heycam]: … if all the SVG elements can also exist in the HTML namespace, that might work
09:45:28 [heycam]: … I wonder if that produces much incompatibility with existing namespace
09:46:14 [heycam]: CM: I think it's worth looking at
09:46:52 [heycam]: TA: if you don't need to care about namespaces, then you no longer need an outer <svg> for inline svg
09:47:01 [heycam]: VH: I did want to be able to do that
09:51:34 [heycam]: [discussion about whether the namespace of the element can be the switch for the new SVG DOM properties]
09:52:41 [heycam]: VH: you could have an attribute on the <svg> element to opt in to the new dom
09:53:53 [heycam]: TA: if you embed SVG in HTML, you need that switch, but we could have bare <rect> in html automatically use the new SVG DOM
09:54:41 [heycam]: ACTION: Tab to bring up SVG elements in HTML namespace in WHATWG
09:54:41 [trackbot]: Created ACTION-3272 - Bring up SVG elements in HTML namespace in WHATWG [on Tab Atkins Jr. - due 2012-05-14].
09:55:14 [vhardy__]: yes :-)
09:56:12 [heycam]: VH: we should consider what this means for standalone SVG
09:56:20 [heycam]: ED: you can already get that with an HTML doctype at the top
09:56:25 [Zakim]: -Tav
09:56:42 [heycam]: TA: you can't use an <img> to link to an SVG in html
09:58:00 [heycam]: TA: we need to investigate how compatibly we can change the SVG DOM
09:58:04 [heycam]: … if we can't, then we'll need the switch
09:59:03 [heycam]: ED: we'll definitely need to improve the CSSOM too if we migrate attributes to properties
10:00:25 [heycam]: [discussion about unitless values]
10:01:58 [heycam]: VH: where are we with the attributes becoming properties?
10:02:28 [heycam]: ED: there was a thread on www-style
10:02:32 [heycam]: CM: I think nobody replied to it
10:02:57 [heycam]: VH: I think there was some issue with the meaning of percentages in width/height
10:05:33 [ed]: http://lists.w3.org/Archives/Public/www-style/2012Feb/0333.html
10:05:45 [ed]: (that's the property proposal)
10:06:34 [ed]: so smfr thinks they should be prefixed, http://lists.w3.org/Archives/Public/www-style/2012Feb/1068.html
10:11:41 [heycam]: Dirk: there's also this getPresentationAttribute API
10:11:51 [heycam]: … will we still need that if we promote everything to properties?
10:14:00 [heycam]: … it would be nice to be able to get typed access to presentation attributes
10:15:34 [heycam]: CM: maybe that could be exposed like element.presentation.x, where element.presentation is the style sheet for presentation attributes
10:16:32 [heycam]: Dirk: should element.x return an object or just a string?
10:16:44 [heycam]: TA: it could be ok to return an object, if we've opted in to the new api
10:24:57 [heycam]: ACTION: Cameron to actually do his SVG DOM proposal action, assuming we will use an opt-in switch
10:24:57 [trackbot]: Created ACTION-3273 - Actually do his SVG DOM proposal action, assuming we will use an opt-in switch [on Cameron McCormack - due 2012-05-14].
10:27:06 [heycam]: ACTION-3273: http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM
10:27:06 [trackbot]: ACTION-3273 Actually do his SVG DOM proposal action, assuming we will use an opt-in switch notes added
10:27:25 [ed]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Specific_Commands_for_Paths
10:27:59 [Zakim]: -Cyril
10:28:51 [Cyril]: Cyril has joined #svg
10:29:05 [tabatkins__]: Element.create() : http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0537.html
10:29:18 [tabatkins__]: better element constructors: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0507.html
10:31:59 [heycam]: [discussion about SVGPoint becoming Point, etc.]
10:32:44 [tabatkins__]: <br type=lunch dur=1h>
10:32:59 [Zakim]: disconnecting the lone participant, +49.403.063.68.aaaa, in Team_(svg)08:58Z
10:33:02 [Zakim]: Team_(svg)08:58Z has ended
10:33:02 [Zakim]: Attendees were Tav, +49.403.063.68.aaaa, Cyril
10:36:51 [nikos]: nikos has joined #svg
11:35:52 [jet]: jet has joined #svg
11:39:05 [vhardy_]: vhardy_ has joined #svg
11:39:37 [heycam]: Zakim, room for 5?
11:39:39 [Zakim]: ok, heycam; conference Team_(svg)11:39Z scheduled with code 26631 (CONF1) for 60 minutes until 1239Z
11:42:22 [tabatkins__]: tabatkins__ has joined #svg
11:42:29 [tabatkins__]: ScribeNick: tabatkins__
11:42:37 [tabatkins__]: Topic: markers hit-testing
11:42:42 [heycam]: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Hit_testing
11:42:42 [shans_]: shans_ has joined #svg
11:43:00 [tabatkins__]: heycam: One of the SVG2 reqs was to hav ea way to distinguish between hit-testing strokes and fills of shapes.
11:43:17 [tabatkins__]: heycam: And related, markers.
11:43:35 [tabatkins__]: heycam: I've suggested a few methods that can be called to determine whether a point was over the stroke/fill/marker of the shape.
11:44:35 [tabatkins__]: heycam: In the proposal, a passed point is in the coordinate space of the element.
11:44:55 [tabatkins__]: heycam: But also it can just take an event object directly, so you don't have to swizzle the coordinates.
11:45:17 [tabatkins__]: heycam: Finally, I provided getMarkerFromPoint and getMarkerIndex for some more marker utility.
11:45:37 [tabatkins__]: vhardy_: What's in a MarkerDetails?
11:46:00 [tabatkins__]: heycam: the index of the marker, the distance along the path, and the actual <marker> element that it's generated from.
11:46:14 [tabatkins__]: heycam: I think that's about as usefula s you can make the autoamtically produced markers.
11:46:29 [tabatkins__]: heycam: Another proposal later is for explicit elements for markers in the document, which you can put event handlers on.
11:48:14 [tabatkins__]: heycam: If your original <marker> had some onclick on it, they'd be cloned into the shadow tree.
11:49:04 [tabatkins__]: heycam: It's silly that pointer-events can't make markers interact with pointer-events. It might not be a big deal in many cases, but if you, say, have a big arrowhead on one end, that's important.
11:49:14 [tabatkins__]: heycam: I don't know how we'd want to include this.
11:49:45 [tabatkins__]: birtles: I think we could probably redefine the existing pointer-events values, since authors are probably assuming that they contribute already.
11:50:36 [tabatkins__]: heycam: We could introduce some more keywords like 'marker/visibleMarker'
11:50:56 [tabatkins__]: heycam: But you can't combine them currently.
11:51:14 [tabatkins__]: ed: I've wanted before to style particular markers, like the one you're hovering.
11:51:40 [tabatkins__]: heycam: That might work with the shadow DOM.
11:51:58 [tabatkins__]: birtles: In MarkerDetails there's an index. What useful stuff can you do with that?
11:52:03 [tabatkins__]: heycam: Good question.
11:52:31 [tabatkins__]: birtles: I think if you could use it to determine if you're at the start/end of the path, that might be useful, but you can't really tell that right now unless you know how many segments your path has.
11:52:46 [Zakim]: Team_(svg)11:39Z has now started
11:52:54 [Zakim]: +Tav
11:53:20 [tabatkins__]: heycam: It might be useful to look at the other marker stuff, so you can see how useful they'd be combined.
11:55:27 [Zakim]: + +49.403.063.68.aaaa
11:55:50 [tabatkins__]: Topic: marker children
11:56:03 [ed]: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Marker_children
11:56:36 [tabatkins__]: heycam: Basically you can put <marker> elements as children of the <path>.
11:56:53 [tabatkins__]: heycam: It can either refer to a <marker> defined elsewhere, or do it inline.
11:57:06 [tabatkins__]: heycam: There's also a @position attribute that gives a distance along the path.
11:57:46 [tabatkins__]: Tav: What about rectangles? Could we put a <marker> on a rectangle?
11:58:29 [tabatkins__]: heycam: They can't apply yet, but we could do so.
11:58:43 [tabatkins__]: ed: We already define where the strokes start on those shapes.
11:59:06 [tabatkins__]: krit: What about the interaction with automatic markers?
11:59:22 [tabatkins__]: heycam: I was thinking you'd draw the automatic markers, then draw the manual ones.
11:59:48 [tabatkins__]: krit: [something about regularly-spaced markers]
12:00:33 [tabatkins__]: heycam: I think there's some more proposal about that.
12:00:50 [tabatkins__]: krit: Could we have the @position take a list of lengths, so you generate multiple markers from one <marker>?
12:01:38 [tabatkins__]: heycam: Maybe, but then you'd have to go back to adding API for working with multiple elements.
12:01:55 [tabatkins__]: tabatkins__: If we're upgrading attributes to CSS properties, you dont' want to call it "position".
12:01:58 [tabatkins__]: heycam: Hm, true.
12:02:06 [tabatkins__]: ???: How about "offset"?
12:02:17 [tabatkins__]: tabatkins__: That's very similar to gradient's usage of @offset, so that's probably good.
12:04:14 [tabatkins__]: heycam: So I'm still not sure about getMarkerFromPoint() - if you use marker children you can do everything you need with events directly on the marker then. But the isPointInX() stuff seems useful still.
12:04:32 [tabatkins__]: cabanier: Sounds potentially expensive.
12:04:56 [tabatkins__]: ed: No, some of them are already directly needed for the pointer-events property. Markers don't, but it's just more geometry.
12:06:17 [tabatkins__]: ed: If you pass in a subpixel point, whether it's "in" the shape or not may depend on whether the browser does subpixel positioning.
12:06:27 [tabatkins__]: tabatkins__: I think that's a QoI issue. Browsers are all moving to subpixel layout anyway.
12:06:39 [tabatkins__]: ed: My main concern is about testing right now.
12:07:00 [tabatkins__]: tabatkins__: For CSS we currently just make sure things are always whole pixels. When we think we can depend on subpixel layout, we'll start writing tests against it.
12:07:37 [tabatkins__]: heycam: I'm not sure what's there to spec. The shapes are exactly defined - the spec doesn't need any more detail about that.
12:08:21 [ed]: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Non-interactive_marker_improvements
12:08:24 [tabatkins__]: Topic: non-interactive marker improvements
12:08:57 [tabatkins__]: heycam: the basic idea is to make marker-mid take a list of markers, so you can alternate between marker styles.
12:10:16 [tabatkins__]: heycam: Also, add marker-position to let you decide where a marker goes - onto the next corner, in the middle of the next edge, or a particular distance from the last marker.
12:11:28 [tabatkins__]: heycam: I've also extended the 'marker' shorthand to let it accommodate these changes.
12:11:47 [tabatkins__]: heycam: To help with this, marker-start and marker-end now have an 'auto' value that takes their marker from the marker-mid property, as appropriate.
12:13:46 [tabatkins__]: vhardy_: Why call it 'corner' rather than 'control-point' or something?
12:14:00 [tabatkins__]: vhardy_: And for 'edge' I prefer 'segment'. I don't think 'edge' is a good layman's term.
12:14:05 [krit]: arker: url(#mm1), 20px url(#mm2), url(#mm3)
12:16:21 [tabatkins__]: krit: How about a 'repeat' keyword on a mid marker to make it repeat them?
12:16:41 [tabatkins__]: tabatkins__: That's implicit - you continually cycle through the list until you run out of room on the path.
12:18:31 [tabatkins__]: heycam: [shows an example of how it works]
12:19:45 [tabatkins__]: heycam: And we could allow negative lengths too, so you can put a marker *before* a corner.
12:20:23 [tabatkins__]: heycam: like "marker: corner url(...), -20px url(...), 40px url(...);" put a marker at each corner, and one 20px to each side of each corner.
12:21:34 [tabatkins__]: vhardy_: Didn't we have something about marker-rotation?
12:22:06 [tabatkins__]: vhardy_: Wouldn't you want this per-marker?
12:22:12 [tabatkins__]: [something I missed about rotations]
12:22:29 [tabatkins__]: heycam: In this case if you had square and rotated square, it would save you duplicating the marker element.
12:22:52 [ed]: http://www.w3.org/TR/SVG11/painting.html#MarkerElement
12:23:52 [tabatkins__]: vhardy_: Eh, since you can just use @marker-orient, that might be okay.
12:28:16 [tabatkins__]: tabatkins__: back-compat issue - right now, if you say "marker: url(foo)", marker-start's value is "url(foo)". Under your proposal, it's "auto".
12:29:01 [tabatkins__]: heycam: I don't think that incompat will matter much in practice.
12:30:58 [tabatkins__]: vhardy_: What's the usage of markers on the web?
12:31:36 [tabatkins__]: krit: A lot of marker-start and marker-end.
12:32:12 [tabatkins__]: tabatkins__: And I've seen plenty of simple marker-mids, like circles on each joint.
12:33:32 [tabatkins__]: tabatkins__: In none of the proposals so far can you put a marker a certain distance from the end.
12:33:48 [tabatkins__]: tabatkins__: I kinda want to be able to say "end -20px url(...)".
12:34:02 [tabatkins__]: tabatkins__: That means potentially multiple start and end markers.
12:34:57 [tabatkins__]: vhardy_: I don't like having marker-position be separate from marker-mid, while they're combined in 'marker'. I'd prefer they be combined everywhere.
12:35:01 [tabatkins__]: tabatkins__: Agreed.
12:35:29 [tabatkins__]: Tav: One thing we get complaints about - if you have an arrow marker, and you position the path, the path sticks out from behind the arrow. I don't know how to fix that.
12:37:11 [tabatkins__]: heycam: There's a similar problem - if you have, say, a subway map where the marker-mids are open circles, you can't make them have transparent center, because the line gets drawn under it.
12:37:59 [tabatkins__]: vhardy_: You can just *very* carefully set up your stroke-dash-array...
12:38:09 [tabatkins__]: heycam: So we could have a keyword for that.
12:39:20 [tabatkins__]: heycam: For the arrowhead case, you dont' quite want to just chop out the overlap. You want to actually *end* the line when the marker starts.
12:39:48 [tabatkins__]: ed: Can't you specify the reference x/y of the marker to put it at the end of the line?
12:40:04 [tabatkins__]: tabatkins__: Then you have to shorten your path if you want the arrow to end at a particular point. Not good.
12:40:19 [tabatkins__]: vhardy_: Maybe a marker clip-path might work.
12:42:10 [tabatkins__]: heycam: For simple cases, you could just use a square.
12:42:33 [tabatkins__]: vhardy_: With some explicit lengths called out, so you can say "clear out the line from 5px - 10px of the marker area, then draw me over".
12:42:52 [tabatkins__]: heycam: And more complex cases can still use a clip-path itself.
12:45:16 [tabatkins__]: [discussion about clip-path on markers]
12:46:29 [tabatkins__]: krit: How would that interact with winding rules on the clip-path?
12:50:17 [tabatkins__]: [discussion of what cases aren't covered by a simple "stop drawing the line between these two lengths"]
12:51:20 [tabatkins__]: birtles: Does this interact with line-cap?
12:51:34 [tabatkins__]: vhardy_: I think it would just cut it sharply (like a 'butt' cap).
12:51:46 [tabatkins__]: vhardy_: But we need to define this as part of the stroking operation.
12:52:24 [Zakim]: -Tav
12:54:02 [tabatkins__]: [summary: it should work like dash-array when a line self-intersects, so different layers of the line may be visible.]
12:54:53 [tabatkins__]: ACTION heycam to write up a proposal about chopping out parts of a line relative to a marker.
12:54:53 [trackbot]: Created ACTION-3274 - Write up a proposal about chopping out parts of a line relative to a marker. [on Cameron McCormack - due 2012-05-14].
12:56:12 [tabatkins__]: heycam: So I think it might be good to drop the functions returning MarkerDetails, and just stick with the isPointInX stuff.
12:57:24 [Zakim]: disconnecting the lone participant, +49.403.063.68.aaaa, in Team_(svg)11:39Z
12:57:27 [Zakim]: Team_(svg)11:39Z has ended
12:57:27 [Zakim]: Attendees were Tav, +49.403.063.68.aaaa
12:58:13 [tabatkins__]: cabanier: What would happen if you had a spot cut out of the marker geometry? Would that affect hit-testing?
12:58:42 [tabatkins__]: RESOLVED: Add isPointInX() functions, from heycam's proposal.
12:59:17 [tabatkins__]: ACTION heycam to add the isPointInX() things to the spec.
12:59:18 [trackbot]: Created ACTION-3275 - Add the isPointInX() things to the spec. [on Cameron McCormack - due 2012-05-14].
13:00:40 [tabatkins__]: heycam: What about the marker children proposal?
13:02:00 [tabatkins__]: tabatkins__: I like it!
13:02:30 [tabatkins__]: birtles: For <marker href>, what about the functionality of <pattern>/etc where referring to an external one, attributes override the referenced element?
13:02:39 [tabatkins__]: birtles: I don't like it much, but for consistency we could allow it.
13:02:54 [tabatkins__]: heycam: Plus it might make an easy way to do differently-oriented markers without repeating yourself.
13:04:22 [tabatkins__]: ed: I'm not sure I like mixing automatic markers and marker children.
13:04:56 [tabatkins__]: tabatkins__: It would just be a fourth marker layer.
13:05:30 [tabatkins__]: heycam: For example, you could use a regularly-spaced auto marker to do a train-track, and use marker children for interactive elements.
13:05:48 [tabatkins__]: ed: Okay, as long as there's a defined drawing order.
13:06:00 [tabatkins__]: heycam: yeah, I was just thinking that marker chidlren would draw after all the automatic markers.
13:06:31 [tabatkins__]: RESOLUTION: Add <marker>-as-children to the spec.
13:07:47 [tabatkins__]: vhardy_: You can't easily mix, say, a marker every 20px and another marker on each corner.
13:08:13 [tabatkins__]: vhardy_: Because when you're cycling through the markers, you'll jump to the next corner, then move 20px, then jump to the next corner, then move 20px, etc.
13:10:40 [tabatkins__]: heycam: Ooh, good point. You may want multiple layers of lists. Hmm.
13:11:02 [tabatkins__]: vhardy_: Another possible problem. If you're, say, using markers to do train-tracks, you want one at the start, one at the end, and then the rest evenly spaced.
13:11:31 [tabatkins__]: tabatkins__: CSS has a similar concept - background-size:round sets it to the nearest size that'll repeat an integer number of times.
13:13:35 [tabatkins__]: heycam: So maybe lists of lists, but that's hard and confusing.
13:13:59 [tabatkins__]: tabatkins__: When CSS has needed nested separators, we use slash. But that binds tighter than commas.
13:15:15 [tabatkins__]: RESOLUTION: Add improved marker properties, per heycam's proposal.
13:33:35 [heycam]: ScribeNick: heycam
13:34:16 [heycam]: Topic: Masking
13:34:52 [heycam]: Zakim, room for 5?
13:34:55 [Zakim]: ok, heycam; conference Team_(svg)13:34Z scheduled with code 26634 (CONF4) for 60 minutes until 1434Z; however, please note that capacity is now overbooked
13:35:02 [vhardy_]: vhardy_ has joined #svg
13:35:37 [heycam]: Zakim, who is on the call?
13:35:37 [Zakim]: apparently Team_(svg)11:39Z has ended, heycam
13:36:17 [Zakim]: Team_(svg)13:34Z has now started
13:36:25 [Zakim]: + +49.403.063.68.aaaa
13:37:02 [birtles]: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Resource_referencing
13:38:48 [Zakim]: +Tav
13:49:04 [heycam]: http://dev.w3.org/SVG/profiles/1.1F2/master/definitions.xml
13:52:18 [ed]: http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org
13:53:49 [ed]: http://www.w3.org/Graphics/SVG/WG/wiki/Mercurial
13:57:12 [Zakim]: -Tav
14:11:34 [nikos]: nikos has joined #svg
14:16:42 [heycam]: ACTION: Cameron to edit SVG2 to make presentation attribute values case insensitive
14:16:42 [trackbot]: Created ACTION-3276 - Edit SVG2 to make presentation attribute values case insensitive [on Cameron McCormack - due 2012-05-14].
14:38:23 [heycam]: ACTION: Cameron to edit SVG2 to add HTML's style element attributes to SVG's style element
14:38:24 [trackbot]: Created ACTION-3277 - Edit SVG2 to add HTML's style element attributes to SVG's style element [on Cameron McCormack - due 2012-05-14].
14:39:00 [Zakim]: disconnecting the lone participant, +49.403.063.68.aaaa, in Team_(svg)13:34Z
14:39:03 [Zakim]: Team_(svg)13:34Z has ended
14:39:03 [Zakim]: Attendees were +49.403.063.68.aaaa, Tav
14:44:42 [heycam]: ACTION: Cameron to edit SVG2 to add onhashchange and other appropriate HTML document wide events
14:44:42 [trackbot]: Created ACTION-3278 - Edit SVG2 to add onhashchange and other appropriate HTML document wide events [on Cameron McCormack - due 2012-05-14].
14:48:31 [heycam]: ACTION: Cameron to add the stroke/fill/marker hit testing proposal to the SVG2 spec
14:48:31 [trackbot]: Created ACTION-3279 - Add the stroke/fill/marker hit testing proposal to the SVG2 spec [on Cameron McCormack - due 2012-05-14].
14:53:49 [heycam]: ACTION: Cameron to add async/defer to SVG script element
14:53:52 [trackbot]: Created ACTION-3280 - Add async/defer to SVG script element [on Cameron McCormack - due 2012-05-14].
14:56:21 [dbaron]: dbaron has joined #svg
14:58:21 [heycam]: ACTION: Cameron to migrate SVG2's baseline-related properties to use those defined in css3-linebox
14:58:21 [trackbot]: Created ACTION-3281 - Migrate SVG2's baseline-related properties to use those defined in css3-linebox [on Cameron McCormack - due 2012-05-14].
15:04:33 [heycam]: ACTION: Cameron to define scripting model for SVG2 to be compatible with HTML5
15:04:33 [trackbot]: Created ACTION-3282 - Define scripting model for SVG2 to be compatible with HTML5 [on Cameron McCormack - due 2012-05-14].
15:08:46 [jet]: jet has joined #svg
15:14:23 [ed]: Zakim, end telcon
15:14:23 [Zakim]: I don't understand 'end telcon', ed
15:14:29 [ed]: RRSAgent, end telcon
15:14:29 [RRSAgent]: I'm logging. I don't understand 'end telcon', ed. Try /msg RRSAgent help
15:14:38 [ed]: RRSAgent, make minutes
15:14:38 [RRSAgent]: I have made the request to generate http://www.w3.org/2012/05/07-svg-minutes.html ed
15:16:28 [ed]: RRSAgent, make minutes public
15:16:28 [RRSAgent]: I'm logging. I don't understand 'make minutes public', ed. Try /msg RRSAgent help
15:16:37 [ed]: RRSAgent, make logs public
15:16:42 [ed]: RRSAgent, make minutes
15:16:42 [RRSAgent]: I have made the request to generate http://www.w3.org/2012/05/07-svg-minutes.html ed
15:17:31 [heycam]: ACTION: Cameron to edit SVG2 to move SVG event listener attributes to Element
15:17:31 [trackbot]: Created ACTION-3283 - Edit SVG2 to move SVG event listener attributes to Element [on Cameron McCormack - due 2012-05-14].
15:18:05 [heycam]: ACTION-3283: See also ACTION-3080
15:18:05 [trackbot]: ACTION-3283 Edit SVG2 to move SVG event listener attributes to Element notes added
15:18:12 [heycam]: ACTION-3080: See also ACTION-3283
15:18:12 [trackbot]: ACTION-3080 File a bug on DOMCore to remind Anne about the event move. notes added
15:21:14 [heycam]: ACTION: Cameron to edit SVG2 to have evt as an alias for event
15:21:15 [trackbot]: Created ACTION-3284 - Edit SVG2 to have evt as an alias for event [on Cameron McCormack - due 2012-05-14].
15:21:33 [heycam]: trackbot, close ACTION-3284
15:21:33 [trackbot]: ACTION-3284 Edit SVG2 to have evt as an alias for event closed
15:25:39 [heycam]: ACTION: Cameron to add the paint-order property to SVG2
15:25:39 [trackbot]: Created ACTION-3285 - Add the paint-order property to SVG2 [on Cameron McCormack - due 2012-05-14].
15:28:50 [heycam]: ACTION: Cameron to add the marker children and marker property improvement proposals to SVG2
15:28:50 [trackbot]: Created ACTION-3286 - Add the marker children and marker property improvement proposals to SVG2 [on Cameron McCormack - due 2012-05-14].
15:34:13 [birtles]: birtles has joined #svg
15:55:31 [jet]: jet has joined #svg
18:10:26 [thorton]: thorton has joined #svg
18:12:02 [thorton_]: thorton_ has joined #svg
18:12:26 [thorton]: thorton has joined #svg
19:43:35 [vhardy_]: vhardy_ has joined #svg
19:52:24 [jet]: jet has joined #svg
21:12:24 [thorton]: thorton has joined #svg
21:14:56 [thorton_]: thorton_ has joined #svg