- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 16 Aug 2021 18:16:59 -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.
=========================================
CSS Variables
-------------
- RESOLVED: Computed value preserves specified value (accept proposed
spec) (Issue #5685: Custom properties and serialization)
- RESOLVED: Registered properties same as normal property (whatever
that ends up being) (Issue #5685)
CSS Flexbox
-----------
- RESOLVED: Accept proposal and remove note (Issue #4311: Should
definite flex-basis make the main size definite?)
- RESOLVED: Specify current behavior (clamp the orthogonal box, not
propagate the clamping to block children) (Issue #4221:
Orthogonal column flex containers)
Fonts 5
-------
- RESOLVED: Add a `incremental` to the `font-technology` values
production as described on the PR (Issue #6063:
@font-face supports incremental)
- RESOLVED: Add this keyword in fonts-4 as well (Issue #6063)
CSS Overflow
------------
- RESOLVED: Close with no change (Issue #3417: Selective
overflow:hidden)
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/20
CSS Variables
=============
Scribe: fantasai
Custom properties and serialization
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5685
TabAtkins: Question about precise details of earlier resolution about
serialization of custom properties
TabAtkins: Previously resolved to serialize back exactly as specified
TabAtkins: to avoid compat issues
TabAtkins: where authors would put content into custom properties
that wasn't properly parseable with CSS rules
TabAtkins: So if re-emitted with normal CSS normalization, changes
content
TabAtkins: e.g. UUIDs sometimes interpreted as scinot
TabAtkins: Question also is, does this apply to computed values?
TabAtkins: In issue, it's reasonably interop that computed values are
also preserved as specified
TabAtkins: except that var() functions are substituted
<TabAtkins> --y: /* baz */;
<TabAtkins> --x: /* foo */ var(--y) /* bar */;
TabAtkins: Here serialization of --x is three comments in a row
TabAtkins: I've put this in the spec
TabAtkins: Want to make sure rest of group agrees
TabAtkins: Also side issues, wrt non-custom properties containing
var()s
TabAtkins: whether those preserved or not
TabAtkins: and then registered properties
TabAtkins: With regards to computed value of custom properties,
though, is that preserved exactly aside from var()
substitution?
astearns: Cycles?
TabAtkins: Handled separately
emilio: We resolved recently that white space is trimmed
TabAtkins: Yes
TabAtkins: by Syntax spec
emilio: Aside from that, the rest should be preserved
<TabAtkins> spec text:
https://drafts.csswg.org/css-variables/#serializing-custom-props
fantasai: If we're not preserving in computed values it won't inherit
correctly; you could manage in serialization but why would
you if you have to preserve it anyway
TabAtkins: Unless objections, can resolve?
RESOLVED: Computed value preserves specified value (accept proposed
spec)
<TabAtkins> color: /* bah */ var(--x);
TabAtkins: Next part is non-custom properties using var()
TabAtkins: Here's an example. Normal serialization rules of color
wouldn't preserve comment
TabAtkins: Does this need to be preserved as well? Gecko does, but I
don't think Chrome does
TabAtkins: Chrome serializes this as var(--x)
emilio: If it doesn't then what does it do?
Rossen: Probably all comments are dropped for performance
Rossen: only tokens are kept
Rossen: Would have to go back and specify serialization
emilio: When talking with Chrome about this, they don't keep original
serialization but the list of tokens that was parsed, and
probably they dropped comments
emilio: when serializing need to be careful, insert comments in some
cases to preserve tokenization
emilio: In Gecko we preserve
emilio: input as-is
emilio: same rules as custom properties
emilio: We do trim white space
emilio: Other than that we keep the whole input as-is
TabAtkins: That doesn't seem to apply when there's not a var()
TabAtkins: Only do it when there's a var()?
<heycam> I think it makes sense for this to work the same way as
custom props themselves
emilio: That and environment variables yes
fantasai: So I don't understand
fantasai: In the example, if you use red instead of var(), the
comment doesn't get serialized
fantasai: Why would it get serialized if you replace red with var()?
fantasai: I would find that surprising
emilio: Because you need to substitute first in order to
tokenize (???)
emilio: If you red there, you know the exact syntax
emilio: keywords in colors are special, we do preserve that in
specified value
emilio: We keep an rgba value
emilio: and keep the ident for legacy reasons
TabAtkins: She's saying that, for any other normal property, when you
serialize, you serialize out the ?? value
TabAtkins: No direct relation to what author put in
TabAtkins: It's unclear why you're referencing substitution as a
reason to keep comments
TabAtkins: This is pre-substitution
TabAtkins: post-substitution
TabAtkins: ...
emilio: Other than actual values, we have uncomputed values which are
strings
emilio: We could keep lists of tokens, but is kind of tricky
emilio: but if we define something other than what author put in,
need to define how to serialize
fantasai: Still don't understand why keeping the comment
emilio: If using actual color, it gets parsed
emilio: Things that need substitution aren't parsed
fantasai: Still isn't making sense to me
Rossen: If we have substitution rules defined, would you align?
emilio: Yes
Rossen: Tab, would you want to specify?
TabAtkins: Both behaviors are allowed by syntax right now
TabAtkins: Can preserve comments or toss them
Rossen: Do we have any compat risk?
TabAtkins: Doubt it
Rossen: Do we need to worry about this issue?
Rossen: Or just say it's allowed?
TabAtkins: It's a CSSOM issue at this point
emilio: Willing to have interop on this
emilio: Would like to understand what chrome and webkit do
emilio: because need to preserve some stuff, but not others
emilio: If you put a UUID into a variable, do you actually serialize
integers?
emilio: Do you have same problem as custom property?
TabAtkins: If you put UUID into a custom prop and then it goes into
normal prop and somehow ends up valid
TabAtkins: then specified doesn't matter because didn't do
substitution
TabAtkins: Computed value doesn't matter because substituted already
TabAtkins: ...
emilio: Is it useful to have consistent behavior for custom
properties and normal properties?
TabAtkins: I think our answer is we parse into token stream, throw
out comments, reserialize (and have some errors in cases
which needs comments re-inserted)
TabAtkins: Could fix those bugs
emilio: Do you also toss the comments?
emilio: If you keep number token with integer on it, or do you keep
1e3?
TabAtkins: I don't remember
emilio: That's the interesting bit. If you serialize what author put
in, ff is more consistent
TabAtkins: OK, I'll open a new issue on CSSOM
fantasai: For consistency, what I'd expect is that non-custom
properties are consistent with themselves as much as
possible, and customs are self-consistent
fantasai: And once you do a substitution that can be consistent with
the original serialization rules...
fantasai: But outside of that substitution, I wouldn't expect
behavior to change, just because a keyword was swapped for
a var()
fantasai: Seems weird from a user pov
<astearns> +1 to fantasai
TabAtkins: OK, I'll open a new issue on CSSOM
TabAtkins: Registered properties with a syntax, should act the same
as a normal property
TabAtkins: I assume that's uncontroversial
emilio: Yes
RESOLVED: Registered properties same as normal property (whatever
that ends up being)
CSS Flexbox
===========
Should definite flex-basis make the main size definite?
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4311
dgrogan: Note in 9.8 ...
TabAtkins: That note should not be adding any conditions ever
dgrogan: Suggestion is to make this note normative and expanding
cases where flex item can have a definite size
dholbert: This is issue that biesi brought up last meeting
dholbert: I wanted to check what Firefox did
dholbert: I did follow up, and we do agree with the behavior that
cbiesinger and dgrogan are proposing
TabAtkins: This has nothing to do with the note
TabAtkins: This issue is about a flexible flex item with a definite
flex basis
dgrogan: That note is inaccurate
dgrogan: Definition of definite is you don't need to layout to get
its size
dgrogan: but many cases here has auto min size
dgrogan: If we go with this idea in the spec issue, can just get rid
of the note
dgrogan: I think we're all on board with the idea behind this
dgrogan: Do have question about a corner case
<dgrogan> https://jsfiddle.net/dgrogan/4r9npf3z/3/
dgrogan: The flex basis is 'content', but the height of ??? is
definite
dholbert: You're talking about 'height: definite'
dholbert: In that case height property is ignored.
dholbert: Only affects flex item if 'flex-basis: auto'
dgrogan: Child of the flex item with percentage
dgrogan: resolves against containing block
dgrogan: "percentage is calculated with respect to the height of the
containing block. If not specified explicitly, computes to
auto."
dgrogan: doesn't trigger behaves as auto clause
dgrogan: I suspect this is minor editorial oversight
dholbert: This is just CSS2 believing that only 'height' property can
affect height
dholbert: whereas in flex layout, there's other factors
astearns: So additional normative change that cbiesinger suggested,
sounds like we're in agreement to spec
TabAtkins: We will add 4th condition to definiteness of flex items,
that definite flex basis always make corresponding axis of
flex item definite
TabAtkins: Consequently can remove the note
astearns: further comments?
RESOLVED: Accept proposal and remove note
<br duration=12m>
scribe: emilio
Orthogonal column flex containers
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4221
fantasai: So originally if you have a horizontal document with a
section with vertical text, and that box is a block
container, we apply this implicit height on it so that the
line of text doesn't become super-long
<TabAtkins> quote from the issue: If you have a column flexbox that
is orthogonal to its parent, and whose flex items are
parallel (not orthogonal), per spec we pass the parent's
infinite available block size to the flexbox's inline
size, which then passes to the flex item, giving the flex
item an infinite available inline size without the flex
item itself being orthogonal.
<TabAtkins> <!DOCTYPE html>
<TabAtkins> <div style="display: flex; writing-mode: vertical-rl;
flex-flow: column; border: 40px double;">
<TabAtkins> <span>foo foo foo foo foo foo foo foo foo foo foo foo foo
foo foo foo foo foo foo foo foo foo foo foo </span>
<TabAtkins> <span>foo foo foo foo foo foo foo foo foo foo foo foo foo
foo foo foo foo foo foo foo foo foo foo foo </span>
<TabAtkins> <style>
<TabAtkins> span { border: orange solid 40px;; }
fantasai: So in flex and grid you have a bunch of items so you don't
really have this need to restrict the height of the flex
container for readability, just its items
fantasai: You could just allow it to get tall
fantasai: but it's kinda simple when you're setting up the orthogonal
flow to apply the restriction without looking at whether
its a block, which is what impl seem to do
fantasai: So the question is do we want to cap the height of the
orthogonal box, or the height of orthogonal blocks?
fantasai: The other question is whether we do want to change
behaviors if we choose the latter
TabAtkins: At least impls are interoperable on clamping flex
containers
TabAtkins: The flex container gets the ICB clamping as is currently
spec'd
florian: I suspect there's no reason to change, the viewport size is
an arbitrary measure
florian: If we have interop I don't see a huge motivation for changing
TabAtkins: That was our thoughts as well
TabAtkins: We should probably spec the interop
TabAtkins: Probably some small tweaks in flexbox+writing-modes
fantasai: I think mostly writing-modes
RESOLVED: Specify current behavior (clamp the orthogonal box, not
propagate the clamping to block children)
fantasai: The most common situation where I'd expect this to show up
is if you have a vertical-text table (because you can put
more content)
fantasai: If you have a vertical-wm table in an horizontal document
you prevent the table from growing
florian: Only when max-content > icb height, not min-content right?
fantasai: Right, is shrink-to-fit on the viewport
CSS Fonts
=========
@font-face supports incremental
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6063
myles: So the w3c has a web-fonts WG. For the past year or so it has
been working on tech to make fonts progressive
myles: Similar to how you load an image over a slow internet
connection you get an image incrementally
myles: The goal is to be able to load the part of the font that's
necessary to draw the relevant text, but be able to draw that
text before the whole font is downloaded
myles: It wouldn't look blocky like images, it's more about slicing
into glyph ranges etc
myles: It's not possible on fonts right now because you need data
from all over the file, so we're solving that
myles: There's a behavior change for content, e.g., if you style a
contenteditable div with these fonts typing might need to fall
back to another font
myles: so we think it should be opt-in
myles: The best way I think would be via the supports keywords in
@font-face
myles: so the proposal is to add a new keyword to the
`font-technology` production
myles: to say that it supports incremental
<fantasai> https://www.w3.org/TR/css-fonts-4/#font-face-src-parsing
florian: Is it worth looking at the other possibilities?
myles: The alternative would be "use a lot of js"
florian: Nope
emilio: One thing you mentioned is it may depend on the content being
styled
emilio: I don't see a great way to make it depend on the element
emilio: Maybe you want your contenteditable...
emilio: I don't have a better proposal
emilio: Might be worth looking into this being allowed per element
myles: so right now the strategy that we think makes the more sense
is to annotate the font loads and not the elements
myles: It'd be cool if the browser knew whether there was going to be
dynamic content or such
emilio: Isn't it like a will-change: content?
emilio: We have precedent for will-change:not-a-property
flackr: Yes there is
myles: Do you think we should only annotate the element, or *also*
the font-face?
emilio: I think the font-face makes sense too
myles: Ok so I think we can talk about these separately - could you
open an issue?
emilio: Sure
flackr: Curious about how this interacts with font-display
flackr: Do we consider a partially-downloaded font ready for use?
myles: I don't know the answer to that, do you think that's a blocker
for this?
TabAtkins: Probably not
RESOLVED: Add a `incremental` to the `font-technology` values
production as described on the PR
fantasai: Question: do we want to add this keywords to fonts-4 or
fonts-5?
fantasai: None of the stuff in 4 is implemented is it?
myles: The metrics override is in 4 I think?
fantasai: The override metrics is in 5 but the supports keyword is
in 4
fantasai: so I think we should move the new keyword to 4 or move the
whole supports thing to 5, since nobody implements any of
the other values either it seems
myles: No strong opinion
astearns: Given we have a PR, maybe let it land in place, tweak later?
fantasai: It's a commit, right?
myles: Yes
myles: There's no argument against what you're saying so it's fine
RESOLVED: Add this keyword in fonts-4 as well
CSS Overflow
============
Selective overflow: hidden
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/3417
florian: So the issue was raised about two topics but I want to focus
on one
florian: There's someone who wants some amount of things to escape
overflow: hidden
florian: The one I want to talk about is focus outlines
florian: because not seeing them is an accessibility issue
florian: There are various situations where this can happen
florian: One is you have a scroller
florian: Another is where the thing is completely hidden
florian: The problematic one is where the thing getting focus is
completely visible
florian: in the UI spec we say that UAs have a fair amount of
flexibility
florian: I don't think UAs take advantage of that
florian: but that's the question
florian: The issue was also hinting about positioned elements and
such, but we've talked about those
florian: but for outlines there's no great conclusion
Rossen: How are focus outlines different from other outlines?
florian: They have different purposes
florian: There's a special value that can be different,
`outline-style: auto`
florian: If you change it you are on your own but `outline-style:
auto` is intended to provide that flexibility
Rossen: On windows we don't have "native" outlines
Rossen: They're made to look and behave as similar to the ones in
the OS
Rossen: but they're not native
Rossen: They're native to the browser, and yeah there's a
default-ua-styled outline
Rossen: but (a) I don't believe this is any different than any
outline from outline handling point-of-view
Rossen: (b) if other outlines are specified by the user (e.g. excel
has multiple focuses etc)
Rossen: In all these things there's no "native" outline, it's
overridden by the app
Rossen: How would we know they're used as focus indicators to give
them this kind of behavior?
Rossen: So [restates]
Rossen: It'll be difficult to try and categorize these two buckets
and give them different behavior
Rossen: so I'd like this behavior to apply to both outlines
florian: But outlines can be decorative and that'd have no reason to
escape overflow
florian: so we'd need a different property or such
Rossen: If you want a different outline value that the UA can use for
its focus outlines, then that's reasonable
florian: I'm not saying we should do that, but if we do then we
should probably not make it automatic
emilio: Agree with Rossen. outline:auto can be special. Focus
outlines can look similar to carets - browsers currently
agree on what clips carets
florian: Difference with caret is that it's inside the thing, not
around it
florian: so you won't clip the entirety of the caret usually
florian: but yeah not sure it changes the main point
<dbaron> One thought, though, is about clipping of outlines on
elements that are clipped...
flackr: Two things. If we decided not to clip outlines, there'd be a
bunch of edge cases with partially-clipped elements
flackr: I'm concerned about getting that right from an aesthetic POV
flackr: Can we modify the clip box? Providing an extra space for that?
astearns: In some cases you don't know the dimensions of the outline
flackr: Yeah, won't solve all cases
Rossen: That was my idea with the optional outline value
Rossen: Would be per element, would expand the clipping bounds
Rossen: You have the ability of today (clipped) and the new thing
emilio: That would still cause the issue flackr raised - should not
show the whole outline and not the button in a scroller
dholbert: I have an adjacent scenario which is `contain: paint`
dholbert: If we are going to fix this in overflow: hidden, should it
also escape `overflow: clip` and `contain: paint`?
dholbert: and would it break `contain: paint`?
flackr: It would but for what it's worth you can expand the clip area
of `contain: paint` (`overflow-clip-margin`)
dholbert: Yeah, but assuming these outlines are sorta
implementation-defined it seems hard
astearns: Do you want a resolution for this? It seems there's
consensus on making this opt-in, but work on all outlines
florian: Yeah, that's enough discussion I think
smfr: I'm concerned about implementation complexity if we need to
track different bounds for outlines
smfr: I think I've heard "only outlines would be painted outside the
clipping area", but maybe that's not the case?
florian: We weren't describing precisely describing how it'd work
smfr: This is a source of incredible complexity for implementers
Rossen: I'd like to amend what I said, which is a compromised first
step would be to at least consider the "special" areas as
scrollable overflow
Rossen: In the specific use case here (something positioned and
overflow: hidden, then it's there)
Rossen: having these outlines add to the scrollable overflow would be
enough
Rossen: The second layer of having these outlines escape I agree is
very complex
smfr: The commenter was asking about escaping overflow: hidden, not
scrollable overflow right?
fantasai: Making them scrollable overflow will cause layout changes,
and you probably don't want that
smfr: We should make easy for authors to add the relevant padding
around things
???: Do native platforms have the same issues?
smfr: Yes
smfr: Another usecase of the proposal was tooltips, isn't there a
different proposal for that? anchored-positioning?
florian: Do you have links for that?
smfr: I think gregwhitworth was working on that
<smfr> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md
<smfr> melanie and others
astearns: Can you summarize and talk to the original proposer?
florian: We can close now and re-open if the OP is not satisfied
RESOLVED: Close with no change
astearns: It was interesting to go through the options and
strike-through all of them
florian: Yeah I thought it was better on a call than letting it
linger for a couple years
Received on Monday, 16 August 2021 22:18:40 UTC