[CSSWG] Minutes A Coruña F2F 2020-01-22 Part I: CSS Values & Units [css-values]

  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 Values and Units

  - RESOLVED: Adopt a round() function with keywords determining which
              behavior (Issue #2513: Values and units round()/
  - RESOLVED: Add the mod() function with an open issue about negative
              (Issue #2513)
  - RESOLVED: Add the sign() function as described in the issue,
              restricted to numbers only (Issue #4673: Add sign() math
  - RESOLVED: Add abs(), log(), exp(), and the two keyword constants e
              and pi (Issue #4688: The rest of the JS Math functions)
  - RESOLVED: Add infinity and NaN as new css math constants
              [calc(infinity), calc(-infinity), and calc(nan)] (Issue
  - RESOLVED: Math precision in CSS is currently kept undefined (Issue
              #4551: Double precision math in calc())
  - RESOLVED: Add a set of viewport units (name TBD) that reflect
              the size of the layout viewport less all UA UI (Issue
              #4329: Add vhc value)
  - There was not consensus on if there was a need to provide an event
      or env() to animate between the new viewport units or if it was
      unnecessary because current functionality is sufficient. More
      examples will be gathered in order to analyze use cases.


Agenda: https://wiki.csswg.org/planning/galicia-2020

  Rachel Andrew, Fronteers
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  L. David Baron, Mozilla
  Amelia Bellamy-Royds, Invited Expert
  Christian Biesinger, Google
  Mike Bremford, BFO
  Oriol Brufau, Igalia
  Emilio Cobos, Mozilla
  Elika Etemad, Invited Expert
  Javier Fernandez, Igalia
  Koji Ishii, Google
  Brian Kardell, Igalia and OpenJSF
  Jonathan Kew, Mozilla
  Ian Kilpatrick, Google
  Chris Lilley, W3C
  Stanton Marcum, Amazon
  Myles Maxfield, Apple
  Cameron McCormack, Mozilla
  Tess O'Connor, Apple
  Manuel Rego, Igalia
  François REMY, Invited Expert
  Florian Rivoal, Invited Expert
  Hiroshi Sakakibara, BPS
  Jen Simmons, Mozilla
  Alan Stearns, Adobe
  Lea Verou, Invited Expert

Scribe: bkardell

CSS Values and Units

Values and units round()/floor()/ceil()/mod()
  github: https://github.com/w3c/csswg-drafts/issues/2513

  TabAtkins: As we knew would probably happen, as we started
             suggesting math functions, people wanted more math
  TabAtkins: Problems in the past the prevented these, we have solved
             those - so this issue is specifically about adding round
             and mod functions - they are all similar under the hood
  TabAtkins: the big question for me is whether we want to add these
             as 4 function names or 1 with a mode?
  chris: Which will people be most familiar with
  TabAtkins: Another concern is spelling, for me ceil or ciel is
             confusing to me - I suspect I am not the only one... my
             suggestion is we go with round function
  TabAtkins: Any ideas, comments suggestions?

  TabAtkins: round(keyword?, calc, calc) -- the second being precision
             you want
  leaverou: Is there any precedent of having a single function like
            this in any language?
  TabAtkins: We have several functions with optional keywords in css
  leaverou: Fair enough

  fremy: When does round function happen?
  TabAtkins: Same time as all of the math functions

  jensimmons: It seems like we asked this on twitter and we are now
              seeming to go against their express intent in this,
              admittedly non-scientific poll
  fantasai: People who come from a math/programming background get
            'floor' and 'ceiling' but as someone coming new to
            programming you won't know that
  myles: It's a math term
  fantasai: I didn't learn it, I don't think a lot of us did. Also for
            discover-ability of people who are not already familiar
            with these terms round() is a better model, because all
            four functions that do almost the same thing with slight
            variations are under the same feature. With the 4 separate
            functions, you have to know that they exist, and it's
            harder to find them unless you already know their names
  leaverou: Don't forget that there is limited value in asking people
            because they will always trend toward whatever they
            already know
  rachelandrew: People will trend toward the simplest things

  dbaron: Is this proposal written in the issue? I didn't find it in
          these comments?
  fremy: One of them was from AmeliaBR, I think
  <dbaron> and I think the comment pointed to was

  <chris> round-up | round-down | round-truncate
  * cbiesinger was also going to suggest round-up
  Rossen: Could bake the keywords into the function name, like
          round-up(), round-down(), etc.
  fantasai: There's no typing benefit to doing that, should just
            follow the CSS pattern we have in gradients, cross-fade(),
            etc. to put the keyword in the parens
  jensimmons: It makes sense to me what fantasai said, that it is
              basically one function / one feature — with several
              different ways to do it.
  Rossen: It sounds like we all are agreeing that one function with an
          optional keyword...
  florian: I was just looking and Ruby has this pattern actually, the
           one we're suggesting
  <florian> https://ruby-doc.org/core-2.5.3/Float.html#method-i-round
  <dbaron> you can get to 8 functions with up|down|towards-zero|
  Rossen: Prior art, agreement in the room, any objections
  Rossen: ok resolved

  RESOLVED: Adopt a round function with keywords detailing which

  TabAtkins: mod() same deal - it's similar to mod() anywhere else,
             but I suggest we don't match javascript here
  myles: There is value in matching js here
  <dbaron> Tab is suggesting that the sign of the result should match
           the sign of the second argument, not the first
  TabAtkins: from what I can tell, most of the time people want the
             sign of the modulus, not the sign of the first argument
  myles: I don't have a strong opinion, I think there is a strong case
         to match JavaScript though
  TabAtkins: I feel mathematical mod is more sensible, how you
             probably learned in school - not as done in js as adopted
             from Java as adopted from C
  jensimmons: I think matching JavaScript is valuable
  <astearns> +1 to jensimmons
  Rossen: Breaking the relationship to JavaScript seem to be a bad
          default - people use JavaScript to create CSS

  fantasai: What are the use cases for modding negative numbers?
  dbaron: If I am imagining some step pattern or some kind of thing
          you would create here - it does seem like what TabAtkins is
          saying is going to be more natural
  <fantasai> +1

  TabAtkins: There seems to be good argument both ways; and you can
             use mod + add + mod calc pattern to switch behaviors if
  fantasai: I would lean toward dbaron argument
  fantasai: People who use JS are going to be more comfortable mucking
            about with mod functions to get the behavior they want
  fantasai: but this way the people who are just trying to get their
            CSS to work don't have to try so hard
  <dbaron> I was arguing that if you're using mod() to generate step
           patterns or something like that, if we use the JS mod(),
           you'll have to be careful to avoid inputting negative
           numbers (or, as Tab said, using multiple-mod() workarounds
           for that).
  bkardell: Lots of preprocessors have functions like this -- which do
            they have, does it matter?
  TabAtkins: They don't seem to have an example in sass

  TabAtkins: Just looking at the wikipedia page, you can see this
             problem demonstrated
  TabAtkins: It's very easy to just accidentally go negative and then
             you will have broken code, whereas the way I am
             suggesting here you have to be more intentional about it
  TabAtkins: Good argument in general that matching js is good - but
             we have also agreed that it is maybe less intuitive
  TabAtkins: What do we want to do?

  Rossen: Straw poll for the initial thing, we can always change our
  Rossen: 1) align with js 2) align with 'math'
  <leaverou2> 2
  <fremy> 2
  <TabAtkins> 2
  <heycam> 1
  <bkardell> 1
  <jfkthame> 1
  <iank> 1
  <Rossen> 1
  <stantonm> 1
  <rachelandrew> 1
  <emilio> 1
  <florian> 2
  <astearns> 1
  <cbiesinger> 2
  <jensimmons> on behalf of dbaron — 2
  myles: 1
  tess: 1
  [various people have lost connectivity; Tab runs an offline poll]
  TabAtkins: 11 to 10, I think we have to leave this as an open issue
  <jensimmons> the vote in the room was 12 for Option 1 (align with
               JS) and 11 for Option 2 (align with math)
  <fantasai> It was 11 against 11 of the people in the room; myles
             claimed to vote for Tess, but she wasn't here for the
             oral arguments :p

  Rossen: Any objections to adding the mod() function with an open
          issue about....what it actually does?

  RESOLVED: Add the mod() function with an open issue about behavior

Add sign() math function
  github: https://github.com/w3c/csswg-drafts/issues/4673

  TabAtkins: This one was opened by oriol, asking for Math.sign
             equivalent. The usecase presented is hacky, but sure, why
             not - it seems unobjectionable - I'm happy to add it...
             he notes you can actually implement it yourself, it is
             even worse
  myles: Should the sign of 1px be....
  heycam: It should return a number if we allow lengths
  emilio: What about percentages?
  TabAtkins: 50% should resolve to whatever that resolves to
  bkardell: In...pixels
  TabAtkins: In many cases, pixels, but whatever that resolves against
  <heycam> make calc(sign(1px)) == 1, because you usually use the
           result of sign() to multiply against other things
  myles: You could always add non-numbers later

  heycam: Does css really support positive and negative zeros?
  TabAtkins: In calc, yes - we use the js semantics -- once you exit
             the calc no... it can affect the infinity
  TabAtkins: Yes, but only inside of calc()
  fantasai: I don't think you can parse negative zero in
  dbaron: You can write a negative 0, but it is just 0
  TabAtkins: If you produce a negative 0 as a result of the calc, you
             can have a negative 0
  Rossen: Is there a use case for that?
  TabAtkins: Consistency with JavaScript?
  Rossen: So we _want_ that in this case? :)
  TabAtkins: You can insert directly via typed om, actually
  <cbiesinger> since I don't think i was scribed -- Tab explained you
               get negative zero by dividing by negative infinity,
               which you get by -1/0
  <astearns> cbiesinger: Tab explained you get negative zero by
             dividing by negative infinity, which you get by -1/0

  TabAtkins: Anyone have an objection to sign() restricted to numbers
  Rossen: Any objections?

  RESOLVED: Add the sign() function as described in the issue,
            restricted to numbers only

The rest of the JS Math functions
  github: https://github.com/w3c/csswg-drafts/issues/4688

  TabAtkins: I went through all of the Math functions and reviewed for
  TabAtkins: in the issue I listed out the functions and constants - I
             just dumped the object in chrome, I assume everyone has
             the same thing...
  TabAtkins: I separated them into categories
  TabAtkins: A handful of algebra stuff - absolute value, cube root
  TabAtkins: You can do these yourself if you know how, but it's fine
             with me to just go ahead and match for parity/consistency
  TabAtkins: Low value, but reasonable

  heycam: If we have this goal of 'if it is on the math object and
          there is no reason to not include it here'... it seems even
          more odd to me that round would deviate from this
  TabAtkins: Exact correspondence is not my goal, we already can't
             match exactly because we have to include precision
  fantasai: If we aren't going for exact correspondence, we should
            maybe not add cube root right now; if there's demand for
            it later, we can add it later
  <dbaron> +1 for adding 'abs' and not adding 'cbrt'
  <florian> +1
  fantasai: I do think we should add abs() because people are unlikely
            to understand there is another way to do that, it's not as

  dbaron: I think there is a small chance that it applies here, one
          reason some of the weird functions exist in JS might be
          because they can be made faster than the non-weird version
  TabAtkins: Is that an argument for doing it or not ?
  dbaron: It might be an argument for someone to look into it
  fantasai: You could optimize it anyway
  dbaron: It would be harder

  [oriol demonstrates math the scribe couldn't understand]
  <dbaron> Oriol was pointing out that cbrt(-8) is -2 whereas pow(-8,
           1/3) is NaN
  <dbaron> And, particularly, fractions 1/N where N is odd are not
           representable exactly unless N is 1 or -1.

  TabAtkins: Next up - hyperbolic trig functions... I don't know use
             cases here in CSS?
  TabAtkins: Can skip this entire category unless someone needs to
  fremy: If you have the exponent function you should be good

  TabAtkins: Next - the family of e related functions -- log(), log 2,
             log 10 in JavaScript it was like this - I suggest we just
             pass in instead of 2, 10
  <dbaron> TabAtkins: log() is 2 argument with base defaulting to e
  TabAtkins: Suggesting we just add log() and possibly exp()?
  fantasai: I think I agree with your basic take, I think we just
            discuss log() now and exp later

  TabAtkins: Next is rounding, we already discussed
  <dbaron> Ah, Mercator projection drawing math uses asinh().

  TabAtkins: The last thing is constants...
  TabAtkins: I can see you wanting to use some of these - Pi, E ..
  TabAtkins: Should we add these as single argument functions? It
             seems like there's a challenge with globally reserved
  <dbaron> TabAtkins: Would break animation-names of e and pi
  heycam: Can you not make it global, just in calc?
  TabAtkins: ... maybe, probably
  <fantasai> +1 to heycam's suggestion
  Rossen: Do we need them for now?
  <chris> maybe make them ε and π (the greek letters) to avoid
  TabAtkins: No non-ascii things please
  florian: Keeping the parser non-breaking seems useful
  <astearns> env(pi) so that it can vary for UAs running in other
  fantasai: We have an intent to add keywords to calc() someday anyway
            -- as long as it is not a great complication to the parser
            it seems like a usability win
  <dbaron> could we add them in a function like const(pi)?
  <florian> env(pi)
  * heycam add e and pi as new units. 2pi, 1e, ...
  TabAtkins: Actually, the units thing is not a terrible idea
  dbaron: One thing that is painful about e is its interaction with
          exponential notation
  dbaron: We already support things like 1e1
  dbaron: I saw a suggestion - what if we stuck these inside of some
          other function?
  TabAtkins: We want this to be short is the counter argument I guess,
             but const is not bad
  <dbaron> 1e1e is pretty ugly (in terms of having pi and e be units)
  myles: It could be math.e to match javascript
  fantasai: That would change the parser

  TabAtkins: Which of these 3 options do we like?
  <TabAtkins> 1. "e" and "pi" allowed in calc() as keywords
  <TabAtkins> 2. e() and pi() available everywhere
  <TabAtkins> 3. const(e) and const(pi) available everywhere
  <leaverou> const(e) might be more clear than e for people reading
             others' code
  <jensimmons> grid-template-layout: 100px 1fr 2pi;
  <jensimmons> `grid-template-layout: 100px 1fr calc(2pi);`
  <jensimmons> `grid-template-layout: 100px 1fr const(pi);`
  <jensimmons> `grid-template-layout: 100px 1fr pi();`
  <jensimmons> `grid-template-layout: 100px 1fr calc(2*pi);`
  <fremy> 2
  <fantasai> 1
  <florian> 1
  <leaverou> 3
  <faceless> 2
  <astearns> 1 or 3
  <iank> not 3
  <chris> 3
  <fantasai> Note that 1 allows calc(e) everywhere
  <dbaron> could also be math(pi) rather than const(pi)
  <fantasai> dbaron, let's take that as a variant of 3
  <chris> 3 > 2 > 1
  <emilio> 1

  <Rossen> option 1: 13 votes
  <Rossen> option 2: 3
  <Rossen> option 3: 5 votes
  <jensimmons> oh I wanted to vote for 2
  <jensimmons> option 2: 2

  TabAtkins: We will take the strawpoll as evidence for now and use
             option 1
  Chris: This'll let us close the long-running issue that 'rad' is
         useless without pi?
  TabAtkins: Yes
  * fantasai notes existence of turn unit

  TabAtkins: Final bits "stuff we probably don't want"... random ...
             seems impossible
  TabAtkins: clz32 -- it's... complicated
  myles: It's used in video codecs
  TabAtkins: Which you probably shouldn't be doing in css
  tess: I love the idea of someone trying tho

  TabAtkins: Last one is imul()
  chris: What is that for even
  TabAtkins: We don't want it

  TabAtkins: pow with an e argument - I don't know if there is
             something here with speed
  fantasai: The pow function takes two args -- what if you give one?
  TabAtkins: It would be invalid
  fantasai: Maybe we should make it consistent with log by making it
            default to e?
  <chris> make second argument to pow optional, defaulting to 1
  <iank> The other way to make it consistent is to not have the
         default arg for, log(), and add ln()
  <iank> log(val, base), ln(val), pow(val, pow), exp(val)
  <TabAtkins> Notes that exp(x) == pow(e, x)
  TabAtkins: That isn't quite true to to precision (which CSS doesn't
             care about)
  TabAtkins: but it's almost true!
  <chris> pow(foo) == pow(foo, 1) == foo
  <jfkthame> calculators I have known typically have a dedicated e^x
             key (=exp), although they also have x^y (=pow)
  dbaron: So is anyone going to be annoyed by log in css being math
          log and not console log
  fantasai: Do you have a different suggestion dbaron ?
  dbaron: ln?
  fantasai: For log of base 10?

  Rossen: Any more comments or objections on adding these 5:
                 abs, log, exp, and the two keyword constants e and pi

  RESOLVED: Add these 5 - abs, log, exp, and the two keyword constants
            e and pi

Irrational Numbers Continued
  Scribe: fremy

  TabAtkins: Now that we have a precedent for "e" and "pi"
  TabAtkins: heycam mentioned it could be useful to add "infinity"
  TabAtkins: It's not useful per se, but it would allow us to
             serialize infinite values coming from TypedOM
  TabAtkins: instead of 1/0
  TabAtkins: Anyone has opinions on this?
  <dbaron> Tab also mentions 1px/0 and the newer option infinity*1px
  oriol: Could we add "NaN" too?
  TabAtkins: Do we need NaN to serialize to infinity
  oriol: We currently we would need to serialize as 0/0 which is
  TabAtkins: I don't think we have to serialize these values at will,
             only when we have that as the result of a computation
  TabAtkins: and we already say that NaN as a result of a computation
             is an infinity
  <jensimmons> `grid-template-column: 1fr 1fr calc(infinity);` ??????
  <jensimmons> `margin-left: calc(-1*infinity);` ???????

  heycam: Nothing to add, but yeah I find the current serialization
          annoying, and since we have this concept of values now, I'd
          like to use it
  TabAtkins: Just realized TypedOM allows injecting NaN anywhere, so
             we might actually need to serialize NaN anywhere
  TabAtkins: I'm then in favor of adding NaN as a keyword
  TabAtkins: (if we add any of them)
  <oriol> Issue #3768, we resolved "Use calc(1/0) and calc(0/0)"

  <leaverou> transitions to infinity would be ...interesting
  TabAtkins: To answer to leaverou, we can already do that, we just
             would need to write as a calc() right now

  dbaron: Serialization would be lower case?
  TabAtkins: Yeah, CSS would serialize lowercase by default
  TabAtkins: but we could do either way, no strong opinion
  <chris> z-index: -infinity

  jensimmons: What capabilities are we adding by allowing these
  TabAtkins: None, you can already get those results today by doing
  TabAtkins: (we clamp to the maximum value if we need to)
  <jensimmons> `margin-left: calc(-1*(1/0));` works today??
  <TabAtkins> Yes it does
  <astearns> it's defined, in any case

  TabAtkins: So, what's the room's feelings about this?
  chris: There are also people who want rational numbers, so
         outputting 1/0 as a returned value would give a bad precedent
  chris: Negative infinity would have to require a space, correct?
  TabAtkins: Yes, we would need to be careful, like usual for math in
  TabAtkins: since nobody objected, let's resolve to add them

  RESOLVED: Add infinity and NaN as new css math constants
            [calc(infinity), calc(-infinity), and calc(nan)]

  myles: Does - have to be followed by a digit in order to be
         classified as a negation? can we actually do -infinity
         without a parser change?
  <myles> calc(negative-infinity)
  <tantek> -infinity-infinity
  <tantek> == 0?
  <jensimmons> calc(-1*infinity)
  TabAtkins: idents can start with dash
  dbaron: but usually it's for vendor prefixes
  TabAtkins: No, vendor prefixes have two dashes, -prefix-
  Rossen: Let's move on

Double precision math in calc()
  github: https://github.com/w3c/csswg-drafts/issues/4551

  <TabAtkins> https://twitter.com/starsandrobots/status/1199757377286754309
  TabAtkins: Somebody mentioned that you can use int precision in
             Blink to implement mod()
  TabAtkins: This is ridiculous, and I think it shouldn't work
  dbaron: What is the consistency difference?
  emilio: Firefox uses floats for everything, but Blink and Webkit use
          doubles only when parsing and simplifying, but inside the
          math expression in use-value-time, it's float
  TabAtkins: In general, I agree that precision should be kept
             undefined if we can
  TabAtkins: but TypedOM will allow input any double, so I guess we
             already have that requirement
  emilio: Not really, right now we store as float inside the cssom,
          typedOM is truncated
  myles: Also, we could also be able to used fixedpoint
  TabAtkins: But not inside a calc() right?
  myles: Not right now, but I would like to keep the option
  myles: Also, order of operations would need to be specified for the
         double-precision to make sense as a requirement
  myles: and I'd like not to have to do this

  TabAtkins: Based on the consensus in the room, it seems we want to
             reject this proposal
  dbaron: Note that we had compat issues in serialization as dbl vs
  dbaron: Specified values would be in float, but computed values were
          doubles, and that caused issues
  dbaron: maybe these compat issues are not relevant in the current
          discussion, but it's interesting to note that if we do, we
          have 7 random digits at the end
  chris: We also will have similar issues with colors
  <chris> because color() lab() lch() all use float
  TabAtkins: We could specify that we also serialize in float space
  TabAtkins: but myles also wanted to keep fixedpoint, so maybe not
  TabAtkins: but it's a tangent
  <dbaron> (as I was talking through it I think I realized the issues
           I was remembering were about the problem that once you
           truncate something from double to float, you should never
           use double-based serialization code to serialize it because
           you'll then get 6 digits or so tacked on to the end)

  TabAtkins: Is there any objection to keep precision undefined for
  Rossen: Any objection?
  (no objection)

  RESOLVED: Math precision in CSS is currently kept undefined

  iank: (Chrome could also investigate changing the parser to use
        floats, but it's not high in our priority list)
  iank: (right now, it depends on the class where we store it,
        sometimes a float, sometimes a double)

Viewport Units vs. Disappearing Browser Chrome

  jensimmons: We have discussed this before
  jensimmons: We are trying to solve the issue on mobile where the
              viewport changes when you start scrolling
  jensimmons: (as the bottom bar retracts)
  jensimmons: You can work around this in javascript, but it's not
              possible to do in css
  jensimmons: Proposal also includes taking into account the
              appearance of the keyboard
  florian: I think the top bar sometimes disappear as well in some OSes
  jensimmons: Ah, good point
  jensimmons: and those things can keep changing
  jensimmons: (also, similar to the issue with vw and scrollbars)
  jensimmons: (maybe it's a different issue, but it's still good to
              keep it in mind)

  jensimmons: I am afraid redefining vh/vw might be too late by now,
              because authors have corrections
  jensimmons: Sometimes we don't want things to resize as the viewport
              changes, too; we want everything to fit at start and
              that's it
  jensimmons: so we should provide all the units to authors, and it's
              on them to take a look
  jensimmons: at performance
  <heycam> jensimmons++ for putting together a great visual intro to
           the issue

  florian: So, we would have a unit that would represent the initial
           containing block?
  jensimmons: Yes, this new unit would be static, and not change when
              the chrome changes
  jensimmons: VHC would be the same but with the chrome maximized
  jensimmons: but we could also use an environment variable
  [proposal summarized:

  dbaron: I just wanted to ask, do we want to talk about keyboards
          when we talk about maximized chrome?
  jensimmons: I don't think so, it would only include the normal chrome
  jensimmons: but an environment variable might be better to handle
              the keyboard case
  TabAtkins: Most of the times, you don't want your footer to reduce
             space when the keyboard appears
  TabAtkins: because content space is already tiny
  jensimmons: But some things might want to snap etc...
  <astearns> my team's use case DOES want to get the reduced space. We
             want to position the input the keyboard is operating on
             to be right above the keyboard
  iank: For example, adding an additional keyboard row
  dbaron: But switching keyboard (between English and Chinese) would
          change the height of keyboards sometimes
  iank: And some form input types can cause the number bar to appear
        or not above the letters

  florian: I am confused at the idea that the animation concept would
  florian: how do you switch between the values on scroll?
  fantasai: Yeah, I don't think that work in practice, because the
            units are not meant to change the value of the units as
            you scroll up and down
  fantasai: because some units are used to compute font size etc and
            relayout during scroll sounds not great for users, and
            also not great for performance/not great for users, or for
            performance, so units need to be static
  fantasai: Environment variables are better for dynamic case because
            it makes it more clear it's gonna change dynamically
  fantasai: but the units are useful for the static initial position
  florian: I think that answers my question
  florian: but if we have both, I don't think we need the other
           viewport units

  <astearns> for the minutes, there have been multiple call-outs
             thanking @frehner for the very clear issue opening and

  myles: I think I might repeat a bit but I do agree the two units
         don't work
  myles: so we add the dynamic thing
  myles: but then why do we need the second unit we currently don't
  fantasai: The reason I think we should have two units, is that the
            env() variables will be dynamic, but the other ones would
            not, and allow ...
  fantasai: to use the concept of minimalized and maximalized chrome
            in layouts
  florian: An article for the top banner which try to cover the screen
           as you open the site
  florian: but you don't want that banner to resize when you scroll or
           open a keyboard
  florian: and you can't solve that with the env() and the one unit
  fantasai: Within an article, you can have graphs or images which you
            want to size in function of the viewport, but you don't
            want their size to change as you scroll

  TabAtkins: I strongly agree that we can use both
  TabAtkins: I would have objected to only add the static ones, but if
             we have both I am fine

  fantasai: We don't have a high demand for the keyboard one in general
  fantasai: and we can't know in advance the size of the keyboard
  fantasai: so I think that use case should only be covered by a
            dynamic env() unit

  jfkthame: Should we think about privacy effects of exposing the size
            of the keyboard
  jfkthame: (because the height of the keyboard might reveal what
            language the user speaks)
  fremy: We already have that info exposed via JS
  myles: We can already solve all of this with javascript
  myles: with an event that say "the chrome is stable now, do your
         computations now"
  myles: Also I would like to note that this will have implications
         for the webkit framework as multiple browsers have to expose
         this to us
  myles: (which is unfortunate)

  bkardell: I'm not entirely clear on what the static thing brings,
            can someone resummarize?
  TabAtkins: vh is the full height, never reduce
  TabAtkins: vhc would be the same, but without the bars
  bkardell: The vh unit does change
  jensimmons: Only if the window is resized, but not as you scroll
  bkardell: but, you agree they are not purely static, right?
  jensimmons: Yes, but what we mean by static, is that it's static as
              you scroll
  jensimmons: It changes when we need to relayout everything
  jensimmons: but it doesn't change otherwise
  myles: Comment about vhc not being useful for one example jensimmons
         showed on the powerpoint
  jensimmons: Good question; both use cases could be fine for designers
  jensimmons: but at least on desktop vh and vhc it seems the units
              would always match

  <jensimmons> example:
  <fantasai> jensimmons shows an example of a page with a large photo
             taking up the viewport on load, below it is the rest of
             the article
  <fantasai> The goal is to see the entire photo, and just below the
             fold the article
  <fantasai> scrolling should not change the size of anything on the
             page, just scroll
  <fantasai> If the smaller measurement was used, part of the article
             would show above the fold when the bottom bar is retracted
  <fantasai> This might not be wanted
  <fantasai> but on the other hand, if important info was aligned to
             the bottom, the author might want to make sure it's
             always visible
  <fantasai> so using the larger measurement (for retracted bars)
             would be a problem in that case, and the smaller one

  Rossen: Let's timebox this for another ten minutes
  florian: I think there is another layer of complexity in this story
  florian: at least in the keyboard case
  florian: What if the keyboard is semi-transparent above the content
  Rossen: Actually one of the things I wanted to mention
  Rossen: we had a similar issue with Windows (8?)
  Rossen: the keyboard would not change the appwindow size on
          the platform
  Rossen: Sometimes the keyboard was not even transparent, it
          occluded the app
  Rossen: but we needed to animate the bottom bar of the app to
          stay above the keyboard
  Rossen: and we had a special "position" value to achieve that
  Rossen: but I don't know if having the units would work,
          because it would be out of sync
  florian: But we can have the value matches the keyboard all the time
  florian: but maybe there are good use cases for both, I'm not sure

  jensimmons: I don't think we want to debate this issue too much
  jensimmons: I guess there are use cases for all
  florian: Thinking that there are two variants of the right case, one
           where the keyboard is on top, the other when it's reduced
  jensimmons: I understand but what a viewport means from the
              implementer is their question
  jensimmons: but for the point of view of the author, it's about to
              design an experience, and the question authors have in
              mind is not this detail
  florian: But if you want to coordinate static positions, it's
           difficult because things would get out of sync

  dbaron: A good point TabAtkins outlined before is: are there
          actually use cases to size things based on the space that
          would be left after the keyboard is added
  dbaron: but when the keyboard is not there
  dbaron: and I suspect that this might be right, we don't need to
          worry about hypotheticals about the keyboard
  dbaron: as long as you can react as the keyboard opens
  <fantasai> +1 to dbaron
  emilio: Fixed position elements used to respond to the keyboard
  emilio: and that had complications very soon
  emilio: Do we want env() units to have the same issues?
  Rossen: Do you mean visual vs .... viewport?
  TabAtkins: I suppose we want visual
  <TabAtkins> Specifically, I think we want this height to match the
              height of a fixpos with top:0; bottom:0;

  myles: One note is that I'd want to warn against trying to chase how
         browser chrome works today, because that might change in the
  myles: When we tried to ship to disappearing bars, we realized there
         are some problems, and we might want to fix them at some point
  myles: I'm not sure we want to have a specific value for each of the
         iterations the browser community ended up with along the way

  jensimmons: fantasai said we might want two env() variables, what
              are they?
  fantasai: static viewport units: the bigger and the smaller;
            dynamic environment vars: one that's the current viewport
            size (between the two viewport unit ranges), and the other
            is what is actually visible with consideration of space
            the keyboard has taken away
  fantasai: I think the keyboard case seems less urgent to solve
  fantasai: so if we aren't sure what to do in this case, it's ok to
            not tackle that use case, but just keep it in mind to
            choose the right framework for future extension

  emilio: Replying to Tab about the visual viewport thing
  emilio: Part of the reason we don't update them is performance
  emilio: and this would kill that performance optimization
  emilio: If you want the visual viewport behavior (fixedpos-0-0) you
          also need a width unit
  emilio: (because when you zoom you change that as well)

  jensimmons: It seems to me that we are talking about a vh unit
              that's a fixed unit based on the maximized space
  jensimmons: vhc would be the minimize space, but similarly static
  jensimmons: and the dynamic variable would be whatever it is right
              now, and yes that would would change 60fps possibly
  jensimmons: We will educate
  jensimmons: but maybe we can make a vhk unit to care about the
              keyboard later
  jensimmons: "question mark, question mark, question mark" (just
              thinking out loud)
  jensimmons: and then there might be another set which is, give me
              the space available
  jensimmons: even if it's behind a keyboard (or not)

  hober: To reply to fantasai list of things, the values is orthogonal
  hober: but for the use case to know about the keyboard, one of the
         use case it to add things above the keyboard
  hober: and that usecase should probably be addressed in html and
         javascript, maybe not css
  hober: For example, we thought about some way to add custom buttons
         for the touch bar in html/js
  hober: and it seems a more natural fit than trying to emulate this
         with positioning with css
  hober: so, is there another use case?
  astearns: When the textbox is focused, move it right above the
  fantasai: You can do that with scroll-snap already (per spec)
  fantasai: because it will snap to the viewport
  jensimmons: So, are you arguing it wouldn't be required to do this
              math with env variables

  fantasai: My proposal is the two static sizes (minimized/maximized
            chrome) as viewport units and the dynamic one where you
            report the current size as an environment variable
  fantasai: vh should probably be the maximized chrome (smaller
  fantasai: because if people are designing on desktop, they might not
            realized that it could end up beyond the fold on mobile as
            you scroll
  fantasai: It's not as pretty if you truly wanted to fit, but safer
  TabAtkins: That's a change of behavior
  fantasai: Chrome folks said they would have loved to change, but
            webkit did the other way around
  TabAtkins: That was a long time ago, I don't think we could switch
             without compat
  fantasai: More breaking than we would fix?
  hober: Yes

  jensimmons: I would like to come to a resolution with the three we
              seem to agree on, and leave the fourth one for later
  hober: I'd be happy to reject the fourth one and reopen later
  jensimmons: Actually the issue doesn't cover the fourth one anyway,
              so resolution not even needed
  Rossen: So, are we reaching a consensus on the two static +  one
          dynamic value?
  jensimmons: I think so

  fantasai: Also, we would also need to add the symmetric values for
            vhi and vhb
  hober: I think the issue is that it would be a lot of similar units
  hober: I'd rather something longer that's more clear
  fantasai: Yeah but that's unfair because vh is short, then if you
            want to write good code you need to write more
  hober: ...
  fantasai: We already have a vmin unit
  jensimmons: Can we resolve on the concepts but not the name?
  myles: Rossen said that the symmetrical values would be needed, but
         in practice we wouldn't have different values in any browser

  fantasai: The viewport units are vh, vw, vmin, vmax, vi, vb
  fantasai: all of these, except vw, can potentially map to vh
  fantasai: At that point, seems a bit odd to leave it out of the set
  dbaron: I am not convinced that vmin and vmax need this new feature
  <hober> v{h,w,i,b,min,max}{,c} is a very large set of units
  fantasai: why would you exclude them?
  Rossen: In tablet mode on windows, there are different chrome
          you can trigger when you swipe etc...
  Rossen: things like notification bars and whatnot
  Rossen: In tablet mode, all of the windows are always maximized
  Rossen: and the bars can appear on top of the content
  Rossen: (but these bars have fixed size value known in advance)
  Rossen: so for us, vw equivalent sounds useful
  <fantasai> I think authors should be able to use these
             "safely-sized" viewport units with the same level of
             usability as the "unsafely-sized" viewport units

  emilio: If we don't want things that are sized with them to be
          affected by zoom
  fantasai: The vh and the new unit and the initial containing block
            should all behave the same way wrt zoom
  fantasai: as long as the browser affect the all three the same way,
            they can do whatever they want

  Rossen: Are we ready to make a resolution?
  Rossen: Can we resolve on the keyboard thing?
  jensimmons: Not necessary
  Rossen: Is there consensus on vhc? (besides the name)
  fantasai: Plus the variants
  Rossen: Plus the variants (vi/vb/...)
  Rossen: Any objection to this set of units?
  dbaron: Not counting scrollbars?
  emilio: Not counting scrollbars
  Rossen: Let's kick that can down the road, we can rediscuss later
  Rossen: but I'm not hearing any objection
  Rossen: So let's resolve

  RESOLVED: Add a set of viewport units (vhc for ex.) that reflect the
            size of the layout viewport less all UA UI

  Rossen: The second question, do we need to provide the events / env
          variable that allows to transition between them
  fantasai: I think the consensus was to have the dynamic full size
            as an env variable
  florian: We can also consider giving differences between the dynamic
           and full one
  jensimmons: That's simpler to just say that env() variable is
              exactly like vh but it doesn't stay static
  jensimmons: and the number is a live measurement of the space,
              instead of a difference
  florian: I don't disagree but I am unsure it answers my question,
           but ok let's move on
  jensimmons: Example of a use case where there is a footer on the
              side that needs to stay stuck on the bottom of the
              viewport, even as the user scrolls
  jensimmons: (done in javascript right now)
  jensimmons: and I think that use case is important

  <dbaron> In hindsight, I think we'd have been better off if we'd
           called vmin vsmaller, and if we'd called vmax vlarger, or
           something like that.
  <hober> dbaron: yeah

  hober: It's a bummer that we'd have to do relayout during scroll
  myles: There is an alternative that doesn't do that as long as there
         is an alternative that doesn't do layout on scroll, and this
         is named appropriately, and it is an opt-in mechanism, it's
  jensimmons: vh doesn't already change for performance
  jensimmons: and that the new env() variable would only be used in
              cases where it's needed
  jensimmons: so the perf impact would be lower
  jensimmons: but I agree we need to enable authors to understand what
              they are doing so they use the unit only when they
              really need the animation
  emilio: Also, it's unfortunate because if you use it on the body
          because then you still need to relayout everything

  Rossen: This example works with position:sticky
  fantasai: This case yes, but it might not always be the case
  fantasai: For example, maybe I have an effect where I click on a
            picture and it becomes the full size of the viewport,
            should be the size of the viewport right now
  jensimmons: I am sure there are use cases

  jensimmons: I could gather more evidence if needed
  Rossen: I think we should probably get another example, but I
          think we should focus on answering the question at hand
  Rossen: Do we agree to add the dynamic unit?
  jensimmons: We need to know if this is something we can implement
  myles: Yes, if you can do in js
  hober: But it's really problematic that we would need to do layout
         in scrolling
  hober: Even if we add this, this would be an attractive nuisance.
         The behavior would be just as janky as js.
  hober: so I don't think we should do this
  hober: but we can have smooth performance with position:sticky
  jensimmons: But there are other examples, if you need to the height
              to be considered
  Rossen: There's position:fixed for that
  emilio: Yes
  * emilio agrees with hober
  TabAtkins: But there are cases where you only want to show it in
             some context
  TabAtkins: and position:fixed make it visible at all times
  dbaron: does position:sticky help with that?

  <bkardell> would it be useful to have a collection of use cases and
             allow the CSSWG to propose how you could do this today,
             and then let devs tell us why that doesn't suit their

  [TabAtkins gives example of some widget which is not position fixed
      or sticky, and is compacted by default, but when expanded (in
      place) should take the size of the viewport]
  Rossen: Also if you have a "fake fullscreen" where an experience
          takes the full size of the viewport
  Rossen: and you might want to resize that experience as the user is
          scrolling, so it doesn't go out of bounds of the viewport
  Rossen: You can of course do that with js, and we ask the
          question whether we want a better solution
  <fantasai> hober, this is why we're providing the units, and making
             them a lot more convenient to work with. vhc or whatever
             is a lot easier than env(viewport-height) unless you've
             got a strong reason for the latter

  Rossen: I think we should probably defer, and see more use cases
  Rossen: Except if we all agree
  Rossen: but the points on performance and layout on scrolling remain

  <fantasai> btw, anyone with Safari mobile able to load
             http://inkedblade.net/viewport-test.html ?
  * fantasai is wondering whether it looks like Chrome, which has them
             different sizes, or not
  <astearns> I see blue taller than yellow, fantasai
  fantasai: I pasted a testcase
  fantasai: There is no interop in a lot of cases
  emilio: There is been a lot of effort from us to match Chrome/Safari
  emilio: so I'm surprised we don't match
  <fantasai> Safari also showing 100% and 100vh not being equivalent
  Rossen: What is showing, I don't have a phone?
  florian: 100% and 100vh don't always match
  florian: In Chrome
  Rossen: But that's for the previous discussion then?
  <fantasai> It's an open point we need to resolve

  Rossen: Let's get back on track
  Rossen: Can we resolve now, or do we want to defer?
  jensimmons: I think we should think about this more
  jensimmons: so let's table this for now

  fantasai: Also, I think we should have a discussion about the compat
  fantasai: Should 100% and 100vh match?
  hober: I don't think we can resolve this
  fantasai: The spec doesn't have a concept to allow them to diverge
  hober: There is a lot of content designed for mobile
  hober: and they rely on webkit/blink actually
  fantasai: I would have loved implementations to file an issue before
            making these changes, because right now the spec and impl
            don't match and we were not made aware
  heycam: But since we aim to match gecko and blink/webkit, I think
          yes we would want to update the spec

<br type=lunch>


  astearns: Where are we with V&U? any issues?
  TabAtkins: I want to do a publication
  TabAtkins: I'm editing in resolutions right now
  TabAtkins: so maybe in 2 weeks
  Rossen: Thought maybe we were ready, but that's fine
  astearns: Regular WD, let it settle, then go to CR?
  fantasai: Need people to read from top to bottom and review

Received on Thursday, 13 February 2020 00:51:54 UTC