[CSSWG] Minutes and Resolutions 2012-03-28

   - 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
   - RESOLVED: Rule that transitions between visible and non-visible
               are visible applies between 0-1; at and beyond 0/1 it
   - 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 ======

   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
   florian: Not sure I like that. One thing I liked with the previous one
   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


   <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
   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
   <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 -
     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
   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


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
   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