- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 Jan 2024 19:17:07 -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.
=========================================
CSS Overflow
------------
- RESOLVED: Specify outline as ink overflow (PR #9824 | Issue #8649:
Specify extent of ink overflow)
CSS Align
---------
- RESOLVED: Alignment on scroll containers results in same layout as
non-scrolling containers, and doesn't affect whether
initial scroll position is zero-coordinate, just changes
which direction and how far you can scroll (Issue #4957:
What is supposed to happen to abspos in an end-aligned
scroll container?)
CSS Scrollbars
--------------
- There was more discussion to be had about testing for issue #9508
(Upgrade to Recommendation?) so discussion will return to github.
CSS Inline
----------
- RESOLVED: Choosing the innermost for textbox:trim for most
requested trim metric (Issue #5426: text-box-trim
accumulation)
- RESOLVED: ink-overflow spills out of the page content area into
padding and margins, user agents that can't draw ink
overflow may shift content down to avoid clipping (Issue
#5335: text-box-trim vs fragmentation)
- RESOLVED: Should text-box-trim apply at fragmentation breaks,
depend on the box-decoration-break property (Issue #5335)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Jan/0011.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Oriol Brufau
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Robert Flack
Paul Grenier
Chris Harrelson
Daniel Holbert
Brad Kemper
Jonathan Kew
Vladimir Levin
Chris Lilley
Eric Meyer
Noam Rosenthal
Jen Simmons
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Jeffrey Yasskin
Regrets:
Lea Verou
Chair: Rossen
Scribe: Frances
Agenda & F2F
============
Rossen: Are there any other topics to discuss?
<fantasai> https://lists.w3.org/Archives/Public/www-style/2024Jan/0004.html
<fantasai> https://github.com/w3c/csswg-drafts/issues/5426
<fantasai> https://github.com/w3c/csswg-drafts/issues/5335
Fantasai: I want to discuss text-box: trim accumulation and
fragmentation
Rossen: We will discuss it after the 3rd topic
Florian: F2F- Are there going to be lightning pitches this time? That
seemed like a good idea
Rossen: I don't see why not
CSS Overflow
============
Specify extent of ink overflow
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8649
github: https://github.com/w3c/csswg-drafts/pull/9824
Florian: Ink-overflow or scroll-overflow, made a pr for ink-overflow.
Need to discuss with the working group.
<chrishtr> +1 to ink overflow
Florian: Wasn't defined until now
fantasai: Correct that it needs to be ink overflow, because
scrollable overflow can trigger layout changes and point of
outline is that it doesn't cause layout changes
Noamr: Need to specify what ink overflow is
fantasai: Doesn't cause scrollable area to expand
noamr: but the extent isn't defined, that's what #8649 is about
[discussion about which issue to post to]
<fantasai> +1 to resolving on ink overflow
<dbaron> +1
Rossen: Outlines are in ink overflow. Any objections?
PROPOSAL: Specify ink overflow extent for outline
RESOLVED: Specify outline as ink overflow
CSS Align
=========
What is supposed to happen to abspos in an end-aligned scroll
container?
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4957
fantasai: We changed the way that we do scroll-coordinate in a
reverse flex container with initial position at 0 as the
position of everything and can scroll from there.
Implementations don't do it for alignment, need to make
content visible if scrolling off the start side of the
container for example.
fantasai: Match the implementations. Broader discussion in 4957 two
mental models for how they happen. Option 1: lay out as
normal, allow access to scrollable area in opposite
direction. Option 2: layout as start alignment, shift
scrollable area. We should go with the first option.
Florian: Constrained by compat?
fantasai: I don't think so.
iank: As long as it flips script-origin seems fine with me.
Rossen: Any other thoughts or objections?
PROPOSAL: alignment in a scroll container follows the same model as
reversing in flex box as implemented which is layout for
non scrollable containers that allow scrolling in the
opposite direction as necessary.
iank: Scroll origin concept to choose which point if in negative
space is actually negative. It is how implementations today
do it.
<iank> This is the concept we have in the spec currently
https://drafts.csswg.org/css-overflow-3/#scroll-origin
Rossen: From a fragmentation point of view?
fantasai: Layout point of view
fantasai: If no scrollbar, would not cause any content to shift its
position. What happens in the box should not move whether
overflow is on or off. In access by scrolling.
fantasai: Due to alignment, need to distinguish layout whether
different or not.
iank: Why not reference scroll origin in resolution? such as how they
behave in flex containers.
Rossen: Some consensus on the scroll origin.
iank: Resolve on the scroll origin?
fantasai: Resolve on behavior and solve implementation later.
fantasai: Current spec of initial scroll position and scroll origin
are distinct and might not be related.
fantasai: and we probably need to fix that
fantasai: so I don't want to rely on that definition
<fantasai> Proposal: alignment in scroll containers doesn't affect
layout wrt non-scrolling containers, just changes which
direction and how far you can scroll
<fantasai> Proposal: alignment in scroll containers doesn't affect
layout wrt non-scrolling containers or whether initial
scroll position is zero-coord, just changes which
direction and how far you can scroll
Rossen: any objections?
<fantasai> Proposal: alignment on scroll containers results in same
layout as non-scrolling containers or whether initial
scroll position is zero-coord, just changes which
direction and how far you can scroll
<fantasai> Proposal: alignment on scroll containers results in same
layout as non-scrolling containers, and doesn't affect
whether initial scroll position is zero-coord, just
changes which direction and how far you can scroll
RESOLVED: alignment on scroll containers results in same layout as
non-scrolling containers, and doesn't affect whether
initial scroll position is zero-coord, just changes which
direction and how far you can scroll
CSS Scrollbars
==============
Upgrade to Recommendation?
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/9508
chris: css scrollbars have not changed much. 115/115 for chrome,
edge, and Firefox, safari a little bit less. Accessibility
concerns are scrollbars do not meet AA and scrollbars with
people in cognitive disability. Both flagged.
Florian: Some tweaks to the bike shed, some notes that we changed to
draw a diagram. Should draw a diagram, we have a bunch of
tests, but I think they are incomplete. Some tests are not
according to the spec. Testing specified and out of scope
elements.
Florian: The tests assume the feature works at all, and if that's
true, test other assumptions. But there's no test for
whether the feature works at all. Very few tests do it
correctly currently.
Florian: If make track transparent, scrollbar might have up and down
buttons or the spec might use color only and do a gradient
if rounded or shaded. Some tests assume wrongly behaviors
and implementations.
Florian: Not an issue with the spec, it is an issue with the site.
Authors should not do this. Just because there is white text
on a white background, would be bad to test possibly since
it is not realistic.
PaulG: When a developer alters a user-agent component take on the
onus of passing from most auditors, such as changing colors
from 3 to 1, it would fail. If we don't accommodate 3:1 the
target size would not work with auto. Transparent is a visual
affordance.
Emilio: It is a good way to provide a scrollbar:hover.
Florian: Spec already contains a fair amount. If aspects that are
missing, would be welcome to adding them.
CSS Inline
==========
text-box-trim accumulation
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/5426
fantasai: Consider an example with a div where inside there is a p,
both asking for text-box:trim. Shared by two elements
nested inside each other, which trimming should we perform?
Such as different metrics?
fantasai: Can choose outer most or inner most or most constrictive
one. Inner most is most specific, the alternative would be
outermost to match up with something outside.
fantasai: Which one would be the most appropriate metric?
florian: If a sense of which one is right we can choose it, or we can
implement the use case driven one.
Rossen: if strong use cases come, would be much easier to select.
<dbaron> innermost seems reasonable, at least
PROPOSAL: Choosing the innermost for textbox:trim for most requested
trim metric.
RESOLVED: Choosing the innermost for textbox:trim for most requested
trim metric
text-box-trim vs fragmentation
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5335
fantasai: One consideration is when requesting text-box:trim, if it
lands at the top of the page, we have ink spilling out of
the page. Currently gets clipped out. If specifying cap
height and land at the top of the page, accent marks will
get clipped.
fantasai: Do we want to specify that ink-overflow can spill onto the
padding area and if so do we want to allow implementations
to pull content. How to approach the problem of clipping?
fantasai: Other question is, if the paragraphs fragments in the
middle, do we trim at the bottom of the page or at the next
page? We need some way to control it and make it happen,
with a consistent top edge.
<bradk> +1 to allowing ink to spill over, similar to box-shadow
fantasai: If using text-box-trim for correct spacing between content
and border, don't necessarily want to trim at fragmentation
breaks. Two issues: clipping and separate control for
fragmentation breaks.
chrishtr: Because it is more difficult to implement with more
complexities, text-box-trim does not apply for printing
Rossen: Allows for additive behavior in the future. Need to specify
it correctly.
<astearns> -1 to not applying to print. Would there be a way to allow
it in print except for at page breaks?
Florian: Need to define cleanly the boundary. In typography such as
using css to make printed material or like printing. About
fragmentation, should not say print, possibly relevant.
Florian: Needs to work for printing. We need to work on this and not
call the compat trap.
fantasai: Shouldn't disable trim for printing, need to spec the ideal
behavior to the extent that it can be printed. Might allow
user agents that can't do that, shift it down the page to
use the text glyphs.
chrishtr: The two together sound fine.
PROPOSAL: ink-overflow spills out of the page content area into
padding and margins, user agents that can't draw ink
overflow may shift content down to avoid clipping.
<fantasai> +1
rossen: Objections?
RESOLVED: ink-overflow spills out of the page content area into
padding and margins, user agents that can't draw ink
overflow may shift content down to avoid clipping
fantasai: A question around text-box-trim taking affect. Should be a
separate property to control them indepdently.
chrishtr: Just operates at the top of the first fragment and the
bottom of the last fragment, not overflow between columns.
fantasai: I'd want it to follow box-decoration-break
PROPOSAL: Should text-box-trim apply at fragmentation breaks, depends
on the box-decoration-break property
Rossen: Objections?
RESOLVED: Should text-box-trim apply at fragmentation breaks, depend
on the box-decoration-break property
<chrishtr> Thanks all!
fantasai: Fragmentation case possibly need an independent control.
Could be a separate feature.
Received on Thursday, 25 January 2024 00:17:42 UTC