Meeting minutes
[discussing potential extra items]
fantasai: can i ask about splitting overflow into different levels?
<chrishtr> Rob Flack also has an extra agenda item
flackr: Mine was just about putting Web Anim 2 from UD to ED
flackr: Also we can skip the WebAnim2 issue on the agenda, we discussed it in the meeting earlier today
github-bot, take up w3c/
[css-text-4] Propose 'text-spacing: space-first' (trim-start-except-first-line) as a normal behavior
<github-bot> OK, I'll post this discussion to https://
florian: With recognition that the property *overall* is too complex (that's another issue) we still have the initial-value bheavior issue
<fantasai> "text-spacing is too complicated" issue is w3c/
florian: there's a tension between what is good typography in CJ, and what's compatible with historical beahvior
florian: There's a q about which of trim-start, space-start, or space-first should be the deafult 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 reasoanble chance, so we should try
myles: also, our native platforms have our own text-spacing beahvior 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 tkae effect by default
fantasai: Right now we ahve a resolution that "normal" is initial, and it corresponds to the trim values more or less *except* space-first, bc 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 taht means "do what the platform wants" but the initial value is a separate q
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?
RESOLUTION: Accept the proposal in the issue (initial value is space-first, and hanging-punctuation hangs ideographic space)
<fantasai> Also +1 to concerns around making 'auto' the initial value. I don't think this is a good idea
github-bot, take up w3c/
[css-text] text-spacing is very complicated
<github-bot> OK, I'll post this discussion to https://
<fantasai> w3c/
florian: myles said this prop 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 fo 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
Rossen_: What simplification do we want to draw attention to?
<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 ]
fantasai: We split the prop into two longhands - text-spacing-trim and text-auto-space
fantasai: t-s-t is about trimming the blank half of full-width spacing in various cases
fantasai: t-a-t adds extra space in certain places
fantasai: We removed all the combos except for the ones we believe woudl actually be used, from t-s-t
fantasai: There were three props controlling start/mid/end individually, but most combos won't be used
fantasai: So we reduced the syntax sapce of what keywords are allowed to be combined. If we want to extend in the future that's possible.
fantasai: for t-a-s: 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 repalce 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.
RESOLUTION: Accept the proposal in the issue to split text-spacing into longhands.
github-bot, take up w3c/
[css-overflow-3][css-overflow-4][css-overflow-5] Reshuffling Levels
<github-bot> OK, I'll post this discussion to https://
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: q to the WG
<fantasai> https://
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 compliated 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, c:f 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 complicate
<fantasai> TabAtkins: I'd rather push to an appendix
florian: that works too
florian: It's less helpful for issue triage, github labelling
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
RESOLUTION: 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
<fantasai> TabAtkins: I don't like having single-issue delta specs, levelling 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 "dont' 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.
florian: Okay, as long as it's marked well.
<fantasai> But I also don't want to spend more time on it
RESOLUTION: Move the continue:fragments to an appendix, marking it as unstable.
Web Anim stuff
flackr: Scroll Animations is depending on a lot of changes in Web Anim 2, to support CSSNumericValues in the API
flackr: But WA2 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
+1 from me for fpwd
<Zakim> fantasai, you wanted to ask if it should go to FPWD
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?
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 reasonble 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 WA, 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.
RESOLUTION: 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?
RESOLUTION: Publish CSS Animations 2 fpwd
flackr: There's also Transitions 2
fantasai: Summarize changes?
flackr: Good question, cant' summarize right now
fantasai: That's fine, we'll come back to it
github: w3c/
github-bot, take up w3c/
github-bot, take up w3c/
[css-backgrounds-4] Split CSS Backgrounds into two separate specs?
<github-bot> OK, I'll post this discussion to https://
github-bot, take up w3c/
[css-overflow] How does overflow-clip-margin: border-box behave on a scroll container?
<github-bot> OK, I'll post this discussion to https://
github-bot, take up w3c/
[mediaqueries-5] Move the definition of "display mode" back to Manifest spec
<github-bot> OK, I'll post this discussion to https://
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
github-bot, take up w3c/
[mediaqueries][css-contain] How to evaluate `<ratio>` queries?
<github-bot> OK, I'll post this discussion to https://
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 exlcuding 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?
<fantasai> TabAtkins: taking up separately seems fine
<fantasai> TabAtkins: For the first, I propose a 4th option: all ratios are always true
<fantasai> TabAtkins: because there's no actual zero value
<fantasai> oriol: I guess that could work, too
<fantasai> TabAtkins: I don't think there's any meaningful behavior existing, so don't need to worry about it
<fantasai> florian: Conceptually the only one to answer false about is "I don't have a screen, I don't have an aspect ratio"
<fantasai> 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: Includign zero
Rossen_: When printing, what's the a-r?
fantasai: page size
<fantasai> TabAtkins: We don't have a way to express "no viewport at all"...
<fantasai> TabAtkins: I'm fine with FLorian's amendment
<fantasai> Rossen_: other opinions?
(in effect, it's never false then)
<fantasai> Rossen_: Then proposed to choose option 4, false in the case of no viewport
<fantasai> 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> 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
RESOLUTION: aspect-ratio queries are always true (except when it can't apply at all)
oriol: So othe rissue 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) Instaed 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
<fantasai> 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
RESOLUTION: Accept Oriol's option 1 (0/0 is comparable with itself, but false when compared with any other ratio)
github-bot, end topic