That's nice resource, especially the "Tests" part showing Firefox keeps them all supported and Safari dropping most of them.
I have explored system colours including deprecated ones with intention to try to tap them into some more pleasant scheme (dimming canvastext for bordrers through color-mix() for example) and was interested about the "palette" we could use without defining own colours. Made a comprehensive "sampler" to test them [1,2] and Results were quite sad, especially outside Firefox [3].
NB, that style does not play well with non-native DPI (e.g. when you have monitor set to 150% scale); to see it mapped to physical pixels, try running this in the browser's console:
tl;dr is that `with` is a long deprecated statement that is good for casual "golfing" and raising eyebrows of JS-savvy folks. Does not work in the "use strict" mode (so in modules) and generally should not be used in any "real-world" production code, since it prevents many optimisations and could possibly make the code harder to grasp. But I guess for casual one-time console doodles it could be fine. Reportedly it is supported in all major JS engines, and I don't think it will be really removed in foreseeable future.
Yes, the sad part of this otherwise brilliant feature is how it got butchered "for the sake of security". Reportedly crooks abused dataURIs as hosting for malware and self-hack schemes. Understandable: it sounds "better" to embed the whole phishing page in link inside e-mail, than to operate some ephemeral server serving the phishing page, that could be blocked on firewall, DNS, or whatever.
So in effect, currently no evergreen browser lets us for example do a top-level navigation to dataURI document. The only way you can get top-level dataURI in your browser is either to type it or open from bookmark. Firefox for example has super cool feature to open "Open this frame to a new tab", what only produces new tab with the dataURI in the url bar, but we have to finish the navigation by pressing Enter or in there.
URL shorteners also do not like dataURIs. Also understandable, since they probably do not want to be "hosting". I have one ancient tinyurl link back from days top-level dataURI navigation worked and tinyurl supported it [1]. This document was able to modify itself :]
Ah, days of yore. I would really like to have a pref in browser's options give me (and other power-users) these "dangerous features" back, like "I know what I am doing and I will always check the URL of all pages, now give me unrestricted dataURIs."
I found typing DataURIs in the location bar to be the "primitive technology" meditation analogue of crafting stuff from flint.
In the spirit of "craftsmen should make their own tools," I've started making an "HTML sandbox" editor with live preview [1] this way, to avoid having to type everything in the URL. It has been fun, and I use it literally daily. It has limited features (no syntax highlighting, for example), but it's super fun to craft that tool in itself.
I dare to bet it has the fastest startup among similar tools. When launched through a keyword "search" bookmark to "seed" the initial content into it, it probably has the fastest "from idea to looking at the outcome" user story of them all. For example, if I have a whim to see whether my browser still can do <blink>, I (alt+)enter "s <blink>foo" into the URL bar and bam, have it loaded, displayed, and can continue editing it in a multiline editor (well, simply a textarea).
I don't think it is "unpopular", the contrary in fact. It's just the best practice to stick to bronze-age standards, since reportedly there are still couple of assistive technologies that do not interpret the new perfectly valid and standardised pattern [1]:
> Both Dragon Naturally Speaking for Windows, and Voice Control for macOS and iOS, don’t recognize implicit association, so the [nesting input inside label without explicit for-id reference] wouldn’t work.
Naturally Speaking was reportedly acquired by a company named "Microsoft", and Voice Control have some connections to that "Apple" company.
That's an argument for continuing to add the "for" and "id" attributes (or for making the association is some other way accessibility software understands)...
But not for keeping the input outside of the label.
True. Maybe I've not put it clear: neither the article nether me were arguing for separated elements. The so called best practice here is exactly as you put it: nest the elements but (sadly) duplicate the relation in attributes, in order to make the two screen readers / voice controls happy.
I've brought up it here just because parent comment stated what perhaps majority of developers believe:
> [nesting] completely avoids [possible gaps in the UI areas] and you don't need to come up with a unique id to use with 'for'.
As for separated elements here, I can imagine scenarios when we need them too (for example if you need to shuffle them in some way, or intend to use a pseudo element of the label), but as noted, it is rarely best solution and requires way more scrutiny and complexity.
I don’t think so, correct me if I’m wrong: an ARIA attribute that might fit here would be aria-labelledby (sic), but per MDN
> Note that while using aria-labelledby is similar in this situation to using an HTML <label> element with the for attribute, there are some very important differences. The aria-labelledby attribute only defines the accessible name. It doesn't provide any of <label>'s other functionality, such as making clicking on the labeling element activate the input it is associated with. That has to be added back in with JavaScript.
The best compromise would be to both wrap the input inside the label _and_ use the “for” attribute.
Typically, it’s best to use elements and controls that are already accessible, as ARIA is more intended to give additional accessibility to components that might not be traditionally accessible, or that require more robust accessibility control.
Having done a lot of accessibility consulting in the past (granted it was a long time ago now), we were instructed to use the aria-label attribute to provide the same text as the label.
Since I do mostly asp.net mvc, I created a bunch of "Accessible" extension methods off the HtmlHelper object.
<%: Html.AccessibleCheckbox("MyCheckbox", label: "My Checkbox") %>
This would output something like:
<label><input type="checkbox" name="MyCheckbox" aria-label="My Checkbox" /> My Checkbox</label>
This is a bad example since the primary reason for not giving IDs is because it is a dynamically created checkbox inside a loop or some other partial view that you might not know if it is a unique ID for the page or not.
Ah interesting, I figured that a properly set and identified label element would suffice - I haven’t noticed our sniffer complaining yet we also strictly use the for attribute and don’t wrap controls that I’m aware of. Thanks for the insight!
> […] picking your preferred language is an unskippable step of setting up a new phone.
This does not address, or more precisely it even prevents the notion of:
> I might prefer some sites in Danish, but others I'd like to have en English.
, i.e. what you set in your OS or UA (browser) is always one preferred and optionally some fallback languages. I second that granular per-site control would be preferable for me either: some texts I prefer in my mother tongue (news, non-tech encyclopedic articles), the rest, namely technical documentation I prefer in English. (Also, I have very bad experiences with localised GUIs, where 1. familiarity with English "original" vastly helps when searching and 2. translations tend to range from bad to hilariously comical.)
But I must admit that most websites serving of content in multiple languages, support client-side pref pretty well, so the situation is not so terrible, in my experience.
Yet, the problematic of content negotiation and user <-> agent <-> author (provider) information passing is interesting and I'd say even under-engineered, and currently terribly suffer from security (anti-tracking) constraints.
One drawback I remember was that sometimes experimental features in some app are available strictly for the US (i.e. "vanilla") version, presumably simply because lack of localisation blocks it for "other" versions.
(Sadly cannot recall concrete program, but I think it was some web browser.)
Nice. Interestingly, the JetBrains Mono OP uses has many opt-in OpenType feature variants that can make more like Fira Code that you use. Some highly opinionated changes I would personally do to like The Monospace Web more would be enabling more serif-y variants and less blockiness, i.e. something like:
/*
Character Variants settings for JetBrains Mono
(All are off by default, left them here all for reference.)
H/T https://wakamaifondue.com/ for the inspect!
This set is pretty much like "ss01" but with "cv07" on
or like "ss02" but with "cv05" off
"id" state `affected glyphs` effect when enabled (my pref/note)
*/
font-feature-settings:
"zero" off, /* `0` slashed, instead of dotted */
"cv01" on, /* `l` flat serif bottom instad of curve (on!!)*/
"cv02" off, /* `t` bottom curve instead of hook */
"cv03" off, /* `g` double-storey (sadly not nice) */
"cv04" off, /* `j` rounded bottom hook */
"cv05" off, /* `l` rounded bottom hook */
"cv06" on, /* `m` smaller middle apex (on!) */
"cv07" on, /* `W` smaller middle apex (on!) */
"cv08" off, /* `K Ж` straight without horizontal joint */
"cv09" on, /* `f` slab serifs (on!!) */
"cv10" on, /* `r` slab serifs (on!!) */
"cv11" on, /* `y λ` rounded tails (on!) */
"cv12" on, /* `u` spur (on!) */
"cv14" on, /* `¢ $` broken strikes (on?) */
"cv15" off, /* `&` like 'ET' */
"cv17" off, /* `f` curved */
"cv18" off, /* `2,6,9 curved diagonals */
"cv19" off, /* `8` symmetrical halves */
"cv20" off, /* `5` rounded bow */
"cv99" off, /* `С с` (cyrillic es) inverted‽‽ */
"liga" off, /* Sadly, not. */
"ss00" off !important; /* // just a terminating bogus without comma. */
Interestingly, what cannot be turned off are the "programming ligatures". Personally I don't like them lately, and I think for a regular webpage content can be odd, especially the triple equals (===) that in JetBrains Mono and other "coding" font produces three parallel lines (like two glyphs wide Identical to : `≡`, if it passes HN character filter).
I've put it into [1] along with some rules that makes it slightly easier to my eyes.
EDIT: disabling ligatures is possible through disabling Contextual Alternates (calt), neat! And it is also possible to keep them on and change only appearance of aforementioned equal sign sequences back to "normal", using ss19. Turns out all features are nicely documented at GH Wiki [1]:
calt – Contains all ligatures. Substitution for : between digits.
ss19 – Adds gaps in ≠ ≠= == ≡≡ ligatures.
Btw, for such simple re-colouring I'd probably rather used CSS hue shift filter or similar effect, and kept the SVG "dumb". But for having different shapes or geometric properties this approach is indeed nifty.
Yes, I do that, too. The benefit of using the sprite system is that it's pretty general, so once you have some CSS for it, it's easy to keep adding new icons. CSS filters are usually more special for each case, but I use them too (mostly for brightness and greyscale things that are repeated on multiple places, e.g. tabs or disabled state).
I have explored system colours including deprecated ones with intention to try to tap them into some more pleasant scheme (dimming canvastext for bordrers through color-mix() for example) and was interested about the "palette" we could use without defining own colours. Made a comprehensive "sampler" to test them [1,2] and Results were quite sad, especially outside Firefox [3].
[1] Dark: https://codepen.io/myf/pen/KKbVpmN [2] Light: https://codepen.io/myf/pen/jOXWPGV [3] https://x.com/myfonj/status/1769512951705149840