- From: Erik Dahlstrom <ed@opera.com>
- Date: Thu, 03 Mar 2011 17:47:27 +1300
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Minutes in html format:
http://www.w3.org/2011/03/02-svg-minutes.html
or as text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
02 Mar 2011
See also: [2]IRC log
[2] http://www.w3.org/2011/03/02-svg-irc
Attendees
Present
+1.649.363.aaaa, +1.425.868.aabb
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Cameron, Anthony, Jonathan Watt, Brian
Contents
* [3]Topics
1. [4]overflow auto
2. [5]shorthand presentation attributes
3. [6]Animation improvements
4. [7]SVG 2 / CSS Filters Module
5. [8]Intrinsic sizing
6. [9]Automatic image sizing
* [10]Summary of Action Items
_________________________________________________________
<trackbot> Date: 02 March 2011
<birtles>
[11]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animati
on_improvements
[11]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements
<birtles> Presentation: [12]http://brian.sol1.net/svg/pres/SVG 2
Animation.html
[12] http://brian.sol1.net/svg/pres/SVG
<birtles> Presentation:
[13]http://brian.sol1.net/svg/pres/SVG%202%20Animation.html
[13] 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
[14]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>
[15]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animati
on_improvements
[15]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements
<birtles> Presentation:
[16]http://brian.sol1.net/svg/pres/SVG%202%20Animation.html
[16] 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> [17]http://www.w3.org/TR/scxml/
[17] 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>
[18]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animati
on_improvements
[18]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements
<birtles> Presentation:
[19]http://brian.sol1.net/svg/pres/SVG%202%20Animation.html
[19] 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>
[20]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/CSS_Ani
mation
[20]
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:
[21]http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CS
S_Animation
[21]
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>
[22]http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CS
S_Animation
[22]
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
([23]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Intrin
sic_sizing_tests) and I can post a test page with images.
[23]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Intrinsic_sizing_tests)
<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
[24]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
[25]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
[26]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>
[27]http://dev.w3.org/Graphics-FX/modules/filters/publish/SVGFilter.
html
[27]
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> [28]http://www.w3.org/Graphics/fx/wiki/Filter_effects
[28] 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> [29]http://en.wikipedia.org/wiki/WebGL
[29] 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> [30]http://en.wikipedia.org/wiki/HLSL
[30] http://en.wikipedia.org/wiki/HLSL
ED: means some definition of how it integrates with the shader
language
<ChrisL>
[31]http://en.wikipedia.org/wiki/Cg_%28programming_language%29
[31] 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>
[32]http://code.google.com/p/angleproject/issues/detail?id=35
[32] 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
[33]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
[34]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 [35]http://code.google.com/p/angleproject/ is a
better pointer for angle
[35] http://code.google.com/p/angleproject/
<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>
[36]http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size/svg_size.
html
[36]
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.
[37]http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size/svg_size.
html
[37]
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>
[38]http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size/svg_size.
html
[38]
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:
[39]http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size-patd-orig
inal/svg_size.html )
[39]
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>
([40]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Intrin
sic_sizing_tests)
[40]
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>
[41]http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height
[41] 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>
[42]http://dev.w3.org/SVG/profiles/1.1F2/publish/coords.html#Intrins
icSizing
[42]
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
[43]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
[44]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:
[45]https://jwatt.org/svg/tmp/embedded-sizing/embedded.html
[45] 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
[46]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
Summary of Action Items
[NEW] ACTION: Cameron to bring up the
CSS-animations-targetting-SVG-attribtues in the next FX telcon
[recorded in
[47]http://www.w3.org/2011/03/02-svg-minutes.html#action04]
[NEW] ACTION: Cameron to write a proposal for allowing shorthand
presentation attributes [recorded in
[48]http://www.w3.org/2011/03/02-svg-minutes.html#action01]
[NEW] ACTION: Doug to add some additional clarification to the
intrinsic sizing part of the spec [recorded in
[49]http://www.w3.org/2011/03/02-svg-minutes.html#action07]
[NEW] ACTION: Erik to bring up the one true animation spec on the fx
call [recorded in
[50]http://www.w3.org/2011/03/02-svg-minutes.html#action03]
[NEW] ACTION: Erik to follow up Dino about the shorthand syntax for
filter effects [recorded in
[51]http://www.w3.org/2011/03/02-svg-minutes.html#action06]
[NEW] 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
[52]http://www.w3.org/2011/03/02-svg-minutes.html#action05]
[NEW] ACTION: Jonathan to come up with text for automatic image
sizing [recorded in
[53]http://www.w3.org/2011/03/02-svg-minutes.html#action09]
[NEW] ACTION: Jonathan to Get Daniel to talk to David about making a
new harmonized animations spec [recorded in
[54]http://www.w3.org/2011/03/02-svg-minutes.html#action02]
[NEW] ACTION: Patrick to consider intrinsic sizing behavior
(particularly when a viewBox is not provided) and follow-up test
cases [recorded in
[55]http://www.w3.org/2011/03/02-svg-minutes.html#action08]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [56]scribe.perl version 1.135
([57]CVS log)
$Date: 2011/03/03 04:18:26 $
_________________________________________________________
[56] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[57] 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 [58]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[58] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/paths/files/
FAILED: s/svg paths/svg fragments/
Succeeded: s/do a sync/do a seek/
Succeeded: s/would that impose some restrictions/would that impose some
restrictions, because it's being suggested that eventbase timing would
n't be allowed in svg-in-img/
Succeeded: s/There is a repeat event which is event based/There is a re
peat event which is event based, but there's also repeat-value which is
n't the same exactly as event-base/
Succeeded: s/... [Slide: Add a reverse feature to time containers]/BB:
[Slide: Add a reverse feature to time containers]/
Succeeded: s/"r'/"r"/
Succeeded: s/Barron/Baron/
FAILED: s/in in/it in/
FAILED: s/so scrap the CSS-animations spec its current incarnation/so i
ntegrate the existing CSS animations spec into a single unified spec/
FAILED: s/containa/contain, including their borders and backgrounds/
FAILED: s/about things/about two things/
FAILED: s/bit/big/
FAILED: s/Chronos/Khronos/
FAILED: s/yes we did/yes at least erik did and he is checking them in/
FAILED: s/square/a square/
FAILED: s/find tune/fine tune/
FAILED: s/ED: what/JW: what/
FAILED: s/cases like that/cases like image without width, and you tried
to fetch image.width.baseVal.../
Found Scribe: Cameron
Found ScribeNick: heycam
Found Scribe: Anthony
Found ScribeNick: anthony_nz
Found Scribe: Cameron
Found ScribeNick: heycam
Found Scribe: Anthony
Found ScribeNick: anthony_nz
Found Scribe: Jonathan Watt
Found ScribeNick: jwatt
Found ScribeNick: birtles
Found Scribe: Brian
Found ScribeNick: birtles
Found Scribe: Brian
Found ScribeNick: birtles
Found Scribe: Brian
Scribes: Cameron, Anthony, Jonathan Watt, Brian
ScribeNicks: heycam, anthony_nz, jwatt, birtles
WARNING: Replacing list of attendees.
Old list: +1.649.363.aaaa tbah
New list: +1.649.363.aaaa +1.425.868.aabb +1.649.363.aacc
WARNING: Replacing list of attendees.
Old list: +1.649.363.aaaa +1.425.868.aabb +1.649.363.aacc
New list: +1.649.363.aaaa
Default Present: +1.649.363.aaaa, +1.425.868.aabb
Present: +1.649.363.aaaa +1.425.868.aabb
WARNING: Fewer than 3 people found for Present list!
WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth
Found Date: 02 Mar 2011
Guessing minutes URL: [59]http://www.w3.org/2011/03/02-svg-minutes.html
People with action items: cameron doug erik jonathan patrick
[59] http://www.w3.org/2011/03/02-svg-minutes.html
WARNING: Possible internal error: join/leave lines remaining:
<scribe> ... One of the guys that really understands it has joi
ned this working group now and he's interested in reworking it
WARNING: Possible internal error: join/leave lines remaining:
<scribe> ... One of the guys that really understands it has joi
ned this working group now and he's interested in reworking it
End of [60]scribe.perl diagnostic output]
[60] 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 Thursday, 3 March 2011 04:49:26 UTC