Repository navigation
Conversation
sirreal
force-pushed
the
css-token-style-attr-processor
branch
from
July 23, 2026 10:33
1318192 to
b458f80
Compare
3 tasks done
sirreal
force-pushed
the
css-token-style-attr-processor
branch
from
August 26, 2026 09:57
1d1fe7a to
202991d
Compare
sirreal
changed the base branch from
trunk
to
css-api/css-token-processor-foundations
August 26, 2026 09:57
sirreal
force-pushed
the
css-token-style-attr-processor
branch
2 times, most recently
from
August 26, 2026 10:48
62b1cbd to
0f7d282
Compare
sirreal
force-pushed
the
css-token-style-attr-processor
branch
from
September 25, 2026 07:07
e560ec9 to
71b865f
Compare
sirreal
force-pushed
the
css-api/css-token-processor-foundations
branch
from
September 25, 2026 07:07
2ed7203 to
7711c31
Compare
sirreal
force-pushed
the
css-api/css-token-processor-foundations
branch
from
October 9, 2026 08:13
7711c31 to
a9d4b5d
Compare
sirreal
force-pushed
the
css-token-style-attr-processor
branch
2 times, most recently
from
October 12, 2026 09:54
b0640e6 to
8c9719a
Compare
set_value() and append_declaration() trimmed CSS whitespace bytes from the end of the value. When the last token is an escape of a space or tab, or a backslash delimiter followed by a newline, the trim removed the byte that completed it, so the `;` written after the value became part of an escape: append_declaration( '--x', "a\\ " ) wrote `--x: a\;`, whose value is the ident `a;`. set_value() rejected the same values because its replacement check saw the declaration absorb the next one. Trim only whitespace tokens, and keep one newline after a final backslash delimiter.
The processor kept an array per token with the type, the decoded value and unit, and the offsets, and get_value_tokens() returned those arrays. It now stores the WP_CSS_Token snapshots from WP_CSS_Token_Processor::get_token() and returns them, so values are decoded when read rather than for every token during parsing, and consumers read the flag and termination that the arrays did not carry. Declarations stay private arrays, and the processor uses the token processor rather than extending it.
get_eof_repair() decided whether a comment or url token at the end of the style was closed by reading bytes: a comment counted as closed when the style ended in `*/`, and a url token was re-tokenized with a sentinel appended. WP_CSS_Token::is_terminated() records the answer, so use it and delete is_url_token_closed(). The byte check counted `/*/` as a closed comment. Appending after it still failed, because the parse check rejects a declaration absorbed by the comment; the new test pins that result, which is the same before and after this change.
Code that reads a declaration and needs to write it back, such as a filter that keeps some declarations and drops others, had no public way to do so: WP_CSS_Token_Serializer is internal, and the processor wrote text only through mutations. serialize_declaration() returns the declaration at the cursor as `name: value;` or `name: value !important;`, as CSSOM writes a declaration, or null when the cursor is not on a declaration, like the other getters. The name is escaped as an identifier and the value is written by WP_CSS_Token_Serializer, so comments are dropped, whitespace runs become one space, and blocks left open at the end of the style are closed. The name follows WP_HTML_Processor::serialize_token(). The private formatter it shares with set_value() and append_declaration() is renamed format_declaration().
Every successful mutation parses the whole style text again, so removing declarations one at a time takes time that grows with the square of the style's length. Measured on this branch, removing every declaration of a style takes 12, 189 and 744 ms for 50, 200 and 400 declarations, while reading them all and joining serialize_declaration() takes 0.3, 1.2 and 2.4 ms. Say so on remove_declaration() and in the spec, and point to the alternative.
set_value() and append_declaration() checked that a supplied value parses as one declaration value, then wrote the caller's bytes: comments, whitespace runs, raw control characters inside strings and any escape spelling reached the style. They now write the declaration as serialize_declaration() does: the name is escaped as an identifier and the value is written by WP_CSS_Token_Serializer from its tokens, with the whitespace and comments around it removed. set_value() writes the decoded name, so `c\6f lor` becomes `color`. trim_value() and the raw_name field have no other use and are removed.
CSS closes a string or a comment that the end of the input cuts off, and so does WP_CSS_Token_Serializer::serialize(), but get_eof_repair() closed only blocks and urls: append_declaration() and set_important() returned false after `font-family: "a` or `color: red /* x`. The repair now writes the string's own quote or `*/` before the block closers. A `\` at the end of the style still makes the append fail, because no appended text can end the escape it starts.
sirreal
force-pushed
the
css-token-style-attr-processor
branch
from
October 14, 2026 06:51
8c9719a to
755bff5
Compare
…-style-attr-processor
…-style-attr-processor
The style attribute processor is not in 7.2.0.
Box drawing shows which bytes each offset of a parsed declaration spans, and which tokens get_value_tokens() returns.
remove_declaration() once removed a declaration from leading_start to trailing_end, taking the comments around it. Since "Preserve comments when removing style declarations" it removes the declaration and the whitespace next to it, and nothing reads either offset. The spec does not name them. With them go get_trailing_ignored_end(), the byte offset tracked before each declaration, and the byte offset that consume_at_rule() and consume_simple_block() returned only to compute leading_start; both now return the token index.
…-style-attr-processor
Comment tokens now have the text between their delimiters as their value.
…-style-attr-processor
…-style-attr-processor # Conflicts: # src/wp-settings.php
WP_CSS_Token_Processor::get_token_value() was removed; get_token()->get_value() returns the same value.
remove_declaration() removes the current declaration. set_value( '' ) was a second way to do it, and made an empty value mean something in set_value() that it means nowhere else: append_declaration() rejects it, as does set_value() for a value that is only whitespace.
…-style-attr-processor
create() no longer returns null, so the four checks could never be true.
…-style-attr-processor
utf8_ord() returns an int, and _wp_scan_utf8() has already confirmed that the bytes are one valid code point.
…-style-attr-processor
Replace the private constructor and the static create() method with a public constructor, as WP_CSS_Token_Processor now has. The parameter stays untyped so that PHP 7.4 can accept `true` and `null`. WP_HTML_Tag_Processor::get_attribute() returns `true` for a boolean style attribute and `null` for a missing one. The constructor reads both as an empty style, so its result can be passed in directly. Any other type that is not a string throws a TypeError, as create() did.
A successful mutation parsed the whole style twice, on the same text.
The verification step built the edited text, parsed it as a candidate
processor and checked the candidate's declarations. Then
apply_lexical_updates() rebuilt that text from the update queue and
parsed it again.
The verification methods now return the parsed candidate, or null where
they returned false, and the mutators take its style text, tokens and
declarations. The checks are unchanged, and so is the cursor handling.
Every mutator queued one update and applied it before returning, so the
queue never held more than one update: queue_lexical_update() always
found it empty, and has_queued_append_at() always returned false. The
test suite passed with assertions for both, and with an assertion that
the sorted and merged output equals the single replacement. With the
candidate's text as the updated style, the queue, its sort and merge,
and the separator check that read it are removed. get_updated_style()
returns the current text.
Timings in µs per call, before and after. PHP 8.5.12 CLI, opcache and
JIT off. N declarations of five kinds, 36 bytes each; 10 calls per run
(remove_declaration() at N=5: 5 calls, removing all); median of runs
within 1 s, one process per variant; median of 3 interleaved rounds.
N=5 N=20 N=100
set_value() 124 -> 74 395 -> 212 1787 -> 916
set_important() 111 -> 55 383 -> 191 1789 -> 889
remove_declaration() 42 -> 21 264 -> 132 1670 -> 831
append_declaration() 180 -> 105 476 -> 263 1989 -> 1103
The before and after runs produce the same output for every case.
The processor has no method that sets a property. The class docblock now shows how: remove the property's declarations in one named next_declaration() loop, then append the new declaration. It covers setting several properties in one unnamed pass, since the cursor moves forward only, and how the appended declaration's position interacts with shorthands in the cascade. A test confirms that remove_declaration() in a named loop removes every matching declaration, including ones that follow a removed one. The example outputs were checked by running the examples as written.
…-style-attr-processor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Depends on #92.
Adds
WP_HTML_Style_Attribute_Processor, a forward-only processor for safely inspecting and mutating decoded CSS declaration lists from HTMLstyleattributes.This PR is stacked on the CSS token processor foundations in #92. That dependency provides
WP_CSS_Token_Processor,WP_CSS_Builder, their test corpus, and focused unit tests. The reviewable change introduced here is the style-attribute processor, its specification, WordPress loading, and its tests. It does not include the earlier selector orselect()API explorations.Summary
set_value(),set_important(),remove_declaration(), andappend_declaration().false.docs/wp-html-style-attribute-processor-spec.md.API and scope
The processor accepts decoded style-attribute text, not raw HTML attribute syntax:
The initial API intentionally does not expose raw declaration values, bookmarks, cascade resolution, or property-specific browser grammar validation. It validates CSS declaration structure and safe placement rather than whether a particular property accepts a particular value.
Validation
Run on the combined branch based on current
upstream/trunk:WP_TESTS_SKIP_INSTALL=1 vendor/bin/phpunit tests/phpunit/tests/css-api/wpCssBuilder.php— 46 tests, 200 assertionsWP_TESTS_SKIP_INSTALL=1 vendor/bin/phpunit tests/phpunit/tests/css-api/wpCssTokenProcessor.php— 266 tests, 385 assertionsWP_TESTS_SKIP_INSTALL=1 vendor/bin/phpunit tests/phpunit/tests/html-api/wpHtmlStyleAttributeProcessor.php— 56 tests, 268 assertionsvendor/bin/phpcs --standard=phpcs.xml.diston the six affected PHP source and test filesgit diff --checkTrac ticket: https://core.trac.wordpress.org/ticket/62653
Use of AI Tools
AI assistance: Yes
Tool(s): ChatGPT/Codex
Model(s): GPT-5
Used for: extracting the CSS foundations into the dependent PR, refining the specification and implementation, adding tests, adversarial review, and updating this PR description.
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.