- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 2 Feb 2023 08:42:26 -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 Text
--------
- RESOLVED: Accept the proposal in the issue (initial value is
space-first, and hanging-punctuation hangs ideographic
space) (Issue #2462: Propose 'text-spacing: space-first'
(trim-start-except-first-line) as a normal behavior)
- RESOLVED: Accept the proposal in the issue to split text-spacing
into longhands (Issue #4246: text-spacing is very
complicated)
CSS Overflow
------------
- RESOLVED: Move line-clamp stuff from Overflow 3 to 4 (Issue #8271:
Reshuffling levels)
- RESOLVED: Move the continue:fragments to an appendix, marking it
as unstable (Issue #8271)
Publications
------------
- RESOLVED: Publish Web Animations 2 as FPWD, with flackr and Brian
as editors
- RESOLVED: Publish CSS Animations 2 FPWD
Media Queries & Contain
-----------------------
- RESOLVED: aspect-ratio queries are always true (except when it
can't apply at all) (Issue #8244: How to evaluate
`<ratio>` queries?)
- RESOLVED: Accept Oriol's option 1 (0/0 is comparable with itself,
but false when compared with any other ratio) (Issue
#8244)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Feb/0000.html
Present:
Rossen Atanassov
Tab Atkins
Oriol Brufau
Elika Etemad
Robert Flack
Chris Harrelson
Daniel Holbert
Peter Linss
Myles Maxfield
Jen Simmons
Miriam Suzanne
Chair: Rossen
Scribe: TabAtkins
Agenda Setting
==============
<florian> should do 2 text issues: the one on the agenda, and
https://github.com/w3c/csswg-drafts/issues/4246
[discussing potential extra items]
fantasai: can I ask about splitting overflow into different levels?
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/8271
<chrishtr> Rob Flack also has an extra agenda item
flackr: Mine was just about putting Web Animations 2 from UD to ED
flackr: Also we can skip the WebAnim2 issue on the agenda, we
discussed it in the meeting earlier today
CSS Text
========
Propose 'text-spacing: space-first' (trim-start-except-first-line)
as a normal behavior
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2462
florian: With recognition that the property *overall* is too complex
(that's another issue) we still have the initial-value
behavior issue
<fantasai> "text-spacing is too complicated" issue is
https://github.com/w3c/csswg-drafts/issues/4246
florian: There's a tension between what is good typography in CJ,
and what's compatible with historical behavior
florian: There's a question about which of trim-start, space-start,
or space-first should be the default value
florian: The short answer is, after discussion, we think space-first
is a good compromise. Acceptable typography in most cases,
and compatible with most markup. Also encourages good
markup practices.
florian: Depending on how many people are interested and haven't
read the GH issue I can give more details as to why, but
the proposal is to say that space-first is the initial
behavior
florian: And part of that, change hanging-punctuation prop so that
its "first" value also hangs paragraph-initial ideographic
space
myles: Kneejerk is sounds like a good first step, but mostly
concerned about compat
myles: And we won't solve compat by thinking hard. Starting with
this and seeing what's wrong sounds useful.
florian: Agree, I'm not sue about compat but think it has a
reasonable chance, so we should try
myles: Also, our native platforms have our own text-spacing behavior
that's not described entirely by any of the CSS props
myles: And we're interested in investigating if we can make "auto"
default, reflecting that behavior
myles: So if it turns out that's compatible we'll come back and ask
for that. Won't propose it yet, so okay with starting from
florian's proposal.
fantasai: We had discussed allowing text-spacing to take effect by
default
fantasai: Right now we have a resolution that "normal" is initial,
and it corresponds to the trim values more or less
*except* space-first, because we believe there will be
some unfortunate compat impacts from trimming first line
fantasai: If WK wants to turn it on by default, it brings the
question of if we want default spacing to be set by the
platform, or be consistent and interoperable.
fantasai: We do have a keyword that means "do what the platform
wants" but the initial value is a separate question
myles: Yeah, I see a parallel between this and the override
descriptors in @font-face
myles: By default the ascent/descent of all text is set by the
platform, but if they really want it they can override those
with specific values
myles: I think this is similar
myles: But again I'm not proposing "auto" as the initial yet. I'll
need to do investigation
florian: Thanks for the heads up. Don't think that affects this
current proposal.
florian: I think you might find that backwards compat is okay, but
I'm concerned about forward compat with other platforms
being forced to agree with it, but that's a future issue.
florian: So circling back, can we accept this proposal?
<fantasai> +1
Rossen: Objections?
<fantasai> Also +1 to concerns around making 'auto' the initial
value. I don't think this is a good idea
RESOLVED: Accept the proposal in the issue (initial value is
space-first, and hanging-punctuation hangs ideographic
space)
text-spacing is very complicated
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4246
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/4246#issuecomment-1404738513
florian: myles said this proposal is too complicated - too many
values interacting in too many ways
florian: fantasai and I agree
florian: We proposed a shorthand/longhand combo of syntax that
hopefully reduces the space of syntax and limits it to a
useful subset of behavior
florian: Proposal is in issue, might still be some bikeshedding
<myles> before: normal | none | auto | no-compress || [ trim-start |
space-start | space-first ] || [ trim-end | space-end |
allow-end ] || [ trim-adjacent | space-adjacent ] ||
ideograph-alpha || ideograph-numeric || punctuation
<myles> after: text-spacing: normal | none | auto |
<'text-autospace'> || <'text-spacing-trim'>
<myles> text-spacing-trim: auto | space-all | trim-all | [ allow-end
|| space-first ]
<myles> text-autospace: normal | auto | no-autospace |
<myles> [ ideograph-alpha || ideograph-numeric || punctuation ]
<myles> || [ insert | replace ]
Rossen: What simplification do we want to draw attention to?
fantasai: We split the proposal into two longhands -
text-spacing-trim and text-autospace
fantasai: text-spacing-trim is about trimming the blank half of
full-width spacing in various cases
fantasai: text-autospace adds extra space in certain places
fantasai: We removed all the combos except for the ones we believe
would actually be used, from text-spacing-trim
fantasai: There were three props controlling start/mid/end
individually, but most combos won't be used
fantasai: So we reduced the syntax space of what keywords are
allowed to be combined. If we want to extend in the future
that's possible.
fantasai: for text-autospace: we added insert/remove keywords which
we can discuss in another issue
fantasai: Controls whether you only insert space where there's none,
or if you can replace adjacent space with the correct
amount of spacing
fantasai: Could split this into a pair of properties too,
controlling inserting vs adjusting, but for now they're
together
fantasai: And text-spacing is a shorthand for these that takes all
the props
myles: This seems like a good place to start iterating.
myles: We think we can start implementing as the bare minimum form
myles: We just resolved on the initial value - it's unclear how that
will be represented with these two props. assume that's an
oversight
florian: In old version there was a set of values for start/mid/end.
space-first set the start.
florian: Here space-first is a variation on trim-all that trims
everywhere but space at the first.
fantasai: Details are in the description. If you like it we can edit
it into the spec.
myles: I think it's an improvement on what was there before.
Rossen: Hearing no objections.
RESOLVED: Accept the proposal in the issue to split text-spacing
into longhands.
CSS Overflow
============
Reshuffling Levels
------------------
github: https://github.com/w3c/csswg-drafts/issues/8271
fantasai: florian and I wanted to prepare Overflow 3 for CR
fantasai: We'd like to shift the line-clamp stuff to L4
fantasai: Also anything else that's not already in 2 browses
fantasai: And then shift the overflow-fragments stuff from L4 to L5
fantasai: Also, there's some extensions to text-overflow in L4 - do
we want to keep it there or push them to L5?
fantasai: Question to the WG
<fantasai> -> https://drafts.csswg.org/css-overflow-4/#text-overflow
florian: I'd just move the "keep" fragment stuff to L5
florian: The text-overflow stuff was in CSS UI for a decade+... impl
is lacking but the stability is good. Not nearly as
complicated as the rest
florian: So move "continue: fragments" to L5, move line-clamp to L4,
keep the rest as-is
Rossen: The L3 to L4 makes sense to me
Rossen: Not sure what moving to L5 buys us for now.
Rossen: Are we expecting L4 to advance fast?
florian: Good question, the continue:fragments stuff is a
continuation on line-clamp. If we keep line-clamp as it is,
the *next* thing is continue:fragments
florian: So if we keep it as is, continue:fragments will make sense,
but if we don't, it probably won't make sense to keep
around.
fantasai: and continue:fragments is very experimental and complicated
TabAtkins: I'd rather push to an appendix
florian: That works too
florian: It's less helpful for issue triage, github labeling
florian: But in terms of spec, whichever
fantasai: continue:fragments is on the level of CSS Regions in terms
of CSS layout.
fantasai: Just don't think it's not a great idea
Rossen: Think we should do the resolutions separately
Rossen: So objections to moving line-clamp to L4?
[no objections]
RESOLVED: Move line-clamp stuff from Overflow 3 to 4
florian: Having done that, I'm opposed to keeping continue:fragments
in the main body
florian: I have a pref for L5 for triage purposes
TabAtkins: I don't like having single-issue delta specs, leveling is
complicated
Rossen: Lets move it to appendix for now, and if you experience any
issues with issue tracking or maintenance, we can bring it
back to approve for a L5
florian: So we'll have an appendix that means "don't look at this
too hard yet"?
TabAtkins: As opposed to a whole spec level that mans "don't look at
this too hard yet"?
<fantasai> I agree with Florian that I don't think this is a good
idea, it's confusing for both the editors and the readers.
<fantasai> But I also don't want to spend more time on it
florian: Okay, as long as it's marked well.
RESOLVED: Move the continue:fragments to an appendix, marking it as
unstable
Web Animations
==============
Web Animations 2 Publication
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/6900
flackr: Scroll Animations is depending on a lot of changes in Web
Animations 2, to support CSSNumericValues in the API
flackr: But Web Animations 2 isn't ED yet
flackr: We've been having discussions around that spec for more than
a year now. I'd like to move it to ED to get things ready
for Scroll Animations
fantasai: Fully support ED, it's overdue. Should it be going to
fpwd? Is there stuff you think should *not* be in the
spec? Or is it all in the direction we want to take?
<TabAtkins> +1 from me for fpwd
flackr: There are many things in the spec not implemented/
experimented yet...
flackr: But I think it's generally in the right direction. Probably
just CustomEffects that's not well defined.
fantasai: Are they in a direction that looks reasonable and could be
more well defined?
flackr: Yes
fantasai: So yeah then, it's fpwd, that's fine
<chrishtr> +1
Rossen: Objections for web-animations-2 FPWD?
Rossen: Same editors?
flackr: It has Stephen and Antoine removed. I know Stephen's no
longer working on Web Animations, dunno about Antoine. But
me and Brian are def in.
Rossen: Okay then let's go with you and Brian, we can add more later.
RESOLVED: Publish Web Animations 2 as FPWD, with flackr and Brian as
editors
fantasai: Do we want fpwd for CSS Animations 2?
flackr: I'm in support
Rossen: Anything there that wouldn't be ready?
flackr: from my perspective it's solid
Rossen: Sounds good, objections?
RESOLVED: Publish CSS Animations 2 fpwd
flackr: There's also Transitions 2
fantasai: Summarize changes?
flackr: Good question, can't summarize right now
fantasai: That's fine, we'll come back to it
Media Queries
=============
Move the definition of "display mode" back to Manifest spec
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7306
florian: Can't take to a great depth. Display Mode is defined by
another spec. They have some MQs for it, and proposed we
should move some of it to MQ 5.
florian: Looks like we moved too much, might want to move it back
florian: We had a discussion, don't want to just introduce syntax
without behavior defined
florian: Like, Web App Manifest has a fullscreen mode but other
things can too
florian: So they were gonna do a PR to see if their idea of balance
matches ours, and I don't see it
florian: So I think the action's on them
Rossen: Looks like they ended up closing the other repo's issue
florian: There's a comment on the issue in a fork of the repo...
Rossen: Okay, progress don't suggest enough maturity
florian: Right, so should we wait for progress or be the one driving
it?
Rossen: Looking at you for suggestions
florian: I wrote the current text and not too dissatisfied with it.
florian: I can guess what they want, but would prefer an actual
suggestion. Maybe should ping again.
Rossen: Sounds like the move.
Rossen: So action is on you to ping them
Media Queries & Contain
=======================
How to evaluate `<ratio>` queries?
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8244
oriol: CQs have the ability to compare the aspect-ratio to a value
oriol: You can also do in MQs, but more difficult to get into the
degenerate cases there, so the CQ case is more important
oriol: So what should happen if you eval aspect-ratio in a boolean
context?
oriol: Typically it's true if the feature is true when equal to any
non-zero value
oriol: But should that apply here?
oriol: And do all 0/N ratios work the same?
oriol: Propose three options:
oriol: 1) Check if any ratio evaluates to true (not excluding a 0
ratio)
oriol: 2) Check if any ratio other than 0/0 would be true - treat
*this* special ratio as the "none"
oriol: 3) Check if any non-degenerate ratio evals to true
oriol: And then there's a question of how to compare different ratios
oriol: If a ratio is > a value, how to compare if one is degenerate?
TabAtkins: Taking up separately seems fine
TabAtkins: For the first, I propose a 4th option: all ratios are
always true
TabAtkins: because there's no actual zero value
oriol: I guess that could work, too
TabAtkins: I don't think there's any meaningful behavior existing,
so don't need to worry about it
florian: Conceptually the only one to answer false about is "I don't
have a screen, I don't have an aspect ratio"
Rossen: What about 0x0 viewport?
fantasai: Two options that could make sense is Tab's proposal with
florian's amendment: only false if you don't have a
viewport at all
fantasai: Even 0/0 is a ratio
fantasai: Other option is any degenerate ratio is false
fantasai: Including zero
Rossen: When printing, what's the aspect-ratio?
fantasai: page size
TabAtkins: We don't have a way to express "no viewport at all"...
TabAtkins: I'm fine with FLorian's amendment
<TabAtkins> (in effect, it's never false then)
Rossen: Other opinions?
Rossen: Then proposed to choose option 4, false in the case of no
viewport
oriol: This would only be for media queries
oriol: So always true in CQ, since there's always an element?
fantasai: I mean an aural browser could exist that doesn't have
sizing
fantasai: Could have a non-visual browser, then can't have a box
florian: That's a broader question - geometry questions in a
non-visual browser is a wider issue
Proposed resolution: aspect-ratio queries in a boolean context are
always true
RESOLVED: aspect-ratio queries are always true (except when it can't
apply at all)
oriol: So other issue is comparison
oriol: [missed]
oriol: ratios of the form N/0 are all equal, and all greater than
finites
oriol: I think this is straightforward, but would like confirmation
oriol: But then have to say what to do with 0/0
oriol: Doesn't fit into the expanded real line
oriol: I proposed some options
oriol: 1) Model this as a special value outside the real line - you
can compare ratios in the real line, or outside the real
line, but not mixed
oriol: 2) Instead of 0/0 being special, it's a value in the interval
that's unknowable
oriol: So we'd get unknown when comparing with real numbers
oriol: 3) Basically the same but with some other cases degenerate.
oriol: I'm leaning towards the first option
oriol: You can look at the tables I made for brwoser behavior
oriol: But I propose option 1 - always true or false, but comparing
0/0 with any real ratio is always false
TabAtkins: I agree, and I think Oriol's option 1 makes sense
Summary: 0/0 == 0/0 is true, 0/0 with any other ratio is false.
Rossen: Objections?
<fantasai> wfm, given Tab's summary
RESOLVED: Accept Oriol's option 1 (0/0 is comparable with itself,
but false when compared with any other ratio)
Received on Thursday, 2 February 2023 13:43:07 UTC