The whitepaper says that the benchmark counted accessibility problems using the tool axe-core (https://github.com/dequelabs/axe-core). It’s too bad that neither the site nor the paper contains any examples of an LLM output and its list of detected problems. I am curious about these aspects:

• Which of axe-core’s rules (https://github.com/dequelabs/axe-core/blob/develop/doc/rule-...) LLMs violate most often

• Which groups of users are most affected by those rule violations (e.g. blind users or deaf users)

• Whether it’s likely that I unintentionally violate those same rules in web pages I write

Examples of rule violations and statistics on most-violated rules would make the website more convincing by showing that the detected accessibility errors reflect real problems. It would rule out that the only detected error was a single noisy false positive rule in axe-core. I bet that most readers are not familiar enough with axe-core to trust that it has no false positive rules.

The section “Utility Classes: Yes, They Still Exist” is unfair in its comparison of Tailwind with pure CSS. It doesn’t take into account Tailwind’s recommendation in https://tailwindcss.com/docs/styling-with-utility-classes#us... that “if you need to reuse some styles across multiple files, the best strategy is to create a component” in your front-end framework or templating language. So its example of a “typical Tailwind component” is incomplete.

A better comparison would use, for example, a React component:

  function Button({ children }) {
    return (
      <button
        className="inline-flex items-center gap-2 px-4 py-2 rounded-full
                   border border-gray-300 bg-white text-gray-900
                   hover:bg-gray-50 focus:ring-2 focus:ring-blue-500"
      >
        {children}
      </button>
    );
  }
  
  // Usage:
  <Button>Save</Button>

This would counter all of the article’s arguments in favor of pure CSS. If the website used a `Button` component like this, it would also be true that the “HTML stays readable”, that “changes cascade”, that “variants compose”, and that “media queries live with components”.

A better argument against Tailwind would be the added complexity of having a build system and a front-end framework or templating language, if your project doesn’t already have those for other reasons.

(adapted from my better-formatted comment at https://lobste.rs/c/oznzzj)

It’s not just on mobile – PC Gamer’s website does that on desktop too. Even with uBlock Origin. :(

standardly’s comment has only hyphens, not em dashes. Em dashes are much longer: - vs. —

Jujutsu’s changelog (https://jj-vcs.github.io/jj/latest/changelog/) goes all the way back to 2022 and shows there was a release as recently as two weeks ago. I don’t see why the maintainers would stop at this point.

Also, from Jujutsu’s README (https://github.com/jj-vcs/jj#mandatory-google-disclaimer):

> I (Martin von Zweigbergk, martinvonz@google.com) started Jujutsu as a hobby project in late 2019, and it has evolved into my full-time project at Google, with several other Googlers (now) assisting development in various capacities.

Wow, 2022? Such age, many longevity.

I made the “sit” gloss long: “to rest your body on your bum (while your bum is on a thing such as a chair or the ground) while your back is up”.

I don’t see anything specifically about boyhood or childhood on that page or on the rest of that sub-Reddit’s wiki. Do you have a more precise link?

Context: the Online Safety Act (https://en.wikipedia.org/wiki/Online_Safety_Act_2023) is a law of the United Kingdom. Previous discussion on Hacker News: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

> the two words do not sound even remotely the same

Pronounced correctly, “segue” sounds just like “Segway” – not like “seg-oo”, as you might have assumed.

TIL, thanks! You are right, that I assumed it would be like "seg-oo".

An excellent example of why dash length matters. Because of the wrong usage of ‘—’ and ‘-’, it took me 10 more seconds of rereading and re-parsing your comment to understand what that first sentence meant.

I see what you did in the second paragraph too. It’s another example of “a millimeter of difference in the length of a line” mattering in that it looks weird, though it’s not much harder to read.

The undotted small "i" character comes from the modern Turkish alphabet. It's perhaps only slightly disorienting for an English reader to slightly shorten some letters that are just lines in a sans-serif font. In Turkish though, a millimeter of line can make an entirely different letter.

Being able to render a variety of line lengths with different meanings is a cool and useful thing.