- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 10 Sep 2023 11:33:00 -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 UI
------
- RESOLVED: Standardize a ::tooltip pseudo, with a few properties,
to style tooltips (Issue #8930: Standardize tooltip
styling and expose as `::tooltip`)
Anchor Positioning
------------------
- jensimmons presented the Anchor Positioning proposal drafted up by
herself, miriam, and fantasai. Explainer:
https://fantasai.inkedblade.net/style/specs/css-anchor-exploration/
This was intended to build on the fundamental layout
model of the existing Anchor Positioning spec, and
provide a more user-friendly interface to its layout
capabilities
- There may be author desire to control the fallbacks instead of
having default values.
- Animation needs additional consideration since the new
proposal is grid-like and introduces a lot of similar
limitations to animation capabilities.
- The authors intend to add more examples to the explainer and
welcome any use cases that they should include.
- Several working group members expressed a desire to spend more
time looking through the details of the proposal and then
discussing further.
- The next step is for the authors of this proposal and the authors
of the Anchor Positioning spec to sit down together and talk
through how best to merge the proposals
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/38
Scribe: fremy
CSS UI
======
Standardize tooltip styling and expose as `::tooltip`
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8930
lea: Proposal as of a few days ago
lea: tooltip styling has been brought up multiple times by multiple
people since 2000
lea: First was tantek, but there were many other ones
lea: Every single time, there was little pushback
lea: yet it never went anywhere
lea: Many websites have custom code to style tooltips
lea: and most of these stylings are not very fancy
lea: Mostly color, background, font-style, customizing the delays...
lea: because browsers sometimes wait too much
lea: but all of this requires changing the markup, because the
element must wrap the location
lea: so this is pretty heavy-weight, and it's easy to forget some
accessibility requirements
lea: so, I really think we should do something about it
<castastrophe> +1 lea I argued so hard against our library building
a tooltip web component at work
lea: and the most common proposal is a pseudo-element accepting a
few properties
lea: Since the tooltips can escape the window bounds, it could make
huge tooltips and confuse the users if everything is
customizable
lea: but some properties sound fine
lea: later on, we can add positioning, maybe using anchor
positioning, but magic is fine for MVP
lea: Content itself can probably be magic too, because SVG and HTML
do this differently
lea: keyword vs totally magic, not that important
lea: we can narrow this down later
lea: Later on, we can add html elements, attributes, focusable,
etc...
lea: but I see consensus on the basics
lea: So, are there implementors that are concerned about this?
lea: (also, maybe javascript-created tooltips?)
lea: maybe in that case, bound to the frame
lea: So, what are the constraints holding us back here?
<castastrophe> A reference for anyone interested in Adobe's tooltip
web component:
https://opensource.adobe.com/spectrum-web-components/components/tooltip/#example
<castastrophe> And an example from Shoelace:
https://shoelace.style/components/tooltip
<masonf> Shameless plug for popover=hint and hover triggering:
https://open-ui.org/components/popover-hint.research.explainer/
masonf: Thank you for bringing this up
masonf: I pasted our shim in the chat, a more complex version of
this using popover
masonf: but for most use cases I have seen, a little styling would
go a long way
masonf: I would love it to have the tooltip in the window bounds, so
that styled tooltips are consistent depending on how much
they are styled
masonf: I would prefer some things to remain magic, like delays,
but ok
masonf: html uses the title element, but also some aria attributes
<masonf> we should support the title attribute for HTML, or the
<title> element with svg.
una: Thank you for opening this issue
una: the first thought that comes to mind, can this also style "form
error messages"
una: Does that also apply to "alt text" over images?
una: Maybe, this can be a "style bag" rather than a pseudo-element
una: but, if you have a popover, that gives you multiple elements,
and more flexibility
una: So, the limitations of this proposal, are they acceptable
enough, is my first question
una: My second question, is that, how does this related to other
features like alt text
<una> also would like to support `popover=hint` to resolve tooltips
for cases beyond simple text
ntim: Outside of the window bounds, we would want to filter down to
a list of properties
ntim: Also, probably some constraints like size or box-shadow
myles: Further than that, tooltips ship with the OS, and the
platforms usually don't allow much styling
myles: so, one limit, I would start with what the platform allows
myles: also, tooltips outside the window, requires nsWindow etc...
myles: This is costly if we want to do that
myles: but I understand that from the issue, the benefits are also
quite high
myles: so, this is not "easy" at least
astearns: The hard part is displaying outside the window. The rest
of the proposal doesn't get to that bar?
myles: yes
<gregwhitworth> myles I noted in my comment that I'd expect you to
bail on native windowing for both security and
easier implementation and also ensures that we don't
limit styling:
https://github.com/w3c/csswg-drafts/issues/8930#issuecomment-1581847783
lea: I think errors for form controls are a different pseudo,
because they have different constraints
lea: there are commonalities, but also major differences
lea: I'm not seeing the alt text connection, which I think is more
of a ::part() I think
lea: To reply to ntim, I would definitely favor an allow list
lea: but, just an allow-list might not be the whole story
lea: I think many authors want padding, rounded borders, etc...
lea: To reply to myles, I think this would generate non-native
tooltips
lea: because what authors do today is this
una: Do you think popover=hint solves these problems?
lea: It can probably solve some, but it requires a lot of code, and
doesn't play natively with title attribute etc
<gregwhitworth> I agree with Lea on this
lea: More complex use cases would like it
myles: If this is not native tooltip, for us this is not a tooltip
myles: I would not want to call this a tooltip at this point
emilio: Indeed, we need to answer whether the content area is enough
(even for iframes)
emilio: If not, non-native tooltips are not ok
emilio: but we already discussed this for <selectmenu> elements
emilio: so, if we are, this seems workable
emilio: If we don't think this is sufficient, I would not think that
this is doable (in a reasonable amount of effort)
<TabAtkins> These are conditions that people already live with when
they're using the custom JS-driven versions.
<gregwhitworth> note, only when ::tooltip is present
emilio: So, would browsers engines be fine with that?
emilio: And I have the impression that myles isn't comfortable with
that, maybe?
emilio: personally, I guess I'm fine, but needs some thoughts
astearns: TabAtkins replied on IRC that people today have those
limitations, so those are probably ok with them
emilio: But those aren't native, right?
<gregwhitworth> not if you don't use ::tooltip
TabAtkins: Yes, they override
SebastianZ: I wanted to say more about the security issue
SebastianZ: The native tooltips should still be able to actual
document
SebastianZ: Right now, UAs can clip the text etc..., UAs can create
new rules based on size etc...
SebastianZ: Do we have consensus that this is something that should
be worked on, at least?
masonf: <confusing echo>
gregwhitworth: Personally, I never envisioned the non-native
tooltips to escape the bounds
gregwhitworth: and I think, as an author, that is reasonable
gregwhitworth: but even then, we can start with simple properties
anyway
gregwhitworth: Una pointed out alt text, and some sites use them as
a tooltip in some cases
gregwhitworth: also, agree with myles, maybe this shouldn't be
called a tooltip
gregwhitworth: but "the box that pops up when tooltips happen"
masonf: Also, pointing out, many sites refuse to use these tooltips
<gregwhitworth> +1 to masonf
<lea> +1 to masonf too
masonf: and these sites accept the trade-off about off-bound
positioning
masonf: Personally, I don't even see that native tooltips are that
necessary
masonf: I would not mind a single path, custom ones
masonf: they would be simpler
astearns: Removing is difficult on the web platform, but that's an
interesting idea
<masonf> astearns, the behavior of the title attribute (generating a
"tooltip") is not standardized, so we're not really
removing something. We're better defining it and making it
more developer-friendly.
lea: Can we get some data about what tooltips can do on native
platforms?
lea: That would help shape the discussion
lea: Also, if it behaves like a tooltip, I feel it should be called
a tooltip
lea: Scrollbars were in that list of strange things once, but we
resolved that built-in customization is better than wild hacks
lea: multiple codepaths are fine on the web platform, like for
<button>, so I don't buy that objection
lea: if we can get rid of the native ones, I don't mind personally
<gregwhitworth> I don't like the artificial limitations because it's
non-deterministic from a DX perspective
lea: eventually, we can probably find constraints
lea: most sites that have enough resources to make a choice
lea: do not use the native ones
<una> +1 will be much easier to build without expanding window
bounds and that doesn't sound like a top requirement to
support authors here
lea: Also, I would object about "title" as the name, because "title"
was an odd name
<gregwhitworth> Lea: all I was saying was I'd like a proposed
resolution that is about the job to be done (eg: A
developer should be able to style the box and the
contents of the box that is rendered via a pseudo
element selector while ensuring security constraints)
<gregwhitworth> effectively, punt on the naming
dbaron: Some feedback we once got about alt text in tooltips
dbaron: We stopped doing this by default
dbaron: because alt text was used as a hack, instead of a real
description
<TabAtkins> Basically, webcomics.
dbaron: so, this change was intentional
emilio: Multiple codepaths are fine, but also the difficulty of them
is important
emilio: for me to become more serious about this, I would like to
hear some consensus from implementors that the bound
restriction
emilio: if we get consensus on that, I'm fine with this
<lea> emilio, Of course the code path is different for buttons, my
point was that from the author side there is precedent for
rendering going through a different code path once CSS is
applied.
<lea> We have "make simple things easy and complex things possible"
in our TAG principles :)
fantasai: Personally, I agree with Lea, we need to bridge the gap
between "you control nothing" and "you have to implement
javascript, accessibility, etc..."
fantasai: right now we don't have that middle ground
fantasai: I also feel like if it looks like a tooltip and behaves
like a tooltip, let's call it a tooltip
fantasai: and for the content, I think we are ok with using the same
text as it would do today
fantasai: I think it's fine, ::tooltip should allow you to style it
fantasai: Given the facts a lot of authors seem fine to keep it in
the window bounds, I think it's reasonable
fantasai: In terms of positioning, we can punt this for now, and
come back to this later
fantasai: but, globally, I think it's a net benefit if (a) it's easy
(b) UA handles positioning and appearance logic so it's
not error-prone (c) accessibility is preserved
<masonf> +1 to everything fantasai just said.
<lea> also +1 to everything fantasai just said!
lea: I would not mind the bounds restrictions to depend on the used
styles
<lea> allowlist and window bounds are related, they should be part
of the same issue
miriam: quick question
miriam: I have seen many a11y recommendations to not use the title
attribute
miriam: Is that an anti-pattern?
chrishtr: I have heard the same, it's often much too loud for them
astearns: I'm wondering, can we resolve on a ::tooltip pseudo, with
a few properties allowed, and figure out the details later
in little pieces
<masonf> +1
<lea> +1
astearns: any direct response to that proposed resolution?
<gregwhitworth> +1
astearns: any objection to this?
<bramus> +1
<castastrophe> Very exciting!
<una> awesome :)
<gregwhitworth> only 23 years
<lea> 🎉
RESOLVED: Standardize a ::tooltip pseudo, with a few properties, to
style tooltips
Anchor Positioning
==================
explainer: https://fantasai.inkedblade.net/style/specs/css-anchor-exploration/
jensimmons: This is a proposal from me, fantasai and miriam
jensimmons: The goal is to make the common cases easy and natural
jensimmons: but also make complex cases possible
jensimmons: [shows a few use cases, not all being tooltips]
jensimmons: [for example, dropdowns with calendars or colors]
jensimmons: Anchors enable more flexibility in the dom vs positioning
jensimmons: [explains popover]
<masonf> last example could be `popover=manual`
jensimmons: [popovertarget="<t>" .... id="<t>" popover]
jensimmons: Anchor positioning enables to control the positioning
conditionally based on available size
jensimmons: We build on the proposal from the anchor positioning
spec drafted by TabAtkins
jensimmons: The anchor lives in space in a containing block
jensimmons: the containing box contains the anchor box
jensimmons: There are 9 zones, 8 around the anchor plus center
jensimmons: 3 columns (left/start, center, right/end)
jensimmons: 3 rows (top... etc)
jensimmons: We also have an "all" span column/row
jensimmons: We propose "position-area: row / column"
jensimmons: eg: position-area: top / center
jensimmons: or if you want to span position-area: top / all
jensimmons: bottom / center seems to be a reasonable default
jensimmons: or maybe center/center in some cases
jensimmons: You can also span, eg position-area: end / center right
jensimmons: but, of course, if there isn't enough space, we could
start to define fallbacks
jensimmons: This is described as a comma-separated list
jensimmons: This is simple and declarative, and the browser can pick
which choice works best
jensimmons: To achieve this, "position" would be broken down into
"position-type" (as today) and "position-area"
jensimmons: Of course, once you are somewhere, you need to use
alignment
jensimmons: just like grid, there is a default
jensimmons: We propose to make the default depends on where the
anchor-positioned item is
jensimmons: We also introduce an anchor-center value for the
middle row
jensimmons: By default, we try to make the box "align" with the
anchor
jensimmons: justify-self does the same in the opposite dimension
jensimmons: with the same "normal = what makes it next to the anchor"
jensimmons: content-width is shrink-to-fit
jensimmons: (presents an example that combines this)
jensimmons: anchor-center aligns based on the anchor width
jensimmons: but the usual center keyword still exists if needed
jensimmons: Now, of course, one might want to apply some margins
jensimmons: the margin applies towards the edges of the container,
and from the anchor
jensimmons: to decide whether the box fits, the margin is taken into
consideration
jensimmons: To shift, it's possible to use inset properties (or top/
left/etc...) with negative values to create overlaps
jensimmons: inset-inline: 50% would also resolve, to 50% of the
columns at respective inline edges of the popover
jensimmons: This is not always the same size
jensimmons: You can of course use different percentages/values
jensimmons: We also propose a ::tether() pseudo element
jensimmons: which can have area-specific styles
jensimmons: It is sized as a rectangle between the popover box and
the anchor
jensimmons: If there is no overlap, it's the smallest gap
jensimmons: If there is overlap, it goes to the other side
jensimmons: For direction, you can use eg ::tether(top / any) to style
jensimmons: For making it a triangle, there are options, but we
would like to add `corner-shape: angle` (from the
css4-backgrounds draft) and add it for authors in the
UA stylesheet
<lea> probably easier with clip-path than corner-shape
jensimmons: If popover styling needs to change depending on the side,
we could add an additional @-rule
jensimmons: or we add selectors, but restrict what styles these
selectors can set to avoid loops
jensimmons: We are not really sure what the best way forward here
is, but we know we will have at least one option, it's
not a dead-end
jensimmons: Now, we need to address how to link the popover and its
anchor
jensimmons: html linking works by default
jensimmons: but we want to add `anchor-name: --foo` and
`position-anchor: --foo` as in the existing spec
jensimmons: we fold the latter into position shorthand,
so it's more clear what it belongs to
jensimmons: also allows "position: absolute --foo" as a shorthand
jensimmons: in case of name conflicts, we bias towards ancestors by
using the first element with the matching anchor-name
value
jensimmons: In addition, anchor-scope like timeline-scope allows
to limit the search
jensimmons: that was a lot :) let's look at some use cases now
jensimmons: (see the slides for the examples, I will only minute
insights here)
<fremy> self-thought, question: how does it work with the shadows
with the tether in the second use case
<fantasai> `filter`
<fremy> @ fantasai, `filter` is a good answer, thanks
jensimmons: show you can use clamp() in some of the properties
jensimmons: link to the explainer
<dbaron> https://fantasai.inkedblade.net/style/specs/css-anchor-exploration/
<TabAtkins> That example is very wrong, it does something
dramatically simpler/more naive than what my example did
<TabAtkins> Doing the same as the slide example is actually
extremely trivial in the current spec, if that's all
that's desired.
jensimmons: The slides will be online later
una: I feel we should clap after this, a lot of good thoughts and
efforts went into this!
una: I was wondering, how do you define the containing block?
fantasai: The same block as the existing proposal
una: So, the viewport can be a default?
fantasai: If it's position:fixed, yes
jensimmons: So you get it for free if you fixed-position them, which
is common
una: The state queries go with the tether, but could we use them on
the popover itself?
jensimmons: We haven't considered this all the way through, but
maybe?
fantasai: If we go with the pseudo-class `:position-area`, you don't
need a special ::tether
fantasai: but we are not sure this is tractable, especially at start
fantasai: this is why we have the arguments in tether too
una: I would like the more organized approach
fantasai: Which assumes we can do this, we are not sure yet
fantasai: but if narrow it down, yes
una: tether is an interesting take
una: One thing the existing spec does not solve is the resize
una: e.g. clamp the max size etc
fantasai: yes, min-width
jensimmons: The current spec needs a lot of math, but because this
proposal is builds on other existing layout concepts,
you can apply your existing knowledge
jensimmons: e.g. stretch, etc etc, or clamp()
jensimmons: any sizing you can put on the page
fantasai: max-width, min-width, etc...
una: What happens when you scroll?
fantasai: The popover will move with the element
una: I have seen cases where <missed>
<lea> una, might be good to share that example with the group so we
can have a shared frame of reference
fantasai: If you place it on the right side, then the containing
block will be the viewport, and the grid will be created
at every step of the way
fantasai: The popover can be the full height of the viewport, then
it will be fixed irrespective of where the anchor moves
<astearns> the arrow would move with the anchor in that case
<una> Also +1 to anchor-default —> position-anchor
lea: I really like the usage of grid-like layout
lea: btw, I really like the slides, it was easy to understand,
thanks for that as well!
lea: One question, we received a request at TAG to review the other
anchor-positioning proposal, is this this relevant?
lea: Some use cases, like the "fixed" sales label have different
requirements
lea: Are we really targeting this?
lea: Also, should we have a "forced default"?
lea: Because otherwise, if the authors forget about the fallbacks,
the popover is outside of view
lea: If like I think most cases require the fallbacks, maybe the
fallback should be built-in?
lea: I think the "last-resort" fallback should be an opt-out, maybe
fantasai: We could certainly make it opt-out, but I think authors
will have an opinion
fantasai: maybe, we could make an auto fallback depend on the position
fantasai: maybe, for the last resort fallback, like the older spec
fantasai: The relationship with the existing proposal, it's up to
debate
TabAtkins: The old proposal still stand, but we could decide to
change
TabAtkins: This is a new proposal by jensimmons and fantasai
lea: I also wanted to point out that clip-path would be enough for a
lot of cases
fantasai: But not if you have a border
lea: But it would be usable without this
fantasai: But let's try to make the best one first (paraphrased)
lea: For the more complicated cases, I think we need more author
feedback
lea: I would prefer this to be moved to level 2
lea: and wait to see what authors do and need
fantasai: I think we are not close to ship, so I'm not concerned yet
fantasai: but this is of course an option
<dbaron> It's not clear to me how a border that goes around both the
anchor-positioned element *and* its tether would work.
emilio: I think the direction of this is elegant
emilio: the tether stuff is a bit sketchy to me
fantasai: It's a tree-abiding pseudo, nothing too special
emilio: The restyling is a bit special, will need more consideration
emilio: One thing I don't like; it's good the mirroring is easy by
default, but what if you don't want that?
fantasai: As the area shrinks, (popover is top center), as the side
shifts, you will shift, we use the "safe alignment"
strategy, and if it doesn't fit at all anymore, you move
to the next fallback
emilio: So, to trigger the fallback, <missed>
emilio: in this case, to trigger the fallback, you need the popover
overflow the container?
jensimmons: I think authors can describe what they want to happen
jensimmons: it will automatically slide over
astearns: Let's discuss in a specific issue
SebastianZ: btw, corner-shape is in borders-4 since yesterday (yay!)
SebastianZ: How would the tether interact with the originating
element?
SebastianZ: For example, what if you want a border around everything?
<astearns> see dbaron's comment above about the difficulty of the
shared border
fantasai: Right now, you cannot define a custom path for the border
fantasai: so, yes, right now, you will have to align carefully,
maybe create an overlap
fantasai: For example with a negative margin on the tether to create
this overlap
fantasai: or sometimes with a box-shadow or filter, it looks close
enough
fantasai: At some point it might be nice to have SVG path borders,
but that is not for this proposal
SebastianZ: The container does it need to be an ancestor?
fantasai: Not always, no
jensimmons: If you use popover, this is up to html
jensimmons: If you use anchor-name, this is the same as the existing
proposal
SebastianZ: Does this use backdrop-filter?
<confusion>
<lea> there may also be more intelligent ways to resolve duplicates
than simply "get the first one". E.g. prioritize ancestors, or
closer elements
astearns: let's table that for a while
TabAtkins: Couple of points
TabAtkins: I think many ideas can be moved over to the current spec,
like align-content: anchor-center
TabAtkins: also, things like tether might be added as well
TabAtkins: However, I don't really see the value of the grid things
TabAtkins: Most of the lines align to simple percentages
TabAtkins: some examples look really simple, like the one with clamp
TabAtkins: but the code show doesn't do the same
TabAtkins: if you wanted this example with the syntax in the current
draft you'd do left: anchor(left); right: anchor(right);
bottom: anchor(top);
fantasai: Besides all of the specifics here
fantasai: one key advantage of the cells, is to automatically adjust
the defaults based on them
fantasai: instead of having to use math for everything, you can rely
on the defaults
fantasai: Also, because of the safe alignment, you don't overflow
jensimmons: TabAtkins, I think you take this too much like a battle
jensimmons: We are trying to make this simpler for authors
TabAtkins: I agree with this, but I would have loved a headsup
TabAtkins: I'm just talking about a few notes I collected, but this
is not a detailed feedback yet because of this
TabAtkins: (some discussion about content-box vs border-box)
jensimmons: I think this is not something we discussed, let's look
at this later
* fantasai notes that the proposal didn't exist 2 weeks ago, and the
writeup wasn't finished (and some of the ideas not
drafted up even) until this week and the slides weren't
done until this morning
TabAtkins: I think the fallbacks examples were not very clear to me,
but I will take a second look later
TabAtkins: I think defining the areas without the at-rule is great,
it goes a bit further than the current proposal, I will
consider this further, this seems good
TabAtkins: I agree that with the current proposal, this would
require some work
TabAtkins: I suppose that things not mentioned in the slides are not
changed with regards to the current draft?
fantasai: Probably, we did not intend to make changes there
<dbaron> One other comment that I'll just make on IRC is that the
changing of what % means on inset-* properties feels too
magical to me. (I think things that are too magical are
likely to be confusing to developers who want to understand
what's going on.)
<rachelandrew> +1 to dbaron's comment, I feel that things that
change behavior based on context seem very magical to
authors.
Rossen: +1 for the presentation, it was good
Rossen: I'm not up-to-date on the current spec either, but I have a
few questions anyway
Rossen: One of them is about accessibility
Rossen: this enables anchoring to places further in the tree
Rossen: How is that represented in the accessibility tree?
jensimmons: This is addressed in the popover spec, I believe
<TabAtkins> In general, anchor positioning makes the a11y easier to
address, since you're a lot more flexible in DOM
ordering and can put things in the correct place.
<TabAtkins> Rather than having DOM order be dictated by positioning
constraints.
Rossen: ok, but this extends beyond that, so I would like this to be
considered a bit more
astearns: Good concern, this will have to be thought about
Rossen: My second question, is this animatable? when constraints
force a change, can we make the transitions smooth?
Rossen: I don't think I have a solution, but I would like this
considered at some point
<dbaron> +1 to Rossen's concern about animation
<TabAtkins> Ooh yeah, this is animation-hostile like Grid itself is
(animating an element between grid positions in Grid
is.... bad)
<fantasai> agree should fix that somehow :/
Rossen: Third point, this is a new constraints-layout system; I
think people will want to describe how to deal with
fallbacks (eat empty space here first, then space there
last, etc...)
Rossen: grid and flex can already do that
Rossen: is this allowed here?
<TabAtkins> yeah, VT is the fix for now, and I'm not sure how to fix
it at a lower level :/
jensimmons: Yes
* fantasai has some ideas
Rossen: That's great
Rossen: Last question, is it possible to reattach to another anchor?
Rossen: Smooth reattachment would be great, I would love to see this
happen
<TabAtkins> smooth reattach is an issue in the current spec fwiw. it
requires some changes to the internal model but should
be possible.
nicole: Transitions are great, but maybe view-transitions can help
here?
<bramus> No, for SPA, VT need a JS trigger
nicole: Position queries seem necessary to address all use cases,
and I would like this investigated more
nicole: some examples in spec, especially at first, are a bit
complex, and I would like this made more accessible for
webdevs
nicole: I would love to see examples sides by sides
fantasai: I agree, we really wanted to do it, but we ran out of times
fantasai: Would have wanted to do for more of the examples for the
opencg examples
fantasai: and if you nicole have examples you look at, can you bring
them forward?
nicole: yes, will do
florian: I just wanted to say, I really I'm impressed with this
proposal
florian: the current draft seems to hit the marks for use cases, but
I really like that this is well integrated with other css
specs and layouts
florian: This was a lot to take in at once, though, this will need
more thoughts
<TabAtkins> (as I said, several bits of this proposal are compatible
with either proposal)
florian: I think Rossen's question is interesting to look at, the
smooth transitions
TabAtkins: Yeah, if you can't define in grid the intermediate
positions, it's tough to animate
iank: Did you have any thoughts about how to do multiple anchors
with this model?
fantasai: We find it a useful feature of the current spec, but we
haven't figured out how to integrate this directly at the
moment
fantasai: But we promise to look into it
iank: It did generate a "wow" from authors who started using this
fantasai: If we can get real use cases for this, this would be super
handy
<masonf> blog post: https://kizu.dev/anchor-positioning-experiments/
fantasai: I agree that the current spec handles animations more
easily, this is definitely something to consider
iank: jensimmons: some discussion of (-2em vs -50%)
fantasai: (clarifies)
iank: Yeah, I understand
iank: We also thought about managing with what percentages resolve
against, we could reopen some thoughts about that
iank: some people wanted to consider for width and height the area
considering the margins
iank: People want to resolve %ages against the inset-modified
containing block rather than the original containing block
fantasai: Good thought
astearns: As the chair of the group, I would like to the authors of
the new proposal and of the older spec to sit together
astearns: I recall for grid, we had many competing proposals
astearns: and in the end, multiple were found to be useful, and we
spent a lot of time trying to integrate them into a single
proposal
astearns: I would like to replicate this success here
TabAtkins: Process thing, can we split the current proposal into
multiple issues?
TabAtkins: That would make this easier
<masonf> @fantasai how can the public comment on the new anchor
positioning proposal? There's just the entry on your
private blog. Is there a public CSSWG issue where others
can raise issues? Or just the private blog?
Agenda
------
astearns: This afternoon, we will do the lightning talks then
breakouts
fantasai: We want to encourage cross-company discussions, and
potentially come up with proposals and potential WG
resolutions for tomorrow
Topic: lunch
astearns: <br until=1pm timezone=PDT>
Received on Sunday, 10 September 2023 15:33:36 UTC