- 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