- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 10 Sep 2023 11:33:25 -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.
=========================================
Lightning Pitches
-----------------
- Topics introduced in the lightning pitches were:
- Advanced Transforms from SebastianZ:
https://github.com/SebastianZ/advanced-transforms/blob/main/README.md
- Animation Trigger from ydaniv:
https://github.com/w3c/csswg-drafts/issues/8942
- Filters from ydaniv:
https://twitter.com/anatudor/status/1669878134932488194
- Dynamic Range Limit from ccameron
- Interop on display:contents focusability from dbaron
- CSS @config from bramus:
https://gist.github.com/bramus/2d321f7558708f4da4c7138e0c3502c2
- Fixing Counters Nonsense from fantasai
https://github.com/w3c/csswg-drafts/issues/9076
- Feature detection for Nesting from SebastianZ:
https://github.com/w3c/csswg-drafts/issues/8399
- CSS Grid and Flexbox should not be 3-5 years out of date
due to missing/unindexed tests from fantasai
- More Animation Timelines from bramus:
https://gist.github.com/bramus/512cad694ad94cde1ba54c9864372698
- Catering for Scrollbars from bramus:
https://gist.github.com/bramus/bcca5788d8ced82837180b7a15760c84
- SVG's Future from fserb:
https://lists.w3.org/Archives/Public/www-archive/2023Jul/0001.html
- Flowing Multiple Grid Items together into 1 cell from TabAtkins
- color-scheme responsive colors from emilio:
https://github.com/w3c/csswg-drafts/issues/7561
- position:fixed viewport from bramus:
https://gist.github.com/bramus/903de19ef7bc2353e9edb6eb873955ae
- Ellipsizing of text in middle of string from SebastianZ:
https://github.com/w3c/csswg-drafts/issues/3937
- Typographical Orphans from myles
- If anyone is interested in one or more of the topics introduced
during the lightning pitches, please reach out to the person
pitching to discuss further.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/38
Scribe: myles
Lightning Pitches
=================
[Note: These are a series of short introductions to topics that
working group members are interested in. The intent is to gather
awareness and/or interest for these topics which can lead to
further offline conversations.]
Advanced Transforms
-------------------
<fantasai> ->
https://github.com/SebastianZ/advanced-transforms/blob/main/README.md
SebastianZ: Currently we just have transforms like translation,
rotation, etc. But they were already some requests for
more advanced transforms.
SebastianZ: Bending elements around a center.... There was an
advanced approach via CSS shaders (pixel and vertex
shaders)
SebastianZ: There is a vertex suggestion. Like a vertex grid that
you can lay on to the element and transform the
different vertices
SebastianZ: This would be like this approach <points> directly
expressed in CSS
SebastianZ: Like a trapezoid. You could translate each vertex around
by 10% etc....
SebastianZ: More advanced transforms are possible so you could bend
or twist
SebastianZ: You could do animation too!
SebastianZ: Please message me if you have ideas
Animation Trigger
-----------------
<ydaniv> https://github.com/w3c/csswg-drafts/issues/8942
YehonatanDaniv: This is a new property for animation.
animation-trigger.
YehonatanDaniv: This one has an issue ^^^
YehonatanDaniv: Basically, this takes the existing syntax of ranges
and timeline ranges for view (and other things) and
then there are more advanced options (like how the
trigger will be hit)
YehonatanDaniv: It's using the ranges for trigger, not for
progressing the animation from 0-100, but just to
toggle the boolean value
YehonatanDaniv: It's mostly being worked on in the issue. I'm
discussing this here to get more attention. Can we
move this forward?
YehonatanDaniv: There will be other related issues, but if this
progresses that would be good
YehonatanDaniv: Regarding advanced triggering, we could have 'once',
'alternate', and 'repeat'
YehonatanDaniv: There is more explanation on the issue
Filters
-------
YehonatanDaniv: Next one! About filters. I'm not sure how far we
can get.
YehonatanDaniv: There was a tweet that I commented about
<ydaniv> https://twitter.com/anatudor/status/1669878134932488194
YehonatanDaniv: Expanding the capabilities of filter effects
YehonatanDaniv: Importing more effects from SVG to CSS, because
people are using that stuff and it's missing. It's
not hardware accelerated. There's some web compat
issues in some cases. It's not really animatable
easily
YehonatanDaniv: The question is: How to move this forward? Should we
progress this in SVG or CSS? How to start a
discussion? An open question to the folks here.
<una> I would be interested in seeing how we can more easily port
SVG effects in CSS 👍
Dynamic Range Limit
-------------------
ccameron: Time to share!
ccameron: Hi! I am chris, talking about an idea for a CSS property.
ccameron: HDR for a 2 minute talk is "brighter than #ffffff" like
images or video. It's here and there. It already exists.
Already than CSS + Canvas. Most displays can do this. SDR
is good but HDR is better
ccameron: You might want things that are _not_ quite as bright as HDR
ccameron: <shows images about what stuff could look like>
ccameron: People who have a mixed SDR/HDR gallery say it looks bad,
so they are asking for either "no HDR" or "just a
liiiiittle bit of HDR"
ccameron: This could be a CSS property. But what kinds of units?
Maybe units of headroom? There's an API on iOS / macOS
that has 3 values: High / constrained-high / standard.
ccameron: So you just turn on `dynamic-range-limit:
constrained-high` for the whole gallery but override it
for a particular image maybe
ccameron: animation should be non-discrete
ccameron: What should the default be? who knows!
Interop on display:contents focusability
----------------------------------------
dbaron: This is a little different. I'm pitching NOT a new feature,
but instead a change about interoperability
dbaron: We designed the display: contents feature because the thing
doesn't have a box but it's still there because it's
children exists. We made design decisions like "should be
exposed to assistive technology"
dbaron: It's supposed to be focusable per spec. But that's not
implemented anywhere. I have a patch for this in Chromium.
Let me explain why
dbaron: When I talk to people who know a lot about accessibility,
they say "there is no single type of disability"
dbaron: People use the web in lots of different ways. Different
kinds of input & output in most of the imaginable
combinations
dbaron: So what you expose to AT should be consistent with keyboard
tabbing order. Because hearing the page might also be
tabbing through with the keyboard. or maybe looking at the
screen. Maybe consistency between screen and keyboard is
necessary.
dbaron: Right now elements with display:contents are exposed to AT,
and AT says "there's a something there" and users expect all
of those things are focusable and they can tab to them, but
this one magically they can't tab to because it's
display:contents. We didn't tell them it's display contents.
We want this to be consistent.
dbaron: That's the basic argument for why elements with
display:contents be focusable. Because what we're exposing
to AT should be consistent with keyboard navigation. There
are some complexities (about outlines) which can be solved
by the CSSWG or authors. But that's a less bad problem than
having content disappear
CSS @config
-----------
<bramus> https://gist.github.com/bramus/2d321f7558708f4da4c7138e0c3502c2
bramus: This is a controversial idea that's been in the back of
my mind
bramus: I have seen the need for authors to configure something on
the page. Should be do-able from CSS. Like view transitions.
Or for contents of <meta>
bramus: Like viewport, resizing behavior for virtual keyboards
bramus: I haven't through this through fully. Perhaps @config that
could include "interactive widget"
bramus: Maybe extended to global rendering switches like "type of
scrollbars" or "change where position:fixed elements should
be" or "disable margin collapsing"
bramus: There should be some requirements. Most values should only
be set once, cannot be changed on the fly. Don't want to
change the scrollbar type during the lifetime of the page.
bramus: Maybe view transitions could be change-able
bramus: For a media-query, you'd want to be able to change that value
bramus: This might work in today's browsers. This is not an
all-of-nothing opt-in, you can pick what you want. And it
will work within @supports to have graceful degradation
bramus: This will complicate things for authors (maintain 2
different codepaths)
bramus: that might be tricky
bramus: This is a starting point for future discussion
Fixing Counters Nonsense
------------------------
https://github.com/w3c/csswg-drafts/issues/9076
fantasai: There is a thread on twitter. The test case looks like
[shows]
fantasai: There's an <ol> with some items. After that there's a
section, and another list. Nested lists. Ok
fantasai: After that there's another <ol>
fantasai: We like list numbers with 1.7.3 style, and there's a
function like that named counters()
fantasai: it joins up all the counters so you get 1.2.3
fantasai: There's our first list. Great, looks correct
fantasai: Then, why is this section not....?
fantasai: Where does the 3 come from? Why are there multiple 3s!
fantasai: The scope of the list counter extends to its siblings
fantasai: counter-reset scope doesn't go to the children but it also
goes to the siblings (because counters are supposed to
work on headings)
fantasai: but then now the counter has expanded to our section. It
doesn't get incremented to 4 on the section, because the
section doesn't have an increment. So then we create
another counter over here...
fantasai: So this inner one has 2 levels of nesting, so we get 3.1,
but that's not what we wanted
fantasai: This is the default way that counters work
fantasai: It's not awesome. It's kind of confusing
fantasai: Let's fix it!
Feature detection for Nesting
-----------------------------
SebastianZ: Browsers start shipping CSS nesting without proper
feature detection.
SebastianZ: I wanted to discuss again how we could improve on that.
Currently it is a bit hard to feature-detect and also
cater for all the browsers that don't support nesting
SebastianZ: There is a link!
<SebastianZ> https://github.com/w3c/csswg-drafts/issues/8399
SebastianZ: It's about feature detection.
SebastianZ: Firefox is the only browser that will ship @supports
with the selector syntax so you can check before you
import something
SebastianZ: That is one part of this issue
<SebastianZ> https://github.com/w3c/csswg-drafts/issues/9082
CSS Grid and Flexbox should not be 3-5 years out of date
--------------------------------------------------------
fantasai: CSS grid and flexbox should not be 3-5 years out of date
fantasai: This is the flexbox spec. You can see the date is 2018.
Not been published in a really long time
fantasai: Why didn't I publish the spec? Because we all decided all
of the changes need to have test cases. Some do, some
don't. Tab and I didn't write the test cases
fantasai: We have other work to do. It's been 5 years. It still
isn't at the top of my priority list.
fantasai: It would be great if they had test cases, but not reality.
fantasai: But there are changes in ED, but not in TR, which is
technically a violation of the W3C's process
fantasai: We should publish anyway!
fantasai: We can gate publishing a Snapshot on having all the tests.
fantasai: but as long as we gate publishing a CRD on having tests,
and tests aren't at the top of anyone's priority lists,
we're not going to have an updated spec.
More Animation Timelines
------------------------
<bramus> https://gist.github.com/bramus/512cad694ad94cde1ba54c9864372698
bramus: scroll-linked animations defined new timelines, like a
"scroll timeline" or a "view timeline" as an element crosses
bramus: There are new potential timelines: a "media playback
timeline"
bramus: To sync with a video or audio element
<flackr> Or the other direction, play this video as you scroll :-)
bramus: Let's gather more ideas for more kinds of timelines! Time of
day timeline, hover timeline, who knows!
Catering for Scrollbars
-----------------------
<bramus> https://gist.github.com/bramus/bcca5788d8ced82837180b7a15760c84
bramus: One issue that often comes back is they want a way to know
what scrollbars are doing and how to respond to that
bramus: there are a bunch of issues
bramus: One is to expose an environment variable for the scrollbar
size. fixed value - independent of whether they show or not.
It's the default size
bramus: Also a way to query which kinds of scrollbar are being used
- classic / overlay
bramus: Also a container state query to know if something is
overflowing or not
bramus: If you combine all 3 you get the code snippet in the gist
bramus: These first 2 that were mentioned were suggested last year's
interop effort
bramus: That's why this is here now
bramus: About scrolling, authors often want to know which direction
the scroller is scrolling, and use that in an animation (if
you scroll down, the animation animates, but if you scroll
up, it animates the opposite direction)
<una> [on the topic of scroll], has there been any thought about a
scrollbar size variable? That would be really helpful too
<una> (ah nvm there it is, `scrollbar-size` <-- big +1 on this!
<emilio> una: Firefox implements this (but doesn't expose it to the
web) fwiw: https://bugzilla.mozilla.org/show_bug.cgi?id=1820280
<emilio> una: well, https://bugzilla.mozilla.org/show_bug.cgi?id=1812868
has the use-case
<tantek> una the preference has been to push information the other
direction, from the web author / server indicating
scrollbar prefs to the client in properties, rather than
the server querying anything about the client / user's
state (which has privacy issues)
SVG's Future
------------
<fserb> https://lists.w3.org/Archives/Public/www-archive/2023Jul/0001.html
fserb: The idea is try to raise some of the use cases people have
been trying to use for vector graphics on the web.
fserb: for animations, interactive UI elements, shapes
fserb: What are the problems people have?
fserb: Is there more we can do?
fserb: What are the technologies where we fall short?
fserb: What are the problems?
fserb: Do we care about those use cases?
fserb: Are they important enough to try to address?
fserb: Also there are some questions - if people are looking for
something, how do we feel about extending SVG to support some
things? Should they even be considered? What about an
alternate format? Is that a possibility? What about support
for text and things outside the browser?
<fantasai> 100% responsive vector graphics would be SO GOOD
fserb: A document to try to raise issues rather than propose
solutions to them. Are there people who are interested in
this space? Or have feelings about which directions to go?
How much effort should we put in which directions? If you
have feelings, please reach out and let's have a talk. It's
potentially a gap here about things we can possibly address.
fserb: Responsive vector graphics are a major thing that we should
improve
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/9098
TabAtkins: I just opened this ^^^
Flowing Multiple Grid Items together into 1 cell
------------------------------------------------
TabAtkins: Flowing multiple grid items together into 1 cell
TabAtkins: If you're rearranging your page with grid, to set up
multiple sidebars, and put things into the sidebars. If
you use grid by itself, one's sidebar will affect lines
in the ride will will affect the other sidebar.
TabAtkins: What you want is "all of you, pretend like you have a
wrapper and all go into one grid item"
TabAtkins: A simple proposal for basic bits. It lets you style the
generated wrapper which lets you style decorated grid
elements. The wrappers can be created whenever even if
there's nothing flowing into them
TabAtkins: Related: Arbitrary content flows. Didn't make it through
CSSWG for circularities in layout or accessibility. But
this proposal solves that problem
TabAtkins: Doesn't have strong reorganization of the document tree.
It's a minimal approach. Just make wrappers for grid item
contents
TabAtkins: And it avoids all of the layout circularities. I want to
pursue this
TabAtkins: It sounds interesting, would be good to get feedback
color-scheme responsive colors
------------------------------
<bramus> https://github.com/w3c/csswg-drafts/issues/7561
emilio: There's no way for authors to specify colors that react to
the color-scheme property
emilio: We need to drop a bunch of media queries but that doesn't
work if you want one part of the page light and the other
dark. Browsers need to have the capability at computed value
time what color goes where (that's how system colors work)
emilio: Browsers have an implementation internally like
`--internal-light-dark`
emilio: can we do this? I filed an issue about it
emilio: it seems relatively straightforward
emilio: Do we want to open it up to arbitrary future color schemes?
emilio: Maybe not? maybe just light/dark
emilio: How does that sound?
<fantasai> how is this different from custom variables?
<fantasai> ah, inline
<TabAtkins> it's easier than having to manually change variables
when you change color scheme.
<miriam> emilio: I want it
position:fixed viewport
-----------------------
<bramus> https://gist.github.com/bramus/903de19ef7bc2353e9edb6eb873955ae
bramus: position:fixed vs viewport
bramus: Linking to issue 7475 about how position:fixed
bramus: Right now position:fixed containing block is layout viewport
bramus: There are often action buttons on the bottom right. This is
a problem on mobile with virtual keyboard. All mobile
browsers resize the visual but not layout viewport when the
keyboard is shown. Because of that, position:fixed floating
toolbar can be obscured by the virtual keyboard
bramus: He goes over several options. The proposal is option 5. If
you click you can see a demo.
bramus: It boils down to creating a position:fixed kind of viewport
which mimics native behavior
bramus: Was discussed previously without webkit. Discussed about
whether this should be done by default or not.
bramus: This also rhymes with the anchoring proposal that Jen
proposed this morning
bramus: This seems to have slipped when getting feedback from other
vendors
bramus: pinch-zoom has no effect on the position:fixed viewport. If
you zoom in, the thing can also go out of view. SO there's
no layout thrashing
Ellipsizing of text in middle of string
---------------------------------------
<SebastianZ> https://github.com/w3c/csswg-drafts/issues/3937
SebastianZ: Ellipsizing text in the middle of the string
SebastianZ: This allows overflowing at the beginning at the end of a
string. My proposal which was celebrating its 10 year
anniversary 2 days ago is to also allow clipping in the
middle of a string which would be great for filenames or
URLs. Or any string where you care about what is at the
beginning and at the end.
SebastianZ: My current proposal is to make the text-overflow
property a shorthand
SebastianZ: and have 2 new longhands: text-overflow-handling and
text-overflow-position
SebastianZ: text-overflow-position would define where to crop the
string
<tantek> doesn't text-overflow take multiple values for start & end?
nicole: user-generated reviews need clear attribution and have
quotation marks. They also need to be truncated (they're
long) and they need to be clearly attributed with quotes
nicole: The desired outcome is truncated to 3 lines, i18n-ized
quotes. Also both open and close quote even when truncated
nicole: What actually happens is not that. We actually get this
quoted in the beginning but not at the end with the ellipsis
nicole: Firefox has text-overflow-ellipsis where you can do a custom
end-quote. So you can sort of do this but it only works on
one line, not 3 lines truncated.
nicole: we tried another thing: the :after pseudo-class. It's pretty
close to where it needs to be, but it's in the wrong place
when truncating to 3 lines.
nicole: we tried putting the quote outside the box, but that's also
in the wrong place
nicole: We're not that far from a solution, just need to put the
pieces together
<tantek> nicole, note that the text-overflow property used to be
multi-valued (start & end) and allow strings!
https://www.w3.org/TR/2015/CR-css-ui-3-20150707/#propdef-text-overflow
but we only got one implementation so it got dropped from
CR :(
Typographical Orphans
---------------------
myles: this is my favorite topic of all times
myles: CSS's concept of orphans is about pagination rather than lines
myles: most people talk about the paragraph kind of widows/orphans
not pagination
myles: this is to avoid the last line having only one word which
looks terrible
myles: lot's of different ways to fix it, any of the solutions are
fine, please make it better
<fremy> isn't that `text-wrap: pretty`?
<myles> fremy: nope
<fantasai> fremy, this is a misconception
<myles> fremy: I think the text-wrap: pretty needs way better spec
text to describe what it actually does
<fremy> @ myles, ok, I would love to learn more then
<myles> fremy: would be happy to chat either publicly or privately
about this
<myles> fremy: astearns and koji are interested in this topic too
<fremy> @ myles, if you open an issue about this, tag me in! I will
take a look at "typographic orphan" on Google to educate
myself in the meanwhile
<myles> fremy: https://github.com/w3c/csswg-drafts/issues/3473
[At this point, the meeting moved into unminuted small breakouts
around topics raised earlier in the F2F as well as some of the
lightning pitch topics]
Received on Sunday, 10 September 2023 15:34:00 UTC