With fetch, an implementation is supposed to throw an AbortError DOMException when consuming the body if the signal passed to fetch is aborted, however I'm unsure which part of the spec covers this. Does anyone know where this comes from? Thanks, would be super helpful

const ac = new AbortController()
const { signal } = ac

const response = await fetch('https://example.com', {
	signal: signal
})

ac.abort()

await response.text()

Filed as https://github.com/microsoft/vscode/issues/161764

hsivonen: https://lists.w3.org/Archives/Public/www-validator/2022Sep/0012.html

I have the self-closing-tag check in the Tokenizer code but I guess I should have it in the TreeBuilder code instead — so I can make it namespace-aware, and so that the warning doesn’t get reported for SVG elements.

hsivonen: I don't really see negative tests for old IBM encoding labels; do you remember creating those?

We could maybe add some to unsupported-encodings.any.js though I'm not sure as we'd have to assume some kind of default I guess. We do for UTF-7 and UTF-32 though so maybe that's okay?

So, if, say, ~70% of precedent is "NotAllowedError" and 30% are something else including TypeError, should we still use TypeError?

Right, I agree that this seems painful to fix across the board retroactively now. Should the TAG Design Principles require authors of "new things that could be used to throw errors" to recommend an error type in the respective spec?

hsivonen: turns out Safari still supports some x-mac-* labels (will PR later and will take suggestions for additional labels to include)

sent an image.

As noted before, it's hard to believe in the use case-drivenness of that list. (specifically: Shift JIS X0213, Big5 times 3, Hebrew times 2, Turkish times 2, both GB18030 and GB2312, Mac OS Korean)

As noted before, it's hard to believe in the use case-drivenness of that list. (specifically: Shift JIS X0213, Big5 times 3, Hebrew times 2, Turkish times 2, both GB18030 and GB2312, Mac OS Korean)

As I think has been mentioned before, that list was essentially copy-pasted from Mail (in 2002), and the last change to the contents of the list seems to have been in 2008. I suspect the changes between 2002 and 2008 were to some degree bug-report-driven.

I'm curious about what Mail counterparty MUA motivated Shift JIS X0213.

I mean I have no idea about the origin of the Mail list, but it wouldn't totally surprise me if that was mostly unchanged from NeXTSTEP Mail.

I suppose Shift JIS X0213 might have had a narrow time window to have come from there if NeXTSTEP Mail had a Pokemon approach to encodings.

Slight cleanup inspired by this discussion: https://github.com/whatwg/webidl/pull/1202

I'm checking, and GNOME Web / Epiphany also has way too many entries in the encoding menu, possibly taking after Safari

Reminds me of those ridiculous sgml shorthands, which I mostly forgot... was it `` or something like that?

Reminds me of those ridiculous sgml shorthands, which I mostly forgot... was it <foo/contents/> or something like that?

I think that's fair, do you have any suggestion where a document that lists recommended error types for common failure scenarios could live?

ISO 8879 § 7.5.1.3 opens with:

The null end-tag is an interesting idea for short elements.

PSA: The W3C HTML checker now reports a warning for any HTML elements that use self-closing-tag syntax — that is, specifically just for elements in the HTML namespace, but not for SVG or MathML elements.

Laissez les bons temps rouler

Is The Standard online these days or do you have a copy of The Handbook?