See also: IRC log
<trackbot> Date: 31 January 2011
<dino> i cannot scribe today
<dino> i will be leaving early
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
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
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: 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: if you look at the wiki page,
i have summarised some of the proposals/wishes for common
... 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
... 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
... 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
... 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
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
... 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
... 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
<ed> scribeNikck: ed
<ed> scribeNick: ed
CM: in the svg testsuite we have a test, *dropping link in*
CM: this test asserts that the
different set of glyphs are supposed to align with the three
... 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
... 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
... 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?
... 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
... 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 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].
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,
... 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
... 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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at 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: http://lists.w3.org/Archives/Public/public-fx/2011JanMar/0042.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 31 Jan 2011 Guessing minutes URL: http://www.w3.org/2011/01/31-fx-minutes.html People with action items: cm shepazu[End of scribe.perl diagnostic output]