[wp-trac] [WordPress Trac] #50867: An API which encourages automatic escaping of HTML

[WordPress Trac]

#50867: An API which encourages automatic escaping of HTML
-------------------------------------------------+-------------------------
 Reporter:  noisysocks                           |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-unit-tests needs-    |     Focuses:
  docs dev-feedback 2nd-opinion                  |
-------------------------------------------------+-------------------------

Comment (by dmsnell):

 Expanding on what @zieladam wrote, I tossed together another version of
 this before I realized this Ticket exists.

 https://github.com/WordPress/wordpress-develop/pull/4065

 That relies on the new Tag Processor to create the HTML, which at first
 seems a bit heavy-handed, but then maybe isn't so bad because it's working
 on tiny little strings and shares the rules of the HTML engine powering
 the new HTML API.

 There's a lot of room for an HTML-creator in the new HTML API. There's no
 concession for CSS classes in my PR apart from the possibility of
 exporting the embedded Tag Processor directly, which opens up `add_class`
 and `remove_class`. That's one of the simpler utilities to tack on though,
 obviously since it's a small function. Conditional attributes are
 supported by nature since a boolean attribute's `false` value translate
 into omitting that attribute from the HTML entirely.

 From what I could tell, even where it's difficult to grasp what's
 happening in a builder call, it's also quite difficult to grasp in the
 existing calls. Worse, it's hard to see if there are obvious defects
 because of the mix of PHP and HTML syntax.

 {{{#!php
 <<?php echo $safe_type; ?> controls="controls" preload="none" width="<?php
 echo (int) $theme_width; ?>"
         <?php
         if ( 'video' === $safe_type ) {
                 echo ' height="', (int) $theme_height, '"';
         }
         ?>
 ></<?php echo $safe_type; ?>>
 }}}

 {{{#!php
 <?php echo WP_HTML::make_tag(
         $safe_type,
         array(
                 'controls' => true,
                 'preload'  => 'none',
                 'width'    => (int) $theme_width,
                 'height'   => 'video' === $safe_type ? (int) $theme_height
 : false
         )
 );
 }}}

 > For example, throwing a _doing_it_wrong when an img doesn't contain an
 alt attribute.

 👍 surely these rules will frustrate developers, but it's sound
 technically.

 ---

 the HTML API focuses on strings, despite introducing new classes into WP.
 the string-nature limits memory bloat. this is why I've proposed accepting
 the `children` parameter as a string.

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