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.
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.
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!
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.
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.
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.
CSS is by far the most advanced, flexible, and powerful layout technology in existence.
I remember various triangles using "border" and 0 width/height being pretty common even in the decade before that.
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.
Chrome and Edge currently support anchor positioning: https://caniuse.com/?search=css-anchor-positioning
https://github.com/WebKit/standards-positions/issues/167#iss...
If you don't clearly state it and people start using the shiny new thing you're hindering the few alternative browsers out there.
Or has it perhaps been accepted as a specification, but Blink-based browsers implemented it first?
https://casual-effects.com/markdeep/features.md.html#diagram...
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.
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.
> 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.
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.
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.
