Meeting minutes
<dbaron> oops, should have waited until after 9am to invite RRSAgent
<ChrisL> (general round of introductions)
<dbaron> on phone can't talk now
github-bot, take up w3c/
[css-color-adjust-1] Wide Review
<github-bot> OK, I'll post this discussion to w3c/
ChrisL: 2 proposed resolutions, to add Alison as editor
… and second to publish CR snapshot
astearns: can you summraize what happend so far?
… do we always do wide review for snapshots?
ChrisL: yes
astearns: any more questions?
alisonmaher: do we do CRD first?
fantasai: no
RESOLUTION: Publish CR Snapshot of css-color-adjust-1
github-bot, take up w3c/
[css-scoping] Scoping of functions, other name-defining at-rules and custom idents
<github-bot> OK, I'll post this discussion to w3c/
kizu: a lot of issue with naming, everything is mostly global
… not accessible to shadow DOM
… not handy for authors of libraries
… things clash together, different libraries and comps
… some tools have solutions, like PostCSS, nothing in CSS
… if you want to build a library you need to handle names yourself
… this is an issue about brainstorming about what can be done, like scoping
… if we do it with scoping it will be attached to trees, and this is not good for perfomance in some engines
… maybe reuse the ... namespace
… have some namepsacing for anything nested
… there was a question about being able to namespace some of the things
… maybe use ident() or other
… maybe expose it via CSSOM, or shadow roots
TabAtkins: this looks good overall
… we need to see what things are scoped
… requires some reviews, but looks fine
… I think we'll need to allow nested namespaces, which will require chaining the namespace component,
… looks like a good approach
kizu: also anonymous namespace would be useful for small components if you don't want to share anything
astearns: I support this, but whatever we call it should probably not be "CSS modules"
… to not mistake it with other stuff
<miriam> +1 to the idea
fantasai: I support just "namespacing"
plinss: not happy with overloading @namespace
… we should define a new namespace, but concept is fine
<TabAtkins> @name-scope or something
lea: are there impl. concerns currently?
… even tree scoping is not implemented
<astearns> +1 to some other @rule name
lea: when inheriting now values will change?
TabAtkins: purely lexical thing
… things will bounce from the @-rule
… custom properties will not, but other things will have {missed}
… trying to avoid complexities of that
fantasai: what if the spacing mechanism would work same as @namespace?
<adamargyle> @realm? @prefix?
plinss: my concern is that the original name was used for something else
… may not be used much anymore
fantasai: it's just binding of a name to a string
TabAtkins: it is semantically related but substentialy different
astearns: it would be good to have a new name that doesn't bump up against docs of the old @namespace
… would be good to have a new one even if hard
emilio: a bit of concern of how it interacts with custom properties
… you're parsing a value like @keyfarmes name, becomes an identifier
… if you specify from there it also get queued up
… but as soon as you do via custom properites, you lose context, like when you apply it
… I wonder how we'll do it in practice, I fear that recovering context will be hard
… have an example to show
<emilio> @namespace foo { @keyframes my-ident { ... } div { --custom: my-ident; animation-name: my-ident; /* works */; animation-name: var(--custom); /* ? */ }
emilio: this is one of the things we'll need to figure out
kizu: good thing think about
… if you define as property and not [missed]
… maybe we need somthing more explicit
<TabAtkins> Could have a function form of the scoped name *as well*, which is processed as substitution function, so eagerly even inside of custom props.
kizu: for that namespace or another
<TabAtkins> `scoped-name(foo, my-ident)`
kizu: maybhave somthing like a namespace function
… that says this is for this namespace or another
astearns: so let's take that back to issue
… so we're looking for a resolution to start working on that, taking back to issue?
kizu: yes
github-bot, take up w3c/
[css-fonts-5] or [css-text-4] Text Fitting: Which spec to put the feature into?
<github-bot> OK, I'll post this discussion to w3c/
kizu: initially we resolved that text fitting will be added to CSS fonts spec
… google thought would be better at CSS text, no idea myself
ChrisL: I weakly agree about using CSS Text
fantasai: probably should be a new level spec
astearns: agree
astearns: other concerns?
PROPOSED RESOLUTION: This will be using CSS Text level 5
astearns: objections?
RESOLUTION: This will be using CSS Text level 5
github-bot, take up w3c/
[css-fonts-5] Text Fitting: Shrinking and Growing
<github-bot> OK, I'll post this discussion to w3c/
tkent: should we provide a single property? or separate ones?
… also will there be a shorthand?
… [showing slides]
… a new text-fit property
… a new text-grow property, and a new text-shrink property
astearns: chair hat off, my impression is that the grow version of this feature has the most uses
… I see uses for shrink, but don't know if it's something authors will use much
… would like a fitting feature that grows first, and consider allowing shrinking later, before we box ourselves, and focus on grow
iank_: we have people that want to use the text shrink specifically
astearns: is taht request documented well? what for?
iank_: they want to contraint an area and reduce things as much as possible
kizu: common cases are when have a number as big as possible and then shrink it
… initial problem can be cumbersome, I think text-fit is the base option here
<adamargyle> +1
kizu: if we have either grow or shrink ...
… having a single property helps here to simplify here
… and later allow grow/shrink for more usecases
TabAtkins: I want to understand, when you allow just shrink or grow ...
kizu: whatever font size you have to specify and then it's either growing or shrinking
… this allows you to say how much you want it to grow or shrink
<ydaniv> +1 to kizu
miriam: sounds to me like use cases are ...
… I like the simple text fit option more
… concerned about a11y issues, is there another issue for that?
kizu: there is one, not mentioned here
… we had concerns about some of the [missed]
… mostly related to drawing, if it's unlimited you may need to zoom your text by 200% or more
… with browser zoom will allow you to grow a lot, but have a limitation of viewport
<astearns> +1 to worries with shrink accessibility
miriam: I worry about shrink option, if it is able to continue shrinking, would prefer if there was a baseline, and only have a top clamp and bottom open ended
… so agree with astearns
astearns: kizu mentioned you have more slides?
<Zakim> emilio, you wanted to ask how would shrinking interact with stuff like minimum-font-size and other accessibility settings
tkent: yes
emilio: glad you said that, the whole shrinking thing sounds bad
<tkent> https://
emilio: not so much as an a11y issue, but could shrink the text down to something that can't be used
… so +1 to start simple
miriam: don't think we should dismiss the rest, there's no guarantee this will always be used on large text
fantasai: are we asking for 1 proeprty? or 2?
astearns: it's the one or the 2
fantasai: I think we should go with the 2, and shorthand them
kizu: wanted to mention that text-fit will allow adjusting spacing and fitting, and will be more extensible
… very hard to solve if we have multiple properties at the same time
fantasai: one way to work around a11y where people have a muinimum font-size, is to always clamp, with an overide keyword
miriam: it's unreliable, people misuse it
fantasai: would should do flooring the value by default
… your prefered size is not the smallest one, and you should have a declared starting point
florian: I think we should go with a single property
… shrinking is possible, but not all possibilites make sense
<fantasai> s/misuse it by e.g. setting it to 10px so they have a unit that's 10px/
florian: so shows syntax is wrong, if we have a single property it may allow a more sensible combination
… as for shrinking, useful buy also dangerous
… when users try to zoom and grow the text but it doesn't, it's hostile for users
… we've been talking about font size, but also need to mention letter spacing and others
… at some point if you reduce letter spacing too much it's not readable
… let's not give up on shrink too quickly, and focus on the grow one first
astearns: we chair hat on, getting into details here
… 3 separate issues here, and Q is growing, would like to scope it to are we using option A or B (1 or 2 properties)
<iank_> my worry with only supporting growing is that people will just set `font-size: 0.1px` and grow from there which is sub-optimal
<miriam> and a vote for option 'a'
astearns: and the rest we should discuss separately
<fantasai> +1 iank_
dholbert: thinking about dynamically loading content, the grow feature, may force text to grow too much in size
… don't have an easy way to avoid
lea: seems useful to have a customsable min and max
… to control text size is a separate thing
… regarding shrink/grow, if you can only grow and specify just min size may not be great for a11y
… also the slides seem to talk about other stuff that are not text
… have you considered a unit-based approach?
… when you see designers they sometime control font size, sometimes letter spacing
<dholbert> (specifically the scenario I'm imagining is if you have a line of text "AAA BBB" that happens to exactly fit, and then some dynamic change happens [e.g. an image loads] and you have to linewrap "AAA" and "BBB" to two lines; then they'd grow to ~2x their initial size. And that sort of change might be a bit jarring)
lea: sometimes it's ok to allow letter spacing grow longer, sometimes not
… what if we had similar semantics to fr? and you could use it in clamp or minmax
<astearns> dholbert: that is exactly the effect that some authors want :)
lea: something along these lines, not well-formed yet
<TabAtkins> Issue with that is that it would only allow "consistent" growth/shrink, not per-line
ChrisL: wanted to point out when grow text kerning, tracking and optical size can change, we shouldn't forget these aspects
fantasai: on the syntax front, if it's option A, you want to be able to relate the limit to multiple operations you're doing
… so I think the syntax needs some more work to allow it
<TabAtkins> There is a lot, but we can't actually search all of them in a reasonable way. That's why, at least at first, basing it on font-size *only* is a reasonable choice. (It's also nearly the only option that is *guaranteed* to work on any font.)
fantasai: and +1 to be able to set default font-size and adjust from there
astearns: so deciding on one of these options, is that viable?
kizu: so this is a start
astearns: I think A is better option
… other comments?
lea: would be great to have library that exposes this and we can observe authors' usage
miriam: there is one, fittext
lea: I know but would like to explore this
astearns: tkent will prototype and we can see how people use it
<fantasai> +1 lea
lea: if it's behind a flag authors don';t use it, then we ship it and we realize it doesn't serve use cases well
astearns: agree
RESOLUTION: use text-fit for now
github-bot, take up w3c/
[css-fonts-5] Text Fitting: Scaling of things based on font-size
<github-bot> OK, I'll post this discussion to w3c/
tkent: this issue is about how other items align
… we had 3 options: A: all font-relative values are scaled based on font size
… b: nothing other than text should be scaled
… C: evenrhing should be scaled
… [shows example in slide]
… seems complexity is high when used with calc()
… (regarding to option A_
… B is simple and we can extend later
… current impl. in Chrome is based on this
… downside is non-text items can't be scaled
… [shows example in slides]
… in option A padding is re-evaluted
… [missed]
kizu: I wanted to say there's discussion in the issue
… Chrome implemented B, works well, the main issue was that I wanted to have option A, don't think it's posisble but would like it
… don't think we should be limitting to one option
… also lea mentioned we may want other properties to fit/scale
… A and B could work in theory, we could implement A later
… if we would be able to do it later, we could fix later things that depend on font-size
… you could scale everything as much and later adjust other things accordingly
… you could mix and match all things
… think that combinations of other things should go to separate issue and we should consider them
… could be something like text-fit [missed]
… we don't yet what would be good by default
… we should start with option B and later continue on A
astearns: on your last point, we don't have to have an explicit keyword for a default value
… I'd like to have an omittable dafault like auto
… in favor of doing B for now, even though A is cool
… worried that the scaling factor is not available to authors
… some non-text thing that could scale on the line, and have no way of finding out what that was
TabAtkins: similar to what astearns said, this has been done before, don't want to do A until we have some ways to solve it
… I think there are good use-cases for B, like if your text has an inline image, it sould scale the same way
… happy with starting with B as default, and have some keyword to allowing it, and later pusure A
emilio: I guess zoom does something similar
… is there a 4th option for doing a slightly better behavior?
kbabbitt: I understand C is stay simple, B is just simple zoom of the text?
iank_: it's not just zoom text, you're changing font-size , not just scale
kbabbitt: so you're basically changing font-size
iank_: just for text
kbabbitt: was wondering how would that work with text-decorations
<TabAtkins> ydaniv: was wondering; I wasn't able to catch up with everything while scribing
<TabAtkins> ydaniv: does this work with SVG text?
<TabAtkins> ydaniv: that' snot just a text node
<TabAtkins> astearns: I think that should be a separate issue that we consider
florian: I think we have to go with B
… taht said, there are non-simple things we want to do, but not necessarily bound to A
… proabbly should also work with units
… but maybe be able to opt-in to other systems, like to grow into something, like the box decorations
<astearns> treat-image-as-text generic feature?
florian: currently only B makes sense for now
fantasai: strongly thins shouldn't go into style computation, like A describes
… the ablilty to scale and change font-size are both useful, but they are different
… want to remind that for other stuff like letter spacing, we have a sizing option that allows changing other stuff
… there are a number of places in text layout where we previously relied only on em's and they resolve later and we needed percentage to do that
… makes sense to me to use zoom
astearns: just to clarify, you're saying let's not do A for em's, but we have to do A for %'s?
fantasai: it could because it's based on a used-time operation
TabAtkins: the way we do it now is do a one-shot guess, and later scale to fit
… in that case we would not have an accurate font-size necessarily
fantasai: you could adjust decorations to that
astearns: I think this would not be effective for authors who wouldn't know what that scale was
fantasai: if you're zooming text and doubling the size of font, and don't scale the letter spacing with it, it would be very weird
<schenney> Also text-decoration-thickness: from-font;
fantasai: if it's set in %'s it supposed to match font-size
kizu: doing with one-shot as now and later apply fitting and scaling, as browsers currently apply
… maybe we could later add a second shot
… maybe what fantasai said could also work
astearns: one min before break
<iank_> for the 2-shot TBH i don't think its worth it, but it should be another issue.
florian: maybe separate to 2 issues, we could do with B and check what it applies to
… maybe would be harder to guess what your sclae would be in a one-shot
<TabAtkins> +1 to florian
florian: the auto default should deal with text and we need to explore and it should include letter-spacing
PROPOSED RESOLUTION: start only with B, only text is scaled
astearns: any objections?
RESOLUTION: start only with B, only text is scaled, "what is text" TBD
<iank_> does Canary do what you expected?
<TabAtkins> iank_: Close enough for this purpose. I'm not 100% sure if I expect it to trigger fallback when the anchor actually starts to leave the page or just continue shifting, but either way, it's at least doing the same thing for ICB and body{position:relative}
<kizu> @ian
<kizu> @iank_ & @TabAtkins — would be nice to look at https://
<iank_> @kizu - can you check M144 for me?
<kizu> @iank_: Yep, just checked in 144.0.7525.3 — still reproduces (although a bit differently than before, but still looks broken)
<iank_> ok
Meta
astearns: a proposal for how to deal with scrollbars in non-rectangular displays being discussed in a few minutes in room 402
… anyone not interested in anchor-pos but would be interested in that case, please go represent us there
… we will likely get the people proposing it as group members once it's gone through some process, would be nice to have someone represent today
anchor positioning
github-bot, take up w3c/
[css-anchor-position-1] Allow anchor references to match names in outer tree scopes
<github-bot> OK, I'll post this discussion to w3c/
TabAtkins: this is an issue where I went ahead and synthesized feedback into a spec edit
… andruud realized we didn't have a spec edit
… smal change to how we resolve anchor names and references with shadow trees involved
… prevoiusly could not reach out in either direction
… I've dropped a small tweak in that allows an anchor name to be defined higher up in shadow tree
… and anchor reference in shadows can refer to that
… will do standard thing of looking up tree ignoring shadow boundaries until it finds a name
<adamargyle> +1
TabAtkins: satisfies westbrook's use case
<sorvell> +1
TabAtkins: there is still the other side where you want an anchor name defined deep in a shadow referenceable elsewhere in tree
… requires more explicit opt-in to be safe in my opinion
<sorvell> +1
TabAtkins: would like to work on in the future but for now I think spec is in a good state
… so if there are no objections we can resolve to take these edits
<Zakim> fantasai, you wanted to ask about other naming
fantasai: could you summarize for the group... we have a variety of name matching behaviors, what's changed?
TabAtkins: previously in the spec, anchor names were tree scoped names
… carry around identity / style tree they were defined in
… anchor names were strict tree scoped references
… would only match tree scoped names defined in same tree as they were
… now they are loose tree scope names
… will match any names in their own tree or higher up tree
… if trees don't have parent-child relationship they won't match
… can define in parent component, top level component, any tree will see that
fantasai: did we change how it works for other props?
TabAtkins: we have not right now because we haven't rewritten scoping rules for timelines to match anchors
… but intention is to keep all those concepts resolving exactly as identically as possible
astearns: do we have that intent written down?
TabAtkins: we resolved on it during breakout in Paris
astearns: do we need CSS operations module or something that collects some of these cross module resolutions
… we do have space on wiki for design principles, this seems like something that should go there
TabAtkins: seems reasonable
astearns: other comments?
Proposed: Accept the edits
RESOLUTION: Accept the edits
github-bot, take up w3c/
[css-anchor-position-1] Back-compat of scrollable containing block for all abspos with implicit anchors
<github-bot> OK, I'll post this discussion to w3c/
fantasai: for scrollable containing blocks of a positioned block
… when you have a scroll container, there's scrollport which doesn't move with scroll
… local containing block which is ICB equivalent for the scrollport
… and there's the scrollable containing block which roughly corresponds to entire scrollable area
… abspos boxes are defined currently if their CB is generated by a scroll container, they reference the LCB
… if I position something bottom:0, in a scroll container, it will be positioned at the initial scroll position to coincide wuth bottom wedge of scroll part and scroll with container
… with anchor pos, we have these fallback concepts and other kinds of sizing where exact position of that bottom matters
<TabAtkins> "fixed" -> size of scrollport, 'outside' the scroller (like fixpos). "local" -> size of scrollport, 'inside' the scroller at top (like ICB). "scrolling" -> size of scrollable content, 'inside' the scroller (this is new and anchorpos automatically uses it sometimes)
fantasai: what's outside the container can affect layout, with try fallbacks or overflow alignment
… as we add more capabilities to abspos, that edge becomes more present even in cases where you were only referencing top and left corners
… we discussed this and decided to use the scrollable containing block as the containing block for boxes that have a default anchor element
… problem with that is that even if you just use normal anchor positioning, boxes that have implicit anchor element now have default anchor element
… and have now switched into this behavior even if they don't use anchor pos
… existing page using popover for example with position bottom 0
… will change behavior from being above the fold to below the fold
… which is a compat issue
… bottom 0 still needs to mean bottom of local containing block
<iank_> (popover is `position:fixed` by default so also need `position: absolute` on the popover to trigger the switch)
fantasai: but for purpose of overflow management we need a bigger area
… my proposal is that if inset is auto, we resolve it to the edge of the scrollable area
… rather than the edge of the local containing block
… and that creates the space we need without triggering overflow
… and without changing interpretation of a fixed length
TabAtkins: I am with iank_
… not liking this particular proposed resolution because it means auto no longer has as stable and obvious thing to resolve to
… difference between leaving edge as auto and wanting to adjust a little bit
… suddenly you opt into other interpretation and get a big jump you didn't expect
… back compat issue is that having any anchor at all is what we resolved to use as a switch
… some things get anchor ayutomatcially without doing anything
… just fixing that bit would solve the back compat issue without being overly problematic in the other way
… my preferrred solution is to explicitly key off non-auto default anchor
… initial value auto will use implicit anchor
… add implicit keyword which uses implicit anchor
… that way you're affirmatively using anchor pos in a similar way to non-auto
… that way we can add more implicit anchors in the future and it won't switch positioning behavior and be low impact
… other possibilities iank_ mentioned of using ? anywhere in your insets
… we rejected doing that for other reasons, don't recall the details
<iank_> i'm ok with that.
TabAtkins: would instead propose to add implicit keyword, and key off having anchor and non-initial value for position-anchor property
fantasai: I have serious problems with that approach
… 2 problems
… 1 I don't think a property that controls anchor binding and changes how it matches the binding should have a big effect on layout
… we're not changing element we're binding to, just changing keyword with exact same behavior, it just has a new side effect of changing how insets are resolved
… that's really confusing
… could have a question of whether there's a binding or not but shouldn't affect layout
… 2, need this to work by default
… if author needs to opt into ?? by default, they can do so with more obvious declaration
… so I don't think that's a good plan
… re: auto and 0 don't resolve to same thing - that's fine
… if you want 10px of spacing, add a margin
TabAtkins: wasn't that auto and 0 resolve to same, auto is unpredictable value now
… can't say I want to use current edge but inset a little bit
fantasai: add a margin
… auto already has a lot of cases where it has an unpredictable value
… can't say I want to be static position + 10px
… this is already a feature of auto insets
iank_: for the non dominant edge it's always true you can inset a bit an dit works
… I was playing around with it and it's very weird if you jump to a local when the right hand side is on the scrolling containing block
… a lot of people do use insets in this way
… I just want you in a little bit
… people will run into jump and not understand it
… very against that
fantasai: then let's require people to set position-area
TabAtkins: that's saying people should use a no-op property that indicates anchor pos vs the property I'm sating
fantasai: difference is position-area is a layout property
… whereas position-anchor is how I connect an abspos to its anchor
… and you want to introduce synonym to initial value
… where only difference is one has a layout side effect
TabAtkins: like all the other non auto values yes
… named anchor has same side effect
fantasai: no
TabAtkins: currently it does
… per current spec it would give you side effect
… problem is right now if you leave as auto and get explicit anchor, that triggers side effect which has back compat
… so if you say implicit anchor and have that trigger
… [missed]
iank_: previous resolution was to trigger this scrollable containing block behavior off the existence of default anchor
… set via position-anchor property, not if you use position-area
… spec is currently mismatched with that resolution
TabAtkins: because position-area only does something when you have a default anchor
… if we care about position-area, it's a subset of having default anchor
fantasai: under current resolytion if you set position-anchor to --foo and there's no --foo you don't get behavior?
TabAtkins: correct
… propose that if you have a default anchor and position-anchor is not default value you opt into the behavior
fantasai: you're saying I want synonym for auto, behaves just like auto, other than it has side effect on contianingh block
… even though this property has no effect on layout prior to this discussion
… and we have separate property for that
TabAtkins: we already resolved that if you have position-anchor --foo and --foo exists, that triggers
fantasai: I'm saying that was a bad decision
… ok with saying you need to change position-area to span-all
… or changing the way auto insets resolve
… not okay with having a property whose sole purpose is to create a binding with 2 nearly identical values where one has side effect
astearns: little confused about how this new feature could have back compat issues
… because you need to set both binding and position-area to get new behavior?
TabAtkins: resolution we had was that if you are using anchor positioning, if your CB is a scroller, you start using scrollable containing block
… that's a good behavior if you're actyally using anchor pos
… problem is behavior for "are you using anchor pos" is just "do you have a default anchor" which is given byt the position-anchor property
… if you specifgy a name and that matches something you're clearly using anchor pos
… problem that default value auto will look for implicit anchor
… and there's several sources for that
fantasai: so this would change behavior of any abspos value before pseudo element
TabAtkins: something using 0 will be at bottom of scroller instead of bottom of scrollers' ICB
chrisl: something being accidentally opterd in?
TabAtkins: correct
… fantasai's preference is to change position-area
… not super opposed but if you don't care about position-area, it's a little strange to have to turn it on and give it a no-op value just to make your anchor pos resolve
fantasai: not a no-opt, opting you into new behavior
TabAtkins: my thing is, thing that gives you position-anchor, add another keyword that opts you in
<kizu> Could it be both: either `position-area` or an explicit `position-anchor` will opt in?
TabAtkins: use the fact that it's non-default value as a strong signal
… also effectively a no-op since it's behavior of autp
… but if you're not using position-area in other way you don't need to put that in your styles as well
<iank_> i'm strongly against setting `position-area`
<iank_> notbody is going to remember how to do that.
TabAtkins: don't feel too strongly about which way we go, find position-area a little weird, but proposed thing about auto resolutions I do object to
<Zakim> fantasai, you wanted to review the position-area value
fantasai: my proposal is switch to using positon-area as signal
… its initial value is none
… we have a span-all value which gets you whole 9 grid
… any non-initial value would give you containign block is entire scrollable area
… to compensate for anchor functions not using position-area in general ,change interprateation of auto for insets to expand out to sctollable area
… specific value would go back to previous behavior
… would be back compatible
… otherwise you need some explicit signal
… TabAtkins is proposing new keyword for position-anchor that will opt you into that behavior
… I am saying we already have explicit switch
miriam: tend to agree with fantasai here
… what we are changing is not the anchor but the area
… so position-area is what makes sense to do that
… wonder if we can be more explicit? not just span-all
… span-all has 2 slightly different meanings, can we explicitly say what I'm doing is opting into ... whatever it's called
… does feel like we're talking about the area, that's what's changing
… if we can say it more explicitly taht's good
<Zakim> fantasai, you wanted to react to miriam to respond to that
fantasai: earlier we discussed a proposal to differentiate between these 3 CBS
<TabAtkins> (what do you mean by "2 slightly different meanings"?)
fantasai: fixed, local, scrollable containing blocks
… plan to work on switch for those 3 explicitly
… would affect 9-grid for position-area as well as everything else
… initially proposed auot to allow anchor pos to just work
… there will be an ability to explicitly do that
fantasai: span-all aready says use whole 9 grid
… bounds of that is whole scrollable CB
TabAtkins: was curoius what miriam meant by 2 slightly different meanings
miriam: is that what fantasai just clarified?
TabAtkins: yes we use entire scrollable CB
miriam: if that means that already ... just noting there's a difference between different containers you could consider 9 grid to be part of or offset of, and we're switching from one to another
… in that case I agree with fantasai straightforwardly
astearns: kind of sounds like we are relitigating the initial design that relied almost entirely on anchor functions and we made a decision to go with position-area instead
… perfectly happy having the anchor functions trigger on position-area as opposed to the position-anchor property
… particularyly since position-anchor has defauylt value that authors might find themselves having to work around without making any anchor pos decisions
… I am probably confused myself but i think I am weakly in favor of fantasai's proposal
TabAtkins: which version?
astearns: using position-area as the trigger
iank_: don't really like position-area to change the behavior of the insets
<fantasai> [The two variants were a) use position-area or b) use position-area and also reinterpret inset:auto ]
iank_: you can use anchor pos in 2 different ways
… position-area or insets with anchor functions
… when you're working in anchor function mode, having to remember oh it's not working in scroll container, I need to set position-area span-all, no one's going to do that
… so I strongly dislike that
… to the point where I'll probably object on API design standpoint
<TabAtkins> miriam, the 9-grid just divvies up *whatever* the CB is; span-all means "use the whole 9-grid". It doesn't *inherently* say anything about which CB you're using, but it does function as a signal for "i'm using anchor positioning", which is a signal we want to use to automatically opt you into the scrollable CB. (and we have resolution to change 'position' to let you explicitly choose your CB too, but this is just to flip the "default" answer)
iank_: shouldn't have to care about position-area if just using anchor functions
… variant could be, if you have a non-implicit default anchor or using position-area, I'd be happy with that
… doesn't affect popover which is position:fixed
… unless you change to absolute
… will affect before, after
… but not sure of compat of that anyway
… my preferred solution is non-implicit default anchor, or use position-area property
fantasai: I think it's a bit weird to have the method of the binding change the layout
… whether or not there's a binding makes sense, but not method
… we want people to choose binding depending on whetehr it's presentational or semantic effect, not what layout side effects it has
… would not expect layout side effects based on choice of HTML or CSS
… would be nice if anchor pos just worked, why I proposed having auto value of insets resolve to edges of scrollable CB
<TabAtkins> the issue Ian has with "rely on position-area" is that it means some otherwise-very-similar styles act wildly differently, as he pointed out in w3c/
fantasai: maybe not ideal that inset 10px doesn't get you 10px inset from currently effective scolling container
<TabAtkins> example: .anchored1 {
<TabAtkins> position-anchor: --a;
<TabAtkins> position-area: bottom;
<TabAtkins> }
<TabAtkins> .anchored2 {
<TabAtkins> position-anchor: --a;
<TabAtkins> top: anchor(bottom);
<TabAtkins> }
fantasai: but easy to use marcgins if you want spacing
… having auto resolve to a non-zero value is not an unreasonable thing for auto to do
iank_: I think it is unreasonable, most people use insets rather than margins for htis
TabAtkins: pretty opposed to the auto change
… don't like its magic
astearns: how do we resolve this standoff?
fantasai: hear from more people
astearns: should we take this back to the issue and go through examples?
… iank_, you said you played with it and it was bad, would be helpful to see what you were playing with
iank_: I can do that
TabAtkins: example in chat, our current resoluytion which relies on default anchor, both of those get scrollable containing block
… using position-area has a little more magic but for raw positioning they work the same
… if we only use position-area as switch, these two would be dramatically different
… using anchor function would most certtainly be overflowing and trigger fallbacks
… because you'd use the LCB which is above the fold section
… which is weird because it looks like you're using anchor pos
… authors have to use no-op position-area value
… onlh problme with intiial reasolution is that it has back compat in non anchor pos cases
… we ideally want to just exclude back compat problem rather than change reoslyutionmore dramatically
flackr: do we have evidence that there is a compat issue with changing abspos behavior in this case?
TabAtkins: we don't have examples in the wild, certain it exists, will hapen if anyone has done before element with abspos and bottom 0 containign block scroller
flackr: what's the use case for that?
TabAtkins: if you have ever used anything with bottom inset in CB scroller you will have changed behavior
… what we did in past will change position
flackr: sizing changes would be bigger issue
TabAtkins: yes for example top0 bottom: 0
<Zakim> fantasai, you wanted to comment on the example with implicit anchors
TabAtkins: suddenly you're size of entire scroller
fantasai: back to TabAtkins example he's using position-anchor to connect
… if you rely on the implicit position-anchor that would not exist
… that's the case that's creating some of the tension here
… an anchor exists but not using position-anchor property
… would be nice if that just worked
… but what TabAtkins is proposing is that top example would be just position-area bottom since we have ancghor
… but second example would have to say position-anchor something as well as anchor top anchor bottom
… would be nice to make that just work, fact ytou have to say position-anchor in order to get your containing block to work is quite weird
… shouldn't change layout behavior
<fantasai> ... you already have an anchor association, and you're not associating it
TabAtkins: though your proposal ignoring inset ayuto for a bit would still require another line there
… which is just as much ofa put a no-op in
fantasai: right, that's why I wanted to change interpretation of autop
… and if you add an extra line, it should be position-area
<fantasai> (and not position-anchor)
TabAtkins: we'll object to changing auto inset behavior in the way that was suggested
… however what if we go with a non-implicit anchor or a non-none position area
… that way in the example from iank_ either position-anchor --a or position-area span-all would work
fantasai: don't think it is good for authors to have implicit anchor have different behaviors than explicit anchor
… don't think method of binding should have effect on layout
… if all keywords have special side effect except initial that makes a little more sense
… don't want to push authors to consider layout effects when trying to decide if they should use explicit or implicit binding, HTML or CSS
… that shouldn't be about whether there's a layout effect, only about what is appropriate type of binding
… also thing it's weird to use binding property as layout switch
… less objectionable if it's not deciding which binding to use, but using a binding property as a layout switch is still weird and I think confusing
miriam: seems like all this is caused by making everything magical without opting in
… wonder about just having a literal opt-in
… default of position-anchor is not auto, it's none
… and you have to set to auto if you want an anchor
<TabAtkins> q for fantasai: wait, are you okay with "non-initial position-anchor *or* position-area", so using the implicit anchor with position-area switches? because that's totally fine with me
miriam: or explicitly opt into anchor pos for anything else to work
… would be a normal thing in CSS
… for positon-anchor, real opt-in
iank_: what was the reason that we didn't want to trigger off anchor functions on insets?
TabAtkins: don't remember and that's a problem
… we resolved to not do it early in the proposal discussion, year + ago
… don't recall exactly what the issue was
emilio: don't remember either
TabAtkins: we decided not to do that, don't remember exact reason
emilio: anchor functions ... when you do interleaving, anchor functions resolve to actual piel values at computed style time
… computed style doesn't have info to tell if there's an anchor reference
… if you keep magic bit for anchor function, it doesn't round-trip
… div.style.bottom = gCS.bottom, it goes away, would be bad
iank_: abspos doesn't reoundtrip insets today anyway
… does it?
TabAtkins: yeah?
emilio: auto resolves
<Snugug> I'm being told by someone in WICG that they're looking for CSS representation for the scrollbar feature. I'm not sure I'm the right person to go down and represent the WG, but if no one else is able to do so I will
iank_: shrink to fit vs stretch ... you % will resolve differently
fantasai: won't change % resolution because that's based on CB
… resolving auto might have some effect
… anything else should round-trip
<Snugug> will do.
iank_: I would be fine with losing the round-tripping
emilio: pretty unfortunate, this would also be the case even with typed om that doesn't do resolved value shenanigans
… typed om doesn't resolve auto
… but does resolve anchor to px
… due to how anchor is defined
<Zakim> fantasai, you wanted to suggest using position-area OR position-try
fantasai: the problem we're running into doesn't happen with TabAtkins example
… problem happens when we add to that example something like position-try
… so what if we trigger SCB on having either position-area non-initial or position-try non-initial
… would that solve teh core problem?
iank_: don't think that works because available space is different between 2 examples
… if it' sleft or right, available space of local CB vs scroillable CB is 2 very diferent things
… shirnbk to fit will be different
TabAtkins: height % will also be different
fantasai: changing the resolution of % also, a lot of things to trigger based on
… also you have the case of, if you use anchor func with named anchor vs implicit anchor, you get different layout behavior alos
… just keying off position anchor is for layout puyrposes is not the right switch
iank_: you get different behavior anyway if you use position-anchor
… very big layout switch anyway
astearns: can we go back to miriam's suggestion of requiring an opt-in for anchor instead of this implicit anchor behavior?
fantasai: position-area span-all is an explicit opt-in
TabAtkins: problem is, abspos behavior today is straight up broken for most anchor related use cases
… anything that cares about the space breaks in most cases if you use local CB of your scorller
… taht's why we want to be forgiing in opting into scrollable CB instead
… explicit opt in a
… problem when you have other things that opt into anchor pos
miriam: we have lots of things that opt into grid but you still have to set display grid and that' suyseful
astearns: and we're tying ourselves into knots on all possible triggers for anchor pos
… do like simplicity of single property that has to be set to something, that gets you into new anchor pos behavior
TabAtkins: very likely can't key all anchor pos off some new opt-in, been shipped in several browsers for quite a while
astearns: just changing implicit anchor behavior to require an opt-in with the property that has that anchor choice built in
… taking the implicit anchor and making it an explicit choice
fantasai: initial value of position-anchor should be none?
astearns: yes
miriam: that's what I was saying
iank_: would likely be fine with popver if we did that and adde dposition anchor implicit for that
… popovers are position fixed by default and don't have this behavior
… probably fine to be honest
TabAtkins: popover is just a matter of one more line in UA stylesheet, should be fine
fantasai: whole point of defining implicit anchor is so you don't ahve to think about that connection
miriam: disagree, you still don't have to know what the name of it is
… still useful to get automatic anchor even if you explicitly opt in
flackr: yes, that was main reason it's useful
astearns: of the things we've discussed, I think that's the most promising thing
… I think we should either resolve on auto anchor selection being a value you have to put in property, or take this back to the issue and move on
TabAtkins: good with first option
fantasai: would like to hear from kizu
iank_: I'm okay with it
kizu: <sigh>
miriam: I agree with kizu
<adamargyle> need demos? need to see something…
kizu: I like the idea of making the position-anchor none by default
… for pseudo elements you opt in by doing this or you could use implicit keyword inside anchor function as well
… so you don't have to mention as position-anchor
<flackr> if it's none by default do we need to use the keyword implicit or is it just auto?
TabAtkins: we would add the implicit keyword as one of the things we put in implicit anchor
… right now if you omit you get popover behavior
<iank_> thats a good idea.
fantasai: if we change this behavior to not create binding by default, inital value should be none
<TabAtkins> default-anchor initial value becomes `none`. `auto` selects an implicit anchor.
astearns: proposed resolution is that the default value of position-anchor is `none` but you can use `auto` to opt in to implicit anchor
fantasai: so we add new value, and change initial value
… and also add to stylesheet for popver
astearns: any concerns?
fantasai: don't love it but can live with it
TabAtkins: this is my proposal with words changed
fantasai: no it's a little diffreent, we don't have synonyms
astearns: objections?
nt1m: if this new value is new default, why do we need to add to stylesheet?
emilio: popover wants old behavior
fantasai: popover would continue to have implicit anchor you could just use, anything else with implicit anchor you need to opt in
… :before and after which create a binding will no longer do that
nt1m: we'd be breaking all the demos that apply anchor pos on pseudo elements?
emilio: the ones that don't use position-area
fantasai: we didn't resolve that position-area would also be a switch
[crosstalk]
fantasai: demos that currently use before and after ...
TabAtkins: not safe to do current behavior
iank_: and I don't think we've shipped before and after behavior
astearns: I hear some reservations but no objections
RESOLUTION: add none value to position-anchor, make it the initial value, change UA stylesheet for popover
<Snugug> @astearns The meeting had wrapped by the time I got down there and it was unclear from those who were still in the room whether the topic had been presented or what the results were
github-bot, take up w3c/
[css-grid-3] Masonry Switch Syntax
<github-bot> OK, I'll post this discussion to w3c/
fantasai: survey had over 300 responses
… popular ones are listed in issue
… top choices include grid-stack, packed-grid stuff
… also grid-lanes or lane-grid
… if you merge some options together that was among the top
<fantasai> w3c/
fantasai: ^ link to top options
… concerns about stack because of confusion with stacking context
… people thought pack got confused with density
… looking at results, TabAtkins alisonmaher and I concluded grid-lanes seemed popular and didn't have downsites
… also works well for creating a shorthand for this purpose
… that's currently what we're thinking is best among surveyed options
alisonmaher: comment on one of those options
<miriam> as my own personal top vote, I approve :)
alisonmaher: do others have ideas on final 2?
… I'm not opposed to grid-lanes, but one downside I see is we have concept of tracks
… if we introduce term for lanes, we'd have both that and tracks, could be confusing
fantasai: we don't expose tracks anywhere, just a spec internal term
ydaniv: what about just lanes?
astearns; we already resolved to have grid in value nam,e
TabAtkins: otherwise I'd agree
oriol: fantasai was saying it would work well with shorthand, can you clarify?
fantasai: Google proposed a sghorthand tailored to masonry that sets only one axis of grid values
… they were calling that shorthandmasonry
… can't use that but grid-lanes would still work for that purpose
astearns: am I correct that the quick part of this is poll between grid-lanes vs masonry-grid as the display value?
<TabAtkins> grid-lanes: column repeat(3, auto);
<TabAtkins> kbabbitt: one thing I discovered
<TabAtkins> kbabbitt: in terms of what people are referring to this with...
<TabAtkins> kbabbitt: "masonry" has been in use since 2009
kbabbitt: In terms of referring, name of masonry has been in use since 2009, so this is what authors have been calling it for a long time
<TabAtkins> kbabbitt: authors have been using the term for a very long time
kbabbitt: Not objecting, but still preference for grid-masonry
POLL: 1. grid-lanes, 2. masonry-grid
<miriam> 1
1
<alisonmaher> 2
<oriol> 2
<bts> 1
2
<florian> 1
<ntim> 1
<kizu> 1
<iank_> 2
<ydaniv> 1
<ChrisL> 1
<adamargyle> 1
<rachelandrew> 2
<astearns> 2
<dholbert_> 1 (but am flexible)
<Snugug> 2
<TabAtkins> no pref
<schenney> 1
<flackr> 1 or 2
<saku> 1
<kzms2> 1
<emilio> 1
astearns: seeing a 3:2 advantage for grid-lanes, not conclusive but better than we've had up till now
<TabAtkins> yeah, 14 to 8 or so
<TabAtkins> about a 3:2
astearns: Proposed: masonry switch will be display: grid-lanes
RESOLUTION: masonry switch will be display: grid-lanes
none
guest from AB
Brent: I'm here from the AB and I'm here to help!
Brent: Tell us how the Process has been working for you.
hober: OK if what you're saying isn't about the Process as written, but about your experience of it
hober: We're looking for the vibes.
ChrisL: Thanks for getting rid of Proposed Recommendation
ChrisL: Amendment process making diffs is painful.
ChrisL: Impetus was great, but implementation was extremely painful
ChrisL: Rechartering, why do we need to do it every 2 years?
ChrisL: It's a lot of work to round up the votes to approve a charter
ChrisL: Can we just take objections
florian: Defer to others.
… +1 to comment on chartering
… #2, I would like to see significantly more tooling
… Many things the Process calls for that indeed should happen
… Enables W3C to fulfill its promises
… But we are undertooled for it.
… As a spec editor, should be able to just push a button that walks you through figuring out all the things
… and don't have to spend half an hour reading documentation
… the problem isn't what we have to do, but doing things manually and unassisted
… want enough tooling that you don't have to read the process
… but click your way through doing the right things
astearns: Personally, from my perspective, things are just fine
… I just can't keep the Process in mind, and rely entirely on ChrisL :)
… If he says it's a problem, +1 from me
hober: You're not the first chair to say this about their Team Contact
florian: Yes, the "Team Contact" is how we "automate" this, and there are more gratifying things to do than being a human publishing bot
astearns: Any others who tried to understand Process and bounced off like me? Or run into intractable issues?
miriam: +1 to Florian, publishing I get tripped up on command line all the time
Brent: If anyone has spicy takes, reach out to any of us directly.
Brent: Or join us in the Process CG
Brent: There's also a monthly AB-led Member Meeting, you are all invited to that
Brent: Welcome to come and comment on things
Brent: Would like this to be a feedback loop, not just a one-time thing.
Florian: Also, for chartering, timelines for specs might be useful in some groups, in ours it's busywork fiction.
astearns: +1 two-year rechartering and timelines are really dumb for us. Though maybe that's just us, so might not need to change.
Florian: Might not be a requirement, but practice of predicting when our 100+ specs go to REC is silly
hober: Charters have different audiences, and sometimes those audiences need or want different things from them
hober: I might want some things, and lawyers might want some different things.
hober: But point taken about made-up random-number schedules
Lunch
returning 13:45 JST
<astearns> we will start again as soon as we can, waiting on stragglers
<iank_> I'm dropping - have fun!
MDN update from Estelle
<TabAtkins> Estelle: [intro]
<TabAtkins> Estelle: over past 2 1/2 years i've been working on a new project, completed but not yet announced
<TabAtkins> Estelle: wanted to talk about it with you
<TabAtkins> Estelle: scroll-driven animations as an example
<TabAtkins> Estelle: i'm trying to document each CSS spec as its own landing page
<TabAtkins> Estelle: 100-ish specs here in the sidebar
<TabAtkins> Estelle: each spec has its own landing page. versions are combined
<TabAtkins> Estelle: has a brief overview. simple example.
<TabAtkins> Estelle: not an educational piece tho; a linking piece
<TabAtkins> Estelle: I noticed CSS specs often had interfaces but they were somewhat hidden
<TabAtkins> Estelle: so this contains properties/types/functions/etc defined in the spec
<TabAtkins> Estelle: also a glossary
<TabAtkins> Estelle: and a guide for some topics
<TabAtkins> Estelle: "related concepts" for things that are highly linked. can't do scroll-driven animations without animations, keyframes, overflow, we animations api
<TabAtkins> Estelle: link to spec, and a "see also"
<TabAtkins> Estelle: another example, borders and box deco
<TabAtkins> Estelle: again, brief intro, and example
<TabAtkins> Estelle: all defined props
<TabAtkins> Estelle: nowhere in MDN do we document things that dont' exist yet. except for here!
<TabAtkins> Estelle: if there's a new feature, easy to hear about it but not find it
<TabAtkins> Estelle: we can list it here and note that it's not yet supported
<TabAtkins> Estelle: that way people can go to MDN and find something not supported
<TabAtkins> Estelle: pointing out again, the IDL interfaces too
<TabAtkins> Estelle: just wanted to intro this
<TabAtkins> Estelle: I've got a list of things that aren't implemented yet, need more check over since i've been doing this for two years
<TabAtkins> Estelle: if anyone wants to help create a guide or example, let me know, these pages are all auto-generated
<TabAtkins> astearns: about explainers. we're trying to be more consistent with having those.
<TabAtkins> Estelle: I didn't know explainers existed until recently. def would have been helpful
<TabAtkins> Estelle: we're talking with docs people to help with explainers too
<TabAtkins> astearns: we also often move stuff around, break properties into a new module or relocate something
<TabAtkins> astearns: we don't do a great job to communicate that
<TabAtkins> astearns: should we have some sort of official channel with you?
<TabAtkins> Estelle: would be helpful if someone communicated that. or a quick PR just to move something.
<TabAtkins> Estelle: It won't change the BCD so I won't be auto-alerted.
<TabAtkins> Estelle: in BCD we list all the specs, every property, and list what module it's in. that's auto-genned.
TabAtkins: We might resolve one later this afternoon, so that'll be a test case
<TabAtkins> astearns: the MDN page for a prop links to the spec it's from. will there also be a link to this documentation?
<TabAtkins> Estelle: on each ref page there's a link to the spec, i'll try to add these too. these aren't reference or educational, just guides to help keep things interconnected
<Zakim> astearns, you wanted to ask about explainers and how to communicate the rejiggering we do
<TabAtkins> astearns: yeah I could see jumping to the See Also in this guide being easier than scanning the spec
<TabAtkins> florian: first, looks great
<TabAtkins> florian: you asked for ping when things changed. i'm a user of MDN, never contributed
<TabAtkins> florian: suspect it's fine if I tried to be a contributor, but I ahvne't done it. as a spec editor, would be nice to have a paragraph in our wiki saying "do X to update MDN". better than trying to figure out what to do on my own.
<TabAtkins> florian: So I'd like just some simple documentation on what exactly to do. suspect it's easy, just don't know what to do yet
<TabAtkins> florian: also more generally, what should we know to avoid making your life hard, and what can we do to make it easier?
<TabAtkins> Estelle: to make life easier, ensure each page is only one spec. like color HDR doesn't belong in the Color page, except in See Also
<Zakim> fantasai, you wanted to suggest explainers be incorporated into specs wher epossible
<TabAtkins> fantasai: re explainers, I think the content should largely be in the module itself
<TabAtkins> astearns: separate discussion
<TabAtkins> fantasai: when impractical we should probably publish as a Note
<TabAtkins> fantasai: other q, Bikeshed generates an automatic index of properties. are we publishing that to TR? If not, could we? that might help Estelle with auditing.
<TabAtkins> astearns: sounds good to me
<TabAtkins> florian: and publishing gives you dated versions so you can diff
<TabAtkins> TabAtkins: yeah easy
<TabAtkins> Estelle: florian, where do you want that documentation?
<TabAtkins> florian: in our wiki is fine.
<TabAtkins> Vadim: clarify explainers. I know we plan to do more explainers, goals and non-goals, things like that. short summary. Is that what you meant?
<TabAtkins> astearns: yes to all. very ill-defined.
<TabAtkins> Vadim: on MDN we try not to document anything that's not in browsers, not directly practical to devs.
<TabAtkins> Vadim: devs go to MDN and see stuff and want to use it. So want to make sure explainers are about impls not just ideas.
<TabAtkins> astearns: we're in process of collecting more explainers that we know exist, they might get integrated into specs or wahtever
<TabAtkins> astearns: motivating use-cases, why it exists...
<TabAtkins> Vadim: Yeah that would b euseful
<TabAtkins> plinss: it wouldn't be difficult to cron and generate Bikeshed indexes on a daily basis, or just get the data direct from the source. we can automate, better than waiting for someone to tell you.
<TabAtkins> astearns: Thank you for this summary!
<TabAtkins> github-bot, take up w3c/
[css-gaps-1] Gap decorations next to empty grid areas
<github-bot> OK, I'll post this discussion to w3c/
<TabAtkins> kbabbitt: in August at f2f we talked a bit about this
<TabAtkins> kbabbitt: there are use-cases for not wanting decorations on all cells in grid
<TabAtkins> kbabbitt: [example] an unfilled grid area, don't want the deco crossing it
<TabAtkins> kbabbitt: [another example] don't want a deco between a filled area and an unfilled
<TabAtkins> kbabbitt: [another example] multicols, don't want lines between the empty columns at the end
<TabAtkins> kbabbitt: Elika suggested rule-visiblitity-items and rule-visiblity-self, I went with that
<TabAtkins> kbabbitt: working thru use-cases, realized just *-items is sufficient
<TabAtkins> kbabbitt: rv-items sets default over whole container for whether there's a deco in a gap between items when one or both sides is empty
<TabAtkins> kbabbitt: 'all' draws all decos. 'around' draws around items (between a filled and unfilled)
<TabAtkins> kbabbitt: 'between' only draws them between two filled (skips filled+unfilled)
<TabAtkins> kbabbitt: rv-self would let you set exceptions for specific items
<TabAtkins> kbabbitt: talking to Sam Davis, in our impl rv-self has some additional complexity
<TabAtkins> alisonmaher: currently gap-decos are set up on the container itself. we just track the segments and don't care about children.
<TabAtkins> alisonmaher: but if rv-self changed we'd have to rerun layout on the whole container to make it work
<TabAtkins> kbabbitt: so all the use-cases we have are satisfied with rv-items, either "around" or "between"
<TabAtkins> kbabbitt: [goes over the examples]
<TabAtkins> kbabbitt: so my proposal for v1 is to just do rv-items: all | around | between;
<TabAtkins> kbabbitt: if we get feedback that we need it, we can add "none", and rv-items, if needed
<TabAtkins> astearns: I think it's fine to start simple and add complexity later
<TabAtkins> astearns: back in first use-case, you said this is solved with "around"
<TabAtkins> astearns: in this case, does author want deco to be entire width, or just over the right 2/3?
<Zakim> astearns, you wanted to ask about the first use case
<TabAtkins> kbabbitt: that's a border actually
<TabAtkins> fantasai: this sounds good, looks like we have a path forward if we need it
<TabAtkins> fantasai: ftr should say "hidden" rather than "none", "hidden" suppresses in other contexts
<TabAtkins> kbabbitt: so proposed resolution is to introduce just rv-items, with "all | around | between" values
Proposed: Introduce column-rule-visibility-items: [ all | around | between ] and row-rule-visibility-items with same syntax, plus shorthand rule-visibility-items for both directions
<florian> +1
<miriam> excited to use this!
<TabAtkins> astearns: objections?
RESOLUTION: Add 'rule-visibility-items: all | around | between' (plus longhands)
<TabAtkins> github-bot, take up w3c/
[css-gaps] Gap decorations with collapsed gutters
<github-bot> OK, I'll post this discussion to w3c/
<TabAtkins> kbabbitt: in Grid, when you have repeat(auto-fit, ...), it generates as many tracks as necessary to fill the space, and then will collapse the unneeded tracks if there's few items
<TabAtkins> kbabbitt: the way Grid is defined, those gaps still exist, they're just between 0-width tracks and overlap
<TabAtkins> kbabbitt: we previously resolved to suppress all but one. went with table border-collapse rules to choose
<TabAtkins> kbabbitt: based on comments iv'e gotten since, think that's wrong choice algo
<TabAtkins> kbabbitt: the scenarios for picking the styles are different from in tables
<TabAtkins> kbabbitt: gap-repeat has a repeat() syntax too, and it would be less confusing to just still use that pattern.
<TabAtkins> kbabbitt: so I'd like to propose we undo the previous resolution and just assign decors to gaps as if the collapsed tracks don't exist
<TabAtkins> alisonmaher: i support this change, want to give an example
<TabAtkins> alisonmaher: if you're using gaps to switch between colors, like `repeat(black, gray)`, if you use table rules you could end up with adjacent gap decos with the same color, rather than laternating
<TabAtkins> alisonmaher: I think authors would find that confusing and would prefer to see the repetition pattern maintained
<TabAtkins> +1
<TabAtkins> fantasai: for cases where we're getting this from repeated tracks this is fine
<TabAtkins> fantasai: we've discussed collapsing empty tracks in other situations. not sure this approach would work for those cases.
<TabAtkins> fantasai: but for the existing collapse cases, it's fine
<TabAtkins> astearns: so you're fine with undoing previous resolution? and figuring out future stuff in the future?
<TabAtkins> fantasai: yes
<TabAtkins> astearns: objections?
RESOLUTION: Undo previous resolution. Apply gap-decos *after* collapse (assuming collapsed tracks come from auto-fit, which is currently the only way to do it)
<emilio> github-bot: take up w3c/
[css-grid-3][Masonry] Intrinsic auto repeats mixed with fixed tracks
<github-bot> OK, I'll post this discussion to w3c/
<emilio> TabAtkins: currently masonry has the ability to do repeat auto-fill with intrinsic tracks in the repeat list
<emilio> ... you can do it in masonry because we have a heuristic
<emilio> ... which works great for span 1
<emilio> ... the spec has some more details but that's the tldr
<emilio> ... to deal with larger span is not so easy
<emilio> ... the current way the spec defines it
<emilio> ... you chop it as if it was made of single-span items
<emilio> ... so if you have 300px span: 2 you pretend you have two 150px single-span items
<emilio> ... for some repeats like 100px auto auto
<emilio> ... it doesn't work that well
<emilio> ... if this was grid this would work well
<emilio> ... but with the heuristics it'd make them 150px wide which means that if you 300px is in the first half you get overflow
<emilio> ... without anything to do about it
<emilio> ... some suggestions in the issue
<emilio> ... I think there's a reasonable opinion, if anyone has different ideas welcome
<emilio> ... preferred option is
<emilio> ... instead of expanding the repeat once, chop large spans and split
<emilio> ... we should repeat the tracks as many times as needed to capture all possible ways a spanner could end up
<emilio> ... then rather than chopping up we group them by span
<emilio> ... and do the hypothetical calculation
<emilio> ... then we pretend all span 1 items live in every position and the 2 span items as well, etc
<emilio> ... with some fixes for perf not to be terrible
<emilio> ... and then take whatever comes out of that
<emilio> ... in the example, it'd result both columns being 200px wide which means regardless of how many times
<emilio> ... there's no perfect solution but guarantees no overflow, and quite often you'd get a perfect fit
<emilio> ... extending the span 1 heuristic to work on span 2 and so on
<emilio> florian: makes sense but trying to confirm
<emilio> ... if I understand right it has an additional benefit, which is we place actual spanners, the sizing phase would take into account that you could span through gaps
<emilio> TabAtkins: wasn't super relevant but the chopping already deals with that (subtract the gaps)
<emilio> florian: ok, seems like a good idea
<emilio> alisonmaher: I'm supportive, I think it's the best of all the options we could through that. Wanted to mention that that the intrinsic sizes would be different between the columns
<emilio> ... so you want to take the max
<emilio> TabAtkins: replied on the thread, you'd need to do two reps so both of the autos have 200px
<emilio> alisonmaher: If you had 100px auto auto auto you'd still get a 150px in the middle
<emilio> ... so we still need the max
<emilio> TabAtkins: I don't think why
<emilio> alisonmaher: you need this for auto repeat to do the division
<emilio> TabAtkins: As long as you have a value I don't think so
<emilio> PROPOSED: Instead of chopping up spanning items, do enough repeats to cover all posibilities and the create hypothetical items for all spans, and do the same process as span-1 items do
<TabAtkins> emilio: This smells like potentially quadratic... maybe fine since it's quadratic on number of items in repeat
<TabAtkins> emilio: how easy is it to end up with a bad layout?
<emilio> TabAtkins: not quadratic it scales with the number of spans
<emilio> ... so you scale up with the max scale of the span
<emilio> ... but more of a question of how many distinct spans you have
<emilio> ... worst would be 1000 items with 1000 different span values
<emilio> ... but that's very bizarre
<emilio> ... so I think you could bail out, I don't think it can happen for reasonable markup
<emilio> emilio: might be worth to put a lower bound on the spec or something?
<emilio> PROPOSED: Instead of chopping up spanning items, do enough repeats to cover all posibilities and the create hypothetical items for all spans, and do the same process as span-1 items do, with a reasonable lower bound on the spec for how much needs to be supported
<emilio> florian: would be good for the bound to not be artificially low
RESOLUTION: Instead of chopping up spanning items, do enough repeats to cover all posibilities and the create hypothetical items for all spans, and do the same process as span-1 items do, with a reasonable lower bound on the spec for how much needs to be supported
<emilio> TabAtkins: yeah will take impl feedback into account
<emilio> github-bot: take up w3c/
[css-grid-3][masonry] impact of negative margins on running positions within a track, dense-packing, and alignment
<github-bot> OK, I'll post this discussion to w3c/
<emilio> TabAtkins: q about impact of negative margins on a running position when doing dense packing
<emilio> ... and alignment
<emilio> ... some great examples in the spec
<emilio> ... about item1 gets placed, item2 gets pulled up by the negative margin
<emilio> ... conclusion was that yes negative margins effectively shrink the size of the item, so they would affect
<emilio> ... then the question is if this has an effect on dense-packing gaps
<TabAtkins> 1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMTEzJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTExM1QwNTM4MzVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1iYzIwZWZhMTYzYzk1ODYzMDhhNGJlZTFmY2E1OWQyYWMyZDg0YzZhYWM1MmYxNjNiMjZlZjY1NDQ5MGQ1YjU4JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.JVa21nv8RU_Od6DZ2OogFxQA699X50EDnve8qy44bsA
<TabAtkins> https://
<emilio> ... if you scroll at the bottom of ^, final image shows a masonry with a couple gaps
<emilio> ... new items on the lower gap, but also has a negative margin that pulls it up past the spanner
<emilio> ... should this reduce the size of the gap in any way
<emilio> ... we (me and elika) thinks it shouldn't
<emilio> ... geometrically it lives in the second gap, it's just small
<emilio> ... so if you use enormous negative margins you deserve what you get
<emilio> ... does it sound reasonable to anybody
<emilio> oriol: have a question. in masonry we keep placing items to the track is less filled
<emilio> ... but if the item we're placing has negative margins so that it ends up negative sized, should it be put in the most-filled track?
<emilio> TabAtkins: for the purposes of running position we should treat the item as zero-sized, if it's negative it wouldn't adjust the running position
<emilio> oriol: didn't you say the opposite
<emilio> ... that neg margin would shrink
emilio: What Tab is sayaing is that if the item is 30px
… [missed]
<dholbert> Tab's proposal makes sense to me, FWIW.
emilio: But if negative margin -1000px, you cap the outer size at zero
oriol: So author sizes are never negative, then it's fine to replace
TabAtkins: I also have a proposal to fix flexbox to prevent flex main sizes from going negative for similar reasons
<emilio> fantasai: tab's proposal, if you place an item with negative margin so negative that would move the position up you would not adjust the position
<emilio> ... next item would be placed at the running position, not below the last item
<emilio> florian: makes sense to me, not new that negative margins cause overlapping position, maybe they want it
<emilio> ... so agree with the proposal
<emilio> alisonmaher: wanted to clarify
<emilio> ... if you have a running position of 100px, and the negative margin would put it at 80 you put the max
<emilio> TabAtkins: effectively
<emilio> alisonmaher: that's different than flexbox and block right?
<emilio> TabAtkins: yeah but I plan to fix flexbox
<emilio> plinss: for consistency, if you give it a positive margin that does increase the size
<emilio> ... so we're making negatives inconsistent right?
<emilio> TabAtkins: we're not, we are special-casing negative sizes, not margin
<emilio> fantasai: the running position can only move down
<emilio> [going through example]
<emilio> plinss: ok, I'm good with that
<emilio> PROPOSED: Negative margins do affect the size of the box for the purpose of dense packing. Negative margins don't interact with any previous gap. Running position only goes down, so if your margin would turn your size negative we treat it as zero for the purpose of running position
<kbabbitt> +1
RESOLUTION: Negative margins do affect the size of the box for the purpose of dense packing. Negative margins don't interact with any previous gap. Running position only goes down, so if your margin would turn your size negative we treat it as zero for the purpose of running position
<emilio> github-bot: take up w3c/
[css-grid-3][masonry] item overflow in a row masonry
<github-bot> OK, I'll post this discussion to w3c/
<emilio> alisonmaher: if you size the container to min-content in row masonry, we'd run layout for each of the items with the min-content size. When items are actually laid out, they use fit-content, so they end up with two items overflowing the container
<emilio> ... doesn't happen in grid because tracks constrain the items
<emilio> ... so fantasai proposed that masonry min-content and max-content size would be the same
<emilio> ... seems reasonable to me. Only tricky is orthogonal items,
<emilio> ... the max-content from the perspective of the container is smaller than the min-content
<emilio> ... proposal would be that orthogonal items would be min-content size rather than max-content
<emilio> ... so that we get the max width to avoid overflow
<emilio> oriol: I'm not following the orthogonal item bit
<emilio> ... why do you say that min-content > max-content
<emilio> alisonmaher: I have an example but it's pretty large
<emilio> astearns: maybe we can resolve on the non-orthogonal behavior?
<astearns> PROPOSAL: Have the min-content size of the stacking axis of a masonry container be the same as its max-content size (same as the "stacking axis" of block layout).
RESOLUTION: Have the min-content size of the stacking axis of a masonry container be the same as its max-content size (same as the "stacking axis" of block layout).
ACTION: Open an issue for orthogonal items
<emilio> github-bot: take up w3c/
[css-grid-3][Masonry] repeat(auto-fill) and minmax()
<github-bot> OK, I'll post this discussion to w3c/
alisonmaher: In the grid spec:
Accoriding to css-grid-2, "For this purpose, each track is treated as its max track sizing function if that is definite or else its min track sizing function if that is definite. If both are definite, floor the max track sizing function by the min track sizing function. If neither are definite, the number of repetitions is one."
The previous resolution: we decided to allow intrinsic auto-repeats in masonry which means that we'll likely want to reconsider this
<alisonmaher> repeat(auto-fill, auto) is the same as repeat(auto-fill, minmax(auto, auto)
fantasai: in grid, we don't have the ability to have 2 intrinsic sizes in the min and max
<TabAtkins> in an auto-repeat
you must have either a min or a max definite size
For the sizes valid in level 2 , we should keep the same grid behavior for masonry in level 3
The case where both are intrinsic is new, and we can do whatever we want
so when we have 2 definite sizes, we get the maximum, makes sense to do the same for intrinsic
We can add a keyword in the future if we want to use the min
TabAtkins: I don't like what Elika said, because masonry can assign heuristic values to its intrinsic keywords, we can treat them the same as the fixed sizes regardless of the position
we also shouldn't treat the sizes differently in a mixed intrinsic case vs a double case
when we last discussed, a couple of people agreed, but not fantasai, wanted to wait for miriam's opinion.
it's 3 months later, we should resolve
fantasai: The treatment we're deciding on here is not the actual size of the track, this is just an estimate we're using for how many tracks we have
… once we have the number of tracks, then we will fully resolve the tracks including intrinsic sizes
… I feel very strongly that for a given track listing, if I do that in grid / grid-lanes, I should get the same number of tracks, for the same set of sizes
TabAtkins: same discussion from August
miriam: it would be good to see demos, intrinsic sizing is sketchy for this
fantasai: there's 2 questions: what to do for existing syntax? what do we do for the new one for double intrinsic?
I don't mind for double
???
miriam: in theory i agree, but in practice I haven't seen demos
i don't know why we would choose one over the other
TabAtkins: fantasai is making an argument for consistency, but i'm also doing the same on the other axis
<TabAtkins> Elika wants "Grid and Masonry act identically for the syntaxes that are actually valid in both". I want "Masonry always acts the same for intrinsic keywords, regardless of how you use them".
alisonmaher: last time we talked about this, we did a whiteboard, and visuals are really helpful here
<TabAtkins> That is, `repeat(auto-fill, auto)` works in Masonry (finds a heuristic size, uses that to determine repeats).
miriam: if the argument for consistency is that auto means minmax(auto, auto), then it's more obscure
<Zakim> fantasai, you wanted to clarify sizing vs counting
TabAtkins: that's not the whole reason, is that repeat(auto-fill, auto) has a meaning in masonry, but not in grid
but repeat(auto, auto) has a meaning in masonry that we agree on and is invalid in grid
Table from the August F2F: https://
I think it's weird if minmax(0px, auto) acts differently from either of these two, because suddenly it's 0px which is what it is in grid
"which is what it is in grid" as it should be!
miriam: just in terms of determining repeats, not sizes
fantasai: Tab just said repeat(auto, auto) is invalid in grid, but we're going to make it syntactically useful in grid, and we should give it an useful meaning. If there's no compat concern we should give it a meaning that is consistent across both grid & masonry
break
<TabAtkins> .masonry { grid-template-columsn: repeat(auto-fill, auto) ; } .item { min-width: calc-size(max(100px, min-content)); }
backgrounds and borders l4
FPWD L4
<ntim> w3c/
w3c/csswg-drafts#13062
<ntim> github: w3c/
RESOLUTION: FPWD css-backgrounds-4
[css-backgrounds] allow optional forward slash in `border-*-radius` long hands
<TabAtkins> fantasai: someone outside the WG wanted to propose we allow / separating the x and y values of border-radius, also in the longhands
<TabAtkins> fantasai: right now borde-rradius takes 1-4 values, a slash, then 1-4 values. x/y
<TabAtkins> fantasai: but in the longhands it's just two values, space-separated
<TabAtkins> fantasai: they thought it was confusing, wanted to put / in the longhands as well
oriol: This would have been good from the beginning, but now that we're using spaces, but at this point
oriol: It might add confusion, if an author sees the two options, wouldn't be obvious that they mean the same thing
oriol: I'm not strongly opposed, but lean against
lea: Seems reasonable to me. I could argue that we should have done it originally, it is weird to be different.
lea: I'm in favor of this change.
kbabbitt: I empathize with the author
kbabbitt: but there are other places where we do this, concerned about lack of ocnsistency
<TabAtkins> fantasai: in colors we introduced an alternate punctuation
<ChrisL> rssagent, draft minutes
<TabAtkins> fantasai: it's not common to set x/y radius independently in the longhands. it happens, but you're usually using the shorthand, or setting both to same value
<TabAtkins> fantasai: wrt other places where we use slash, mostly it's places where wer'e combining two longhands and need the / to separate two numbers
<TabAtkins> fantasai: don't think we have any other example of where a / is used in the shorthand to separate two values, but those same two values in the longhand aren't slash-separated
<TabAtkins> fantasai: like in background-position, the / separates sizing from offsets. but in the longhands they're separate things
<TabAtkins> fantasai: so I think the consistency argument here is an overall win for authors.
astearns: Slight concern that we can resolve to make this change but never gets implemented.
astearns: doesn't seem high priority for anyone
astearns: but I'm hearing some slightly more sentiment towards making the change than opposition
astearns: Shall we resolve to change the spec?
oriol: To clarify, we alias at parse time?
astearns: And continue return without slash for comat
fantasai: yes
PROPOSED: Allow forward slash in these properties.
RESOLUTION: Allow forward slash in these properties.
[css-backgrounds] `background-clip: content-box` with scrollbar
oriol: If you set background-clip padding-box, it includes the scrollbar gutters
oriol: but spec is unclear about the content-box
oriol: but browser do content-box + scrollbar gutter
oriol: seems weird though
oriol: I would propose to keep spec and browsers are wrong
astearns: Opinions from implementers?
emilio: I agree with oriol
<TabAtkins> Agree, as drive-by webdev opinion.
astearns: so propose to keep spec and add WPT tests
fantasai: overlay scrollbars?
TabAtkins: they have no gutter
PROPOSED: Keep spec. Add tests.
oriol: This is only observable with classical scrollbars
emilio: Tests should be valid in both
ntim: WPT is forcing classic scrollbars already
ntim: We should see if implementers have any objections afterwards
astearns: certainly
RESOLUTION: Keep spec. Add tests. Revisit if implementers notice a problem.
[css-backgrounds-4] Computed Value serialization of background-position and its longhands
oriol: Here there's a disagreement in the spec about computed value of background-position
oriol: Shorthand says computed value is length-percentage per axis
<ntim> (did we skip w3c/
oriol: but longhands it includes also a keyword representing the origin
oriol: We need to decide if the computed value keeps this keyword or not
oriol: One way to observe this is with logical keywords
oriol: e.g. background-position-x: x-end 25%
<TabAtkins> My position on any question of how 'inherit' works for non-inherited properties: that's weird, don't do that.
oriol: If a child inherits this value, does it inherit the x-end 25% as a logical thing, or does it resolve to 75% and then child inherits 75%?
oriol: It's so far only implemented in WebKit, and it resolves the percentage
<TabAtkins> +1 to WebKit behavior here, I think
oriol: However I propose to keep the keyword.
<TabAtkins> (as a knee-jerk response, at least)
oriol: It's not absolutely necessary, but it will help with the logical longhands because we want to keep different meanings depending on whether you use a physical longhand or logical longhand
oriol: So that would be the first part, and the rest would depend on whether we resolve on this or not
<TabAtkins> fantasai: I feel like we need to figure out he resolution of the shorthand/longhands
<TabAtkins> fantasai: is it possible to... computing it thru is simpler, it gives you a more calculated answer
<TabAtkins> fantasai: I don't care about inheritance, no reasonable person does "background: inherit", especially thru direction change
<TabAtkins> fantasai: but if we need it for shorthand/longhand, it's reasonable to keep the keywords around
<TabAtkins> fantasai: but if we don't need it, I think it's preferable to compute the keyword away
oriol: I think it would be good for the logical longhands, but other way to do it could be an internal flag
oriol: but if we have a keyword, then we already know if it's logical or physical
fantasai: hmm, ok, then in that case let's keep it
oriol: So how do we serialize the resolved value? We're compat constrained to not include it in the existing syntax
fantasai: we would need to drop the keyword for physical ones
oriol: I checked for gCS on `right 50%`
oriol: WebKit was (at least until recently) including the keyword
fantasai: might be ok to keep keyword in both cases
fantasai: but we do currently hvae interop on resolving to percentage
oriol: When WebKit added the new keywords they resolve it to percentage
oriol: We could go for ocnsistency and never include keywords
oriol: Or we could include them for logical, or include them always
ntim: Was it background-size or background-position that had a special rule for omitting one of the two axises?
ntim: there was a difference in prefixed vs unprefixed behavior
<ntim> it was background-size!! w3c/
<karlcow> SeeAlso w3c/
fantasai: Maybe we should figure out the logical property cascade and then figure this one
ntim: wpt is consistent, what's the issue?
oriol: The spec contradicts itself
oriol: and we need to decide how to fix it
ntim: If we already have interoperable implementations, that would drive compat
oriol: Also there are new keywords
oriol: Some behaviors are only observable with these
[css-borders] allow multiple borders
lea: Years ago we got a use case from APA around having both white and black borders
lea: to make sure border was visible regardless of colors
lea: We introduced 1-dimensional images and stripes() function
lea: Which in hindsight I think was overengineered
lea: We expanded border-color to accept stripes() and it would curve around the border
lea: So initial motivation was that listifying border-color created some weird issues
lea: because specify border-width: 2px; you could end up with 6px border because it's multiple colors
lea: If we naively listify border colors, you have to specify colors in a weird order that's confusing
lea: These are problems
<lea> https://
lea: When this issue was opened, I revisited this question
<lea> https://
lea: Posted some polls
lea: There are 2 author intents: I want to specify width of entire border, or I want to specify width of individual borders
lea: As you can see, overwhelmingly people prefer listifying
lea: but then we'd need to support multiple border-styles
<miriam> on the other hand: solid, dotted, solid could look excellent
lea: another issue with listifying is, how do we reconcile issue of border-width
lea: honoring that while also being able to say 1px white, 1px black
lea: One idea I had was to have border-width specify width of the total border (as it is today)
lea: So layout would still be as expected
lea: But if you have a border shorthand specifying multiple border widths, they would dereference a new longhand
lea: where you can specify a list of border widths ando/ro fr
lea: just like in stripes() function
lea: Another concern is that even though this looks nice for simple cases, it makes some other cases more difficult
lea: Actual use cases are overwhelmingly simple
lea: People don't generally do differnet colors on each side
lea: So yes, doing layers around and around would still be awkward, but nobody really needs it
lea: But if can't resolve to that, there are other solutions
lea: Maybe we can listify outline rather than border since it doesn't affect layout
lea: but I don't think stripes is natural
emilio: Whatever solution we come up with, it has to specify width of each border individually
emilio: otherwise you end up with snapping issues
emilio: 3 colors with 2px, it's an issue
emilio: borders snap to pixels
<Zakim> about, you wanted to react to emilio
emilio: Need to make sure each stripe is device-pixel sized. Otherwise it looks like crap
oriol: I disagree that stripes() is overengineered. To me it seems simple.
oriol: I like that it allows grouping each side the various colors
oriol: because with multiple border solution you have to specify inner ones, then outer ones, etc.
oriol: it's harder to visualize what colors go to which place
oriol: I also don't like that the styles will always be solid, and need to keep repeating 'solid' for each layer
oriol: with stripes() you only need to specify the style once
TabAtkins: Small question, snapping every color, in existing two-tone borders, do we snap those?
emilio: I think the width is not snapped, but when you paint you snap
ntim: Problem I have with stripes is, naming is indicates that striping is on the other axis ...
ntim: One thing that could be possible is making stripes take sizes
TabAtkins: it already does that
florian: You still have to specify the total explicitly though
<TabAtkins> have to say `border: 5px stripes(white 1px, black 3px, blue 1px)`
ntim: makes sense
ntim: So I guess my main issue is the axis
<TabAtkins> can't just say `border: stripes(white 1px, black 3px, blue 1px)` and magically have it know it's 5px wide
ntim: Also a lot of ppl use box-shadow for this use case
<TabAtkins> (tho we could probably fix that somehow)
ntim: could we just make that more convenient?
ntim: also easier to implement
miriam: I'm interested in having a box-shadow approach, but big difference wrt layout
miriam: so stacking multiple borders wouldn't be the same
miriam: might want either or both
miriam: doesn't remove need for multiple borders
miriam: I like the just list them syntax, and disagree that we always want solid
<TabAtkins> box-shadows all stack on top of each other; people "use box-shadows" by using a wide, fully opaque shadow, then gradually adding narrower shadows.
miriam: def situations where combining dots with solid and dashes could get interesting results
miriam: so not a useless feature
lea: box-shadow is what ppl have, but it's a hack
<TabAtkins> I challenge Miriam to come up with a single example of two-dots that doesn't look horrible. ^_^
lea: You have to adjust all the lengths because they stack z-axis, not in space
lea: We could use outline, but they are used for focus rings
lea: We could have an outline-inset that goes on the inset
<ntim> (box-shadow is easier to implement because it would be a parse-time translation)
<dholbert> (TabAtkins / emilio - I just checked `groove`, following up on Tab's question a few minutes ago, and Firefox/Chrome both antialias it, based on a screenshot of `data:text/html,<div style="border: 2px groove black">Hello` on my 150% HiDPI screen on Linux)
lea: A few other things to mention
<miriam> I didn't say _every_ combination would look good :)
lea: Current stripes() has indirection issue. I need to add up my stripes. Should be able to specify intent directly
lea: Weird to have two border-width properties, but hope is that weirdness is internal
<miriam> but I think dotted, solid, dotted could look great
lea: people will very rarely need to set border-width-foo themselves
lea: listifying also allows to easily set sizes and colors independently, which is useful
lea: wrt snaps, any solution we pick will have this issue
lea: We could skip allowing flexin, but then authors will do it themselves with calc(), so you still have to deal with rounding
lea: so seems better to have author intent directly so we can make intelligent decsions
lea: Oriol mad epoint I made around how it is confusing to specify multiple colors per side
lea: but people generally don't do it
lea: it's not controversial that it's awkward
<TabAtkins> thanks, dholbert, that's useful to know. and presumably negates emilio's point about needing to snap the stripe colors, then. ^_^
lea: I agree
lea: but not a confusing thing that people will hit
lea: Also he said you need to specify solid multiple times, that's how this works
lea: but if you wnat to specify once, it's easy, following existing pattern just set border-style after the shorthand once
lea: Wrt confusing stripes() direction that tim mentioned
lea: I agree, it's confusing
lea: Would expect it to work like background clipping
<dholbert> (I disagree that it negates emilio's point; I don't think we want to draw inspiration from how 'groove' is implemented...)
<adamargyle> +1 reserve stripes() for something else some other time
<Zakim> florian, you wanted to bikeshed and propose "bands" instead of "stripes"
florian: To extent that name is problem, maybe consider bands() or something
florian: calculating the total is annoying, well, we can introduce an `auto` value
florian: sum up all the definite lengths
<noamr> color-sequence?
lea: yeah, it'd be weird to do that with stripes() but with border-width-relative would be fine
oriol: Instead of adding a new auto size, we could say that if you specify border shorthand and you omit the width component then it could automatically take from stripes function
<lea> that means we can no longer use `border-color` in the whitelist of properties that don't affect box model
oriol: if you specify in border-color wouldn't be able to, but for shorthand could do it
lea: [comment above]
oriol: wouldn't have an effect, only when setting shorthand
astearns: not hearing consensus, so take to issue
app-region for draggable app windows
diekus: windows have default ux for moving
… several APIs to expand the viewport area
… when api is enabled, can do things like create custom title bars
<kbabbitt> github: w3c/
diekus: but then the default dragable area disappears
… so propose to specify app-region
… [shows slides that expands the viewport area, losing the titlebar area]
… This exists, but no definition of how ti exists
… And this is the behavior. It's enabled only when default platforms UX is not visible
… works for inline and block elements
… property consumes all pointer events
… can use it to drag the window etc.
… won't work if it is overlapped by other elements
… works even when animating
… suppose here I have a button in the middle of the window, I set app-region on it, andI can use it to drag the window
… propose to spec it in css-ui-4
ntim: Multiple things to think about
… what happens if you put no-drag and then child is drag
… does the property inherit, what wins?
diekus: Depends on which element absorbs the pointer events
ntim: I implemented moz-window-dragging for GTK port, so some prior art
emilio: Gecko has similar property. We don't expose it to Web content
emilio: for PWA cases makes sense
emilio: If you have a native titlebar, is this property expected to work?
diekus: no
diekus: before you enable window controls overlay, you can define the drag region
emilio: That's weird. E.g. macos has toolbar where you have native titlebar, and toolbar, but the toolbar is also draggable
diekus: I fyou want to create that effect in a PWA you would enable window controls
diekus: It's used to create a custom titlebar
<jyasskin> +1 emilio
emilio: Annoying if I have to rebuild a titlebar in order to drag the toolbar
emilio: In Gecko if you drag anywhere in the toolbar, it also take sthe window, not just the titelbar
diekus: you could move from any element you set it on
diekus: but the titlebar would have to be off
emilio: that seems unfortunate
astearns: Is this a -webkit- property?
ntim: It was unshipped from Safari
hober: Yeah, it was asserted that it already exists. It's not actually all the things.
ntim: It's only shipping in Chrome apparently
ntim: I don't think app-region is a good name for this
ntim: Could reuse for other things
diekus: agree the name is not descriptive at all
diekus: but do we agree on having the behavior?
<emilio> fantasai: This seems something that should be inherited
<emilio> ... so that you can put on and off
diekus: and only affects element you set it on
… that would solve the toolbar case, as long as it works even with titlebar
<adamargyle> maybe just a new touch-action value?
diekus: details in explainer
astearns: Anyone in the room to oppose this feature? Is this not something to work on?
hober: I'd have to ask ppl in the wrong time zone
astearns: Given in one engine, was in anotther, and third has something similar...
hober: unsure it was ever in safari
astearns: Answer seems to be "maybe"
diekus: as long as it's fine overall, I can write the spec text
emilio: fine to work on it. issue on name, inheritance, when it applies
astearns: We'll work on this and decide if it goes into a draft or not
[css-page] Expose unprintable areas via CSS
foolip: Issue is unprintable areas
foolip: Original idea was using env() for safe areas
foolip: but a bit unreliable because not dependable depending on how you feed the paper
foolip: so only safe to do is to report the largest margin
foolip: So new proposal, where we have a descriptor on @page and margin boxes
foolip: and new alias for margin called safe-margin which would compute to larger of margin and safe margin
foolip: required to do fallback correctly
foolip: 3 modes for this: current behavior (no compensation), clamp (largest of the margins), and add (add to existing margin)
foolip: Unsure what the use case for that is, but long discussion with morton + dholber led to that
florian: I agree that not reliably knowable where things are
florian: unsure that it's never knowable
florian: maybe we can have some flexibility, UA can say it knows
florian: want to avoid limiting behavior in cases where we could use that knowledge
foolip: You could easily turn page-safe-margin into 4 longhands
foolip: but if nobody wants that, should we really do that, or add it only when someone claims to be able to support
florian: good enough
Proposal -
Add a property / descriptor (the spec seems confused about this terminology) for @page and @page margin boxes:
Name: page-margin-safety
Value: none | clamp | add
Initial: none
(because I scribed it badly originally)
emilio: I'm not sure awhy we need the aliasing thing?
emilio: Adds a weird dependency
emilio: Shouldn't change the descriptor's margin value
foolip: margin by itself would apply to all environments, but if don't need it
emilio: We have @supports for that
foolip: for descriptors?
emilio: Yeah, we have a resolution for that
emilio: Consider you print multiple pages per sheet
emilio: wouldn't you wnat to use the normal margin rather than the page-margin-safety thing?
foolip: This would apply to the 3 edges that apply to the edges
foolip: Some explanation that it only applies to margins adjacent to an edge
foolip: also applies to page margin boxes
florian: there the margin only applies to the one or two sides at the edge of the paper
emilio: but 1cm in the page... the page would be scaled down
foolip: that's why we moved away from env() as a solution
foolip: with this you know both the page size and what the safety is
foolip: scaling doens't make it unsafe again
emilio: if we need both, the override should happen at used-value time
<ChrisL> [css-conditional-5] Feature detection for descriptors
<ChrisL> w3c/
emilio: when you access .style ...
foolip: it is
<mstensho6> When there are multiple pages per sheet, the UA should already add whatever margin safety it needs around the set of pages, and `page-margin-safety` should do nothing in such cases.
emilio: Mortons proposal for aliasing margin is weird
astearns: I expect that there is prior art in print formatters for this
astearns: might be worth checking what it is
<mstensho6> Aliasing is for feature detection. If we can do it `@supports`, that would be much better.
<Zakim> astearns, you wanted to ask whether there is prior art in print formatters to follow
fantasai: page-margin-safety seems good
fantasai: page-safe-margin seems problematic, just use @supports
florian: [something about individual cases]
fantasai: if we're taking the max, we take the max always. If we want individual controls, we can add them
fantasai: Might want symmetric all around. Or per axis. or each side individually. We can add keywords for these.
<dholbert> (I'm not fully grokking the page-safe-margin proposal, partly because I'm sleepy. :) but I agree with fantasai I think; if we can use @supports, I'm happy with the earlier `page-margin-safety` descriptor)
astearns: Let's have morton change the proposal in response to feedback, and bring it back for adoption
end
<dholbert> (i.e. bullet point 2 from mstensho's Sep 10 comment seems reasonable, in w3c/
<dholbert> (assuming we get `@supports` working as described there)
<dholbert> (and per whatever prior resolution folks mentioned in the discussion today, about @supports with descriptors)
<noamr> ScribeNick noamr
<noamr> github-bot, take up w3c/
[css-sizing] Which replaced elements stretch?
<github-bot> OK, I'll post this discussion to w3c/
none
<noamr> github-bot, take up w3c/
[css-sizing] Which replaced elements stretch?
<github-bot> OK, I'll post this discussion to w3c/
<noamr> oriol: there are some replaced elements that stretch in the inline axis. the exact mechanism is not clear. I want to discuss in which cases this should happen
<noamr> oriol: this happens with replaced elements that don't have natural sizes, e.g. SVG can have natural size with width/height, image gets it from the resources. also a non-degenearate aspect ratio, e.g. natural or from the CSS prop
<noamr> oriol: browsers agree with this, but eg in iframes gecko and webkit ignore the aspect ratio, but it works because iframe doesn't have preferred aspect ratio. can we resolve on those two conditions?
<emilio> +1
fantasai: consistency seems good?
<kbabbitt> +1 for consistency
<noamr> iank_: it happens when there is non-degenerate aspect ratio and no natural sizing
<noamr> PROPOSED RESOLUTION: spec what browsers are doing.
<noamr> RSOLVED: spec what browsers are doing.
RESOLUTION: spec what browsers are doing.
<noamr> iank_: do you want to discuss which elements use this effect?
<noamr> oriol: It matches all replaced elements, but some don't have preferred aspect ratio, e.g. iframe or not-ready video
<noamr> iank_: there is a bug on other browsers to drop natural sizes on video. so that's fine
<noamr> github-bot, take up w3c/
[CSS2][css-position-3] Negative containing blocks and `auto` margins
<github-bot> OK, I'll post this discussion to w3c/
<noamr> oriol: we resolved this issue in Paris. when the inset is big enough so that the containing block is negative, what should happen? browsers seem inconsistent. Servo allows it to have a negative size. We resolved to go with the blink way. but we implemented it in servo we realized that blink it does this for sizing, auto sizing and margin, but for alignment it uses negative size inset-modified containing block
<noamr> iank_: it's not what's happening in blink
<noamr> iank_: it's a bug in blink. when we clamp the IMCP we have 3 options. adjust end inset, start inset, or both
<noamr> iank_: we shift the inset based on alignment to be negative
<noamr> iank_: the other option is to take the dominant side and always do that. blink always has a positive IMCP for alignment
<noamr> iank_: the other option is just to take the dominant side based on writing mode and direction. I think we resolved on that.
<noamr> oriol: we resolved on aligning with blink and then I found a case where this is different. no strong opinion
<noamr> iank_: I am fine with changing this
<noamr> fantasai: between blink and resolved behavior, no strong opinion. unlikely people would intentionally run into this. intuition from authoring perspective anyone?
<noamr> iank_: I want to clamp the negative size to non-negative
<noamr> astearns: keep resolution and consider it a bug in blink; or amend it slightly to specify blink's current behavior
<noamr> PROPOSED RESOLUTION: close with previous resolution accepted
RESOLUTION: close with previous resolution accepted
<noamr> github-bot, take up w3c/
[css2][css-tables] Cells spanning collapsed track
<github-bot> OK, I'll post this discussion to w3c/
<noamr> oriol: in tables you might have a cell that spans multiple cols/rows. one of them can be collapsed. what CSS2 says is that the area that is intersecting the collapsed track should be clipped. it's weird e.g. when there is text intersecting this
<noamr> oriol: webkit doesn't implement collapsed tracks. In gecko, in the inline-axis, it would overflow. in the vertical case, in gecko vertical aligment applies first and then it can overflow
<noamr> oriol: in blink vertical alignment happens after collapsed row, unsafely
<noamr> oriol: in servo we do something similar in a safe way
<noamr> oriol: maybe we should decide on something
<noamr> iank_: it was concious decision to relayout at the new width because of the inline overflow case. you have potentially more block size than inline size. it's a tradeoff to try not to overflow inline direction
<noamr> astearns: I don't like the alignment in blink. I don't have a good idea of what we should do here, but having the content at least start and overflow in the writing mode appropriate ways is better than hoisting above the start of the cell
<noamr> oriol: we already resolved on on vertical aligning safely. but there is a q of whether vertical alignment should be before/after collapsing
<noamr> fantasai: the original collapse was supposed to not impact layout for perf reasons. tables 25 years ago were very expensive. it's not a good behavior. what people would actually want is to do an extra table layout but that's complicated
<noamr> fantasai: reflowing the spanning cell would be helpful from a user perspective. overflowing is not great. but we can't reflow everything because of perf/complexity. we should align with blink/servo
<noamr> iank_: we haven't implemented safe centering. does servo reflow in the inline direction?
<noamr> oriol: no
<noamr> iank_: overflowing block is better than overflowing inline
<noamr> fantasai: if we go with not reflowing. servo is the most consistent with this. it adjusts the alignment, and will get a good result when fits. blink reflows the spanning cells but not the middle, it's half way this and half way that
<noamr> fantasai: I think servo's behavior is better here. if we want something that reflows, we should reflow all the relevant rows and columns
<emilio> +1
<noamr> astearns: mild preference to avoid reflow because it's not fixing enough to be worth it, for overflow cases
<noamr> astearns: a simpler set of specified steps for edge cases that authors are likely avoid
<noamr> iank_: we have to reflow the collapsed cells
<noamr> fantasai: you can either removed the collapsed cells and adjust the size. or pretend those cells don't exist and reflow the table. halfway is not great
<noamr> fantasai: they can set overflow on the cell
<noamr> iank_: blink behavior keeps text readable if it's in the spanning cell
<noamr> oriol: my mild concern is that doing the blink behavior of reflowing would have extra perf cost
<noamr> fantasai: this was designed for large tables of data. there are usually less spanning cells in those tables
<noamr> iank_: we can also disallow collapsing when there are spanning cells. you have to collapse all the columns and rows affected
<TabAtkins> Given the use-case for spanners in this case could be, like, "large header cell describing multiple columns", reflowing the spanner does seem like the right idea.
<noamr> fantasai: not sure "don't collapse if there's a spanner" is viable
<noamr> kizu: if we add overflow:auto to the spanning cell, it works fine in chrome, in firefox it's just doesn't overflow
<noamr> emilio: this is a known issue, not related to this
<noamr> fantasai: main thing is that you have text-align based alignment it gets fixed up
<noamr> iank_: I would prefer to reflow then
<noamr> fantasai: we have to reflow then
<noamr> astearns: two options, to specify servo's behavior that doesn't relayout. the other is to specify blink behaviors (% the alignment bug) that does relayout
<noamr> fantasai: because of text-align we should probably go with relayout
<noamr> astearns: it also avoids some overflow
<noamr> PROPOSED RESOLUTION: go with blink behavior, fixing the alignment bug)
RESOLUTION: go with blink behavior, fixing the alignment bug
RESOLUTION: go with blink behavior, fixing the alignment bug
RESOLUTION: Spanning cells get relaid out when rows/cols are collapsed
<noamr> github-bot: take up w3c/
[css-logical-1] Order of inheritance vs. mapping in logical properties
<github-bot> OK, I'll post this discussion to w3c/
<iank_> yeah https://
<noamr> oriol: we resolved on this 5 years ago. when you have an inherit on a logic property, it would inherit from the same logical property, even if the physical mode is different
<noamr> oriol: no browser is doing this. everyone resolves logical to physical first and only then applies inheritance
<noamr> fantasai: I can see the argument. I also think it was the right behavior to do. the properties that this affect are not inherited property. not a lot of people do this. I am somewhat inclined to leave current resolution
<noamr> emilio: strong disagree. it's weird that some css wide keywords you affect some properties but not others
<noamr> emilio: in implementations conversion to physical happens before inheritence
<noamr> emilio: I don't see this as being terribly useful
<noamr> emilio: not sure it's worth it
<noamr> kbabbitt: agree with emilio. the resolution was sitting for 5 years. there is additional compat risk. lets spec the current behavior
<noamr> fantasai: ok if we are going with that direction
fantasai: but disagree there's a compat risk
fantasai: super unlikely to use inherit in a logical property across direction changes even if usage was 90%
noamr: logical properties are complicated enough already, let's keep it simple
<noamr> PROPOSED RESOLUTION: specify inheritance works on physical properties
<noamr> emilio: if this affected inherited properties the inherited one would be the physical one
PROPOSED: Logical properties inherit from the parent using physical correspondance
<noamr> florian: how mad are i18n going to be on this
<noamr> fantasai: not a big deal I think? you can also, depending on what you're doing, you *want* the physical prop
<noamr> astearns: let's resolve and find out
RESOLUTION: specify inheritance works on physical properties
<noamr> github-bot, take up w3c/
[css-will-change] Should `will-change: transform` establish a containing block for fixed background attachments?
<github-bot> OK, I'll post this discussion to w3c/
<noamr> oriol: when you set will-change to the name of another property the element would get all the behaviors related to that specify property. in particular, for transform, the spec says that the element establishes a CB for all descendants (abs, fixed, fixed background attachment)
<noamr> oriol: the first two already apply for the first two. but not for background attachment. in does do this in gecko and blink, and not in webkit
<noamr> oriol: smfr said this is a webkit bug
<noamr> oriol: I think should cover this in will-change
<noamr> oriol: there was a discussion on how to deal with it, e.g. just for transform.
<noamr> emilio: also the individual transform properties
<noamr> astearns: does the general statement in the quote match your expectation?
<noamr> emilio: I think so
<noamr> fantasai: all values or just CB/SC creating values?
<noamr> TabAtkins: do create a stacking context there
<noamr> astearns: sounds like we agree about that comment in the last issue
<noamr> PROPOSED RESOLUTION: If any (*) non-initial value of a property would cause the element to generate a containing block for fixed background attachments, specifying that property in will-change must cause the element to generate a containing block for fixed background attachments.
RESOLUTION: If any non-initial value of a property would cause the element to generate a containing block for fixed background attachments, specifying that property in will-change must cause the element to generate a containing block for fixed background attachments.
<dholbert> +1 to the ambiguity around "any" there
<TabAtkins> github-bot, take up w3c/
[scroll-animations?] Proposal: Add overscroll gestures with ability to reveal elements
<github-bot> OK, I'll post this discussion to w3c/
www-archive@w3.org
<vmpstr> thanks
<TabAtkins> flackr: many apps have swiping gestures to pull in components
<TabAtkins> flackr: often a directional meaning, menu on left, etc
<TabAtkins> flackr: in photos, swipe down to dismiss current photo
<TabAtkins> flackr: common thing devs want to do, they're usually handling this with events
<TabAtkins> flackr: we think this is very similar to scrolling in UX tho
<TabAtkins> flackr: movement of finger usually corresponds to movement of a UI component. often chained on a scrolling experience. we already have scroll-snap to talk about sticking
<TabAtkins> flackr: so we want to explore building this declaratively as an interaction
<TabAtkins> flackr: have a couple of ideas
<TabAtkins> flackr: could be CSS or html
<TabAtkins> flackr: the core thinking is it would be done with an ancestor scrolling area
<TabAtkins> flackr: you have content, when yous croll past it you pull in other UI
<TabAtkins> flackr: this creates a natural interaction where you can still access all the content in your scroller, then pull further to get the extra UI
<TabAtkins> flackr: the extra UI needs to be in one of these "overscroll areas"
<TabAtkins> flackr: so our proposal lets you say "my menu wants to be in this named overscroll area"
<TabAtkins> flackr: [shows example of CSS]
<TabAtkins> flackr: I mentioned this feels natural to integrate with scorlling
<TabAtkins> flackr: looking at maps, same action first scrolls in the sheet, then initiates overscroll action to pull in extra content
<TabAtkins> fantasai: [question about how slide 7 example is interpreted]
<TabAtkins> fantasai: what would it mean to say "right: 50%"?
<TabAtkins> flackr: it would be 50% in view
<TabAtkins> fantasai: so is the 'right' property what makes it on the left? if I set 'left: 10px; right: 10px;'?
<TabAtkins> flackr: then there's no overscroll content
<TabAtkins> [more qs trying to figure out exactly what the layout model is here]
<TabAtkins> flackr: we're open to ideas on how to do it better
<TabAtkins> fantasai: what are the use-cases for multiple overscroll into same position?
<TabAtkins> vmpstr: top bar, then pull to refresh after that
<TabAtkins> vmpstr: you keep going and chain into higher levels
<TabAtkins> fantasai: how do you know which one is scrolled to first?
<TabAtkins> vmpstr: [looks at slide] based on scroll areas, they nest
<TabAtkins> vmpstr: based on order of the names in 'overscroll-area'
<TabAtkins> flackr: I have demos based on regular scrollers so you can playl with it
<TabAtkins> flackr: we want to make this easier to build
<TabAtkins> flackr: [explains the demos]
<TabAtkins> flackr: swipe to dismiss has overscroll in three directions
<TabAtkins> flackr: for any of these, we want to make sure there's a way to access the content when you're not on a swipe able device
<TabAtkins> flackr: some thoughts are based on what people do today in native apps or the web
<TabAtkins> flackr: maybe if one element creates the area, that element's label can describe the area
<TabAtkins> flackr: saying "swipe in X direction, you active this component". or maybe it's a button.
<TabAtkins> flackr: maybe a generic announcement about components.
<TabAtkins> flackr: on iOS there's a specific announcement about pull-to-refresh
<TabAtkins> flackr: scroll into view should do what you expect, bringing the area into view
<TabAtkins> flackr: a benefit for doing this in HTML is there's a more natural semantic meaning for the area to express
<TabAtkins> flackr: but there is a pretty tight CSS coupling regardless
<TabAtkins> flackr: many extensions possible. overlay a backdrop to hide content, so a pseudo for that
<TabAtkins> flackr: some cases where you want to push content out of view vs overlay content, want a switch
<TabAtkins> flackr: if you interact with the content you usually want to dismiss the overscroll area, need to define what would cause this
<TabAtkins> flackr: and some physics things to get right. scrolling is sometimes too easy to engage, maybe some stickiness
<TabAtkins> keithamus: looks cool and well motivated
<TabAtkins> keithamus: difficult to do today
<TabAtkins> keithamus: curious, a lot of actions would need to have an equivalent button. a lot of demos show that
<TabAtkins> keithamus: like menu has a button as well
<TabAtkins> keithamus: since engineers will author a button anyway, wonder if we can express this using those button relationships
<TabAtkins> keithamus: won't always have a button, but could imagine pull-to-refresh where ethe overflow content itself is the button
<TabAtkins> keithamus: another rpoint, you talk about aria announcements
<TabAtkins> keithamus: not entirely sure that's necessary (but encourage reaching out to aria), but do think it's very important to get focus right
<TabAtkins> keithamus: curious about semantics of that
<TabAtkins> keithamus: abridged: scrolling gestures need an equivalent button, and focus is very important, maybe the most important a11y thing
<TabAtkins> keithamus: also, overscroll-for in HTML shoudln't have a dash
<TabAtkins> wendyreid: this is very cool, reviewed it during breakout this week
<TabAtkins> wendyreid: I think this presents some concerns about a11y, most have been identified. but also opportunities to make things a lot better
<TabAtkins> wendyreid: a challenge, already in native, is to navigate with a screen reader, you have to go thru all the content. bottom nav you have to scroll all the way down.
<TabAtkins> wendyreid: so I think this gives us the oppo to make shortcuts
<TabAtkins> wendyreid: something to consider might be - an aria prop called 'aria-flowto' that gives alternate nav
<TabAtkins> wendyreid: maybe under implemented because it "sounds good" but unclear how to use it
<dbaron> context for my future comment: snap-to-activate explainer is at https://
<TabAtkins> wendyreid: but yeah, this definitely sounds like should be in html
<TabAtkins> wendyreid: really hard when things get abstracted away, when trying to debug this stuff.
<TabAtkins> emilio: a few qs
<TabAtkins> emilio: how does this compare to native APIs?
<TabAtkins> emilio: do you have a quick answer? if not we can chat separately.
<astearns> if native equivalents have accessibility affordances this would also be useful input
<TabAtkins> flackr: my understanding is the native approach is based on the toolkit, the toolkit usually handles things
<TabAtkins> noamr: we researched this - the layout is different on native. overflow doesn't exist the same way. instead it creates a stack, can stack to the left and right, up and down, above and below
<TabAtkins> noamr: the whole model is this stacked transparencies, very different from how CSS works
<TabAtkins> noamr: but the underlying concept is chained scrollers, and that's the same as css
<TabAtkins> flackr: in manyc cases, you need to bea ble to access the scrolled content first before you pull in a sidebar
<TabAtkins> emilio: in your demos you use scrollers, you can see the scrollbars moving around
<TabAtkins> emilio: so these things don't contribute to scrollable overflow, they're in this overscroll area that you can't normally scroll to...?
<TabAtkins> flackr: they're in the scrollable overflow of an ancestor *pseudo-element*
<TabAtkins> flackr: the dev wont' see an element with the scroll offset
<TabAtkins> emilio: okay so an anonymous scroller
<TabAtkins> emilio: is that a problem - I wonder how that interacts with the scroll APIs.
<TabAtkins> emilio: if I scrollIntoView something in the sidebar, it needs to focus and scroll in anonymous views, but there's no scroll event
<TabAtkins> flackr: ah, forgot to mention we do need to define events for this. because there's implicit snapping, there will be events exposing some of the details
<TabAtkins> emilio: ok. a bit tricky to figure out how much is done magically with anonymous boxes and custom events, or an HTML element with some default styles... I dunno
<TabAtkins> emilio: just a bit worried about a lot of anonymous magic that authors need to udnerstand
<TabAtkins> emilio: just my first gut feeling is a stacked nav element in HTML, maybe
<adamargyle> https://
<TabAtkins> astearns: lets' take this as input
<TabAtkins> adamargyle: posted a link to exploration I did myself, recreating Android ecosystem, very swipey
<TabAtkins> adamargyle: one hidden scrollbar, some exposed ones
<TabAtkins> adamargyle: and a button, not common in OSes but it feels nice
<TabAtkins> adamargyle: I've done research on my own on gesture interfaces, run in script
<TabAtkins> adamargyle: have a q about axis locking
<TabAtkins> adamargyle: in Chrome scrolling is very axis locked usually
<TabAtkins> adamargyle: but swipe to dismiss image gesture is pretty omni-directional
<TabAtkins> adamargyle: script is often used for the customization people want, for physics and smoothness
<TabAtkins> adamargyle: I was curious about how much scroll-snap was used, it was a lot in my demos
<TabAtkins> adamargyle: especially scroll-snap-stop
<TabAtkins> adamargyle: interaction with scroll chaining, which doesn't always stop
<TabAtkins> adamargyle: is there gonna be some kind of overscroll-stop?
<TabAtkins> adamargyle: also good to hear about events
<TabAtkins> adamargyle: there was a proposal the other day that was snap-to-tap [?????]
<TabAtkins> adamargyle: I tap something, that takes it a snap target. noamr presented a swiping that [did something else]
<TabAtkins> adamargyle: is my focus cursor going to discover these areas?
<TabAtkins> adamargyle: also, semantic element. with responsive nature of web, difficult because this is very mobile centric
<ntim> +1 to this being mobile central
<TabAtkins> adamargyle: in CSS you can do all this on demand, only when needed
<ntim> mobile centric*
<TabAtkins> noamr: want to reiterate that we see this as styling, progressive enhancement. shouldnt' change the semantic nature of your page
<TabAtkins> noamr: so this is tied strongly to CSS. a11y challenges, provide hooks to that. might match *with* an HTML semantic, "this action is an overscroll action", action is in HTML but where it goes to is in css
<TabAtkins> noamr: want to start from that design principle
<TabAtkins> ydaniv: 1, I'd expect positioning to be done with anchor positioning, feels more natural
<TabAtkins> ydaniv: could anchor to the viewport
<astearns> (heads nodding)
<TabAtkins> ydaniv: 2, what are possibilities to change animation style, in and out? if it's scrolling I guess it's just scroll-snap and maybe a scroll timeline
<TabAtkins> ydaniv: but if people want to do other things, like coming in as a transparent container...
<TabAtkins> ydaniv: will that be how to customize?
<TabAtkins> flackr: back to Adam, we imagine these areas have an implicit snap to edge
<TabAtkins> flackr: lot of slight extensions to existing features. like don't think this should be axis locked. in a lot of overscrolls you're either constraining to one axis anyway, or just dont' want it locked
<TabAtkins> flackr: making it possible to un-lock a scroller in general is a feature we want to do
<TabAtkins> kizu: big things were already mentioned by others
<TabAtkins> kizu: think for sure we do want to approach this from it being usable without the feature, for a11y, then this is enhancement
<TabAtkins> kizu: something I saw as a footgun is right:100% might be outside of scrollable area, not accessible otherwise
<TabAtkins> kizu: so need to think about how it would work by default
<wendyreid> +1 to testing it
<TabAtkins> kizu: I think snap is pretty good, make some areas and then choose them, when the feature is active you position them, but you can still navigate with mouse/etc
<TabAtkins> kizu: shouldn't rely on authors manually adding a button for non-swiping access, authors often don't add that stuff
<Zakim> dbaron, you wanted to reply to keith with some context about snap-to-activate
<dbaron> https://
<miriam> +1 kizu
<TabAtkins> dbaron: working on a separate but related feature called "snap to activate", which is connected to some of these use-cases
<TabAtkins> dbaron: at this point not as advanced, wasn't ready to present this week
<TabAtkins> dbaron: just discussing right now, not concrete proposal
<TabAtkins> dbaron: but did have a discussion with aria on Tuesday morning. I pasted the explainer
<TabAtkins> dbaron: to respond to some parts of Keith and Wendy's comments, there are pieces of here that do belong in CSS, and some that belong in HTML.
<TabAtkins> dbaron: I think snap to activate is probably mostly in HTML (but not fully worked out yet)
<TabAtkins> dbaron: still early, we've been actively talking to aria
<adamargyle> tap to snap example https://
<TabAtkins> astearns: I wonder if this is something we should have a joint session with aria about
<wendyreid> +1 to joint session, maybe AGWG too?
<TabAtkins> astearns: probably better sooner than later
<TabAtkins> keithamus: maybe OpenUI too
<TabAtkins> astearns: let's keep noodling on this, thanks for the presentation
<TabAtkins> flackr: I think there will also be a lot of sub features that could launch separately, those will be separate issues
<TabAtkins> github-bot, end topic
<astearns> until the top of the hour
<TabAtkins> github-bot, take up w3c/
[css-view-transitions-2][css-conditionals] Exposing navigation/route matching
<github-bot> OK, I'll post this discussion to w3c/
<TabAtkins> dbaron: Noam presented this twice before, in Paris and once at a Telcon since
<TabAtkins> dbaron: back to use-cases
<TabAtkins> dbaron: a bunch of what this is about is having styles that are conditional on the currently-active navigation, or current url
<TabAtkins> dbaron: you might be navigating from URL A to B and want styles that depend on that
<TabAtkins> dbaron: a bunch of the use-cases are related to VT (but this isn't VT itself)
<TabAtkins> dbaron: like, if you want to set up a VT between a list and details page
<TabAtkins> dbaron: so you click the item in the list, it expands to the whole page, VT shows the transition
<TabAtkins> dbaron: and potentially the reverse
<TabAtkins> dbaron: there are other examples like a loading indicator from one thing to another specific thing
<TabAtkins> dbaron: some times these depend on where you're coming from or where you're going
<TabAtkins> dbaron: it's tempting to focus on the link you activated to try and do this
<TabAtkins> dbaron: what we talked about before was conditional rules, conditional on where you're going to or from. we have a spec draft for that
<emilio> https://
<TabAtkins> dbaron: Morten has prototyped a bunch of this in chromium
<TabAtkins> dbaron: not sure exactly how in sync the prototype and spec are right now
<TabAtkins> dbaron: another piece we'd like to add to this is the ability to have pseudo-classes for links that are related to the nav
<TabAtkins> dbaron: hopefully will have a proposal soon, been back and forth in discussion. more complicated than I thought at first
<noamr> https://
<TabAtkins> dbaron: we'd previous talked about this "route map syntax" in HTML, for now we've taken it out
<TabAtkins> dbaron: but fo rnow we're prototyping b y putting URLs into the css
<TabAtkins> dbaron: a function represented URL patterns (based on WHATWG spec)
<TabAtkins> dbaron: what I'd like to get to is getting the group to adopt the draft. there might be qs about where to put it
<TabAtkins> noamr: wanted to quote something from a VT user
<TabAtkins> noamr: "trying to replace the default cross-fade with directional animations, doing without JS right now is like driving without turn signals"
<TabAtkins> noamr: today a lot of people are just cross fading, or otherwise not doing something that gives orietnation
<TabAtkins> noamr: because they'd need JS to actually do it
Maybe less "driving without turn signals" and more "driving without a steering wheel"...
<TabAtkins> noamr: we didn't want to discuss all the open issues here, just want to check that this is a valid use-case and we're going in the right direction
<TabAtkins> noamr: to adopt the draft as ED and continue form there
<TabAtkins> astearns: 1, why isn't the JS solution sufficient?
<TabAtkins> noamr: two reasons. first, this is a styling decision. CSS VT is a styling feature.
<TabAtkins> noamr: second, perf wise, we're trying to avoid event-driven JS when we can, especially in perf-sensitive places like first paint after navigation
<TabAtkins> noamr: using JS, now we have to run script before we can show anything. if we can set it tup in advance in CSS, no need for that
<TabAtkins> noamr: it's also just kinda hard
<TabAtkins> astearns: I just wonder if we want to wait on more author patterns
<TabAtkins> noamr: we've already done that, VTs have been out for two years. this *is* the author feedback about the lack.
<TabAtkins> astearns: my other q was about URL patterns, but your draft answers that
<Zakim> kbabbitt, you wanted to react to noamr to comment further on JS
<TabAtkins> kbabbitt: about JS, less that JS isn't sufficient, it's that the more we can move into the engine the better
<TabAtkins> kbabbitt: some of our perf teams are trying to rip out as much JS as possible
<TabAtkins> lea: I think this is a problem worth solving, authors always talk about how hard routing is
<TabAtkins> lea: could imagine conditionals in HTML based on the route, use-cases in JS based on the route, etc
<TabAtkins> lea: tho it seems you don't want the indirection of naming your route. simple cases you just want to match a single route. then complex cases with lots of routes that you want to use names
<TabAtkins> lea: so it seems useful to have both, names and anonymous
<TabAtkins> lea: since there are use-cases for both, and naming global routes needs coord across the platform, might be useful to do anonymous matching in CSS and then solve route-naming on top
<TabAtkins> lea: also, someone mentioned @document before, would be interesting to see lessons
<TabAtkins> JakeA: @document would have predated URLPattern
<TabAtkins> emilio: it's not particularly complicated to implement, matching a URL can be expensive, but...
<TabAtkins> emilio: I think it just never got enough adoption
<JakeA> (I didn't get to my comment)
<TabAtkins> emilio: I removed it because it was causing some compat pain
<TabAtkins> emilio: we still support @moz-document with an empty URL, it detects Gecko
<TabAtkins> dbaron: the original motivation was for user stylesheets
<TabAtkins> lea: URLPattern in JS has the nice feature where you can extract params form the URL. down the line, might be useful to think about designing to match parameters and use them
<TabAtkins> lea: could solve other problems, like SVG Params spec
<TabAtkins> dbaron: we were actually looking at using URL patterns Params for the pseudo-classes. part of the complicated thing is exactly what to do there, there's multiple things to match between, hard to make ergonomic in CSS.
<TabAtkins> dbaron: part of the reason this isn't ready yet is because I want to figure out the param stuff
<TabAtkins> dbaron: also doing patterns now and route maps later is already what we're thinking
<TabAtkins> JakeA: general support
<astearns> +1 to separating urlpattern()
<TabAtkins> JakeA: perf, relative to a navigation probably not a huge issue to run a little JS
<TabAtkins> JakeA: but wrt back/forward navs, if the Vt has any directionality you want to change if it's a back navigation
<TabAtkins> JakeA: so yes, important to have that doable at a high level
<Zakim> JakeA, you wanted to react to JakeA
<Zakim> fantasai, you wanted to ask about integration with navigation
<TabAtkins> fantasai: I think the draft could use some examples, took a while to figure out what was happening
<TabAtkins> fantasai: I think overall this looks like a reasonable design for the idea
<TabAtkins> fantasai: one thing that through me off was the at-rule being @route, it doesn't declare a route it declares a condition based on the current navigation state of the doc
<TabAtkins> fantasai: so my suggestion is to use @navigation instead, and use @route in the future as the named routing feature
<TabAtkins> fantasai: that would also let you have :route() pseudo matching up
<TabAtkins> fantasai: once I figured out that term confusion it made a lot more sense
<TabAtkins> JakeA: how would that be different from @document if it supported URLPattern?
<TabAtkins> fantasai: @document is the current doc, right? but this condition might be the current doc or the active nav
<TabAtkins> JakeA: I meant about @route
<lea> this is a bit like masonry: route is the term of art, but to those not yet inducted into all this it seems very confusing. I still remember how confused I was when I first heard about routes.
<TabAtkins> fantasai: that's for declaring a named route
<TabAtkins> fantasai: can later do @navigation route(foo) {...}
<astearns> route also sounds like root (depending on the speaker)
<TabAtkins> fantasai: [goes over her :route example again]
<lea> `@navigation` sounds like it's about going somewhere, rather than about where you _are_
It's about the current state of navigation
So yeah, it *is* about going somewhere
<TabAtkins> wendyreid: this also means we can do reduced-motion response, people can turn them off easily if they're in CSS
<TabAtkins> fantasai: that would turn off on the VT side, you can already do that
<adamargyle> can the common case of back navigation being a reverse of the prior view transition, be a single easy opt in instead of needing to intercept or @route declare the intent which plays keyframes in reverse? seems like something like this could work:
<adamargyle> @view-transition {
<adamargyle> navigation: auto;
<adamargyle> backwards: reverse;
<adamargyle> }
<TabAtkins> noamr: I think we had this discussion internally about naming. "route" was a bit of a relic, coming from the HTML history. so this reflects our internal convo
<TabAtkins> lea: echoing from IRC, agree with changing "route". "route" is a term of art, but people not already familiar with it find it weird/confusing
<TabAtkins> lea: I was very confused when I first started learning about this
<TabAtkins> lea: but I also find navigation a bit confusing, sounds like it's about going somewhere or coming from somewhere
<TabAtkins> lea: rather than where you currently are
<Jxck> route mapping json seems quite similar w/ speculation rules.
<Jxck> https://
<TabAtkins> lea: Elika said it *is* about coming from somewhere, but I thought this was most about where you are
<TabAtkins> dbaron: the current proposal has both
<TabAtkins> dbaron: the thing we're probably focused on more is the "where are you going", not "where you are", but it can do both
<TabAtkins> JakeA: these rules apply during same-doc navigations too, right/
<TabAtkins> noamr: yes
<TabAtkins> lea: and the rule can be used for other things than VT
<TabAtkins> noamr: scoping back to what do we need to do to get this into an ED
<TabAtkins> noamr: we're not trying to figure out these issues today
<TabAtkins> JakeA: examples
<TabAtkins> fantasai: yes
<TabAtkins> fantasai: add examples, put in ED
<kbabbitt> +1 fantasai
@navigation (at: urlpattern) {
styles that apply to a page at urlpattern
}
@navigation (from: urlpattern1) and (to: urlpattern2) {
styles that apply when you are navigating from urlpattern1 to urlpattern2
}
@navigation (route: --foo) {
styles that apply when navigation state is --foo
}
@route --foo {
from: urlpattern3;
to: urlpattern4;
}
a: route(--foo) {
styles for link that go from urlpattern3 to urlpattern4
}
a: route-to(urlpattern) {
styles for link that go to urlpattern
}
<TabAtkins> JakeA: what's the lifetime of the @navigation rule? especially with a from()
<TabAtkins> noamr: directly tied to Navigation API concepts
<TabAtkins> noamr: navigation.transition have "from" and "to", it's tied to that
<TabAtkins> JakeA: that doesn't work for cross-document
<TabAtkins> noamr: I have a proposal to fix that
<TabAtkins> noamr: the "from" and "to" starts at the navigate event, "to" changes at redirect and swap
<TabAtkins> noamr: and in the next document, the "to" is only until the first frame
<TabAtkins> JakeA: makes sense
<TabAtkins> noamr: first frame + view transition
<TabAtkins> astearns: so details like that in the draft, examples
<TabAtkins> noamr: so suggesting css-navigation for the ED name
<TabAtkins> astearns: any objections to doing an ED yet?
<TabAtkins> astearns: proposed to start an ED for css-navigation
<TabAtkins> JakeA: I think most important part of this is back vs forward, that's not part of this yet, right?
<TabAtkins> noamr: not at the moment
<TabAtkins> JakeA: okay I think it should be
<TabAtkins> JakeA: [summarizes what he meant again]
RESOLUTION: Start a css-navigation ED
<JakeA> dbaron: https://
<TabAtkins> github-bot, take up w3c/
[css-view-transitions-2] [scoped] What is the layout of the ::v-t pseudo in relation to the scope?
<github-bot> OK, I'll post this discussion to w3c/
<TabAtkins> vmpstr: in scoped VT, reminder it's about VT running on subtrees, not just the document
<TabAtkins> vmpstr: setup is roughly the same, you just start the transition on an element, discover names in the subtree, create VT pseudos representing the transitioning parts of the subtree
<TabAtkins> vmpstr: for document VT we hoist the VT pseudos to the top layer so it can capture the document itself, too, and represent that in its pseudos
<TabAtkins> vmpstr: so we need an equivalent thing for elements. pseudos should be able to capture the hosting element's decorations/background/etc. can't be a child without it being circular
<TabAtkins> vmpstr: so our idea is to have ::v-t pseudo-element be a next-sibling of the VT scope element
<TabAtkins> vmpstr: and then use anchor positioning to put it over top of the scope
<TabAtkins> vmpstr: this works pretty well for a lot of cases
<TabAtkins> vmpstr: one case where it doesn't
<TabAtkins> vmpstr: if the scope element is rotated or not axis aligned
<TabAtkins> vmpstr: anchor spec says the anchor box is the axis-aligned bounding box of the anchor
<TabAtkins> vmpstr: there's a workaround, selfishly hoping the anchor spec can eventually allow positioned elements to be in the same positioned space as the anchor
<TabAtkins> vmpstr: so we'd like to go ahead with the current design of it being the next sibling, and just positioning it over
<TabAtkins> ntim: from an impl pov, a bit worried about making the pseudo a sibling
<TabAtkins> ntim: might have implications in the Dom tree, sounds tricks
<TabAtkins> noamr: it's just in the layout tree, the box tree
<TabAtkins> noamr: reproducing the doc VT case where the VT is in the top layer, a "sibling" to the doc
<astearns> ack +
<TabAtkins> emilio: is the idea that we don't want this in the top layer? we want it clipped by ancestors?
<TabAtkins> TabAtkins: yes, absolutely
<TabAtkins> JakeA: yes, in Shopify days we couldn't use VT in some cases because they wanted a VT on just a small piece of the page.
<TabAtkins> JakeA: they used VT:none on root to prevent that from animating, but then if they had a tooltip on top it would drop below the top-layer VT stuff, so they made *it* VT as well, whack-a-mole
<JakeA> astearns: doh, hah!
<TabAtkins> emilio: if you have something in-flow, and you put something out of flow on top of it, that doesn't quite match the in-flow painting order.
<TabAtkins> emilio: it's painted by the abspos's CB, might be higher up
TabAtkins: We've had some cases where we want to make it easier to select other containing blocks
<noamr> TabAtkins: we want to make it easier to select other containing blocks, e.g. your parent
TabAtkins: in particular, your parent
<noamr> emilio: let's say you have a thing with overflow: clip and animating something inside of it. now you call startViewTransition on that. you effectively created an abs-pos on top. it would escape the clip
<noamr> emilio: clips of any ancestor from the scoped element to the nearest abs-pos
<noamr> TabAtkins: we want to enable it in the future
<noamr> emilio: sounds like it's a bit in the air
<Zakim> fantasai, you wanted to comment on containing blocks
<TabAtkins> fantasai: I don't think anchorpos is the right solution for this
<TabAtkins> fantasai: you really do want to change the CB to this element. not by pos:rel, that is disruptive
<TabAtkins> fantasai: but we should have some way to say that the scope is the CB for that
https: //www.w3.org/TR/css-position-4/#scrollable-cb
<TabAtkins> fantasai: some points to talk about why not do that. scorlling is one. we recently talked about three CBs generated by a scroller, one is the fixed CB, that's what you want
<TabAtkins> fantasai: so there are plans to add switches for that, should rely on that
<TabAtkins> fantasai: for the transform case, when you're contained by the transformed element you're in it so you're transformed with ti
<TabAtkins> vmpstr: the problem here isn't so much positioning, as trying to capture the effects on the scope itself
<TabAtkins> vmpstr: like a filter on the scope, the pixels you capture from that filter have to go into the VT pseudo-element. if that pseudo is also a child of the filter, then you're double-filtered
<TabAtkins> vmpstr: or circular if you want to prevent that
<flackr> not being filtered by the element, not being clipped by the element, etc
<TabAtkins> vmpstr: so it's less positioning, more about not being in the same filter tree/effect tree as the scope
<TabAtkins> ntim: back to DOM mutations
<TabAtkins> ntim: say you move the scope element elsewhere in the tree. do you track the pseudo and move it at the same time?
<TabAtkins> ntim: otherwise you get z-order issues
<TabAtkins> TabAtkins: moving is a remove/add, so you cancel everything
<TabAtkins> JakeA: no, new method just moves it directly
<TabAtkins> noamr: just need to make sure that's an issue we track
<TabAtkins> flackr: yeah, confirming that this can't be a box child so we don't clip/filter it
<TabAtkins> emilio: I wonder, if you make this API parallel to the doc version, the doc version isn't in the doc itself, but the contents of the document
<TabAtkins> [not sure what that means or if I minuted it right]
<TabAtkins> emilio: instead of capturing the whole scope, you capture just the contents of the element, then the issue goes away
<TabAtkins> JakeA: my first draft did that, people just end up creating a wrapper div
<TabAtkins> vmpstr: we did consider that, but a very common use-case people do is "run on a div, change its background". but that won't work, background is part of the element itself not its contents
<TabAtkins> vmpstr: so we're really trying to make it so the scope itself is represented
<TabAtkins> emilio: I wonder if we could define, rather than a sibling, it's a regular child but define special painting/capturing rules, in a VT the stacking context your box creates is in one place...
<TabAtkins> emilio: so the pseudo isn't a sibling in the box tree, but in the stacking context sense. one order that's for capturing VT, another for actual rendering
<TabAtkins> emilio: that solves layout issues, unsure if it adds more complications
<TabAtkins> emilio: but this is similar to what you do for the doc transition to capture the canvas background/etc
<TabAtkins> vmpstr: i'm not opposed to that, it's just more magic
<TabAtkins> vmpstr: it's more *explainable* with anchorpos, while this is pure magic. but I'm fine with that
<TabAtkins> noamr: initially this was my mental model, an anonymous container that holds the element and the VT pseudos
<TabAtkins> emilio: yeah, same way you can define the order in which stacking contexts are applied, you can define filter/transform/opacity, etc in a particular order to be correct. can define VT at a particular spot so it's outside the filters but within the element still.
<TabAtkins> noamr: only thing is it's less explainable in CSS terms
<TabAtkins> emilio: but still the same as the doc VT, yeah? doc transitions capture the canvas background, that's outside the document element. so I think this matches doc VT more closely.
<TabAtkins> emilio: if it makes the whole setup simpler should just do it
<TabAtkins> vmpstr: difficult part would just be describing transforms/etc. doc is affected by less than elements are.
<TabAtkins> emilio: sure
<TabAtkins> vmpstr: I think it's doable, just a little awkward
<TabAtkins> emilio: do you know off top of you head if transform is before or after filters?
<TabAtkins> emilio: [goes into a little more detail]
<TabAtkins> emilio: I find that model a bit easier, or more parallel to doc VTs
<TabAtkins> fantasai: makes sense to me
<TabAtkins> emilio: like if you apply filter to root, it doesn't just apply to root it applies to whole doc. but doc VT escapes that.
<TabAtkins> vmpstr: I also need to think through how the VT pseudos can be styled
<TabAtkins> emilio: same as in doc VT, the pseudo isn't affected by the VT styles
<TabAtkins> JakeA: btw, it's filter *then* transform
<TabAtkins> emilio: so yeah that works, transform is applied on top after the VT is already positioned, so it follows along
<flackr> +1 that sounds like it could work
<fantasai> +1
<TabAtkins> astearns: so sounds like a different route. Vlad, do you want to explore implication in the issue, or just take a resolution?
<TabAtkins> vmpstr: might as well resolve, if we have issues we'll bring it back
<TabAtkins> vmpstr: resolution is to make the VT have a stacking context that's a sibling of the scope stacking context, but painted at a point before transforms/filters. Still a child of the box tree.
<TabAtkins> emilio: should we enforce the scope to be a CB for abspos? if you start a VT on a staticpos, the insets wont' work
<TabAtkins> noamr: it's layout-contained, that already makes it a CB
<TabAtkins> kush: I was trying to understand - if it's a sibling in the box tree... sorry, a child, but it's painting involves all the content besides itself
<TabAtkins> kush: does it get the local clips?
<TabAtkins> emilio: probably not. ancestor clips apply, but on the element itself won't
<flackr> it should only be affected by the transform of the element
<TabAtkins> emilio: it'll be a painting layer defined,
<TabAtkins> kush: q is just if we make it a child of the scope, how many things that are inherited from the scope will have to be handled special
<TabAtkins> emilio: fair, but all those special things are what you want
<TabAtkins> kush: right, but we got all those special things for free by making it a sibling, they're manual now that it's a child
<TabAtkins> emilio: but many other things are easier as a child
<TabAtkins> vmpstr: what I think we really want is the scope to be the child of the VT
<TabAtkins> vmpstr: but that's... complicated
<TabAtkins> astearns: we're at time. should we not resolve yet?
<TabAtkins> kush: taking resolution seems fine for now, curious about what we'll learn impl wise
<TabAtkins> kush: i'm on the same side as Emilio, argued for that in my head, but other than moving the pseudo alongside the element, what am I gaining by the child approach rather than sibling?
<TabAtkins> emilio: you also get abspos CB for free, rather than it escaping all the clips up to its actual abspos CB
<flackr> +1
<TabAtkins> astearns: this is details. back to the question. objections to the proposed resolution?
RESOLUTION: make the VT have a stacking context that's a sibling of the scope stacking context, but painted at a point before transforms/filters. Still a child of the scope.
[css-multicol-2] column-height:0
<TabAtkins> rachelandrew: Noam asked if column-height:0 is allowed.
<TabAtkins> rachelandrew: not really a reason. Grid floors at 1px
<TabAtkins> rachelandrew: so probably what we want to do too
<TabAtkins> florian: agree.
<TabAtkins> florian: so there's no restriction at syntax level, but floor at layout time
TabAtkins: We do syntax restrictions all the time, could do 1px+ range which would still be closed range
<dbaron> There's a precedent for this with the perspective property and perspective() function.
<TabAtkins> dholbert: I weakly like having column-ehight:0 available for testing, useful for test printing
<TabAtkins> dholbert: can end up with printing with zero content area
<TabAtkins> dholbert: we make progress by putting *something* on the page
https://
"To guarantee progress, fragmentainers are assumed to have a minimum block size of 1px regardless of their used size."
<TabAtkins> dholbert: so like *supporting* height:0
<TabAtkins> ntim: if the restriction is at syntax level, what about calc()?
TabAtkins: Same as we handle 0px today
TabAtkins: clamp at used value tie
<TabAtkins> fantasai: we already have a rule that says fragmentatiners are assumed to have a min block size of 1px, regardless of used height
<TabAtkins> fantasai: we already have this case if the Multicol container itself has height:0px
<TabAtkins> fantasai: but each column will assume it's 1px high
<TabAtkins> fantasai: so we can do this clamp whenever. computed time, used time, or not at all and rely on the fragmentainer always laying out 1px of ontent
<TabAtkins> astearns: I have concerns with relying on fragmentation module, there are layout concerns that aren't necessarily fragmentation concerns
<TabAtkins> astearns: i'd rather have things clamped before we start layout
<TabAtkins> emilio: we'll have to clamp at used-value anyway, is there any benefit to restricting at syntax time?
<TabAtkins> emilio: if not i'd prefer to handle it at layout time
<TabAtkins> fantasai: I think key question is just whether the layout height is 1px, or just the fragmentation height?
<TabAtkins> florian: I think layout height.
<TabAtkins> s/min block size of 0px/min block size of 1px/
<TabAtkins> florian: even if there's overlap, you can at least see progress
<TabAtkins> plinss: want to agree with Elika/Emilio, handle it at layout time rather than syntax time
TabAtkins: We have lots of 0px restrictions, it's well-defined
<TabAtkins> astearns: so clamping to 1px at used-value time?
<TabAtkins> fantasai: yes
<dholbert> +1 to what plinss said
<TabAtkins> plinss: I think used-value time is even too early. let it be zero, require progress
<ntim> +1 to what plinss said
<ntim> +1 to what dholbert said about what plinss said
<TabAtkins> fantasai: proposed resolution: allow to be zero, let fragmentation spec ensure progress
<TabAtkins> astearns: I disagree but won't object
<TabAtkins> florian: same
<TabAtkins> plinss: I think that's the right concept
<TabAtkins> florian: can we poll? we agree it's not syntax time, want to see what our actual pref is
RESOLUTION: allow to be zero, let fragmentation spec ensure progress
[css-multicol-2] `column-wrap`, `column-height` and column balancing
<rachelandrew> w3c/
<TabAtkins> rachelandrew: this is about this particular comment, not rest of issue thread
<TabAtkins> rachelandrew: we resolved, if there's not enough content to fill a column-height, you'll still get the specified height
<TabAtkins> rachelandrew: Morten points out that this can disable column balancing, if you've got all the height you can put all content in the first column
<TabAtkins> rachelandrew: think this isnt' what we want
<TabAtkins> rachelandrew: but it would mimic what happens in normal Multicol; if you've got more space you can still balance
<TabAtkins> florian: did you suggest that the row stretches to fill the space but the line wouldn't?
<TabAtkins> rachelandrew: we've got the columns themselves, then the content inside. if you stretch both it disables balancing effectively
<TabAtkins> rachelandrew: we dont' want that
<TabAtkins> rachelandrew: I think what we want here is MOrten's Option B
<TabAtkins> fantasai: if you run out of space before a spanner... never mind
<TabAtkins> astearns: objection to going with option b?
<TabAtkins> florian: there's lots of details in the issue, it's subtle. *if we assume* that what's discussed here in the room is sufficient, then I agree with B.
<TabAtkins> astearns: If there's re implications we missed, Morten will bring them up
RESOLUTION: go with option B (balancing still works)
<TabAtkins> github-bot, take up w3c/
[css-multicol] Clarify the section on Pagination and Overflow Outside Multicol Containers
<github-bot> OK, I'll post this discussion to w3c/
<TabAtkins> rachelandrew: we've made various resolutions, i'm having to make all the rest of the text makes sense now that we have column rows
<TabAtkins> rachelandrew: I've written in the issue what's there at the moment and what i'm suggesting
<TabAtkins> rachelandrew: this is a change in normative text, so getting verified
<TabAtkins> florian: looks right. we're generalizing the concept, so things need generalization. looks good
<TabAtkins> fantasai: needs better lienbreaks, but otherwise looks good
<TabAtkins> proposed resolution: accept Rachel's text/direction
RESOLUTION: accept Rachel's text/direction
lunch
<Euclid> +present
nicolo-ribaudo: source maps, does anyone here know what it is?
<kbabbitt> github: w3c/
nicolo-ribaudo: recap, mostly for JS but also now for HTML
… you write some code and then go through build tools
… more and more the code you write is not what ends up in the browser
… source maps have been around for some time now
… they are instructions for build tools
… to make sure the code in browser looks like what you wrote in editor
… there's partial description in a google doc of what it does
… in ECMA we started defining it, and talking with browser dev teams
… where is it still problematic
… evolving the idea
… maybe you're using SASS or others and they do create source maps
… we should also try to focus on what can be done in CSS
… is ti just for build tools?
… what can we do more for CSS? ...
… one is nesting, that may be transpiled
… there are other bunch of build tools features that transpile
… I'm preseting this here because I think this transpiling may be confusing for authors
<astearns> the namespacing we just talked about might also be a use case
nicolo-ribaudo: could be great if we could work this out together
… find if we have dev experience issues
… if ppl have opinions
kizu: would be great to have
… a lot of it is not actually CSS, like comments etc.
… the source for things in CSS may not be just CSS itself, may come from JSON or JS
… [examples]
… also may come from [missed]
nicolo-ribaudo: it's something you can do with source maps ideally
TabAtkins: you mentioned some features, like nesting
… it's not only transpiling things that can't be, it may be also things from JS,
… also there's a lot of source transforms that can't be done
nicolo-ribaudo: to be clear, there's no one with CSS experience
… so happy to see others for helping out
miriam: because transpiling is in external tools, would be nice to reach out for those tool makers
kizu: tailwind is intreresting, the source is in CSS but tranforms to HTML
nicolo-ribaudo: if you want to see the slides we have contact info there
… thanks!
emilio: you have comment syntax there, is that what would be strandardised?
nicolo-ribaudo: yes
… there are ppl from FF dev tools on there
astearns: thank you, moving on
w3c/csswg-drafts#12803
<ntim> github: w3c/
fantasai: going back to item flow discussions we had previously
… there's been discussion on what the syntax should be
… TabAtkins and iank_ said we should not go with what grid does
… this is blocking impl. work
… we still need to decide what longhand do
… we need to underlying longhands
… we need to resolve on what they are? what the values are? and shorthands later
… we have a proposal with counter arguments
… we have to decide are using grid properties, or minting new ones
… what are those properties? what are the values? and what they're mapped to?
… also discussed about "auto" initial value for the flow direction, to automatically decide based on the -template properties; but this needs to be renamed (maybe to normal) to avoid conflicts in grid shorthand with 'auto' track sizing
TabAtkins: I'll present while reusing grid-auto-flow is not correct
… if you want grid-lane layout fallback specified with @contents
<miriam> I think 'waterfall' in this case refers specifically to vertical grid-lanes
<astearns> yes
<emilio> TabAtkins: to avoid confusion we've referred to waterfall and brick
<emilio> ... if you have a waterfall layout you have columns, that's also the initial value because it's the most common initial value for grid-lanes
<emilio> ... grid-auto-flow initial value is row
<emilio> ... so we'd need to magic up a new initial value
<emilio> fantasai: which we planned to do anyways
<emilio> TabAtkins: not for grid
<emilio> ... secondly grid-auto-flow, row vs row-reverse, they change whether items autoflow ltr or rtl
<emilio> ... in grid-lanes a lot of people have the intuition that the primary direction should be the direction where they break ties
<emilio> ... you'd start rtl again even with a column layout
<emilio> ... so if we reuse grid-auto-flow, row-reverse would mean a different thing than in grid-lanes
<emilio> ... would mean perpendicular axis
<emilio> ... because you want columns to be ltr columns and column-reverse to be rtl
<emilio> ... in grid your default is row / row-reverse
<emilio> ... if you say column that means top to bottom or bottom to top
<miriam> almost makes you think we should call it the same thing as in grid…
<emilio> ... this is due to the distinction between flow direction and track direction. In flexbox and grid they are aligned in masonry they are opposite
<emilio> ... so reusing the same terms that mean track / direction in grid but giving the keywords a perpendicular meaning doesn't seem good to learning how these work
<emilio> ... it might be if waterfall layout was rows
<emilio> ... but it's not
<emilio> ... so we should mint a new property
<emilio> ... grid-lanes specifically
<emilio> ... so I think we should do that instead of changing the meaning of specific values in grid-lanes masonry
<emilio> astearns: this felt two introductions about two different topics
<emilio> ... let's go through the queue and see if we can get some clarity
<emilio> florian: my initial impression was a bit similar to tab in the sense of of course waterfall should be column
<emilio> ... but looking at it I don't think we're calling it anything
<emilio> ... we're controlling aspects of the design
<emilio> ... so sure if you look at it I see columns
<emilio> ... but even then depending on the property I'm comfortable saying that the flow of the items in a waterfally grid-lane goes by row
<emilio> ... and that seems fine to me
<emilio> TabAtkins: if the thing that determines the direction uses rows for masonry which uses grid-template-columns etc for everything
<emilio> ... I'd formally object to that
<emilio> florian: just saying that I used to have the same opinion, but no longer do
<oriol> I agree with Tab it would be super confusing
<emilio> TabAtkins: I'd formally object to that
<emilio> ntim: re. flow vs track
<emilio> ... I think that track direction doesn't really matter, ATs what you experience is the flow direction not track direction
<emilio> ... if you really care about track and ?? then you use multicol
<emilio> ... I'd probably object if we were to consider the track direction was the primary one
<emilio> miriam: Thanks for not taking into account our opinions
<emilio> ... you wanted us to follow up, we did, we disagree with you and now it's a formal objection situation
<emilio> ... have no power in that situation, that's cool, have fun with it
<emilio> astearns: I'm with you in the frustration but you can formally object as a member of this group
<emilio> fantasai: you don't even need to be a member, anyone can literally formally object
<emilio> ... I want to present my position and counter proposal
<emilio> ... we think that keeping the properties consistent with grid is better
<emilio> ... therefore we should use grid-auto-flow, and interpret the values in the same way
<emilio> ... if you switch display the overall layout would flow in the same direction
<emilio> ... TabAtkins mentioned that he wants a shorthand
<emilio> ... and if you write row 200px
grid-lanes: row 100px 200px;
grid-template-columns: 100px 200px;
<emilio> ... which would be confusing
grid-auto-flow: row;
<emilio> ... I have several suggestions
<emilio> ... first one is we've discussed grid-auto-flow initial value would be normal
<emilio> ... and depending on grid-template-rows/columns we'd pick the correct flow direction
<emilio> ... whichever one is none picks the flow direction
<emilio> ... now grid-lanes sets grid-template-{rwos,columns,areas} and grid-auto-flow, ... either to the initial value or something else
<emilio> ... I suggest changing grid-lanes to instead of `row` being a grid-auto-flow
<emilio> ... value, we'd change it to `rows`
<emilio> ... and then set grid-template-rows
<TabAtkins> my point is and has been that *this* would be a terrible mistake that I can't allow as editor of the spec:
<TabAtkins> .waterfall {
<TabAtkins> display: grid-lanes;
<TabAtkins> grid-template-columns: 100px auto;
<TabAtkins> column-gap: 1em;
<TabAtkins> column-rule: thin solid silver;
<TabAtkins> grid-auto-flow: ROW????!?!?
<TabAtkins> }
grid-lanes: rows 100px 200px;
grid-template-rows: 100px 200px;
grid-template-columns: none;
grid-auto-flow: normal;
<emilio> fantasai: I think that resolves the biggest syntactical problem
<emilio> ... instead of saying what the auto-flow value is, it decides which template prop we set
<emilio> ... the shorthand also becomes useful for grid layout
<emilio> astearns: Is that proposal in the issue?
<emilio> fantasai: thought of it a bit too late
<emilio> astearns: we should've deferred this then
<emilio> ... to give people some time to look at it
<emilio> fantasai: last part is what about grid-auto-flow
<emilio> ... currently it takes {row, column, dense}
<emilio> ... recently we introduced reverse-*
<TabAtkins> [ row | column ] || dense
<emilio> ... we think we should have a consistent interpretation
<emilio> ... I think most people don't need this property on grid-lanes except if you're doing reversing
<emilio> ... we have row-reverse | column-reverse || wrap-reverse
<emilio> ... so that's confusing, but also the interpretation of row and columns is confusing
<emilio> ... so I think it'd be clearer if we named the keywords as primary-direction followed by secondary
<emilio> ... so grid-auto-flow: row-column | column-row
<emilio> ... so you can do [row | row-reverse] || [column | column-reverse]
<emilio> ... so I think that might be a bit more straight-forward
<lea> +1 for reusing `grid-auto-flow`
<emilio> ... altogether, main point I want to put forward is that grid-lanes should have a keyword representing the suffix of the template property
<emilio> ... and we should reuse grid-auto-flow matching grid
<emilio> ... I think that addresses most of the key points on both sides of the argument
<ntim> what is primary vs secondary?
<dholbert> For the part with primary direction followed by secondary direction, I'm a bit uneasy that folks will forget what primary/secondary are here (similar to how waterfall is sort-of rows but nobody thinks of it like that)
<emilio> alisonmaher: +1 to alan, would be useful to see this in the issue
<emilio> ... I think it's a promising direction
<emilio> ... but there are a few side effects
<TabAtkins> yeah, this entire idea is new to me, and I don't think it solves several of the issues. take to the issue.
<ntim> Is primary the flow direction? and secondary the track direction?
primary is the first direction you go, secondary is the second direction you go
<emilio> ... afaiu right now `grid-lanes: rows none` you'd get a columns lanes with the template of none
<emilio> ... which means you can't have a row-based masonry without a track definition
<emilio> ... we could potentially handle this with some grid-lanes-orientation thing or something
You can, you would use grid-auto-flow, just wouldn't use the shorthand
<emilio> ... and that'd always tell you which one to use
grid-auto-flow *is* the orientation controlhere.
<emilio> ... the other one is reusing grid-auto-flow would be a bit weird
<emilio> ... so grid-lanes: columns and grid-auto-flow: column, it won't do anything because in masonry you can't have your flow items in the column direction when ??
<emilio> fantasai: it can, the default auto-flow chooses based on templates, but non-initial values you get what you asked
<emilio> alisonmaher: I think it'd be clear if we had a grid-lanes-flow
<emilio> florian: I understand the proposal is very fresh but I think it's useful to discuss it
<emilio> ... it came out from the fact that we're at TPAC, this is an issue that needs solving and the ability to talk about this is great
<emilio> ... even if we don't resolve I think it's important to discuss this to get it unstuck
<emilio> ... I'd need more time to think about part 3 because that's very fresh
<emilio> ... 1 and 2 make a lot of sense to me
<emilio> ... we get around TabAtkins and ntim's formal objection
<emilio> ... because you use columns to define grid-lane
<emilio> ... and the low-level controls is mostly automatic but when it's not it does the thing ntim wants
<emilio> ... but I'm optimistic
<emilio> astearns: let's discuss this during the break
<emilio> ... I think throwing around formal objections was inappropriate and unproductive
<emilio> TabAtkins: was just repeating my words from a few weeks ago
<emilio> astearns: I hadn't put it on the agenda because I knew we weren't going to get anywhere, but I readded I got told we'd talk about smaller topics
<emilio> fantasai: we did
<emilio> astearns: anyways for now hallway conversation, let's go back to mixins for a bit
github-bot, take up w3c/
[css-mixins-1] Do we really need the `@contents` parameter?
<github-bot> OK, I'll post this discussion to w3c/
TabAtkins: currently in the spec, mixins can take number of args
… can also take a nested block, you can sub that in mixin
… with media query to apply, other reasons as well
… question here is how to declare how this is done
… the current spec is how you declare the argument in the list, you declare the contents in the args list as well
… some ppl don't see the point of this, other than declaring, current spec doesn't allow other things to do
… like typing
… literaly it's just about declaring the contract
… but enough ppl are not liking this and we'd like to make it be passable all the time, so maybe remove it from args list
… if you do pass it then allow but doesn't do anything
… there are suggestions to retain some of it, like to allow passing ony if mixin uses one
… like for debugging by replacing contents,
… if we wannt go this way, than not objecting to always alllow passing it
… so proposing removing it from args list and always allow passing
<lea> I was just in the queue to +1 but if there are no objections, there's no point to spending time arguing why the +1
<kizu> +1
<lea> +1
<kbabbitt> +1
<miriam> +1
miriam: +1
proposed resolution: remove @contents block from the args list
lea: if you don't use it in the mixin it's empty
TabAtkins: yes
astearns: seeing approvements
kizu: if you have a mixin with @contents that have some malformed decls inside, if you call it without braces then it's replaced by the content
TabAtkins: correct
lea: would be nice to have a way to pass default contents to be used when the mixin is used without contents
astearns: other things to add?
… obejctions?
TabAtkins: there is, you just add a block
RESOLUTION: remove @contents block from the args list
astearns: objections to always allowing to pass @contents block?
RESOLUTION: always allow passing @contents block
github-bot, take up w3c/
[css-mixins-1] A var()-based model for mixin parameters
<github-bot> OK, I'll post this discussion to w3c/
TabAtkins: just intro-ing this topic
… current spec for mixins, for some reasons, it has to handle args to mixins in speciial way
… can't just use var(), becaue the body is passed to another rule and you don't want to pollute other stuff
… so I difined a new idea of scope
… it kanda works, have some issues
… and we thought of another idea
… effectively when you apply a mixin, we do a funky inversion where you end up with a lot of anonymous functions in the leaf property values
… where you have a behavior where they interleave in a nice way
… so not inventting a new way to invoke funcitons
… makes it work substantially better, may have some odd implications
… helps a lot with caching
… we used YOUTUBE as test case
… so letting ppl know that we're experimenting with it, very happy about it internally
<kizu> +1
TabAtkins: if there are no objections, would like to change spec to this new model
lea: based on this summary, not sure what is proposed
… very hard to say whether we object
<ntim> +1 to lea
TabAtkins: this is just an intro
… in the linked issue there are more details
<fantasai> +1 to lea
miriam: I think would be helpful to have comments on implications, not just impl. details
TabAtkins: the author facing implications, A: not introducing a new arg for custom funcs and var, they look similar
… B: this makes variables passed to mixins work better, to some extent
… in most cases did not work in previous model
… there are some limitations still, like how geenric macro works
… but upshot is, in general case, maybe all, passing variables in should work
… and same authoring model
<Zakim> miriam, you wanted to finish my thought
miriam: and there are also implications that you can only impact decendants?
TabAtkins: not necessarily, if I want to add a restriction that it acts like it's scoped
… if you don't apply it then, if you select above or siblings, they may work differently
… it's a bit of a footgun if you want to allow unscoped mixins
<Zakim> fantasai, you wanted to ask what impact this has on people using mixins
miriam: will have to look into it more
fantasai: what is the look path for foo variable?
TabAtkins: similar to custom functions, mixins also introduce hypothetical elements
… so if you in the simple cases ...
fantasai: from the element you apply from?
TabAtkins: this comes to discussion on scoping or not
fantasai: if I take a code block and apply a mixin, if I ask for element foo do I get same element? or looking it up on the applied?
TabAtkins: you first use where you apply, the walk up the tree
astearns: we have this proposal, and impl behind flag you can try out
miriam: we can play with it in canary?
TabAtkins: yea
astearns: moving on
github-bot, take up w3c/
[css-mixin-1] How does Shadow DOM influence mixin lookup?
<github-bot> OK, I'll post this discussion to w3c/
github-bot, take up w3c/
[css-mixins-1] Expose environmental variables inside apply's contents block
<github-bot> OK, I'll post this discussion to w3c/
kizu: this depends on change from env vars to regular vars, moving to env vars simplifies things
<TabAtkins> look at this example:
<TabAtkins> @mixin --test(@contents) {
<TabAtkins> --foo: pink;
<TabAtkins> @contents;
<TabAtkins> }
<TabAtkins> button {
<TabAtkins> --foo: lightgreen;
<TabAtkins> @apply --test {
<TabAtkins> background: var(--foo);
<TabAtkins> }
<TabAtkins> }
kizu: you can use custom props inside, and means that if you define them they are args to the mixin, and will be invisible inside it
TabAtkins: posted an example, mixin that sets foo
… the element also sets foo
… question is which color does it see? the one from the mixin sub?, can mixins shadow vars?
kizu: in my opinion it's useful, however, if we want to explicitly say differently, when you look at the applied value from the side you don't know which one it will be
… so either we could either use the one inside, but by default would be more useful to use the one outside, a bit confusing
TabAtkins: in this example it ends up light green
<ntim> my intuition would be either use inner, then outer (if inner is absent).
<ntim> failing that, ignoring both is an option
TabAtkins: agree it's possible the most obvious thing, content styles look more local, and if you have nested rule
… you wouldn't want to change behavior
kizu: I think it's actaully pink there
… because if you use it this way, because it's a registered custom property
<kizu> https://
TabAtkins: you're right, if the mixin took that var...
<kizu> @mixin --test(@contents, --foo: pink) {
<kizu> @contents
<kizu> }
<kizu> button {
<kizu> @apply --test {
<kizu> background: var(--foo);
<kizu> }
<kizu> --foo: lime;
<kizu> }
miriam: I think you're getting confused between what happens in impl and what we want
TabAtkins: yes, exactly
kizu: hard to tell from where something would come, and need to resolve it in some way
TabAtkins: in this example don't care about impl.
… so ideally should not be pink?
kizu: yes
<miriam> `@apply dark-colors { background: var(--from-mixin); }`
miriam: I agree we should with this, but counter for that I know in SASS it's different, where you have a mixin that defines stuff and then you psas a block and want an access to that
<fantasai> +1 miriam
miriam: but agree that the default case would not be that
<kizu> `@apply dark-colors using all { … }` maybe?
TabAtkins: in that case this behavior would be supported
miriam: ok
astearns: had an explanation... but now confused
TabAtkins: proposing for this behavior a contents block will see vars defined in the body of mixin,
… but it will not see ones defiend in args
miriam: in several examples there's an @local
TabAtkins: a local var acts a like arg but just not listed args list
miriam: in SASS that would not change the outside vars and access the inside, would that be possible?
… not sure how important
kizu: I opened about this, regarding env vars, how do we access them
TabAtkins: it's still possible for us to add syntax for that
<Zakim> fantasai, you wanted to ask about the earlier example
fantasai: you had an example before, the contents passed in would have access to sutff in the body, but not parameters
TabAtkins: yes
fantasai: in that case the vars would be part of the output of the mixin
… so if you wanted a set of vars that put in the mixin, then you would need to overide those say vars on where the mixin is used?
TabAtkins: yes
… currently yes
<ntim> It would be really useful for these kinds of issues to have all the possible combinations listed somewhere as a comment on the Github issue. Having to think through the combinations in your head highers the bar to contribution.
miriam: that's what I was saying, we could have extra syntax for that
TabAtkins: yes
astearns: more qs or examples?
TabAtkins: I think we got what we need
… folks think it's a good behavior, got approvals
kizu: we should resolve after another related issue
I guess one of the advantages of env() was that it could be clearer about what resolves against what
astearns: would like to get detailed examples of what we just talked about in the spec and why it works this way
TabAtkins: yes
<kbabbitt> +1 astearns
TabAtkins: I can do that
ntim: I think this issue is hard to reason about, right now trying to think about it and combinations and it's hard
TabAtkins: fair enough
astearns: moving on
<ntim> (and we should get examples of combinations written on the issue)
github-bot, take up w3c/
[css-mixins-1][css-values-5] The inherit() function in custom functions
<github-bot> OK, I'll post this discussion to w3c/
TabAtkins: about custom functions
… in there, if you write results: inherit, it just makes the function resolve to inherit
… similar to a var() with a fallback of inherit
… the behavior is idnetical on purpose
… but we don't define inherit function to have the same sort of behavior
… so proposal is let's do that
miriam: 2 questions, why is that true only about inherit?
TabAtkins: we currently don't have other functions for other keywords
miriam: so question why only inherit gets pass through
TabAtkins: all global keywords gets passthrough unchanged
kizu: css keywords do pass but function not
miriam: we're saying the function doesn't pass through in results
TabAtkins: yes
<TabAtkins> @function --foo() { result: inherit(--bar); }
TabAtkins: this is the case we're talking about
… this is different from inheting a var, the function should work the same way, there are use-cases for both
miriam: how does this interact with last conversation
… the var doesn't inherit from an arg that's passed in
TabAtkins: if we don't get a special behavior it would get value from the element, like a bare inherit
<miriam> +1 to the proposed change
astearns: anyone else?
TabAtkins: kizu I suppose you +1 too?
kizu: yes
<TabAtkins> proposed: in `result: inherit();`, the inherit() is treated the same as a plain `inherit` (passed thru and only resolved on the actual element)
astearns: objectsions?
RESOLUTION: in `result: inherit();`, the inherit() is treated the same as a plain `inherit` (passed thru and only resolved on the actual element)
github-bot, take up w3c/
[css-pseudo] Add a property to the `CSSPseudoElement` IDL interface to retrieve pseudo argument(s)
<github-bot> OK, I'll post this discussion to w3c/
<sakhapov> sakhapov
sakhapov: some context, we have pseudo interface for proxy for pseudo elements
… this object always exists
… it's just a proxy element, not a real one, even if you don't render anything
… when you pass in a selector, can have args, question is how define properties to get the args of the pseudo element
… in the last comment on the issue I have a suggestion
… we do .arguments to return a list of args, or just null if none
… so that this returns a normalized text and can round-trip
… maybe someone has objection to naming?
TabAtkins: I think these are all good, good design, this can't be a sequence OM string
… I'll help to fix
emilio: this makes sense but, don't think we should call this an identifier, it's not that, don't have a better idea
… don't have on arguments vs. parameters
… do we have a precedent for that?
TabAtkins: don't know
emilio: so could be either way
TabAtkins: I don't know what we do in CSS
<ntim> css-highlights/css-pseudo/css-view-transitions probably have examples
emilio: bikesheding aside, selector text identfier aside, looks good
<kbabbitt> ::highlight uses "argument" as well
astearns: what do we use for selector for a rule in CSSOM?
emilio: selector text, might be a better name
sakhapov: question about scroll buttons, whether should be logical or physical
emilio: separate issue
… I don't know if those things alias eachother, probably discuss separately
astearns: I hear we're agreeing on a type, arguments, selectorText and separate issue for scroll buttons?
emilio: if you called .pseudo and pass a selector that could select multiple things should not be allowed
… the point of these are to get specific elements, so should probably just throw
… for the logical vs. physical it's a bit tricky
sakhapov: we can discuss separately
<astearns> Proposed resolution: use type, arguments, selectorText
emilio: arguments seems fine
astearns: kbabbitt said there is precedent
astearns: objections?
sakhapov: for the pseudos only one argument still return a list
"Parameters refer to the variables listed in a function's declaration, defining the input that the function can accept. Arguments, however, are the actual values passed to the function when it is called, filling the parameters during execution."
TabAtkins: currently all have one
ntim: if we have ones without args,
… I think it's a bad pattern to have multiple args but to point to one thing
emilio: imagine we had a pseudo element for corners
[cross talk]
TabAtkins: arguments is a good name for this sort of thing, we will in the future have an element with multiple args
fantasai: I think we have it just return a string
TabAtkins: I don't want to have to deal with that legacy later
florian: we've done this before and not fun
TabAtkins: in CSS all concepts that deal with multiple args have comma separation
ntim: I can see in the future using commas and still only point to one thing
TabAtkins: don't see how these concepts are related
… you can have multiple and none args
fantasai: it's not the parameters to a function, they just look like it
… we're creating an unneccary API here
ntim: I can see this list becoming an identifier
[cross talk]
astearns: I think we're having difficulyt with hypothetical future stuff here
… we could go with argument for now to return a string, and in future if we have multiple we have arguments for return an array
TabAtkins: sounds bad, I hate it!
<fantasai> +1 to astearns :)
<ntim> ydaniv: s/I can see this list becoming an identifier/we could name it "identifier" instead of "argument"
florian: was thinking this example is more convincing
fantasai: question is do we use commas or spaces, and how does that appear on the IDL
<TabAtkins> JS doesn't offer `.argument` and `.arguments`, with the former letting you avoid writing `[0]` for single-arg functions.
<ntim> (my point was `arguments.join(",")` is also extra overhead in the future, as much as `arguments.split(",")` is an overhead)
fantasai: we may have a sophisticaed syntax for multiple args, and we're trying to reduce this to whether these are args or not
ntim: you will need both, in the future you'll need to collapsed string as well
We sometimes use commas to separate arguments, sometimes spaces. If we're trying to avoid parsing things, we should return a list of tokens even when it's space-separated.
astearns: going round and round without any decision
… show of hands who would object to doing the string thing?
… seeing plinss and tabatkins
<TabAtkins> Yes, we use various ways, but we *also* specifically honor comma-separated arguments as something special
in what way?
<TabAtkins> custom functions, for example
<TabAtkins> commas separate the arglist into individual var()s
POLL: a) argument string b) arguments array c) neither
b
a, c
astearns: objections to use selector text?
[none]
RESOLUTION: Add selectorText to the pseudo object
break
github: w3c/
sakhapov: coming back to CSSPseudoELement object
… it's a proxy for an element
… but element can exist or not exist
… and what it means depends on what we discussed
… for :after it can mean rendered, for :selection it can mean something's selected
… sometimes we need to know if the thing exists
… 2 approaches suggested: synchronous exists property
… second suggestion by noam, pseudo element observer
… which is a synchronous way
… tells you which were added and which were removed
… can use this to add event listeners
… most use cases I can think of right now are covered by observer
… for example if you think about scroll markers, you might want stats on which scroll marker has been clicked
… observer is better for this case becaues it tells you scroll marker has been created
… I also think there are possible use cases for sync .exists property
… which I listed in 2nd to last comment in issue
… first is, might want another event listener which checks existense of pseudo
… might want sync approach
… also, point is that observer probably is not suitable for non tree abiding pseudos
… those are more like states than nodes
… also some libraries if you use them might want to init first with knowledge of sync existence of pseudos
… those use cases for now are more theoretical
… but I think they can be things we might need in the future
[css-pseudo] Add a property to the CSSPseudoElement IDL interface to determine if a pseudo element "exists"
github-bot, take up w3c/
[css-pseudo] Add a property to the `CSSPseudoElement` IDL interface to determine if a pseudo element "exists"
<github-bot> OK, I'll post this discussion to w3c/
sakhapov: I think we should resolve for pseudo element observer
… want to hear opinions
ntim: first thought looking at this api is that why don't we just make element.pseudo return null
… like querySelector returns null
astearns: because we already resolved on having the interface ...
sakhapov: discussions before
emilio: if you do that, you need to synchronously update layout, may wantobserver for pseudeo that doesn't exust yet
… otherwise if you have a before pseudo that goes away then comes back, you don't want to expose whether underlying psedo ? or not
ntim: exists prop checks for htat?
emilio: but object may not be the same
astearns: successive iterations of same pseudo
… it's a separate issue
… given previous resolution we need to decide what to do here
sakhapov: previous discussion was in favor of consistent proxy
… good arguments for that
astearns: other comments?
ntim: disagree with other issue
… which affects this
ydaniv: really like the observer approach
… but we're doing something specific here with pseudos
<ntim> where can i find the other issue?
ydaniv: maybe we can open something more generic
… last we talked, ? talks about having selector observer when things are added/removed that match a specific selector
… maybe we want a more generic thing that also works for pseudos
… or mutation observer that takes selector as filter
… would like to see if we could consider that
astearns: sakhapov has that been considered?
sakhapov: no, mostly considered sync way, noam is in favor of observer, see use cases for both
… heard opinions in favor of observer, want to hear in favor of exists property
TabAtkins: while the observer proposal from noam is a little complex to solve this, I think it's pretty well shaped
… avoiding sync recalc is reasonable
… agree there might be use cases for sync stuff but can pursue in future
… support sticking with observer
emilio: 2 things, if we do sync version , I'd rather make it a method than a getter
… going to do underlying work to update layout tree etc.
… also some of the use cases feel a bit dubious
… don't think we want to expose whether spelling error exists
<ntim> spelling-error
emilio: or grammar error
<ntim> Is w3c/
emilio: so not clear a lot of these have good answers for those
… don't know what the right answer for those would be
sakhapov: ? said for privacy reasons we can't expose a number of pseudos
emilio: guess you want to return null when it's a tree state
… true false or unexposed
sakhapov: there's a table in the issue
emilio: think that's a bad pattern, don't have a lot of nullable booleans
… proposal for exists was nullable boolean
… null if we can't answer
TabAtkins: don't think we have any nullable booleans right now
… given that both null and false are false-y that fits simple test for is it there?
sakhapov: idea behind nullable bool was null = can't tell, false = not there
TabAtkins: both seem false-y to me, seems okay to me
emilio: feels like a lot of these ... for example first-letter, first-line
… do you need a rule for them to match?
… same for placeholder
… could use .matches(placeholder)
… highlights you know whether you have them because there's a registry
… spelling error we don't want to expose
… seems like theres very few where this would be useful
… guess the observer, I wonder if we could reuse mutationobserver
astearns: that was ydaniv's suggestion
TabAtkins: can you filter a mutationobserver?
emilio: yes, only text changes, only additions, etc
TabAtkins: can you have default off things?
emilio: it's optional spec so potentially
… also tricky thing with mutationobserver, we don't want to turn on details of when actual element gets createdx
… seems to me like there's very few really compelling use cases for this given the complexity
astearns: I kind of like the idea of reusing something we already have
… instead of creating something new
… wonder if we should take this back to the issue, especially since noam's not here
… and have him weigh ydaniv's idea against his proposal
sakhapov: sounds good
astearns: you can ping noam to say there's this other idea, and we'll weigh the alternatives
sakhapov: and sync version can be discussed later
astearns: ok, back to the issue
github-bot, take up w3c/
Mixing :is() (or equivalent) with pseudo-elements
<github-bot> OK, I'll post this discussion to w3c/
miriam: I want to see this happen
TabAtkins: we've explicitly excluded putting pseudo elements inside :is for a while
… this is for various selector data model reasons
… big one is that :is is a pseudo class which is simple selector, and simple selectors do nothing but filter
… can always take the things matched by a couple of simple selectors, intersect them, and that's what you get when you combine them together
… if we allowed pseudo elements inside :is, that stops being tryue
… you can have .foo which selects all .foo, add :is::before
… and suddenly set of elements is not a subset of .foo
… it's a completely different set, the befores
… and that's weird
… however people want to be able to do that because it's useful
… both directly in :is and indirectly via nesting
… useful to split slector and resolve differently
… so I have a proposal for how to slightly alter the semantics of selectors to make this possible to do
… in :is and in nesting
… so that all of the nesting cases work more naturally
… example that doesn't work well:
<TabAtkins> .foo { ::before, ::after { :hover { color: red; } } }
TabAtkins: that example does not work because, while we let first 2 work okay via special case
<miriam> (I think those all need `&`)
TabAtkins: as soon as you go past that, before and after get shoved into internal :is
… and that makes the innermost nested selector invalid
<TabAtkins> .foo { &::before, &::after { &:hover { color: red; } } }
TabAtkins: doesn't match anything
… so the suggested change is, before you match a complex selector unit
… i.e. compound selector plus pseudo elements
… (thing between combinators)
… we grow the set of matched elements by adding all pseudo elements that are...
<TabAtkins> A > B:is(::before) > C
<emilio> But does that even work? ::before and ::after don't support :hover: data:text/html,<style>:root::before{ content: "foo"; } :root::before:hover { color: red }}</style>
TabAtkins: in that example, ignore whether they go left or right, equivalent meaningfully
… start with elements that match A, combinator takes us to children
… now we add to that set all pseudo elements of A children
… then we execute the B:is(::before)
… that will chop down the list of possible elements to things just matching that
… then before we move on, we will remove any pseudos that were not explicitly matched by that selector
<oriol> emilio, ::before:hover is supposed to work per the spec, https://
TabAtkins: that last step is required because that selector unit might not have had a pseudo in there, could be :hover applying to a bunch of elements
… can't keep those in list for compat reasons
… a number of psuedo classes do work on pseudo elements
… so, this means my nesting example would work
… there are a few limitations
… listed in issue
<TabAtkins> .foo:is(*, ::before, ::after)
TabAtkins: this selector ^
… worked in the old webkit matches
… would match .foo, .foo::before, .foo::after
… doesn't match in todays world and will continue to not match
… because pseudoes are supposed to be re-orderable
astearns: why does that rule invalidate your example?
<emilio> `::before.foo`
TabAtkins: there are no ::before pseudos that are also .foo
… that is not only illegal syntactically but will not match
… will continue to not match
emilio: but it matches now?
TabAtkins: no
… only matches .foo, not .foo::before or ::after
… that selector is illegal right now
… won't match what webkit-matches would have matched
… secondly, building on that same thing
<TabAtkins> :hover:is(::before) and :is(::before):hover
TabAtkins: simple selectors in a compound are always reorderable
… these 2 selectors need to be identical
… they are in all cases today and should continue to be
… but that means that these 2 selectors...
<TabAtkins> :hover::before and ::before:hover
TabAtkins: which are indeed distinct things and select different things, only 1 can be the meaning of those other 2
… my proposal selects one of these
… the latter
… a before which is hovered
… not the before of a hovered element
<ntim> I wouldn't expect :hover:is(::before) and :is(::before):hover to be the same
astearns: here we're defining new behavior
<lea> Would that change the meaning of .foo { &:hover { &::before {} } }?
emilio: that's channging currint behavior?
TabAtkins: no
<lea> `.foo { &:hover { &::before {} } }`
TabAtkins: the 2 I listed without :is do work today, select distinct elements
… but the 2 that use :is are illegal today
… giving them meaning, both equal to second one
… those are the only places where this I believe gives potentially unintuitive results
<lea> Or, if not, would it become illegal once you turned it into `.foo, .bar { &:hover, &:focus { &::before, &::after {} } }`?
TabAtkins: in all other cases this lets pseudos be used in is and gives obvious answers for all these work
emilio: I'm not quite fond of this proposal
<ntim> +1 to emilio
emilio: it feels like, especially making hover before mean the same as before hover seems super intuitive to me
TabAtkins: if you replace :hover with .foo does it make more sense?
emilio: no, I don't know why reordering preserves the meaning
… point is you want to preserve that, within a sinple selector, reordering is important
… vs doing intuitive thing which I think would be, hover before selects the before of hovered element, before hover does something different
miriam: that argument makes sense until you add :is
… the is makes them the same thing
emilio: so when you add ...
<miriam> ::before:is(:hover)
oriol: if you have before and hover without is, they'll be different
<miriam> and :hover:is(::before)
oriol: when you add is, reordering them will ?
emilio: don't think that makes sense
… hover before should not be different from before hover
miriam: I think they should be, 'is' says theyre the same thing
… not the before on the hover, the ...
emilio: that doesn't make sense to me
… I get it in that you're using :is
… but that's so confusing
… also not what authors would expect.
… if I have a complex sector, before after, &::before &::after
… behave the same as if
miriam: distinction will be if it has the & or not
emilio: in general, pseudos in my mental model are basically a combinator
TabAtkins: correct
emilio: which means making this work is annoying
… but if you look at it that way, isn't :is ... guess if you do .foo descendant .bar then ... you're not selecting anything hover
… feels really annoying
… wouldn't expect that behavior at all
<TabAtkins> :hover:is(> .bar) and :is(> .bar):hover
lea: was about to say +1
… but this reordering thing is giving me pause
… might have misunderstood, questions in IRC
<lea> 1. `.foo { &:hover { &::before {} } }`
lea: would that change how it works given it would be composed with is?
TabAtkins: no that would work fine
lea: you said foo hover is before
<TabAtkins> equivalent to :is(.foo:hover)::before
lea: would be equivalent to :is(::before):hover
… doesn't that mean it would change?
TabAtkins: the stuff higher in nesting list gets wrapped in pretend :is
… if you invert these, that would give different behavior than you might expect
… as written, equivalent to foo hover before
<lea> `.foo { &::before { &:hover {} } }`
lea: so if you had this
TabAtkins: that would be equivalent to:
<TabAtkins> ::before:is(.foo:hover)
TabAtkins: not that
<TabAtkins> :is(.foo::before):hover
TabAtkins: that
lea: so hover is on before itself?
TabAtkins: yes
lea: same result is same?
TabAtkins: no, hover on foo vs hover on before
lea: you still have a pseudo in there
TabAtkins: this entire thing is confusing by default, I know
… if we end up not resolving here, that's fine
… I need to fix this problem somehow
<miriam> the first becomes :is(.foo:hover)::before
TabAtkins: I tried another way and everyone hated it
lea: any cases where an is through nesting does something different based on nesting?
<miriam> the second becomes :is(.foo::before):hover
TabAtkins: sometimes hopefully not often
lea: that's worrying
… second example
<lea> `.foo, .bar { &:hover, &:focus { &::before, &::after {} } }`
lea: based on answer to the first, does that change?
TabAtkins: no, it's valid today and does what you expect, won't change
… will only give new results to selectors that don't select pseudos
… i.e. pseudo in middle of nesty
lea: problem is once we do this we can't make them work right way
TabAtkins: trying to find *a* way to make them work
astearns: is the motivation for this entirely nesting and the bare is behavior just a side effect?
TabAtkins: yes
astearns: no use case for bare is?
TabAtkins: there's use cases but not solving for this solving for nesting
astearns: any back compat issues having some of these either nested or bare is things with pseudos in someone's stylesheet doing nothing suddenly working?
TabAtkins: maybe, hopefully not
astearns: does this fall out of the fact that we defined nesting by referencing is?
… and if so, can we instead redefine nesting to use an ish-is like thing
… but sever the tight connectoin between them?
<lea> +1 astearns, was wondering about this too
<ntim> :almost-is()
TabAtkins: does somewhat fall out of the semantics defined in terms of is
… don't thnk we can define in other terms to get around this iwhtout either getting back to cominatorial problem
astearns: wondering whetehr we can say, for purpose of nesting, this is the extra behavior you get with pseudos
TabAtkins: maybe
… would be very frustrating if you could only express certain selectors via nesting
astearns: that's fair
<romain> `.foo:is(*, ::before, ::after)`
romain: bit confused about one example, in irc
… don't see why that doesn't work
<romain> `.foo:is(.bar, ::before, ::after)`
romain: I do but also worry that this second example won't work
… is it wildcards, or anything in pseudo won't work?
TabAtkins: first one with wildcard totally works
… will match .foo elements only
… second one will match .foo.bar elements only
romain: none of the pseudos will match?
TabAtkins: correct ,because no pseudo matches .foo
romain: think that's surprising
… mixing pseudos in doesn't work
TabAtkins: agree, this is my second try to fix this
romain: that's my main issue with this proposal, it's also very surprising
miriam: this proposal fixes this?
<TabAtkins> my previous idea was `.foo = (.bar, ::before, ::after)`
emilio: it's meant to
miriam: my understanding was that's the initial problem & what we're trying to fix
romain: what TabAtkins was saying & what I was understanding, you can use pseudos in is, can't mix them
TabAtkins: no right now pseudos in is are dropped
romain: with proposal they become valid
TabAtkins: yes
romain: but only match with only pseudos or only classes
TabAtkins: yes
… [another case that works I missed]
romain: like astearns's thinking, if we let go of is, is there more we can do?
… cases written with nesting aren't ambiguous
… but when written with is, become invalid
… maybe there's more there
astearns: also not sure
oriol: also share concerns about implications for :is being a bit confusing
… along lines of what astearns was saying
… first not the case that & in nesting is defined in spec in terms of is
… just that definition happens to match same behavior
… impls use some kind of alias internally
… but that doesn't have to be the case per spec
… could say & will match elements OR pseudos
… don't see that this would introduce any combinatorial explosion
… with just this change ... impls will not be able to reuse is
<lea> +1 oriol
oriol: but at first glance doesn't seem like a big problem to me
… not just asking around this direction, want to propose it, seems simpler
TabAtkins: wouldn't cause a combinatorial explosion, correct
… would cause that some selectos could only be written with nesting, would like to avoid
… want a syntax that lets us expres ssame things with and without nesting
<TabAtkins> .foo { ::before, ::after { :hover { color: red; } } }
oriol: I htink it's fine if that's the case
… maybe not ideal but preferable to making is very confusing
… could always extend to is in the future
… or some other syntax
astearns: agree it would be nice to express same things nesting vs not
… but only if non-nested version is ergonomic and would get use
TabAtkins: example I gave earlier would be totally valid to turn on in nesting but not normal selectors
astearns: if non-nesting way of expressing it is so weird no one will ever use it. would be okay to have it be expressible nested only
miriam: can be expressed without single selector
TabAtkins: any nested selector if you want to expand out, it's fine
<ntim> I think astearns is saying we shouldn't regress the DX for :is() just to solve the nesting problem, if so +1
emilio: is there any reason we cannot make is do what I think is expected behavior?
… not preserve order but feels most intuitive?
… as long as you're in the rightmost compound, pseudos only match there
… we don't allow combinators past pseudos
… they don't have descendants that way
… from an impl perspective, does complicate stuff quite a bit
… suddenly selector can match a gazillion pseudos
… but feasible to implement
<astearns> ntim: it’s not so much regressing the entire DX of :is(), I just don’t think it’s worth it to create a hard-to-use version of this with :is()
emilio: I think you would still, other than that weirdness of order representing different things
… (gives examples)
… to me that seems more intuitive for authors
… it's not impossible to implement
TabAtkins: the issue becomes that we don't have a concept in selectors ... would lose group of selectors that covers an element
… we rely on the fact that compound selectors can't change subject in a few places e.g. :not
emilio: negations and such become tricky, yeah
TabAtkins: we rely on the fact thaqt something in CSS lets us only filter, not filter and change
… would no longer have that to reach for at syntactical level
… unfortunate but not killer
emilio: not thing is weird ,agree
… any use case?
TabAtkins: not pseudo elements, but if pseudos are allowed inside is and can change subject
… why not relative selectors
… (examples)
… at that point we're working on some really shaky foundations
… a before pseudo is a child of an element
… if is can change to child, it should be able to change to any child
… not syntactically ambiguous, would run on same restrictions as nesting
… need combinator at start to trigger
… but if we're going in for a penny, might as well go in for a pound
… use cases for selecting an element and one of its children
… can do with nesting
<TabAtkins> .foo { &, & > .bar {...}}
emilio: thinking about ...
TabAtkins: this nesting example is totally fine
… being able to express that with is, why not?
lea: I think the top priority is that nesting needs to have expected semantics in evrey case
… nice to have multiple ways to express but lower priority
… if we ship this, will always violate principle of least surprise
… is there a subset of cases where it does what author expects?
… I think I came up with cases where even terminal pseudos didn't work, not sure
… I wonder if there's any subset where what TabAtkins is describing is expected
… maybe scope down to that
… and continue to keep other cases as invalid until we find a way to deal with them correctly
… I was also thinking along the lines of what astearns said
… maybe we can internally rewrite how & works
… maybe another path is to see if some limited expansion would prevent combintorial explosion
plinss: kind of chasing a red herring and conflating too many things here
… nesting being defined with invisible is, should be considered an implementation detail
<lea> +1 plinss
plinss: nesting should just work as if a simple substitution
… combinational explosions okay, that might be behavior you get
TabAtkins: minus specificity
… other than that I agree
plinss: if we have a problem here with impl detail of nesting, we shouldn't fix that by changing behavior of is
… don't have a problem with changing behavior with is
… if you allow pseudos, you should allow combinators, since a pseudo is a combinator
emilio: if it has the outcome of also fixing nesting ...
plinss: if it also fixes a way of impling nesting, awesome
… don't need to redefine
TabAtkins: What I'm hearing is decent appetite in WG to make nesting work better
<romain> +1
TabAtkins: even if there's some selectors that can't be written without it
… or causing an explosion
<astearns> +1
TabAtkins: and continue to pursue separately how to write without an explosion
… okay
astearns: is this what you wanted miriam?
miriam: yes
astearns: are we taking back to issue or is there a scoped resolution?
TabAtkins: Proposed: Go ahead and fix nesting, don't worry about non-nesting yet
<ntim> PROPOSED: Go ahead and fix nesting for pseudo-elements, don't worry about :is() yet
emilio: this has the issue of effectively getting same semantics as keeping is-like substitution
… and making is be able to change target to pseudo element
… would rather investigate that
… don't think it's hard to prototype, kind of annoying
TabAtkins: don't have to tie together, I just want them tied together
<lea> TabAtkins: https://
emilio: maybe we can start ...
astearns: does it change your calculation if you account ofr the fact that some aren't happy with the is behavior change?
emilio: want to change is to match what you want for nesting
… so you can do (example)
TabAtkins: but then I want relative selectors to work
emilio: fair but a bigger extension
plinss: that's the part I'm not clear on what the result is
emilio: I want this...
<emilio> .foo:is(.bar, ::before, ::after) == .foo.bar, .foo::before, .foo::after
emilio: to be the same as ...
ntim: I disagree with that
emilio: why?
… isn't that what people want?
ntim: .foo is not a before pseudo
emilio: don't you want combinators there?
<TabAtkins> (this is the :-webkit-matches() behavior)
[crosstalk]
<emilio> .foo:is(.bar, > .baz, > .bar)
plinss: if we put a combinator in is, what does that mean?
… does combinator go before thing that is is or after?
emilio: what I typed
TabAtkins: yeah that should work
emilio: would be equivalent to...
<emilio> `.foo:is(.bar, > .baz, > .bar) == .foo.bar, .foo > .baz, .foo > .bar`
ntim: why do we want to overload is? create a new pseudo class?
emilio: maybe but if we introduce that concept for nesting may as well
TabAtkins: if we do this in pseudo space, no reason not to put it in is
ntim: maybe :with?
… would make more sense as you read it
… .foo isn't a before pseudo element
… and isn't whatever overload
emilio: is this only about naming of is?
ntim: yes
emilio: what about where?
TabAtkins: :is is not meant to be read as "argments are things before"
… it's "I'm selecting something that's one of these'
plinss: if you give me that explanation and write what emilio did
… the thing you're selecting is a .baz that is descendant of something that's also .foo
… so it's .foo.baz, not .foo > .baz
TabAtkins: now you're arguing for accepting my idea as stated
plinss: trying to get an idea of what combinator means
… emilio's expectation doesn't match mine
TabAtkins: what emilio wrote is
… the pseudo element version is what :-webkit-matches did
… if it had a relative selector version as well, it would have same semantics emilio listed
<ntim> I expect: `.foo:is(.bar, > .baz, > .bar)` == `.foo.bar, .baz > .foo , .bar > .foo`
TabAtkins: but we don't have to solve this right now
… could take resolution to fix nesting and figure out how to fix as selector later
plinss: want to clarify that fix nesting means nesting behaves as naive substitution and got combinatorial explosion if that's the result
TabAtkins: as much as possible yes
emilio: I find it weird because then you need to define what specificity of pseudo being there vs not
… right now is will drop pseudos
… nesting will right now drop pseudos
… and not consider their specificity in there
TabAtkins: but if you put pseudos as innermost nested it works fine
<ntim> `.foo:is(> .baz)` reads to me as ".foo which is a child of .baz", so `.baz > .foo`
emilio: you're adding a selector that can select elements in a pseudo
… would rather make this work in :is
… don't see any reason not to do it if we're going to have this functionality
TabAtkins: agree
ntim: not saying we shouldn't express it, should be an issue for later
astearns: I think people in the room agree that this should be expressible, just disagree on how to get it done
… we have agreement on how to make it work with nesting
emilio: would like to preserve the fact that nesting can be expressed in terms of regular selectors
… answers a lot of questions about how selectors work
… if you have .foo:is(*)before after
… .before after don't contribute to specificity
… with nesting now they do
TabAtkins: they're valid but pseudo elements don't
TabAtkins: do pseudo elements have specificity? I don't think they do
emilio: I think they do, but right now it might not be visible since you can only have 1
… and it only competes with 1 other pseudo
… when we implemented nesting, one thing that came up is that browsers do have some kind of ? specificity and they were getting mixed
plinss: I get your desire to have a pseudo class that behaves exactly like this, and support it
… not usre it should be is
emilio: not sure it should not be is
… extending where is something new
plinss: not saying we ahve to invent something new, doesn't have to be is
emilio: guess it depends how you read it
… if I select something that is this or that, that makes sense to me
plinss: is and notion of combinators starts confusing what is is
… which is th eis
… is the is before the combinator or is the is after the combinator
… not sure is is the right thing here
TabAtkins: should be read as thing after combinator, selecting thing matching argument
plinss: you're basically lofting the combinator in front of the thing outside is
TabAtkins: no
plinss: then what does combinator do?
TabAtkins: as if you just threw away other args and just removed the is
ntim: that's not how I read it
TabAtkins: that's how webkit-matches does it
plinss: that interpretation may make sense if you call it matches, not if you call it is
emilio: something we need to decide on is, what specificity these pseudos have
… some pseudos have class specificity
… should is have class specificity?
<oriol> Issue about the specificity of pseudo-elements in nesting: w3c/
emilio: something else?
… that selector can now be matched against ?
TabAtkins: class specificity, say what they have
emilio: only relative ot other v-ts righ tnow
… needs to be defined in terms of global selector space
TabAtkins: what is the specificity of an element midway down a pseudo stack
ntim: already defined?
TabAtkins: not yet but will become
plinss: for a long time there was a restriction on pseudos, did we relax?
TabAtkins: yes
ntim: vt pseudos have specificity
<emilio> emilio: but only against each other right now
[missed]
TabAtkins: emilio can you raise that as an issue?
<ntim> emilio: I think we should implement this in :is, but fine
<ntim> astearns: consensus by exhaustion?
<ntim> PROPOSED: Resolve on behavior for nesting, and thinking about non-nesting later
RESOLUTION: Resolve on behavior for nesting, and thinking about non-nesting later
ACTION: Emilio to file issue about specificity
w3c/csswg-drafts#5265
github: w3c/
<emilio> github-bot: take up w3c/
<github-bot> emilio, ignoring request to take up w3c/
oriol: In the marker pseudo, we restrict which props that can be used, because layout is special, and we wanted to avoid browsers doing random things. but there are properties like counter that affect only style and not layout.
… I have been using it in counter, which is convenient
… also you can use open-quote/closed-quote in content to increase the quotes, but you can't increase the counters, or the use the symbols increased by the quotes
fantasai had mild objection
<TabAtkins> +1
oriol: I think we should just allow it
fantasai said she had opinions on this issue
sakhapov: Is the ordering relative to ::before defined?
oriol: yes
<fantasai> I was concerned that people will get confused about what the counter increment is doing
<fantasai> and not get the results they're expecting
TabAtkins: It's a mystery for me why ::marker pseudo-elements are not fully styleable, but fantasai had opinions
<TabAtkins> people do that with ::before today and it does indeed work reasonably
emilio: Isn't that because the outside-marker layout is not defined?
oriol: but counters don't affect layout
ntim: can't counters affect layout?
oriol: maybe we should leave it for later if fantasai is strongly opposed
<emilio> emilio: they affect layout but anything you can put with text you can put on a counter
<fantasai> it's mainly we don't know how the counter is laid out, but to the extent that it contains text it's fine
astearns: i know you said this is mostly a convenience because you can work off the element itself
oriol: for most cases yes, but <describes cases>
oriol: i have a ::before pseudo, increment the counter, and print it with content, I should be able to do the same in ::marker
<astearns> fantasai: would you object to us resolving to allow this, or is it more a minor concern
oriol: I thought that it was more straightforward than expected
<fantasai> minor concern, just want to be sure we're not causing more problems than we solve
PROPOSED: allow counter and quotes properties in ::marker, revisit later if there are a lot of problems
fantasai: ^
objections?
RESOLUTION: allow counter and quotes properties in ::marker, revisit later if there are a lot of problems
end
<fantasai> The problems I expect aren't on the implementation side. It's on the author side, that people might get some confused output
<astearns> yes, that was a clear input into our discussion. thanks for following along in irc
<fantasai> Like if you increment on ::marker, but make it not a list-item, then you don't have numbers that you expect
<fantasai> Best practice is to increment on the element itself.
<fantasai> You're less likely to get into trouble that way.