[HN Gopher] Flow Charts with CSS Anchor Positioning
___________________________________________________________________
Flow Charts with CSS Anchor Positioning
Author : roosgit
Score : 146 points
Date : 2024-06-27 07:07 UTC (15 hours ago)
(HTM) web link (coryrylan.com)
(TXT) w3m dump (coryrylan.com)
| xnx wrote:
| We might have pushed CSS further than it should go, but using
| gradient for the connector lines is pretty clever.
| lukan wrote:
| It is pretty nice, but my thirst thoughts were also, how this
| will make new browser engines more hard to make.
| zarzavat wrote:
| We passed that threshold in 2019 when Microsoft gave up
| trying to make a browser engine because it was too difficult.
| clan wrote:
| Yet, Ladybird.dev is happening.
| worldsayshi wrote:
| Or they don't know what they gain from maintaining their
| own.
| lukan wrote:
| 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.
| robertlagrant wrote:
| 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.
| allendoerfer wrote:
| > 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
| robertlagrant wrote:
| Where's the bit with connectors, though?
| the_other wrote:
| 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.
| llama_drama wrote:
| 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.
| Izkata wrote:
| "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.
| bugfactory wrote:
| 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 ;)
| autoexec wrote:
| > 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!
| persnickety wrote:
| 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.
| _nalply wrote:
| 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.
| eyelidlessness wrote:
| 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.
| persnickety wrote:
| One way around it is to do what the Tor Browser does:
| report an arbitrary value.
| bugfactory wrote:
| 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.
| cantSpellSober wrote:
| 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.
| ramesh31 wrote:
| >"Only CSS"
|
| CSS is by _far_ the most advanced, flexible, and powerful
| layout technology in existence.
| azangru wrote:
| I am not seeing it used much in print though.
| brobdingnag_pp wrote:
| That's because print is an additive medium and requires
| support for additive colorspaces (CMYK) and device color
| profiles.
| california-og wrote:
| 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
| rikroots wrote:
| It's in the CSS Color 5 spec - here:
| https://drafts.csswg.org/css-color-5/#cal-cmyk
| Kiro wrote:
| I don't understand how this is still a thing in 2024.
| dwallin wrote:
| 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.
| bob1029 wrote:
| 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.
| sollniss wrote:
| Connector lines not showing in Firefox.
| wellyeahkinda wrote:
| 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
| azangru wrote:
| > 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
| panzerboiler wrote:
| > 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.
| azangru wrote:
| Even as a suggestion that this is hardly pushed as a
| Chrome feature?
| riquito wrote:
| 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.
| robin_reala wrote:
| Nothing but Chromiums support this, but it should be happening
| in the not too distant future: https://caniuse.com/css-anchor-
| positioning
| _nalply wrote:
| 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...
| autoexec wrote:
| 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.
| lenkite wrote:
| 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.
| iddan wrote:
| See:
| https://web.archive.org/web/20140901100550/https://developer...
| 6510 wrote:
| Just have a flow chart html element?
| dgb23 wrote:
| I don't quite understand your comment. You can embed SVG in
| HTML and vice versa and you can use CSS on it.
| the_other wrote:
| 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.
| lukan wrote:
| 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).
| livrem wrote:
| 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/
| mock-possum wrote:
| That's an interesting point - how accessible is JSON to
| differently abled users?
| lukan wrote:
| 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.
| staminade wrote:
| 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.
| dgb23 wrote:
| 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.
| Veuxdo wrote:
| > 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.
| arcbyte wrote:
| He just laid out the rule. It's a bad idea for very good
| reasons.
| Veuxdo wrote:
| 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.
| the_other wrote:
| 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.
| woopsn wrote:
| 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)
| fkyoureadthedoc wrote:
| 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.
| the_other wrote:
| 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.
| ericyd wrote:
| Friendly warning that anchor positioning is not yet available in
| any non-Chromium-derived browser.
| meindnoch wrote:
| Great. Yet another special case added to CSS.
| gavinbao wrote:
| 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?
| simple10 wrote:
| 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
| dgb23 wrote:
| 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.
| AstroJetson wrote:
| I just use Markdeep and create the block diagrams that way
|
| https://casual-effects.com/markdeep/features.md.html#diagram...
___________________________________________________________________
(page generated 2024-06-27 23:01 UTC)