IRC log of css on 2012-06-13

Timestamps are in UTC.

15:22:41 [RRSAgent]
RRSAgent has joined #css
15:22:41 [RRSAgent]
logging to
15:22:48 [glazou]
Zakim, this will be Style
15:22:48 [Zakim]
ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 38 minutes
15:22:53 [glazou]
RRSAgent, make logs public
15:36:31 [dbaron]
dbaron has joined #css
15:51:47 [antonp]
antonp has joined #css
15:53:03 [florian]
florian has joined #css
15:56:07 [Zakim]
Style_CSS FP()12:00PM has now started
15:56:14 [Zakim]
15:56:28 [Zakim]
+ +1.206.324.aaaa
15:56:35 [glenn]
zakim, ??p48 is glenn
15:56:35 [Zakim]
+glenn; got it
15:56:37 [sylvaing]
Zakim, aaaa is sylvaing
15:56:37 [Zakim]
+sylvaing; got it
15:57:24 [glenn]
sylvaing: working on response to ur email... will send something in next few hours
15:57:24 [Zakim]
15:57:33 [florian]
Zakim, I am ??P6
15:57:35 [Zakim]
+florian; got it
15:57:42 [rbetts]
rbetts has joined #css
15:58:15 [Zakim]
+ +1.604.312.aabb
15:58:31 [sylvaing]
glenn, cool thx!
15:58:32 [rbetts]
aabb is me
15:59:01 [glazou]
Zakim, code?
15:59:02 [Zakim]
the conference code is 78953 (tel:+1.617.761.6200, glazou
15:59:07 [glenn]
zakim, aabb is rbetts
15:59:07 [Zakim]
+rbetts; got it
15:59:23 [Zakim]
15:59:39 [glazou]
Zakim, why do I _always_ need to dial in twice before being able to log in?
15:59:39 [Zakim]
I don't understand your question, glazou.
15:59:45 [glazou]
Zakim, ??P14 is me
15:59:45 [Zakim]
+glazou; got it
15:59:50 [Zakim]
+ +93550aacc
16:00:03 [antonp]
Zakim, aacc is me
16:00:03 [Zakim]
+antonp; got it
16:00:57 [Zakim]
+ +1.415.766.aadd
16:01:08 [dbaron]
Zakim, aadd is dbaron
16:01:08 [Zakim]
+dbaron; got it
16:01:18 [Zakim]
+ +1.206.390.aaee
16:01:26 [stearns]
zakim, aaee is me
16:01:26 [Zakim]
+stearns; got it
16:01:33 [Zakim]
16:01:38 [dbaron]
I really don't understand why zakim remembers my phone number to name association on some weeks but not others
16:01:51 [Zakim]
16:01:53 [arronei]
zakim, microsoft has me
16:01:54 [Zakim]
+arronei; got it
16:01:54 [glazou]
same thing here
16:01:57 [Zakim]
+ +1.650.253.aaff
16:01:59 [stearns]
16:02:06 [TabAtkins]
zakim, aaff is me
16:02:20 [Zakim]
+TabAtkins; got it
16:03:02 [TabAtkins]
ScribeNick: TabAtkins
16:03:24 [vhardy_]
vhardy_ has joined #css
16:03:26 [Zakim]
16:03:41 [vhardy_]
zakim, who is here?
16:04:14 [Zakim]
On the phone I see glenn (muted), sylvaing, florian, rbetts, glazou, antonp, dbaron, stearns, ??P32, [Microsoft], TabAtkins, ??P33
16:04:19 [Zakim]
[Microsoft] has arronei
16:04:23 [Zakim]
16:04:47 [JohnJansen]
JohnJansen has joined #CSS
16:04:55 [Zakim]
16:05:03 [JohnJansen]
zakim, microsoft has johnjansen
16:05:03 [Zakim]
On IRC I see vhardy_, rbetts, florian, antonp, dbaron, RRSAgent, Zakim, glazou, shepazu, koji, miketaylr, glenn, SimonSapin, drublic, Ms2ger, macpherson, kennyluck, isherman,
16:05:09 [TabAtkins]
glazou: Any other agenda items?
16:05:10 [Zakim]
... gsnedders, danielfilho, TabAtkins, hober, decadance, trackbot, heycam|away, fantasai, Bert, stearns, logbot, Hixie, Liam, CSSWG_LogBot, paul___irish, plinss, alexmog, shans,
16:05:10 [leaverou]
leaverou has joined #css
16:05:15 [Zakim]
... krijnh, vhardy, ed, arronei, sylvaing
16:05:28 [TabAtkins]
florian: I was wondering if there was something to actually do with Flexbox this week.
16:05:33 [Zakim]
16:05:45 [Zakim]
+johnjansen; got it
16:05:50 [alexmog_]
alexmog_ has joined #css
16:05:50 [TabAtkins]
TabAtkins: Nothing to discuss about flexbox this week.
16:06:02 [vhardy_]
Zakim, ??P33 is vhardy_
16:06:07 [TabAtkins]
glazou: Everyone noticed that our two drafts were published this week? Box Alignment and Flexbox.
16:06:15 [oyvind]
oyvind has joined #css
16:06:22 [TabAtkins]
Topic: Device Adaptation
16:06:41 [TabAtkins]
glazou: Note that the Apple people aren't on the call today.
16:06:44 [Zakim]
+vhardy_; got it
16:06:59 [glazou]
16:07:02 [florian]
16:07:23 [Zakim]
16:07:36 [TabAtkins]
florian: In MQ there is a piece of text in MQ that says you don't really have to evaluate MQ when the environment changes. Device Adapation copied that.
16:07:46 [TabAtkins]
florian: It's okay to say that, but we should probably tie the two together.
16:07:52 [Zakim]
16:07:52 [fantasai]
Zakim ??P67 is fantasai
16:08:00 [TabAtkins]
florian: So there's a proposed wording for synchronizing them.
16:08:23 [rbetts]
The message in question:
16:08:26 [Katie]
Katie has joined #css
16:08:26 [TabAtkins]
florian: [describes existing text, copied from MQ]
16:08:41 [glazou]
thanks rbetts
16:09:06 [TabAtkins]
florian: We'd like to add "however, UAs that also support MQ must reevaluate at any time that would cause them to reevalulate MQs.
16:09:20 [TabAtkins]
dbaron: Should the requirement be bidirectional?
16:09:22 [glenn]
what is the granularity for evaluating "change"? every second, every nanosecond?
16:09:46 [TabAtkins]
florian: I don't see any harm in making it MUST in both directions.
16:09:56 [glenn]
guidelines for interop would be useful
16:10:25 [Zakim]
+ +1.206.427.aagg
16:10:40 [TabAtkins]
florian: So tweak the wording to make it bidirectional.
16:10:49 [Katie]
Zakim, +1.206.427.aagg has me
16:10:49 [Zakim]
+Katie; got it
16:11:29 [TabAtkins]
RESOLVED: Tie DA and MQ together so they resolve changes at the same time.
16:11:32 [glenn]
tabatkins: not good enough to just say UA dependent, need guidelines
16:11:42 [florian]
16:12:00 [CesarAcebal]
CesarAcebal has joined #css
16:12:12 [TabAtkins]
florian: The spec says nothing about fractional pixel lengths.
16:12:24 [TabAtkins]
florian: And the constraining procedure can result in 0px for width or height.
16:12:48 [Zakim]
+ +1.425.753.aahh
16:12:51 [Zakim]
+ +34.60.940.aaii
16:12:59 [TabAtkins]
florian: So I recommend we add some text that says that fractional pixels are rounded to the nearest whole pixel, and if it would round to 0, it instead rounds to 1px.
16:13:02 [CesarAcebal]
zakim, aaii is me
16:13:02 [Zakim]
+CesarAcebal; got it
16:14:04 [TabAtkins]
astearns: Can you distinguish between it being made 0 due to device adaptation and it being explicitly specified as 0?
16:14:11 [Zakim]
16:14:23 [koji]
zakim, ??p15 is me
16:14:23 [Zakim]
+koji; got it
16:14:29 [TabAtkins]
florian: I don't think it's useful to make the viewport 0 width or height anyway.
16:14:53 [TabAtkins]
florian: Do we have a universal rounding mechanism?
16:15:01 [TabAtkins]
florian: Or should we specify the mechanism?
16:15:44 [TabAtkins]
glazou: If we're speaking of the viewport, a single pixel can be important.
16:15:57 [TabAtkins]
dbaron: It's not clear to me what these values are that you're talking about rounding.
16:16:09 [TabAtkins]
dbaron: Also, Acid3 does test the behavior of MQ in a zero-sized viewport.
16:17:11 [rbetts]
The referenced section:
16:17:20 [TabAtkins]
florian: The constraining algorithm sets a bunch of descriptors, then runs them together to set the initial value of the viewport.
16:18:09 [TabAtkins]
florian: If you end up specifying a viewport as .1px wide, or even 1.3 wide, you want to make it an integer number of pixels, and probably not 0.
16:18:26 [TabAtkins]
dbaron: I think we do have non-integer number of pixels. And in high-dpi devices, you might want it more.
16:18:38 [TabAtkins]
dbaron: That said, this is a weird context - it's the fake viewport you're using to zoom around in.
16:18:57 [nimbu]
nimbu has joined #css
16:19:25 [TabAtkins]
sylvaing: I'm not so concerned about the 0 thing, but am somewhat concerned about rounding in high-DPI.
16:19:44 [TabAtkins]
sylvaing: I think we should specify rounding behavior, but I don't care that much about the super-small viewport.
16:19:50 [Zakim]
16:19:53 [Zakim]
16:20:10 [krit]
krit has joined #css
16:20:39 [TabAtkins]
florian: If we force integer pixels, we need to define rounding. If we don't, we can either leave it up to UAs, or define a roundign scheme for subpixels.
16:20:51 [TabAtkins]
dbaron: I'd rather not try and solve rounding here first.
16:21:27 [TabAtkins]
dbaron: We have a lot of other places with rounding behavior and a lot of dependencies on that, so I'd prefer not to decide something here where it doesnt' matter much, and end up copying it to places where it does matter and might be incompatible.
16:21:35 [TabAtkins]
florian: Okay, so we can postpone this for now.
16:21:53 [TabAtkins]
florian: Next issue:
16:21:59 [TabAtkins]
florian: Issue 238
16:22:02 [glazou]
16:22:02 [Rossen]
Rossen has joined #css
16:22:10 [TabAtkins]
florian: It mentions the existence of the non-standard device-pixel-ratio MQ.
16:22:19 [florian]
16:22:41 [TabAtkins]
florian: It asks if we should define this or not, since it's redundant with resolution.
16:23:30 [TabAtkins]
TabAtkins: I'm somewhat for defining device-pixel-ratio, because of its pickup on the mobile web in webkit.
16:23:35 [nimbu]
nimbu has joined #css
16:23:35 [fantasai]
zakim, unmute fantasai
16:23:35 [Zakim]
sorry, fantasai, I do not know which phone connection belongs to fantasai
16:23:40 [fantasai]
16:23:51 [TabAtkins]
florian: I'd rather have it in MQ.
16:24:05 [TabAtkins]
TabAtkins: Oh yes, sorry, I'd fine with dropping the issue here and raising it in MQ.
16:25:02 [dbaron]
I think we need to define device-pixel-ratio
16:25:09 [dbaron]
despite that I don't like it
16:25:23 [sylvaing]
people don't wait for the WG to do prefixes; they future-proof by writing the unprefixed version ahead of time
16:25:23 [TabAtkins]
fantasai: If the compat issue is just -webkit prefixed d-p-r, I don't think it's as much of an issue. But if there's compat with unprefixed d-p-r, then we can talk about it.
16:25:28 [sylvaing]
16:25:29 [jet]
jet has joined #CSS
16:25:30 [TabAtkins]
florian: I'd like to talk about this within MQ.
16:25:43 [florian]
16:25:44 [TabAtkins]
RESOLVED: Drop the issue in DA about device-pixel-ratio.
16:26:09 [TabAtkins]
florian: This whole thing was drafted to both ahve a sensible behavior, and to have enough hooks so that existing implementations of meta-viewport could be mapped into this.
16:26:28 [TabAtkins]
florian: The Android browser has a target density property, which lets you set the size of a CSS pixel.
16:26:41 [TabAtkins]
florian: So we've introduced this concept.
16:26:54 [TabAtkins]
florian: I think that most of the time authors are best served by making it magic.
16:27:09 [TabAtkins]
florian: But in some cases, I think it might make sense to request 1 device pixel per CSS pixel.
16:27:14 [TabAtkins]
florian: But I think all other values are nonsense.
16:27:30 [TabAtkins]
florian: So I'd like drop the capability to set arbitrary values.
16:27:40 [TabAtkins]
TabAtkins: Can you elaborate on use-cases for this?
16:28:46 [TabAtkins]
florian: It may be useful for performance reasons.
16:29:18 [TabAtkins]
TabAtkins: I'm mildly for dropping it, unless we have good reasons for keeping it. But if it's easy and there are mildly good reasons for it, I'm okay with keeping it.
16:30:22 [glazou]
hober: don't you listen to your peers at WWDC ???
16:30:28 [Zakim]
- +1.425.753.aahh
16:30:44 [TabAtkins]
florian: I don't know if both Android Browser and Chrome for Android have it, but iphone doesn't.
16:30:59 [TabAtkins]
TabAtkins: Hober's link seems to show mild support for Chrome dropping it.
16:31:23 [TabAtkins]
rbetts: The only way I've found target-densitydpi useful is when the default for the device is broken, like the original Galaxy Tab.
16:32:04 [TabAtkins]
florian: So it sounds like agreement that we can drop arbitrary resolutions, and we might not want it at all.
16:32:24 [TabAtkins]
florian: I'd really like to get rid of the first part, and we can take the more general question up later.
16:32:39 [TabAtkins]
RESOLVED: Drop arbitrary resolution capability from the target-dpi feature in Device Adaptation.
16:35:12 [TabAtkins]
glazou: Choice now - go to 2.1 issues, or deal with Hamburg issues.
16:36:20 [TabAtkins]
Topic: Media Queries 4
16:36:25 [TabAtkins]
florian: MQ4 is starting now.
16:36:32 [TabAtkins]
florian: Several new things I'm wanting to do:
16:36:45 [TabAtkins]
florian: I'm interested in more media features.
16:37:14 [TabAtkins]
florian: For example, people want to design different websites on a tv and on a tablet, but going by media type (handheld vs tv) doesn't work because everyone reports themselves as screen.
16:37:24 [TabAtkins]
florian: So we should give up on media types and instead rely on media featuresd.
16:37:28 [TabAtkins]
florian: Real differences are:
16:37:34 [TabAtkins]
florian: differences in input mechanisms
16:37:48 [TabAtkins]
florian: One approach that was tried out in Moz was an explicit media query for touch.
16:37:59 [TabAtkins]
florian: I dont' think this is a good idea - it's not a media feature, it's a type.
16:38:07 [TabAtkins]
florian: For example, touch is special in two ways.
16:38:22 [TabAtkins]
florian: It can't do hovering well, so a "hover" media query would let you know if you should do :hover-based menus or not.
16:38:31 [TabAtkins]
florian: The other way it's different is that the pointer isn't very accurate.
16:38:48 [TabAtkins]
florian: So a MQ saying if you have an accurate pointer like a stylus or mouse versus an inaccurate one like a finger or a wiimote.
16:39:00 [TabAtkins]
florian: using these we can categorize and design against a whole range of devices.
16:39:25 [hober]
if you zoom in a finger can be accurate...
16:40:46 [TabAtkins]
sylvaing: Devices today match :hover when the user presses on something.
16:40:59 [TabAtkins]
sylvaing: So no one will ever report "no" on the hover pseudo.
16:41:32 [TabAtkins]
TabAtkins: It's not a strict "do you support the :hover pseudo" or not. It's about whether you ahve a persistent pointer on the screen that can hover over things.
16:41:50 [TabAtkins]
florian: Another difference between tv and others is that you don't ahve a convenient way to scroll, so you want to put everything on the single viewport.
16:42:12 [TabAtkins]
florian: So hoverability, accuracy, and scrollability are the three MQ that I want to add for input.
16:42:36 [TabAtkins]
florian: There are more I want to address, such as one asking for whether you're paged or not, since that's no longer strictly tied to being "print" or not.
16:42:51 [TabAtkins]
florian: So in general I want to extend media features to do everything that media types were originally supposed to do.
16:43:03 [TabAtkins]
florian: Because media types aren't useful in practice.
16:43:29 [TabAtkins]
florian: For example, the grid feature lets you detect if you're on a tt device, no need for a media type about it.
16:43:32 [sylvaing]
I note that laptops with touch screen and mice work fine with windows 8 and have both a persistent pointer and touch support....
16:43:57 [TabAtkins]
florian: The other thing I want to do is pull the OM into the MQ spec, rather than being in the CSSOM spec.
16:44:53 [TabAtkins]
florian: There's also another MQ spec about whether you're fullscreen, widgeted, etc.
16:45:08 [TabAtkins]
florian: This spec is already CR. I think it's worth merging this into MQ so it's all defined in one place.
16:45:12 [Ms2ger]
16:45:57 [TabAtkins]
glazou: Do you think pulling the view mode stuff in will create a long delay for PR?
16:46:22 [TabAtkins]
glazou: And OM stuff.
16:46:52 [TabAtkins]
fantasai: I think worrying about transitioning to PR is premature right now. We can always mark things as at-risk later. We don't even have a FPWD yet.
16:47:05 [fantasai]
16:47:15 [Katie]
16:47:24 [TabAtkins]
glazou: ok
16:47:42 [TabAtkins]
florian: There are fairly large editorial rewrite - I've shuffled bits around and such.
16:48:16 [TabAtkins]
florian: It's not standalone - right now the media types just point to CSS 2.1. I'd prefer to pull those in.
16:48:57 [TabAtkins]
florian: Final thing I want to do is deprecate some media types.
16:49:08 [TabAtkins]
florian: speech and print are used, and maybe speech.
16:49:17 [TabAtkins]
florian: But the other ones aren't actually in use.
16:49:37 [TabAtkins]
florian: It's misleading for authors to have a handheld type that never matches on any handheld device.
16:50:00 [TabAtkins]
florian: This is why I want to introduce the features that actually let you detect what sorts of devices you're on.
16:50:24 [TabAtkins]
florian: What else should we do in MQ4?
16:50:33 [TabAtkins]
glazou: Some people wanted to test for the presence of scripting or not.
16:50:44 [TabAtkins]
florian: Oh yes, I forgot about that. I already have a draft about thqat.
16:51:33 [TabAtkins]
fantasai: There were some requests from the a11y side to test for high-contrast.
16:52:06 [TabAtkins]
TabAtkins: We discussed that casually in the f2f, and the question we had was whether "high-contrast mode" means the OS has forced you into high-contrast or if it's asking you to make yourself high-contrast.
16:52:17 [TabAtkins]
fantasai: Different OSes may have different conventions. We may need options there.
16:52:30 [nimbu]
florian: wait is this similar to @supports by dbaron?
16:52:36 [Zakim]
16:53:06 [Katie]
hides sprites
16:53:09 [Katie]
16:53:27 [fantasai]
nimbu: what is?
16:53:49 [TabAtkins]
dbaron: I'm not sure that any OS actually changes the bits being sent over. Yes to color schemes and such.
16:54:03 [TabAtkins]
sylvaing: On windows it shuts down box shadows and changes default control rendering and such.
16:54:13 [TabAtkins]
sylvaing: There's a prefixed IE MQ about this.
16:54:29 [nimbu]
fantasai: (MQ4 discussion that glazou just mentioned about adding detection for scripting etc)
16:54:37 [nimbu]
sorry it was glazou not florian.
16:54:39 [TabAtkins]
dbaron: In gecko, I think if the user is in high-contrast mode we disable the ability of the page to set colors.
16:55:12 [TabAtkins]
sylvaing: Is B&B still at a point where we can add a note?
16:55:17 [TabAtkins]
fantasai: Yes, editorial is fine.
16:55:32 [nimbu]
*TabAtkins: that would be cool.*
16:55:48 [TabAtkins]
sylvaing: We had a fun issue about border-radius lowering the hit-area.
16:56:22 [TabAtkins]
sylvaing: The back button in the Windows Store, for example, was sized to the normal "minimum finger-touch area", then was reduced by border-radius, and we had usability problems with missed touches.
16:56:48 [TabAtkins]
sylvaing: So maybe a note that when designing for touch accessibility, design it so that the hit area fits within the border-radius-reduced shape.
16:56:56 [TabAtkins]
fantasai: Send a suggestion to the list, we'll add it.
16:57:00 [fantasai]
16:57:12 [Zakim]
16:57:37 [sylvaing]
that's all we need to agree on the scientific notation...
16:57:55 [antonp]
16:58:03 [jet]
jet has joined #CSS
16:58:07 [TabAtkins]
glazou: Action everyone to review the 2.1 issue at for next week's call.
16:58:18 [Zakim]
16:58:19 [Zakim]
16:58:20 [Zakim]
16:58:21 [Zakim]
16:58:21 [Zakim]
16:58:21 [Zakim]
- +1.206.427.aagg
16:58:22 [Zakim]
16:58:24 [Zakim]
16:58:25 [Zakim]
16:58:25 [antonp]
antonp has left #css
16:58:27 [Zakim]
16:58:29 [nimbu]
nimbu has left #css
16:58:29 [Zakim]
16:58:32 [Zakim]
16:58:33 [Zakim]
16:58:35 [Zakim]
16:59:01 [TabAtkins]
fantasai: I'll be in SF on Friday. Wanna meet up for a bit to review the flexbox sizing issue that Alex raised?
16:59:19 [fantasai]
TabAtkins: yes!
16:59:54 [fantasai]
TabAtkins: we should also pick a day and spend it doing editorial author-friendly edits for flexbox, like glazou requested
17:00:00 [TabAtkins]
17:02:04 [Zakim]
17:07:05 [Zakim]
disconnecting the lone participant, [Microsoft.aa], in Style_CSS FP()12:00PM
17:07:07 [Zakim]
Style_CSS FP()12:00PM has ended
17:07:07 [Zakim]
Attendees were +1.206.324.aaaa, glenn, sylvaing, florian, +1.604.312.aabb, rbetts, glazou, +93550aacc, antonp, +1.415.766.aadd, dbaron, +1.206.390.aaee, stearns, arronei,
17:07:07 [Zakim]
... +1.650.253.aaff, TabAtkins, [Microsoft], johnjansen, vhardy_, Katie, +1.425.753.aahh, +34.60.940.aaii, CesarAcebal, koji
17:19:29 [oyvind]
oyvind has left #css
17:25:38 [dbaron]
dbaron has joined #css
18:09:48 [dbaron]
dbaron has joined #css
18:17:26 [logbot]
logbot has joined #css
18:21:43 [leaverou]
leaverou has joined #css
18:26:45 [krijnh]
krijnh has joined #css
18:37:40 [Zakim]
Zakim has left #css
19:32:05 [nimbu]
nimbu has joined #css
19:44:13 [krit]
krit has joined #css
20:02:26 [jet]
jet has joined #CSS
21:31:09 [jet]
jet has joined #CSS
22:02:08 [leaverou]
leaverou has joined #css
22:22:36 [nimbu]
nimbu has joined #css
22:25:12 [fantasai]
leaverou: ping
22:26:54 [jet]
jet has joined #CSS
22:31:22 [krit]
krit has joined #css
22:38:15 [jet]
jet has joined #CSS
22:51:08 [krit]
krit has joined #css