W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2011

Minutes January 31 2011 public-fx telcon

From: Erik Dahlstrom <ed@opera.com>
Date: Mon, 31 Jan 2011 23:04:23 +0100
To: "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <op.vp60xlclgeuyw5@mbp-2.local>


and in text form:


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

                                - DRAFT -

                    CSS-SVG Task Force Teleconference

31 Jan 2011



    See also: [3]IRC log

       [3] http://www.w3.org/2011/01/31-fx-irc


           heycam, smfr, dbaron, [IPcaller], ed, Doug_Schepers,
           +1.408.881.aaaa, dino, anthony_work, +1.415.920.aabb,




      * [4]Topics
          1. [5]SVG/CSS filters
          2. [6]alignment-baseline initial value being different between
             SVG and CSS
          3. [7]animationFramerate
      * [8]Summary of Action Items

    <trackbot> Date: 31 January 2011

    <dino> i cannot scribe today

    <dino> i will be leaving early

    <heycam> Scribe: Cameron

    <heycam> ScribeNick: heycam

SVG/CSS filters

    ED: i just wanted to go over what i've done so far with this
    ... and that is basically just to move the SVG 1.2 filters module
    over to the public fx repository
    ... and to set up the build scripts so that it can build from that
    ... bascially at the moment it's requiring the svg subdirectory to
    be checked out as well, since it's pulling the java tools from there
    ... i also started a wiki page trying to summarise some of the email
    ... haven't got everything yet, been a lot of discussions on the
    ... what i wanted to hear from you guys is what direction you'd like
    this to take
    ... would you prefer having one spec or two? one for css
    specifically and one for svg, or a joint one?

    <shepazu> [I'd like a joint one]

    SF: there's ambiguity about what applies to svg and what to css

    DS: it can be called out

    SF: UAs that implement both have to be compliant with both parts of
    the spec

    DS: isn't that the goal?

    SF: with transforms as well, if we want to advance one faster than
    the other, then it's going to take longer to get compliant

    ED: i can see the problem with that. otoh there are already
    implementations of the svg filters, so i wouldn't expect minor
    changes or additions to the svg side of things to have a slow down

    SF: implmentations compliant with svg filters would no longer be
    compliant, because of the css parts, right?

    ED: depends how you set up the conformance classes

    DB: i would think the normal way to do it would be to have two
    conformance definitions, and you can meet one or both

    ED: yeah

    SF: ok that sounds fine

    ED: if eveyrone is on board with that, i'll start merging some of
    the mozilla proposals
    ... bascially to allow the html/css cases to use the svg filters
    ... at the moment what's in the spec is kidn of loose, and the host
    language has to define the regions and the input keywords

    DS: do you have a link?



    ED: it's mostly the same as the 1.2 filters that got published, some
    minor changes
    ... i will have to go over it again, making sure we have all the
    changes from 1.1SE, there've been some minor changes there

    DS: do you talk at all about canned effects?

    ED: at the moment it's mostly dealing with the svg side of things,
    and i would like to have some sort of css canned effects, a simpler
    syntax, for common effects as has been discussed on the list

    DS: there's been a lot of discussion on the css list about this
    ... i think to build excitement/interest abotu this, it might be
    useful for us to have some wording in there

    ED: i agree

    <ed> [10]http://www.w3.org/Graphics/fx/wiki/Filter_effects

      [10] http://www.w3.org/Graphics/fx/wiki/Filter_effects

    ED: if you look at the wiki page, i have summarised some of the
    proposals/wishes for common primitives
    ... like i said, this is not everything, i haven't gone through the
    whole email thread yet, but it's a start
    ... and i'd like to structure it like this and keep it on the wiki,
    it's easier to get an overview
    ... i'll use that as a starting point. i'm not at this point
    concerned about the syntax itself, just the general idea of having
    ... i can probably start putting some suggestions into the draft, if
    that sounds like a good idea
    ... i think some of the more common ones like blur/glow would be
    something i could put in relatively quickly

    DS: i think that would be great
    ... we can poitn people to that and it could help spur the
    conversation, having something concrete in there
    ... regardless of whether that's the exact way we do it

    ED: i think there's still a lot of changes on the svg side of things
    that i've been planning to do, but haven't got to
    ... some are in the svg tracker
    ... i will try to do my edits on the public fx repository now, going
    ... and just leave the svg part of it as it was

    CM: does that mean we're definitely going forward with a single

    ED: yes going forward, that's what i'm hearing

    DS: it's my preference

    ED: my requirement is to keep the actual implementation side of
    things compatible between the svg and css
    ... so that we can have some common ground, making the
    implementation easier for everyone

    <dino> my only concern with single specs is that they tend to make
    little progress overall. it always seems faster to combine
    afterwards. not a big deal.

    ED: even if the syntax may not exactly be the same
    ... the point about the repository, is that something we should try
    to do right away? moving to hg?

    <smfr> hg, not git?

    DS: i've just been using mercurial for the web events specs, and
    it's pretty cool, people can fork and fold changes back in more

    <dino> do we really want forks of specs?

    DS: since this group is more collaborative by nature, with multiple
    editors, it might be an interesting way forward

    SF: is hg something used by other groups? i remember hearing
    something about git rather than hg

    DS: i don't think w3c supports git, they chose hg in the end
    ... relatedly, i've been using berjon's respec, and really like it a
    lot. we might consider it. but let's have that conversation on the

    ED: simon, you said you'd like to be coeditor on the filters spec?

    SF: me, or maybe dean is interested

    DJ: yeah you can put me down as interested

    <shepazu> ACTION: shepazu to get an HG repo set up for FX [recorded
    in [11]http://www.w3.org/2011/01/31-fx-minutes.html#action01]

    <trackbot> Created ACTION-24 - Get an HG repo set up for FX [on Doug
    Schepers - due 2011-02-07].

    ED: the other minor thing is what to call the spec itself, do we
    need a new name for it?
    ... or is that too earlier?

    DS: filter effects 1.0?

    SF: sounds good

    ED: i guess it's fine to go ahead and start changing the spec
    itself, if you want to have a go at it
    ... my first edit will probably be to fold in the filter proposal
    from mozilla
    ... and then try to merge back some of the changes from svg 1.1
    second edition, minor things
    ... and another major thing is removing the margin attributes, which
    were originally added from svg 1.2 full
    ... but the consensus seems to be that it's a bit clunky, and we
    should look at other ways of doing clipping of filters
    ... e.g. to make sure that blurs aren't clipped at the edges, and
    you just get the effect you're after
    ... there are some bugs in inkscape where the filter size attribtues
    are set too small and that causes issues when viewing
    ... so aiming to fix those cases, and making it easier to use
    ... i don't see the point in making it more complex to control the
    filter region

    CM: sometimes you want to clip some of the filter region out, would
    there be a way to do that?

    ED: we would need to add something to allow that

    DB: i think we have code that tracks how much different filter
    effects extend, so we could work it out, without adding much code
    ... since we have that infomration for invalidation

    ED: same

    SF: same for webkit, e.g. with box shaodw you need a larger
    invalidation rect

    CM: there was also discussion about parameterised filters

    ED: i think the first thing to do is look at the common effects
    people are after
    ... blur/glow/etc for example
    ... we should put those in as a first step
    ... trying to figure out the rest on the wiki, from the email
    threads, is probably a good second step
    ... and we can proceed from there

    DJ: there've been lots of proposals, and i tend not to like the ones
    where the idea is to define something in svg and somehow expose that
    as a shorthand in css, where you can pass in params
    ... the set of available filters, is small enough that you could
    define the svg equivalent and just call it "blur" with one
    ... and a sharpening, you know what the one parameter is, etc.
    ... seems like that's much simpler to implement than coming up with
    a lgnauge where you define a parameterisation scheme
    ... and in fact, the good thing is that it falls back nicely you
    could implement it in svg anyway
    ... let's say you did 'filter: blur(10) sharpen(5)
    ... you could easily transcode that into an svg filter chain

    DB: there are also cases like shadows where they don't want a direct
    chain of filters, they want to composite that with some other
    non-shadowed part

    ED: where do you draw the line?

    DJ: i think in most cases people will apply these to images, or a
    standalone thing like a single element
    ... if they do it to a tree of things...
    ... let's make the simple things simple, and fall back to
    complicated svg things if they need something complex

    DB: i guess that's probably ok

    DJ: the other huge advantage here is that it makes animation of
    filters very simple, we know exactly what the parameters are for the
    canned filters
    ... while we've defined how it might work exactly with svg filters,
    you might not implement it that way
    ... you know in adance you'll animate some parameter
    ... so you can get better performance

    DS: i think that's a great point

    SF: you're saying all filters in css are canned?

    DJ: no you'd still allow url(somesvg), but you'd define some
    precanned ones
    ... i don't think we need to define a full parametersiation syntax
    ... where the svg filter can expose a param via a name
    ... the list on the wiki is a great start, let's look around for
    others people use, anything more complex just use url() and point to

    DS: that's how i'd expect it to work
    ... when i was referring to parameterisation, whether you can say
    more blur/less blur, what direction it's in

    DJ: it was an interesting suggestion, the ability to mark up svg
    with parameters, and expose that to css
    ... if i write deanblur, a gaussian blur plus a hue rotation, i
    could expose the blur radius to css -- i don't think we want to go
    there yet
    ... there's a simple set of filters we want to tick off before we go
    down that path

    DS: thanks, my idea of parametersiation was that simply it'd be a
    css function and you'd give a blur direction, stddeviation, etc.
    ... so we're on the same page there
    ... with regards to real parametersiation, the svg parameters spec
    would be fine for that
    ... it's not specific to filters, but we can have that discussion
    ... i'm with you that having the simplest solution first is probably
    the best way forward
    ... so all of what you described is what i meant by canned effects

    ED: dean or simon, you can go and propose some syntax for the canned
    ... my first changes won't touch that yet

    <dino> yes, sure

alignment-baseline initial value being different between SVG and CSS

    <ed> scribeNikck: ed

    <ed> scribeNick: ed

    CM: in the svg testsuite we have a test, *dropping link in*


      [12] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/text-align-07-t.svg

    CM: this test asserts that the different set of glyphs are supposed
    to align with the three baselines
    ... it's using the alignment-baseline property
    ... while investigating this test, i found the definitions between
    CSS3 linebox and SVG are slightly different
    ... in svg initial value is auto
    ... in css there's a keyword 'use-script' that gives the behaviour
    the test expects
    ... in css the inital value is baseline
    ... each set of glyphs in a fontsize establish a separate group for
    alignment purposes

    EE: CSS3 linebox hasn't been actively edited for some years
    ... doesn't make sense to align to the different baseline, how do
    you handle punctiuation characters?

    CM: there's a referral to the text-script property

    EE: you're going to pick a dominant baseline for all your text,
    otherwise it's going to look weird
    ... having different glyphs aligned to different baselines, mixing
    numbers, alphabetic text and indic text for example
    ... there shouldn't be a value that picks a baseline for each
    ... it should be per element
    ... not per character, that doesn't make any sense

    CM: in css3 linebox, the use-script value should be dropped

    DS: so we should drop this test from the svg testsuite
    ... and going forward align with css

    CM: is the spec going to be worked on again?

    EE: john daggett will work on it
    ... you may want to keep a test to align to the alphabetic baseline,
    which is what i believe most implementations do atm

    DS: do we need to change the SVG 1.1 spec to deal with this?

    CM: possibly
    ... kind of a big change

    DS: suggest that we remove the relevant section, and drop the test
    for now

    CM: the alignment-baseline property (in svg 1.1)

    DS: or worry about the spec change later
    ... it's not clear what the implications of changing it would be

    CM: aligning with css text stuff will come up in context of the
    vertical text stuff in css
    ... will people never want to align to different baselines like the
    test expects?

    EE: maybe, but you could do that using spans and styling
    ... for a given run of text you'd want one baseline
    ... doing it per character doesn't really make a lot of sense to me
    ... especially considering shared classes, like numerical characters
    and punctuation

    <explanation about fonts and glyphs and baselines>

    DS: so let's bring this back to the svgwg

    CM: curious about the use-cases

    <scribe> ACTION: CM to ask XSL WG about the use-cases for
    alignment-baseline=use-script (or equivalent) [recorded in

    <trackbot> Created ACTION-25 - Ask XSL WG about the use-cases for
    alignment-baseline=use-script (or equivalent) [on Cameron McCormack
    - due 2011-02-07].


    CM: we want to bring this to the WG to standardise
    ... could be done in the FXTF and put into the SVG charter

    SF: we're interested in it
    ... for canvas games and canvas animations

    CM: my first choice was webapps, but it's hard to add specs to

    SF: what about Html?

    CM: hadn't considered, maybe
    ... i've started writing something up... to help discussions on the

    DS: it's a challenge to add things to existing charters
    ... but if we have the right people involved it doesn't really
    matter in which charter it is, or in which group/taskforce

    SF: it's fine to work on a proposal, we'll figure out where it
    should go

    DS: why would it be a problem in svg?
    ... it's something that will cover svg, canvas, html and webapps...
    ... don't see a problem keeping it in the FXTF
    ... it's mostly an issue of finding the right people to work on it,
    and i think we have these here in FX

    <smfr> requestAnimationFrame, yeah

    RESOLUTION: to start work on requestAnimationFrame in the FXTF

    trackbot, end telcon

Summary of Action Items

    [NEW] ACTION: CM to ask XSL WG about the use-cases for
    alignment-baseline=use-script (or equivalent) [recorded in
    [NEW] ACTION: shepazu to get an HG repo set up for FX [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [16]scribe.perl version 1.135
     ([17]CVS log)
     $Date: 2011/01/31 22:01:58 $

      [16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [17] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20
Check for newer version at [18]http://dev.w3.org/cvsweb/~checkout~/2002

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/that/whether that/
Succeeded: s/blur 10 sharpen 5/blur(10) sharpen(5)/
Found Scribe: Cameron
WARNING: No scribe lines found matching ScribeNick pattern: <Cameron> .
Found ScribeNick: heycam
Found ScribeNick: ed
ScribeNicks: heycam, ed
Default Present: heycam, smfr, dbaron, [IPcaller], ed, Doug_Schepers, +
1.408.881.aaaa, dino, anthony_work, +1.415.920.aabb, fantasai
Present: heycam smfr dbaron [IPcaller] ed Doug_Schepers +1.408.881.aaaa
  dino anthony_work +1.415.920.aabb fantasai
Agenda: [19]http://lists.w3.org/Archives/Public/public-fx/2011JanMar/00


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 31 Jan 2011
Guessing minutes URL: [20]http://www.w3.org/2011/01/31-fx-minutes.html
People with action items: cm shepazu

      [20] http://www.w3.org/2011/01/31-fx-minutes.html

    End of [21]scribe.perl diagnostic output]

      [21] 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 Monday, 31 January 2011 22:05:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:37 UTC