W3C home > Mailing lists > Public > public-svg-wg@w3.org > April to June 2012

Minutes, Hamburg 2012 SVG WG - Day 1

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>
Message-ID: <op.wdx2cen1geuyw5@mbp-2.local>
Minutes as html:


and as text:


       [1] http://www.w3.org/

                                - DRAFT -


07 May 2012


       [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


           +49.403.063.68.aaaa, Tav


           vhardy, heycam, tabatkins__


      * [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

    <cabanier> yes

    <vhardy_> ScribeNick: vhardy



      [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

    … 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

    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

    <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

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

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

    <vhardy_> dirk: ok.



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

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

    <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

    <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

    <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

    <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

    <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

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

    <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

    <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

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

    <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

    <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

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

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

    <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

    <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

    <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

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


    <tabatkins__> Explains the CSS and events interaction really

    <tabatkins__> ScribeNick: tabatkins__

Painting order


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

    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

    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

    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.



    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.


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


      [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: Maybe link to that requirement when talking about




      [27] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_position


      [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


    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

    … to determine the context

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

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

    … it would be good to have no differences between these

    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

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

    … I wonder if that produces much incompatibility with existing

    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

    <scribe> ACTION: Tab to bring up SVG elements in HTML namespace
    in WHATWG [recorded in

    <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

    … 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


      [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

    Dirk: there's also this getPresentationAttribute API

    … will we still need that if we promote everything to

    … 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

    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

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


      [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



    <tabatkins__> Element.create() :


    <tabatkins__> better element constructors:


    [discussion about SVGPoint becoming Point, etc.]

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

    <tabatkins__> ScribeNick: tabatkins__

markers hit-testing


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


      [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

    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
    ... If you pass in a subpixel point, whether it's "in" the
    shape or not may depend on whether the browser does subpixel

    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



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

    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

    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

    [discussion about clip-path on markers]

    krit: How would that interact with winding rules on the

    [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'
    ... But we need to define this as part of the stroking

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

    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

    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

    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

    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.

    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

    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

    <heycam> ScribeNick: heycam





      [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

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

    <scribe> ACTION: Cameron to edit SVG2 to add HTML's style
    element attributes to SVG's style element [recorded in

    <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

    <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

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

    <scribe> ACTION: Cameron to add async/defer to SVG script
    element [recorded in

    <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

    <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

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

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
    [NEW] ACTION: Cameron to add async/defer to SVG script element
    [recorded in
    [NEW] ACTION: Cameron to add the stroke/fill/marker hit testing
    proposal to the SVG2 spec [recorded in
    [NEW] ACTION: Cameron to define scripting model for SVG2 to be
    compatible with HTML5 [recorded in
    [NEW] ACTION: Cameron to edit SVG2 to add HTML's style element
    attributes to SVG's style element [recorded in
    [NEW] ACTION: Cameron to edit SVG2 to add onhashchange and
    other appropriate HTML document wide events [recorded in
    [NEW] ACTION: Cameron to edit SVG2 to make presentation
    attribute values case insensitive [recorded in
    [NEW] ACTION: Cameron to migrate SVG2's baseline-related
    properties to use those defined in css3-linebox [recorded in
    [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
    [NEW] ACTION: Tab to bring up SVG elements in HTML namespace in
    WHATWG [recorded in

    [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/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Emonds/Emmons/
Succeeded: s/tav/tab/
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: + 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


      [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:
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:47 UTC