- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 26 Feb 2010 14:43:23 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Reviewed SVGWG's message on image-fit and image-position:
http://lists.w3.org/Archives/Public/www-style/2010Jan/0476.html
- RESOLVED: Replaced elements are always clipped to the content box
- RESOLVED: Unqualified references to a box in the image-fit/position
definitions should be 'content box'
- RESOLVED: Whether image-fit & image-position inherit should match
the inheritance behavior of SVG's preserveAspectRatio
attribute.
- RESOLVED: The proposal for a new 'auto' value to 'image-fit' is
not accepted.
- Briefly discussed animation fill modes and timing functions;
further discussion deferred until later.
====== Full minutes below ======
Present:
David Baron
Bert Bos
Beth Dakin
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Peter Linss
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2010/02/24-CSS-irc
Scribe: szilles
Administrative
--------------
Daniel: Light agenda, mostly from last week
Daniel: we should start a discussion of coming F2F, agenda items, schedules,
attendance
Agenda: 1. Follow up on Image Position and Image Fit
<glazou> http://lists.w3.org/Archives/Public/www-style/2010Jan/0476.html
Bert: Last weeks discussion did not reach a conclusion on anything
wrt Overflow mismatch
Bert: Elika proposes and I agree that the rule for "overflow" should be
clip the overflowing parts
Simon: I can see use cases for scrollbars or the above solution; We could go either way
fantasai: The author can put scroll bars on the replace element it self; e.g. a document inside an iframe. Thus there
is no particular need for scroll bars on the box into which the replace element goes
Simon: I agree with Elika's analysis; clipping makes most sense
dbaron: no opinion, still trying to understand it, but willing to live with the clipping proposal
RESOLVED: Clipping is the behavior for overflow
wrt Missing "none"
fantasai: the answer may depend on what the model is for negotiation between
the box and the replaced element. I suggested one in a reply
<fantasai> http://lists.w3.org/Archives/Public/www-style/2010Feb/0164.html
fantasai: The "none' value is asserted as necessary for SVG. I am not sure
that this is so.
fantasai: If CSS decides on the view box size and SVG decides how to fill
it then there is no need for a 'none' value because SVG setting
will be used anyway
ACTION (all) read Elika's answer above
wrt Fit to content or padding box?
RESOLVED: content box
wrt Don't inherit
Daniel: It is suggested to not inherit image-postition and image-fit
fantasai: the use case for inheritance is "nested object elements" but it's
more important to match SVG's preserveAspectRatio
Simon: I am fine with no inheritance
Bert: me too
RESOLVED: Do what is best for SVG
N. B. if what is best for SVG involves no inheritance, then there will be
no inheritance
ACTION (Elika): Find out what is best for SVG
wrt Which module does image-fit go into
fantasai: could move this property out of the page module into the images
module which is being actively edited
Bert: Paged Media should be back into CR as soon as possible
fantasai: The catch is that there are a bunch of open issues that will delay
getting paged media done
Peter: HP is implementing it now and will likely want to push this through,
perhaps via me
SteveZ: Who will make the changes?
fantasai: The problem with making the changes in Paged Media, is that due
to references to the CR version from other standards orgs we
cannot move the draft back to WD
fantasai: The result of this is that the "editor's draft" that is public
cannot be reissued so there is a large discrepency between it
and the CR draft, since Melinda and I fixed *lots* of issues.
SteveZ: it is disconcerting that someone is normatively referencing an out
of date document whatever its status
fantasai: There was CSS print stuff going on at MIPC and some other org;
HP could perhaps provide more detail.
SteveZ: can we action HP to tell us what they think the constraints are on
the paged media module
ACTION (PL): Get information from HP
wrt A new 'auto' behavior
Bert: I do not like it; I think we can do without it
Peter: how do we get the default behaviors without it
fantasai: We can say that we assign the box and the content "filler" does
what ever it thinks is right
fantasai: using the model above, the content filler is given the size of
the area to fill and it makes the decision on how to fill it
Sylvain: Would 'auto' be the default behavior then?
Answer: yes
dbaron: Because "object" is so hard to implement, perhpas we should not
force that on every other kind of element
Sylvain and dbaron: auto should not be the default just because it is good
for "object"
Daniel: do you agree that a new "auto" value is needed?
<dbaron> I think <object> behavior might be a bunch of quirks... and
object isn't used very much for any of this.
<dbaron> I think the right behavior for <object> might be to switch
implementations to doing 'fill'.
Sylvain and dbaron: no, we do not agree there is a need
RESOLVED: the proposal for a new "auto" value is not accepted
Disrete Transitions
-------------------
Topic: Applying transitions to properties like visibility
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0328.html
dbaron: I think that this is more likely a F2F topic
agreed
<Zakim> -fantasai
* fantasai has to attend an i18n telecon
Animation Fill Modes
--------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2010Jan/0443.html
Simon: this would be in addition to animation spec to add a property
'animation-fill-mode'
Simon: property allows author to spec whether the effect of the animation
extends from now to end of delay period and how it ends
dbaron: How does this interact with the animation-iteration-count?
Simon: this would apply only after the last interation
dbaron: With and iteration count of 3 and a fill-mode of "both"
Simon: With a count of 3 and goes forward-backward-forward it applies to
the last frame, but if the count were 2 which frame does it apply to
dbaron: I like it provided that with even iteration counts are explained
<dbaron> I think even iteration counts should probably mean that the from
keyframe applies at both ends
<dbaron> er, even iteration counts *and* direction:alternate
Simon: should the animation spec say anythnig about rendering when the
animation event fires?
<glazou> http://lists.w3.org/Archives/Public/www-style/2010Jan/0445.html
ACTION (SMFR); Come back with a more detailed proposal
Animation Timing Function property
----------------------------------
<smfr> http://lists.w3.org/Archives/Public/www-style/2010Feb/0212.html
<smfr> ACTION (smfr); Write a more detailed proposal for animation-fill-mode
Simon: This overlaps with the 'visibility' discussion
Decision: this becomes a topic for the F2F meeting
Percentage heights
------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0286.html
dbaron: I would need some time to recall this suggestion
Administrative Part II
----------------------
Daniel: Please gather ideas for the F2F agenda
Bert: Richard Ishida has volunteered to help edit the Ruby Module and we
should invite him to explain what he is doing
Daniel: I will arrange an invitation
<dbaron> http://www.w3.org/International/wiki/BidiProposal
dbaron: There is a bidi proposal that the I18N WG will be discussing.
This is aimed at HTML, but is likely to affect CSS as well
SteveZ: Should we ask Richard to update us on the bidi propoasl while at
our meeting
dbaron: that would be good.
Adjourn at 9:58 AM PST
Received on Friday, 26 February 2010 22:44:00 UTC