W3C home > Mailing lists > Public > www-svg@w3.org > July 2012

Minutes, Seattle/Paris SVG WG F2F Day 3

From: Erik Dahlstrom <ed@opera.com>
Date: Wed, 25 Jul 2012 23:16:02 +0200
To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Message-ID: <op.wh0tc0f0geuyw5@dhcpwifi-22-33.enst.fr>
Same minutes URL as day 2, because rrsagent. Day 3 minutes start about  
halfway in...

Minutes here:



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

                                - DRAFT -

                     SVG Working Group Teleconference

24 Jul 2012



    See also: [3]IRC log

       [3] http://www.w3.org/2012/07/24-svg-irc


           +1.206.675.aaaa, Tav


           birtles, ChrisL, krit, cabanier, heycam, TabAtkins_


      * [4]Topics
          1. [5]Marker proposal review
          2. [6]Revised text layout proposal
          3. [7]white spaces edits in SVG
          4. [8]SVG in Web IDL
          5. [9]Quick question about mask: <funciri> auto
          6. [10]Mapping update
          7. [11]buffered rendering and image flattening
          8. [12]HTML5 drag and drop
          9. [13]SVG 2 section signoff for publication
         10. [14]SVG/HTML integration
         11. [15]SVG DOM improvements
         12. [16]SVGOpen F2F meeting
      * [17]Summary of Action Items

    <trackbot> Date: 24 July 2012

    <Tav> Telephone?

    <birtles> scribenick: birtles

Marker proposal review

    <ChrisL> scribenick: ChrisL


      [18] https://svgwg.org/svg2-draft/painting.html#Markers

    <birtles> CM: I want to go through the marker part of the spec

    <birtles> ... some might need changing

    <birtles> ... I've rewritten that hold section using fewer

    <birtles> .... I've defined different types of markers

    <birtles> ... four kinds: (1) vertex markers

    <birtles> ... you can do this currently

    <birtles> ... (2) segment markers, this is a new one

    <birtles> ... they place markers at the centre of the path

    <birtles> ... (3) repeating markers

    <birtles> ... specify a pattern like a dash to repeat markers
    at fixed distances along the patah

    <ed> scribenick: birtles

    UNKNOWN_SPEAKER: (4) position markers
    ... use markers as a child of a path element
    ... at fixed positions


      [19] https://svgwg.org/svg2-draft/painting.html#MarkerSegmentProperty

    UNKNOWN_SPEAKER: this is (2), similar to marker-mid
    ... but in the middle of the edge

    ED: what happens if you have a zero-length segment


    CM: I think it's defined but I would expect it to paint

    DS: what about a zero-length path?

    CM: I think it won't paint
    ... marker-mids render on zero-length segments right?
    ... so in keeping with that you'd do the same here
    ... and render even for zero-length segments

    DS: what does that mean?
    ... so in order for it to render you have to have at least one
    segment of non zero-length?
    ... so an empty path doesn't render

    CM: right
    ... someone pointed out they'd prefer not to have a
    discontinuity as segments get shorter and shorter
    ... they shouldn't suddenly disappear

    ED: what about only rendering if the segment length is longer
    than some length?

    CM: that's an interesting idea

    DS: could be a property

    CM: apart from that marker segments aren't too complicated
    ... but marker patterns (3) are more interesting


      [20] https://svgwg.org/svg2-draft/painting.html#RepeatingMarkers

    CM: in Hamburg we discussed this
    ... talked about having a feature where you could say "skip to
    the next vertex"
    ... but after thinking about that it didn't seem that useful to
    ... and if you want things on edges and vertices then you can
    use the other properties

    TA: looks good to me

    CM: one thing you may want to do
    ... is stretch out the marker pattern so that it's an even
    number of markers along the path
    ... perhaps the pathLength attribute could affect the distances
    in the marker pattern?
    ... like with dash arrays
    ... so we should get that for free by using pathLength
    ... the lengths you specify in this property would be
    proportions of the pathLength if you specify that property

    DS: what's the big difference between marker and marker-pattern

    CM: the existing markers can only be positioned on the vertices
    ... but this lets you put them by distance along the path

    DS: if I click on one of these markers what happens?

    CM: these ones (1)-(3) are the same, you can't click on them
    ... that don't have a unique ID
    ... so you won't know which one you clicked on
    ... but the positioned markers (4) do allow you to do that


      [21] https://svgwg.org/svg2-draft/painting.html#MarkerElement

    CM: there is an example of positioned markers in the element
    ... at the end of that subsection
    ... below the attribute definitions
    ... you could use this for putting arbitrary patterns on a path
    ... the item marked "the cross" in example 1 in the spec
    ... in this example there are some marker children
    ... and the reason they are positioned markers and not regular
    markers using the referencing scheme discussed yesterday is the
    position attribute
    ... as well as the position attribute I've added an href
    ... since you might want to reference some existing marker
    ... rather than duplicating it
    ... in that example, there's <marker href="#Square" ... />

    DS: why no just use <use>?

    CM: because then how do you know it's a marker?/
    ... I used a calc since we should be allowing calc wherever we
    allow lengths
    ... that is, we should be allowing CSS lengths

    CC: how does this work this the proposal we discussed yesterday
    ... where marker children become regular markers?

    CM: well, a marker could serve both purposes
    ... a child marker could simultaneously by referenced from
    marker-mid, marker-segment
    ... as well as being a positioned marker by having a position
    ... whether it is a positioned attribute or not is dependent
    solely on whether or not it has a position attribute

    RC: so a marker that doesn't have an href, has no refX, refY?

    CM: there is a default value
    ... 0,0
    ... my example there should have a refX
    ... the thing with the positioned markers is that you can put
    event listeners on those markers

    CL: it would be worth calling that out

    CM: yes, I have an issue to do that

    DS: I like it

    CM: re clipping, the problem was we wanted to specify parts of
    the underlying path to knock out
    ... e.g. so it doesn't appear around the edge of the arrow head
    ... so I tried to make it easier to compute a single clipping
    path to apply when rendering the whole path element

    <Tav> [22]http://tavmjong.free.fr/blog/

      [22] http://tavmjong.free.fr/blog/

    TB: I think it would work better if you specify a clipping path
    relative to the marker
    ... I have some examples of that
    ... you define the marker and you define a clipping path
    relative to that

    CM: clipping paths normally specify the part you preserve
    rather than the part you remove

    DS: I'd like to revisit that

    CM: one issue is if you have a bunch of markers that overlap
    ... it would be nice if you could in the implementation, treat
    it as a clipping path you apply before painting
    ... if each clipping path specifies the area you want to remove
    ... the implementation has to compute the inverse of that
    ... which might tricky but probably possible

    DS: do you want the author or implementation to calculate it?
    ... it makes sense for the implementation to do it for simple
    ... but for complex cases it doesn't

    CM: I'm ok with the author specifying the clip path

    CC: Figure 13, with knock out
    ... you have two paths joining
    ... and you specify marker start and end
    ... how many line segments do you have in these examples?

    CM: 1

    DS: these are shapes being cut out
    ... each of these labelled sections is a path
    ... and there's a knockout for those

    CM: to make it easy to calculate intersection of shapes
    ... I limited it to some simple shapes
    ... it makes the computation easier for calculating
    ... so I specified the two halves of the shape you're knocking
    out separately

    CL: can left and right be different?

    CM: yes

    CC: what is the syntax

    CM: it's underneath

    DS: why can't the path in the mask be the clipping-path?

    CL: I think that's common, e.g. the path plus 3px

    CM: I think that's common but also I think these shapes are

    TB: how does this affect the fill on the path

    CM: I haven't quite worked that out yet
    ... but you could either have this knockout the fill or not or
    make it controllable

    DS: can Tav's proposal also solve the problem?

    CM: yes

    CC: it would be nice to have more drawings in the spec about
    how the triangle etc. are drawn

    DS: if I clicked on one of these knockout areas what happens?

    CM: I assume we do the same as clip-path, i.e. it doesn't hit
    the element

    DS: ok, we should make that explicit

    CM: if we allow the author to specify arbitrary paths for the
    area you want to remove
    ... or the area to include from the marker
    ... what you need to end up with is a clipping path as we
    currently have it
    ... that you can apply before painting
    ... if you do that manually you need a big rect to cover the
    ... plus a reverse path for the section you want to remove

    <ed> would be nice to have an example like this: ->>-

    CM: you have to get the clipping path in that form
    ... unless you want to turn it into a mask (which would be
    ... so you need to get the clipping path in that form
    (everything included except some bit)
    ... but you don't want the author to have to specify that
    ... since, for a start, the author doesn't know how big the
    path will be
    ... so you could allow the author to just specify the bit to
    ... or they specify the bit they want to include
    ... and the implementation computes the reverse shape
    ... and I'd rather not require implementations compute the
    reverse shape
    ... to make it easiest for the author you want them to specify
    some part of the shape
    ... but the implementation has to calculate the overall
    clipping path
    ... and that's what I was trying to help with by using these
    predefined shapes
    ... makes it easy for the implementation to do intersection

    DirkS: so you can calculate it rather than asking the graphics

    CM: it's a lot simpler than bezier curves
    ... I'm not sure if this is the best way

    DougS: what if I don't want to specify a knockout shape
    ... would the default be the bbox of the shape?

    CM: bbox would work for some things like arrows
    ... but not for many other things

    DougS: I think for other cases you use the knockout shapes
    ... but having a default be bbox it takes the burden off
    authors from having to specify anything at all
    ... perhaps "auto" = bbox ?

    <Zakim> ChrisL, you wanted to ask about child(n) and to
    consider a keyword that takes the stroke width

    CL: I was wondering if would be useful to have a keyword that
    means the width of the stroke
    ... since I think that would be one of the most common knockout

    CM: that's the most you need to clip out is up to the width of
    the stroke

    DougS: yes, that might be more common than bbox

    CM: if you're clipping out a square that is exactly the height
    of the stroke
    ... you need to be careful that you do actually do cover the
    whole stroke
    ... if you specify the clipping path you have the be careful
    you don't run into precision issues

    DougS: what happens if the stroke comes back again under the
    ... what happens to that new bit of stroke?

    CM: I think unless you want to split up the path into multiple
    ... if you set up a single clipping path before you draw the
    ... you'll have problems
    ... at least, if you the area you're knocking out goes beyond
    the marker shape

    DirkS: paths are 1-D, so you apply the clipping path to the
    whole path

    CM: if you want overlapping behaviour, like the overlapping
    road example, you have to split the path

    DirkS: should the knockout area for a marker on a curved part
    of the stroke also follow the curve?

    CM: good question
    ... I think there are cases where the marker should be
    distorted and cases where it shouldn't (e.g. subway circle)
    ... if the marker is empty and you just want to remove some
    part of the path
    ... then you probably do want the knockout area to be curved

    CC: this knockout property seems to make a different between
    left and right
    ... but so far markers don't make that distinction

    CM: the shape of your marker might not be symmetrical
    ... so you might want to knockout out different shapes on
    different sides when the marker is in the middle of the path

    ED: is the rendering order defined?

    CM: yes, it's defined
    ... marker-start, alternating, segment vertex, marker-patterns,
    children etc.

    TA: why left / right?
    ... start / end?

    CM: sounds good

    <ed> ah, found it...

      [23] https://svgwg.org/svg2-draft/painting.html#MarkerAlgorithm

    CM: when we publish the spec, is it ok to keep this part in?

    All: yes, leave it in

    Break time, 15mins

    <krit> nickScribe: krit

    <krit> scribeNick: krit

Revised text layout proposal

    heycam: Wanted to reduce the amount tha I presented in Hamburg

    <ed> [24]http://people.mozilla.org/~cmccormack/temp/text.pdf

      [24] http://people.mozilla.org/~cmccormack/temp/text.pdf

    heycam: I want to give the proposals and let people say yes or
    ... one: make it easier to integrate text layout
    ... text is chucked on abs. pos. at the moment
    ... each chuck is independent for shaping
    ... each chunk almost a different text element
    ... (has presentation on slides)

    <ChrisL> relevant CSS work - line layout module

      [25] http://dev.w3.org/csswg/css3-linebox/

    heycam: chunking affects how ordering happens, make it more
    difficult to reuse text layout
    ... text elements should be blocks and child elements as spans
    ... chunks won't stop shaping accross elements
    ... absolute pos. happens once you got text layout

    <ChrisL> also writing modes module

      [26] http://dev.w3.org/csswg/css3-writing-modes/

    heycam: SVG allows specifying it by each glyph at the moment

    AS what happens when you have liguaritures

    heycam: there are rules in the spec how to apply chars into a
    ... and how to ignore
    ... We still need to solve the char to glyph mapping before
    applying chunks
    ... evrything should happen across a text element as a whole
    ... what happens if you specify some pos. but other glyphs
    don't have a pos?
    ... I think we should specify that glyphs without pos should be
    relative positioned to previous glyph

    fi n a l exampl

    fi ligurature

    x="100 1550 200"

    fi 100

    n 150

    a 200

    sorry wrong

    fi 100

    n 200

    a = 212

    l = 224

    AS: luguature should break in roman text

    Cyril: I miss the explaination why 150 is not used

    heycam: that is what spec says currecntly, skip it

    <Tav> telephone?

    <ChrisL> we need to allow the flexibility of per-font defaults
    for discretionary ligatures

    <ChrisL> note that this changed recently in css3 fonts


    heycam: I think it might make sense

    ChrisL: don't disallow positioning ligatures

    heycam: what is the default value?

    ChrisL: do what the font says
    ... we agreed not to overwrite it
    ... or switch them of
    ... svg says, if chars have a pos, glyphs shouldn't ligatures

    heycam: if more than one pos, is specified you get behavior
    questional ligatures won't be formed

    ChrisL: should say may not formed, dependent what the font says

    AS: it is up to the font
    ... I would not expect to form ligatures, but think ChrisL is
    right. It depends on the font

    heycam: do the CSS layout first
    ... for the x positions you can not really say how it affects
    the font

    <ChrisL> see

      [27] http://dev.w3.org/csswg/css3-fonts/#font-variant-ligatures-prop

    AS: right, so you can't rely on the ligature forming
    ... We shouldn't let it to the font to decide

    <ChrisL> Initial: normal

    <ChrisL> A value of �normal� implies that the defaults set by
    the font are used.

    ChrisL: we have to see what the font syas
    ... initial value is normal - do what the font says

    heycam: pos should not influence if ligatures should be formed

    ChrisL: AS: agree
    ... It gives you more flexibiity

    heycam: you can't know as an author which chars get a glyph
    ... after positioning anchoring
    ... I won't change how anchoring worsk
    ... the current behavior stays, fi and nal get anchored
    ... at 100 and 200

    ed: end anchoring might be difficult
    ... basically wondering what happens

    heycam: text-anchor is end
    ... you got 2 chunks
    ... first chung single glyph
    ... you should look at all glyphs within a chunk, and look at
    the very right or left chunk (dependent on ltr) and shift it
    from there

    <ed> <text x="100 200" text-anchor="end">ABCDE</text> (and the
    same with BIDI)

    heycam: ltr text
    ... right edge of A would be 100, BCD on its's left Eat 200

    ed: browsers don't do the same think

    heycam: I think the spec is clear about that

    ed: what if text was rtl

    heycam: you would have the left edge of the A at 200
    ... you look at the left edge of all glyphs
    ... A is on the most left
    ... x should give you exactly the anchor position

    Cyril: for my understanding: ltr example
    ... step one apply CSS layout?

    heycam: yes
    ... lets say fi is a ligature
    ... then the described behavior is what UAs are doing
    ... in simple cases it gives you same results
    ... I show more complicated cases

    <text x="300 100">1nab</text>

    heycam: 1. perfm css layout and find glyph pos
    ... n 1 a b
    ... 20,10,20,32

    ChrisL: what you show is the backing store \

    heycam: mark up is visual order

    <ChrisL> alef and bet are the two letters, btw - see

      [28] http://en.wikipedia.org/wiki/Hebrew_alphabet

    heycam: normal position

    n and 1 are hebrew

    heycam: 2. preform CSS layout and find glyph pos
    ... n is at 200
    ... 1 is at 100
    ... a at 110
    ... b at 122
    ... a and b calculated according to pref pos
    ... 1 ab n
    ... old behavior 1ab n
    ... I want to change SVG behvaior

    AS: 1 and n are rtl
    ... ab would be pos to the right of n

    heycam: I think my proposal makes it possible just to look at
    last char in memory

    Cyril: english hebrew english
    ... ——> <—— ------>
    ... english he___brew english
    ... don't want to have second english word pos between hebrew

    krit: I think positioning of glyphs is stupid
    ... we should deprecate it

    heycam: well, it is complicated
    ... at least my proposal is simple to implement
    ... look from left to right, shift all position

    <cabanier> slide deck:

      [29] http://people.mozilla.org/~cmccormack/temp/text.pdf

    heycam: Opera renders the example correctly according to the
    current spec

    krit: can we deprecate it?

    heycam: yes
    ... but we need to specify how the deprecated feature is
    supposed to work

    krit: :P

    heycam: have no strong feeling disabling anchoring all together
    ... propably not important

    ChrisL: you have a backing store of glyphs and order them in
    rendering order
    ... where does text-anchor: none go

    <ChrisL> the slides are confusing the source display and the
    backing store order - slides could be improved for clarity

    heycam: have to check anchoring: none, but I think it is an
    unimportant case
    ... undefined behavior in the spec t the moment:
    ... where should it ogo?
    ... the bottom left of the text path should be relevant for
    positioning text after textpath
    ... we should relax some restictions and allow x,y on textpath
    ... it just translates the content by transforming the space of
    the text path
    ... we should also allow textpath in tspan
    ... summary, di what CSS is doing and apply SVG on top of it

    shepazu: Can we have a resolution to make textPath element as
    top level element (not surrounded by text element)?

    general agreement to do so

    RESOLUTION: textPath must not surrounded by text element

    <ed> [30]https://svgwg.org/svg2-draft/text.html#WhiteSpace

      [30] https://svgwg.org/svg2-draft/text.html#WhiteSpace

    ChrisL: I edited the section about white space handling

    s/RESOLUTION: textPath not needed to be surrounded by text
    element anymore./RESOLUTION: textPath not needed to be
    surrounded by text element anymore.

    Cyril: I think I am fine with the proposal
    ... but am concerned about the complexity of the basic thing
    ... Is it still from the same complexity as before?

    heycam: depends on you implementation of the text rendering
    ... I don't think that you need to implement all the CSS now
    ... it is quite unprecise in some cases anyway

    <ChrisL> it is the linebox and writing-modes and text modules
    of CSS3

    <ChrisL> see [31]http://dev.w3.org/csswg/ for links to those

      [31] http://dev.w3.org/csswg/

    heycam: you don't have to worry about the whole CSS box model.
    And the CSS text layout isn't much greater than it is currently

    krit: CSS is a requirement anyway

    Cyril: I am thinking about the cost to implement it

    ChrisL: It does things for browsers easier, but for sure more
    complicated fot viewers without CSS engine

    heycam: I can put current proposal into the spec and ask if it
    makes sense.
    ... I tried to make it simple
    ... I think it is easy to implement it
    ... I can ask Mozilla people as well

    RESOLUTION: Add Camerons proposal to spec and ask for wider

white spaces edits in SVG

    <ChrisL> [32]https://svgwg.org/svg2-draft/text.html#WhiteSpace

      [32] https://svgwg.org/svg2-draft/text.html#WhiteSpace

    ChrisL: previously whitespace was notgood and complicated
    ... we removed tests from test suite
    ... I kept it in
    ... for legacy
    ... white space handling is using whitespece-property now
    ... added it to the spec
    ... added a third section for old and new whitespaces
    ... and how to do both
    ... I felt it needs to be adressed

    heycam: not hane any XML white space behavior and use property
    to select whitespace behavior
    ... there are still differences
    ... but should be mostly the same, inore differences and switch
    over to white-space: normal and pre
    ... I have implemented it using a UI style sheet rule

    shepazu: we are not talking about word breaking

    heycam: ChrisL: yes we are

    s/word breaking/collapsing/ ?

    ChrisL: I think we want pre-wrap

    heycam: CSS people already splitting out whit space collapsing
    ... If white space is normal I would like to wrap if the width
    attribute is specified on the text element
    ... width attribute is new for text

    TabAtkins_: how far do we want to go? We want to have <p> in
    SVG anyway

    krit: use cases might be different

    ChrisL: that is right


      [33] http://dev.w3.org/csswg/css3-text/#white-space


      [34] http://dev.w3.org/csswg/css3-text/#soft-wrap-opportunity

    ChrisL: it is just using space collapsing
    ... I think we agree that we want to remove things from the XML

    <scribe> ACTION: ChrisL to work out things on removing XML ns
    stuff on text and figure things out with the CSS WG [recorded
    in [35]http://www.w3.org/2012/07/24-svg-minutes.html#action01]

    <trackbot> Created ACTION-3323 - Work out things on removing
    XML ns stuff on text and figure things out with the CSS WG [on
    Chris Lilley - due 2012-07-31].

    <ChrisL> action-3323?

    <trackbot> ACTION-3323 -- Chris Lilley to work out things on
    removing XML ns stuff on text and figure things out with the
    CSS WG -- due 2012-07-31 -- OPEN


      [36] http://www.w3.org/Graphics/SVG/WG/track/actions/3323

    <ed> -- 15 min break --

    <cabanier> scribenick: cabanier

    <ChrisL> scribenick: ChrisL

    <scribe> scribenick: cabanier



SVG in Web IDL

    CM: I propose to redo the SVG idl



    …turn "stylable", "locatable" and "transformable" in actual

    …SVGtransformable is inherited the most

    WebIDL doesn't support multiple inheritance

    …there is nothing too contraversial

    …I do propose to get of the SVG namespace. move away from XML

    …there is only a couple of elements that you can't use the
    properties on

    …if you use xml lang on animate, it's not going to have any

    TA: it negotiates fonts.

    …for different languages

    BB: ElementTimeControl

    will it disappear all together?

    CM: yes

    BB: this is how I test for SMIL support. We might break content
    if we remove interfaces

    … gecko and webkit support it. Opera doesn't

    CM: I can leave it in.

    BB: not sure if there's content that relies on it
    ... I can change my content

    CC: in some case you remove multiple inheritance by merging. In
    others they implement. I don't understand how you made the

    CM: take SVGFitToViewBox. SVGSVGElement needs it and a couple
    of others.

    …SVGSVGElement we want to be able to transform but not

    CC: the solution to multiple inheritance

    DS: why not multiple inheritance?

    CM: because JavaScript doesn't support it

    …there is a difference between 'implements' and 'inherits'

    … implements is a new copy of the function while fill:inherits
    is the same

    … the reason SVGGraphicsElement and SVGDefinitionElement are
    introduced because it's a good place to hang the mixed in
    interface instead of the more specific

    from the spec: "Having these two interfaces gives us a place to
    mix in other common interfaces (like SVGTests) without having
    to do it on each sub-interface."

    … this is how we might reorganize the interfaces

    … Jen, don't you use WebIDL directly

    J: not sure about that

    CM: any questions?

    All: no

    resolution: we will adopt Cameron's proposal for Proposals/IDL
    interface reorganization

    CM: let's move SVGStylable up to the SVGElement

    All: agreed

    BB: so get rid of stylable element?

    all: yes

    BB: that's great

    resolution: we will get rid of SVGStylableElement

    <scribe> ACTION: Cameron to do all this interface stuff
    (Proposals/IDL interface reorganization) [recorded in

    <trackbot> Created ACTION-3324 - Do all this interface stuff
    (Proposals/IDL interface reorganization) [on Cameron McCormack
    - due 2012-07-31].

    CM: can we get rid of externalresourcesrequired?

    all: what's it for?

    BB: it should line up with DOMContentLoaded

    all: yes

    CL: people wanted that if one resource doesn't load, nothing
    should load

    RC: externalresourcesrequired was more granular since it worked
    per group and we especially helpful for fonts

    … but I don't think anyone implements or use it

    DS/ED: we believe that is true

    ED: Opera implements it, but eRR isn't used much

    DS: are there cases where this is useful?

    BB: if that's true, we should do it for HTML as well.

    resolution: remove ExternalResourcesRequired from the spec

    CM: That's all for the IDL talk

    BB does a demo of an animation application written in SVG

    BB: having viewbox as a property would be very helpful in
    conjunction with media queries

    CM: is viewbox the CSS name?

    css syntax:

    svg { viewbox: 0 0 240px 240px; }

    <ed> ick, why the units?

    <ChrisL> because CSS

    CM: does it make sense to non-svg?

    DS: such as iframe

    <ChrisL> can the units be optional?

    TA: yes, just iframe establishes a viewport

    <ed> if we allow units, then we should allow units in the
    viewbox attribute too, but sure, that follows from making it a
    presentation attribute I guess...

    <heycam> ed, agreed

    fixed CSS syntax: svg { view-box: 0 0 240px 240px; }

    <ed> calc too?

    <heycam> of course

    <ed> people are probably already writing "viewbox" in
    html-with-inline-svg, and "viewBox" in svg... and then

    Doug: this seems to be a very nice feature in combination with
    auto scaling

    …there is a question with auto

    … what happens when things move around? content will start

    DirkS: then you should absolute coordinates

    …should we apply to HTML as well?

    TA: HTML and iframe create a viewbox

    resolution: convert viewbox to a property and give it an 'auto'

    <scribe> ACTION: Tab Atkins to take HTML and Iframe view-box
    property to the CSS working group [recorded in

    <trackbot> Created ACTION-3325 - Atkins to take HTML and Iframe
    view-box property to the CSS working group [on Tab Atkins Jr. -
    due 2012-07-31].

    <scribe> ACTION: brian birtles to write up a proposal for
    view-box property for SVG [recorded in

    <trackbot> Created ACTION-3326 - Birtles to write up a proposal
    for view-box property for SVG [on Brian Birtles - due

Quick question about mask: <funciri> auto

    BB: in the case you have a mask property, let the mask decide
    what it is: luminance or alpha

    <birtles> current syntax proposal: [ <funciri> | child |
    element(<compound-selector>) | none ] [ luminance | alpha |
    auto ]?

    … auto means do what the mask says

    … but if you point it to an image, what should it be?

    <ChrisL> you need to be able to choose either

    RC: it seems that you should get luminance

    DirkS: I think it should be alpha

    CL: people that want alpha point to a grayscale. I have a
    feeling that it should be alpha

    <ChrisL> alpha alpha alpha, ra ra ra

    resolution: alpha is chosen when selection 'auto' is set and
    mask is pointed to an image
    ... the property alpha/luminosity wins when pointing to a mask

    <krit> <!DOCTYPE html>

    <krit> <html lang="en">

    <krit> <head>

    <krit> </head>

    <krit> <body>

    <krit> <svg>

    <krit> <rect width="100%" height="100%" fill="green"/>

    <krit> </svg>

    <krit> </body>

    <krit> </html>

    <krit> [42]http://jsfiddle.net/FcQVn/

      [42] http://jsfiddle.net/FcQVn/

    <krit> [43]http://jsfiddle.net/FcQVn/

      [43] http://jsfiddle.net/FcQVn/

    <krit> [44]http://jsfiddle.net/WFCZz/

      [44] http://jsfiddle.net/WFCZz/

    <krit> [45]http://jsfiddle.net/WFCZz/

      [45] http://jsfiddle.net/WFCZz/

    <krit> [46]http://jsfiddle.net/j9zJw/

      [46] http://jsfiddle.net/j9zJw/

    <krit> [47]http://jsfiddle.net/Mym5r/

      [47] http://jsfiddle.net/Mym5r/

    <krit> [48]http://jsfiddle.net/FcQVn/1/

      [48] http://jsfiddle.net/FcQVn/1/

    <krit> [49]http://jsfiddle.net/WFCZz/1/

      [49] http://jsfiddle.net/WFCZz/1/

    <krit> [50]http://jsfiddle.net/j9zJw/1/

      [50] http://jsfiddle.net/j9zJw/1/

    <krit> [51]http://jsfiddle.net/Mym5r/1/

      [51] http://jsfiddle.net/Mym5r/1/

    <heycam> shepazu,

      [52] http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org


      [53] http://en.wikipedia.org/wiki/Magic_Roundabout_%28Swindon%29

    <ChrisL> action chris to rewrite the SVG2 Concepts chapter to
    make more sense in 2012

    <trackbot> Created ACTION-3327 - Rewrite the SVG2 Concepts
    chapter to make more sense in 2012 [on Chris Lilley - due

    <ed> going for coffee now, back in 15min

    <heycam> trackbot, start telcon

    <trackbot> Meeting: SVG Working Group Teleconference

    <trackbot> Date: 25 July 2012

    <heycam> Chair: Cameron

    <heycam> ScribeNick: heycam

Mapping update

    <birtles> [54]http://www.slideshare.net/brianskold/web-maps

      [54] http://www.slideshare.net/brianskold/web-maps

    BB: I want to give a little update with where we're at with

    … I spoke to Takagi-san from KDDI last month

    … I want to summarise some of the materials he sent me

    … some of it we looked at in Sydney in January

    … some of it is new

    … I also spoke to some folks at Mozilla last week, and we have
    some thoughts about what we think the next steps are

    … he suggests that maps are as fundmanetal to the web as video,
    just another data type

    … he expects that that usage will grow, especially with mobile

    … and also the fact that Apple is entering the maps space

    … suggesting it's an important area

    … that said, it's already possible to do maps on the web, there
    are mapping services already

    … why do we need to do anything more?

    … Takagi-san's concern is current systems are closed, and
    you're at the mercy of the mapping service to do local storage
    of map data, ad hoc sharing, mashing up data with other

    … wrt offline access, that seems to be particularly important
    in the wake of the disasters in Japan last year, where internet
    access was unreliable during relief work

    … there was a recommendation from ITU-T that SVG mapping be
    pursued as a possible technology to assist in disaster relief
    situations, especially for the offline access but also ad-hoc
    sharing, taking map data from one source

    … for example the base data comes from OSM and extra regional
    data, relief centres for example, that you would overlay

    … also Takagi-san argues that the web should be decentralised,
    and current mapping services are very much run by one server

    … there's not really a facility for sharing data

    … if the processing is done more on the client side, the user
    is in more control

    CC: for offline usage you need navigation logic to be stored
    locally, right?

    BB: yes

    … it's not that offline access is completely impossible, I
    think Google Maps offline is available

    NA: there's Off Maps on the iPhone

    BB: but you're at the mercy of the mapping service

    … if there was client side technology, there would be
    guarantees that you could cache that data

    CL: that ties in with the approach with the Linked Open Data
    people, instead of everyone uses my mapping service, everyone
    publishes data and can use them together

    BB: it's not entirely impossible with current services, with
    Google maps you can take KML files from different sources

    … but you are at the mercy of the service as to what services
    are available

    … what would be needed to achieve the model that Takagi-san is

    … the main piece of it is the Tiling and Layering feature

    … I want to go into that a littble bit


      [55] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping

    … we looked at this in January, basically you have container
    files that reference other SVG filtes


    … and you can cascade those container files

    [example shown using <animation> elements, and

    … in SVG, the <image> element is static, it's basically just
    converted into four channel image data

    … <animation> from 1.2T allows dynamic content

    … that's why he used that here, but he's open to using some
    different element

    … the other main piece is the <globalCoordinateSystem>, and we
    talked about that a lot in January

    … that's a mapping from the coordinate system of the tile's SVG
    file to a global coordinate space, and then you have the same
    element in the container file so that you can transform into
    the coordinate space of the container file

    Dirk: it's a 2D coordinate system?

    BB: I think it's a standard cartographic coordinate system

    … the x/y/width/height on the <animation> indicates which tiles
    you need to load, and it also does clipping

    … the other feature of T&L is layering, where you put the
    pieces on top of each other

    … not sure how that bit works

    … there's also the min/max zoom thing, which tells you at which
    points to show and hide any element, but typically applied to a

    … that's the basic features of the Tiling & Layering spec

    … it has lots of applications beyond maps, Takagi-san had a
    list of them


      [56] http://www.w3.org/Graphics/SVG/WG/wiki/Use-cases_of_SVGTL

    … on that page are a list of places you could use T&L

    … that's the main piece of what Takagi-san is proposing

    … some other pieces we discussed last time, non-scaling-stroke
    which I think is implemented widely now

    … shared paths is something which we agreed was good but
    there's no commitment from anyone to write that up for SVG2

    … that's especially useful for borders between countries, where
    you want the same line to be shared between different shapes,
    and stroked just once

    … fixed size objects, we talked about reintroducing
    transform-ref from 1.2T, but that seems to be at risk too

    … non-linear transformations we've rejected

    … UI features, we knocked back built-in map controls

    … we also rejected the idea of programming-less geolocation,
    e.g. centre the map on my location

    … I am not sure what we have decided on SVG views with
    geographic coords, but there's no commitment to have that in

    … API features for smooth transitions of zooming/panning, but I
    think we didn't understand what that was about

    … if we do support global coordinate systems, then it makes
    sense to have an API for that

    … but that's assuming we have the <globalCoordinateSystem>

    … finally, if we were to introduce some sort of <tile> element
    then it needs to have contentDocument, contentWindow for
    accessing the contents

    … I want to present a summary of the discussions I had with
    Mozilla folks last week

    … basically, one of the things we discussed was that map UIs
    are very complicated, for example they can do all sorts of
    things like if the label is close to the edge of the viewport,
    you shift it so that it's readable

    … Google Maps has integration with WebGL

    … so it seems hard to imagine you could standardised a set of
    map features that would be competitive with existing map

    … you obviously can't get UAs to implement all the features of
    Google Maps

    … so we thought it would be better to agree on a standard
    markup for maps, and then have at least one open source app
    that consumes that data

    … so it's still client side, and the user is in control, but
    without requiring UAs to implement the mapping features

    … in response to that, Takagi-san agrees that complex mapping
    services should still be realised as web apps with JS, but he
    would like to see some sort of minimum subset as a UA native

    … I think his argument is that then you would have some
    guarantees that the map data is independent from the mapping

    … Takagi-san believes there are good reasons for implementing a
    base set of features in UAs

    … he'll be at the next F2F so can explain better at that point

    Dirk: I don't see anything that can't be done with current
    markup that we have

    … we can still provide some microformats, just introduce some
    name conventions

    … at the end you still need an application that knows about all
    these terms

    BB: that's basically the Mozilla position

    … with the exception of the next piece, we think tiling is
    generally useful beyond maps, and are interested in some sort
    of iframe-like element in SVG

    CL: I didn't understand the relationship between those two

    … I didn't understand why you would then use iframe

    BB: the idea would be to add something along the lines of
    <animation> element, which allows embedding SVG, also in
    combination with that having a load on demand facility

    … so that those items wouldn't be loaded when they're not in
    the viewport, or some heuristic like that

    … that's one way you could realise tiling

    Dirk: what about using <use>?

    … if you want to have tiling as well, you could surround it
    with <svg> inline element, because they act as clipping region

    BB: that's worth investigating

    … I think iframe is attractive because it gives some features
    like sandboxing, although that might not be important in this

    … something of that nature anyway

    Dirk: we'll eventually <iframe> in SVG anyway

    CL: one obvious use case is high res imaging, medical or

    … being able to just specify "here's a high res source" and
    have it automatically bring in low res things on demand, is
    useful general functionality

    … with DOM support too, but without needing script for base
    level functionality

    CM: I think one reason for suggesting iframe was to avoid
    introducing a new element that does the just the same thing as
    an existing element

    Doug: we've talked about tiling in two different ways this week

    … there's the tiling as decorative, taking a preexisting
    resource and repeating it in different permutations

    … and there's also tiling as in fetching external resources on
    demand, and not repeating them

    <ChrisL> the first one is the css background tiling

    … we should somehow converge those two if it's useful

    CL: I think it's better to use different terminology, since
    they're mostly different things

    … one is replication of an image

    Doug: one area where they might be related, the superpath where
    you want to join different tiles up

    … a road doesn't end one tile

    … so there is the matching of edges aspect, so that might be
    related on both

    BB: as to the minimum subset that is needed, Takagi-san
    identified two things

    … one is the T&L feature, and the other is zooming & panning

    … (browser native UI to zoom and pan the image)

    CL: in SVG 1 we said that all UAs had to have that feature, and
    the first round of UAs did have that

    … but they all did it differently

    … the second generation of implementations in browsers either
    ignored it completely, or just gave you scroll bars which is
    not ideal

    … and suggested that authors use script to do this

    Doug: as an author, I've run into situations where I did and
    didn't want users to zoom/pan

    … if we're not going to provide UI controls, which I think is a
    shame, we should at least provide a rich API for panning and

    … for example "zoom to a particular rectangle"

    … "zoom centered around a particular point"

    … maybe we could have a zoom to rect, zoom at point API

    … and something for panning as well

    CM: I think that is in line with what we've previously
    resolved, to not have native UI but to make it easy for script
    to implement zoom/pan

    DS: I would like to see browsers implement native zoom and pan

    … maybe they could be turned on or off in preferences

    BB: so today I'm not aiming for particular resolutions, I'm
    just summarising where we're up to

    … in Zurich Takagi-san can present his thoughts and concerns

    … perhaps the most concrete thing that could come out of this
    is to investigate some sort of use/iframe element for this sort
    of thing

    … one thing I realised for <iframe> is that it has has seamless

    Dirk: you have to maybe specify inherit as the property value

    Doug: one problem with iframe is that it has its own coordinate
    system embedded in it

    … that might be a good thing or a bad thing

    … you might want to have a coordinate system in the tile

    … but you probably want it relative to the other tiles

    … we need to write down use cases and requirements for exactly
    what is required for T&L

    BB: right

    Doug: do you really expect to have dozens of iframes how is
    that going to affect performance?

    BB: I don't think there's any particular performance concern

    Doug: what about overlaps?

    BB: I don't know exactly how it works in the proposal
    Takagi-san has put forward, but there are a lot of ways to
    realise that

    Doug: there would be some metadata that says "I am this portion
    of this other document"

    … if you have a raster that you've tiled and you're zooming in
    on an x-aray


    … each segment knows what part of the larger image it is

    … also, are these things injected into the dom automatically,
    and removed?

    … or is it more like a <use> where there's a shadow tree?

    … does each tile actually have an element, or is there
    something weird going on?

    BB: I think all that stuff needs to be worked out

    … you would probably have contentDocument on the DOM node,
    especially if it's an iframe that would be the obvious way to
    approach it

    … wrt the load on demand facility, you might say that when it
    goes out of view the contentDocument becomes null

    Doug: currently if you have a <use> or an <image> which it
    hasn't retrieved it, it doesn't give you an indication that
    there's something missing

    … I think we need something that shows the missing image, maybe
    a pseudo class

    … and then you could style it yourself

    BB: I think we need a concrete proposal for what is required

    … we need to investigate further the load on demand for zoom

    … that would be a step towards the T&L spec, but not
    necessarily committing to do the whole thing

    BB: that's it

    … I think we need a specific proposal for an element like
    animation/iframe that can contain the SVG

    Doug: I'd like to know how it would be like iframe

    … it has a particular DOM interface, features

    CM: I think Mozilla's view is that rather than come up with a
    new element that has substantial overlap with an existing one,
    that we extend the existing one for the new features (like load
    on demand)

    Dirk: we've been discussing this topic for nearly a year now,
    but we still don't have a proposal

    … it doesn't seem like we're making progress

    BB: I guess Mozilla is saying that we're not interested in
    implementing the proposal as it stands, but we're intersted in
    pulling off one of the features of it and implementing that

    … the feature where you can include another SVG or raster image
    and have load on demand control

    Dirk: can't you already do that? <foreignObject><iframe>?

    BB: it's not iframe specifically, it's the load on demand

    … it might be possible with a <use> element, if so great

    … but the automatic loading of subresources based on zoom level
    and viewport is the part we're interested in

    CM: what is the next concrete step?

    BB: someone to come up with a proposal for an element for
    pulling in subresources on demand with zoom level control

    Dirk: should it work with other formats?

    BB: yes, definitely raster images too

    … it needs to do more than SVG, but it can't do less than
    dynamic SVG

    … as opposed to the <image> element

    … but also should allow raster graphics as well

    CC: is it really zoom level control? or bit rate control?

    CL: it's more zoom level control

    CC: I was thinking in terms of bit rate control. does it have
    to be inside SVG, or could we have some indirection level where
    you first get some resource which describes other resources and
    you get one of them?

    … when I was talking about the adaptive streaming that's how it

    … not suggesting to use exactly that, but having that extra
    level of indirection might be useful

    Dirk: how does the dynamic stuff work? so you zoom in and this
    makes the document load?

    … it still sounds very specific

    … I'm just wondering if it's better to write a JS library to do

    BB: I think for say a medical image you would want that to
    happen automatically, browsers could optimise the prefetching

    NA: you can also use that kind of feature for handling small

    Doug: maybe media queries would be good for this

    CM: yes I keep thinking of media queries too

    CC: what about switch?

    Doug: MQ is friendlier than switch, with switch you have to use
    a specific document structure

    BB: MQs don't currently take into account the transforms you
    apply for zooming in, it's just the viewport you render into

    … the T&L spec has this min/max zoom attributes, and that may
    be one way to do it

    Dirk: with MQ you can just put the details or want or not want
    in classes, and then just not display them, for a certain
    viewport size

    BB: when you have the cascading style you need to control
    specific tile loading some levels deep




      [57] http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html#multires

    CL: there's a concrete proposal

    … it did have a fully specced out way of doing this, not saying
    it's a good idea, but it's something to look at

    … Kodak demoed an implementation in Batik at one point

    TA: HTML is doing srcset

    … you specify several urls with an alternate resources giving
    the pixel ratio

    BB: that's only a single level though

    CC: I agree the solution should not be specific to SVG

    CL: see how this multires proposal has minpixelsize and



    … however it's still not great because you've got explicit
    markup, you have to do this slicing yourself

    … take an image, slice it into four, take those and slice it
    into four, inventing a naming scheme for tile files

    CM: I think Takagi-san's proposal requires that too

    BB: but these subresources could also use multiimage, so that
    would support the cascading

    … I think the cascading is an important feature

    Dirk: I still think it's too tied to the markup and it should
    be done in script

    s/cascading/cascading or recursion/

    BB: so I think what's missing is what's needed is someone to
    work on this

    … maybe the thing then is to bring this up in Zurich, I can't
    find the time before then to work on this

    … so we should bring it up when Takagi-san is present

    CL: would be useful to get feebdack from Alex Danilo on the
    problems he found when implementing it for his player

buffered rendering and image flattening

    CC: I have ACTION-2863


      [59] https://www.w3.org/Graphics/SVG/WG/track/actions/2863

    … the action is quite generic, investigate how to improve
    buffered-rendering for SVG2

    … I tried to think about it and look at the requirements so far

    … we have another requirement called "flatten to image"

    … to keep an image as pixels and not as a dom structure

    … if you look at it, buffered-rendering has 3 values: auto,
    static, dynamic

    … dynamic is a hint that the content of the group will change,
    so it's not worth caching it

    … static means it might not change, so it might be worth

    … auto means do whatever you want

    … but it's just a hint

    … I'd like to discuss the possibility to have not a hint, but
    something normative with conformance statements

    … where if you put the value say "static", the browser is
    allowed to keep the object cached without the associated dom

    … thereby reducing the memory required to store the object

    … it does not need to be a pixel representation, it could be a
    vector representation

    … it could be controlled by the rendering hints

    … the idea would be to have something a bit like canvas, where
    you just give JS calls and the result is an object in memory
    that you can reuse

    … in this case you don't use JS calls but you describe it with
    the dom

    … when it's loaded, if it's a clip art for instance you know
    you won't animated it or script it

    … it won't change, so the browser can keep it efficiently in
    its cache

    Dirk: but still vectors?

    CC: I think it should, but we could discuss it

    RC: is that a problem with keeping the dom around?

    … if you still have a vector representation...

    Dirk: you might have dom access during a rendering

    … if we have a dom tree and a render tree, you could even throw
    away some render tree and just keep say the cairo context with
    its path

    CC: why would you not always have an efficient render tree?
    ... marshalling things between the DOM and the render tree is

    Dirk: if nothing changes, you don't need the dom

    CC: the DOM consumes memory right?

    CM: I think that's what cyril is worried about

    BB: if you get rid of the dom, there are things in there that
    describe how to scale for example, and once you set static you
    won't have enough implementation to rerender properly

    ED: I don't think it would be a problem to define this as
    getting a snapshot

    CC: when an html image element points to an svg, are you
    optimising that?

    BB: they can be animated, so we keep the dom around

    … even for things like percentage lengths they'll change if you
    drop the dom

    ED: the question is whether that's acceptable

    BB: I'm dubious

    Dirk: what about hit testing?

    CM: this seems very dependent on how implementations are
    currently written

    Dirk: each render tree object is associated with a dom object

    … in WebKit when you destroy a DOM object the render object is

    CC: what happens when you have a canvas?

    <ed> hit testing should work just fine assuming the UA keeps
    the vector representation around

    … you don't have a dom, but you have a render tree?

    Dirk: for a canvas you always need the dom object

    CC: if you have a group with this property set to static, the
    whole tree could be collapsed to one object

    Dirk: I think that is what Rik was suggesting

    CC: so with SVG you have a big DOM, with JS you have a bunch of
    JS, maybe there's a way in between

    Dirk: we need to specify how hit testing works

    … if WebKIt decides not to implement for example, hit testing
    would still apply

    … wouldn't want the behaviour to be different from
    implementations that do do it

    JY: what's the advantage of html img?

    … if you have a static svg file, browsers could just optimise
    it themselves couldn't they?

    BB: I think percentage lengths is something that's difficult

    … you could have a rectangle that is 300 high, 80% wide

    … the aspect ratio is going to depend on the viewport

    … it's fine to say take a snapshot, but when?

    … if that's in an html document and you reflow, the aspect
    ratio would hcange

    … what you would get depends on when you take the snapshot

    JY: what is the expected behaviour when you set it to static?

    BB: maybe in one browser it happens to snapshot just after a
    font is loaded?

    CC: can't you just resize the object? you have to resize
    individual parts?

    … indeed that's a problem

    RC: I think the buffered-rendering hint works fine, the auto
    thing can detect if something changes

    CC: I think having a hint is useless, it's better not having a

    … if browsers don't use the hint, then authors will use the
    hint in the wrong situation

    … browsers will then have to ignore it anyway

    CM: I agree

    RC: it cannot really know, it can't know what the JS user is
    going to do

    <Cyril> ack


    CC: I agree there are problems, if we go in this direction we'd
    need to specify when the snapshot is taken

    … and how it behaves for picking and so on

    … we could say when the full document is loaded, or when the
    tree is loaded, when DOMContentLoad is generated

    … or if we don't know exactly, we could go for an API

    … call .flattenTree()

    BB: I think you'd need to require a viewBox, so you don't end
    up with inconsistent sizes

    … so you have a fixed aspect ratio

    CC: this is for a subtree

    BB: that wouldn't help then, unless you require a viewBox on
    the top

    CC: when you have flattened the tree, you should be able to
    rescale and keep good quality, but the result shouldn't be that
    you rescale text only horizontally for example

    … the example about percentages or ems, should not be allowed

    Dirk: I think it doesn't really help if the size should always
    be in the same ratio

    … because you would get pixellation if you scale a lot

    BB: but this is a vector snapshot

    CC: I think this would bridge the performance gap between
    canvas and svg

    ED: from our experience, traversing trees is a big cost

    CM: if you are traversing a render tree isn't it that same?

    ED: it's quicker for us to traverse the render tree compared to
    the dom tree

    CC: I just want a single render object with a sequence of
    drawing commands

    CM: this would be a lot of work for us

    Dirk: also for us it wouldn't help with performance much

    CC: I think there is a gain in performance and memory here

    … if you don't have to traverse the dom

    Dirk: we don't traverse the dom



    [some discussion about implementation internals]

    JY: big files coming from inkscape or illustrator, you can just
    reference that with an <image>

    … then browsers can optimise that themselves

    … or for large things generated by script, if you want you can
    render that to canvas yourself

    NA: we have the flatten to image requirement from the SVG2 list

    … this is not exactly the same as cyril's thing, but maybe that
    approach would be better

    BB: there's drawElement on canvas

    CM: I think relying on the browser's on optimisation for
    <image> elements is fine here

    BB: animations run in HTML <img>

    … in firefox/chrome/safari/opera

    … but I think the <image> element in SVG is static

    ED: in opera we support animated png in SVG <image>

    … so why forbid svg animations in there

    CM: what about buffered-rendering?

    ED: that's already in the spec

    … but I think this action was about exploring other things

    … I think it's still useful, for some devices

    CC: in an interoperable way?

    ED: whether it's there or not doesn't make a difference

    BB: firefox allows animations in SVG <image>

    Doug: let's just change the spec

    <ed> s/for rendering it doesn't matter if BR is specified or
    not, it should produce an identical rendering result/

    <ed> s/whether it's there or not doesn't make a difference/for
    rendering it doesn't matter if BR is specified or not, it
    should produce an identical rendering result/

    RESOLUTION: SVG <image> will allow declarative or frame-based
    animated images

    <shepazu> s/SVG <image> will allow declarative or frame-based
    animated images/SVG <image> will allow declarative or
    frame-based animated images, but not scripted animations/

    RESOLUTION: SVG2 won't have a flatten to image feature

HTML5 drag and drop



    ED: this is a proposal to add all of the drag and drop
    attribtues and events to svg

    … currently HTML5 specifies that drag and drop attributes only
    apply to html elements

    … you can have svg inside html, but currently it's not
    specified to do anything for svg elements

    … so this proposal is to add those

    … there's a list here of changes that would be needed to be

    … a list of events that html has, the event attributes like

    … two attributes, one could draggable, one called dropzone

    … to all svg elements

    … then the question is how much would need to be repeated in
    the spec, how much can we depend on html to define this

    … I'd like to hear what people think about this

    CM: I think it would be good to have on SVG

    <krit> what about moving drag and drop to DOM from HTML?

    Doug: there is widespread dislike for html's drag and drop

    CL: if there are better things why aren't they in the spec

    Doug: there's nothing better implemented

    … I agree in general it's better to align with html, but let's
    not fool ourselves that's it's a good solution

    <krit> again, what about moving it to DOM4?

    ED: I have seen lots of people ask how to drag html elements
    into svg

    … things like files from the desktop, too

    … I don't think this helps with the problem of getting mouse
    event coordinates in the right coordinate space

    <ChrisL> OH: steaming pile of bovine manure

    ED: I don't think we should come up with something new SVG


    Doug: should do it in webapps or whereever

    <ed> s/… I don't think this helps with the problem of getting
    mouse event coordinates in the right coordinate space/Doug: I
    don't think this helps with the problem of getting mouse event
    coordinates in the right coordinate space

    Doug: you can't just let things be draggable, you have to use
    script to do it

    … maybe we should contact jquery ui guys and ask them whether
    we should ignore this api for now or come up with something new

    ED: I think though with SVG inline in HTML people would expect
    it to work on SVG elements

    … specifically I've heard people wanting to drag and drop
    images into svg, but also with compound documents dragging
    elements between html and svg and having things draggable and

    CM: may as well just allow it to work on svg elements

    RESOLUTION: SVG elements will support the HTML drag & drop API

    CM: I'd prefer for us to copy as little text defined in HTML as

    <krit> heycam: Did someone even consider moving it to DOM?

    ED: referencing HTML is fine?

    CL: I think so

    krit, I am not sure

    <krit> :(

    ED: I am not sure if it makes sense, especially if it depends
    on markup

    <ChrisL> s/think so/think so, they will likely be at CR by the
    time we get to CR/

    … (moving it to DOM that is)

    <scribe> ACTION: Erik to add the drag & drop functionality to
    SVG2 [recorded in

    <trackbot> Created ACTION-3328 - Add the drag & drop
    functionality to SVG2 [on Erik Dahlström - due 2012-08-01].

SVG 2 section signoff for publication


      [63] https://svgwg.org/svg2-draft/text.html#WhiteSpace

    CM: first thing is the white-space changes Chris has made

    … sounded like everyone was ok with that

    CM: next is

      [64] https://svgwg.org/svg2-draft/text.html#TextElementWidthAttribute


      [65] https://svgwg.org/svg2-draft/text.html#TextOverflowProcessing

    … which Erik has added

    CM: next is painting chapter changes

    … most things after the introduction


      [66] https://svgwg.org/svg2-draft/painting.html


      [67] https://svgwg.org/svg2-draft/painting.html#SpecifyingFillPaint

    … I rewrote that section


      [68] https://svgwg.org/svg2-draft/painting.html#StrokeShape

    … is that new section useful?

    <ChrisL> I made changes to the fonts chapter, but didn't put in
    the class for the changes sorry

    <ChrisL> [69]https://svgwg.org/svg2-draft/fonts.html

      [69] https://svgwg.org/svg2-draft/fonts.html

    ED: I think it's useful

    CL: I changed the introduction to the Fonts chapter to talk
    about woff, remove css2 references

    … and moved around the order of the chapter

    … i put the svg fonts at the end

    … so the first thing is @font-face

    … I haven't yet trimmed down the section on fonts so it just
    describes tine fonts


    … but there's a purple box to say we'll do that

    CM: are we keeping the <font-face> elements?

    CL: we could discuss that

    … I would fine with removing it

    … and I think we should be encouraging @font-face

    … they're equivalent

    … not sure if all implementations do both, though

    JY: we don't do the <font-face> elements, but we do do

    CM: maybe we can drop top-level <font-face>, but keep it as a
    child for <font> for implementations that do SVG Fonts

    RESOLUTION: SVG2 will drop support for top-level <font-face> in
    favour of @font-face, but keep <font-face> child of <font> for
    SVG Fonts

    <scribe> ACTION: Chris to remove support for top-level
    <font-face> for external font referencing support [recorded in

    <trackbot> Created ACTION-3329 - Remove support for top-level
    <font-face> for external font referencing support [on Chris
    Lilley - due 2012-08-01].

    Doug: we haven't discussed: html has <!DOCTYPE> as a switch

    CM: rewritten section in color chapter


      [71] https://svgwg.org/svg2-draft/color.html


      [72] https://svgwg.org/svg2-draft/color.html#ColorProperty

    CM: that's to remove the definition of color in SVG

    … is it too much removed?

    CL: for white-space I still included the blue property
    definition table, but pointed to the other spec for the
    definitions of the values

    … the property table is fairly concise

    … also our table has whether the property is animatable, which
    the css one doesn't

    … so I'm tending to say to include the property definition

    <scribe> ACTION: Cameron to add back property definition tables
    [recorded in

    <trackbot> Created ACTION-3331 - Add back property definition
    tables [on Cameron McCormack - due 2012-08-01].


      [74] https://svgwg.org/svg2-draft/pservers.html#MeshGradients

    CM: Tav's gradient mesh work



    CM: Brian's maskType attribute addition

    BB: I haven't marked it yellow yet

    … I reworked parts of the introduction as well

    … but I'm yet to add things about referencing mask elements

    CM: but ok to publish?

    BB: yes

    CL: Tuesday 21st August for publication?

    CM: sounds ok


      [76] https://svgwg.org/svg2-draft/filters.html

    CL: what about compositing?


      [77] http://www.w3.org/TR/SVG11/render.html#ParentCompositing

    … we need to review chapter 14 whether we can remove things in
    favour of the compositing chapter

    … we need a resolution to publish compositing

    RESOLUTION: SVG WG agrees with publishing the Compositing spec

    <scribe> ACTION: Nikos to add notes to SVG2 referencing
    Compositing, and remove any duplicated text if that can be done
    before publication [recorded in

    <trackbot> Created ACTION-3332 - Add notes to SVG2 referencing
    Compositing, and remove any duplicated text if that can be done
    before publication [on Nikos Andronikos - due 2012-08-01].




      [80] https://svgwg.org/svg2-draft/script.html

    CM: I removed contentScriptType and contentStyleType


      [81] https://svgwg.org/svg2-draft/animate.html#Introduction

    CL: do we still want to point to web animations instead of SMIL

    BB: I want to drop the whole chapter and reference Web
    Animations specs

    CM: also I removed all mention of DTDs

    RESOLUTION: We will publish SVG2 FPWD mid August

    <scribe> ACTION: Cameron to remove eRR from SVG2 [recorded in

    <trackbot> Created ACTION-3333 - Remove eRR from SVG2 [on
    Cameron McCormack - due 2012-08-01].



    <scribe> ACTION: Cameron to define "default object size" so
    that css3-images <image> works for SVG paints [recorded in

    <trackbot> Created ACTION-3334 - Define "default object size"
    so that css3-images <image> works for SVG paints [on Cameron
    McCormack - due 2012-08-01].


      [85] http://dev.w3.org/csswg/css3-images/#default-object-size


      [86] http://dev.w3.org/csswg/css3-images/#default-object-size

    <trackbot> Sorry... adding notes to ACTION-3344 failed, please
    let sysreq know about it

    <TabAtkins_> heycam, you also need to add <image> to the
    definition of <paint>.


    <krit> heycam: If you need something, ping me at any time

    <scribe> ACTION: Cameron to work out whether to add a new repo
    for all new modules, or a new repo for each [recorded in

    <trackbot> Created ACTION-3335 - Work out whether to add a new
    repo for all new modules, or a new repo for each [on Cameron
    McCormack - due 2012-08-01].

    <krit> heycam: wait

    <krit> 1406@

    <krit> heycam: --^

SVG/HTML integration

    BB: I don't have anything to sa


    … where are we up to?

    … at hamburg we talked about both including HTML elements in
    SVG directly, without having to wrap them in <foreignObject>

    … and we also talked about the opposite direction, including
    SVG elements directly in HTML without wrapping them in <svg>

    … I was just wondering what the next step is there, because I
    think it sounds good

    … is this something we should be pushing for? does it have any
    connection svg2?

    … how can we drive it forward?

    Doug: make an experimental implementation

    … that will help point out flaws

    BB: I agree that sounds good

    <krit> shepazu: in JS? :D

    … just curious if people think that this would never happen

    <krit> heycam: It will happen

    TA: henri is against it

    <krit> heycam: might take till next year :)

    … the svg wg didn't want an explicit list for the parser

    Doug: SVG Integration was meant to have that list

    … we didn't want HTML5 to white list what SVG elements are

    Doug: but i would be happy with whitelisting the svg2 elements
    for now

    TA: there are four conflicting elements

    … style, script, a, font

    <ChrisL> a is changing to a href

    <ChrisL> the other difference is svg a can next

    CL: SVG's <a> can nest, but HTML's doesn't

    CM: I think that is just enforced by the parser

    … the behaviour is still defined though because you can do it
    in teh dom


    Doug: I think it's not a big deal if in text/html you can't
    nest them

    TA: Hixie is against unifying SVG and HTML script, because SVG
    script is sane and HTML is not

    … but Henri argued for unifying

    Doug: innerHTML and document.write aren't allowed in SVG script

    <ChrisL> hooray

    TA: several people are opposed to having chameleon HTML/SVG

    … the final element conflict is <font>

    CM: I would fine with requiring wrapping <svg> around <font> if
    that solves the problem

    TA: I'm still not entirely sure why chameleon namespaces are

    … on a related note, we have two element conflicts with MathML

    … it's in semantic MathML which nobody implements

    … <image> and <set>

    <ChrisL> where 'nobody' means 'no browsers, jst mathematical

    BB: seems like most people are generally in favour of that

    TA: Hixie's largest argument against embedding SVG directly in
    HTML, is that embedding a <rect> into a <p> doesn't gain you

    … that might not be true if you are doing a path to do a star,
    for example

    … and if you are embedding a <g> you may as well embed an <svg>

    <ChrisL> I agree with Hixie there (shock, horror)

    CM: Brian's <mask> children would be good to support too

    Dirk: it's just another thing for authors to learn

    <birtles> Some single elements do give you quite a lot of
    value, e.g. <animate>

    JY: it is a bit strange to have to wrap say <filter>, but for
    rendering things it's not as useful

    Dirk: should these elements have a CSS layout box? I think they
    should, but we don't have anything defined in the spec to
    handle this

    TA: if you have a <path> as a child of a flex box, what does
    that do?
    ... for embedding HTML in SVG I can write that up, that's easy

    … embedding SVG in HTML is more controversial

    … we need to convince hsivonen, dbaron and maybe abarth

    … and have us all agree on what the correct solution for this
    problem is

    … I will work on the proposal for HTML in SVG

    BB: maybe we can just allow <mask>, etc. as children in HTML

    JY: there's also the question of whether people would put that
    directly in their document, or reference an external file

    TA: being able to reduce external requests is a nice thing

    ED: there are some complications, percentages depending on the

    … if a mask has a maskWidth="50%" what do you resolve that

    … solvable of course but not defined

    Dirk: we have that in filters too, we use the bounding client
    rect of the element

    <ed> s/maskWidth/mask @width/


      [88] http://www.w3.org/TR/SVG11/masking.html#MaskElementWidthAttribute

    BB: depends on maskUnits, whether it resolves against the thing
    being masked or the viewport the <mask> element is in

    ED: what if you have <mask> with text inside?

    TA: you can just put display:none on it
    ... I will look at the selected SVG elements in HTML too

SVG DOM improvements

    TA: how do we improve the SVG DOM without a big red switch?

    CM: we are a bit limited in the improvements we can do without
    a big switch

    Dirk: with turning every attribute into a property, do we still
    need the SVG DOM?

    TA: a lot of the benefit disappears when you can the CSS OM

    rect.x.px += 20

    CM: that is no worse than using CSS OM

    TA: in CSS OM it would convert it into the current unit you're

    … if you are using percentages, and you add 20px, it would
    convert the result into %

    … if throwing the CSS OM on top lets us ignore animVal/baseVal,
    that would be good

    CM: should I just write up a concrete proposal for the x.px

    CL: yes

    BB: this is not going to help with say path interfaces, so we
    definitely need something there and can't rely on CSS OM

    <scribe> ACTION: Cameron to propose SVGAnimatedLength
    improvements [recorded in

    <trackbot> Created ACTION-3336 - Propose SVGAnimatedLength
    improvements [on Cameron McCormack - due 2012-08-01].

    <TabAtkins_> ScribeNick: TabAtkins_

    heycam: We've decided we're meeting just after svgopen - the
    mon-wed directly afterards. Sep 17-19.
    ... Andreas asked if we want to meet something in the mountains
    rather than the svgopen conference venue.

SVGOpen F2F meeting

    krit: I have to leave at noon on wednesday.

    heycam: But that means you'll miss all of wednesday anyway.
    ... Continuing, andreas says there are hotels in the mountains
    with meeting rooms we can use.

    <heycam> Schuders

    heycam: And there is one place, Schuders, that is a 2hr train
    ride from Zurich.

    Cyril: My parents are an hour or two away from Zurish, so I was
    planning on commuting from them sometimes.

    heycam: Prices are between $50 and $75 swiss franks, which
    includes breakfast.

    shepazu: The frank is about 1-1 with the dollar, so that's
    cheap and beautiful.

    <heycam> www.postschuders.ch

    <ChrisL> looks like a fun place

    <ChrisL> i won't be hiking anywhere though

    Cyril: Let's get Tav's opinion as well.

    ChrisL: We can still decide now.

    <heycam> RESOLUTION: We will meet at Andreas's suggested Swiss
    mountain town.

    <heycam> ACTION: Cameron to set up a wbs for SVG Open F2F and
    let Andreas know [recorded in

    <trackbot> Created ACTION-3337 - Set up a wbs for SVG Open F2F
    and let Andreas know [on Cameron McCormack - due 2012-08-01].

    ed: Any plans for the next meeting after that?

    Cyril: I can offer Paris any time.

    heycam: you don't want to go to australia or nz?

    Cyril: That would be fine too. ^_^

    heycam: Okay, so we get Alex Danilo to arrange it for us.

    nikos: Or maybe Canon.

    Cyril: So, dates? Sometime in January?
    ... week starting with the 21st is no good for me.
    ... Conflicting meeting.

    <ed> feb 4 - 8, 2013

    <heycam> january 14 - 17 is better

    <heycam> RESOLUTION: We will meet January 14 - 17, 2013 in

    <heycam> good idea to meet with CSS in Tokyo in April which it
    sounds like they might be

    <ed> trackbot, make minutes

    <trackbot> Sorry, ed, I don't understand 'trackbot, make
    minutes'. Please refer to
    [91]http://www.w3.org/2005/06/tracker/irc for help

      [91] http://www.w3.org/2005/06/tracker/irc

Summary of Action Items

    [NEW] ACTION: brian birtles to write up a proposal for view-box
    property for SVG [recorded in
    [NEW] ACTION: Cameron to add back property definition tables
    [recorded in
    [NEW] ACTION: Cameron to define "default object size" so that
    css3-images <image> works for SVG paints [recorded in
    [NEW] ACTION: Cameron to do all this interface stuff
    (Proposals/IDL interface reorganization) [recorded in
    [NEW] ACTION: Cameron to propose SVGAnimatedLength improvements
    [recorded in
    [NEW] ACTION: Cameron to remove eRR from SVG2 [recorded in
    [NEW] ACTION: Cameron to set up a wbs for SVG Open F2F and let
    Andreas know [recorded in
    [NEW] ACTION: Cameron to work out whether to add a new repo for
    all new modules, or a new repo for each [recorded in
    [NEW] ACTION: Chris to remove support for top-level <font-face>
    for external font referencing support [recorded in
    [NEW] ACTION: ChrisL to work out things on removing XML ns
    stuff on text and figure things out with the CSS WG [recorded
    in [101]http://www.w3.org/2012/07/24-svg-minutes.html#action01]
    [NEW] ACTION: Erik to add the drag & drop functionality to SVG2
    [recorded in
    [NEW] ACTION: Nikos to add notes to SVG2 referencing
    Compositing, and remove any duplicated text if that can be done
    before publication [recorded in
    [NEW] ACTION: Tab Atkins to take HTML and Iframe view-box
    property to the CSS working group [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [105]scribe.perl version
     1.136 ([106]CVS log)
     $Date: 2012/07/25 21:10:19 $

     [105] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [106] 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 [107]http://dev.w3.org/cvsweb/~checkout~/2002

     [107] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/pint/paint/
Succeeded: s/this markers/these markers/
Succeeded: s/specify relative/specify a clipping path relative/
Succeeded: s/pth/path/
Succeeded: s/DS: so/DirkS: so/
Succeeded: s/questions/question/
Succeeded: s/would be 200/would be 100/
Succeeded: s/at 100/at 200/
Succeeded: s/middle/none/
Succeeded: s/surouned/surrounded/
Succeeded: s/edded/edited/
FAILED: s/RESOLUTION: textPath must not surouned by text element anymore
./RESOLUTION: textPath not needed to be surrounded by text element anymo
Succeeded: s/RESOLUTION: textPath must not surouned by text element anym
ore./RESOLUTION: textPath not needed to be surrounded by text element an
Succeeded: s/coast/cost/
WARNING: Bad s/// command: s/word breaking/collapsing/ ?
Succeeded: s/it doesn't see much use/Opera implements it, but eRR isn't
used much/
FAILED: s/filtes/files/
Succeeded: s/DS/Doug/
Succeeded: s/inherit/fill:inherit/
FAILED: s/aray/ray/
FAILED: s/cascading/cascading or recursion/
Succeeded: s/CC/RC/
FAILED: s/for rendering it doesn't matter if BR is specified or not, it
should produce an identical rendering result//
FAILED: s/whether it's there or not doesn't make a difference/for render
ing it doesn't matter if BR is specified or not, it should produce an id
entical rendering result/
FAILED: s/SVG <image> will allow declarative or frame-based animated ima
ges/SVG <image> will allow declarative or frame-based animated images, b
ut not scripted animations/
FAILED: s/ED/Doug/
FAILED: s/… I don't think this helps with the problem of getting mouse e
vent coordinates in the right coordinate space/Doug: I don't think this
helps with the problem of getting mouse event coordinates in the right c
oordinate space/
FAILED: s/think so/think so, they will likely be at CR by the time we ge
t to CR/
FAILED: s/tine/tiny/
FAILED: s/sa/say/
FAILED: s/teh/the/
FAILED: s/maskWidth/mask @width/
Found ScribeNick: birtles
Found ScribeNick: ChrisL
Found ScribeNick: birtles
Found ScribeNick: krit
Found ScribeNick: cabanier
WARNING: No scribe lines found matching ScribeNick pattern: <cabanier> .
Found ScribeNick: ChrisL
Found ScribeNick: cabanier
Found ScribeNick: heycam
Found ScribeNick: TabAtkins_
Inferring Scribes: birtles, ChrisL, krit, cabanier, heycam, TabAtkins_
Scribes: birtles, ChrisL, krit, cabanier, heycam, TabAtkins_
ScribeNicks: birtles, ChrisL, krit, cabanier, heycam, TabAtkins_

WARNING: Replacing list of attendees.
Old list: +1.206.675.aaaa Tav mdyck TimMills
New list: +1.206.675.aaaa Tav

Default Present: +1.206.675.aaaa, Tav
Present: +1.206.675.aaaa Tav

WARNING: Fewer than 3 people found for Present list!

Agenda: [108]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_Paris_20
Found Date: 24 Jul 2012
Guessing minutes URL: [109]http://www.w3.org/2012/07/24-svg-minutes.html
People with action items: atkins birtles brian cameron chris chrisl erik
  nikos tab

     [109] http://www.w3.org/2012/07/24-svg-minutes.html

    End of [110]scribe.perl diagnostic output]

     [110] 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 Wednesday, 25 July 2012 21:16:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:36 UTC