- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 10 Sep 2023 11:49:56 -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 Transforms
--------------
- The WG discussed adding longhands for the translate -x -y -z,
rotate -angle -axis, scale -x -y -z properties, and was in favor
theoretically, but since these would add complexity to
a performance-sensitive feature and the use cases presented so far
were not very strong, the WG resolved not to add them (for now).
(Issue #7646: Syntax of individual transforms should reflect
general CSS syntax)
CSS Text
--------
- RESOLVED: Accept proposal (Issue #8972: Reconsider atomic inlines
overriding GL/WJ classes)
- RESOLVED: Add a control that is either a property or a value that
causes UAs to make the last line longer than it would've
originally done unless that was a bad idea (Issue #3473:
Preventing too-short final lines of blocks (Last Line
Minimum Length))
CSS Syntax
----------
- RESOLVED: Accept parsing behavior change as described in issue
(Issue #8834: Review requested of new Parsing text)
- RESOLVED: Republish CSS Syntax as CRD
Overflow & Contain
------------------
- The issue in #9003 (Setting containment on root should not make
scrolling impossible) does need to be addressed, but the group
needs to think more about expected behaviors before resolving.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/38
Scribe: florian
CSS Transforms
==============
Syntax of individual transforms should reflect general CSS syntax
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7646
bramus: Individual transforms property now exist, and help author
with control over their animations
bramus: Now people want more granularity, like translate-x, -y, etc
TabAtkins: I'm fine with that
TabAtkins: The other part was the logical transforms
(translate-inline, etc)
TabAtkins: that I'm against, because we don't have logical
transforms, and thus nothing to map them too cleanly
bramus: that's ok
fantasai: Do we want to just add those?
TabAtkins: Not part of this issue
SebastianZ: How about scale-x, scale-y, and the same for rotate
TabAtkins: They were deliberately omitted from the transform
properties, because there's no obvious correct order
TabAtkins: Sorry, skew was omitted
flackr: Does rotate have a long hand?
TabAtkins: You'd have rotate-axis and rotate-angle
flackr: When you create an animation with these now separate props,
it might be surprising to authors:
flackr: if they set translate-x in the first and last keyframe, and
-y in the middle, they'd only get the transition on the -
TabAtkins: That seems fine
fantasai: If you want the other behavior, then just put the necessary
properties in the relevant keyframes
flackr: Seems fine, never mind
bramus: The current standalone properties have enabled that, so it
would be the same
TabAtkins: Animating on the separate properties and the joint ones
give different results
astearns: Proposal: translate, rotate and scale have long hands
TabAtkins: translate -x and -y, rotate -angle -axis, scale -x -y -z
<TabAtkins> (and translate-z)
flackr: Is it well defined how we interpolate from one rotation angle
to another?
TabAtkins: I forget what the answer is, but yes, it's in the spec
SebastianZ: Why rotate-angle and rotate-axis when we have rotate-x,
rotate-y and rotate-z as functions
TabAtkins: There are multiple results depending on the order when you
combine them, so it'd be ambiguous
TabAtkins: So if you do want to do independent rotations, use
'transform'
RESOLVED: Add the longhands to these properties as discussed above
fantasai: Should we take up this comment as its own issue
https://github.com/w3c/csswg-drafts/issues/7646#issuecomment-1545399874
which is filed at https://github.com/w3c/csswg-drafts/issues/1544
already
dbaron: I'm not sure…
dbaron: I am concerned about the complexity this adds. Need to think
about it.
astearns: How about you comment on the issue after reviewing that
fantasai: Wanted to comment the logical part of this problem
astearns: It is a separate issue, and the agenda is already too
crowded so no
CSS Text
========
Reconsider atomic inlines overriding GL/WJ classes
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8972
fantasai: We have a problem that line breaking around images is weird
fantasai: Web pages expect images to introduce a line breaking
opportunity
[fantasai summarizes the issue]
fantasai: The proposal is that for Unicode characters with non
tailorable line breaking properties, other than NBSP,
should be honored and take precedence
florian: +1
iank: Not too familiar with the implementation details, will sync
with Koji before a definite answer
iank: seems ok
fantasai: Main concern is probably not implementation complexity, but
web compat, but it seems ok here
iank: Is there any complexity with reordering controls
fantasai: There's only a handful of characters
fantasai: should not have any effect on bidi
iank: Seems fine, just want to check with Koji
Rossen: can we resolve on it, and you bring it back if there's
an issue
hober: Similar to Ian, I want to talk internally, like with the books
people
hober: can bring it back later if we have additional feedback
RESOLVED: Accept proposal
CSS Transforms
==============
Syntax of individual transforms should reflect general CSS syntax
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7646
dbaron: I don't see a whole lot in terms of usecases
dbaron: It seems we want to do this for completeness and consistency
dbaron: but the cost seems high
dbaron: because you need to support animating them on separate
timelines
dbaron: not theoretically hard, but adds complexity to a performance
sensitive path
dbaron: would be ok given strong use cases, but otherwise, the cost
might be too much
TabAtkins: We'd go from 3 properties to 7
hober: I share dbaron's concern, but would defer to Simon if he has
an opinion
dbaron: Not absolutely opposed to doing this, but want a stronger
justification than has been given so far, given the cost
bramus: I remember requests, but not what the motivating use case was.
Rossen: The proposal is to revert the previous resolution
RESOLVED: Undo previous resolution, do not add the longhands to the
rotate, translate, and scale properties
CSS Syntax
==========
scribe: fantasai
scribe's scribe: emilio
Review requested of new Parsing text
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8834
TabAtkins: As part of refactoring for nesting, I realized that there
is some common structures we could use to make more sense
TabAtkins: This results into 1 non-editorial change
TabAtkins: Rules that previously only contained rules, like @media,
previously used an algorithm that only cared about rules,
not declarations
TabAtkins: now that they do care about declarations, at least in
nested form -- ideally top-level form parses the same way
-- and that causes an error-recovery change
TabAtkins: specifically ...
<TabAtkins> @media { garbage; bar {...} }
TabAtkins: this ^ previously would have resulted in a single rule,
"garbage; bar { ... }"
TabAtkins: now it results in two statements, a "garbage;" statement
and a "bar { ... }" statement
TabAtkins: only affects when there's a semicolon
TabAtkins: but changes parsing on existing stylesheets
TabAtkins: Question is if that's OK
florian: So you say previously we wouldn't discard "garbage;" and
keep "bar { ... }"
florian: that seems better, but is it Web-compatible?
TabAtkins: Suspect so, since only small cases
florian: Doesn't seem unlikely people will put in a media query and
forgot selector and then add full rules with a selector
later, and the garbage which used to gobble up next rule and
thereby disabled it
florian: no longer disables it
florian: seems plausible that it could be written by accident
florian: Let's try, but it would be possible it causes problems
emilio: Fact that nested and unnested parse differently seems super
weird, so +1 to try fixing this
emilio: I *think* that's how I implemented in Firefox, but might have
been conservative when implementing, don't remember
Rossen: Hearing support, any reasons to not resolve?
RESOLVED: Accept parsing behavior change as described in issue
TabAtkins: Can I republish Syntax?
TabAtkins: All the changes should be captured in Changes list; will
double-check before publishing
TabAtkins: still need to do review of tests that might need changing,
but that's separate
Rossen: Any objections to new CR?
RESOLVED: Republish CSS Syntax as CRD
Overflow & Contain
==================
Setting containment on root should not make scrolling impossible
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9003
miriam: Decided with container queries not to have container on root
miriam: but said authors should be able to set root as container, and
be able to query it similar to media queries with some
advantages of it being an element
miriam: but it doesn't quite work
miriam: because if you set size/layout containment on root element
miriam: the overflow property propagates to the viewport, but size/
layout containment causes the root to not have any scrollable
overflow
miriam: So we need to either say, when you set containment on root,
the overflow property doesn't propagate to root and get
scrollbars
miriam: or we propagate containment to the viewport
miriam: Not sure if that means anything other than "it doesn't apply
to the root"
florian: I believe the first one has a well-defined behavior that's
useful
florian: One thing that makes it ok is that when we no longer
propagate to viewport, the the viewport gets default value
of 'overflow' which resolves to auto on the viewport
florian: therefore if the root itself would overflow the viewport,
you get scrollbars to see all of it. It might be odd, but
you can access all the content
fantasai: I think that having the containment and overflow apply to
the root element would be pretty terrible
fantasai: because if you do size/layout containment you get 0-height
and no overflow
fantasai: if you also have paint containment you also clip
fantasai: if you compensate by making the root element larger
fantasai: then you have a scrollbar which is inside the border edge
of the root element rather than attached to the viewport
fantasai: which is also not great
fantasai: I think the first option is terrible and we should
propagate containment to the viewport
miriam: You would likely uses 100% rather than 100 vh
miriam: but it's only minimally better
miriam: I agree that the other is nicer for authors
Rossen: Would that be compatible? then percentages on body would
resolve (which wouldn't previously)
iank: Containment on root is probably pretty rare in the web
iank: remind me the syntax?
emilio: What's the difference between propagating containment to the
viewport rather than just not applying containment to the
root?
miriam: It establishes a container for querying.
miriam: @container [...]
emilio: so the size of the root...
emilio: what you want isn't the root element box size, it's the
viewport?
miriam: I was assuming you'd get the root size, but in general what
the author would do is size the root to 100% so they can get
the viewport size
miriam: The difference between that and media query is that you can
use actual font sizes (for font units)
miriam: other than that you want a container that's a fallback for
everything for the page
emilio: Isn't the fallback already the root?
miriam: No, there is no default
miriam: We intentionally didn't, because there are cases where it
would be surprising if you didn't expect it
florian: So, size containment doesn't mean size to zero. It means
size as empty
florian: Most typically case is querying width, so empty isn't zero
florian: it would work better than viewport, because if there are
margins etc, then you are considering those
florian: in the block axis, yes, you would size the root to zero
florian: but is it that bad?
florian: I'm not sure the scenario is that bad as imagined
emilio: Fallback is for container units but not container queries?
emilio: that's a bit weird
miriam: Yes
emilio: Ignoring containment on root to make this work seems sketchy
emilio: I am a bit torn
dbaron: I'm struggling at this point to understand the ways in which
ignoring containment on the root and propagating to the
viewport different
dbaron: (other than for container establishing effects)
dbaron: though I guess they differ because of the size of the root,
but unsure what that means for effect on developers
emilio: Is alternative to this to provide an opt-in to fall back to
viewport somehow?
emilio: If we didn't do the fallback because we think it's
confusing.. then what makes it not confusing would be having
an opt in
iank: It's confusing if you're writing these rules and you don't
expect it to resolve yet because you haven't specified a
container, and then it suddenly resolves
miriam: If you're mainly using CQ on small things, and end up not
being in a small thing and get a very large result
miriam: can be confusing
miriam: but in other cases want the nearest container, and in that
case want the fallback
miriam: if you added containment on root, you can add a name so that
you can reference it
miriam: if you're in control you can handle both use cases, if not
can only handle one
[fantasai gets tapped to speak]
fantasai: Don't know what to say
florian: Put you on the queue about the scenario you were concerned
about
florian: not sure what happens
fantasai: Containment works in both axes right?
florian: Not necessarily, if you only do it on one axis doesn't
collapse to zero
florian: in the block direction if you set it to a 100% shouldn't it
be fine
florian: If we propagated neither overflow nor containment, shouldn't
it work?
florian: You'd set the block size to 100%
fantasai: If the content needs to scroll you wouldn't be using the
viewport scroller but an internal scroller
fantasai: Is it the same?
emilio: It's not the same. There are UA features that only work on
the root scroller, like marking find-inpage things, etc.
smfr: Another difference is background-attachment fixed is optimized
for root scrolling
Rossen: Let's take the issue back to GH and talk about it there, once
we have a path for resolution we can bring it back
<miriam> hopefully we can get some good conversation and a resolution
soon - because the longer we wait, the more likely we
develop compat issues
CSS Text
========
Preventing too-short final lines of blocks (Last Line Minimum Length)
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3473
myles: This is a small issue ....
myles: We have had many requests throughout the years where
typographers and designers have come to us and show us a
paragraph on the web page
myles: they'll point to last line and say, 'this last line is tooooo
narrow'
myles: This has a name, it's called orphans and widows
myles: also term has two meanings
myles: CSS has support for the other meaning (pagination)
myles: but for this one, doesn't
myles: This is one of our highest requested text-related features
myles: so it would be cool if CSS could solve
myles: Problem here is that last line is too narrow, so get wide
paragraph and maybe one word on last line. Looks bad
myles: More nuance, but what I will say is, I think there's two
potential solutions
myles: one is a new property, and one is a change to value space of
`text-wrap: pretty`
myles: so could invent a new property or add a thing that when you do
pretty, try to focus on the last line
florian: text-wrap: pretty solves this and more, and is expensive
florian: and that's important
florian: If it wasn't expensive, just using pretty would be fine
florian: there are terrible solutions to this problem
florian: If you implement one that is "good enough"
florian: is there enough perf difference with pretty that it's worth
a separate control
hober: Very significant perf difference
myles: Naive implementation of pretty is exponentially bad perf
myles: whereas an algorithm that just focuses on this problem would
be at worst linear, but almost constant time
iank: Yes, expensive, but we might have different perspectives on how
expensive we're willing to tolerate for pretty
iank: lot of nuance there, let's not get into it now
iank: From our perspective, if there is a control, it would be nice
if it could also control pretty
iank: fundamentally, pretty does have a lot of knobs like "how much
to bias for x consideration"
myles: If independent control for last line and pretty, browser could
see and modify pretty to focus on last line
iank: Potentially
myles: That sounds great
nicole: I wanted to ask, how many lines would be impacted by that
myles: I think we're flexible here, not super clear what the spec
should say
myles: if we were to implement this, first version would start at 1
line and then iterate from there and see if need to increase
<astearns> -1 to only stealing words from one line
nicole: Similar to headline balancing?
iank: Not really
hober: Taking a first pass would only use one line, but I can imagine
empirically discovering that we can tolerate 3-4 and might
have a spec, but let's not prematurely decide
florian: Are you aiming for a yes/no property or are you thinking of
giving author control like at least 3em or at least 30%
myles: Flexible
myles: Firstly, we know using words is wrong
myles: not clear, in i18n context, what exactly a word is
myles: from implementation perspective, can make a boolean
myles: If authors need more control, can add
myles: When authors request this, they usually request a percentage
myles: e.g. at least 50%
iank: Is that what they actually want, or think that's the tool that
indesign provides...
myles: I don't know, but my proposal is a boolean switch
myles: and as implementations progress, we can see if that makes
sense or not
smfr: Should we just resolve on adding a property without specifying
if boolean or not?
astearns: For a property that does only this one thing
astearns: I would advocate strongly for just a boolean switch
astearns: Anything more finely grained is really going to have to be
weighed against other line-breaking considerations
astearns: and needs to modify results of pretty
astearns: If we're separating the two, then the simple thing, should
just be a boolean
florian: I think I support this because of the perf difference
florian: but even then it does feel like it's a variant of pretty,
you've decided what you care about
florian: so is it really separate from pretty?
* fremy wanted to say the same thing
fantasai: There are a lot of knobs that factor into pretty and a lot
of them are already separate knobs
fantasai: In level 4 or some other we had word-spacing and
letter-spacing give you the optimal value but we also allow
a range for the line-breaker to play with
fantasai: that's a factor into the line breaker
fantasai: same for hyphenation controls
fantasai: these are already split out into multiple controls
fantasai: Turning on pretty shouldn't need to re-declare your controls
fantasai: so should cascade separately
fantasai: I agree with myles, we should have this tweak
<florian> [Florian is convinced]
fantasai: I'd like something that can be applied to the single-page
HTML spec and not spin for 10 minutes
fantasai: I also agree with astearns that you have to look at more
than one line
fantasai: A boolean switch is fine but we should define this thinking
of extending it to percentages too
fantasai: If we spec it out we need to pick a name that's gonna work
for both
<myles> sooooo `minimum-last-line-length: normal | auto [maybe more
in the future]`
fremy: I have a similar thought, that just looking at one line
doesn't cut it
fremy: you will end up with a triangle. If you have only two lines
it's fine, if you have three, you'll have a long first line,
then a smaller second line, and even smaller third line. Very
strange
fremy: So in a way I'm struggling, if you have elements with more
than two line, oh an implementation can produce good results
without balancing lines from where it's stealing the words
fremy: I don't think I can see how to make it different from pretty
fremy: if you're doing that you're back with pretty
astearns: I am convinced that there is a faster linebreaking
algorithm that would only do this and not look at the full
"pretty" penalty values
astearns: it doesn't have to be as expensive as the full pretty
implementation to do just this one thing
iank: But you can bias the pretty implementation
<astearns> I absolutely agree that we should avoid introducing the
line wrap triangle shapes that fremy described
iank: One thing on controls, it's not clear how this control would
apply to `text-wrap: balance`
fantasai: It wouldn't
myles: `balance` will win. it handles last line by itself
iank: It feels to me that we have at least 3 line-wrapping
algorithms, might have others in the future
iank: This control wouldn't affect balance
fantasai: It also doesn't affect nowrap
iank: Sure
iank: I somewhat agree with fremy that you might be getting into
pretty territory
iank: I'm not convinced by the global control argument
hober: If setting balance means it doesn't apply, then you aren't
setting whatever this is
hober: you're not setting it if you're not setting `text-wrap:
balance`
<ntim> +1 to what hober said
nicole: Does anyone want orphans? is anyone like "I want to turn off
nice ending to my text"
astearns: Yes, because you will get faster text composition
florian: I suspect we all agree, but will say explicitly, when that
is turned on it is a request for the browser to *attempt* to
make the last line not terrible
florian: but if can only do this by making some other line terrible,
shouldn't do it
[agreed]
florian: Also agreeing with Tess that it's also a text wrap value
florian: and can have it as an additional keyword
myles: Requested resolution isn't any particular grammar
ntim: I want to echo what Tess said, it feels like text-wrap extension
fantasai: So all of this is why I did not want this in text-wrap
fantasai: whether and how you are wrapping should be separate
fantasai: because they needs to cascade separately
<florian> +1
fantasai: You want to set the controls in a single place in your
stylesheet
<astearns> and if we want this to be extensible as a text-wrap:
pretty control it needs to be separate
fantasai: This needs to be a separate thing and honestly I think
`pretty` should have as well
fantasai: I think this gets into how we're wrapping and that should
only set once
<fantasai> This is why I was against "text-wrap: pretty" as a syntax
in the first place
Rossen: Let's pause for a second. There's a clear proposal for a
clear problem
Rossen: There are also ideas about how to do it performantly...
Rossen: We have plenty of engineers on the room, and we're getting
into how to solve the issue, let's not do that
Rossen: Let's go through the queue if you want to discuss syntax or
how to solve it
fantasai: What's the proposed solution?
Rossen: To have a property or a value that solves this problem in a
more performant way to pretty
<florian> I think we should open a separate issue to move "balance |
stable | pretty" out of text-wrap, and probably add
"avoid-orphans" there
SebastianZ: Iterating on nicole's question
SebastianZ: If the algo can be made pretty fast, why can't it be the
default?
SebastianZ: We also have text-decoration skip-ink
SebastianZ: but it was worthwhile having as a standard
Rossen: Let's close that bridge when we get to it
PROPOSED: Add a control that is either a property or a value that
causes UAs to make the last line longer than it would've
originally done unless that was a bad idea
RESOLVED: Add a control that is either a property or a value that
causes UAs to make the last line longer than it would've
originally done unless that was a bad idea
<br until=3:10>
Received on Sunday, 10 September 2023 15:50:32 UTC