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.
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 ;)
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.
> 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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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?
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.