Tags to make HTML work like you expect • Hacker News Board

Re: Tags to make HTML work like you expect

#241

Post by mb2100 » Tue, Oct 28, 2025, 4:18 PM UTC

ilaksh wrote: post #19

Anyone else prefer to use web components without bundling? I probably should not admit this, but I have been using Lit Elements with raw JavaScript code. Because I stopped using autocomplete awhile ago. I guess not using TypeScript at this point is basically the equivalent for many people these days of saying that I use punch cards.

Definitely team #noBundler for most websites. But I didn't wanna give up TypeScript. With Deno and even Node.js supporting type-stripping now natively, all I had to do for https://mastrojs.github.io was to use ts-blank-space to transform client-components on the fly.

Re: Tags to make HTML work like you expect

#242

Post by chrismorgan » Wed, Oct 29, 2025, 4:07 AM UTC

childintime wrote: post #159

brianzelip wrote: post #73

> ` ` The author might consider instead: ` `

It's time for an "en-INTL" (or similar) for international english, that is mostly "en-US", but implies a US-International keyboard and removes americanisms, like Logical Punctuation in quotes [1]. Then AI can start writing for a wider and much larger public (and can also default to regular ISO units instead of imperial baby food). Additionally, it's kind of crazy we are not able to write any language with any keyboar…

If you want to divide English into only two categories, I reckon US English (color, analyze, center) and International English (colour, analyse, centre) is the best divide. It’s imperfect—Canadians are mostly International but want analyze, and there are other controversial words like program/programme (US, CA and AU prefer program; GB and IN prefer programme)—but I think it’s the best divide if you want only two.

Windows distributes ISOs labelled English (en-US) and English International (en-GB) along this divide.

It’s also a valuable divide for reasons beyond language, because the USA really does have a habit of doing its own thing, even when pretty much the rest of the world has agreed on something different. Your US English locale can default to Fahrenheit, miles, pounds, Letter, and their bizarre middle-endian date format, while International English can default to Celsius, kilometres, kilograms, A4, and DD/MM/YYYY. It doesn’t sort out everything, but it gives a much better starting point. Not every non-American prefers DD/MM/YYYY, but even if they’d prefer something like DD.MM.YY or YYYY-MM-DD, DD/MM/YYYY is a whole lot better than MM/DD/YYYY.

Re: Tags to make HTML work like you expect

#243

Post by dinkelberg » Wed, Oct 29, 2025, 5:51 PM UTC

zamadatix wrote: post #210

dinkelberg wrote: post #102

TFA itself has an incorrect DOCTYPE. It’s missing the whitespace between "DOCTYPE" and "html". Also, all spaces between HTML attributes where removed, although the HTML spec says: "If an attribute using the double-quoted attribute syntax is to be followed by another attribute, then there must be ASCII whitespace separating the two." ( https://html.spec.whatwg.org/multipage/syntax.html#attribute... ) I guess the brows…

For anyone else furiously going back and forth between TFA and this comment: they mean the actual website of TFA has these errors, not the content of TFA.

Sorry for confusing you!

Re: Tags to make HTML work like you expect

#244

Post by angiolillo » Wed, Oct 29, 2025, 6:43 PM UTC

panzi wrote: post #226

angiolillo wrote: post #150

Earlier quoted context omitted.

Setting aside the relative merits of 12pt vs 16pt font, websites ought to respect the user's browser settings by using "rem", but HN (mostly[1]) ignores this. To test, try setting your browser's font size larger or smaller and note which websites update and which do not. And besides helping to support different user preferences, it's very useful for accessibility. [1] After testing, it looks like the "Reply" and "Hel…

Side note: pt != px. 16px == 12pt.

You are correct, it should have been "px".

Re: Tags to make HTML work like you expect

#245

Post by hunter2_ » Wed, Oct 29, 2025, 9:40 PM UTC

lioeters wrote: post #219

hunter2_ wrote: post #215

Earlier quoted context omitted.

Yeah, this is like keeping a sound system equalized for one album and asserting that modern mastering is always badly equalized. Tune the system to the standard, and adjust for the oddball until it's remastered.

Except we all know what happened to the "standard" with the Loudness War.

I'm not a fan of extreme compression and limiting, but doing so in a multiband fashion (as occurs due the loudness war) actually does result in more consistent EQ from album to album, label to label, genre to genre, etc. which virtually eliminates the need to adjust EQ at playback time between each post-war selection.

Re: Tags to make HTML work like you expect

#246

Post by fud101 » Sun, Nov 02, 2025, 2:57 AM UTC

cluckindan wrote: post #192

CSS rules to make styling work like you expect: *, *:before, *:after { box-sizing: border-box; }

can you explain why you add this please?

Re: Tags to make HTML work like you expect

#247

Post by eska » Sun, Nov 02, 2025, 10:59 AM UTC

hnthrowaway121 wrote: post #57

eska wrote: post #55

Earlier quoted context omitted.

I’m not a blind person but I was curious about once when I tried to make a hyper-optimized website. It seemed like the best way to please screen readers was to have the navigation HTML come last, but style it so it visually comes first (top nav bar on phones, left nav menu on wider screens).

Wouldn’t that run afoul of other rules like keeping visual order and tab order the same? Screen reader users are used to skip links & other standard navigation techniques.

Interesting question. I don’t remember testing this, sorry.

Re: Tags to make HTML work like you expect

#248

Post by hnthrowaway121 » Sun, Nov 09, 2025, 5:34 PM UTC

cluckindan wrote: post #195

sholladay wrote: post #81

Earlier quoted context omitted.

Props to you for taking the time to test with a screen reader, as opposed to simply reading about best practices. Not enough people do this. Each screen reader does things a bit differently, so testing real behavior is important. It's also worth noting that a lot of alternative input/output devices use the same screen reader protocols, so it's not only blind people you are helping, but anyone with a non-traditional s…

”Each screen reader does things a bit differently, so testing real behavior is important.” Correction: each screen reader + os + browser combo does things a bit differently, especially on multilanguage React sites. It is a full time job to test web sites on screen readers. If only there was a tool that would comprehensively test all combos on all navigation styles (mouse, touch, tabbing, screen reader controls, sip a…

Do you know about assistiv labs?

Doesn’t hit everything but it can run real device screen reader automated tests