- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 18 Feb 2020 19:19:55 -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
----------
- TabAtkins' polls for how to handle mod() in issue #2513 (Add
round()/floor()/ceil() functions) got different answers
depending on how the question was asked so there is no clear
conclusion on the best approach.
- Polls: https://twitter.com/tabatkins/status/1219936010961915905
| https://twitter.com/tabatkins/status/1219939184682717184
CSS Transforms
--------------
- RESOLVED: No change to the behavior, add a note to the spec
- RESOLVED: Move the box keyword definitions on css-box and publish
a new working draft
- RESOLVED: Rebase the rest of the specs referring to these
definitions to point to css-box
- RESOLVED: Move margin-trim to css-box-4 before republishing
CSS Overflow & CSS Scollbars
----------------------------
- RESOLVED: Move scrollbar-gutter to the scrollbars spec, add
florian as an editor (Issue #4674: scrollbar-gutter is
too complex)
- Due to the discussion about what properties below on
scrollbar-gutter (below) it was suggested that the move
shouldn't occur until after the final property set is
decided and therefore it can be certain that this property
is a better fit for Scrollbars.
- There are not documented use cases for all the scrollbar-gutter
properties so several implementors expressed concern about
implementing properties that may not be needed. Florian will go
back through and add in the use cases for the properties for the
group to use and then finalize the property set during a future
meeting.
Web Animations & CSS UI
-----------------------
- RESOLVED: Mark user-select as discretely animatable, not
non-animatable. (Issue #3153: Animating user interaction
controls)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/galicia-2020
Scribe: emilio
CSS Values
==========
Update on mod() function
------------------------
github: https://github.com/w3c/csswg-drafts/issues/2513
<TabAtkins> https://twitter.com/tabatkins/status/1219936010961915905
<TabAtkins> https://twitter.com/tabatkins/status/1219939184682717184
TabAtkins: So the poll I started yesterday about mod has ended
TabAtkins: had some fair results, and the contradictory results I
expected
TabAtkins: So 3/2 in favor of JS semantics if you ask directly, 9/1
in favor of math if you ask them about expected results
of a basic computation. So depends on how you ask.
TabAtkins: So the conclusion is that most people just write buggy
code and they think / want math semantics
TabAtkins: There's also a lot of discussion in the replies about
use-cases
TabAtkins: and it seems math is a better suit to fix those use cases
jfkthame: Would people be better off with explicit is-odd / even
functions
TabAtkins: They sometimes use it as a proxy for odd / even, but it's
not general of course
TabAtkins: So no decision for now yet unless the room is convinced,
but worth thinking about it and we can pick this up at a
later call
TabAtkins: How does the room feel? Did anyone change their mind?
myles: I guess there's a third option which is not defining what
negatives does
TabAtkins: That's what C++ does and that's evil
myles: I didn't mean to return unicorns but just explicitly return 0
or something
TabAtkins: It seems negatives could be common, I wouldn't want that
Rossen: Seems not many opinions have changed so let's move on
CSS Transforms
==============
'view-box' definition doesn't make sense
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4662
TabAtkins: The definition seems to not make sense
TabAtkins: The origin and size of the box are not related
TabAtkins: says that the origin of the coordinate space is the
viewbox start
TabAtkins: and the size is the size of the viewbox
TabAtkins: So for example if you have a viewbox="20 20 100 100"
TabAtkins: the origin of the coordinate space is outside of the
viewport, such as the origin is at (-20, -20)
TabAtkins: so that the viewbox is based off a rectangle outside of
the svg's viewport
heycam: So before CSS transforms, in svg you couldn't use percents
inside transform so this was a non-issue
heycam: I wonder if the issue is the way we're defining this
rectangle
heycam: Maybe it doesn't make sense to define that rect
emilio: For percents in transforms you just need a basis so you
don't need any origin right?
fantasai: Yeah but other stuff references the view-box
TabAtkins: And the origin matters for rotations and scales
emilio: Fair
myles: Pretend you use transform-box: view-box and rotate by 3deg or
something, what would you expect?
TabAtkins: Multiple acceptable answers, but the issue is that the
size and the origin are not related, unlike other boxes
fantasai: The issue is that this is how transforms have been defined
in SVG
fantasai: [reads AmeliaBR's comment in the issue:
https://github.com/w3c/csswg-drafts/issues/4662#issuecomment-576496516
]
TabAtkins: Ok if it's what SVG uses by default then sure, whatever
TabAtkins: but I'd like it to be called out explicitly
faceless2: The way we see the viewbox is just a translate transform
faceless2: I'm not sure it's as confusing as it sounds
TabAtkins: My issue is that if you choose transform-origin: 100%
100% the point you get makes no sense
TabAtkins: but sure if it's legacy then fine, I thought it was
invented recently as it was added after other changes
TabAtkins: so I'm ok with the behavior but I want to clarify that
this is legacy svg behavior
Consolidating Box Definitions
-----------------------------
fantasai: There are other specs that reference these values somewhat
inconsistently
fantasai: we copied them all out into the box model module
fantasai: I want to update the definition of viewbox to account for
this and then change all specs to reference those
definitions
fantasai: Any objections to doing that?
<TabAtkins> https://drafts.csswg.org/css-box/#keywords
RossenF2F: It seems something we should do, and seems we should
close 4662 with no change
RossenF2F: with the note added to the spec explaining why
TabAtkins: I guess we'll add it to the box spec
RossenF2F: Sure
fantasai: Do we need another keyword to reference the box tab was
talking about? (size of viewbox at the position of
viewbox?)
RossenF2F: Probably not
RossenF2F: Objections to the proposed resolution?
RESOLVED: No change to the behavior, add a note to the spec
RESOLVED: Move the box keyword definitions on css-box and publish a
new working draft
RESOLVED: Rebase the rest of the specs referring to these
definitions to point to css-box
fantasai: I propose to move the only non-css2 feature in css-box
(margin-trim) to level 4 and move this to CR and co. fast
so that other specs can depend on it
RossenF2F: Sounds reasonable, objections?
RESOLVED: Move margin-trim to css-box-4 before republishing
CSS Overflow
============
scrollbar-gutter is too complex
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4674
cbiesinger: We're interested in implementing this: there's a lot of
values for this property, but a lot of values didn't
seem that useful to me
cbiesinger: florian came with some use cases but I'm not sure
they're useful enough?
iank: We probably only want to implement stable
florian: The other values were solving issues raised by Google
florian: we should explain them better in the spec
florian: but I'd be sad if we removed it
cbiesinger: I think your explanation makes sense
fantasai: Seems to me this feature belongs on css-scrollbars, not
css-ui
florian: I don't care, though I'm not an editor of css-scrollbars,
so if you want me to keep editing the feature I should
become an editor
RossenF2F: Objections to move from css-ui to css-scrollbars and
adding florian as an editor?
RESOLVED: Move scrollbar-gutter to the scrollbars spec, add florian
as an editor
myles: We did a review with some people that know more about design
than me
myles: This feature fundamentally breaks overlay scrollbars
myles: but we also understand that there's a real problem here
myles: and you don't want the scrollbar to cover things
myles: There's also another issue (#4691) which proposes adding an
environment variable with the width of the native scrollbars
myles: It seems that'd allow authors to peek
<tantek> myles++ has a very good point
florian: I don't think the stable value changes anything with
overlay scrollbars, it's the force value what's problematic
for you right?
myles: Any property that says "all elements should not be covered by
overlay scrollbars" is problematic
hober: We like the idea of moving active elements but we don't want
to encourage authors to try to inset everything
cbiesinger: The env variable seems a better solution for the google
use case
florian: I don't think it would because an env variable is for the
entire page, so it doesn't depend on whether there actually
are scrollbars
cbiesinger: I meant the combination of the env variable with the
stable value
fantasai: But florian's point means that scrollbar width may change
fantasai: and you don't know the scrollbar width
myles: The wide value is not really that wide, so probably just the
wide one would be enough
myles: I think the value should be zero for non-overlay scrollbars
<tantek> we deliberately removed explicit numeric width from
scrollbar-width. there's also no "wide" value
<tantek> https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width
<tantek> just: auto | thin | none
fantasai: We need both to align non-scrollable elements to scrollbars
myles: Isn't that a problem now?
florian: Yes, but that's something that `scrollbar-gutter` solves
florian: The `always` toggle let you get the scrollbar gutter on
elements that are not scrollable
florian: which lets you fix that
<fantasai> The example is is a toolbar which is not scrollable over
a scrollable box. The author wants the rightmost item in
the toolbar to align with the rightmost item in the
scrollable box.
hober: In a world with that value and overlay scrollbars then that'd
be zero
myles: [[discussing with florian on the whiteboard]]
<fantasai> The discussion is about how to know how thick to make the
padding on the toolbar if the scroller has a
'scrollbar-width: thin' declaration - the solution
currently is to say 'scrollbar-width: thin;
scrollbar-gutter: always force' on the toolbar
myles: So you mean that we need two environment variables, one per
scrollbar-width value?
<tantek> there is no "thick"
<tantek> scrollbar-width: auto
<tantek> is what I think people are trying to say?
<tantek> examples?
* tantek agreed with myles
florian: The thing that would fix this is `always`, people are
already moving stuff away from the scrollbars, just
guessing how wide they are
hober: So a variable that tells you how wide it is?
florian: As long as you can do that then I'm fine
myles: There are too many values
TabAtkins: Some of them could be named better
<TabAtkins> Okay, so I remember why we did "always" - "stable" means
that authors still have to ensure their designs work on
both widths. "always" was meant to be a "let authors
safely be a little lazier" value.
<TabAtkins> I feel strongly that if we do stable, we *need* force;
that's the use-case Florian illustrated and it's very
valuable I think.
<TabAtkins> We can maybe drop "both" - it had use-cases that I think
were mostly based on "always".
<TabAtkins> So perhaps an `auto | [ stable && force? ]` grammar
reduction.
<tantek> re: https://github.com/w3c/csswg-drafts/issues/4674 "Blink
is interested in implementing/shipping scrollbar-gutter"
tantek: I'd like to ask Google which other values besides stable is
Blink interested in implementing, and is blink interested in
implementing scrollbar-{width,color}?
cbiesinger: Definitely interested in stable and the env variable,
not so much in others
tantek: Makes sense, and I tend to agree with myles that there's if
there's no implementor interest and no use case maybe should
be dropped
cbiesinger: scrollbar-{width,color} is not on the roadmap
iank: Not meaning we won't implement, but not on the roadmap
tantek: Then I'd probably advocate for undoing the move to the
scrollbars spec
tantek: we'd have to do a lot of gymnastics
hober: Why not put them in different levels of the same spec?
fantasai: I think there's a benefit to readers to have related
features in the same spec
fantasai: keeping it in overflow doesn't make much sense
tantek: I don't think there's any benefit of moving it
RossenF2F: I don't think we should do busywork just for the sake of
doing it, but I do think that we should have
scrollbar-related properties together to move them for
the REC track, and for readers
RossenF2F: This is why we have modules and levels
RossenF2F: so we probably can still make a level of scrollbars be on
the REC track with color/width
<bkardell> what about what hober said?
<fantasai> hober, scrollbar-color and scrollbar-width already have
one implementation
<fantasai> hober, scrollbar-gutter has an intent from Chrome
<fantasai> hober, it's not clear which is further ahead in that
respect
<fantasai> hober, and we're not even in CR, so there's no reason to
drop anything atm
tantek: Given the fact that there's disagreement on what
implementors are interested in I think that trumps the
cosmetic use case
tantek: That practical divergence should override the cosmetic thing
<bkardell> "interest" and "priority" aren't the same though
fantasai: But it's a WD
tantek: Right that's why I think busywork is not warranted
tantek: hearing from WebKit that they're interested in all three,
otherwise just leave it alone?
RossenF2F: Let's try to avoid discussing process too much... Do you
want to undo the previous resolution?
tantek: Yes, because the lack of interest from blink in
scrollbar-width/color means we shouldn't do it
iank: That's a misrepresentation
jensimmons: interest is not the same as saying not on the roadmap
iank: It just meant not in the roadmap at the moment
iank: that may change in the future
cbiesinger: I'm more skeptical about the scrollbar-width use case,
we just don't plan to implement it soon
RossenF2F: There are other implementors other than google :-)
TabAtkins: Yeah we try to be extremely clear when objecting because
we understand it's a powerful statement
<fantasai> I want to point out that overflow-4 is otherwise
completely experimental stuff and is not an appropriate
place for a feature that is being imminently implemented
<tantek> fantasai then move the experimental stuff in overflow-4 to
overflow-5
<tantek> don't make extra busy work for multiple specs
<fantasai> tantek, it's not an overflow feature, it's a scrollbar
feature
<fantasai> tantek, it doesn't belong in that module
<tantek> overflow and scrolling are tightly related
<TabAtkins> tantek, stop objecting to other people volunteering to
do work
<tantek> fantasai quit making an aesthetic argument
<fantasai> tantek, it's a usability argument. I want our specs to
not be GCPM-style hodgepodges
<tantek> I'm saying postpone until we get positive signals from
implementers for all three properties
<tantek> I'm arguing for more modularity not less
<tantek> anyway my objection to the previous resolution is recorded
<TabAtkins> tantek, one property per spec?
<tantek> TabAtkins: no I'm not interested in strawman like that or
fantasai's "GCPM-style hodgepodgs"
<tantek> seriously, not good faith arguments
<tantek> starting by removing things that lack a reason is the right
thing to do
florian: I heard calls for dropping values and I'd like to push
back. We designed this for years in response to use cases.
I'm happy to document what the use cases were and maybe
rename values so they're better names
florian: but until that's done I don't think we should drop values
hober: That's some work in order to chop things, I'd rather spare
you the work and chop them now
<tantek> hober++
<tantek> I'm really not sympathetic to features without examples/
explanations up front
florian: It's just some examples, and I'm sure we won't chop it off
dbaron: I'd say that's a reason why specs should have explainers
with what they're trying to solve
myles: I don't think that actually conflicts with the env variable
proposal
<tantek> if you can't link to the examples / explanations, consider
them non-existent
florian: I recall people saying there are no use cases but there
were, and I'll spend some time cleaning up this and
investigate dropping these after we remember what they're
for?
<tantek> florian: if you want to postpone dropping, then why not
postpone merging also? why is that kind of tentative
reasoning good for one postponement and not another?
<tantek> feels pretty inconsistent
TabAtkins: I think we agree that stable or something that implements
that is good, and that env doesn't solve it
TabAtkins: I think `force stable` seems reasonable too
TabAtkins: as that is what you can use to align
TabAtkins: non-scrollable things to scrollable things
cbiesinger: You can use that with the env variable right?
TabAtkins: Yes
florian: Don't you need a media query for overlay scrollbars?
emilio: env variable would be zero in that case
TabAtkins: Always is the one you were more skeptical about
TabAtkins: it's done so that you can consistently design stuff
across systems
TabAtkins: I could see us dropping always for now
TabAtkins: `both` is intended for always and it seems to be a lot
less valuable with stable
TabAtkins: and I think we can drop it for now too
TabAtkins: So we can probably drop them and use `stable` with the
`force` keyword, or with the `env()` variable
myles: Sounds reasonable
* fantasai thinks we should take this offline, have Florian and Tab
come to a conclusion and come back with it
<emilio> fantasai++
florian: My proposal is to revisit this in a week or three
florian: once we have the cases described and alternatives clear
<tantek> if you're postponing dropping, then postpone merging
<tantek> why is postponing ok for one and not the other?
hober: I wanted to reply to tab
hober: You said that you're ok dropping always and both, and then
between stable + force, or stable + env() you're indifferent
right?
hober: I prefer the env variable
hober: I think it should be an exceptional thing done with
particular descendants, and the env variable encourages this
a bit more
TabAtkins: Are you ok with adding more than two values for different
widths?
hober: We can get to that once it comes up
cbiesinger: I agree with hober though for different reasons. I think
env() is more understandable for authors than `stable
force`
RossenF2F: So next steps florian brings the use cases for the
current design
hober: I think we have multi-engine agreement here, which seems
worth noting
<tantek> I agree with cbiesinger, so don't bother with moving a dead
property into a different spec
<cbiesinger> well the property isn't dead, just maybe some values of
it
RossenF2F: Re: merging, scrollbar-width/color just styles
controls... scrollbar-gutter is more about the box model
RossenF2F: so let's not move everything to scrollbars yet until we
know what will remain there
RossenF2F: next call we'll see whether we stick to that resolution
<tantek> Thanks Rossen for clarifying purpose of scrollbars spec.
You're right we should have started there
<tantek> Rossen++ for upleveling the conversation
<tantek> That sounds like I need to better document scope in the
Scrollbars spec
<tantek> TabAtkins: I've grown very intolerant of time-wasting
aesthetics.
CSS Env
=======
Scribe: TabAtkins
safe-area-insets-* for embedded document by iframe
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4670
emilio: There's no explicit area in env() spec about how
safe-area-inset behaves in iframes
emilio: Implementations disagree. We're doing some related work,
would like it clarified.
emilio: If iframes are nested, they may not care about safe areas,
etc.
TabAtkins: Who's responsible for this spec?
heycam: dino and you
TabAtkins: I'm there for processing model, not values. ^_^
hober: I'm happy to bug dino about this.
TabAtkins: Can you (emilio) tag dino into the thread?
emilio: Yes
Web Animations & CSS UI
=======================
Animating user interaction controls
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3153
fantasai: I thought we resolved this topic last year. I think we
should be marking these properties as discretely
animatable? (nav-up, user-select, etc)
fantasai: Stuff in the UI spec.
dbaron: I think we've only marked things as non-animatable when
there are technical problems, like animation-* or display.
fantasai: That's my understanding, so I think we just close this
issue?
<tantek> is that really the right default?
florian: I agree we only make things impossible when it's
technically hard, and I don't that the css-ui things are
that. I think they should be switched to discrete
explicitly.
florian: So if anything in CSS UI is still marked as non-animatable,
we should fix that to say "discrete"
tantek: Something dbaron said about non-animatable.
tantek: I agree that's been our historical default, but I'm
wondering if that's actually desirable.
tantek: At minimum, every time we mark something animatable, that
implies we need tests for that, that the animation works.
tantek: So those are all costs. So is that rule a sufficient
default? In this particular case, it feels kinda weird to
animate these particular properties.
tantek: I want to know florian's opinion on this. But my intuition
is that there's no use-case for these particular properties.
dbaron: As far as use-cases, people use animations in contexts where
they animate some UI in from not being there, then "turn it
on".
dbaron: I could imagine setting nav-up as part of turning it on.
Maybe it could have been there all the time, but it seems
plausible to do.
tantek: That's the kind of reasoning I'm happy to have on the record.
tantek: If you're animating layout, you might need to animate the
nav-* props; seems weird but I've seen weirder.
TabAtkins: And Lea has brought up examples in the past of
odd-seeming animations; I think there's probably an
example for everything.
heycam: I think there's value in having the blanket rule of
"animatable unless impossible" vs lots of use-case analysis.
heycam: And if something's not animatable we have to write tests for
that anyway, so same amount of work.
* emilio was going to make the same point as heycam :)
<tantek> good point heycam
<heycam> great minds :)
florian: Agree on testing.
florian: And note it's also about transitions. "animate or not"
tells you whether the transition happens at the middle or
at the beginning (or end? don't remember). So it has to
switch anyway.
florian: display, animation, etc can't be switched at all for
technical reasons, but everything else we're just deciding
where in the animation it switches, and there's no good
reason to ban it from choosing where to switch.
florian: I agree that user-select doesn't appear to have a use-case,
but for afore-stated reasons having an exception here
doesn't seem to be useful; we still have to pick one way or
the other.
<tantek> is there a use-case for user-select animating?
<tantek> what are we making user-select consistent with?
<fantasai> all other properties in CSS that use keyword values
<heycam> tantek, perhaps for similar reasons as dbaron mentioned
about some UI animating in. maybe you want it not to
respond to user interaction until the animation is done, or
at a certain point
<tantek> ok heycam. good enough for now.
<TabAtkins> tantek, more importantly to florian's point,
transitioning the property makes it swap at some point
regardless, its just about whether it's possible to
choose where it transitions or not.
<tantek> TabAtkins, ok that's the consistency I was looking for.
thanks.
RossenF2F: So close as accepted? Any objections?
RESOLVED: Mark user-select as discretely animatable, not
non-animatable.
Received on Wednesday, 19 February 2020 00:20:38 UTC