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
At first sight, this does not seem like a blocking problem because most times these templates will be inside <script> tags, and other solutions could be possible (like ignoring <script> contents or using a CDATA block). But anyway, it would be nice if attoparser could detect such unknown structures and just ignore them as a sort of "unknown inner block", passed as-is to the event system.
For example, the following blocks could be ignored:
{...}, for any number of consecutive {'s.
[...], for any number of consecutive ['s.
(...), for any number of consecutive ('s.
<...>, for any number of consecutive <'s.
The text was updated successfully, but these errors were encountered:
Reference: thymeleaf/thymeleaf#261
It seems some client-side technologies like ember.js can include macros inside tags themselves (see http://emberjs.com/guides/templates/binding-element-attributes/ ) which would result in a parsing error.
At first sight, this does not seem like a blocking problem because most times these templates will be inside
<script>
tags, and other solutions could be possible (like ignoring<script>
contents or using aCDATA
block). But anyway, it would be nice if attoparser could detect such unknown structures and just ignore them as a sort of "unknown inner block", passed as-is to the event system.For example, the following blocks could be ignored:
{...}
, for any number of consecutive{
's.[...]
, for any number of consecutive[
's.(...)
, for any number of consecutive(
's.<...>
, for any number of consecutive<
's.The text was updated successfully, but these errors were encountered: