17:02:45 <RRSAgent> RRSAgent has joined #css
17:02:50 <RRSAgent> logging to https://www.w3.org/2024/11/27-css-irc
17:02:50 <kizu> present+
17:02:50 <Zakim> RRSAgent, make logs Public
17:02:51 <florian> present+
17:02:51 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
17:02:52 <fantasai> Topic: Administrivial
17:02:55 <chrishtr> present+
17:03:24 <jfkthame> present+
17:03:28 <fantasai> scribenick: chrishtr
17:03:54 <oriol> present+
17:04:36 <emilio> present+
17:05:25 <rachelandrew> present+
17:05:32 <gfaujdar> gfaujdar has joined #css
17:05:35 <fantasai> scribe+
17:05:40 <gfaujdar> present+
17:05:56 <fantasai> fantasai: Reminder to send regrets to w3c-css-wg, not www-style (which goes out to hundreds of people)
17:06:17 <fantasai> fantasai: Winter F2F, looking at Wed-Fri Jan 29-31. Unfortunately had no meeting space on Tuesday
17:06:32 <JaseW> present+
17:06:45 <chrishtr> fantasai: we'll resolve that the Winter F2F will be at apple Jan 29-31.
17:07:02 <chrishtr> florian: is childcare available at the meeting?
17:07:05 <chrishtr> fantasai: will ask
17:07:25 <lea> (fwiw ChrisL and I are extremely unlikely to attend if childcare is not provided)
17:07:31 <DavidA> DavidA has joined #css
17:07:32 <fantasai> RESOLVED: Winter F2F is Wed-Fri Jan 29-31 2025 at Apple Park
17:07:38 <emeyer> emeyer has joined #css
17:07:47 <schenney> schenney has joined #css
17:07:58 <emeyer> present+
17:08:07 <chrishtr> oriol: I sent an email with a proposed agenda items, can we cover it?
17:08:24 <chrishtr> rossen: issue 4456
17:08:26 <flackr> present+
17:08:41 <chrishtr> github-bot, take up https://github.com/w3c/csswg-drafts/pull/11137
17:08:42 <github-bot> Topic: [css-viewport-1] Add automation support for viewport segments
17:08:42 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/pull/11137.
17:09:18 <chrishtr> Rossen: is Alexis Menard on the call?
17:09:28 <chrishtr> emilio: I can introduce it otherwise
17:09:43 <chrishtr> rossen: otherwise we can move on
17:10:10 <chrishtr> emilio: there is no precedent for specifying web driver things in CSS specs, is this something we want to do?
17:10:17 <chrishtr> emilio: that is the main question
17:10:41 <chrishtr> rossen: I looked for issues on this topic beside the PR and didn't find one
17:11:09 <chrishtr> 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
17:11:32 <chrishtr> emilio: would it be reasonable to file an issue with the meta point?
17:11:37 <chrishtr> rossen: agreed
17:11:44 <jyasskin> present+
17:11:46 <chrishtr> emilio: will file an issue
17:11:50 <Rossen1> ack fantasai
17:12:01 <chrishtr> fantasai: there are also editorial improvements in this PR that should land regardless
17:12:18 <chrishtr> fantasai: recommend separating those two things from the web driver into separate PRs
17:12:45 <chrishtr> rossen: ok, so split the PR into editorial and web driver, and emilio will open an issue for the meta point
17:12:56 <chrishtr> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11013
17:12:56 <github-bot> Topic: [css-text] Use the Unicode East Asian Auto Spacing for `text-autospace`
17:12:56 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11013.
17:13:27 <fantasai> present+
17:13:33 <DavidA> present+
17:13:34 <chrishtr> koji: this is about text autospace
17:13:50 <chrishtr> koji: there have been many discussions about this, now I'd like to bring it to the group
17:14:07 <chrishtr> koji: previous discussions led to complications
17:14:34 <chrishtr> koji: I and two other people made a proposal related to this to the Unicode working group, and it was accepted
17:14:48 <chrishtr> koji: it will be in public review soon as part of version 59
17:15:12 <chrishtr> koji: proposal is to switch the character categorization for autospace to align with version 59 of Unicode
17:15:17 <florian> q+
17:15:26 <chrishtr> rossen: and how long will version 59 take to publish?
17:15:33 <chrishtr> koji: not totally sure, maybe Jan or Feb?
17:15:54 <chrishtr> florian: as you said the set of issues were complicated
17:15:54 <Rossen1> ack florian
17:16:09 <chrishtr> florian: in principle, I think it's great that it's been taken up by Unicode and we should use it
17:16:52 <chrishtr> florian: follow-up questions. Some of the things we discussed previously were not regular full-width characters but some special cases, and how to deal with those. Am I right that this Unicode proposal deals with all those special cases in CJK?
17:17:10 <chrishtr> florian: there were also special cases about symbols, are those also handled?
17:17:23 <florian> s/some special cases/hangul and bopomofo
17:17:45 <chrishtr> 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.
17:18:04 <chrishtr> koji: there are cases where people will want to override to adjust behavior, for things like printed typography
17:18:27 <chrishtr> koji: what we wanted to do in version 59 is to set a solid default value for code points
17:18:28 <koji> The current draft: https://www.unicode.org/L2/L2024/24259r-tr59-1-working-draft.html
17:18:56 <chrishtr> florian: the original thing had special cases around letters and numerals, but also possibly around symbols
17:19:33 <chrishtr> 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.
17:19:49 <chrishtr> koji: I'm not sure if we want to split symbols and punctuation
17:20:02 <chrishtr> florian: I'm not sure we disagree, just noting that we had discussion
17:20:14 <fantasai> https://www.unicode.org/L2/L2024/24259r-tr59-1-working-draft.html#symbols-punctuation
17:20:26 <chrishtr> florian: I'm supportive of the intent of your proposal, just haven't had the time to read it
17:20:43 <chrishtr> rossen: does this mean you're ok accepting this as a forward-looking resolution?
17:21:08 <chrishtr> florian: depends on if others have reviewed, might suggest changes on review
17:21:39 <chrishtr> fantasai: suggest accepting this change since it's an improvement, and if we find adjustments we can modify the Unicode proposal
17:21:58 <chrishtr> koji: just wanted to note that the proposal in Unicode was reviewed and accepted already, as an indication of review
17:22:35 <chrishtr> jfkthame: noticed that it's proposed that the changes are disabled outside of CJK for now, is that right?
17:22:41 <chrishtr> koji: yes
17:23:09 <chrishtr> jfkthame: what about content that is Chinese but not marked as such (e.g. blog comments)
17:23:47 <chrishtr> 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.
17:23:59 <chrishtr> koji: there's a chance that it would do the wrong thing on such documents
17:24:28 <chrishtr> 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.
17:24:52 <chrishtr> jfkthame: reasonable answers, but not sure about the conclusion
17:25:17 <chrishtr> koji: I think this is in line with what we've done for other properties
17:25:59 <chrishtr> 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.
17:26:31 <chrishtr> florian: things will improve less for Japanese and Korean than Chinese?
17:26:57 <chrishtr> koji: it wouldn't solve the performance issue to include non-explicit languages
17:27:05 <chrishtr> koji: sub-optimal rendering would also result
17:27:09 <Rossen1> ack fantasai
17:27:29 <chrishtr> fantasai: wanted to express the same thing as Jonathan Kew
17:27:58 <chrishtr> fantasai: propose to accept UTR 59 but leave the question of in what situations to apply the behavior open
17:28:18 <chrishtr> fantasai: I lean towards what Jonathan and Florian are saying and trying to make it work when we can
17:28:43 <chrishtr> 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?
17:29:06 <chrishtr> fantasai: I think that's open. We should ideally try to make it work in all documents if we can find a way.
17:29:25 <chrishtr> florian: agree with the proposed resolution
17:29:41 <fantasai> PROPOSED: Adopt forthcoming UTR#59 as basis for text-autospace character classifications (deferring question of default behavior to a new issue)
17:29:45 <florian> s/the proposed resolution/the proposed two-part resolution
17:30:20 <chrishtr> RESOLVED: Adopt forthcoming UTR#59 as basis for text-autospace character classifications (deferring question of default behavior to a new issue)
17:30:56 <DavidA> DavidA has joined #css
17:31:08 <chrishtr> github-bot, take up https://github.com/w3ctag/design-reviews/issues/1003
17:31:08 <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.
17:31:33 <github-bot> Topic: [cssom] getComputedStyle for  ::before::marker or ::after::marker
17:32:29 <chrishtr> 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.
17:32:53 <chrishtr> oriol: I proposed generalizing the second argument to getComputedStyle to put multiple pseudo element selectors in this
17:33:15 <chrishtr> oriol: we already resolved this in animations for the ? function that we already resolved, in issue 7469
17:33:35 <chrishtr> oriol: there we resolved that multiple pseudo-elements could be provided. Propose to repeat that pattern here.
17:33:45 <emilio> +1
17:33:50 <kizu> +1
17:34:01 <schenney> +1
17:35:19 <chrishtr> emilio: have you thought through all the corner cases?
17:35:34 <schenney> Also relevant: https://github.com/w3c/csswg-drafts/issues/10297
17:35:39 <chrishtr> florian: this resolution doesn't add any new cases, it's just about querying existing cases
17:36:12 <chrishtr> oriol: for the other web animations issue, if you end up matching multiple things then you take the first one
17:36:24 <chrishtr> oriol: not sure if this was exactly what you were saying about view transitions
17:36:30 <florian> makes sense
17:36:36 <chrishtr> emilio: this is what my memory was, so sounds good
17:37:28 <dbaron> +1 (to the initial proposal here)
17:37:34 <chrishtr> PROPOSED: allow multiple pseudo-elements in the same way as in the web animations spec
17:38:06 <Rossen1> The pseudoElement argument to animate() takes any pseudo-element selector, and selects the first matching pseudo-element like querySelector()
17:38:29 <chrishtr> PROPOSED: The pseudoElement argument to getComputedStyle takes any pseudo-element selector, and selects the first matching pseudo-element like querySelector()
17:38:35 <chrishtr> RESOLVED: The pseudoElement argument to getComputedStyle takes any pseudo-element selector, and selects the first matching pseudo-element like querySelector()
17:39:17 <github-bot> Topic: [css-text] Preventing too-short final lines of blocks (Last Line Minimum Length)
17:39:37 <Rossen1> https://github.com/w3c/csswg-drafts/issues/3473#issuecomment-2348275178
17:40:17 <kizu> q+
17:40:35 <chrishtr> 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.
17:40:47 <Rossen1> ack kizu
17:41:25 <chrishtr> 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
17:42:07 <chrishtr> kizu: in online articles and books there is also confusion about terms, and some authors propose ways to improve the names for these concepts
17:42:23 <chrishtr> kizu: propose to rename to "avoid short lines" instead of widow or orphan
17:43:09 <chrishtr> rossen: +1 to what kizu said
17:43:10 <astearns> +1 to using a different term
17:43:15 <Rossen1> ack kizu
17:43:35 <emilio> makes sense, though we already have `orphans` and `widows` properties right?
17:43:42 <fantasai> yes
17:43:49 <chrishtr> florian: in favor of renaming generally
17:44:21 <chrishtr> 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
17:44:24 <Rossen1> ack florian
17:44:48 <chrishtr> kizu: the current spec is already not strict about requiring user agents to do particular things
17:44:50 <fantasai> PROPOSED: Adopt edits; open a new GH issue to discuss the name and mark issue in spec
17:45:16 <fantasai> RESOLVED: Adopt edits; open a new GH issue to discuss the name and mark issue in spec
17:45:17 <chrishtr> RESOLVED: Adopt edits; open a new GH issue to discuss the name and highlight issue in spec
17:45:50 <chrishtr> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11014
17:45:50 <github-bot> Topic: [css-fonts] Clarification font-variant-emoji should not affect characters `0-9#*`
17:45:50 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11014.
17:46:35 <chrishtr> 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
17:46:49 <chrishtr> fantasai: this makes it easy for people to ask for emoji to look the way they want
17:47:11 <chrishtr> fantasai: problem is digits have emoji versions, and authors are usually not asking for those be emojified
17:47:51 <chrishtr> fantasai: request is to accept the digits, # and & to be excluded from font-variant-emoji
17:47:59 <chrishtr> s/&/*/
17:48:27 <chrishtr> fantasai: we could also add a keyword saying include everything, but they can already do that via variation selectors
17:48:42 <chrishtr> florian: possible in content, not styling
17:48:48 <chrishtr> fantasai: correct
17:49:10 <moonira> q+
17:49:13 <chrishtr> fantasai: think it's reasonable to emojify things that aren't digits. Marking up all digits is annoying.
17:49:33 <Rossen1> ack moonira
17:49:56 <chrishtr> moonira: Elika, you said we only can do that in content, not styles, but I'm not sure I understood that properly.
17:50:19 <chrishtr> moonira: dominik mentioned in his last comment we can also use span elements on those digits to achieve the desired outcome
17:50:55 <chrishtr> 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.
17:51:04 <fantasai> (and might not even be possible in their system)
17:51:34 <chrishtr> 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
17:52:00 <chrishtr> fantasai: we should have a value that makes exceptions for these characters, so they can request extra
17:52:17 <chrishtr> florian: the point is interesting because there is stuff in-between.
17:52:35 <chrishtr> florian: for digits you almost always want to exclude, but less often for these other ones
17:52:48 <chrishtr> fantasai: request includes digits, # and *
17:54:40 <chrishtr> 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?
17:54:48 <chrishtr> moonira: there is an option to do that with Unicode keywords...
17:55:11 <chrishtr> fantasai: the problem is that the Unicode keywords use the Unicode defaults, which are oriented around backwards compatibility in text.
17:55:24 <chrishtr> fantasai: e.g. to avoid emoji staring to show up in math and science textbooks
17:56:08 <moonira> q+
17:56:13 <chrishtr> 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
17:56:39 <chrishtr> fantasai: think it makes sense to accommodate this request, but in CSS instead of Unicode
17:56:57 <Rossen1> ack moonira
17:57:08 <fantasai> The 'unicode' value is a good default, but it is necessarily conservative.
17:57:27 <Linux_Kerio> Linux_Kerio has joined #css
17:57:27 <fantasai> This is a request to be more aggressive in emojification, but the 'emoji' value as currently defined is too aggressive.
17:57:51 <chrishtr> 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.
17:57:55 <jfkthame> q+
17:58:09 <chrishtr> moonira: should we raise it in the Unicode group instead?
17:58:31 <Rossen1> ack joshtumath
17:58:39 <Rossen1> ack jfkthame
17:58:55 <fantasai> s/aggressive/aggressive for these common uses/
17:59:00 <chrishtr> 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.
17:59:13 <chrishtr> jfkthame: I'm uneasy about that, and where to draw the line
17:59:37 <Rossen1> joshtumath 😁
17:59:51 <chrishtr> jfkthame: there are other symbols used in text that have the emoji setting, such as trademarks, copyrights, make/female symbols. not sure we want to be in that business.
18:00:07 <fantasai> s/not sure/it's a difficult line to raw, and not sure/
18:00:15 <chrishtr> rossen: let's continue the discussion in the issue
18:00:45 <chrishtr> florian: do you mean that therefore it's an insoluble problem (or best solved in Unicode as Munira suggests)?
18:01:01 <chrishtr> florian: is it possible for Unicode to solve this or impossible for them too?
18:01:33 <chrishtr> 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.
18:02:57 <fantasai> Topic: End
18:03:00 <emeyer> emeyer has left #css
18:03:11 <fantasai> Rossen1: Future meetings will be at regular call time, unless otherwise specified.
18:03:22 <RRSAgent> I have made the request to generate https://www.w3.org/2024/11/27-css-minutes.html fantasai
18:03:34 <Rossen1> Zakim, end meeting
18:03:34 <Zakim> As of this point the attendees have been schenney, kizu, florian, chrishtr, jfkthame, oriol, emilio, rachelandrew, gfaujdar, JaseW, emeyer, flackr, jyasskin, fantasai, DavidA
18:03:37 <Zakim> RRSAgent, please draft minutes v2
18:03:38 <RRSAgent> I have made the request to generate https://www.w3.org/2024/11/27-css-minutes.html Zakim
18:03:44 <Zakim> I am happy to have been of service, Rossen1; please remember to excuse RRSAgent.  Goodbye
18:03:44 <Zakim> Zakim has left #css
19:25:53 <jfkthame> jfkthame has joined #css
21:15:55 <emeyer> emeyer has joined #css