Meeting minutes
<khush> flackr i agree that it's a better model for props which are meant to be used outside. but for the ones meant to be encapsulated, would be nice if they were defined internally only
<astearns> +1 to flackr
<khush> TabAtkins: any shadow internal custom props being in capable of being defined, unless you also include a script or stylesheet globally is bad
<khush> the fact that they can't be scoped at all is a consequence of inheritance. being able to define them internally with a well named internal semantic is worth it
<khush> i can accept it being global only.
<khush> noamr one way to resolve this. problem with internal props is that it could be a mismatch. so if it's defined internally, let's make it not inherited
<khush> then this is your own property, deal with it
<khush> your prop would fallback to what you defined in the descriptor as initial value and not inherit from global scope
<khush> TabAtkins what happens on the host element itself. can define something. otherwise the idea sounds reasonable
<khush> emilio was gonna argue for currently implemented behaviour
<khush> as soon as there are name conflicts. you need to remove all the niceties of the shadow dom data encapsulated. have preference for the current behaviour. i need to think through, you have properties with same name. one is defined outside via part one is inside via regular stylesheet. that also seems fairly annoying. preference to just spec what is
<khush> currently there
<khush> TabAtkins i want to explore the behaviour noam was talking about. if we can find a less annoying version. but ok with specing current behaviour
<khush> kizu: this is something i encounter without shadow dom. multiple sources define the same prop name with different values. if some element registers it with a different value, custom element on the host or regular element on itself. as soon as it reaches this by inheritance it will use initial value if there is a type mismatch
<khush> you define for your scope. if an internal one defines the same type then inheritance works otherwise it's overridden
<khush> TabAtkins if noam's idea is limited to defining on tree roots it matches your idea
<khush> and sounds reasonable behaviour to me
<khush> astearns my chair hat off, i would accept what noam is proposing. prop def scoped to the shadow root. accept what's currently there, everything is global. don't accept what is currently implemented that shadow dom can't define props.
<khush> westbrook cross shadow boundary and change if there is something defined inside the shadow dom.
<khush> TabAtkins if inheritance carries a font face to the shadow, the font face being defined won't changge
<khush> if the outer face defines font face foo, and shadow defines the same. outer sets font-family: foo, it is referring to the outer one. when inherited it refers to the outer one
<khush> it won't use the internal one, name collsiion was accident
<khush> if the shadow says font-family foo, now it's the internal one
<khush> emilio what is the implemention for font-face. gecko ignores them
<fantasai> strong +1 to Tab's point about binding font-family to @font-face before inheritance
<khush> TabAtkins it's inconsistent. some ignore them internally, some make it global
<khush> emilio wouldn't want to expose font faces to document.fonts. haven't discussed this
<khush> TabAtkins that is undefined. happy to do reasonable stuff there
<khush> TabAtkins we don't have a version of .fonts for shadow trees
<khush> emilio all shadow roots have their fonts in document.fonts is not good behaviour
<khush> TabAtkins figuring out reasonable behaviour there is more complicated
<khush> noamr prop is an API surface between shadow roots by definition. and the desc defines an interface point, fonts don't have any of this. they define something else. so the parallel is not right
<khush> there's reason default scopung is not for prop
<khush> chrishtr let's take it back to the issue
<khush> astearns take it back to the issue. see if we can scope the prop definition.
<khush> github-bot, take up w3c/
[css-values] Security concerns regarding attr()
<github-bot> OK, I'll post this discussion to https://
<TabAtkins> on that note, I think the right behavior for scoped @property is that *the host element* will refuse to inherit from its parent, if its shadow registers a custom property.
<khush> moonira 2 open questions left for attr security. invalidation time and second is painting custom props
<khush> for the first we propose making security violation. if we have a grammar that allows doing type, that doesn't cause security issues we can't say for sure
<khush> until after the substitution
<khush> in the current spec, attr is already a computed value time. there's no substition value
<khush> we just be consistent with security violation at computed value time
<khush> if attr is subsitutued into custom prop value. affected part of custom prop become tainted, not the whole custom prop value
<khush> moonira that's the proposal
<khush> TabAtkins i agree with both of these. url taining only causes invalid at computed value time, not parse time. makes it more diff to do that
<khush> indivisual tainiting is amazing! at the moment, spec says entire value is tainted if any part has attr. i assumed it's easier. if doing it for individual tokens is possible, which means we can combine sec and not security sensitive tokens in the same prop. that's great!
<khush> astearns 2 separate resolutions?
<khush> emilio curious about how you do partial tainting?
<khush> if that token gets used for a security sensitive spot then it's invalid, color is fine
<khush> emilio feels sketchy
<khush> astearns we could resolve on what is proposed. and make it more strict?
<khush> TabAtkins presence of attr taints the entire custom prop which keeps chaining
<khush> emilio what is the computed value? does that contain attribute value?
<khush> TabAtkins computed value is post substitution
<khush> emilio i like the current spec more. i can see why it's more useful.
<khush> emilio feels unfortunate to track token tainiting lacking clear use-cases
<khush> TabAtkins both need to taint token, you need to tell that URL came from a tainted variable
<khush> emilio if i were to implement this, you would mark img as tainted.
<khush> the whole custom prop --img is tainted. rather than partial tainting
<khush> feels simpler to spec, reason about
<khush> TabAtkins on the spec side its only slightly simpler
<khush> implementation wise also feels same, you have to care about token ranges
<khush> one is example using bar and the other one is a URL
<khush> emilio very curious about use-case, feels more complex than current spec and unwarranted
<khush> iank_ i'll show you the chrome implementation
<iank_> https://
<iank_> moonira is that correct?
<khush> chrishtr the second part of the proposal, is the reason you suggested it is because it's more natural to implement
<khush> moonira yes, it's easier to implement that way
<khush> moonira it makes sense. the example in the issue, there it makes sense
<khush> moonira not sure
<khush> astearns what if we resolve on first part. and left the second part open so we could decide whether there is enough author justification
<emilio> https://
<khush> emilio +1
<khush> astearns PROPOSED RESOLUTION: change the spec such that violating attr security restriction will make it invalid at computed value time
<khush> astearns for now the tainting whole custom prop stays as is
<khush> can decide whether to make it partial later
<khush> RESOLVED change the spec such that violating attr security restriction will make it invalid at computed value time
RESOLUTION: change the spec such that violating attr security restriction will make it invalid at computed value time
<TabAtkins> github-bot, take up w3c/
Alternative masonry path forward
<github-bot> OK, I'll post this discussion to https://
<khush> rachelandrew summarize the feedback. we've got 2 versions in terms of feature parity they are the same
<khush> the syntax is different
<khush> taken it to 2 devs
<khush> after the initial post from webkit, we got feedback
<khush> there's no way that devs will get all features showed in the post if we go with separate syntax
<khush> went through all the comments and looked at how many of them said display:grid because that's the only way to get features
<fantasai> I think that's not quite correct, just that the state of the opposite proposal was to intentionally exclude some of the grid-integrated features.
<fantasai> at the time of that post
<khush> other feeedback is, is masonry grid or not.
<khush> as a teacher of CSS it matters how people think
<khush> there is noo consensus there
<khush> the other response, which approach is easier to teach and understand
<khush> that's the core issue, what is easier for devs to understand
<khush> that post is really hard to write
<khush> because it's complicated. display masonry has much simpler syntax. display grid requires changing other values
<khush> it's just hard. i'll have a hard time explaining it to people
<khush> the response to the second post has supported masonry
<khush> me and chrome team prefer display: masonry for ergonomics
<khush> the other point is future proofing
<khush> there are enough things in display grid which are weird
<khush> we will have to work around by saying they only work in masonry
<oriol> +1 to display:masonry
<khush> fantasai: i intentionally did not add it to the agenda. too early for this debate
<khush> underlying layout model is the same
<khush> only syntax is up for debate
<khush> we only published it end of last week
<TabAtkins> (it's not just a syntax issue, there is still some behavior differences)
<khush> chrome madde the blog post last thursday
<TabAtkins> (and they're unresolvable imo)
<khush> we should continue to work on issues
<khush> impl is not blocked
<khush> i want to collect author feedback and think through the syntax
<khush> get input from TAG
<khush> too soon to start debating syntax
<khush> Won't go into my opinion on the syntax
<khush> the state of the draft which outlines the 2 syntax and have same functionality
<khush> there's pros/cons to each syntax. one is definitely not better
<khush> has to come from the context where the syntax is being used and rest of CSS
<khush> let's not argue it here right now
<khush> TabAtkins: the difference between integration into grid vs masonry is not just syntax.
<khush> diff initial values for properties
<khush> display: masonry gets you better values right away
<khush> masonry can do auto repeat of instrinsic size tracks
<khush> that is not even possible with grid
<khush> fantasai: those are separate issues
<khush> TabAtkins : it's incorrect to say it's only syntax. behaviour is different
<khush> i'm fine with deferring
<khush> TabAtkins: it's pretty clear that a bunch of common cases are indeed simpler with the display: masonry syntax.
<khush> want to see similar examples with grid.
<rachelandrew> Chrome post https://
<khush> let's have those examples when this discussion happens
<khush> keithamus: display: masonry is a inside display: grid
<khush> i can't see any examples for inline masonry
<khush> TabAtkins assume inline-masonry exists.
<khush> astearns please file an issue for this
<khush> fantasai: one argument for grid syntax is we don't have props which only apply to specific context
<khush> it's better to go with more examples/input before debating
<TabAtkins> I think we actually don't have *any* such properties here. Every property is *at least slightly* different in its syntax.
<khush> github-bot, take up w3c/
[css-grid-3] The initial value of `masonry-slack` should be 0
<github-bot> OK, I'll post this discussion to https://
<khush> oriol: it would be better to summarize the prop. another issue for naming it
<khush> with masonry we place the item into a track that is less filled.
<khush> with this prop you can provide a threshold so instead of doing it strictly order is preserved
<khush> current spec tentative initial value is 1em
<khush> i think it should be set to 0
<khush> was investigating js frameworks which provide this
<khush> all of them have the strict value
<khush> they offer 2 possibilties: masonry-slack: 0 or infinite
<khush> when you set it to a positive value, no framework supports it
<khush> authors don't expect or ask for it
<khush> maybe it can be beneficial. exact value which will work well is highly dependent on the use-case
<khush> so just supporting 1em is confusing
<Zakim> fantasai, you wanted to point out they don't have a concept of masonry-slack
<khush> align with frameworks and set initial value to 0
<TabAtkins> +1 to fantasai's point
<khush> fantasai: the reason why frameworks don't have non-0 initial value since there is nothing other than infinity
<khush> this is a concept frameworks don't have
<khush> allows placements to occur in a more natural way for the user
<khush> slight diff of a few pixels jumping to a diff track breaks accessibility and sequencing order also
<khush> it would be better to have a non 0 initial value
<khush> 1em is used for gap
<khush> significantly more than 1px but less enoug
<khush> almost no use-case for anything less than this
<khush> oriol: i don't get the accessibility problem. reorder happens anyway in other cases
<khush> fantasai: when you start mixing span values, you have this problem. span: 1 doesn't cause jumping backwards.
<khush> the most common case won't have this jumping around
<khush> as long as your slack is big enough yoy're always moving fwd
<khush> masonry-slack being too small makes it not obvious why the movement happened
<khush> noticeable difference between 2 columns for you to go higher. user won't understand why we moved unless the slack is high
<khush> astearns: i don't understand the argument that an em's worth of slack is more natural when none of the current libs give you that facility
<khush> fantasai: they just didn't think of it
<khush> astearns: it's been long enough. why no feature request?
<khush> fantasai: we might be able to do better than the js framework though
<khush> astearns: 1em is currently spec'd?
<khush> fantasai: yea
<khush> TabAtkins: +1 to fantasai
<khush> oriol: this would align with col-gap. it's initial value is normal.
<khush> should we do something more along the lines?
<khush> not 0 but normal keyword
<khush> oriol: there may be different cases where the value changes due to other things and changing the initial value would be harder
<khush> so yes
<khush> fantasai: sounds good to me
<khush> oriol: i still believe defaulting to a positive value will trigger confusion
<khush> fantasai: surprised and delighted?
<khush> astearns: any implementations?
<khush> fantasai: not yet
<dholbert> I have a concern that 1em as a magic value might produce unexpected layouts, if a user has a different font-size in their UA stylesheet etc
<dholbert> 1em as a threshold of "a distance that a user may notice" is a bit fiddly
<dholbert> which means I think I agree with a "normal" value, but I'm not sure how it should be defined. :)
<fantasai> dholbert, it's not 1rem, it's 1em :)
<khush> astearns: we don't have a basis to decide this issue. let's implement and get feedback from authors. revisit once we have that data
<fantasai> so it will always scale with the font the author chose
<kbabbitt> +1 astearns
<miriam> I would consider 1lh…
<khush> fantasai: let's resolve on what we have
<dholbert> fantasai: if a user sets a minimum font-size in their browser, I thought that still impacts 1em sizing? need to confirm
[selectors] Pseudo-class to indicate when a slot has content
<khush> keithamus: has slotted is a pseudo class. it is the opposite of definition of default slotted
<khush> has slotted means that it has been slotted
<khush> we resolved on the issue to just have the :has-slotted pseudo-class
<khush> a bare pseudo class. not functional one
<khush> i want a functional one which takes a compound selector
<khush> lea has raised a PR of non-functional pseudo-class
<khush> could we resolve on both
<khush> lea: there are distinct use-cases for both
<khush> the non-functional version is not an alias for :has with *, because the non-functional version also matches text nodes
<khush> have chatted with implementors, bare version is easier
<khush> i want it to move fwd
<khush> there is confusion with has(slotted)
<khush> we don't have slotted pseudo-class, only pseudo element
<khush> there is potential confusion in terms of authors not understanding
<khush> but functionality is clear
<khush> we could name it something related to fallback, but I'm not sure if i would be in favour of fallback based naming
<khush> since we want it even if there's no fallback content
<khush> but just mentionning
<khush> emilio: the bare version is very straightforward
<khush> the functional version feels hard to implement. naming suggests we're looking at descendants. what's supported would be confusing
<TabAtkins> I don't think it would be that confusing. It would be interpreted basically identically to ::slotted()
<khush> keithamus: there is confusion around what combinators would do
<khush> should only match the slotted element
<TabAtkins> If ::slotted(.foo) would match an element, :has-slotted(.foo) will match
<khush> emilio: it might be worth naming it after nth-child perhaps
<khush> has it been considered?
<khush> the naming is off and confusing, otherwise it's fine
<khush> the bare version is extremely simple to implement
<khush> emilio: you mentioned you wanted it to also match fallback content.
<khush> lea: if we wanna change the naming to not confuse with has, it could be fallback-show
<khush> the matching would be the same logic
<Zakim> lea, you wanted to also mention :has-slotted variant that excludes whitespace-only slotted nodes
<khush> lea: since this has to reflect the behaviour of existing js api
<khush> even if only slotted is blank white space node it still has to match
<khush> we want a bare slotted version which includes just whitespace
<khush> is that easy to implement>
<khush> ?
<khush> fserb: maybe the name would be better as revered
<khush> has-fallback-content for example
<lea> :fallback-shown is also nicely analogous to :placeholder-shown. What happens with that pseudo-class if there is no placeholder on the input?
<khush> keithamus: i like the symmetry between the 2. renaming would make them asymetrical and cause confusion
<Rossen9> scribes list - David (shapes) Kevin (first scrolling), Tab (later scroling),
[css-shapes-2] Add a way to change an element's shape
<noamr> w3c/
noamr: I posted the comment from smfr with a proposal
fantasai: The proposal is to add a new border shape property
fantasai: We can probably split discussion into concept vs. specific syntax.
fantasai: The idea of a border-shape property is that it defines shape of border edge of box.
fantasai: It can both cut in to border edge and go out. It just gives a new path.
fantasai: We use that for painting purposes only.
fantasai: So backgrounds, border. Doesn't affect layout.
fantasai: The syntax here subsumes the corner-radius step. We can talk about that...
fantasai: We could make it a shorthand for corner-shape and border-radius and another thing that has a path.
fantasai: The proposed syntax has several variations.
fantasai: One is to provide border radius and corner shape values and derive shape from that.
fantasai: Another is a basic-shape that gets stroked.
fantasai: With shape function you can provide shapes relative to the box.
fantasai: Third option gives 2 paths, one for the outer border edge and the other for the inner border edge.
fantasai: you fill in between them.
fantasai: There's an example in the issue showing how that would work.
fantasai: With the shape function you can have fully responsive shapes.
fantasai: That's the basic proposal, we can go into details from there.
lea: First, +1 to pursuing this. This needs solving, outstanding for some time. This avoids complexity about how borders adapt to regular shapes.
lea: I think we should avoid basing things on corner-shape or using it as precedent. I think at this point it was a bad design that we need to rethink.
lea: It introduces a lot of complexity for things that aren't needed.
lea: I'd design this ignoring corner-shape.
lea: Naming border-radius around borders is a recognized mistake in CSS.
lea: I worry about calling this border-shape. Element might have no borders.
lea: I think it makes more sense than border-radius here because it's defining the shape of the border.
lea: Though there's complexity about what if these paths intersect.
<fantasai> SebastianZ's refinement of the proposal
lea: Also, does border line style need to be a part of this?
lea: Would be nice to see examples with real world use cases and the syntax.
fantasai: I've gone back and forth on the border-radius question for that reason.
fantasai: It does give border edge rather than padding edge or content edge.
fantasai: We could call it box-shape if we wanted something different, but might be useful to be consistent.
fantasai: I think I disagree on corner-shape, it's a good way to do common cases like beveling.
TabAtkins: This proposal looks good to me. I think all 3 variants are useful.
TabAtkins: Simple one, single path, or two paths.
TabAtkins: A little weird: the way to specify fill on 2 stroke path is weird. The fill is specified using a border-area background-clip value.
<lea> TabAtkins, background-clip: border-area; was something we resolved on months ago
<lea> it's not part of this proposal
lea: background-clip border-area was something we resolved in February
lea: It's something we've already specified, not being proposed here.
TabAtkins: I'll leave it alone though I think we're overloading background.
noamr: Wanted this in my web developer days. Popup baloon on wikipedia.
noamr: I wonder if this is 3 proposals.
noamr: I think the third one with the 2 paths is complex and has many questions. Could we start with other 2 and then add the third?
noamr: Or do we need to specify all at the same time?
noamr: Most use cases seem handled by second type.
noamr: Also needs clarification, important for this proposal: it's not just about painting, but also clips descendants like border-radius.
fantasai: only if you specify overflow
noamr: yes, same clipping semantics as border-radius
<TabAtkins> I'm not sure what looks particularly complex about the two-path version. Fill one shape, cut out the second shape, that's well-defined to do with a single path using reverse winding on the "inner".
noamr: Reason why border-line-style options are specific and not using the existing ones is that some of the values don't work with arbitrary paths.
fantasai: This is the rendering simon gave me about how border colors should work.
fantasai: Now when you specify border colors there's a diagonal cut where the color changes. That's calculated from the inner and outer border stuff.
fantasai: From this picture I think he's proposing we use that same calculation. This isn't especially useful. But it's a clear path from the existing behavior to what we'd do as the border path.
fantasai: and generally you only use one color.
fantasai: gives a defined rendering for the other cases.
fantasai: We could consider other options but this seems like the best idea so far.
fantasai: Regarding inner/outer paths, Simon's rendering is weird. But use case: consider a speech bubble. You don't typcially want a single thickness stroke around the entire speech bubble. The corners are narrow, middle of curve is thicker, etc. Or some other pen/brush-like effect.
fantasai: So variation in thickness of stroke of border is a common scenario.
fantasai: That's the use case for having two.
astearns: To noamr's point, those could be separated and we could get to them later. The first 2 bits don't depend on it.
fantasai: but we have a proposal that also addresses those.
lea: Re fantasai, I agree the diagonal could be any angle, just needs ot be well defined.
lea: grammar is hard to parse here. What happens if you specify only one shape, or do you always need an inner and outer.
TabAtkins: Can specify one shape and you stroke that shape.
lea: Discussions in June about difficulty of offseting a path to make it smller or bigger.
TabAtkins: IT strokes the center of the path; if you want inside/outside you need to specify two.
fantasai: You could have it represent the outer edge, stroke it, and clip it, but that's...
fantasai: The stroking in the middle is one thing I don't like about this.
lea: That would force authors to use 2 shapes in many cases when they could use one.
<fantasai> s/lea: You could/fantasai: You could/
lea: forces authors to specify a path that's not visible at all in their layout
lea: I noticed in the rendering that some text is clipped, how does that work?
fantasai: With border-radius it's clipped if you specify overflow.
lea: Would be nice to see what happens if you don't
fantasai: Just draws on top like any other box.
fantasai: we're not chagning the layout, just the border and background painting
kizu: This issue with overflow -- we might want how to make it accsesible in most cases. ??? ??? How we can make a big border-radius. For example, making big area by default -- by default the content if hidden or auto will not ??? and will exapnd further
kizu: It would be nice by default to not put content under something that's hidden.
kizu: Would be nice to find a safe solution for this.
kizu: This is a proposel that I'd want to see. ??? define shape in a way that borders still work.
kizu: I will check... It will depend on ths proposal to make compat shapes as boxes.
fantasai: With an arbitrary shape there's no real way to make extra padding magically. The intrusions might not be at the bottom. If it's hourglass shape, what does that do?
<astearns> there is shape-inside…
fantasai: This has to be something that ... shape of the box. Up to author to adjust the padding.
fantasai: For authors adjusting shape... we still don't have a way to make shape-inside to something s in a responsive + performant way.
fantasai: border-image doesn't avoid the content. If you make the border thick it does. But if you use insetting ability then you don't have that.
fantasai: It will paint under the content.
fantasai: I have some questions.
<TabAtkins> +1
fantasai: First, do we want to adopt a border-shape property such as this one, in princple?
(questions to the group)
<astearns> and as a hack, you could use shape-outside to mimic the inside edge of the fancy border
<noamr> +1
<kizu> +1
<kbabbitt> +1
<astearns> +1
fantasai: with details ot be worked out later
<chrishtr> +1
<miriam> +1
<lea> +1 but very concerned about the single shape syntax
astearns: back to noam's point of separability, we can draft this, and if we find the 2 shape thing is more complicated we can mark it at risk or move to another level
noamr: or give it TODOs
fantasai: but this is the beginning, so draft what we can
chrishtr: what about animations?
fantasai: yes, you can animate it
fantasai: given with shape syntax, animates same way as shapes
chrishtr: can it be HW accelerated?
fantasai: as much as anything else?
chrishtr: has the team tried? Expressed in shader, put on compositor thread?
fantasai: I don't know implementation details.
chrishtr: would be good to follow up on that question
fantasai: sure, but does that block anything?
TabAtkins: Given that we can hw accelerate clip-path, seems similar.
noamr: we don't hw accelerate border (?), we don't hw accelerate clip-path yet. We don't accerelate border-raidus if it's complex.
chrishtr: We draw it with a shader when possible. But we don't accelerate animations of it.
chrishtr: I want to make sure the syntax gives us a path to doing that.
noamr: I think the challenge is the complextiy of drawing borders, not the shapes.
chrishtr, noamr: color, image, storke, shadow
lea: Were lots of +1 about working on this. I wanted to get clarity on what's a detail?
lea: Would people be open to improving single shape syntax so it doesn't define something that's not visible anywhere.
fantasai: Just question of whether we want to solve the problem.
fantasai: I don't want to dive into all the details without agreeing that we want to pursue the general idea.
ydaniv: Why you can't do something like shape-outside to offset text?
fantasai: you can, yes
ydaniv: so if you want text overflowing, and also ?? on top of it, you can use shape-outside
<astearns> shape-outside uses floats. this would not
fantasai: You can use shape-outside on a shape element to flow text around it. But there are interesting problems with shape-inside.
fantasai: This proposal doesn't change layout. You could use the same path in shape-outside (which we have) and shape-inside (which we don't).
Rossen9: do we want to resolve on all 3 or one at a time?
fantasai: Let's go one at a time, I have more questions on specifics.
Proposed resolution: adopt border-shape in principle and continue to discuss specifics
RESOLUTION: adopt border-shape in principle and continue to discuss specifics
fantasai: Next question: what should we call it?
fantasai: Current proposal is border-shape.
fantasai: Do people want to suggest other names?
<kizu> I like `box-shape`
fantasai: Quickly, could bikeshed more later.
noamr: Argument for border-shape -- it's in the family of existing things. We already have border-radius even if we don't like it.
noamr: this makes it discoverable
fantasai: We have border-shape and box-shape. Should we straw poll?
<fantasai> 1. border-shape
<fantasai> 2. box-shape
<castastrophe> 1
<TabAtkins> 1
<kizu> 2
<kbabbitt> 1
<fantasai> 0
<futhark> abstain
1
<noamr> 1
<alisonmaher> 1
<astearns> 1 (for now, ok to bikeshed later)
<Rossen9> 1
<kschmi> 1
<masonf> abstain
<oriol> abstain
<ydaniv> abstain
<noamr> (box-shape feels like a layout thing)
RESOLUTION: Call it border-shape for now
fantasai: next question: should this be a shorthand that sets corner-shape and border-radius properties, or should it be a separate property than when sets, overrides everything else regardless of cascade
fantasai: I feel like shorthanding makes sense, but question about what happens if you set both.
fantasai: If we make it a shorthand then if you specify either a shape or corner then that's what you get for sure.
fantasai: If it's a separate longhand, then the border-shape always wins.
fantasai: We could go either way... could also open separate issue.
astearns: I would like to take this to an issue. I'm happy to have something in the draft with issue in it. But I don't think we can design this in committe right now.
lea: I agree that this needs more design work. I also don't think we should design around corner-shape, in spec for >10 years and not implemented. If we're adding a new thing, do we *also* need corner shape? We already have border-radius for common cases. We don't need another new way to set element shape.
lea: For something it might be easier, let's define a shape funciton and continue to use element shape for them.
fantasai: Counter to that is that there are common use cases. When you're using a path you have to give a path for the whole shape. Corner shape lets you set corners independently, can do writing-mode-relative easily.
fantasai: When you're doing something compcilated you need to specify the whole path.
<Zakim> lea, you wanted to react to lea
<Zakim> fantasai, you wanted to respond to that
lea: That would apply if all we could do is specify path. But there's a lot to shapes: inset, etc.
fantasai: But you have to set them all. But if you want a slash shape, you have to define the path of the whole box rather than just the corner.
fantasai: I think that's a much easier thing when that's what they want,which is common.
fantasai: So I think the border-shape properties make sense.
fantasai: But that doesn't really affect this question because we still have the border-radius properties.
fantasai: corner-shape is only a minor additional complexty
lea: That's a ???. corner-shape does make some cases simpler. But it has cruft for things that aren't really needed.
lea: For things like bevel, helps with some polygons, but most polygons in the wild have rounding which it doesn't account for.
TabAtkins: ??? concern is that I don't care about shorthand or complicated direction. If you just set border-shape it should do the right thing. It looks like in the example he didn't to do something to explicitly cause the regular border to not render. It should work better in that case.
TabAtkins: If you set border-shape it should affect the other border properties appropriatly without author needing to do extra work.
castastrophe: Question: is there a perf gain for repainting just a border corner versus a larger shape?
fantasai: no idea
fantasai: I also don't think that's a consideration; we should worry about the ergonomics.
noamr: We could probably figure out from any shape, could reverse-engineer it to a corner-shape and get the same hypothetical perf benefit.
fantasai: So on this question we're opening a new issue.
fantasai: ANother question: do we want the 2 path syntax where you can fill between or do we think that's not worth trying?
fantasai: The current proposal has a stroked 1 path version and a filled 2 path version. Do we like both options or want just 1?
<astearns> +1 to add it in for now, issues to remove or postpone as necessary
noamr: I tihnk we want both shapes, question of editorial understanding and iteration on spec to make it readable.
<TabAtkins> 1-shape super restrict you to *solely* the geometry of a shape's stroke, that's quite limiting (if common)
lea: especially if we don't figure out how to offset paths property, I think the 2-shape syntakx is essential for specifying what you want
lea: If you don't have a way to specify the shapes explicitly then it doesn't have the necessary level of control.
lea: we definitely need the 2 path syntax esp. if we don't figure out the 1 path syntax.
(I think lea meant offsetting for the 1 path syntax.)
RESOLUTION: specify the 2 path syntax
RESOLUTION: also specify the 1 path syntax
fantasai: One other question from smfr, a little orthogonal, do we need additional keywordsfor background-origin.
fantasai: and maybe background-clip
fantasai: to change from using the layout box to using the box of the whole border shape
Rossen9: also sounds like a feature we can define once we get ...
<TabAtkins> Yeah, I think it's needed.
astearns: noam, would you be willing to become an editor for shapes2 for these features
noam: yes
astearns: my proposal is to add Noam as editor to shapes 2
fantasai: this goes in borders 4
astearns: ok, that spec in addition!
fantasai: I'm going to take actions to file followup issues, and I'm going to add this to the ED of borders 4.
[css-shapes-2] In `shape()` It should be possible to specify control points relative to their point on the curve
noamr: This is about the shape syntax.
noamr: Mostly saw ??? a bit complex to define shape syntax with bezier curves, cubic and quadratic.
noamr: When we define those curves we first define end points and then control points.
noamr: sometimes we want control points relative to start rather than to what we just defined which is the end
noamr: this can be boggling
noamr: In SVG control points go in order. They always end in the end.
noamr: Here we can have either order.
noamr: With keyword where you can specify 2 or specify ????
noamr: Simon added another issue that I think we should open separately.
noamr: Proposal here that I raised that we can discuss is that you can add the word "from" after specify point, can say "From start"
noamr: It's getting less and less similar to SVG, for better or for worse.
noamr: Do we want to keep it similar-ish to SVG, with same mental model, or do we want to break free from that.
noamr: We were breaking away a bit, but piecemeal.
noamr: I think it needs a higher decision about that.
<astearns> my vote is to break free if there is good justification
noamr: Specifically here because we changed the order of endpoints earlier, it makes it difficult to have points relative to start, and we need another keyword for that.
noamr: This becomes quite wordy.
noamr: I think with the property syntax, people sometimes avoid it because it adds a lot of CSS.
noamr: We need to be careful about not being too verbose.
noamr: The SVG ordering allows being a bit more terse.
noamr: I think switching the order and allowing using keywords is more verbose.
<lea> This issue seems to be related to #10647 (overloading path() for the path syntax that is closer to SVG)
I don't have an opinion on exactly ???, but it's complicated... but for the more general case of close to SVG or break free. I don't think we should pay attention to what SVG can do right now. We should continue expanding what's useful regardless of what we can port back to SVG syntax.
<ydaniv> +1 to TabAtkins
noamr: For now, proposed resolution would be that you can add from keywords that latches the next coordinate to the beginning of the segment.
noamr: you can say from-start, latches the previous coordinate to the start of the segment
<TabAtkins> Fine with this for now; I'll review more closely when I get back.
RESOLUTION: Add a from-start keyword that goes after the value and latches the coordinate to the beginning of the segment.
[css-shapes-2] Order of points and control points in `shape()`
noamr: This is a very related issue.
noamr: We resolved on allowing any order -- either control points first or end points first.
noamr: With verbosity it seems like it's making things unnecessarily complex
noamr: Maybe endpoints should always go first and control points second?
Rossen9: any reason we can't do it? Implementations that need to change?
noamr: Not shipped yet anywhere.
Rossen9: any objections to making the order strict with the endpoints first?
RESOLUTION: Make the order strict: endpoints before control points.
chrishtr: did you resolve to use the adjustment approach in the issue or what simon said in the beginning?
TabAtkins: I think the opposite.
noamr: yeah, what Simon was suggesting that the endpoints go firs.t
<TabAtkins> (noam's comment has the endpoints last; we resolved (correctly) on Simon's preference for endpoints first)
[css-shapes-2] Interpolation between `shape()` and `path()` needs more detail
noamr: This is about what happens when you animate betwen a path shape (a pixel based SVg string) and a shape (going farther and farther away from SVG).
noamr: There's already some ambiguities. For example with shape you always start from where theshape starts from, whereas SVG path functions start from 0,0.
noamr: smfr suggested just not animating.
noamr: This creates a cleaner ex.pectation -- just use a tool to convert your path to a shape rather than relying on the browser to convert for you.
<TabAtkins> +1 to pretending that path() has a `from 0 0` argument that tinterpolates with the shape()'s `from` argument.
noamr: The other option is more complex, is that path with moves it will be the first one to mix them together. In SVG path you can do to and by.
noamr: In shape you kind of can.
noamr: I think it's between those 2 options.
noamr: I think prefer to not interpolate between path andshape, but there was pushback in the issue.
noamr: ???
TabAtkins: This issue is about whether shape and path interpolate based on the from stuff.
noamr: I want to address this issue by ... this specific issue of the from is one divergence between path and shape. There might be more in the futuer. This issues makes me think they shouldn't be interpolated.
TabAtkins: There's a trivial transformation of the path string into the shape syntax, we should just do that.
TabAtkins: The path syntax will just turn into a moveto and a closepath if it was a shape.
noamr: So interpolate path as if it always has "From 0 0"
TabAtkins: my assumption this whole time is that the SVG path syntax turns into a bunch of shape commands
TabAtkins: Whavever arguments shape() takes given appropriate default value, in this case `from 0 0`, and interpolation is based onthat.
emilio: There will probably always be a way to turn a path into a shape. It feels a bit weird to do it automatically for interpolation.
TabAtkins: when things are easily inter-convertable, I think it's good to do so.
TabAtkins: for example 3 rect functions: inset(), xywh(), ...
emilio: those all compute to same function
emilio: this distinction is preserved at computed value time
emilio: given how trivial it is to turn a path into a shape, it feels like adding the special code path ???, ... it's fine
TabAtkins: I don't have a strong opinion, but doing it since we can seems right.
noamr: The difference here is that usually you start your path with a moveto.
<TabAtkins> TabAtkins: given how trivial it is to turn a path into a shape, it feels like something we should do for the author ^_^
noamr: If the path doesn'tstart with 0 0.
noamr: so your path will turn into a shape that doesn't have a from.
noamr: It starts it on the wrong foot.
noamr: Something about thsi conversion doesn't feel right.
noamr: It will be not exctly as intended.
noamr: Telling the developer to turn it into a shape yourself and decide if it's a moveto or a from, or use several movetos in the beginning, would be cleaner.
kbabbitt: A couple things: I'm curious why shape starts with this from to begin with. It seems like syntactic sugar for a move but maybe I'm missing something.
TabAtkins: All the shape functions have an origin. That ??? the motion-path.
TabAtkins: A starting point for where the motion path is from rather than forcing them to start at 0,0
kbabbitt: I'll have to take a closer look at motion path.
kbabbitt: I was just looking at the grammar for SVG path, it requires that the first command is a move.
kbabbitt: Another alternative: have from line up with the first move in the path.
ChrisL: That was a design decision, every path segment creates the start position for the next segment, so the first has to start with a move.
noamr: We need to explore whether this is enforced in the shape segment in CSS. If it doesn't that solves it.
<lea> can't we just default to a move to 0,0 if no move is specified?
<TabAtkins> https://
noamr: I think the resolution should be to align from with the first segment which is supposed to be a move.
noamr: With the constraint that we will check if this is actually enforced by browsers.
Proposed: Align `from` with the mandated first move.
RESOLUTION: Align `from` with the mandated first move.
[css-shapes] Overload `path()` for CSS-y SVG path syntax instead of taking up `shape()`
lea: As mentioned many times, SVG paths don't have the best ergonomics.
lea: Have been long discussions about improving.
lea: And not just expose the exsiting model with CSS syntax. Though there's value in exposing existing model in CSS syntax.
lea: Seems like we're trying to do both with shape() function.
lea: But we already have a path() function which has a very strange syntax for CSS.
lea: It seems reasonable to me that we should overload that function to harmonize with rest of CSS functions
lea: That frees up shape() to do what we want, we don't have to be consistent with SVG.
lea: We don't have to be consistent with SVG at all without being bound by legacy/baggage of SVG.
lea: Seems like it's 2 birdds with one stone. Make path() a reasonable function and free up shape() to do something more reasonable without baggage().
lea: Lea is that path() is CSS specification of SVG paths whose model stays close to SVG aths, and shape() can be whatever.
TabAtkins: I don't agree with this.
TabAtkins: I don't think we need to do more reinvention while keeping close to SVG.
TabAtkins: I don't think the SVG starting point is particularly holding us back.
TabAtkins: what SVG does is mostly fine.
TabAtkins: We can engineer around the awkward bits. curve sucks but we can do better curvens.
TabAtkins: I don't think we're limited in a meaningful way.
TabAtkins: I don't like when functions have significantly divergent grammar paths.
TabAtkins: It's clearer when path() is the SVG syntax and shape() is the CSS nytax, more teachable.
TabAtkins: I like the current approach and think we shouldn't change.
noamr: I t hink most useful thing about path() is that you can paste in strings from an SVG authoring tool.
noamr: It's a feature that can stay the way it is
noamr: Let sleeping dogs lie.
lea: I'm not proposing we drop the string argument of path(), just overload it.
lea: If you don't think the current shape() is a sigificant departure from SVG, then maybe we should just stick with path().
lea: All the other SVG shapes have CSS functions, path() is the odd one out that only takes a string.
lea: We should fix path to have a better design. Then question of if we need a new function. But I think we do -- fix how we specify control points, how we ??, fix arcs.
lea: We've discussing many improvements, many of which we can't backport.
TabAtkins: 2 things to repsond to -- all other SVG shapes are just elemnts with attributes, there's no data format to port over to CSS.
TabAtkins: path is the execption where the data are in a string
lea: polygon!
TabAtkins: Aside from the whitespace rules it's identical to CSS grammar.
TabAtkins: path() has nontrivial syntax that can be dropped into other contexts. Taking that is still useful.
TabAtkins: but also useful to take advantage of CSS and its gfull abilities.
TabAtkins: Second, I don't understand how points about gradually making shape better than what SVG can do suggest putting it into path(). If anyhting, I think shows separate function is better to underline that it's different.
lea: That's not what I was suggesting. If was saying that if we're significantly different it should be a separate function, but there's still value in a CSS serialization of path.
lea: I think you could do a CSS-if-ication of path syntax and allow that in path().
lea: Having to reach for a different function that has nothing to do with paths makes it difficult to learn.
TabAtkins: I don't see great value to users in a direct cssification of the path syntax.
TabAtkins: if people are using path syntax, they want to ureuse it, just take te string and go.
TabAtkins: If they're rewriting then rewriting into shape syntax which gives substantially more ???.
lea: I don't think it should be mapped that closely, but I'd take thit af itis' the only way.
lea: ???
lea: Taking a path from SVG and sticking it into CSS has limited utility because SVG paths are fixed sizes... current path odesn't deal with percentages, units.
TabAtkins: it's well defined
lea: It's well defined but not useful.
TabAtkins: are you asking to drop path() entirely?
lea: no
lea: I'm saying what either what we have now in shape() in which case it should be in the path() function, or it's far enough and we should improve the path() function and have the shape() function separately.
TabAtkins: I agree with second point except I don't think there's value with improving path syntax and I think we should stick with current approach.
Rossen9: I think we should take this back to the issue. Two contrasting opinions here.
<noamr> I think this proposal should be a bit more specific
Rossen9: Sounds like we should get closer together on the issue before trying to resolve.
Break until 11am PDT
github-bot, take up w3c/
[css-align][css-position][css-anchor-position] Introduce "document containing block" for some purposes?
<github-bot> OK, I'll post this discussion to https://
TabAtkins: Anchor positioning exposes details of the containg block a lot more than abspos did
… generally this works just fine, inset-area cares about how it's positioned relative to cb
… or if it's outside, it's an exceptional case and is also handled fine
… exception is when you're fixpos, because then you end up using the ICB which while is reasonably sized, is not a reasonably positioned rect
… ICB just sits at the top of the document
… and most of the document is outside of that rectangle
… which means that almost all of your acnhors need the exceptional behavior of anchor outside of CB
… while we have as reasonable as we can behavior, it's not ideal
… all an error case and always recovering
… all you really want for something like an element acnhored to something far down is to avoid flowing outside the bounds of the doc
… e.g. offscreen
… and that doesn't work well in the case we have here
… what you want is a CB that is the size of the visible document
… what that means is part of this issue
… My proposal is that this sort of request is useful outside of anchor positioning
… relatively common for people within a scrollable area to position in the bottom right area of ths scrollable content
… can't do that today wiothout an additional wrapper
… if you go to the bottom right with insets and it positions you in th ebottom right of the scroll container not the scrollable content
… people work around that today by using a replos wrapper around all of their scrollable content
… so their abospos can go to the bottom right of the scroll container
… making this behavior easier to opt into, and making anchor positioning generally work better when your CB is the document is worth fixing
… my proposal is that we have a new concept: the document containing block
… which is a rectangle size to contain all the stuff in the document
… we use that by default for anchor position ing if we would use the ICB
… also have some way to explicitly opt normal abspos into being able to reference this concept both for document and for any scrollable content
… two big questions: first what is this rectangle, how do you define it in a way that's reasonbly chjeap
… iank_ has an answer that works in Chrome and sounds approximately right
… don't know how generalizable that is
iank_: when you calculate the scrollable overflow for a scroll container
… you need to know where the end ? is
… and that's one of the calculations that goes into the whole scrollable area
… e.g. for grid this is defined as the end of the grid
… this is relatively cheap, the calculation is only based on the in-flow children at that point
… w/o transforms, usually what people wnat for this calculation
TabAtkins: : other questio would be how we can let normal abposes opt into it
… probably a position subproperty, don't want to solve for it now, can still devault anchor positioning to right default today
Rossen0: I missed the reasoning about, does top line get redefined as well?
… so that when you scroll, that positioned element also gets scrolled with it?
TabAtkins: No, the DCB will start still at the top left of the entire ducoument just like ICB, will just grow downward and rightward to contain entire contents of the page
iank_: not growing into negative space beyond the scrollable region
… there are cases .eg in rtl container where right would stay 0 and flips like that
fantasai: curious about the definition in the inline axis
… this totally makes sense, we probably want a similar concept for non-document scrollers
… agree with most of what you're trying to do here
iank_: easiest thing is unify behavior when we fixed the end point for the scrollable behavior
TabAtkins: I'm calling it DCB, need a better name
… intend it applies equally to other scrollers, if your anchor is inside a scroller you want same behavior
fantasai: you're suggesting for inline axis we use the point where we attach the inline padding? I agree with that
<Rossen0> Rossen
fantasai: have to think about exactly where else it would be used, using it for anchor positioning seems reasonable
iank_: when I as doing webdev stuff, I ran into this problem constantly
<flackr> +1
emilio: agree this a good thing in general
… esp when you get into edge cases e.g. rtl
… having something that consistentl covers scrollable areas gets tricky
… 2 questions, one: with regards to scrollable padding we add, you mean that CB would be included or excluded?
iank_: included
emilio: so it would cover everything, sounds good
iank_: we're not changing the fact that abspose references padding box by default
fantasai: any box that is scrollable when it gerneates a CB, genreates 2 CBs, inner and outer
… I guess it generates 3, you have the content one too
emilio: if you have something that overflows that cb, you have something that scrolls down
iank_: the reason the padding edge definition is useful is, you don't need to calculate the entire scrollable area
iank_: based on flow content this is where the padding edge is, then you run abspos layout
iank_: then you gather up scrollable area
fantasai: this comes from when we decided to add padding to scrollable area ... it only considers in-flow content
emilio: sounds good
iank_: that box is also nice because it doesn't consider transforms
emilio: wonder if there are use cases like, I want to ? the whole scrollbar
iank_: [missed]
fantasai: we've got each box generates 3 CBs, inflow CB which is content area, local CB which is this padding edge that takes over the area that scrolls, then outer CB which is the background attachment scroll box
… we need better terms for these
… in your comment you suggested position area would be one way to capture this entire area
… that reads really well
… issue says only when there's a valid anchor
… do we make position area do it always since it doesnt rely on anchor>
TabAtkins: potentially. I feel like that's a bit hacky and probably wnat CB control to be done via a more focused properly, more things in that vein you want to select between
… somewhat uninclined to fix things in this hacky way but could be convinced in another issue
fantasai: making it contidional on the validity of anchor is a little weird
… making it not that would be great, I have a few ideas
Rossen4: the position area bounds you define is based on the static content only but it doesn't include any abspos content?
TabAtkins: correct, no abspos no transforms
I'm thinking maybe `position-area` always applies, it's just that if you have no valid anchor then you always get the entire area
Rossen4: what about relative
<crosstalk>
iank_: it does not include relative
iank_: when it comes to adding padding to scrollable end, we have basically alignment on that
Rossen4: sounds like a very useful feature
TabAtkins: suggest resolution: Adopt the concept of document containing block (better name TBD) into position-4 and have anchor positioning use it by default instead of ICB
Rossen4: additional comments or objections?
<flackr> +1
fantasai: we should proably actually publish position-4
RESOLUTION: Adopt the concept of document containing block (better name TBD) into position-4 and have anchor positioning use it by default instead of ICB
[discussion about contents of position-4]
Rossen4: any objection on publishing FPWD of position-4?
RESOLUTION: Publish FPWD of position-4
github-bot, take up w3c/
[css-anchor-position-1] Define scroll interaction better.
<github-bot> OK, I'll post this discussion to https://
github-bot, take up w3c/
[css-conditional][css-anchor-position][scroll-animations] Snapshotting post-layout State
<github-bot> OK, I'll post this discussion to https://
futhark: there are multiple specs that do some sort of snapshotting of particular scroll state
… some specs try to specify this timing and some have not
… for scroll driven animations there is a spec that refers to the HTML spec
… that scroll position is snapshotted in the HTML ? at the begining of the animation
… there's a separate snapshotting that happens after resize observers
… in order to have a stable first frame and avoid flickering
… then there is the anchor positioning spec that emilio pointed out
… that has an issue to specify when this scroll position / adjustment snapshotting happens
… now we're working on state queries and I need the exact same thing for sticky pos state queries
… in this issue I propose we try to unify scroll snapshotting to a common point
… instead of referring to modified HTML ? from CSS spec
… the CSS specs that need to do snapshotting can say it needs to be done during these steps in CSS
… what I propose is that we introduce a new step called run snapshot
<TabAtkins> "run snapshot post-layout state steps"
futhark: do this between media query and update animations
… basically aligns with where scroll animations spec specifes to do it
… and then update the snapshots again and if the snapshots have changed beacuse of layout change, there is a second run of style and layout
… that is my proposal
emilio: first, why do we need two steps?
… could we do it as part of the resize observer step
… do content visibility stuff to prevent unstable frame issue
.
… I think that would be nice because you wouldn't need resize observer updates
futhark: right, that is actulaly what the current chrome implementation does
I talked to flackr and he said dieally in terms of the specification have it after the resize steps
flackr: it's fairly common that devs use resize observer to change the shape of something on screen
… you expect that these things that respond to scroll or anchoring or other things to be able to anchor to the content or the size based on developer ?
emilio: the loop is basically: update style and layout, then figure out ??, then figure out for resize observers wehtehr something's changed
emilio: if you ? you would potentially run multiple layout loops
emilio: and you could make it so that you ? resize observations probably
flackr: I agree and that's probably better, you could have resize observers respond to updated snapshot
emilio: other question is why do we need snapshot at beginning?
flackr: usually the scroll position doesn't change and you need to do some layout in your initial pass
flackr: so in the case where the thing that you're responding to hasn't changed as a result of scrolll, we onlyl have one pass through style and layout
flackr: whereas if you did it after you'd always have second pass
flackr: [missed]
flackr: and unless the result of running that caused scroll position to change, you have your result
emilio: you are doing the thing right after scroll events get sent
… but you have no guarantee that you have updated layout here right?
… and you would snapshot a potentially dirty tree or you would run layout there
<emilio> https://
emilio: proposal is iintroducing a step right after step 10 [in link above]
futhark: yes, that was our proposal, inspired by scroll animations spec
emilio: but you either run layout there, in which case it's not more efficient, or just snapshot ?
flackr: but there is a known scroll position at the least
… I guess you're saying some of these things could have snapshot there
emilio: in order to get consistent bejavior and not depend on... you would get different behavior if a media query change had updated layout versus not which seems bad
… so to get consistent behavior you need to update style and layout before doing snapshot
flackr: other reason to run at this time is I believe it's before rAF callbacks
emilio: no, it's after
emilio: nm, it's before
flackr: this also puts things in a correct animation state which is good for scroll driven animations
… your animations are based on the correct input state
… would be open to moving that around
emilio: if we put it before the update animations and send events you also need to update style & layout
… that seems promising because rAF is something people use to move content around
… so you want to update style & layout as late as possible
flackr: I think it might be okay to remove that early snapshot
emilio: that would be great because then snapshot the right thing, resize observer can react properluy
emilio: update events or animations can ? that snapshot
emilio: other than anchor positioning where the snapshot doesn't affect what the page can observe ...
flackr: I suppose if you had a rAF observer that was looking at the position of an anchor element, that observatio nwould forcea style and layout to make it correct
emilio: you would use the snapshot from your last frame
flackr: then it would be a correct ?
emilio: potentially
futhark: [missed]
emilio: yes and that's unfortunate because it causes inconsistent behavior if someone has updated style & layout before
… anything that changes frame that updates style & layout causes different offsets
futhark: we use information from last frame
emilio: not necessarily, you use info from last layout update
futhark: should be information from ?
emilio: would prefer to move this only to resize observer, then you get that behavioor automatically
… without changing depending on whether someone has updated ?
… the whole frame sees the updated offsets until the resize observer
flackr: right, it makes these scroll dependent queries basically equivalent to a developer observer
emilio: if we decided that we need for some reason after the offsets from before rAF then I think we should update style & layout to be consistent
… that's unfortunate
futhark: there are a couple of things I'd like to resolve on regardless of orderting
… creating this new run steps where we collect all these kinds of snapshotting in the same space for CSS specs
emilio: think that's great
futhark: strictly this forum cannot decide the order of the HTML event loop
… but creating that step is one resolution I'd lie to make
… propose CSSOM-view for it
Rossen4: back to first resolution which is adding this step for snapshotting
… is there anything else we need to discuss about it?
… not sure if there was agreement
flackr: I think we have agreement, I think this is okay to draft
… my only concern is things devs to in rAF
… but that's also a problem with anything they do in resize observers
emilio: already the case if author has updated layout manually
flackr: I do think that case is less common, still common but majority of updates are scroll with no dirty layout
emilio: in that case we're observing a dirty tree because you haven't done layout yet
flackr: if the animation time is updated according to the new scroll position, then a rAF observing some style or layout property will force an update, getting the correct for now position
Rossen4: back to resolution, any objections?
<futhark> “run snapshot post-layout state steps”
RESOLUTION: run snapshot post-layout state steps
Rossen4: second part was figuring out where this should go
… was suggested to put in cssom-view
futhark: that's kind of arbitrary based on where scroll steps were
emilio: seems fine to me
RESOLUTION: add it to cssom-view
futhark: the rest here is really WHATWG's HTML spec change
github-bot, take up w3c/
[css-anchor-position-1] Define scroll interaction better.
<github-bot> OK, I'll post this discussion to https://
emilio: the timing of the operation was already discussed
… seems we should put it somewhere in HTML, not talk about it here
… other problem is that the whole anchor element doesn't resolve
… depends on whether there's an anchor function which means that gCS doesn't round trip anymore
… feels quite unfortunate
… setting the inset to a fixed value would remove the anchor ness and that would just break positioning
… that seems kind of bad
TabAtkins: that is the case, I agree it's bad, we have a case or two of that already with the shadow related things we were talking about before
… agree they're not great
… don't know how to get around it unless we add a syntax to let it reflect the fact that there was an anchor
… indicate that it was anchored even though you're using an explicit value
emilio: could also include scroll offset in resolved value but that might be weird too
TabAtkins: I'd have to think about that, might work
emilio: we can think about it and figure out a solution
TabAtkins: would not mind coming up with something that addresses this problem, let's see what we can do in the issue
github-bot, take up w3c/
[css-conditional] @container scroll-state(snapped) and snapchanged vs snapchanging
<github-bot> OK, I'll post this discussion to https://
futhark: this is an issue about scroll state snapped
… question of whether state queries should match at the same time the snap changes or also including snap changing
… think it makes sense to maek state query change while you're scorlling
… got some feedback from ? that he thought you might want to have 2 separate queries
… one that changes with snap query and one that's only matching after ?
… just looking for input, if someone thinks current behavior matching snap changing is good or if there are any other suggestions
TabAtkins: I agree that if we continue to keep just one query, having it match the snapchanging event so you'll start succeeding on the element that is becoming snapped is right
… Adam's argument about having 2 is intriguing, would like to see an example
… could easily be convinecd that it's a good thing to do
futhark: happy to resolve on matching snapchanging
flackr: also agree that snapchanging is the right first step would like to see use cases for snapchanged
<flackr> w3c/
flackr: also wanted to point out open issue about what snapchanging targets
… 10838
… where I think, Adam has potentially requested a third possible query
futhark
futhark: just to correct a bit about what I have implemented so far
… checking oth snapchanged and snapchanging
… in case there's snapchanged that happened without snapchanging
flackr: that is not supposed to happen
miriam: I think I basically agree with TabAtkins and flackr
… to clarify, snapchanging is inclusive of ? changed
… we're not saying it matches only when it's changing but also when it has changed
… agree we're starting in the right way
Rossen4: other opinions?
futhark: currently snap... if that's a bad name, if we decide to add the scroll changed / snap changed later... [?]
flackr: are there other patterns we could follow
TabAtkins: I don't think we have precedent yet
miriam: I think snap is nice for the default
… we can figure something else out for the other
futhark: we can just resolve that snapped matches snapchanging
Rossen4: other comments?
RESOLUTION: snapped matches snapchanging
CSS Forms
astearns: just before eth power went out Tuesday, we took a resolution on what the scope of the new CSS forms draft is gonna be
<astearns> https://
astearns: there was some confusion about the scope of that resolution
astearns: it's "this is the *scope* of what will go into the draft"
astearns: the only thing we resolved about the specific *concepts* into the draft are the principles
astearns: the rest we're gonna wait for Apple's proposal, and look at what OpenUI has, and we'll have further discussion/resolutions about what actually goes into the draft at that point
astearns: so the resolution wasn't "we're gonna adopt Apple's currently-unseen proposal and put it into the draft", we've got more steps
<chrishtr> +1
github-bot, take up w3c/
[css-ui] Support setting offscreen content inert
<github-bot> OK, I'll post this discussion to https://
<masonf> +1 thanks
flackr: we talked about this previously, there were some open questions and a arequest to talk to a11y folks
flackr: i've done both
flackr: certainly a controversial area, but i think a11y folks are largely in support of making it easier to match the expected a11y of these use-cases
flackr: and i've outline a way in which a property could explain the inert attribute, so we don't have complex interactions between the two
flackr: could we pursue the proposed option of adding a new property for this, and the UA stylesheet explaining inertness?
w3c/
flackr: Option 1, bikeshedding welcome
chrishtr: Is Scott's comment in line with this?
flackr: I believe so, yes, he has some additional comments about how/when you should be able to escape inertness.
emilio: This also affects how browsers implement this
flackr: It mostly tracks how browsers implement, but the current proposal has the ability to escape
emilio: In Gecko, you can't - we implemented <dialog> stuff without the :has() (it doesn't work with shadow Dom)
emilio: we implement escaping the same way
emilio: the only reason authors can't escape inert now is because we don't expose the internal property that allows that
emilio: exposing it contradicts some of the discussions a while ago when this was being discussed. I'm personally okay with it, tho.
emilio: part of the reasoning to not expose to CSS was a lack of use-cases, but it seems there are some
Rossen4: so back to the original proposal, Option 1.
Rossen4: Objections?
emilio: to clarify, this is inherited?
flackr: yes
emilio: okay, instead of doing wonky pseudo-inheritance
RESOLUTION: Accept Option 1 in flackr's latest comment
github-bot, take up w3c/
[css-overflow-5][css-scroll-snap-2] Snapping and generating scroll-marker pseudo-elements from fragments
<github-bot> OK, I'll post this discussion to https://
flackr: we had a previous discussion about the use-cases for snapping and generating scroll markers on column boxes
flackr: based on some of the discussion/concerns, i'm proposing we go with a fourth option
flackr: define a ::column pseudo
flackr: that you can attach scroll markers to, set scroll-snap-align on. potentially we could expose more props in the future
flackr: and I think this resolves a lot of the issues we had, and is consistent with some of elika's comments
<TabAtkins> +1 from me
Rossen4: Rune, you had comments on this issue
flackr: you commented on the ::nth-fragment option, but the proposal now is to go with a ::column pseudo
futhark: that's kinda a sidenote, about styling columns when elements fragment across them
futhark: is that relevant now?
flackr: I think there's one potentially relevant question here.
flackr: if you set scroll-snap-align:inherit...
futhark: yeah, which one do you align if an element breaks across columns
flackr: need to decide if we inherit
flackr: if we never support selecting particular columns, it's okay
flackr: but if we do, you could inherit different values on each fragment
fantasai: there shouldn't be inheritance
miriam: why?
fantasai: we could go either way in theory
fantasai: I think there are use-cases for having *some* sort of inheritable pseudo-element, but that's really complicated
fantasai: but a lot of times you just want to address the pseudo itself as a box
fantasai: another issue, ::column is a pretty generic name, we have columns elsewhere.
<miriam> got it, makes sense - thanks
fantasai: if we have it just be a leaf box in the tree, it's easier for us to reuse it in those other contexts
flackr: proposed resolution, add ::column pseudo-element as described in the issue
flackr: it's a leaf node (nothing inherits from it), and it supports scroll-marker and scroll-snap-align for now
futhark: you said nothing inherits from it, what about ::scroll-marker?
fantasai: nothing *in the tree* inherits from it. chained pseudos still do, as normal
RESOLUTION: Add ::column pseudo, as a leaf node on the multicol, supporting scroll-marker and scroll-snap-align
github-bot, take up w3c/
[css-overflow-5] Scroll button pseudo-elements
<github-bot> OK, I'll post this discussion to https://
flackr: the ::scroll-button pseudos let authors easily add buttons scrolling partiuclar directions to a scroll container
flackr: last time the main thing tha tprevented us from resolving was a lack of clarity on how they would work
flackr: i have a specific list of answer to the open questions in my comment
flackr: basically, ::scroll-button(<direction>) syntax, taking logical or physical directions
flackr: the buttons come before the scrolling contents in focus order, all together
flackr: they scroll one "page", as determined by the UA similar to PgDn, in the relevant direction
flackr: I have opened a separate issue specifically to talk about the focus order of th epseudos with respect to each other
TabAtkins: I was gonna ask about that, happy to have it in a separate issue
lea: this seems reasanable. could we have a non-parenthetical version so you can style all of them the same way without enumerating them?
fantasai: that makes sense, but I'd keep the parens and let it be empty
lea: why?
fantasai: it's more like a universal selector
fantasai: we have other patterns similar to this
lea: we have precedent for un-paren'd pseudo-classes
fantasai: yeah, but pseudo-elements don't have that precedent. VT pseudos, for instance.
lea: Okay, no strong opinion.
<lea> I think `::scroll-button` is cleaner than `::scroll-button()` but not a hill I'd die on
flackr: proposed resolution, add ::scroll-button() pseudo-elements to Overflow 5, as describe din the issue
RESOLUTION: add ::scroll-button() pseudo-elements to Overflow 5, as describe din the issue
end
<br until=2pm>
Scrolling Continued
[css-overflow-5] Creating scroll-marker groups within which to select an active marker
flackr: ::scroll-marker() have an implicit element [missed]
flackr: but when using anchor tags to create scroll markers, the grouping mechanism needs to be explicit
flackr: currently proposal is to use ? as focusgroup
flackr: do we want to do this? should that be dependent on focusgroup existing?
flackr: should we add a specific attribute name or something on ancestor of elements?
flackr: My suggestion was stick with focusgroup as container of elements
flackr: ergonmically it means any time you create a group of scroll markers they will have arrow navigation among them
flackr: because that's what focusgroup does
flackr: it'll also pull in any focusable elements
Rossen6: what's the proposal?
flackr: outside of CSS, but would push for an attribute, either on links themselves to how radio buttons have a name
flackr: or attribute on an ancestor
flackr: to capture all of the anchors as a marker group
flackr: I would propose explicit name as more reasonable alternative
Rossen6: was this already socialized beyond CSS, with a11y or HTML folks?
flackr: original proposal was socialized
Rossen6: seems reasonable for now...
fantasai: this doesn't affect making a scroll marker, just navigation among them
flackr: we need to choose the active marker among a group of active markers
flackr: need a group to select from
kbabbitt: suggestion to change, alternative mechanism, was there feedback? or just something you were thinking about?
flackr: not based on author feedback, but more spec concern that focusgroup is not yet specced
flackr: so relying on a feature to develop the HTML version of this that still needs to pull out into its own spec
kbabbitt: but radio button group does use a named identifier
flackr: if we have concrete proposal, happy to take to HTMLWG, but 'name' is not available :)
fantasai: would help to show your demo and markup, so everyone has full context on what you're asking
<Zakim> fantasai, you wanted to ask robert to show the markup so everyone is on the same page
flackr: [projects demo of table of contents of a doc, dots on the right]
flackr: Look at source, we have <ol focusgroup> on the table of contents, ancestor of all the related links
flackr: similarly we have focusgroup on an ancestor of all the circles
flackr: so that's created two scroll marker groups
flackr: where one is active in the left group and one is active in the right group
flackr: the inline links in the doc don't become active because not part of the group
flackr: this is how written now. Alternative would be possibly some sort of name attribute on each link
flackr: or add any attribute on an ancestor
fantasai: styling the active one with ...?
flackr: :checked right now. Issue about bikeshedding that name?
kizu: I like this proposal, focusgroup sounds like a good way to grou pit
kizu: only thing to have that would be nice would be to opt-out some of the ??
kizu: you might want some of the items excluded, only use prior items. Or even highlight multiple...?
kizu: I guess can just use :has(:checked)
kizu: [missed]
kizu: use case, summary collapsed with elements, if they do not currently display should be excluded from the group?
flackr: that's an interesting question
flackr: if I put display: none in here
flackr: then supposed to select other markers
<astearns> fantasai: I think this should be a style
fantasai: I think that this should be a style property rather than an html property
fantasai: if you want your ToC to be different, then yeah, it should be in the html
<lea> +1 fantasai, and we should figure out what the right style primitives are to make this feasible/easy
fantasai: but if you want to change the scroll marker [???] effect, then that should be a property
fantasai: I don't think that doing this markup is the right place to do it
fantasai: so that would mean you wouldn't have the up/down arrow effect. but you'd at least get the :checked styling
flackr: Makes sense
<miriam> +1
<kizu> +1, if it is possible to make it just via CSS, it would be more flexible
flackr: appreciate suggestion of doing as style
PROPOSED: Enabling active scroll marker styling and grouping should be done via CSS properties
<kbabbitt> sgtm
lea: agree with fantasai that this should be a style, but haven't dived deep
lea: but it does seem like styling
Rossen6: others?
Rossen6: objections?
RESOLUTION: Enabling active scroll marker styling and grouping should be done via CSS properties
Publishing css-overflow-5
https://
fantasai: should we resolve to publish FPWD? Not published yet, but we're actively working on it
Rossen6: do we want to wait for edits?
fantasai: yes but want to put some pressure on flackr to publish :)
Rossen6: you feeling the pressure?
flackr: I'm feeling the pressure
[css-overflow-5] Improve active marker calculation
flackr: Currently in spec we select the marker whose target has scrolled at least as far as, if not further than,
flackr: but this means that as you scroll into next section, doesn't become active until it hits its aligned position
flackr: e.g. at top of viewport
flackr: similarly for carousel use cases, doesn't switch until next item is completely scrolled into view
flackr: [demo of lag in the scroll marker]
flackr: proposing more intelligent selection, finds next marker when it's closer to the viewport
flackr: rough proposed algorithm in the spec
flackr: details are nuanced, because don't need to be larger than scrollport
flackr: for example distance from one heading to another
flackr: so wanted to take a resolution that yes, we make changes
flackr: similar to if we were snapping, would change to the new thing
flackr: not quite the same because scroll targets could be headings, not the entire section
flackr: so this is why we can't share exactly the scroll snap properties
fantasai: haven't thought through it in detail, but going in this direction does make sense
florian: Makese sense to go in this direction, but wonder if it shouldn't be a quality of implementation issue
florian: Can imagine variants
florian: e.g. if you are scrolling towards one vs (missed)
florian: may be some nuances
flackr: could keep it open for now
flackr: but in any case what you're proposing shouldn't be disalowed
miriam: there's some advantage to predictability
miriam: so I have some concerns about being too clever with it
miriam: which makes me lean other way from Florian, maybe better to keep it simple and consistent across browsers
miriam: definitely I don't trust the concept of "closer" because one heading can be much closer when still not in th viewport
miriam: it has to be a lot more clever than that
flackr: cleverer thing written in the issue
miriam: don't want to lose simple and predictable
flackr: would it make sense to come back with a concrete somewhat clever proposal and see if we can agree on it?
kizu: what's proposed there in the issue makes sense
kizu: this is close to my latest implementation of this
<kizu> w3c/
kizu: [describes his latest marvel of CSS engineering]
kizu: in Chrome you can see how it works
kizu: I really like this, it's very in line with what flackr wrote
kizu: but would be nice to see exactly what's proposed
<Rossen6> ack *
florian: for discussion with mia, goes both ways
florian: to the extent people will build on it, better to have more predictability
florian: on the other hand this is in UX space, and trade-offs in one UA might differe from other UA, possibly depending on input modalities
florian: I would expect UAs to fine-tune this, which might result in different answers
florian: so providing flexibility seems useful
miriam: less about building on top and, already there are use cases where I would want different ansewrs
miriam: if I was being clever
miriam: I would come up with a different clever algo for ToC than for carousel slider
miriam: so that makes me mistrust the idea that we can find one clever option that will work across use cases
flackr: could add for a snapping carousel, if using scroll position that you would land on after snapping
flackr: so this exampe with carousel is slightly contrived, since I'm holding downt the scrolling mechanism
flackr: but in any free-flowing content, this problem is as I showed you
fantasai: I don't remember what's in the spec, but if there are constraints we are sure of, e.g. this should definitely be the scroll marker, we should document those in the spec
fantasai: for cases where we need to decide the next action, we/miriam shoudl document some use cases
fantasai: flackr should perhaps document the parameters that are worth reasoning about when comparing strategies here
fantasai: once we have the examples for these use cases, we can decide which direction to go
flackr: what sorts of examples might be handy?
fantasai: e.g. "if you're an implementor and you're looking at these two cases, here's how you might write an algorithm to land on the right thing"
fantasai: maybe with an illustration, but that's optional
flackr: Propose resolve as keep spec as-is, but miriam adds use cases, flackr adds example algorithms ...
flackr: but might require resolving that there's flexibility in the spec
flackr: so should we resolve on flexibility in the spec?
fantasai: there's some flexibility, and some non-flexibility
fantasai: there are cases when e.g. you'd land on a thing where it's obvious you need to pick that scroll marker
flackr: I think for this demo should relax it a bit
flackr: so need to remove the explicit algorithm about finding the thing before the current scroll position and use more open language
flackr: similar to snap point selection
<florian> +1
PROPOSED: Relax spec for less definitive cases, miriam to add use cases to issue, flackr to write possible algorithm(s) as examples
RESOLUTION: Relax spec for less definitive cases, miriam to add use cases to issue, flackr to write possible algorithm(s) as examples
[css-scroll-snap-1] Avoid page scrolling skipping past snappable items
flackr: context of scroll buttons , but pre-existing issue with snapping
flackr: currently if you pgae down, the browser can select a snap area that is more than one page away
flackr: even though there's a possible snap area that's not that far away
flackr: I propose putting wording in the spec that, at least for explicit actions like page down, find a snap area that is less than one page away
flackr: so that you don't skip over content
flackr: then I had a further open question of whether we need to solve this for scrolling APIs
flackr: original issue was calling .scrollTo
flackr: to mimic same behavior
fantasai: I think yes, page-up page-down should scroll <= viewport
fantasai: might be exactly equal, but could be <=
fantasai: for programmatic API, those are supposed to [...]
fantasai: ...have the same behavior as a person scrolling
fantasai: if scroll-snap is going to interfere with a person scrolling, then programmatic aPI should get that same interference
flackr: if I make a page-down button, as a web developer, and add an event listener that calls scrollTo(currentPos + 85% of scrollport)
flackr: the same problem as pressing pagedown on keyboard exists, that browser could select something further away
flackr: should we try to scroll less?
fantasai: round-down version?
flackr: most expressive version is to say "don't want to scroll more than 1 page"
fantasai: ...
flackr: that's scrollIntoView
flackr: this is for APIs where you specify how far you want to scroll, or a position
fantasai: do we want to add a scrollByPages API?
flackr: that would be reasonable
fantasai: or do we give a "bias-towards" parameter?
fantasai: which of those would make more sense
flackr: I feel like we'd be more likely to do what the dev expects, if the API was specifically "scroll by a page"
fantasai: I guess then we have 2 resolutions?
fantasai: (1) pageUp/pageDown type operations should never scroll by more than a page, unless that's the only valid snap area
PROPOSED RESOLUTION: pageUp/pageDown type operations should never scroll by more than a page, unless that's the only valid snap area
RESOLUTION: pageUp/pageDown type operations should never scroll by more than a page, unless that's the only valid snap area
fantasai: (2) we want to add some kind of scroll-by-page type API, to be sketched out by flackr
flackr: I can sketch that out
Rossen6: no need to resolve on that now
ACTION: flackr to sketch out a scroll-by-page API
Fragmentation
FWIW there is a scrollByPages API in Firefox, non-standard: https://
<astearns> github-bot, take up w3c/
[css-box-4] Applying `margin-trim` to fragmentation containers
<github-bot> OK, I'll post this discussion to https://
fantasai: we discussed this issue & related issue about text-box-trim on multicol containers a while back
fantasai: iank wanted some time to talk about how feasible it'd be to implement on the end side
fantasai: of containers
iank_: I synced up with morten. we're fine with the proposals. it does require backtracking
iank_: (the proposals for margin-trim and text-box-trim)
fantasai: the proposal is that margin-trim on a multi-column container trims the block-level margins adjacent to the affected edge of the column box
fantasai: if your margin is adjoining the top edge of the column, the margin-trim-top applies to you, and analogous for the bottom
RESOLUTION: margin-trim on a multi-column container trims the block-level margins adjacent to the affected edge of the column box. if your margin is adjoining the top edge of the column, the margin-trim-top applies to you, and analogous for the bottom
[css-inline-3] text-box-trim vs fragmentation
fantasai: this issue is the same, but now for text-box-trim
fantasai: if you apply text-box-trim to a multicol container, it applies to the first formatted line of each column, and analogous for the last
PROPOSED RESOLUTION: if you apply text-box-trim to a multicol container, it applies to the first formatted line of each column, and analogous for the last
RESOLUTION: if you apply text-box-trim to a multicol container, it applies to the first formatted line of each column, and analogous for the last
Pseudo-Elements
[css-shadow-parts] are rules for which pseudo-classes and pseudo-elements work after ::part() parse-time or match-time?
dbaron: I filed a series of pseudo-element issues. this first one was a case where spec was written after impls/tests were written
dbaron: impls are interoperable and disagree with spec
dbaron: spec says some pseudo elements / classes work after ::part
dbaron: but all of them are supposed to be syntactically allowed at parse time, and the ones that don't work just don't match
dbaron: but impls reject at parse time the ones that don't work
dbaron: TabAtkins prefers what the spec says
dbaron: TabAtkins thinks parse-time selector restrictions haven't been very successful and we shouldn't add more of them
<TabAtkins> +1
dbaron: counterargument: it's already implemented across 3 engines, so changing impls might have some level of risk
dbaron: Also, it's more consistent with other pseudo-elements
dbaron: other pseudos that don't do anything are invalid at parse time
dbaron: [gives an example with ::before::before selector, which is invalid]
dbaron: my inclination is to do easy thing and change spec to match the impls + tests
dbaron: this is widely tested in WPTs. We could just change the spec and say we've got it already implemented and tested
dbaron: I'd like us to do that, or to hear a convincing argument in the other direction
keithamus: another benefit is that impls can highlight this in devtools
<lea> We can address that head-on by providing a method to test whether selectors are valid
keithamus: that's another argument for the parse-time restriction
florian: people who put tests in WPTs are welcome to change the spec & file spec bugs
florian: we should generally be more careful about this
dbaron: in this particular case, the tests were mostly testing other things. They were testing the rules for what wasn't allowed, and they didn't realize that there was stuff about it being a parse-time restriction
florian: there's a significant difference between things that are currently invalid are strongly expected to stay invalid forever, vs. if it may someday change
florian: if we treat a selector as a parse-time error and we want to make it valid in the future, that'll be painful
florian: But if we know these are going to be invalid forever, I have an easier time agreeing with your position
emilio: I think parse-time is generally better; it works better with @supports
emilio: (and CSS.supports, etc)
<astearns> +1 to emilio and keithamus
emilio: I was going to also argue that impl-wise it's better not to have to deal with sort-of valid states, but we have to deal with that with nesting anyways
emilio: but yeah, @supports makes parse-time checking very valuable
emilio: if you want match-time restriction, you can use :is or :where
emilio: given we have a way of doing both things, I lean towards fixing the spec to match reality
florian: I'd be more comfortable with the proposal if we had selector error recovery at each comma, but especially given the availability of :is and :where, I think that's fine. [agreeing I think]
dbaron: given the later issues I want to discuss, there might be a few strange cases of restrictions where we want to relax in the future
dbaron: but in most cases the restrictions are solid because it just doesn't make sense
lea: it sounds like there are upsides & downsides
<Zakim> lea, you wanted to ask, it sounds like there's a clear upside to doing the validation at match time. What's the downside?
lea: sounds like arguments for parse-time checking are for testing if something's supported
lea: is there a way we could add a way to check for if something is valid that would account for this case, and if we can, are there remaining arguments?
kbabbitt: does document.querySelector throw on an invalid selector, and that could be used to check for validity?
lea: only throws at parse time
lea: all our tools right now check for validity at parse-time
kbabbitt: you're looking for a way to check whether a selector that's valid at parse time is valid when used?
lea: sort of, yes
dbaron: we just listed 3 different ways for checking whether selectors are valid, and they're all the parse-time version
dbaron: it'd be confusing to add another way that checks at a different time
lea: who was arguing for making it invalid at match time?
[various]: Tab
dbaron: TabAtkins is OK either way but would prefer match time
Rossen6: we're leaning towards fixing the spec & going with parse time
Rossen6: objections?
RESOLUTION: reject these invalid selectors at parse time
(fixing the spec to match reality)
[css-shadow-parts] need definition of which pseudo-classes can follow `::part()` that is sufficient to produce interoperability
dbaron: this is now going into the details of the rules for which pseudo-classes are invalid or valid after ::not
dbaron: this is important because we're introducing concept of part-like pseudo-elements
dbaron: this set of rules is now not only applying to part but also to other things
dbaron: the spec says the part pseudo element can take pseudo-classes like :hover...tree information... local element information [quoting spec]
dbaron: this is a reasonable design guideline for authors, but it's not specific enough to produce interoperability
dbaron: some tests revealed differences between implementations on this, RE whether something is tree information vs. local-element information
dbaron: what I want to do is change the spec so that it's explicitly listing which pseudo-classes are & are not allowed
dbaron: still giving design principle behind that, but making it more explicit
<dbaron> w3c/
dbaron: proposal is what's in Tab's comment from 3 weeks ago^
dbaron: which is basically, the things that we'll disallow the things the spec defines as structural pseudo-classes - first-child, nth-*, etc
dbaron: you can't use :has, it's asking about descendants
dbaron: you can't use :scope, :host, :host-context
dbaron: but all the other current pseudo-classes would be allowed. We'd be allowing :lang and :dir (previuos resolution)
dbaron: we'd be allowing :focus-within and :target-within, and :picture-in-picture
dbaron: those are the ones Tab thought were somewhat ambiguous but probably allow
dbaron: that's the proposal unless people want to change it
emilio: I agree on making it more explicit
emilio: I think there are some tests that are invalid, e.g. the last one uses :is ...
emilio: I think some of the tests that you landed may need tweaks. I think current behavior from WebKit and Gecko is correct, on :is:first-child etc
emilio: because it was resolved that we'd preserve the inner element serialization [?]
dbaron: there are some tests that Chromium fails due to serialization
emilio: we can sort the test failures out async. generally I support this
Rossen6: did you get a chance to check WHATWG discussions to be sure nothing needs to change
dbaron: I read through the more recent discussions. I don't think any of that would change this list
PROPOSED RESOLUTION: Tab's comment from 3 weeks ago w3c/
PROPOSED RESOLUTION: disallow
:has()
:scope
:host, :host(), and :host-context()
<fantasai> +1
RESOLUTION: disallow :has() :scope :host, :host(), and :host-context()
[css-pseudo] more clearly define which pseudo-elements are tree-abiding or part-like
Related: https://
dbaron: we introduced this concept of ::part-like pseudo-elements
dbaron: there's a few different ways to think about it; I like to think it's a pseudo-element where underneath there's actually an element. So you can do most things with it
dbaron: ::part lets you use a pseudo element that was part of the shadow tree
dbaron: we're adding another way to do for form-controls that's similar
dbaron: we've added tree-abiding pseudo elements. they support a smaller set of things. General assumption: we can make a tree out of them
dbaron: they're not things like ::selection that cross the tree in random ways
dbaron: they're like ::before which lives in the tree at this place, and it has clearly-defined before/after siblings
dbaron: we have a lot of pseudo-elements in different specs. We need to be sure the ones that should be defined as ::part-like are defined that way, and same for tree-abiding, and we should say which ones aren't those things too
dbaron: I tried to make a list of which pseudo-elements go in each bucket
dbaron: I'd like other folks to take a look, especially the ones that I put question marks next to
dbaron: this is in the last comment in the issue, w3c/
fantasai: there are multiple categories of pseudo-elements. we should be sure the names for the categories are reasonable
fantasai: "tree-abiding" seems reasonable. we have some that are restricted in terms of which properties they can take (e.g. ::before vs ::marker)
fantasai: "tree-abiding and takes any property", "tree-abiding but restricted", and "part-like" -- are those the 3 categories?
dbaron: we've already allowed pseudo elements to have hand-written restrictions
dbaron: everything not in the ::part-like bucket has some restrictions hand-written at its definition
dbaron: there are also a bunch of general rules about how selectors combine, more than about what properties are used
dbaron: ::part-like pseudo elements do allow any properties, but the more interesting part is about how you can combine selectors
dbaron: anything that's not part-like has custom prose saying which properties are allowed
<flackr> w.r.t. having a known location in the tree, see https://
emilio: I think your list is pretty reasonable. I don't think all the tree-abiding pseudos support the content property
dbaron: that was me reading the spec, not checking reality
dbaron: I looked through all the specs for things that reference those definitions
dbaron: in reality support for the content property does not match the spec
emilio: ::backdrop might not be implemented as an element in all engines... as a box, in all engines?
fantasai: that's how it should be defined. There's no reason for it to have an element backing...
emilio: not sure if all impls make it an element. if they don't make it an element, I'm not sure it should be tree-abiding?
fantasai: it does fit in the tree. stuff that's not tree-abiding is stuff that crosses element boundaries. ::first-letter, ::first-line, all that stuff
emilio: ::cue might be ::part-like
emilio: and also [...]
emilio: for now we can go with -- if an engine doesn't implement it as a part, we can consider it not-part-like, and we can sort out more later
emilio: my other intuition for part-like vs. not is whether there's an actual dom element behind it, that isn't created by layout
emilio: (::before and ::after and ::marker are special)
emilio: but generally, my list would match yours, except for maybe ::backdrop and ::cue
<emilio> perhaps ::placeholder could be part-like
<emilio> Once we define how `<input>` is laid out
<emilio> One of these days ;)
andreubotella: you could think of part-like as selecting something in the flattened element tree, tree-abiding as selecting something in the box tree
andreubotella: do these pseudo-elements have some particular distinction? does it make sense to group them in this way, depending on what they select into?
andreubotella: ::first-line and ::nth-fragment() select into the fragment tree, and nth-fragment also
andreubotella: does it make sense to treat these as a separate category? or are the restrictions on those similar enough to the groups you've defined already?
dbaron: It may well make sense to describe that as a category
dbaron: I'm not aware of any common definition, so I'm hesitant to define spec terms if we don't have a reason to do so
dbaron: but the classification makes some sense
<kbabbitt> I think dbaron's list makes sense for the selectors that I understand
dbaron: might be premature to take a resolution on this one. but I'd encourage discussion on the issue
jarhar: for the classification question/concepts: hopefully this is related... On Mon or Tues at a joint meeting, I brought up whether new pseudo elements for customizable select should be before-like or part-like
jarhar: there weren't spec concepts for this but it's important for implementation
jarhar: if I want to make it part-like, I need to wire it to shadow tree, real element in the tree, etc
jarhar: would be useful to have some kind of distinction for implementors, to help steer impl strategies
jarhar: (on new pseudos)
emilio: that's the main distinction. tree-abiding may encompass other things that are like generated content
emilio: we want to make part-like be things that have an element behind, unrelated to the styling of the parent
emilio: that's how a lot of the form-control shadow trees are implemented
emilio: I'm pretty sure gecko/webkit have same kinds of assumptions about generated content. It'd be kinda hard to support a lot of these pseudo-classes on before/after
emilio: depending on how we decide to make a pseudo-element work, you need to take one approach or the other to implmeent it
fantasai: could you implement a tree-abiding as a part-like pseudo-element?
emilio: you could, it'd be more restricted
emilio: if you have an actual DOM element, you can implement a part-like and tree-abiding pseudo-element
fantasai: you can't implement a part-like pseudo without an actual element backing it, without a lot of work
fantasai: but you could implement tree-abiding as a part-like pseudo-element with some disabled features
emilio: that's how placeholder is implemented in webkit and blink
emilio: we could change how gecko works to work that way too
emilio: but that's not great if we don't define what tree it is and what it works
Rossen6: let's move on
[css-pseudo] Should ::before / ::after really be part-like?
dbaron: this is a subtopic of previous one. emilio filed a specific issue about ::Before and ::after
dbaron: I agree with him, that ::before and after are not part-like
<kbabbitt> +1
fantasai: right, it surprised me to find that in the spec
emilio: sounds good
<andreubotella> +1
PROPOSED RESOLUTION: ::before and ::after are not ::part-like
<flackr> +1
kbabbitt: but they are tree-abiding?
emilio: right
PROPOSED RESOLUTION: ::before and ::after are not ::part-like but are tree-abiding
RESOLUTION: ::before and ::after are not ::part-like but are tree-abiding
[css-pseudo][css-shadow-parts] Define "part-like pseudo-element" concept
dbaron: this one, we already had a resolution, but I wanted to give a brief update since the state of things is confusing
dbaron: so we resolved to make this :part-like pseudo-element concept
dbaron: half of the edits are edited in, but not all of them
fantasai: e.g. this edit, which has been waiting for this current discussion
https://
dbaron: we've made some of the edits, to make partlikes like ::part
dbaron: earlier we were discussing what selectors and pseudo-classes apply after ::part
dbaron: those all apply to ::part-like as well, and I'm planning to make those edits
dbaron: Tab made edits about what properties apply. But the selector edits have not yet been made
dbaron: that's all
[css-shadow-parts][css-nesting] is & allowed after ::part()
dbaron: this is getting into fun stuff that I don't have strong opinions about, mixing multiple new features
dbaron: is the & selector allowed after ::part?
dbaron: we have restrictions saying these selectors are allowed, these aren't (after ::part)
dbaron: should we allow the nesting & selector after part, when it is a selector and is after part, or not
w3c/
fantasai: I'd go with "no" per this comment^
fantasai: we do allow ::is but with restrictions, IIRC
fantasai: the & is pulling in a whole type-selector ... Unless we're wanting to allow type-selector, I don't think it makes sense to allow &
fantasai: proposed resolution: no change to spec, & is not allowed after ::part
RESOLUTION: No change to spec. & is not allowed after ::part
[css-shadow-parts][css-scoping] Is ::slotted() allowed after ::part()?
dbaron: this is the last one of these
dbaron: is ::slotted allowed after ::part?
dbaron: this only makes sense if a shadow DOM exposes a slot as a part
lea: I've done that
dbaron: ok. So it sounds like this is maybe a useful thing to do sometimes
lea: that's useful when you want to expose a part but you don't want to pay a separate container for it. It can become a box. why not expose it
dbaron: So, the current state of allowing ::slotted after ::part is that Chromium and Gecko do not allow it
dbaron: WebKit allows it at parse time but it doesn't match the things I thought it should match
dbaron: there are 2 points here.
dbaron: (1) it's not clear to me if there's much of a use-case for ::slotted after ::part
dbaron: (2) it's pretty complex to implement
dbaron: it's combining things that jump in/out of shadow trees in ways that are extra fun and raise questions about how to cascade rules from different sources
dbaron: general rules suggest that this should be allowed, but it's a good bit of work to do correctly, and it's not clear to me if there are actually good use-cases for it
dbaron: and if it would require rewriting a bunch of scary code in the middle of cascade impl to do something obscure that nobody needs
emilio: I was going to say what dbaron just said
emilio: I'm pretty sure the reason this doesn't work in webkit is:
emilio: when youre styling a slotted node, you look at the trees from the shadow-trees where you're slotted (?)
emilio: the slotted combination makes it go out of the trees you would usually look at, which is why it doesn't work
emilio: this doesn't seem useful. I'd rather not allow it, & agree with dbaron
lea: the use-case for me was for a wrapper that's there whether you have the fallback content display or not
lea: doing that with a nested element... you have to wrap the slot with a separate element... I suppose that'd work
lea: there was a reason, but I need to remember it
dbaron: it's not just about why did you want to expose a slot as a part, but: if you did that, would you want to use ::part::slotted _from outside_
emilio: there are use cases for exposing slots as parts, thats's what the details element ended up doing
emilio: but the question is why would you do details::details-content::slotted(div) (?) instead of details>div
keithamus: for something to be slotted, you can query for it... the only thing you gain from ::slotted on the outside is to know that it's a descendant of a named ::part. but I can't see why that would matter in practice
keithamus: it kind of exposes an impl detail of the shadow dom that might be undesirable
keithamus: would you have to make it unmatchable in a closed shadow root?
emilio: we resolved to add :has-slotted , so that detail would already be exposed via that pseudo-class
keithamus: good point, maybe we should ???
<emilio> s/:has(:slotted)/:has-slotted/
dbaron: even though it's a closed shadow-root, it's exposed as a part. there's supposed to be something exposed there
emilio: in general we haven't gone very far on trying to prevent exposing pseudo-classes/elements that are dependent on what element the part is
emilio: some are useful. you can do ::part ::placeholder to style a placeholder - that's an actual thing that was requested
emilio: I'm not sure we should go to great lengths to avoid matching :has-slotted after ::part()
er: has-slotted
lea: if we decide not to do it, can we revisit this in the future?
lea: or will we be hit by webcompat in that scenario?
<emilio> +1 to dbaron
dbaron: always some risk of webcompat problems. Maybe there already are webcompat problems. But I think this is in the category of low-risk, and we could allow it in the future even if we don't do it now. But not a thing we can promise
<fantasai> +1 to dbaron
dbaron: and I can't even really promise that we can do it now
Proposed resolution: don't allow ::slotted after ::part
RESOLUTION: don't allow ::slotted after ::part
<lea> When do we reconvene?
<astearns> lea: 7 minutes ago officially, but I am guessing 5-10 minutes from now
<keithamus> We are reconvening
Cascade
github-bot: take up w3c/
[css-cascade] may need to define cascading order between sibling encapsulation contexts
<github-bot> OK, I'll post this discussion to https://
dbaron: one of the steps in the cascade, between origin and specificity
… (don't remember how it interacts with layers)
… is that rules based on tree scopes cascade separately
… so rules from outside the shadow root generally wins, except !important which goes the other way around
… there's spec text that assumes that only tree scopes relevant to styling are outside / inside
… but in some edge cases you can have sibling scopes
… one of these is if we allow ::part() after ::slotted()
… the other is the /slotted/ combinator
… so in these cases you have stuff in one shadow tree that affects styles in a sibling shadow tree
… the cascade spec is not clear about this
… I don't really have a solution, thinking about this makes my head hurt
… for an impl perspective is probably easier not to cascade them together
… because having them together may be painful
… the problem here is we don't define what happens
… I don't have very strong opinions
Rossen: tab seems to propose tree order
<Zakim> lea, you wanted to say, it's definitely not high priority. Q: if we decide to not allow it now, is that something we can revisit later or will we run into web compat?
<dandclark> emilio: The shadow incluuding tree order thing makes sense except I don't know how to define !important in that case beacuse there's no inside or outside. Not clear if it should be reversed or not, that seems weird. So don't have clear answer.
dandclark: Was going to agree with tab
… it generalizes that definition
… but agree with emilio that it seems weird to do the reverse from !important
… unclear if there's something better
lea: not quite sure I understand so might be off
… not sure how making slotted a combinator relates to this
… the whole point was to circumvent some of the issues
… wouldn't it be the same as
… you're using regular selectors to target the slotted elements
… so regular cascade rules should apply
… if it's about styling inside and outside we have :host and regular selectors too
… maybe I'm misunderstanding
dbaron: I think it'd be the /slotted/ combinator in combination with ::part or something else
dbaron: I think I was thinking was something like /slotted/ element::part(foo) from inside a component
<dandclark> emilio: No because the outside is not a sibliing
dbaron: then slotted looks at the parent tree scope, and ::part() could be a child of the parent tree scope (thus a sibling)
lea: wouldn't that be the same as targetting the part from outside?
emilio: no because outside scope wouldn't be a sibling
dbaron: the other possibility is that some of the rules are not desirable with ::slotted()
lea: that's a big motivation for the slotted combinator
<lea> that any CSS you include in ::slotted() has lower precedence than litterally any other CSS, including the universal selector, CSS resets, generic type selectors etc
<lea> unless you use !important, which is too strong
<dandclark> emilio: I am confused because the slotting behavior doesn't fix that layout
lea: my understanding was that ::slotted() behaves like this because it's a pseudo of the slot
emilio: that's not correct
lea: so this is the reason ::slotted() doesn't work?
dbaron: yes, the reason ::slotted() is so weak is this rule about encapsulation context
… which I think makes sense for ::part()
… but maybe it's not the right decision for ::slotted()
lea: but now we cannot change ::slotted() because of webcompat
… so /slotted/ would work
… btw I chatted with rniwa, and his implementation concerns are about targetting descendants and other elements
… but if we restrict what comes after to a compound selector he's fine with it
<dandclark> emilio: So that is correct, that was an implementation issue, but making slotted combinator doesn't help as long as we don't change the cascade spec in subtle ways.
lea: it's clear we need to fix both
… but we probably can't change how ::slotted() behaves because webcompat
<dandclark> emilio: I am not sure that's necessarily true. Does need some investigation . RIght now in the cascade spec all @@@ have hte same behavior. So it would feel weird to change the behavior only because multiple selectors can match
<dandclark> ...we could try to fix the cascade spec
<dandclark> ...but that's sort of tangential to this issue
<dandclark> ...but should do that if that's what we really want
<lea> w3c/
lea: there are a lot of other things that need to be fixed, see ^
<dandclark> emilio: Seems there's no clear consensus
keithamus: Can you style `:has()` with a combinator? So you'd do `:has(/slotted/ something)`
lea: yeah `:has()` supports relative selectors
… first example in mdn
Rossen9: let's take this back to the issue
github-bot: take up w3c/
[selectors] Pseudo-class to indicate when a slot has content
<github-bot> OK, I'll post this discussion to https://
Rossen9: who's best to summarize this one?
dbaron: was discussed yesterday according to github-bot
<dbaron> w3c/
keithamus: didn't resolve because I had a question about the functional pseudo-class
… to do the same things I was talking about
… wrt /slotted/
… I think we need to pick a direction, either we look into the slotted combinator or we look into :has-slotted()
<dandclark> emilio: Did we resolve on the nonfunctional version?
keithamus: we resolved to that prior
… but test were written for the functional pseudo-class
… it seems the functional pseudo is more interesting to the WC community
… but happy to investigate the combinator
emilio: Given :has-slotted() is dependent on whether we do the combinator, and the combinator kinda depends on what we do about the cascade order, I'd prefer to discuss the cascade order at least first, when TabAtkins is around ideally
<dandclark> emilio: We can keep the tests as tentative or I can split it
<dandclark> emilio: I think we need an issue about the cascade issue
<dandclark> ...wasn't clear that was the main complaint about the slotted selector
ACTION: keithamus to open issue about ::slotted() cascade order
github-bot: take up w3c/
[css-pseudo-4] ::self-link pseudo, for self-linking
<github-bot> OK, I'll post this discussion to https://
flackr: as TabAtkins wrote, it's a very common pattern (bikeshed etc mentioned)
… this adds a link to the heading that you can link to
… developers write tools to add these
… the proposal is to add a pseudo to generate this before the element
… long list of proposed behavior
… main one is it requires the content is linkable which means it has to have an ID attr
fantasai: main issue, sometimes they want it at the start or at the end
… the other is sometimes you want a link to the container, not the heading itself
… e.g. <section id=foo><h1>...
… you could add the id to both but the desired thing is to target the section
… so I like the idea
… I don't think it's a problem to do it with CSS
… but needs a way of solving these two
flackr: the second seems more tractable
… we could allow it to refer to the nearest ancestor with id
fantasai: that won't get you reasonable behavior for the fifth heading in the section or something
… you'd be jumping too high
… maybe fine
… but if you have somewhat unpredictable markup...
… [missed]
… it's a bit tricky
flackr: not sure I understand the use case
… isn't the <section> what you link the one you want?
fantasai: the nearest element with an id might be <main> or what not
flackr: ah because they forgot or something
1+
flackr: I supposed if there was a functional pseudo you could use `attr(id)` to refer to yourself or something
fantasai: that might be more practical
… I think those are my two concerns
emilio: Is it well-defined to have generated interactive content?
<dandclark> emilio: My question is is it well defined to have generated interactive content?
<dandclark> ...What's the click event target?
<dandclark> ...Might be fine but might need some work on DOM side as well
flackr: there is common behavior when you click on pseudos that you dispatch on the outer element, not great but...
… it is at least targettable
… we could explain this in the future
<dandclark> emilio: But I think the targets @@@ is mostly an effect of the generated content. Not quite pointer events but sort of. Must be targetable. Thinking about user-select.
flackr: not sure I have the answer about how to support before / after
<dandclark> emilio: What if instead of making new pseudo you make it content function or something? That way you can use ::before and ::after, can target anything
flackr: that way you could use content: self-link(self) or self-link(closest) or something
… and would solve the before / after issue
flackr: yeah
Rossen9: let's take it back to the issue
github-bot: take up w3c/
[css-overflow][css-contain][css-sizing] `overflow: auto` incompatible with size containment and container queries
<github-bot> OK, I'll post this discussion to https://
oriol: florian added this to the agenda
github-bot: take up w3c/
[css-color] [css-ui-4] Authors should have access to accent-color value to use in their code
<github-bot> OK, I'll post this discussion to https://
florian: no longer objecting
emilio: to restate, this was about making AccentColor and AccentColorText react to accent-color property
emilio: some concern about them resolving at computed value time making it harder to not expose the system color from OS
emilio: but as Florian said, no longer objecting on that basis
emilio: I think general consensus was, make these react to accent-color property
emilio: figure out a reasonable definition for what happens with color/currentColor/accent-color/AccentColor cycles
emilio: That's TBD, can sort out in a separate issue
emilio: I think we were working towards resolving like other system colors at computed value time
emilio: it's easier implementation-wise, and more sense if accent-color changes throughout the tree
fantasai: not sure about the resolving about the resolving at computed-value time
… currentcolor doesn't do that
… sympathetic to the impl complexity argument
emilio: I have a counter-example
emilio: all system colors go in pairs, right? Not talking about one keyword, but two
emilio: all system colors that go in pairs resolve early
emilio: changing the color could cause text to be unreadable
emilio: consider you have :root... { background: AccentColor; color: accentColorText; }
emilio: if you change the accent-color further down in the tree, then you can end up with text you can't read
fantasai: but that's the behavior of color: currentColor and such right?
emilio: but color is only one, there's no background / foreground concept
fantasai: right, but...
miriam: several questions
fantasai: if you set a color that works on a background, and then change it down the tree you can get unreadable text also
fantasai: so don't do that; same thing here.
miriam: maybe I wasn't following
… do these get set once at the root and then they stay through the document
… or do they change (both?) when I change accent color
fantasai: what emilio is proposing is binding to the element you set them on and then they stay fixed as they inherit
… alternative is to have them as keywords and let them change if accent-color changes in a descendant
miriam: but then you change accent color and it changes both?
fantasai: think we can resolve to do the easier thing (eager resolution) and come back if we hit a use cases that needs it late
emilio: I'm fine resolving; but if some concerns with resolving at computed value time then happy to ?
<lea> what about color-scheme and canvas/canvastextelaborate
emilio: canvas/CanvasText does eager resolution against color-scheme
kbabbitt: little confused because two keywords (accentcolor/accentcolortext)
… the accent-color property influences accentcolor
<miriam> yes, I also have @lea'a question above
kbabbitt: what about accentcolortext
… wouldn't that mess up the contrast
miriam, lea: those resolve at computed value time; emilio is proposing to match them essentially
emilio: same way accent-color affect background of checkbox, but also adjusts tickmark so you can still see it
emilio: you would do same with AccentColorText
emilio: ensures contrast between the two
<miriam> fantasai - the question is about updating them in the document as the color-scheme changes
emilio: you can't specify the exact color of the checkmark, similar with AccentColorText
kbabbitt: what's the intended relationship between these two?
emilio: one is background other is foreground
miriam, the answer to that question is it binds at computed value time
emilio: AccentColor will be what you specify in accent-color
emilio: and AccentColorText will be the foreground color associated with that accent-color
emilio: I don't think there's a precise algorithm, but UAs do have one (that may or may not be fully interoperable but nonetheless ensures contrast)
lea: I thought we resolved on when do they resolve?
fantasai: didn't resolve on anything
lea: what are we discussing?
… my understanding was that the primary objection was florian
… did miriam ask about canvas/canvastext
fantasai: yeah
lea: is the proposal to do the same for these?
fantasai: yeah
lea: why not doing that?
fantasai: we haven't concluded yet
lea: why not?
PROPOSED: AccentColor takes its value from accent-color, and AccentColorText takes its value from the appropriately contrasting foreground color for AccentColor; these resolve at computed value time
RESOLUTION: AccentColor takes its value from accent-color, and AccentColorText takes its value from the appropriately contrasting foreground color for AccentColor; these resolve at computed value time
w3c/csswg-drafts#10746
github-bot: take up w3c/
[selectors] Shouldn't there be a pseudo selector for `:unchecked` inputs?
<github-bot> OK, I'll post this discussion to https://
fantasai: proposal to have :unchecked, parallel to :checked and :indeterminate
… parallel to other pseudos like :enabled/:disabled
… apparently this one is the only one that doesn't have it
… proposal is to add it
Rossen9: so when does this match?
fantasai: when it can be checked but isn't
fantasai: e.g. div:not(:checked) matches but div:unchecked doesn't
emilio: is it exclusive with :indeterminate?
fantasai: yes
fantasai: because indeterminate means it's not checked or unchecked
dbaron: checked can match radio/input/option
… indeterminate can match radio/checkbox/progress
… I assume this would match only the things checked might match?
fantasai: yes
<dbaron> https://
kizu: in scroll-marker :checked was mentioned as something we'd match
… should we have :unchecked too?
fantasai: I think we shouldn't have :checked for that
flackr: if we use :checked it probably should
<kbabbitt> :unchecked sounds good to me
PROPOSED: Define :unchecked for elements for which :checked applies, exclusive with :indeterminate
RESOLUTION: Define :unchecked for elements for which :checked applies, exclusive with :indeterminate
[css-overflow-5] Bikeshed pseudoclasses for active scroll-marker
flackr: so in scroll-markers spec I used :checked, because it's a state that doesn't involve focus... but :checked is associated with form elements
<kizu> +1 to `:current`
flackr: there was a suggestion to use `:current`
… related to `:past` and `:future`, tab objected to that
https://
flackr: we can't use :active because things become :active while you interact with this
<kizu> `:scroll-target`?
fantasai: fun historical link, on IE clicking a link to a target on the same page would remain `:active`
flackr: so there's precedent for `:active` as long as the browser was still targetting that ID!
<kizu> `:active-anchor`
miriam: seems tab's objection to `:current` seems more about `:past` and `:future`
… `current` matches what I'd use in JS which is aria-current
flackr: wouldn't mind `:current`
<keithamus> +1 to :current
fantasai: my only concern with current is possible conflict with a different meaning of `:current`
<ydaniv> +1 to miriam
emilio: does any browser implement `:current` with any other meaning?
(nobody knows)
emilio: Gecko doesn't at least
flackr: another thing to think about is whether `:current` makes sense for all use cases
… can't think of any, even if you use it for tabs, or scrolling content, or slides, `:current` feels right
fantasai: current was designed to work as a styling for navigation or so for screen readers
… currently used for captions
… like the fact that it means the right thing
… but if we did this and we ever wanted to do something like that then it'd conflict
flackr: should we try to resolve on `:current` for now?
fantasai: yeah I think `:current` is better than `:checked`, we can keep the issue open
astearns: reading MDN of the current use of `:current` it'd match the ancestor of the thing that's currently played
… so if you style a marker for a carousel tab that is currently playing a video with `:current` it'd pop out everywhere
dbaron: is it video or vtt?
astearns: vtt
emilio: isn't the vtt tree scoped?
fantasai: if it isn't it should
Rossen9: what's the issue with `:active`?
fantasai: while you're clicking on the button that's `:active`
… don't mind reusing it but if you need that meaning...
flackr: that wouldn't work for the link version of scroll markers
fantasai: yeah you probably want something different then
[jokes]
emilio: seems people thought `:current` is better than `:checked`
https://
PROPOSED: `:current` > `:checked`, issue remains open while we look for better alternatives
RESOLUTION: `:current` is better than `:checked`, issue remains open while we look for better alternatives