Unfortunately, almost all of them are terrible for accessibility. Most of them cannot be focussed by keyboard. And even more do not have a focus styling. I did not check their code, but that alone does not make a good impression.
Tailwind UI's checkboxes (https://tailwindui.com/components/application-ui/forms/check...) are fine, accessibility-wise. They can be tabbed to using the keyboard, they are proper <input type="checkbox"> elements in the DOM, they can be activated using the space key, they can be activated by clicking on their label.
It's kinda dangerous for the webpage to include the checkbox code to be copied as this. It's commercial product and from seeing tailwind public relations they are super stingy about it.
Javascript is actually great for accessibility, it’s really hard to properly implement WAI-ARIA without it. Most people with screen readers will have js enabled too.
Tailwind is one of the vanishingly few css frameworks/css utility collections/css design systems that is really, really good about keeping semantic meaning of things and accessibilty intact, and whose examples show how to implement them correctly.
Almost everyone else is "screw this, we're going to use links as buttons and divs as lists".
This seems more like a gallery of art/starting point than a "use this as-is", so I'm sad to see this comment on the top of HN since as a show of what can be accomplished with checkboxes it's amazing.
We front-end devs would benefit from a lot more works of art like this, and then people trying to implement them into real systems would need to make them accessible. Similar to how we benefit greatly from Dribbble. If we don't allow for unrestricted just artistic bits like this, then creativity suffers.
Counterargument to myself: the click to copy though makes it seem like it's ready to use, and many newer devs would just use them straight away. It's on the hands of more senior devs to tell them that these snippets, similarly to many StackOverflow ones, need to be adapted to integrate in an actual app for things like accessibility, uniformity, etc.
I am so sad anyone can look at this amazing resource and with a straight face say that only 10% of it is valid as an inspiration. It's a magnificent source of inspiration! Sure some are not perfect, but that doesn't detract from the overall goal.
Naming element types by their style or form (box) rather than features in an implementation that encourages separating style leads to a more general problem.
Incidentally most of them _are_ focusable by the keyboard but just aren't tabbable.
I'm using a Chrome plugin Vimium - one of the shortcuts 'f' (documented as opening links) actually highlights all focusable elements. Using this feature shows most of the checkboxes are interactive.
Edit: I guess the reason for me pointing this out is hopefully there's an easy way to make these more accessible for keyboard users.
Very interesting! I had a look at your "RFC 001: Core Architecture" but one question remains. You mentioned "git as the backend". As far as I understand, you don't use the word "backend" in the classic frontend <=> backend sense. Instead, you mean that Git is being used as a software repository and as a content database. Is that correct or am I missing something?
I'm already sold on the idea of using Git as a database for content and localization. But I'm obviously biased as we are working on a similar solutation ;) It is called FrontAid and it is a CMS that stores your (localized) content in a JSON file within your own repo. More information can be found at https://frontaid.io/
Using Git for content has some great benefits. Like complete version history, easy reverts (for devs at least), (feature) branch support, Git hooks, ... And of course, you own your content at all times.
PS: Both the "Editor" and "VS-Code-Extension" links in your repo are broken.
Correct, the term git backend refers to git as a content database (with built-in version control and automation).
Regarding front aid, great to see fellow startups working on solution built on git. It took months to realize the benefits of git and the logical step to build the backend on git. sorry, use git as the content database.
If you are considering switching to a (different) date library, I would suggest to hold off. ECMAScript is about to introduce a native date and time API that is much better than the current Date functionality. It may also make the need for a third-party date library obsolete (as long as you do not need to parse custom date formats).
As far as I know, issue #1450 is the last remaining blocker for the standardization. I'd assume that this will be resolved in the next months. So Temporal will likely be officially released with ECMAScript 2023, but browser vendors and other implementors will start shipping it before the offical release.
Welllll… “works right now” is perhaps an overly strong assertion when it comes to day.js. I was working on a library we use for parsing "schedules" (like, alarm turns on at 9:00pm on Thursday, and off again at 7:00am on Friday). I was doing things like computing the number of seconds until the next scheduled transition. I tried switching from moment to day.js, and my unit tests immediately failed. Within a couple of hours I’d opened two bugs [1][2], both related to incorrect behaviour in corner cases (like generating the incorrect date when near a daylight saving time transition).
The fact that it only took me a few hours to find these suggests there are plenty more bugs like these to find. The fact that these bugs have been open since the start of March with no movement on them suggests they aren’t too interested in correct behaviour (or perhaps they’re just your typical under-staffed open source project).
Maybe I just got super unlucky and ran into the only two bugs here… but it’s not likely.
Luxon and moment.js both handled these cases perfectly. If you’re looking to move from whatever you’re using now, and you can’t wait for the new standard, I’d pick one of those.
They mentioned "switching" which implies an already working solution. Within that context, yeah, maybe wait a few months if you can afford to.
Also, once the spec is finalized, there may also be a compliant polyfill available. If so, you'll get the functionality early and still have good compatibility down the line.
If you have something working, perhaps delay refactoring to a new library.
Or as it is coming RealSoonNow(tm) perhaps start looking into polyfills as you are going to need one anyway for a story time at least to support LTS browser versions.
you don't need to hold off - you just wrap the library in an api of your own, specific for your usage. Then, when/if the ecmascript standard library adds a good one in, you just need to re-implement the wrapper, which would be presumably pretty easy as the api surface area is fairly small.
If I were helping someone start a web project _right now_ I'd probably tell them to just use Moment.js and forget about it. Any live web product I've ever worked on has always had more than enough to work on to keep updating the date-time library at the bottom of the to-do list almost indefinitely.
I was tangentially involved in the back-end data part of a web project in the last few weeks.
Right from the beginning, I told anyone who would listen that the underlying data was in UTC. So far, so good.
They get to T-24h for the client's Big Demo Day...
...and someone in London, UK notices the front end UI times are all an hour out (that would be because the UK is still on summer time, UTC+1). I happened to be in Germany and after finally being given a login for the UI found that, wonder of wonders, the timings were two hours out!
<groan>
So we had to bodge the API to fiddle the times forward to UTC+1 for the purposes of the damned demo.
Someone is presumably going to find this in the repo waaaay in the future and ask themselves "wtf were they thinking?". I wish I knew the answer.
I wouldn't recommend anyone use moment.js if they're starting a new project. It's an unnecessarily large library, and the fact that moment objects are mutable almost always causes more issues than it solves. The only reason to use it is if you're working on software that is already using it. Otherwise use a more modern, immutable datetime library like day.js, date-fns, or luxon.
Having read the cookbook [1], and wow that's a complex API out there. I can see that there will be a `Temporal Light` to allow us to do `now().startOf('month')` like calls.
Moment.js was one of our biggest dependencies, and the transition to Day.js was easy. I'm certainly glad we didn't hold off. I'm sure we'll switch to Temporal eventually, but it's misguided to suggest everyone should wait a year or more to improve their sites just to save a little effort in the interim.
One has also got to hope that Temporal offers all the features a well built daytime library does offer. What good is it if Temporal is lacking that one feature you need, so that you end up including another library as well.
By then you can assume that the other library will be a lightweight wrapper around Temporal.
Even if you're not using modules, using an IIFE avoids all this by making your variables local instead of having them define/update properties on the global.
I think this does not work well for mobile devices. Spacing and the font size is too large. Hence, a lot of screen space is wasted and the user has to scroll more. Larger font sizes on mobile are usually not a good idea as the device tends to be closer to your eyes anyway.
A snippet that could work better in my opinion is the following:
html {
max-width: 70ch;
/* larger spacing on larger screens, very small spacing on tiny screens */
padding: calc(1vmin + .5rem);
/* shorthand for margin-left/margin-right */
margin-inline: auto;
/* fluid sizing: https://frontaid.io/blog/fluid-typography-2d-css-locks-clamp/ */
font-size: clamp(1em, 0.909em + 0.45vmin, 1.25em);
/* use system font stack: https://developer.mozilla.org/en-US/docs/Web/CSS/font-family */
font-family: system-ui
}
/* increase line-height for everything except headings */
body :not(:is(h1,h2,h3,h4,h5,h6)) {
line-height: 1.75;
}
I wonder if everyone has a different optimum here based on different eyesight, screen size, and usage patterns. I always have a slightly different zoom on every website I visit.
With this one I tend to agree, I can't see enough text at once and the margins seem a bit wide.
Yeah, the zoom, that almost needs to be customized per website, sigh. But one of the worst misfeatures for old (and maybe not so old) eyes, is the gray text on some "pastel" background. Contrast helps readability (as does a carefully chosen font), but "modern" designers seem to think contrast is bad or outdated or whatever.
I have a state of the art Macbook too, and a good monitor, but I still find light grey text hard to read. Because I have old eyes with suboptimal eyesight.
Anyway, it would be reasonable if designers tested their designs with other people on other hardware, instead of thinking "looks fine for me" … at least that's what I learned about design, user interfaces, etc ;-0
> I wonder if everyone has a different optimum here based on different eyesight, screen size, and usage patterns. I always have a slightly different zoom on every website I visit.
I would think so. And because of that, accessibility is an essential topic. Luckily, this snippet will automatically follow your zoom level and/or font size settings.
But it would be better still if browsers offered an opt-in modern default style, to relieve us developers of having to make assumptions about the user's visual needs, which should be the domain of the user agent.
Firefox had that for a long time, hidden in a menu, but discoverable eventually. It also used to have a menu for Alternate Styles when a webpage included named LINKs to alternate styles (allowing pages to have a heavy, preferred default but offer the user other options, without needing to add a "theme picker" in the HTML somewhere).
Outside of dedicated "Reader Views" it seems like we've given up on the idea that might be something the browser should do. (Which, I appreciate the "Reader View" as an easier to discover way to do this, even if I think moving it into a "modal" with its own liminal space continues the narrative of the browser moving away from being a "user agent" to being an "application runtime".)
Content on the web used to flow pretty well irrespective of those factors. The 'liquid' layout in Adobe's pdf reader works as it should, as does the simplified view in Chrome (which is suspiciously only offered on sites without ads). So, I'm optimistic that simplified layouts are worth pursuing.
Designers want the latitude to place ads where they're likely to be effective. How does an ads company which incidentally also provides a browser balance that interest?
> Will people (and you?) pay for Chromium browser to compensate its development? It's _expensive_, by the way, to develop that complex project.
This sounds like an argument for breaking up Alphabet, not an argument against it.
You're effectively saying that Google is using their resources to give away something really expensive, which means that no competition will ever arise.
The Linux kernel is OSS, yet magically gets build collaboratively. And many large OSS projects exist, often more complex than a browser, without a sole source, single corporate backer.
Or, gasp!, even a corporate backers at all.
The modern stack is built upon, and relies upon OSS. Even chromium draws code taken from other projects, and also, relies upon a myriad of OSS libraries and toolsets.
And beyond all of that, Firefox exists is an immensely cash flush environment.
There are endless business models, and OSS development models, without business involvement to make a browser.
The world was doing just fine before chromium came onto the scene. Chrome was pushed by Google's search engine, bundled with Chrome books, Android, on TVs, and more.
Chrome is market dominant partially due to Google's aggressive push for market share.
All this said, your fears are unfounded, and currently one of largest threats to our way of life, to freedom, to democracy, is the entire ad ecosystem.
This ecosystem, in its curent form, simply must die. There are no patches, no fixes which involve any data collection on the user, that allow for co-existance with personal freedom and democratic principles.
Ads need to be served with zero knowledge stored and collected about users, and anonomization is meaningless and proven useless.
Whether Google is broken up or not, Chrome will die soon enough, as a personal spy, and a collection device.
Google's best move right now, is to discover profitability, research how to enable it, without data collection.
Because what has happened to Meta is only the start, what is happening to Google and others in the EU, is coming to the rest of the West, and this business model is over. It's done. Finished.
Execs who are not planning for a corporate future without data collection, are poorly managing, and living in the past.
Google's best move is to see where the market will be without data collection, and use its immense power to move there now.
> Hence, a lot of screen space is wasted and the user has to scroll more
Unfortunately that appears to be the case for a great many sites when viewed on a mobile device.
My current pet hate is British Airways, https://www.britishairways.com/travel/home/public/en_gb/ has so much wasted space that on my Pixel I have to scroll to reach the buttons "Manage My Booking" and "Check In". Further down the page the "Your account" and "Sign up" bits are so large and generously padded that they fill my mobile device's screen all by themselves.
Is this by design? Maybe in some warped design brief "scrolling" = "[potential] customer interaction" = a KPI gets fulfilled?
Au contraire. That is good question. Everything in the snippet except the font-size should also work with the body selector. The font-size is an exception here as it defines the root font size that the `rem` unit is based on. And that has to be defined on html.
in my personal css framework, i only do fluid type on headers, not body text, as i found the effect to be too subtle to matter. but header text can be overwhelming on small devices without it.
then you can let the user (agent) set the default font size on root/html.
I like this but given the max-width: 70ch, how do you prefer to handle things that you do want to take up the full screen width, such as pictures or header/footer with a background color? Explicitly set each of them to 100vw? I've tried the opposite approach, setting the max-width only on p,h1,h2,h3 (etc) but it's error-prone. I've never quite found a set up that feels simple and robust.
OK. This will probably be in the range 640–780px where it caps out (taking the font-size scaling for that width into account), but it depends on the font (and the viewport aspect ratio because of the font-size vmin component). Acceptable.
> padding: calc(1vmin + .5rem);
Assume the browser em is 16px (almost always true) and the above values for 70ch, and you end up with this reaching almost 15px at 700px, down to 11px on a 300px viewport (which is about the narrowest realistic viewport). I reckon a bit more is warranted at both ends, and tying it to viewport width only rather than vmin. I’d prefer just `padding: 1rem` (16px everywhere) or `padding: 4vw` (12px at 300px, 28px at 700px). Maybe a mixture like `padding: calc(3vw + .2rem)` if you really want to get fancy (12.2px at 300px, 24.2px at 700px).
Actually, a correction (though I’ll leave that paragraph alone): you haven’t touched the body margin in this stylesheet, so you’ll get an extra 8px on every side, so I’d either adjust that or reduce this padding by approximately 8px in each case. In light of the extra 8px, calc(1vmin + .5rem) is actually a bit much on tiny viewports, rather than too little.
This is typically 16px until 323.5̅px, 18px at 768px, 20px from 1212.4̅px. I would generally prefer to cap at 18px, but this scaling is acceptable. Actually, since it’s using vmin rather than vw, it’s seldom going to reach even 19px because almost no one has viewports that are both even 1000px wide and tall.
I object to this. system-ui is problematic because there’s no guarantee that the font it resolves to is suitable for your content language. In Chinese Windows setups, this is likely to get you a font that renders English fullwidth, basically equivalent to massive letter-spacing. Use `font-family: sans-serif` instead. At present it will commonly resolve to a font that is subjectively not so “pretty”, but it will always provide a reasonable font, and it’ll be even better for users that have chosen their own default fonts.
system-ui has often been being used as a proxy for nicer-looking default fonts, but it has semantics attached to it, and those semantics actually make it an unreliable choice.
Also again comparatively new in the scheme of things, with Firefox the latecomer having only had it for twelve months: https://caniuse.com/font-family-system-ui. Where unsupported, you’ll get the default font, which is likely to be serif. Even if keeping system-ui, I would recommend adding a fallback, e.g. `font-family: system-ui, sans-serif`. (Incidentally also, remember the semantics of system-ui and that it might not be a sans-serif. It could be a serif, or even something more exotic. It could be Comic Sans. Do you really want your website shown in Comic Sans? Wonder if that’s the angle to take in dissuading people from system-ui! :P)
> line-height: 1.75;
Too much. Much too much. I’d suggest something in the range 1.2–1.5.
:is() is also new, last couple of years, https://caniuse.com/css-matches-pseudo. So this excessive line-height is comparatively unreliable. A more compatible spelling of the selector would be `body :not(h1):not(h2):not(h3):not(h4):not(h5):not(h6)`.
> Glyphs are taken from the default user interface font on a given platform. Because typographic traditions vary widely across the world, this generic is provided for typefaces that don't map cleanly into the other generics.
So it might have been used to make the snippet "truly" universal for the developer using it. That said, I believe it would be better to choose the font family based on the content.
Even if a viewer is from a place where Serif/San-Serif/etc. doesn't make sense, they are still viewing the same content as anyone else.
I still don't get it. You don't know what users select as UI font, how can it be universal? On the other hand, you do know what font they like for text, but decide to ignore it and serve them text rendered in what they selected for buttons!
You are correct not to get it. system-ui has been abused from the very start as a proxy for prettier default fonts, but it has semantics, and those semantics make it unsuitable for use as a body font. https://infinnie.github.io/blog/2017/systemui.html gives a simple demonstration of how it can go wrong.
I like my code to be explicit. Meaning, you are clearly defining explicity what you code should DO.
But using the ":not(:set())" operator, you're making your code implicit. Because you're telling your code what NOT to do (and instead rely on defaults or other side effects to define what will happen to your headings line-height).
https://www.nytimes.com/rss