Right now we go through a lot of hoops to see if we ever see a relevant link. However, that information is not needed: if the element is a link, we'll always need to compute its visited style because its its own relevant link. If the element inherits from a link, we need to also compute the visited style anyway. So the "has a relevant link been found" is pretty useless when we know what are we inheriting from. The branches at the beginning of matches_complex_selector_internal were affecting performance, and there are no good reasons to keep them. I've verified that this passes all the visited tests in mozilla central, and that the test-cases too-flaky to be landed still pass. |
||
---|---|---|
.. | ||
attr.rs | ||
bloom.rs | ||
build.rs | ||
builder.rs | ||
Cargo.toml | ||
context.rs | ||
gecko_like_types.rs | ||
lib.rs | ||
matching.rs | ||
nth_index_cache.rs | ||
parser.rs | ||
README.md | ||
sink.rs | ||
size_of_tests.rs | ||
tree.rs | ||
visitor.rs |
rust-selectors
CSS Selectors library for Rust. Includes parsing and serilization of selectors, as well as matching against a generic tree of elements. Pseudo-elements and most pseudo-classes are generic as well.
Warning: breaking changes are made to this library fairly frequently (13 times in 2016, for example). However you can use this crate without updating it that often, old versions stay available on crates.io and Cargo will only automatically update to versions that are numbered as compatible.
To see how to use this library with your own tree representation,
see Kuchiki’s src/select.rs
.
(Note however that Kuchiki is not always up to date with the latest rust-selectors version,
so that code may need to be tweaked.)
If you don’t already have a tree data structure,
consider using Kuchiki itself.