Element processing method, display method and device for structured document

Abstract

This specification provides an embodiment of a method, display method, and apparatus for element processing in a structured document. The element processing method includes: in a first operating environment, in response to a user's annotation operation on a target element of the structured document, extracting semantic information from the target element's identifier attributes, business attributes, or class names of parent nodes at several levels; combining the semantic information into a selector string for locating the target element; using the selector string or a hash value obtained by hashing the selector string as the semantic coordinates of the target element; and associating and storing the semantic coordinates with the annotation information generated by the annotation operation, so that the target element in the structured document can be located in a second operating environment based on the semantic coordinates. This method can meet the requirements of accurate cross-operating environment positioning of specific elements and the requirements of automated processing.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of computer software development, and more particularly to methods, display methods and apparatus for element processing of structured documents. Background Technology

[0002] Currently, with the rise of low-code platforms and AIGC (Artificial Intelligence Generated Code), the way structured documents are constructed has undergone a fundamental change. In these scenarios, users often need to annotate specific elements (such as buttons, forms, product cards, chart components, etc.) in structured documents and bind the generated annotation information (such as comments, highlight marks, test status, configuration parameters, etc.) to specific elements, requiring that the annotation information and specific elements can be associated and displayed in different runtime environments (such as editing mode, preview mode, and sharing mode).

[0003] In existing technologies, several methods are commonly used to locate specific elements. One method relies on the element's static identifier; another is based on the element's physical path; yet another is based on the source code location; and still another is based on manually embedded attributes. These methods either fail to meet the requirement of accurate location of specific elements across different operating environments or fail to meet the requirements of automated processing.

[0004] For example, in architectures employing time-slicing and concurrent rendering, DOM nodes are not statically existing but dynamically generated by mapping from a virtual DOM tree. AI-generated code often lacks explicit, stable key properties, or its key-value pairs rely on random hashes generated at runtime. When a state update or re-render occurs, the scheduler interrupts the current rendering task based on priority and recalculates the subtree upon resumption. During this process, even if the UI visual appearance remains unchanged, the underlying DOM node instances may be completely destroyed and rebuilt, causing the original memory references to break completely. Traditional positioning methods based on source code line numbers or initial DOM paths are essentially bound to static text positions at compile time or the instantaneous topology of the first rendering; once the Fiber architecture triggers a change in the node reuse strategy during the asynchronous commit phase, or the AI ​​fine-tunes the component nesting level during secondary generation (e.g., inserting a meaningless wrapper div into the parent container), the original static index immediately becomes invalid, causing source code position confusion, and the system cannot establish a mapping between the new node instances at runtime and the stored old annotation anchors.

[0005] AI-generated code tends to use highly abstract, generic component libraries or style atomicity schemes, resulting in class names that are mostly meaningless hash strings (e.g., css-1a2b3c) or pure layout helper classes (e.g., flex, p-4). In traditional human development, developers typically inject IDs or classes with business semantics (e.g., submit-btn) as anchor points, constructing a rich semantic feature space. However, in AI-generated code scenarios, due to the lack of direct human intervention, this feature space collapses. All isomorphic elements (e.g., 100 product cards in a list) appear to the machine only as a combination of "tag name + random hash class name + relative index." When the list data is added, deleted, or sorted, the relative index shifts, and the random hash class name is refreshed with each build version. This makes it mathematically impossible for existing technology to construct a unique and stable invariant in this scenario, inevitably leading to positioning failure.

[0006] Therefore, there is a need to provide an improved solution that, through element processing of structured documents, meets the requirements for accurate positioning of specific elements across operating environments, as well as the requirements for automated processing. Summary of the Invention

[0007] This specification describes one or more embodiments of an element processing method, display method, and apparatus for structured documents, which can meet the requirements of accurate positioning of specific elements across operating environments and automated processing.

[0008] Firstly, a method for element processing in structured documents is provided, including:

[0009] In the first operating environment, in response to the user's annotation operation on the target element of the structured document, semantic information is extracted from the identifier attribute, business attribute or class name of the parent node at several levels of the target element;

[0010] Generate the semantic coordinates of the target element based on the semantic information;

[0011] The semantic coordinates are associated with and stored with the annotation information generated by the annotation operation, so that the target element in the structured document can be located based on the semantic coordinates in the second running environment.

[0012] In one possible implementation, extracting semantic information from the identifier attribute, business attribute, or class name of parent nodes at several levels of the target element includes:

[0013] Determine whether the target element has a valid identifier attribute; if the target element is determined to have a valid identifier attribute, extract semantic information from the identifier attribute;

[0014] If it is determined that the target element does not have a valid identifier attribute, then it is determined whether the target element has a business attribute; if it is determined that the target element has a business attribute, then semantic information is extracted from the business attribute.

[0015] If it is determined that the target element does not have business attributes, then traverse the parent nodes of the target element at several levels upwards to find the parent node with a semantic class name, and extract semantic information from the semantic class name.

[0016] Further, determining whether the target element has a valid identifier attribute includes:

[0017] Obtain the identifier attribute value of the target element;

[0018] If the value of the identification attribute is empty, it is determined that it does not have a valid identification attribute;

[0019] If the identification attribute value is not empty, then the preset regular expression matching rule is used to detect whether the identification attribute value conforms to the dynamic noise feature;

[0020] If the dynamic noise characteristics are met, it is determined that it does not have a valid identification attribute; the dynamic noise characteristics include: starting with a preset frame prefix, containing continuous random hash characters, or conforming to a timestamp generation format;

[0021] If it does not meet the dynamic noise characteristics, it is determined to have valid identification attributes.

[0022] Furthermore, the business attributes include custom attributes;

[0023] The extraction of semantic information from the business attributes includes:

[0024] Scan the target element for custom attributes with a preset prefix;

[0025] Extract semantic information from the attribute values ​​of the custom attribute.

[0026] Furthermore, the step of traversing upwards through several levels of parent nodes of the target element includes:

[0027] Starting from the target element, its parent nodes are obtained level by level until the preset maximum depth threshold is reached or the document root node is traversed.

[0028] During the traversal, record the list of class names of the parent nodes at each level and the position index of the child elements.

[0029] Furthermore, the step of finding the parent node with a semantic class name includes:

[0030] Perform noise cleaning on the class name list of each level of parent node in the record, remove hash class names, random prefix class names and layout auxiliary class names without semantics, retain business class names with natural language semantics, and use the node corresponding to the business class name as a candidate anchor point.

[0031] If a candidate anchor point exists in a certain level of parent node, then the candidate anchor point is determined as the parent node with a semantic class name.

[0032] Further, the extraction of semantic information from the semantic class name includes:

[0033] Construct a path segment from the parent node with the semantic class name through intermediate nodes to the target element; wherein, if the intermediate node in the path segment does not have a valid class name, the intermediate node is used to complete the path segment by using the index of the child element position in the list of child nodes of its parent node.

[0034] Furthermore, before determining whether the target element has a valid identifier attribute, the method further includes:

[0035] In the first operating environment, the set of elements in the same group as the target element is analyzed, and its sequence position in the set is calculated.

[0036] By combining the source code location and sequence location of the same set of elements, an instantiation enhancement identifier is generated;

[0037] The instantiation enhancement identifier is injected into the custom attribute of the target element.

[0038] Further, the analysis of the set of elements in the same group as the target element includes:

[0039] Based on the loop iteration metadata injected into the target element during compilation, query the set of elements in the same group as the target element.

[0040] In one possible implementation, the first runtime environment is an editing environment, and the second runtime environment is a preview environment or a sharing environment.

[0041] Secondly, it provides a method for displaying structured documents, including:

[0042] In the second operating environment, when loading the annotation information of the structured document, the semantic coordinates of the target elements associated with the annotation information are read; the semantic coordinates are associated with and stored as described in the first aspect.

[0043] The semantic coordinates are used to match the elements of the structured document.

[0044] If the target element is matched, the target element and the annotation information will be displayed together.

[0045] Thirdly, a device for element processing in structured documents is provided, comprising:

[0046] The extraction unit is used in the first operating environment to extract semantic information from the identifier attributes, business attributes or class names of parent nodes at several levels of the target element in response to the user's annotation operation on the target element of the structured document in the first operating environment.

[0047] A generation unit is used to generate the semantic coordinates of the target element based on the semantic information extracted by the extraction unit;

[0048] A storage unit is used to associate and store the semantic coordinates obtained by the generation unit with the annotation information generated by the annotation operation, so as to locate the target element in the structured document according to the semantic coordinates in the second running environment.

[0049] Fourthly, a display device for structured documents is provided, including:

[0050] The reading unit is used to read the semantic coordinates of target elements associated with the annotation information when loading the annotation information of a structured document in a second operating environment; the semantic coordinates are associated with the device as described in the third aspect.

[0051] A matching unit is used to match each element of the structured document using the semantic coordinates;

[0052] The display unit is used to associate and display the target element and the annotation information if the matching unit matches the target element.

[0053] Fifthly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of the first or second aspect.

[0054] In a sixth aspect, a computing device is provided, including a memory and a processor, wherein executable code is stored in the memory, and when the processor executes the executable code, it implements the method of the first aspect or the second aspect.

[0055] The element processing method and apparatus for structured documents provided in the embodiments of this specification construct a multi-level semantic decision-making mechanism, which can intelligently identify and extract stable features of target elements in different rendering states, such as effective identifiers, business attributes, or denoised semantic class names, thereby generating semantic coordinates with high robustness and anti-interference capabilities. By associating and storing annotation information with semantic coordinates, a persistent association between annotation information and target elements is achieved, ensuring that the same target element can be automatically and accurately restored and locked without manual intervention in heterogeneous operating environments such as editing, previewing, and sharing states. This not only significantly improves the accuracy and consistency of locating specific elements across operating environments but also greatly reduces the cost of manual calibration in multi-scenario collaboration, meeting the requirements for accurate locating of specific elements across operating environments and the requirements for automated processing.

[0056] The method and apparatus for displaying structured documents provided in the embodiments of this specification reuse the highly robust semantic coordinates generated in the first aspect to build an automated positioning and rendering mechanism in the second operating environment. This mechanism can accurately identify and lock target elements. Without manual re-marking or manual calibration, the stored annotation information can be automatically and accurately anchored and associated with the target elements for display. This achieves a fully automated closed loop from data loading to view presentation, significantly improving the accuracy and consistency of positioning specific elements across operating environments. It also greatly reduces the cost of manual intervention in multi-scenario collaboration, meeting the requirements for accurate positioning of specific elements across operating environments and the requirements for automated processing. Attached Figure Description

[0057] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0058] Figure 1 This is a schematic diagram illustrating an implementation scenario of one embodiment disclosed in this specification;

[0059] Figure 2 A flowchart illustrating an element processing method for a structured document according to one embodiment is shown.

[0060] Figure 3 This diagram illustrates a method for cyclically instantiating index calculation according to one embodiment;

[0061] Figure 4 A flowchart illustrating a method for displaying structured documents according to one embodiment is shown;

[0062] Figure 5A flowchart of a multidimensional coordinate positioning method in a nested loop scenario is shown according to one embodiment;

[0063] Figure 6 A schematic block diagram of an element processing apparatus for a structured document according to one embodiment is shown;

[0064] Figure 7 A schematic block diagram of a display device for structured documents according to one embodiment is shown. Detailed Implementation

[0065] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0066] Figure 1 This is a schematic diagram illustrating an implementation scenario of one embodiment disclosed in this specification. This implementation scenario involves element processing and display of structured documents, specifically, the location of target elements and the display of the association between annotation information and target elements across runtime environments. A structured document is a data file written in a markup language (such as HTML, XML, SVG, etc.) with a strict hierarchical nesting relationship. Internally, it is parsed into a tree-like data structure, namely a Document Object Model (DOM) tree. Starting from the root node, the document forms a complete topological structure containing header information, body content, container nodes, and leaf nodes through nested parent-child relationships. Although its underlying structure is code text, after processing by a browser or rendering engine, it can be mapped to a user-visible graphical interface. In modern web development, structured documents are not static but dynamically modify their node attributes (such as ID, Class) or topological structure as users interact, data is loaded, or the framework re-renders.

[0067] Reference Figure 1 This demonstrates a visual interface for a structured document. A visual interface is the visual representation of a structured document rendered in a specific runtime environment (such as an editor, browser preview window, or mobile app). It consists of several visual UI components (such as buttons, input boxes, cards, and text paragraphs) arranged according to layout rules. Each visual component on the interface uniquely corresponds to one or more nodes in the structured document's DOM tree. For example, the "Log in Now" button 11 in Figure 1 corresponds to... <button>Tag Nodes. Visual interfaces typically consist of two logical layers: a basic content layer, comprised of elements natively defined in the structured document to implement business functions, such as button 11 in Figure 1; and a supplementary information layer, floating above the basic content layer, containing additional information for explanation, collaboration, or annotation, such as annotation information 12 in Figure 1. A target element is a specific UI component selected by the user in the visual interface as the focus of operation or attention. It is a specific node in the structured document's DOM tree. In Figure 1, the "Login Now" button 11 is a target element. This element has unique identifier attributes (such as id, class, or custom attributes data-*) or a specific path location in the DOM tree; it serves as the anchor connecting the user's visual perception with the underlying code data.

[0068] In dynamic environments, the identifier attributes of target elements may change unpredictably due to version iterations, code obfuscation, or random generation mechanisms (e.g., from id="btn_01" to id="v2_x9z"), making them difficult to track stably. Annotation information refers to a set of metadata created by the user for the target element, independent of the original structured document. This includes, but is not limited to, text comments (such as "Loading status needs to be added"), graphical markers (highlighting, selection), voice annotations, or status labels, as shown in annotation information 12 in Figure 1. Annotation information is not directly embedded in the HTML source code of the target element, meaning it does not modify...< / button> <button>Instead of storing the internal structure of the tags, the annotation information is stored as external data in a database or memory. In this embodiment, a logical mapping relationship is used to bind annotation information to target elements. Only when the corresponding target element is accurately located can the annotation information be correctly extracted and rendered in the appropriate position on the visualization interface.

[0069] Based on the above definition and the scenario shown in Figure 1, the following significant drawbacks typically exist when processing cross-environment collaboration of structured documents.

[0070] One drawback is the failure of target element location in dynamic environments. In modern front-end frameworks (such as React and Vue) and AI-generated code scenarios, structured documents are highly dynamic. As shown in Figure 1, the underlying identifier attributes (ID, Class) of target element 11 often change due to framework automatic compilation, hash obfuscation, or random generation mechanisms in edit, preview, and share states. For example, in edit state, id="A", but in share state, it becomes id="B". Traditional location methods rely on fixed IDs or paths. Once the underlying code undergoes even a slight change, the original location rules immediately become invalid, making it impossible to find the corresponding target element across environments.

[0071] Another drawback is the loss of synchronization caused by the decoupling of annotation information from the target element. Since annotation information 12 is independently stored external data, it must rely on a stable anchor point to be displayed in the correct location. When the target element 11 becomes unlocatable due to code refactoring, the annotation information 12, which was originally attached to it, loses its anchor point. This causes user feedback left in the editing state (such as modification comments and test annotations) to become misaligned, disappear, or incorrectly attached to other elements when switching to the preview or sharing state. This severely disrupts the consistency of cross-environment collaboration, forcing manual re-marking, which is extremely inefficient.

[0072] Another drawback is the lack of a noise-resistant semantic extraction mechanism. Typical solutions lack a mechanism capable of penetrating code noise (such as random hashes and ambiguous class names) and extracting core business semantics. Faced with AI-generated code lacking semantic identifiers, or compressed and obfuscated production-environment code, traditional solutions cannot construct an environment-independent semantic coordinate system. Therefore, they cannot meet the need for automated processing with precise localization.

[0073] In the embodiments described in this specification, a highly robust element location mechanism is constructed to address the dynamic changes in the identifier attributes of structured documents and the heterogeneity of code structures in different operating environments. This mechanism generates stable semantic coordinates, thereby enabling accurate, automatic, and persistent synchronous display of annotation information and target elements across different environments, eliminating the problem of data loss due to code changes.

[0074] Figure 2 This diagram illustrates a flowchart of an element processing method for a structured document according to one embodiment, which can be based on... Figure 1 The implementation scenario is shown. For example... Figure 2 As shown, the element processing method for structured documents in this embodiment includes the following steps: Step 21, in the first operating environment, in response to the user's annotation operation on the target element of the structured document, semantic information is extracted from the identifier attribute, business attribute, or class name of the parent node at several levels of the target element; Step 22, the semantic information is combined into a selector string for locating the target element, and the selector string or the hash value obtained by hashing the selector string is used as the semantic coordinates of the target element; Step 23, the semantic coordinates are associated with and stored with the annotation information generated by the annotation operation, so that the target element in the structured document can be located according to the semantic coordinates in the second operating environment. The specific execution method of each of the above steps is described below.

[0075] First, in step 21, within the first runtime environment, in response to user annotation operations on target elements of the structured document, semantic information is extracted from the target element's identifier attributes, business attributes, or class names of parent nodes at several levels. It can be understood that the first runtime environment can be any of the editing, preview, or sharing states. In the fields of software development, low-code platforms, and document collaboration, editing, preview, and sharing states represent three key stages in the lifecycle of structured documents (such as web pages and application interfaces).

[0076] The editing mode is the environment for creating and modifying structured documents. It typically refers to the canvas of an integrated development environment (IDE), a low-code platform, or the user interface of a visual design tool. Users (i.e., developers or designers) have the highest privileges and can directly modify page structure, style code, component properties, and business logic. They can access complete, uncompressed, and unobfuscated source code, including rich debugging information, original class names, and custom properties. Drag-and-drop components, real-time rendering, and hot updates are supported.

[0077] The preview state is an internal validation environment for structured documentation. It simulates the product's operation but is typically only accessible within the development team or a controlled network environment. Users usually cannot directly modify the underlying code structure, but can trigger the page's business logic (such as clicking buttons or submitting forms) to test functionality. The page code has usually undergone preliminary build processing and may include some optimizations, but retains a significant amount of debug mapping information for troubleshooting. Preview links are usually temporary and updated with code commits.

[0078] The shared environment is the final delivery environment for structured documents. This refers to the official version released to production servers, accessed via public links, or packaged and distributed to end users. Users are only permitted to perform business operations; any form of code modification or structural alteration is strictly prohibited.

[0079] In this embodiment of the specification, user interaction behavior can be monitored in the first operating environment. When the user selects a target element (such as the "Log in Now" button in Figure 1) on the visual interface and performs a specific annotation operation, step 21 is triggered. The annotation operation includes, but is not limited to, right-clicking and selecting "Add Comment", using annotation tools to circle or highlight elements, inputting text feedback, or binding test cases. This operation not only generates "annotated content" to be stored, but more importantly, it triggers an instruction to "extract semantic information" from the currently selected element.

[0080] In one example, extracting semantic information from the identifier attribute, business attribute, or class name of parent nodes at several levels of the target element includes:

[0081] Determine whether the target element has a valid identifier attribute; if the target element is determined to have a valid identifier attribute, extract semantic information from the identifier attribute;

[0082] If it is determined that the target element does not have a valid identifier attribute, then it is determined whether the target element has a business attribute; if it is determined that the target element has a business attribute, then semantic information is extracted from the business attribute.

[0083] If it is determined that the target element does not have business attributes, then traverse the parent nodes of the target element at several levels upwards to find the parent node with a semantic class name, and extract semantic information from the semantic class name.

[0084] This example successfully constructs a robust, adaptive, and non-intrusive element semantic information extraction solution through a progressive logic of "prioritizing explicit identifiers -> degrading to business attributes -> ultimately relying on parent node semantics." It completely solves the industry pain point of unstable element positioning in dynamic front-end environments and is a key technical means to achieve high-quality cross-environment annotation synchronization.

[0085] Further, determining whether the target element has a valid identifier attribute includes:

[0086] Obtain the identifier attribute value of the target element;

[0087] If the value of the identification attribute is empty, it is determined that it does not have a valid identification attribute;

[0088] If the identification attribute value is not empty, then the preset regular expression matching rule is used to detect whether the identification attribute value conforms to the dynamic noise feature;

[0089] If the dynamic noise characteristics are met, it is determined that it does not have a valid identification attribute; the dynamic noise characteristics include: starting with a preset frame prefix, containing continuous random hash characters, or conforming to a timestamp generation format;

[0090] If it does not meet the dynamic noise characteristics, it is determined to have valid identification attributes.

[0091] In this example, by introducing a dynamic noise filtering mechanism based on regular expression matching, the problem of location failure caused by random identifiers (such as hash values, timestamps, and framework prefixes) generated by modern front-end frameworks and automation tools is effectively solved. It can not only identify the presence or absence of identifier attributes, but also intelligently determine their business validity, actively eliminating noisy IDs that change with code compilation, refactoring, or re-rendering, ensuring that only identifiers with stable business semantics are extracted as anchor points. This ensures that the generated semantic coordinates have cross-version and cross-environment robustness from the source, avoids misalignment or loss of annotation information caused by minor changes in the underlying code, and significantly improves the accuracy of element location and the reliability of automated synchronization.

[0092] To accurately identify and eliminate dynamically generated noisy class names and IDs automatically generated by modern front-end frameworks (such as Vue and React), CSS modularization schemes (CSSModules, Styled Components), and build tools (Webpack, Vite), this specification's embodiments construct an extensible noise filtering regular expression library. The library's construction follows this logic: It collects typical random identifier samples generated by mainstream frameworks in different versions. For example, Vue's `data-v-xxxx`, React CSS Modules' `ComponentName_hash`, Emotion's `css-xxxx`, and UUID-formatted timestamp strings. The regular expression rules are divided into three levels: a prefix matching layer, targeting features with fixed random prefixes. For example, defining the rule `^(data-v-|__sc__|css-|el-)` to match common framework-injected prefixes; and a structural feature layer, targeting features containing consecutive hash characters of a specific length. For example, the rule `[a-zA-Z0-9]{8,}$` matches strings ending with a random alphanumeric combination of 8 or more characters, or `-[a-f0-9]{7}$` matches typical short hash suffixes. A semantic exclusion layer (whitelist mechanism) defines retention rules to ensure that natural language words with clear business meaning are not mistakenly excluded. For example, a minimum word length threshold can be set (e.g., length > 3 and containing vowels), or a common business vocabulary list can be maintained (e.g., btn, form, list, card, submit). If a string completely matches the whitelist or contains whitelist words, it is considered semantically valid and exempt from noise filtering.

[0093] The above multi-level regular expressions are merged into a single efficient large union regular expression (UnionRegex) and pre-compiled into a finite state machine during system initialization to achieve millisecond-level single-scan matching, thus avoiding performance bottlenecks when traversing a large number of DOM nodes.

[0094] Using this regular expression library, the system can automatically extract the css-1a2b3c from login-form_css-1a2b3c at the moment of extracting the class name or ID, keeping only login-form as a valid semantic class name.

[0095] For example, check if the target element itself possesses a stable identifier with business meaning. Extracted objects can include identifier attributes such as id, name, data-testid, and data-pro-key from HTML or XML tags. Not all identifier attributes are available; preset rules (such as regular expressions) can be used to filter out dynamic noise features. Typical noise features include framework-generated hash values ​​(such as vue-1a2b3c), random strings (such as el-8829), or IDs starting with a timestamp. Valid identifier attributes include IDs with business semantics manually written by developers (such as submit-btn and login-form).

[0096] Furthermore, the business attributes include custom attributes;

[0097] The extraction of semantic information from the business attributes includes:

[0098] Scan the target element for custom attributes with a preset prefix;

[0099] Extract semantic information from the attribute values ​​of the custom attribute.

[0100] In this example, by establishing a custom attribute scanning mechanism based on a preset prefix, stable identifiers (such as data-testid, data-pro-key, etc.) explicitly injected by developers for automated testing, data tracking, or business logic are effectively mined. This not only makes full use of the semantic specifications already available in modern front-end development, achieving non-intrusive and accurate positioning without modifying the original code structure, but also provides an effective extraction path for dynamic elements that lack standard IDs but contain business meaning. This significantly enhances adaptability and robustness in complex scenarios such as low-code platforms or AI-generated code, ensuring the continuity and accuracy of semantic coordinate generation.

[0101] In addition, business attributes also include platform-injected business attributes, such as data-cell-id.

[0102] Furthermore, the step of traversing upwards through several levels of parent nodes of the target element includes:

[0103] Starting from the target element, its parent nodes are obtained level by level until the preset maximum depth threshold is reached or the document root node is traversed.

[0104] During the traversal, record the list of class names of the parent nodes at each level and the position index of the child elements.

[0105] In this example, the maximum depth threshold can be, but is not limited to, 4. By constructing a bottom-up context backtracking mechanism and depth restriction strategy, the problem of locating the target element when it lacks an independent identifier (no valid ID or business attribute) is effectively solved. It uses the semantic class name of the parent node (such as login-form) combined with the relative position index of the child element to construct a stable relative path based on the business container context. This avoids the fragility of traditional DOM paths caused by the insertion or deletion of intermediate nodes, and prevents performance loss and noise interference caused by excessive traversal through the maximum depth threshold. Thus, it can still accurately lock the target area when the code structure is finely adjusted, providing a reliable fallback solution for generating highly robust semantic coordinates.

[0106] Furthermore, the step of finding the parent node with a semantic class name includes:

[0107] Perform noise cleaning on the class name list of each level of parent node in the record, remove hash class names, random prefix class names and layout auxiliary class names without semantics, retain business class names with natural language semantics, and use the node corresponding to the business class name as a candidate anchor point.

[0108] If a candidate anchor point exists in a certain level of parent node, then the candidate anchor point is determined as the parent node with a semantic class name.

[0109] In this example, by implementing a refined "class name noise cleaning" strategy, random hash values ​​generated by modern front-end build tools (such as css-1a2b3c), temporary prefixes generated by frameworks, and purely visual layout class names (such as flex, mt-4) are effectively removed. Natural language semantic class names that carry core business logic (such as user-card, submit-wrapper) are accurately selected as candidate anchor points. This mechanism ensures that the generated semantic coordinates are based on a stable business container context rather than volatile implementation details or style code. Therefore, even when the page structure undergoes partial reconstruction, style library upgrade, or code obfuscation, it can still penetrate visual noise and accurately locate the logical belonging of the target element, greatly improving the anti-interference ability and cross-version consistency of the positioning algorithm in complex dynamic environments.

[0110] Further, the extraction of semantic information from the semantic class name includes:

[0111] Construct a path segment from the parent node with the semantic class name through intermediate nodes to the target element; wherein, if the intermediate node in the path segment does not have a valid class name, the intermediate node is used to complete the path segment by using the index of the child element position in the list of child nodes of its parent node.

[0112] In this example, a hybrid path fragment combining "semantic anchors + relative indexes" cleverly solves the positioning challenge between a stable parent container and a specific target element. It utilizes a parent node with business meaning as a stable reference anchor, while dynamically completing ordinary structural nodes lacking semantic class names (such as divs used for pure layout) using child element position indexes. This generates a composite path that has both human-readable business context and precise machine positioning coordinates. This strategy not only avoids path breaks caused by the insertion of meaningless intermediate nodes or minor adjustments in order, but also significantly reduces the path's sensitivity to deep DOM structures. It ensures that even during partial page reconstruction, the target element can still be accurately and uniquely restored and locked based on a stable business container and relative positional relationships.

[0113] For example, instead of recording the simple path div > div > div > button, it records the semantic path .login-form > .action-area > button:nth(1).

[0114] Furthermore, before determining whether the target element has a valid identifier attribute, the method further includes:

[0115] In the first operating environment, the set of elements in the same group as the target element is analyzed, and its sequence position in the set is calculated.

[0116] By combining the source code location and sequence location of the same set of elements, an instantiation enhancement identifier is generated;

[0117] The instantiation enhancement identifier is injected into the custom attribute of the target element.

[0118] In this example, by introducing an active injection mechanism of "instantiated enhanced identifier," the problem of locating target elements lacking native stable identifiers (no valid ID and no business attributes) in scenarios such as AI-generated code, low-code dynamic rendering, or third-party component libraries is solved. It uses the sequence position and source code position in the same set of elements to construct a unique dynamic fingerprint and solidifies it into a custom attribute of the target element, thereby transforming the originally volatile and disordered DOM nodes into standard objects with traceable semantic coordinates. This strategy not only achieves a technical leap from "passive extraction" to "active empowerment," ensuring that highly robust anchor points can be generated even in highly dynamic or unstandardized development environments, but also provides a solid data foundation for subsequent accurate synchronization across environments.

[0119] Further, the analysis of the set of elements in the same group as the target element includes:

[0120] Based on the loop iteration metadata injected into the target element during compilation, query the set of elements in the same group as the target element.

[0121] The compiler can recognize loop structures such as `map` and `forEach`. It injects the `_PRO_ITER_` attribute, containing the iteration variable name and the loop source code location, into the root element generated by the loop. If the data source contains a unique business key, it automatically injects the `data-pro-key` attribute.

[0122] In this example, by utilizing compile-time injected loop iteration metadata (such as v-for indexes, map key-value pairs, and other framework-level information), the collection of isomorphic elements (e.g., list items, table rows, or repeating cards) generated by dynamic data rendering is accurately identified and locked. This effectively solves the technical challenge of traditional DOM traversal methods in distinguishing dynamic nodes with identical structures but different data. It enables the construction of instantiated enhanced identifiers based directly on the "sequence position" at the business logic level rather than the volatile physical DOM order. This ensures that even when list data is rearranged, added, deleted, or asynchronously refreshed, causing drastic changes in DOM nodes, the semantic coordinates of the target element still maintain logical uniqueness and stability, greatly improving the accuracy and anti-interference capability of element positioning in dynamic rendering scenarios.

[0123] This multi-level extraction mechanism, as described in the embodiments of this specification, avoids identifier failure caused by front-end framework re-rendering or code compression by filtering random IDs and hash class names. Even for AI-generated code lacking standardized IDs, stable semantic features can still be extracted by mining business attributes and parent context. Even if the page structure is slightly adjusted (such as inserting new elements between sibling nodes), as long as the core business class name container remains unchanged, the semantic information based on the parent node context can still accurately locate the target.

[0124] For example, suppose a user comments on a "submit" button in edit mode.

[0125] Case A: Button code is< / button> <button id="btn_submit">Extraction result: id="btn_submit" was directly extracted as semantic information.

[0126] Case B: Button code is< / button> <button class="btn-v2-random-hash">(No ID, class name contains noise). Extraction result: Ignoring the class name, searching upwards reveals its parent node is... Furthermore, this button is the second interactive element within the form. The semantic information extracted is: ParentClass: "login-form" +RelativeIndex: 2.

[0127] Case C: Button code is < / button> <button data-action="confirm">Extraction results: A custom business attribute was identified, and data-action="confirm" was extracted as semantic information.

[0128] Through the aforementioned step 21, the visually volatile DOM nodes were successfully transformed into a set of standardized semantic descriptions that are independent of the environment and resistant to interference, laying a solid foundation for the subsequent generation of unique semantic coordinates.

[0129] Then, in step 22, the semantic information is combined into a selector string for locating the target element. The selector string or the hash value obtained by hashing the selector string is used as the semantic coordinates of the target element. It can be understood that after successfully extracting the semantic information in step 21, step 22 no longer relies on the original DOM node object, but instead combines these static text features into a structured string or hash value, i.e., semantic coordinates.

[0130] In the embodiments of this specification, the specific generation strategy depends on the level hit in step 21. That is, whether the semantic information is extracted from the identifier attribute of the target element, the business attribute, or the class name of the parent node at several levels.

[0131] Scenario A: Generation based on valid identifier attributes. If a valid ID (such as login-btn) is extracted in step 21, it is directly formatted as a standard selector string as the semantic coordinate. Generation formula: Coordinate = "#" + ID_Value. Example: #login-submit-btn.

[0132] Scenario B: Generation based on business attributes. If a custom business attribute (such as data-pro-key="confirm_action") is extracted in step 21, it is constructed into an attribute selector format. Generation formula: Coordinate = "[" +Attr_Name + "=\"" + Attr_Value + "\"]". Example: [data-pro-key="confirm_action"].

[0133] Scenario C: Generation based on context path. If neither of the first two is available, the path fragments constructed in step 21, consisting of "semantic anchors + relative indexes", are serialized and concatenated to form a relative semantic path. Take the nearest parent node class name with a semantic class name (e.g., .user-card). Concatenate the relative position index of the intermediate node (e.g., > div:nth-child(2)). Concatenate the tag name and its own characteristics of the target element (e.g., > button.submit). Generation formula: Coordinate = ParentClass + ">" + PathSegments + ">" + TargetTag. Example: .login-form >.action-area > button:nth-child(1).

[0134] Optionally, to further compress data volume and improve matching efficiency, in some embodiments, the generated long string can be hashed, such as by using the first 8 bits of MD5 or SHA-256, to generate a short, unique hash code as the final semantic coordinate. Regardless of the complexity of the underlying path, the final stored coordinate is a fixed-length string (e.g., Key: a1b2c3d4), greatly reducing database storage pressure and transmission bandwidth consumption. A mapping table is maintained to record the correspondence between Hash_Code <-> Semantic_Path, ensuring that during matching, both rapid location and backtracking of the original path for verification are possible.

[0135] In the embodiments of this specification, the generated semantic coordinates do not contain any simple paths (such as / html / body / div[3] / ...) or dynamic random values. They are entirely composed of business semantics (class name, attribute value) and relative topology (which child element). This means that even if the root structure of the HTML document changes, or the code is compressed and obfuscated, the coordinates are still valid as long as the business logic container (such as .login-form) exists. For the same target element, no matter how many times it is executed in the editing state, as long as its business characteristics remain unchanged, the semantic coordinates generated in step 22 will always be completely consistent. Compared with pure numeric IDs or hashes, coordinates generated based on semantic paths (such as .form > .btn) have natural readability. When developers are debugging or viewing the database, they can intuitively understand which business module the coordinates point to, which is convenient for manual intervention and maintenance.

[0136] For example, suppose a "Submit" button is selected in edit mode, which has no valid ID and no business attributes. Parent node semantic class name: .checkout-container; relative position: the second button element under this container; concatenate the string according to the preset template: .checkout-container > button:nth-of-type(2), and get the semantic coordinates as "SC: .checkout-container > button:nth-of-type(2)", where SC represents semantic coordinates.

[0137] Through step 22, this embodiment of the specification successfully abstracts volatile physical DOM nodes into stable logical coordinates, achieving accurate data synchronization across environments and versions.

[0138] It should be noted that the multi-level semantic decision-making mechanism provided in the embodiments of this specification is intended to fundamentally solve the technical challenges brought about by AI code generation and Fiber architecture.

[0139] To address the issue of broken memory references, the embodiments in this specification do not rely on any transient DOM node objects or physical paths. Instead, they construct a logical fingerprint by extracting business attributes or denoised semantic class names. Regardless of how the Fiber scheduler destroys or reconstructs DOM instances in memory, as long as the business logic container (e.g., .order-list) and the business characteristics of the target element (e.g., data-item-id) remain unchanged, the semantic coordinates generated by the embodiments in this specification can be re-matched to the corresponding node instance in the new rendering cycle by traversing the current DOM tree in real time. This achieves a paradigm shift from binding memory addresses to binding business logic.

[0140] To address the semantic feature space collapse problem, this specification's embodiments introduce noise cleaning and relative topology completion mechanisms. Random hash class names generated by AI are directly eliminated using regular expressions to avoid interfering with matching. For isomorphic elements lacking independent identifiers, composite paths are constructed using compile-time injected cyclic metadata or the stable semantic context of the parent container, combined with the relative order of child elements. This strategy is equivalent to artificially reconstructing a high-dimensional coordinate system based on the business context within the collapsed feature space, ensuring that even in extreme cases of AI code fine-tuning or dynamic data rearrangement, a unique positioning vector can still be calculated. This fundamentally avoids the positioning failure caused by the single feature in traditional techniques.

[0141] Finally, in step 23, the semantic coordinates are associated with and stored in relation to the annotation information generated by the annotation operation, so that the target elements in the structured document can be located based on the semantic coordinates in the second runtime environment. It can be understood that this step completes the transformation from "runtime memory objects" to "persistent database records," establishing the semantic coordinates as the link between different runtime environments.

[0142] This embodiment constructs and persists a "labeling record". Instead of hard-coding the annotation content directly into the HTML source code or relying on temporary memory references, it creates an independent data structure to bind semantic coordinates with annotation information.

[0143] The semantic coordinates generated in step 22 (such as #login-btn or .form > button:nth(1)) can be used as the primary key or index field. Meanwhile, the annotation information generated by the user in step 21 (including text content, author ID, timestamp, status marker, highlight color and other metadata) can be used as the payload data and assembled into a complete JSON object or database record.

[0144] Example data structure:

[0145] json

[0146] {

[0147] "id": "annotation_001",

[0148] "semantic_coordinate": ".login-form > button.submit", / / Core anchor

[0149] "content": "Loading status needs to be added", / / Annotated content

[0150] "author": "developer_A",

[0151] "timestamp": 1715623400,

[0152] "status": "pending"

[0153] }

[0154] This record is written to a cloud database, a local file system, or a configuration file associated with the project codebase. At this point, the annotation information is completely decoupled from the specific DOM node instance, and is only linked through the logical pointer of "semantic coordinates".

[0155] Traditional annotations often directly modify the DOM tree (such as inserting...). Tags (and their associated elements) lead to code pollution and difficulty in maintenance. This specification's embodiment uses external storage, where annotation information exists independently of the structured document. Regardless of document restructuring, as long as semantic coordinates match successfully, annotations can be attached.

[0156] Furthermore, the same semantic coordinate can be associated with multiple annotations, for example, multiple developers may have different opinions on the same button. Storing this information in a list structure ensures that all feedback is accurately mapped to the same target element. Because it stores abstract semantic coordinates rather than specific node memory addresses, this storage record can transcend time and be applicable to any historical or future version of the document.

[0157] Optionally, when a user opens a structured document in the second runtime environment, the system first loads all existing annotation records corresponding to that document. It then traverses the DOM tree in the current environment, using the same extraction and generation logic from steps 21 and 22 to calculate the current semantic coordinates of each element in real time. The calculated current coordinates are compared with the historical coordinates stored in the database. If a match is found, the system immediately renders the corresponding annotation information above the element, restoring the collaborative editing scenario. If a match fails, it indicates a fundamental change to the target element, such as the removal of business logic; the system can mark the annotation as "invalid" or "pending confirmation" to avoid incorrect display.

[0158] By solidifying the coordinates and information in step 23, it is ensured that users see the same accurate set of annotation data regardless of the number of different runtime environments, eliminating the need for repetitive work. Because the stored coordinates are cleaned and verified semantic coordinates, even if the code in the second runtime environment undergoes packaging, compression, class name hashing, or structural tweaks, as long as the core business semantics remain unchanged, the system can still retrieve the target element through coordinate matching. This solves the problem of traditional storage methods based on physical paths or random IDs failing across environments. Associative storage means that there is no need to inject massive annotation logic or redundant data into the code delivered to the end user. The second runtime environment only needs to fetch the annotation data on demand and render it dynamically, maintaining the purity and high performance of the production environment code.

[0159] In one example, the first runtime environment is an edit-mode environment, and the second runtime environment is a preview-mode environment or a share-mode environment.

[0160] This example not only defines a specific application scenario but also reveals the core architectural advantages of the embodiments described in this specification. It generates stable semantic coordinates in the editing state, enabling precise positioning in both the preview and sharing states. This design cleverly balances positioning accuracy, runtime performance, and collaboration efficiency, solving the challenge of cross-environment collaboration in front-end development.

[0161] For example, in edit mode, developer A adds the annotation "Add debouncing" to the "Submit" button. The system generates the coordinates .action-bar > button.primary and stores {coordinates: ".action-bar > button.primary", content: "Add debouncing"} in the cloud database. In share mode, product manager B opens the officially released webpage link. The code is obfuscated, and the button ID changes to x9z. The system reads the database records, scans the current page, and finds that a button's parent container class is named .action-bar and its own class name contains "primary". It calculates that its coordinates are still .action-bar > button.primary. The match is successful, and product manager B immediately sees the annotation information about adding debouncing. Step 23 transforms the semantic coordinates generated in the first two steps into persistent and transferable data assets. By establishing a "coordinate-content" mapping relationship, it breaks down the information barriers from the development environment to the production environment, achieving high-precision collaborative synchronization across environments and versions.

[0162] Semantic coordinates, while physically implemented using selectors, are logically a higher-level abstraction and enhancement of traditional selectors. Traditional CSS selectors (such as IDs, class names, or XPaths) often focus only on the physical structure or surface attributes of the DOM tree, making them highly susceptible to failure due to code compression, random hashing, or node additions and deletions. In contrast, the semantic coordinates in this embodiment are stable fingerprints generated by intelligent algorithms that filter noise, refine business logic, and reconstruct the context of the original selector features. They proactively discard volatile implementation details (such as framework-generated random IDs) and instead lock onto identifiers with persistent business meaning (such as custom attributes, semantic class names, and relative topological relationships), thus transforming fragile physical paths into interference-resistant logical anchors. This specially reinforced selector form ensures that semantic coordinates can transcend compilation and environment differences, accurately and uniquely locating target elements even in dynamically changing cross-version scenarios.

[0163] The element processing method for structured documents provided in the embodiments of this specification constructs a multi-level semantic decision-making mechanism, which can intelligently identify and extract stable features of target elements in different rendering states, such as effective identifiers, business attributes, or denoised semantic class names, thereby generating semantic coordinates with high robustness and anti-interference capabilities. By associating and storing annotation information with semantic coordinates, a persistent association between annotation information and target elements is achieved, ensuring that the same target element can be automatically and accurately restored and locked without manual intervention in heterogeneous operating environments such as editing, previewing, and sharing states. This not only significantly improves the accuracy and consistency of locating specific elements across operating environments but also greatly reduces the cost of manual calibration in multi-scenario collaboration, meeting the requirements for accurate locating of specific elements across operating environments and the requirements for automated processing.

[0164] For dynamic list rendering scenarios (such as isomorphic element collections generated by v-for, map, and forEach), in order to solve the index drift problem caused by data addition and deletion, the embodiments in this specification adopt a two-stage algorithm of "compile-time metadata injection + runtime sequence recalculation".

[0165] Figure 3 A flowchart illustrating a method for cyclically instantiating index calculation according to one embodiment is shown. Figure 3 As shown, the cyclic instantiation index calculation in this embodiment includes the following two stages, each of which contains several steps:

[0166] Phase 1: Compile-time metadata injection, i.e., static analysis and tagging. This phase is executed during code build or low-code platform saving and is completed by the parser / compiler.

[0167] Step 31: Loop structure identification and scope locking.

[0168] Optionally, parse the source code AST (Abstract Syntax Tree) to identify loop directive nodes (such as v-for, map, forEach). Locate the root DOM element to which the loop directive is bound to determine the scope of the loop.

[0169] Step 32, stability key value detection.

[0170] Optionally, check whether the cycle item defines a stable business-unique key (e.g., key="item.id").

[0171] If a stable key exists, extract the attribute path of that key and mark it as "strong stability mode".

[0172] If no stable key exists, it is marked as "weak stability mode", and the position of the subsequent dependent sequence is set for positioning.

[0173] Step 33, metadata tagging and injection.

[0174] Inject a hidden metadata attribute, defined as _PRO_ITER_META_, into the root DOM element locked in step 31. The content to be written can include: sourceLine: source code line number; loopId: generated unique loop identifier; expectedLength: estimated list length; keyMode: strong or weak stability flag.

[0175] The second stage: runtime sequence recalculation, i.e., dynamic positioning and coordinate synthesis. This stage is triggered during user interaction, annotation matching, or runtime execution.

[0176] Step 34, target set locking (context backtracking).

[0177] Receives the currently selected target DOM element. Starting from this element, traverse upwards through its parent nodes, finding the nearest ancestor node that carries the _PRO_ITER_META_ tag. All child elements under this ancestor node are then identified as belonging to its "group of elements".

[0178] Step 35: Filtering of candidate queues from the same source.

[0179] Iterate through the "set of elements in the same group" determined in step 34. Perform feature filtering and retain elements that meet the following conditions to enter the "candidate instance queue": the tag name is consistent with the target element; the static class name set is consistent with the target element, excluding interference from dynamic hash class names.

[0180] Step 36, instantiate index calculation.

[0181] Read the stability pattern recorded in step 32 and perform differential calculation:

[0182] In strong stability mode (with a key), the business key value of the target element (e.g., id=101) is read. Elements with the same key value are retrieved from the "candidate instance queue".

[0183] Retrieve the logical order of the element in the queue and define it as the "instantiated index". This order does not change due to node displacement caused by physical insertion or deletion in the DOM, but depends only on the order of the data source.

[0184] In the weak stability mode (no key), calculate the physical index position of the target element in the "candidate instance queue". Obtain the total number of child nodes of the parent container. Perform normalization processing to generate a relative position fingerprint (format example: Nth / Mth of M), and define it as the "instantiation index".

[0185] Step 37, semantic coordinate synthesis.

[0186] Get the loop unique identifier (loopId).

[0187] Combine the loopId, the "instantiated index" calculated in step 36, and the existing business key value to generate the final enhanced semantic coordinate string (example format: List_{LoopId}_Index{N}_Key{Value}). Output this coordinate as a persistent location identifier for the element in cross-environment scenarios.

[0188] Step 38, handling any exceptions.

[0189] If no element matching the key is found in strong mode, the system may automatically downgrade to weak mode logic due to a complete change in the data source. This involves combining the element content snapshot (Text Content Snapshot) for fuzzy matching and recalculating the approximate index.

[0190] This loop-based index calculation ensures that even if a new element is inserted in the middle of the list, causing a change in the physical DOM order, the calculated logical index remains constant as long as the business key remains unchanged, thus achieving precise positioning.

[0191] Optionally, in the embodiments of this specification, when the target element has both "valid business ID" and "circular metadata" (_PRO_ITER_META_), the system does not select only one of the identifiers, but adopts a fusion strategy of "primary key anchoring + context verification" to generate the final semantic coordinates.

[0192] Specifically, when a target element is detected to possess both a stable key (e.g., data-pro-key="item_101") and loop context information (e.g., loopId="list_A", index=3), the generated semantic coordinate string will contain dual-dimensional information, defined in the following format: {Scope_ID}:{Loop_Context}[Index:{N}]#{Business_Key}

[0193] Example: Page_Main:List_Products[Idx:3]#item_101

[0194] In this structure: the business key (#item_101) serves as the primary locator, used to directly lock onto a unique business entity at the data source level, unaffected by the physical order of the DOM.

[0195] The loop context ([Idx:3]) acts as a secondary validator: it records the logical order of the elements at the time of generation.

[0196] In addition, for the extreme case of "list reordering and IDs being dynamically generated (or IDs being invalid)," the following three-level fallback mechanism can be used to ensure that the fallback role of the circular metadata is fully reflected.

[0197] Level 1: Primary key exact match (normal scenario).

[0198] The system prioritizes parsing the Business_Key in the coordinates. If an element with the same Key is found in the target environment, regardless of whether its current physical index has changed due to list reordering (e.g., from the 3rd to the 5th position), the system considers the location successful. In this case, the Index in the loop metadata is only used for logging or secondary verification. If the Key matches but the Index deviation is too large, a "data order error" warning may be triggered, but it will not affect the location result.

[0199] Level 2: Contextual fingerprint fallback (ID dynamic or invalid scenarios).

[0200] If the target element's ID is identified as dynamic noise, such as a regular expression matching el-{timestamp} and no other stable business attributes, or if the original key value no longer exists in the target environment (e.g., data source reconstruction causing ID rule changes), the system automatically ignores the invalid Business_Key portion and downgrades the Loop_Context portion of the coordinates. The system locks the isomorphic list container based on the _PRO_ITER_META_ flag and recalculates the target position in the candidate queue using the recorded "logical order" or "relative position fingerprint" (e.g., "3rd / out of 10").

[0201] Even if the ID becomes completely invalid, as long as the isomorphic structure of the list is not fundamentally broken—that is, it is still the same list being rendered in a loop—the system can still accurately locate the corresponding DOM node based on its "relative position." This solves the pain point of traditional solutions where the target is completely lost once the ID changes.

[0202] Level 3: Fuzzy matching of content snapshots (scenario of drastic structural changes).

[0203] If the list is updated with additions or deletions, causing a shift in the original logical order (for example, if the original 3rd item is deleted, the current 3rd item is actually the original 4th item), the system combines a text content snapshot (such as product name or specific text features) captured during compilation or initial runtime to perform a fuzzy match in the current candidate instance queue. Within the constraints of the loop context, i.e., only within the same `_PRO_ITER_META_` scope, it searches for the element with the highest content similarity as the final target.

[0204] In summary, the embodiments described in this specification do not present an either-or choice between "valid ID" and "circular metadata." Instead, they construct a comprehensive positioning system with the business key at its core, the circular context as a safety net, and content snapshots as the last line of defense. When the ID is valid, the circular metadata provides consistency verification; when the ID becomes invalid (dynamically generated or changed), the circular metadata immediately takes over as the core positioning basis; when both are interfered with, the content snapshot provides final fault tolerance. This design ensures that in any extreme dynamic scenario, the positioning logic always has at least one feasible backtracking path, thus achieving a true technical closed loop.

[0205] Figure 4 The diagram illustrates a method for displaying structured documents according to one embodiment, which can be based on... Figure 1 The implementation scenarios shown and Figure 2 The method shown associates stored semantic coordinates. For example... Figure 4 As shown, the method for displaying structured documents in this embodiment includes the following steps: Step 41, in the second running environment, when loading the annotation information of the structured document, read the semantic coordinates of the target elements stored in association with the annotation information; the semantic coordinates are as follows: Figure 2 The method shown is associated with storage; step 42, matching the semantic coordinates among the elements of the structured document; step 43, if the target element is matched, then displaying the target element and the annotation information together. The specific execution method of each of the above steps is described below.

[0206] First, in step 41, in the second running environment, when loading the annotation information of the structured document, the semantic coordinates of the target elements associated with the annotation information are read; the semantic coordinates are as follows: Figure 2 The method shown is associated with storage. It is understood that the second runtime environment is usually different from the first runtime environment; for example, the first runtime environment is in edit mode, and the second runtime environment is in preview mode or share mode.

[0207] In the second runtime environment, structured documents have typically been built, minified, or even obfuscated, and their DOM structure may have changed significantly compared to the first runtime environment, such as class name hashing and ID randomization. When a user opens a page containing annotation functionality, or when the system detects that the current document has associated collaborative projects, the process of loading annotation information is automatically triggered.

[0208] In this embodiment, the system can send requests to a cloud database, local configuration file, or API interface to retrieve all annotation records associated with the current structured document by matching document ID, version number, or URL features. These records are the data packets previously generated and stored in the first runtime environment using the method shown in Figure 2. Each record typically includes: annotation content, author information, timestamp, and semantic coordinates. The semantic coordinate field is extracted separately from each loaded annotation record. At this point, the semantic coordinate is a static string (e.g., .login-form > button[data-key="submit"] or its hash value).

[0209] For example, a product manager opens a published activity page in the sharing mode (i.e., the second runtime environment). After page initialization, the system identifies the project ID corresponding to the current URL. The system calls the API to retrieve all annotation data for that project. The returned JSON data is parsed, and the list of semantic coordinates is extracted.

[0210] Annotation 1: Coordinates: .hero-section > h1.title;

[0211] Annotation 2 Coordinates: [data-action="register-btn"];

[0212] Annotation 3: Coordinates: .footer > nav > a:nth-child(2);

[0213] These coordinates are the semantic coordinates of the target element generated in the editing state (i.e., the first runtime environment) in Figure 2.

[0214] Then, in step 42, the semantic coordinates are used to match each element in the structured document. It is understood that this step no longer relies on simple string equality checks, but instead activates an intelligent matching engine to traverse or index all candidate elements in the current structured document (DOM tree) and verify whether they possess business characteristics that match the stored semantic coordinates.

[0215] In the embodiments described in this specification, the system can adaptively select the appropriate matching strategy based on the composition type of semantic coordinates.

[0216] Strategy A: Direct selector matching. If the semantic coordinates are represented in the standard CSS selector format, the system calls the browser's native API (such as document.querySelectorAll()) to directly query the current DOM. Since random noise has been removed during the generation of these coordinates, even in an obfuscated code environment, as long as the business class name or property remains unchanged, the target can be directly matched.

[0217] Strategy B: Semantic Feature Backtracking Matching. If the semantic coordinates contain relative paths or complex logic (such as "the Nth child element whose parent node class name is X"), the system will perform reverse verification: first locate the parent container with a specific semantic class name (such as .user-card). Under this container, lock the candidate element based on the relative position index recorded in the coordinates (such as nth-child(2)). Verify whether the label name and business attributes of the candidate element are consistent with the coordinate description.

[0218] Strategy C: Hash fingerprint comparison. If hash values ​​are stored, the system needs to calculate the "instant semantic fingerprint" of key elements in the current DOM in real time and compare it with the stored hash values ​​to find nodes with the same value.

[0219] Finally, in step 43, if the target element is matched, the target element and the annotation information are displayed together. It can be understood that the geometric information of the target element in the current window can be obtained, and the screen coordinates of its center point, edge, or specific corner point can be calculated. This is used as an anchor point to determine the initial display position of the annotation information, such as "top right corner of the element" or "directly below the element".

[0220] This allows for the dynamic creation of a floating layer container without modifying the original HTML structure. The annotation information read in step 31 (e.g., text content, author avatar, time, status tags, etc.) is then populated into the template of this container to generate visual annotation cards.

[0221] This specification's embodiments establish a two-way interactive logic between target elements and annotation information. When the user hovers the mouse over or clicks on a target element, the corresponding annotation information is highlighted; conversely, clicking on annotation information also highlights the corresponding element. The system listens for page scrolling events and recalculates the position of the annotation cards in real time, ensuring they always move with the target element and preventing misalignment. If the window size changes or the element's position changes due to animation, the card position is automatically adjusted to prevent obstruction or overflowing the screen.

[0222] The method for displaying structured documents provided in the embodiments of this specification can be reused. Figure 2 The method shown generates highly robust semantic coordinates, which build an automated positioning and rendering mechanism in the second runtime environment. This mechanism can accurately identify and lock target elements. Without manual re-marking or calibration, the stored annotation information can be automatically and accurately anchored and associated with the target elements for display. This achieves a fully automated closed loop from data loading to view presentation, significantly improving the accuracy and consistency of positioning specific elements across runtime environments. It also greatly reduces the cost of manual intervention in multi-scenario collaboration, meeting the requirements for accurate positioning of specific elements across runtime environments and the requirements for automated processing.

[0223] The embodiments in this specification also provide processing methods for several typical scenarios.

[0224] A typical scenario is nested loops. To address the issue of confusing element hierarchy caused by multi-level nested loops in complex lists (such as "chapter-paragraph-sentence" or "table-row-cell"), a context stack array named `_PRO_ITER_STACK_` is constructed during compile time. This array records the metadata of the target element in each loop iteration (including the loop variable name, current index value, and parent path). At runtime, the system dynamically generates coordinate identifiers with multi-dimensional hierarchical characteristics based on this stack information (e.g., `list_level1_idx2 > list_level2_idx5 > item`), restoring the flattened DOM sequence to a three-dimensional business logic structure. This mechanism ensures that even in scenarios with a large number of repetitive isomorphic elements and extremely deep structures, the system can still uniquely locate the target node based on a precise iteration path, completely eliminating positioning ambiguities caused by the similarity of sibling elements' structures.

[0225] Another typical scenario is dynamic addition and deletion of list items. To address the issue of dynamic insertion, deletion, or reordering of list items (i.e., index drift) caused by user interaction or data refresh, a hierarchical fault-tolerant matching strategy was established. The primary strategy is to prioritize identifying and utilizing stable business keys (such as data-pro-key) injected by the developer. Since this attribute is directly bound to the business entity ID rather than its physical location, it is completely immune to the impact of index changes. When an explicit business key is lacking, the system automatically triggers a fallback mechanism, employing a composite matching algorithm of "relative index + element content fingerprint snapshot." This not only compares the relative order of elements within the local container but also extracts and compares key text features or attribute hash values ​​within the elements for fuzzy verification. This dual-protection mechanism ensures that even in the event of drastic data changes leading to large-scale DOM node reorganization, the annotation information can still be intelligently attached to the correct business object, avoiding the misalignment or loss inherent in traditional index-based positioning methods.

[0226] Another typical scenario is handling layer penetration across iframe isolated scenes. This is relevant to the widespread issue of layer penetration in web pages. <iframe>To address the technical problem that conventional DOM queries cannot cross document boundaries due to sandbox isolation, a dedicated hierarchical penetration selector syntax and recursive traversal engine are constructed; this mechanism allows defining a composite path in the format of iframe[name="target_frame"] >>> internal_selector, where the >>> operator instructs the execution engine to suspend the traversal of the current document, switch to the internal document context (Content Document) of the iframe with the specified name, and recursively execute the subsequent selector matching logic in the new context; in this way, the system can seamlessly penetrate single-layer or multi-layer nested iframe structures, bring elements scattered in different Document Domains into a unified semantic coordinate system, and achieve full coverage and accurate annotation of complex pages including third-party plugins, advertising modules or micro-frontend sub-applications.

[0227] Figure 5 shows a flowchart of a multi-dimensional coordinate positioning method in a nested loop scenario according to an embodiment. As shown in Figure 5, this embodiment is used to solve the problem of accurate element positioning in a multi-level dynamic list (such as floor - product - specification), which specifically includes the following steps:

[0228] Step 51: Target element capture and reverse traversal initialization.

[0229] Optionally, a user-selected target DOM element (for example, the .color-option node in three-level nesting) is received. An empty temporary stack data structure, defined as _PRO_ITER_STACK_, is initialized for storing loop context information captured along the way. Starting from the target element, a traversal operation is performed upward (in the Parent direction) along the DOM tree.

[0230] Step 52: Loop metadata identification and stack construction.

[0231] Optionally, during the traversal process, it is checked one by one whether the current parent node carries the loop tag attribute (_PRO_ITER_META_) injected at compile time.If a marker is detected, extract the loop metadata for that node, including but not limited to: loop level identifier (Loop ID), business-unique key values ​​(such as product ID, floor ID), and the index position of the current instance in its queue. Push the extracted metadata as a separate "hierarchy record object" onto the `_PRO_ITER_STACK_` stack. Continue traversing upwards until the document root node is reached or no new loop markers are found. If no marker is detected, continue traversing upwards to the next parent node.

[0232] It should be noted that for a three-level nested scenario, the stack will store the metadata records of Level 3 (color layer), Level 2 (product layer), and Level 1 (floor layer) in sequence.

[0233] Step 53, multidimensional path identifier serialization.

[0234] Optionally, after traversal is complete, all level records in _PRO_ITER_STACK_ are read. The stack data is serialized and concatenated in a predefined order (usually top-down, i.e., from the outer loop to the inner loop). A multidimensional path identifier string with level separators is constructed.

[0235] Format example: {Level1_Name}[Idx:{N}, Key:{V}] > {Level2_Name}[Idx:{N},Key:{V}] > ... > {Target_Tag}.

[0236] Generation result: For example, Floor_List[Idx:2] > Product_List[Idx:3, ID:P2] > Color_Options[Idx:2] > .color-option.

[0237] Step 54, cross-environment recursive hierarchical matching.

[0238] Optionally, in the target runtime environment (such as the share state or preview state), the multidimensional path identifier generated in step 53 is parsed. A recursive hierarchical positioning strategy is executed, instead of a single flat path matching. Specifically, first-level positioning: Nodes matching Level 1 features (such as the second floor container) are searched globally. Scope shrinking: Using the node located in the first level as the new search context, nodes matching Level 2 features (such as the third product container) are searched within its subtree. Double verification: When matching Level 2 and deeper levels, both the "physical index" and the "business key value" are verified simultaneously.Only when both are matched (or the Key value match is prioritized), it is determined that the layer is hit. Progress layer by layer: repeat the above process of "shrinking the context -> searching the next layer -> performing double verification" until the innermost target element is located.

[0239] Step 55: Abnormal breakpoint detection and feedback.

[0240] Optionally, during the recursion process of performing step 54, if no matching node can be found at a certain level, the search for subsequent levels is immediately terminated. The specific level information of the current break is recorded and returned (for example: "Level 2 product container is missing, the reason is that the product ID P2 does not exist or the index is out of bounds"). A clear error report is output to indicate whether it is caused by the change of the outer structure or the lack of inner data, instead of returning an ambiguous localization failure.

[0241] According to an embodiment of another aspect, an element processing apparatus for structured documents is further provided, and the apparatus is configured to execute the element processing method for structured documents provided in the embodiments of this specification. Figure 6 shows a schematic block diagram of an element processing apparatus for structured documents according to an embodiment. As shown in Figure 6, the apparatus 600 includes:

[0242] An extracting unit 61, configured to, in a first operating environment, extract semantic information from the identification attribute and service attribute of the target element or the class names of parent nodes at several levels in response to a user's labeling operation on the target element of the structured document;

[0243] A generating unit 62, configured to combine the semantic information extracted by the extracting unit 61 into a selector string for locating the target element, and use the selector string or a hash value obtained by performing a hash operation on the selector string as the semantic coordinate of the target element;

[0244] A storage unit 63, configured to associate and store the semantic coordinate obtained by the generating unit 62 with the labeling information generated by the labeling operation, so that the target element in the structured document is located according to the semantic coordinate in a second operating environment.

[0245] Optionally, as an embodiment, the extraction unit 61 includes:

[0246] The first judgment subunit is used to determine whether the target element has a valid identification attribute; if it is determined that the target element has a valid identification attribute, semantic information is extracted from the identification attribute;

[0247] The second judgment subunit is used to determine whether the target element has a business attribute if the first judgment subunit determines that the target element does not have a valid identifier attribute; and to extract semantic information from the business attribute if the target element has a business attribute.

[0248] The third judgment subunit is used to, if the second judgment subunit determines that the target element does not have business attributes, traverse the parent nodes of several levels of the target element upwards to find the parent node with a semantic class name and extract semantic information from the semantic class name.

[0249] Further, the first judgment subunit is specifically used to obtain the identification attribute value of the target element; if the identification attribute value is empty, it is determined that it does not have a valid identification attribute; if the identification attribute value is not empty, it is used to detect whether the identification attribute value conforms to the dynamic noise feature using a preset regular expression matching rule; if it conforms to the dynamic noise feature, it is determined that it does not have a valid identification attribute; the dynamic noise feature includes: starting with a preset frame prefix, containing continuous random hash characters, or conforming to a timestamp generation format; if it does not conform to the dynamic noise feature, it is determined that it has a valid identification attribute.

[0250] Further, the business attributes include custom attributes;

[0251] The second judgment subunit is specifically used to scan the custom attributes of the target element with a preset prefix; and extract semantic information from the attribute values ​​of the custom attributes.

[0252] Further, the third judgment subunit is specifically used to obtain its parent node level by level starting from the target element until the preset maximum depth threshold is reached or the document root node is traversed; during the traversal process, the class name list and child element position index of each level of parent node are recorded.

[0253] Further, the third judgment subunit is specifically used to perform noise cleaning operation on the class name list of each level of parent node, remove hash class names, random prefix class names and layout auxiliary class names without semantics, retain business class names with natural language semantics, and take the node corresponding to the business class name as a candidate anchor point; if a certain level of parent node has the candidate anchor point, then the candidate anchor point is determined as the parent node with semantic class name.

[0254] Further, the third judgment subunit is specifically used to construct a path segment from the parent node with the semantic class name through the intermediate node to the target element; wherein, if the intermediate node in the path segment does not have a valid class name, the child element position index of the intermediate node in its parent node child node list is used to complete it.

[0255] Further, the extraction unit 61 also includes:

[0256] The analysis subunit is used to analyze the set of elements in the same group where the target element is located and calculate its sequence position in the set before the first judgment subunit judges whether the target element has a valid identification attribute in the first running environment.

[0257] A generation subunit is used to generate an instantiation enhancement identifier by combining the source code position and sequence position of the same set of elements obtained by the analysis subunit;

[0258] An injection subunit is used to inject the instantiation enhancement identifier generated by the generation subunit into the custom attribute of the target element.

[0259] Further, the analysis subunit is specifically used to query the set of elements in the same group where the target element is located, based on the loop iteration metadata injected into the target element during compilation.

[0260] Optionally, as an embodiment, the first running environment is an editing environment, and the second running environment is a preview environment or a sharing environment.

[0261] With the element processing apparatus for structured documents provided in the embodiments of this specification, a multi-level semantic decision mechanism is constructed. The extraction unit 61 can intelligently identify and extract stable features of the target element in different rendering states, such as valid identifiers, business attributes or denoised semantic class names, so that the generation unit 62 generates semantic coordinates with high robustness and anti-interference capability. The storage unit 63 performs associated storage of the annotation information and the semantic coordinates, realizing the persistent association between the annotation information and the target element, ensuring that between heterogeneous operating environments such as the editing state, preview state and sharing state, the same target element can be automatically and accurately restored and locked without manual intervention, which not only significantly improves the accuracy and consistency of positioning a specific element across operating environments, but also greatly reduces the manual calibration cost in multi-scenario collaboration, and can meet the requirements for accurate positioning of a specific element across operating environments and the requirements for automated processing.

[0262] According to an embodiment of another aspect, an apparatus for displaying a structured document is further provided, which is configured to execute the method for displaying a structured document provided in the embodiments of this specification. Figure 7 shows a schematic block diagram of an apparatus for displaying a structured document according to one embodiment. As shown in Figure 7, the apparatus 700 includes:

[0263] A reading unit 71, configured to, when loading annotation information of a structured document in a second operating environment, read the semantic coordinates of the target element stored in association with the annotation information; the semantic coordinates are stored in association by the apparatus as shown in Figure 7;

[0264] A matching unit 72, configured to perform matching among respective elements of the structured document by using the semantic coordinates obtained by the reading unit 71;

[0265] A display unit 73, configured to, if the matching unit 72 matches the target element, display the target element and the annotation information in association with each other.

[0266] With the display apparatus for structured documents provided in the embodiments of this specification, the highly robust semantic coordinates generated by the apparatus shown in Figure 7 are reused, and a set of automatic positioning and rendering mechanisms is constructed in the second operating environment. The target element can be accurately identified and locked through the reading unit 71 and the matching unit 72; without manual re-marking or manual calibration, the stored annotation information can be automatically and correctly anchored and displayed in association with the target element through the display unit 73, which realizes a fully automated closed loop from data loading to view presentation, significantly improves the accuracy and consistency of positioning of specific elements across operating environments, greatly reduces the labor intervention cost in multi-scenario collaboration, and can meet the requirements for accurate positioning of specific elements across operating environments and the requirements for automated processing.

[0267] According to an embodiment of another aspect, a computer-readable storage medium is further provided, on which a computer program is stored. When the computer program is executed on a computer, the computer is caused to perform the method described in any one of the embodiments in conjunction with Figure 2 to Figure 5.

[0268] According to an embodiment of a further aspect, a computing device is further provided, which includes a memory and a processor. Executable code is stored in the memory, and when the processor executes the executable code, the method described in any one of the embodiments in conjunction with Figure 2 to Figure 5 is implemented.

[0269] Those skilled in the art should appreciate that, in one or more of the examples described above, the functions described in the present invention may be implemented by hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium.

[0270] The specific embodiments described above have further illustrated the purpose, technical solution and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.< / iframe> < / button>

Claims

1. A method for element processing in structured documents, comprising: In the first operating environment, in response to the user's annotation operation on the target element of the structured document, semantic information is extracted from the identifier attribute, business attribute or class name of the parent node at several levels of the target element; The semantic information is combined into a selector string for locating the target element, and the selector string or the hash value obtained by hashing the selector string is used as the semantic coordinates of the target element. The semantic coordinates are associated with and stored with the annotation information generated by the annotation operation, so that the target element in the structured document can be located based on the semantic coordinates in the second running environment.

2. The method according to claim 1, wherein, The step of extracting semantic information from the identifier attribute, business attribute, or class name of parent nodes at several levels of the target element includes: Determine whether the target element has a valid identifier attribute; if the target element is determined to have a valid identifier attribute, extract semantic information from the identifier attribute; If it is determined that the target element does not have a valid identifier attribute, then it is determined whether the target element has a business attribute; if it is determined that the target element has a business attribute, then semantic information is extracted from the business attribute. If it is determined that the target element does not have business attributes, then traverse the parent nodes of the target element at several levels upwards to find the parent node with a semantic class name, and extract semantic information from the semantic class name.

3. The method according to claim 2, wherein, The step of determining whether the target element has a valid identifier attribute includes: Obtain the identifier attribute value of the target element; If the value of the identification attribute is empty, it is determined that it does not have a valid identification attribute; If the identification attribute value is not empty, then the preset regular expression matching rule is used to detect whether the identification attribute value conforms to the dynamic noise characteristics; If the dynamic noise characteristics are met, it is determined that it does not have a valid identification attribute; the dynamic noise characteristics include: starting with a preset frame prefix, containing continuous random hash characters, or conforming to a timestamp generation format; If it does not meet the dynamic noise characteristics, it is determined to have valid identification attributes.

4. The method according to claim 2, wherein, The business attributes include custom attributes; The extraction of semantic information from the business attributes includes: Scan the target element for custom attributes with a preset prefix; Extract semantic information from the attribute values ​​of the custom attribute.

5. The method according to claim 2, wherein, The upward traversal of the parent nodes of the target element at several levels includes: Starting from the target element, its parent nodes are obtained level by level until the preset maximum depth threshold is reached or the document root node is traversed. During the traversal, record the list of class names of the parent nodes at each level and the index of the child element positions.

6. The method according to claim 5, wherein, The process of finding the parent node with a semantic class name includes: Perform noise cleaning on the class name list of each level of parent node in the record, remove hash class names, random prefix class names and layout auxiliary class names without semantics, retain business class names with natural language semantics, and use the node corresponding to the business class name as a candidate anchor point. If a candidate anchor point exists in a certain level of parent node, then the candidate anchor point is determined as the parent node with a semantic class name.

7. The method according to claim 6, wherein, The step of extracting semantic information from the semantic class name includes: Construct a path segment from the parent node with the semantic class name through intermediate nodes to the target element; wherein, if the intermediate node in the path segment does not have a valid class name, the intermediate node is used to complete the path segment by using the index of the child element position in the list of child nodes of its parent node.

8. The method according to claim 2, wherein, Before determining whether the target element has a valid identifier attribute, the method further includes: In the first operating environment, the set of elements in the same group as the target element is analyzed, and its sequence position in the set is calculated. By combining the source code location and sequence location of the same set of elements, an instantiation enhancement identifier is generated; The instantiation enhancement identifier is injected into the custom attribute of the target element.

9. The method according to claim 8, wherein, The analysis of the set of elements in the same group as the target element includes: Based on the loop iteration metadata injected into the target element during compilation, query the set of elements in the same group as the target element.

10. The method according to claim 1, wherein, The first operating environment is an editing environment, and the second operating environment is a preview environment or a sharing environment.

11. A method for displaying structured documents, comprising: In the second operating environment, when loading the annotation information of the structured document, the semantic coordinates of the target elements associated with the annotation information are read; the semantic coordinates are associated with the storage method as described in claim 1. The semantic coordinates are used to match the elements of the structured document. If the target element is matched, the target element and the annotation information will be displayed together.

12. An element processing apparatus for a structured document, comprising: The extraction unit is used in the first operating environment to extract semantic information from the identifier attributes, business attributes or class names of parent nodes at several levels of the target element in response to the user's annotation operation on the target element of the structured document in the first operating environment. A generation unit is used to combine the semantic information extracted by the extraction unit into a selector string for locating target elements, and to use the selector string or the hash value obtained by hashing the selector string as the semantic coordinates of the target element. A storage unit is used to associate and store the semantic coordinates obtained by the generation unit with the annotation information generated by the annotation operation, so as to locate the target element in the structured document according to the semantic coordinates in the second running environment.

13. A display device for structured documents, comprising: The reading unit is configured to read the semantic coordinates of target elements associated with the annotation information when loading the annotation information of a structured document in a second operating environment; the semantic coordinates are associated with the device as described in claim 12. A matching unit is used to match each element of the structured document using the semantic coordinates; The display unit is used to associate and display the target element and the annotation information if the matching unit matches the target element.

14. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-11.

Images