- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 31 Oct 2024 18:55:02 -0400
- 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.
=========================================
Color HDR
---------
- RESOLVED: Accept the PR (Issue #10271: Add interpolation between
multiple values of dynamic-range-limit)
CSS Images
----------
- smfr will research if webkit is able to change to the chromium
behavior for issue #4165 (Should CSS decorative images respect
EXIF-orientation by default) which the group will use to guide
the resolution.
CSSOM View
----------
- RESOLVED: Change the spec to match reality around child-of-root
BODY elements (Issue #10549: Spec for offsetTop/Left does
not match impls when offsetParent is `position:static`
`<body>` element)
CSS Text
--------
- RESOLVED: Plain text copy must ignore text replaced autospace. open
to other feedback (Issue #8511: text-autospace: what gets
copied?)
- Comments are requested in issue #3434 (Prevent line breaking after
explicit hyphens) to help move the conversation toward a
resolution.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Oct/0015.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
Kevin Babbitt
Oriol Brufau
Stephen Chenney
Emilio Cobos Álvarez
Yehonatan Daniv
Stephanie Eckles
Elika Etemad
Gaurav Singh Faujdar
Robert Flack
Simon Fraser
Daniel Holbert
Jonathan Kew
Roman Komarov
David Leininger
Chris Lilley
Alison Maher
Florian Rivoal
Cassondra Roberts
Noam Rosenthal
Khushal Sagar
Alan Stearns
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Lea Verou
Sebastian Zartner
Regrets:
Keith Cirkel
Chris Harrelson
Scribe: noamr
Scribe's scribe: TabAtkins
Color HDR
=========
Add interpolation between multiple values of dynamic-range-limit
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10271
Chris: We have this dynamic range value. But you might have more than
value, e.g. in animation, need to decide what happens
ChrisL: We have a PR, we either should merge it or revert. I think
it's a good syntax
astearns: Inclined to accept the PR
ChrisL: I prefer to review things in place
astearns: Objections?
RESOLVED: Accept the PR
CSS Images
==========
Should CSS decorative images respect EXIF-orientation by default
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4165
ChrisL: It wasn't clear what we've resolved on
ChrisL: What this means that if you have EXIF that comes before the
image data we must respect it
ChrisL: For consistency we should probably ignore it when it comes
after
smfr: You mean in the order in which the image is encoded?
ChrisL: Yes, which is not always possible
schenney: I agree with ignoring after the image, but the question was
whether the orientation should look at the
image-orientation property on the element
schenney: Chrome does this but Safari does not
ChrisL: There wasn't a discussion on this, can we discuss now?
schenney: One, I implemented this a while ago, the usage data for
image-orientation and it's rising, but not in a huge amount
schenney: People use it to avoid applying the image metadata
schenney: From that point of view the current chrome behavior is
preferable for web devs. But the long term is perhaps to
not have that property
schenney: We'll get pushback if we do that
schenney: if we don't honor image-orientation
noamr: Even now, image-orientation is broken in the sense that it
doesn't work on cross-origin images
noamr: which is a real big breakage for people
noamr: I find it a broken CSS property because of that
noamr: having it apply to CSS images, it's a bit weird you have
something for the whole element and apply it to all images.
I'd expect it to be a url modifier or something, a keyword
that says you read the EXIF
<ChrisL> +1 to URL modifier
noamr: We have url() modifiers now for other things, we can put it
there. I think that's the right place
<TabAtkins> (+1 to that, it was clumsy to have it apply that way)
smfr: It should be per-image, maybe on the image function
smfr: background: webkit started supporting orientation by default on
regular images, we just didn't get to CSS images
smfr: I think we can change it to match the chromium behavior
ChrisL: URL modifier is perhaps a good way to go
schenney: URL modifier would address the original reason why image
orientation is ignored on cross-origin
<fantasai> url modifiers should be for generic modifiers. We should
use image() for image-specific modifiers.
<fantasai> And we should have more of them.
dbaron: I'm more hesitant about modifiers. They make sense for
features we want permanently. My impression is that this
feature is more for compatibility during transition
dbaron: If we want to end up always honoring the metadata, we should
only add as many features as we need for that, rather than
add more granularity
astearns: If we resolve on ignoring EXIF at the end, does that help
with the transition?
dbaron: It wasn't clear to me which cases the resolution applies to
PaulG: For a11y I'd be concerned that if people relied on this
feature for WCAG orientation, I wouldn't want to get rid of it
PaulG: I suspect we'd want to keep that
fantasai: Modifiers should be in image() and not in url()
<TabAtkins> Yeah since this is explicitly an image *file*, I'm fine
with it living on url()
astearns: We can probably resolve on ignoring metadata that's after
the metadata
schenney: I thought it was resolved a while ago
ChrisL: It was unclear enough that it's hard to say what a PASS is
smfr: We might not be able to do this in the implementation
fantasai: HTML could add special rules, but in CSS we should say how
we handle images with EXIF, regardless of the host language
smfr: Odd that CSS would define things around the encoding of an image
<noamr> it should at least be in both
<fantasai> It doesn't need to be in both. It's a rendering question,
it needs to be in CSS. HTML can optionally say stuff, but
it doesn't need to -- we do.
noamr: We talked before in WHATWG about separating some of those
image details to a separate spec
noamr: It never happened because nobody had time, but I think right
now, relying on parts of HTML that defines how images are
decoded, relying on that inside of CSs, is the best we'
noamr: We should behave the same way for HTML and CSS
<ChrisL> relevant PNG WG issue is https://github.com/w3c/png/issues/310
astearns: It is claimed that all browsers ignore post-image-data
orientation
astearns: smfr would you validate?
smfr: Will validate
astearns: Will take it back to the issue about encoding order
astearns: to validate that all browsers do this today
ChrisL: Please check with JPEG with PNG, I saw that Safari does
something different
smfr: That's why we need more time
<noamr> (In PNG this is encoded in XMP IIRC)
<ChrisL> No, it can be but there is also an exif chunk
astearns: For how we override the metadata
smfr: This is *this* issue, but we discussed a different one
noamr: Also there's a proposal for a url() modifier. not clear yet.
But at least not taking the info from image-orientation
schenney: So proposal is phase out a per-image way of specifying it,
and phase-out image-orientation property
<TabAtkins> phase in an image-specific way to do *CSS images*.
dbaron: Replaced elements, form HTML, would still obey
image-orientation
astearns: So let's continue that part of the discussion in this issue
astearns: Action item for smfr to validate the tests
CSSOM View
==========
Spec for offsetTop/Left does not match impls when offsetParent is
`position:static` `<body>` element
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10549
oriol: We encountered this in servo, that impls are not per-spec
oriol: offsetTop/offsetLeft of the element, when there is no
offsetParent, the distance is used
oriol: Implementations do something different with body which has
position static, they use its parent (document element), and
use the border edge instead of a padding edge
oriol: There's a bug in Firefox but the idea is still the same
oriol: I think what the spec says makes more sense, that even though
browsers are doing something different, we should probably
align the spec with reality
astearns: Probably browsers wouldn't change this and maintain
backwards compat
oriol: It works differently in nested body elements
<TabAtkins> I'm also very sad about this being so weird, but suspect
we couldn't fix it without everyone being off by 8px
<noamr> no one likes to touch offsetLeft issues, I tried before
astearns: So the discrepancy is only about the body?
oriol: Implementations are doing different things for all body
elements
oriol: maybe that's ok
oriol: If it's something is nested we might have to do something, I'm
fine either way
<kbabbitt> agree that we probably need to spec current behavior for
compat
astearns: The simple thing would be to change the spec to match
reality
astearns: What would be the change?
oriol: We'll add a case where if the offset parent is body with
position static, we'd take its parent's border edge instead of
its padding edge. Need to analyze some details
oriol: We could establish for all body elements, or just for body
that is a child of a root
fantasai: No strong opinion; our propagation rules for certain thing
depend on body being the child of the HTML element
fantasai: The value of position makes a difference. Does it make
sense to depend on position?
oriol: Browsers only do this with position:static, otherwise they
compute the distance from the body
oriol: It would probably be tricky compat-wise to do something else
PROPOSED RESOLUTION: change the spec to match reality around
child-of-root BODY elements
fantasai: We should not be checking in WPTs that aren't backed by
a spec
<astearns> fwiw I'm OK with tests that pass everywhere but are not
specced. This points out things we should spec
flackr: Is it just that the body element is position:static, or
possibly when the body element is not a containing block? Do
we need to worry about position:relative containing
position:fixed
oriol: If the body establishes a containing block using position, eg
fixed inside relative, it would do the normal thing
oriol: If it's not the offsetParent, we also do the normal thing. so
it needs to be in the containing block chain
oriol: If the body is not in the containing block chain, it also
wouldn't be the offsetParent and this wouldn't apply
flackr: What is the offsetParent with position:fixed
oriol: This is only a special case when the body is the offsetParent.
So if position prevents the body from being a containing block
it would also not be the offsetParent
flackr: Just making sure there is no additional special case here
oriol: Just that from what I can see
astearns: Objections?
RESOLVED: Change the spec to match reality around child-of-root BODY
elements
CSS Text
========
text-autospace: what gets copied?
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8511
florian: text-autospace, in cjk at the limit between cjk and other,
e.g. numeric, it adds spacing because it's typographically
expected
florian: The property has a syntax variant that it's not inserting
but rather replacing the spacing, because sometimes that
there is an explicit space
florian: Similar, outside of cjk, this is used to insert spaces in
French before some punctuations. In some cases there is a
narrow space, and CSS does it for people because people
don't do it
florian: What do we do with copy-paste in this mode? At least in the
CJK context we ignore and copy the source
florian: There are individual opinions that we should do the same for
French
florian: We were wondering whether this should be different for
French, it's more an abuse/correction than styling
florian: The i18n recommendation was to just copy the source
florian: I was wondering about French, perhaps we should copy the
original one
fantasai: I would expect it to be copied correctly as a user,
definitely for CJK we shouldn't copy
fantasai: There wasn't an obvious agreement in the group about what
to do when we use replacement
fantasai: for CJK autospace insertion we shouldn't copy, but for
French, narrow spaces etc, a lot of other contexts wouldn't
fix it, e.g. word wouldn't correct pasted stuff
florian: For having the spaces manually inputted into the text, it
might be intentional, but if you're copy/pasting into an
email, it's nicer if there was a space there
florian: I find the i18n resolution plausible, still on the fence for
French. then again it's a bit of a hack
astearns: Do we know what browsers do?
fantasai: I suspect they use the underlying text
fantasai: Let's close and using underlying text, but come back to it
if users complain
fantasai: Users can copy stuff that has a space, sometimes they'll
get one and sometimes not
fantasai: It's probably better to do the fixup in terms of users, but
perhaps we can wait
astearns: Inclined to resolve on specifying we should copy the
underlying text, perhaps with a note that this can change
with user feedback
fantasai: We can be open to changing it if there's user demand for it
Jonathan: It's similar to copying text with text-transform. There are
always going to be people unhappy with the decision
Jonathan: I think this is up to presentation tools
Jonathan: We shouldn't mangle the actual data
noamr: Isn't this a bit up to the browser? If the browser wants
multiple copy functions in the context menu
noamr: Is it the standard's job?
fantasai: There's often different format, sure - plain text, or html
with formatting, etc
fantasai: We're just talking about plain text copy
fantasai: We do say that we collapse white space for a plain text
copy, for example. If you didn't do that, the text would be
a big mess if there's indentation
noamr: We copy capitalization, don't we?
florian: This is contentious, but no
fantasai: text-transform is a bit different because it's not
correcting the text, it's providing a style. We're clear in
the spec that it's a contextual style
fantasai: That's why you don't copy it
fantasai: The cases we're considering doing the transform are where
the literal text isn't actually representative of the char
string the author wants
fantasai: not just for presentation purposes
fantasai: If you're typing regular space instead of nbthinspace,
you're doing it because nb thin space is hard to type
noamr: Okay so it's more of an error correction
florian: The injection to CJK is styling. The removal and replacement
in French is error correction
florian: Yeah, at least part of it. The injection of spacing in CJK
contexts is styling. The removal/change of what's there (in
French) is correction
dbaron: A copy operation in many OSes already does multiple things
at once
florian: We're only defining plain text here
PROPOSED REOSLUTION: plain text copy must ignore text replaced
autospace. open to other feedback
RESOLVED: plain text copy must ignore text replaced autospace. open
to other feedback
Prevent line breaking after explicit hyphens
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3434
florian: Browsers might to suppress hyphens in special words like
t-shirt. Which property controls this? hyphen: none doesn't.
Maybe a new value? Maybe a new value of the break property?
florian: This issue is to discuss what toggle do we use for this.
There are a few options on the table. Please chime in.
Received on Thursday, 31 October 2024 22:55:39 UTC