- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 4 Nov 2020 09:51:55 -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.
=========================================
Fragmentation
-------------
- Before resolving on issue #4989 (Rules for direction to use when
slicing inline borders for box-decoration-break:slice are
unclear) there needs to be additional use cases from
internationalization. r12a will add examples and then the group
will re-discuss.
- RESOLVED: Ink overflow does not cause new fragments to exist, and
does not fragment (Issue #4099: Specify that ink
overflow doesn't fragment?)
- RESOLVED: Work on a mechanism to control where slicing is allowed
as a length from either side of the monolithic element
(Issue #3405: Orphans and widows for fragmented
monolithic replaced elements)
- RESOLVED: Add "break-inside: allow" to enable slicing of images
even if they could fit in the next page (Issue #3404:
Should fragmentation of block-level replaced-elements be
configurable? ("object-slice"))
- Adding a 'never' value to break-inside, which would prevent
slicing if slicing would be necessary and instead cause
clipping, will be discussed in a separate issue where use cases
can be compiled.
CSS Overflow
------------
- RESOLVED: scrollWidth/scrollHeight ignore overflow:clip when
computing the value (Issue #5572: CSSOM scrollWidth/
scrollHeight behaviour of “overflow: clip”)
CSS Display & CSS Pseudo Elements
---------------------------------
- RESOLVED: ::marker::marker is invalid (Issue #1793: Is ::marker
created by display:list-item or does it always exist?)
- RESOLVED: Computed 'display' on ::marker drops 'list-item' keyword
(Issue #1793)
CSS UI
------
- RESOLVED: Adopt accent-color as a hint to the UA, with
requirements on contrast (Issue #5187: Allow specifying
the "accent color" of a form control element)
- RESOLVED: Mason Freed added as UI 4 editor
CSS Pseudo Elements
-------------------
- RESOLVED: Remove ::inactive-selection from Pseudo 4, and add an
issue on MQ to add an active-window media feature (Issue
#4579: ::selection vs ::inactive-selection)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2020#agenda-schedule
Scribe: fremy
Fragmentation
=============
Rules for direction to use when slicing inline borders unclear
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4989
fantasai: dbaron said the rules for box-decor-break slice are not
clear on which direction you should use for the splicing
fantasai: either the inline element itself
fantasai: or the parent block
fantasai: and I would suggest to use the inline
fantasai: For example if you used a rainbow gradient it should
splice in the direction of the element
florian: I am confused about what the alternative would do
florian: but I agree that what you described sounds like the right
solution
Rossen: ok sounds reasonable
Rossen: any objection to resolve this?
* r12a wonders what happens with latin text wrapping inside an
arabic paragraph
Rossen: (repeats r12a question on irc)
r12a: If you write "unicode conference" and "conference" moves
to the next line
r12a: and in this case it would not to that in terms of what the
text actually does
r12a: but in terms of rendering maybe it does
florian: For the border, you want the side that is the side on the
end of the line to be open
florian: but that doesn't match what we just discussed with the
background
r12a: Yes, we should probably look at a few examples
r12a: I can provide examples if the group wants
Rossen: that sounds great
Rossen: (the examples)
Rossen: fantasai does that change your mind?
<r12a> https://r12a.github.io/scripts/tutorial/part5#latin-in-rtl
fantasai: Yes, let's take another look after we considered all the
examples
Rossen: Ok, if the examples don't break everything (no pun intended)
we will resolve what we decided
Rossen: but otherwise we will re-discuss
Specify that ink overflow doesn't fragment?
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4099
fantasai: We don't specify if ink-overflow gets paginated or not
fantasai: I think we should say it does not
fantasai: that's my proposal
<astearns> +1 from me
Rossen: That sounds like a reasonable resolution indeed
<jfkthame> +1
myles: If it doesn't cause scrollbars it shouldn't cause new pages
fantasai: That was my reasoning
Rossen: ok, any objection?
smfr: Also box-shadow?
fantasai: Yes
fantasai: If it renders across adjacent columns, that's fine
fantasai: but it should not fragment in the fragmentation direction
Rossen: So if the box shadow is long, and it goes beyond the end of
the page
Rossen: then we don't create a page for that shadow
Rossen: but if there is content that generate the page, then we
don't drop the shadow
smfr: Yes, both cases were things I considered
florian: Ink overflow does not cause new fragmentainers to exist
florian: I don't think we have reached consensus on the first
question if the fragmentainer exists anyway
fantasai: These are things you don't want to slice though, such as
parts of glyphs that are outside the bounding box
fantasai: So if the things that generate the shadow is in two
fragmentainers, you get it in both places
fantasai: but if there is no reason to draw it because the item
itself doesn't fragment, then you don't draw it
<astearns> I agree with fantasai on where ink overflow should get
rendered
Rossen: We can split in two resolutions
Rossen: The first one is mature
Rossen: whether or not you create a new fragment
Rossen: depends on content
Rossen: and ink overflow does not cause the creation of a new
fragment
fantasai: What I want to define is that you don't fragment ink
overflow. Neither can it cause new fragmentainers, nor can
it be sliced across them if they exist
Rossen: That would be the combination of the two resolutions
<faceless2> +1 to Elika's proposal.
jensimmons: Something I have seen is that the shadow sometimes
appear at the top of the next column and it's weird
iank: We consider that a bug indeed
Rossen: Let's try to take the super resolution
Rossen: The ink overflow does not cause new fragments to exist, and
does not fragment
RESOLVED: ink overflow does not cause new fragments to exist, and
does not fragment
Orphans and widows for fragmented monolithic replaced elements
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3405
fantasai: This is a feature request for fragmentation level 4
fantasai: It would be nice to control widows/orphans on
monolithic boxes
fantasai: It would be a length instead
fantasai: and thus cannot inherit so we need a new property
fantasai: It would say how much space you need on the page to accept
and fragment vs push in the box to the next page
fantasai: Proposal would be widow-something: <length> or something
faceless2: I don't think the name should be widow/orphan its a
different concept
florian: Maybe I misremember but I think we are not supposed to
split monolithic elements at all
florian: so the default value should be 100% right?
florian: (split only happens if you cannot fit)
fantasai: We want to control that
fantasai: And that is the next issue
florian: Why a different toggle?
florian: If you have 100%
fantasai: Yes, but break-inside is more reasonable to find for
authors
florian: Yes, that's true
Rossen: Are we discussing accepting the proposal?
myles: Is my understanding correct to say that they don't
myles: like when 3px of their image appears at the end of a page
myles: and the rest gets displayed on the next page?
fantasai: Yes
myles: Ok
Rossen: Any other thought?
florian: I am not sure it's a different than the break-inside thing
florian: For example on some images there might be only three points
where you want to break
<tantek> interesting, the image breaking equivalent of soft-hyphens
Rossen: Is that a reason to hold off on the proposal?
florian: I think it's weird to have a toggle for something
florian: that we can't do yet
fantasai: We slice if it doesn't fit
florian: but we might want different if it is forced or not
JonathanNeal: Seems to be refinements of break-inside to me
JonathanNeal: so sub-properties of break-inside
<florian> +1 to jfkthame
fantasai: We don't control where you can break via break-inside
fantasai: break-inside, so far, is only whether you can break or not
fantasai: I think this is a good separation to have
myles: Also, there are two values, bottom and top
myles: If the sum is bigger than 100%, what happens?
fantasai: Can't break anywhere
florian: But then you are back to the case where you have to
differentiate whether you are in the normal case or the
error case
fantasai: If needed you slice wherever (if the unbreakable item
is larger than the fragmentation container)
myles: In the case I described, we would not slice though, right?
fantasai: You slice
myles: I am confused
myles: let me restate
<myles> you have an image that's 100px tall
<myles> the fragmentainer is 75px tall
<myles> and you use both of these properties to say "don't break
within 80px of the top and don't break within 80px of the
bottom"
<myles> <fin>
<myles> this would overflow, right?
Rossen: (btw we only try to decide if we want to work on this, don't
need to have all the details nailed in)
fantasai: Several things happen
fantasai: Let's start with 120px fragmentainer
fantasai: In that case, we move the image to the next fragmentainer
fantasai: Now, if the fragmentainer is smaller as you said
fantasai: we are going to ignore the restrictions
fantasai: so we do slice at 75px
fantasai: though in theory, the UA is allowed to break anywhere
fantasai: There is a further proposal to add toggles for this, but
this would remain an opt-in
fantasai: by default we make sure all the content is rendered
myles: Got it
Rossen: So, do we feel we want to pursue this?
Rossen: and add to break-4
Rossen: Any objection?
RESOLVED: Work on a mechanism to control where slicing is allowed as
a length from either side of the monolithic element
Controlling fragmentation of block-level replaced-elements
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3404
fantasai: The issue is that, for replaced elements, we can't control
whether they are breaking or not
fantasai: We would like to add a control to say "hey, even if you
could avoid slicing, you don't need to"
fantasai: The proposal was to add a new property for this
fantasai: I would rather add a value for break-inside
fantasai: then if you specify new "allow" value, we trigger this
behavior
fantasai: auto is avoid for replaced and allow for non-replaced
fantasai: In the future, we can also add "never" which is not like
"avoid" because it doesn't even slice, it justs get clipped
fantasai: This should be a different issue though, let's walk back
fantasai: I would like to propose "break-inside: allow" that would
enable to slice a replaced element
florian: We should accept this, otherwise what we accepted in the
previous issue doesn't make much sense
florian: so I am in support
Rossen: Any other thoughts?
Rossen: Hearing no other remark, let's call for objections
RESOLVED: Add "break-inside: allow" to enable slicing of images even
if they could fit in the next page
fantasai: Can we discuss the "never" value?
fantasai: I would like to suggest taking this here
fantasai: We add "never" which prevent slicing if slicing would be
necessary, and then we just clip
fantasai: It's fine because it's an opt-in
Rossen: Do we want to resolve this now?
Rossen: The name "never" seems a bit too strong
florian: That's not the meaning of never we want here
fantasai: We just overflow and clip
myles: The last issue we said the reverse
florian: Yes, that is the 'avoid' behavior
florian: The proposal is to add a new behavior
faceless2: But you have to print it right?
faceless2: Engines don't slice an image now
fantasai: I am pretty sure it's not true
fantasai: 'avoid' allows to slice across pages as a last resort
florian: This proposal is to disallow that
<jfkthame> +1 to florian
Rossen: The name confused me
Rossen: but this could be lack of caffeine
Rossen: Do we really want to take this now?
Rossen: It's a break 4 thing, let's maybe open a new issue
Rossen: unless fantasai you feel strongly we should resolve now
fantasai: No we don't need to, but it would be nice
Rossen: And the resolution we just took covers that no?
fantasai: No it's a different behavior. We discussed allowing things
to break without avoidance, that currently avoid breaking
(by moving to a next page first). The other option
discussing now is to forbid breaking.
Rossen: Ok, let's resolve on keep working on this
Rossen: but with keyword tbd
myles: Reading through the thread, one of the issue is that there
are no example use cases
myles: and I think it would be useful to have them, because we could
hit cases
myles: like what you can fit in the first column would be 1px
myles: so we should think about this more
Rossen: The way I'm perceiving this is very similar to ink-overflow,
it's just decorative like it's an image but it works like a
shadow or something
Rossen: I need that decoration to take some space, but when printing
I don't care about it
Rossen: At least that's what I understood
Rossen: but I don't know how frequently this is needed
florian: If that's the use case, you don't need that behavior
florian: because you don't want to push if possible to the next page
myles: Yes, in this case, you don't want the decoration at the top
of the next column
myles: so this is not what we described there
florian: Ok, let's open a new issue to review use cases
Rossen: Let's move to the next issue
CSS Overflow
============
CSSOM scrollWidth/scrollHeight behaviour of “overflow: clip”
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5572
Rossen: iank raised this and emilio last added to the agenda
Rossen: Who want to bring us up to speed?
emilio: Me.
emilio: We considered what scrollWidth/Height should return when
overflow:clip is set
emilio: there is no scrollbar
emilio: but there is content out there (invisible)
emilio: The question is should we return the size as if there was
scrollbar
emilio: I think acting as visible is easier
emilio: but iank said there is an optimization if we don't include
any of the overflow
<TabAtkins> +1 to behaving the same as visible, at least from first
thoughts
iank: If you have overflow:hidden, can be scrolled
iank: For visible, it still makes sense to return the full value,
because it will cause scrollbars on ancestors
<TabAtkins> Hm, okay, Ian's making sense
iank: When you clip though, it's not useful, because it really does
not exist
iank: but if you don't do that, you can return early
iank: because you don't need to calculate the scrollable overflow
for the element when the value is fetched
iank: but it's not super important and only works if clip is in both
directions
smfr: The other option was what?
iank: Report as if you had no children
iank: If the size is definite and you clip overflow, you don't need
to layout the children
iank: but it's a small case
smfr: And offsetWidth/offsetHeight?
iank: Yes, this is the same as what I had in mind
smfr: Oh, in that case, yes, I prefer that option slightly
Rossen: Other opinion?
iank: If I had to choose I would probably try to keep things
consistent, but I really don't mind
iank: We just need to do something
Rossen: Ok, let's get a summary of the two options and resolve
iank: Option 1 is to do what we do when overflow:visible is applied (
you need to layout the children to report that width)
iank: Option 2: (ignoring overflow-clip-margin) report the size of
the element ignoring whether or not you have something that
will be clipped
iank: but if you have a clip margin, you need to do the full
computation to see where inside that margin you land
Rossen: (restates the two proposals)
fantasai: scrollWidth scrollHeight are asked on an element which is
not scrollable
fantasai: Does that mean they are defined on all elements?
emilio: Yes
fantasai: Ok, then, if we have a clipping, what happens if you have
a border?
iank: They return content-box sizes, so it's a bit complicated
fantasai: Padding box you mean?
iank: Yes, padding box size
iank: If you have no children, this is clientWidth/clientHeight,
which is the padding box
iank: If you have a child, it returns whichever is bigger (the
padding box or that child)
iank: So if you set overflow:clip with no margin, you can return the
padding box because the child will not overextend
iank: but this only works if you don't have a margin
iank: If you have a margin, there could be an overflow
iank: so you need to do the full computation
fantasai: The advantage of doing like visible is that you get
the value that tells you "how big should it be not to
overflow"
fantasai: The advantage of taking the clip into account, is that you
know how much you will ask the parent scroller
iank: With proposal 2 you can't get answer 1
iank: but with proposal 1 you can compute the difference yourself
Rossen: This seems more clear now
Rossen: For "what you see is what you get" option 2 is nicer
Rossen: I don't want to do a straw poll, let's try to resolve
Rossen: Can we resolve on option 2 which takes into account the
visual clipping?
emilio: I lean towards option 1
emilio: because I don't see strong arguments
emilio: and for testing purposes, we can copy all the tests
emilio: and we have shipped like that
emilio: But this is not a super strong argument
emilio: but given option 2 removes your ability to get the value of
option 1
emilio: I would rather we did 1
Rossen: If you want to get the bounds for the clip, what do you do?
iank: In script, you get the style of the clipping, then you do
Math.min
iank: between scrollWidth and offsetWidth + the clip margin
Rossen: Authors might not think about it
Rossen: and very often it's more useful to consider what is visible
emilio: I don't disagree it's useful
emilio: but scrollWidth is not the right API for that
emilio: It's weird and legacy, so I would rather not change it
Rossen: ok let's do a poll
Rossen: because it's pretty split
<fantasai> Given the arguments in favor of emilio's position, and
the fact that you can get answers to the second question
fairly easily with the first option but not the other way
around, I'd be in favor of emilio's position
smfr: If we have scrollWidth not behave like overflow:visible
smfr: then you can't get the data and know if you can flip to
visible without overflow
fantasai: Yes, option 2 hides info from authors you can't get
otherwise
fantasai: It's not great
Rossen: Pk, then let's resolve for option 1
RESOLVED: scrollWidth/scrollHeight ignore overflow:clip when
computing the value
CSS Display & CSS Pseudo Elements
=================================
scribe: florian
Existence of ::marker::marker
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/1793
<fantasai> https://github.com/w3c/csswg-drafts/issues/1793#issuecomment-708072107
fantasai: This is a follow to previous decisions on ::marker
fantasai: we didn't want to have infinite markers
fantasai: so you cannot have ::marker::marker
fantasai: Right now ::marker doesn't accept the display property,
so can't anyway.
fantasai: But, is ::marker::marker invalid?
fantasai: And, in the future, if we want to allow display on ::marker
fantasai: then do we force it to compute 'display' so that it loses
its 'list-item' keyword?
Rossen: So, taking things one at a time, should we allow
::marker::marker
fantasai: I'd like to make it invalid
TabAtkins: Browsers don't support it
<tantek> +1 on no ::marker::marker
oriol: Implementations are behind flags, so not too relevant
oriol: In firefox, no nested pseudos
oriol: In chrome ::before::marker and ::after::marker work, but
::marker::marker doesn't
oriol: but then the styles don't quite work anyway
oriol: so I'd prefer to keep it invalid
Rossen: Any objection to ::marker::marker being invalid
RESOLVED: ::marker::marker is invalid
fantasai: In the future, when display applies to ::marker, should it
lose the list itemness
oriol: Seems reasonable
Rossen: Me too
RESOLVED: Computed 'display' on ::marker drops 'list-item' keyword
CSS UI
======
scribe: TabAtkins
scribe's scribe: fantasai
Allow specifying the "accent color" of a form control element
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5187
masonfreed: Summary is I closed the "interoperability thread" -
question I was trying to ask was whether we wanted
precise control over where accent colors should go on a
control
masonfreed: Think I got the answer I needed - we don't want to do so.
masonfreed: Majority opinion seems to be that we want this to be
more of a hint to the UA - "accent-color: purple" means
"use purple on this control if you can if it makes
sense".
masonfreed: Not "put this purple on the checkbox background", more
of a hint instead
masonfreed: So I'd like to get a resolution from the group on this
direction
TabAtkins: I'm not sure this is exactly the right direction, fine
with it as long as we adopt something like what fantasai
said, where we require the UA's chosen colors contrast
appropriately with the accent-color
TabAtkins: UA can't put black on black if you specify
accent-color:black
TabAtkins: With that, sounds fine
Rossen: You can't ignore the accent color?
fantasai: Can always ignore it...
jensimmons: I think the way Mason described is really good, more
realistic to where we are
jensimmons: More time to solve the problem of robust styling
jensimmons: Allows us to give authors something useful and gives us
time to solve the problems more robustly
florian: Roughly in line with all that. As long as the hint involves
the requirement that contrast must work.
florian: Don't think we have a resolution on one vs many colors, but
we can decide that later
florian: I think there is an appetite for precise control, but that
requires a more robust solution. Should do that too, but
shouldn't conflate with this.
Rossen: Taking the lack of queue as meaning we've said everything we
need. Objections?
Rossen: proposed resolution: adopt accent-color as a hint to the UA,
with requirements on contrast
<tantek> I think we're ok with that too
RESOLVED: Adopt accent-color as a hint to the UA, with requirements
on contrast
masonfreed: We probably need to discuss the 1 vs many colors
question later
Rossen: yes
fantasai: I think we should put this into UI 4, should we let the
editors put that in, and discuss 1 vs many colors
separately?
astearns: Would Mason like to become an editor?
masonfreed: "want" is strong, but I'm willing to do it
florian: Happy to have help
fantasai: There is proposed text already
Rossen: Objections to adding Mason as UI 4 editor?
RESOLVED: Mason Freed added as UI 4 editor
Pseudo Elements
===============
::selection vs ::inactive-selection
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4579
fantasai: We'd talked about replacing the selection/
inactive-selection distinction with a MQ for whether the
parent window is inactive
fantasai: So question is if we're actually doing that, should I
remove ::inactive-selection from Pseudo and open an MQ
issue?
florian: Seems good, but it seemed there was an active question
about how much nuance there is about active vs inactive
iframes?
fantasai: It seemed commented that we could get by with just the
two, but we can make this an issue for the WG.
TabAtkins: Since impls don't have ::inactive-selection anyway, we
can decide that later?
GameMaker: Looking at the PDF at the bottom, I made a comparison of
all browsers
GameMaker: Can't recall exact thoughts at the time, but based on
these results, I was fine with making a MQ
Rossen: So what's the proposed resolution?
fantasai: Removed ::inactive-selection from Pseudo 4, and add an
issue on MQ to add an active-window media feature
Rossen: Objections?
florian: Are we removing it while we're thinking about it, and it's
gone? Or will we maybe put it back?
florian: Asking because we have tests for this - should I mark as
tentative, or delete?
fantasai: Mark as tentative until we're totally finished on this
issue. Good chance we can just revise them later
RESOLVED: Remove ::inactive-selection from Pseudo 4, and add an
issue on MQ to add an active-window media feature
Received on Wednesday, 4 November 2020 14:53:01 UTC