W3C home > Mailing lists > Public > www-style@w3.org > December 2012

[CSSWG] Minutes Telecon 2012-12-12

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 12 Dec 2012 19:47:58 -0800
Message-ID: <50C94FEE.3020006@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - Discussed Flexbox issue wrt stretch-sizing elements with aspect ratio.

   - Discussed Animations terminology for

   - RESOLVED: Transitions defines the timing functions, Animations has
               normative dependency on Transitions for them.

   - RESOLVED: Animations only "run" (fire start events, etc) if they have
               at least one valid keyframe.

   - RESOLVED: When an element changes from display:none to display: non-none,
               animations start immediately.

   - RESOLVED: An initially-paused animation is still started (fires start
               events, etc.)

   - RESOLVED: Animations can be paused during their delay phase, which
               freezes the remaining delay to be applied after it unpauses.

   - RESOLVED: animation-play-state is not in the shorthand on purpose

   - RESOLVED: animation-play-state has the same list behavior as the other
               animation properties, matching the length of animation-name.

   - RESOLVED: Look into "adjacent keyframes" for level 4, but not for the
               current level.

   - Discussed motivations and problems with Florian's 'pointer' MQ
     proposal, along with conceptual framework for extending MQ in
     level 4. See also 'pointer' threads at

====== Full minutes below ======

   Glenn Adams
   Tab Atkins
   Tantek Çelik (mostly via IRC)
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   John Jansen
   Peter Linss
   Alexis Menard
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Simon Sapin
   Leif Arne Storset
   Lea Verou
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2012/12/12-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2012Dec/0147.html
ScribeNick: TabAtkins


   plinss: Any additions?
   glazou: If florian is here, we can discuss the MQ issue.
   florian: yeah, I'm here, and we can discuss it.
   fantasai: Maybe discuss setting up a call for text-related issues before
             bringing it to the WG, with a time that actually works for
   fantasai: And just a subset of people that are interested.


   <plinss> http://lists.w3.org/Archives/Public/www-style/2012Oct/0781.html
   rossen: We needed to consider the case from last week...  I think we
           responded to it on the mailing list.
   rossen: The behavior you're proposing as a change to the spec is okay
           with us.
   rossen: A separate issue was raised int he same thread.
   rossen: The cross size of items affecting the main size, due to intrinsic
           aspect ratios.
   TabAtkins: As the algorithm currently sits, once the main size is set,
              the cross size can't affect it any more.
   <Rossen> http://jsfiddle.net/69qda/4/
   Rossen: One remaining problem we have with this is that in such cases
           you might end up with overlapping items.
   TabAtkins: You should never end up with overlapping items.
   TabAtkins: Chrome is wrong here right now; that's just a bug.
   TabAtkins: Changing the cross-size after resolving flexible lengths is
              not allowed to go back and affect the main size again.
   Rossen: So we determine the main size based on this, we'll lay out all
           the items to figure out the line-breaks, then determine their
           cross size.
   Rossen: In this case, once the cross size is determined, it'll drive
           the main size of the image.
   Rossen: So we'll go and reevaluate the linebreaks.
   TabAtkins: That behavior is incorrect per spec.
   Rossen: Right. I think our current behavior sometimes results in better
           results, but we need to make sure it's sane.
   Rossen: Sometimes, of course, you might push the item that is stretching
           to the next line, and when things get reevaluated, things stretch
           which shouldn't.
   Rossen: So there are problems with this behavior, but we want to minimize
           by default overlaps of flex items.
   Rossen: This is specifically about the multiline case, where the cross
           size can't be determined ahead of time.
   TabAtkins: As the spec currently stands, the result is sometimes ugly
              (doesn't honor the item's ratio), but it's stable and easy.
              I don't think it's possible to do something else without a
              "layout repeatedly until you reach a stable state" thing.
   Rossen: Okay, let's work out details on the list and pick it up again
           next week just in case.


   * fantasai notes dbaron is not here today

   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=16116
   <sylvaing> http://dev.w3.org/csswg/css3-animations/#animations
   sylvaing: This one is a terminology issue that Dirk noticed in the spec.
   sylvaing: There's a diagram that talks about "intrinsic style", but
             doesn't define what that means.
   TabAtkins: Seems like what it means is the style without Animations
   sylvaing: The intent of the bug was to say that it should point to an
             existing phrase.
   TabAtkins: I don't think we have one. Maybe just use a phrase.
   <darktears> initial style -> final style (after animation run)
   <fantasai> static style / animated style?
   smfr: Do we have a document listing the terms for th existing style levels?
   fantasai: Cascade.
   <fantasai> http://dev.w3.org/csswg/css3-cascade/
   TabAtkins: Even if we don't define a new term, the diagram is wrong and
              should have a short phrase rather than "specified" and
              "computed" style.

   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=14784
   sylvaing: next is some grammar issues.
   sylvaing: One is user-defined ident case-sensitivity, which is still
   sylvaing: Another is that the animation and transition specs both define
             the timing functions, and we should really define it only once.
   sylvaing: Can we define that Animations is dependent on Transitions for
   [several]: yeah
   RESOLVED: Transitions defines the timing functions, Animations has
             normative dependency on Transitions for them.

   sylvaing: Now about the user-ident stuff, how is that going?
   fantasai: jdaggett just wrote a bunch of tests for it, and posted to the
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Dec/0149.html
   glazou: I pinged i18n about it too.

   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=15251
   sylvaing: This bug is about prose in the spec along the lines of...
   <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Dec/0144.html
   sylvaing: Spec says that animation-start events are dispatched for each
             animation-name in the list, but impls don't fire if the
             @keyframes rule is empty.
   smfr: I think we should define more strictly when an animation runs,
         and just say that empty keyframes don't run an animation.
   TabAtkins: Is there any compat impact for just making an empty @keyframes
   sylvaing: I was thinking about that.  There's a potential compat case -
             if a keyframe "foo" is overridden by another "foo" which is
             empty, it'll hide it.
   smfr: I think it makes sense to have it be valid, so you can start with
         an empty @keyframes rule and fill it with script.
   TabAtkins: Makes sense.
   smfr: I think we can define that a side-effect of an animation running
         is that animations fire, and empty keyframes don't run.
   sylvaing: Missing 0% and 100% keyframes are filled in by the UA, so
             one's never actually empty, right?
   TabAtkins: Those don't show up in the OM, though - we just fill in
              values to the actual animation.
   sylvaing: Okay, so I'm okay with that.  We can specify that an animation
             runs only if it has one or more valid keyframes.
   RESOLVED: Animations only "run" (fire start events, etc) if they have
             at least one valid keyframe.

   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=14785
   sylvaing: Next is display:none effects.
   sylvaing: display:none stops animations.
   sylvaing: We didn't clearly write down when you go from display:none
             to non-none.
   sylvaing: Our assumptions in IE is that animations will start, but not
   sylvaing: I think it's reasonable to agree on the animations thing now,
             but maybe not transitions without dbaron around.
   TabAtkins: I agree about animations.
   RESOLVED: When an element changes from display:none to display: non-none,
             animations start immediately.

   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=14774
   <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Oct/0214.html
   sylvaing: This is about adding animation-play-state:paused when an
             animation isn't yet running.
   sylvaing: Today, FF and IE10 freeze the animation on its first frame
             (or don't show anything, if it's delayed).
   sylvaing: Related, what if you're in delay, and you flip to pause.
   TabAtkins: I think dbaron said that FF just freezes the remaining delay
              and continues with it when you unpause.
   sylvaing: [checking whether animation-fill-mode affects the
              immediately-paused animation]
   TabAtkins: Does it fire an animationStart event?  I think it should,
              since it's already displaying the start of the animations.
   sylvaing: Based on quick testing, looks like IE and FF don't.  But we
             think that it should?
   TabAtkins: yeah.
   sylvaing: What effects would this have on elapsedTime?  I think it's
             relative to the animation, not absolute.
   smfr: I think so - the time the animation has already been running.
   RESOLVED: An initially-paused animation is still started (fires start
             events, etc.)
   <smfr> and it may be paused during the delay phase
   RESOLVED: Animations can be paused during their delay phase, which
             freezes the remaining delay to be applied after it unpauses.

   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=14787
   sylvaing: Is it intentional that animation-play-state can't be applied
             in the shorthand?
   smfr: I think it was intentional, because of potential ambiguity
         collision with animation names, and low possibility of usefulness.
   sylvaing: I'm fine with that.
   RESOLVED: animation-play-state is not in the shorthand on purpose

   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=14786
   sylvaing: The behavior of animation-play-state as a list isn't defined.
             I imagine it's just the same as the other properties (cycled
             until it reaches the length of animation-name list)?
   RESOLVED: animation-play-state has the same list behavior as the other
             animation properties, matching the length of animation-name.

   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=20092
   sylvaing: Tab had a proposal to add the ability to have "adjacent"
             keyframes, which are explicitly next to each other.
   sylvaing: Today you have to hack around it with "50%" and "50.00001%"
             or similar.
   florian: Sounds useful, but we have to finish the current level, so
            I'd prefer to delay it.
   fantasai: Agreed.
   RESOLVED: Look into "adjacent keyframes" for level 4, but not for the
             current level.

   sylvaing: The rest are animation/transition stuff that we want dbaron
             for, or some interrelated bugs I need to work on.

'pointer' MQ

   glazou: The pointer MQ hasn't been discussed in the group.
   glazou: It may have been a side discussion, but hasn't been official.
   glazou: I don't want to put the burden on florian specifically, but
           it's a good chance to remind people on how the group should
           work.  Editors can make proposals, but it shouldn't show up
           in the draft until it's been discussed in the group.
   florian: My understanding is that when we're close to LC, nothing hits
            the draft until it's been discussed, but early on it's looser -
            we can put things in the draft so that there's *something*
            to discuss.
   florian: It's true that it's been in the draft longer than intended
            before discussion, but both I and the group have been busy.
   <glenn> an editor's draft is an "Editor's" draft
   <glenn> what goes into an ED does not have to have be discussed by the
           group beforehand
   glazou: What I'm hoping for is just that, if you add something to an ED,
           even early on, just drop an email to the group with a pointer
           to it.
   glazou: That way we know about your new feature and can discuss it.
   glazou: I just want to make sure that we don't fall into the same trap

   glazou: [doesn't quite like the syntax]
   florian: I'd like to describe why I put the feature in, before discussing
   florian: My impression is that media features are... screen is used
            everywhere, but things like "handheld" are failures,
            because they are mutually exclusive with screen.
   florian: So move away from media types, and move toward media features.
   florian: Right now, since the mobile browsers don't advertise themselves
            as "handheld", there's no good way to figure out when you're
            on one.
   florian: what is it that makes a media type "special"?
   florian: want to define feature queries for that
   florian: [touch things aren't accurate with pointer, and you can't hover]
   <tantek> I think that changes too fast at this point
   <tantek> there are no fixed axiomatic descriptions of such media types -
            that's what we've learned (with the exception of print)
   florian: I think "print" isn't nearly as much of a failure, but still,
            I'd like to add features to let you detect the *relevant thing*
            about being on a paper.
   florian: 'pointer' for the level of accuracy and 'hover' for whether
            you can or not are, through side discussion, things that
            appear to be useful.
   florian: I'm not very strongly attached to these specific media queries,
            but the general direction I think is the right way to go.

   glazou: Accuracy of pointer depends on the zoom level.
   glazou: The accuracy of the pointer depends on the zoom level.
   * tantek agrees with glazou
   florian: The property should describe the accuracy of the pointer at
            the default level.
   florian: You can make things more accurate, but it would be inconvenient
            for the user.
   hober: I raised the same point as daniel just now.
   hober: I think the underlying problem is that media queries in the past
          that have failed are because they're exclusive.
   hober: We should fix that first.
   hober: My concern in relation to the pointer media query is that, I
          think it's main use is to increase the size of touch targets.
   hober: If zoom doesn't increase these, my concern is that well get
          ugly-looking websites.
   florian: This just affects the default level of the button size, etc.
             When you zoom, they just scale appropriately.
   TabAtkins: Just to counteract everyone else, I love the media query.

   fantasai: I'm concerned about coarse vs. fine
   fantasai: [some concern about the definition of fine/course being unclear]
   fantasai: how coarse is coarse? how does that inform the design?

   <glazou> 'coarse' is not understandable by people with low English knowledge
   <tantek> I agree that "coarse" is bad
   <tantek> also "coarse" sounds like "CORS"
   <tantek> another reason not to use that term

   * glazou thinks the pointer MQ should be removed from spec at this point

   <tantek> I also dislike the 'pointer' media query
   <tantek> changes based on screen resolution etc.
   <TabAtkins> tantek, Uh, what?  No it doesn't.
   <tantek> TabAtkins, how you'd use the mediaquery changes on pixel density
   <TabAtkins> tantek, No, it wouldn't.  Can you give an example of why you
               think that?
   <tantek> TabAtkins, screens have different pixel densities, thus different
            "fuzziness" of what finger taps hit
   <TabAtkins> tantek: Sub-pixel accuracy is completely swamped by gross size.

Meeting closed =========================================================

   <TabAtkins> Seriously, 2x pixel density might vary the size of the touch
               target by ~ 1/200th of an inch.
   <TabAtkins> That's irrelevant when we're talking about 10px high versus
               20px high.

   <tantek> I also think that these are a bit present-context (this year's
           devices) anachronistic.
   <tantek> part of the reason handheld and TV failed is that they were stuck
           with the definition of technologies that were fixed in time and
           obsoleted during the course of being on the WG!
   <tantek> handheld predated large screen smartphones - which is why no
           "large screen mobile" devices or sites bother with "handheld"
   <tantek> (they just use m.example.com instead of example.com)
   <tantek> similarly with TV - was based on old analog TV resolutions,
           constraints ("safe area", refresh rates, single pixel line
   <tantek> that reminds me. we need to turn both the TV Profile and the
             Mobile Profile into Notes.

   <TabAtkins> tantek: I agree with you there - trying to slice things into
               media type categories is a losing proposition.
   <TabAtkins> Phones to tablets to mini-books to laptops to ultrabooks to
               desktops are more or less a continuum these days, not separable
   <tantek> right, the hardware spectrum is filling out

   <tantek> there *are* differences in usage patterns which strongly affect
           design - e.g. in "mobile" situations, you need simple clear
           interfaces that are focused on only a very small number of actions
   <tantek> as opposed to when sitting a desk
   <tantek> but "handheld" vs. "screen" does not (and will not) give you that
   <TabAtkins> Right, but even then, that's not really a device category.
               I sometimes am doing normal browsing on my phone and want
               the full site, and sometimes want the abbreviated easy-to-use
   <TabAtkins> I don't think you can hit that with CSS.
   <tantek> exactly, you can be sitting at your desk using your smartphone
   <tantek> where you can give it plenty of attention / focus / concentration,
           and read little details because you're not walking down the street

   <tantek> well - we could create a media selector for inertial sensors
   <tantek> it's probably worth looking at all the hardware sensing WebAPIs
           and seeing if there is a useful higher level CSS media query
           selector equivalent for any of them.
   <tantek> like we do with orientation and screen aspect ratios
   <tantek> also, touch targets are harder to hit when walking rather than
           standing, or sitting
   <tantek> so "coarse" doesn't cover it

   <tantek> on the subject of including things in drafts to get discussion -
           I'm a fan of course
   <tantek> I'm even ok with such experiments/brainstorms making it out to
           public working drafts
   <tantek> I've added / removed plenty of things like that in the past, and
           getting them into public working drafts is what helped make the
           discussion happen.
   <tantek> of course that was before public EDs became so prevalent, so
           maybe it doesn't apply any more?
   <tantek> I can also see some value in whatever is in a WD (vs. ED) having
           some degree of consensus from the WG
   <tantek> although that seems to vary from WG to WG, culturally as it were
   <tantek> so there's nothing you can conclude about W3C public WGs as a
           whole in that regard. It could be one person's idea. It could
           be strongly agreed by the whole group.
   <sylvaing> I'd rather be able to add things to the ED though I'd be fine
             with marking it with some class that styles in a way that says
             'this is only my opinion and was not discussed by the group ever'
   <TabAtkins> sylvaing: Daniel's point that an editor should at least drop
               a mail to the group about it immediately is fine, I think.

   <TabAtkins> tantek: We can theoretically get into the exact correct size
               for touch targets based on various data, but it's not necessary.
               Having two values is sufficient for real-world use-cases while
               still being useful.
   <TabAtkins> (Similar to how we have only three light levels - those are
               the minimal useful set for covering the use-cases.)
   <tantek> TabAtkins - not sure about two values being sufficient. Existing
           UIs fail at this.
   <tantek> E.g. touch keyboards *suck* for when you're walking (nearly
           impossible to use)
   <tantek> there's at least three levels (crappy names on purpose) :
           mobile-coarse, stationery-coarse, and fine
   <TabAtkins> tantek: I think touch keyboards kinda suck all the time,
               personally.  They're a compromise between screen space
               and normal keyboard layout.
Received on Thursday, 13 December 2012 03:48:31 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:22 UTC