Meeting minutes
<astearns> https://
face-to-face
astearns: please add yourself to the wiki page if you haven't already for in-person or remote attendance
emilio: if you want food ... that's pretty much it
… will try to account for extra people
… if 10 people more than expected show up, that might be an issue
astearns: emilio told me there's a larger and smaller room available, we could have breakouts if folks have topics
… I'll start putting the agenda together beginning next week
github-bot, take up w3c/
[selectors-4] Move to CR?
<github-bot> OK, I'll post this discussion to w3c/
ChrisL: we have generall agreement from this group to push this to CR
… I put into horizontal review, all are in except security
… also wrote an explainer, there were some changes from i18n, I'd like to publish an updated WD with those changes
… with an eye towards taking to CR once we know which things need to be fixed
… but none of that precludes an updated WD
fantasai: I reviewed the changes since previous publication
… couple points where we made things better but others we might have regressed something
… an+b stuff, was surprised at the resolution
ChrisL: don't understand that part, TabAtkins did it
<TabAtkins> Let me see what elika is confused about wrt an-b...
fantasai: there's a difference between does it match and does it parse, have to be careful about what we end up treating as invalid and invalidating whole selector
… something I would like to double-check before we publish
ChrisL: ok will need re-sign-off from reviewers
… sorry if I overstepped, went ahead with wide review
fantasai: appreciate you did that, should have reviewed changes
astearns: next round of wide review should be easier since it will be a smaller set of changes
… fantasai, you want to look at some issues before we publish? or could we publish. now with idea that we'll publish again after looking?
fantasai: I suspect it will not take more than a week to circle through this, largely just some tweaks
… if there's an actual problem I'll bring it back up with WG
… we could resolve to publish pending a few editorial changes
… I do have a question about the an+b discussion, not sure how I missed that, but I don't particularly like the thing we settled on, it's awkward
… were people really rejecting the other options?
astearns: since the an+b thing wasn't on the agenda, could you raise an issue for it?
ChrisL: that was a change on syntax-3, not selectors
… selectors was updated to point to that
<TabAtkins> It was a low-impact discussion, nobody had big opinions on it, there was weak desire for a-n-plus-b
emilio: is the an+b thing even normative?
fantasai: it's not normative but also has syntax-3 been updated? it won't link otherwise
<TabAtkins> not republished, but yes https://
fantasai: will reopen that issue, we should not republish until syntax-3 is updated
ChrisL: fair
astearns: we'll come back to these soon
github-bot, take up w3c/
[css-grid-3][masonry] Static positions of out-of-flow items in fill-reverse
<github-bot> OK, I'll post this discussion to w3c/
cepan: context is, in grid-lanes container, if fill-reverse is applied, we fill from end of stacking axis
… columns that's bottom to top, rows right to left
… question is, if we have out of flow items, do we want to change their static positions?
… if we change the flow usig fill reverse seems like static positions should be affected as well
… there's a follow up question for track reverse case
… where in columns you fill from right to left
… do we want to reverse static positions in track reverse case as well?
… my suggestion was for both fill-reverse and track-reverse, yes we do want to adjust static positions
astearns: and you note we do reverse static positions in flex?
cepan: in flex we do reverse static positions with any reversals
<TabAtkins> I have no strong opinion on static positions (in general I think non-block static positions are more or less useless), so I'm happy to go with whatever's consistent and easy
emilio: don't disagree necessarily, was going to make a simmilar comment
… generally we try to keep static positions as simple as possible
<TabAtkins> yeah +1 to emilio
emilio: if this is simple implementation wise then it's fair
… otherwise I feel either way would be okay
… is there a ? static position to choose if we don't reverse otherwise?
… so you're laying stuff out, you hit an abspos
… if you don't reverse them, is there a good way to come up with a reasonable static position? 0,0 or something?
cepan: yes, I think static position is where it would be without other reversals
… it's possible item ends up far away
<fantasai> I think I agree with the static position being flow-responsive
<TabAtkins> one sec
TabAtkins: in general I find static positions outside block layout to be more ore less useless
… what static position does in block layout does not represent a useful position in grid, flex, etc.
… like emilio said I'm fine with anything that is simple and consisitent
… don't need to worry about use cases, there aren't any for static positions in these things
… as long as we have something that's reasonably consistent and explainable I'm fine with anything we come up with
astearns: don't think there is a reversal case in non-lanes grid, is that the case?
fantasai: if we add reversal to grid-lanes, we should add to grid as well, we have an outstanding resolution for that
… so there will be reversals in all 3 layouts
astearns: so I see 2 ways forward. one is, don't mess with it because we don't think anyone will use it, other is, do reversals because we have a precedent in flexbox
cepan: I think it makes sense to follow flexbox precedent
… if no one has any objections, I'd prefer that
<sgill> +1
<TabAtkins> +1
<hoch> +1
astearns: I think I'm in that camp as well
… proposed resolution is we will do reversals of static positions in grid-lanes
RESOLUTION: we will do reversals of static positions in grid-lanes
github-bot, take up w3c/
[css-scroll-snap-1] Clarify whether to use the DOM tree order or the flat tree order
<github-bot> OK, I'll post this discussion to w3c/
emilio: this is about which tree order we use to select snap points
… the spec seems to use dom order
… but I think that doesn't make any sense, because dom order and layout tree order don't have anything to do with each other once you ? slots
… I think spec should just use flat tree order, that's what Firefox does
… we haven't seen any compat issues
… also how things like counters work
TabAtkins: just to understand a little better, is this ordering only being used for telling which element we're snapping to when multiple snap points coincide?
emilio: it's been a while, need to look at test, but yes I think so
TabAtkins: so this is just tie breaking... I don't have a strong opinion, whatever works better for implementations works for me
… no correct answer, just a matter of selecting a winner out of otherwise indistinguishable possibilities
… unlike e.g. counters where order is visible and smantic
… less obvious what the answer should be here
flackr: TabAtkins already asked the question I wanted to
… I think I agree that using flat tree makes more sense
astearns: proposed resolution is to use the flat tree in ... what exactly?
[missed]
flackr: it's in the scroll snap spec when choosing between equally valid candidates
astearns: proposed, we will use the flat tree in section 6.2.1
RESOLUTION: we will use the flat tree in section 6.2.1
github-bot, take up w3c/
[css-scroll-snap] Clarify snapping behavior with multiple single-axis scrollers
<github-bot> OK, I'll post this discussion to w3c/
vmpstr: we have resolved to be able to create single axis scrollers by not coercing overflow clip into hidden
… when the other axis is something like scroll
… this means that the element becomes a scroller in one axis but not the other
… TabAtkins put together a draft PR to update a bunch of specs for this
<TabAtkins> (no longer a draft PR, it's merged now)
vmpstr: a lot of cases you have to find nearest scroll container and which axis matters
… this issue is about scroll-snap
… I think we want to say it's reasonable to want to snap 2 different scrollers for 2 different axes
… one smallproblem here is that scroller, when it specifies snap type, also specifies an axis
… question is what do we do in these cases
… think it's obvious for vertical scroller with vertical axis
<TabAtkins> definitely +1 to the proposal in the issue, it's consistent with the non-scrolling behavior and how we treat single-axis scrollers elsewhere
vmpstr: question is what do we do if we have a vertical scroller with snap in horizontal axis
… proposal I have is that we ignore the fact that scroll-snap-type has horizontal axis since scroller is not horizontal
… would find scroller higher up
… examp[les in the issue
flackr: this is the same as what we do for scroll-snap-type on non-scroller
vmpstr: right, first we find a scroller then check its scroll-snap-type
astearns: questions or concerns?
<flackr> +1 to the proposal
<TabAtkins> non-scrolling axises don't capture snaps
vmpstr: scroll-snap-type which doesn't affect a scroller doesn't contribute scroll points
smfr: if you have nested scrollers and inner scroller is horizontal, when you're selecting snap candidates in parent scroller, you are looking at ones in inner scroller?
vmpstr: the ones for other axis, yes
smfr: when you specify a snap target, do you give it an axis?
flackr: yes, you specify scroll-snap-align in each axis
smfr: guess that makes sense
astearns: this makes sense to me but summary in minutes doesn't yet
… when there's a mismatch between scroll-snap-type and scroll axes, we ignore the mismatched scroller?
vmpstr: essentially you do bitwise and between scroll-snap-type axis and which axis the element is a scroller
<flackr> Proposed resolution: Snap positions affect the nearest ancestor scroll container in each axis they align to
vmpstr: if it has both but scroller is only vertical only consider snapping in vertical axis, horizontal snap can be in ancestor scroller
<flackr> existing spec text is "Snap positions only affect the nearest ancestor scroll container on the element’s containing block chain."
<TabAtkins> yeah +1 to resolution
flackr: wrote a resolution based on existing spec text
… I am proposing that we just say "in each axis which they align to"
<ChrisL> +1
astearns: right because really we are affecting scrolling of scroll container based on what scroll positions
astearns: any objections to flackr's proposed resolution?
RESOLUTION: Snap positions affect the nearest ancestor scroll container in each axis they align to
github-bot, take up w3c/
[filter-effects] chained filter support, aka href on the filter element
<github-bot> OK, I'll post this discussion to w3c/
TabAtkins: SVG 1.1 defined that filter element could have an href attribute
… like in gradients, it inherits a bunch of attributes from referenced filter
… filter effects spec accidentally dropped this
… but it also turns out practically nobody implemented it
… Firefox was the only browser, none of the drawing tools e.g. Inkscape implemented it
… SVG WG discussed and decided to drop href attribute from filter element
… now that it's a spec owned by us partially, they brought to us to resolve on
… suggest we resolve that filter element no longer has href attribute
<smfr> +1
<schenney> +1
ChrisL: this is a nice feature in theory but very complex in practice, brings multiple inheritance
<ydaniv> +1 to ChrisL
ChrisL: most tools have not done it, I support removing it
<dholbert> seems fine.
<kurt> +1
astearns: Proposed resolution is we drop href attribute in filter element
TabAtkins: no change in spec, we already did it, affirms what we accidentally did in spec
schenney: idl in spec might need updating
<ChrisL> yes
TabAtkins: right, need to drop that mixin
astearns: objections?
RESOLUTION: drop href attribute in filter element
github-bot, take up w3c/
[css-filter-effects] Clarify the `filter region` for CSS reference filters
<github-bot> OK, I'll post this discussion to w3c/
smfr: when css filters reference an svg filter, the user agent has to compute filter region
… which is used to compute geometry for svg filters
… spec talks about how to do this for svg elements but not css boxes
… impls have converged on using ink overflow bounds for userSpaceOnUse, border box for objectBoundingBOx
… this matters because you could create SVG filters for things with flood which identify extent of ink overflow
… I think Firefox and Blink behavior for ink overflow is okay but suprised this is not specified anywhere
<TabAtkins> yeah, shadows are another of those places that are *technically* infinite in extent; in practice it's the bounds of 1.5x the kernel width of our box blur.
emilio: without having most context on this, I agree with your feeling
… exposing ink overflow bounds like that seems fairly unfortunate
… do you know the compat impact of not doing it?
smfr: don't think I've seen any pages break because of this but very easy to write a test case
emilio: I'd be open to trying to change this to use border box always if that's what safari's doing
smfr: if you use border box you risk truncating content
… testcase has a relpos with abspos childern outside parent, filter on parent
… may or may not clip out descendants
… safari clips out descendants
emilio: seems okay, same as any other overflow
… only other defined box we have around I think
… fwiw, if you have a non relpos with an abspos inside, Firefox does include abspos as ink overflow
… so already differences between Firefox and Blink
… I would be willing to switch to border box given ink overflow is totally undefined
… open to other things
<TabAtkins> I think I agree, being consistent here
ChrisL: agree absolutely it should be defined
… my intiial thought was ink overflow, but with blurs it's theoretically infinite
… we have to pick what we have to define it as
… I am sensitive to what people are saying about border box, also possible to extend filter region
… if you're generating new content and see it's clipped out, you can change the filter
<TabAtkins> note the spec even recommends using a 10% margin outside the filter, to make sure you catch some of those bordering things
ChrisL: comfortable with border box but there's a risk of back compat that should be inestigated
schenney: ink overflow does make an appearance for intersection observer
… there was an issue somewhere to define what ink overflow meant which opens a can of worms
<emilio> (only intersection observer v2 which is Blink only right now tho, right?)
schenney: with that in mind I'd go with always using border box and requiring people to set a larger region if they need to
… don't think there'd be a compat issue if safari hasn't seen bugs filed against it
… would support using border box for userSpaceOnUse
<dbaron> +1 to observable behavior differences depending on the ink overflow bounds being bad... but agree with the other concerns as well
astearns: if we decide to default to border box, would it make any sense in the future when ink bounds is well defined to have an opt-in? or is that over-engineered?
ChrisL: we can burn that bridge when we come to it
astearns: changing filter makes more sense to me
smfr: if we use border box, it's goig to be annoying for authors if they have to extend region to cover descendants
… one proposal might be, use bounding box of border boxes of target element and all descendants
… does that make sense? or should we go with border box of target element?
schenney: I think we have another issue about whether geometry should include children
… I would probably not complicate things at this point
emilio: I guess that would be more like defining the scrollable overflow, kind of
… except you need to define a bunch of pieces where it doesn't matter right now
… that abspos inside composition whatnot
… it seems like the case that people are not running into it, would rather do simple thing
… is there any precedent for having this combined scrollable overflow boxes of descendants thing?
… that isn't scrollable overflow
smfr: I can't think of one
… I'm okay resolving on border box
emilio: if people find issues with this,w e can revisit
… my guess is border box is fine for most use cases
… if you do scrollable overflow think
… you solve some issues
… but if something with ink overflow creates shadow you still have this issue, you're half solving the problem
schenney: would support the resolution that we always use border box
… anything else seems challenging to define consistently
smfr: if it's a split inline, it's bounding box of pieces?
schenney: yes, so what do we return for
emilio: bounding client rect
smfr: ok I'm happy with that
astearns: proposed resolution, we will define filter region as either border box or bounding client rects for split inline
… objections?
RESOLUTION: define filter region as either border box or bounding client rects for split inline
github-bot, take up w3c/
Image Orientation in <feImage> filter nodes
<github-bot> OK, I'll post this discussion to w3c/
schenney: this came out of a privacy issue filed in Chromium
… exif image orientation was being revealed for cross origin images
… back in the day, for html / css image orientation property
… the decision was that all cross-origin images would always be oriented
… so to resolve the privacy issue in Chrome, I switched it so we always apply exif orientation inside an feImage image which puts image into filter
… this matters for filters spec because SVG references CSS filters
… I agree with chris who commented in issue, best thing is to add attribute to feImage to control orientation and then solve this in SVG land
… gives users control and sovles the immediate problem
… only counterargument is that again a long time ago there was a desire to deprecate image orientation property entirely and always apply exif orientation
… but there's been no action on that in last 10 years so I don't think that's going to happen
… my proposal is option 3 in issue, work through svg and filters spec to add attribute to feImage about orientation
… open to any other ideas
<ChrisL> +1 to option 3
TabAtkins: quick question, for images used elsewhere in css or html, is the default now to always respect orientation
… and it's only if you use image-orientation that you can get original encoded orientation out?
schenney: yes. any place where there's no reasonable way to find an element with style that specifies image-orientation, we orient the image
… there's canvas cases for this
… only one this applies to is when image is drawn into canvas
… there's an open issue for hta
TabAtkins: spec currently says for image-orientation, inital values is from-iage, ist that what we do?
emilio: yes
TabAtkins: in that case I agree, let's do it
… don't care whether we add to feImage, was just waiting on information on whether image-orientation was web compatible
… don't see need to propagate anywhere else
emilio: agree but do we need the attribute?
… can we say feImage respects image-orientation?
schenney: certainly an option
… haven't gotten any bug reports since I changed it
<TabAtkins> (my opinion is that we don't need an attribute, yeah)
<ChrisL> I would be okay with that too
emilio: then my preference would be feImage respects image-orientation property
… do we need a mapped attribute for any reason?
astearns: I thought purpose of attribute is, what's implemented is applying orientation from exif image, no way for author to change it
emilio: but image-orientation property would be that, right?
<TabAtkins> (see the note at the end of <https://
schenney: problem for filters is that it's tricky to ... filter can be defined once and used all over the place
… could in theory pull image-orientation from element filter is applying to, but then same filter could be different in different places
emilio: need to check who is embedding the filter
<TabAtkins> we *first* defined "none" as the initial value (no exif), but then changed it to from-image and waited for impl feedback
schenney: makes implemenation messin in that situation
… there remain cases where you can't get an element to use
emilio: style would be on feImage, the thing you need to check is same-origin-ness of filter chain
… whether your filter is itself cross-origin
<TabAtkins> now that the feedback is "everyone changed their initial value and didn't hit any problems", we should pursue what the note said, and *try* to remove 'image-orientation' entirely, and not spread image-orientation-likes to any other APIs
emilio: in which case you don't honor image-orientation
schenney: this issue is about whether image referenced by filter is cross-origin
emilio: to what?
schenney: to the document using the filter
… security origin to which filter is applied
emilio: so that's the thing you need to check
… you could set feImage style=image-orientation:none
… but you need to tell if image is cross origin anyway
schenney: I guess feImage is an element,. could attach style to that element
emilio: thought that's what mapped attribute would do
schenney: let me test what happens, see if that's possible, in which case this issue may go away
… sounds like people are okay with always applying image orientation as fallback position
<Zakim> dbaron, you wanted to react to emilio
dbaron: one thing schenney said I wasn't sure
… there were cases that might cache an svg filter from element and use it both cross-origin and same origin?
… is that an issue you were bringing up?
schenney: that's not an issue, only that you could have 2 elements on page with different values for image-orientation, applying same filter to each one
… I don't think we're proposing that
ChrisL: reminder, presentation attributes are not analagous to a css property, they're exactly that property with 0 specificity
… any style will override
… not clear when you'd want an attribute on there instead of styling it
… unless you have an external styolesheet, in which case images don't allow external anything
schenney: I have a better understanding of issue with attribute, will confirm whether there's actually a workaround, will update issue
kurt: to emilio's point I think it makes sense to look at css property on feImage because that's where href is defined, that's where we look at origin
<emilio> right :)
schenney: yes I'll test and verify that works
github-bot, take up w3c/
[css-typed-om-1] Clarify reification of computed 1–4 side values
<github-bot> OK, I'll post this discussion to w3c/
emilio: tldr is that there's some different ... typedom doesn't define how some properties reify
… typed om was spec'ed such that ... how to reify particular properties
… browsers have diverged from the spec
… resolution I would want for this would be, we should define reification rules for a property at the place we define the property
… especially now that typed om is more cross browser
… agree with TabAtkins's last comment, we shouldn't rush and generically define a bunch of these
TabAtkins: strongly agree with emilio's suggestion that we add reification to propdef blocks
… reason it was defined for typedom is that it was for a while a chrome only api, didn't want to spread past speec
… would be clearer if we had that locally everywhere
… starting to make that adjustment would be a process, don't know when I'd get to it but happy to have help with it
… do not believe we can very usefully define generic rules for reification that will apply usefully across things
… point of typed om is that we get a useful reification of value
… that requires specialized apis for a lot of these things
… see for example transform lists
… as we do more of these we shouldn't get more of these specialized apis
… default behavior should be fall back to a string, not the best but still useful
… don't want to bake in something that blocks extension later
… so I propose that we (a) resolve to start adding reification behavior to propdef blocks
… happy to take a crack at a couple of them
… (b) spend a little more effort on getting reification behavior working
… I stopped working on it because high value part - transforms - was done
… those two resolutions then
<kbabbitt> +1 to proposal
weinig: I'm a little concerned about spreading this out to individual specs only because
… as things stand right now it would be easy to get things wrong
… not easy to update grammar in future and keep api the same
… before we spread it out to individual specs, look at how we approach some of the more complicated properties
… like the one in this bug where you have minimally serializing quad and figuring that out
<fantasai> +1 weinig
weinig: also think current status quo is bad, which is wpt doesn't match spec
<TabAtkins> +1
weinig: don't think what's in wpt is particularly well thought out, just what fell out of chrome implementation
… as I proposed in bug, would like to get to square one and reset wpt to only support the properties that are explicitly supported in spec
<TabAtkins> strong +1 to making wpt match the spec
weinig: then judiciously add back others
… have a plan to make webkit match spec rather than ad hoc behavior we have now
… agree with TabAtkins that needs to be long term solution but needs more love before we do that
emilio: to be clear I wasn't proposing we suddenly define them, reification unspported would be a reasonable place to start for most properties that are not defined
… would be fine with what weinig proposed, making sure wpt matches spec
… might be a good project if all browsers agree to change behavior at same time
… in table is better
weinig: don't think we're disagreeing, just putting some caution on it
astearns: let's take back to issue and discuss first steps, I think we're agreed on eventual end, need to figure out how we start
github-bot, end topic