// Copyright 2024 The Chromium Authors // Use of this source code is governed by a BSD-style license that can be // found in the LICENSE file. #ifndef THIRD_PARTY_BLINK_RENDERER_CORE_CSS_INVALIDATION_RULE_INVALIDATION_DATA_VISITOR_H_ #define THIRD_PARTY_BLINK_RENDERER_CORE_CSS_INVALIDATION_RULE_INVALIDATION_DATA_VISITOR_H_ #include "third_party/blink/renderer/core/css/invalidation/rule_invalidation_data.h" #include "third_party/blink/renderer/core/css/invalidation/selector_pre_match.h" namespace blink { class CSSSelector; class StyleScope; enum class RuleInvalidationDataVisitorType { … }; // This template is used in two different scenarios: // 1. Builder: Iterates over CSS selectors and constructs InvalidationSets and // related data based on their contents. See comments on class RuleFeatureSet // for a more detailed breakdown of how these work. // 2. Tracer: Follows the same logic as Builder while looking at previously // constructed RuleInvalidationData, without modifying it. The use case for // this is reconstructing the relationships between style rules and // invalidation data for developer tooling. // // The default assumption, and vast majority of usage, is the Builder scenario. // Method names reflect this assumption; they are held over from when this was // the only scenario. So in the Tracer scenario, 'Add' does not actually add // anything and 'Ensure' does not fill in a missing entry. Rather, they reflect // steps taken by the Builder that the Tracer is following in. template <RuleInvalidationDataVisitorType VisitorType> class RuleInvalidationDataVisitor { … }; } // namespace blink #endif // THIRD_PARTY_BLINK_RENDERER_CORE_CSS_INVALIDATION_RULE_INVALIDATION_DATA_VISITOR_H_