Parser thinks that <= is a valid open tag.

[ELadner]

In vanilla NodeBB (via the sanitize-html plugin, which is built using htmlparser2), any combination of <, >, <=, >= can be entered in a post and the results are rendered correctly.

In NodeBB, sanitize-html installed (which uses htmlparser2 internally), < and > are handled correctly, but using <= in a post will treat it as an HTML start tag and not include anything beyond the symbol combination.

This, for example: "this <= is a >= test" renders as "this = test" (the > after 'is a' is treated as the close of the <= ).

Reported to sanatize-html initially and the developer there pointed out the htmlparser2 involvement.

[boutell]

The HTML5 spec seems to indicate that this is a point where an unexpected character like = should cause the interpretation as a tag to be revoked and the < and = to be consumed as text instead, when aiming to be tolerant, as htmlparser2 generally is. https://www.w3.org/TR/html5/syntax.html#tag-open-state

[ELadner]

Thanks for the additional info.

I'm all for tolerance and flexibility, but <= shows up a lot when you're pasting code blocks. Hopefully, the benevolent developers will grant an exception for that bit of flexibility and receive it as plain text.

Note there was a recent issue with <[ being recognized as a start tag, and that issue was handled nicely.

[boutell]

The "tolerance and flexibility" is the thing you're asking for (:

…

On Mon, Sep 11, 2017 at 10:37 AM, ELadner ***@***.***> wrote: Thanks for the additional info. I'm all for tolerance and flexibility, but <= shows up a lot when you're pasting code blocks. Hopefully, the benevolent developers will grant an exception for that bit of flexibility and receive it as plain text. Note there was a recent issue with <[ being recognized as a start tag, and that issue was handled nicely. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#220 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB9fR5ZE_PT7_4KLE1E6DEulvQOceaFks5shUWfgaJpZM4PTPKf> .

-- *THOMAS BOUTELL, *SUPPORT LEAD P'UNK AVENUE | (215) 755-1330 | punkave.com

[ELadner]

Well, if htmlparser2 is being more lenient than the HTML5 spec (and I agree with your assessment of the spec that 8.2.4.8 says any character other than ! or / should dump the parser back in character mode), removing that leniency would be moving the parser back to less tolerance and less flexibility, no? (i.e. stricter adherence to the spec = less flexibility and tolerance for the parser).

I guess it depends on which side you're looking at the issue from, though.

[boutell]

The spec I referred to is describing how to be lenient. Anyway, semantic argument.

…

On Mon, Sep 11, 2017 at 3:41 PM, ELadner ***@***.***> wrote: Well, if htmlparser2 is being more lenient than the HTML5 spec (and I agree with your assessment of the spec that 8.2.4.8 says any character other than ! or / should dump the parser back in character mode), removing that leniency would be moving the parser back to less tolerance and less flexibility, no? (i.e. stricter adherence to the spec = less flexibility and tolerance for the parser). I guess it depends on which side you're looking at the issue from, though. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#220 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB9fVb9s8bDK7D3TcKpsRVLzZN2Rq-eks5shYzXgaJpZM4PTPKf> .

-- *THOMAS BOUTELL, *SUPPORT LEAD P'UNK AVENUE | (215) 755-1330 | punkave.com

[fb55]

Please refer to inikulin/parse5 if you need a spec-compliant parser.