<trackbot> Date: 09 November 2009

<scribe> Scribe: anthony

CSS and SVG Filters

<ed_work> filter: <uri> | none | inherit | <shorthand>

<ed_work> <shorthand>: dropshadow(<shadow>) | grayscale | sepiatone | motionblur(<direction>, <length>[, <color>]) | flipX | flipY | glow(<color>[, <length>][, <length>])

ED: I'm suggesting to add a new syntax for the filter property

<ed_work> <shadow>: (as defined in http://www.w3.org/TR/css3-text/#text-shadow)

ED: It might be a good idea to have those short hands as elements as well
... some are really simple mappings
... some others might need to be a new element e.g. motion blur
... we sort of have motion blur, but not arbitrary
... not in any direction

DS: So it will be primitive built on top of another primitive?

ED: Probably
... Not sure either if it would be nice to have multiple changed effects
... like dropShadow, greyscale
... CSS could focus on various parts such as the boarder
... could use SVG params to map those
... could add different keyWords to the 'in' attributes
... could extend filters for CSS
... if you want to dropShadow the boarder and greyscale the image

DS: Give multiple inputs using params syntax

ED: I see the short hand as a quick way of doing things
... If the URI is used, need a way of passing parameters in

DS: What if there were an feExclude element

<ed> <feDropShadow in="CSSBorder" stdDeviation="3"/>

DS: could use it to exclude various parts of the SVG when rendering them
... Could extend the URI to be a list
... an ordered list

ED: May want to chain the filter effects
... could want some of them as values and some elements

AG: Regarding greyscale filter
... what do you think about the idea of colour preservation when applying a greyscale transform on an image
... e.g. preserving the colour of a red rose in a photo. The rest of the photo will go greyscale except for a certain area or colour

ED: Might need a new element for that

AG: Have to think about that one

DS: I was talking about something similar with people at TPAC
... shift only a certain colour range

AG: Was thinking of both, having a box around an area to preserve
... or a range of colours to preserver
... Could find certain colour areas, then blur them

ED: Can do that using clipping and filters together

Parameters Specification

ED: I'm curious about how this will effect the filters syntax

DS: I showed the parameters primer to the CSS working group
... which included two designers
... Everyone in CSS Working Group were really excited about this
... there were some issues, one of the issues pointed out by Dave S in Apple
... is where is the transformation happening?
... I said it was happening client side
... he said then the question mark syntax is a server side syntax
... I didn't realise it was for server side processing
... need to come up with another syntax
... could use '#' type syntax
... I saw the '$'

AG: I don't think the '$' is used

DS: I spoke to some URI people about this
... and they didn't say you could specify how it's processed on the server side
... but in the context of SVG
... you could say it applies to parameters
... '$' is used to denote variables in some scripting languages
... if it was processed server side using the '?'
... could send the file to the client
... with a different delimiter browers could be smart about caching

ED: I'm already using the '?' for some images

DS: You are using SVG params?

ED: Sort of. Problem is have to URL encode
... to pass in params
... Like I write something readable, then URL encode it and it becomes unreadable

<ed> ...or at least semi-unreadable, depending on what's in the params :)

AG: Also consider '!', I don't think that is used

DS: Anyone of those three ('?', '$', '!') sounds fine to me
... just need to investigate pros and cons of each
... CSS and SVG will be discussing params on public-fx

ED: If you have a plug-in you'd probably only be able to send the params once
... because that's the way the API works
... if the implementation is all native
... then it's probably not all that difficult to keep track of the changes

DS: This is possibly something that could be dealt with more specifically in HTML
... I suspect that plug-ins would like to get parameters updated
... Geolocation API

<scribe> ACTION: Doug to Talk to Julian R about plug-in API and changing parameters [recorded in http://www.w3.org/2009/11/09-svg-minutes.html#action01]

<trackbot> Created ACTION-2689 - Talk to Julian R about plug-in API and changing parameters [on Doug Schepers - due 2009-11-16].

<shepazu> s/PAI/API updates, for example

Face-to-face meeting

AG: Just wondering when everyone is free
... in February

ED: away 18th - 22nd Feb

DS: conflict I was thinking about is in April
... late Jan is fine with me

ED: Late Jan is with me as well

DS: Not sure if Chris will be able to attend
... it would be good to have a co-located SVG/CSS face-to-face

AG: Do you know when CSS is meeting again?

DS: They did decide the dates, don't know what they are
... if we had a meeting in France
... that would allow Chris to attend
... could have overlapping meeting Mon - Wed for SVG and Wed - Fri for CSS
... if we could get XSL-FO in there
... that would be good
... XSL-FO is doing wrapping to arbitrary shapes
... we want to do this also
... I think this is something we should all be collaborating on

<scribe> ACTION: Doug to Find out when CSS is meeting [recorded in http://www.w3.org/2009/11/09-svg-minutes.html#action02]

<trackbot> Created ACTION-2690 - Find out when CSS is meeting [on Doug Schepers - due 2009-11-16].

SVG DOM

DS: Been talking to alot of people about SVG DOM
... implementers, Brad Neuberg, Alex from Dojo
... it's pretty clear we need to change the SVG DOM at this point
... may need to change the DOM in general
... having an interface on every element
... even if there are not attributes seems overkill
... so I had the idea of having a DOM Summit
... who have experience in creating DOM
... people who would be targets implementers and authors
... have a two or three day summit
... to figure out a good design
... I already have offers to host it
... in California
... possibly in January
... which means we'd have a Feb face-to-face
... I'd want this to be an SVG DOM discussion
... we need to cater this for people in the Valley
... TC39 are interested
... (Technical Committee 39 of ECMA)
... A couple of things I'd like to cover
... an API that works for SVG and Canvas
... A math library that covers points and vectors in addition to matrices
... would solve a lot of layout and position problems
... trigonometric and geometric library

ED: Should make sure that the CSS Transforms DOM and SVG Transforms DOM are compatible
... CSS Transforms spec defines new interfaces for getting to the transforms in the DOM
... which is different to SVG Transforms
... would be nice to use one Transform only

DS: I talked to a bunch of people about a revised SMIL spec
... probably SMIRC (Synchronised Multimedia for Integrated Rendering and Capturing)
... largely based on SMIL
... stripped down SMIL that is profiled
... so it would probably happen as a task force between CSS, SVG and HTML
... would let us take a good look at use case and requirements
... would be tightening of wording and probably allow for SCXML to allow for state machine
... pretty clear to me that the SVG Working Group needs more resources

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/PAI/API/
FAILED: s/PAI/API updates, for example/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: Shepazu, ed, anthony
Present: Shepazu ed anthony
Found Date: 09 Nov 2009
Guessing minutes URL: http://www.w3.org/2009/11/09-svg-minutes.html
People with action items: doug