SV_MEETING_TITLE -- 07 May 2012

<ed> hi Cyril

<Cyril> hi Erik

<nikos> g'day Cyril

<ed> dialing in today?

<Cyril> hi all

<Cyril> if possible?

<heycam> we are still waiting on a couple of people, so let's aim to start in 15 minutes

<heycam> I'll set up a bridge then

<Cyril> or if one of you has Skype

<heycam> there is a microphone system in the room here, not sure how easy it would be to hook skype up to it

<Cyril> then I'll call

<Cyril> I might have to call back every hour

<shepazu> what telcon is this?

<shepazu> oh!

<shepazu> are you starting the SVG f2f?

<heycam> yes

<Tav> Hi

<Tav> yes

<Tav> code?

<cabanier> connect url: https://my.adobeconnect.com/_a295153/vhardy

<cabanier> yes

<vhardy_> ScribeNick: vhardy

SVG2

<vhardy_> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page

<vhardy_> heycam: we are running behind on our schedule.

<vhardy_> … we wanted to have subsections in the spec. for all the new things people had signed up for.

<vhardy_> … I am guilty as well. But everybody is behind.

<vhardy_> …. what can we do to make sure that we make progress?

<vhardy_> tav: I have put 40% of them in. It takes time.

<vhardy_> .. who is supposed to be responsible. The requirements, the link to the resolution.

<vhardy_> heycam: a few of them are at the top of the chapter.

<vhardy_> tav: some I can figure out.

<vhardy_> heycam: I am getting the impression that people do not have a lot of time to allocate to spec. editing.

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

<vhardy_> … not just 1 or 2 features.

<vhardy_> … we have not selected any people yet for that.

<vhardy_> … anybody feels that they have the time to do that?

<vhardy_> tab: I would love to, but cannot.

<vhardy_> jet: who is there on the editor list now?

<vhardy_> heycam: in the SVG 1.1 spec., we did not have a main editor. Everybody was pitching in.

<vhardy_> … there was no primary editor. We need 1 or 2 main editors for this version.

<vhardy_> tav: yes, it is very inconsistent.

<vhardy_> heycam: tav you have already done a lot of work on the spec., can you become the main editor?

<vhardy_> tav: I have asked Mozilla and Google for support, but this is not their current priority.

<vhardy_> heycam: there is a lot of CSS high priority items.

<heycam> ScribeNick: heycam

VH: this is close to my concern about the spec editing

… SVG 2 is large, rewriting it is a big effort

… especially if we have constraints on editorship, this is a question for the group

… should we focus on particular efforts that are critical? integration work, animation, etc.?

… we know there is a big issue on the web with animation, it's a big thing to sort out

… we know that better canvas integration in svg would improve things

… my question is shouldn't we focus on smaller specs

… even the web animation is going to be a large effort, but still much smaller than SVG2 as a whole

… since we have people motivated for these pieces, it's more likely we can pull it off

TA: modularisation like CSS

VH: we're still needing implementations to get up to speed with SVG 1.1

… we could have SVG DOM improvements as a separate spec

ED: some things would be easier to write up in modules than others

Dirk: paint servers could be split out

BB: I'm in favour of modularisation

ED: I think identifying small parts, standalone modules

VH: do we think the highest priority things can be done as modules?

<vhardy_> heycam: we can have a look at the list of things we have signed up for and see what can be modularized.

<vhardy_> … for example, SVG DOM improvements may be hard to split out.

<vhardy_> … canvas integration can be easy to split out.

<vhardy_> dirk: should we make a list now of what could be a module?

<vhardy_> heycam: yes, we can do that list now.

<vhardy_> … and we could get people to sign up as separate specs.

<vhardy_> dirk: ok.

http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments

<vhardy_> heycam: let's look at the one for which someone signed up for.

<vhardy_> z-index http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#z-index

<Cyril> could be good if the tick in the table had a link to the spec

<vhardy_> dirk: that could be combined with something else.

<vhardy_> heycam: this is fundamental, changes the painting model.

<vhardy_> dirk: should it be in the new definition of the rendering model?

<vhardy_> heycam: we could split out the rendering model in a separate spec.

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

<vhardy_> … stitching specs together is going to be hard.

<vhardy_> tab: what we have done in CSS, we have turned pieces of the core spec. into new modules of the spec.

<vhardy_> brian: so you do not need a full SVG 2.0 spec. at all?

<vhardy_> tab: yes, possibly. CSS 2.1 is still a reference for things that are not redefined in a module.

<vhardy_> heycam: does that work well?

<vhardy_> tav: yes, because we did not have to redo a lot of low level work.

<vhardy_> … we still have to do things like the box model.

<scribe> ScribeNick: vhardy

<vhardy_> vhardy: I thnk that while not perfect, this is a pretty good option.

<vhardy_> shepazu: I do not agree at all. It took CSS a decade to do that.

<vhardy_> tav: it took a decade to get CSS 2.1 good.

<vhardy_> shepazu: I think that trying to find the parts of SVG to split out and then doing their own spec is difficult.

<vhardy_> … unless we see a plan to see which parts can be split out.

<vhardy_> … we have already split out filters, transforms, etc… What is left is core functionality.

<vhardy_> dirk: paint servers is something that could be done independent of SVG.

<vhardy_> … it could be a module of its own.

<vhardy_> ed: it was suggested as a module in the past. Andrew Emmons was supposed to take that module.

<vhardy_> shepazu: the other thing is that we have individual people who might take on individual specs. All these things depend on one another.

<vhardy_> … I do not think that we face the same problems as CSS faces. We do not have the same number of people.

<vhardy_> tav: we can identify things that are independent and can be carved out as new modules.

<vhardy_> shepazu: we already decided about what goes into SVG 2.0.

<heycam> VH: I think it's clear it's hard to put together a big monolithic spec

<heycam> … and we're behind schedule

<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

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

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

<vhardy_> dirk: how do we do that?

<vhardy_> tab: we have a collection of things that are SVG.

<Cyril> if people don't have time to edit the current spec, I don't think they'll have time to edit modules

<vhardy_> (discussion about how modules would be split out or not and what would constitute SVG 2.0)

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

<vhardy_> …. CSS modules just augment the CSS 2.1 spec.

<vhardy_> …. we also collect errata for CSS 2.1

<vhardy_> .. SVG 2.0 is not near that point.

<vhardy_> … if someone wanted to pull a module out, we could do that.

<vhardy_> … this could be decided piecemeal.

<vhardy_> cyril: I do not see how modules can help.

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

<vhardy_> … I do not see how modules would help.

<vhardy_> heycam: what would make it easier to edit if things are independent specs.

<vhardy_> brian: easier to find editors.

<vhardy_> heycam: people own the separate features.

<Cyril> an editor of a module is the same as an editor of a part of the spec, no?

<tabatkins__> Cyril: Basically, yeah. It's just an organization/semantic thing.

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

<vhardy_> dirk: I think tab's proposal, we could increase our ability to split out modules as needed.

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

<vhardy_> dirk: can we agree that we want to use this model?

<vhardy_> shepazu: do we need a new resolution on that? We have been doing this for years now.

<vhardy_> … we should work on spec. and technical work.

<Cyril> +1

<vhardy_> dirk: it seems that you just agreed to tab's proposal.

<vhardy_> heycam: If people want to break things out, they can ask the group and we can agree to do that or not.

<vhardy_> tav: we could annotate, along the way, what is solid and what is not, like in the HTML5 work.

<vhardy_> heycam: that sounds right.

<vhardy_> shepazu: yes

<vhardy_> … and it should be backed up with tests.

<vhardy_> … they'll ensure that we get interoperability.

<vhardy_> … tests are needed before we can mark things as stable.

<vhardy_> heycam: we do not need to go through the list at this point.

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

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

<vhardy_> … I think this mixes well with what Tab suggest to keep SVG 1.1 as the reference. We can keep the old text.

<vhardy_> … as the reference.

<vhardy_> dirk: don't we need a global editor to organize and keep the overall consistency?

<vhardy_> shepazu: what would be the role?

<vhardy_> heycam: coherence, bug fixing for things that do not fall into features, insuring the document as a whole is reasonnable.

<vhardy_> vhardy: in the SVG 1.0 and 1.1 1rst edition, the editors did a tremendous amount of coherence checking etc....

<vhardy_> heycam: having to rewrite sections was an impediment to making progress.

<vhardy_> … for SVG tiny.

<vhardy_> shepazu: the spec. as it stands has holes and consistencies, we are continuing the inconsistencies.

<vhardy_> heycam: I do not think it is completely terrible.

<vhardy_> shepazu: I do not want to argue about this anymore.

<vhardy_> heycam: realistically, nobody is going to put the time into this.

<vhardy_> … we can just continue to aim at our milestone page and follow that plan.

<vhardy_> tav: the list of requirements is not sorted. It is one long list. I'd like to sort it by chapter.

<vhardy_> heycam: that would be fine.

<vhardy_> cyril: the numbers would have to change.

<vhardy_> tav: is that a problem?

<vhardy_> heycam: I do not think people rely on those numbers.

<vhardy_> … tav: go and do that if you want.

<vhardy_> cyril: a long time ago, I sent an email with a sorting/categorization of the requirements.

<vhardy_> heycam: would it be beenficial to do some work on the spec. during the F2F?

<vhardy_> tav: yes, that would be good.

<vhardy_> ed: +1

<vhardy_> tav: requirements, resolution, etc… short summary and responsible person would help.

<Cyril> making sure everyone has the right environement for editing

<vhardy_> tab: I am afraid some people will end up clocking out.

<vhardy_> heycam: I think it might help getting people started if they have not done it yet.

<vhardy_> heycam: ok, we'll do that at the end of the day today.

<vhardy_> (before 5:15pm)

<vhardy_> heycam: we are done with the SVG 2.0 discussion then.

<vhardy_> heycam: we can talk about the web components now.

Web Component

<vhardy_> shepazu: it just happened last week.

<vhardy_> … we have been talking for a while about the <use> and the resulting shadow tree.

<vhardy_> … pretty unpopular. We have been talking about using the Web component model that Dmitry Glaskov has been writing.

<vhardy_> … at TPAC, when we talked, he was not sure how it would work with the <use> element.

<vhardy_> … the goal of having <use> be an instanciation of the shadow DOM model would be easier.

<vhardy_> … with SVG as it stands, it is more complicated and not very performant (as I understand it).

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

<vhardy_> … so there is some differnece.

<vhardy_> … in his old model, that would not work. In the new model, it would work.

<vhardy_> … you could have a separate styling for each instance of the component.

<vhardy_> … so in other words, we can go ahead and use the component model to mimic the <use> element.

<vhardy_> dirk: that is what we do in WebKit now.

<vhardy_> … was done in the last couple months.

<vhardy_> tav: does that change anything, is it fully compatible?

<vhardy_> dirk: the use element now works a lot better in WebKit/

<vhardy_> shepazu: there are some DOM methods for the <use> element (like ElementInstance) that would need to be deprecated.

<vhardy_> … not impelmented consistently.

<vhardy_> … modern SVG content does not use that.

<vhardy_> …. it was implemented in the ASV viewer.

<vhardy_> tab: we would need to re-write the <use> DOM.

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

<vhardy_> heycam: I have not looked at the shadow DOM for a while.

<vhardy_> …. there are methods to get to the shadow tree?

<vhardy_> tab: yes, the element.shadow.

<vhardy_> heycam: is there event retargeting.

<vhardy_> tab: it is a closer rewrite of the XBL2 event model.

<Tav> The conference code has expired... can't call back in.

<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. [recorded in http://www.w3.org/2012/05/07-svg-minutes.html#action01]

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

<vhardy_> heycam: shepazu, can you explain how the style can be inherited from the <use> element on the instance.

<vhardy_> tab: I think this is a todo in the shadow DOM spec. to allow inheritance.

<vhardy_> shepazu: the <use> will be syntactic sugar for regular shadow tree.

<vhardy_> (discussion about event retargeting, see the Shadow DOM proposal).

<vhardy_> shepazu: there were only some classes of content that was doing this. I am not worried about breaking that content.

<vhardy_> brian: would that be useful for markers as well?

<vhardy_> shepazu: I think we could safely state that markers are <use> instances and we could add functionality to markers.

<vhardy_> heycam: we should be able to describe markers in terms of shadow tree.

<vhardy_> vhardy: I think markers could be modeled with the shadow DOM, but they may have a memory footprint consequence.

<vhardy_> heycam: implementations can be smart about it and lazily create the DOM.

<vhardy_> vhardy: there was a discussion about shadow DOM and regions and memory was shown to be an issue.

<vhardy_> shepazu: may be markers do not have to be modeled with the shadow DOM.

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

<vhardy_> shepazu: another problem with markers is simply that the ability to position them is very limited.

<vhardy_> … I do not think it is a particularly good model.

<vhardy_> heycam: I have proposals for that.

<vhardy_> heycam: so the web component model will be good for the <use> element. Anything else on this?

<vhardy_> shepazu: done.

<vhardy_> heycam: break for 15mn

<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

<tabatkins__> Explains the CSS and events interaction really easily.

<tabatkins__> ScribeNick: tabatkins__

Painting order

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Paint_order

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.
... Especially for text, you sometimes want the stroke *underneath* the text, rather than on top.

krit: How does this relate to Vector Effects?

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.
... 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.
... So I think it's better to have it as a separate property, and later define how it interacts with VE.

[somewhat confusing discussion about repeated use of keywords]

[resolved by explaining the syntax better]

birtles: How does this interact with stroke-inner/outer?

vhardy_: It adjust the shape of the stroke, not the painting order.

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?

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.

birtles: fill-opacity makes a difference between the two cases,

tabatkins__: stroke-outside is what you want with partially-transparent fill.

vhardy_: I think that some rendering engines dont' do this well.

krit: You can just clip around the text.

vhardy_: Still potentially pixel-level rendering issues.

tabatkins__: So it's a QoI issue.

krit: So if we had good stroke-outside, is there still a good reason to have this?

ed: Moving markers around is still a useful effect, and can't be done otherwise.

heycam: It also lets you get the stroke-outside effect in opaque cases without us having to wait for stroke-outside.

krit: [discussion about offsetting strokes more powerfully with the proposals about stroke-outside/offset/whatever]

birtles: Is there a strong use-case besides the one that can be done with a stroke offset?

tabatkins__: Markers moving their painting order is still something else.

[discussion about spec path for stroke-offset, maybe just starting with inside/outside/middle, and later use more powerful stuff]

vhardy_: I'm in favor of this proposal. It's simple, and can be useful for authors.

ed: I'm not particularly happy with the name.

vhardy_: Yeah, 'paint-order' reminds me of z-order.

heycam: Naming suggestions welcome.
... And if you don't specify all the keywords, presumably the rest get applied in the normal order, after the specified ones.
... So if more layers show up in the future, it doesn't invalidate the existing content.

krit: What about controlling the order of clipping/masking/etc?

heycam: Not right now. That might be something to look at in the future.
... It might be getting into the realm of something you want to write a whole VE definition for.

<krit> http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.html

birtles: I'd be happier if there was an explicit strong use-case, but I'm okay with the property.

heycam: I think usually I've wanted something like this to make "stroke outside", but that's an incomplete solution.

krit: What about hit-testing?

ed: I think pointer-events defines how that should work, more or less.

vhardy: I think pointer-events is just about the geometry of the pieces.

<ed> http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty

vhardy: In which case the painting order doesn't matter.

<krit> https://developer.mozilla.org/en/CSS/pointer-events

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.

RESOLUTION: Add heycam's "paint-order" proposal, though possibly with a different name.

<ed> http://www.w3.org/TR/SVG11/render.html#PaintingShapesAndText

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]

[some naming discussion for 'paint-order']

<Cyril> to which reqs does the paint-order proposal correspond ?

<heycam> Cyril, none, it's a new one. (sorry!)

<birtles> other options suggested: painting-order, draw-order, painting-operation-order, shape-order

<Cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Stroke_position

Cyril: Maybe link to that requirement when talking about paint-order.

<krit> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments

<Cyril> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_position

<heycam> http://lists.w3.org/Archives/Public/www-svg/2011Sep/0057.html

tabatkins__: The two aren't actually related, except that one use-case can be done with either.

krit: Note that stroke-position *would* affect hit-testing.

<heycam> ScribeNick: heycam

SVG DOM

TA: we've discussed fixing the SVG DOM generally

… like throwing away animVal/baseVal, in favour of a way of retrieving those things separately

… obviously that's a breaking change

BB: we have a proposal for deprecating that at the same time as introducing compact syntax

TA: if we can do this compatibly, that'd be awesome

… but if not, we need to think about version switching

… we'd need to do this in such a way that's usable in SVG and HTML as well

… the version switch for example can't be based on doctype

… since that wouldn't work for inline SVG-in-HTML

<Cyril> Commitments page modified

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

RC: so for inline SVG, all the APIs change?

TA: well you would use createElement instead of createElementNS

… one problem is style/script/font/a

… we want a context free parsing mode in HTML, but to do that properly it needs to know context

… we want that to work for SVG too

… if the markup string starts with "<g>" then it should know it's SVG

… if the first element you see is style/script/font/a, then it'll think that it's HTML instead

… if we switched it all over to the HTML namespace it's ok

… the only sane way to do the parsing is to look at the start tag

… to determine the context

Dirk: there's also different DOM APIs for SVG/HTML script and style

TA: if there is a fragment that starts with <a> then it's very likely to be HTML

ED: people have been suggesting innerSVG instead of innerHTML

… which is one way of switching, but it's not great

<birtles> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Make_it_easier_to_read_and_write_to_attributes_in_the_DOM

<birtles> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM

<birtles> rectElt.x.px = 20

TA: className works differently between SVG and HTML, so that's weird

… it would be good to have no differences between these accessors

TA: the proposal linked to there is better than baseVal.value, but it's still not the same as HTML

CM: I think the fragment parsing and SVG DOM improvemnets are mostly separate issues

TA: yes but it would make it easier if they are all in the HTML namespace

… if all the SVG elements can also exist in the HTML namespace, that might work

… I wonder if that produces much incompatibility with existing namespace

CM: I think it's worth looking at

TA: if you don't need to care about namespaces, then you no longer need an outer <svg> for inline svg

VH: I did want to be able to do that

[discussion about whether the namespace of the element can be the switch for the new SVG DOM properties]

VH: you could have an attribute on the <svg> element to opt in to the new dom

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

<scribe> ACTION: Tab to bring up SVG elements in HTML namespace in WHATWG [recorded in http://www.w3.org/2012/05/07-svg-minutes.html#action02]

<trackbot> Created ACTION-3272 - Bring up SVG elements in HTML namespace in WHATWG [on Tab Atkins Jr. - due 2012-05-14].

<vhardy__> yes :-)

VH: we should consider what this means for standalone SVG

ED: you can already get that with an HTML doctype at the top

TA: you can't use an <img> to link to an SVG in html
... we need to investigate how compatibly we can change the SVG DOM

… if we can't, then we'll need the switch

ED: we'll definitely need to improve the CSSOM too if we migrate attributes to properties

[discussion about unitless values]

VH: where are we with the attributes becoming properties?

ED: there was a thread on www-style

CM: I think nobody replied to it

VH: I think there was some issue with the meaning of percentages in width/height

<ed> http://lists.w3.org/Archives/Public/www-style/2012Feb/0333.html

<ed> (that's the property proposal)

<ed> so smfr thinks they should be prefixed, http://lists.w3.org/Archives/Public/www-style/2012Feb/1068.html

Dirk: there's also this getPresentationAttribute API

… will we still need that if we promote everything to properties?

… it would be nice to be able to get typed access to presentation attributes

CM: maybe that could be exposed like element.presentation.x, where element.presentation is the style sheet for presentation attributes

Dirk: should element.x return an object or just a string?

TA: it could be ok to return an object, if we've opted in to the new api

<scribe> ACTION: Cameron to actually do his SVG DOM proposal action, assuming we will use an opt-in switch [recorded in http://www.w3.org/2012/05/07-svg-minutes.html#action03]

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

ACTION-3273: http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM

<trackbot> ACTION-3273 Actually do his SVG DOM proposal action, assuming we will use an opt-in switch notes added

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Specific_Commands_for_Paths

<tabatkins__> Element.create() : http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0537.html

<tabatkins__> better element constructors: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0507.html

[discussion about SVGPoint becoming Point, etc.]

<tabatkins__> <br type=lunch dur=1h>

<tabatkins__> ScribeNick: tabatkins__

markers hit-testing

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Hit_testing

heycam: One of the SVG2 reqs was to hav ea way to distinguish between hit-testing strokes and fills of shapes.
... And related, markers.
... I've suggested a few methods that can be called to determine whether a point was over the stroke/fill/marker of the shape.
... In the proposal, a passed point is in the coordinate space of the element.
... But also it can just take an event object directly, so you don't have to swizzle the coordinates.
... Finally, I provided getMarkerFromPoint and getMarkerIndex for some more marker utility.

vhardy_: What's in a MarkerDetails?

heycam: the index of the marker, the distance along the path, and the actual <marker> element that it's generated from.
... I think that's about as usefula s you can make the autoamtically produced markers.
... Another proposal later is for explicit elements for markers in the document, which you can put event handlers on.
... If your original <marker> had some onclick on it, they'd be cloned into the shadow tree.
... 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.
... I don't know how we'd want to include this.

birtles: I think we could probably redefine the existing pointer-events values, since authors are probably assuming that they contribute already.

heycam: We could introduce some more keywords like 'marker/visibleMarker'
... But you can't combine them currently.

ed: I've wanted before to style particular markers, like the one you're hovering.

heycam: That might work with the shadow DOM.

birtles: In MarkerDetails there's an index. What useful stuff can you do with that?

heycam: Good question.

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.

heycam: It might be useful to look at the other marker stuff, so you can see how useful they'd be combined.

marker children

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Marker_children

heycam: Basically you can put <marker> elements as children of the <path>.
... It can either refer to a <marker> defined elsewhere, or do it inline.
... There's also a @position attribute that gives a distance along the path.

Tav: What about rectangles? Could we put a <marker> on a rectangle?

heycam: They can't apply yet, but we could do so.

ed: We already define where the strokes start on those shapes.

krit: What about the interaction with automatic markers?

heycam: I was thinking you'd draw the automatic markers, then draw the manual ones.

krit: [something about regularly-spaced markers]

heycam: I think there's some more proposal about that.

krit: Could we have the @position take a list of lengths, so you generate multiple markers from one <marker>?

heycam: Maybe, but then you'd have to go back to adding API for working with multiple elements.

tabatkins__: If we're upgrading attributes to CSS properties, you dont' want to call it "position".

heycam: Hm, true.

???: How about "offset"?

tabatkins__: That's very similar to gradient's usage of @offset, so that's probably good.

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.

cabanier: Sounds potentially expensive.

ed: No, some of them are already directly needed for the pointer-events property. Markers don't, but it's just more geometry.
... If you pass in a subpixel point, whether it's "in" the shape or not may depend on whether the browser does subpixel positioning.

tabatkins__: I think that's a QoI issue. Browsers are all moving to subpixel layout anyway.

ed: My main concern is about testing right now.

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.

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.

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Non-interactive_marker_improvements

non-interactive marker improvements

heycam: the basic idea is to make marker-mid take a list of markers, so you can alternate between marker styles.
... 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.
... I've also extended the 'marker' shorthand to let it accommodate these changes.
... 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.

vhardy_: Why call it 'corner' rather than 'control-point' or something?
... And for 'edge' I prefer 'segment'. I don't think 'edge' is a good layman's term.

<krit> arker: url(#mm1), 20px url(#mm2), url(#mm3)

krit: How about a 'repeat' keyword on a mid marker to make it repeat them?

tabatkins__: That's implicit - you continually cycle through the list until you run out of room on the path.

heycam: [shows an example of how it works]
... And we could allow negative lengths too, so you can put a marker *before* a corner.
... like "marker: corner url(...), -20px url(...), 40px url(...);" put a marker at each corner, and one 20px to each side of each corner.

vhardy_: Didn't we have something about marker-rotation?
... Wouldn't you want this per-marker?

[something I missed about rotations]

heycam: In this case if you had square and rotated square, it would save you duplicating the marker element.

<ed> http://www.w3.org/TR/SVG11/painting.html#MarkerElement

vhardy_: Eh, since you can just use @marker-orient, that might be okay.

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".

heycam: I don't think that incompat will matter much in practice.

vhardy_: What's the usage of markers on the web?

krit: A lot of marker-start and marker-end.

tabatkins__: And I've seen plenty of simple marker-mids, like circles on each joint.
... In none of the proposals so far can you put a marker a certain distance from the end.
... I kinda want to be able to say "end -20px url(...)".
... That means potentially multiple start and end markers.

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.

tabatkins__: Agreed.

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.

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.

vhardy_: You can just *very* carefully set up your stroke-dash-array...

heycam: So we could have a keyword for that.
... 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.

ed: Can't you specify the reference x/y of the marker to put it at the end of the line?

tabatkins__: Then you have to shorten your path if you want the arrow to end at a particular point. Not good.

vhardy_: Maybe a marker clip-path might work.

heycam: For simple cases, you could just use a square.

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".

heycam: And more complex cases can still use a clip-path itself.

[discussion about clip-path on markers]

krit: How would that interact with winding rules on the clip-path?

[discussion of what cases aren't covered by a simple "stop drawing the line between these two lengths"]

birtles: Does this interact with line-cap?

vhardy_: I think it would just cut it sharply (like a 'butt' cap).
... But we need to define this as part of the stroking operation.

[summary: it should work like dash-array when a line self-intersects, so different layers of the line may be visible.]

ACTION heycam to write up a proposal about chopping out parts of a line relative to a marker.

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

heycam: So I think it might be good to drop the functions returning MarkerDetails, and just stick with the isPointInX stuff.

cabanier: What would happen if you had a spot cut out of the marker geometry? Would that affect hit-testing?

RESOLUTION: Add isPointInX() functions, from heycam's proposal.

ACTION heycam to add the isPointInX() things to the spec.

<trackbot> Created ACTION-3275 - Add the isPointInX() things to the spec. [on Cameron McCormack - due 2012-05-14].

heycam: What about the marker children proposal?

tabatkins__: I like it!

birtles: For <marker href>, what about the functionality of <pattern>/etc where referring to an external one, attributes override the referenced element?
... I don't like it much, but for consistency we could allow it.

heycam: Plus it might make an easy way to do differently-oriented markers without repeating yourself.

ed: I'm not sure I like mixing automatic markers and marker children.

tabatkins__: It would just be a fourth marker layer.

heycam: For example, you could use a regularly-spaced auto marker to do a train-track, and use marker children for interactive elements.

ed: Okay, as long as there's a defined drawing order.

heycam: yeah, I was just thinking that marker chidlren would draw after all the automatic markers.

RESOLUTION: Add <marker>-as-children to the spec.

vhardy_: You can't easily mix, say, a marker every 20px and another marker on each corner.
... 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.

heycam: Ooh, good point. You may want multiple layers of lists. Hmm.

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.

tabatkins__: CSS has a similar concept - background-size:round sets it to the nearest size that'll repeat an integer number of times.

heycam: So maybe lists of lists, but that's hard and confusing.

tabatkins__: When CSS has needed nested separators, we use slash. But that binds tighter than commas.

RESOLUTION: Add improved marker properties, per heycam's proposal.

<heycam> ScribeNick: heycam

Masking

<birtles> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Resource_referencing

http://dev.w3.org/SVG/profiles/1.1F2/master/definitions.xml

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Mercurial

<scribe> ACTION: Cameron to edit SVG2 to make presentation attribute values case insensitive [recorded in http://www.w3.org/2012/05/07-svg-minutes.html#action04]

<trackbot> Created ACTION-3276 - Edit SVG2 to make presentation attribute values case insensitive [on Cameron McCormack - due 2012-05-14].

<scribe> ACTION: Cameron to edit SVG2 to add HTML's style element attributes to SVG's style element [recorded in http://www.w3.org/2012/05/07-svg-minutes.html#action05]

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

<scribe> ACTION: Cameron to edit SVG2 to add onhashchange and other appropriate HTML document wide events [recorded in http://www.w3.org/2012/05/07-svg-minutes.html#action06]

<trackbot> Created ACTION-3278 - Edit SVG2 to add onhashchange and other appropriate HTML document wide events [on Cameron McCormack - due 2012-05-14].

<scribe> ACTION: Cameron to add the stroke/fill/marker hit testing proposal to the SVG2 spec [recorded in http://www.w3.org/2012/05/07-svg-minutes.html#action07]

<trackbot> Created ACTION-3279 - Add the stroke/fill/marker hit testing proposal to the SVG2 spec [on Cameron McCormack - due 2012-05-14].

<scribe> ACTION: Cameron to add async/defer to SVG script element [recorded in http://www.w3.org/2012/05/07-svg-minutes.html#action08]

<trackbot> Created ACTION-3280 - Add async/defer to SVG script element [on Cameron McCormack - due 2012-05-14].

<scribe> ACTION: Cameron to migrate SVG2's baseline-related properties to use those defined in css3-linebox [recorded in http://www.w3.org/2012/05/07-svg-minutes.html#action09]

<trackbot> Created ACTION-3281 - Migrate SVG2's baseline-related properties to use those defined in css3-linebox [on Cameron McCormack - due 2012-05-14].

<scribe> ACTION: Cameron to define scripting model for SVG2 to be compatible with HTML5 [recorded in http://www.w3.org/2012/05/07-svg-minutes.html#action10]

<trackbot> Created ACTION-3282 - Define scripting model for SVG2 to be compatible with HTML5 [on Cameron McCormack - due 2012-05-14].

- DRAFT -

SV_MEETING_TITLE

07 May 2012

Attendees

Contents

SVG2

Web Component

Painting order

SVG DOM

markers hit-testing

marker children

non-interactive marker improvements

Masking

Summary of Action Items

Scribe.perl diagnostic output