[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:  6.9
Component:  HTML API                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-feedback has-test-     |     Focuses:
  info has-unit-tests                            |
-------------------------------------------------+-------------------------

Comment (by ibrahimhajjaj):

 Hi @dmsnell,

 Thank you for the detailed feedback. I completely agree with the
 philosophy of keeping the core processor lean and using subclasses for
 specialized needs...To make sure I'm on the right track before posting a
 new patch, I wanted to run the proposed solution by you.

 Based on your comments, I've moved the functionality into a new
 WP_HTML_Breadcrumbs_Processor subclass. The core WP_HTML_Processor class
 would remain completely untouched.

 The key features of this subclass would be:

 Strictly Opt-In: All features (index tracking, attribute tracking) are
 disabled by default via methods like enable_index_tracking(true).

 Lazy Attribute Decoding: It avoids the eager cost you mentioned. Instead
 of decoding and storing all attributes for every element, it only decodes
 the specific allow-listed attributes (id, role, class) on-demand, when
 get_element_breadcrumbs() is called.

 On-Demand Index Calculation: Indices are calculated by counting siblings
 at the required level when needed, not stored during parsing.

 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.

 Thank you again...

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