[HN Gopher] Tether elements to each other with CSS anchor positi...
___________________________________________________________________
Tether elements to each other with CSS anchor positioning
Author : feross
Score : 170 points
Date : 2023-03-01 12:18 UTC (10 hours ago)
(HTM) web link (developer.chrome.com)
(TXT) w3m dump (developer.chrome.com)
| a1371 wrote:
| 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 wrote:
| 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/
| jefftk wrote:
| Draft specification: https://drafts.csswg.org/css-anchor-
| position-1/
| tannhaeuser wrote:
| 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.
| traviswt wrote:
| 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]
| akersten wrote:
| 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 wrote:
| This is the same felling I get about it as well. Breaking
| that understood cascading never sits well in my brain.
| fwlr wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| If I remember right, QML used in Qt allows that kind of
| positioning.
| danielvaughn wrote:
| Yep, Qt uses a very similar syntax.
| bfgeek wrote:
| 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/
| sorcix wrote:
| This is what Slint[1] does in their UI language[2].
|
| 1: https://slint-ui.com/
|
| 2: https://slint-
| ui.com/releases/0.3.5/docs/rust/slint/docs/lan...
| danielvaughn wrote:
| 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!
| sam_goody wrote:
| 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.
| jefftk wrote:
| The spec is a W3C CSS working group draft:
| 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/vsPdd...
|
| [2]
| https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/...
|
| [3] https://github.com/mozilla/standards-
| positions/issues?q=anch...
| matt_kantor wrote:
| 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/
| pupppet wrote:
| 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.
| Bagusajiwo01 wrote:
| Kakekmerah4d
| stephen wrote:
| 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 wrote:
| 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.
| DaiPlusPlus wrote:
| > 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.
| billconan wrote:
| 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.
| ramesh31 wrote:
| 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.
| vimax wrote:
| 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.
| megaman821 wrote:
| Shouldn't they be using `data-anchor` then? If you are using
| raw attributes then you risk breakages.
| tuukkah wrote:
| 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.
| fwlr wrote:
| 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 wrote:
| 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.
| Erem wrote:
| 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...
| werdnapk wrote:
| 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.
| 6510 wrote:
| Mt secret is to use <center> but I cant remember how many times
| I've considered using js and absolute positioning. The user
| clicks an image, the image is enlarged to fit the viewport,
| remaining space is filled with a color. Doable with css. The
| user zooms the image (scale), so far so good... the user pans
| the image... uhh how do I limit panning in css? bounding
| rectangle + get computered style??
| lelandfe wrote:
| Pan by adding a wrapping element with 'overflow: hidden' and
| use 'translate' to move the child image element inside it.
| rad_gruchalski wrote:
| > most famous being the "center a div" problem
|
| It's crazy how many attempts at this have been done over the
| years. And it worked great in Adobe Flex, back in 2009.
| LoganDark wrote:
| With display:flex on the parent you can just put margin:auto on
| the child. That's what I do and it works fine. Although I admit
| to having used the transform trick more than a few times before
| flexbox was a thing.
| c-smile wrote:
| If we would have flex units instead of display:flexbox then
| this: div { width:max-content;
| margin:*; }
|
| is enough to place block in the middle of its container
| (vertically and horizontally), see:
| https://terrainformatica.com/2018/12/11/10-years-of-flexboxi...
| martin_a wrote:
| Whaaaaaat? I thought
|
| > margin: 0 auto;
|
| would be the way to go for centering divs...
| lelandfe wrote:
| https://jsfiddle.net/c7gt4or2/2/
|
| No luck for elements of unspecified widths, or for inline
| elements.
| DaiPlusPlus wrote:
| > now we are down to "place-self: center;"
|
| `place-self` still requires the parent to be a flex-box
| container, though. You can't just apply it to an arbitrary
| element to make it center in its parent.
|
| `place-self` is just shorthand for setting both `align-self`
| and `justify-self` in a single proeprty - I don't see how this
| is necessarily an improvement: CSS is already (unfortunately,
| necessarily) confusing at it is, so adding a literally
| redundant CSS property with a distinct name is not going to
| reduce confusion nor make CSS any more accessible.
|
| CSS's shorthand properties work best when the shorthand version
| actually aids comprehension, rather than making you think: for
| example, `border: <width> <style> <color>;` and `margin: <top>
| <right> <bottom> <left>;` are great examples of how they should
| be: either because each parameter is unambiguously typed (in
| `border`'s case: widths, border-style and colors are very
| distinct) or uniformly-typed but follow a familiar pattern
| (e.g. `margin:`'s parameters are all length-values but are in a
| clockwise sequence) - this is not something we see in some of
| the more modern shorthand properties like `flex` and `box-
| shadow` where you need to have pre-memorized which parameter
| corresponds to each longhand property, e.g. it's non-obvious
| that the `2` in `flex: 1 2 3px` is for `flex-grow` - or that
| the `3px` in `box-shadow: 1px 2px 3px 4px rgba(0,0,0,0.2);` is
| for `blur-radius` and not `spread-radius`.
|
| > It's good to see that the problem of anchoring tooltips is
| progressing through this process!
|
| I'm also strongly in favour of this CSS feature, it's a long-
| time coming - BUUUUT I also really would have liked some
| browser-native tooltip/title feature that allows for rich-
| content without resorting to hacks like `foo[title]::after {
| position: absolute; content: attr(title); etc }`
| fwlr wrote:
| I completely agree with your take on what makes for a good
| shorthand property, I would also have pointed to border: as a
| good shorthand and flex: as a bad shorthand. I think place-
| self: is a good shorthand, though - the fact that it's a
| redundant way to specify two separate properties in a single
| line is good in this specific case because it matches the
| developer's mental model of "center this div please" being a
| single and simple request. Yes, the truth of layout is that
| centering stuff is not actually simple and does not involve
| one single operation, and so we have had to build complex
| layout systems to handle all the edge cases and complexities,
| but now that we've built those systems it makes sense to
| offer a shorthand for this common request that resolves to
| the set of commands required to achieve the result. (e.g. I
| think ES6's for-of iteration construct is a good idea,
| despite redundancy/confusion with the existing C-style
| for-i++ iteration construct.)
| javajosh wrote:
| Parent element "modes" that affect child layout and
| "enable/disable" child available properties is what makes CSS
| tricky. To do CSS well you end up having to learn all the
| modes and all the properties, which makes CSS a defensible
| professional specialization, but its less good for drive-by
| designers who just want simplicity. (My personal favorite
| remains the good old "absolute layout".)
|
| (Aside: another technology in the thankfully small _know
| everything before you can do anything_ set is gradle, a
| popular build tool in the Java universe. These tools are
| capable, but quite demanding of the user. Git may also
| qualify.)
| DaiPlusPlus wrote:
| Right.
|
| Prior to CSS, it used to be that literally anyone could
| (and should!) write HTML: web-pages were just simple
| documents (by design) using only paragraph-flow content
| with inline objects (like images, Java applets, ActiveX on
| Windows), and appearance was directly set inline with
| <font>, <small>, etc. This is fine for web-page _documents_
| , but not web-page _applications_ , and it turns out that
| defining a layout system for a medium as flexible as a web-
| browser viewport is very, very hard.
|
| It's the same thing with desktop software: previously it
| was perfectly acceptable for a VB6 application to consist
| entirely of fixed-size windows with controls placed at
| fixed-positions, with no resize logic - or to handle re-
| flow when the text changes, or high-DPI for that matters.
| Users, today, have much higher expectations, and now it's
| now basically impossible for a "citizen programmer" to meet
| the expectations of normal users, and I feel this is a bad
| trend for everyone: we all love to grimmace at a giant
| Excel VBA macro doing 20 things at once that still somehow
| works, but the person or company that actually has that
| macro really is better-off than someone without it.
|
| -------
|
| The complex layout systems in modern UI frameworks (like
| WPF/XAML, Cocoa Touch, etc) are converging with CSS (or
| vice-versa, depending on your experience) in their
| expressiveness - which necessitates complete abstraction-
| away from fixed-layout WYSIWYG systems that were _the key
| component_ of the democratization of desktop computers
| since the late-1980s, and while HTML was never WYSIWYG an
| average person could still immediately understand what `
| <font color="">` did - and could immediately see how their
| fixed-layout VBA Form would look when it runs.
|
| Unfortunately I don't have a solution to this problem:
| citizen-programmers are going to _need_ a WYSIWYG fixed-
| layout design tool, but such a tool is fundamentally
| incompatible with end-user expectations - and essential
| things like accessibility and device-portability. I guess
| we 'll be stuck with proprietary, half-arsed, "low-
| code"/"no-code" tools for a long while.
| 6510 wrote:
| Even longer ago, with fixed width fonts and fixed size
| screens things were even better. On C64 the keyboard had
| --- ||| characters to draw line with corner characters T
| splits and + . The empty space was filled with space
| characters so you could just move around your cursor.
| Someone with no previous experience could draw boxes and
| make cool looking menus. Could stick a few sprites on it
| with absolute positioning.
|
| Supporting all kinds of screen sizes is a dumb idea but
| we are stuck with it. If you also want to support
| different languages the screen is mostly empty with
| logograms and the languageswithgiantwords stick out of
| the boxes. We are pretty lucky English is a reasonable
| middle ground.
| nailer wrote:
| > You can't just apply it to an arbitrary element to make it
| center in its parent.
|
| You can with grid-first.
|
| With the proviso that third party components may not work
| (which is fine, third party components are usually very low
| quality). I'd recommend, right after your existing:
| *, *:before, *:after { box-sizing:
| border-box; }
|
| Adding: div { display: grid; }
|
| You can now remove:
|
| - all margins (there's just padding and gap now)
|
| - margin auto centering hacks
|
| - clearfix hacks
|
| - translateY -50% hacks
|
| - a billion wrappers around every UI element (per all those
| low quality third party components, particularly common in
| the react space which seems to have a culture of "add divs
| until it looks right")
|
| plus a bunch of other code.
|
| In 99% of cases, using grid-first, there will be a 1:1 match
| of element to UI - getting around the div-soup of older web
| apps.
|
| The app I'm developing now is 1:1 with the exception of
| rounded gradient borders, which still needs a hack.
| DaiPlusPlus wrote:
| > ...your existing
|
| I don't use CSS Reset techniques: don't try to fight the
| browser.
|
| > div { display: grid; }
|
| I'm concerned this will have a nontrivial impact on browser
| layout performance. Existing browser layout engines are
| heavily optimized for flow/block layout, but defaulting
| every div to grid breaks that major assumption all the
| browser-makers made and... for what gain? I actually _don
| 't want_ every div to potentially be a grid layout
| container by default.
|
| > You can now remove $things:
|
| I don't use any of those tricks/hacks anyway - and clearfix
| hasn't been relevant since IE8 came out.
|
| > rounded gradient borders
|
| Just use border-radius combined with `border-image: some-
| gradient-function()`. No hacks or tricks required.
| frosted-flakes wrote:
| > I'm concerned this will have a nontrivial impact on
| browser layout performance.
|
| I've experienced this with iOS Safari. I was
| experimenting with different layout methods, and at one
| point a display:grid didn't get deleted, and some days
| later when I was testing with Safari it was taking at
| least half a second to render a page. I'm talking 5
| paragraphs of text, possibly with subgrid I was
| experimenting with, nothing crazy. I had no idea CSS
| could ever get that so slow and I thought it _had_ to be
| something with React, and it took way longer than it
| should have to narrow it down to that single property.
| lelandfe wrote:
| > I'm concerned this will have a nontrivial impact on
| browser layout performance. Existing browser layout
| engines are heavily optimized for flow/block layout
|
| Layout and paint performance is pretty low stakes. Unless
| you're doing a lot of painting, or your demographic is
| surprising, your users are going to be fine.
| 867-5309 wrote:
| >some-gradient-function()
|
| >which still needs a hack
| nailer wrote:
| I've been doing grid-first for a few years now (last
| major update was when buttons hot grid support) across
| apps including high performance google docs-type collab
| interfaces. It's fine.
|
| Optimising for existing behavior reminds me of when
| people didn't want to use async/await as V8 'wasn't
| optimised' for it. await never felt slow in their apps
| anyway, but now it's similar fast to what callbacks were.
| Skate to where the puck going to be.
|
| > for what gain? I don't use any of those tricks/hacks
| anyway
|
| OK. Everyone else does but maybe you're the exception.
|
| > For rounded gradient borders... just use border-radius
| combined with `border-image: some-gradient-function()`.
| No hacks or tricks required.
|
| Are you sure?
| https://stackoverflow.com/questions/51496204/border-
| gradient... - judging by the views on that question, if
| you have a codepen there's at least 42,000 people who'd
| love to see, it my understanding is that the W3C spec
| says it shouldn't work.
|
| Probably obvious, you sound like you know what you're
| doing but: adding additional elements, pseudoelements etc
| counts as hacks.
|
| Here's border-radius combined with `border-image: some-
| gradient-function()`:
|
| https://codepen.io/mikemaccana/pen/QWVpdmo
| xnx wrote:
| 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.
| eurasiantiger wrote:
| <center> is effectively <div style="text-
| align: center;"> <span>centered element</span>
| </div>
| c-smile wrote:
| Not so easy, at least: <span
| style="display:inline-block">centered element</span>
|
| But in general <center> still cannot be 100% expressed by
| CSS means.
| fwlr wrote:
| I also used to be annoyed by how long it took to get "basic
| useful functionality" for some use case in CSS. Over the
| years I have mellowed as I recognized it simply takes a long
| time to converge on what functionality is actually desired,
| and then what systems need to be in place so you can request
| that functionality in the most obvious location in your code
| (e.g. it turns out we really want to put the request for
| centering on the element to be centered, not the parent)
| along with figuring out the truly minimal, truly necessary
| information to carry out that functionality -- and then
| further still to implement those needed systems in all major
| browsers. It's just a long and incremental process by its
| nature and we probably can't do much better than that.
| Ironically, the fact that the state of the art changes every
| few years is evidence that this process, though slow, does
| work reliably well.
| graderjs wrote:
| It's sort of like Storyboard layout constraints in MacOS app
| development?
| xrd wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| micromacrofoot wrote:
| That seems like a good guess. I'd also guess that there
| are a lot more internal politics involved when they're
| implementing OS-integrated features that are easy to
| abuse. There are a lot of sites that ask for notification
| permission that definitely don't need to, and that
| probably saps some of the motivation for implementation
| at Apple. It's frustrating for developers with completely
| valid use cases, frustrating for open web standards, but
| I can understand being overprotective of user experience.
| It's a difficult balance.
| ajkjk wrote:
| Generally stopping reading over a small complaint is, yeah,
| pretty petty.
| tgv wrote:
| You're completely right. It's a kludge for attaching elements
| in a page structure that wasn't designed for it, and of course
| it's Chrome only.
| megaman821 wrote:
| I mostly do web development. Is there a UI framework that
| really nails this pop over and alignment problem that you
| have in mind?
| ErikHuisman wrote:
| https://tetherjs.dev
| jefftk wrote:
| _> I 'll file this under something interesting to revisit in a
| year or two._
|
| That's fine to do if you're only interested in "is this a thing
| I can use now" (no, not yet). But if you care about how the
| feature is designed and are worried that they might get it
| wrong, now is the time to read the proposal and speak up!
| akersten wrote:
| 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 wrote:
| 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 wrote:
| Tether?
| caseyf wrote:
| 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
| c-smile wrote:
| 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
|
| 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
| wildrhythms wrote:
| 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.
| sugeng020881 wrote:
| bp77
___________________________________________________________________
(page generated 2023-03-01 23:01 UTC)