chromium/third_party/blink/renderer/core/css/invalidation/rule_invalidation_data_visitor.h

// 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_