- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Feb 2020 19:51:05 -0500
- To: www-style@w3.org
=========================================
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()/
floor()/ceil()/mod())
- 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
function)
- 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
#4688)
- 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.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/galicia-2020
Present:
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
functions
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
https://github.com/w3c/csswg-drafts/issues/2513#issuecomment-565736728
<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|
away-from-zero|nearest-half-goes-up|nearest-half-goes-down|
nearest-half-goes-away-from-zero|
nearest-half-goes-towards-zero
Rossen: Prior art, agreement in the room, any objections
Rossen: ok resolved
RESOLVED: Adopt a round function with keywords detailing which
behavior
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
needed
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
minds
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
only?
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
consistency...
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
intuitive
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
object?
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
keywords
<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
conflicts
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
universes
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
<break>
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
strange
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
keywords?
TabAtkins: None, you can already get those results today by doing
computations
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
css
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
floats
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
math?
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
----------------------------------------------
github:https://github.com/w3c/csswg-drafts/issues/4329
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:
https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-547551485
]
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
work
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
case
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
summaries
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
have?
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:
https://labs.jensimmons.com/2016/examples/coversheet-2.html
<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
appropriate
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
future
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
keyboard
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
measurement)
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
acceptable.
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
needs?
[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>
Publication
-----------
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