16:26:19 <RRSAgent> RRSAgent has joined #css
16:26:19 <RRSAgent> logging to http://www.w3.org/2012/12/12-css-irc
16:26:25 <glazou> Zakim, this will be Style
16:26:25 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 34 minutes
16:26:29 <glazou> RRSAgent, make logs public
16:34:27 <cabanier> cabanier has joined #css
16:36:50 <jet> jet has joined #CSS
16:37:48 <arno> arno has joined #css
16:40:06 <antonp> antonp has joined #css
16:45:52 <lmclister> lmclister has joined #css
16:54:17 <arno1> arno1 has joined #css
16:54:22 <sylvaing> sylvaing has joined #css
16:56:44 <Zakim> Style_CSS FP()12:00PM has now started
16:56:49 <Zakim> +plinss
16:57:01 <florian> florian has joined #css
16:58:18 <Zakim> +??P50
16:58:22 <lmclister> lmclister has joined #css
16:58:36 <florian> Zakim, I am ??P50
16:58:36 <Zakim> +florian; got it
16:59:12 <Zakim> +hober
16:59:27 <Zakim> +??P55
16:59:33 <glazou> Zakim, ??P55 is me
16:59:33 <Zakim> +glazou; got it
16:59:38 <Zakim> +[Microsoft]
16:59:54 <sylvaing> Zakim, [Microsoft]has me
16:59:54 <Zakim> I don't understand '[Microsoft]has me', sylvaing
16:59:57 <sylvaing> Zakim, [Microsoft] has me
16:59:57 <Zakim> +sylvaing; got it
17:00:05 <leif> leif has joined #css
17:00:21 <oyvind> oyvind has joined #css
17:00:26 <smfr> smfr has joined #css
17:00:32 <glenn> glenn has joined #css
17:01:04 <Zakim> +smfr
17:01:14 <smfr> why doesn't the conf. bridge let me type the code sooner?
17:01:23 <cabanier1> cabanier1 has joined #css
17:01:29 <Zakim> + +34.93.192.aaaa
17:01:30 <TabAtkins_> TabAtkins_ has joined #css
17:01:31 <glazou> smfr: same thing happened to me
17:01:33 <Zakim> +leif
17:01:41 <antonp> Zakim, aaaa is me
17:01:41 <Zakim> +antonp; got it
17:01:46 <SimonSapin1> SimonSapin1 has joined #css
17:01:50 <smfr> it has enough acronyms, it should be able handle this!
17:02:03 <JohnJansen> JohnJansen has joined #CSS
17:02:16 <Zakim> +??P37
17:02:29 <Zakim> +fantasai
17:02:31 <sylvaing> smfr, probably runs on a PDP-11 in MIT's basement
17:02:46 <darktears> Zakim, ??P37 is me
17:02:46 <Zakim> +darktears; got it
17:02:51 <Zakim> +??P78
17:03:01 <glenn> zakim, ??p78 is me
17:03:01 <Zakim> +glenn; got it
17:03:11 <Zakim> +[Microsoft.a]
17:03:18 <smfr> hober: http://www.compunetix.com/ix/assets/pdfs/products/CONTEX_240_480.pdf
17:03:26 <Zakim> +SteveZ
17:03:39 <Zakim> +SimonSapin
17:03:39 <smfr> "The CONTEX conferencing platform is the most reliable in the industry. CONTEX systems feature continuous real-time diagnostics, hot-swappable and self-healing system designs and are built to military standards with patented space-division switching architecture"
17:03:40 <glenn> that's ralph swick talking
17:03:55 <JohnJansen> Zakim, Microsoft has JohnJansen
17:03:55 <Zakim> +JohnJansen; got it
17:04:10 <rhauck> rhauck has joined #css
17:04:37 <Zakim> +[Microsoft.aa]
17:04:39 <glazou> sylvaing: military… you think of the html5 and CSS3 logos ?-)
17:04:44 <Zakim> + +1.832.797.aabb
17:04:45 <arronei> zakim, microsoft has me
17:04:45 <Zakim> +arronei; got it
17:04:50 <TabAtkins_> zakim, aabb is me
17:04:50 <Zakim> +TabAtkins_; got it
17:05:05 <Zakim> +??P92
17:05:15 <glazou> we never did
17:05:31 <TabAtkins_> ScribeNick: TabAtkins_
17:05:51 <TabAtkins_> plinss: Any additions?
17:05:57 <TabAtkins_> glazou: If florian is here, we can discuss the MQ issue.
17:06:04 <TabAtkins_> florian: yeah, I'm here, and we can discuss it.
17:06:04 <smfr> Agenda: http://lists.w3.org/Archives/Public/www-style/2012Dec/0147.html
17:06:43 <TabAtkins_> 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?
17:06:50 <TabAtkins_> fantasai: And just a subset of people that are interested.
17:07:26 <TabAtkins_> Topic: Flexbox issue
17:07:31 <plinss> http://lists.w3.org/Archives/Public/www-style/2012Oct/0781.html
17:08:17 <TabAtkins_> rossen: We needed to consider the case from last week...  I think we respondedto it on the mailing list.
17:08:30 <TabAtkins_> rossen: The behavior you're proposing as a change to the spec is okay with us.
17:08:39 <TabAtkins_> rossen: A separate issue was raised int he same thread.
17:08:55 <tantek> tantek has joined #css
17:09:20 <TabAtkins_> rossen: The cross size of items affecting the main size, due to intrinsic aspect ratios.
17:09:35 <Rossen> Rossen has joined #CSS
17:10:17 <TabAtkins_> TabAtkins_: As the algorithm currently sits, once the main size is set, the cross size cant' affect it any more.
17:10:37 <Rossen> http://jsfiddle.net/69qda/4/
17:10:39 <TabAtkins_> Rossen: One remaining problem we ahve with this is that in such cases you might end up with overlapping items.
17:11:06 <Zakim> -smfr
17:11:28 <Zakim> +smfr
17:12:08 <fantasai> TabAtkins_: You should never end up with overlapping items.
17:12:19 <fantasai> TabAtkins_: Chrome is wrong here right now; that's just a bug.
17:12:50 <fantasai> TabAtkins_: Changing the cross-size after resolving flexible lengths is not allowed to go back and affect the main size again.
17:13:14 <TabAtkins_> 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.
17:13:26 <TabAtkins_> Rossen: In this case, once the cross size is determined, it'll drive the main size of the image.
17:14:15 <Zakim> +Lea
17:14:25 <TabAtkins_> Rossen: So we'll go and reevaluate the linebreaks.
17:14:34 <TabAtkins_> TabAtkins_: That behavior is incorrect per spec.
17:15:12 <TabAtkins_> Rossen: Right. I think our current behavior sometimes results in better results, but we need to make sure it's sane.
17:15:39 <TabAtkins_> 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.
17:15:56 <TabAtkins_> Rossen: So there are problems with this behavior, but we want to minimize by default overlaps of flex items.
17:16:59 <TabAtkins_> Rossen: This is specifically about the multiline case, where the cross size can't be determined ahead of time.
17:18:27 <TabAtkins_> 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.
17:18:49 <TabAtkins_> Rossen: Okay, let's work out details on the list and pick it up again next week just in case.
17:19:53 <TabAtkins_> Topic: Animation issues
17:20:31 <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16116
17:20:46 <sylvaing> http://dev.w3.org/csswg/css3-animations/#animations
17:20:50 <TabAtkins_> sylvaing: This one is a terminology issue that Dirk noticed in the spec.
17:21:03 <TabAtkins_> sylvaing: There's a diagram that talks about "intrinsic style", but doesnt' define what that means.
17:21:50 <fantasai> TabAtkins_: Seems like what it means is the style without Animations applied
17:22:17 <darktears> initial style -> final style (after animation run)
17:22:57 <TabAtkins_> sylvaing: The intent of the bug was to say that it should point to an existing phrase.
17:23:10 <fantasai> static style / animated style?
17:23:36 <TabAtkins_> smfr: Do we have a document listing the terms for th existing style levels?
17:23:37 <fantasai> http://dev.w3.org/csswg/css3-cascade/
17:23:40 <TabAtkins_> fantasai: Cascade.
17:24:20 <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14784
17:24:27 <TabAtkins_> 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.
17:24:33 <TabAtkins_> sylvaing: next is some grammar issues.
17:24:43 <TabAtkins_> sylvaing: One is user-defined ident case-sensitivity, which is still pending.
17:25:01 <krit> krit has joined #css
17:25:05 <TabAtkins_> sylvaing: Another is that the animation and transition specs both define the timing functions, and we should reallyd efine it onlyl once.
17:25:23 <SteveZ> SteveZ has joined #css
17:25:28 <TabAtkins_> sylvaing: Can we define that Animations is dependent on Transitions for this?
17:25:32 <TabAtkins_> [several]: yeah
17:25:40 <TabAtkins_> sylvaing: Now about the user-ident stuff, how is that going?
17:25:58 <TabAtkins_> fantasai: jdaggett just wrote a bunch of tests for it, and posted to the list.
17:26:10 <TabAtkins_> glazou: I pinged i18n about it too.
17:26:29 <TabAtkins_> RESOLVED: Transitions defines the timing functions, Animations has normative dependency on Transitions for them.
17:26:46 <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15251
17:26:54 <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Dec/0149.html
17:26:56 <TabAtkins_> sylvaing: This bug is about prose in the spec along the lines of...
17:27:00 <sylvaing> posted here: http://lists.w3.org/Archives/Public/www-style/2011Nov/0542.html
17:27:17 <sylvaing> wrong link: http://lists.w3.org/Archives/Public/www-style/2011Dec/0144.html
17:28:16 <TabAtkins_> sylvaing: Spec says that animation-start events are dispatched for each animatino-name in the list, but impls don't fire if the @keyframes rule is empty.
17:28:36 <TabAtkins_> smfr: I think we should define more strictly when an animation runs, and just say that empty keyframes don't run an animation.
17:29:06 <TabAtkins_> TabAtkins_: Is there any compat impact for just making an empty @keyframes invalid?
17:29:53 <TabAtkins_> 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.
17:30:09 <TabAtkins_> 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.
17:30:42 <TabAtkins_> TabAtkins_: Makes sense.
17:31:02 <TabAtkins_> smfr: I think we can define that a side-effectof an animation running is that animations fire, and empty keyframes don't run.
17:32:02 <TabAtkins_> sylvaing: Missing 0% and 100% keyframes are filled in by the UA, so one's never actually empty, right?
17:32:15 <TabAtkins_> TabAtkins_: Those don't show up in the OM, thoguh - we just fill in values to the actual animation.
17:32:29 <TabAtkins_> sylvaing: Okay, so I'm okay with that.  We can specify that an animation runs only if it has one or more valid keyframes.
17:32:53 <TabAtkins_> RESOLVED: Animations only "run" (fire start events, etc) if they have at least one valid keyframe.
17:33:03 <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14785
17:33:15 <TabAtkins_> sylvaing: Next is display:none effects.
17:33:20 <TabAtkins_> sylvaing: display:none stops animations.
17:33:30 <TabAtkins_> sylvaing: We didn't clearly write down when you go from display:none to non-none.
17:33:41 <TabAtkins_> sylvaing: Our assumptions in IE is that animations will start, but not transitions.
17:34:06 <TabAtkins_> sylvaing: I think it's reasonable to agree ont he animations thing now, but maybe not transitions without dbaron around.
17:34:23 <SteveZ> SteveZ has joined #css
17:34:27 <TabAtkins_> TabAtkins_: I agree about animations.
17:35:25 <TabAtkins_> RESOLVED: When an element changes from display:none to display: non-none, animations start immediately.
17:35:40 <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14774
17:35:55 <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Oct/0214.html
17:36:03 <TabAtkins_> sylvaing: This is about adding animation-play-state:paused when an animation isn't yet running.
17:36:39 <TabAtkins_> sylvaing: Today, FF and IE10 freeze the animation on its first frame (or dont' show anything, if it's delayed).
17:36:52 <TabAtkins_> sylvaing: Related, what if you're in delay, and you flip to pause.
17:37:25 <TabAtkins_> TabAtkins_: I think dbaron said that FF just freezes the remaining delay and continues with it when you unpause.
17:37:43 <cabanier> cabanier has joined #css
17:38:41 <jet> jet has joined #CSS
17:38:44 <TabAtkins_> sylvaing: [checking whether animation-fill-mode affects the immediately-paused animation]
17:39:48 <TabAtkins_> TabAtkins_: Does it fire an animationStart event?  I think it should, since it's already displaying the start of the animations.
17:40:29 <TabAtkins_> sylvaing: Based on quick testing, looks like IE and FF don't.  But we think that it should?
17:40:32 <TabAtkins_> TabAtkins_: yeah.
17:40:45 <TabAtkins_> sylvaing: What effects would this have on elapsedTime?  I think it's relative to the animation, not absolute.
17:40:53 <TabAtkins_> smfr: I think so - the time the animation ahs already been running.
17:41:02 <smfr> ^elapsedTime
17:41:15 <TabAtkins_> RESOLVED: An initially-paused animation is still started (fires start events, etc.)
17:41:28 <smfr> and it may be paused during the delay phase
17:42:26 <TabAtkins_> RESOLVED: Animations can be paused during their delay phase, which freezes the remaining delay to be applied after it unpauses.
17:42:46 <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14787
17:43:17 <Zakim> -hober
17:43:36 <TabAtkins_> sylvaing: Is it intentional that animation-play-state can't be applied int he shorthand?
17:43:40 <Zakim> +hober
17:44:00 <TabAtkins_> smfr: I think it was intentional, because of potential ambiguity collision with animation names, and low possibility of usefulness.
17:44:06 <TabAtkins_> sylvaing: I'm fine with that.
17:44:37 <TabAtkins_> RESOLVED: animation-play-state is not in the shorthand on purpose
17:44:42 <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14786
17:45:05 <glazou> Zakim, mute me
17:45:05 <Zakim> glazou should now be muted
17:45:19 <glazou> Zakim, unmute me
17:45:20 <Zakim> glazou should no longer be muted
17:45:24 <smfr> agreed
17:45:45 <TabAtkins_> 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)?
17:46:06 <TabAtkins_> RESOLVED: animation-play-state has the same list behavior as the other animation properties, matching the length of animatino-name.
17:46:24 <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20092
17:46:37 <plinss> s/animatino-name/animation-name/
17:47:07 <TabAtkins_> sylvaing: Tab had a proposal to add the ability to have "adjacent" keyframes, which are explicitly next to each other.
17:47:21 <TabAtkins_> sylvaing: Today you have to hack around it with "50%" and "50.00001%" or similar.
17:47:45 <TabAtkins_> florian: Sounds useful, but we have to finisht he current level, so I'd prefer to delay it.
17:47:50 <TabAtkins_> fantasai: Agreed.
17:48:14 <TabAtkins_> RESOLVED: Look into "adjacent keyframes" for level 4, but not for the current level.
17:48:36 <TabAtkins_> sylvaing: The rest are animation/transition stuff that we want dbaron for, or some interrelated bugs I need to work on.
17:49:20 <TabAtkins_> Topic: 'pointer' MQ
17:49:42 <TabAtkins_> glazou: The pointer MQ hasn't been discussed in the group.
17:49:52 <TabAtkins_> glazou: It may have been a side discussion, but hasn't been official.
17:50:46 <TabAtkins_> glazou: I don't want to put the burden on florian specifically, but it's a good chance to remind people on hwo 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.
17:51:32 <Zakim> +[IPcaller]
17:51:38 <TabAtkins_> 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 int he draft so that there's *something* to discuss.
17:51:43 <tantek> Zakim, IPcaller is tantek
17:51:43 <Zakim> +tantek; got it
17:51:52 <TabAtkins_> 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.
17:51:54 <glenn> an editor's draft is an "Editor's
17:52:06 <glenn> "Editor's" draft
17:52:30 <glenn> what goes into an ED does not have to have be discussed by the group beforehand
17:52:37 <TabAtkins_> 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.
17:52:41 <glenn> s/what/... what/
17:52:42 <tantek> glazou: when you add something to an ED, please send an email to the list
17:52:48 <TabAtkins_> glazou: That way we know about your new feature and can discuss it.
17:53:29 <TabAtkins_> glazou: I just want to make sure that we don't fall into the same trap again.
17:54:08 <TabAtkins_> glazou: [doesn't quite like the syntax]
17:54:19 <TabAtkins_> florian: I'd like to describe why I put the feature in, before discussing details.
17:54:45 <TabAtkins_> florian: My impression is that media features are... screen is used everywhere, but things like "handheld" are failures.
17:54:55 <TabAtkins_> florian: So move away from media types, and move toward media features.
17:55:14 <TabAtkins_> florian: Right now, since the mobile browsers dont' advertise themselves as "handheld", there's no good way to figure out when your'e on one.
17:55:48 <TabAtkins_> florian: [touch things arent' accurate with pointer, and you can't hover]
17:56:07 <tantek> what is it that makes a media type "special"?
17:56:15 <tantek> I think that changes too fast at this point
17:56:17 <TabAtkins_> florian: I think "print" isnt' 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.
17:56:29 <Zakim> -SimonSapin
17:56:41 <tantek> there are no fixed axiomatic descriptions of such media types - that's what we've learned (with the exception of print)
17:56:47 <TabAtkins_> 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.
17:56:51 <fantasai> florian: I'm not very strongly attached to these specific media queries, but the general direction I think is the right way to go.
17:57:02 <fantasai> glazou: Accuracy of pointer depends on the zoom level.
17:57:06 <Zakim> +SimonSapin
17:57:09 <TabAtkins_> glazou: The accuracy of the pointer depends on the zoom level.
17:57:30 <TabAtkins_> florian: The property should describe the accuracy of the pointer at the default level.
17:57:41 <TabAtkins_> florian: You can make things more accurate, but it would be inconvenient for the user.
17:57:56 <TabAtkins_> hober: I raised the same point as daniel just now.
17:58:19 <TabAtkins_> hober: I think the underlying problem is that media queries in the past that have failed are because they're exclusive.
17:58:24 <TabAtkins_> hober: We should fix that first.
17:58:50 <TabAtkins_> 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.
17:59:28 <TabAtkins_> hober: If zoom doesn't increase these, my concern is that well get ugly-looking websites.
17:59:56 <TabAtkins_> florian: This just affects the default level of the button size, etc.  When you zoom, they just scale appropriately.
17:59:56 <tantek> I also dislike the 'pointer' media query
18:00:04 <tantek> changes based on screen resolution etc.
18:00:05 <Zakim> -glazou
18:00:29 <smfr> gtg
18:00:35 <Zakim> -smfr
18:00:44 <TabAtkins_> TabAtkins_: Just to counteract everyone else, I love the media query.
18:00:50 <tantek> TabAtkins, how you'd use the mediaquery changes on pixel density
18:00:59 <tantek> fantasai: also concerned about coarse vs. fine
18:01:10 <tantek> I agree that "coarse" is bad
18:01:11 <TabAtkins_> tantek: No, it wouldn't.  Can you give an example of why you think that?
18:01:36 <tantek> TabAtkijns, screens have different pixel densities, thus different "fuzziness" of what finger taps hit
18:01:38 <TabAtkins_> fantasai: [some concern about the definition of fine/course being unclear]
18:01:39 <fantasai> fantasai: how coarse is coarse? how does that inform the design?
18:01:43 <tantek> "coarse" doesn't capture it
18:02:07 <tantek> also "coarse" sounds like "CORS"
18:02:12 <Zakim> -SteveZ
18:02:13 <Zakim> -TabAtkins_
18:02:13 <Zakim> -hober
18:02:15 <Zakim> -[Microsoft.aa]
18:02:15 <Zakim> -fantasai
18:02:16 <Zakim> -[Microsoft]
18:02:16 <Zakim> -leif
18:02:17 <Zakim> -glenn
18:02:17 <Zakim> -??P92
18:02:18 <Zakim> -antonp
18:02:18 <Zakim> -plinss
18:02:18 <Zakim> -darktears
18:02:19 <tantek> another reason not to use that term
18:02:20 <Zakim> -florian
18:02:20 <Zakim> -SimonSapin
18:02:20 <TabAtkins_> tantek: Sub-pixel accuracy is completely swamped by gross size.
18:02:21 <Zakim> -tantek
18:02:24 <Zakim> -[Microsoft.a]
18:02:24 <florian> florian has left #css
18:02:44 <TabAtkins_> Seriously, 2x pixel density might vary the size fo the touch target by ~ 1/200th of an inch.
18:02:45 <liam> liam has joined #css
18:02:56 <TabAtkins_> That's irrelevant when we're talking about 10px high versus 20px high.
18:03:07 <SimonSapin1> SimonSapin1 has joined #css
18:03:34 <tantek> I also think that these are a bit present-context (this year's devices) anachronistic.
18:04:03 <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!
18:04:34 <tantek> handheld predated large screen smartphones - which is why no "large screen mobile" devices or sites bother with "handheld"
18:04:44 <tantek> (they just use m.example.com instead of example.com)
18:05:13 <tantek> similarly with TV - was based on old analog TV resolutions, constraints ("safe area", refresh rates, single pixel line problems)
18:05:34 <tantek> that reminds me. we need to turn both the TV Profile and the Mobile Profile into Notes.
18:07:26 <Zakim> disconnecting the lone participant, Lea, in Style_CSS FP()12:00PM
18:07:26 <Zakim> Style_CSS FP()12:00PM has ended
18:07:26 <Zakim> Attendees were plinss, florian, hober, glazou, sylvaing, smfr, +34.93.192.aaaa, leif, antonp, fantasai, darktears, glenn, [Microsoft], SteveZ, SimonSapin, JohnJansen,
18:07:29 <Zakim> ... +1.832.797.aabb, arronei, TabAtkins_, Lea, tantek
18:29:05 <TabAtkins_> tantek: I agree with you there - trying to slice things into media type categories is a losing proposition.
18:29:40 <TabAtkins_> Phones to tablets to mini-books to laptops to ultrabooks to desktops are more or less a continuum these days, not separable categories.
18:30:06 <tantek> right, the hardware spectrum is filling out
18:30:44 <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
18:31:06 <tantek> as opposed to when sitting a desk
18:31:22 <tantek> but "handheld" vs. "screen" does not (and will not) give you that
18:31:34 <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.
18:31:46 <TabAtkins_> I don't think you can hit that with CSS.
18:31:56 <tantek> exactly, you can be sitting at your desk using your smartphone
18:32:19 <tantek> where you can give it plenty of attention / focus / concentration, and read little details because you're not walking down the street
18:32:43 <tantek> well - we could create a media selector for inertial sensors
18:33:17 <krit> krit has joined #css
18:33:51 <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.
18:34:18 <tantek> like we do with orientation and screen aspect ratios
18:34:46 <tantek> also, touch targets are harder to hit when walking rather than standing, or sitting
18:35:02 <tantek> so "coarse" doesn't cover it
18:35:35 <tantek> on the subject of including things in drafts to get discussion - I'm a fan of course
18:35:49 <tantek> I'm even ok with such experiments/brainstorms making it out to public working drafts
18:36:14 <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.
18:36:34 <tantek> of course that was before public EDs became so prevalent, so maybe it doesn't apply any more?
18:36:54 <tantek> I can also see some value in whatever is in a WD (vs. ED) having some degree of consensus from the WG
18:37:04 <tantek> although that seems to vary from WG to WG, culturally as it were
18:37:29 <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.
18:39:11 <sylvaing> I'd rather be able to add things to the WD 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'
18:40:18 <sylvaing> s/WD/ED
18:52:20 <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.
18:52:41 <TabAtkins> (Similar to how we have only three light levels - those are the minimal useful set for covering the use-cases.)
18:53:16 <TabAtkins> sylvaing: Daniel's point that an editor should at least drop a mail to the group about it immediately is fine, I think.
18:57:23 <SteveZ> SteveZ has joined #css
18:57:46 <florian> florian has joined #css
18:57:46 <florian> florian has left #css
19:01:43 <tantek> TabAtkins - not sure about two values being sufficient. Existing UIs fail at this.
19:01:59 <tantek> E.g. touch keyboards *suck* for when your walking (nearly impossible to use)
19:02:08 <tantek> s/your/you're
19:02:59 <tantek> there's at least three levels (crappy names on purpose) : mobile-coarse, stationery-coarse, and fine
19:05:50 <TabAtkins> tantek: I think touch keyboards kinda suck all the time, personally.  They're a compromise between screen space and normal keyboard layout.
19:09:45 <florian> florian has joined #css
19:13:25 <SteveZ_> SteveZ_ has joined #css
19:27:54 <rhauck> rhauck has joined #css
19:36:10 <florian> florian has left #css
19:43:04 <cabanier> cabanier has joined #css
19:58:04 <Zakim> Zakim has left #css
20:10:50 <arno> arno has joined #css
20:24:54 <drublic> drublic has joined #css
22:08:59 <heycam|away> heycam|away has joined #css
22:18:22 <jet> jet has joined #CSS
22:28:57 <jet_> jet_ has joined #CSS
22:38:05 <sylvaing> sylvaing has joined #css
22:58:05 <jet> jet has joined #CSS
23:27:00 <SimonSapin> SimonSapin has joined #css