Amy: No activity at all. They stated a deadline of 16th June, but not what this was for. Chrome status says it's shipping (117). Positive signals from firefox.

Amy: Proposal: is this noncontroversial? Just okay it? (this is a q for Peter and Lea)

Lea: looking at it right now it looks quite well designed to me - developers need this desperately. Seems like a really well thought out API.

Rossen: concerned with the default fallback behavior. It requires authoring rather than having an esxpected behavior handled by the UA. There are a number of choices we could take - absolute element... default static position.

Lea: that would not work for tool tips and stuff...

Rossen: what would happen to UAs that dom't implement it?

Lea: will write comment after the call

Tess: some discussion on CSS calls... I think people are actively working on a counterproposal.

Tess: css f2f happening soon - let's hold off...

Lea: looks like there was another proposal presented at the CSS wg... don't know if there's a point in doing a TAG review right now. I asked in the CSS meeting whether we should review - and I was told that there is.

Rossen: My take - is that there is a proposal on the table - the spec has been worked on - there are additional considerations... The new proposal is a simplification ... very little new functionality. People working on this were caught off-guard. Should we review or not? I would put to back to the authors... I don't have a strong reason why we shouldn't.

Lea: seems almost certain it will change signifigantly. Ideally they should update us and let us know.

Lea: i did review - and posted feedback... My main points are: developers want this - but main concern is that (tho it's nice fall back can be specified) fallbacks are opt in - and if you don't do anything then popups stay... which seems undesirable. it seems to me the common case should be the one that requires least amount of code. "i want this popup to be visible in visible part of the viewport" - that should be default behaviour. With new proposal that behaviour is more possible.

Rossen: could we feed back

Lea: "Givenhow the position is specified here it's hard for the browser to figure out what the fallback should be automatically - without the author having to specify explicit fallbacks." Counter-arg from Tab was that there are cases where you don't want a fallback. I suspect the percentage of these cases would be very small. Bigggest painpoint that this solves is positioning menus, etc...

... other question was - "it seems difficult to do a pointer... with popups and menus you sometimes want a pointer arrow."

... new API is very well designed and solves these issues.

Peter: i don't think we should review this without incorporating our information about the new proposal. Maybe put this on hold?

Rossen: i think they are gonna take this back to the whiteboard.

Rossen: we should ask - should we wait for a new proposal?

Peter: not sure we need to be quite so formal...

Lea: we could also establish that these are TAG concerns..

Peter: +1

Dan: +1

Rossen: Yes that's fine. I support.

Peter: if wg ships this as level 1 and something else as level 2...

Peter: i think the comments stand as they are - I don't think we need to clarify anything.

Rossen: let's just ask Tab explicitly - with the propisal of new additions an enhancements to this, how should we proceed?

Peter: "givem that we know of propisals to enahance this, we're gonna pause this review." I can post that

Lea: we've replied - there's nothing to reply... there's a new proposal...

Lea: we said we'll pause our review

Peter: [update milestone]

Rossen: ... since pause, there has been at least one breakout on this that did bring alignment... Not sure if other onese since... Not aware of large disagreements. If that's the case, can we unpause? Could we say "we like this, developers want it, belongs in the CSS layer and we think CSS wg should work on it."

Lea: we don't need to do a review to say this.

Peter: apple came up with a new design...

Lea: valid reasons for the new design... we paused the review to review the end proposal... we don't even need an explainer to say that... j

Rossen: path forward is pretty well aligned... syntax difference will be resolved by the working group.

Peter: question is: do we have something to review?

Lea: I don't think we do.

Peter: it's worth waiting until the wg resolves on something... maybe that's happened but I don't see it written down. Let's kick it down the road. We already left positive feedback.

bumped

(We didn't get to this one; oops!)

Punting as Lea isn't present

general discussion of spec; concerns around complexity of @position-try; whether anchor positioning could be more of an extension to absolute positioning; and the use cases for the fixed position aspect (explicit DOM relationships seem preferred - the explainer doesn't elaborate)

Peter: Feels related to work that went on in SVG to produce links between objects (at least in use case). There's an example of anchoring to two other elements. Maybe useful for SVG?

Martin: @position-try seems like a whole new feature - concern about how it fits with the rest of the platform.

Peter: Agree

Martin: At what point do you try one of the alternatives? Why is there no declarative way of saying what would cause you to try an alternative? Currently seems like the only reason is if overflow is detected. It's possible to generate a situation that will never trigger overflow.

Matthew: prefers-interaction-side proposal may provide a reason to try things in a different order? (Either physical preference, or viewport aspect ratio)

Martin: Privacy concerns three. It's better to provide non-exposed preferences to support use cases like this. Better to find ways to adapt content based on screen size (media query @screen) than to have passive fingerprinting.

Matthew: Maybe we should ask Lea (who is participating in CSS) what the status in the WG is.

Peter: Needs Lea's input, but not sure when we can.

Starting some draft feedback...

Discussions on blink-dev suggest that there might not be WG consensus on the maturity of the specification. The recently-opened issues also indicate some unresolved questions.

FIXME(grammar): Unclear what the implications of anchor-name and anchor-scope for authors. The algorithm for finding anchors is complex and not exactly intuitive.

anchor-scope does not appear in the explainer(s) and does not appear to feature in the algorithm that finds an anchor.

Interactions with shadow DOM are not covered by the explainers (though it is in the specification)

Not clear about position: fixed vs position: absolute and how this works. e.g. why an author would choose one vs the other. This doesn't appear to be explained in the spec. A related question is why not a new position type vs extending absolute/fixed, e.g. position: anchor(ed). This could also result in renaming the anchoring specific position-* properties as anchor-* and making it clearer that they only apply in the anchor use-case.

We're concerned about the status of the explainer relative to the Chromium blog post.

The [@]position-try[-options] part seems like it might not be baked. We observe that this produces an alternative set of styling rules that can be activated under specific conditions, but those conditions cannot be specified by authors and are limited to when elements overflow. A better alternative might be to either put all the positioning controls into a @position (or @anchor or even @alternative) rule and just refer to that from the style declaration (which could then be a list of positions, rather than set of properties and then a list of overrides to try), or to have a syntax that keeps the alternatives in the primary delcaration. Some future planning as to other triggers for alternate positions may be warranted as well.

Tess to read the re-drafted feedback cooked up in breakout B

Lea: I propose closing ... we expressed some concerns ... the response was some of these things can be done in the future ... or defered ... "this has shipped in chrome" ... It's addressing a major author pain point. I think it could have been designed better. It has been improved from the original version, thanks to Apple. So I think it's a lot better. I worry about the easy of use vs. power curve...

Peter: I would say "satisifed with concerns" as I have concerns. I haven't been as active in the CSS wg... but I don't think Tab has taken any of these concerns back to the working group...

Tess: the wg is asking us to look at their spec - they should be receiving our feedback.

Dan: leaves comment

Jeffrey: chrome shipped it... CSS discussed... chrome fixed certain things... still one disagreement... otherwise it feels fully discussed in CSS... Think there aren't architectural things for the TAG to address.

Tess: is the thing where we cause a pile of compat problems every time we try to make a heretofore-not-a-shorthand thing a shorthand...?

Jeffrey: Yes. I would like to close it as satisfied.

Tess: this feels like a classic theoretical purity vs. compat risk ... I'm fine with closing it as satisfied.

Dan: sets to proposed closed

Dan: great! let's revisit at the plenary call.