Re: Minutes: March 7, 2013 SVG Working Group meeting

On Thu, 07 Mar 2013 23:35:34 +0100, Richard Schwerdtfeger  
<> wrote:

> Rich Schwerdtfeger

The same minutes in text format for tracker:



                                - DRAFT -

                     SVG Working Group Teleconference

07 Mar 2013



    See also: [3]IRC log



           Rich, [IPcaller], ed, cabanier, hober, smfr, dino, krit,
           +, Tav, +61.2.980.5.aabb, nikos




      * [4]Topics
          1. [5]Transformation Proposal
          2. [6]SVG2 publication status
          3. [7]Pseudo stacking context for 2D transformations
          4. [8]Masking
          5. [9]Filter Effects
          6. [10]Make filter regions unbound
          7. [11]Publication of new WD
          8. [12]Referencing the HTML spec
      * [13]Summary of Action Items

    <trackbot> Date: 07 March 2013

    <richardschwerdtfeger> scribe: Rich

    <richardschwerdtfeger> erik: skip over publication status



Transformation Proposal

    <nikos> Zakim +61.2.9 is me

    <richardschwerdtfeger> krit: at the last face to face we though
    it would be a go change to create a new svg matrix that is
    integral with other specifications so that could be used with



    <richardschwerdtfeger> krit: they thought it was good and to
    evolve over time



    <richardschwerdtfeger> the interface is quite similar to the
    interface proposed by D Jackson

    <richardschwerdtfeger> krit: I made more compatible with SVG
    matrix. It has a 2 dimensional scale. it scales to the x and y

    <richardschwerdtfeger> krit: there is one more change. for svg
    matrix for 2d compatibility

    <richardschwerdtfeger> krit: just 2d instead of 3d

    <dino> the change was rotate() to be compatible with SVG, so is
    only 2d

    <dino> but 3d is covered by rotateAxisAngle

    <richardschwerdtfeger> smfr: maybe you should take vector x, y,

    <richardschwerdtfeger> krit: just the x and y

    <richardschwerdtfeger> thanks

    <richardschwerdtfeger> smfr/we did not have skew z

    <dino> smfr: suggest renaming to rotate(double angle, optional
    double originX, ...)

    <dino> smfr: the fact that x,y is origin should be clear, and
    that the x,y,z from rotateAxisAngle is a vector



    <richardschwerdtfeger> smfr: I would like to ask the same
    question as David Baron. Can they take a string and slam into a
    transform attribute

    <richardschwerdtfeger> krit: yes. takes a DOM String and does a
    CSS transform

    <richardschwerdtfeger> Kitt: if you have an element get the
    transform out of it. … the pixel would not be the same.

    <richardschwerdtfeger> smfr: maybe this text needs some
    non-normative examples. The spec. is isolated right now

    <richardschwerdtfeger> krit: the specification can reference

    <richardschwerdtfeger> krit: i happy to put more informative
    text in it

    <richardschwerdtfeger> krit: examples like this one with a
    constructor with dom strings in it and the transforms.

    <richardschwerdtfeger> smfr: when you are inputing a string
    where it the text for the conversion into the matrix

    <richardschwerdtfeger> krit: that is why issue 3 is there

    <richardschwerdtfeger> … I think it is ok to put an example in

    <richardschwerdtfeger> krit: if we keep it I will extend the

    <richardschwerdtfeger> krit: for SVG it might not be a problem
    because SVG 1 is already a recommendation

    <richardschwerdtfeger> erik: if you translate 2020 to 20px



    <richardschwerdtfeger> … trying to learn the voices

    <richardschwerdtfeger> :-)

    <ed> Constructor (DOMString transformList),

    <richardschwerdtfeger> krit: this takes double

    <ed> new Matrix("translate(20,20)") something liek that

    <richardschwerdtfeger> krit: yeah that works. you don't have
    units for the pixel

    <richardschwerdtfeger> krit: one for presentation and one for
    CSS presentation attributes. We can't say we have a relaxed
    syntax for the DOM string as well.

    <richardschwerdtfeger> krit: we have 2 different syntaxes at
    the moment - one relaxed and one strict

    <richardschwerdtfeger> smfr: we can decide what people want?

    <richardschwerdtfeger> krit: I don't see why the CSS wg would
    object to that.

    <richardschwerdtfeger> erik: do we publish this?

    <richardschwerdtfeger> krit: yes

    <richardschwerdtfeger> RESOLUTION: SVG WG wants to publish
    Transformation matrix interface spec as a first public working

    <richardschwerdtfeger> Dean: why don't we ask to publish it as
    a first public working draft?

    <richardschwerdtfeger> thanks

    <richardschwerdtfeger> ACTION: Krit mail the spec. to the
    effects list and have David Barron review. [recorded in

    <trackbot> Created ACTION-3470 - Mail the spec. to the effects
    list and have David Barron review. [on Dirk Schulze - due



SVG2 publication status

    <richardschwerdtfeger> krit: I will reference HTML5 vs. the
    working draft

    <richardschwerdtfeger> erik: put an action on me to make that

    <richardschwerdtfeger> erik: I will contact the appropriate
    people to make it publish

    <richardschwerdtfeger> nikos: Any idea why my changes would not
    result in a notification?

    <ed> ACTION: erik to follow up on getting the SVG2 WD
    published, run linkchecker etc [recorded in

    <trackbot> Created ACTION-3471 - Follow up on getting the SVG2
    WD published, run linkchecker etc [on Erik Dahlström - due

    <richardschwerdtfeger> Rich: Can I touch the spec. since you
    are taking it to public working draft

    <richardschwerdtfeger> krit: can we reference a specific
    version in Mercurial?

    <richardschwerdtfeger> erik: wait until we get this published

    <richardschwerdtfeger> nikos: Once publication has happened, we
    will need to remove highlighting for changes since last WD 1,
    in preparation for editing for WD 2

    <richardschwerdtfeger> erik:

Pseudo stacking context for 2D transformations

    <richardschwerdtfeger> smfr: do not address to day and leave on
    mailing list

    <richardschwerdtfeger> erik: OK


    <richardschwerdtfeger> krit: all masks are clipped at the

    <richardschwerdtfeger> krit: I would like to ask if we could
    skip this binding and use the bounding box. … an unbound mask

    <richardschwerdtfeger> Krit: only place - filters are bound.



    <richardschwerdtfeger> smfr: I don't have any problems with
    masks being unbounded.

    <richardschwerdtfeger> krit: the default value matching is 10%

    <richardschwerdtfeger> erik: ah ok

    <richardschwerdtfeger> smrf: I think this important in HTML
    where you may be masking and the content overflows and you
    don't want the content to get clipped by the mask

    <richardschwerdtfeger> krit: the clipping could effect the

    <richardschwerdtfeger> erik: to me it sounds better to use the
    unbounded one but I guess that is something to look at to see
    how much content is effected

    <richardschwerdtfeger> erik: guess not that much

    <richardschwerdtfeger> krit: how do we get data as to whether
    content is effected in a negative way.

    <richardschwerdtfeger> erik: this does not affect explictly set
    x, y with height.

    <richardschwerdtfeger> krit: yes

    <richardschwerdtfeger> erik: I guess one way to look at it
    would be see what authoring tools output.

    <richardschwerdtfeger> erik: I don't think there is going to be
    much of a problem

    <richardschwerdtfeger> krit: do we want to get to a resolution
    or delay that

    <richardschwerdtfeger> erik: I think it would be fine to have
    the spec. allow it and deal with any concerns at the next draft

    <richardschwerdtfeger> krit: next version should be the last

    <richardschwerdtfeger> erik: do you see any problem along that
    or the other way around

    <richardschwerdtfeger> krit: there is the property called mask
    .. maskclip but this does not apply to the mask element

    <richardschwerdtfeger> erik: I don't have a strong opinion

    <richardschwerdtfeger> erik: any objections to having unbounded

    <richardschwerdtfeger> RESOLUTION: allow unbounded masks and
    see what we get back from last call

    <richardschwerdtfeger> krit: CSS X, y, and height . Is it ok
    that we don't specify them in SVG2 and not in this

    <richardschwerdtfeger> erik: I think that is probably fine

    <richardschwerdtfeger> erik: so at the moment there is nothing
    to reference

Filter Effects

    <richardschwerdtfeger> @support rule for filter effects



    <richardschwerdtfeger> krit: I put this on the mailing list

    <richardschwerdtfeger> erik: Ok so follow up with the
    discussion on the mailing list

Make filter regions unbound

    <richardschwerdtfeger> krit: the only problems as we have some
    filter effects that produce infinite boundaries

    <richardschwerdtfeger> krit: things like lighting filters or
    inputs could be effected

    <richardschwerdtfeger> krit: this filter has a drop shadow

    <richardschwerdtfeger> krit: we still have the 10% margin and
    everything outside gets clipped awayu

    <richardschwerdtfeger> erik: I agree this problem has been up
    for discussion a number of times

    <richardschwerdtfeger> erik: for example feFlood has unbounded
    output, so can just fill the viewport e.g

    <richardschwerdtfeger> krit: there can be problems. I would
    write a proposal where there could be problems and with a
    solution for that. Is it worth it for me to do that or is it
    too difficult to be specified

    <richardschwerdtfeger> erik: we have a sort of unbounded filter
    region already with filterUnits=userSpaceOnUse, requires impls
    to optimize otherwise perf is really bad

    <richardschwerdtfeger> erik: I think it would be much of a
    problem to run a similar filter on this

    <richardschwerdtfeger> krit: can you and I work on that?

    <krit> ACTION: ed and krit to work together on an unbound
    filter proposal [recorded in

    <trackbot> Created ACTION-3472 - And krit to work together on
    an unbound filter proposal [on Erik Dahlström - due

    <krit> ACTION: krit to work together on an unbound filter
    proposal [recorded in

    <trackbot> Created ACTION-3473 - Work together on an unbound
    filter proposal [on Dirk Schulze - due 2013-03-14].

Publication of new WD

    <richardschwerdtfeger> Erik: I don't have any problems with
    publishing a new working draft

    <richardschwerdtfeger> Rich: would like to get tabindex out in
    a public working draft

    <richardschwerdtfeger> rich: never mind

    <richardschwerdtfeger> :-)

    <richardschwerdtfeger> RESOLUTION: publish a new working draft
    of the filter effect spec.

    <richardschwerdtfeger> ACTION: krit create the public working
    draft [recorded in

    <trackbot> Created ACTION-3474 - Create the public working
    draft [on Dirk Schulze - due 2013-03-14].

    <scribe> scribenick: cabanier

Referencing the HTML spec



    richardschwerdtfeger: I started working on tabindex

    … we found a number of interesting points that we need to agree

    <richardschwerdtfeger> 1. Do you agree that the way event
    listeners are registered in SVG and HTML

    <richardschwerdtfeger> should be the

    <richardschwerdtfeger> same? -- both should support
    `element.addEventListener("click", ...)` and

    <richardschwerdtfeger> `element.onclick = ...`. (The latter
    needs some spec work still, but

    <richardschwerdtfeger> implementations all support this.)

    richardschwerdtfeger: this discussion, should we follow the
    same scheme for eventl listener like html

    … how are they registered in svg 1

    <ed> rich, did you see my response here:
    ml (please keep technical discussions on the www-svg list)


    krit: it should not be different

    ed: it should work the same, yes

    … did you see my reply

    … I responded to some of your points

    richardschwerdtfeger: I didn't see that

    <richardschwerdtfeger> 2. There are some inconsistencies
    between the events SVG defines to fire

    <richardschwerdtfeger> > and those in HTML. We need to be
    harmonizing these and

    <richardschwerdtfeger> > should do it for SVG 2.

    … number 2, there are inconsistencies. we have focus out in svg
    2 but HTML has onblur

    … should they be consistent or should there be a mapping

    krit: onfocus is already used. can we have them in parallel or
    should we map them?

    richardschwerdtfeger: not sure.

    ed: it should be possible to map them. they are different event

    <richardschwerdtfeger> This is about SVG not having the focus
    and blur events, right? I think SVG

    <richardschwerdtfeger> should have them. Feel free to add a
    complete list of the inconsistencies

    <richardschwerdtfeger> you found.

    richardschwerdtfeger: since we're sharing the same dom, should
    we have the same events?

    krit: so, if onfocus fires, onblur should fire too

    richardschwerdtfeger: yes.

    … SVG didn't have keyboard focusable events

    krit: blur is for mouse

    richardschwerdtfeger: we do have the anchor

    … what do we want to do for that?

    … should the spec say that they're the same

    ed: they are 2 different events

    … I don't see a problem with allowing both and then mapping
    them so old and new content

    … one might fire after the other

    richardschwerdtfeger: OK

    … so maybe only 1 event listener

    ed: no, you can have listener for both events

    … I'm not sure if they're connected right now but they could be

    richardschwerdtfeger: where would the event stop. would it go
    outside the svg container?

    ed: with an iframe?

    richardschwerdtfeger: we have an svg doc in a html doc. the
    onblur in the svg is not processed. does it go up?

    ed: if the svg is inline, yes, it should

    richardschwerdtfeger: …(?)

    … if we have onfocus out and onblur and nothing captured them,
    only onblur would get out because onfocus is not recognized by
    the parent

    <ed> not sure that's correct

    <ed> events typically bubble regardless of the event type if
    they bubble

    … the next one is: how do the document and window align between
    html and svg

    … what if you have a reader that only supports SVG. how much of
    HTML do we have to implement?

    … Cam, suggested the following text:

    <richardschwerdtfeger> Cam suggested the following intorductory

    <richardschwerdtfeger> >

    <richardschwerdtfeger> > Conforming SVG interpreters are not
    required to implement HTML;

    <richardschwerdtfeger> > however, some specific features of
    HTML are required to be

    <richardschwerdtfeger> > implemented.

    <richardschwerdtfeger> >

    <richardschwerdtfeger> > And then later in the spec:

    <richardschwerdtfeger> >

    <richardschwerdtfeger> > A conforming SVG interpreter that does
    not also implement HTML

    <richardschwerdtfeger> > must implement the following IDL

    <richardschwerdtfeger> >

    <richardschwerdtfeger> > partial interface Document {

    <richardschwerdtfeger> > readonly attribute Element?

    <richardschwerdtfeger> > };

    <richardschwerdtfeger> >

    <richardschwerdtfeger> > The activeElement attribute must have
    the same behavior as

    <richardschwerdtfeger> > described in HTML. [with a link to
    HTML's definition of

    <richardschwerdtfeger> > activeElement]



    <richardschwerdtfeger> Document element Interface:


    <richardschwerdtfeger> DOM Document element Interface:


    <richardschwerdtfeger> HTML5 Document element Interface:


    krit: is it part of the integration spec?

    richardschwerdtfeger: I posted 3 links

    … we would say to add this text for SVG to the document object

    … for SVG standalone, you'd have these properties

    … does that make sense?

    krit: I think I have an action on this

    … we already relying on the document interface of HTML5

    richardschwerdtfeger: so, you're referring to the document
    object of htmk5

    krit: yes. I have an action to add the link

    richardschwerdtfeger: you want this spec:



    richardschwerdtfeger: that's the cr version

    krit: ah. I think I have the wrong one then

    … I'm using the partial interface

    … HTML5 is relying on the definition of DOM (?)

    … this is a problem. We have dom4 now



    richardschwerdtfeger: this is the current spec

    … I need the activeElement to be there

    krit: If we say document is an HTMLDocument

    richardschwerdtfeger: we have other things in here

    <richardschwerdtfeger> partial interface Document {

    <richardschwerdtfeger> readonly attribute DOMString title;

    <richardschwerdtfeger> readonly attribute DOMString referrer;

    <richardschwerdtfeger> readonly attribute DOMString domain;

    <richardschwerdtfeger> readonly attribute SVGSVGElement

    <richardschwerdtfeger> };

    … this is what we currently have

    … and we want to add activeElement

    … and it's not in DOM4

    krit: is it in html5?



    who is editing dom4?

    richardschwerdtfeger: I don't know

    krit: could you follow up?

    <krit> s/up/up with Anne van Kesteren/ ?



    krit: can you follow up with Anne and other?

    … ms2ger is also good

    richardschwerdtfeger: for publishing, you might want to add the
    right link

    … here it is:

    <richardschwerdtfeger> [37]


    … do we need title, referrer, domain in dom 4?

    <scribe> ACTION: richardschwerdtfeger to ask HTML WG and Anne
    to add activeElement to their spec [recorded in

    <trackbot> Error finding 'richardschwerdtfeger'. You can review
    and register nicknames at


    <scribe> ACTION: rich to ask HTML WG and Anne to add
    activeElement to their spec [recorded in

    <trackbot> Created ACTION-3475 - Ask HTML WG and Anne to add
    activeElement to their spec [on Richard Schwerdtfeger - due

    <richardschwerdtfeger> 4. When HTML refers to tab navigation it
    indicates the elements that can

    <richardschwerdtfeger> receive focus without using tabindex.
    Examples are command, input, and

    <richardschwerdtfeger> anchor elements. Cam and I think this is
    fine if the UA does not implement

    <richardschwerdtfeger> HTML and therefore won't be doing
    anything with <html:input> elements for

    <richardschwerdtfeger> example, then it doesn't matter if they
    are focusable by default or not.

    <richardschwerdtfeger> Yet, in terms of defining that <svg:a>
    is focusable by default, we might

    <richardschwerdtfeger> need to get HTML to change there --
    either by having a hook that we can

    <richardschwerdtfeger> refer to from SVG to state that <svg:a>
    is focusable by default, or just by

    <richardschwerdtfeger> HTML defining it so. Do people agree we
    should define this in HTML?

    richardschwerdtfeger: we might need to html to change their

    ed: svg tiny already does define that elements are focusable

    richardschwerdtfeger: do you want to put that in our spec that
    certain elements are focusable?

    ed: that would make more sense.

    richardschwerdtfeger: are there others that are focusable in

    ed: yes, you could do it on any element.

    richardschwerdtfeger: we were using tabindex

    ed: we can see if it can be made compatible

    richardschwerdtfeger: tabindex of −1 would change the tab order

    … would this change the tab order?

    ed: yes

    richardschwerdtfeger: so it's equivalent to tabindex 0

    … so you think we should say something like that?

    ed: yes

    <richardschwerdtfeger> rich: so focusable is equivalent to
    tabindex="0" in DOM order sequential navigation

    richardschwerdtfeger: do we need to say anything in the HTML
    spec since anchor is alreadu focusable

    ed: I'm unsure. aspects in the model are not defined

    richardschwerdtfeger: yes, that's the browser context

    …. if we need to go to the html wg we can do that

    <richardschwerdtfeger> 5. The HTML5 spec. defines how to
    process browsing contexts. IOW documents

    <richardschwerdtfeger> in a document when it comes to
    sequential navigation. Do people agree we

    <richardschwerdtfeger> can just refer to the HTML5 definition
    of browsing context? This will also

    <richardschwerdtfeger> be important when we embed <iframe>s in
    and SVG document per the face to

    <richardschwerdtfeger> face.

    <richardschwerdtfeger> This was the approach I was going to
    take when adding tabindex.

    richardschwerdtfeger: do people agree that we refer to browsing
    context when we do sequential navigation?

    ed: yes

    krit: yes

    richardschwerdtfeger: ok, we'll refer to HTML5 and go from

Summary of Action Items

    [NEW] ACTION: ed and krit to work together on an unbound filter
    proposal [recorded in
    [NEW] ACTION: erik to follow up on getting the SVG2 WD
    published, run linkchecker etc [recorded in
    [NEW] ACTION: krit create the public working draft [recorded in
    [NEW] ACTION: Krit mail the spec. to the effects list and have
    David Barron review. [recorded in
    [NEW] ACTION: krit to work together on an unbound filter
    proposal [recorded in
    [NEW] ACTION: rich to ask HTML WG and Anne to add activeElement
    to their spec [recorded in
    [NEW] ACTION: richardschwerdtfeger to ask HTML WG and Anne to
    add activeElement to their spec [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [48]scribe.perl version
     1.137 ([49]CVS log)
     $Date: 2013-03-07 22:31:59 $


Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01
Check for newer version at [50]


Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/tip/default/
Succeeded: s/dino/smfr/
Succeeded: s/might/might not/
Succeeded: s| /query smfr||
Succeeded: s/public/publish/
Succeeded: s/the spec/Transformation matrix interface spec/
Succeeded: s/Ken/Dean/
Succeeded: s/SVG/SVG WG/
Succeeded: s/smfr/cameron/
Succeeded: s/cameron/nikos/
Succeeded: s/smfr/nikos/
Succeeded: s/we should highlight the changes since the last working draf
t/Once publication has happened, we will need to remove highlighting for
  changes since last WD 1, in preparation for editing for WD 2/
Succeeded: s/effect/affect explictly set/
Succeeded: s/maskclip/maskclip but this does not apply to the mask eleme
Succeeded: s/reference it/specify them in SVG2 and not /
Succeeded: s/for example just be as big as ever/for example feFlood has
unbounded output, so can just fill the viewport e.g/
Succeeded: s/we have some sort of unbound filter region already/we have
a sort of unbounded filter region already with filterUnits=userSpaceOnUs
e, requires impls to optimize otherwise perf is really bad/
WARNING: Bad s/// command: s/up/up with Anne van Kesteren/ ?
Succeeded: s/yet/yes/
Found Scribe: Rich
Found ScribeNick: cabanier
Default Present: Rich, [IPcaller], ed, cabanier, hober, smfr, dino, krit
, +, Tav, +61.2.980.5.aabb, nikos
Present: Rich [IPcaller] ed cabanier hober smfr dino krit +
aa Tav +61.2.980.5.aabb nikos
Agenda: [51]
Found Date: 07 Mar 2013
Guessing minutes URL: [52]
People with action items: ed erik krit rich richardschwerdtfeger


WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

    End of [53]scribe.perl diagnostic output]


Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog:

Received on Friday, 8 March 2013 10:40:31 UTC