[CSSWG] Minutes Sydney F2F 2018-07-04 Part III: CSS Variables, CSS Environment Variables [css-variables] [css-env-1]

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


CSS Variables
-------------

  - RESOLVED: 'all' shorthand does not reset custom properties (Issue
              #2518)
  - RESOLVED: -- is reserved (Issue #2518)
  - RESOLVED: Don't add shorthand for custom props (Issue #2518)

CSS Environment Variables
-------------------------

  - RESOLVED: Accept proposal in the issue. “UA vendors MUST NOT
              expose built-in env() features to the web without going
              through that process” (Issue #2820)
  - Mostly issue #2868 (Accept safe-area-inset*) was favored in
      general, but it was unclear how the insets are defined when
      different axes interact, as two different definitions were
      possible. Raised use cases raised included round watches, the
      iPhone notch, but also TVs and printers, for which one of the
      definitions wouldn't really work very well. Dino will bring it
      back for discussion after figuring out these issues.
  - The fullscreen-inset proposal (Issue #2871) also was in favor and
      both Microsoft and Apple have already tried to solve for having
      something like a keyboard or a close icon appear without
      shifting what's on screen.
      - It will need to be renamed, though, since it isn't
          really about fullscreen and more about overlaying.

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

Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule

Scribe: fantasai

CSS Variables
=============

Does all reset custom properties?
---------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2518

  TabAtkins: Two questions to this issue. First is does all reset
             custom properties? I say yes
  TabAtkins: Second, should we have something that does? I say yes,
             Emilio says no
  emilio: I don't remember why...
  astearns: Proposed that custom properties don't get reset by all.
            Any objections?

  dbaron: Have ppl checked implementations?
  frremy: Edge doesn't
  xidorn: In Gecko it doesn't reset custom properties either
  emilio: We have an invariant that only have one longhand in a given
          declaration block
  emilio: We only store longhands, we don't store shorthands
  emilio: That's why it doesn't reset custom properties
  emilio: We'd need to rewrite everything.
  TabAtkins: Chrome also does not reset custom properties

  RESOLVED: all shorthand does not reset custom properties

  <TabAtkins> test:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6017

  TabAtkins: Next question, should something reset all custom
             properties
  emilio: Custom properties are inherited, so if you had a -- property
          that resets everything, and it would inherit, so it resets
          everything all the way down the subtree?
  fantasai: It would have to be a non-custom property
  leaverou: What's the usecase?
  TabAtkins: If you have some component, you want to make sure you
             don't get the outer page inheriting stuff into it that
             disrupts your stuff because of name clashes
  emilio: So it would be a longhand
  TabAtkins: So it would be a shorthand
  fantasai: It would be a longhand from engine's perspective, has
            effect of reseting the properties, so it looks like a
            shorthand to the author

  emilio: Reason why it's hard is, it's hard to know when do you need
          to reset it. And hard to make it do the right thing
  emilio: When do you check the value of this property?
  emilio: Presumably you want it to work like all property
  emilio: --: reset;
  emilio: vs --: foo;
  emilio: What properties is it resetting? We don't know what the
          properties are that we're resetting
  emilio: until we've cascaded/inherited all the custom props
  TabAtkins: ... I understand the problem now
  TabAtkins: If you say --foo: red; --: initial; --bar: blue;
  TabAtkins: The --foo needs to be reset to initial, but --bar needs
             to still be blue
  TabAtkins: That's problematic because you have no idea that -- needs
             to expand into --foo until you see that --foo is declared
             on or inherited into that element
  frremy: In Edge we have a registry of all properties, which need to
          be handled before ...
  TabAtkins: So you would expand it to all the properties on the page?
  emilio: That's not the point of the feature
  emilio: You can't expand it at parse time
  frremy: You don't expand at parse time
  xidorn: Expanding at parse time is how shorthand is supposed to work
  emilio: Also, magic of "every prop that has appeared on the page so
          far" is really bad
  frremy: Not proposing that
  TabAtkins: If you do it as that type of pre-scan, then you can do
             this. Otherwise you can't
  emilio: You can't implement as a shorthand, because you don't know
          for serialization what it expands to
  emilio: You have to treat it as a longhand, but then you need to
          look at that property before you look for custom properties
  emilio: Let's say you specify this as a longhand property, then you
          can do what eric said
  emilio: But you need to look at the value of this property before
          computing the custom properties.. which you need to compute
          the values of the rest of the properties (in case they're
          used)
  emilio: Right now we have different phases
  emilio: This would convert it from 2 to 3 phases.
  emilio: First figure out magic property's computed value
  emilio: then figure out custom properties
  emilio: then figure out the rest
  emilio: which is kindof annoying
  ...
  frremy: ...
  emilio: We don't want a global index of custom properties

  xidorn: Maybe we can have a longhand property which doesn't affect
          element itself, but cuts inheritance to its children, which
          doesn't have this problem
  TabAtkins: This would change the inherited value of your custom
             properties on the children to the value of --
  TabAtkins: But then can't both block inheritance from parent and set
             specific custom props for inheritance to your children
  TabAtkins: on the same element
  TabAtkins: Possibility is to make -- take a list of custom
             properties to *not* reset, and then it alters the way
             that all unspecified custom properties inherit to the
             element's children.
  TabAtkins: And then it alters the way that all unspecified custom
             properties inherit to the element's children
  frremy: I don't think we like this
  TabAtkins: I think it's the only way to make -- work on a single
             element without being a shorthand
  astearns: You would be duplicating the properites that you want to
            declare on that element
  TabAtkins: Correct.
  fantasai: Think that this means we should not add the feature.
            Nobody's been clamoring for it anyway.

  RESOLVED: -- is reserved
  RESOLVED: Don't add shorthand for custom props

CSS Environment Variables
=========================

process for adding env() variables
----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2820

  TabAtkins: I agree.
  astearns: Currently spec says “user agents may define additional
            undocumented environment variables”
  * heycam agrees too
  TabAtkins: I think Apple agrees with proposal, too
  dino: When original discussion happened, there was some mumblings
        that some platforms might want to expose system colors
        specific to that platform in some way
  dino: But I don't know if anyone still believes that

  RESOLVED: Accept proposal in the issue. “UA vendors MUST NOT expose
            built-in env() features to the web without going through
            that process”

Accept safe-area-inset*
-----------------------
  github: https://github.com/w3c/csswg-drafts/issues/2868
  drawing referenced below:
https://github.com/w3c/csswg-drafts/issues/2868#issuecomment-402755877

  <astearns> https://drafts.csswg.org/css-env-1/#safe-area-insets
  dino: We proposed this last year
  dino: I think this one is hopefully not so controversial
  dino: We expose it so people can avoid notch in iPhone and rounded
        corners
  dino: But can also be used for e.g. safe area for televisions
  fantasai: Would be really useful for printing as well

  dino: Having experimented with this, it makes sense for insets
  dino: But let's imagine that what you're trying to do is get ppl to
        avoid X in the top corner of the screen
  dino: page shouldn't put anything there
  dino: Should we inset the entire top/left sides?
  dino: Or just a note saying avoid that part of the screen?
  dino: Let's pause and talk about that later?

  dbaron: There was some spec prose that Rebecca Hughes and I iterated
          over
  dbaron: Because I didn't want Google to ship without a spec for it
  dbaron: What I suggested there, and which I think is now in the
          draft,
  dbaron: Was that the insets together should define a rectangle such
          that everything in that rectangle is safe
  dbaron: But what you're showing is your insets are more than that
  dbaron: You could use any pair of them... but that doesn't work for
          the notch
  dino: Right, for notch, we have top and bottom insets and it's fine
  dino: But if your rotate sideways, then you have left and right
        insets
  dbaron: I'm wondering if the diagram is intentional
  dbaron: I'm suggesting that the rectangle inside the insets was safe
  dbaron: but if you move any of those lines outward, then it's no
          longer safe
  (dbaron is talking about taking the largest rectangle that would
      fully fit within the safe area, and using its edges as the inset
      edges vs. considering each inset individually, making sure the
      entire screen is safe along that edge or inward from it)
  dbaron: Specced that the UA is allowed to pick whatever it wants
          that would maximize the the usable space
  dbaron: There are multiple solutions, might want a narrower or wider
          rectangle, that affects how tall it can be
  myles: The UA is the one that decides what safe meanss
  myles: We could say that the innermost rectangle is safe

  dbaron: Prose we put it said something like
          “There is some non-rectangular safe region. The insets
          define some maximal rectangle within that region”
  [fantasai restates what dbaron was saying since ppl look confused]
  dino: I think this definition would be acceptable...
  dino: User agent could also be free to pick a rectangle where it
        only specifies a top and a bottom inset in this case, and uses
        the entire width
  dino: Would be overaggressive in saying what's safe
  fantasai: There might be different use cases for each definition...
  myles: For TV example, there's no horizontal line that's safe all
         the way across
  dino: TV wants more like the green example (individual insets)
  dino: Whereas a rounded display needs more like the red one
        (dbaron's definition)
  iank: Another take is that the green is the same as the red plus a
        margin

  fantasai: Could have two different sets of variables,
            safe-area-inset and safe-rect-inset...
  heycam: With scrolling, might have different preferences on whether
          to maximize horizontal or vertical areas
  myles: UA could alter these
  astearns: Horizontal vs vertical orientation of device, would UA
            reset them depending on orientation?
  dino: Currently does, yes
  myles: ...
  astearns: Are you unsure whether having these four insets is the
            right design?
  dino: I was sure, now wondering whether we should define them as the
        red rectangle
  dino: With the green rectangle you can be safe, if I pad enough from
        the top, I know I'm going to be visible in that case, even
        though I won't be safe...
  dino: Maybe we should hold this.
  dino: I will take this back and discuss with other people
  dbaron: I think the text needs adjusting for the TV use case, also.

Full-screen insets
------------------
  github: https://github.com/w3c/csswg-drafts/issues/2871

  [dino draws a fullscreen video player
    There's a title in the top left corner
    There's controls along the bottom]

  dino: Works fine on a desktop machine because everyone knows you can
        get out with escape or whatever
  dino: But touch interface doesn't have escape key
  dino: So we need to provide some UI for escaping
  dino: e.g. an X in the top left corner
  dino: Fades away if you haven't touched the screen much lately
  dino: Trying to come up with variables to take the page where it can
        draw content when the browser UI is available

  florian: We kindof talked about that when we were doing round
           display, with different approach
  florian: MQ with coordinate, if I put something there, will it be
           visible?
  florian: Rather than browser trying to prove geometry, can just ask
           "can I put the box there"?
  myles: Why would you want to binary search for an available space?
         Seems awful

  [dino writes an example: title { pos: abs; top: env(fs-inset-top); ]
  dino: Can even say title { transition: top 1s; }
  dino: then the title shifts as the browser UI disappears and appears
  dino: While we specify top/left/bottom/right
  dino: Top effectively reserves the entire top
  dino: We might do {various things } in this area
  dino: In safe mode, would also have put the left side offset, but we
        decided to just do the top
  ...
  astearns: So the space taken up by the browser UI is only known when
            the UI is showing
  dino: The issue is that we did that for awhile, and it looks weird
        if the title is not at the top. Looks like they've got a weird
        design
  dino: Other issue I link to, because we fade out the X, it's a good
        example where YouTube fades out their UI as well
  dino: Might want to expose timers on our fading so they can
        synchronize
  heycam: Maybe use events rather than time?
  dino: Events makes more sense, usually we're responding to those in
        JS anyway
  heycam: Also you don't know when exactly to start counting those
          seconds
  dino: We'd also have to publish and make sure everyone's listening
        to the same events
  dino: That's basically the two proposals. Happy for any suggestions
        or comments

  florian: What we started with seemed nice and simple
  florian: but seems like maybe they're overly simplified, and as you
           get into more complicated situations we keep having to add
           more and more tricks
  dino: It's very specific to our design, but we want to have
        something that works for others as well.

  [florian draws a dashboard display and asks about how far are we
      going to go]
  dino: safe-area-* is about hardware shapes. fullscreen-inset is
        about on-screen displays
  florian: ...
  myles: System with arbitrary shapes would be so difficult to use
         that no developer would do it

  Rossen: Similar to this, we had a value called device-fixed
  Rossen: Worked exactly you describe,
  Rossen: When onscreen keyboard came in, didn't want to resize the
          entire window
  Rossen: But if you wanted to attach UI on top of the keyboard, e.g.
  Rossen: Instead of position: fixed
  Rossen: You'd do position: device-fixed
  Rossen: And it would adjust
  Rossen: You won't have to resynch or compute any numeric values like
          top/bottom etc.
  dino: You wouldn't be able to animate
  Rossen: That would be done for you
  Rossen: Basically saying that the device now is going up
  Rossen: on-screen keyboard is coming up
  Rossen: If this UI was important for YouTube, they'd simply position
          this as device-fixed
  Rossen: And then this simply becomes bottom: 0;
  Rossen: And they don't need to do anything else
  Rossen: They don't even know, it's still the same thing
  florian: If you are sizing things, would that affect viewport units?
  Rossen: This is overkill
  Rossen: Another example put forward was if you have, suppose some
          vertical sidebar
  Rossen: Same thing, a bit more work for us, but if you have
          positioned top and bottom it would respond
  Rossen: From what I know, it was very successful because very simple
  Rossen: position: fixed vs position: device-fixed
  fantasai: Why isn't position:fixed have the behavior of device-fixed?
  Rossen: We weren't actually resizing the viewport, it was an overlay
          UI
  Rossen: e.g. keyboard uses semi-translucent colors
  fantasai: But what if you want to clearly see the content at the
            bottom of the page?
  Rossen: Just dismiss the keyboard
  fantasai: What if you need to type into a form field at the bottom
            of the page?
  frremy: Then you can dock your keyboard.
  dino: Do you still support device-fixed?
  Rossen: Yes
  Rossen: We were doing this for action center, which is something
          that swipes from the right
  Rossen: If you have some UI that's really important to your app
  Rossen: you can attach it
  myles: Does it work if the window is not full screen?
  Rossen: No, this is only for full-screen

  iank: What is the box?
  dino: In our case the device-fixed box would be what remains after
        the inset here.
  iank: But it wouldn't solve this use case?
  dino: It would, but it wouldn't solve use case of wanting to fade
        all controls at once
  iank: What about tile shifting to the right?
  dino: We're reserving the right to put more things up there
  dino: Would be up to browser to animate the the device-fixed box.
  myles: Animation is different
  myles: We want the animation to fade out
  myles: whereas you want it to slide out
  Rossen: You can fade out the keyboard or slide it?
  myles: How does the page know to fade out or side out things?
  dino: Say youtube uses a 3s fade, and we use a 4s fade.
  dino: Want to tell youtube to use 4s if it wants to be in sync
  fantasai: In Apple's case, could just use the transition time value
            in the 'transition' property
  Rossen: Reason we wanted it done in browser was because syncing
          timers was not working
  astearns: Weirdly shaped things will need to use a lot of
            environment variables
  dino: OK, we'll take back this feedback

  fantasai: Also, you might want to consider s/fullscreen/overlay in
            the names... it's not really about the fullscreening

  Rossen: If we are looking to solve the tying of author-defined
          controls with UA controls animation
  Rossen: You can have a start and an end event
  Rossen: Just also need to know how long between the two
  myles: Could be part of the start event
  astearns: Maybe you only need one set of environment variables

Received on Tuesday, 24 July 2018 23:09:44 UTC