- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 13 Jun 2012 14:41:47 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Tie Device Adaptation and Media Queries together so they
resolve changes at the same time.
http://www.w3.org/TR/css-device-adapt/
http://www.w3.org/TR/css3-mediaqueries/
- RESOLVED: Drop the issue in DA about device-pixel-ratio.
- RESOLVED: Drop arbitrary resolution capability from the target-dpi
feature in Device Adaptation.
- Florian gave an overview of new features and other changes proposed
for Media Queries Level 4.
====== Full minutes below ======
Present:
César Acebal
Glenn Adams
Tab Atkins
David Baron
Ryan Betts
Arron Eicholz
Katie Ellison
Elika Etemad
Sylvain Galineau
Daniel Glazman
Vincent Hardy
Koji Ishii
John Jansen
Divya Manian
Anton Prowse
Florian Rivoal
Alan Stearns
<RRSAgent> logging to http://www.w3.org/2012/06/13-css-irc
Scribe: Tab Atkins
Administrative
--------------
glazou: Any other agenda items?
florian: I was wondering if there was something to actually do with
Flexbox this week.
TabAtkins: Nothing to discuss about flexbox this week.
glazou: Everyone noticed that our two drafts were published this week?
Box Alignment and Flexbox.
Device Adaptation
-----------------
glazou: Note that the Apple people aren't on the call today.
<glazou> http://www.w3.org/Style/CSS/Tracker/products/38
<florian> http://www.w3.org/Style/CSS/Tracker/issues/264
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.
florian: It's okay to say that, but we should probably tie the two together.
florian: So there's a proposed wording for synchronizing them.
<rbetts> The message in question:
http://lists.w3.org/Archives/Public/www-style/2012Jun/0224.html
florian: [describes existing text, copied from MQ]
<glazou> thanks rbetts
florian: We'd like to add "however, UAs that also support MQ must reevaluate
at any time that would cause them to reevalulate MQs.
dbaron: Should the requirement be bidirectional?
florian: I don't see any harm in making it MUST in both directions.
<glenn> what is the granularity for evaluating "change"? every second,
every nanosecond?
<TabAtkins> glenn, it's UA-dependent.
<glenn> guidelines for interop would be useful
<TabAtkins> glenn: the proper definition isn't timer-based. It's based on
when changes actually happen.
<glenn> tabatkins: not good enough to just say UA dependent, need guidelines
florian: So tweak the wording to make it bidirectional.
RESOLVED: Tie DA and MQ together so they resolve changes at the same time.
<florian> http://www.w3.org/Style/CSS/Tracker/issues/239
florian: The spec says nothing about fractional pixel lengths.
florian: And the constraining procedure can result in 0px for width or
height.
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.
astearns: Can you distinguish between it being made 0 due to device
adaptation and it being explicitly specified as 0?
florian: I don't think it's useful to make the viewport 0 width or height
anyway.
florian: Do we have a universal rounding mechanism?
florian: Or should we specify the mechanism?
glazou: If we're speaking of the viewport, a single pixel can be important.
dbaron: It's not clear to me what these values are that you're talking
about rounding.
dbaron: Also, Acid3 does test the behavior of MQ in a zero-sized viewport.
<rbetts> The referenced section:
http://dev.w3.org/csswg/css-device-adapt/#constraining-procedure
florian: The constraining algorithm sets a bunch of descriptors, then
runs them together to set the initial value of the viewport.
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.
dbaron: I think we do have non-integer number of pixels. And in high-dpi
devices, you might want it more.
dbaron: That said, this is a weird context - it's the fake viewport you're
using to zoom around in.
sylvaing: I'm not so concerned about the 0 thing, but am somewhat concerned
about rounding in high-DPI.
sylvaing: I think we should specify rounding behavior, but I don't care
that much about the super-small viewport.
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 rounding
scheme for subpixels.
dbaron: I'd rather not try and solve rounding here first.
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 doesn't matter much, and end up copying it to places
where it does matter and might be incompatible.
florian: Okay, so we can postpone this for now.
florian: Next issue:
florian: Issue 238
<glazou> http://www.w3.org/Style/CSS/Tracker/issues/238
florian: It mentions the existence of the non-standard device-pixel-ratio MQ.
florian: It asks if we should define this or not, since it's redundant
with resolution.
TabAtkins: I'm somewhat for defining device-pixel-ratio, because of its
pickup on the mobile web in webkit.
florian: I'd rather have it in MQ.
TabAtkins: Oh yes, sorry, I'd fine with dropping the issue here and
raising it in MQ.
<dbaron> I think we need to define device-pixel-ratio
<dbaron> despite that I don't like it
<sylvaing> people don't wait for the WG to drop prefixes; they future-proof
by writing the unprefixed version ahead of time
fantasai: If the compat issue is just -webkit prefixed d-p-r, I don't
think it's as much of an issue. People can switch to 'resolution'
when they decide to unprefix. But if there's compat with unprefixed
d-p-r, then we can talk about it.
florian: I'd like to talk about this within MQ.
RESOLVED: Drop the issue in DA about device-pixel-ratio.
<florian> http://www.w3.org/Style/CSS/Tracker/issues/237
florian: This whole thing was drafted to both have a sensible behavior,
and to have enough hooks so that existing implementations of
meta-viewport could be mapped into this.
florian: The Android browser has a target density property, which lets
you set the size of a CSS pixel.
florian: So we've introduced this concept.
florian: I think that most of the time authors are best served by making
it magic.
florian: But in some cases, I think it might make sense to request 1
device pixel per CSS pixel.
florian: But I think all other values are nonsense.
florian: So I'd like drop the capability to set arbitrary values.
TabAtkins: Can you elaborate on use-cases for this?
florian: It may be useful for performance reasons.
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.
<hober> http://lists.webkit.org/pipermail/webkit-dev/2012-June/020914.html seems relevant
florian: I don't know if both Android Browser and Chrome for Android
have it, but iphone doesn't.
TabAtkins: Hober's link seems to show mild support for Chrome dropping it.
rbetts: The only way I've found target-densitydpi useful is when the
default for the device is broken, like the original Galaxy Tab.
florian: So it sounds like agreement that we can drop arbitrary resolutions,
and we might not want it at all.
florian: I'd really like to get rid of the first part, and we can take the
more general question up later.
RESOLVED: Drop arbitrary resolution capability from the target-dpi feature
in Device Adaptation.
glazou: Choice now - go to 2.1 issues, or deal with Hamburg issues.
Media Queries 4
---------------
florian: MQ4 is starting now.
florian: Several new things I'm wanting to do:
florian: I'm interested in more media features.
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.
florian: So we should give up on media types and instead rely on media
features.
florian: Real differences are:
florian: differences in input mechanisms
florian: One approach that was tried out in Moz was an explicit media
query for touch.
florian: I don't think this is a good idea - it's not a media feature,
it's a type.
florian: For example, touch is special in two ways.
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.
florian: The other way it's different is that the pointer isn't very
accurate.
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.
florian: using these we can categorize and design against a whole range
of devices.
<hober> if you zoom in a finger can be accurate...
sylvaing: Devices today match :hover when the user presses on something.
sylvaing: So no one will ever report "no" on the hover pseudo.
TabAtkins: It's not a strict "do you support the :hover pseudo" or not.
It's about whether you have a persistent pointer on the
screen that can hover over things.
florian: Another difference between tv and others is that you don't have
a convenient way to scroll, so you want to put everything on
the single viewport.
florian: So hoverability, accuracy, and scrollability are the three MQ
that I want to add for input.
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.
florian: So in general I want to extend media features to do everything
that media types were originally supposed to do.
florian: Because media types aren't useful in practice.
florian: For example, the grid feature lets you detect if you're on a tt
device, no need for a media type about it.
<sylvaing> I note that laptops with touch screen and mice work fine with
windows 8 and have both a persistent pointer and touch support....
<TabAtkins> sylvaing: Similar stuff on our side - we're happy with the
definitions as they exist, and will give feedback about how
we deal with it.
<sylvaing> Tab, I'm not worried about the definition but the things that
will be done with them. Specifically under the assumption that
mouse and touch are mutually exclusive as they have been for
some time now...
* fantasai agrees with sylvaing, it seems like this all is going in a
good direction, but needs more thought
<TabAtkins> Yeah, I'm saying that we're well aware that they're not
exclusive, and we find it still useful here.
<sylvaing> so use-cases for detecting this are the important bit; I'm
not too worried about the detection itself
<sylvaing> in other words, I'm concerned that touch detection could turn
into another resolution-like hot mess if we don't go carefully
through the use-cases beforehand...
<fantasai> sylvaing++
<TabAtkins> yup, agreed.
<Katie> sylvaing++
florian: The other thing I want to do is pull the OM into the MQ spec,
rather than being in the CSSOM spec.
florian: There's also another MQ spec about whether you're fullscreen,
widgeted, etc.
florian: That spec is already CR. I think it's worth merging this into
MQ so it's all defined in one place.
<Ms2ger> http://www.w3.org/TR/view-mode/
glazou: Do you think pulling the view mode stuff in will create a long
delay for PR?
glazou: And OM stuff.
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.
glazou: ok
florian: There are fairly large editorial rewrite - I've shuffled bits
around and such.
* fantasai suggests breaking media features down into subsections
florian: It's not standalone - right now the media types just point to
CSS 2.1. I'd prefer to pull those in.
florian: Final thing I want to do is deprecate some media types.
florian: speech and print are used, and maybe speech.
florian: But the other ones aren't actually in use.
florian: It's misleading for authors to have a handheld type that never
matches on any handheld device.
florian: This is why I want to introduce the features that actually let
you detect what sorts of devices you're on.
florian: What else should we do in MQ4?
glazou: Some people wanted to test for the presence of scripting or not.
florian: Oh yes, I forgot about that. I already have a draft about that.
<nimbu> wait is this similar to @supports by dbaron?
http://dev.w3.org/csswg/css3-conditional/
<TabAtkins> nimbu: Only insofar as @supports is kinda a Media Query.
<nimbu> *TabAtkins: that would be cool.*
fantasai: There were some requests from the a11y side to test for high-contrast.
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.
fantasai: Different OSes may have different conventions, so we might
need multiple options.
dbaron: I'm not sure that any OS actually changes the bits being sent over.
Yes to color schemes and such.
sylvaing: On windows it shuts down box shadows and changes default control
rendering and such.
sylvaing: There's a prefixed IE MQ about this.
dbaron: In gecko, I think if the user is in high-contrast mode we disable
the ability of the page to set colors.
Miscellaneous
-------------
sylvaing: Is B&B still at a point where we can add a note?
fantasai: Yes, editorial is fine.
sylvaing: We had a fun issue about border-radius lowering the hit-area.
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.
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.
fantasai: Send a suggestion to the list, we'll add it.
<fantasai> http://wiki.csswg.org/topics/overflow-formatting-context
glazou: Action everyone to review the 2.1 issue at
http://wiki.csswg.org/topics/overflow-formatting-context
for next week's call.
Meeting closed.
Received on Wednesday, 13 June 2012 21:42:17 UTC