There are already a few sites that don't work properly in Firefox, people started testing only for chrome because its market share is so big.
Really unfortunate because it lets Google get away with anything they want, they are the new standard. But then again, I'm reminded of how Mozilla has pissed away all the users goodwill, and it's not a surprise.
Would be cooler if the whole system were more flexible: you simply define 2 anchor points (one on the target, another on the source, so center bottom would be bottom width 50% and top width 50%) instead of being limited to the 9 predefined areas
`position-anchor` is a high-level simple way of doing it, and it comes with the restrictions you mention. However, the `anchor()` function, which is also mentioned in the article, gives you the kind of flexibility you want.
I’m surprised it’s not in Firefox. I don’t remember the last time I ran into something in Safari and Chrome but not FF.
I was reading the article and thinking it would be a great thing to adopt for some code we recently wrote, but we have to support Firefox. And since we already have an existing solution that works, no point cleaning it up with this until Firefox adopts it.
I occasionally look into what CSS is being transcoded for the projects I work on, and it’s normally Firefox ESR that needs the most help. If you eliminate that from your browserlists configuration, your source and deployed CSS become a lot more closely aligned. For instance, it was only a year ago that Firefox ESR got CSS nesting.
It solves many of the pain points Tether[0] tried to solve.
For example it helps when the anchoring element is inside of an oveflow hidden/scroll container, but geometrically you need the tethered element to sit/extend outside of the container (so—for now at least—its DOM node needs to be outside of the container).
This always results in a ton of hacky JS to detect how the element should reposition itself if it overflows the screen (depending on the content and screen size)
This relies on being able to set the position relative to a parent selector, this doesn't work if the element you are positioning is not a descendant of the element you wish to anchor to.
Anchor positioning sounds cool, but I ran into some very unintuitive behavior when I tried to use it. Can’t remember the details, it was a couple years ago.
My problem is always been on sites that have a menu or something similar at the top. The anchor always inevitably goes to the very top of the screen gets covered by whatever menu it is.
I guess you're being downvoted as a general nay-sayer, but you're right. I tried this feature last month and a bunch of browser bugs and design issues got in the way. I reported them, and they're being worked on https://github.com/w3c/csswg-drafts/issues/12466
The `margin:0` issue was particularly frustrating & imo should have been covered in the article, as it's a real gotcha when trying to use popover & anchor positioning in combination.
Doesn't this count? Been there for several years.
https://github.com/oddbird/css-anchor-positioning
Really unfortunate because it lets Google get away with anything they want, they are the new standard. But then again, I'm reminded of how Mozilla has pissed away all the users goodwill, and it's not a surprise.
[0] https://anchoreum.com/
https://developer.mozilla.org/en-US/docs/Web/CSS/anchor
I was reading the article and thinking it would be a great thing to adopt for some code we recently wrote, but we have to support Firefox. And since we already have an existing solution that works, no point cleaning it up with this until Firefox adopts it.
Still, looks like a very nice feature.
It’s not especially uncommon. For instance payment requests, web share, and remote playback are all implemented by Blink and WebKit but not Gecko.
https://developer.mozilla.org/en-US/docs/Web/API/Payment_Req...
https://developer.mozilla.org/en-US/docs/Web/API/Web_Share_A...
https://developer.mozilla.org/en-US/docs/Web/API/RemotePlayb...
I occasionally look into what CSS is being transcoded for the projects I work on, and it’s normally Firefox ESR that needs the most help. If you eliminate that from your browserlists configuration, your source and deployed CSS become a lot more closely aligned. For instance, it was only a year ago that Firefox ESR got CSS nesting.
IIRC Firefox lagged quite a lot on Color Profiles and :has
Background data sync/download with continuation
Very true, they started 2 years ago and it has been constantly worked on with the latest update 12 days ago: https://bugzilla.mozilla.org/show_bug.cgi?id=1838746
So, it literally will be "any day now" :-/
For example it helps when the anchoring element is inside of an oveflow hidden/scroll container, but geometrically you need the tethered element to sit/extend outside of the container (so—for now at least—its DOM node needs to be outside of the container).
[0] https://tetherjs.dev
The simplest example is if you have content that it not contained by the box you're positioning against. Think tooltips, popovers, etc.
For some usecases like annotating content, this hugely simplifies things.
The `margin:0` issue was particularly frustrating & imo should have been covered in the article, as it's a real gotcha when trying to use popover & anchor positioning in combination.