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

Minutes, Seattle/Paris SVG WG F2F Day 2

From: Erik Dahlstrom <ed@opera.com>
Date: Wed, 25 Jul 2012 15:47:12 +0200
To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Message-ID: <op.whz8kywygeuyw5@dhcpwifi-22-33.enst.fr>
Minutes below:

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


    [1]W3C

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

                                - DRAFT -

                     SVG Working Group Teleconference

24 Jul 2012

    [2]Agenda

       [2]  
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_Paris_2012/Agenda#Agenda

    See also: [3]IRC log

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

Attendees

    Present
           +1.206.675.aaaa, Tav

    Regrets
    Chair
           ed

    Scribe
           birtles, ChrisL, krit, cabanier

Contents

      * [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
      * [10]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 24 July 2012

    <Tav> Telephone?

    <birtles> scribenick: birtles

Marker proposal review

    <ChrisL> scribenick: ChrisL

    <birtles>
    [11]https://svgwg.org/svg2-draft/painting.html#Markers

      [11] 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
    words

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

    <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

    <heycam>
    [12]https://svgwg.org/svg2-draft/painting.html#MarkerSegmentPro
    perty

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

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

      [13] 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
    me
    ... 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

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

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

    CM: there is an example of positioned markers in the element
    section
    ... 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
    attribute
    ... since you might want to reference some existing marker
    definition
    ... 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
    attribute
    ... 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> [15]http://tavmjong.free.fr/blog/

      [15] 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
    cases
    ... 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
    intersections
    ... 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
    useful

    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
    bbox
    ... 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
    slower)
    ... 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
    remove
    ... 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
    detection

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

    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
    cases

    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
    marker
    ... what happens to that new bit of stroke?

    CM: I think unless you want to split up the path into multiple
    sections
    ... if you set up a single clipping path before you draw the
    path
    ... 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...
    [16]https://svgwg.org/svg2-draft/painting.html#MarkerAlgorithm

      [16] 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> [17]http://people.mozilla.org/~cmccormack/temp/text.pdf

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

    heycam: I want to give the proposals and let people say yes or
    no
    ... 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
    [18]http://dev.w3.org/csswg/css3-linebox/

      [18] 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
    [19]http://dev.w3.org/csswg/css3-writing-modes/

      [19] 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
    glyph
    ... 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

    no

    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
    [20]http://dev.w3.org/csswg/css3-fonts/#font-variant-ligatures-
    prop

      [20] 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
    [21]http://en.wikipedia.org/wiki/Hebrew_alphabet

      [21] 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
    chunks

    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:
    [22]http://people.mozilla.org/~cmccormack/temp/text.pdf

      [22] 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
    there

    heycam: have to check anchoring: none, but I think it is an
    unimportant case
    ... undefined behavior in the spec t the moment:
    <textPath>…</textPath>TextAfterTextPath
    ... 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
    anymore.

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

      [23] 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 [24]http://dev.w3.org/csswg/ for links to those

      [24] 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
    feedback

white spaces edits in SVG

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

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

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

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

    <ChrisL>
    [27]http://dev.w3.org/csswg/css3-text/#soft-wrap-opportunity

      [27] 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
    ns.

    <scribe> ACTION: ChrisL to work out things on removing XML ns
    stuff on text and figure things out with the CSS WG [recorded
    in [28]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

    <trackbot>
    [29]http://www.w3.org/Graphics/SVG/WG/track/actions/3323

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

    <ed> -- 15 min break --

    <cabanier> scribenick: cabanier

    <ChrisL> scribenick: ChrisL

    <scribe> scribenick: cabanier

    <ed>
    [30]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interf
    ace_reorganization

      [30]  
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization

SVG in Web IDL

    CM: I propose to redo the SVG idl

    [31]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interf
    ace_reorganization

      [31]  
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization

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

    …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
    lang

    …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
    effect

    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
    decision

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

    …SVGSVGElement we want to be able to transform but not
    SVGMarker

    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 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
    [32]http://www.w3.org/2012/07/24-svg-minutes.html#action02]

    <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

    CC: 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
    "view-box"?

    DS: 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
    growing/shrinking

    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'
    characteristic

    <scribe> ACTION: Tab Atkins to take HTML and Iframe view-box
    property to the CSS working group [recorded in
    [33]http://www.w3.org/2012/07/24-svg-minutes.html#action03]

    <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
    [34]http://www.w3.org/2012/07/24-svg-minutes.html#action04]

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

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
    element

Summary of Action Items

    [NEW] ACTION: brian birtles to write up a proposal for view-box
    property for SVG [recorded in
    [35]http://www.w3.org/2012/07/24-svg-minutes.html#action04]
    [NEW] ACTION: Cameron to do all this interface stuff
    (Proposals/IDL interface reorganization) [recorded in
    [36]http://www.w3.org/2012/07/24-svg-minutes.html#action02]
    [NEW] ACTION: ChrisL to work out things on removing XML ns
    stuff on text and figure things out with the CSS WG [recorded
    in [37]http://www.w3.org/2012/07/24-svg-minutes.html#action01]
    [NEW] ACTION: Tab Atkins to take HTML and Iframe view-box
    property to the CSS working group [recorded in
    [38]http://www.w3.org/2012/07/24-svg-minutes.html#action03]

    [End of minutes]
      __________________________________________________________


     Minutes formatted by David Booth's [39]scribe.perl version
     1.136 ([40]CVS log)
     $Date: 2012/07/24 19:02:03 $
      __________________________________________________________

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

      [41] 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
re./
Succeeded: s/RESOLUTION: textPath must not surouned by text element anym
ore./RESOLUTION: textPath not needed to be surrounded by text element an
ymore./
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/
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
Inferring Scribes: birtles, ChrisL, krit, cabanier
Scribes: birtles, ChrisL, krit, cabanier
ScribeNicks: birtles, ChrisL, krit, cabanier

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: [42]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_Paris_201
2/Agenda#Agenda
Found Date: 24 Jul 2012
Guessing minutes URL: [43]http://www.w3.org/2012/07/24-svg-minutes.html
People with action items: atkins birtles brian cameron chrisl tab

      [42]  
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_Paris_2012/Agenda#Agenda
      [43] http://www.w3.org/2012/07/24-svg-minutes.html


    End of [44]scribe.perl diagnostic output]

      [44] 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 13:47:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 25 July 2012 13:47:50 GMT