- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 12 Dec 2012 19:47:58 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Discussed Flexbox issue wrt stretch-sizing elements with aspect ratio.
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
- RESOLVED: Transitions defines the timing functions, Animations has
normative dependency on Transitions for them.
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
- 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
- RESOLVED: An initially-paused animation is still started (fires start
events, etc.)
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
- RESOLVED: animation-play-state is not in the shorthand on purpose
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
- RESOLVED: Look into "adjacent keyframes" for level 4, but not for the
current level.
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/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
Agenda: 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
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
<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
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/
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
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
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
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
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
<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.
+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 03:48:31 UTC