- From: Sebastian Zartner <sebastianzartner@gmail.com>
- Date: Thu, 13 Dec 2012 06:55:57 +0100
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: "www-style@w3.org" <www-style@w3.org>
- Message-ID: <CAERejNbYahj_P4qrf496doPjRZ77UmoXKz2x+PLtSRkMUqowgQ@mail.gmail.com>
fantasai, all your Bugzilla links are missing the underscore between "show"
and "bug".
So e.g. instead of
https://www.w3.org/Bugs/Public/showbug.cgi?id=16116
it should have been:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16116
Sebastian
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