[wp-trac] [WordPress Trac] #60229: HTML API: Introduce HTML Templating

[WordPress Trac]

#60229: HTML API: Introduce HTML Templating
-------------------------------------------------+-------------------------
 Reporter:  dmsnell                              |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:
Component:  HTML API                             |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-dev-  |     Focuses:
  note dev-feedback                              |
-------------------------------------------------+-------------------------

Comment (by dmsnell):

 > whether you've given any thought to using an existing (and mature)
 syntax/implementation rather than creating something custom?

 Thanks for asking @alexsanford1! Yes absolutely. This is in part the end
 of the work discussed regarding
 [https://github.com/WordPress/gutenberg/discussions/39831 dynamic server-
 side tokens], a project that ultimately began years ago looking to find
 placeholder syntax, which in part has guided the development of the HTML
 API itself.

 As briefly [https://make.wordpress.org/core/2023/08/19/progress-report-
 html-api/ discussed in the HTML API Progress Report] and in the linked-
 PR's description, the choice of this syntax ultimately fell down to
 finding a safe syntax embedded within HTML itself. It's actually //this
 very syntax// which relies on one of the most mature syntaxes and
 implementations in any system (HTML) and in so doing, avoids the category
 of issues created when adding new syntax into HTML.

 This is both //new// syntax and also //nothing new//. It's new inside
 attribute values because there's no escape hatch there, but it's not new
 in any other place. This means that unlike every known templating syntax
 I've seen (outside of JSX), it's not possible to break HTML boundaries
 with the placeholders. I draw a strong contrast to using something like
 `{{{ }}}` which is a level of parsing above or below HTML. A superset
 syntax raises questions about how to handle the template syntax when it
 clashes with the HTML. By embracing the HTML syntax WordPress would never
 have to answer that question, because a misplaced placeholder is going to
 be interpreted in some other way, perhaps as an HTML attribute name, but
 won't break the document.

 This syntax places additional constraints that I personally consider
 beneficial. They cannot be used to for the tag name, cannot be used to
 concatenate HTML elements, and most importantly, cannot be nested at all
 (because as HTML syntax, they terminate at the first `>` following their
 opening. Should the server fail to replace these, a browser will interpret
 them as HTML comments, and the biggest leak will be the contents of the
 placeholder, the page at large being interpreted as if they never existed
 rather than breaking the HTML structure.

 All of this is to say that I believe this is the end of the search for a
 mature existing syntax and not the prompt for one. These avoid the
 security issues inherent in almost every templating syntax I've ever seen,
 and provide a context-aware auto-escaping feature that means developers
 don't have to worry about escaping, because the system does. It it likely,
 as you call out, this will mean they don't bring all of the features
 available in other templating systems, or get them as fast. Concerning the
 HTML API though reliability and trust are more important than speed and
 features.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60229#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform