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

Re: [CSSWG] Minutes Telecon 2012-12-12

From: Sebastian Zartner <sebastianzartner@gmail.com>
Date: Thu, 13 Dec 2012 06:55:57 +0100
Message-ID: <CAERejNbYahj_P4qrf496doPjRZ77UmoXKz2x+PLtSRkMUqowgQ@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "www-style@w3.org" <www-style@w3.org>
fantasai, all your Bugzilla links are missing the underscore between "show"
and "bug".
So e.g. instead of


it should have been:



On Thu, Dec 13, 2012 at 4:47 AM, fantasai <fantasai.lists@inkedblade.net>wrote:

> Summary:
>   - Discussed Flexbox issue wrt stretch-sizing elements with aspect ratio.
>       http://lists.w3.org/Archives/**Public/www-style/2012Oct/0781.**html<http://lists.w3.org/Archives/Public/www-style/2012Oct/0781.html>
>   - Discussed Animations terminology for
>       https://www.w3.org/Bugs/**Public/showbug.cgi?id=16116<https://www.w3.org/Bugs/Public/showbug.cgi?id=16116>
>   - RESOLVED: Transitions defines the timing functions, Animations has
>               normative dependency on Transitions for them.
>               https://www.w3.org/Bugs/**Public/showbug.cgi?id=14784<https://www.w3.org/Bugs/Public/showbug.cgi?id=14784>
>   - RESOLVED: Animations only "run" (fire start events, etc) if they have
>               at least one valid keyframe.
>               https://www.w3.org/Bugs/**Public/showbug.cgi?id=15251<https://www.w3.org/Bugs/Public/showbug.cgi?id=15251>
>   - RESOLVED: When an element changes from display:none to display:
> non-none,
>               animations start immediately.
>               https://www.w3.org/Bugs/**Public/showbug.cgi?id=14785<https://www.w3.org/Bugs/Public/showbug.cgi?id=14785>
>   - RESOLVED: An initially-paused animation is still started (fires start
>               events, etc.)
>               https://www.w3.org/Bugs/**Public/showbug.cgi?id=14774<https://www.w3.org/Bugs/Public/showbug.cgi?id=14774>
>   - RESOLVED: Animations can be paused during their delay phase, which
>               freezes the remaining delay to be applied after it unpauses.
>               https://www.w3.org/Bugs/**Public/showbug.cgi?id=14774<https://www.w3.org/Bugs/Public/showbug.cgi?id=14774>
>   - RESOLVED: animation-play-state is not in the shorthand on purpose
>               https://www.w3.org/Bugs/**Public/showbug.cgi?id=14787<https://www.w3.org/Bugs/Public/showbug.cgi?id=14787>
>   - RESOLVED: animation-play-state has the same list behavior as the other
>               animation properties, matching the length of animation-name.
>               https://www.w3.org/Bugs/**Public/showbug.cgi?id=14786<https://www.w3.org/Bugs/Public/showbug.cgi?id=14786>
>   - RESOLVED: Look into "adjacent keyframes" for level 4, but not for the
>               current level.
>               https://www.w3.org/Bugs/**Public/showbug.cgi?id=20092<https://www.w3.org/Bugs/Public/showbug.cgi?id=20092>
>   - 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
>       http://lists.w3.org/Archives/**Public/www-style/2012Dec/0152.**html<http://lists.w3.org/Archives/Public/www-style/2012Dec/0152.html>
>       http://lists.w3.org/Archives/**Public/www-style/2012Dec/0172.**html<http://lists.w3.org/Archives/Public/www-style/2012Dec/0172.html>
> ====== Full minutes below ======
> Present:
>   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<http://www.w3.org/2012/12/12-css-irc>
> Agenda: http://lists.w3.org/Archives/**Public/www-style/2012Dec/0147.**
> html <http://lists.w3.org/Archives/Public/www-style/2012Dec/0147.html>
> ScribeNick: TabAtkins
> Administrative
> --------------
>   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
>             Japan?
>   fantasai: And just a subset of people that are interested.
> Flexbox
> -------
>   <plinss> http://lists.w3.org/Archives/**Public/www-style/2012Oct/0781.**
> html <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.
> Animations
> ----------
>   * fantasai notes dbaron is not here today
>   <sylvaing> https://www.w3.org/Bugs/**Public/showbug.cgi?id=16116<https://www.w3.org/Bugs/Public/showbug.cgi?id=16116>
>   <sylvaing> http://dev.w3.org/csswg/css3-**animations/#animations<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
>              applied
>   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/<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<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
>             pending.
>   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
>             this?
>   [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
>             list.
>   <fantasai> http://lists.w3.org/Archives/**Public/www-style/2012Dec/0149.
> **html <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<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 <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
>              invalid?
>   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<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
>             transitions.
>   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<https://www.w3.org/Bugs/Public/showbug.cgi?id=14774>
>   <sylvaing> http://lists.w3.org/Archives/**Public/www-style/2011Oct/0214.
> **html <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<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<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<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.
> +tantek
>   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
>           again.
>   glazou: [doesn't quite like the syntax]
>   florian: I'd like to describe why I put the feature in, before discussing
>            details.
>   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
>           problems)
>   <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
>               categories.
>   <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
>               version.
>   <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 05:56:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:24 UTC