Meeting minutes
Administrivial
fantasai: Reminder to send regrets to w3c-css-wg, not www-style (which goes out to hundreds of people)
fantasai: Winter F2F, looking at Wed-Fri Jan 29-31. Unfortunately had no meeting space on Tuesday
fantasai: we'll resolve that the Winter F2F will be at apple Jan 29-31.
florian: is childcare available at the meeting?
fantasai: will ask
<lea> (fwiw ChrisL and I are extremely unlikely to attend if childcare is not provided)
RESOLUTION: Winter F2F is Wed-Fri Jan 29-31 2025 at Apple Park
oriol: I sent an email with a proposed agenda items, can we cover it?
rossen: issue 4456
github-bot, take up w3c/
[css-viewport-1] Add automation support for viewport segments
<github-bot> OK, I'll post this discussion to https://
Rossen: is Alexis Menard on the call?
emilio: I can introduce it otherwise
rossen: otherwise we can move on
emilio: there is no precedent for specifying web driver things in CSS specs, is this something we want to do?
emilio: that is the main question
rossen: I looked for issues on this topic beside the PR and didn't find one
rossen: one path forward is to say we don't have precedent or reason and to say no to web driver things in our specs
emilio: would it be reasonable to file an issue with the meta point?
rossen: agreed
emilio: will file an issue
fantasai: there are also editorial improvements in this PR that should land regardless
fantasai: recommend separating those two things from the web driver into separate PRs
rossen: ok, so split the PR into editorial and web driver, and emilio will open an issue for the meta point
github-bot, take up w3c/
[css-text] Use the Unicode East Asian Auto Spacing for `text-autospace`
<github-bot> OK, I'll post this discussion to https://
koji: this is about text autospace
koji: there have been many discussions about this, now I'd like to bring it to the group
koji: previous discussions led to complications
koji: I and two other people made a proposal related to this to the Unicode working group, and it was accepted
koji: it will be in public review soon as part of version 59
koji: proposal is to switch the character categorization for autospace to align with version 59 of Unicode
rossen: and how long will version 59 take to publish?
koji: not totally sure, maybe Jan or Feb?
florian: as you said the set of issues were complicated
florian: in principle, I think it's great that it's been taken up by Unicode and we should use it
florian: follow-up questions. Some of the things we discussed previously were not regular full-width characters but hangul and bopomofo, and how to deal with those. Am I right that this Unicode proposal deals with all those special cases in CJK?
florian: there were also special cases about symbols, are those also handled?
koji: similar to utr 50, this doesn't do exactly the same thing as e.g. MS Word as it relates to these half-width or ambiguous characters, but it is close.
koji: there are cases where people will want to override to adjust behavior, for things like printed typography
koji: what we wanted to do in version 59 is to set a solid default value for code points
<koji> The current draft: https://
florian: the original thing had special cases around letters and numerals, but also possibly around symbols
koji: the current draft of the Unicode proposal (posted in chat) classifies values to W and N and if CSS wants more control we will need to use general categories to split W into multiple pieces.
koji: I'm not sure if we want to split symbols and punctuation
florian: I'm not sure we disagree, just noting that we had discussion
https://
florian: I'm supportive of the intent of your proposal, just haven't had the time to read it
rossen: does this mean you're ok accepting this as a forward-looking resolution?
florian: depends on if others have reviewed, might suggest changes on review
fantasai: suggest accepting this change since it's an improvement, and if we find adjustments we can modify the Unicode proposal
koji: just wanted to note that the proposal in Unicode was reviewed and accepted already, as an indication of review
jfkthame: noticed that it's proposed that the changes are disabled outside of CJK for now, is that right?
koji: yes
jfkthame: what about content that is Chinese but not marked as such (e.g. blog comments)
koji: this is a good point. the reasons I proposed it that way is that the property value is different between Chines and non-Chinese. If we applied to a document that is not Chinese we need a default for that document.
koji: there's a chance that it would do the wrong thing on such documents
koji: another reason is performance. This will slow down layout 1-3% due to additional complexity, and so limit it to the languages where it has clear user benefit.
jfkthame: reasonable answers, but not sure about the conclusion
koji: I think this is in line with what we've done for other properties
jfkthame: agree that it's aligned with things like hyphenation. But in the case of hyphenation it could be wrong, whereas here it wouldn't be wrong but it would be a bit less good than it might be.
florian: things will improve less for Japanese and Korean than Chinese?
koji: it wouldn't solve the performance issue to include non-explicit languages
koji: sub-optimal rendering would also result
fantasai: wanted to express the same thing as Jonathan Kew
fantasai: propose to accept UTR 59 but leave the question of in what situations to apply the behavior open
fantasai: I lean towards what Jonathan and Florian are saying and trying to make it work when we can
koji: I can file a new issue. To clarify, we're leaving undefined if the language is not specified, but not do it in English document?
fantasai: I think that's open. We should ideally try to make it work in all documents if we can find a way.
florian: agree with the proposed two-part resolution
PROPOSED: Adopt forthcoming UTR#59 as basis for text-autospace character classifications (deferring question of default behavior to a new issue)
RESOLUTION: Adopt forthcoming UTR#59 as basis for text-autospace character classifications (deferring question of default behavior to a new issue)
github-bot, take up w3ctag/
<github-bot> chrishtr, I can't comment on that github issue because it's not in a repository I'm allowed to comment on, which are: w3c/csswg-drafts w3c/fxtf-drafts w3c/css-houdini-drafts w3c/svgwg web-platform-tests/wpt WICG/animation-worklet WICG/construct-stylesheets WICG/scroll-animations WICG/custom-state-pseudo-class openui/open-ui whatwg/html.
[cssom] getComputedStyle for ::before::marker or ::after::marker
oriol: this is about nested markers. The spec already allows these syntaxes. If authors are able to style them then they should be able to query the style of them.
oriol: I proposed generalizing the second argument to getComputedStyle to put multiple pseudo element selectors in this
oriol: we already resolved this in animations for the ? function that we already resolved, in issue 7469
oriol: there we resolved that multiple pseudo-elements could be provided. Propose to repeat that pattern here.
<emilio> +1
<kizu> +1
<schenney> +1
emilio: have you thought through all the corner cases?
<schenney> Also relevant: w3c/
florian: this resolution doesn't add any new cases, it's just about querying existing cases
oriol: for the other web animations issue, if you end up matching multiple things then you take the first one
oriol: not sure if this was exactly what you were saying about view transitions
<florian> makes sense
emilio: this is what my memory was, so sounds good
<dbaron> +1 (to the initial proposal here)
PROPOSED: allow multiple pseudo-elements in the same way as in the web animations spec
<Rossen1> The pseudoElement argument to animate() takes any pseudo-element selector, and selects the first matching pseudo-element like querySelector()
PROPOSED: The pseudoElement argument to getComputedStyle takes any pseudo-element selector, and selects the first matching pseudo-element like querySelector()
RESOLUTION: The pseudoElement argument to getComputedStyle takes any pseudo-element selector, and selects the first matching pseudo-element like querySelector()
[css-text] Preventing too-short final lines of blocks (Last Line Minimum Length)
<Rossen1> w3c/
florian: re-reading the entire PR would take too long. The previous resolution was not to accept the change but write it. Wanted to bring this to the WG for re-review before landing the PR.
kizu: to repeat what I wrote in the comment, there are two issues: widows and orphans are considered sensitive, and it's very confusing what the words mean
kizu: in online articles and books there is also confusion about terms, and some authors propose ways to improve the names for these concepts
kizu: propose to rename to "avoid short lines" instead of widow or orphan
rossen: +1 to what kizu said
<astearns> +1 to using a different term
<emilio> makes sense, though we already have `orphans` and `widows` properties right?
yes
florian: in favor of renaming generally
fantasai: have the same concerns. Propose to adopt the edits, open an new issue to rename, and put an issue in the spec saying we should rename and linking to the issue
kizu: the current spec is already not strict about requiring user agents to do particular things
PROPOSED: Adopt edits; open a new GH issue to discuss the name and mark issue in spec
RESOLUTION: Adopt edits; open a new GH issue to discuss the name and mark issue in spec
RESOLUTION: Adopt edits; open a new GH issue to discuss the name and highlight issue in spec
github-bot, take up w3c/
[css-fonts] Clarification font-variant-emoji should not affect characters `0-9#*`
<github-bot> OK, I'll post this discussion to https://
fantasai: this issue was opened by someone pointing out that font-variant-emoji currently has values to say do-default or change emoji to more text-like or more emoji presentation-like
fantasai: this makes it easy for people to ask for emoji to look the way they want
fantasai: problem is digits have emoji versions, and authors are usually not asking for those be emojified
fantasai: request is to accept the digits, # and * to be excluded from font-variant-emoji
fantasai: we could also add a keyword saying include everything, but they can already do that via variation selectors
florian: possible in content, not styling
fantasai: correct
fantasai: think it's reasonable to emojify things that aren't digits. Marking up all digits is annoying.
moonira: Elika, you said we only can do that in content, not styles, but I'm not sure I understood that properly.
moonira: dominik mentioned in his last comment we can also use span elements on those digits to achieve the desired outcome
fantasai: yes, but the commenter is saying that digits are commonly used and rarely do they want emoji styling. Forcing the author to put spans around every digits is a lot of extra work.
(and might not even be possible in their system)
moonira: also, the are other code points that are defined by unicode as emojis, like the hash sign, asterisk, that are commonly used as text and not emoji
fantasai: we should have a value that makes exceptions for these characters, so they can request extra
florian: the point is interesting because there is stuff in-between.
florian: for digits you almost always want to exclude, but less often for these other ones
fantasai: request includes digits, # and *
moonira: I don't understand users want to use digits and other symbols mentioned mostly as text from, the point was made that some emojis are more ambiguous. For example, we can use font-variant-emoji Unicode, but digits in text presentation and Unicode presentation for others?
moonira: there is an option to do that with Unicode keywords...
fantasai: the problem is that the Unicode keywords use the Unicode defaults, which are oriented around backwards compatibility in text.
fantasai: e.g. to avoid emoji staring to show up in math and science textbooks
fantasai: in cases where you want to emojify your text font-variant-emoji does that, but the commenter is saying that this is too aggressive and a better default is to exclude some of those symbols
fantasai: think it makes sense to accommodate this request, but in CSS instead of Unicode
The 'unicode' value is a good default, but it is necessarily conservative.
This is a request to be more aggressive for these common uses in emojification, but the 'emoji' value as currently defined is too aggressive.
moonira: also, implementation-wise we use commonly used libraries like ICU that follow unicode standards. It makes more sense to raise the same issue in the Unicode standard. That would allow us to avoid performance problems due to these exclusions.
moonira: should we raise it in the Unicode group instead?
jfkthame: wanted to comment that while I am sympathetic to the request, I am sympathetic to Dominik's comment in the issue expressing an unwillingness to create exceptions to Unicode.
jfkthame: I'm uneasy about that, and where to draw the line
<Rossen1> joshtumath 😁
jfkthame: there are other symbols used in text that have the emoji setting, such as trademarks, copyrights, make/female symbols. it's a difficult line to raw, and not sure we want to be in that business.
rossen: let's continue the discussion in the issue
florian: do you mean that therefore it's an insoluble problem (or best solved in Unicode as Munira suggests)?
florian: is it possible for Unicode to solve this or impossible for them too?
jfkthame: I would be happier to see it solved in Unicode than patched in CSS. Not sure any solution would be perfect, but there could be a Unicode property to represent this.
End
Rossen1: Future meetings will be at regular call time, unless otherwise specified.