While working on whatwg/url#557 I realized that the URL standard will have to invoke the Encoding Standard at a lower level of abstraction as it needs to deal with erroneous output (&#...;) differently from non-erroneous output. I.e., an error that results in &#...; might have to be percent-encoded, but a non-error &#...; sequence might not have to be.
So URL basically wants to invoke the encoder's handler directly I think. I don't really see a better abstraction as it needs to deal with errors in a very different way. I suppose we could make error handling a caller defined set of steps, but I don't really like the complexity of that.
text/plain form submission could in theory still use the current high-level encode hook, but I'm not sure it's worth saving just for that.
It also seems there's potentially quite a lot of other potential cleanup that would result from this (e.g., https://encoding.spec.whatwg.org/#concept-encoding-process no longer needs to handle "html").
Having "html" in the Encoding standard as well as this high-level hook was intentional as a way of limiting the amount of badness that could be introduced by consumers, but we will have to use review rather than abstractions for that instead (UTF-8 or die). It's unfortunate, but it might also make the Encoding standard a little leaner.
cc @andreubotella @hsivonen @achristensen07 @JKingweb
While working on whatwg/url#557 I realized that the URL standard will have to invoke the Encoding Standard at a lower level of abstraction as it needs to deal with erroneous output (
&#...;) differently from non-erroneous output. I.e., an error that results in&#...;might have to be percent-encoded, but a non-error&#...;sequence might not have to be.So URL basically wants to invoke the encoder's handler directly I think. I don't really see a better abstraction as it needs to deal with errors in a very different way. I suppose we could make error handling a caller defined set of steps, but I don't really like the complexity of that.
text/plainform submission could in theory still use the current high-level encode hook, but I'm not sure it's worth saving just for that.It also seems there's potentially quite a lot of other potential cleanup that would result from this (e.g., https://encoding.spec.whatwg.org/#concept-encoding-process no longer needs to handle "html").
Having "html" in the Encoding standard as well as this high-level hook was intentional as a way of limiting the amount of badness that could be introduced by consumers, but we will have to use review rather than abstractions for that instead (UTF-8 or die). It's unfortunate, but it might also make the Encoding standard a little leaner.
cc @andreubotella @hsivonen @achristensen07 @JKingweb