- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 24 May 2021 18:52:08 -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
----------
- RESOLVED: Adopt an 'inherit' function to values-5 (Issue #2864:
inherit() function: like var() for parent value, for any
property)
- It was noted that making this work would require us first to have
100% interop on value serialization across all properties, which
is a large project, and will take a lot of time and effort.
CSS Text
--------
- RESOLVED: Update spec to alias at compute time (Issue #6156: Same
behavior or alias for text-justify: inter-character and
text-justify: distribute)
Fill and Stroke
---------------
- RESOLVED: CSS stroke-width on text will resolve percentages
against 'computed font-size' size (Issue #6116: Should %
stroke widths be relative to the viewport for CSS?)
CSS UI
------
- RESOLVED: This feature should be solved with an attribute rather
than a CSS value (Issue #5998: appearance: base to
enable interoperable styling of controls/components)
- gregwhitworth will create an issue about adding a mechanism in
CSS to determine if this feature is enabled
Overflow
--------
- RESOLVED: We propagate scrollbar-gutter from the root to the
viewport (Issue #6079: viewport propagation of
scrollbar-gutter)
- RESOLVED: Scrollbar-gutter does not propagate from <body> (Issue
#6079)
- RESOLVED: No future properties should propagate from <body> to the
ICB or viewport (Issue #6079)
- RESOLVED: Deprecate any existing use of body propagation (Issue
#6079)
CSS Fonts
---------
- RESOLVED: font-optical-sizing: auto references the used font-size,
accounting for 'size-adjust' and 'font-size-adjust'
(Issue #6190: Clarify font-optical-sizing behaviour
under size-adjust)
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/17
Scribe: dlibby
CSS Values
==========
inherit() function: like var() for parent value, for any property
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2864
leaverou: Numerous request to extend var() to arbitrary properties,
can't do this generally due to cycles. Seems to be a less
powerful pattern that may be possible
leaverou: We can use it to get the value from the parent
leaverou: Should we do work to pursue this? I volunteer if consensus
that it is a good idea
leaverou: I can point to many use cases, in case they are not
obvious.
emilio: Seems implementable, but we want it to work like var() at
the token level
emilio: You need to define for each property how it serializes,
etc.. it's a lot of work
leaverou: Would be equivalent to the token sequence
emilio: But what sequence? font-stretch as an example. You need to
get interoperable serialization for all properties
leaverou: Don't you need that anyways?
emilio: Yes, just pointing out it is a lot of work
Rossen: This is indicative of how long it might take to implement
emilio: Seems fine to implement
[What emilio is saying is that as a prerequisite to this,
we need to get interop on serialization of all properties,
which is something we don't have yet.
This requires a bunch of spec work, QA work, and
implementer follow-up to fix all the inconsistencies.
So it is not a small task.]
castastrophe: For container queries, computing ancestors comes down
to a 'contract' as things are flagged as cascading
'down'
castastrophe: Can we use a similar mechanism (!inherited) to
indicate such a pattern
emilio: I don't think that is necessary, as long as you inherit with
the same property, you already need the complete ancestor
style
TabAtkins: Shouldn't need that since there is no circularity
smfr: Concerned about implementation complexity vs. usefulness. In
the example, you could say inherit z-index to a font property
leaverou: There are use cases that you have to use a mixture of
properties
emilio: This would be implemented via existing serialization rules,
so this doesn't explode, you don't convert between
properties, use serialization syntax, then reparse token
stream
leaverou: In most cases you'll probably end up with an invalid
declaration
Rossen: Hearing consensus on what we want to achieve, but some
warning on how long this might take
Rossen: Any other points on the topic?
leaverou: proposed resolution - add an inherit function to values-4
to get the value of parent properties
RESOLVED: Adopt an 'inherit' function to values-5
CSS Text
========
Same behavior or alias for text-justify: inter-character | distribute
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6156
florian: In CSS text, we say that text-justify: inter-character has
an old name of distribute and has same behavior. Should
these be aliases? Conceptually this makes sense and is what
implementations do.
florian: Firefox implements as an alias where distribute serializes
to inter-character
fantasai: Distribute was implemented in IE5.5 or so. Computing in
Firefox demonstrates web compatibility, maybe we should
go with that behavior
florian: Not 100% clear if aliased at parse time or computed value
time, but it's being converted
emilio: We do it at computed value time, but wonder if we should do
at parse time
florian: Compute time is easier to spec, parse time can work also.
emilio: We alias a lot of properties at parse time
florian: For values, I'm not sure if it is well specified what it
means for a parse-time aliasing
emilio: The only difference is when querying specified style.
florian: We can spec Firefox behavior, or we can change to spec to
desired behavior.
emilio: Given that we have a lot of parse-time aliasing, maybe
better to go in that direction.
fantasai: Parse-time aliasing is not actually spec'd so we should
figure out where that would go.
emilio: [provides example of linear-gradient and
-moz-linear-gradient]
Rossen: This is a good precedent to clean up and specify
fantasai: Suggest that since existing implementation computes, we
should update spec to match implementation. Separately we
should define how aliasing works.
fantasai: At that point, if Gecko wants to change text-justify to
use the aliasing mechanism, we can do that in a separate
step
emilio: Sounds good to me
florian: We should not leave the spec as-is, either spec what is
happening today or what we want in the future
florian: proposed resolution - update spec to match Gecko
implementation
RESOLVED: Update spec to alias at compute time
Fill and Stroke
===============
Should % stroke widths be relative to the viewport for CSS?
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6116
smfr: Noticed that % stroke-width are relative to viewport, this
seems unexpected that it would change when resize window
smfr: I would expect it to map to line-height or something more local
Rossen: Didn't we have something in the SVG spec that was
disambiguating properties that derive from SVG viewport,
what happens in CSS
smfr: I don't recall
heycam: transform-box has all the keywords and how they map in
non-SVG contexts. We can probably use the same mapping
Rossen: In most cases resolving to containing box
heycam: That's right
Rossen: May or may not be expected here
<fantasai> heycam, https://www.w3.org/TR/css-box-3/#keywords ?
<heycam> fantasai: that's it
<heycam> so 'border-box' according to that definition
smfr: Context: filed this when noticing some odd webkit code, not
high priority
Rossen: I'd like to align behaviors that is coming from SVG, and how
to map the concepts when they come to CSS
Rossen: Continue to use the escape hatch for weirdness in the future
miriam: Consistent translation from SVG makes sense. I associated
with text-decoration-thickness which resolves against em
fantasai: There's not a good reason for text stroke width to
reference containing box, but resolving against font
metrics makes sense, and we should do what is useful if
there are no webcompat concerns
fantasai: re: diverging from SVG behavior, would be beneficial for
conceptual clarity rather than trying to stay consistent
in an unclear manner
fantasai: Not sure if percentages on stroke-width on text in SVG is
common, maybe we can switch SVG as well?
fantasai: More compat concerns but can't imagine that authors were
intentionally using it as it is currently spec'd
Rossen: Worth getting data
fantasai: Agreed for SVG, we should probably just do it for CSS
heycam: You can use stroke-width on non-text
heycam: Hopefully we can do it across SVG
fantasai: Might be more risk, not sure we can change all the behavior
fantasai: We should have percentages resolve against 'font-size',
and inherit as a percentage, as it does for text decoration
Rossen: proposed resolution - for CSS stroke-width on text will
resolve percentages against 'computed font-size' size
RESOLVED: CSS stroke-width on text will resolve percentages against
computed font-size
<break>
CSS UI
======
scribe: Myles
appearance: base to enable interoperable styling of controls/components
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5998
gregwhitworth: The context is that we're trying to start down the
path of standardizing form controls and components.
We'll need an agreed-upon DOM and styles.
gregwhitworth: Last time I presented on this, I presented about the
base appearance keyword and the pseudo element for
checkbox. I want to de-tangle them. I've had requests
for input type=range
gregwhitworth: I want to move forward with the base keyword.
gregwhitworth: For more context, the base keyword would be a toggle
that informs the browser that you want to have a
standardized dom and styles for a given element. That
would allow you to style interoperably.
gregwhitworth: UAs want to provide their own defaults. Authors need
to opt-in.
gregwhitworth: I'm looking for feedback: questions, thoughts.
emilio: If we want this to change the shadow dom that UAs create,
this is better as an attribute, despite that option sucking.
emilio: For gecko, it's kind of okay to create a lot of dom during
layout. It's not amazing. I'd like to get rid of that
mechanism. Blink generates the shadow dom at the DOM level,
not depending on layout.
emilio: Making CSS changes affect DOM for them, I suspect it would
be more of an issue.
emilio: Conceptually, it feels wrong
gregwhitworth: Sure. I'm primarily .... not that that's bikeshedding
.... I want to get at the more meta-issue. If
implementors say they prefer the attribute, I can
bring this to WHATWG. I'm asking if this group
accepts standardized styles and standardized DOM
emilio: I'm definitely okay in getting more interop in form controls.
emilio: This detail probably matters.
emilio: Can chrishtr weigh in?
emilio: Is CSS the right place for this toggle?
<tantek> +1 emilio
hober: My understanding is that we're also pretty reluctant to add
more mechanisms in CSS that cause DOM to get created.
hober: So, I think, this does seem like a problem we should be
trying to solve. An attribute would be less weird.
hober: ... on the implementation side of things.
florian: In addition to the implementation complexity, I have 2
other reasons for why attributes are probably better.
florian: 1. If we got with a CSS property with a single base
keyword, we need to introduce it simultaneously on all the
elements that accept it, or have a bunch of values so
people can detect their way into doing the right thing.
That problem isn't true if we do it as an attribute.
florian: 2. Depending on whether an element is base or not base, you
want to style it differently. If you cause it to be base or
not base through CSS, then you can't select on it.
<tantek> +1 florian about what you want to style differently
florian: The UA stylesheet needs to be different for a regular
checkbox vs a base checkbox, if the switch is in CSS, all
that solves itself if the switch is done via an attribute.
florian: We have multiple things pointing in this direction. All of
these work better if we got with an attribute vs a CSS
property.
fantasai: Just to throw a wrench into that, florian, you want to
style them differently based on the attribute, but also on
whether or not the browser supports that attribute
florian: We should have an attribute an attribute AND a pseudo-class.
fantasai: We can also add an @supports query.
fantasai: We need a way to answer the question "is this implemented"
florian: The base pseudo-class would mean "is it present AND
implemented"
florian: pseudo-classes are simpler
<fremy> +1 to the pseudo-class suggested by florian
<tantek> +1 to considering pseudo-class
fantasai: For style vs content vs behavior, this belongs more in CSS
than HTML. But emilio and florian gave good arguments for
why it might have to end up in HTML regardless.
fantasai: If we add appearance: value, I would go for appearance:
basic
<tantek> in general I'm opposed to any extension to the 'appearance'
property, but that's a lower level concern
<heycam> `input[type=checkbox]:custom`
Rossen: Most of the conversation leans toward attribute.
gregwhitworth, does that work?
gregwhitworth: I want a resolution, as ammunition for going to WHATWG
gregwhitworth: Also for adding styles to checkbox. I'm looking for a
resolution.
florian: 2 resolutions: 1. to use an attribute, and 2. to add a
pseudo-class
fantasai: proposed resolution: This functionality be pursued as an
attribute, and CSS adds a mechanism to detect an element
in this mode in a browser that has support for it
gregwhitworth: I'm fine working on that BTW
<fantasai> "CSS Working Group recommends that"
bkardell: Wouldn't existing "define" work?
bkardell: The "define" pseudo-class
bkardell: should work
bkardell: I guess not, because it's already defined. Never mind
emilio: It almost works, because you can't extend form controls. But
maybe you can. If you can, then it doesn't work
gregwhitworth: I don't want to go down that rabbit hole
emilio: It seems cleaner to use a different thing
Proposed resolution: This functionality be pursued as an attribute
instead of a CSS property, and CSS adds a mechanism to detect an
element in this mode in a browser that has support for it
<bkardell> it would already be true, is the real problem I think
florian: I support the resolution as it stands. But I would also
support a more specific resolution: the mechanism is a
pseudo-class. @supports would be awkward. Pseudo-class
would make it easy. If we do a pseudo-class, we have to
figure out which element you're testing against. Would look
like a selector
fantasai: Yeah, this is element-by-element
florian: It's also applied element-by-element
fantasai: yeah.
fantasai: I guess that what it's going to have to be. I can't think
of a name that makes sense
florian: We should match the name that HTML sues
bkardell: Can it be 0 specificity?
gregwhitworth: Can we figure this out after I open the issue?
bkardell: Yes.
fantasai: I support gregwhitworth investigating whether or not it
should be 0 specificity
Rossen: We were leaning toward using an attribute. Second
resolution: Adding a mechanism to detect the state of the
feature. Is this right?
RESOLVED: This feature should be solved with an attribute rather
than a CSS value
<fantasai> [I would like to note that it's not great that, in order
to change the styling of the form element, it's necessary to
change the markup. But it seems we're constrained by practical
considerations.]
ACTION gregwhitworth: Create an issue about adding a mechanism in
CSS to determine if this feature is enabled
Overflow
========
viewport propagation of scrollbar-gutter
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6079
chrishtr: When you apply properties on the HTML or body elements,
under certain conditions, it gets propagated to the root
element's scroller. Does this apply to scrollbar gutter
properties? Proposed: yes.
Rossen: This is reverse propagation thing for overflow and direction
fantasai: Overflow doesn't inherit so it's less bad
fantasai: I absolutely hate body propagation rules in CSS. They
should die. But the web depends on them. I don't want it
to propagated from the body to the viewport.
fantasai: But we do need to specify that it propagates from the root
to viewport.
<tantek> +1 fantasai
emilio: Right. The scroll-snap stuff, and the thing that allows you
to do smooth scrolling, those don't propagate.
chrishtr: If the user puts overflow on the body, and <missed> then
they're just out of luck?
florian: They should put it on the root instead.
florian: Putting things on HTML instead of body causes no problem.
It's confusing if you've put it on body and it works, but
you want to put other stuff on body but it doesn't work
<tantek> +1 florian, can we deprecate putting it on body so it's
still "supported" but warned in CSS validators?
Rossen: Let's go back to the actual issue here
Rossen: There's a proposal here about scrollbar-gutter.
Rossen: For better or worse, we have behavior today that does the
propagation
Rossen: Can we make that work for scrollbar-gutter as well
florian: There are 2 potential resolutions. The first is required.
Propagate from the root to the viewport is required.
Whether or not we ALSO propagate from the body is
controversial
<tantek> +1
fantasai: Let's resolve that we propagate from root to viewport
first.
Rossen: Any objections?
RESOLVED: We propagate scrollbar-gutter from the root to the viewport
Rossen: Now what about body?
Rossen: It still works everywhere. I think our mutual feelings are
the same.
fantasai: We're not saying that it should stop working on overflow.
We're saying we shouldn't add more properties to that list
emilio: There was a huge discussion years ago in gecko and other
browsers. Gecko only propagates overflow and .....
florian: Overflow, background, and principal writing mode (i.e.
writing-mode and direction) writing mode
emilio: Browsers do different things. Fancy new properties don't
propagate. Let's leave it as it is. Not propagate from body
to root.
<tantek> +1 emilio
emilio: A lot of other properties don't either
iank_: Overscroll behavior does.
emilio: Scroll snap does
emilio: Those only work on the root
<tantek> can we instead introduce an informative WARNING about
depending on <body> propagation? (i.e. that devtools could
flag for example)
<fantasai> tantek, I'm happy to warn about it for the properties
which currently do propagate (overflow/background/
direction/writing-mode). But I *do not* want to add more
properties to that list.
<tantek> fantasai, 100%
emilio: If UAs want to add a warning, if you detect you have a body
that's not scrollable and it has scroll properties, they can
log them to the console, that would be helpful, but let's
not add more propagation
Rossen: It's less worse to put your custom scroll bar ... is to not
have the appropriate space for it, so you're risking to have
some broken UI experience in this case
florian: If you apply a property and it doesn't do what you want
then you fix your code
heycam: I was going to ask what the specific list of scrollbar
related properties is that currently propagates from body to
the viewport. I don't want to end up in a situation where
some scrollbar related things propagate but others don't. If
scroll snapping and scrollbar color and scrollbar width
don't propagate, then that's good
chrishtr: I'm okay with the not body thing.
chrishtr: That shortens the conversation
Rossen: I'm okay with this.
Rossen: Anyone else want to keep it?
Rossen: Objections?
RESOLVED: Scrollbar-gutter does not propagate from <body>
<tantek> can we generalize that to any future scroll-*?
fantasai: Tantek is asking "can we generalize ..."
<tantek> yes please fantasai
fantasai: The proposed resolution is "don't propagate anything else
ever from BODY to viewport"
chrishtr: Do we need a resolution for scrollbar-width and one other?
emilio: Those already don't propagate
Rossen: I think that was the generalized proposed resolution that
fantasai said
Rossen: "Anything outside of overflow, direction, and background
should not propagate from body"
florian: In addition, we need to propagate some things from HTML to
the viewport
florian: Otherwise you can't change the scrollbar width
Rossen: I'm talking about <body>
florian: We should open a new issue about which things need to be
propagated from :root and are missing
fantasai: Proposed resolution: no future properties will propagate
from <body> to the ICB
<tantek> +1
chrishtr: I'll open a new issue about scrollbar-width on the HTML
element
Rossen: No new objections
<fantasai> chrishtr, the spec already defines this
<fantasai> chrishtr, see
https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width
<fantasai> chrishtr, no need to open an issue...
<chrishtr> fantasai, great!
RESOLVED: No future properties should propagate from <body> to the
ICB or viewport
<tantek> even current properties that don't say they propagate too
right?
fantasai: Tantek said something in IRC
tantek: proposal: deprecate, or add a warning, to any existing use
of body propagation. This would enable CSS validators and
dev tools to warn and flag when they depend on that behavior
emilio: I don't feel strongly. but sure.
emilio: Dev tools can warn for whatever without anything in the spec
emilio: We warn for stuff that doesn't apply. Saying "this is bad
and you should feel bad" is not good
fantasai: I'm fine with deprecating and making that a statement so
it can make its way to author-facing materials
fantasai: Deprecating settings values on <body> with the expectation
it propagates up to root
florian: Making it officially bad. "please don't do this"
RESOLVED: Deprecate any existing use of body propagation
CSS Fonts
=========
scribe: fantasai
Clarify font-optical-sizing behaviour under size-adjust
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6190
chrishtr: Question of size-adjust interaction with
font-optical-sizing
chrishtr: The proposed resolution is to use font-optical-sizing of
the used font size
myles: Of course
RESOLVED: font-optical-sizing: auto references the used font-size,
accounting for 'size-adjust' and 'font-size-adjust'
CSS Display
===========
Should <display-legacy> values be aliased at parse time?
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5575
[There isn't time left on the call to discuss]
<astearns> fantasai: add a comment with your proposed resolution
<fantasai> proposed resolution: resolve at computed value time, not
at parse time, so that specified value is how you
specified it
Received on Monday, 24 May 2021 22:58:22 UTC