- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 27 Nov 2024 18:14:12 -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.
=========================================
F2F
---
- RESOLVED: Winter F2F is Wed-Fri Jan 29-31 2025 at Apple Park
CSS Viewport
------------
- Split PR #11137 (Add automation support for viewport segments) into
two. One PR with the editorial changes and one issue with the
meta question about if we add web driver items in specs.
CSS Text
--------
- RESOLVED: Adopt forthcoming UTR#59 as basis for text-autospace
character classifications (deferring question of default
behavior to a new issue) (Issue #11013: Use the Unicode
East Asian Auto Spacing for `text-autospace`)
- RESOLVED: Adopt edits; open a new GH issue to discuss the name and
highlight issue in spec (Issue #3473: Preventing
too-short final lines of blocks (Last Line Minimum
Length))
CSSOM
-----
- RESOLVED: The pseudoElement argument to getComputedStyle takes any
pseudo-element selector, and selects the first matching
pseudo-element like querySelector() (Issue #4456:
getComputedStyle for ::before::marker or ::after::marker)
CSS Fonts
---------
- There was not consensus if issue #11014 (Clarification
font-variant-emoji should not affect characters `0-9#*`) should
be solved in CSS or in Unicode. Discussion will continue on the
github issue.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Nov/0028.html
Present:
Rachel Andrew
Rossen Atanassov
David Awogbemila
Oriol Brufau
Stephen Chenney
Emilio Cobos Álvarez
Elika Eremad
Robert Flack
Chris Harrelson
Koji Ishii
Jonathan Kew
Roman Komarov
Eric Meyer
Florian Rivoal
Gaurav Singh Faujdar
Alan Stearns
Munira Tursunova
Jason Williams
Jeffery Yasskin
Regrets:
Tab Atkins-Bittner
David Baron
Yehonatan Daniv
Daniel Holbert
Chris Lilley
Alison Maher
Miriam Suzanne
Bramus Van Damme
Scribe: chrishtr
Next F2F
========
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: I will ask
<lea> (fwiw ChrisL and I are extremely unlikely to attend if
childcare is not provided)
RESOLVED: Winter F2F is Wed-Fri Jan 29-31 2025 at Apple Park
CSS Viewport
============
Add automation support for viewport segments
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/11137
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: I 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
CSS Text
========
Use the Unicode East Asian Auto Spacing for `text-autospace`
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11013
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
florian: The original thing had special cases around letters and
numerals, but also possibly around symbols
<koji> The current draft:
https://www.unicode.org/L2/L2024/24259r-tr59-1-working-draft.html
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
<fantasai> https://www.unicode.org/L2/L2024/24259r-tr59-1-working-draft.html#symbols-punctuation
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 Chinese 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
<fantasai> PROPOSED: Adopt forthcoming UTR#59 as basis for
text-autospace character classifications (deferring
question of default behavior to a new issue)
RESOLVED: Adopt forthcoming UTR#59 as basis for text-autospace
character classifications (deferring question of default
behavior to a new issue)
CSSOM
=====
getComputedStyle for ::before::marker or ::after::marker
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4456
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
<schenney> Also relevant: https://github.com/w3c/csswg-drafts/issues/10297
emilio: Have you thought through all the corner cases?
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
<Rossen> 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()
RESOLVED: The pseudoElement argument to getComputedStyle takes any
pseudo-element selector, and selects the first matching
pseudo-element like querySelector()
CSS Text Con't
==============
Preventing too-short final lines of blocks (Last Line Minimum Length)
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3473#issuecomment-2348275178
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?
<fantasai> 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
<fantasai> PROPOSED: Adopt edits; open a new GH issue to discuss the
name and mark issue in spec
RESOLVED: Adopt edits; open a new GH issue to discuss the name and
highlight issue in spec
CSS Fonts
=========
Clarification font-variant-emoji should not affect characters `0-9#*`
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11014
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.
<fantasai> (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
<fantasai> The 'unicode' value is a good default, but it is
necessarily conservative.
<fantasai> This is a request to be more aggressive in emojification,
but the 'emoji' value as currently defined is too
aggressive for the common uses.
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
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 draw, 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.
Received on Wednesday, 27 November 2024 23:14:44 UTC