SVG Working Group Teleconference -- 02 Mar 2011

<trackbot> Date: 02 March 2011

<birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements

<birtles> Presentation: http://brian.sol1.net/svg/pres/SVG 2 Animation.html

<birtles> Presentation: http://brian.sol1.net/svg/pres/SVG%202%20Animation.html

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

overflow auto

RO: the spec currently says that overflow:auto should be treated as visible
... that is incorrect
... in non SVG contexts, overflow:auto clips
... scrollbars if necessary, btu always clips
... for consistency, overflow:auto should be interpreted as clipping
... I don't think we should add scrollbars in SVG
... it's a pain
... we don't have that feature currently, don't want to add it now
... so we should make overflow:auto clip to be consistent with HTML

ED: are the use cases for HTML and SVG different?
... for us, implementation wise it's cheaper to not clip
... but that's a detail
... in that sense I don't really care
... it makes it easier for people not to clip

RO: auto is not the default value
... the default is visible
... so it only affects people who say overflow:auto
... people setting overflow:auto and expecting it to have no effect is unlikely

DS: what about scroll?

RO: the spec says treat it as hidden
... I'm saying treat overflow: auto, scroll, hidden all the same
... we provide scrollbars on the viewport
... but this is for a non-root element
... the root element is special

DS: ah ok

RO: css defines that, and we do that for svg
... which makes sense
... this is for non-root SVG elements

CM: how does this relate to markers?

ED: markers are overflow:hidden by default

RO: so that would be totally unaffected

ED: we probably need more tests around overflow

RO: CSS is reinterpreting overflow as a shorthand for overflow-x and overflow-y
... if one of them is not visible, then the other one is treated as hidden
... so you can't clip in one axis only
... SVG should probably change that, but that's a separate issue
... so we need to add text to say that overflow: auto, hidden and scroll should all clip

RESOLUTION: overflow:auto will be treated as hidden

shorthand presentation attributes

CM: if overflow becomes a shorthand, then what happens to the overflow="" presentation attribute?
... we have rules to say that we don't have presentation attributes for shorthands
... I think that should change

<scribe> ACTION: Cameron to write a proposal for allowing shorthand presentation attributes [recorded in http://www.w3.org/2011/03/02-svg-minutes.html#action01]

<trackbot> Created ACTION-2992 - Write a proposal for allowing shorthand presentation attributes [on Cameron McCormack - due 2011-03-09].

<anthony_nz> Scribe: Anthony

<anthony_nz> ScribeNick: anthony_nz

<birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements

<birtles> Presentation: http://brian.sol1.net/svg/pres/SVG%202%20Animation.html

Animation improvements

BB: The presentation is pretty much the same as what's on the wiki
... The topic is "what we are going to do with SMIL"
... want to keep it high level
... and decide on what direction we want to head
... What are we trying to solve with declarative animation?
... The presentation is just to give some background
... for discussion later on
... the question is what we want to do with SMIL: drop it, patch it or something in between
... [goes through presentation]

ROC: If you're creating the image from scratch, but if you want to import some other animated image and your tool doesn't understand the JS library that was used
... then you're stuck
... one thing that SMIL gives you is a standard vocabulary

BB: The trouble is what tools
... and I don't think that hasn't been realised yet

DS: We know we need tools for animation
... and that is going to emerge
... and it is important that we keep the facility in there to keep that interchange

ED: Wanted to say something about the first point. There is small possibility to optimise things if you know what's going to happen in the document
... with script it is a bit more difficult
... in animation it is more possible to do some optimisations

CM: There is probably still more chances for bridges between JS and animation
... have the timing done in the animation but have the values fed by script

DS: That actually comes close to defining a script library defined by animation

BB: [continues with presentation]

DS: One thing that SMIL can't do is get the mouse position. So perform animation based on mouse position
... you frequently want to move something around with the mouse and you want to be able to do that declaratively

BB: [Continues with presentation]
... [Slide: But SMIL isn't perfect...]
... [Slide: SMIL is complicated by syncbase timing]

ED: Between fragments you mean between separate SVG files?
... I don't think it's defined in the spec or in CDF

<ed> s/svg paths/svg fragments/

BB: [Slide: SMIL is complicated by syncbase timing contd.]
... [Slide: Remove syncbase timing and replace with time containers]
... [Slide: SMIL 3 time containers - <par>]
... [Slide: SMIL 3 time containers - <excl>]
... [Slide: SMIL 3 time containers - nested contd.]
... [Slide: Wins]

DH: What do you mean cancel the group?

BB: If you have all these animations grouped together and you end that group then all the children will end as well
... so allows you to cancel that chain which you previously couldn't do
... so that's one of the advantages of having time containers and sync based timing
... [Slide: Challenges]
... [Slide: Challenges contd.]

AG: You mean deprecating?

BB: Might be a bit harsh, just say somethings don't work with the new containers

DS: I basically deprecating, means we recommend don't using this feature

BB: One of the issues with sync based timing you need to go through all the events when you do a seek
... we can keep event based timing, because that would allow you to do a lot of the current use cases

DS: If you had them in the same time container, then you'd be guaranteed of syncronisation. I like that you can syncronise multiple resources
... then if event based timing doesn't guarantee that, then I'd be worried

BB: You can still syncronise event based timing using a time stamp

ED: Another point with sync based thing, is that if you have an SVG image would that impose some restrictions, because it's being suggested that eventbase timing wouldn't be allowed in svg-in-img

BB: Some complex interactions would not be supported
... where two different elements can trigger the animation

ED: There is a repeat event which is event based, but there's also repeat-value which isn't the same exactly as event-base

BB: But it describes a qualified repeat event
... ... [Slide: Limiting the scope]

CM: In SVG you use structure alot to control the rendering. If you introduce the containers control the timing

BB: As it stands that is an issue, and you would need to redo where you are putting all your animations and all that

DS: Bitflash based on one of their customers needs, added a state machine, I noticed one of the things you were going to talk about was reversing animations
... specifically they added SCXML
... the state machine was attractive because you could define how things interact under changed conditions
... if you're in this state do this thing, etc
... I authored to it and I found it very handy
... their extension of it would allow you keep the history of what had gone one
... navigating around a UI using the state machine would allow the reuse of animations
... it was completely declarative
... not sure where that fits with your proposal

BB: There is a whole bunch of stuff in the SMIL state and I was thinking about that recently
... because I thought it would be good to be able to track state more

DS: When we are talking about the animation use case, I think the state machine would be very useful for handling the sync for UI stuff
... I think we should take a serious look at it

<heycam> http://www.w3.org/TR/scxml/

BB: [Slide: Limiting the scope]
... [Slide: Structural manipulations need specification]
... not defined in SMIL so we need to

DS: They didn't anticipate script

CL: They were very much looking at authoring tools, because of the people involved
... One of the guys that really understands it has joined this working group now and he's interested in reworking it

<ed> (15min break)

BB: [Slide: Structural manipulations need specifications]

<tbah> I'm done for the night so Patrick could dial in direct (it was a better connection than through the bridge).

<pdengler_home> that's me

<birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements

<birtles> Presentation: http://brian.sol1.net/svg/pres/SVG%202%20Animation.html

BB: [Slide: Structural manipulations need specification]
... [Slide: Specify and test structural manipulations]
... [Slide: Discrete to-animation is counter-intuitive]
... [Slide: Fix discrete to-animation]
... [Slide: Frozen to-animation is broken]
... [Slide: The requirement for an end-instance time is confusing]
... Basically if doesn't find an end instance it just sits there

AD: It never starts

CM: Doesn't create the interval?

BB: After that first interval it will never find the end time
... [Slide: Fix end-instance condition]
... [Slide: min/max aren't necessary useful]

CM: Can you explain what the use cases are?

BB: Just put a cap on the length on your child animations without knowing anything about them

CL: If you have all these time animations and you want them to end a certain point then you specify the ending time for them
... then they all stop

BB: [Slide: animateTransform]

DS: One of the things I hate is the term "fill" on animations
... you had to determine by the context what "fill" meant

CM: In CSS it is animation-fill-mode

JW: What are the values?

CM: Before, after, both
... both means to fill backwards before the animation
... the property value you can't understand it in isolation

BB: [Slide: Reversing animations]

CL: So you had the mouse over the button and it grew as big as it could then went back to the original size
... SMIL doesn't have this concept

BB: [Slide: Add a reverse feature to time containers]

JW: Maybe call it rewind?

BB: [Slide: Add a reverse feature to time containers contd.]
... need to work out if want to do an ease in then an ease out or an ease in then an ease in going in reverse
... might need to do the exact reverse

AD: I think that would be the logical thing to do
... running the clock backwards
... would need to work out how to specify it

BB: [Slide: Re-use animations]
... [Slide: Re-use animations contd.]
... [Slide: Brief overview of SMIL Timesheets]

CL: That would be really nice with :target

BB: [Slide: Selectors can be nested]
... [Slide: Other features introduced by SMIL Timesheets]

DS: Can I trigger something manually for when I'm making a presentation

CL: You'd want two triggers in that case
... When the time hits or when I press the mouse

BB: Not sure
... [Slide: Consider integrating SMIL Timesheets]

CL: If you're animating class it's a discrete animation

BB: Need to define how it all gets resolved
... [Slide: Migration path]

CL: So the first one has a slight risks regarding confusions
... the second one is more what we are doing
... the third seems somewhat drastic but if we are combining SMIL and CSS animation then we are harmonising it
... At the end of the day it's also about animating HTML as well
... So I can see the third option as long as it does right

DS: I think using the word SMIL is somewhat dangerous, because SMIL can mean different things to different people
... There is also the case where people will compare it to SMIL
... There are some people out there that dislike SMIL so it might not be as friendly to them
... If we are going to change it dramatically, I'm not sure the second way makes sense
... We could have backwards compatibility with SVG 1.1

<pdengler_home2> I don't think I have been bashful about this. This is a great presentation. I believe we should focus on one animation engine/syntax. I thought this is what we exited Lyon with. Why would we continue to enhance something that no web developer is looking at? Let's take these ideas/proposals to CSS :)

DS: One concern I have is as flawed as it is, and if we are going to reinvent the wheel we should be careful about what we do
... we may introduce new problems
... so we need to be careful about what we do with the new stuff

<pdengler_home2> I don't disagree; just like in other areas (gradients, transforms, etc) this group has a lot of experience. We can contribute to a single effort and spread the knowledge more quickly.

AD: In terms of web animations 1.0. One of the things we want to achieve is harmony between CSS and SVG. We take the things that we think are good in SMIL
... and add that to Web 1.0 along with the new stuff
... I'm not talking about breaking with the syntax, I'm talking about taking a subset
... and adding that to Web animation 1.0
... We kind of deprecate the SMIL stuff we say is not useful but provide better alternatives

CL: It's a gradual already ramp up
... to a certain extent the process has already started
... it will be more widely available when we have first working draft

DS: I am curious about time lines
... when do we realistically think this could be done
... I'd like to see some of this stuff in the next releases of web browsers
... these time lines are important

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

JW: if there are resources available in the css animation community, and those in smil, and can collaborate in the short term, maybe it can happen quickly
... but I don't know if that will happen

AD: i really like the reverse stuff

JW: i'm more concerned about if we're chopping up smil, or doing something else, we should do it pretty soon

DS: i'm also concerned with having 3 major vendors here, with 1 mobile vendor, all on the same page
... we don't have google/webkit people here
... authoring tool people?

CL: authoring tool people would be unwise to start now, if we're going to change things
... unless you're right in the discussions

DS: so they should participate in the discussions
... content creators, too

<anthony_nz> Scribe: Anthony

<anthony_nz> ScribeNick: anthony_nz

<pdengler_home2> For this proposal, my key contributions are the scenarios and the properties/attributes that I think we need to animate to satisfy them.

<pdengler_home2> My approach is to keep the list of attributes/properties constrained also to simple types so as to no introduce complicated interpolation issues.

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/CSS_Animation

<pdengler_home2> This should is consistent with my original proposal last year to keep SVG 2.0 scenario and use case driven, and incremental.

PD: This is to reduce complexity

<pdengler_home2> Also, supports Jonathon’s desire to move quickly.

<pdengler_home2> Further simplification attempts to avoid the discussion of animVal by using the CSS model.

<pdengler_home2> Though there is a recommended proposal for promoting attributes to properties I was sufficiently convinced for good reasons why this is not a wise idea and these are indicate by Cameron here: http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation

<pdengler_home2> I like these proposals and could live with any that satisfy the scenarios put forth, and that don’t push us into a corner.

<pdengler_home2> The key is to also recognize the imperative need to coordinate with the CSS working group. I’ve tried contacting Dean with this proposal but I do not believe I got a response.

<pdengler_home2> As a group we should decide as to whether or not we should be doing this (obviously I think yes), if yes, then choose a model which does not paint us into a corner, and get it socialized quickly with CSS.

PD: I believe my proposal doesn't quite work given Cameron's comments

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation

CM: All this is based on that you should be able to use the CSS Animation syntax to target things which are currently not properties in SVG
... Section 1 presents a few different ways in achieving that goal
... Simplest on the surface would be to convert all these attributes we think are worth animating into properties
... then naturally they will animatable with CSS animations
... [Reads downsides from wiki]

CL: The definition in CSS 2.1 is very precise for width and height
... could run into problems with inheriting

CM: So this proposal is promoting to properties and using the exact names we have for attributes
... A major issue is that changes the distinction between attributes and properties
... There is a chance here to allow that sort of distinction to say which are styling attributes and which are presentation attributes

CL: We were thinking about this and we'd ask what would make sense to re-style on a graphic
... geometry ended up being content in that way

DS: One of the most important semantics about SVG is about how it is interpreted by accessibility agents
... and how SVG can be made accessible is not defined

CM: The next point against this proposal is the whole SVG DOM interface

ROC: We can have them reflect the CSS animated values
... and we can keep them

CM: Another issue is which particular set of attributes we'd promote to properties
... in this proposal I think you should convert all the animatable attributes

<pdengler_home2> The only objection I have to that is staging/timing

CM: this is so we have the same functionality between CSS animations
... I think Patrick argument is starting with a smaller set is it is achievable goal

<pdengler_home2> Interopolation is the item I worry about, but they may already be well specified with SMIL

CL: If we do a certain subset and they don't scale across then we've painted ourselves into a corner
... If we were going to promote things to properties then we'd do them all at once

<pdengler_home2> Either way we should nail the syntax that CSS animations and transitions need to pick up to target attributes and start there, yes?

CL: but I still think that is a bad idea
... because it has a lot problems

CM: This is probably the fundamental issue about how to target these attributes
... the biggest argument against this proposal is the names these attributes have
... we have attributes that have name as existing properties
... and we may limit CSS from expanding into certain areas

CL: One of the other differences between properties and attributes
... is properties can apply to all elements
... so if we have a circle radius, it means that every element has a circle radius

<pdengler_home2> Isn't that already the case with stop-color for example?

CL: it's pointless to have a radius on all elements
... In CSS they want to restrict the property set
... so if look at proposals they normally choose the proposal that has the least number of properties

ROC: We should actually check to see how many properties we have
... and what can be grouped together
... it is a lot of properties but you're adding more leverage to CSS

DS: Some people want to do more of what we do in SVG in CSS

<pdengler_home2> I thought it was generally agreed upon in Lyon that animating attributes in CSS was a goal. I agree that introducing more properties / aligning properties could take time. Could we start with attributes and worry about what’s a property and what does inheritance mean later (I realize this is against my proposal)

CM: So there already are CSS properties that only apply to certain SVG elements
... and like wise for HTML
... Second proposal is the same as the first
... but giving new names

CL: So it's really an alias

CM: They are given unique names to avoid conflicts and short names e.g. "r"
... You could introduce a circle radius attribute to maintain consistency and say how they both work
... and secondly you could break the naming correspondence

CL: I'd prefer to have a table that has the correspondence between the properties and the attributes
... I guess people may start putting it in as an attribute and wondering why it's not working

CM: Third is to not do an promotion

<pdengler_home2> Me too!

CM: and make attributes animatable by CSS Animations

<pdengler_home2> Yes, I changed my mind; I never came up with a syntax that worked but Cameron did.

CM: The simple way is to just allow the attribute names where you can put property name inside the key sets
... then it's unclear if it's a property name or attribute name
... you're stepping on the namespace area again

<pdengler_home2> YES! Perfect Chris!

CL: CSS has rect { transition: (attr x) 0.5s; animation: a 0.5s both infinite }

<AD> rect { transition: attr(x) 05.s ...

<pdengler_home2> ship it

ROC: attr() seems like the right thing to me
... because it's existing syntax and it's already there

CM: Downside is the animation attributes is quite different about how you specify properties
... The third code snippet is a different proposal in this domain

CL: How would you evaluate that one compared to attr()
... currently attr is used on the right hand-side of the ":"

CM: I don't think CSS people would be happy with using that in normal rule sets
... These last few code snippets have the same idea
... Why do I prefer promoting properties - it seems less of a hack
... doesn't require new syntax
... I like the idea of extending the scope of properties
... the downside is quite a small set

DS: I don't particularly care for the semantics argument
... the semantics argument is not a strong one in my opinion

CM: If we can animate these things with CSS animations why wouldn't you want style these things regularly

<pdengler_home2> Whether or not we want to style them, IMHO is a seperate argument. I don't want to style stdDeviation

DS: Because of all the problems with promoting them to properties

CM: Rest of the page is timing and interpolation functions and features that are missing
... and also how the sandwiches interact
... and a lot more so questions rather specific answers

ROC: First of all, David Baron will be implementing CSS Animations in Gecko
... he's got a lot of knowledge in Transitions and Animations

DS: So Chris do you predict any issues with putting attr on the left-hand side

CL: Some

ROC: In the context of animations it's doable
... in the context of actually doing it, it's probably not doable

CL: It depends on why we would be doing this
... if the point is to get CSS Animation to work
... if the point is to style anything

ROC: In the key frame stuff, it would work
... not for general stuff

PD: Is this also Transitions?

CL: Yes

CM: So you don't have a problem with attr() on the left-hand side of the ":"
... because you need that for Transitions

ROC: Why?

CL: Transitions are triggered by certain things - changes attribute

ROC: All Transitions says, when something changes make the change smooth

CM: [Writes on the board]
... rect {transition: attr(x) 1s}
... rect: hover {attr(x): 50x}

ROC: We shouldn't allow rect: hover

CM: So you're saying that CSS Transitions can never change attributes
... Patrick do you have any thoughts about transitions not working CSS styled transition animations?
... the second rule is a straight style rule
... what if you change the x in the DOM
... would that cause a Transition?

ROC: Yes

DS: If you already have the underlaying model, then changing the parser to set up the model seems trivial

CL: I agree
... it's the core animation stuff and how you do your display

<pdengler_home2> so attr() works on transitions, animations and selectors?

ROC: I would like to run it by David Baron

ED: I will ask the people at Opera

CM: The result of this discussion is that putting attr() in regular style rules on the left-hand side wouldn't work
... but the attr() in the Transition would still work

<pdengler_home2> rect:hover{attr(x): 50px}

PD: That's not supported?

CL: Correct
... you'd thrash the DOM doing it that way

CM: The work around is to make a CSS Animation
... because you can make the animation apply on the :hover
... We can discuss the proposal at the next FX call
... in two weeks

<ed> next fx telcon will be in two weeks time

CL: Get it finialised if we meet in June with CSS Working Group

RESOLUTION: We prefer to use the attr() solution that allows CSS animations to target SVG attributes directly rather promoting attributes to properties

<ed> (break for lunch)

<pdengler_home2> I sent some of you an email with files to support our intrinsic sizing discussion. If I am late, please begin without me and I will catch up. See the agenda page for clear information about what we discovered.

<pdengler_home2> Jonathan has been working on this for a while and shared his tests with all of us a long time ago.

<pdengler_home2> We wanted to share some tests back and perhaps we can use them as a test bed for the test framework discussed on Monday.

<pdengler_home2> We believe that these tests are accurate to the specification and where we believe the spec to be ambiguous, is within the spirit of the specification and/or interoperable.

<pdengler_home2> So we can start with what we found (http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Intrinsic_sizing_tests) and I can post a test page with images.

<pdengler_home2> For the tests, you will notice that indeed IE9 passes all of them; this is because we used these tests to develop our platform.

<pdengler_home2> As indicated on the email DL, after our latest platform preview we caught some sizing discrepancies between our implementation and the spec; we subsequently made adjustments

<pdengler_home2> At the time of the change we aligned with Firefox beta. I think Firefox made adjustments for interop based upon our implementation (I think that’s what Rob said).

<pdengler_home2> My apologies on this and my lack of communication on our last minute updates. They were fast and furious and as I promised these tests we want to contribute and believe that they accurately reflect the specification.

<pdengler_home2> (be back shortly0

<ed> i see that the examples patrick mailed out uses preserveAspectRatio="None" (caveat being that svg attributes are case-sensitive)

<ed> the keyword value that is

<ed> just one of the files: test_svg_viewbox_preserveratio.svg

<jwatt> scribe: Jonathan Watt

<jwatt> scribenick: jwatt

BB: do we want a new spec for Web Animations, or to continue work on SVG animation?

CM: so would Web Animations be an abstract spec about the model?

DS: I think a single spec

BB: I think we want this to apply to CSS properties in HTML, so have it separate to SVG

CM: would that allow <animate> et. al. in HTML documents?
... or just have those elements being in SVG fragments but being allowed to target CSS properties in HTML documents?

BB: defined in a way to allow HTML X to pull it in
... to target attributes if they wanted to do that

DS: I think DOM bindings should be defined in that spec

CM: separate spec sounds similar to the way we have separate SMIL specs now
... would it define elements that a host language can put it its own namespace?

BB: I don't want to make in so abstract that we're not giving elements with names

DH: it worries me slightly that we'll end up with four separate animation specs which people implement subsets of
... it seems like it might make more sense to keep in in the SVG spec

s/in in/it in/

scribe: to deserve the name "Web Animations" it would have to be a super-model to rule them all

BB: getting CSS animations in the same spec

DS: having a distinct and short name for the spec would have value
... I suggest we put something on paper as a single spec, try that, and split it if we have to

ROC: first I want to get everyone together to figure out what browsers currently do with SMIL and CSS animation integration
... and transitions
... how they interact

DS: it seems like the CSS stuff should override

ROC: having CSS animations override SMIL animVals makes sense to me
... I would put everything in one spec

DH: so scrap the CSS-animations spec its current incarnation?

ROC: I think so

<shepazu> s/so scrap the CSS-animations spec its current incarnation/so integrate the existing CSS animations spec into a single unified spec/

<scribe> ACTION: Jonathan to Get Daniel to talk to David about making a new harmonized animations spec [recorded in http://www.w3.org/2011/03/02-svg-minutes.html#action02]

<trackbot> Created ACTION-2993 - Get Daniel to talk to David about making a new harmonized animations spec [on Jonathan Watt - due 2011-03-10].

RESOLUTION: Try to bring the existing declarative animation spec work together into a single spec, with separate sections for CSS animation and SVG animation

<scribe> ACTION: Erik to bring up the one true animation spec on the fx call [recorded in http://www.w3.org/2011/03/02-svg-minutes.html#action03]

<trackbot> Created ACTION-2994 - Bring up the one true animation spec on the fx call [on Erik Dahlström - due 2011-03-10].

<birtles> scribenick: birtles

<scribe> Scribe: Brian

<pdengler_home2> can't understand

<pdengler_home2> Filters

<pdengler_home2> How about filters

<pdengler_home2> I have some text I wrote

SVG 2 / CSS Filters Module

<pdengler_home2> are we all on the same chat now?

<dholbert> I'm here

<dholbert> heycam, can you see me? :)

<heycam> ACTION: Cameron to bring up the CSS-animations-targetting-SVG-attribtues in the next FX telcon [recorded in http://www.w3.org/2011/03/02-svg-minutes.html#action04]

<trackbot> Created ACTION-2995 - Bring up the CSS-animations-targetting-SVG-attribtues in the next FX telcon [on Cameron McCormack - due 2011-03-10].

<dholbert> (heycam says 'yes')

<scribe> scribenick: birtles

<scribe> Scribe: Brian

ED: I did some updates to the filter spec

<ed> http://dev.w3.org/Graphics-FX/modules/filters/publish/SVGFilter.html

I added some wording for handling filters applied to HTML thru CSS

scribe: based on what roc wrote up
... taking part of the spec from Mozilla and integrating it into this filter spec

<pdengler_home2> We need to distinguish what the filter is being applied to. From my simple understanding, the SVG Filters apply to graphical elements and paint underneath.

<pdengler_home2> HTML “filters” (box-shadow, text-shadow) target different parts.

<pdengler_home2> I suggest we add a ‘filter-target’ property to target different things (“box|text”) or (“content|whole”).

PD: need to differentiate between targetting background content vs content itself

<pdengler_home2> yes i can hear you

RO: I think the best way to do that is to add new images
... right now you have SourceAlpha etc.
... ContentImage, ContentAlpha etc.

ED: I added into the spec some wording in red about this

RO: I don't think it's difficult to add new image names here

ED: So what do we want to add Border? Background?

RO: Border, Background, Outline are the 3 main ones
... Content would be everything else
... that includes everything their child can containa
... that would be really powerful, and easy to undersatnd
... let's do it

ED: Does that map to something in SVG

RO: no

<ChrisL> s/containa/contain, including their borders and backgrounds

CM: What are you thinking of?

CL: Of those, SVG only has Content
... Content would apply to SVG and HTML equally

PD: So I want to be able to only target the background of a table
... I want to take a SVG filter and target it to the text in this page, the background in another
... so it shouldn't be on the filter

<pdengler_home2> filter-target="background"

CM: So it should be on the property not the filter

CL: But sometimes you want more than one

CM: But for the simple case you only need one

RO: one thing that's missing is how to interpret user space units

<pdengler_home2> filter-target="border|background|content(default)"

ED: it's there

PD: I'm talking about targetting a div

CM: we're talking about things (1) inside the filter introduce new filter primitive keywords (2) targetting a whole filter to only one aspect of a box

s/about things/about two things/

CL: there's always going to be a limit to what you can do with shorthand properties

ED: keep the canned filters as simple as possible

CM: I'd be happy with a feature like that

PD: I agree
... the shorthand lets people doing something quickly
... but if you want to do something more complex you have to dig deeper
... and that's in a new spec where you start talking about new sources

<pdengler_home2> So how do we get that to the CSS working group? Next FX call

ED: Dino has an action to come up with the proposed syntax for the shorthands
... he's the co-editor of the spec
... it's moved to the public fx taskforce
... I'll get in touch with him to see how it's going

<pdengler_home2> Sounds great, for my ability to track this can you create an issue on that

ED: If he's too busy I'll propose something
... I'd like to remove the margin attribute
... and figure out the filter regions so we don't get clipping by default

<pdengler_home2> All of this sounds great Eric

ED: the margins were in the original SVG 1.1 which was suppose to address blur margins
... but all implementations are doing optimisations to address the slow cases anyway
... so they need to optimise the regions anyway

CM: was there other stuff you'd like to rip out

ED: they were the major things

<pdengler_home2> I was going to say we clamp, but....we don't do filters...

ED: the next step would be new filter primitive

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

CM: experience shows explicit clamping in there didn't prove to be a useful optimisation
... people don't do it properly

PD: if we were to do clamping it would be nice to have specific properties
... e.g. to what extent to you extend to infinite regions
... i'd like a story that says you can shoot yourself in the foot, but this is as far as you can go

RO: can you give us an example?
... what are you talking about clamping?

<pdengler_home2> i'm talking about clamping the combination of dx, stddeviation etc. don't worry

<pdengler_home2> i prefer the margin proposal

CM: we're talking about different things

<pdengler_home2> Sorry

ED: in those cases it might make sense to have limits
... although it needn't necessarily be in the spec
... but implementations should probably have limits

CL: shorthand properties (canned filters) should say that here is an SVG filter that is equivalent
... but make clear you don't have to implement it like that
... as long as it has the same effect
... but authors shouldn't expect that SVG filter to show up in the DOM
... that allows hardware/platform acceleration to be used

<pdengler_home2> Sure

<ed> ED: could you explain a bit more about the point: "Support the inclusing of SVG <defs> as part of <link> in HTML"

<pdengler_home2> <link rel=”import” type=”image/xml+svg” href=”file.svg”>.

PD: I often end up with fairly large filters which I'd like to link externally

CM: the current way you reference filters is in this way: url # something

<pdengler_home2> <link rel="import" type="image/xml+svg" href="file.svg">.

<ChrisL> url()

<pdengler_home2> <filter="url(svg1.svg#mydef)"

ED: how does import work?

PD: it's difficult to import gradient, image definitions

RO: you can reference all of those with URL # references
... what's wrong with that?

PD: i don't have a bit complaint

s/bit/big/

RO: there's one situation: people writing stylesheets would like to reference filters without requiring yet another document
... one proposal is allowing CSS to contain XML
... so you can put the filter directly in the stylesheet
... I don't think it's a bad idea
... but for now the URL syntax seems to work

PD: yeah, that makes sense
... let's leave it

CL: in SVG we were very careful to use URI refs rather than ID ID-refs
... since that doesn't work for other docs
... so it gives us flexibility to address that

ED: in this draft here I have one filter primitive that's not defined yet
... feCustom
... it's for defining shaders with SVG filters
... one possible way is to allow people to write filter primitives with open CL
... or perhaps WebGL
... it's lower level but gives you a lot of power

CL: previously we proposed javascript callbacks for this

ED: that would be slow

CL: yeah, so this looks like more practical

ED: so do you want to allow software-only engines to run shaders?

PD: before we go to far down this path... is WebGL going to be brought into the W3C

RO: WebGL may not be W3C but it is a standard

<pdengler_home2> Is webgl under the same patent policy as w3c?

<ChrisL> http://en.wikipedia.org/wiki/WebGL

RO: on any platform that can run WebGL you should be able to use WebGL in a shader

ED: could be a feature string
... so if you can run this, do this, otherwise do that

CL: or we could use another language feature

DS: what's the license?

RO: not sure
... but the Chronos group has dealt with IP a lot

<heycam> s/Chronos/Khronos/

ED: so if we do that it would be good to pull into filter input images
... and integrate with the rest of the filter spec

<ChrisL> http://en.wikipedia.org/wiki/HLSL

ED: means some definition of how it integrates with the shader language

<ChrisL> http://en.wikipedia.org/wiki/Cg_%28programming_language%29

ED: how SVG filters integrate
... otherwise you could have just the shader and some fallback

CM: so you want 1/2 inputs just like you do with filter primitives?

ED: what does the shader look for?

CM: mapping from the SVG buffer to whatever the shader takes

ED: same for the output from the shader too

CL: Cg lang can output different types of shaders
... so it could provide different shaders depending on the platform

RO: Google provide ANGLE

<pdengler_home2> "almost native"

PD: will you pull that stuff out in the next week or so?

<ChrisL> http://code.google.com/p/angleproject/issues/detail?id=35

ED: in the coming weeks

CL: I want some language in the spec about the canned effects
... that you don't actually need the equivalent SVG in the DOM as long as you get the same result

<pdengler_home2> Did we solve the issue I brought up before with filter-target on HTML elements?

<scribe> ACTION: Erik to work on removing the margins and put some proposed text for how to deal with the proposed filter regions into the filters spec [recorded in http://www.w3.org/2011/03/02-svg-minutes.html#action05]

<trackbot> Created ACTION-2996 - Work on removing the margins and put some proposed text for how to deal with the proposed filter regions into the filters spec [on Erik Dahlström - due 2011-03-10].

<scribe> ACTION: Erik to follow up Dino about the shorthand syntax for filter effects [recorded in http://www.w3.org/2011/03/02-svg-minutes.html#action06]

<trackbot> Created ACTION-2997 - Follow up Dino about the shorthand syntax for filter effects [on Erik Dahlström - due 2011-03-10].

<ChrisL> actually http://code.google.com/p/angleproject/ is a better pointer for angle

<pdengler_home2> my phone failed

<pdengler_home2> I don't have my machine configured

<pdengler_home2> to check into W3C

<pdengler_home2> I emailed them, can someone please do that for me (my apologies)

<pdengler_home2> (Did you get them in email?)

<pdengler_home2> Ok I will get another phone and meet back after your break

<ChrisL> s/yes we did/yes at least erik did and he is checking them in/

<ed> http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size/svg_size.html

<dholbert> pdengler_home2, so it looks like your page ^ is pairs of [svg testcase] [raster expected-rendering], right?

<pdengler_home2> *should* be a test with the expected rendering next to it in a raster format

<pdengler_home2> we overloaded the server with .5MB? :)

<scribe> scribenick: birtles

<scribe> Scribe: Brian

Intrinsic sizing

<pdengler_home2> Jonathan has been working on this for a while and shared his tests with all of us a long time ago.

http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size/svg_size.html

ED: I've made some fixes (doctype, preserveAspectRatio="none" <-- lowercase "none")

<jwatt> http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size/svg_size.html

<ed> (for completeness, here are the unmodified files from patrick: http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size-patd-original/svg_size.html )

<pdengler_home2> We wanted to share some tests back and perhaps we can use them as a test bed for the framework discussed on Monday.

<pdengler_home2> We believe that these tests are accurate to the specification and where we believe the spec to be ambiguous, is within the spirit of the specification and/or interoperable.

<pdengler_home2> For the tests, you will notice that indeed IE9 passes all of them; this is because we used these tests to develop our platform.

<pdengler_home2> As indicated on the email DL, after our latest platform preview we caught some sizing discrepancies between our implementation and the spec; we subsequently made adjustments.

<pdengler_home2> At the time of the change we aligned with Firefox beta. I think Firefox made adjustments for interop based upon our implementation (I think that’s what Rob said).

<pdengler_home2> (http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Intrinsic_sizing_tests)

PD: Let's see if we can agree on what the spec says, or if the tests are wrong

JW: I think the 7th and 8th images are not being sized correctly on IE

<jwatt> JW: "SVG sizing with 'viewbox' specified while 'width' and 'height' is percentage inside an 'object' tag."

JW: the 4th set of images
... from my understanding, the object element ends up with width 50%, height: auto because the containing block, the body, has height auto
... which gets you to section 10.6.2 of CSS 2

<jwatt> http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height

<jwatt> JW: Otherwise, if 'height' has a computed value of 'auto', and the element has an intrinsic ratio then the used value of 'height' is:

<jwatt> JW: (used width) / (intrinsic ratio)

JW: since the height is not resolvable you end up using the intrinsic dimensions of SVG (100x100) --> ratio 1:1
... so the height of the object tag should be given the same computed value as its width
... so you should end up with square

s/square/a square/

PD: so firefox ends up with a square on this one?

JW: previously you might have been testing firefox in quirks mode
... but if you run the test again you'll see it is a square in firefox

PD: Erik, what's your interpretation

ED: Jwatt is probably right
... what does the P1, P2, P2 mean in the wiki page

PD: ignore that

<jwatt> RRSAgent: make minutes

ED: The P3 might have only been wrong because of the capitilisation of preserveAspectRatio

PD: do you agree with jwatt's assessment that it should be 1:1

ED: yeah, I think so

PD: what does Opera do?

DH: Opera matches the bitmap on my computer

PD: it's the same as IE9 on my computer

DH: could it be that they're using the viewBox to generate an aspect ratio?
... in this case there's a width and a height

ED: jwatt is probably correct here
... I think the spec says the width/height takes precedence in this case
... and viewBox is used if there's no width/height

<pdengler_3> My understanding is that the viewBox would take precidence as the percentage is 100% correct?

<dholbert> height/width are both 100px

JW: I'm pretty sure I'm right

<dholbert> there's no percentage 100%, IIUC

CL: 1.1F2 should have the same wording as Tiny

ED: so width/height should have precedence

PD: I want to make sure we're on the same page and it seems Erik and Jonathan are agreed
... I think this would be a good set of tests to formalise
... into the test bed
... where else do you think our interpretation might be incorrect?
... bear in mind that these tests are hot off the press

<jwatt> JW: I think FF currently handles "SVG sizing without 'viewbox' specified while 'width' and 'height' is percentage inside an 'object' tag." incorrectly

<dholbert> I agree

JW: it doesn't override the width/height on the SVG tag

<ed> "SVG sizing with 'viewbox' specified while 'width' and 'height' is percentage inside an 'object' tag."

ED: the first example says the width/height is % but the test case doesn't use % -- was the test case wrong
... oh it refers to the object element

<pdengler_3> Eric, do you mean the very first test?

<ed> http://dev.w3.org/SVG/profiles/1.1F2/publish/coords.html#IntrinsicSizing

ED: yes, so I just wasn't sure where the percentages were, but it's ok
... So, is Firefox's handling of the first case is incorrect?

JW: no not the first case

<jwatt> JW: "SVG sizing without 'viewbox' specified while 'width' and 'height' is percentage inside an 'object' tag." - half way down the page

<ed> ED: sorry, misread it, a bit confused by the similar text descriptions

JW: So those are the only two cases I would point out

DH: Looks like we match the reference on everything else

<pdengler_home5> Ok, and that's the same issue as the 4th one right?

ED: you mean just the SVG part, not the dotted lines

DH: I mean including the dotted lines
... but ignoring the padding

JW: Are the images supposed to match in size and position as well?

PD: I believe Opera had some differences with the stylesheet

JW: In IE9 after adding the doctype the rendering and bitmaps don't seem to be the same

<pdengler_home5> That' because we made changes since PPB7 in RC to match Firefox :)

<pdengler_home5> and the spirit and letter of the spec (I hope)

PD: They all match for me on my build

<pdengler_home5> SVG sizing without 'viewbox' specified while 'width' and 'height' is percentage inside an 'object' tag."

JW: Mozilla needs to fix that

DH: Firefox does that incorrectly

<pdengler_home5> The only issue is then that we have #4 incorrect

<pdengler_home5> (aside from the preserveAspectRatio casing)

JW: For the examples on this page, the first one I pointed out you don't do correctly, but the second one you and Opera do correctly and Mozilla does not

ED: I think we should try to forward this to the WebKit guys
... our next step would be to try to collect these test cases into a test framework
... but it sounds like we're mostly on the same page

PD: maybe contact with WebKit will really get us online

JW: on the wiki page, under Firefox 4 there are 5 bullet points
... referring to the third one
... I think this is the correct thing to do
... did you remove viewBox logic?
... talking about it in terms of a viewBox is just to get the desired result
... to give the same effect as for raster images

The point in question is "Next Firefox 4 beta will have Opera’s <img> viewBox logic."

DH: I think the problem is when you have a non-percent width/height and NO viewbox
... we've changed it to synthesize a viewBox in that case

<pdengler_home5> I think we all recognize that this is probably desirable, but I definitely want to raise the issue that injecting a missing attribute might be considered "quirks"

DH: that's what Opera does
... this is for scaling
... the straightforward thing to do is to clip but what Opera does and what we think authors expect is to have the image scale
... like with a raster image
... an author can add a viewBox to get that behaviour
... but authoring tools generally don't do that

CL: but then you can't get the image to be the size you desire anymore

JW: if that's what you want just put width/height auto on your image tag

DH: it's only when the SVG width/height doesn't match the image width/height

<pdengler_home5> That was our concern; it may make sense, but it is assuming an attribute that is not there

DH: we do it on the image tag, list style image (CSS images), but not on the SVG:image tag because it's well defined there

ED: we don't do it there either

DS: Tab Atkins wrote on www-style that he found the intrinsic sizing discussion a bit confusing
... we sorted out what was confusing him -- it wasn't clear to him that the SVG canvas extended infinitely on all sides
... he thought we could make that more clear
... and that if we talked about % width/height as a transformation

CL: it's fairly easy to explain
... e.g. 30% each transform="scale(0.3)"

DS: I thought it would be harmless to explain in those terms

<scribe> ACTION: Doug to add some additional clarification to the intrinsic sizing part of the spec [recorded in http://www.w3.org/2011/03/02-svg-minutes.html#action07]

<trackbot> Created ACTION-2998 - Add some additional clarification to the intrinsic sizing part of the spec [on Doug Schepers - due 2011-03-10].

CL: (re Patrick's concern about the "quirk" of adding a viewBox attribute)

DH: it doesn't match object

PD: it doesn't match the spec

DH: it doesn't match the spirit of the spec

CL: is there anything in the HTML spec regarding this behaviour for PNG images etc.
... we could see if we're consistent with that

DH: I'm sure it's in the CSS spec for raster images / replaced elements
... but I think a lot of the CSS spec text about this stuff doesn't expect images that react to their viewport

JW: the bottom line is that without this viewBox insertion behaviour is unexpected for authors

<ChrisL> until recently, that was certainly true

JW: with this they get what they expect

PD: I'm not sure, it's tough

<jwatt> JW: some very loose spec text that daniel and I came up with while trying to get images to behave as authors expect: "for SVG-as-an-image, if the /embedding/ element doesn't implement preserveAspectRatio and the root <svg> in the image doesn't have a viewBox, resolve the <svg>'s width/height to pixels values and use viewBox="0,0,resolvedwidth,resolvedheight" and preserveAspectRatio=none...

<jwatt> ...(ignoring any preserveAspectRatio on the <svg>)"

DH: I acknowledge our current behaviour makes me uncomfortable given the lack of clarity in the spec
... I'd be more comfortable if we had something in the spec

PD: it does say that for image
... but not when used as an <img>

DH: the SVG image has different behaviour than the HTML <img> element for raster images
... so it's not unexpected that it would be different for SVG images either

CL: Well we shouldn't define it in terms of faking a viewBox, but rather by analogue with raster images

JW: maybe we can express it in terms of inserting an extra transform
... actually that's what we do
... we talk about viewBox to make it easier for an author to understand

CL: if an image has an intrinsic size / fixed size and you want to make it bigger
... for raster images you scale it up
... and same for SVG but it just happens to scale nicely
... it's not SVG, it's about CSS replaced content
... it has an intrinsic size and we scale it up because the context in which it's being used says to

DH: but you can find tune that scaling with a viewBox and preserveAspectRatio
... that's why we "add a viewBox"

s/find tune/fine tune/

JW: we'd say more than just scaling, but some other wording that didn't mention "viewBox"
... which will be more complicated but avoids talking about fake viewBoxs

ED: as long as we get the same behaviour
... I think jwatt's text is more clear

<scribe> ACTION: Patrick to consider intrinsic sizing behavior (particularly when a viewBox is not provided) and follow-up test cases [recorded in http://www.w3.org/2011/03/02-svg-minutes.html#action08]

<trackbot> Created ACTION-2999 - Consider intrinsic sizing behavior (particularly when a viewBox is not provided) and follow-up test cases [on Patrick Dengler - due 2011-03-10].

<jwatt> JW: another set of tests for sizing: https://jwatt.org/svg/tmp/embedded-sizing/embedded.html

JW: we seem to diverge widely on these tests

ED: can we put these in the UA sizing?

JW: yes
... Patrick, those tests seem to show that IE's implementation of the CSS replaced elements stuff seems wrong
... especially further down where everything just collapses to nothing
... we've run out of time to talk about individual ones there
... but if you disagree with our implementation on any of those can you get back to me and I'll explain

Automatic image sizing

JW: currently the SVG <image> tag if you don't specify width/height they default to 0 and nothing is shown
... they're required
... no way to get the width/height to automatically resize to the image you're embedding
... we should do what CSS embedding algorithm
... but simpler
... one or both of width/height can be specified and we determine the width/height

CL: is this for SVG 2nd ed or 2?

JW: SVG2
... I'd like the attributes to be optional
... we use the image aspect ratio to calculate the width/height

DS: it's a breaking change

CL: only if you're linking to images without specifying width/height

DS: which I've done

JW: I think the value of this is high enough that we should just go ahead and do this

<ChrisL> DS: I did that to force preload of images

<ChrisL> JW: Use visibility: hidden in future

CM: I can imagine someone relying on that behaviour because they're going to animate it out
... (i.e. relying on it becoming 0, 0)

DS: I usually make the attributes 0, 0
... this does break the idea of a rect with no width/height is 0,0

JW: but rectangles don't embed resources

DS: I think your rationale is perfectly reasonable
... I think this will be much more user-friendly

CM: I agree
... is this for rasters and SVGs?

JW: anything that can be embedded by an image tag that has an intrinsic size

DS: how about an SVG with % width/height
... would it act the same as an HTML img element?

JW: yes, but I need to look into it
... I want to simplify what CSS is doing

ED: what does Tiny say about %s, are they intrinsic?

s/ED: what/JW: what/

JW: I don't particularly like the idea of resources that don't know what they're getting put into

<scribe> ACTION: Jonathan to come up with text for automatic image sizing [recorded in http://www.w3.org/2011/03/02-svg-minutes.html#action09]

<trackbot> Created ACTION-3000 - Come up with text for automatic image sizing [on Jonathan Watt - due 2011-03-10].

<ChrisL> kiriban!

RESOLUTION: For SVG <image> missing an explicit width/height we will take in account the intrinsic dimensions/aspect ratio of the resource being embedded

ED: this is not just for image
... there's feImage and potentially other places
... animation element

DS: so bbox will clearly get the width/height

<ed> foreignObject too

DS: however, what about getting the attribute
... 0? null? undefined?

CM: you'd get empty
... it wouldn't affect the DOM
... it should do whatever we do for other automatic values

ED: currently we'd just create an object on the fly for cases like that

DS: if you change the href if would also change
... do we need to put that in the spec?

<ed> s/cases like that/cases like image without width, and you tried to fetch image.width.baseVal.../

JW: I don't think that's necessary but it might be helpful as a note
... but you should apply the same rule with a new image

DS: "even if the resource should change"

<ed> trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

02 Mar 2011

Attendees

Contents

overflow auto

shorthand presentation attributes

Animation improvements

SVG 2 / CSS Filters Module

Intrinsic sizing

Automatic image sizing

Summary of Action Items

Scribe.perl diagnostic output