Recent "special tokens not allowed inside html tags" change breaks existing templates
sgammon opened this issue · comments
Hey there esteemed closure templates authors,
A recent change on this line:
Throws an error for any case involving a "special token" inside an HTML tag. however, that eliminates previously-valid syntax and that change is preventing us from upgrading our Closure Templates compiler.
there is a valid use case for spaces within HTML tags, for instance, declaring a space explicitly to separate conditional attributes:
{template .script}
{@param script: trusted_resource_uri} /** JavaScript asset that we wish to create a link for. */
{@param? id: string} /** Optional ID at which to attach the script in the DOM. */
{@param? module: bool} /** Whether this should be a module or not. */
{@param? nomodule: bool} /** whether this should be a `nomodule`-flagged script or not. */
{@param? async: bool} /** Whether we should add the async flag. */
{@param? defer: bool} /** Whether we should add the defer flag. */
{@param? integrity: string} /** Integrity fingerprint to apply. */
{@param? crossorigin: string} /** Cross-origin value to use. */
<script type="text/javascript"
src="{$script}"
{if isNonnull($id)}{sp}id="{$id}" {/if}
{if isNonnull($module) and $module}
{sp}module
{else}
{if isNonnull($nomodule) and $nomodule}{sp}nomodule{/if}
{/if}
{if isNonnull($async) and $async}{sp}async{/if}
{if isNonnull($defer) and $defer}{sp}defer{/if}
{if isNonnull($integrity)}{sp}integrity="{$integrity}"{/if}
{if isNonnull($crossorigin)}crossorigin="{$crossorigin}"{/if}></script>
{/template}
arguably this can be accomplished for new code with type=attributes
, but this breaks old code in a significant way, and changes the syntax rules of the language. is this a deliberate change, that we cannot come back from, such that we must update old (but previously valid) Soy code to adopt new compiler versions?
cc: @emspishak / @iteriani
A few more details:
The command characters, like {sp}
, are meant for printing text, so within an html tag they don’t really make sense.
In most cases, it looks like you're adding an {sp}
at the beginning or end of a line, but the soy html parser handles newlines between attributes and tag names as a separator, and already parses this correctly. In cases like this, you can just delete the {sp}
.
Does this make sense?
@emspishak @iteriani thank you for the quick response here. yes, that makes sense, but we occasionally get double-spaces in the output between attributes. would that, then, be considered a bug on its own, alleviating the need to use {sp}
for manual control? that's the goal of the above code's use of those symbols
hey all-
just wanted to follow up that i believe this to be fixed, and we've repaired our code to remove the offending {sp}
. thank you for your help!
Really sorry about this. We'll be releasing a formatter/code fixer for similar issues soon!