Flow Charts with CSS Anchor Positioning | Hacker News Reader

Flow Charts with CSS Anchor Positioning

coryrylan.com

163 pointsroosgit66 comments

Neat examples!

However I think I would still use SVG for these sorts of things, especially since they can easily be manipulated, animated and are more mathematically declarative than CSS anchor positioning.

I think the sweet spot for this CSS feature is not having to do complex workarounds with calc, positioning, transforms or JS in order to have more control over positioning elements relative to others. Container queries have a similar use case.

Both of these features (as well as CSS grid) are born out of the same underlying issues:

- HTML and CSS are not orthogonal in terms of layout, but very tightly coupled

- Trees are a fundamentally crippled data structure to express layouts. Almost every sufficiently complex layout wants to be represented as a graph or a matrix. Trees are fine until they aren't.

Your last sentence is very interesting to me. Can you explain what you mean? Or suggest something to read?

I'm constantly amazed by how much can be achieved with only CSS nowadays. It seems like it's getting more powerful by the month as developers find new and tricky ways to push the boundary ;)

> I'm constantly amazed by how much can be achieved with only CSS nowadays.

Honestly it's a bit too much. CSS is used for fingerprinting and exploits. It's become a security risk to have it enabled and I think before long we'll want CSS blockers the same way we have blockers for JS. The ability to allow only sane subset of CSS would be really useful!

I've been longing for the ability to disable media queries. Just serve me the default.

It's not only useful against fingerprinting, but also when the creator's idea of what layout is appropriate on my setup differs from mine.

Did not try it out, but an idea: write a user script that changes the <meta viewport>.

See https://developer.mozilla.org/en-US/docs/Web/HTML/Viewport_m... what this meta tag does.

You might be pretty disappointed by the defaults in many cases: it’s extremely common to start with styles for the smallest viewports (“mobile”) and use media queries to add larger viewport variants. I don’t know if you’re among the same people who complain about the overuse of mobile UI techniques on larger screens/devices, but that’s almost certainly what you’d get more of in general.

One way around it is to do what the Tor Browser does: report an arbitrary value.

Modern responsive design can do away with almost 100% of media queries. I used one single media query for one element after spending several days trying to write formulas to handle a weird edge case. I dislike media queries.

That's a good point. At the same time, I believe it can make a lot of sense, particularly if it is used to implement functionality that was previously implemented in JavaScript.

Given that CSS is not an actual programming language, browser vendors can optimize it in ways that JavaScript can't. This extra optimization is a big benefit in the world of mobile devices and batteries.

Frontend devs in 2000: "Why can't we do grid layouts?!"

In 2020: "Grid is too much!" :)

Anchors in general are great, and they can be abused. Just like how we abused `transform` to vertically center things before flexbox.

>"Only CSS"

CSS is by far the most advanced, flexible, and powerful layout technology in existence.

I am not seeing it used much in print though.

That’s because print is an additive medium and requires support for additive colorspaces (CMYK) and device color profiles.

This is probably coming to CSS in the coming years. [0] Which makes me very excited for one reason: CSS is nearing feature parity (and surpassing it in some areas) with Adobe InDesign, so we can finally ditch adobe and just make print publications within the browser. The only other thing missing after custom colour profiles is a proper text justification algorithm, although, for many, it's not so important because people are already used to reading ragged text.

[0]: https://www.w3.org/TR/css-color-4/#color-space

It's in the CSS Color 5 spec - here: https://drafts.csswg.org/css-color-5/#cal-cmyk

I don't understand how this is still a thing in 2024.

It’s essential complexity, so it’s not going anywhere.

I would maybe say that it is almost assuredly one of the most featureful and widely used layout technology. But I'm not convinced it's the most powerful, flexible, or even advanced. It suffers from significant performance issues due to legacy baggage and a poor underlying abstractions. There is a reason anyone building things like visual editors, spreadsheets, et al tend to drop into lower level rendering technologies.

Flexbox & grid took a lot of wind out of the sails of the various frameworks.

The #1 (by a long shot) reason I used to reach for things like Bootstrap was to get my divs in the right spots on the viewport. Now, I can specify sophisticated 2d layouts based upon media queries that consider a combination of viewport dimensions and other device capabilities. Not a single line of javascript is required to do this.

Yep, I had a huge library of SASS (SCSS) mixins that I’d use to accomplish a lot back in the day. ThoughtBot had (has?) a library called Bourbon that came with a bunch and they were amazing.

Friendly warning that anchor positioning is not yet available in any non-Chromium-derived browser.

We might have pushed CSS further than it should go, but using gradient for the connector lines is pretty clever.

It is pretty nice, but my thirst thoughts were also, how this will make new browser engines more hard to make.

We passed that threshold in 2019 when Microsoft gave up trying to make a browser engine because it was too difficult.

Yet, Ladybird.dev is happening.

Or they don't know what they gain from maintaining their own.

Well, they had a dominating browser for many years, so they know the benefit. Apparently they decided it is cheaper to just focus on the "user experience".

Now they can still control what buttons there are and whatbis shown on the home screen by default, but do not have to bother so much with all the expensive technical details.

Yeah - very smart.

I suppose the lines won't be interactive (e.g. "double click on this line to add a text label") because the line isn't there in any sense Javascript would be aware of. Unless Javascript computes the same gradient, which is then a pointless duplication. But it's very clever.

Makes me wonder if there's a missing format out there that should be built into browsers that describes shapes and connections.

> Makes me wonder if there's a missing format out there that should be built into browsers that describes shapes and connections.

https://developer.mozilla.org/en-US/docs/Web/SVG

Where's the bit with connectors, though?

I think it's "cute" but a hack that abuses the spirit of what HTML and CSS are for, and what they do well. It's inaccessible and lossy.

I don't think we pushed CSS too far; the complexity of CSS is inherently tied to the complexity of the UI requirements. Even now CSS can't handle everything.

"The Shapes of CSS" was 6 years ago: https://css-tricks.com/the-shapes-of-css/

I remember various triangles using "border" and 0 width/height being pretty common even in the decade before that.

Ideally, browsers should offer an API where a certain rect on screen can be rendered as SVG or PNG. Then such CSS flowcharts can be distributed as independent images instead of being a web-page.

See: https://web.archive.org/web/20140901100550/https://developer...

Just have a flow chart html element?

I don't quite understand your comment. You can embed SVG in HTML and vice versa and you can use CSS on it.

Thanks for sharing. This has a lot of promise once browsers fully support anchor positioning. With the current rate of CSS standards adoption, my guess is Firefox and Safari will add support by end of this year. Pure speculation as they haven't announce support plans yet AFAIK.

Chrome and Edge currently support anchor positioning: https://caniuse.com/?search=css-anchor-positioning

Considering this is a CSS trick, it'd be nice if all the demos didn't require/load a ton of JS. Viewing source on the demos shows them to be like 90% javascript, several tens of thousands of characters, and that doesn't even include the five external JS files it also loads.

Connector lines not showing in Firefox.

I mean, the article starts by explaining the fact CSS anchors was pushed as a chrome feature. Only browsers that inherit from it by default will have this.

https://developer.mozilla.org/en-US/docs/Web/CSS/anchor

> was pushed as a chrome feature

Or has it perhaps been accepted as a specification, but Blink-based browsers implemented it first?

https://www.w3.org/TR/css-anchor-position-1

> This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Even as a suggestion that this is hardly pushed as a Chrome feature?

The article doesn't mention that it's not supported by other browsers. The two things (pushed by chrome / unsupported by others) are not consequential.

If you don't clearly state it and people start using the shiny new thing you're hindering the few alternative browsers out there.

Nothing but Chromiums support this, but it should be happening in the not too distant future: https://caniuse.com/css-anchor-positioning

Safari also has not yet implemented it and they want to wait for it to become stable then implement it.

https://github.com/WebKit/standards-positions/issues/167#iss...

I just use Markdeep and create the block diagrams that way

https://casual-effects.com/markdeep/features.md.html#diagram...

div popover in css … yay

Great. Yet another special case added to CSS.

Flow charts are a terrible use case for CSS (and HTML). The nodes and edges of a flow chart are all meaningful data. When you render the connectors using a mixture of empty divs, pseudo-content and largely arbitrary hacks, all that meaning gets lost from the _content_ (the HTML). Access tooling will largely fail to communicate your intent.

Flow charts are much better represented by something like PlantUML or Mermaid, and then rendered direct to SVG or a canvas. The mark-up is much more human-readable and could be used as source to drive an even-more accessible alternative.

I think it is possible to use this as just the renderer and have your actual data of the nodes in a clean state elsewhere (as JSON for example).

Could have it as an output format for something like Pikchr, but not sure what the advantage would be over just generating a SVG?

https://pikchr.org/

That’s an interesting point - how accessible is JSON to differently abled users?

Was that a serious question?

If so, JSON is just a raw data object. I suppose one could read it with a screen reader, but whether that makes sense depends how the data is structured. But it would not be a great experience.

Why not represent them as PlantUML or Mermaid and render to HTML/CSS? That way you get far superior layout capabilities, particularly for text, than SVG or canvas provide you.

You can embed HTML in SVG, vice versa and use CSS on both.

In fact one little trick if you are doing a complex animated layout with SVG is to nest HTML elements with it that you animate it via CSS transitions or keyframes, which are much more optimized than SVG animations in browsers.

> When you render the connectors using a mixture of empty divs, pseudo-content and largely arbitrary hacks, all that meaning gets lost from the _content_ (the HTML)

Well, yeah. But you can commit the same sins in SVG and canvas. There's certainly no rule that HTML can't be used to make effective, meaningful diagrams.

He just laid out the rule. It's a bad idea for very good reasons.

Re-reading it, he did limit his rule to not using HTML for _connectors_. I can't refute that; that sounds like a bad idea for anything that isn't a toy POC (which this submission certainly is).

I do think a mix of HTML (for boxes) and canvas/svg (for connectors) is viable, however.

If you can mark up where the connectors go in a way that makes them accessible, you have some chance of making this work.

I think it would require extensions to HTML. There are already mechanisms for linking some elements to others, but most of them have pre-defined semantics (labels for controls, headers for sections and widgets). The closest is probably the `form` attribute that links form controls to a non-nesting `<form >` "parent" element... but forms are a worse hack for a flow chart than CSS connectors.

I tried a few techniques, in terms of accessibility I think "old" ways are the best here.

    <div class=flowchart>... crazy modern shit ...</div>

    <ol class=sr-only>
      <li id=step1> Water on stove.
        <ol>
          <li>Boiling? Proceed to <a href=#step2>Step 2</a></li>
          <li>Otherwise return to <a href=#step1>Step 1</a></li>
        </ol>
      </li>

      <li id=step2> Cook dumplings in water. Wait a minute.
        Floating? Proceed to <a href=#step4>Step 4</a>.</li>
        Otherwise proceed to <a href=#step3>Step 3</a>.</li>
      </li>

      <li id=step3> Stir dumplings. Return to <a href=#step2>Step 2</a>.</li>

      ...
   </ol>

(or start with the anchors/list, and progressively enhance)

It's just a cool CSS demo. I don't know why contrarian comments with little actual substance and mostly baseless speculation are so well accepted here.

> The mark-up is much more human-readable and could be used as source to drive an even-more accessible alternative.

Any examples of this _actually happening_, does the tooling exist?

Well rather than just saying that I'll actually check. Looking at Mermaid, the only thing I can find with regard to accessibility is what Mermaid does by default. No other first or third party tooling.

I just tested that with VoiceOver on their accessibility documentation page, and it does not work well on the page. I can get labels but not the title/description. Pulled some of the charts to their own page, and you get title / description of the chart (if the person who did the mermaid markup decided to add the special accessibility fields), then you can arrow through some of the text internals of the chart, but you get no semantic information.

Quite easily replicable in OPs solution if you're so inclined, and you could even take it further, although it would be a lot of manual effort.

Sorry… I didn’t mean to imply that PlantUML or Mermaid had any accessibikity support out of the box. I’ve not tested it and wouldn’t expect it to do that.

My point was more that the raw Marmaid “code” is more likely to communicate the content of a flow chart to some users with certain access needs than a diagram made of divs. In the same way that raw HTML, or HTML rendered with no stylesheet is (should be) more accessible than a document with accordions and carousels.

I accept there probably isn’t tooling to turn Mermaid into a more accessible diagram yet. But there could be. If instead you transmit the diagram as HTML with CSS hacks, you’re losing all the semantic data through the informality of the solution.

I left my contrarian comment because fancy demos have a habit of turning into justification for further “clever” but flawed work. A naive user might see the flow chart example as “good” andnpropose they use the hack in their own project. The solution prevents certain groups of people from accessing the data.

Saying it another way: hacks shouldn’t be used to endorse a new technology.

Is it possible that it can create a flow chart library with pure css? maybe like we make the className like tailwind to let others use to easily ship flow chat with pure css?

Reply on news.ycombinator.com