Meeting minutes
github-bot, take up w3c/
[css-grid-3] FPWD for Masonry Layout
<github-bot> OK, I'll post this discussion to https://
fantasai: Tab and I got together - we figured out how to do mixed intrisnic tracks, and that removed most of the differences. we made a merged single draft with both proposals
fantasai: Differences are largely syntactic, they're listed as "grid-integrated" or "grid-independent"
fantasai: Changes are the properties from display:masonry proposal, you'll notice masonry-template-tracks has the same syntax now as grid-template-columns
fantasai: We also sketched the optimizations for track sizing that should make things work faster
fantasai: And how to handle sub-masonry to avoid the exponential aspects of nesting them.
fantasai: Probably a little left to do with nesting of subgrids, but should handle the major parts
fantasai: Integrated the 'masonry-slack' property, it was 'masonry-threshold' when we discussed it in the past
fantasai: We did edits for collapsing tracks for auto-fit; there were some details not discussed in the issue so please take a look if you're interested. We had to define a heuristic for what tracks were "occupied"
fantasai: Added row-reverse, column-reverse, and column-reverse for the Grid properties, and similar for masrony
fantasai: And Tab's draft had repeat(auto-areas)
fantasai: Issue open on whether we need it
fantasai: Aside from the fallback behavior, its behavior is already part of grid
fantasai: Also we added an a11y section, outlines some of the potential problems. References reading-flow property
<fantasai> https://
fantasai: and talks about some ways to avoid the need for back-tracking
fantasai: So that's the current draft. We think this represents the discussion well. At this point there's three impls of Masonry layout, two under grid-integrated and one under grid-independent. \
fantasai: Think it's important to get the draft out, post for TAG review, and get broader input from the community so we can refine the draft further.
chrishtr: Thanks Elika and Tab to integrate these alternatives
chrishtr: Happy to see this go to fpwd for wider community feedback, particularly webdevs
chrishtr: one question I have is, does the current draft point out differences in functionality between the alternatives?
chrishtr: My understanding is there are some things possible in grid-independent that aren't in grid-integrated
<fantasai> TabAtkins: Some differences, but much closer
<fantasai> TabAtkins: not huge either
<fantasai> fantasai: which differences, other than initial value?
<fantasai> TabAtkins: repetition of intrinsic track sizes
<fantasai> TabAtkins: which I think should be the initial value
<fantasai> fantasai: With mixed track sizing, no longer guaranteed to have the same size, so is that even still possible?
<fantasai> TabAtkins: need to review
<fantasai> astearns: should have an issue to track each difference
astearns: Any more comments?
astearns: Concerns about publishing fpwd?
RESOLUTION: FPWD for Grid 3
github-bot, take up w3c/
[css-scrollbars] Is the track visible in overlay scrollbars?
<github-bot> OK, I'll post this discussion to https://
florian: A bit of an issue. With scrollbar-color, authors can (and must) specify two colors, one for the thumb and one for the track
florian: It's *the author's* responsibility to ensure that these colors ahve sufficient contrast so the scrollbar is visible and usable
florian: Problem is there's no cosntraint on what the UA can do with them.
florian: With overlay, there's many situations where the track isn't drawn at all
florian: So the author picked two contrasting colors, one might not be used, the other is used against a color they didn't anticipate
florian: So we gave the author a responsibility, without giving them assurances they're able to uphold it. that's a problem
florian: Several things could be done
florian: UAs could show the track all the time, could put a glow/border/shadow/outline around the thumb, they could do this only when they're not showing the track, they could test the contrast for the thumb against the content behidn it and only do the mitigations when needed
florian: Lots they could do, don't think we should mandate any particular one, but shoudl mandate they do *something*
florian: Because a white thumb on a black track, with a white background and no track, isn't good
florian: So I prefer to put a UA MUST in the spec, with a suggestion box giving some ideas for accomplishing it
florian: There's a bunch of options, just pick one that either allows both author colors to be there, or otherwise ensure contrast
chrishtr: Agree it's infeasible to require a particular scrollbar UX, so I agree with the normative text suggestion that just requires some way to have contrast, with suggestions in informative text
flackr: Agree as well, same general thing.
flackr: May only be necessary to do this if the dev overrode the track color.
flackr: So we can say UAs can have a default transparent track color, and if the author overrode that, the UA must ensure contrast
florian: So the author has to specify both colors right now
florian: You're saying if they happen to specify the same track color as what the UA would have done, they don't need to do anything special?
flackr: I didn't realize they both had to be specified. But yeah, if the author gives the same track as the UA, they UA doesn't need to do anything.
flackr: Maybe a bit unfortunate the author can't just specify a thumb color
florian: Reason we didn't allow just a thumb color is the author wouldn't know the track color, and wouldn't be able to ensure contrast.
florian: But yeah, if they deliberately say a tranparent track, that's a reasonable exception to the "must provide contrast"
bramus: An alt to your B suggestion in the issue, is to give authors control to let them force rendering the track
bramus: Related to 9785, I needed to force-render the thumb
bramus: So like I *really* want a particular track color
florian: We could do that too, but as long as it's opt-in we still need what we're discussing here
florian: For the other case when the UA is still allowed to not draw the track.
PaulG: Is it possible to write a selector that lets author supply two contingencies, for thumb-with-track and for thumb-without?
PaulG: If that's the case, UA doesn't necessarily need to do heroics
florian: At the moment it's not possible. Could maybe add a MQ, but right now there's nothign
<emilio> 2+
PaulG: Okay, in general less magic is better, but if that's a longer/more difficult path, I understand the need for UAs to resolve it.
emilio: Regarding Bramus's comment, I think force-rendering the thumb is not great because it doesn't match platform conventions - it's weird for scrollbar-color to change how scrollbars work. Users still see familiar scrollbars.
emilio: So I'm fine with florian's proposal, but don't think we should force rendering bits.
emilio: Like in GTK Firefox will only render the thumb unless you're hovering the track, in which case the track will render too. That matches GTK behavior.
emilio: So I lik eFlorian's proposal that lets us pick a strategy to ensure contrast while staying within platform conventions
<bramus> https://
bramus: There are some use-cases, it's more like a design choice to actively show the scrollbars to make something clear. I'm dropping a demo
bramus: I really wanted to show the scrollbars always, even if you only have overlay
bramus: We don't need to continue the discussion, just saying there are use-cases
astearns: Yes, I think forcing scrollbar parts to be displayed is a separate issue
smfr: I think forcing UA to do treatments on the thumb to make it visible is placing quite a burden on the UA.
smfr: In apple the scrollbars are rendered by UI Kit
smfr: Having them add shadows or glow or something is quite a burden
smfr: I'm wondering if this puts the whole idea of author-controlled scrollbar colors at risk
florian: The proposal isn't that you have to adjust the thumb, it's that you have to do *something*. Maybe ignore *both* colors if that's fine.
florian: Maybe in the Apple case, currently that's fine. Earlier designs, thumb had texture and designs on it, would be visible regardless of color.
florian: But today's UI where the author can choose good colors and still not get a usable scrollbar isn't fine.
<TabAtkins> +1
smfr: I always considered the colors as providing a base color and the UA can apply subtle effects on top of that
smfr: So if the UA can do not a flat color, that's ok
smfr: I think the issue is making sure the thumb is readable across different parts of the page, like a zebra stripe background.
smfr: So if the UA has flexibility with the colors that's fine
florian: Yeah, that's mentioned already
emilio: We already take some liberties with the color to provide stuff like hover feedback
emilio: more directly to Simon's point, I think in Cocoa the thumb has a subtle outline, maybe semi-transparent. That might be enough already to conform to the requirement.
emilio: You'll still see the slight outline even with a matching background
emilio: So I think AppKit maybe does that already; we copied AppKit's scrollbar rendering and have code to do that, so you did it at some point
<florian> PROPOSED: accept proposal as outlined in github, with an exception when the author explicitly sets a fully transparent track.
astearns: Not hearing sustained pushback. [outlines proposal]
chrishtr: So part of the normative text will say something about transparent?
florian: That wasn't in the original proposal, but was discussed here. If the author gives a transparent track they've already specified their thumb will match their background.
flackr: The author has provided two colors that should contrast, and the UA should maintain at least that contrast. If one is transparent, there's nothing for the UA to preserve.
chrishtr: So the UA will defer to the author about whether it actually contrasts.
flackr: yeah
chrishtr: Similar to if you make a white text on white bg, don't do that, not the UA'
smfr: Concerned about a transparent track, it can just be invisible then. Should be a provision for the UA to override colors if they're bad
florian: Already have that provision, including if the scrollbars just can't be customized.
astearns: At this point I think we should get the proposal into the draft and get feedback afterwards.
astearns: Concerns or objections?
RESOLUTION: accept proposal as outlined in github, with an exception when the author explicitly sets a fully transparent track.
[css-view-transitions-2] view-transition-name determined by element
bramus: Right now we require a unique VT name for every element
bramus: A bit cumbersome for authors, if you have 40 cards on the page that participate, they each need a unique name
bramus: A lot of input in the thread
bramus: To summarize, our conclusion seems to be needing some way to auto-name the element
bramus: Right now, value is "auto", with details still a little uncertain
bramus: Two suggestions - auto uses the ID if it has one, or else generates a unique internal ident.
bramus: Second is to just go straight to unique internal ident
bramus: Reason for second path is if the author has ID on the element, like <div id=hero>, it will use "hero" as its name. If someone later explicitly uses "hero" as the VT name, it'll clash
bramus: I think that's where we're at. In addition to "auto" only being able to generate unique ids, there's a proposal for an ident() function that can be used like ident(attr(foo)), to produce an ident from an arbitrary attribute
bramus: So options are "auto" tries to use ID, otherwise generates unique. Second is we just only do unique. And then for either, maybe give authors ability to take name from a different attribute.
khush: Elika left good points on the issue.
khush: I'm less a fan of deriving from ID for two reasons. One, can be a bit of a surprise if author isn't expecting the ID to be used, not obvious. Can cause unintended collisions.
khush: Tho talking with Vlad, if that's a showstopper we can namespace explicit vs ID-derived names.
khush: If we do decide on being able to use any attribute as the name, I'm more not in favor of auto doing it automatically. Author can just do it explicitly.
(Agree with that, ident() seems fine, or attr(foo ident), whatever.)
fantasai: The reason to have "auto" use the ID by default and fallback if needed is it allows author to rely on IDs in the markup that are already created, if that exists.
fantasai: If you can only do it explicitly, you have to know there is an ID on that element.
(I mean, `.foo[id] { v-t-name: attr(id ident); }`)
fantasai: LIke, as an author, you want an elment to transition, and if you have an ID it'll transition even if it's moving around the document or something.
fantasai: Should be something that works with a single keyword.
fantasai: If the element exists in both trees they probably want it to identify with itself.
fantasai: shoudln't make the author do additional work
astearns: Would it help if the attr method is invalid if the ID doesn't exist? So you can set auto on everything, and for the things you want to use an ID, use the function; it'll fallback.
fantasai: So you're proposing two keywords, one that uses ID if possible with fallback to element identity, and the ohter that just uses element identity
fantasai: that's fine with me
fantasai: I just want things to work by default
fantasai: Matching up obvious things seems obvious
vmpstr: I agree with the last point, not making author do extra work. I think there are edge cases that might not be common, where an element matches by ID, but the ID attr is removed - do we continue matching by identity?
vmpstr: I worry there's a little magic, like if you remove the element and add it back, it works *if* you had an ID on it, but not if you relied on identity.
<fantasai> `auto` is the keyword of magic!
vmpstr: Maybe that's something we can overcome with dev education
vmpstr: I think there are other things we might want to match on, like being selected
vmpstr: So I think having an attr is useful
khush: I like the idea of two explicit keywords
khush: And maybe "auto" that magically chooses between the two, if it's not the initial value.
khush: We can make it pretty explicit int he property description
khush: So I'd be fine with "auto" as the name, if the behaviors were chooseable separately.
astearns: So you're proposing three keywords?
khush: The ability to draw from an attribute is somethign proposed generically
khush: So three things (tho not necessarily keywords)
<fantasai> wfm
bramus: One thing for proposed ident() function, this doesn't just apply to v-t-name, but anywhere that takes an ident
bramus: So that's why I'm a big fan, it's not focused on only VT.
TabAtkins: Haven't read entire thread, very long, but
TabAtkins: sounds like we want multiple strategies, and if one doesn't work, we fall back
TabAtkins: so can we do comma-separated?
TabAtkins: then we could allow future things, like use the selected thing (?)
TabAtkins: Then we can have strategies for marking and matching view transitions
<vmpstr> +1
<khush> sgtm
bramus: commas seem a bit weird?
bramus: commas seem a bit weird, e.g. animation-name, [missed]
bramus: If you do commas in animation-name, both names apply
bramus: view-transition-name: x, y
vmpstr: we could do space separated
TabAtkins: we use commas for lists of stuff, helps allow future syntax evolution
TabAtkins: problem with the counter properties because they didn't have commas
vmpstr: This isn't something we're thinking of doing today, but at some point we considered having multiple view transition names
vmpstr: so that same element can morph into multiple
vmpstr: so prefer space separation for that reason
TabAtkins: fine with that
TabAtkins: I doubt any syntax evolution here, it's just a name
TabAtkins: so fine to do space separation, I just default to commas
fantasai: I think multiple keywords are a bit more cognitive overhead if there's really only two things that are fallbacks
fantasai: I think having auto keyword doing that makes the most sense
(we've already discussed more than two behavior in this convo)
fantasai: So I think having just "auto" doing the two fallbacks makes the most sense. If we have more behaviors in the future we can add it
astearns: Tab said we already had more discssuion
fantasai: Like what?
TabAtkins: The selected element between two trees
vmpstr: Specifically, just some element with a particular class in both trees
fantasai: Isn't that what selectors are for?
fantasai: If you want to choose one attribute if it's .foo, another with .bar, we can do that with selectors
(tbf that same argument applies to ID, tho the possible common-ness of ID use is still an argument in favor)
astearns: If we go with "auto" for now, nothing stops us from allowing multiple fallbacks in the future
<TabAtkins> +1
<fantasai> +1
astearns: So I'd like to propose we have three values - one that uses the ID, one that uses element identity, and "auto" that uses ID then falls back to identity
<astearns> ac khush
khush: For using a keyword for ID, is that something we want to do in other naming properties? Or is it VT specific?
PROPOSED: Introduce keyword for element identity, some other syntax for using the element's ID, and auto keyword that switches between the two
fantasai: I think that's a good question. A challenge is we have two different concepts for "id" and "identity" that's hard to distinguish in explanation.
fantasai: We could extend this to other properties possibly. Other properties have more referencing, might be a bit less useful.
fantasai: You name the thing, *and* refer to it from other elements. In that case the CSS needs to know the name anyway.
<khush> that's fair
fantasai: VT is a case where you don't need to know the name, you can reference it just via classes.
fantasai: If we introduce an ident() it should have its own issue
bramus: #9141
fantasai: If we do it shoudl be generic across CSS
vmpstr: Still just one keyword to specify? No fallback list?
fantasai: Yes. Three new keywords, but only use one at a time.
astearns: the ident() function isn't part of this issue, will be a different discussion
astearns: So three new keywords, use one at a time. Objections?
bramus: If we do ident() elsewhere, do we need the third keyword now? Will that be affected?
PROPOSED: Introduce keyword for element identity, some other syntax for using the element's ID, and auto keyword that switches between the two
fantasai: This'll be whatever the markup language defines as the element identifier, "id" in html
fantasai: xml:id in XML
flackr: The function for using element's ID, is that differetn from attr()
TabAtkins: proposal here is to have a specialized keyword that uses the ID
TabAtkins: could *also* allow the ident() function
flackr: and attr() would be a separate solution
fantasai: currently no-one implements ident-generating attr(), only string-generating attr()
RESOLUTION: Add three keywords, one for ID attribute, one for element identity, and one that does fallback between the two.
End
Meeting closed.