HTML API: Plans for 6.8 #63037
Labels
[Feature] HTML API
An API for updating HTML attributes in markup
[Type] Iteration
Scoped iteration of an effort from a tracking issue or overview issue ideally for a major release.
🔝Block API | HTML issues | Refactors | ↑ Broader Roadmap | ← Plans for 6.7
Potential HTML rule changes.
<select>
parser whatwg/html#10557Lingering work from 6.7
Speed speed speed. Make the HTML Processor 10x faster.
if
statements that don't execute anything (they have a comment as their body).case
statements in each insertion mode. Test against 100s of 1000s of websites based on web popularity.'#text' === $token_type
with::STATE_TEXT_NODE === $this->parser_state
step()
where all nodes are real. Reference these values instead of calling->get_token_name()
etc…after_element_push()
since these are all instigated from within the HTML Processor, unlike pop withpop_until()
(unless we madepop_until()
return a generator and we couldforeach ( $state->pop_until( 'TAG' ) as $popped )
if
checks with flags that are set on events, as is done withhas_p_in_button_scope
.next_token()
if a text node is only whitespace.Following the change to push/pop, immediately pop elements off of the stack of elements as instructed in the parsing rules, vs. letting
step()
perform the check and pop.With some initial explorations I've found 16% - 40% speed improvement with some of these ideas. That's not good enough, but it's a start.
Lingering support edge-cases.
seek()
calls in the HTML Processor to ensure reliability. (Core-????)May be covered by HTML API: Ensure that full processor can seek to earlier bookmarks.
New Features and Interfaces
set_inner_html()
to HTML Processor wordpress-develop#7326Blocks
The text was updated successfully, but these errors were encountered: