SVG Working Group Teleconference -- 11 Apr 2013

<trackbot> Date: 11 April 2013

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

how to handle Document object

<ed> 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> 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 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> 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 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 https://svgwg.org/specs/integration/

<birtles> (see element table: 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?

- DRAFT -

SVG Working Group Teleconference

11 Apr 2013

Attendees

Contents

how to handle Document object

telcon time

SVG Integration

Firefox unprefixing context-fill and context-stroke

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

SVG Integration

Summary of Action Items

Scribe.perl diagnostic output