the more I work with HTML, CSS, and JS the more footguns I find

today I learned that - although you have to escape all raw < and > characters in HTML with < and > respectively under all(?) other circumstances - you should never do that if those characters are inside of a <script> tag

seriously?

@kasdeya yeah no it's not just script tags

style, script, and a few others only close with their exact match, and the stuff inside them is not interpreted as html tags (as they're just embedding another language in there)

this leads to some weird behavior where like you shouldn't have "</script>" anywhere in your JS block (even inside string quotes) as the browser is resolving the HTML tag tree before it even begins to evaluate what's inside the script or style tags

@kasdeya

The way I think about it is:

If you want literal `<` and `>` in HTML, you have to use the escaped versions so it can distinguish between literals and tags.

But once you're inside a `<script>` tag, you're no longer writing HTML, you're writing Javascript. Since you don't need to escape `<` and `>` in Javascript, you don't escape them.

(But it does of course get weird if you use Javascript to inject HTML into the doc.)

Once you arrive at `</script>`, you're back to writing HTML.

@kasdeya

If it bugs you, you can always pull your JavaScript out into a separate document, have the HTML page load it in the header, and just work with them separately.

@tempest @kasdeya it never really clicked for me why HTML can't just be described as a subset of XML. stuff like this is the reason isn't it

@erin @kasdeya that and void tags and probably some other errata yeah

@tempest @erin @kasdeya html should not be

@tempest @kasdeya @erin html still should not be

@tempest @erin @kasdeya in addition to void tags, html's {compatibility with self-closing tags despite not supporting self-closing tags} introduces all sorts of fun inconsistencies between [html, xml]

• <img> is {invalid xml: <img> open tag isn't closed} but {valid html: because img is a void element, <img> tags implicitly close themselves}
• <img></img> is valid xml but {invalid html: explicit close tags for void elements are forbidden}
• <img /> is {valid xml: the tag is explicitly self-closing} and also {valid html: the slash for the self-closing tag is silently discarded, but the img tag closes itself}
• <span /> is valid xml but {invalid html: the slash is silently discarded, and there is no </span> close tag}
• <span /></span> is {invalid xml: </span> close tag has no paired open tag} but {valid html: the slash is silently discarded, and [the <span> open tag, the </span> close tag] form a pair}

@catgirl_so @erin @kasdeya see we classified this all under "void tags and their consequences" so didn't feel it needed to be spelled out, but thank it for being precise

*pats the bot*

@catgirl_so @tempest @erin @kasdeya are we allowed to bring up quirks mode in addition to this?

@erin @tempest @kasdeya you can use XHTML if you want a more XML-like experience. you have to be way more strict with what you write though, because the slightest error will result in a yellow screen of death, but i see that as a positive, at least in a dev environment.

@esheep @tempest @erin I’ve actually been thinking of switching over to XHTML. I’m not sure if yattag - the HTML generator I’m using - supports it but I love that the syntax is stricter and less cursed lol

do you know if it supports enough modern HTML stuff to be worth using? because I don’t know too much about HTML but I know that HTML 5 has “semantic tags” for describing what’s inside of them, which is helpful for screen readers. and I’m not sure if XHTML has those too

@kasdeya @tempest @erin It has all the things HTML5 has, in theory it’s “just” a slightly different, stricter syntax. I don’t think it even has an official XSD to validate against.

Actual support may differ in practice though, so I’d recommend to test a lot with different browsers. You also need to serve it with a different Content-Type header, which may not be possible depending on your setup (a cheap shared web host may not let you tinker with that for instance).

With regards to accessibility, it’s got all the same tags and ARIA markers as HTML, so in theory I’d say it’s comparable, but once again in practice I don’t know if assistive tech like screen readers treat XHTML differently than any other HTML webpage.

WHATWG has a Wiki page listing the differences between HTML and XHTML. It doesn’t mention accessibility at all though. Here’s the link: https://wiki.whatwg.org/wiki/HTML_vs._XHTML

@kasdeya @tempest @erin Like at the most basic level I’m sure there’s some browser out there that will just not support the application/xhtml+html mime type at all and just crash then and there before even attempting to parse the response

heck, maybe a corporate vpn would block it too idk

@esheep @tempest @erin ooh thank you for the info! I’m using Flask so I’m like 90% sure that I can set the Content-Type header when responding to an HTTP request. and I’m really glad that XHTML is just a different syntax for HTML instead of like, a branch in HTML’s functionality that isn’t forwards-compatible with changes in how HTML works

I really might look more into this once I’m done with the basic functionality of my project, because HTML’s inconsistent syntax bothers me a fair bit lol

@rowan @kasdeya @catgirl_so @erin we considered it but declined to take the opportunity

. . . but if you want to, be our guest