The reasoning behind not supporting (or requiring rather) markdown=1 in html elements makes perfect sense, however the new rules do make it more difficult to paste code and will result in some annoying scenarios. As a result, it would make sense to allow the opening html element to instead specify markdown=0 (essentially making markdown=1 be implied when omitted) such that no markdown processing is attempted until the end tag.
The issue is that this would require an end tag to be there (which is not the case currently). And requiring an end tag involves backtracking if you cannot find it, making parsing much more complex
I understand the issue, however thats a decision being made to make the life of programmer easier, not the life of the user easier.
The need to backtrack impacts parsing speed, which impacts users.
@eanderson, I agree with you choices should not be made in favor of programming at the cost of user experience / simplicity.
1 Like
I’m in agreement that programmer convenience should not guide the design of the spec. However, this isn’t an issue of programmer convenience. The issue is whether we have a syntax that can be parsed without polynomial or exponential slowdown.
Performance is an element of user experience. If your commonmark parser can be tied up in knots by a malicious input (say, with lots of open tags with no closers), that is a problem for users, not just programmers.
1 Like