7 ms·

Tether elements to each other with CSS anchor positioning

191 points by feross 4y ago

traviswt 4y ago
I’m not sure how I feel on this one. The solution looks complicated, but really the problem itself is also complicated. Maybe this is just as simple as it can get? Either way, avoiding a large amount of quite expensive JS is promising. Looking forward to seeing how this goes. Would love to rip out floating ui dependency.
- deleted 4y ago
  [deleted]
- fwlr 4y ago
  Fundamentally the anchoring problem requires you specify 1. the target you want to anchor to, and 2. where in relation to the target you want your content to appear (above, below, justified to a particular edge, etc…). “anchor: below ——my—target;” seems about as simple as you can get.
  - traviswt 4y ago
    Sure, the happy path is straightforward. I'm fine with that (except I don't see why they're pursuing the HTML attribute variant... just keep it CSS). The complexity comes later in the article when they talk about handling details and oddities. Like `position-fallback`. Again, maybe this is just as simple as it gets since it's just a hard problem. I really would love a CSS-only solution to this. Use cases are everywhere, and I certainly don't have any better ideas.
- danielvaughn 4y ago
  Yeah I'm fairly proficient with CSS, having written it for over a decade, and as I skimmed the article I found myself getting a bit overwhelmed. Seems like quite a bit of effort. For years I've been working on a programming language for UI designers, and this was one of the stumbling blocks for me. It's definitely a hard problem. My solution was to enforce unique names for every element, and then you could use a simple syntax for describing positioning constraints between them. For example: BlueSquare { width: 100px height: 100px top: 0px left: 0px } RedSquare { width: 100px height: 100px top: @BlueSquare.bottom + 10px left: @BlueSquare.right + 10px } This code would anchor the red square to the bottom/right of the blue square, with a 10px spacing between the two. Super simple! Far more difficult to implement a backend that satisfies this of course, which is why I haven't made much progress lol.
  - dezgeg 4y ago
    If I remember right, QML used in Qt allows that kind of positioning.
    - danielvaughn 4y ago
      Yep, Qt uses a very similar syntax.
  - sorcix 4y ago
    This is what Slint[1] does in their UI language[2]. 1: https://slint-ui.com/ https://slint-ui.com/ 2: https://slint-ui.com/releases/0.3.5/docs/rust/slint/docs/langref/index.html https://slint-ui.com/releases/0.3.5/docs/rust/slint/docs/lan...
    - danielvaughn 4y ago
      Every time I bring up my language on HN, someone tells me about a project I've never heard of before. This is super interesting, thanks for sharing!
  - bfgeek 4y ago
    FWIW the equivalent code with this API is: .BlueSquare { width: 100px; height: 100px; top: 0px; left: 0px; anchor-name: --BlueSquare; } .RedSquare { width: 100px; height: 100px; top: calc(anchor(--BlueSquare bottom) + 10px); left: calc(anchor(--BlueSquare right) + 10px); } https://jsfiddle.net/kbqua1te/ https://jsfiddle.net/kbqua1te/
- akersten 4y ago
  Part of the "hmm" factor for me on this one is that these "anchor" and "anchor-size" functions really just seem like cute names for a more generic "get position of element" and "get size of element" functions. So it's a big departure from the way I always imagined CSS (a tree of styles where an element was affected mostly/completely only by its ancestors/siblings) vs this proposal cracking that model by letting styles interact between elements "horizontally" across different trees. We already kind of did that with grid I guess. It feels like one step closer to imperative code in CSS rather than declarative, but I'll take it over JS to achieve this effect.
  - dylan604 4y ago
    This is the same felling I get about it as well. Breaking that understood cascading never sits well in my brain.
ramesh31 4y ago
This has been sorely needed for a long time. Z-index issues are a perennial nightmare on the frontend. And the React Portal style solution is less than ideal, as it introduces markup dependencies. Glad to see it finally handled by CSS.
fwlr 4y ago
CSS has several long-standing problems in a similar vein to this one, most famous being the “center a div” problem. A simple-to-specify end result (“I just want to center this content within its parent”) is desired, a series of arcane CSS magic invocations are devised and become accepted as the standard invocation to solve the problem (usually using translateX/Y -50%), and eventually a series of formal and more general solutions are implemented in the CSS spec that solve the problem in progressively fewer lines of CSS (first “display: flex; align-items: center; justify-content: center;”, now we are down to “place-self: center;”). It’s good to see that the problem of anchoring tooltips is progressing through this process!
- AndroidKitKat 4y ago
  Never heard of place-self before! I've always resorted to fumbling around with flexbox froggy and wondering why the changes I make to froggy seemingly don't do the same thing to my simple HTML.
  - werdnapk 4y ago
    First I've heard of place-self as well. I see it's been available for quite some time. I've always used the "longhand" version instead of this shorthand property. Good to know.
  - Erem 4y ago
    Laughing in bed because I always assumed I was the only one using froggy as my flexbox reference material. The worst is when you get angry and start blaming the frog for its lies. As if it's the frog's fault...
- xnx 4y ago
  Every few years I have to look up what the current state of the art is for centering something in CSS. I've so often been shocked that there still wasn't something as simple as <center>. Similarly, I couldn't believe how long it's taken to get something as useful as tables for layout.
  - 4y ago
xrd 4y ago
I stopped reading when it said this was behind a browser flag. Was I wrong to stop reading; is there a better story than that? I've been doing CSS long enough to know that to get things work you often have to work with what you have and that means wrapping things inside (otherwise) redundant containers, etc. Using a polyfill is less than ideal, but at least I have control over including this. And, it says it is under development, so I didn't even want to use that. But, asking my users to enable a browser flag? That's a non-starter. I'll file this under something interesting to revisit in a year or two.
- pancrufty 4y ago
  Uhm, this is a preview. You’re not supposed to use it until it’s widely available. They’re just showing it off and gathering feedback. > I'll file this under something interesting to revisit in a year or two. Correct. However things are moving fast so certain new features become widely available within months.
  - londons_explore 4y ago
    > available within months. Unless you need to support iOS... In which case, wait a few years because we can't have the web platform being too effective compared to apps...
    - micromacrofoot 4y ago
      They've been very quick at implementing CSS changes in Safari, faster than Firefox in some cases, but yeah bigger web APIs like push notifications have taken too long
      - londons_explore 4y ago
        Perhaps because CSS is entirely a programming task within the rendering engine... But Web Push requires changes from the whole browser, perhaps minor changes to the OS, and probably a whole server side implementation. And with all that cross-team effort going on, it's very easy for management to deprioritize it.
stephen 4y ago
I don't suppose this (or another forthcoming CSS property) would allow multiple `position: sticky` elements to stack after each other (instead of underneath)? That is one of our biggest layout PITAs, is the slippery slope of "sticky the table header" ... "and the filtering controls above it" ... "and the page header as well", and these are all across different levels of the DOM / component tree. We currently solve it with React portals, which lets elements in the component tree "promote up" their localized content to the single/top-level-stickied div, so that within that div they can all flow after each other & not overlap.
- traviswt 4y ago
  This sounds interesting to me. One of the struggles with sticky table headers is supporting automatic column widths. How does your portal trick support that? Currently I'm using a double rendering trick combined with resize observers.
  - stephen 4y ago
    We only use `position: sticky` for the first row of the table, but then stack everything else in a separate div, so something like: - parent div -- 1st child div, everything that is "stickied" to the top of the screen (really a tree of react components like the header + filters + table actions) -- 2nd child div, the table itself with a single position: sticky header row The portal trick/approach is that technically the table is rendered by some leaf-ish component in the 1st child's component tree, but once the leaf components knows "hey I'm the leaf", it uses a portal to push it's content to the 2nd top-level child, which gets it stuck below everything in the 1st child. It sounds kind of elaborate, but it lets everything in the top div get correctly dynamically sized without any hard-coded offset hacks.
- DaiPlusPlus 4y ago
  > is the slippery slope of "sticky the table header" ... "and the filtering controls above it" ... "and the page header as well", and these are all across different levels of the DOM / component tree. I've been using `thead > tr > * { position: sticky; }` just fine for years, with filtering controls within `<th>`. Don't forget to also specify `scroll-margin:` though, as that's how you get `position: sticky` to play-nice with other potentially-overlapping elements.
sam_goody 4y ago
Is this being done by the Chrome team alone, or has this been submitted to a group like whatwg? I think it is important for Chrome to keep on innovating, but the community should call them out for assuming a monopolistic position.
- matt_kantor 4y ago
  There's a link to the CSSWG draft[0] in TFA (along with a warning that the current implementation isn't completely in sync with it). [0]: https://drafts.csswg.org/css-anchor-position-1/ https://drafts.csswg.org/css-anchor-position-1/
- jefftk 4y ago
  The spec is a W3C CSS working group draft: https://drafts.csswg.org/css-anchor-position-1/ https://drafts.csswg.org/css-anchor-position-1/ It looks like less of a Chrome thing and more of an Edge thing? The Intent to Prototype [1] links to an Edge explainer [2] with Microsoft authors. It doesn't look like anyone has asked Mozilla for a position yet [3] but I expect if they get positive signals from web developers (us!) that will be soon. [1] https://groups.google.com/a/chromium.org/g/blink-dev/c/vsPddM3fGj0/m/5s87Yx95BAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/vsPdd... [2] https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/... [3] https://github.com/mozilla/standards-positions/issues?q=anchor https://github.com/mozilla/standards-positions/issues?q=anch...
caseyf 4y ago
If you liked this and you use Twitter, follow the author (@jh3yy) - one of my favorite CSS tweeters. eg "Use anchor positioning to tether an element to multiple anchors" https://twitter.com/jh3yy/status/1628127228763537409 https://twitter.com/jh3yy/status/1628127228763537409
pupppet 4y ago
I made a drag-and-drop page builder once upon a time and tethering the tooltip to the draggable object was such a pain in the ass unless I made the tooltip a child of the draggable object which isn’t ideal. Can’t wait to see CSS anchoring.
akersten 4y ago
I wonder if they should rename the concept to avoid confusion with the ubiquitous and existing anchor tag, <a>? :( I think it's confusing to introduce an HTML attribute named "anchor" that has nothing to do with HTML anchors.
- Narretz 4y ago
  Well most people don't call it an anchor tag, they call it an a or link tag. I think the battle for clear naming is already lost. What would be a good alternative name for anchor positioning, though?
  - bobbylarrybobby 4y ago
    Tether?
billconan 4y ago
I use the position:absolute approach, but One issue I don't know how to solve is that part of the floating div might be outside its parent, and will stretch the size of its parent. Even the parent has display:relative; overflow: hidden.
graderjs 4y ago
It's sort of like Storyboard layout constraints in MacOS app development?
jefftk 4y ago
Draft specification: https://drafts.csswg.org/css-anchor-position-1/ https://drafts.csswg.org/css-anchor-position-1/
Bagusajiwo01 4y ago
[flagged]
vimax 4y ago
This is a dangerous proposal, it includes adding a new HTML element attribute “anchor” that will completely reposition the element. I would expect there are frameworks out there using “anchor” as a custom attribute that this would break. Changing the CSS spec is all well and good, but I’d like a slower more considered approach to the HTML spec.
- tuukkah 4y ago
  Isn't the introduction of new attributes perfectly normal in how HTML advances? If a framework breaks because of that, it's their own fault.
- megaman821 4y ago
  Shouldn't they be using `data-anchor` then? If you are using raw attributes then you risk breakages.
tannhaeuser 4y ago
At a certain point you've got to draw a line and say this isn't a case for CSS and HTML don't you? We should've developed/completed Houdini (allowing low-level access to layout from JavaScript) ages ago to save us from incorporating everything under the sun into CSS only to arrive at a single implementation able to render it.
c-smile 4y ago
Just CSS is not enough for tooltips... Here is what we've got in 10+ tooltip providing experience in Sciter[1] ... Declarative tooltips support: <div title="some text" /> <div titleid="dom-element-id" /> <div tooltip="<b>some html goes here</b>" /> Dynamic support, on demand, event handler: element.ontooltiprequest = function(evt) { evt.relatedTarget = ... some dome element reference ... } Dynamic, explicit popup show: anchorEl.popup(popupEl, {anchorPos:..., popupPos:...}); anchorEl.popup(<div>some JSX expr</div>, {anchorPos:..., popupPos:...}); Popups (tooltips included) are shown as out-of-canvas elements - separate desktop windows, that's the must for desktop UI. Check this: https://terrainformatica.com/w3/sciter-tooltip.png https://terrainformatica.com/w3/sciter-tooltip.png So far these APIs appear as complete, I do not have other tooltip related requests last 5 or so years. And finally CSS styling: anchorselector > popup[role="tooltip"] { ... } [1] https://sciter.com https://sciter.com
- wildrhythms 4y ago
  How do you style the tooltips? Fixed positioning? I always run into issues where I need to maintain some document.body level collection of tooltips because 'position: fixed' is affected by its parent elements also having 'position: fixed' applied- it's deceptively not as simple as just inserting a tooltip in the DOM where the anchor lives.
  - c-smile 4y ago
    There is a special internal position:popup mode that cannot be set in CSS. Only internally. position:popup is accompanied with the pair of anchor-position:1..9 and popup-position:1..9 props. For the meaning of these numbers see NUMPAD keys on keyboard. They define attachment of popup to the anchor. anchor-position:1; popup-position:7; means border-box bottom-left corner of anchor corresponds to top-left margin box corner of popup. That positioning schema defines position of the popup relative to the anchor.
sugeng020881 4y ago
[flagged]
a1371 4y ago
I don't understand why we can't have something like this: ``` .target { name: myname } .tooltip: { left: var(myname.left), bottom: calc(var(myname.top)-20px) } ``` What's hard about exposing some element properties in var()? Instead of just making specific APIs all the time.
- bfgeek 4y ago
  With this API this would be: .target { anchor-name: --myname; } .tooltip { left: anchor(--myname left); bottom: calc(anchor(--myname top) - 20px); } https://jsfiddle.net/3rasnhyp/ https://jsfiddle.net/3rasnhyp/

191 points by feross 4y ago

I’m not sure how I feel on this one. The solution looks complicated, but really the problem itself is also complicated. Maybe this is just as simple as it can get? Either way, avoiding a large amount of quite expensive JS is promising. Looking forward to seeing how this goes. Would love to rip out floating ui dependency.

deleted 4y ago
[deleted]
fwlr 4y ago
Fundamentally the anchoring problem requires you specify 1. the target you want to anchor to, and 2. where in relation to the target you want your content to appear (above, below, justified to a particular edge, etc…). “anchor: below ——my—target;” seems about as simple as you can get.
- traviswt 4y ago
  Sure, the happy path is straightforward. I'm fine with that (except I don't see why they're pursuing the HTML attribute variant... just keep it CSS). The complexity comes later in the article when they talk about handling details and oddities. Like `position-fallback`. Again, maybe this is just as simple as it gets since it's just a hard problem. I really would love a CSS-only solution to this. Use cases are everywhere, and I certainly don't have any better ideas.
danielvaughn 4y ago
Yeah I'm fairly proficient with CSS, having written it for over a decade, and as I skimmed the article I found myself getting a bit overwhelmed. Seems like quite a bit of effort. For years I've been working on a programming language for UI designers, and this was one of the stumbling blocks for me. It's definitely a hard problem. My solution was to enforce unique names for every element, and then you could use a simple syntax for describing positioning constraints between them. For example: BlueSquare { width: 100px height: 100px top: 0px left: 0px } RedSquare { width: 100px height: 100px top: @BlueSquare.bottom + 10px left: @BlueSquare.right + 10px } This code would anchor the red square to the bottom/right of the blue square, with a 10px spacing between the two. Super simple! Far more difficult to implement a backend that satisfies this of course, which is why I haven't made much progress lol.
- dezgeg 4y ago
  If I remember right, QML used in Qt allows that kind of positioning.
  - danielvaughn 4y ago
    Yep, Qt uses a very similar syntax.
- sorcix 4y ago
  This is what Slint[1] does in their UI language[2]. 1: https://slint-ui.com/ https://slint-ui.com/ 2: https://slint-ui.com/releases/0.3.5/docs/rust/slint/docs/langref/index.html https://slint-ui.com/releases/0.3.5/docs/rust/slint/docs/lan...
  - danielvaughn 4y ago
    Every time I bring up my language on HN, someone tells me about a project I've never heard of before. This is super interesting, thanks for sharing!
- bfgeek 4y ago
  FWIW the equivalent code with this API is: .BlueSquare { width: 100px; height: 100px; top: 0px; left: 0px; anchor-name: --BlueSquare; } .RedSquare { width: 100px; height: 100px; top: calc(anchor(--BlueSquare bottom) + 10px); left: calc(anchor(--BlueSquare right) + 10px); } https://jsfiddle.net/kbqua1te/ https://jsfiddle.net/kbqua1te/
akersten 4y ago
Part of the "hmm" factor for me on this one is that these "anchor" and "anchor-size" functions really just seem like cute names for a more generic "get position of element" and "get size of element" functions. So it's a big departure from the way I always imagined CSS (a tree of styles where an element was affected mostly/completely only by its ancestors/siblings) vs this proposal cracking that model by letting styles interact between elements "horizontally" across different trees. We already kind of did that with grid I guess. It feels like one step closer to imperative code in CSS rather than declarative, but I'll take it over JS to achieve this effect.
- dylan604 4y ago
  This is the same felling I get about it as well. Breaking that understood cascading never sits well in my brain.

ramesh31 4y ago

This has been sorely needed for a long time. Z-index issues are a perennial nightmare on the frontend. And the React Portal style solution is less than ideal, as it introduces markup dependencies. Glad to see it finally handled by CSS.

fwlr 4y ago

CSS has several long-standing problems in a similar vein to this one, most famous being the “center a div” problem. A simple-to-specify end result (“I just want to center this content within its parent”) is desired, a series of arcane CSS magic invocations are devised and become accepted as the standard invocation to solve the problem (usually using translateX/Y -50%), and eventually a series of formal and more general solutions are implemented in the CSS spec that solve the problem in progressively fewer lines of CSS (first “display: flex; align-items: center; justify-content: center;”, now we are down to “place-self: center;”). It’s good to see that the problem of anchoring tooltips is progressing through this process!

AndroidKitKat 4y ago
Never heard of place-self before! I've always resorted to fumbling around with flexbox froggy and wondering why the changes I make to froggy seemingly don't do the same thing to my simple HTML.
- werdnapk 4y ago
  First I've heard of place-self as well. I see it's been available for quite some time. I've always used the "longhand" version instead of this shorthand property. Good to know.
- Erem 4y ago
  Laughing in bed because I always assumed I was the only one using froggy as my flexbox reference material. The worst is when you get angry and start blaming the frog for its lies. As if it's the frog's fault...
xnx 4y ago
Every few years I have to look up what the current state of the art is for centering something in CSS. I've so often been shocked that there still wasn't something as simple as <center>. Similarly, I couldn't believe how long it's taken to get something as useful as tables for layout.
- 4y ago

xrd 4y ago

I stopped reading when it said this was behind a browser flag. Was I wrong to stop reading; is there a better story than that? I've been doing CSS long enough to know that to get things work you often have to work with what you have and that means wrapping things inside (otherwise) redundant containers, etc. Using a polyfill is less than ideal, but at least I have control over including this. And, it says it is under development, so I didn't even want to use that. But, asking my users to enable a browser flag? That's a non-starter. I'll file this under something interesting to revisit in a year or two.

pancrufty 4y ago
Uhm, this is a preview. You’re not supposed to use it until it’s widely available. They’re just showing it off and gathering feedback. > I'll file this under something interesting to revisit in a year or two. Correct. However things are moving fast so certain new features become widely available within months.
- londons_explore 4y ago
  > available within months. Unless you need to support iOS... In which case, wait a few years because we can't have the web platform being too effective compared to apps...
  - micromacrofoot 4y ago
    They've been very quick at implementing CSS changes in Safari, faster than Firefox in some cases, but yeah bigger web APIs like push notifications have taken too long
    - londons_explore 4y ago
      Perhaps because CSS is entirely a programming task within the rendering engine... But Web Push requires changes from the whole browser, perhaps minor changes to the OS, and probably a whole server side implementation. And with all that cross-team effort going on, it's very easy for management to deprioritize it.

stephen 4y ago

I don't suppose this (or another forthcoming CSS property) would allow multiple `position: sticky` elements to stack after each other (instead of underneath)? That is one of our biggest layout PITAs, is the slippery slope of "sticky the table header" ... "and the filtering controls above it" ... "and the page header as well", and these are all across different levels of the DOM / component tree. We currently solve it with React portals, which lets elements in the component tree "promote up" their localized content to the single/top-level-stickied div, so that within that div they can all flow after each other & not overlap.

traviswt 4y ago
This sounds interesting to me. One of the struggles with sticky table headers is supporting automatic column widths. How does your portal trick support that? Currently I'm using a double rendering trick combined with resize observers.
- stephen 4y ago
  We only use `position: sticky` for the first row of the table, but then stack everything else in a separate div, so something like: - parent div -- 1st child div, everything that is "stickied" to the top of the screen (really a tree of react components like the header + filters + table actions) -- 2nd child div, the table itself with a single position: sticky header row The portal trick/approach is that technically the table is rendered by some leaf-ish component in the 1st child's component tree, but once the leaf components knows "hey I'm the leaf", it uses a portal to push it's content to the 2nd top-level child, which gets it stuck below everything in the 1st child. It sounds kind of elaborate, but it lets everything in the top div get correctly dynamically sized without any hard-coded offset hacks.
DaiPlusPlus 4y ago
> is the slippery slope of "sticky the table header" ... "and the filtering controls above it" ... "and the page header as well", and these are all across different levels of the DOM / component tree. I've been using `thead > tr > * { position: sticky; }` just fine for years, with filtering controls within `<th>`. Don't forget to also specify `scroll-margin:` though, as that's how you get `position: sticky` to play-nice with other potentially-overlapping elements.

sam_goody 4y ago

Is this being done by the Chrome team alone, or has this been submitted to a group like whatwg? I think it is important for Chrome to keep on innovating, but the community should call them out for assuming a monopolistic position.

matt_kantor 4y ago
There's a link to the CSSWG draft[0] in TFA (along with a warning that the current implementation isn't completely in sync with it). [0]: https://drafts.csswg.org/css-anchor-position-1/ https://drafts.csswg.org/css-anchor-position-1/
jefftk 4y ago
The spec is a W3C CSS working group draft: https://drafts.csswg.org/css-anchor-position-1/ https://drafts.csswg.org/css-anchor-position-1/ It looks like less of a Chrome thing and more of an Edge thing? The Intent to Prototype [1] links to an Edge explainer [2] with Microsoft authors. It doesn't look like anyone has asked Mozilla for a position yet [3] but I expect if they get positive signals from web developers (us!) that will be soon. [1] https://groups.google.com/a/chromium.org/g/blink-dev/c/vsPddM3fGj0/m/5s87Yx95BAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/vsPdd... [2] https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/... [3] https://github.com/mozilla/standards-positions/issues?q=anchor https://github.com/mozilla/standards-positions/issues?q=anch...

caseyf 4y ago

If you liked this and you use Twitter, follow the author (@jh3yy) - one of my favorite CSS tweeters. eg "Use anchor positioning to tether an element to multiple anchors" https://twitter.com/jh3yy/status/1628127228763537409 https://twitter.com/jh3yy/status/1628127228763537409

pupppet 4y ago

I made a drag-and-drop page builder once upon a time and tethering the tooltip to the draggable object was such a pain in the ass unless I made the tooltip a child of the draggable object which isn’t ideal. Can’t wait to see CSS anchoring.

akersten 4y ago

I wonder if they should rename the concept to avoid confusion with the ubiquitous and existing anchor tag, <a>? :( I think it's confusing to introduce an HTML attribute named "anchor" that has nothing to do with HTML anchors.

Narretz 4y ago
Well most people don't call it an anchor tag, they call it an a or link tag. I think the battle for clear naming is already lost. What would be a good alternative name for anchor positioning, though?
- bobbylarrybobby 4y ago
  Tether?

billconan 4y ago

I use the position:absolute approach, but One issue I don't know how to solve is that part of the floating div might be outside its parent, and will stretch the size of its parent. Even the parent has display:relative; overflow: hidden.

graderjs 4y ago

It's sort of like Storyboard layout constraints in MacOS app development?

jefftk 4y ago

Draft specification: https://drafts.csswg.org/css-anchor-position-1/ https://drafts.csswg.org/css-anchor-position-1/

Bagusajiwo01 4y ago

[flagged]

vimax 4y ago

This is a dangerous proposal, it includes adding a new HTML element attribute “anchor” that will completely reposition the element. I would expect there are frameworks out there using “anchor” as a custom attribute that this would break. Changing the CSS spec is all well and good, but I’d like a slower more considered approach to the HTML spec.

tuukkah 4y ago
Isn't the introduction of new attributes perfectly normal in how HTML advances? If a framework breaks because of that, it's their own fault.
megaman821 4y ago
Shouldn't they be using `data-anchor` then? If you are using raw attributes then you risk breakages.

tannhaeuser 4y ago

At a certain point you've got to draw a line and say this isn't a case for CSS and HTML don't you? We should've developed/completed Houdini (allowing low-level access to layout from JavaScript) ages ago to save us from incorporating everything under the sun into CSS only to arrive at a single implementation able to render it.

c-smile 4y ago

Just CSS is not enough for tooltips... Here is what we've got in 10+ tooltip providing experience in Sciter[1] ... Declarative tooltips support: <div title="some text" /> <div titleid="dom-element-id" /> <div tooltip="<b>some html goes here</b>" /> Dynamic support, on demand, event handler: element.ontooltiprequest = function(evt) { evt.relatedTarget = ... some dome element reference ... } Dynamic, explicit popup show: anchorEl.popup(popupEl, {anchorPos:..., popupPos:...}); anchorEl.popup(<div>some JSX expr</div>, {anchorPos:..., popupPos:...}); Popups (tooltips included) are shown as out-of-canvas elements - separate desktop windows, that's the must for desktop UI. Check this: https://terrainformatica.com/w3/sciter-tooltip.png https://terrainformatica.com/w3/sciter-tooltip.png So far these APIs appear as complete, I do not have other tooltip related requests last 5 or so years. And finally CSS styling: anchorselector > popup[role="tooltip"] { ... } [1] https://sciter.com https://sciter.com

wildrhythms 4y ago
How do you style the tooltips? Fixed positioning? I always run into issues where I need to maintain some document.body level collection of tooltips because 'position: fixed' is affected by its parent elements also having 'position: fixed' applied- it's deceptively not as simple as just inserting a tooltip in the DOM where the anchor lives.
- c-smile 4y ago
  There is a special internal position:popup mode that cannot be set in CSS. Only internally. position:popup is accompanied with the pair of anchor-position:1..9 and popup-position:1..9 props. For the meaning of these numbers see NUMPAD keys on keyboard. They define attachment of popup to the anchor. anchor-position:1; popup-position:7; means border-box bottom-left corner of anchor corresponds to top-left margin box corner of popup. That positioning schema defines position of the popup relative to the anchor.

sugeng020881 4y ago

[flagged]

a1371 4y ago

I don't understand why we can't have something like this: ``` .target { name: myname } .tooltip: { left: var(myname.left), bottom: calc(var(myname.top)-20px) } ``` What's hard about exposing some element properties in var()? Instead of just making specific APIs all the time.

bfgeek 4y ago
With this API this would be: .target { anchor-name: --myname; } .tooltip { left: anchor(--myname left); bottom: calc(anchor(--myname top) - 20px); } https://jsfiddle.net/3rasnhyp/ https://jsfiddle.net/3rasnhyp/