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

minutes, SVG WG Sydney 2012 F2F day 3

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 13 Jan 2012 17:45:26 +1100
Message-ID: <4F0FD306.3050308@mcc.id.au>
To: SVG public list <www-svg@w3.org>
http://www.w3.org/2012/01/12-svg-minutes.html

and below as text:

    [1]W3C

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

                                - DRAFT -

                      SVG WG Sydney 2012 F2F day 3

12 Jan 2012

    See also: [2]IRC log

       [2] http://www.w3.org/2012/01/12-svg-irc

Attendees

    Present
    Regrets
    Chair
           Erik

    Scribe
           Cyril

Contents

      * [3]Topics
          1. [4]alpha mask proposal
          2. [5]SVG in HTML <head>
          3. [6]shorthand properties as presentation attributes
          4. [7]SVG2 Requirements
          5. [8]Milestones and Planning
          6. [9]getBBoxOf
          7. [10]Auto sized image
          8. [11]test suite
          9. [12]Spec review requests
         10. [13]CSS Compositing
      * [14]Summary of Action Items
      _________________________________________________________

    <cabanier> scribenick: cabanier

alpha mask proposal

    <heycam>
    [15]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Alpha_mask

      [15] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Alpha_mask

    cm: mask are currently unintuive since they use luminance
    ... it is quite confusing
    ... we opened an issue where you can use the alpha values
    ... I opened a small proposal where you can specify luminance or
    alpha
    ... there were a proposal where you could combine the 2 by having a
    seperate property for each mask type

    rc: are alpha values currently ignored?

    cm: no they contribute to the luminance.

    rc: this is similar to what PDF
    ... except noone uses the alpha version

    bb: there seems to be some confusion in the spec about what mask
    apply to

    it seems pretty unlikely for a given mask mask element that it can
    be use for both luminance and alpha

    rc: why is that?

    cm: it's unlikely that you use the same element but then use it with
    alpha in one place and luminance in the other

    <birtles> (re the confusion in the spec, specifically
    [16]http://www.w3.org/TR/SVG11/masking.html#MaskProperty says the
    mask property can refer to "another graphical object", not just a
    <mask>. That restriction appears earlier in the prose.)

      [16] http://www.w3.org/TR/SVG11/masking.html#MaskProperty

    <ed> another way could be mask: <funciri> | none | alpha(<funciri>)
    | luminance(<funciri>)

    <ed> replace those <funciri> in the last two with <iri> I guess
    though

    <ed> that would make it rather easy to do fallbacks because old
    useragents would fail parsing the css

    bb: it would be nice if you wouldn't have to create id's

    cm: not everyone puts masks in the defs
    ... that does seem handy

    bb: very often you have to write a unique id generator to create the
    id's

    cm: maybe we can raise an issue

    ed: people have asked for this for gradients

    <heycam> ISSUE: Consider allowing <mask>, <clipPath>, etc. as direct
    children of elements they'd apply to, to avoid IDs

    <trackbot> Created ISSUE-2431 - Consider allowing <mask>,
    <clipPath>, etc. as direct children of elements they'd apply to, to
    avoid IDs ; please complete additional details at
    [17]http://www.w3.org/Graphics/SVG/WG/track/issues/2431/edit .

      [17] http://www.w3.org/Graphics/SVG/WG/track/issues/2431/edit

    bb: this does impace how it impacts alpha and luminance

    cm: you can have new keywords for mask: 'mask: child' and then if
    there is a mask element child that that is using it as a child.

    ed: having a keyword like that because we don't always traverse into
    an element. this keyword would tell us to examine the element.
    ... I have no problems with the functionality itself
    ... I think that's what we want

    cm: bb do you want to investigate this further?

    bb: yes, I would like to look into this further to make sure there
    are no issues

    action birtles to investigate issue 2431

    <trackbot> Created ACTION-3205 - Investigate issue 2431 [on Brian
    Birtles - due 2012-01-19].

    action heycam to proposal a final syntax on alpha mask after Brian
    investigate 2431

    <trackbot> Created ACTION-3206 - Proposal a final syntax on alpha
    mask after Brian investigate 2431 [on Cameron McCormack - due
    2012-01-19].

    resolution: we will add alpha mask functionality to SVG 2

    <ed> [18]http://www.w3.org/Graphics/SVG/WG/track/

      [18] http://www.w3.org/Graphics/SVG/WG/track/

    ed: until the break we will work on some open actions

    <ed> [19]http://www.w3.org/Graphics/SVG/WG/track/users

      [19] http://www.w3.org/Graphics/SVG/WG/track/users

    <heycam> -- doing actions until morning tea break --

    <ed> -- <tbreak dur="15min"/> --

    <heycam> scribenick: heycam

SVG in HTML <head>

    <ed> previous discussion of this:
    [20]http://www.w3.org/2012/01/05-svg-minutes.html#item04

      [20] http://www.w3.org/2012/01/05-svg-minutes.html#item04

    DS: there's strong resistance from browser vendors to add elements
    to the HTML <head>

    … because it breaks backwards compat, and requires changes to the
    parser

    … the parser is pretty much set in stone at this point

    CL: I don't think we need to put things in head

    … our <defs> is like a <div> with display:none

    … so you can stick whatever you want there

    … there's no need to put it in the <head>

    … the only thing we do have that maybe belongs in the head is the
    <meta> element, though our <metadata> is structured

    … in SVG you can nest elements in <metadata>

    … so it really doesn't belong in <head> either

    DS: I do think it's not unreasonable for people to think they should
    add things to the head

    CL: at first sight it's very reasonable

    DS: I think our best course of action is not to follow up on hixie's
    recommendation to define our elements as metadata content

    … rather to simply to educate people that you can't do that

    … I think it's very unusual that hixie would recommend this course
    of action

    … I will respond to the original commenter

    RESOLUTION: SVG will not allow elements to be put in HTML <head>

shorthand properties as presentation attributes

    <ed>
    [21]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Shorthand_prese
    ntation_attribute

      [21] 
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Shorthand_presentation_attribute

    <birtles> ScribeNick: birtles

    CL: CM's proposal on the wiki where you put the shorthands before
    all the properties in doc order satisifies my earlier concerns

    CM: proposal is to allow pres attr for properties which are
    shorthands
    ... at the moment you can't write marker="" b/c marker is a
    shorthand
    ... creates confusion for authors
    ... don't understand why they need to use marker-start etc. if
    they're using pres attr
    ... with style you can just use "marker"
    ... last time this issue came up was in context of when CSS
    properties get split and orig becomes a shorthand
    ... e.g. overflow becoming overflow-x and overflow-y
    ... overflow is now a shorthand

    CL: likewise whitespace might go that way

    CM: we want to allow overflow to continue to be a pres attr
    ... even if it becomes a shorthand
    ... original reluctance was you have multiple attr targetting the
    same property
    ... and override behaviour was not clear since attr are unordered
    ... unlike styles where you have doc order
    ... but the proposal addresses that by taking shorthands first

    ED: so you if have marker-mid before marker (as attributes) then
    marker will override marker
    ... so you if have marker-mid before marker (as attributes) then
    marker will override marker-mid

    CL: it's something we're going to have to address with properties
    being split up and becoming shorthands
    ... any comments from implementors?

    ED: it's probably fine but I need to check the code
    ... it would be pretty simple to verify if there were some test
    cases

    CM: I think it should be ok
    ... is there a difference between animating the style or the
    presentation attribute

    CL: attributeType is just for disambiguation when the attribute name
    and property name overlap and are not the same thing
    ... not to provide different behaviour

    RESOLUTION: We will allow shorthand properties to be used as
    presentation attributes (ISSUE-2430) according to Cameron's proposal

    <scribe> ACTION: Cameron to describe using shorthand properties as
    presentation attributes in spec [recorded in
    [22]http://www.w3.org/2012/01/12-svg-minutes.html#action01]

    <trackbot> Created ACTION-3207 - Describe using shorthand properties
    as presentation attributes in spec [on Cameron McCormack - due
    2012-01-20].

    ED: is there an order normally to style

    <heycam> ACTION-3207:
    [23]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Shorthand_prese
    ntation_attribute

      [23] 
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Shorthand_presentation_attribute

    <trackbot> ACTION-3207 Describe using shorthand properties as
    presentation attributes in spec notes added

    CL: yes, if it's in a stylesheet (incl style attr)

    ED: if you start modifying the element by script, then the order is
    not guaranteed

    CL: the assertion was attributes are unordered

    CM: the stylesheet is not exposed to script though right?
    ... you can getComputedStyle but there's no order requirement there

    ED: if it's just for when it's parsed then it's ok

    CM: even if you're modifying the attr then you still need the
    shorthand first
    ... if you're actually creating stylesheets you could create two
    (one for shorthands)
    ... might be simpler than managing the order

    ED: what about font? you have to use CSS rules such as requiring
    units
    ... isn't that confusing?
    ... for all shorthands you have to use units
    ... whereas elsewhere you don't

    CL: it's only really for lengths where we have this different
    ... where you don't need units in SVG
    ... marker etc. are ok
    ... it's only really 'font'
    ... so it would be a rule that shorthands have to use CSS rules
    which includes using units (and excluding scientific notation)

    CM: what if we came up with our own shorthand
    ... that wasn't ambiguous

    CL: that would be confusing to use a different notation
    ... and might outweigh the benefit of using shorthands
    ... because you'd add syntax to disambiguate

    CM: so we'll just require CSS parsing for shorthand presentation
    attributes

    ED: I think that would be ok, better than adding quirks

    CM: what about new CSS properties?
    ... we have font-size in SVG so we can explicitly allow unitless
    lengths

    CL: do we want to revisit scientific notation in SVG 2?
    ... because perhaps it's not used?

    CM: many scripts default to using exponential notation

    CL: we were originally expecting much more use of the world coord
    system with very large numbers
    ... but in practice you actually run into precision problems

SVG2 Requirements

    Up to:
    [24]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#I
    mprove_to-animations

      [24] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_to-animations

    <cyril> we should also deal with
    [25]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#S
    MIL_time_containers

      [25] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_time_containers

    deciding on time containers depends on me finishing action-3202

    BB: not sure what this means

    CM: I guess it's about addressing differences

    BB: what are the differences?

    CM: underlying value is fixed, reversing

    BB: my guess is reversing?

    VH: we should find out what is specificallly required here

    <scribe> ACTION: Cameron to contact Dr. Olaf Hoffmann to ask what is
    specifically required to make to-animation similar to CSS
    transitions [recorded in
    [26]http://www.w3.org/2012/01/12-svg-minutes.html#action02]

    <trackbot> Created ACTION-3208 - Contact Dr. Olaf Hoffmann to ask
    what is specifically required to make to-animation similar to CSS
    transitions [on Cameron McCormack - due 2012-01-20].

    ACTION-2308:
    [27]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#I
    mprove_to-animations

      [27] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_to-animations

    <trackbot> ACTION-2308 Draft an email response for the second half
    of ISSUE-2089 notes added

    ACTION-3208:
    [28]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#I
    mprove_to-animations

      [28] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_to-animations

    <trackbot> ACTION-3208 Contact Dr. Olaf Hoffmann to ask what is
    specifically required to make to-animation similar to CSS
    transitions notes added

    CL: we are going to have transitions anyway based on Patrick's
    proposal to allow using SVG's attributes in CSS

    <cyril> RESOLUTION: SVG 2 will allow CSS-transitions-like animations

    <cyril> RRSAgent pointer

    <heycam> ACTION-3208: Say to Olaf we have interpreted his request in
    this way, and we agree, but if he means something else please
    explain

    <trackbot> ACTION-3208 Contact Dr. Olaf Hoffmann to ask what is
    specifically required to make to-animation similar to CSS
    transitions notes added

    next, Transitions for discretely animated properties, text-anchor in
    particular

    <ChrisL> commenter wants to smoothly animate from

    <ChrisL> .................|..................

    <ChrisL> SOME_TEXT_1

    <ChrisL> SOME_OTHER_TEXT_2

    <ChrisL> to

    <ChrisL> ................|..................

    <ChrisL> SOME_TEXT_1

    <ChrisL> SOME_OTHER_TEXT_2

    ED: even though text-anchor-end animation is discrete it would be
    possible to provide linear interpolation

    CM: it is a bit of a violation of the model and the idea of
    "discrete"

    <ChrisL> I think that breaks the modelof animation. at all points in
    the animation, the value of the animated property has to be one of
    the actual values

    VH: there's a difference between calcMode="discrete" and
    calcMode="linear" that falls back to discrete

    CM: if we wanted it to work for text-anchor we could allow it to
    take numeric values

    <ChrisL> we could imaging a mapping with for example-100% as start,
    0 as middle,100% as end

    CM: e.g. -100 to 100

    CL: we could spec it fairly easily
    ... I think it's ok if we're just talking about calcMode="linear"
    that falls back
    ... as opposed to calcMode="discrete"

    CM: but I often rely on that fallback behaviour
    ... and don't specify calcMode="discrete"

    CL: if we did this change and people are relying on the discrete
    behaviour they might get a surprise

    <ChrisL> butthey could fix it by adding calcmode discrete to keep
    the old behaviour

    BB: so you have to modify the definition of those attributes to
    allow numeric values

    CL: the approach is to make attributes that take discrete values to
    be shorthand for those that take numeric values

    CM: in font-weight, some of the keywords are synonyms for numbers

    CL: but it's an ordered series

    CM: what happens when you getComputedStyle---which do you get? the
    keyword or the number?
    ... likewise what will happen here if we use getComputedStyle on the
    new text-anchor etc. that takes numeric values

    CL: I'm proposing promoting some values so that can take
    *continuous* values
    ... so font-weight would not be an example

    RESOLUTION: SVG2 will allow linear interpolation for properties
    which were previously discrete

    <scribe> ACTION: Chris to write up a proposal for allowing linear
    interpolation of properties that were previously discrete but could
    be reasonably interpolated linearly [recorded in
    [29]http://www.w3.org/2012/01/12-svg-minutes.html#action03]

    <trackbot> Created ACTION-3209 - Write up a proposal for allowing
    linear interpolation of properties that were previously discrete but
    could be reasonably interpolated linearly [on Chris Lilley - due
    2012-01-20].

    <scribe> ACTION: Brian to look for text in SVG/SMIL that suggests
    using different calcMode's based on the values used (enum values
    versus numeric) [recorded in
    [30]http://www.w3.org/2012/01/12-svg-minutes.html#action04]

    <trackbot> Created ACTION-3210 - Look for text in SVG/SMIL that
    suggests using different calcMode's based on the values used (enum
    values versus numeric) [on Brian Birtles - due 2012-01-20].

    next, animateTransform with matrix-decomposed like CSS

    <ed>
    [31]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#a
    nimateTransform_with_matrix-decomposed_like_CSS

      [31] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#animateTransform_with_matrix-decomposed_like_CSS

    CM: diff between animateTransform and CSS Animations with transform
    property, is CSS considers the whole transform list, but SVG
    Animations does one transform at a time and post-multiplies
    ... request is to add a new type to animateTransform that matches
    CSS Animations
    ... but we could just <animate> to get that behaviour
    ... <animate attributeName="transform" values="scale(...)
    rotate(...); scale(...) rotate(...)"/>
    ... it overrides the whole list
    ... need to define how additive works with whole lists of items

    VH: so how does animateTransform add to the end of the list?

    BB: it differs between browsers
    ... if you inspect the animVal in the DOM some browsers will just
    append a matrix transform, some will try to preseve the
    animateTransform's type, others just replace the whole list with a
    matrix

    VH: even if we deal with lists we already have a model for adding
    that to the underlying transform, it doesn't change the model

    CC: it doesn't change the post-multiplication
    ... it doesn't change the final value
    ... but it does change the animVal

    VH: but given the way the requirement is worded I think it wouldn't
    change
    ... we want to allow <animate attributeName="transform">

    CM: I agree

    RESOLUTION: We will support animation using a transform-list

    [32]http://dev.w3.org/csswg/css3-2d-transforms/#animation

      [32] http://dev.w3.org/csswg/css3-2d-transforms/#animation

    [33]http://brian.sol1.net/svg/animatetransform-issues/accumulation-o
    f-transformations/

      [33] 
http://brian.sol1.net/svg/animatetransform-issues/accumulation-of-transformations/

    BB: Addition of transforms is a bit unusual (see above link)
    ... we can rely on CSS Transform's behviour for interpolation but we
    need to specify how addition works for transform lists

    CM: this difference is specific to animateTransform
    ... so if we go to using animate, do we want to just use the default
    behaviour?
    ... which would mean adding the transform components rather than
    post-multiplication

    <scribe> ACTION: Cyril to investigate different methods for adding
    transform in animation [recorded in
    [34]http://www.w3.org/2012/01/12-svg-minutes.html#action05]

    <trackbot> Created ACTION-3211 - Investigate different methods for
    adding transform in animation [on Cyril Concolato - due 2012-01-20].

    ACTION-3211:
    [35]http://brian.sol1.net/svg/animatetransform-issues/accumulation-o
    f-transformations/

      [35] 
http://brian.sol1.net/svg/animatetransform-issues/accumulation-of-transformations/

    <trackbot> ACTION-3211 Investigate different methods for adding
    transform in animation notes added

    ---break 1hr for lunch---

    <vhardy>
    [36]http://dev.w3.org/SVG/profiles/1.2T/test/htmlObjectHarness/anima
    te-elem-81-t.html

      [36] 
http://dev.w3.org/SVG/profiles/1.2T/test/htmlObjectHarness/animate-elem-81-t.html

    <patrickdengler_> Sorry, I didn't catch the end of this discussion,
    and I hope you had a good lunch :)

    <patrickdengler_> When we talk about adding a new element, such as
    animateTransform, are we consulting with the HTML group as well?

    <patrickdengler_> Not animateTransform but any *new* element (sorry)

    <ChrisL> scribeNick: ChrisL

Milestones and Planning

    <ed> [37]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page

      [37] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page

    heycam: need some target dates

    <ed> [38]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page

      [38] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page

    <heycam> [39]http://dev.w3.org/SVG/profiles/2.0/reqs/publish/

      [39] http://dev.w3.org/SVG/profiles/2.0/reqs/publish/

    heycam: was supposed to add stuff back into the wiki page from the
    separate document

    ChrisL: and people were to add explanation for the accepted items

    vhardy: whatabout use cases?

    heycam: should be in the wiki page
    ... if its useful we can continue working on a /TR requirements doc

    ChrisL: want oto avoid work that is of no beefit. wiki page is more
    easily updated

    ed: easier to update wikipage

    heycam: easier to read a published doc though

    cyril: we have 90 left to do
    ... out of 180 at the start
    ... wereat 40% after tpac

    vhardy: think its a big effort to migrate to a new document

    ChrisL: people do not read reqts top to tail, they drill down on a
    particular issue
    ... still feasible to do by end of this f2f?

    cyril: we have 2/3 by scrollbar

    birtles: doc gets longer as we edit

    ChrisL: earlier ones were more vague and we took a lot of time to
    understand the comments. later ones are specced features from 1.2T
    so its either in or out
    ... next, whatdo we have in fpwd - lots or a little (ipp
    implications)

    <heycam> CM: the other question is whether we go forward with this
    grand refactoring of the document that we talked about before

    <heycam> … I think it would be better to not do that upfront

    <heycam> … instead we just add the features/changes according to the
    existing structure

    <heycam> … so we can get drafts published with them

    <heycam> … rather than having the first couple of working drafts
    just consist of reorganisation of existing text, with no other
    changes

    ChrisL: would prioritise documenting new features over
    refactoringexisting ones
    ... patent exclusions are at fpwd and last call, and are per-feature
    ... so its better to at least list a feature even if the spec is
    incomplete or the syntax not stable
    ... want to see tests early

    heycam: so when new feature is added, add tests as well

    ChrisL (explains how automatic test assertion annotation is added)

    ed: good to get some tests using the new harness, to see how it
    works

    ChrisL: we need to decide link mechanisms. WOFF used this new
    mechanism (but the files were mostly html)

    <scribe> ACTION: chris to continue to work on test suite linking
    mechanism for new harness [recorded in
    [40]http://www.w3.org/2012/01/12-svg-minutes.html#action06]

    <trackbot> Created ACTION-3212 - Continue to work on test suite
    linking mechanism for new harness [on Chris Lilley - due
    2012-01-20].

    ed: we can update the milestones to add this testsuite item

    <cyril> [41]http://test.csswg.org/

      [41] http://test.csswg.org/

    birtles: good reftests use lime green for pass and red for fail

    that is not the right link

    [42]http://w3c-test.org/framework/

      [42] http://w3c-test.org/framework/

    ChrisL (walks through the new reporting framework)

    heycam: need stubs for every new feature for fpwd. say 3 months
    after the editors draft
    ... so July
    ... then another in October for TPAC

    vhardy: who can lead the spec editing effort

    cyril: needs someone who already has ssh mercurial access

    ed: tav has done most of the editing so far

    heycam: last entry depends on the feature owners

    vhardy: in reqts we have big sections then a lot of tiny ones

    heycam: as we go through the list we can allocate owners

    vhardy: we need to triage the requirements to prioritise the most
    important ones

    heycam: we did not do that, so we accepted a lot of requirements
    some of which might not be for 2.0

    vhardy: need priority on all the accepted requirements

    cyril: once we have commitments for the popular features this will
    lead to priorities. if no-one commits its low priority

    heycam: and if that is loo long we can cut it

    cyril: up to individuals how many new features to take on

    vhardy: priority needs to be decided before fpwd
    ... march is better

    <scribe> ACTION: erik to remind people early March 2012 about
    prioritisation [recorded in
    [43]http://www.w3.org/2012/01/12-svg-minutes.html#action07]

    <trackbot> Created ACTION-3213 - Remind people early March 2012
    about prioritisation [on Erik Dahlström - due 2012-01-20].

    heycam: looks good for the milestones

    vhardy: management nightmare to weigh the priorities

    heycam: happy to make a form for that

    <scribe> ACTION: heycam to make a form for priorities [recorded in
    [44]http://www.w3.org/2012/01/12-svg-minutes.html#action08]

    <trackbot> Created ACTION-3214 - Make a form for priorities [on
    Cameron McCormack - due 2012-01-20].

    ChrisL: goot time for lc would be after tpac so (with holidays) jan
    would be good, finished by May/June and CR in August depending on
    need for a second LC

    vhardy: for selecting requirements we could update - things thatare
    broken, graphical features
    ... for 2.1 2.2 etc we could put the theme that adds value for each
    iteration, nt too ambitious each time
    ... first priority could be graphical features, with animation and
    dom refactoring left for a dot release

    heycam: seem to have a range of killer things that do not fit those
    themes

    cyril: this discussion is easier when we have a prioritised list

    vhardy: main point is to limit the scope to what is acheivable

    heycam: ok so lets aim for LC in January 2013

getBBoxOf

    <heycam>
    [45]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/getBBoxOf

      [45] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/getBBoxOf

    heycam: this is getting the bbox in a different elements coordinate
    system
    ... often want to do this
    ... proposal is to add getBBoxOf that you call in the element whith
    the desired coord system and you apss the element you want the bbox
    of
    ... need not be a descendent

    cyril: bbox is always axis aligned?

    heycam: yes

    ed: its like getScreenBBox in Tiny

    cyril: (points out an error in the proposal, this and element are
    transposed

    vhardy: do we want a rect or a set of points?

    <ed>
    [46]http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGLocatable_ge
    tScreenBBox

      [46] 
http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGLocatable_getScreenBBox

    vhardy: (draws on whiteboard)

    ed: agrees with vhardy, you want four points for a non axis aligned
    bbox

    vhardy: want the points, or an option to get the points

    cyril: last step is trivial, min maxso return the points

    ChrisL: getBBoxCorners ?

    birtles: what will people do more often?

    vhardy: adding handles is common so the points would be better there

    cabanier: illustrator gives the full bbox

    heycam: we don't want to multiply the number of methods unecessarily

    cabanier: if you miter corners and transform, miter will go further

    ChrisL: recall that we also wanted to have an inked bbox that
    includes stroke and markers
    ... so for this one which is geometric, stroke mitering does
    notaffect it

    vhardy: bbox is for dirty areas, editing

    birtles: hit testing

    ChrisL: for painted bbox we would need the analog of this (get
    painted bbox in another coord system)

    cabanier: if transformed, miters would become sharper

    vhardy: we do pre-transform stroking
    ... illustrator gives you both
    ... non scaling stroke strokes the transformedgeometry

    heycam: so maybe instead give a much easier way to get quads and
    then transform them to another coordsys

    vhardy: like the quad idea

    getBoundingQuad and then transform and getBBox on that

    <scribe> ACTION: heycam to revise getBBoxof proposal based on this
    discussion [recorded in
    [47]http://www.w3.org/2012/01/12-svg-minutes.html#action09]

    <trackbot> Created ACTION-3215 - Revise getBBoxof proposal based on
    this discussion [on Cameron McCormack - due 2012-01-20].

Auto sized image

    <vhardy>
    [48]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Auto-sized_imag
    e

      [48] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Auto-sized_image

    <birtles>
    [49]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
    uto-sized_image

      [49] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Auto-sized_image

    cyril: is it auto size or auto scale

    heycam: (rapidly corrects proposal)
    ... its the same rules css uses for intrinsic aspect ratio

    vhardy: the initiial viewport is there is there is no bbox
    ... defaults to 100% 100% and the width is known

    heycam: so you dont use any 150 300 ratio

    cyril: like the idea to not give w & h if you don't want
    ... do no t want to break backwards compat

    <vhardy> vhardy: at the end of the day, we need to align with the
    CSS 2.1 behavior.

    heycam: prefer 1 over 2 but itdoes change existing meaning
    ... second one doesn't
    ... in old viewers, missing attrs gives zero so no display - do that
    all the time

    vhardy: if you have w h and viewbox there is enough to work out the
    aspect ratio

    ChrisL: people depend on missed attrs going to zero, so I prefer the
    second option

    vhardy: common case of images with same width and variable height

    cyril: so that leads to proposal 2
    ... how aboutsizing="intrinsic"

    ed: i've seen some (rather complex) js driven frameworks that fill
    out w and h later and it does not want it to render if zero

    cyril: used for image preload

    birtles: is the preload specced?

    (we think not)

    vhardy: to display an unknown image you load by script just to
    calculate the w and h

    1 - two

    2 - four

    ppl voting 1 can live with 2

    resolution: image resizing will use option 2 with sizing="intrinsic"
    as an attr not a property

    ---break---

    <cyril> scirbe: Cyril

    <cyril> scribe: Cyril

    <scribe> ScribeNick: cyril

test suite

    CM: are we only having ref tests or scripted tests?

    CL: they are not mutually exclusive

    CM: yes

    BB: the scripted tests have the advantage of finding the reason for
    a failure easily
    ... you don't have to dig

    CM: there is the CSS thing (ref test) and the testharness.js

    ED: James Graham worked on making sure it works with our existing
    test harness
    ... so it is possible to use the existing test suite if we had
    script snippets
    ... but I' mot sure that's the best way to convert the tests
    ... I don't know if the existing test set is the best test
    ... Opera is working on publishing the existing animation tests for
    SMIL but scripted so that we don't have to look at the output
    ... it has some requirements on the API: pauseAnimation, and
    setCurrentTime

    <ChrisL> [50]http://w3c-test.org/resources/

      [50] http://w3c-test.org/resources/

    CC: at TPAC, the break out on testing was explaining how to use the
    harness

    <ChrisL> [51]http://w3c-test.org/resources/apisample.htm

      [51] http://w3c-test.org/resources/apisample.htm

    <ChrisL> [52]http://w3c-test.org/resources/apisample2.htm

      [52] http://w3c-test.org/resources/apisample2.htm

    <scribe> ACTION: Erik to check in an example on how to use the
    testharness.js [recorded in
    [53]http://www.w3.org/2012/01/12-svg-minutes.html#action10]

    <trackbot> Created ACTION-3216 - Check in an example on how to use
    the testharness.js [on Erik Dahlström - due 2012-01-20].

    CL: the current tests, we only have the image patches in the case
    where Batik does not pass
    ... now we want one of all
    ... and they need to be a lot simpler

    VH: that could be a real time sink
    ... I would like to say that we don't touch the old tests

    CL: that's a good comment

    ED: apart the animation tests, that should be fine for the others

    VH: especially with the new Browser API, is there anything to do
    screen capture

    CL: it has been proposed as modal and for the specific purpose of
    testing

    <ChrisL> but not enabled by default, for security

    VH: do we agree to keep the old test suite
    ... as is and work on a new one

    CL: yes

    ED: yes

    CL: we can copy over if needed

    CM: we would need to annotate the old tests for the coverage
    evaluation

    CL: the current annotation does not have the granularity
    ... that we need
    ... you need an id and a class, the test points to that id
    ... I did that with the WOFF spec and it's quite simple
    ... an id on each assertion and a class for viewers, authoring tools
    ....

Spec review requests

    CM: we got two requests to review CSS specs
    ... we need to assign actions so that that gets done

    VH: a third one is shadow dom

    CL: CSS Values and Replaced Content

    <ChrisL> Title: CSS Image Values and Replaced Content Module Level 3

    <ChrisL> Temporary URL: [54]http://dev.w3.org/csswg/css3-images/

      [54] http://dev.w3.org/csswg/css3-images/

    <ChrisL> Title: CSS Basic User Interface Module Level 3:

    <ChrisL> Editor's draft: [55]http://dev.w3.org/csswg/css3-ui/

      [55] http://dev.w3.org/csswg/css3-ui/

    RC: the first one has gradients

    CM: UI has pointer events and cursor
    ... UI is meant to be reviewed by 14th of Feb
    ... Image Values byt the 17th

    <scribe> ACTION: Vincent to review the Shadow DOM draft [recorded in
    [56]http://www.w3.org/2012/01/12-svg-minutes.html#action11]

    <trackbot> Created ACTION-3217 - Review the Shadow DOM draft [on
    Vincent Hardy - due 2012-01-20].

    CM: it told dmitry we will find in the SVG spec, where shadow dom is
    useful
    ... I didn't give him a timeline

    <scribe> ACTION: Chris to review CSS UI [recorded in
    [57]http://www.w3.org/2012/01/12-svg-minutes.html#action12]

    <trackbot> Created ACTION-3218 - Review CSS UI [on Chris Lilley -
    due 2012-01-20].

    <scribe> ACTION: Erik to review the 3 specs [recorded in
    [58]http://www.w3.org/2012/01/12-svg-minutes.html#action13]

    <trackbot> Created ACTION-3219 - Review the 3 specs [on Erik
    Dahlström - due 2012-01-20].

    <scribe> ACTION: Cyril to review CSS Image Values and Replaced
    Content Module Level 3 [recorded in
    [59]http://www.w3.org/2012/01/12-svg-minutes.html#action14]

    <trackbot> Created ACTION-3220 - Review CSS Image Values and
    Replaced Content Module Level 3 [on Cyril Concolato - due
    2012-01-20].

    <vhardy> ScribeNick: vhardy

    <heycam> Shadow DOM spec:
    [60]http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/ind
    ex.html

      [60] 
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html

CSS Compositing

    <cyril> [61]http://www.w3.org/TR/SVGCompositing/

      [61] http://www.w3.org/TR/SVGCompositing/

    ag: last time we edited the spec, I started putting in parts for CSS
    so that the document could apply to CSS and SVG, both.
    ... I do not remember how far we went, and there is more work to be
    done.

    <cyril>
    [62]http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.
    html

      [62] 
http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.html

    rc: did you send a pointer.

    (group looking for the draft).

    ag: the wording was changed, for example, on enable-background, to
    be generic and talk about 'host language' and use SVG as 'an example
    host language'. The document in dev is doing that migration.
    ... same for knockout and compop

    rc: do you remember why did you add Porter Duff.

    ag: filters were not enough because when you use the compositing
    operators in filters, they include the background twice and so you
    get an incorrect result. This is why we added the PD operators in
    the spec.

    cyril: I have dug up in previous documents/proposals, one of the
    reasons was that filters require a filter region, but for PD, you
    can do it while rasterizing and you do not need a region.
    ... I'll send a link to a document created by Craig Brown.
    ... if you have a set of elements that are composited with the
    painter's algorithm, and you want to make one compositing change on
    one element, you would have to completely modify the DOM (if using
    filters).

    rc: I would like to see an example to understand.

    <cyril> example:

    <cyril> <?xml version="1.0" encoding="utf-8"?>

    <cyril> <svg>

    <cyril> <path fill="#00FFFF" stroke="#000000"
    d="M103,120.5c0-33.137,26.863-60,

    <cyril> 60-60c33.137,0,60,26.863,60,60s-26.863,60-60,60

    <cyril> C129.863,180.5,103,153.637,103,120.5z"/>

    <cyril> <path fill="#FF0000" stroke="#000000"
    d="M151,114.5H37V0.5h114V114.5z"/>

    <cyril> <path fill="#00FF00" stroke="#000000"
    d="M223,69.5l-51,58l-76-97L223,69.5z"/>

    <cyril> </svg>

    <cyril> you want to modify to the third object to be composed with
    multiply

    <cyril> <?xml version="1.0" encoding="utf-8"?>

    <cyril> <svg>

    <cyril> <defs>

    <cyril> <g id="BoverA">

    <cyril> <path fill="#00FFFF" stroke="#000000"
    d="M103,120.5c0-33.137,

    <cyril> 26.863-60,60-60c33.137,0,60,26.863,60,60s-26.863,60-60,60

    <cyril> C129.863,180.5,103,153.637,103,120.5z"/>

    <cyril> <path fill="#FF0000" stroke="#000000"
    d="M151,114.5H37V0.5h114V114.5z"/>

    <cyril> </g>

    <cyril> <filter id="X" filterUnits="objectBoundingBox" x="-50"
    y="-50"

    <cyril> width="100" height="100">

    <cyril> <feImage xlink:href="#BoverA" result="blah"/>

    <cyril> <feComposite in="SourceGraphic" in2="blah"
    operator="multiply"/>

    <cyril> </filter>

    <cyril> </defs>

    <cyril> this introduces the filter element

    <cyril> whereas:

    <cyril> <?xml version="1.0" encoding="utf-8"?>

    <cyril> <svg>

    <cyril> <path fill="#00FFFF" stroke="#000000"
    d="M103,120.5c0-33.137,26.863-60,60-60c33.137,0,60,26.863,60,60s-

    <cyril> 26.863,60-60,60

    <cyril> C129.863,180.5,103,153.637,103,120.5z"/>

    <cyril> <path fill="#FF0000" stroke="#000000"
    d="M151,114.5H37V0.5h114V114.5z"/>

    <cyril> <path fill="#00FF00" stroke="#000000" comp-op="multiply"
    d="M223,69.5l-51,58l-76-97L223,69.5z"/>

    <cyril> </svg>

    <cyril> is much closer to the original

    rc: ok, so the argument is that it is easier to use.

    ag: thre is more than an ease of use issue, there are functional
    limitation, the background is included twice.

    <cyril> Note that

    <cyril> using feBackground has the effect of the background being
    used twice – once

    <cyril> as an input in the filter – and a second time as the result
    being drawn onto….

    <cyril> If the background is not initially opaque this causes
    strange effects.

    rc: I have proposed to separate the spec. in two. For PD, you never
    need the background.
    ... explains the way PD happens within a group and does not effect
    anything outside the group.

    <svg>

    <rect id="r1">

    <g>

    <rect id="r2">

    <rect id="r3">

    </g>

    No matter what the compositing operator is on r3, it only composites
    with the content of <g> at the time it is rendered. In this example,
    only with r2. There is no compositing done with r1 when rendering
    r3.

    The rendering of <g> will then composite with r1.

    <Anthony> [63]http://www.svgopen.org/2005/papers/abstractsvgopen/

      [63] http://www.svgopen.org/2005/papers/abstractsvgopen/

    Discussion on enable-background and compositing, looking at the
    examples in section 8 of
    [64]http://www.svgopen.org/2005/papers/abstractsvgopen/.

      [64] http://www.svgopen.org/2005/papers/abstractsvgopen/.

    There is agreement that compositing is done between a src and dst
    and that following the painter's algorithm, the default dst would be
    the content of the parent group at the time an element is rendered
    (i.e., the rendering of the element's previous siblings in the
    parent group). There might be use cases for compositing with the a
    destination that contains the rendering of the parent group's
    siblings. In the preceding example, it means that r3 would

    composite with either the content of its parent group (r2 only) or,
    in a different mode, with the content of r1 and what is already in
    it's parent group (r2).

    ag: the reason for the naming of new/accumulate is that it describes
    the initialization of the group buffer used with compositing.

    <scribe> ACTION: cyril to work with Rik and discuss with Alex to
    resolve whether, for the purpose of compositing only, we need a
    control to select the destination used for the compositing
    operation. [recorded in
    [65]http://www.w3.org/2012/01/12-svg-minutes.html#action15]

    <trackbot> Created ACTION-3221 - Work with Rik and discuss with Alex
    to resolve whether, for the purpose of compositing only, we need a
    control to select the destination used for the compositing
    operation. [on Cyril Concolato - due 2012-01-20].

    Moving on to blending.

    (discussion about enable-background in blending context).

    <svg>

    <rect id="r1">

    <g>

    <rect id="r2">

    </g>

    r2 is multiply

    g is is enable-background: accumulate

    Agreement that in both compositing and blending, the behavior and
    controls for enable-background are the same. In both cases, the need
    is to control how the 'group' buffer is initialized before it is
    used as an input in the blending or compositing operation.

    (demo of compositing, blending and knockout groups in a popular
    illustration authoring tool)

    <cabanier> example of knockout and enable-background:
    [66]http://lists.w3.org/Archives/Public/www-archive/2012Jan/att-0007
    /KO_isolate.pdf

      [66] 
http://lists.w3.org/Archives/Public/www-archive/2012Jan/att-0007/KO_isolate.pdf

    RESOLUTION: the group agrees to separate compositing from blending
    in the specification. The group agrees to add the missing blend
    modes. The group agrees to have the default blend mode to be
    'normal'.

    <scribe> ACTION: rik to resolve issues on clip-to-self,
    enable-background on compositing and knock-out. [recorded in
    [67]http://www.w3.org/2012/01/12-svg-minutes.html#action16]

    <trackbot> Created ACTION-3222 - Resolve issues on clip-to-self,
    enable-background on compositing and knock-out. [on Rik Cabanier -
    due 2012-01-20].

Summary of Action Items

    [NEW] ACTION: Brian to look for text in SVG/SMIL that suggests using
    different calcMode's based on the values used (enum values versus
    numeric) [recorded in
    [68]http://www.w3.org/2012/01/12-svg-minutes.html#action04]
    [NEW] ACTION: Cameron to contact Dr. Olaf Hoffmann to ask what is
    specifically required to make to-animation similar to CSS
    transitions [recorded in
    [69]http://www.w3.org/2012/01/12-svg-minutes.html#action02]
    [NEW] ACTION: Cameron to describe using shorthand properties as
    presentation attributes in spec [recorded in
    [70]http://www.w3.org/2012/01/12-svg-minutes.html#action01]
    [NEW] ACTION: chris to continue to work on test suite linking
    mechanism for new harness [recorded in
    [71]http://www.w3.org/2012/01/12-svg-minutes.html#action06]
    [NEW] ACTION: Chris to review CSS UI [recorded in
    [72]http://www.w3.org/2012/01/12-svg-minutes.html#action12]
    [NEW] ACTION: Chris to write up a proposal for allowing linear
    interpolation of properties that were previously discrete but could
    be reasonably interpolated linearly [recorded in
    [73]http://www.w3.org/2012/01/12-svg-minutes.html#action03]
    [NEW] ACTION: Cyril to investigate different methods for adding
    transform in animation [recorded in
    [74]http://www.w3.org/2012/01/12-svg-minutes.html#action05]
    [NEW] ACTION: Cyril to review CSS Image Values and Replaced Content
    Module Level 3 [recorded in
    [75]http://www.w3.org/2012/01/12-svg-minutes.html#action14]
    [NEW] ACTION: cyril to work with Rik and discuss with Alex to
    resolve whether, for the purpose of compositing only, we need a
    control to select the destination used for the compositing
    operation. [recorded in
    [76]http://www.w3.org/2012/01/12-svg-minutes.html#action15]
    [NEW] ACTION: Erik to check in an example on how to use the
    testharness.js [recorded in
    [77]http://www.w3.org/2012/01/12-svg-minutes.html#action10]
    [NEW] ACTION: erik to remind people early March 2012 about
    prioritisation [recorded in
    [78]http://www.w3.org/2012/01/12-svg-minutes.html#action07]
    [NEW] ACTION: Erik to review the 3 specs [recorded in
    [79]http://www.w3.org/2012/01/12-svg-minutes.html#action13]
    [NEW] ACTION: heycam to make a form for priorities [recorded in
    [80]http://www.w3.org/2012/01/12-svg-minutes.html#action08]
    [NEW] ACTION: heycam to revise getBBoxof proposal based on this
    discussion [recorded in
    [81]http://www.w3.org/2012/01/12-svg-minutes.html#action09]
    [NEW] ACTION: rik to resolve issues on clip-to-self,
    enable-background on compositing and knock-out. [recorded in
    [82]http://www.w3.org/2012/01/12-svg-minutes.html#action16]
    [NEW] ACTION: Vincent to review the Shadow DOM draft [recorded in
    [83]http://www.w3.org/2012/01/12-svg-minutes.html#action11]

    [End of minutes]
      _________________________________________________________
Received on Friday, 13 January 2012 06:46:09 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:50 GMT