[CSSWG] Minutes TPAC F2F 2020-10-20 Part II: Media Queries [mediaqueries]

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Media Queries
-------------

  - RESOLVED: Adopt the multiscreen MQs into MQ5 (Issue #5621:
              Updating the CSS media feature syntax for foldable &
              dual-screen devices)
  - The multiscreen MQs will need bikeshedding to ensure the names are
      clear and using terms consistent with each other and other MQ.
  - RESOLVED: Add dlibby as editor to MQ5

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/tpac-2020#agenda-schedule

Scribe: TabAtkins

Media Queries
=============

CSS media features for foldable & dual-screen devices
-----------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5621

  dlibby: This is an updated proposal for primitives we'd like to
          introduce for dual-screen and foldable devices
  dlibby: This one is a new media feature that describes the number of
          logical display regions a viewport is spanning across
  dlibby: Not the device itself, the relationship of the viewport to
          the device regions
  dlibby: The syntax is in two axises to allow for future form factors
          to use the same feature
  dlibby: goes hand-in-hand with the environment vars we discussed
          yesterday
  dlibby: Looking for opinions on this and if it's okay to add to mq5

  heycam: My initial thoughts about this is whether these features
          are, don't wanna say complex because the syntax isn't
          complex, but wondering if really there will be that many
          arrangements of displays that we need a feature shaped like
          this, as opposed to something simpler
  dlibby: In our original proposal we were more scoped, but that came
          with the baggage that as new form factors appeared, what is
          the syntax you would use for them?
  dlibby: So we feel this gives a more future-proof model, while
          allowing author to target today's devices

  myles: So for width queries, for example, if you say
         (display-span-x: 3), is that *at least* three screens, or
         exactly 3?
  dlibby: Exactly, if you use the : or =. If you use < or > it gives
          less or more
  myles: This also suggests authors might have different layouts for
         each arrangement - a different for 2x1 vs 1x2 vs 2x2, etc.
         That's the intent?
  dlibby: Yes.

  fantasai: The mq would give you an exact number, but because it's an
            integer it can take min-/max- prefixes as well, so you can
            just opt into "2 or more displays"
  <myles> fantasai, display-span-x: min(2)?
  <TabAtkins> myles, no, (min-display-span-x: 2)
  <myles> TabAtkins: oh! are all number-taking media queries supposed
          to automatically get min- and max- prefixes?
  <TabAtkins> yes

  fantasai: To respond to heycam, the reason I didn't want to do
            simpler syntax, if someone has a 3-fold device we'd need a
            new MQ
  fantasai: The syntax for this simple case isn't any harder to use
            than a more "specialized" one, but it lets us extend to a
            grid easily
  fantasai: It doesn't let us extend to a non-grid, tho
  fantasai: but I think most of the cases we'll need to worry about
            will be a grid or simplification of a grid
  fantasai: Didn't want to box us into a corner of only handling 2
            screens

  florian: I think this works nicely
  florian: As discussed yesterday, desktops can be more complex
           arrangements
  florian: but this isn't just windows that can be slightly offset
           from each other, it's a special display mode
  florian: And I think a grid is really the only realistic mode to
           deal with
  florian: [shows off an example]
  florian: So I think we're good

  smfr: Does the answer to these mqs depend on which screen the
        browser is on?
  smfr: From samsung demos, browser can be on left, right, or spanning
        both
  smfr: So will these change?
  dlibby: Yes, if you're only on a single screen, your display-span
          will be 1
  smfr: So not about the physical device, about the current
        configuration

  fantasai: On that note, think we need some bikeshedding on this - we
            use "display" to refer to the physical device
  fantasai: so like display-width vs width
  fantasai: and we want consistent wording between env() and MQ
  TabAtkins: Note the MQ word is 'device-', not 'display-'
  fantasai: Oh yeah. But the env() is using viewport, so we should be
            consistent between them
  Rossen: So any preferences or opinions?
  TabAtkins: No strong opinion on word, but strong opinion towards
             naming consistency like fantasai said
  <astearns> device-arrangement
  florian: 'viewport' isn't great, it's how your viewport spans
  heycam: Perhaps something about presentation
  fantasai: If you have a normal display it'll have a value of 1
  TabAtkins: If your window spans a folded device, is that span 2 or
             span 1?
  heycam: So I think like 'display-span-x' will sound like it should
          match if your single window spans across both segments even
          if it's just acting like a normal window

  florian: If you're on a device with a seam between screens, then yes
           absolutely
  florian: But on a device with a seamless pane separation, up to the
           UA to decide which way it goes
  dlibby: Valid point, goes down to what Cam was mentioning - if
          you're in more of a tiled mode that the device is informing
          the UA about
  dlibby: So possibility of a seamless device not presenting itself as
          multipane if you're not doing something

  smfr: Some implication of spanning the whole utility area
  smfr: If you span both screens, but half of one screen is filled
        with a different app, your browser is 1.5 screens wide
  smfr: So without information about what size each pane is...
  TabAtkins: That's what the env() is for, reporting those pane sizes
  Rossen: So yeah in your example, the shared pane will just have a
          smaller viewport for the browser in that pane

  florian: So my suggestion is to resolve to adopt it, bikeshed naming
           in github
  florian: But I think we're agreeing to the proposal overall, maybe
           need a few details to be clearer
  florian: But not hearing real pushback
  fantasai: Agree with florian
  fantasai: Also might be useful to query info about the gap, how big
            it is and if there's content missing in the gap - if it
            doesn't paint or if it just jumps across
  dlibby: The env variables are designed let you avoid the gap, but
          perhaps there's a query to make it clearer up front
  myles: Are the env() indexed?
  dlibby: Discussed that a bit yesterday, yes they are
  dlibby: Based on discussion, should match the 2d grid indexing
  <fantasai> The question of whether working on the "explode" model or
             the "window" model is probably relevant -
             http://fantasai.inkedblade.net/style/discuss/table-backgrounds/

  Rossen: So any objections to adopting them into MQ5?

  RESOLVED: Adopt the multiscreen MQs into MQ5.

  <br until=":15">

  [side conversation about mixing environment variables and media
      features in comparisons as media queries,
      e.g. (env(x) > env(y)) or (m-q < env(z)) ]

  [side conversation about breakout rooms and trying to replicate
      hallway conversations virtually]
</br>

Editorship
----------
Scribe: Tantek

  RESOLVED: Add dlibby as editor to MQ5

  astearns: We added Daniel as an editor to MQ spec
  astearns: More editor positions are available on specs as well!
  astearns: If you've been opening issues on specs, and have some
            suggested solutions, we can use the help.
  astearns: Let astearns know on IRC or email if you'd like to take
            him up on the offer

Received on Thursday, 29 October 2020 23:39:19 UTC