- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Apr 2022 18:42:51 -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 UI 4
--------
- Pull request #6537 (Define how to compute the kind of widget to use
for an element) will be merged next week unless there are edits
to it before then.
CSS Pseudo
----------
- RESOLVED: Highlight pseudos continue to inherit the text-decor
properties, but do not propagate decorations the normal
document. (Issue #6829: highlights and decoration
propagation)
CSS Cascade 5
-------------
- RESOLVED: Add .layerName to CSSStyleSheet as a readonly attribute.
(Issue #7002: Add a .layer attribute to CSSStyleSheet)
CSS Text
--------
- RESOLVED: ‘word-spacing' takes a number value. (Issue #3232: Syntax
for percentage-of-width-of-space for 'word-spacing')
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Apr/0002.html
Present:
Tab Atkins Bittner
Delan Azabani
David Baron
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Jonathan Kew
Ian Kilpatrick
Vladimir Levin
Chris Lilley
Peter Linss
Alison Maher
Eric Meyer
Morgan Reschenberg
Florian Rivoal
Jen Simmons
Alan Stearns
Miriam Suzanne
Regrets:
Rachel Andrew
Lea Verou
Scribe: TabAtkins
CSS UI 4
========
Define how to compute the kind of widget to use for an element
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/6537#issuecomment-1083049538
florian: We discussed this last time, and I think we agreed that
doing an editorial refactor was desirable
florian: But the convo, largely by my fault, fell by the wayside and
hasn't made progress
florian: So request is to merge now because I have no substantive
disagreements, and track the editorial refactor separately.
florian: Seems reasonable, only hesitation is the changes to address
the editorial bit have to land in both HTML and CSS, and it
seems easier to get them done before.
florian: So if considered reasonable I'd like to have one week to try
and finish the changes, but if that's too much I yield
astearns: otoh, we could just merge this, have you do the check, and
if there's something you want addressed before HTML picks
up the change you have a week to pick that up
florian: HTML is waiting for us, so once we merge they'll probably
merge
astearns: Fair. Anyone prefer merging now rather than waiting one
more week?
[silence]
astearns: Okay, you have a deadline.
CSS Pseudo
==========
highlights and decoration propagation
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6829
delan: Some background, text-decorations have this thing called
decoration propagation
delan: which is normally how descendants ensure they're also decorated
delan: The text-decoration props aren't inherited normally, they use
this propagation instead
delan: However, with highlight pseudos, we've saying all properties
are inherited, even if they're not normally defined to inherit
delan: So how do these two things interact? Do we still have decor
propagation anyway?
delan: If we do, it seems like you'd get a second underline, which
might not be desirable
delan: on the other hand, if we say no, then we'll be relying on
inheritance to ensure children are decorated, which also has
negative side effects
delan: So: do decorations propagate into highlight pseudos?
fantasai: I think when decorations propagate it's from one element to
another, and for highlight pseudos, each piece of a
highlight pseudo is applying decorations on its own
fantasai: so I think they don't propagate if they're set above the
highlight pseudo
fantasai: say you have a <p> with an <em>
fantasai: If you decor the <p> if propagates to the <em>
fantasai: If you highlight across it, there'll be two pieces, inside
and outside the em
fantasai: each one will have an underline decl, you don't want it to
be twice. you don't want to propagate since each piece
takes care of the underline itself
fantasai: I think that's what happens, but might give different
results.
<iank> what is the interaction when highlights come across an inline
which is a stacking-context?
fantasai: Propagation and inheritance can give different thickness
fantasai: but we probably want it to look like a normal underline, so
we *do* want it to propagate...
delan: For example, a <sup> insdie the <p>. Normally there's a single
underline that doesn't jump up. (Blink does jump up, but we do
it wrong.)
delan: We don't actually do the decorating box, we do an inheritance
hack.
fantasai: I think what you want is to render as if it's propagated,
but the existence of the underline is based on inheritance,
but then......
fantasai: Dunno if this makes sense. Inherits like every other
property, but instead of each part drawing its own, they
look up to see if they would propagate from their parent.
fantasai: I think that would get us the results we want.
florian: I agree in general. I wonder if it's that bad in the case of
highlight pseudos if we do jump up and down.
florian: In a whole paragraph with some <sup> you do want something
continuous and homogeneous.
florian: But in highlights it might depend on how you get there. If
you highlight the whole para, yeah you might want it to be
the same. But if you start within the sup, maybe you do want
it to be up. And as you drag out to the normal text, maybe
the whole highlight moves down, or just the part in the
normal text.
florian: it's not hierarchical.
florian: So if we don't fix the inconsistency for highlights, maybe
that's fine, unlike in the normal case.
delan: If we rely on inheritance, wouldn't we...
delan: Now that I think about it, I'm not sure that saying there's
not propagation is really all that feasible.
delan: Because the parent will draw its decoration, and there will
have to be additional work done to ensure that it stops
painting its decor when there's a child. that would still
require changes to impls.
astearns: Ian had a question about if there's anything interesting in
the interaction with stacking contexts?
iank: If you've got an inline which is self-painting, a stacking
context, is there any interesting interaction there?
delan: It sounds like if we relied on inheritance to "propagate",
then that would cause problems.
delan: Is how it's supposed to work normally that when you have a
stacking context propagation doesn't happen?
iank: Unsure, is why I was asking.
iank: Is it possible to have inlines that paint independently from
the rest of the inline content, and if there are implications.
iank: Fine if we don't have an answer.
fantasai: When you're doing highlighting normally, if you're
highlighting the paragraph and there's an inline-block
inside, I don't think you highlight the inline-block, you
just skip it or run the line across it, depending. (all the
"highlight"s mean underlines)
fantasai: So maybe it just makes sense to use the inheritance model
even if it doesn't work as well for superscripts
fantasai: because in the case of highlights, we'd want to go into the
inline block to indicate what's highlighted
<iank> specifically thinking about inlines which are self painting,
e.g. <div>text <span style="position: relative; z-index: 2;
opacity: 0.5; background: lime;">self<br>painting</span>
florian: One thing I wanted to ask - is the worry you have actually
going to pan out like this?
florian: Unlike the normal text-decor we're not applying to the whole
paragraph.
florian: If we highlight from the start of the paragraph, thru a
superscript, to the end of the paragraph, we actually have
three highlight pseudos, right?
florian: You're not highlighting the parent "behind" the superscript,
you're highlighting three adjacent chunks
delan: That's how we do it in Blink, we paint chunks.
delan: Not sure if that's correct.
iank: at the IFC level we have a data structure that determines where
to paint decorations for the whole IFC
iank: We can chat offline about this.
astearns: So what I heard was, there is a reason for text-decors in
highlights to render differently than in normal elements
astearns: At first I thought the answer was no, but the scenario
about starting a highlight in a superscript and then
dragging out of it, means the highlight decorations change
as you drag. I think that's wrong, they should be stable as
you do the highlight gesture.
astearns: So that suggests to me we should only be using inheritance,
no propagation.
<fantasai> astearns++
delan: Not sure I follow, that's not a problem outside of highlight
land
astearns: Outside of highlights you have the decor set on an element,
and it propagates to the children, and there's a stable
rendering of that
astearns: In the highlighting gesture you can get an unstable
decoration state if you're using propagation painting rules
delan: Agree that's not desirable. What if we went the other way and
said they do have propagation, but the decoration properties
aren't inherited?
delan: Everything else continues inheriting, so things like
background-color works. But not text-decor props. Would that
work?
astearns: I think that might still have problems. Say I start a
highlight within a superscript. How do you assess the
propagation rules? You don't know how far up the parent
chain to go, so you just propagate from the sup. Now you
drag it out, you've got a shared parent, the propagation
changes?
delan: I think we could use the same rules as for originating
elements.
delan: Whether you've highlighted something determines whether we
actually paint the decor there.
delan: But we actually figure it out as if highlighted
florian: Abspos example - if you highlight something that's been
absposed elsewhere.
florian: Classically, when you underline a paragraph, the abspos
child doesn't get underlined.
florian: Here if you start the selection in the abspos you want to
see the highlight styles in the abspos, and if you drag into
the paragraph text you don't want it to suddenly change.
florian: In general we're just not highlighting one span of text,
we're highlighting lots of bits.
delan: That makes sense
astearns: So I think we can get a resolution to have text-decor
properties in highlight pseudos inherit only, not propagate
any decorations?
delan: Sounds good.
RESOLVED: Highlight pseudos continue to inherit the text-decor
properties, but do not propagate decorations the normal
document.
CSS Cascade 5
=============
Add a .layer attribute to CSSStyleSheet
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7002
fantasai: So it just seemed reasonable to add, and discussion
suggests it should be called .layerName to match the
CSSLayerRule
astearns: And using .layerName is preferable to switching both to
.layer?
fantasai: I'm open to both.
* smfr prefer layerName
astearns: I think .layerName does suggest a string rather than an
object, so it seems slightly more clear
emilio: Does @import allow us to set this on import, so we can make
it immutable?
TabAtkins: If this stylesheet is reflecting from a <link>, that's
changeable in HTML
TabAtkins: Maybe we could make it immutable in the API?
emilio: Link mutations already have steps to recreate the stylesheet
object
emilio: So that would trigger the same as changing media=''
emilio: Which creates a new stylesheet
TabAtkins: What about constructed stylesheets?
emilio: Hopefully we can set it in the constructor - it already has
an option bag for things like baseURI, which also is
immutable. Hopefully we can follow the same pattern.
TabAtkins: I'm fine with that.
emilio: The original issue uses @import syntax, which requires using
an extra argument object somewhere to preserve the mime
type...
TabAtkins: Don't understand
emilio: When you use `import sheet from style.css`, can you set the
layer there?
emilio: I think in JS you have a trailing object that lets you set
the mimetype?
TabAtkins: Yes, but I'm unsure whether that's meant to be just
assertions or can have extra data
astearns: Sounds like we can resolve on .layerName?
TabAtkins: And on making it readonly unless that's killer for the JS
import syntax
emilio: Agreed
astearns: objections?
RESOLVED: Add .layerName to CSSStyleSheet as a readonly attribute.
CSS Text
========
scribe: emeyer
Syntax for percentage-of-width-of-space for 'word-spacing'
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3232
<fantasai> https://github.com/w3c/csswg-drafts/issues/3232#issuecomment-1040836766
fantasai: We've been wanting to represent percentage spacing in
word-spacing as a percentage of the character's advance
width.
<TabAtkins> we want the ability to say "words should be separated by
two spaces worth of whitespace", for example
fantasai: We're already using percentages against font size.
fantasai: we already have a meaning for all the lengths, and em for
percentages. Still want “increase width of this word
separator character by X%”.
fantasai: Space is the most common word separator, but there are
others with different advance widths.
fantasai: We want to represent a multiplier, not a percentage or
length.
fantasai: I think we have some number of options. One: use a number.
Cons: you can't combine numbers and lengths in calc()s.
fantasai: Two: Use a different unit, like ‘fr'. We could mint a new
unit, either a generic one or one specific to this property.
fantasai: Three: We could mint a new function.
TabAtkins: The fact that this can have different effects on
per-character basis makes it more strongly not a length.
My objections in the issue are largely irrelevant; fine
with it being a number.
astearns: It's a unit that inherits as itself.
florian: Do we expect people to actually calc() this sort of thing?
fantasai: I don't know.
TabAtkins: In the general case, no, but it might be sense to double
ASCII space a tweak it. I don't think so, but…?
dbaron: This is a sort of general problem that we should find a
decent solution for that isn't a horrible hack. We keep
running into situations where we want a value that's relative
to something computed for inheritance purposes. Maybe we need
to actually figure out a more permanent solution for this.
fantasai: We have percentages usually, but we're already using them
here.
dbaron: Part of what I mean is that for lengths, we have different
units. We might want different relative units. Maybe ‘fr' was
going down the right path. We should have a solution we can
re-use multiple times.
fantasai: If the ‘x' unit was available, that might be nice.
florian: If you know of the fr unit, it does the job fine, but
discovering is a mess.
astearns: I agree this is a problem that crops up in several places
and we have one relief valve, where we use a number and set
that number to have a special relationship.
fantasai: Two relief valves: percentages and numbers. The problem
with numbers is you can't combine with calc().
florian: We don't need a unit system for percentages, we only ever
need two at most.
fantasai: Maybe we need a generic “this is a number” unit for calc()
florian: I think dbaron said this is a problem in a number of places.
What number of places? If it's a few, maybe that's okay. If
it's a lot, maybe ‘fr' is the way to go because that's
learnable.
fantasai: border-image uses both, I think.
<astearns> percentage(150%, font-size)
dbaron: I think there are a bunch of cases where percentage confuses
people because they don't always know what it means.
dbaron: ... sometimes % of height, % of width, % of font-size
<fantasai> also line-height, but that was a terrible mistake imho
<iank> (even on single properties percentages can resolve to
different things depending on the context, e.g. top :P )
<TabAtkins> 5%(em)
<fantasai> https://www.w3.org/TR/css-backgrounds/#border-image-width
florian: I retract my earlier comment about two types of percentages,
we do have more.
astearns: Spelling out percentages in functional form would be easier
than some abbreviation.
florian: Maybe you could do “%(height) + 2%(width)” in some way.
iank: We want to be very careful if we're introducing percentages
that can resolve against specific things. Cyclic dependencies
are a risk.
<TabAtkins> %(foo) is just a new unit, it's not currently allowed by
Syntax
<iank> I see.
<TabAtkins> 5foo% vs 5%(foo) vs just 5foop
astearns: We could restrict where those identifiers could be used to
avoid cycles.
fantasai: That feels excessively complicated for what we're dealing
with here.
dbaron: Maybe we should make more things like ‘fr' rather than
re-using it all the time. Doing that seems the least horrible.
astearns: We could resolve to use a unit, but we lack consensus on
what that should be named.
fantasai: I think either a new unit, or just use numbers.
iank: new unit that's only valid for word-spacing?
fantasai: yes, or maybe also tab-size
fantasai: It would be nice if there was syntactic compatibility.
<aja> 1) would % of 'ch' unit be appropriate? 2) consistency with
letter-spacing would be a plus for authors.
<fantasai> 1) no, because it resolves to an absolute length 2) no use
case, but could in theory (generally people don't want
inconsistent tracking)
<dbaron> Also, vh, vw, etc., etc., are very %-like (but the user
can't tell which way they inherit).
florian: Bikeshedding aside, that sounds reasonable unless dbaron is
right and we'll need a whole bunch of new units that are
conceptually similar.
florian: If we think we need a bunch, we do that but try to come up
with a scheme that lets us group these.
astearns: I'm not hearing moving toward resolution aside from not
being interested in making a length.
fantasai: I propose we use a number for now. If we come up with a
good unit we want later, we could make this and ‘tab-size'
accept it.
astearns: Anyone with concerns with resolving that ‘word-spacing'
takes a number and punting on general solution until a
later date?
<dbaron> I'm not objecting, but it does feel like just postponing the
problem...
RESOLVED (for now): ‘word-spacing' takes a number value
Received on Wednesday, 13 April 2022 22:43:31 UTC