[CSSWG] Minutes and Resolutions Telecon 2012-06-13

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