Micro-horror of this moment:
Uncategorized
18
Posts
6
Posters
0
Views
-
Micro-horror of this moment:
- In the HTML/DOM event model, events have names like "click" or "submit"; you attach an event handler to a tag by saying "onclick" or "onsubmit".
- Apparently, for thirty years, I've been writing this wrong, like "onClick" or "onSubmit". Web Browsers just sorta roll with this and convert to lowercase. React/Preact JSX do the same conversion and do not flag an error, they pass it through and then the browser accepts it.
(post 1 of 2)
-
Micro-horror of this moment:
- In the HTML/DOM event model, events have names like "click" or "submit"; you attach an event handler to a tag by saying "onclick" or "onsubmit".
- Apparently, for thirty years, I've been writing this wrong, like "onClick" or "onSubmit". Web Browsers just sorta roll with this and convert to lowercase. React/Preact JSX do the same conversion and do not flag an error, they pass it through and then the browser accepts it.
(post 1 of 2)
However, Yew, the Rust "React"/"Elm"-like library, in its html!{} macro,
- Treats onsubmit and onSubmit as two different things,
- But also recognizes it doesn't know of an html attribute named "onSubmit",
- And also Yew simply *allows* non-specification HTML attributes, rather than rejecting them as React/Preact JSX do,
- However, because unknown HTML attributes default to being strings, it will expect your input to be a string, and you will get a *baffling* error message.
-
However, Yew, the Rust "React"/"Elm"-like library, in its html!{} macro,
- Treats onsubmit and onSubmit as two different things,
- But also recognizes it doesn't know of an html attribute named "onSubmit",
- And also Yew simply *allows* non-specification HTML attributes, rather than rejecting them as React/Preact JSX do,
- However, because unknown HTML attributes default to being strings, it will expect your input to be a string, and you will get a *baffling* error message.
@mcc oh fuck
-
@mcc oh fuck
@xgranade I think I might be able to make a claim that Yew is doing something so wrong here I can file an issue but I'm going to have to think carefully about what.
-
Micro-horror of this moment:
- In the HTML/DOM event model, events have names like "click" or "submit"; you attach an event handler to a tag by saying "onclick" or "onsubmit".
- Apparently, for thirty years, I've been writing this wrong, like "onClick" or "onSubmit". Web Browsers just sorta roll with this and convert to lowercase. React/Preact JSX do the same conversion and do not flag an error, they pass it through and then the browser accepts it.
(post 1 of 2)
I had always just kinda assumed the DOM was specified to be case-insensitive but going back to look at the DOM 1 spec, it was case-sensitive but assumed the environment would do at least some case normalization, without specifying what those normalizations were.
-
@xgranade I think I might be able to make a claim that Yew is doing something so wrong here I can file an issue but I'm going to have to think carefully about what.
@mcc Yeah, makes sense. No step along the way feels *obviously* wrong as I read it, and yet...
-
I had always just kinda assumed the DOM was specified to be case-insensitive but going back to look at the DOM 1 spec, it was case-sensitive but assumed the environment would do at least some case normalization, without specifying what those normalizations were.
Also Elm seems really neat to me.
-
Also Elm seems really neat to me.
@rk Well, unfortunately, I'm not using Elm.
-
I had always just kinda assumed the DOM was specified to be case-insensitive but going back to look at the DOM 1 spec, it was case-sensitive but assumed the environment would do at least some case normalization, without specifying what those normalizations were.
@rk Can you help me figure out, in the current living standard, what the browsers would point to to guide their decisionmaking on what happens if they see an html attribute which has the same name as a standard-defined attribute but with a different case? https://html.spec.whatwg.org/multipage/dom.html#attributes
-
@rk Can you help me figure out, in the current living standard, what the browsers would point to to guide their decisionmaking on what happens if they see an html attribute which has the same name as a standard-defined attribute but with a different case? https://html.spec.whatwg.org/multipage/dom.html#attributes
Hmm. There’s this:
All attribute names on HTML elements in HTML documents get ASCII-lowercased automatically, so the restriction on ASCII
uppercase letters doesn't affect such documents. -
Hmm. There’s this:
All attribute names on HTML elements in HTML documents get ASCII-lowercased automatically, so the restriction on ASCII
uppercase letters doesn't affect such documents.And the part of the doc talking about XSLT preprocessing indicates that all elements should be converted to lowercase if producing HTML, if I’m reading it correctly.
-
Hmm. There’s this:
All attribute names on HTML elements in HTML documents get ASCII-lowercased automatically, so the restriction on ASCII
uppercase letters doesn't affect such documents.@rk Thanks.
-
Micro-horror of this moment:
- In the HTML/DOM event model, events have names like "click" or "submit"; you attach an event handler to a tag by saying "onclick" or "onsubmit".
- Apparently, for thirty years, I've been writing this wrong, like "onClick" or "onSubmit". Web Browsers just sorta roll with this and convert to lowercase. React/Preact JSX do the same conversion and do not flag an error, they pass it through and then the browser accepts it.
(post 1 of 2)
@mcc wait what
I swear I've only ever seen them camel cased, I would have been money that was correct
-
@mcc Yeah, makes sense. No step along the way feels *obviously* wrong as I read it, and yet...
@xgranade @mcc to us the flaw is mostly that it doesn't put more work into giving an error message that helps you understand the root cause. like, error messages should not be purely formal things, they are a form of communication, and tools that generate them should consider context to present the error in the most helpful way
-
@xgranade @mcc to us the flaw is mostly that it doesn't put more work into giving an error message that helps you understand the root cause. like, error messages should not be purely formal things, they are a form of communication, and tools that generate them should consider context to present the error in the most helpful way
@ireneista @xgranade yes but to my mind that's not a clear enough ask to file an issue, at least not when I have the ability to read the spec and come up with a better suggestion.
-
@ireneista @xgranade yes but to my mind that's not a clear enough ask to file an issue, at least not when I have the ability to read the spec and come up with a better suggestion.
-
@xgranade @mcc to us the flaw is mostly that it doesn't put more work into giving an error message that helps you understand the root cause. like, error messages should not be purely formal things, they are a form of communication, and tools that generate them should consider context to present the error in the most helpful way
@ireneista @mcc I agree it's a flaw, but it's also not obviously wrong behavior so much as suboptimal? Error messages are immensely important to figure out how to get something that doesn't work to a state where it does, I agree fully, but also what's the correct behavior here?
-
@ireneista @xgranade yes but to my mind that's not a clear enough ask to file an issue, at least not when I have the ability to read the spec and come up with a better suggestion.
Valid. Meanwhile though, your chain of logic in the explanation highlights to me the key step where expectations and error output get disconnected is the one where an unknown attribute continues through. Maybe there's a discussion about the right behaviour at each step, especially that one, but more so I think your error might be much less baffling if it made clear that the attribute is an unknown unhandled stringly typed thing.
-
undefined oblomov@sociale.network shared this topic
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@eyeling perfect. hook her up with critically acclaimed mmorpg final fantasy xiv
-
spazioComunicazioni
@anarchia
spazioComunicazioni Ciò che si muove nel movimento questa settimana. Per promuovere le iniziative e gli eventi nei posti occupati e di movimento mandare una mail a ondarossa@ondarossa.info.
https://www.rivoluzioneanarchica.it/spaziocomunicazioni/
-
@aeva She's chronically online enough as it is chatting to anyone under the sun. 😅
-
There's more, especially on the state level. Eg the Idaho house just passed a bathroom ban that bans trans use of bathrooms *in private businesses*, with mandatory enforcement by businesses, punishable by a $10k fine if a customer identifies a trans person in the bathroom. https://www.boisestatepublicradio.org/politics-government/2026-02-17/idaho-house-passes-transgender-bathroom-ban
Kansas rolled out a bathroom bill that provides *bounty hunting*, where people are paid for turning in trans people who use the "wrong" (ie, right) bathroom https://www.thepinknews.com/2026/02/19/anti-trans-bathroom-bill-kansas/
I'm just saying. It's getting bad. It's worth knowing how bad.
-
@ephesossh She was into farming simulators a few years back. However, she's chronically online enough as it is. Less screentime would be better.
-
@eyeling @bouncinglime 😂 As an introvert who enjoys being alone, this is the best idea I can give you. I can't think of anything else.
-
@stefano
Maybe it would be needed some additions."Excluding languages stating memory-safety. They shall not allow writing mutually memory unsafe operations like volatiles, memory mapped I/Os. Let those to be written in other languages and sanely link with it with warnings."
-
@fetchezlavache 😂
