- From: Erik Dahlstrom <ed@opera.com>
- Date: Mon, 07 May 2012 17:22:52 +0200
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Minutes as html:
http://www.w3.org/2012/05/07-svg-minutes.html
and as text:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SV_MEETING_TITLE
07 May 2012
[2]Agenda
[2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Hamburg_2012/Agenda
See also: [3]IRC log
[3] http://www.w3.org/2012/05/07-svg-irc
Attendees
Present
+49.403.063.68.aaaa, Tav
Regrets
Chair
SV_MEETING_CHAIR
Scribe
vhardy, heycam, tabatkins__
Contents
* [4]Topics
1. [5]SVG2
2. [6]Web Component
3. [7]Painting order
4. [8]SVG DOM
5. [9]markers hit-testing
6. [10]marker children
7. [11]non-interactive marker improvements
8. [12]Masking
* [13]Summary of Action Items
__________________________________________________________
<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:
[14]https://my.adobeconnect.com/_a295153/vhardy
[14] https://my.adobeconnect.com/_a295153/vhardy
<cabanier> yes
<vhardy_> ScribeNick: vhardy
SVG2
<vhardy_>
[15]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page
[15] 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.
[16]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Co
mmitments
[16]
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
[17]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
put#z-index
[17]
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
[18]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:
[19]http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/
index.html
[19]
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>
[20]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Paint_orde
r
[20] 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>
[21]http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVecto
rEffectsPrimer.html
[21]
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>
[22]http://www.w3.org/TR/SVG11/interact.html#PointerEventsPrope
rty
[22] http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
vhardy: In which case the painting order doesn't matter.
<krit> [23]https://developer.mozilla.org/en/CSS/pointer-events
[23] 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>
[24]http://www.w3.org/TR/SVG11/render.html#PaintingShapesAndTex
t
[24] 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>
[25]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
put#Stroke_position
[25]
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>
[26]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Co
mmitments
[26]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments
<Cyril>
[27]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_pos
ition
[27] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_position
<heycam>
[28]http://lists.w3.org/Archives/Public/www-svg/2011Sep/0057.ht
ml
[28] 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>
[29]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
put#Make_it_easier_to_read_and_write_to_attributes_in_the_DOM
[29]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Make_it_easier_to_read_and_write_to_attributes_in_the_DOM
<birtles> [30]http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM
[30] 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
[31]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>
[32]http://lists.w3.org/Archives/Public/www-style/2012Feb/0333.
html
[32] 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,
[33]http://lists.w3.org/Archives/Public/www-style/2012Feb/1068.
html
[33] 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
[34]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:
[35]http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM
[35] 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>
[36]http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Specific_C
ommands_for_Paths
[36]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Specific_Commands_for_Paths
<tabatkins__> Element.create() :
[37]http://lists.w3.org/Archives/Public/public-webapps/2011JulS
ep/0537.html
[37]
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0537.html
<tabatkins__> better element constructors:
[38]http://lists.w3.org/Archives/Public/public-webapps/2011OctD
ec/0507.html
[38]
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>
[39]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Hit_testin
g
[39] 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>
[40]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Marker_chi
ldren
[40] 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>
[41]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Non-intera
ctive_marker_improvements
[41]
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> [42]http://www.w3.org/TR/SVG11/painting.html#MarkerElement
[42] 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>
[43]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Resource_r
eferencing
[43]
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Resource_referencing
[44]http://dev.w3.org/SVG/profiles/1.1F2/master/definitions.xml
[44] http://dev.w3.org/SVG/profiles/1.1F2/master/definitions.xml
<ed> [45]http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org
[45] http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org
<ed> [46]http://www.w3.org/Graphics/SVG/WG/wiki/Mercurial
[46] http://www.w3.org/Graphics/SVG/WG/wiki/Mercurial
<scribe> ACTION: Cameron to edit SVG2 to make presentation
attribute values case insensitive [recorded in
[47]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
[48]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
[49]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
[50]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
[51]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
[52]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
[53]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].
Summary of Action Items
[NEW] ACTION: Cameron to actually do his SVG DOM proposal
action, assuming we will use an opt-in switch [recorded in
[54]http://www.w3.org/2012/05/07-svg-minutes.html#action03]
[NEW] ACTION: Cameron to add async/defer to SVG script element
[recorded in
[55]http://www.w3.org/2012/05/07-svg-minutes.html#action08]
[NEW] ACTION: Cameron to add the stroke/fill/marker hit testing
proposal to the SVG2 spec [recorded in
[56]http://www.w3.org/2012/05/07-svg-minutes.html#action07]
[NEW] ACTION: Cameron to define scripting model for SVG2 to be
compatible with HTML5 [recorded in
[57]http://www.w3.org/2012/05/07-svg-minutes.html#action10]
[NEW] ACTION: Cameron to edit SVG2 to add HTML's style element
attributes to SVG's style element [recorded in
[58]http://www.w3.org/2012/05/07-svg-minutes.html#action05]
[NEW] ACTION: Cameron to edit SVG2 to add onhashchange and
other appropriate HTML document wide events [recorded in
[59]http://www.w3.org/2012/05/07-svg-minutes.html#action06]
[NEW] ACTION: Cameron to edit SVG2 to make presentation
attribute values case insensitive [recorded in
[60]http://www.w3.org/2012/05/07-svg-minutes.html#action04]
[NEW] ACTION: Cameron to migrate SVG2's baseline-related
properties to use those defined in css3-linebox [recorded in
[61]http://www.w3.org/2012/05/07-svg-minutes.html#action09]
[NEW] 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
[62]http://www.w3.org/2012/05/07-svg-minutes.html#action01]
[NEW] ACTION: Tab to bring up SVG elements in HTML namespace in
WHATWG [recorded in
[63]http://www.w3.org/2012/05/07-svg-minutes.html#action02]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [64]scribe.perl version
1.136 ( [65]CVS log)
$Date: 2012/05/07 15:16:48 $
__________________________________________________________
[64] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[65] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43
Check for newer version at
[66]http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
[66] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/Emonds/Emmons/
Succeeded: s/tav/tab/
Succeeded: s/RESOLVED:/RESOLUTION:/
Found ScribeNick: vhardy
WARNING: No scribe lines found matching ScribeNick pattern: <vhardy> ..
.
Found ScribeNick: heycam
Found ScribeNick: vhardy
WARNING: No scribe lines found matching ScribeNick pattern: <vhardy> ..
.
Found ScribeNick: tabatkins__
Found ScribeNick: heycam
Found ScribeNick: tabatkins__
Found ScribeNick: heycam
Inferring Scribes: vhardy, heycam, tabatkins__
Scribes: vhardy, heycam, tabatkins__
ScribeNicks: vhardy, heycam, tabatkins__
WARNING: Replacing list of attendees.
Old list: +33.1.75.06.aaaa Cyril +49.403.063.68.aabb Tav Doug_Schepers
New list: Tav +49.403.063.68.aaaa Cyril
WARNING: Replacing list of attendees.
Old list: Tav +49.403.063.68.aaaa Cyril
New list: Tav +49.403.063.68.aaaa
Default Present: +49.403.063.68.aaaa, Tav
Present: +49.403.063.68.aaaa Tav
WARNING: Fewer than 3 people found for Present list!
WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting
Agenda:
[67]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Hamburg_2012/Agenda
[67] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Hamburg_2012/Agenda
WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth
Got date from IRC log name: 07 May 2012
Guessing minutes URL:
[68]http://www.w3.org/2012/05/07-svg-minutes.html
People with action items: cameron shepazu tab
[68] http://www.w3.org/2012/05/07-svg-minutes.html
WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.
End of [69]scribe.perl diagnostic output]
[69] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Monday, 7 May 2012 15:23:34 UTC