Whenever I write basic html, and display it on a phone, the text is unfathomably tiny. What I want it to do is do semantic html and pick a reasonable text size and format around that. But instead it's like "I MUST simulate a 1080p monitor then shrink down". It is like I am missing some magic on-phones:dont-look-like-butt CSS tag.

Why :(

Examples:
1. https://pocket.runhello.com
2. https://data.runhello.com/j/redox/pkg-test-2/
3. Same but with max-width css removed, in case that's the problem

This fixed the problem :( This fixed it completely :( I hate HTML :( I hate hate hate hate HTML :(

https://glauca.space/@r/117356657383921680

*Me, from the 1990s, having a good time typing on my computer*: <html>

*Web browser, screaming directly into my ear*: WRONG

Okay so what I've got now is

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>

</body>
</html>

Is that the current/2026 valid "minimum viable html"? Are there any other SECRET CODES I should know about? Is there some secret third <meta> for "don't display text behind the big fucking hole in modern iphones"?

@mcc no thats it

Also can I just say how annoyed it makes me that html at some point made /> on certain html elements (like, <br />) optional or even disfavored. XHTML was a good idea. Why didn't we stick with that. How the fuck am I supposed to remember if /> is banned or required

RE: https://mastodon.social/@mcc/117312480130722719

.

@mcc /> is strictly banned in HTML5.

@Sylvhem then how do I remember which tags need a corresponding closing tag and which tags are banned from being closed

@mcc I mean, there is only thirteen void elements, so I supposed you just have to learn them by heart.

https://html.spec.whatwg.org/multipage/syntax.html#void-elements

@Sylvhem THE THIRTEEN VOID ELEMENTS sounds like a cool wizard thing and not like html having historical baggage :(

@mcc as it turns out, in the face of a > getting dropped somewhere, "do your best" is a better experience than "Malformed XML document"

@eevee I actually didn't know today that xhtml pages got rejected if the XML didn't parse. In my defense, XHTML was never seriously adopted, so apparently my experiential data of it is non-existent

@mcc @eevee i remember finding this out back in uh... 2008, i think? i remember thinking XUL is a good idea and tried to get Firefox to run XUL from a non-local origin (it didn't like my javascript :<)

@whitequark @mcc @eevee yeah i also make some small admin UIs for a startup with XUL. It was painful but also felt like it was so promising!

@evert @mcc @eevee remember xulrunner? i made an "electron app" with it for a game i was working on before everyone hated electron (and before electron even existed)

@whitequark @mcc @eevee yeah also! i was always scared of C (still) so i felt that this could finally open the door to desktop apps to me.

@evert @mcc @eevee the big reason to use xulrunner for me (i used html for the frontend) was that i wanted a socket and websockets weren't a thing yet either

@mcc @eevee also browsers are pretty tolerant with that stuff. You could write something like

<div><p>hello<br>world

In a document and it would display just fine and the browser will close the elements automatically if you look at the dev tools lol

@eramdam @eevee What we are discussing is that if you opt into XHTML parsing with your doctype, either currently or at one time, you were specifically opting into a mode where it actually rejects your page if the XML does not parse. This was explained to me by someone else yesterday but I have never seen it.

@mcc @eramdam i think you also needed to send an xml mimetype, or you'd just get the normal html parser, which would ignore all your self-closing / anyway

an easy way to demonstrate the difference is to try to write <script />

i did do Real XHTML™, but it turns out templating tends to amplify typos, and while the xml parser is good at *finding* them, it's a crapshoot who it finds them for first

@mcc @eevee well, in strict mode.

@fishidwardrobe @mcc there is no non-strict mode. xml has no error-correction. if your xhtml is being parsed leniently then it's not really xhtml, it's just html with aspirations. this was actively bad since <script src="..."/> means very different things to an xml parser (shorthand for empty element) vs an html parser (opening tag with an errant / and everything else up to a </script> is the contents)

@fishidwardrobe @mcc in practice i would guess a lot of "xhtml" was just html with errors in it, written by people thinking "wow this <br/> stuff is so much clearer" when it wasn't actually doing anything and would explode if you tried to use it meaningfully

@eevee @fishidwardrobe @mcc yeah last time i saw xhtml in the wild it was just straight invalid xml. still rendered fine though since i don’t think any browser ever actually parsed it as xml?

@charlotte @fishidwardrobe @mcc firefox absolutely did if you sent it as application/xhtml+xml

@eevee @charlotte @fishidwardrobe imo any technology that requires me to use a server with correctly configured MIME types is a dead technology

@mcc @eevee @charlotte @fishidwardrobe I definitely messed around with xhtml like, idk, 15 years ago (…probably closer to 18) and the browsers I was using it validated it like xml without needing to configure the MIME type

I can’t remember if I had to do anything special but, like, this was when I was using shared hosting or just “opening files from my hard drive” and I know I got xml render errors when I broke things

@mcc @eevee @charlotte @fishidwardrobe hugely bad news about activitypub,

@eevee @charlotte @fishidwardrobe @mcc It still does, with the very same famously clear error messages as 15 years ago

@mathieui @eevee @charlotte @mcc
"DTD XHTML 1.0 Transitional" — the cop-out we all used, i think

@fishidwardrobe @mathieui @charlotte @mcc "transitional" has nothing to do with how it was parsed, it just allowed a few elements like <font> that were considered obsoleted by css

@mcc @eevee @charlotte @fishidwardrobe I feel like the year 2026 might be the time that MIME types have actually mattered more than any time before. I've run into quite a few things that break if MIME types are wrong.

@eevee @charlotte @fishidwardrobe @mcc I used to absolutely send application/xhtml+xml, and it made quite a few people mad.

I liked it though. It's the only time HTML has made any sense in any way.

@WAHa_06x36 @mcc @eevee @charlotte @fishidwardrobe Also BTW for the HTML encoding thing it's also a good idea to serve up your content-type as "text/html; charset=utf8" if possible (although still have the '<meta charset="utf-8">' in the <head> since it's more portable, it's so stupid that HTML still defaults to the current locale in 2026)

@WAHa_06x36 @mcc @eevee @charlotte @fishidwardrobe The most recent information I have (which I had to refresh myself on the other day) is that text/* content-types default to the locale (and what counts as "the locale" is suuuuuper subjective and poorly-defined) and everything else is supposed to specify a default encoding but most things don't (but the rare things which do all use utf-8, thankfully)

@WAHa_06x36 @mcc @eevee @charlotte @fishidwardrobe or there's always the wishful thinking of always sending out a BOM at the start of the file and hope it gets respected (it probably won't, and will just cause the consumer to interpret it as a literal 0xFE 0xFF byte sequence and then break something else)

@fluffy @mcc @eevee @charlotte @fishidwardrobe I seem to recall that sending a BOM in UTF-8 is actually completely against spec as well?

@WAHa_06x36 @fluffy @mcc @charlotte @fishidwardrobe it's not, it's just not recommended (because the BOM is meaningless for utf8) (FF FE and FE FF are both invalid utf8 though)

@eevee
@charlotte @fishidwardrobe @mcc caniuse suggests that all browsers still do, and only when with the correct content type is set

@WAHa_06x36 @fluffy @mcc @charlotte @fishidwardrobe lmao but HTML5 does mandate detecting encoding via the BOM, including utf8. wild but ok

@charlotte@akko.chir.rs @fishidwardrobe@mastodon.me.uk @mcc@mastodon.social @eevee@slime.global my blog page is xhtml, probably
https://pikopublish.ing/u0421793/bolg/whichradio.xhtml

@eevee @WAHa_06x36 @mcc @charlotte @fishidwardrobe a BOM does make sense in UTF8, it's just encoded as EF BB BF, the UTF-8 encoding of U+FEFF.

@fluffy @WAHa_06x36 @mcc @charlotte @fishidwardrobe i mean, there's no such thing as byte order in utf8 in the first place, because it's defined as a stream of individual bytes

@eevee @WAHa_06x36 @mcc @charlotte @fishidwardrobe right but the point to the BOM is to detect what the encoding is of a document, and so it's just "how does this document encode U+FEFF." It's probably not the best name for it but the concept is the same, just a little more general than what's implied by the name that's based on the two UTF-16 variants.

A better term would probably be "Unicode encoding marker" but, y'know. Language is imprecise.

@eevee @WAHa_06x36 @mcc @charlotte @fishidwardrobe also technically Unicode just refers to it as "U+FEFF zero width space" and having it as the first codepoint in a file as an encoding detection is what the BOM concept entails

but regardless, a *lot* of things break with a BOM if they're not specifically expecting it, so it's a well-meaning attempt at declaring an encoding in a byte stream that still doesn't work in the real world most of the time