- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Oct 2019 19:20:50 -0400
- 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 4
------------
- The use case presented in issue #4329 (Add vhc value) to address
the shifting viewports in mobile when the nav bar hides is one
that the working group wants to address. However, there was
concern that enough time hadn't been spent on understanding all
the possible cases that need to be addressed and the pros and
cons of each potential solution. jensimmons will take the lead
on making sure the necessary research is done to reach a
resolution.
CSS Transforms
--------------
- There was support expressed for changing the semantics of having
transform-style: preserve-3d on the root element such that it
means that anything that's preserved as 3-D up to the root
element would be rendered in actual 3-D to address issue #4242
(Proposal new transform-style: detached) but there were people
missing from the call so a resolution will be reached later.
- RESOLVED: For the individual transform properties if they spec a
value that can be expressed as 2d we treat as 2d and
serialize accordingly (Issue #3305: Is it necessary to
serialize all 3 components of translate given the 3rd
component is 0px)
- RESOLVED: Require transform functions to be downgraded to 2d if
possible (Issue #3305)
- RESOLVED: We return the values the animation is working on while
the animation is going and that includes the endpoints
per the definition in web animations (Issue #3920:
Serialization of individual transform when the animation
is at 0% or 100%)
- RESOLVED: Reject this proposal (Issue #589: Let 'transform-origin'
and 'transform' take comma-separated lists)
CSS Text 3
----------
- Florian created examples and a PR to resolve issue #4422 (Bidi and
pre-wrap end of line spaces). fantasai will make some changes to
the PR and a call for resolution will happen next week.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Oct/0025.html
Present:
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Oriol Brufau
Dave Cramer
Kevin Ellis
Elika Etemad
Robert Flack
Simon Fraser
Dael Jackson
Sanket Joshi
Brian Kardell
Peter Linss
Anton Prowse
Florian Rivoal
Devin Rousso
Christopher Schmitt
Jen Simmons
Alan Stearns
Regrets:
Rachel Andrew
Tantek Çelik
Brian Kardell
Manuel Rego Casasnovas
Scribe: dael
CSS Values 4
============
Add vhc value
-------------
github: https://github.com/w3c/csswg-drafts/issues/4329
fantasai: Topic is not add a vhc as much as it is solve the problem.
Issue is that on mobile we have multiple notions of
viewport. Viewport units are defined in regards to
viewport but on most browsers there's a disappearing
address bar
<fantasai> https://chanind.github.io/javascript/2019/09/28/avoid-100vh-on-mobile-web.html
fantasai: To avoid content from constantly shifting have made that
not respond to appear/disappear of address. Problems is
defaults being impl makes viewport behavior where 100vh
assumes address bar is not visible. That's not initial
state.
fantasai: Lots of websites design to fit within visible are upon a
page load or to have things visible/invisible upon load.
Getting that things supposed to be on screen using vh are
not visible due to changing height.
fantasai: Need to solve the problem. Multiple options, could take
multiple of them.
fantasai: Want to hear what others think
AmeliaBR: Recap proposals from issue. 1 is don't add any new syntax
but encourage any browser with the disappearing nav bar
effect to size vh to value when chrome is visible.
AmeliaBR: Sometimes you'll have more than 100vh visible but on
initial load it will fit the screen. That's a guidance to
UA without changing language
AmeliaBR: Original posted suggested alternate unit proportional to
the smaller viewport
fantasai: Third is make the current vh unit to fit the initial load
and then add a unit that allows author to take full height
of viewport if they want. Inverse of the initial proposal
fantasai: Advantage with that is current keyword is the safer value
AmeliaBR: Final option is to not add a unit and then add environment
variables for disappearing effect so it's similar to inset
variables
florian: Another aspect to problem; it's not just the title, but
appearance and disappearance of keyboard. Currently
keyboard resizes viewport, but maybe that should only
change visual viewport. That's a good idea, but title bar
can't do that
smfr: I don't think we should derail with keyboard. What you
described florian is iOS where it does not change layout height
florian: If you think it's separate let's keep that out
smfr: Did any proposals include a unit that changes value when
chrome hides? vh that changes
smfr: It's an option
TabAtkins: From author feedback they do not want that because layout
jiggle while it moves
AmeliaBR: Doesn't behave nicely with things that disappear on
scroll. For UX and rendering reasons. For other things
like keyboard where it's more discrete it's reasonable.
smfr: I'm all for avoiding layout jiggle. Seems that pages may be
designed such that chrome disappears when you're at bottom
florian: I think it would be weird to build a page that way
jensimmons: This is something I've heard a lot, the sentiments in
this issue. Like many parts of CSS the loudest voices
can be most negative. We should work on this and give
consideration for all use cases and not jump too quickly
and not resolve quickly for what loudest voices say. I'd
be happy to work on this and think it through. We need
to think about how to animate if they want that. This is
more complex. But we should tackle
smfr: Related all would match, 100vh, 100% body, window.innerHeight
would all mean same thing. Currently don't. Don't know if they
can but it should be a goal
<jensimmons> +1 to everything should match
smfr: Do we know if Android has a similar behavior to iOS where
100vh is the chrome hidden state?
<smfr> here’s a testcase: http://smfr.org/css/viewport-units.html
fantasai: Blink has 100vh and 100% on html body meaning different
things. 100vh matches Safari. They would like 100% html
match but that's currently being a work around for vh not
considering address bar
fantasai: One of the devs that worked on this in Blink said they
wanted to argue for 100vh not including address bar but
they had to match Safari
jensimmons: Seems like WG took approach for UAs to fill in details
and each browser took a different approach and it's not
really working and we should come in and specify, but
with a range of options for authors so they can do what
they want
astearns: Anything else on this to discuss or do we have jensimmons
work on the use cases to consider?
fantasai: I'm happy to kick it to jensimmons to think. It's
important and we should not drop, but we can talk later
astearns: Anything else people want added to discussion?
astearns: I think smfr list of things that should be equivalent is
excellent
AmeliaBR: Another option on issue was someone suggesting box sizing
like property where authors choose what vh units are
relative to. It's another thing to think of
fantasai: Probably 2 pairs of units would be cleaner and less likely
to result in accidental errors
myles: 2 units might be better cause can use both at the same time.
Mode switch you can't use both at same time
<dbaron> Using both at the same time is probably very hard to do
correctly, though.
AmeliaBR: Good arguments.
AmeliaBR: Lots of options and use cases. Getting through pros and
cons for each sounds sensible
astearns: Let's continue in GH. jensimmons I'll assign it to you?
jensimmons: Okay
astearns: We'll discuss again on the call when it's at a good point.
CSS Lists
=========
Should automatic list-item increment adjust for ol[reversed]?
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4181
TabAtkins: I'd like to delay for a week. I just pinged to
implementation and the person to look is on vacation. I'm
not comfortable talking before he's back next week.
astearns: fantasai anything we can get through?
fantasai: Not urgent
CSS Transforms
==============
Proposal new transform-style: detached
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4242
AmeliaBR: Use case is for 3d environmental displays, VR and AR.
Having a way to spec css content should be displayed in 3d
in that environment without getting flattened to web page
rendering
AmeliaBR: Rik's proposal was to add a new keyword to transform-style
property that would indicate this stays in 3d separate
from plane of browser rendering
AmeliaBR: Another option from dbaron is to just use existing
transform-style:preserve-3d but if you say it on the body
or root and rendering environment can preserve the 3d
rendering gets to the overall rendering environment
AmeliaBR: Question is would it be web compat or is there content
that would look bad if it's not flattened?
TabAtkins: I generally support dbaron proposal absent compat data
showing it's bad
florian: I also support it in part for a weird thing with the other
way. If you have a small iframe and the page doesn't intent
3d but the iframe does leak 3d you could have intrusive ads
even that the page didn't want. If you put it on the root
the hosting page does what it wants
smfr: Don't think we should get too far without Rik
astearns: That's fair. Rik can read this and I'll ping him about
joining a call
AmeliaBR: If you know anyone working on 3d in immersive environments
get them to look at the issue
Is it necessary to serialize all 3 components of translate given the
3rd component is 0px
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3305
TabAtkins: Question was the individual transform for translate spec
distinction between 2d and 3d. If you explicitly give 2d
it always does 2d, 3d is always 3d even if z is 0.
Question of if it violates shortest serialization.
Originally thought no because 3d has a meaning, but after
looking any differences left we treat as bugs
TabAtkins: We're fine serializing as 3d. Fine with doing what heycam
suggests.
TabAtkins: Does have minor changes because some difference as you do
3d animation as you pass through 0 if you pause right
there it looks a little different. Considered minor by
those in thread
dbaron: No longer animation difference between 2 value and 3 value
syntax?
TabAtkins: If you pause a 3d transform while it's animating and at a
state where it's 2d transform it will serialize
differently. We're fine with that for now and consider it
a bug being fixed
dbaron: I thought another difference was animation behavior
depending on if you spec 2 or 3 values. My memory is a bunch
of the is it 2d or 3d are related to interpolation
AmeliaBR: If before and after states one is 2d and one is 3d they
won't match us as being consistently the same. If one of
them uses 3 values and 3rd is 0 I don't know how it's
interpolated
AmeliaBR: With this proposal the 3 value disappears at computed and
interpolates as a 2d
TabAtkins: dbaron do you have an example for your concern?
dbaron: If you're trying to interpolate between translate and matrix
and if the translate is 2d or 3d might effect if
interpolation goes into 3rd dimension. But interpolation
rules have changed so I'm not sure current state
TabAtkins: Think I'm in the same boat.
dbaron: Basically want to make sure when you said there aren't
significant differences you ran it by someone who is up to
date on the interpolation rules
TabAtkins: Eric W and chris have been in support
dbaron: Okay
astearns: Would it be emilio on gecko's side?
dbaron: Possibly birtles, but I'm not sure.
dbaron: Possibly hiro
astearns: dbaron would you be okay resolving?
dbaron: I'm okay
AmeliaBR: I want to mention that this complicates how transforms are
specified for svg which does make distinction between 2d
transforms being regular layout vs 3d transforms being an
isolating, flattening effect.
AmeliaBR: We haven't had a lot of implementors following spec to
distinguish for SVG so might not be breaking. We do need
people to commit to following through and cleaning up
those areas of the spec and how do they work if we don't
have clear consistent way to define 2d transform and 3d
transform
TabAtkins: Yeah. Other evidence, Eric points out all 4 engines
serialize scale 3d with 1 z value as a 2d matrix. In
general engines are loose even when you explicitly say
3d. Remaining errors with z-axis translate we're fine
treating as a bug
astearns: Proposal?
TabAtkins: Option 1: For individual transform properties should they
make 2d vs 3d distinction vs number of properties. We
propose go on the value of the z value
TabAtkins: In general should transforms be more permissive about 3d
functions without 3d requiring transform being equivalent
to 2d. Have a mixture of behaviors, Blink is in favor of
downgrade to 2d when possible model
TabAtkins: Individual transform is easier.
astearns: Proposal: When there is a 3d value the transform
properties are only 3d if the value is not 0
TabAtkins: If the transform can be expressed as a 2d we serialize as
a 2d
astearns: Just serialization then?
AmeliaBR: More then serialization. It means that the round tripping
is if you serialize and re-parse it's 2d so we don't want
it to behave different whether you set the 3rd parameter
or leave as default
TabAtkins: A translate with 3 values but z is 0 should not trigger
full compositing
astearns: Trying to figure out how to state option 1
TabAtkins: For the individual transform properties if they spec a
value that can be expressed as 2d we treat as 2d and
serialize accordingly
RESOLVED: For the individual transform properties if they spec a
value that can be expressed as 2d we treat as 2d and
serialize accordingly
astearns: Second?
TabAtkins: Apply the above to all transform functions in normal
transform property and then figure out implications for
serialization and interpolation
AmeliaBR: Have some sort of resolution conditional on people doing
web compat tests and get feedback from more authors?
TabAtkins: I'd rather not resolve if we're waiting for that.
AmeliaBR: At this point without a clear text of all places it'll
impact it's hard to get author feedback
AmeliaBR: I'm a little worried about web compat depending on fine
details
TabAtkins: I suspect this will be hard to get author feedback
because it's technical and tiny. Compat-wise sure. Blink
is okay with eating the compat, but if others are
uncomfortable we can wait
AmeliaBR: You're right feedback won't happen until it's pushed.
astearns: I expect that making this change to figure out compat
problems requires a resolution? Or would Blink experiment?
TabAtkins: We'd like spec text, but in a proposal is okay. So we can
point to that's what we're doing
fantasai: We can resolve and say checking web compat
AmeliaBR: Not sure anywhere it makes sense to talk about this as at
risk. I guess it's not a CR change
AmeliaBR: Widely impl but not officially stable
TabAtkins: Yes
AmeliaBR: Make the change with the awareness we might get author
screams and have to revert
astearns: Proposal: Require transform functions to be downgraded to
2d if possible
astearns: And we'll see what web compat shakeout is. Objections?
smfr: Just for serialization?
TabAtkins: Not sure the distinction. What would be different between
yes and no to that
smfr: I guess not interpolation because 2d and 3d matching
TabAtkins: Preserves compositing if you're in an animation
AmeliaBR: 2d gets upgraded to 3d to match endpoint
smfr: webkit uses it as a trigger
TabAtkins: That's what we're willing to stop doing
astearns: Any concerns smfr?
smfr: No, worth experimenting
astearns: Objections?
RESOLVED: Require transform functions to be downgraded to 2d if
possible
Serialization of individual transform when the animation is at 0%
or 100%
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3290
astearns: Also from heycam.
AmeliaBR: Overview. When interpolating transform functions you often
first need to do processing to upgrade function into a
form that interpolates with other end. At exact moment
when at beginning or end of animations or in frozen
animation state is serialization using the upgraded
functions or is it using the original as specified
functions for the endpoint
AmeliaBR: There are wpt tests that do it one way and someone
expected the other. Not sure who does what
dbaron: This can influence transitions, like if you reverse when
it's filling you might get different behavior. I've seen
that in the past, though maybe rules have been fixed to
avoid some of those cases
smfr: I wouldn't expect function upgrading for animation would
effect serialization.
AmeliaBR: The issue is specifically about individual transforms and
upgrading the none keyword. Not sure how it compares to
functions in transform property. I would expect consistency
dbaron: I was thinking of transform property, not individual
transform properties.
AmeliaBR: My fault for skimming too quick
smfr: I understand now the endpoint there's ambiguous about if you
use upgraded functions
TabAtkins: Individual transform properties, given the previous
resolution that we should serialize to lowest state I
think this answer the question. Not for none but the ones
that are 3d to 2d there is an upgrade in the middle. If a
none value should serialize as the null value or not when
it's an endpoint
astearns: We should resolve on the endpoints not upgrading first?
AmeliaBR: There is a switch in between a none value and any other
value has side effects. Despite previous resolution actual
transform side effects are clearly defined. translate: 0 0
has side effects that translate: none does not. Can't just
ignore that as a rule
AmeliaBR: If you're in an animation from a transform to another
value the side effects persist as long as the animation.
Makes sense as long as animation persists you have an
explicit value instead of none
<dbaron> +1 to what AmeliaBR (IRC) just said
TabAtkins: Agree. If animation is active we should preserve that
there is a transform b/c none has a lack of side effects
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/3290#issuecomment-539719709
TabAtkins: Further issue is ^
TabAtkins: There's an example where one endpoint has non-normalize
rotation, but during animation we do axis normalization.
If it's active do we return normalized or specified
non-normalized? Fine with consistent where when animation
is running we report the animation's value.
smfr: Does WebAnimations have something to say?
TabAtkins: Yes, it has to report if there is an active animation.
Not sure if it has details about this issue. It knows if
an animation is running
smfr: May be a case where we just want consistency
TabAtkins: Agree, everything except none case is consistency. I
think that leans us to take value animation is working
on, not the endpoint value
smfr: Sounds fine to me
astearns: Proposal is we return the values the animation is working
on while the animation is going and that includes the
endpoints per the definition in web animations
astearns: Any concerns with this change?
astearns: Objections?
RESOLVED: We return the values the animation is working on while the
animation is going and that includes the endpoints per the
definition in web animations
Let 'transform-origin' and 'transform' take comma-separated lists
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/589
smfr: Old proposal to allow transform property to take a comma sep
list where each has its own transform-origin. Additionally a
proposal for shorthand to allow origins
smfr: Seems a bit too late to add this, big change to transform. Not
in favor, but welcome other input
<dbaron> Seems like a bunch of complexity (e.g., with animations),
so I'm fine with rejecting the proposal.
TabAtkins: Reasonable. To address use case might be interesting to
explore transform-origin function that takes the list.
But that would be convenience feature.
TabAtkins: I was in favor back in the day, but I agree it's minor
and not worth the churn
AmeliaBR: Agree with TabAtkins. If we do this it has to apply to
transform-box as well as transform-origin
astearns: Is what the proposal requests possible but in a different
way?
TabAtkins: Yeah, translate-origin is a translate function before and
after your transform list. You can simulate it on your
own. You have to know how to do that and perhaps an
example would be good. Nothing to prevent you from
representing on your own
astearns: Proposal is to reject this proposal
astearns: Concerns?
RESOLVED: Reject this proposal
CSS Text 3
==========
Bidi and pre-wrap end of line spaces
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4422#issuecomment-543054050
florian: Spoke about similar and resolved. This is a new one.
florian: We have provisions as to what happens to spaces at end of
line. Number of cases where supposed to hang. When you do
bidi on line and spaces end up in the middle of the line is
unclear and not interop. Screenshot in the issue of what
everyone does and a second of what I should should be done
florian: Complication of screenshot is spec allows 2 things, spaces
to hang or spaces to collapse. Not discussing changing that.
florian: There's a number of variants, so easier to look at. If
people have looked would appreciate feedback on if you
agree or not.
TabAtkins: In your example are the colored spaces logically in
rainbow order?
florian: No, just different colors. No order. whitespace-pre example
show order when they are bidi reordered. Source order is in
link above
TabAtkins: Looking for easy way to know logical order of spaces, but
answer is look at source
AmeliaBR: Example is spaces between every letter and some of the
letters are naturally right to left and some are left to
right
florian: Look at comment at bottom where I explain every case where
I think they should change and why they're wrong. If you
think there's something incorrect in that claim it would be
good to know
fantasai: Intention is correct, want to re-work PR
astearns: People should look, fantasai rework the PR before next
week, then we'll resolve
astearns: Thanks everyone and we'll talk next week
Received on Wednesday, 23 October 2019 23:21:31 UTC