Using >, $, control characters, ", ', empty string, and probably more that I haven't discovered yet will cause a runtime error when used with Html.Attributes.attribute a "".
Normally this isn't much of an issue since Html.Attributes.attribute isn't used often. But at the moment I'm making a html previewer which renders user written html text. When the user is in the middle of typing an html tag, it's quite likely that temporarily malformed html leads to some invalid attribute being created and crashing the app.
One possible solution would be to fix this in the html parsing step (in my particular case that would be https://github.com/danneu/html-parser/tree/2.0.3) but there are several different html parsing packages, and several of them don't account for this. It seems like it would be better to fix this at the source to guarantee that malformed html attributes can't crash the webpage.
Two existing issues bring up this problem #46 #47. Both are closed under the assumption that validating attribute names will significantly impact performance and that the validation code would be unreliable.
Is this true though? Adding a try catch around the the kernel code should not affect performance much in the majority of cases where no exception is thrown? And in the case where it is thrown, I think a performance loss is fine as it will be quite rare. I think it would also be reasonable in those cases to just not render the given attribute or render some placeholder instead.
Likewise, adding a try catch means we don't need to understand every possible way an attribute can be malformed, we just catch the DOMException instead.
Using
>,$, control characters,",', empty string, and probably more that I haven't discovered yet will cause a runtime error when used withHtml.Attributes.attribute a "".Normally this isn't much of an issue since
Html.Attributes.attributeisn't used often. But at the moment I'm making a html previewer which renders user written html text. When the user is in the middle of typing an html tag, it's quite likely that temporarily malformed html leads to some invalid attribute being created and crashing the app.One possible solution would be to fix this in the html parsing step (in my particular case that would be https://github.com/danneu/html-parser/tree/2.0.3) but there are several different html parsing packages, and several of them don't account for this. It seems like it would be better to fix this at the source to guarantee that malformed html attributes can't crash the webpage.
Two existing issues bring up this problem #46 #47. Both are closed under the assumption that validating attribute names will significantly impact performance and that the validation code would be unreliable.
Is this true though? Adding a try catch around the the kernel code should not affect performance much in the majority of cases where no exception is thrown? And in the case where it is thrown, I think a performance loss is fine as it will be quite rare. I think it would also be reasonable in those cases to just not render the given attribute or render some placeholder instead.
Likewise, adding a try catch means we don't need to understand every possible way an attribute can be malformed, we just catch the DOMException instead.