- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 28 Mar 2012 18:23:52 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Publish CSS3 Images as CR
- RESOLVED: No transition (and no transition event) if the end of the
transition is not in the future (not the present or the
past).
- RESOLVED: Rule that transitions between visible and non-visible
are visible applies between 0-1; at and beyond 0/1 it
clamps.
- RESOLVED: Pseudo-element attribute on transition event is called
"pseudoElement" and the argument to initTransitionEvent()
is pseudoElementArg.
- RESOLVED: Publish Transitions and Animations as WD
- RESOLVED: Add 'reverse' and 'alternate-reverse' to 'animation-direction'
- RESOLVED: make interaction of border-image with collapsed tables
undefined, suggest not implementing it in L3, expect it to
be defined in L4
- Discussed proposal for text-size-adjust
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
David Baron
Bert Bos
Cathy Chan
Tantek Çelik
John Daggett
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Arno Gourdol
Vincent Hardy
Molly Holzschlag
John Jansen
Håkon Wium Lie
Edward O'Connor
Anton Prowse
Florian Rivoal
Alan Stearns
David Storey
Steve Zilles
Scribe: fantasai
CSS3 Images
-----------
glazou: Tantek, noticed you sent an extra agenda item. Try to do that, but let's see if it fits.
glazou: First thing on agenda is moving CSS3 Images to CR
glazou: Left 1 week to members to think about it and read the spec. What's
the opinion?
dbaron: I'm curious what conclusions fantasai and Tab came to
fantasai: Only thing that changed since last week is the object sizing
algorithm. I sent mail on those changes.
dbaron: I didn't get a chance to look, but probably ok to move on
florian: Opera is happy to publish
glazou: me too
Bert, sylvain: +1
RESOLVED: CSS3 Images goes to CR
<Ms2ger> \o/
<kennyluck> \o/
CSS3 Transitions
----------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Feb/1083.html
glazou: Anything else to review here?
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2012JanMar/0454.html
dbaron: Nothing to discuss from 1st message -- need proposals
dbaron: 2nd message, I made edits reflecting previous 2 discussions we had
from 1st message.
dbaron: 4 things want to follow up on
dbaron: Straightforward, but wanted to run by ppl before we publish again
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Mar/0593.html
dbaron: 1st, we agreed that when transition-? and transition-duration are 0,
there is no transition
dbaron: Didn't discuss what happens if transition-delay is negative
dbaron: Wrote in spec that there's no transition if the end of the transition
point is not in the future
glazou, florian, florian agree
RESOLVED: Accept proposal
dbaron: Next one, we'd discussed rounding font-weight where we round to
nearest 100
dbaron: For integers we floor, though, instead of rounding to nearest
* fantasai wonders whether -.0001 rounds to -1 or 0
<glazou> we don't have negative font weights elika...
<fantasai> but we have negative integers
<sylvaing> we don't but it's a valid point for integer interpolation
based on real numbers
dbaron: thought it would be best to be consistent, so made it floor.
There is an open issue on rounding, but thought it best to make
consistent.
florian: Not sure I like that. One thing I liked with the previous one
was
florian: If you're just in a loop, the time you spend on any of them would
be same as others
florian: This changes that
glazou: Not sure I agree with that based on the proposal
Bert: Don't you want the step function for that?
florian: If you're looping through font weights...
fantasai: Why would you want to do that? It's not a smooth transition.
You'll be jumping all around, pretty randomly .
dbaron: I'm happy to change it back. Not what we implement, but I can
switch it back to the other way.
florian: I don't think it's critical, but prefer other behavior.
smfr: We do have an issue filed that floor behavior is different from SMIL
and SVG
smfr: We picked floor so that you didn't jump near the beginning or right
near the end.
* oyvind doesn't understand how floor doesn't jump at the end
smfr: Wondering if we should resolve integer-rounding before font-weight
fantasai: How about we make font-weight what we want, say there's an
issue with making it consistent with integers but also there's
an issue with how to round integers.
fantasai: Then we can publish this, and resolve the issue later
szilles: Which way are you leaning, smfr?
smfr: Have to go back and think about it. Think we wanted some sensible
step behavior, but leads to issues like this one.
glazou: Let's adopt fantasai's proposal
RESOLVED: Make font-weight round to nearest, mark issues as above
dbaron: Said transitions between visible and other intermediate values map
to visible
dbaron: Right now we have cubic bezier functions that output results that
are not in the range 0-1
dbaron: I realized that, if you're 0 or 1 or anything outside that range,
you pick the appropriate endpoint
dbaron: And you do the visible thing between 0 and 1
dbaron: if you transition from visible to hidden, then if you're 1 or
greater you're hidden
smfr: Think this issue crops up with other properties where you have to clamp
dbaron: Noted in spec we need to address for some others
smfr: Say something about clamp to 0-1 range
dbaron: effectively same thing
glazou: What about current implementations?
dbaron: There are implementations, not sure what they do
smfr: Webkit animates visibilities. Think we relaxed timing functions to
go beyond 0/1, but not sure the details
glazou: Would be good to know what current browsers are doing.
vhardy: ... not constrained with 0-1 range?
dbaron: We allow y values to be outside 0-1 range.
dbaron: I just looked at Gecko, and it does match the proposal
dbaron: Dunno if I thought about the issue when I wrote it
glazou: any objections against proposal?
dbaron: Proposal is, rule that you're always visible applies only between
0-1, not at or beyond 0/1
vhardy: is it clear what happens what happens if you go outside the 0-1
box for colors and things like this?
dbaron: No, noted as issue in spec we need to fix
florian: do we need to fix independently, or in the same way?
dbaron: different for different properties
vhardy: Going beyond 0-1 is useful for transforms.
glazou: Want to know what it means for colors
dbaron: for Gecko, we clamp to 0-255
Bert: It's not forbidden to have colors outside that range.
dbaron: That's why it's not quite the right behavior
glazou: Any objections to proposal?
RESOLVED: Proposal accepted
dbaron: Last thing, we agreed to add pseudo-attribute to Transition event.
So I called it pseudoElement
dbaron: Wanted to check a) that ppl ok with that
dbaron: ... something about argument ...
<dbaron> http://lists.w3.org/Archives/Public/www-style/2012Mar/0598.html
glazou: I think both make sense
glazou: no objection?
RESOLVED: proposal accepted
dbaron: Other things ChrisL wanted to resolve for transitions
<dbaron> and animations
<glazou> http://www.w3.org/mid/1936834258.20120327170804@w3.org
<smfr> looks good to me
florian: Not sure what's in the drafts, but publishing is good
RESOLVED: Publish Transitions and Animations as WD
Animations
----------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Mar/0234.html
<glazou> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14632
sylvaing: First one is, we talked about defining an animationCancelled
event for animations that don't run to completion
sylvaing: I'm proposing we push that to L4
sylvaing: Same for all features here -- propose to move to next level
<smfr> no objection
florian: Have we done anything other than suggest it should exist?
Is there any spec?
sylvaing: No, just listed as a nice-to-have
florian: ok
RESOLVED: defer
<glazou> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14777
sylvaing: Proposal to allow animations to happen along a path
RESOLVED: defer
<glazou> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14780
<smfr> http://lists.w3.org/Archives/Public/www-style/2011Sep/0399.html
sylvaing: When you create a keyframes rule, you divide 100% by number of
keyframes ...
sylvaing: Idea was let's get rid of percentages, and find syntactic way
to use numbers, let browser add them up / divide evenly
sylvaing: There's no spec, just nice to have
glazou: It's a good idea, but we can defer that.
<smfr> no objection
RESOLVED: defer
sylvaing: Proposal for more complex animation scenarios
<glazou> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14798
sylvaing: Extending calc() function to use in animation functions like
animation-delay
sylvaing: Advanced scenarios, don't think we need for this level
RESOLVED: defer
sylvaing: Last one, from Lea, about animation-direction
sylvaing: Takes normal and alternate
sylvaing: Asking whether to add a reverse value
sylvaing: Essentially would be like alternate, except only one phase
dbaron: I thought we resolved to add those at one point
sylvaing: ok, I missed that
sylvaing: did we resolve to add all three?
<smfr> http://lists.w3.org/Archives/Public/www-style/2011May/0676.html
dbaron: Thought the proposal was to have 4 values
* fantasai can't find the resolution
fantasai: If it's very easy to add, let's add it
florian: Significantly easier than everything else proposed so far
dbaron: This is one of those things where implementing it is less work
than unprefixing it
glazou: Probably authors will use a lot
smfr: WebKit has an implementation already
RESOLVED: add animation-direction: reverse | alternate-reverse
Selectors for fragment identifiers
----------------------------------
glazou: There's a community group about that, started by ? and Simon
St.Laurent
<glazou> http://simonstl.com/articles/cssFragID.html
dbaron: Chris is most active CSSWG member on their mailing list, and he's not
here right now. Might be worth having him around for this discussion
Molly: Bears weight w/ other community groups starting up
Molly: e.g. accessibility group for CSS
Molly: ... for these community groups anyway
Molly: liaison / relationship w/ groups that build things like CSS fragment
identifiers, CSS a11y
Molly: There will be other groups that crop up, that we will need to have
a relationship with
glazou: Would you like to report to WG on a11y?
ACTION: Molly something about CSS a11y group
<trackbot> Created ACTION-454
glazou: This will drastically increase our liaison work
<mollydotcom> note that I will also talk with Eric and Simon re: css
fragment identifiers
Margin collapsing
-----------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Mar/0057.html
* fantasai wonders what happened to item about CSS3 Backgrounds and Borders
Backgrounds and Borders
-----------------------
Scribe: Bert
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Mar/0602.html
fantasai: 2 issues that are open
<Bert> http://lists.w3.org/Archives/Public/www-style/2012Mar/0602.html
fantasai: [explains the option at the bottom of that msg]
fantasai: The difference is the effect of the width of the collapsed borders,
dbaron: Why allow image border on collapsed tables at all?
fantasai: Why forbid it?
dbaron: it doesn't make much sense.
dbaron: I think that was what the commenter suggested, too.
Molly: Are there strong use cases?
dbaron: not well-defined how it joins at corners and sides
fantasai: these options resolve the issues of corners and sides.
Stevez: would be good to see this live.
SteveZ: what's implemented?
dbaron: What I proposed, i.e., no images borders
fantasai: I think both these options make it straightforward to apply
Bert: I think it makes sense to have an image around the table even if
the borders are collapsed inside it.
fantasai: So, here's an example -
http://dev.w3.org/csswg/css3-writing-modes/#logical-to-physical
border-collapsed table there
Imagine this table with a paper background and a ragged paper edge
around it.
I think that should be fine.
glazou: yeah, why not
dbaron: Not happy with adding features
fantasai: this isn't new
dbaron: I think we spent too much time implementing lots of features in
this spec that nobody wants
<tantek> can we action the proposer to post a use-case to the list? or
defer to level 4?
glazou: Can we defer to L4?
florian: Will there be a compatibility problem if we do it later?
Molly: I'd like to see some visual or real-world use cases
Molly: My concern is priority
* glazou why is the word "collapsing" triggering headache here ? :-)
florian: As general principle, don't want our specs to contradict future
improvements. Otherwise I'm fine
florian: Can we defer to L4 without contradicting ourselves later?
fantasai: Yes, there's 3 ways I can do this
1. Say you MAY apply to border-collapsed tables, and if you do, this is
how you do it
2. Say you MUSTn't do this
3. Say you it's undefined, we suggest you don't do anything for now,
but we might define it later
<Bert> (Something like: "Border images apply to table elements, but the
effect of the width of collapsed borders is not defined in level
3."?)
Glenn: Mark it at-risk
Molly: [...]
dbaron: When it's in the spec, we get pressure to implement it
Molly: Concern that priority gets passed to implementors
Straw poll
florian: 3
glazou: 3
dstorey: 3
molly: 3
hober: abstain
anton: 3
<tantek> I'm ok with 3 or 1
?: 3
smfr: 3
arronei: 3
vhardy: 3
steve: 3
fantasai: 1, fine with 3
dbaron: 1 or 2. or 3 I guess
sylvaing: 3
glenn: 4 (at-risk)
rossen: going to round up to 3
howcome: 3
Bert: 1, second choice is 3
RESOLVED: make interaction with collapsed tables undefined, suggest not
implementing it in L3, expect it to be defined in L4
text-size-adjust
----------------
Scribe: fantasai
<tantek> here is the summary of the agenda item I sent in late:
<tantek> I'd like to spend a few minutes on text-size-adjust if that's ok.
<tantek> Specifically, we don't currently have a spec, and I'd like to propose
<tantek> a (very) rough draft based on notes/research of various
<tantek> implementations[1] if there are no objections. Obviously I'll reformat
<tantek> my notes into our spec template before checking in an editor's draft.
<tantek> [1] https://wiki.mozilla.org/CSS/text-size-adjust#property_definition
<tantek> I can hear the telcon but apparently skype is not letting me talk
<glazou> https://wiki.mozilla.org/CSS/text-size-adjust#property_definition
glazou: very rough draft of text-size-adjust
glazou: He would like to have it in a WD if there's no objection
glazou: Of course will reformat the notes into spec template
florian: Opera doesn't implement that
<tantek> oh odd, people are using -o-text-size-adjust
<tantek> in pages today
<tantek> oh boy
glazou: They're putting the prefixes for all browsers
<tantek> I always assume opera implements things :)
<tantek> ok I'll update my notes
florian: Thankful for ppl thinking of us, but we don't implement it.
glazou: Afaict, Tantek's notes match the current implementations
glazou: Any objection for turning that into an editor's draft
Bert: Can someone explain what it does? "text inflation" doesn't mean
anything to me
dbaron: I can try to describe something
dbaron: But explanation is somewhat complicated
<tantek> happy to include to text from dbaron
<sylvaing> if Apple has IP, might there be an objection from them?
florian: I have a guess at what it is, but not sure I'm right
florian: If you're a mobile browser with tap / zoom
florian: You tap on something: could do 2 things, could zoom in at 100%
size and if the lines are too long you wrap them
florian: Alternatively you zoom in to make the lines fit
florian: but then the font size might be too small
florian: so you increase the font size
* fantasai is confused
<tantek> this is just a question of may I start an editor's draft
<tantek> I'm not saying I've resolved all issues
<tantek> nor am I asking for a FPWD yet
<glazou> tantek: sure
<tantek> glazou - chair-request
<tantek> happy to collect issues
<tantek> happy to record any disputes in the draft also
szilles: Agree with Bert's comment that it needs more text before it
goes in. not clear what it does
glazou: Can you be more precise about concept of inflation before we decide?
<tantek> yes
<tantek> please action me
ACTION Tantek make text-size-adjust more accurate definition of font inflation
<trackbot> Created ACTION-455
<tantek> hober, any objection to an editor's draft?
glazou: ?
hober: Ongoing discussions within Apple
vhardy: Wouldn't the IPR issue get resolved when we do FPWD and the
exclusion period kicks in?
glazou: Yes, but if it's a problem then not worth doing
glazou: Tantek, please update the draft and send us email
glazou: Going to suggest keeping this on the member's list, since
controversial.
glazou: Tantek?
<tantek> is ok with that, but not my preference
glazou: If you move fast and refine your proposal, we can move fast and
go public immediately
<tantek> ok
glazou: Let's be clear about what we publish to the general public
<tantek> ok
<tantek> thanks glazou
glazou: Ok, and that's top of hour. Thanks everyone, talk to you next week.
<glazou> tantek: call that a compromise on a controversial topic and we
can still move fast if you make "inflation" more precise
Received on Thursday, 29 March 2012 01:24:26 UTC