CSS-SVG Task Force Teleconference -- 31 Jan 2011

<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 location
... 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 threads
... haven't got everything yet, been a lot of discussions on the list
... 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 implementations

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 effect

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 directly
... 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> http://dev.w3.org/Graphics-FX/modules/filters/publish/SVGFilter.html

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> 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 it.
... 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 forward
... and just leave the svg part of it as it was

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

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 easily

<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 list.

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 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 parameters
... 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 yet
... 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 svg

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 later
... 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 filters
... 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*

<heycam> 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 character
... 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

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 http://www.w3.org/2011/01/31-fx-minutes.html#action02]

<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].

animationFramerate

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 webapps

SF: what about Html?

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

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

- DRAFT -

CSS-SVG Task Force Teleconference

31 Jan 2011

Attendees

Contents

SVG/CSS filters

alignment-baseline initial value being different between SVG and CSS

animationFramerate

Summary of Action Items

Scribe.perl diagnostic output