You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
HTML tokenization does not handle CR correctly #5618
After upgrading from alpha46 to alpha47, there seems to be some extra spacing added when projecting elements via ng-content or using anything <template> related (ng-if, ng-switch, ng-for).
"CR" (U+000D) characters and "LF" (U+000A) characters are treated specially. All CR characters must be converted to LF characters, and any LF characters that immediately follow a CR character must be ignored. Thus, newlines in HTML DOMs are represented by LF characters, and there are never any CR characters in the input to the tokenization stage.
(related: LF has a special handling after textarea, pre & listing).
I have updated the title of the issue to better reflect what the bug is (the one described in my previous message).
It should not be too hard to solve but it's not too easy either (as we want to preserve the source location while parsing the html - ie it is not a simple as a "find & replace").
@vicb I've created bundles from your branch and replaces the ones in my code. It seems to fix the issue. Thanks!
The ng-content text node ("HQ alerts: no alerts, everything normal.") is aligned with the header above, and the space between template instances is also gone.
Activity
vicb commentedon Dec 5, 2015
Probably linked to the content of the text node ("HQ alerts: no alerts, everything normal.")
On alpha 47 it is (char codes): 13-10-32-32-72-81
On alpha 46 it is: 10-32-32-72-81-...
Notice the extra CR on alpha 47.
Probably related to the new parser. I'll have to investigate more next week.
/cc @tbosch
vicb commentedon Dec 5, 2015
The clue might be http://www.w3.org/TR/html5/syntax.html#preprocessing-the-input-stream
"CR" (U+000D) characters and "LF" (U+000A) characters are treated specially. All CR characters must be converted to LF characters, and any LF characters that immediately follow a CR character must be ignored. Thus, newlines in HTML DOMs are represented by LF characters, and there are never any CR characters in the input to the tokenization stage.
(related: LF has a special handling after
textarea, pre & listing).[-]template/ng-content adding extra spacing in alpha47[/-][+]HTML tokenization does not handle CR correctly[/+]vicb commentedon Dec 5, 2015
I have updated the title of the issue to better reflect what the bug is (the one described in my previous message).
It should not be too hard to solve but it's not too easy either (as we want to preserve the source location while parsing the html - ie it is not a simple as a "find & replace").
vicb commentedon Dec 5, 2015
Actually I think we can convert CRLF to CR then CR to LF and preserving source position should not be a problem. I'll try to PR soon.
filipesilva commentedon Dec 5, 2015
@vicb I've created bundles from your branch and replaces the ones in my code. It seems to fix the issue. Thanks!
The
ng-contenttext node ("HQ alerts: no alerts, everything normal.") is aligned with the header above, and the space between template instances is also gone.vicb commentedon Dec 7, 2015
Great, thank you so much for having tested !
filipesilva commentedon Dec 7, 2015
Thank you for fixing it :p
angular-automatic-lock-bot commentedon Sep 7, 2019
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.