- From: Erik Dahlstrom <ed@opera.com>
- Date: Mon, 31 Jan 2011 23:04:23 +0100
- To: "public-fx@w3.org" <public-fx@w3.org>
Minutes:
http://www.w3.org/2011/01/31-fx-minutes.html
and in text form:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
CSS-SVG Task Force Teleconference
31 Jan 2011
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-fx/2011JanMar/0042.html
See also: [3]IRC log
[3] http://www.w3.org/2011/01/31-fx-irc
Attendees
Present
heycam, smfr, dbaron, [IPcaller], ed, Doug_Schepers,
+1.408.881.aaaa, dino, anthony_work, +1.415.920.aabb,
fantasai
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Cameron
Contents
* [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
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>
[9]http://dev.w3.org/Graphics-FX/modules/filters/publish/SVGFilter.h
tml
[9]
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> [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
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 [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
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>
[12]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/text-align-07-t.sv
g
[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
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
<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
[13]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
Summary of Action Items
[NEW] ACTION: CM to ask XSL WG about the use-cases for
alignment-baseline=use-script (or equivalent) [recorded in
[14]http://www.w3.org/2011/01/31-fx-minutes.html#action02]
[NEW] ACTION: shepazu to get an HG repo set up for FX [recorded in
[15]http://www.w3.org/2011/01/31-fx-minutes.html#action01]
[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
/scribe/
[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
42.html
[19]
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: [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