5 ms·

> Especially considering what they want would rather be specified as a parser for generating URLs from user input, and not to simply demand every tool interacti

> Especially considering what they want would rather be specified as a parser for generating URLs from user input, and not to simply demand every tool interacting with URLs to be able to parse malformed URLs. The goal of the URL standard isn't to generate URLs from user input (for example, the browser address bar is out-of-scope), but instead define how <a href="foo"> in HTML (or, rather, more generally, {http://www.w3.org/1999/xhtml}a@href http://www.w3.org/1999/xhtml}a@href from the DOM), url("foo") in CSS, Location: foo in HTTP, and similar get parsed. There are large parts of this that the web relies on undefined error handling around this, which makes it worth standardising somewhere (as browsers cannot practically drop it, and most web content is targeted primarily at browsers, hence if you want to be compatible with the web you need to be compatible with browsers). I'll also point out that the WHATWG scarcely exists: as a venue there's almost no formal organisation or high-level plan, it largely working on some shared values, and as a result there's a fair bit of variety between different groups of people working on different specifications where some take those values to further extremes than others.

kuschku 10y ago
> The goal of the URL standard isn't to generate URLs from user input […], but instead define how <a href="foo"> in HTML Ehm, that’s exactly user input. If it were machine input, there would be a normalized definition, and you’d use that internally. And you wouldn’t define a URL spec this way, but you’d define a strict URL spec that browsers and all tools should use, and a legacy tool for converting URLs. Then any tool that doesn’t directly deal with user input can always be sure the URL they get will strictly follow the standard, and only the first tool in the pipeline has to deal with malformed input (which this is)
- gsnedders 10y ago
  > Ehm, that’s exactly user input. If it were machine input, there would be a normalized definition, and you’d use that internally. That depends on the definition of "user"; most things I'm used to refer only to the current user of the device as the user, and everything else as untrusted input. The problem with having a formal definition of the strict subset is that you end up with bugs (often security critical) in almost every implementation because of some case where the conversion produces something not in the strict subset. That's something that's happened with way too many formats.
  - kuschku 10y ago
    Not really. Usually, in such a situation, you can fail early, and you can log a warning. The alternative, of trying to fix the developers error with heuristics, almost always ends with worse security-critical bugs. There’s a reason people advocate for strict typing, and proper errors, and not PHP’s "any unreferenced constant is of type string with its name being its content".

kuschku 10y ago

> The goal of the URL standard isn't to generate URLs from user input […], but instead define how <a href="foo"> in HTML Ehm, that’s exactly user input. If it were machine input, there would be a normalized definition, and you’d use that internally. And you wouldn’t define a URL spec this way, but you’d define a strict URL spec that browsers and all tools should use, and a legacy tool for converting URLs. Then any tool that doesn’t directly deal with user input can always be sure the URL they get will strictly follow the standard, and only the first tool in the pipeline has to deal with malformed input (which this is)

gsnedders 10y ago
> Ehm, that’s exactly user input. If it were machine input, there would be a normalized definition, and you’d use that internally. That depends on the definition of "user"; most things I'm used to refer only to the current user of the device as the user, and everything else as untrusted input. The problem with having a formal definition of the strict subset is that you end up with bugs (often security critical) in almost every implementation because of some case where the conversion produces something not in the strict subset. That's something that's happened with way too many formats.
- kuschku 10y ago
  Not really. Usually, in such a situation, you can fail early, and you can log a warning. The alternative, of trying to fix the developers error with heuristics, almost always ends with worse security-critical bugs. There’s a reason people advocate for strict typing, and proper errors, and not PHP’s "any unreferenced constant is of type string with its name being its content".