minutes, 11 April 2013 SVG WG telcon

Minutes for the 11 April 2013 SVG WG telcon are below.

http://www.w3.org/2013/04/11-svg-minutes.html


    [1]W3C

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

                                - DRAFT -

                     SVG Working Group Teleconference

11 Apr 2013

    [2]Agenda

       [2] 
http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0056.html

    See also: [3]IRC log

       [3] http://www.w3.org/2013/04/11-svg-irc

Attendees

    Present
           ed, heycam, dirk, brian, rich, nikos, rik

    Regrets
           thomas, cyril

    Chair
           ed

    Scribe
           Cameron

Contents

      * [4]Topics
          1. [5]how to handle Document object
          2. [6]telcon time
          3. [7]SVG Integration
          4. [8]Firefox unprefixing context-fill and context-stroke
          5. [9]backpointing pointer-events:boundingBox from SVG
             1.2T to SVG 2
          6. [10]SVG Integration
      * [11]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 11 April 2013

    <heycam> Scribe: Cameron

    <heycam> ScribeNick: heycam

how to handle Document object

    <ed>
    [12]http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJu
    n/0015.html

      [12] 
http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0015.html

    richardschwerdtfeger: it appears that Gecko really has a full
    Document object

    … they have a reduced one for SVGDocument but that has
    activeElement in it

    … their version of Document has activeElement

    … but the W3C standard does not

    … what's the right answer for SVG?

    heycam: when you say the spec doesn't have activeElement which
    are you talking about?

    richardschwerdtfeger: DOM4

    … we sent a note to Anne, and he suggested using the HTML5
    Document

    heycam: the HTML5 Document interface augments the DOM one

    richardschwerdtfeger: so HTML should define what activeElement
    means for all documents?

    heycam: yes

    krit: the HTML5 editors said that we should define the
    behaviour for SVG

    … which I don't agree with

    richardschwerdtfeger: when we have SVG as a standalone
    document, do we still want to use the HTML5 Document object?

    … and still address activeElement etc.?

    krit: yes

    birtles: what about for standalone SVG viewers?

    heycam: it's a good question

    birtles: boris had two proposals

    … one was to have SVG say for these implementations that they
    just implement activeElement from HTML

    … the other was to move activeElement to DOM4

    richardschwerdtfeger: Anne wasn't in favour of moving
    activeElement
    ... I'll work on it

telcon time

    <ed> [13]http://doodle.com/wsru9ykt2u8nqbin

      [13] http://doodle.com/wsru9ykt2u8nqbin

    ed: Chris wasn't super happy with any of these times, and I
    think Cyril didn't like the late times

    … but if you look at everyone reponding here, the time that
    best fits everyone is Thursday 11pm in GMT+1

    … the second column

    ed: another option is to split the telcon in two

    … have two separate times every other week

    <shepazu> (I will abide by any times)

    heycam: would it do the same topics?

    krit: I don't think that's helpful

    birtles: another possibility is half an hour earlier

    … 10:30pm in Europe

    heycam: so that would be 6:30am for me/Nikos, 5:30am for brian?
    ... I could do that

    ed: fine for me too

    birtles: it might help, would have to ask them

    <richardschwerdtfeger> got to drop. I will look at the minutes

    heycam: how about we leave it at this current time, which is
    the one selected in the Doodle poll, and during the week ask
    Chris/Tav/Cyril to see if 30 mins earlier would help

    <scribe> ACTION: Cameron to mail public-svg-wg with 30 min
    earlier telcon proposal [recorded in
    [14]http://www.w3.org/2013/04/11-svg-minutes.html#action01]

    <trackbot> Created ACTION-3485 - Mail public-svg-wg with 30 min
    earlier telcon proposal [on Cameron McCormack - due
    2013-04-18].

SVG Integration

Firefox unprefixing context-fill and context-stroke

    <nikos> scribenick: nikos

    heycam: as part of the SVG in OpenType work
    ... we originally had different names for these values
    ... there was something like moz-object-fill and
    moz-object-stroke. We discussed in Switzerland and decided to
    go with ContextFill and ContextStroke
    ... As part of the renaming work, Edwin is wondering if we can
    drop the prefixes
    ... are people happy that the functionality of these won't
    change?
    ... Currently they don't have an effect on other elements -
    e.g. markers

    krit: can we have more time to review?

    heycam: that's fine. The other alternative is to keep those
    values behind a pref - there is already a pref for the font
    support, we could place them behind that.
    ... to avoid the problem

    krit: Is it specified in SVG 2 or in the OT spec?

    heycam: In SVG 2.

    krit: I'm not sure if it is part of SVG 2
    ... if you can use it in other places then maybe

    <heycam>
    [15]https://svgwg.org/svg2-draft/painting.html#SpecifyingPaint

      [15] https://svgwg.org/svg2-draft/painting.html#SpecifyingPaint

    heycam: there was an SVG requirement talked about before the
    font stuff

    nikos: They'll be useful for use as well

    krit: is it supported in FireFox already?

    heycam: no
    ... The plan is for them to also apply to marker

    krit: I'm fine with it

    Resolution: SVG working group don't want ContextFill and
    ContextStroke unprefixed in Mozilla yet, but behind a pref is
    ok.

    <heycam> Scribe: Cameron

    <heycam> ScribeNick: heycam

backpointing pointer-events:boundingBox from SVG 1.2T to SVG 2

    ed: do we want this functionality in SVG 2?

    … just adding this keyword

    ed: the feature itself allows to more easily get pointer events
    on text

    … but also for other shapes

    ack

    krit: what's the difference for text?

    ed: I recently saw an example where someone had a <text> that
    contained lots of tspans, and the bbox of all those parts be
    clickable

    … to avoid computing the rect that covers the whole thing

    … and if the text changes, you have to recompute

    … so this is telling the UA to automatically generate that
    clickable region from the bbox

    krit: I think you've already got this behaviour with WebKit and
    Blink?

    shepazu: there's a couple of different scenarios

    … if the text is really large, and you want to click through
    the circle in the middle of the O

    … so there's the glyph cell

    … and then what if you have a really big line height

    … do you want the space between the lines to respond to pointer
    events?

    … those are two scenarios where you might want to control this

    … there's already behaviour for making it not hittable,
    pointer-events:none

    … there should be a way of getting these two different things

    … (a) are the hole in the glyphs hit tested?

    … (b) also with the line height

    … I don't think we should do any of this in SVG 2, we should
    push this forward as a CSS module

    … it was removed from CSS UI 3, deferred to 4

    … UI 3 hasn't had much progress

    … I propose we find someone to do a hit testing for the web
    spec in CSS

    … I have some notes on that

    … and I propose that we do it in that spec, and not in SVG,
    although there might be SVG specific behaviour

    krit: I spoke with Tantek and he says it'll be in CSS UI 4

    shepazu: it was also going to be in 3

    krit: the CSS WG didn't know how to solve some of the problems
    with it applying to HTML content

    shepazu: so I'm proposing we defer this to some CSS spec

    krit: I agree with that

    shepazu: I think we should make this use case clear to the CSS
    WG so they can specify it similarly

    ed: not just similarly, but with the exact same keywords

    shepazu: I respect that

    krit: we can special case anything

    … but we should specify things in a general manner

    heycam: I'm wondering whether this new value should be dash
    separated rather than camel case

    ed: making this use case clear to CSS WG would be good

    <scribe> ACTION: Erik to talk to CSS WG about the use cases for
    pointer-events in SVG [recorded in
    [16]http://www.w3.org/2013/04/11-svg-minutes.html#action02]

    <trackbot> Created ACTION-3486 - Talk to CSS WG about the use
    cases for pointer-events in SVG [on Erik Dahlström - due
    2013-04-18].

    ed: does this spec exist yet? CSS UI 4?

    krit: no, just talked about

SVG Integration

    heycam: I moved the spec here
    [17]https://svgwg.org/specs/integration/

      [17] https://svgwg.org/specs/integration/

    <birtles> (see element table:
    [18]https://svgwg.org/specs/integration/#svg-elements)

      [18] https://svgwg.org/specs/integration/#svg-elements)

    shepazu: it looks tidier, but it requires JS to interact/read
    the table

    … we could have three different tables, one for each spec

    … or maybe different subrows

    … like you have with "For SVG 1.1", "For SVG 1.2T", ...

    shepazu: you could, on top of that, have a script that hides
    and shows this presentation

    … so why do we have this table in the first place?

    … it's sort of a master table

    … the motivation was that, at the time, Hixie wanted to white
    list certain SVG elements for the parser

    … has that motivation gone by the wayside?

    heycam: it might well have

    … we did discuss not coming up new camelcase names from now on

    shepazu: the Integration spec was intended for any other specs
    that reference SVG

    … one of the motivations for making the spec in the first
    place, was I was on the ODF TC

    … and there was a real sense at the time, that they'd be moving
    on to ODF.next any day now, and they wanted to fix the way they
    used SVG

    … but ODF has lost steam, and I'm not convinced at this point
    that there's going to come along a similar thing that wants to
    reference SVG like that

    … HTML has re-taken over, and I'm trying to think of other
    specs that want to reference SVG

    … another one at the time was Widgets

    … that spec wanted to reference SVG for icons, but not enable
    JS

    … and I can see wanting to have a set of features that might be
    considered part of those individual referencing modes

    … when thinking about the table, think about which of these
    features are enabled in which referencing mode

    … if people are trying to make SVG just for Inkscape, static,
    or maybe static and animated but not with JS ...

    … or if people are making a Filter that they upload to a
    website, should certain elements be restricted ...

    … SVG Integration could be useful for defining these things

    … that could make the use of SVG consistent

    … across different applications

    heycam: I think the spec needs to still exist

    … I want to reference it from the SVG OpenType Fonts stuff

    ed: I think it make sense to have a list of static elements, or
    elements that can reference things

    … not sure how easy it would be to generate these tables

    shepazu: if we decide upon a list of these things, we could
    simply have a <span class> or <a class>, and those classes
    could be colour coded

    … to identify which things are allowed in which referencing
    mode

    … as a way to not balloon out the table

    … but we could also have the referencing mode sections list the
    allowed elements/attributes too

    shepazu: we should go through the referencing modes to see if
    they're still accurate

    … implementations do allow animations even though the "in
    <img>" referencing mode doesn't allow it

    birtles: for the use case we talked about on public-fx, an SVG
    avatar

    … so you're including an SVG image from a third party site

    … is it enough to say in that context that you can't use these
    elements and you can't have interactivity?

    … you'd still need to do some content filtering

    krit: I think this should be specified, it should not rely on
    the server filtering these things

    … the browser implementations should enforce the modes

    shepazu: there might be some things that are easier and some
    harder

    … enforcing reasonable coordinate spaces is a harder one

    birtles: if the content uses some feature in a way that makes
    the browser run slowly, is that something that should be
    specced?

    shepazu: maybe it uses a whole bunch of clip paths for example

    … I don't know if it's the kind of thing we should specify

    scribe: I think at least for V1 we should worry just about the
    security problems

    birtles: it's almost a security problem; someone can post a
    message to your forum with an avatar that has <path>s with
    ridiculous values, and suddenly people can't read your page any
    more

    shepazu: I'm going to take a stab at revising Integration to
    address the things we talked about

    … and put in a section about element/attributes restrictions in
    different modes

    shepazu: what if there were an attribute that could restrict
    these features? refmode='secure animated'?

    heycam: sounds similar to iframe sandbox

    ed: I think WICD had something like that too

    … I think Opera implemented that at one point, but don't think
    it took off

    <ed> s/it took off/the params part (for controlling
    interactivity/scripting etc) was much used/

    <glenn> heycam: ping?

Summary of Action Items

    [NEW] ACTION: Cameron to mail public-svg-wg with 30 min earlier
    telcon proposal [recorded in
    [19]http://www.w3.org/2013/04/11-svg-minutes.html#action01]
    [NEW] ACTION: Erik to talk to CSS WG about the use cases for
    pointer-events in SVG [recorded in
    [20]http://www.w3.org/2013/04/11-svg-minutes.html#action02]

    [End of minutes]
      __________________________________________________________

Received on Thursday, 11 April 2013 22:14:10 UTC