Does this look like a reasonable approach?
We could consider generate the "fast-path" keyword parser as well.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Does this look like a reasonable approach?
We could consider generate the "fast-path" keyword parser as well.
We probably should generate that, yeah. If we do, it would be great if certain keywords would be allowed only given a certain runtime flag.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
1 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the submitted one.
Enforce fast-path parsing for CSS "keyword" properties
Some simple keyword properties had a custom ParseSingleValue(). Make
sure that new properties use
CSSParserFastPaths::IsValidKeywordPropertyAndValue() instead of a custom
ParseSingleValue().
Provide a keyword_custom for the cases where we use the keyword template
but need custom parsing implementation.
Currently:
- The cursor property also parses and stores a set of urls and a hotspot
in the computed_style_extra_flags. Should probably not have been a
"keyword" in the first place.
- The ruby-position property does some use counting for currently
unsupported keywords.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |