[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 dmsnell):

 @ibrahimhajjaj thank you for posting that patch and for documenting the
 functions and providing tests.

 first of all, this patch and functionality seems very fitting for the
 Optimization Detective. I’m glad that the HTML Processor is able to
 provide the information it wants to generate its XPath queries.

 this particular feature request, however, introduces a break from the
 performance characteristics so-far built into the system (well, at least
 as much as is possible). that is, the HTML API generally makes you aware
 of any performance impact you request. it avoids doing extra work up-front
 and for everyone in case someone needs the information. but if we decode,
 allocate, and store every attribute for every element during a parse, I’m
 worried about penalizing every use case for the very specific use case
 presented here.

 storing attributes carries two costs: they are text-decoded so that
 calling-code doesn’t have to determine if and how it should be decoded and
 this carries a runtime cost usually skipped-over unless it’s needed; they
 can be very large and lead to memory bloat, increasing the cost of a page
 and sometimes getting close to doubling the memory requirements.

 given that I work frequently with sub-classes, and given that the HTML API
 was designed to be subclassed, I’d like to understand better why sub-
 classing is not working, especially for a plugin as staffed and maintained
 as the Optimization Detective. we should not see sub-classes as failures
 or inherent things to eradicate.

 please see my previous comment as well, which this is mostly a rewording
 of. proposing a patch is the easy part, but fitting in the needs of one
 very-specific use-case into a system meant to be a low-level mechanism for
 building HTML processors is much more difficult.

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