13:02:41 <RRSAgent> RRSAgent has joined #css
13:02:45 <RRSAgent> logging to https://www.w3.org/2025/04/03-css-irc
13:02:45 <Zakim> RRSAgent, make logs Public
13:02:46 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
13:03:47 <hoch> present+
13:05:14 <fantasai> scribe+
13:05:26 <kurt> present+
13:05:56 <emeyer> present+
13:06:41 <fantasai> Topic: Gaps
13:06:46 <github-bot> Subtopic: [css-gaps-1] Grammar for expanded column-rule shorthand
13:07:06 <fantasai> kbabbitt: First issue is about gap rule shorthand
13:07:06 <bkardell> bkardell has joined #css
13:07:22 <fantasai> kbabbitt: In the future, I wanted to allow different parts of container ot have different gap decorations
13:07:23 <bkardell> present+
13:07:30 <ydaniv> present+
13:07:52 <fantasai> kbabbitt: In the current version of the spec, we allow for varying gap decorations within a given region o the container
13:08:12 <fantasai> kbabbitt: For the purposes of the shorthand, specify widths styles colors ...
13:08:27 <fantasai> kbabbitt: For longhand properties to do varying decorations, can specify them all: columnrule-color: red blue ; alternate red/blue
13:08:39 <fantasai> kbabbitt: For shorthand it's more complicated because of additional values
13:08:58 <fantasai> kbabbitt: I previously used slashes to separate width/style/color groups
13:09:08 <fantasai> kbabbitt: wanted to reserve commas for future feature for regions
13:09:19 <fantasai> kbabbitt: Got feedback that slashes were not great for this particular separation
13:09:37 <fantasai> kbabbitt: subsequent discussion, several pointed out that when that feature comes along, we'll need to specify which region each set applies to
13:09:43 <fantasai> kbabbitt: identify the region of the container
13:09:58 <fantasai> kbabbitt: so we could use those indicators as the separators for this set of decorators applies to this region of the grid etc.
13:10:01 <fantasai> kbabbitt: that seems reasonable to me
13:10:13 <fantasai> kbabbitt: indicates that it's safe to use comma for separators for varying decorators within a section
13:10:16 <fantasai> kbabbitt: so that's what I would like to do
13:10:33 <emeyer> scribe+
13:10:40 <astearns> ack fantasai
13:11:05 <emeyer> fantasai: border-radius has a similar problem trying to assign things to different positions
13:11:22 <emeyer> …It also wanted to make sure it had the ability to use repitition
13:11:31 <emeyer> …This seems like a similar problem to what you have here
13:11:47 <emeyer> …You want to be able to specify all the gaps individually, or be able to repeat them
13:11:59 <emeyer> kbabbitt: We do have a repeat pattern defined in the syntax
13:12:28 <emeyer> fantasai: I think I need to read the proposed syntax a little more closely
13:12:54 <astearns> `gap-rule: 1px solid red, 2px solid red [2/2/4/4] 2px dashed silver, 2px dashed gray`
13:13:07 <fantasai> fantasai: Maybe we can have an example?
13:13:07 <emeyer> astearns: Is this representative?
13:13:15 <emeyer> kbabbitt: Yes
13:13:43 <fantasai> kbabbitt: in that example you'd have 1px / 2px alternating across the grid, and then alternating silver and gray in the other section
13:13:46 <emeyer> …In that example, you’d alternate 1px/2px for most of a grid, but within that potrtion of the grid you’d alternate silver and gray
13:14:09 <emeyer> …That would be in a future version; the question here is whether we can use commans to separate portions of the grid
13:14:19 <rachelandrew> present+
13:14:47 <emeyer> astearns: If I understand, I think in order to more closely follow border-radius, we should use commas to separate values within…
13:14:58 <emeyer> fantasai: border-radius doesn’t use commas, so may not be a good analogy
13:15:01 <fantasai> border-radius:  <length-percentage [0,∞]>{1,4} [ / <length-percentage [0,∞]>{1,4} ]?
13:15:03 <kbabbitt> border-radius: 2em 1em 4em / 0.5em 3em;
13:15:27 <emeyer> fantasai: The slash in border-radius separates the X side and Y side
13:15:37 <emeyer> …I don’t know how applicable this is to gaps
13:15:47 <emeyer> …You usually want to set border and color as a set
13:15:55 <emeyer> …Useage patterns may not be the same
13:16:09 <emeyer> kbabbitt: I got feedback that caused me to raise the issue
13:16:23 <dbaron> Present+
13:16:25 <emeyer> fantasai: We could separate regions with commas, but I think it might be confusing
13:16:35 <astearns> q?
13:16:41 <emeyer> …Then again we do use commas to separate lists of things, so following that pattern is a good thing
13:17:01 <emeyer> astearns: I think I’m good with the current proposed PR, not as sure about the extension
13:17:15 <emeyer> kbabbitt: The PR was written assuming extensions will be needed
13:17:34 <emeyer> …Another thing I raised was that we don’t need a separator within a given region
13:17:55 <emeyer> fantasai: But then you have to fix the order of them, and everywhere else we do line styling you can mix the order of width, style, color
13:18:04 <emeyer> …I don’t think we can just use spaces
13:18:22 <emeyer> …Commas is probably the best we can do here and we’ll have to get creative with region styling
13:18:38 <emeyer> astearns: Even if we use something other than commas, commas might still not be right for the extension
13:18:50 <emeyer> …I’µ good with commas and not concerned about being backed into a corner
13:19:05 <emeyer> astearns: Proposed resolution is to accept PR
13:19:29 <emeyer> TabAtkins: I have a tiny technical nit about the grammar but not germane to this issue
13:19:52 <astearns> RESOLVED: accept the PR to solve this issue
13:19:59 <jfkthame> jfkthame has joined #css
13:20:02 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11814
13:20:02 <github-bot> Topic: [css-gaps] Gap decorations with collapsed gutters
13:20:02 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11814.
13:20:14 <fantasai> s/Topic/Subtopic/
13:20:56 <emeyer> kbabbitt: Oriol pointed out the way collapse tracks work in grid, when a track get collapsed, the gutters to either side overlap
13:21:15 <emeyer> …That’s fine if they’re empty, but will cause decorations to overlap
13:21:25 <emeyer> …I want to leave the definition of where gaps are to other specifications
13:21:40 <emeyer> …There are reasons to have overlapping gutters
13:21:43 <TabAtkins> q+
13:21:58 <emeyer> …But there could be an animation of a gutter collapsing down could cause weird discontiunities
13:22:17 <emeyer> …I’m leaning to leaving the behavior as is, since it seems to cause the fewest surprises
13:22:20 <astearns> ack TabAtkins
13:22:21 <emeyer> …But wanted to open the floor
13:22:35 <emeyer> TabAtkins: I don’t recall the reasons to have only a single gutter; can you restate?
13:22:58 <emeyer> kbabbitt: The PR that landed the change was that gutters can be detected by abspos elements within the grid
13:23:23 <emeyer> TabAtkins: Ah. I think we should suppress the display of one of the gutters when they overlap
13:23:38 <emeyer> …We could do it by making all but one of the gutters transparent
13:23:51 <emeyer> …I don’t think people would like overlapping multiple decorations
13:24:38 <emeyer> …We could say that if gutters overlap, all but one are transparent in some way, and could say that if they’re animated together, the transparent ones could be faded out
13:25:09 <emeyer> kbabbitt: Your proposal is to define this in gaps to say if two gutters are exactly coincdental, draw only one decoration
13:25:15 <emeyer> TabAtkins: Yes
13:25:27 <astearns> ack fantasai
13:25:34 <emeyer> …When a track collapses, and gutters are coincident, only one paint
13:25:46 <emeyer> fantasai: Collapsing a gap is binary right now; you’re either collapsed or you’re not
13:25:55 <emeyer> …I don’t know how we would even define otherwise
13:26:05 <emeyer> …I agree with Tab that we should paint only one
13:26:22 <emeyer> …We should do something similar to border-collapse rules, where you use whichever is most prominent
13:26:36 <emeyer> astearns: I did not know we had those rules!
13:26:40 <florian> q+
13:26:49 <emeyer> fantasai: I’m pretty cranky about the border-collapse code
13:27:16 <emeyer> …The rules about which border wins prioritize which style looks weirder
13:27:27 <emeyer> …Here, we don’t have a hierarchy for resolving conflicts
13:27:51 <emeyer> …If we ever have a region concept, we probably want the outermost border to win
13:28:04 <emeyer> …The boundary is most prominent, usually
13:28:16 <emeyer> astearns: Could there be decorations on the outside of subgrids that we should consider?
13:28:30 <oriol> BTW, rules for border collapsing conflicts are in https://drafts.csswg.org/css-tables/#border-specificity
13:28:37 <emeyer> fantasai: Yeah, if you have gap decorations that are more outside, they should get priority
13:28:50 <emeyer> kbabbitt: The conflicts rules in the context of tables are in the tables spec?
13:28:57 <emeyer> fantasai: They’re in CSS 2.1
13:28:57 <astearns> ack florian
13:29:03 <fantasai> https://www.w3.org/TR/CSS2/tables.html#border-conflict-resolution
13:29:05 <emeyer> kbabbitt: We’d just point to those
13:29:25 <emeyer> florian: I agree that tables got it wrong, because an edge is a specific thing
13:29:48 <emeyer> …I think saying the edges of a subgrid should win; parts that are special shoudl win ver parts that are generic
13:29:55 <emeyer> s/ver/over/
13:30:06 <emeyer> astearns: Any other comments or questions?
13:30:10 <emeyer> (silence)
13:30:33 <emeyer> Proposed resolution is that we’ll suppress all but one decoration if gaps are coincident due to collapsing
13:30:38 <emeyer> kbabbitt: I’d say for any reason
13:31:07 <emeyer> fantasai: If we end up with negatively sized tracks and decorations overlap, both should be painted
13:31:09 <emeyer> kbabbitt: Fair
13:31:25 <emeyer> astearns: And amend the resolution to say we’ll use the same rules as border collapsing
13:31:27 <emeyer> Objections?
13:31:35 <emeyer> (silence)
13:31:44 <oriol> In fact in flexbox you can have overlapping gaps with items with negative margins, right? So better restrict to collapsed gaps.
13:32:09 <emeyer> RESOLVED: Suppress all but one decoration if gaps are coincident due to track collapsing, and use the same rules as border collapsing
13:32:19 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11857
13:32:19 <github-bot> Topic: [css-color-adjust-1] Forced Colors Mode support for gap decorations
13:32:19 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11857.
13:32:39 <dholbert> dholbert has joined #css
13:32:40 <jfkthame> present+
13:32:47 <dholbert> present+
13:33:38 <emeyer> alisonmaher: The gap decorations spec define rule color, which is a shorthand, so the proposal is to add row-rule-color and rule-color to the forced colors spec
13:33:41 <fantasai> +1
13:33:42 <astearns> +1
13:33:42 <kbabbitt> +1
13:33:55 <emeyer> astearns: Any concerns?
13:33:59 <astearns> ack dbaron
13:34:26 <emeyer> dbaron: Minor nit, but the forced color spec looks a little inconsistent about listing short- or longhand properties
13:34:34 <emeyer> …Should probably be consistent about that
13:34:42 <emeyer> …The concept of what you’re proposing is fine
13:35:15 <emeyer> fantasai: The forced colors spec says to use the shorthand if there’s only a shorthand
13:35:22 <emeyer> s/only//
13:35:39 <emeyer> TabAtkins: We could be editorial and say “the longhands of blah blah blah”
13:36:09 <emeyer> fantasai: The real problem of the spec is that it lists properties, and it should be clear that the list isn’t exclusive, because other specs add properties all the time
13:36:23 <emeyer> alisonmaher: So just update to rule-color, then
13:36:49 <emeyer> dbaron: I think the editor of the spec can read it closely, but from a quick read it looks inconsistent
13:36:56 <dbaron> https://drafts.csswg.org/css-color-adjust-1/#forced-colors-properties
13:37:02 <emeyer> fantasai: I don’t see it as inconsistent
13:37:21 <emeyer> dbaron: Maybe it’ll all end up being shorthands
13:37:38 <emeyer> astearns: First thing is, add appropriate shorthand to the list to fix this issue
13:37:52 <emeyer> …Thus, resolution is to add `rule-color` to the list in the forced colors spec
13:38:07 <emeyer> kbabbitt: And delete `column-rule-color` since it’s covered
13:38:13 <emeyer> astearns: Hearing no objections…
13:38:39 <emeyer> RESOLVED: add `rule-color` to and remove `column-rule-color` from the list in the forced colors spec
13:39:12 <emeyer> astearns: I agree with Elika that listing shorthand is sufficient, but I agree with David that it’s not necessarily clear to people not used to specs
13:39:28 <fantasai> I would argue that it's clearer to people not used to specs than to people used to specs :)
13:39:35 <emeyer> …So I’d like to explicitly call out in the relevant sectoin that shorthands apply to all encapsulated longhands
13:39:44 <emeyer> s/sectoin/section/
13:40:07 <emeyer> …So I’d like to take an explicit resolution to that effect
13:40:07 <dbaron> That might depend whether people are more familiar with the shorthands or the longhands, which might in turn depend on whether the shorthands or longhands are older.
13:40:07 <emeyer> (no objections)
13:40:41 <emeyer> RESOLVED: add explicit text to the forced colors spec to make it clear sshorthands also apply to their longhands
13:41:12 <emeyer> s/sshorthands/shorthands/
13:41:43 <kbabbitt> q+
13:41:50 <emeyer> astearns: There should be an explicit criteria in the spec that says why these properties are in the list, so we know that new color propoerties should go onto the list
13:41:58 <emeyer> fantasai: Do we need a list?
13:42:04 <emeyer> TabAtkins: Yes, we need a list
13:42:19 <emeyer> alisonmaher: There is an additional list that has box-shadow and other things
13:42:27 <emeyer> …The main list is all colors
13:42:39 <emeyer> …For the main list, we might be able to do something to make that more clear
13:42:51 <emeyer> astearns: Actually, never mind; what’s in the spec seems good for this
13:43:11 <emeyer> …I thus drop my third proposal
13:43:24 <emeyer> kbabbitt: I was going to ask Elika’s question about whether we need a list
13:43:56 <emeyer> …I guess we can say any color component of a property is force-adjusted; for example, these properties
13:44:02 <emeyer> fantasai: Unless otherwise called out
13:44:04 <emeyer> kbabbitt: Yes
13:44:12 <kbabbitt> ack kbabbitt
13:44:18 <emeyer> astearns: Do you feel strongly about omitting the list
13:44:39 <emeyer> fantasai: I feel it would be better for maintenance going forward to not have an explicit list
13:44:53 <emeyer> …I wouldn’t mind having a list in a note that’s noted as examples
13:44:57 <bkardell> that seems sensible to me
13:45:09 <bkardell> +1 to fantasai's comment
13:45:14 <emeyer> kbabbitt: I do agree that we shouldn’t have to update this spec every time a color property is added
13:45:30 <emeyer> florian: It makes sense having the general principle
13:45:42 <emeyer> …Otherwise, if the list is normative, that’s a maintenance burden
13:46:05 <emeyer> alisonmaher: Question on that note; in the list we don’t have some colors, but they’re in a second list as exceptions
13:46:30 <emeyer> florian: Color-related properties not affected, or affected in a special way; those should be in a normative list
13:46:36 <emeyer> alisonmaher: Sounds good
13:47:00 <emeyer> astearns: I think the proposed resolution is to take the list of affected properties and put them in a note saying, at the time of note-writing, here are the affected properties
13:47:02 <emeyer> Objections?
13:47:05 <emeyer> (silence)
13:47:30 <emeyer> RESOLVED: put the list of affected properties in a note saying at the time of note-writing, here were the affected properties
13:47:49 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/6900
13:47:49 <github-bot> Topic: Republishing Tasks Permathread
13:47:49 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6900.
13:48:06 <emeyer> astearns: Any concerns about FPWD for this module?
13:48:18 <emeyer> …Or anyone who’d like to take time to review the edits before moving on?
13:48:36 <emeyer> …Objections?
13:48:40 <emeyer> (none)
13:49:02 <emeyer> RESOLVED: public First Public Working Draft of CSS Gaps
13:49:25 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11999
13:49:25 <github-bot> Topic: [css-cascade-7] @sheet - allow nested @sheet statements?
13:49:25 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11999.
13:50:13 <emeyer> kurt: For @sheet, should we allow sheets to be nested?  It would be similar to @layer
13:50:22 <emeyer> …They should also be delimited with a period, like with layers
13:50:33 <emeyer> …My proposal is that we allow this for consistency
13:50:37 <TabAtkins> q+
13:50:42 <astearns> ack TabAtkins
13:50:53 <emeyer> TabAtkins: This sounds reasonable; what’s the complexity about @import?
13:51:09 <emeyer> kurt: The behavior of @import in @sheet isn’t well defined yet
13:51:20 <emeyer> TabAtkins: Do you foresee any extra complexity?
13:51:25 <emeyer> kurt: I don’t
13:51:44 <emeyer> astearns: It makes sense to me to follow the layers model
13:51:45 <bramus> +1
13:52:07 <emeyer> astearns: Proposed resolution is to allow nested @sheet statements and follow the nested layer syntax
13:52:24 <emeyer> RESOLVED: Allow nested @sheet statements and follow the nested layer syntax
13:52:27 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12000
13:52:27 <github-bot> Topic: [css-cascade-7] Should anonymous @sheets be explicitly disallowed?
13:52:27 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12000.
13:53:03 <emeyer> kurt: You can have anonymous layers, but for sheets, rules don’t apply until they’re imported but you can’t import an anonymous sheet
13:53:09 <emeyer> …So I think we should disallow that
13:53:15 <emeyer> TabAtkins: Agreed
13:53:16 <bramus> +1
13:53:31 <emeyer> astearns: Any reason someone might want to set up a bunch of sheets and then add a name later?
13:53:36 <emeyer> TabAtkins: No
13:53:50 <emeyer> …We’d have to make the rule mutable, and we aren’t consistent about that
13:54:03 <emeyer> …Worst case, you can put in a dummy name
13:54:27 <emeyer> kurt: If a sheet could have wildcards, maybe, but we don’t
13:54:59 <emeyer> kbabbitt: It does imply that when we write the CSSOM, the sheet name should be immutable
13:55:18 <emeyer> TabAtkins: We could make it mutable but a DOM string, but I don’t think there’s a great reason to make it mutable
13:55:36 <emeyer> astearns: Proposed resolution is to require a name for every @sheet rule
13:55:44 <emeyer> …Objections?
13:55:46 <emeyer> (none)
13:55:57 <emeyer> RESOLVED: Require a name for every @sheet
13:55:59 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11998
13:55:59 <github-bot> Topic: [css-cascade-7] CSS @sheet - is there a need for an @sheet statement (in addition to block)?
13:55:59 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11998.
13:56:25 <emeyer> kurt: Another divergence from @layer: you can have a statement without any rules
13:56:34 <TabAtkins> q+
13:56:45 <astearns> ack TabAtkins
13:56:45 <emeyer> …The difference is that in @sheet, there are no explicit priorities
13:56:51 <emeyer> TabAtkins: I agree
13:57:23 <emeyer> …The @layer is a completely different construct that just has a similar pattern
13:57:40 <emeyer> …If you need an empty sheet, just put empty braces after it
13:57:58 <emeyer> astearns: If the only purpose is avoid writing open-close brackets, that’s not worth the effort
13:57:59 <emeyer> TabAtkins: Right
13:58:31 <emeyer> astearns: Proposed resolution is that bare @sheet statements are invalid; block is always required
13:58:44 <emeyer> RESOLVED: bare @sheet statements are invalid; the following block is always required
13:58:46 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12001
13:58:46 <github-bot> Topic: [css-cascade-7] What happens with duplicate @sheet identifiers?
13:58:46 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12001.
13:59:11 <emeyer> kurt: Yet another @layer divergence, which I used as imspiration for @sheets
13:59:35 <emeyer> …In @layer, duplicate names cause rules to be merged, but here this is up for interpretation
13:59:39 <TabAtkins> q+
13:59:53 <emeyer> …Other name-defining rules are, last one wins, and I think that makes sense here
14:00:06 <emeyer> TabAtkins: I agree with the points in the thread
14:00:13 <astearns> ack TabAtkins
14:00:28 <emeyer> …@layer is setting an aspect of specificity, and not an independent construct
14:00:37 <emeyer> …@sheet does create a construct, and thus last shoudl win
14:00:43 <emeyer> astearns: Is that okay with you?
14:00:46 <emeyer> kurt: Yes
14:00:48 <bramus> (I’m undecided on it)
14:01:06 <emilio> present+
14:01:07 <emeyer> astearns: So @sheet conflicts go with last-defined wins
14:01:42 <emeyer> bramus: I’m just not sure which way this should swing, but Tab makes a good point
14:01:52 <emeyer> astearns: So your concern is more why @layer does this?
14:02:16 <emeyer> bramus: More that if @layer does this, why doesn’t @sheet? Authors might not see the technical different underneath the two things
14:02:27 <stepheckles> stepheckles has joined #css
14:03:01 <emeyer> astearns: How about a resolution to have @sheet use last-definition-wins for now, without prejudice; we can raise again later if the need arises
14:03:06 <emeyer> …Any objections?
14:03:11 <emeyer> (silence)
14:03:27 <kurt> https://github.com/w3c/csswg-drafts/pull/11980
14:03:27 <emeyer> RESOLVED: WHere @sheet names conflict, the last one delcared wins
14:03:58 <emeyer> kurt: Feedback welcome on #11980 as well
14:04:15 <kurt> Formatted version here: https://kurtcattischmidt.github.io/kurtspublishedw3cdrafts/AtSheet.html
14:04:21 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11859
14:04:21 <github-bot> Topic: [selectors][css-scoping] Should :host(:has()) match?
14:04:21 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11859.
14:04:57 <emeyer> alisonmaher: We previously resolved to allow host:has(), matching against shadow DOM descendants
14:04:57 <TabAtkins> :host:has() (allowed), :host(:has()) (what we're discussing here)
14:05:09 <emeyer> …But the spec doesn’t allow matching into the light DOM
14:05:20 <emeyer> …If we were to allow this, we’d have to change something
14:05:32 <emeyer> …I think we’d have to change what we allow by :host
14:05:39 <TabAtkins> q+
14:05:44 <astearns> ack TabAtkins
14:05:46 <emeyer> …Want to open this for discussion
14:06:24 <emeyer> TabAtkins: The main objection for this was coming from Apple developers, so I’d like to have them in the room when we discuss this
14:06:35 <tantek> tantek has joined #css
14:06:51 <emilio> q+
14:06:53 <emeyer> …My opinion is we should allow everything because I like features, but I also appreciate performance concerns
14:07:06 <astearns> ack emilio
14:07:14 <emeyer> …I can’t represent their opinion
14:07:54 <emeyer> emilio: This might not be an issue because of where CHroms sotres (or maybe stored?) invalidations, but we really don’t want to do the same
14:08:26 <emeyer> …I do think it can be problematic
14:08:58 <emeyer> …I can check with the person who implemented :has() in Gecko, but I think this makes invalidating :has() rather complicated and I’m not sure how to go about it
14:09:17 <emeyer> s/CHroms sotres/Chrome stores/
14:09:46 <emeyer> …I can take an issue to check with David Shin, but I don’t see a great way of making this fast
14:10:12 <emeyer> astearns: I know Ryuske hosted Breakout Day sessions that were at least related to this; anyone attend those?
14:10:15 <emeyer> (no)
14:10:29 <emeyer> …I’ll look to see if there’s anything there I can bring back to the issue
14:10:36 <emeyer> …We’ll have to come back to this later
14:10:42 <emeyer> alisonmaher: Sounds good to me
14:11:23 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10296
14:11:23 <github-bot> Topic: [selectors] Adding a `:heading()` selector for headingoffset?
14:11:23 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10296.
14:12:15 <emeyer> TabAtkins: There was a suggestion for adding a :heading to apply to all headings, and also to select to select things based onthe outline algorithm that eventually got dropped
14:12:38 <emeyer> …There are HTML attributes that let you adjust the level of headings in a subtree, so this is relevant again
14:13:01 <emeyer> …Anything we do here should be contigent on the HTML thing actually happens
14:13:33 <emeyer> …Proposal is to allow `:heading(an + b)` that applies to adjusted heading levels rather than tag names
14:13:39 <ydaniv> ydaniv has joined #css
14:13:53 <kizu> q+
14:13:57 <astearns> ack kizu
14:14:06 <emeyer> kizu: I support this
14:14:10 <TabAtkins> (comma-separated list of an+b expressions)
14:14:29 <emeyer> …Do we want to have a shortcut to allow `:heading(n)`
14:14:32 <emeyer> TabAtkins: Yes
14:15:30 <emeyer> astearns: Proposed resolution is allow comma-separated list of an+b expressions to apply to adjusted heading levels
14:15:39 <emeyer> …Seeing no objections,
14:16:04 <emeyer> RESOLVED: Add `:heading()` that accepts a comma-separated list of an+b expressions
14:16:46 <emeyer> TabAtkins: All the UA stylesheets apply to headings by tag names, which has tag-level specificty
14:17:04 <emeyer> …A `:heading()` would by default of class specificity
14:17:08 <emeyer> …Is that a problem?
14:17:12 <kbabbitt> q+
14:17:19 <astearns> ack kbabbitt
14:17:23 <emeyer> …Should we say `:heading()` has tag specificity rather than tag specificity?
14:17:45 <kizu> q+
14:17:45 <emeyer> kbabbitt: To the extent this would juggle rule application order, that would be confined to the UA stylesheet, right?
14:17:49 <emeyer> TabAtkins: Yes
14:18:07 <emeyer> kbabbitt: So the implementor could rejuggle styles
14:18:25 <emeyer> TabAtkins: Yes, but author styles might get overridden byu the new UA styles if this has class specificity
14:18:36 <emeyer> kbabbitt: Ah, so that’s the concern, is that clash
14:18:42 <emeyer> TabAtkins: Yes, it’s representative
14:18:46 <astearns> change my h1, h2, h3, h4, h5, h6{} rule to :heading{}
14:18:54 <emeyer> …of the general class of concerns
14:18:56 <kurt> *:heading()?
14:19:10 <emeyer> astearns: I think there’s good reason to define this as having tag specificity
14:19:14 <TabAtkins> (the workaround is `:is(div:not(*), :where(:heading))`)
14:19:25 <emeyer> kbabbitt: Do we have other pseudos that do this?
14:19:47 <emilio> q+
14:19:48 <emeyer> TabAtkins: No; we don’t have any pseudos that stand in for tag nakmes except maybe :any-link
14:19:56 <astearns> ack kizu
14:20:22 <emeyer> kizu: It’s basically an alias to the adjusted tag names, so tag specificity makes sense here
14:20:24 <astearns> ack emilio
14:20:26 <emeyer> q+
14:20:34 <kbabbitt> s/is that clash/is authors adopting the new pseudo and getting surprising results/
14:20:47 <emeyer> emilio: Have we checked if changing the UA style sheet will result in conflict?
14:21:08 <emeyer> …I agree that migrating to H-tags to this makes tag specificity appealing
14:21:22 <emeyer> …But having a pseudo with tag specificity is odd
14:21:35 <kizu> `:is(h1,h2,h3)` — also a pseudo-class with tag specificity, kinda
14:21:39 <emeyer> …What about attribute selectors?
14:21:51 <emeyer> TabAtkins: They’re exactly class level
14:22:15 <emeyer> emilio: …I’d rather keep to class specificity for consistency, unless we find out it breaks lots of things
14:22:18 <bramus> +1 on staying consistent
14:22:27 <emeyer> …I think that’s somewhat unlikely
14:22:45 <emeyer> astearns: I’m not that concerned about the user stylesheets
14:22:58 <emeyer> …There are likely to be UA rules that can’t use the new thing for whatever reason
14:23:27 <emeyer> …I’m worried about defining this thing and then making it so you can’t use it without knowing the special incantation
14:23:38 <emeyer> TabAtkins: I’m pretty evenly divided on this
14:23:38 <ntim> ntim has joined #css
14:23:43 <astearns> ack emeyer
14:23:44 <TabAtkins> scribe+
14:23:51 <kizu> one of workarounds: `:is(:not(h1, :not(h1)), :where(:heading(1, 2, 3)))`
14:24:03 <lea> What about role=heading aria-level=N?
14:24:14 <ntim> present+
14:24:23 <TabAtkins> emeyer: is there a way we can make it so that... you know how :where() doesn't have specificity implications, can we do something related so it has specificity of the things inside it?
14:24:58 <TabAtkins> emeyer: so :heading(1) that's equivlaent to `h1`, if I have :heading(n+4), can we have the thing in the parens convey the specificity.
14:25:14 <lea> That’s not like :where, :where has 0 soecificity. It’s more like :is or :not
14:25:19 <emeyer> TabAtkins: Ths issue is all things you can do here, you could do with `:is()`
14:25:39 <astearns> ack dbaron
14:25:46 <TabAtkins> (it's always tag-equivalent when you desugar it)
14:25:54 <emeyer> dbaron: I worry about the cost of making rules more complex for everybody
14:26:04 <emeyer> …For implementors, for authors
14:26:20 <emilio> 1+
14:26:24 <emeyer> …This feels like a case of adding more magic, and probably isn’t worth more magic
14:26:26 <emilio> +1*
14:26:37 <emeyer> …The additional overhead of learning and understanding isn’t worth it
14:26:45 <emeyer> …I don’t feel strongly about this, but that’s where I lean
14:26:45 <ntim> +1 to dbaron
14:27:01 <emeyer> astearns: The sense of the room is that making an exception is not motivated enough
14:27:14 <emeyer> …So we should open this to a wider audience to see how people will use this
14:27:46 <emeyer> TabAtkins: Like IDs exist only for IDs, tags exist to apply to tags, so it’s probably unlikely to cause issues in practice
14:28:08 <emeyer> …I think having :heading() being class specificity should be safe
14:28:24 <kizu> `.foo { … } h1 { … } <h1 class="foo">` — replacement  here will not be safe
14:28:29 <emeyer> astearns: Since that’s what falls out of the definition, do we need a resolution?
14:28:41 <emeyer> TabAtkins: Let’s record the sense of the room
14:28:46 <emeyer> astearns: Objections?
14:28:48 <emeyer> (none)
14:29:03 <emeyer> RESOLVED: `:heading()` has the expected class-level specificity
14:29:26 <emeyer> astearns: Lea asked about ARIA heading roles
14:29:37 <emeyer> TabAtkins: That’s up to HTML, not our problem
14:29:40 <emeyer> astearns: Fair enough
14:29:44 <dbaron> I think in general aria attributes don't affect non-a11y things, though.
14:29:51 <TabAtkins> ("what are headings" and "what level are they" is a host-language problem)
14:30:18 <astearns> topic: 20 mins break
14:31:21 <TabAtkins> kbabbitt, https://github.com/w3c/transitions
14:33:28 <ydaniv> ydaniv has joined #css
14:41:03 <dholbert> dholbert has joined #css
14:44:07 <ydaniv> ydaniv has joined #css
14:48:39 <dshin> dshin has joined #css
14:51:31 <ydaniv> ydaniv has joined #css
14:51:33 <alisonmaher> alisonmaher has joined #css
14:51:53 <TabAtkins> ScribeNick: TabAtkins
14:52:15 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11969
14:52:15 <github-bot> Topic: [selectors][css-conditional] Pseudo-class or combinator that is syntactic sugar for wrapping in an `@rule`
14:52:15 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11969.
14:52:19 <lea> present+
14:52:38 <TabAtkins> lea: a while back i posted a proposal for :media() pseudo-class
14:52:44 <TabAtkins> lea: was well received, tho didn't get finished
14:52:51 <TabAtkins> lea: since then i've been spotting a more general problem, not just MQs
14:53:02 <TabAtkins> lea: combining filterering logic from other at-ruels with selectors
14:53:09 <TabAtkins> lea: conditional rules in general are obvious example
14:53:35 <astearns> (we just added media() to @import: https://github.com/w3c/csswg-drafts/issues/10972#issuecomment-2773298233)
14:53:35 <TabAtkins> lea: but also @layer. use-case is you want to style regular elements by tag name, but give them lower priority by defualt, or offer a class name to apply them as well
14:53:45 <TabAtkins> lea: or @scope, with one selector in the scope and another selector outside
14:53:57 <TabAtkins> lea: @starting-style too, might want it to share some styles with a regular selector
14:54:06 <TabAtkins> lea: so at this point I think we need a more general solution
14:54:15 <TabAtkins> lea: i posted a proposal but am not married to it, just want to solve the problem
14:54:26 <TabAtkins> lea: proposal is a pseudo-class that is generic enough, letting people specify any at-rule
14:54:30 <TabAtkins> lea: it's sugar for nesting
14:54:47 <TabAtkins> lea: in every example i gave, the "after" version includes duplicates
14:55:01 <TabAtkins> lea: someone thought this was a compact way to do nesting; that's a benefit, sure, but not the point
14:55:21 <TabAtkins> lea: right now if you have something applied via an at-rule and a selctor, duplication is all you can do. and someontimes that can be *dozens* of declarations
14:55:30 <TabAtkins> lea: Oriol suggested it only makes sense for CSSGroupingRule
14:55:37 <TabAtkins> lea: that drops @page, but that's not a major use-case
14:55:40 <kizu> q+
14:56:09 <TabAtkins> lea: someone suggested the opposite, having an at-rule that allows combining with selector logic
14:56:19 <oriol> q+
14:56:26 <TabAtkins> lea: that could work, but it's less flexible, selectors are better known
14:56:34 <TabAtkins> TabAtkins: you also ccan't combine multiple at-rules that way
14:56:41 <astearns> ack kizu
14:56:46 <hoch> hoch has joined #css
14:56:57 <TabAtkins> kizu: i think it would be great to have something like that. the problem is quite common, for darkmode for example
14:57:09 <TabAtkins> kizu: have a selector that applies it, and an at-rule that applies it by default
14:57:24 <TabAtkins> kizu: this could potentially be done with block-level mixins, but it woudln't be a sconvenient as what's expressed in this issue for one-offs
14:57:24 <lea> Dark mode is actually a good use case for combining the logic with `@scope`, if you have e.g. `.dark` and `.light` and `.invert` classes
14:57:31 <emilio> q+
14:57:39 <TabAtkins> kizu: you could make a mixin that wraps any number of rules and use it in multiple spots
14:57:49 <TabAtkins> kizu: but for one-offs, having this just live in the selector is convenient
14:57:50 <astearns> ack oriol
14:58:03 <TabAtkins> oriol: mentioning a point i raise din the issue
14:58:09 <TabAtkins> oriol: this is equivalent to some desugaring, and we have options
14:58:11 <fantasai> I have to drop soon, but I have some concerns about using a pseudo-class here.
14:58:16 <TabAtkins> oriol: expand to the desugar, or say the behavior is equivalent
14:58:20 <lea> q?
14:58:23 <lea> q+
14:58:25 <TabAtkins> oriol: my concern with the first is it's easy to have combinatorial explosions
14:58:32 <TabAtkins> oriol: with second option it seems more complex to implement
14:58:37 <TabAtkins> oriol: so a bit tricky
14:58:45 <fantasai> Because a pseudo-class is classifying an element, and these conditions aren't connected to an element but to a selector as a whole
14:58:49 <TabAtkins> oriol: since the order of these things matter, i don't think a pseudo-class is right
14:58:59 <TabAtkins> oriol: should be a combinator maybe, use the @ as a combinator
14:59:01 <lea> qq+
14:59:08 <astearns> ack lea
14:59:08 <Zakim> lea, you wanted to react to oriol
14:59:24 <TabAtkins> lea: right, i forgot about the combinator idea, i do like that better. Tab will have to commont on whether it's possible grammar-wise
14:59:27 <TabAtkins> TabAtkins: i'll have to think about it
14:59:29 <astearns> ack emilio
14:59:43 <TabAtkins> emilio: i'm curious about the ocmbinator idea. what does it combine with?
15:00:02 <TabAtkins> emilio: at least for some of these reules it's quite complicated. @media and @supprots are fine, but @laer and @scope change the cascade order
15:00:18 <TabAtkins> emilio: i'm just not sure how we'd define mixing multiple of these
15:01:02 <TabAtkins> emilio: for each rule that provides a boolean answer, that's fine. for @scope and @container, it might make sense as long as we prevent the cascade-order side effects, otherwise i don't know how it works. how does multiple @scope work
15:01:19 <TabAtkins> emilio: so i'd rather not start making selectors affect the cascade order other than via specificity
15:01:22 <lea> q?
15:01:24 <astearns> ack dbaron
15:01:24 <ntim> Not super convinced about the cost/benefit ratio of the idea
15:01:45 <TabAtkins> dbaron: another concern is if we want to do this, we shoudl figure out the perf characteristic we want
15:02:14 <TabAtkins> dbaron: some filtering at-rules have an expectation that the filter happens at a particiular stage. when thye look like selectors, the normal expectation for selector matching is a different stage of the process; might happen later and many more times than as an at-rule
15:02:30 <TabAtkins> dbaron: and that's tied into the question of how they're represented in the cssom, and if this expands the way oriol said
15:02:31 <TabAtkins> q+
15:02:39 <astearns> ack lea
15:02:53 <TabAtkins> lea: to emilio, @scope/layer/container ar emajor use-cases.
15:03:04 <TabAtkins> lea: just solving for conditionals would be useful, but it doesn't reach the 80% case
15:03:15 <TabAtkins> lea: @container is biggest from the non-conditional cases, then @scope then @layer
15:03:35 <TabAtkins> lea: to dbaron, i think perf should be similar to the desugared veresion or better, since we're not duplciating declarations
15:03:49 <TabAtkins> lea: to oriol, combinatorial is less here than regular nesting, less at-rules to combine with
15:03:54 <emilio> q+
15:04:00 <TabAtkins> lea: so even if we go that way, it's not as bad, and we cna introduce a maximum limit
15:04:09 <TabAtkins> lea: i think the number of at-rules in actual use is fine, two or three
15:04:26 <TabAtkins> lea: thinking more abou tthe combinator idea, while i like the syntax, i don't like that it muddles what a combinator is
15:04:32 <TabAtkins> lea: combinators get you from one element to another element
15:04:49 <TabAtkins> lea: here we're not doing that, at-rule can be wrapping the whole thing, or something at the end, etc
15:04:52 <TabAtkins> lea: not sure about this
15:05:15 <TabAtkins> lea: another benefit of doing this in selector land, selectors have forgiving handling for selectors we don't understand in :is()/:where()
15:05:24 <TabAtkins> lea: so authors could use this immediately and wrap in an :is()
15:05:32 <TabAtkins> lea: while an at-rule that's misunderstood gets dropped entirely
15:05:51 <TabAtkins> lea: last, i was thinking what if instead of a pseudoclass, could we @sheet andd import that internally?
15:06:09 <TabAtkins> lea: could have the style rule and at-rule, then just import the @sheet inside of each
15:06:18 <TabAtkins> lea: tim, you said not sure about cost-benefit. is it the cost of the syntax or the benefit of the results?
15:06:19 <florian_irc> florian_irc has joined #css
15:06:26 <TabAtkins> ntim: cost of the syntax, mostly, and having devs understand the syntax
15:06:34 <TabAtkins> ntim: i'm not convinced the current proposals are easy to understand
15:06:42 <TabAtkins> ntim: so those combined vs the benefit from it...
15:06:59 <TabAtkins> lea: fair. i htink if the syntax was as close to the at-rule as possible would help. but there might be value in two separate resolutions
15:07:16 <TabAtkins> lea: (a) is this a problem to solve in some way, and (b) the specific syntax
15:07:30 <TabAtkins> ntim: also, where the combinator/pseudo-class fits in the order...
15:07:34 <TabAtkins> lea: that's explained in the proposal
15:07:46 <TabAtkins> lea: the pseudo-class downside is the relative order of pseudo-classes mattered, which is new
15:08:06 <lea> scribe+
15:08:39 <lea> TabAtkins: This is a problem worth solving. I had to do this duplication before, avoided doing somethings because of the duplication. I think the right place to solve it is on the declaration, neither the @rules or the selectors.
15:09:25 <lea> Combining our existing rules because they work in many ways is not super feasible in an understandable way. Giving us a mechanism to easily dedupe chunks of declarations would be good. Mixins are the obvious way, or your idea of being able to reference an `@sheet`
15:09:56 <kbabbitt> q+ to comment on the @sheet approach
15:10:00 <lea> TabAtkins: It requires more work for one-off cases, but I think that's still justified for the overall improvement. Some way to do rule-level deduplication of contents
15:10:02 <astearns> ack TabAtkins
15:10:18 <TabAtkins> dbaron: i probably agree witih Tab
15:10:20 <lea> q+
15:10:21 <emilio> q-
15:10:31 <TabAtkins> dbaron: i think there are widely different solutions to the underlying problems
15:10:37 <TabAtkins> dbaron: i'm very worried about the complexity of this particular set of solutions
15:10:47 <TabAtkins> dbaron: two things. first is comment about perf
15:10:55 <TabAtkins> dbaron: lea said shoudl be faster because less duplication
15:11:12 <TabAtkins> dbaron: what i meant was, if you have @media or @support that doesn't match, those rules get thrown out earlier than doing selector matching
15:11:36 <emilio> +1 to dbaron
15:11:40 <emilio> (Was on the queue for that)
15:11:48 <TabAtkins> dbaron: whereas if it looks like as elector, the syntax is saying "we'll try to match all of these", then we get to the top and see the :media(). we've spent all this time on selecto rmatching for rules that we could ahve avoided
15:11:53 <TabAtkins> lea: doesn't that depend on how it's implemented?
15:12:02 <oriol> This is my combinatorial explosion concern https://www.irccloud.com/pastebin/3PIUwxZd/
15:12:09 <TabAtkins> dbaron: yes, but if you assume it's going to be implemented by desugaring to some other syntax, you need to make sure that's practical to
15:12:33 <TabAtkins> dbaron: so i don't think it's trivial to say "it'll be faster", you'd need a practical proposal for the underlying model
15:12:34 <astearns> ack dbaron
15:12:38 <TabAtkins> dbaron: and ahve a plan for what to do about it
15:13:00 <TabAtkins> dbaron: second point, when you say "is it worth solving", i think we still need to udnerstand what cost
15:13:17 <ntim> +1 to dbaron
15:13:20 <TabAtkins> dbaron: when i look at this proposal, i ask how much complexity is this adding to selector matching. is it 20% more complex, or twice as complicated?
15:13:22 <lea> q+
15:13:50 <TabAtkins> dbaron: i dont' know the answer off the top of my head, but I think when i look at a proposal like this, we're really asking the question "is it worth potentially doubling the complexity of selector matching to solve this", which i think is a real possibility
15:14:04 <TabAtkins> dbaron: while I think Tab's mixin idea is much lower cost and does get the bulk of the use-cases
15:14:06 <astearns> ack kbabbitt
15:14:06 <Zakim> kbabbitt, you wanted to comment on the @sheet approach
15:14:28 <TabAtkins> kbabbitt: wrt @sheet approach, we're very limited now in where we can put @import to reference the sheet
15:14:40 <TabAtkins> kbabbitt: apart from that, i tend to agree with tab adn david that i worry about the complexity this is adding
15:14:48 <TabAtkins> kbabbitt: i think it's worth exploring if we can solve this with mixins
15:14:54 <astearns> ack lea
15:15:08 <TabAtkins> lea: i agree with Tab as well. like I said in the beginning, i just want to solve the problem, not married to a solution
15:15:28 <TabAtkins> lea: since i've seen a lot of use-cases, their characteristics is usually you don't have a ton of them, but th eones you have are big. wrapping an entire stylesheet, an entire theme
15:15:39 <TabAtkins> lea: and you just want to wrap the whole thing with a selector *and* an at-rule
15:15:46 <ydaniv> ydaniv has joined #css
15:16:00 <TabAtkins> lea: btw to dbaron, i said we *might* gain some perf from deduplication. unsure if it's a net positive or not.
15:16:11 <TabAtkins> lea: but i might be convinced this can be done with mixins
15:16:34 <TabAtkins> lea: so, if mixins are solving this, does it chagne the cost-benefit to drop some cases? like dropping @layer and only doing conditionals or @scope
15:16:39 <astearns> q+
15:16:47 <TabAtkins> lea: is there a subset that we could carve out that makes it easier to solve with a pseudo-class?
15:16:58 <lea> `:if()` even
15:18:17 <TabAtkins> TabAtkins: [i wasn't minuted]
15:18:28 <TabAtkins> lea: smaller places come out of here, like @supports
15:18:29 <dbaron> (though on second thought, earlier filtering probably looks a bit like the bloom filter optimizations that we already have so it's probably not too hard)
15:18:37 <TabAtkins> lea: some new CQs like :stuck
15:18:40 <dbaron> (but many of the other issues remain)
15:19:13 <kizu> q+
15:19:22 <astearns> (unminuted back and forth)
15:19:44 <TabAtkins> astearns: i know mixins are still vague, but are there problems outlined in this issue that they're not a solution for?
15:19:57 <astearns> ack astearns
15:19:58 <lea> scribe+
15:20:15 <lea> TabAtkins: Mixins should be able to trivially address anything that can be nested in a style rule today
15:20:43 <lea> TabAtkins: Any model we're thinking for mixins allows that. Conditionals work, scope works, container works. layer currently doesn't, but should be fine to amend it to do so
15:20:56 <lea> TabAtkins: I think those are all the rule examples that have been given, so it should be fine
15:20:57 <lea> q+
15:21:05 <TabAtkins> astearns: so everything in this issue should be input ot our mixins work
15:21:17 <lea> TabAtkins: Yes, nested @layer is the only new use case
15:21:19 <astearns> ack kizu
15:21:46 <TabAtkins> kizu: to answer lea's q about if there's anything form what we were talkinga bout that would b euseful in a selector space, i can only really think of CQs
15:21:57 <TabAtkins> kizu: with CQs you can have a named container, then choose a container for which you're running the query
15:22:15 <TabAtkins> kizu: with selectors it could be useful as a shortcut to be able to indicate at which element you're running the querys
15:22:32 <TabAtkins> kizu: right now to do this you ahve to write a seaprate selector creating a named container
15:22:46 <TabAtkins> kizu: so kinda convenient in selectors. exception is probably not usable inside a :has()
15:22:47 <astearns> ack lea
15:23:09 <TabAtkins> lea: right now, proposals around mixins have been global. that works for the big-chunk use-cases, but less for the smaller use-cases
15:23:20 <TabAtkins> lea: liek "i just want to add two delcarations if this is supported"
15:23:27 <florian_irc> florian_irc has joined #css
15:23:27 <TabAtkins> lea: wonder if some small version of scoped mixins would be useful here
15:23:45 <TabAtkins> lea: naming things globally is hard. small targeted mixins with local names could be more lightweight
15:23:57 <lea> scribe+
15:24:26 <kizu> (https://github.com/w3c/csswg-drafts/issues/11798 — an issue about scoping named things)
15:24:37 <lea> TabAtkins: The possibilities there are interesting. Mixins will get applied before the cascade, at sheet parsing layer. We could have a notion of lexical scope, that is I think a viable thing to explore.
15:24:47 <lea> TabAtkins: No comment on whether we'll for that but it sound plausible
15:25:39 <TabAtkins> astearns: so queue is empty. close this discussion for now?
15:25:51 <TabAtkins> lea: yeah. fine to even close the issue. looks like we want to take this as input into mixins.
15:26:18 <TabAtkins> lea: so i'm hearing we're sorta in agreement about solving this as long as cost is reasonable. doing it in selector isn't reasonable in cost/complexity. so we'll take it as input to ensure mxiins satisfy these
15:26:43 <TabAtkins> TabAtkins: can I have lea open an issue on Mixins spec?
15:26:48 <TabAtkins> lea: yeah, will tag in this issue
15:26:50 <lea> ACTION: Lea to open issue with these use cases and ideas tagged mixins
15:27:32 <lea> PROPOSED RESOLUTION: We agree the problem needs solving, but doing it selectors seems too complex. We'll instead close this and make sure mixins satisfy these use cases.
15:27:42 <TabAtkins> astearns: objections?
15:27:51 <TabAtkins> RESOLVED: We agree the problem needs solving, but doing it selectors seems too complex. We'll instead close this and make sure mixins satisfy these use cases.
15:28:16 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/2425
15:28:16 <github-bot> Topic: ::slotted() should full support complex selector!!
15:28:16 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/2425.
15:29:21 <TabAtkins> lea: representing this since it's opened by a non-member
15:29:45 <TabAtkins> lea: since ::slotted() only does compound selectors, it imposes constraints on the markup that aren't good for a11y, seo, etc. forces a shallower structure than is ideal
15:30:06 <TabAtkins> lea: in many cases you ahve new components thata re just a div, but that way you have logic and styling in them. <carous-el> and <carous-el-item>
15:30:28 <TabAtkins> lea: lots of instances of this, parent control and dummy child control, just to get ::slotted access
15:30:37 <TabAtkins> lea: so lots of people confused
15:30:42 <TabAtkins> lea: usual pushback is hard to implement
15:30:52 <TabAtkins> lea: and pushback against ::slotted() a combinator is it doesn't support complex selectors
15:31:07 <TabAtkins> lea: think we'll need to do that at some point anyway, and then we'll have a pseudo-element with complex selectors, which is worse
15:31:25 <TabAtkins> lea: so i think this adds to the pile of reasons slotted should be a combinator (not to beat a dead horse)
15:31:42 <TabAtkins> lea: i hear the arguments about not breaking encapsulation, don't want a component tos tyle light dom... i disagree, but i get them
15:32:02 <TabAtkins> lea: but for things inside the component's own light-dom subtree, it's arbitrary to say they can style their direct chidlren but not descendants
15:32:23 <TabAtkins> lea: like how would we do <tab-el>? or <s-el-ect>?
15:32:42 <TabAtkins> astearns: in your comments you said usual complaint is hard to implement. i think keith put this on here to ask
15:33:06 <TabAtkins> TabAtkins: do we want to delay until Emilio returns, then?
15:33:29 <TabAtkins> ntim: i wanna hear from Ryosuke as well
15:33:59 <TabAtkins> astearns: so maybe we can take this up... would this be okay to take up in the Forms TF? can we get ryosuke to join that?
15:34:07 <TabAtkins> ntim: how is that forms related...
15:34:29 <TabAtkins> astearns: so we're closing this with "i dunno" for now
15:36:19 <lea> github-bot: take up https://github.com/w3c/csswg-drafts/issues/6245
15:36:19 <github-bot> Topic: Interpolate values between breakpoints
15:36:19 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6245.
15:37:07 <TabAtkins> TabAtkins: we talked about this a few weeks ago. people liked -mix(), but not -map() or -scale()
15:37:17 <TabAtkins> lea: linked, we talked about interpolate, tween, range, scale
15:37:22 <TabAtkins> lea: we're looking for somethign that works for many types
15:37:41 <TabAtkins> lea: color-sacle is fine, calc-scale is fine, but image-scale is bad, and generic scale() conflicts with transforms
15:37:49 <TabAtkins> lea: i think tween() is obscure and tied to animations
15:37:55 <TabAtkins> lea: range() sounds like it returns a range
15:38:02 <TabAtkins> lea: intermediate() is as longa s interpolate().
15:38:15 <TabAtkins> lea: interpolate() is clearest, it's just long. but other than that i think it's best option
15:38:18 <oriol> q+
15:38:26 <TabAtkins> lea: so if we can't do scale() i think interpolate() is best
15:38:27 <TabAtkins> lea: confusing is worth than long
15:38:27 <kbabbitt> q+
15:38:30 <astearns> ack oriol
15:38:46 <TabAtkins> oriol: i had a minor question of what's different between mix() and interpolate()
15:39:37 <lea> TabAtkins: The mix functions do a weighted average, the interpolate functions take a sequence of values and an input value, like a gradient, and give you where your progress position landed on
15:39:59 <astearns> ack kbabbitt
15:39:59 <lea> e.g. `color-scale(30%, white, red 30%, black)` would give you red
15:40:13 <TabAtkins> kbabbitt: i like the name interpolate(). agree it's long but it's used elsewhere
15:40:24 <TabAtkins> kbabbitt: bramus pointed out we use it in color-interopolation and interpolate-size
15:40:29 <astearns> ack dbaron
15:40:31 <TabAtkins> kbabbitt: i agree clear is more important than short
15:40:41 <TabAtkins> dbaron: another idea is use the word tab just said, gradient()
15:40:49 <TabAtkins> dbaron: that's a thing people currently understand
15:41:12 <TabAtkins> TabAtkins: i think color-gradient() is a little funky
15:41:19 <dbaron> s/another idea/another idea (maybe a bad idea, but worth considering)/
15:41:31 <TabAtkins> astearns: have there been any arguments against interpolate() besides length?
15:41:33 <TabAtkins> TabAtkins: no
15:41:38 <ntim> gradient reminds me of math gradient descent
15:41:39 <oriol> q+
15:41:43 <astearns> ack oriol
15:42:00 <TabAtkins> oriol: a shorter idea, pick()?
15:42:19 <lea> `image-pick()`, `color-pick()`, `calc-pick()`
15:42:33 <lea> TabAtkins: My only worry is that it sounds like you're picking one of existing options, not interpolating
15:42:59 <TabAtkins> TabAtkins: we can just go for interpolate()
15:43:10 <TabAtkins> lea: yeah i think anything else is just unclear. saving a fe wmore characters isn't worth it
15:43:19 <TabAtkins> astearns: anyone who would prefer not to resolve on interpoltae() today?
15:44:00 <TabAtkins> ntim: what's the sytnax of this function?
15:44:10 <TabAtkins> TabAtkins: [summarizing] it's basically the linear-gradient() syntax, more or less
15:44:24 <TabAtkins> astearns: objectiosn to using interpolate()?
15:44:35 <TabAtkins> RESOLVED: Rename the interpolation functions to *-interpolate()
15:44:43 <TabAtkins> lea: is it before or after the type particle in the name?
15:44:50 <TabAtkins> TabAtkins: after, like color-mix()
15:44:56 <bramus> Yay!
15:44:59 <TabAtkins> astearns: but if yo uwant the other way, open an issue
15:45:43 <TabAtkins> github-bot, end topic
15:45:57 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/7869
15:45:57 <github-bot> Topic: [css-forms-1] `control-value()` function
15:45:57 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7869.
15:46:02 <florian_irc> florian_irc has joined #css
15:46:18 <TabAtkins> ntim: a problem devs often ahve is they want to refer to the value insdie a range or text input
15:46:29 <TabAtkins> ntim: for range input, you see a bubble with a number in it following the thumb
15:46:42 <TabAtkins> ntim: in the current Forms draft there's a control-value() function
15:46:50 <TabAtkins> ntim: syntax is draft-y, i think we can match attr()
15:46:55 <TabAtkins> ntim: i'm hoping to get a formal resolution
15:46:56 <TabAtkins> q+
15:47:14 <lea> q+
15:47:17 <TabAtkins> ntim: and maybe we want to think about the problem of, do we want to scope this to the control itself, or allow other elements to refer to the values of other elements
15:47:25 <TabAtkins> ntim: havne't thought too mucha bout that yet
15:47:31 <astearns> ack TabAtkins
15:47:55 <lea> TabAtkins: I think we should add this. Few details that I listed. Control value is just as dangerous as `attr()` but should be solvable the same way, just repeat the same handling
15:48:16 <lea> TabAtkins: 2. I don't think we should exactly match the attr() syntax, we're not doing arbitrary parsing of an unknown string, we have a well-known value coming from the control
15:48:28 <lea> TabAtkins: getting it as a string is always useful, getting it as a number also useful
15:48:35 <lea> TabAtkins: other than that, I think it's a good idea and we should do it
15:48:50 <TabAtkins> ntim: i agree we should let people switch the types. might want it as a number to use in a calc() to set a width
15:48:57 <astearns> ack lea
15:49:01 <TabAtkins> lea: also agree we should do it
15:49:07 <TabAtkins> lea: how do web components hook into this for their own values?
15:49:31 <TabAtkins> lea: and also, we do want it to inherit in some way. the tooltip of a slider often shows the slider value. so how does that work if it's only on the slider itself.
15:49:47 <TabAtkins> TabAtkins: if it's a pseudo-element it's fine, they refer to the main element
15:49:52 <kbabbitt> q+
15:49:53 <TabAtkins> lea: yeah but that doesn't solve a custom element
15:50:04 <TabAtkins> ntim: yup, pseudo-elements get you part of the way, but not all the wya
15:50:14 <TabAtkins> lea: if it resolves at the right time it's not insumoutable
15:50:19 <TabAtkins> ntim: how does inheritance work?
15:50:42 <TabAtkins> ntim: you'd need to get the value out of the slider and pull it up?
15:50:44 <TabAtkins> TabAtkins: yeah that's hard
15:50:44 <kizu> anchor positioning and scroll-driven animations :)
15:50:51 <florian_irc> florian_irc has joined #css
15:51:14 <astearns> ack dbaron
15:51:15 <TabAtkins> ntim: the separate element reference can be another issue
15:51:55 <TabAtkins> dbaron: there was some discussion of security restrictions in the bug, wanted to make sure it's not list
15:52:03 <TabAtkins> TabAtkins: yeah, i mentioned it should be the same as attr()
15:52:04 <astearns> ack kbabbitt
15:52:08 <TabAtkins> ntim: yup, to avoid exfiltration into a url
15:52:12 <dbaron> s/list/lost/
15:52:28 <TabAtkins> kbabbitt: i was also thinking about security issue here. wondering if it has to be stronger than attr(), like using it on a password input
15:53:05 <TabAtkins> kbabbitt: i don't know if attr() already addresses this
15:53:22 <TabAtkins> TabAtkins: it should, the attr() restriction prevents any value produced by it to be used in a url
15:53:35 <TabAtkins> astearns: so it sounds like we're just asking for waht's in the draft to be blessed?
15:53:38 <TabAtkins> ntim: yeah
15:53:49 <TabAtkins> astearns: proposed resolution: control-value() as described in the draft looks reasonable
15:54:14 <TabAtkins> RESOLVED: Accept control-value() as described in the draft (with subsequent edits)
15:54:28 <TabAtkins> dbaron: also wanted to point out there's proposals to have selectors that depend on control values
15:54:34 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11164
15:54:34 <github-bot> Topic: [cssom-view] Scroll steps don't match implementations
15:54:34 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11164.
15:55:08 <TabAtkins> emilio: the cssom-view spec has a bunch of issues, it doesn't match impls in several parts and are just wrong in several
15:55:27 <TabAtkins> emilio: scroll events aren't fired at a specific time, scroll-snap are fired before other scroll events, there's no distinction between visual viewport and others
15:55:37 <TabAtkins> emilio: i posted my research on how browser behave in this regard
15:56:04 <TabAtkins> emilio: webkit and gecko order visual viewport and regular scroll events consistently
15:56:27 <TabAtkins> emilio: with addition of scrollEnd and scorllSnap, the chromium appraoch of just having them on the same separate queue and fire them in order makes sense, i think
15:56:42 <TabAtkins> emilio: in aprticular, i don't see a reason why scroll triggered by some events should fire on the same frame vs another
15:56:54 <TabAtkins> emilio: so having all scroll events in one queue, fired in order
15:57:01 <TabAtkins> emilio: and side effects firing in next frame. seems fine
15:57:10 <TabAtkins> emilio: i have a patch to fix all this, but wondered if people have strong opinions
15:57:30 <TabAtkins> astearns: did you do any looking back thru commit history to see why scrollsnap is sbefore all other events?
15:57:39 <TabAtkins> emilio: no, they were the last added and i think they were just put in the wrong place
15:58:10 <TabAtkins> TabAtkins: i defer to flackr, so as long as he's looked at it i'm happy to accept emilio's opinion
15:58:19 <TabAtkins> astearns: everyone was pinged, no comments in a few months
15:58:26 <TabAtkins> dbaron: flackr or skobes, i'll ping them both
15:58:36 <TabAtkins> astearns: do people want to wait on a positive response? i'm happy to just change the spec
15:59:02 <TabAtkins> TabAtkins: i think the spec is messy enough that we can just merge what we have and quibble over the details
15:59:07 <TabAtkins> ntim: should i ping Simon?
15:59:12 <TabAtkins> emilio: yes plz
15:59:25 <TabAtkins> astearns: do you think we should wait on resolution?
15:59:34 <TabAtkins> ntim: dunno
15:59:55 <TabAtkins> dbaron: i guess i dont' feel like we have to wait. would be nice to get thru to them at some point, but it can be post resolution
16:00:30 <TabAtkins> astearns: so proposed: Fix up the spec to put all scroll-related events in a single queue
16:00:37 <TabAtkins> ntim: one argument for waiting for simon is he's co-editor
16:00:44 <TabAtkins> emilio: that means he can revert my change
16:00:50 <TabAtkins> astearns: yeah, it's been months and i'd like to move things along
16:00:55 <TabAtkins> astearns: objections to the proposed resolution?
16:01:11 <TabAtkins> RESOLVED: Fix up the spec to put all scroll-related events in a single queue
16:01:16 <TabAtkins> github-bot, end topic
16:01:18 <TabAtkins> <br dur=1h>
16:01:29 <jfkthame> present-
16:02:23 <florian_irc> florian_irc has joined #css
16:06:53 <florian_irc> florian_irc has joined #css
16:24:30 <florian_irc> florian_irc has joined #css
16:30:22 <stepheckles> stepheckles has joined #css
16:41:25 <florian_irc> florian_irc has joined #css
16:53:46 <jwatt> jwatt has joined #css
16:55:42 <jamesn> jamesn has joined #css
16:57:10 <florian_irc> florian_irc has joined #css
17:01:44 <stepheckles> stepheckles has joined #css
17:02:29 <alisonmaher> alisonmaher has joined #css
17:03:20 <florian_irc> florian_irc has joined #css
17:03:36 <kurt> kurt has joined #css
17:03:44 <Francis_Storr> Francis_Storr has joined #css
17:03:47 <bkardell> ScribeNick:bkardell
17:04:05 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11828
17:04:05 <github-bot> Topic: [css-anchor-position] Computed value of `position-area`
17:04:05 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11828.
17:05:14 <bkardell> TabAtkins: the position-area property has a number of syntaxes - it has two that are exactly equivalent
17:05:43 <TabAtkins> start start and `block-start inline-start`
17:05:54 <bkardell> elika said they should be equivalent, tab doesn'thavean opinion
17:06:17 <bkardell> TabAtkins: which of the pair it should go to elika? opinion?
17:06:20 <fantasai> astearns: Should it be the shortest serialization or the most explicit one?
17:07:37 <bkardell> kiet: I opened this - It comes up because I am implementing and some of the tests are mismatched because webkit serializes one way, chrome another - if we have one way it's easier to write tests
17:07:55 <bkardell> florian: make it short if we can
17:08:27 <bkardell> TabAtkins: if it is already the case that multiple browsers do this, but just disagreeonwhich I would agree and say lets just use start start
17:09:09 <bkardell> Proposed resolution: block-start and inline-start will serialize to start start and they will compute to start start
17:09:52 <bkardell> kiet: this also applies to self block start...?
17:09:55 <bkardell> TabAtkins: yes
17:10:12 <florian_irc> florian_irc has joined #css
17:10:47 <TabAtkins> proposed: block/inline-start-end (and the self-* variants) compute to start/end or self-start/end
17:11:16 <bkardell> resolved
17:11:21 <dholbert> dholbert has joined #css
17:11:26 <bkardell> resolved:  block/inline-start-end (and the self-* variants) compute to start/end or self-start/end
17:11:35 <bkardell> RESOLVED:  block/inline-start-end (and the self-* variants) compute to start/end or self-start/end
17:11:39 <bkardell> !!!!
17:11:48 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10422
17:11:48 <github-bot> Topic: [css-anchor-position] flip should also flip safe-area-inset values
17:11:48 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10422.
17:12:58 <fantasai> scribe+
17:13:22 <fantasai> fantasai: position-try flipping should also flip the safe-area-insets
17:14:06 <fantasai> TabAtkins: If you have left: env(safe-area-inset-left) and you flip that to become a top value, you almost certainly want to use the safe-area-inset-top instead of the left.
17:14:17 <florian_irc> florian_irc has joined #css
17:14:17 <fantasai> TabAtkins: That seemed obvious, so I edited it in.
17:14:19 <TabAtkins> commit is here https://github.com/w3c/csswg-drafts/commit/e143edf116418e86e6c940061515d856a70a8d2d
17:14:30 <fantasai> astearns: Does this only happen for top-level values that are the appropriate env() function
17:14:40 <fantasai> astearns: or any component of the value that might happen to be referenced
17:14:52 <fantasai> TabAtkins: the env() function itself will flip if the property flips
17:14:58 <fantasai> astearns: if it's wrapped in complicated calc()
17:15:01 <fantasai> TabAtkins: they all filip
17:15:04 <fantasai> s/filip/flip/
17:15:06 <fantasai> astearns: any other questions?
17:15:25 <fantasai> PROPOSED: env(safe-area-inset-*) flip also
17:15:30 <fantasai> RESOLVED: env(safe-area-inset-*) flip also
17:15:49 <github-bot> Topic: [css-anchor-position] Clarify computed value serialization for `anchor-scope`
17:16:05 <fantasai> TabAtkins: anchor-scope is <ident>#
17:16:12 <fantasai> TabAtkins: in practice it's a set, not a list -- order doesn't matter
17:16:17 <fantasai> TabAtkins: question was what order should it serialize in?
17:16:31 <fantasai> TabAtkins: fantasai argues that Computed value says "as specifies"
17:16:42 <fantasai> TabAtkins: Order needs to be well-defined enough to be specified
17:16:49 <fantasai> TabAtkins: so either need to define a sort order or use input order
17:16:57 <fantasai> TabAtkins: so suggestion is to use the input order
17:17:23 <fantasai> astearns: The only benefit in sorting the serialization is, if something is looking for style changes then the sorting would fail some false positives
17:17:30 <fantasai> astearns: but that's probably not useful enough to require sorting
17:17:43 <fantasai> TabAtkins: if you have allow-discrete transition, that would kick off a transition with no effect
17:17:47 <fantasai> astearns: so I'm fine with saying computed value is as specified
17:18:06 <TabAtkins> fantasai: yeah, i think the ideal computed value woudln't maintain the order, for this reason, but it's such an edge case to care about
17:18:24 <fantasai> astearns: Proposed resolution is the list of idents in anchor-scope are computed in the order specified
17:18:36 <fantasai> RESOLVED: the list of idents in anchor-scope are computed in the order specified
17:18:52 <github-bot> Topic: [css-anchor-position] Naming of the `inside` and `outside` `<anchor-side>` values
17:19:27 <fantasai> TabAtkins: Right now, for generic side names, we use keywords inside / outside
17:19:46 <fantasai> TabAtkins: map to left/right/top/bottom depending on whether it puts anchored item inside the anchor or outside the anchor
17:20:19 <fantasai> TabAtkins: e.g. left: anchor(outside); puts the anchored item outside the anchor, i.e. to the right of the anchor
17:20:32 <fantasai> TabAtkins: jwatt felt these keywords were not super clear and suggested some alternatives
17:20:37 <kizu> q+
17:20:47 <fantasai> TabAtkins: Personally I think inside / outside are pretty fine
17:21:06 <fantasai> TabAtkins: and also these names have been deployed, so unless a strong reason to change, propose to close no change
17:21:08 <astearns> ack kizu
17:21:18 <fantasai> kizu: I think I still like inside / outside more than anything proposed
17:21:25 <fantasai> kizu: given we also have interop thing, we should keep it as-is
17:21:29 <jwatt> I don't have a strong opinion
17:21:49 <fantasai> astearns: objections to closing no change?
17:21:55 <fantasai> RESOLVED: Close no change
17:22:21 <github-bot> Topic: [css-anchor-position-1] `position-area`: `self` keyword inconsistency
17:22:51 <fantasai> TabAtkins: We have both normal logical keywords and self-* logical keywords
17:23:03 <fantasai> TabAtkins: using either containing block writing mode or box's own writing mode
17:23:28 <fantasai> TabAtkins: Kiet pointed out that there's an inconsistency in the keywords about the placement of 'self'
17:23:46 <fantasai> TabAtkins: This was intentional on our part, because self- is not modifying the axis, but the direction
17:24:02 <fantasai> TabAtkins: x-self-start is combining physical direction and logical direction
17:24:22 <fantasai> TabAtkins: whereas self-inline-start is using self writingmode for both axis and direction
17:24:34 <fantasai> Kiet: Wanted to understand why it's the case. once I read Tab's comment, it makes sense
17:24:39 <fantasai> Kiet: So I think it's fine to keep it like that
17:24:58 <fantasai> Kiet: Another issue which is editorial is, in some places we use self-block and other places we use block-self
17:25:15 <fantasai> TabAtkins: Oh, indeed we do!
17:25:23 <fantasai> astearns: Is it just in anchorpos spec or others?
17:25:23 <florian_irc> florian_irc has joined #css
17:25:26 <fantasai> TabAtkins: just here
17:25:31 <fantasai> TabAtkins: but that is definitely an editorial mistake
17:25:39 <fantasai> fantasai: That raised the question of what was intended.
17:25:45 <fantasai> TabAtkins: Ohh, yeah.
17:26:06 <fantasai> TabAtkins: I think it still needs to be self-block-start, since it's interpreting the axis also per the self writing mode
17:26:11 <fantasai> TabAtkins: ...
17:26:17 <fantasai> TabAtkins: We did a copy-paste error probably
17:26:20 <ntim> I heard block as a verb :D
17:26:31 <ntim> block self start
17:26:33 <fantasai> astearns: Is that an argument to make the change?
17:26:38 <fantasai> TabAtkins: just an editing error
17:26:54 <fantasai> TabAtkins: more general argument that self-{block-start} is what we have here
17:27:13 <fantasai> TabAtkins: other way around could imply you're taking the axis (block) from the container and the direction (start) from the self
17:27:34 <fantasai> RESOLVED: x-self-start and self-block-start are correct, fix the spec
17:28:06 <github-bot> Topic: [css-anchor-position] Let more pseudo-elements have implicit anchor elements
17:28:38 <fantasai> TabAtkins: Anchor Positioning defines notion of an "implicit" anchor element, a relationship that other web platform features can define
17:28:53 <fantasai> TabAtkins: e.g. for <select> picker, the implicit anchor is the <select>
17:29:08 <fantasai> TabAtkins: We've also talked about making ::scroll-marker-group implicitly attached to the scroll container
17:29:16 <fantasai> TabAtkins: More general question is, do we want to apply this generally for pseudo-elements
17:29:29 <fantasai> TabAtkins: so for any tree-abiding pseudo, should it have an implicit anchor element of its originating element
17:29:32 <fantasai> TabAtkins: I think it's a reasonable idea
17:29:32 <ntim> q+
17:29:53 <astearns> ack ntim
17:29:57 <fantasai> TabAtkins: That way a ::before pseudo can be automatically anchored to its element
17:30:02 <fantasai> ntim: I could see this being useful for forms
17:30:08 <fantasai> ntim: If you use ::after or ::before or whatever
17:30:17 <fantasai> ntim: Can anchor tooltips easily without extra work
17:30:31 <fantasai> TabAtkins: for forms, there might enough structure sometimes to allow someoverridden
17:30:40 <fantasai> TabAtkins: e.g. might want something to attach to thumb of a slider
17:31:02 <fantasai> TabAtkins: I suggest we define that by default, imply the originating element
17:31:06 <kizu> +1
17:31:06 <fantasai> TabAtkins: but other specs can override
17:31:23 <fantasai> ntim: Is this web-compatible?
17:31:39 <fantasai> TabAtkins: Right now if you don't specify a position-anchor, all of your anchor references just wouldn't work
17:31:50 <fantasai> TabAtkins: so seems pretty unlikely that ppl are depending on broken behavior for this right now
17:31:56 <fantasai> TabAtkins: we'll see, but I think this is safe
17:31:59 <fantasai> <fantasai> +1
17:32:18 <fantasai> astearns: If it was out in the wild longer, might have more worries, but
17:32:28 <fantasai> fantasai: Not even been a year since shipping anchorpos
17:32:51 <fantasai> PROPOSED: All tree-abiding pseudo-elements use their originating element as their implicit anchor element, unless otherwise defined
17:33:19 <fantasai> fantasai: should it be all pseudo-elements?
17:33:21 <fantasai> TabAtkins: ok sure
17:33:23 <fantasai> TabAtkins: not observable
17:33:31 <fantasai> fantasai: but makes less of a maintenance problem if later it is
17:33:43 <fantasai> PROPOSED: All pseudo-elements use their originating element as their implicit anchor element, unless otherwise defined
17:33:55 <fantasai> astearns: Other questions/comments on proposed resolution?
17:33:58 <fantasai> astearns: objections?
17:34:02 <fantasai> RESOLVED: All pseudo-elements use their originating element as their implicit anchor element, unless otherwise defined
17:34:30 <github-bot> Topic: [css-anchor-position] Allow a positioned el's containing block to be the anchor
17:34:55 <fantasai> TabAtkins: When I was on a podcast with Miriam, question of why can't an anchor element anchor to its own containing block.
17:35:13 <fantasai> TabAtkins: Indeed it doesn't make a lot of sense. you could for example anchor it to another abspos that's anchored to the containing block.
17:35:19 <fantasai> TabAtkins: Podcast host filed issue for us.
17:35:50 <fantasai> TabAtkins: Ian pointed out that you don't need anchor positioning in order to position relative to containing block, that's how positioning currently works
17:36:15 <kizu> q+
17:36:16 <fantasai> TabAtkins: Doing so would potentially limit what you can do in some cases when you've got a container that's nested inside itself
17:36:24 <fantasai> fantasai: ????
17:36:30 <fantasai> TabAtkins: ian pointed out usability issues.
17:36:37 <fantasai> TabAtkins: So I suggest we close no change. You don't need anchorpos to do this.
17:36:51 <fantasai> TabAtkins: Someone asked if that limits what you can do with position-try
17:37:01 <fantasai> TabAtkins: but that doesn't require using anchor positioning
17:37:04 <astearns> ack kizu
17:37:20 <fantasai> kizu: I don't understand the argument about useful cases
17:37:40 <iank_> q+
17:37:40 <fantasai> kizu: My thinking generally was that, even though yes you can use just top: 0; to attach to your CB
17:37:48 <fantasai> kizu: didn't make sense that you can't use an anchor name
17:38:11 <fantasai> kizu: So you are limited by this, you cannot use anchor() to target it .
17:38:16 <fantasai> kizu: In my mind you should be able to do this
17:38:31 <fantasai> kizu: Case where inside you have element with the same name... I don't see a use case where I would want this
17:38:54 <fantasai> TabAtkins: The name of your CB is just, you spell it without the anchor() function at all. It can be addressed more simply. Means same as what you would get from anchor()
17:39:02 <fantasai> kizu: I've cases where I susbtitute dynamically the name with stuff
17:39:08 <fantasai> kizu: e.g. :hover { assign name }
17:39:13 <fantasai> kizu: Wrapper breaks this
17:39:26 <fantasai> TabAtkins: In that case, you can hack around it with a dummy abspos
17:39:38 <fantasai> kizu: I think I saw this in some other cases, like link to ??
17:39:50 <fantasai> kizu: People playing with anchor pos stumble on this limitation and wonder why they can't
17:39:56 <fantasai> kizu: It's common to run into it
17:40:02 <astearns> ack fantasai
17:40:16 <TabAtkins> fantasai: it also means you can't use position-area syntax or the combination fo that and anchor-center
17:40:22 <TabAtkins> fantasai: i think it's weird to exclude it
17:40:30 <TabAtkins> fantasai: i don't want to close this unless there's a good reason not to
17:40:35 <astearns> ack iank_
17:40:37 <fantasai> iank_: I have good reasons why you can't do this.
17:40:54 <fantasai> iank_: On the surface this seems reasonable.
17:41:15 <fantasai> iank_: Part of the issue is that devtooling for abspos should show what the actual CB of an element is. Currently they don't, which creates lots of confusion about scoping.
17:41:22 <fantasai> iank_: A simple thing that browsers can do is show the IMCB
17:41:29 <fantasai> iank_: so devtooling needs to improve substantially
17:41:32 <fantasai> iank_: In no particular order
17:41:46 <fantasai> iank_: The problem with using position-area with this is that the available size is always going to be zero
17:41:56 <fantasai> iank_: E.g. position-try-options doesn't work as you might expect, for example.
17:42:05 <fantasai> iank_: Part of this is also, when you are applying scroll adjustment or scroll filter
17:42:09 <fantasai> iank_: that currently happens within the CB
17:42:14 <kizu> q+
17:42:20 <fantasai> iank_: So it doens't actually work
17:42:33 <bkardell> s/doens't/doesn't
17:42:37 <TabAtkins> (whereas anchoring to a a dummy abspos with `inset:0` does "work" - it scroll like any other content
17:42:43 <fantasai> iank_: Next reason is, it's got poor interaction if CB itself is a scroller
17:42:59 <fantasai> iank_: In that particular case, you might say "I want this to be right of the CB", but it's within the scrollable area. Doesn't do what you want.
17:43:15 <fantasai> iank_: We had previously talked about mode switch so that your CB rectangle would be the scrollable area
17:43:27 <fantasai> iank_: If we do that, then your position wouldn't make sense
17:43:36 <fantasai> iank_: Couple more reasons...
17:43:55 <fantasai> iank_: The component example, anchoring something to a component
17:44:12 <fantasai> iank_: put in issue. Would break this, and require wrapper elements for what I think will be a common use case.
17:44:24 <fantasai> iank_: I could understand an argument for adding convenience functions to reference CB edges
17:44:33 <fantasai> iank_: but I don't think we should do this, will have bad side effects
17:44:35 <florian_irc> florian_irc has joined #css
17:44:55 <fantasai> TabAtkins: On that note, syntax of anchor() and position-area definitely has space for predefined keywords that whatever we want. We could put container as a keyword
17:45:19 <fantasai> iank_: Part of ask here is, you want to be able to select what CB is laying you out
17:45:45 <fantasai> iank_: You provide some CB name on a CB, and then your abspos will skip up to the CB that matches its name
17:45:58 <TabAtkins> agree fwiw. (but definitely a seaprate issue)
17:46:01 <fantasai> iank_: this would solve a lot of problems where people are applying 'position: relative'
17:46:01 <astearns> ack kizu
17:46:08 <fantasai> We already resolved to add that, didn't we?
17:46:15 <fantasai> kizu: ...
17:46:20 <fantasai> kizu: I think for ?? it might be useful.
17:46:22 <kizu> https://github.com/w3c/csswg-drafts/issues/2406
17:46:36 <fantasai> kizu: For scroller-based, I think a better fix could be is the ??? pseudo-element that oriol proposed
17:46:47 <fantasai> kizu: I also agree that maybe having something like a named CB could be nice
17:46:56 <TabAtkins> yeah, being able to distinguish inside-scroller from outside-scroller is pretty important to do eventually
17:47:03 <fantasai> kizu: but my main argument is just that, we have at least 3 cases where authors stumbled across this when using anchor positoining
17:47:52 <fantasai> astearns: I confess, I didn't follow the argument that said the available space will always be zero. But if that's the case, Roman, would the cases where ppl tripped over this, would it even be useful for them even if it worked?
17:47:54 <TabAtkins> (if the CB *is* the anchor, then position-area's grid is degenerate; the center cell fills the entire grid
17:47:58 <TabAtkins> )
17:48:11 <fantasai> kizu: The available space question is only relevant for cases where you use position-try
17:48:28 <fantasai> kizu: ...
17:48:41 <fantasai> kizu: Not sure if you could use 100% as a substitute for anchor-size()
17:48:51 <fantasai> iank_: percentages resolve against the CB
17:48:55 <fantasai> kizu: but you couldn't cross axis
17:49:10 <fantasai> kizu: With anchor-size() you can do calculations based on both axes
17:49:17 <fantasai> iank_: if that's desired, we can add syntax for it
17:49:30 <fantasai> TabAtkins: In that case will want different ones for inside / outside scrollers
17:49:36 <fantasai> kizu: But definitely need devtools to help authors
17:49:52 <fantasai> iank_: 100% agree. I've been advocating to any devtools ppl that will listen that abspos needs help from devtools
17:49:59 <fantasai> iank_: I'm happy to explain what would be useful
17:50:48 <fantasai> [discussion about what to do with this discussion and the various duplicats]
17:51:50 <fantasai> astearns: So proposed resolution is we intend to allow you to target the container with a keyword?
17:51:59 <fantasai> TabAtkins: but keep not referring by name
17:52:07 <fantasai> fantasai: How does that solve the problem?
17:52:13 <TabAtkins> like `anchor(container)`
17:52:20 <TabAtkins> like `anchor(container top)`
17:52:32 <iank_> `anchor-size(container width)`
17:52:42 <fantasai> fantasai: not sure I understand
17:52:51 <fantasai> astearns: All sorts of things go wrong, but only if you refer to it by name?
17:53:03 <fantasai> TabAtkins: Keyword fixes one thing that's wrong. other things are still just as wrong.
17:53:19 <fantasai> TabAtkins: but ability to refer to scrollable area vs ... need keywords to refer to these things
17:53:31 <fantasai> TabAtkins: Right now no way to refer to scrollabe area of an anchor
17:53:32 <iank_> `anchor(container-scroll bottom)
17:53:35 <fantasai> TabAtkins: but for container, might want either one
17:53:39 <iank_> `anchor(container-scroll bottom)`
17:53:44 <fantasai> astearns: Is it reasonable to ask for a named ocntainer?
17:53:51 <fantasai> TabAtkins: yes, I want to think about those two together
17:54:05 <TabAtkins> fantasai: so we already have a resolution to add position-container
17:54:13 <TabAtkins> fantasai: that lets you change CB explicitly
17:54:29 <TabAtkins> TabAtkins: it's a little funky
17:54:37 <TabAtkins> fantasai: it sounds like we need that too
17:54:59 <TabAtkins> fantasai: you probably want a function, not a keyword, so you can pass parameters, like in/out of scrollers
17:55:10 <TabAtkins> TabAtkins: i want to do that for named anchor too, so it should just be a bag of keywords
17:55:29 <TabAtkins> fantasai: so it sounds like we're not addressing this issue in the way it's request, but there are several features that will address the use-case which we want to add
17:55:47 <TabAtkins> fantasai: so closing this as no change for now, investigate keywords/fucntions for referencing the container, and edit in the work for position-container
17:56:08 <fantasai> s/the container/container scrollport vs scrollable area of container/
17:56:27 <fantasai> TabAtkins: We were talking about narrowing the CB. This is about expanding the CB. maybe address by same property.
17:56:40 <TabAtkins> (re: position-container)
17:56:44 <astearns> q?
17:56:44 <fantasai> ACTION: Tab and fantasai to reread these minutes and come up with a proposal
17:57:26 <fantasai> PROPOSED: Not allowing to refer to CB by anchor name
17:57:44 <fantasai> RESOLVED: Not allowing to refer to CB by anchor name. We'll address use cases by other means (see minutes for ideas).
17:58:22 <github-bot> Topic: [css-anchor-position] Default alignment in center track.
17:58:47 <TabAtkins> fantasai: i think we got the default alginment wrong for the center track
17:58:58 <TabAtkins> fantasai: you can be in the center track, or span two, or span all three
17:59:07 <TabAtkins> fantasai: with all three, you want anchor-center by default so you're connected to the anchor
17:59:22 <TabAtkins> fantasai: but when you're just in the center track, anchor-center tries to put you centered on the anchor even if you specify an inset
17:59:34 <TabAtkins> fantasai: if you are using an inset, tho, usually that means you're compensating for something
17:59:36 <TabAtkins> fantasai:
17:59:59 <TabAtkins> fantasai: so i think it makes more sense to actually center when we're in just the center track
18:00:29 <TabAtkins> fantasai: kizu posted an example where using center looks weird with the insets, but i think that's actually another bug in chrome, where anchor-center isn't paying attention to the insets properly
18:00:31 <kizu> q+
18:00:36 <fantasai> This makes a difference if the author applies asymmetric insets, e.g. given a 100px anchor, suppose there's a 10px inset on the right. Should the item be centered against the entire anchor, or against the inset area?
18:00:44 <astearns> ack kizu
18:00:46 <kizu> https://github.com/w3c/csswg-drafts/issues/12020
18:01:31 <TabAtkins> kizu: i think i prefer to account for inset-area more
18:01:47 <TabAtkins> kizu: if you're compensating for the dimensions of something, we should honor that
18:02:26 <TabAtkins> fantasai: [example time]
18:02:40 <TabAtkins> fantasai: anchor element, with two bits, a main and a extra bit on the right
18:02:50 <TabAtkins> fantasai: i want my abspos to be below the anchor
18:02:58 <TabAtkins> fantasai: i want to compensate for the right bit, i'm not centering on that
18:03:31 <TabAtkins> fantasai: so use some `right: 10px` to shrink my area to match excluding the right bit of the anchor
18:03:52 <TabAtkins> fantasai: so now my IMCB is a little smaller, centered on the "main" bit of the anchor that I want
18:03:57 <TabAtkins> fantasai: i think it should center in that remaining space
18:04:10 <TabAtkins> fantasai: current spec says to use anchor-center
18:04:18 <TabAtkins> fantasai: which'll ignore the insets, it's caring about the anchor itself not the IMCB
18:04:41 <TabAtkins> fantasai: so I think if the author is explicitly using an inset we should pay attention to that. default shoudl be center, not anchor-center
18:04:44 <bkardell> sounds reasonable
18:04:59 <fantasai> TabAtkins: In the overflow case, where abspos is larger than the IMCB.
18:05:07 <fantasai> TabAtkins: you're saying that it's a chrome bug?
18:05:43 <fantasai> fantasai: Yeah, it'll center against the anchor box, ignoring the insets
18:05:48 <fantasai> fantasai: and I think it should honor the insets
18:06:38 <TabAtkins> (in other words, it should decenter when it's wide enough to hit one edge of the IMCB)
18:06:52 <fantasai> TabAtkins: I don't think I have a strong opinion. Ian, do you have any compat concerns?
18:07:06 <fantasai> iank_: probably compat wise is fine, early enough
18:07:18 <fantasai> iank_: people are usually using top/bottom, not center
18:07:53 <fantasai> astearns: Roman, sounds ok?
18:07:59 <fantasai> TabAtkins: we're basically showing off his example
18:08:17 <fantasai> PROPOSED: Default alignment in the center track (single track), default alignment is 'center' not 'anchor-center'.
18:08:26 <fantasai> RESOLVED: Default alignment in the center track (single track), default alignment is 'center' not 'anchor-center'.
18:08:50 <github-bot> Topic: [css-position][css-anchor-position][css-align] anchor-center and overflowing the inset-modified containing block
18:09:20 <TabAtkins> fantasai: when you have an anchor-center alignment, and you're using insets, the insets reduce the space you have available to you.
18:09:29 <TabAtkins> fantasai: normally you'd align inside that reduced rectangle and overflow when you're too big
18:09:45 <TabAtkins> fantasai: we have rules now that say, by default, you can overflow your IMCB until you overflow your original CB
18:10:02 <TabAtkins> fantasai: anchor-center has the behavior that you can overflow the IMCB even when it's smaller than the IMCB
18:10:19 <TabAtkins> fantasai: [drawing example on the whiteboard]
18:10:38 <TabAtkins> fantasai: i have a big CB. The anchor is small and near the edge.
18:11:06 <TabAtkins> fantasai: on my abpos, I set `inset: 25px` (which is further than the anchor's distance from the CB edge)
18:11:19 <TabAtkins> fantasai: with left/right/center alignment, it's aligned inside the IMCB
18:11:37 <TabAtkins> fantasai: but anchor-center's desired alignment is centered right on the anchor. But the anchor is in the no-go zone (outside the IMCB)
18:11:54 <TabAtkins> fantasai: chrome positions the abspos outside the IMCB (even tho it could fit in there) becuase it asks to be on the anchor
18:12:07 <TabAtkins> fantasai: I'm arguing the author gave us insets, they're asking to stay inside this region. so we should honor that.
18:12:23 <TabAtkins> fantasai: anchor-center should be as close as it *can* be to the ideal position, but should stay in the IMCB until it actually overflows.
18:12:40 <TabAtkins> iank_: even if it's overflowing - that gets complex but we can push it to the side temporarily
18:13:15 <fantasai> TabAtkins: shift off of center but stay as close as you can is what happens if abspos is big enough to overflow CB, it will break center alignment to stay within CB but stay close enough
18:13:23 <fantasai> TabAtkins: our impl doens't do that for the IMCB, just the CB
18:13:42 <fantasai> TabAtkins: I don't recall if this was intentional or not
18:14:11 <fantasai> iank_: My initial recollection was that prioritizing anchoring, centering on the anchor, was desirable until you hit the original CB
18:14:17 <fantasai> iank_: so that's I interpreted the note in the spec
18:14:32 <fantasai> iank_: I'm fine with changing this, but I worry that we might get... people might be setting insets to reduce available space, for example
18:14:39 <fantasai> iank_: that's a side-effect that happens here
18:14:43 <fantasai> iank_: so I worry we might get some bug reports
18:14:48 <fantasai> iank_: "not actually on my anchor"
18:14:50 <fantasai> iank_: I'm not sure
18:15:08 <alisonmaher> alisonmaher has joined #css
18:15:16 <astearns> ack kizu
18:15:21 <fantasai> kizu: I would prefer to stay in the IMCB as long as possible
18:15:26 <fantasai> kizu: basically I agree with Elika
18:15:42 <fantasai> iank_: if we go with that, what happens when the anchored element is larger than the IMCB
18:15:52 <fantasai> iank_: It'll stay locked to one side if IMCB
18:16:02 <fantasai> TabAtkins: I think it should try to grow towards centering on the anchor
18:16:10 <fantasai> iank_: My concern with that is that it creates a jump
18:16:26 <fantasai> iank_: typically want to be continuous
18:16:29 <fantasai> TabAtkins, fantasai: no jump
18:16:41 <fantasai> TabAtkins: as it grows it says as close as it can be to anchor while in the IMCB
18:17:04 <fantasai> TabAtkins: as growing past IMCB, keeps growing in the direction that puts closer to anchor-center ideal
18:17:16 <fantasai> TabAtkins: If as wide as CB, fills it.
18:17:23 <fantasai> TabAtkins: if wider, grows in direction towards anchor
18:17:33 <fantasai> TabAtkins: once it hits the edge, then starts growing towards end side
18:17:37 <fantasai> [Tab draws this]
18:17:49 <fantasai> iank_: So potentially 3 direction changes that could occur
18:18:08 <fantasai> fantasai: I believe this is what I hav implemented in webkit
18:18:15 <fantasai> astearns: compat concerns?
18:18:17 <fantasai> iank_: Not particularly
18:18:23 <fantasai> iank_: I can try behind a flag and see what happens
18:18:29 <TabAtkins> (actually there's four potential direction changes. it might reach its ideal position before it touches the original CB edge
18:18:30 <TabAtkins> )
18:18:30 <fantasai> iank_: I think changing center thing is more
18:18:44 <fantasai> iank_: but the tests will be tricky because of the 3 direction changes that can occur
18:18:56 <fantasai> iank_: But I think the spec does need to be clarified
18:19:23 <fantasai> TabAtkins: Happy to get that clarified
18:20:03 <fantasai> PROPOSED: anchor-center alignment is constrained by IMCB, similar to other alignments
18:20:15 <fantasai> astearns: Further comments or questions?
18:20:19 <fantasai> astearns: Any objections?
18:20:52 <fantasai> RESOLVED: anchor-center alignment is constrained by IMCB, similar to other alignments
18:21:29 <fantasai> Topic: Group Hoto
18:21:33 <fantasai> s/Hoto/Photo/
18:21:38 <TabAtkins> Hoto
18:25:38 <RRSAgent> I have made the request to generate https://www.w3.org/2025/04/03-css-minutes.html fantasai
18:25:53 <astearns> 20-minute break
18:27:00 <ydaniv> ydaniv has joined #css
18:37:12 <ydaniv> ydaniv has joined #css
18:46:03 <florian_irc> florian_irc has joined #css
18:47:26 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10410
18:47:27 <github-bot> Topic: [css-anchor-position] Should scroll-margin/padding have an effect on position-visibility: anchors-visible?
18:47:27 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10410.
18:48:03 <TabAtkins> kizu: rn when we use position-vis:anchors-visible for an anchor in a container, it hides when the anchor scrolls outside the scrollport
18:48:14 <TabAtkins> kizu: i think it would be useful to account for scroll-margin and scroll-padding for this
18:48:30 <TabAtkins> kizu: usual case for these properties is you ahvea  sticky element or header floating over the scroller.
18:48:39 <TabAtkins> kizu: you probably want to treat the anchor as hidden when it's under that area
18:48:44 <TabAtkins> astearns: makes sense to me
18:48:46 <TabAtkins> TabAtkins: agreed
18:49:13 <TabAtkins> proposed: the 'anchors-visible' value takes 'scroll-padding' and 'scroll-margin' into account for determining if the anchor is visible
18:49:23 <TabAtkins> astearns: questions?
18:49:30 <TabAtkins> astearns: objections?
18:49:38 <TabAtkins> RESOLVED: the 'anchors-visible' value takes 'scroll-padding' and 'scroll-margin' into account for determining if the anchor is visible
18:50:11 <TabAtkins> kizu: i'll spend some more time on scroll-padding/margin when using nested scrollers, no interop.
18:50:23 <TabAtkins> astearns: yeah, assume WPT woudl only be testing single scrollers for simplicity
18:50:41 <TabAtkins> github-bot, take uphttps://github.com/w3c/csswg-drafts/issues/10950
18:50:41 <github-bot> TabAtkins, Sorry, I don't understand that command.  Try 'help'.
18:50:46 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10950
18:50:46 <github-bot> Topic: [css-anchor-position] Is `anchor()` fallback used when outside of inset properties?
18:50:46 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10950.
18:51:30 <TabAtkins> fantasai: so there's a question of where anchor() is "valid"
18:51:47 <TabAtkins> fantasai: there's parse validity, and there's "does it have a value, or does it use the fallback"
18:51:56 <kizu> q+
18:51:58 <TabAtkins> fantasai: I think what we mean is that it's only parse-valid in the inset properties
18:52:04 <TabAtkins> fantasai: but some of the text in the spec is confusing on that point
18:52:13 <TabAtkins> fantasai: so want to double check that's the intention
18:52:21 <fantasai> fantasai: and if so, we need to clarify spec
18:52:25 <fantasai> TabAtkins: yes that was the intention
18:52:26 <astearns> ack kizu
18:52:38 <TabAtkins> TabAtkins: they fundamentally don't make sense outside of the inset property
18:52:50 <TabAtkins> kizu: in my exploration i found some use-cases for using them outside of those
18:53:04 <TabAtkins> kizu: wonder if we could say that an explicit side like "left" is okay outside?
18:53:18 <TabAtkins> kizu: there are use-cases both for anchor() and anchor-size() where you might wnat to compute something intersting based on them
18:53:25 <TabAtkins> kizu: right now it's very limited. there are workarounds
18:53:43 <fantasai> TabAtkins: The reason they're not usable outside 'inset' properties is because they compute to the value that the 'inset' property needs to hit a paricular position
18:53:51 <fantasai> TabAtkins: so you need to know which inset property you're in (e.g. left vs top)
18:54:00 <fantasai> TabAtkins: and outside the inset properties, we have no context
18:54:02 <fantasai> s/top/right/
18:54:04 <iank_> `right: anchor(left)` != `left: anchor(left)`
18:54:07 <fantasai> TabAtkins: so if you could elaborate on use cases ..?
18:55:04 <TabAtkins> kizu: really i just wanted ot use the difference between two anchor positions
18:55:11 <TabAtkins> kizu: the acutal value doesn't amtter, just he difference
18:55:21 <fantasai> TabAtkins: What you described, diff between two position, is not contextual
18:55:23 <jensimmons> jensimmons has joined #css
18:55:26 <bkardell> s/mtter, just he difference/matter, just the difference
18:55:28 <jensimmons> present+
18:55:30 <fantasai> TabAtkins: if we wanted to do that, we could address it via new function
18:55:35 <fantasai> TabAtkins: anchor-distance() or something
18:55:42 <fantasai> TabAtkins: similar to anchor-size()
18:56:02 <fantasai> TabAtkins: So i think we should reject using anchor() outside insets, but could explore using another anchor function
18:56:10 <fantasai> fantasai: separate issue
18:56:16 <fantasai> kizu: anchor-size() ?
18:56:22 <fantasai> TabAtkins: anchor-size() is already usable more widely
18:56:24 <dshin> I think the main reason for rejecting general-use is https://github.com/w3c/csswg-drafts/issues/9827
18:56:36 <fantasai> iank_: it's allowed on the size properties, whereas anchor() isn't
18:56:58 <TabAtkins> anchor-size() is allowed in a sizing property, an inset property, or a margin property
18:57:03 <fantasai> kizu: Background size shadow on the ground would be very useful
18:57:07 <TabAtkins> (aka the properties you can adjust in position-try, iirc)
18:57:08 <fantasai> kizu: but not allowed currently
18:57:30 <fantasai> astearns: not expanding where it's valid, but could add a different function for those use cases
18:57:45 <fantasai> astearns: anyone who would object to resolving that the anchor() function is not applicable elsewhere than insets?
18:57:56 <fantasai> RESOLVED: anchor() functions are only valid in inset properties, clarify spec
18:58:06 <fantasai> astearns: original post here asks about anchor-size()
18:58:10 <fantasai> astearns: Is that something to discus snow
18:58:25 <fantasai> TabAtkins: Limitation on anchor-size() was due to some processing pipeline timing restrictions
18:58:33 <fantasai> TabAtkins: limited to properties allowed in position-try
18:58:39 <fantasai> TabAtkins: I should check that lists are synced
18:58:45 <fantasai> TabAtkins: I think that's the restriction
18:58:59 <fantasai> iank_: We want to avoid stuff that changes element in general
18:59:12 <fantasai> iank_: e.g. border isn't allowed, has substantial effects on e.g. tables
18:59:19 <fantasai> iank_: margins and size properteis are fine
18:59:27 <astearns> ack fantasai
18:59:51 <fantasai> PROPOSED: anchor-size() only allowed in properties allowed in @position-try. Clarify spec.
18:59:55 <fantasai> astearns: any objections?
19:00:02 <fantasai> RESOLVED: anchor-size() only allowed in properties allowed in @position-try. Clarify spec.
19:00:56 <astearns> github-bot, topic https://github.com/w3c/csswg-drafts/issues/11868
19:00:56 <github-bot> Topic: [css-anchor-position] Behavior of positioned element when anchor is in top layer
19:00:56 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11868.
19:01:27 <fantasai> TabAtkins: Asked what should happen to anchorpos when anchor is in top layer
19:01:31 <fantasai> TabAtkins: currently in implementations this fails
19:01:43 <fantasai> TabAtkins: if your anchorpos element is abspos or fixedpos, and anchor is promoted to top layer, can't find the anchor
19:02:06 <fantasai> TabAtkins: this is intentional and required behavior because things in top layer haven't been laid out during normal page layout, when a normal abspos or fixed pos is laid out
19:02:15 <iank_> q+
19:02:24 <fantasai> TabAtkins: In order to lay out abspos would need to be in same or higher top layer
19:02:30 <fantasai> TabAtkins: so I think this needs to be closed no change?
19:02:38 <fantasai> TabAtkins: not the best that you can't anchor random thing to top-layer dialog
19:02:40 <ydaniv> ydaniv has joined #css
19:02:52 <fantasai> TabAtkins: but we've had lots of discussions about stuff outside dialogs becoming inert
19:03:00 <fantasai> TabAtkins: and this would be asking to make such a thing not inert
19:03:06 <fantasai> TabAtkins: suggest to close no change
19:03:07 <astearns> ack iank_
19:03:27 <fantasai> iank_: falls out of resolution that top layer elements are processed after everything else
19:03:40 <fantasai> iank_: there's one caveat, if you have fixedpos in top layer thing, laid out after that thing
19:03:48 <fantasai> iank_: but that's subtle
19:03:57 <fantasai> iank_: Most people want to anchor things in top layer to something on the page, can't do other way around
19:04:05 <astearns> ack fantasai
19:04:14 <fantasai> "Would it make sense to automatically elevate positioned elements (and pseudo-elements) into the top layer when their anchors are also in the top layer?"
19:04:24 <TabAtkins> fantasai: q in the issue is if it makes sense to aiutomatically elevate positioned lemeents to the top layer when their anchors are in the top layer
19:04:49 <fantasai> TabAtkins: An element could have any number of anchors.
19:04:56 <kizu> q+
19:04:57 <fantasai> TabAtkins: so would have to be "if any" then goes to top layer
19:05:03 <fantasai> TabAtkins: that's fiddly
19:05:05 <iank_> q+
19:05:10 <fantasai> TabAtkins: but also, things in top layer should be inert
19:05:23 <fantasai> TabAtkins: if you want something to work in a modal dialog, then need to put it in the modal dialog
19:05:35 <fantasai> TabAtkins: don't want to circumvent the top layer inert modal paradigm
19:05:59 <astearns> ack kizu
19:06:10 <fantasai> kizu: I also wanted to do something like this, and I wonder if only elevating it for the default anchor
19:06:14 <fantasai> kizu: this is only one element
19:06:23 <fantasai> kizu: and then we move it to be rendered after the corresponding anchor element
19:06:37 <fantasai> kizu: But if it's complicated and don't want to handle inertness here, understandable
19:06:43 <fantasai> kizu: but I was playing with effects I wanted to do
19:06:56 <fantasai> kizu: One use case for this, when you have something like a focus ring which you want to use an element over another element
19:07:06 <fantasai> kizu: it works well for regular elements, but as soon as you have popover or dialog you can't do this
19:07:15 <fantasai> kizu: and you have to use a separate element inside every dialog etc.
19:07:32 <fantasai> TabAtkins: that's exactly the case I'm concerned about doing automatically
19:07:48 <fantasai> TabAtkins: that should be handled as part of popover stuff. Some way to elevate things together with the modal dialog.
19:08:10 <fantasai> TabAtkins: I think this is an HTML feature. Then we can adopt. But we shouldn't be working around existing top layer stuff automatically.
19:08:14 <astearns> ack iank_
19:08:37 <fantasai> kizu: More or less impossible to implement
19:08:40 <fantasai> s/kizu/iank/
19:08:56 <fantasai> iank_: Don't know when laying out the abspos if there is something in the top layer
19:08:59 <fantasai> iank_: or something in subtree
19:09:07 <fantasai> iank_: ...
19:09:12 <fantasai> iank_: gets very complex very quickly
19:09:37 <fantasai> astearns: proposed to close issue no change for fear of messing with top level stuff
19:09:43 <fantasai> TabAtkins: and if this is desired, pursue in HTMLWG
19:09:50 <bkardell> q+
19:09:59 <astearns> ack bkardell
19:10:09 <fantasai> bkardell: I think there's relationship with some of the things discussed around interactivity property and CSS inert
19:10:20 <fantasai> bkardell: but I agree it should be discussed in HTML
19:10:34 <fantasai> TabAtkins: exactly the issues I'm worried about us stepping into with this
19:11:09 <fantasai> RESOLVED: Close no change. Use cases should be addressed through HTML
19:11:38 <github-bot> Topic: [css-anchor-position] Add containing block rules to acceptable elements in top layer
19:12:16 <fantasai> TabAtkins: Rules for determing whether something is an acceptable anchor element, when talking about top layer
19:12:35 <fantasai> TabAtkins: if your positoined element is in top layer and anchor is in a previous top layer, it's acceptable
19:12:54 <fantasai> TabAtkins: Reason for this in spec is, our only requirement for being reasonable anchor is that it is fully sized and positioned before the abspos
19:13:06 <fantasai> TabAtkins: conditions are there to set up that situation
19:13:20 <fantasai> TabAtkins: top layers are defined to fully lay out atomically, so later top layer can depend on earlier top layers being fully laid out
19:13:37 <fantasai> TabAtkins: I'm not certain if OP is confused about conditions, or if pointing out something I'm missing
19:13:55 <fantasai> TabAtkins: pointing out case of positioned element is in a relpos dialog that is opened into top layer
19:14:08 <fantasai> TabAtkins: so dialog is in top layer, and anchor is in preceding top layer
19:14:25 <fantasai> TabAtkins: in the normal page, something outside your CB is never acceptable  because not guaranteed to be laid out yet
19:14:29 <fantasai> TabAtkins: so limited there
19:14:32 <fantasai> TabAtkins: but that's because all in the same page
19:14:54 <fantasai> TabAtkins: but in this case, because separate top layers, no dependency because previous top layer is already laid out
19:15:01 <fantasai> TabAtkins: I think this is close no change, unless I'm missing something
19:15:03 <astearns> q?
19:15:33 <fantasai> astearns: propose no change, anchors in previous top layers is intentionally allowed
19:15:47 <fantasai> astearns: if we're wrong, OP will likely let us know?
19:16:20 <fantasai> kizu: No objection, but could we qualify this in the spec
19:16:27 <fantasai> kizu: when we talk about restrictions, if we talk about why we do this restriction
19:16:37 <fantasai> kizu: that way when you read it you understand
19:16:46 <fantasai> kizu: why it's different in this case
19:16:56 <fantasai> TabAtkins: I do have a note preceding the algorithm explaining its intent
19:17:20 <fantasai> RESOLVED: No change, anchors in previous top layers is intentionally allowed.
19:17:43 <github-bot> Topic: [css-anchor-position-?] SVG element or coordinate as anchor
19:18:01 <fantasai> TabAtkins: Request is to allow HTML elements to anchor to SVG sub-elements
19:18:12 <fantasai> TabAtkins: a lot of obvious use cases for this, e.g. labels in a chart
19:18:24 <fantasai> TabAtkins: use cass seem reasonable
19:18:35 <fantasai> TabAtkins: problem is, this breaks some assumptions that browsers currently make about SVG
19:18:47 <fantasai> TabAtkins: layout engine considers SVG a replaced element. Doesn't know what happens inside.
19:18:53 <fantasai> TabAtkins: so info is not surfaced to layout tree
19:19:13 <fantasai> TabAtkins: additoinal problem is, SVG is mostly laid out with transforms, not with positioning
19:19:23 <fantasai> TabAtkins: and transforms are still not taken into account with anchorpos (intentionally)
19:19:31 <fantasai> TabAtkins: we have an open issue ot think about what cases could be made to work
19:19:43 <fantasai> TabAtkins: but in general, it means SVG elements can't tell us their position
19:19:53 <bkardell> q+
19:19:54 <fantasai> TabAtkins: question about what rectangle to use, we can just use bounding box
19:20:08 <iank_> q+
19:20:10 <fantasai> TabAtkins: but other two questions make this a hard request to satisfy, even though it has good use cases
19:20:19 <fantasai> TabAtkins: I think that means we close no change for now, but leave open possibility in the future
19:20:21 <astearns> ack bkardell
19:20:35 <fantasai> bkardell: Any time someone says SVG I'm contractually obligated to say "but what about MathML?"
19:20:40 <fantasai> iank_: It should all work today
19:20:44 <fantasai> iank_: You should test it :)
19:20:53 <fantasai> TabAtkins: I think it is a full citizen of the CSS nation
19:21:18 <fantasai> ChrisL: It doesn't depend on transforms. Has an in-flow layout model.
19:21:29 <astearns> ack iank_
19:21:39 <fantasai> iank_: Also a bunch of visual effects that typically apply to SVGs
19:21:46 <fantasai> iank_: e.g. displacement filters
19:21:50 <fantasai> iank_: It's a whole can of worms
19:22:08 <TabAtkins> fantasai: i think at the point people are using filters, it's okay that the position isn't correct
19:22:17 <TabAtkins> fantasai: but transforms are integral to svg layout, we'll have to do something about those
19:22:29 <TabAtkins> TabAtkins: i want to do something about trasnforms anyway
19:22:36 <TabAtkins> fantasai: so it looks like resoliution is "defer to next level"
19:22:40 <TabAtkins> TabAtkins: yup
19:22:40 <fantasai> astearns: Proposed resolution to defer
19:22:48 <fantasai> RESOLVED: Defer to next level
19:23:00 <fantasai> astearns: though this may also be deferred from that level
19:23:05 <fantasai> TabAtkins: potentially, yeah
19:23:31 <github-bot> Topic: [css-anchor-position] could anchor()'s side argument be optional?
19:24:20 <fantasai> kizu: Right now you have to say `inside` or `outside` always. Maybe we want to just default to `inside`.
19:24:33 <fantasai> kizu: one common case is doing something like `anchor(inside --foo 0)`
19:24:45 <fantasai> kizu: Just a very small thing
19:24:52 <iank_> q+
19:25:05 <fantasai> TabAtkins: no strong opinion. Agree inside is the best default
19:25:13 <astearns> ack iank_
19:25:24 <fantasai> iank_: I would be hesitant to doing this. For anchor-size() 99% of the time you wnat same axis
19:25:34 <fantasai> iank_: but here, I don't know what the percentage breakdown but it's not anything like that
19:25:42 <fantasai> iank_: it'll be split evenly
19:25:46 <fantasai> iank_: so for that reason I don't think we should omit this
19:25:54 <TabAtkins> yeah actually i retract my "best default:
19:25:58 <fantasai> kizu: It will be split if you mention just one side
19:26:05 <TabAtkins> `inset` it's the best default, `left` outside is the best default
19:26:06 <fantasai> kizu: but if you use the shorthands, only 'inside' make sense
19:26:51 <TabAtkins> fantasai: i think for shorthands, inside is 100% the right default
19:27:00 <TabAtkins> fantasai: for individual sides, it is more often that you'd use outside
19:27:11 <TabAtkins> fantasai: but yeah it's probabyl on the 60/40 side
19:27:39 <fantasai> TabAtkins: I'm weakly against because the weakness of the defaulting argument here. Wouldn't oppose if strong arguments, but prefer to skip
19:27:49 <fantasai> kizu: I think this was also before position-area, which makes this a bit easier
19:27:56 <fantasai> kizu: So not strong issue for me
19:28:05 <TabAtkins> yeah, just `position-area:left` means you rarely need to mention anchor() anyway
19:28:06 <fantasai> astearns: so propose to close no chnage
19:28:15 <fantasai> astearns: objections?
19:28:18 <fantasai> RESOLVED: Close no change
19:28:30 <github-bot> Topic: [css-anchor-position-1] Computed value of `visibility` when a box is strongly hidden
19:28:43 <fantasai> TabAtkins: Another issue from Kiet
19:28:55 <fantasai> TabAtkins: We use concept of 'strongly hidden'.
19:29:12 <fantasai> TabAtkins: Forces effect of visiblity:hidden on it and descendants
19:29:17 <fantasai> TabAtkins: question is, does this affect the computed value?
19:29:25 <fantasai> TabAtkins: I don't have an opinion on this.
19:29:27 <iank_> q+
19:29:49 <fantasai> TabAtkins: this concept is used for hiding the abspos when its anchor is e.g. scrolled offscreen
19:29:55 <astearns> ack iank_
19:30:12 <fantasai> iank_: I think the answer is no
19:30:21 <fantasai> iank_: There are lots of places where we hide things, e.g. empty-cells
19:30:32 <fantasai> iank_: engines need a way to suppress paint and hit testing outside of visibility:hidden
19:30:50 <fantasai> iank_: which is separate from 'visibility'
19:31:15 <TabAtkins> fantasai: i also have no real opinion, id' go with whatever's easiest to implement
19:31:17 <TabAtkins> TabAtkins: agreed
19:31:33 <fantasai> TabAtkins: propose to close no change, no change to computed value
19:32:41 <ydaniv> ydaniv has joined #css
19:32:50 <fantasai> RESOLVED: no change to computed value of 'visibility'
19:32:57 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10913
19:32:57 <github-bot> Topic: [scroll-snap-2] Rename `scroll-start-target` to `scroll-target`?
19:32:57 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10913.
19:33:37 <TabAtkins> fantasai: we ahd a property named scroll-start-target, i complained we use "start" in too many other ways
19:33:44 <TabAtkins> fantasai: so my suggestion was to rename to scroll-target
19:33:58 <TabAtkins> fantasai: draft is currently using scroll-initial-target
19:34:17 <TabAtkins> fantasai: so i think that resolves the concern, tho i still think "initial" might not be needed
19:34:22 <fantasai> https://drafts.csswg.org/css-scroll-snap-2/#scroll-initial-target
19:34:38 <fantasai> TabAtkins: I do like the 'initial' in there because it's a temporal effect on the scroller
19:34:46 <fantasai> TabAtkins: not sure it suggests very well that you start the scroller there
19:35:00 <TabAtkins> (it doesnt' suggest if you don't have it there)
19:35:11 <fantasai> fantasai: How does it interact with fragids etc.? Do those win?
19:35:20 <fantasai> TabAtkins: fragID causes scroll to happen, and that would override these
19:35:25 <fantasai> TabAtkins: this is just first layout
19:35:26 <fantasai> faceless: ok
19:35:30 <fantasai> s/faceless/fantasai/
19:35:42 <fantasai> RESOLVED: Close as fixed; dup of earlier issue
19:35:49 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10907
19:35:49 <github-bot> Topic: [css-backgrounds-4][css-borders-4] Should initial value of border-color be sensitive to border-area?
19:35:49 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10907.
19:36:03 <flackr> flackr has joined #css
19:36:25 <TabAtkins> fantasai: we added 'background-clip:border-area' to clip out the backgroudn and just show what's under the element
19:36:36 <TabAtkins> fantasai: in almost all cases, you want the border color to be transparent
19:36:53 <TabAtkins> fantasai: and you want it set possibly conditionally based on whether border-area is supported or not
19:37:14 <oriol> q+
19:37:27 <TabAtkins> fantasai: currently the initial value is currentcolor; my suggestion was change it to 'auto' and ahve it compute to currentcolor or transparent based on 'background-clip:border-area', so the author doesn't need to worry about it
19:37:38 <TabAtkins> jensimmons: this came up when i was making a lot of demos
19:37:44 <TabAtkins> jensimmons: it was very easy to forget to change the color
19:38:12 <TabAtkins> jensimmons: so there's a question of if css should just be simple and consistent. but it was a consistent stumbling block to remember to change it every time.
19:38:20 <TabAtkins> jensimmons: so i think this would really help devs use this feature
19:38:31 <astearns> ack oriol
19:38:39 <fantasai> jensimmons: would make it more streamlined and easy to use
19:38:47 <TabAtkins> oriol: I'd prefer not to. it seems unexpected.
19:38:56 <stepheckles> stepheckles has joined #css
19:38:56 <TabAtkins> oriol: also, background-clip has multiple values, a list of backgrounds
19:39:00 <jensimmons> Developer experience wins over theoretical purity.
19:39:11 <TabAtkins> oriol: not clear if some layers have the clip and others clip differently, if it should happen
19:39:20 <florian_irc> q+
19:39:24 <astearns> ack fantasai
19:39:24 <Zakim> fantasai, you wanted to reply to that
19:39:25 <TabAtkins> oriol: i don't think it's a big problem for authors, especially if they can just specify #0000
19:39:39 <TabAtkins> fantasai: for multiple layers, i think it would be if any of the layers have border-area clip
19:39:52 <TabAtkins> fantasai: it demonstrates the author *is* thinking about the border area
19:40:05 <astearns> ack florian_irc
19:40:08 <TabAtkins> fantasai: if they *do* want a specific border, they almost always set the color explicitly anyway
19:40:26 <TabAtkins> florian_irc: reason it's confusing when you don't have it?
19:40:31 <TabAtkins> jensimmons: if the border has a color, it's probably opaque
19:40:45 <TabAtkins> jensimmons: if you use 'border-area' you're putting an image there, you expect it to show
19:40:51 <TabAtkins> jensimmons: but the border paints over it
19:41:03 <TabAtkins> jensimmons: a lot of authors might not expect that the border always exists and always has a color
19:41:26 <TabAtkins> jensimmons: so as soon as you use this property, you set a 10px border and set a background-image with border-area clip
19:41:43 <TabAtkins> jensimmons: but it doesn't work, it's all black or something
19:41:58 <florian_irc> I'm convinced
19:42:01 <lea> same
19:42:02 <jensimmons> jensimmons has joined #css
19:42:05 <TabAtkins> jensimmons: i get the theoretical purity argument, but i also believe in teh priority of constituencies
19:42:49 <fantasai> TabAtkins: when you're setting these up, Jen, if I'm correct about this the initial border style is 'none'.
19:42:56 <fantasai> TabAtkins: you already have to set width and style
19:43:16 <fantasai> TabAtkins: having to say 'border: solid 10px #000' adding the color doesn't seem that big of a deal
19:43:16 <dbaron> "5px solid transparent" works too
19:43:23 <lea> q?
19:43:26 <lea> q+
19:43:39 <fantasai> TabAtkins: If you could get the desired result with just the width... but you already have to say the style
19:43:46 <jensimmons> Demo of this for reference: https://codepen.io/jensimmons/pen/rNXZvQG
19:43:49 <fantasai> jensimmons: Different people write differently
19:43:49 <astearns> ack lea
19:43:55 <fantasai> lea: There's two core use cases here.
19:44:03 <fantasai> lea: one is adding a border that's an image to something that doesn't have a border
19:44:12 <fantasai> lea: second is when you change styling of something that already has a border
19:44:23 <fantasai> lea: in the first case, yeah, no big deal to add transparent
19:44:32 <fantasai> lea: but if you're restyling something that already has a border
19:44:37 <fantasai> lea: the only thing you want to change is border color
19:44:47 <fantasai> lea: although... this would help anything there because about initial color
19:44:56 <fantasai> TabAtkins: if you're setting border, already setting color
19:45:05 <astearns> ack dbaron
19:45:19 <fantasai> dbaron: I was just thinking what would we do if we did want to do this
19:45:31 <fantasai> dbaron: We'd need to introduce a new keyword for border-color that computes to currentColor sometimes and transparent sometimes
19:45:36 <fantasai> dbaron: and make that the initial value
19:45:45 <lea> q+
19:45:49 <fantasai> dbaron: and decide how to reflect in getComputedStyle
19:46:01 <fantasai> fantasai: colors return as resolved color
19:46:19 <fantasai> dbaron: but then specified style, might create values that aren't expected in the OM
19:46:27 <fantasai> dbaron: Not insurmountable, but if we want to do that there are some risks
19:46:29 <lea> q-
19:46:32 <fantasai> dbaron: so that's another thing against it
19:46:43 <lea> q+
19:46:56 <TabAtkins> The other argument against that was raised in the thread is we don't default text color to 'transparent' when using 'background-clip:text' today, so there's another argument for consistency there.
19:46:57 <fantasai> ntim: I don't think that's a significant risk, because if you're using background-clip: border-area, you can likely deal with the border-color being a new keyword
19:47:14 <fantasai> dbaron: that keyword would be the initial value, so would show up in OM
19:47:23 <fantasai> astearns: For the specified value which is much less accessed than the computed value
19:47:25 <TabAtkins> (Tho it was pointed out that we really *couldn't* do that, since 'color' affects more than just text.)
19:47:27 <lea> q-
19:47:27 <fantasai> dbaron: yes, but still exists
19:48:10 <fantasai> lea: I see the appeal of being able to say `border: 2px solid; background-clip: border-area` it just works
19:48:17 <kizu> q+
19:48:23 <fantasai> lea: though in that case `solid` is a bit redundant, people almost never want other styles
19:48:32 <TabAtkins> lol, yeah, the 'border-*' initial values are kinda badly designed
19:48:34 <TabAtkins> we've run into this beforee
19:48:38 <dbaron> "border: 5px" is the same as "border: 5px none" !
19:48:41 <fantasai> lea: but the complexity dbaron mentioned seems not worth the small improvement in UX
19:48:52 <astearns> ack kizu
19:48:57 <fantasai> kizu: I also wanted to add a bad idea.
19:49:08 <fantasai> kizu: What if border had a value that enables background-clip?
19:49:45 <fantasai> lea: what if border-shorthand could turn on background-clip: border-area. But not a good idea.
19:49:54 <fantasai> lea: border shorthand shouldn't set background properties
19:50:05 <ydaniv> ydaniv has joined #css
19:50:06 <fantasai> lea: and also you usually want to set multiple things, not just image
19:50:25 <fantasai> ntim: Could have border-style: auto; and auto would be invisible border
19:50:39 <fantasai> TabAtkins: having border-style have a new value, since you have to set it anyway
19:51:23 <fantasai> TabAtkins: border-style: auto; if any background colors are border-area, set color to transparent, otherwise set to solid
19:51:43 <fantasai> florian_irc: but you can't make that the initial value
19:51:51 <fantasai> florian_irc: if you could, might be interesting
19:52:01 <kizu> `border: 5px auto`
19:52:08 <Linux_Kerio> Linux_Kerio has joined #css
19:52:10 <fantasai> TabAtkins: Interesting because you have to set the border-style. Jen is trying to avoid setting border-width, border-style, *and* border-color
19:52:29 <oriol> +1 to floarian
19:52:30 <fantasai> florian_irc: yes, but you have to *remember* to set this value -- and in that case, you might as well remember to set it to transparent
19:52:35 <astearns> +1 to florian_irc
19:52:47 <fantasai> florian_irc: The problem she wants to solve ins't typing transparent, it's having to remember to set transparent
19:53:56 <fantasai> astearns: so seems too risky to do, even though maybe nice
19:54:23 <fantasai> ntim: not sure it's too late, e.g. we changed initial value of border-color
19:54:45 <fantasai> dbaron: yes, but from magic that's the same as currentColor to the actual currentColor keyword
19:54:50 <fantasai> kizu: Useful for ??
19:55:15 <fantasai> kizu: E.g. using transparent border when making a border that later becomes visible
19:55:24 <fantasai> kizu: just having that in the shorthand would be useful
19:56:11 <TabAtkins> TabAtkins: so not a conditional transparency, jsut a value that gives the border geometry but always paints transparent
19:56:32 <fantasai> astearns: shall we resolve no change?
19:56:35 <TabAtkins> fantasai: but i think that doesn't help us, when you do want to paint it you'll have to change the color *and* the style
19:56:39 <fantasai> jensimmons: seems we have no choice
19:56:44 <fantasai> astearns: objections?
19:56:48 <fantasai> RESOLVED: Close no change.
19:57:16 <github-bot> Topic: [css-rhythm-1] Define interaction of block-step-align and align-content
19:57:44 <flackr> present+
19:58:17 <TabAtkins> fantasai: block-step-align's initial value is "auto", which looks at align-self when you're inserting margins to adjust the step
19:58:21 <TabAtkins> fantasai: that makes sense
19:58:22 <ydaniv> present+
19:58:37 <TabAtkins> fantasai: but when you're inserting inside the box (padding or content) we don't look at the alignment properties
19:58:44 <TabAtkins> fantasai: but it probably makes sense to lookk at the align content property
19:58:52 <TabAtkins> fantasai: and might even want to let it win over block-step-align
19:59:21 <fantasai> TabAtkins: So if we're doing block-step by inserting into padding/content, we defer to align-content as long as it's no-normal
19:59:37 <fantasai> TabAtkins: seems plausible
19:59:49 <fantasai> TabAtkins: makes align-content have an effect where doesn't currently, like blocks
19:59:54 <fantasai> fantasai: it does affect blocks
20:00:25 <TabAtkins> fantasai: so proposed resoliution is if block-step-insert is padding-box or content-box, block-step-align:auto defaults to following align-content when it's not normal
20:00:35 <TabAtkins> astearns: what happens when it is normal?
20:01:00 <TabAtkins> fantasai: separate resolution
20:01:06 <TabAtkins> iank_: remind me how this works?
20:01:12 <TabAtkins> iank_: non-normal align-content estalbishes an IFC
20:01:16 <TabAtkins> iank_: that's okay for this?
20:01:24 <TabAtkins> fantasai: I think it's okay. doesn't make the feature more complicated
20:01:46 <dbaron> s/an IFC/an independent formatting context/
20:01:48 <TabAtkins> astearns: so we ahve the first proposed resolution
20:01:55 <bkardell> s/ahve/have
20:02:02 <dbaron> (IFC could also mean "inline formatting context", but Ian said "independent")
20:02:03 <TabAtkins> astearns: objections?
20:02:16 <TabAtkins> RESOLVED: if block-step-insert is padding-box or content-box, block-step-align:auto defaults to following align-content when it's not normal
20:02:36 <TabAtkins> fantasai: so followup, should alingment property win over block-step align if they're both set to an explicit value
20:02:53 <TabAtkins> fantasai: so if you have block-step-align:start and align-content:end...
20:02:58 <TabAtkins> fantasai: seems weird
20:03:01 <TabAtkins> fantasai: can't imagine why you'd want that
20:03:24 <TabAtkins> fantasai: if you're setting the alingment property, and shifting the content by a potnetially large amount, ahving block-step-align move you back away from that desired alignment seems weird
20:03:38 <TabAtkins> astearns: i believe that block-step-align is applied in a more general context, and aling-content will be more specific
20:03:44 <TabAtkins> astearns: so i do agree align-content should win
20:04:16 <fantasai> TabAtkins: Yeah, I think I agree with astearns that align-content would b emore specific
20:04:41 <TabAtkins> jensimmons: in my head, i wonder if it's that alignment should apply to the items inside the box that would be on the side of the box if block-step wasn't turned on, and block-step applies to the space that's put there by block-step
20:04:57 <TabAtkins> jensimmons: imagine a website with components, one with block-step applied and another without lbock-step
20:05:26 <TabAtkins> jensimmons: people can use the block-step for vertical rhythm regardless fo the content alignment, don't think it's contradictory
20:06:05 <astearns> q?
20:06:06 <TabAtkins> fantasai: thing is, if you're alinging contents to the end, and block-step says you need to be slightly bigger, you don't want to push it further away from the end
20:06:47 <TabAtkins> florian_irc: i think this could be another situation similar to the border color, author could be confused why they're alinging something but it's clearly not visually aligned
20:06:55 <TabAtkins> florian_irc: so i agree that align should win there
20:07:24 <TabAtkins> astearns: i don't see it as one or the other, you ahve both things applying to the element, block-step produces a size, but the alignment *within* that size should be controled by the alingment property
20:07:43 <TabAtkins> fantasai: [example on whiteboard]
20:08:09 <TabAtkins> fantasai: so we have a big box. it's larger than its content, and has align-content:end
20:08:35 <TabAtkins> fantasai: so the contents are flush with the end of the box
20:08:41 <TabAtkins> fantasai: then block-step comes in
20:09:23 <TabAtkins> fantasai: everything has 'block-step-align: center'. If this applies naively, it puts some extra space between the box and its contents, so the contents are no longer flush
20:09:26 <TabAtkins> fantasai: confusing gap there
20:09:37 <TabAtkins> jensimmons: okay, this does look liek a case where alignment should win
20:09:40 <TabAtkins> fantasai: right
20:09:55 <TabAtkins> fantasai: different case
20:10:54 <TabAtkins> fantasai: say you ahve a flexbox with vertical rhythm
20:11:36 <TabAtkins> [confused about example]
20:12:13 <TabAtkins> fantasai: if you're inserting block-step into margin, shoudl be consistent with align-self if specified, again so if the element *wants* to be flush with an edge, we stay consistent with that when inserting block-step space
20:12:28 <TabAtkins> fantasai: so i htink alignment should probably always win when it's specified as non-normal
20:12:41 <TabAtkins> fantasai: just can't imagine you'd ever want it to have effects opposite that of the alignment
20:12:55 <jensimmons> jensimmons has joined #css
20:12:58 <TabAtkins> florian_irc: I'm convinced in the first case. I'm confused about the second case.
20:13:01 <TabAtkins> jensimmons: agreed
20:13:13 <TabAtkins> jensimmons: it does feel liek block-step should win when it's on the outside
20:13:39 <TabAtkins> fantasai: if you're self-aligning an item, say in a grid, and block-step is trying to align it, you probably want to match that
20:14:21 <TabAtkins> proposed: non-normal values of align-content/self win over block-step-align (depending on whether block-step-insert is putting the space inside or outside the element)
20:14:53 <fantasai> TabAtkins: This wouldn't give align-self behavior in cases where it doesn't currently apply
20:15:02 <fantasai> fantasai: right
20:15:04 <TabAtkins> astearns: objections?
20:15:06 <fantasai> (we should make that clear)
20:15:15 <TabAtkins> RESOLVED: non-normal values of align-content/self win over block-step-align (depending on whether block-step-insert is putting the space inside or outside the element)
20:15:32 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/4344
20:15:32 <github-bot> Topic: Support Cross-Origin iframe use case
20:15:32 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/4344.
20:16:19 <TabAtkins> flackr: with view timelines, you can create an effect when the subject is visible within its nearest ancestor scroller
20:16:49 <TabAtkins> flackr: but in some of the use-cases with our partners, they wanted to do something like intersection observer, where it was looking at its frames' visibility in the outer frame. view-timeline doesn't let you do that
20:17:05 <TabAtkins> flackr: so should it? a view-timeline based on your frame root, giving you the intersection with your embedding frame
20:17:11 <fantasai> TabAtkins: simple example, you haven iframe
20:17:24 <fantasai> TabAtkins: It wants to run a view-timeline-animation based on the iframe's position in the outer page
20:17:29 <fantasai> TabAtkins: relative to the scroller its in
20:17:46 <TabAtkins> fantasai: so basically passing the timeline from outside the iframe into the iframe
20:17:56 <TabAtkins> flackr: this can be cross-origin, so it's not striclty passing "objects"
20:18:08 <TabAtkins> flackr: you are allowed to know when you're intersecting the viewport, via IntersectionObserve33r
20:18:23 <TabAtkins> flackr: maybe we don't want to allow it since it does technically expose more info than IO, at least a single IO
20:18:36 <TabAtkins> flackr: but you can get this information to some granularity by creating several IOs with different offsets
20:18:42 <TabAtkins> fantasai: i can't comment from a security perspective
20:19:03 <TabAtkins> fantasai: from how to do it, maybe say view timelines on the root element are about the root's position in the outer scroller
20:19:07 <TabAtkins> flackr: yeah, that's my thought
20:19:19 <TabAtkins> flackr: if your subject is the root you're observing its psoiition in an outer frame's scroller
20:19:27 <TabAtkins> flackr: but we'd still ahve to figure out if it's okay from a security perspective
20:19:36 <TabAtkins> astearns: so rob's proposal in the issue is to punt for now
20:19:48 <TabAtkins> fantasai: if we think we want to do this, we might want to define that a view-timeline on the root has no effect
20:20:07 <TabAtkins> fantasai: bc in theory you could define a root element with lots of margins and padding and observe its transit across the viewport
20:20:09 <TabAtkins> fantasai: suspect not used
20:20:33 <TabAtkins> flackr: yeah, if you have a root subject and "contain", it's using the root's scroll timeline basically
20:20:39 <TabAtkins> (i think i got that right)
20:20:52 <TabAtkins> flackr: but i'd be supportive of reserving this, today you'd get a timeline that's always inactive
20:21:22 <TabAtkins> TabAtkins: so do the reservation now, punt the feature to after security review
20:21:36 <TabAtkins> fantasai: proposed: view timelines defined on the root element are always inactive
20:21:41 <TabAtkins> flackr: whose subject is the root element
20:21:49 <TabAtkins> astearns: objections?
20:22:05 <TabAtkins> RESOLVED: View timelines whose subject is the root element are always inactive (with the expectation we'll give them more behavior later)
20:22:46 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11283
20:22:46 <github-bot> Topic: [css-text] Rename `text-wrap-style: avoid-orphans`
20:22:46 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11283.
20:23:06 <TabAtkins> jensimmons: text-wrap:pretty is defined to do many different things to make it prettier
20:23:39 <TabAtkins> jensimmons: i propose to have a new value that *only* avoids orphans (word by itself on the last line of a paragraph)
20:23:46 <TabAtkins> jensimmons: similar to chrome's current bheavior anyway
20:24:03 <TabAtkins> jensimmons: it's proposed as avoid-orphans. that's actually a widow, adn the names are bad anyway
20:24:08 <TabAtkins> jensimmons: lots of suggestions, i think all the names are bad
20:24:09 <astearns> not just a word by itself, very short lines with more than one word should also be avoided
20:24:23 <TabAtkins> jensimmons: if you read thru it, i think `avoid-short-last-line` is best so far
20:24:37 <florian_irc> q+
20:24:47 <TabAtkins> jensimmons: we can bikeshed the name if needed, but even if we don't have the name decided on i'd like to switch to avoid-short-last-line *for now*
20:24:53 <kizu> q+
20:25:00 <TabAtkins> +1 to abandoning the orphan/widow terminology
20:25:01 <lea> q+
20:25:10 <TabAtkins> I have *never* remembe3red which is which anyway
20:25:20 <TabAtkins> florian_irc: agree with the problem, and the temporary problem
20:25:36 <TabAtkins> florian_irc: and the suggested name isn't wrong in an international context, it doesn't mention "words". that's nice
20:25:41 <TabAtkins> florian_irc: would like something shorter, but this'll do
20:25:47 <astearns> ack florian_irc
20:25:57 <TabAtkins> fantasai: one idea is avoid-short-lines? i guess we want to avoid short lines in general
20:26:11 <TabAtkins> astearns: this is just about last lines
20:26:14 <astearns> ack fantasai
20:26:20 <TabAtkins> fantasai: so a short line in the center of a paragraph is okay?
20:26:25 <TabAtkins> jensimmons: yeah this doesn't handle that
20:26:40 <TabAtkins> florian_irc: nuance: if the penultimate line is short, it would somewhat balance that against the last line
20:26:46 <TabAtkins> florian_irc: but wouldn't touch a line in the middle
20:27:07 <astearns> q+
20:27:16 <TabAtkins> jensimmons: so if you have one line with a short word, followed by a long word, in a narrow column. right now the long word will wrap.
20:27:29 <ChrisL> Supercalifragilisticexpialidocious
20:27:30 <TabAtkins> jensimmons: which will leave you with a short line in the middle of the paragraph. and this feature isn't trying to mitigate that.
20:27:31 <jensimmons> jensimmons has joined #css
20:27:43 <astearns> ack kizu
20:27:43 <TabAtkins> jensimmons: so i think it's best to be specific with "avoid-short-last-line"
20:27:53 <TabAtkins> kizu: i think i like this term even if the value is long
20:28:02 <TabAtkins> kizu: you won't use it that often, and it's very understandable
20:28:20 <ntim> q+
20:28:27 <jensimmons> q+
20:28:27 <TabAtkins> kizu: looking at all the other values i think they're all a bit too wide in what they cover
20:28:30 <astearns> ack lea
20:28:36 <TabAtkins> lea: right now this is a flag, essentially
20:28:48 <TabAtkins> lea: a lot of typesetting programs give designers more control over orphan prevention
20:28:55 <TabAtkins> lea: that woudl change naming conventions
20:29:00 <florian_irc> q?
20:29:00 <TabAtkins> lea: number of words, or % of content area
20:29:07 <TabAtkins> lea: that would give us different names to work with
20:29:11 <florian_irc> q+ to respond to lea
20:29:19 <TabAtkins> lea: and more ability, probably with an auto value to let the UA choose
20:29:25 <kurt> q+
20:29:29 <TabAtkins> lea: it's not just about orphans, if you have a very long line even two words looks bad
20:29:41 <TabAtkins> lea: but i do agree changing the word "orphan"
20:29:55 <TabAtkins> lea: orphan is used in both words and lines, typographically. confusing because you dont' know which it's referring to
20:29:59 <TabAtkins> florian_irc: and it' bad in both cases
20:30:02 <astearns> ack florian_irc
20:30:02 <Zakim> florian_irc, you wanted to respond to lea
20:30:19 <TabAtkins> florian_irc: i disagree with giving fine-grained controls, there's so many fine-grained things you might want to set, you have to not only set those but also their priorities
20:30:38 <TabAtkins> florian_irc: you end up with a toolbox of many knobs, most of the parameter space is nonsensical. think letting the browser figure it out is more often better.
20:30:39 <lea> q?
20:30:52 <TabAtkins> florian_irc: but if we do want to do that, it's a big problem, file a separat eissue. but i'd rather not
20:31:07 <TabAtkins> astearns: i agree mostly with florian. InDesign doesn't let you choose a % of content length
20:31:31 <TabAtkins> astearns: it's complicated on what effect this has on other lines in the paragraph
20:31:41 <TabAtkins> astearns: it's not okay to implement this as putting an nbsp in the last two words
20:31:54 <TabAtkins> astearns: the spec should say something like "use the facilities you have in text-wrap:pretty to avoid a short last line"
20:32:11 <TabAtkins> astearns: if the overall line-breaking for a paragraph cannot be improved, we will sometimes still get a short last line
20:32:39 <astearns> ack ntim
20:32:42 <TabAtkins> astearns: so the spec should say that this is a bit subtle, not a dumb switch
20:32:44 <astearns> ack astearns
20:32:47 <TabAtkins> florian_irc: right, its' "avoid", not "forbid"
20:33:03 <TabAtkins> ntim: iirc, avoid-orphans was one of the ways to mitigate the perf problems of text-wrap:pretty
20:33:18 <TabAtkins> ntim: should it be a name that's easy to remember, then, so people are more likely to use it rather than pretty?
20:33:23 <TabAtkins> ntim: "pretty" is short and easy to use
20:33:39 <TabAtkins> florian_irc: so rename "pretty" to "please-use-nice-typography-if-you-can"
20:33:46 <TabAtkins> florian_irc: it would be nice to find a shorter name, yeah
20:33:55 <TabAtkins> ntim: yeah, would just be nice to encourage people to use the new value
20:34:06 <TabAtkins> fantasai: i think the fact that it's obvious what it does might actually encourage people
20:34:15 <astearns> ack jensimmons
20:34:21 <TabAtkins> astearns: and if you can come up with a better name, feel free to suggest it
20:34:35 <TabAtkins> jensimmons: i think avoid-short-last-lines is good because it is flexible enough to handle all scripts
20:34:43 <TabAtkins> jensimmons: and it's very clear what it is, no prior typographic education
20:35:01 <TabAtkins> jensimmons: if you've never known typograph stuff, you read this property, you see this value and you think you know waht it does right away. that's a good quality
20:35:13 <TabAtkins> jensimmons: i think we've been prioritizing those two qualities *over* a short word
20:35:28 <bkardell> I like `avoid-short-last-lines` - it is clear... +1 to what jensimmons is saying rightnow
20:35:33 <TabAtkins> jensimmons: dont' think we'll really find a shorther phrase. trick is a lot of people havne't thought about this before, so we ahve to name all the pieces
20:35:55 <TabAtkins> jensimmons: there is a question of if we need this at all, i think perf of "pretty" shoudl be fine anyway unless they have ridiculous paragraphs
20:35:58 <kbabbitt> q+
20:36:08 <TabAtkins> jensimmons: but it does give browsers some flexibility to avoid messing up "pretty"
20:36:32 <TabAtkins> jensimmons: and to address alan's concerns about the precise definition, it does go to some details about that already. you have to look at multiple lines
20:36:37 <TabAtkins> jensimmons: there's a lot of MAY in there
20:36:55 <astearns> ack kurt
20:36:55 <TabAtkins> jensimmons: you'll see a lot of different choices if you open the same text in chrome and safari, that's fine
20:36:58 <kurt> https://drafts.csswg.org/css-break/#widows-orphans
20:37:08 <TabAtkins> kurt: there's a property for widows and orphans in css-break already
20:37:17 <TabAtkins> kurt: does that hit the same problems?
20:37:33 <TabAtkins> jensimmons: yeah, those affect the first/last lines of a paragraph around a break
20:37:40 <astearns> ack kbabbitt
20:37:44 <TabAtkins> astearns: if we had to replace those we'd need an alias anyway. but this is a new term
20:37:53 <TabAtkins> kbabbitt: among these terms i like avoid-short-last-line best, yeah
20:38:05 <TabAtkins> kbabbitt: isn't there a property... the use-case is finding the right balance of quality vs perf
20:38:32 <TabAtkins> kbabbitt: there's another set of propertites about image-rendering that also hint about quality vs perf
20:38:37 <TabAtkins> TabAtkins: image-rendering, yeah
20:38:42 <TabAtkins> kbabbitt: can those names apply
20:39:42 <iank_> q+
20:39:59 <TabAtkins> TabAtkins: we have deprecated optimizequality and optimizespeed. they mean the same thing. the other values are all specific about what's happening. so if we want to draw a parallel, it's similar to what's being proposed ehre, with specific details about what's happening
20:40:25 <TabAtkins> jensimmons: and we dont' want to necessarliy say "speed", computers get faster, algos get better. don't want to tie a behavior to taht based on current perf considerations that might change later
20:40:41 <TabAtkins> jensimmons: if you turn on the feature flag in the recent version, webkit's pretty does a lot of work.
20:40:50 <TabAtkins> jensimmons: doesn't handle rivers yet, but it's a lot more than what chrome does right now
20:40:54 <TabAtkins> jensimmons: and the perf is great
20:41:10 <TabAtkins> jensimmons: i need to do some more testing, but afaik you can put it on as many elements as you want
20:41:25 <TabAtkins> jensimmons: concern is that i fyou have one element that's hundreds or thousands of lines long, you might see an issue
20:41:47 <TabAtkins> jensimmons: so if you just have zero paragraph breaks at all in a long article, that's the area that might be slow. but otherwise is fine.
20:41:55 <astearns> ack iank_
20:42:02 <TabAtkins> jensimmons: that's also why i hesitate warning people off of pretty
20:42:14 <TabAtkins> iank_: for perf, we don't see on the low end devices getting faster year over year. they're getting cheaper, isntead
20:42:22 <TabAtkins> iank_: that's been true for many years now
20:42:33 <TabAtkins> iank_: i think we're positioned to have the msot users in that segment.
20:42:48 <TabAtkins> iank_: so yeah, perf in the high end is getting better, but on the low end it's static, and we have the biggest slice of that market
20:42:58 <TabAtkins> jensimmons: good point. iphone 16e is pretty fast
20:43:15 <TabAtkins> astearns: so i think we're ready to rename avoid-orphans to avoid-short-last-line
20:43:17 <TabAtkins> astearns: objections?
20:43:27 <TabAtkins> RESOLVED: rename avoid-orphans to avoid-short-last-line
20:43:36 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11463
20:43:36 <github-bot> Topic: [css-align] `justify-items: legacy` fails to fulfil its only purpose of explaining `<center>` and `align`
20:43:36 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11463.
20:44:13 <TabAtkins> oriol: this is a problem i ran into when i was implementing justify/align-self on blcoks in Servo
20:44:25 <TabAtkins> oriol: initial value of justify-self is `auto`, which takes from justify-items on parent
20:44:42 <TabAtkins> oriol: justify-items ahs an value of "legacy" which is combined with left/right/center
20:44:56 <TabAtkins> oriol: these have special behavior when you inherit to jsutify-self where you jsut use left/right/center
20:45:17 <TabAtkins> oriol: this was designed to explain the weird behaior of html's <center>/<left>/<right> and its align="" attribute
20:45:43 <TabAtkins> oriol: problem is if you're using justify-items:legacy center, children will resolve justify-self:auto to center.
20:45:50 <TabAtkins> oriol: and center prevents auto widths from stretching
20:45:56 <TabAtkins> oriol: that is different from the HtML behavior
20:45:57 <iank_> q+
20:46:00 <TabAtkins> oriol: so it doesn't work
20:46:14 <TabAtkins> oriol: i think to address this we shoudl either say this legacy combination allow auto sizes to still stretch
20:46:22 <TabAtkins> oriol: or we should do this some other way
20:46:26 <bkardell> "whoops"
20:46:33 <iank_> https://github.com/w3c/csswg-drafts/issues/10388#issuecomment-2233714476
20:46:34 <TabAtkins> oriol: because browsers currently implement them with text-align, which doesn't make sense
20:46:43 <astearns> ack iank_
20:46:51 <TabAtkins> iank_: i posted a link to the issue
20:47:14 <TabAtkins> iank_: i think we already have a reoslution from last year that we handle the html alignmetn as -webkit prefixed text-aling values
20:47:21 <TabAtkins> iank_: so do we need legacy justify-items at all?
20:47:38 <TabAtkins> oriol: my understanding from the previous resolution is that even tho <center> was setting text-align:-webkit-center
20:47:52 <TabAtkins> oriol: it was still possible for these special keywords to force the computed value of justify-items to these legacy combos
20:48:03 <TabAtkins> oriol: but since they don't work either maybe we just do text-align
20:48:15 <TabAtkins> iank_: yeah, also people have been using text-align:-webkit-center manually
20:48:20 <astearns> ack fantasai
20:48:24 <TabAtkins> iank_: so my pref is to drop the justify-items values
20:48:40 <TabAtkins> fantasai: looking at the example here, it shows that justify-self property on block boxes causes it to size differently
20:48:48 <TabAtkins> fantasai: i'm not sure that's what we we meant when we wrote the spec
20:48:57 <TabAtkins> fantasai: just the overconstrained comps are replaced with alignment
20:49:04 <TabAtkins> fantasai: i don't think we meant for it to change how boxes are sizes
20:49:20 <TabAtkins> fantasai: we could do that, just it wasn't my original intent. i originally was just trying to fix the overconstrainted situation
20:49:35 <TabAtkins> oriol: i'm pretty sure shrinkwrapping the sizing is alreayd working in grid and flexbox
20:49:44 <TabAtkins> oriol: so i dont' know that blocks being inconsistent woudl be good
20:49:45 <bkardell> s/alreayd/already
20:49:52 <bkardell> s/woudl/would
20:50:25 <TabAtkins> fantasai: othe rpoint. the legacy stuff *was* designed to replace the html alignment. if that's not working, we should remove it.
20:50:37 <bkardell> s/othe rpoint./other point.
20:50:59 <TabAtkins> fantasai: i don't think this sizing issue is why to remove it. but if sites are relying on text-align disabling the html alignment behavior, then it means the only property that can be used for html alignment has to be text-aling
20:51:09 <TabAtkins> fantasai: so then we do need to standardize on that, and we can drop this from alignment
20:51:17 <fantasai> TabAtkins: I agree with Elika
20:51:18 <iank_> +1
20:51:31 <bkardell> s/ text-aling/text-align
20:51:31 <fantasai> https://github.com/w3c/csswg-drafts/issues/10388#issuecomment-2254475149
20:51:33 <TabAtkins> astearns: so are you proposing to see if we can remove the property?
20:51:37 <TabAtkins> astearns: or remove it now?
20:51:54 <TabAtkins> fantasai: here's the example from the other issue. if that is working, i suspect people *are* relying on it, and we'r elocked into text-align
20:52:20 <TabAtkins> iank_: yeah i'd be hesitant to change the parent behavior with text-align. just asking for a lot of pain
20:52:25 <TabAtkins> iank_: given how old these values are
20:52:45 <TabAtkins> iank_: we still might have a compat problem if we remove 'legacy'
20:52:59 <TabAtkins> iank_: people depending on it working in grid/flex
20:53:02 <fantasai> TabAtkins: And ultimately we can list is as valid but ignored
20:53:05 <TabAtkins> iank_: but i'm willing to risk it
20:53:13 <fantasai> fantasai: does anyone actually use this value?
20:53:34 <fantasai> TabAtkins: proposal to remove 'legacy' values, relying on text-align for HTML alignment
20:53:45 <fantasai> TabAtkins: and if compat impact, we can redefine it as a useless keyword
20:53:55 <fantasai> astearns: and see if that's compatible
20:54:15 <fantasai> PROPOSED: Drop the legacy keyword, assuming that's Web-compatible
20:54:25 <fantasai> RESOLVED: Drop the legacy keyword, assuming that's Web-compatible
20:54:46 <TabAtkins> fantasai: on this issue, if we're using text-aling for html alignment
20:54:59 <TabAtkins> fantasai: then i think we should take that as an explicit reoslution, and give the webkit values actual names
20:55:01 <bkardell> s/text-aling/text-align
20:55:09 <TabAtkins> fantasai: i suggest appending -items to each keyword
20:55:18 <TabAtkins> fantasai: text-align: start-items
20:55:28 <TabAtkins> astearns: we ahve a resolution to put the -webkit keywords in compat
20:55:49 <fantasai> TabAtkins: We also have a standing resolution to remove things from compat spec when we can
20:56:06 <fantasai> TabAtkins: These are long-deprecated features supported for legacy reasons. I don't see a good reason to give them a good name.
20:56:17 <fantasai> TabAtkins: This is nasty value
20:56:39 <fantasai> fantasai: If you want the effect, then why give users the ability to specify without -webkit-prefix
20:56:41 <iank_> +1 to tab
20:56:59 <TabAtkins> astearns: agree with Tab, keep them named clearly as back-compat
20:57:11 <TabAtkins> astearns: if there's a reason for similar functionality that doesn't have to exactly match, we can introduce new values
20:57:20 <fantasai> fantasai: we tried with the legacy keywords
20:57:25 <fantasai> s/fantasai/Tab/
20:57:33 <fantasai> TabAtkins: But ...
20:57:42 <fantasai> TabAtkins: if we were doing it on purpose, wouldn't have called it 'legacy'.
20:57:47 <fantasai> TabAtkins: call it 'match-text-align' or something
20:57:56 <fantasai> fantasai: But it doesn't inherit
20:58:13 <TabAtkins> TabAtkins: we were not defining this behavior on purpose
20:58:36 <fantasai> fantasai: If people are using -webkit- keywords then that means they want the behavior
20:58:44 <fantasai> fantasai: so we should give it reasonable keywords
20:58:54 <ntim> q+
20:59:01 <TabAtkins> TabAtkins: if people want this, we can define it *propertly*. we would *never* have put this on text-align if we designed it on purpose
20:59:14 <TabAtkins> iank_: i think in most cases people don't really need full inheritance anyway
20:59:21 <astearns> ack ntim
20:59:46 <TabAtkins> ntim: if we're doing in the path TAb is suggesting, would we bea ble to use the new css design adn apply it to the html tags?
20:59:54 <TabAtkins> ntim: and get rid of the text-align properties/
21:00:13 <TabAtkins> fantasai: that's what I'm saying, people are using text-align to override an inherited value set by the html element
21:00:25 <TabAtkins> fantasai: if we did this with something other than text-align it would change the behavior
21:00:54 <fantasai> fantasai: they are using text-align and HTML alignment laternating, assuming they cascade and inherit as a single thing
21:01:08 <fantasai> fantasai: so we wouldn't be able to change the attribute mapping
21:01:32 <fantasai> TabAtkins: I think we shouldn't give these values real names.
21:01:33 <dbaron> (I think if we wanted to design the feature "right" we'd probably want something reasonably close to the "legacy" keyword that we just resolved to remove...)
21:01:43 <TabAtkins> dbaron, yes, but not named "legacy"
21:02:03 <TabAtkins> fantasai: I don't thinkl -webkit prefixes should be in the web platform for any reason other than supporting pages using webkit prefixes
21:02:12 <TabAtkins> astearns: we're out of time, we'll discuss this in a future meeting
21:02:14 <astearns> topic: end
21:02:17 <dbaron> seems like we should have another issue on adding items-start, items-center, etc.?
21:02:48 <emeyer> emeyer has left #css
21:04:46 <hoch> hoch has joined #css
21:05:21 <astearns> https://github.com/explainers-by-googlers/limiting-local-fonts-access?tab=readme-ov-file
21:13:52 <jensimmons> jensimmons has joined #css