[wp-trac] [WordPress Trac] #63020: HTML API: Breadcrumbs should include element indices and attributes

[WordPress Trac]

#63020: HTML API: Breadcrumbs should include element indices and attributes
-------------------------------------------------+-------------------------
 Reporter:  westonruter                          |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  HTML API                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-feedback has-test-     |     Focuses:
  info has-unit-tests                            |
-------------------------------------------------+-------------------------

Comment (by dmsnell):

 > My question is: Does this approach—a dedicated subclass with lazy, on-
 demand decoding and explicit opt-in controls—align with the performance
 profile and architecture you had in mind for handling this use case?
 >
 > If this sounds correct, I will post the patch for this subclass
 implementation soon.

 @ibrahimhajjaj yes it does, very much, inside the Optimization Detective
 plugin. I've yet to see something that suggests it should be baked in as
 part of Core. to get there, I think it would be good to see concrete
 motivation for it: a number of different plugins doing this same thing in
 this same way, where the implementation is full of easy-to-miss steps.

 it seems like the motivating use case is a fairly degenerate form of XPath
 which is a kind of custom tracker for a specific element rather than
 something that represents normative XPath usage. that’s fine again, in a
 plugin, but if that’s the feature leading this design I would love to see
 more evidence of universal need for that.

 now if there’s anything in the HTML API that makes building this custom
 subclass difficult I want to see if we can’t align those better.

 > suggest that…there be a way to get more information from the open stack
 of tags, including the attributes for each tag and the node index for
 each.

 this is something that seems might be best done by tracking the bookmarks,
 which are technically already internally stored, and re-parsing as
 necessary. on the one hand, plugin code can already easily track the
 attributes for the open elements. the code @westonruter shared as
 something he would want to be able to write should be trivial to add to a
 subclass which does nothing more than wraps `next_token()`.

 {{{#!php
 <?php
 public $open_stack = array();
 public $element_indices = array( 0 );

 public function next_token() {
         if ( ! $this->expects_closer() ) {
                 array_pop( $this->open_stack );
                 array_pop( $this->element_indices );
         }

         if ( ! parent::next_token() ) {
                 return false;
         }

         if ( $this->is_tag_closer() ) {
                 array_pop( $this->open_stack );
                 array_pop( $this->element_indices );
         } else {
                 $element_index = ++$this->element_indices[ count(
 $this->element_indices ) - 1 ];
                 $this->open_stack[] = array(
                         'token_name' => $this->get_token_name(),
                         'id' => $this->get_attribute( 'id' ),
                         'role' => $this->get_attribute( 'role' ),
                         'class' => $this->get_attribute( 'class' ),
                         'elementIndex' => $element_index,
                 );
         }

         return true;
 }
 }}}

 this glosses over some of the details, but I think it provides what your
 patch provides, though with less code and in a way that shouldn’t need to
 be maintained in harmony with the rest of the HTML Processor. this is
 using //only// public methods. it also doesn’t force Core to make a
 decision for everyone on which attributes for any given element are
 essential or not (for example, this code and the proposed patch do not
 indicate if a given element is a `last-child`, something I would think
 some code might want, and another thing I would be skeptical of adding for
 all people in all situations).

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