Table cell style rendering method based on node attribute extension

Abstract

The invention discloses a form cell style rendering method based on node attribute extension, relates to the technical field of computer software processing, and aims to extend a node attribute model of a form cell of a rich text editor, add oblique line header attributes and multi-direction frame attributes, and render the form cell style of the rich text editor. Establishing a node attribute model with a complex style expression capability and an extended node attribute model with the complex style expression capability; receiving an HTML text sequence, converting the HTML text sequence into a document object model tree, performing depth-first traversal to extract standard attributes of cell nodes, and analyzing style features of the standard attributes to map the standard attributes to the expansion node attribute model; constructing an editor node system serving as an editor single fact source; generating rendering description according to the attribute state of the cell node in the editor node system; when the expansion attribute is detected to be an effective value, mapping the oblique line header attribute into a class name identifier for controlling pseudo element drawing, combining the multi-direction frame attributes into an inline CSS style character string, and merging to generate a final rendering tree; and in response to a user interaction instruction, executing local attribute updating.

Description

Technical Field

[0001] This invention relates to the field of computer software processing technology, and in particular to a method for rendering table cell styles based on node attribute extension. Background Technology

[0002] With the widespread adoption of rich text editing technology in online documents, collaborative office work, and content management systems, tables, as a crucial carrier of structured information, directly impact user experience and content expression capabilities due to their style complexity and editability. However, existing rich text editors generally only support basic table functions, failing to meet more complex business needs, such as diagonal headers, multi-directional asymmetrical borders, and multi-line borders. Traditional solutions often rely on the following methods to achieve complex table styles: implementing diagonal lines or special borders through nested multi-layered document object models, resulting in a cluttered page structure and significantly reduced rendering performance; using images or SVG overlays to simulate special cell styles, which is difficult to synchronize with the edited content, leading to a poor interactive experience; and styles are easily lost during copying, pasting, and content persistence, making it difficult to maintain consistency in table structure. These problems are particularly prominent in actual products, especially in scenarios requiring refined style editing and complex business document processing (such as corporate reports, questionnaire design, and teaching documents), where existing technologies are no longer sufficient. Therefore, it is necessary to provide a technical solution that can render and interact with complex table styles without changing the document object model tree, in order to solve the problems of difficulty in expressing complex table styles, poor rendering performance, and easy loss of persistent content in the existing technology.

[0003] Currently, Chinese invention patent application number CN202211037867.5 discloses a dynamic rendering method and apparatus for Swing tables. The method includes the following steps: obtaining a corresponding dynamic style file and a static style file based on the table to be rendered; executing the dynamic style file to filter and obtain cell components in the table to be rendered that meet preset filtering conditions, denoted as cell components to be rendered; configuring corresponding table style information for the cell components to be rendered based on the row and column information of the cell components to be rendered and the static style file; wherein, the static style file is used to store row and column information and the corresponding table style information. This application, based on Swing tables, dynamic style files, and static style files, filters and renders cells in the table to be rendered, achieving separation of style control code and component code, thus meeting current table rendering requirements. However, existing rich text editors suffer from drawbacks when handling complex table styles, such as performance degradation due to reliance on complex document object model trees, difficulty in persistent style saving, and poor interactive experience. Summary of the Invention

[0004] The technical problem solved by this invention is that existing rich text editors suffer from performance degradation, difficulty in persistently saving styles, and poor interactive experience when processing complex table styles due to their reliance on complex document object model trees.

[0005] To solve the above technical problems, the present invention provides the following technical solution: a table cell style rendering method based on node attribute extension, comprising the following steps: Step S1: Extend the node attribute model of the table cell in the rich text editor, add the diagonal header attribute and multi-directional border attribute, and establish an extended node attribute model with the ability to express complex styles. Step S2: Receive the HTML text sequence and convert it into a document object model tree. Extract the standard attributes of the cell nodes through depth-first traversal and parse their style features to map them to the extended node attribute model. The extracted attributes are normalized and their topology is verified to construct an editor node system that serves as the single source of facts for the editor. Step S3: Generate a rendering description based on the attribute status of the cell nodes in the editor's node system; When a valid value is detected for an extended property, the diagonal header property is mapped to a class name identifier that controls the drawing of pseudo-elements, the multi-directional border property is combined into an inline CSS style string, and the final render tree is generated. Step S4: Respond to user interaction commands, update the corresponding attribute fields in the editor node system, trigger state change detection, calculate the minimum change set by comparing the node attribute snapshots before and after the change, and perform local attribute updates.

[0006] Preferably, the node attribute model of the extended table cell specifically includes: The newly added diagonal header attribute is used to indicate whether the diagonal header effect is enabled in the table cell. The attribute field is a class name identifier used to control the style. The newly added multi-directional border attribute describes the border style, type, and width in the top, bottom, left, and right directions, and supports asymmetrical and user-customized border effects. The hierarchical structure of the node attribute model adopts a key-value pair format, which specifically includes attribute fields: column span, row span, column width, background color, diagonal header identifier, left border type, right border type, top border type, bottom border type, left border width, right border width, top border width, bottom border width, and cell vertical alignment.

[0007] Preferably, step S2 specifically includes: Step S21: Receive an externally input HTML text sequence and convert the HTML text sequence into a Document Object Model (DOM) tree using a standard HTML parser. The DOM tree serves only as a data extraction carrier and does not directly participate in the editor state construction. Step S22: Initialize the cursor pointer and context stack, perform a depth-first traversal of the document object model tree, locate the table container node, row node and cell node level by level, extract standard attributes and parse extended attributes, and encapsulate them into a structured intermediate representation after normalization. Step S23: Traverse the structured intermediate representation, instantiate editor nodes using the node factory pattern, accurately inject the extracted extended attributes into the node attribute fields, and reconstruct parent-child links according to the hierarchical relationship to reconstruct a complete editor node system that conforms to the editor specification. Step S24: Perform state verification and correction on the editor node system, and forcibly repair abnormal structures to ensure the legality of the editor node system; Step S25: Atomize the verified editor node system and insert it into the editor state, establish the editor node system as a single source of fact, identify changes and generate rendering descriptions through difference comparison algorithm, minimize the update of the document object model tree, and attach event listeners to intercept user operations and convert them into model modification instructions, thereby realizing an input-output closed loop.

[0008] Preferably, step S21 specifically includes the following sub-steps: Step S211: Receive the externally input HTML text sequence through the clipboard interface, file import interface and network transmission interface, and perform cleaning and preprocessing operations on the HTML text sequence. The cleaning and preprocessing operations include removing script tags that cause security risks, unifying the character encoding format, and filtering out illegal control characters that are not supported by the editor, so as to obtain a clean HTML text sequence to be parsed. Step S212: Call the standard HTML parser built into the runtime environment to parse the HTML text sequence to be parsed. The parsing process includes a lexical analysis stage and a syntax analysis stage. The lexical analysis phase includes: The standard HTML parser scans the HTML text sequence to be parsed, decomposes the HTML text sequence into independent tag sequences, and the tag types included in the tag sequence include start tags, end tags and text content. The start tags also include attribute names and attribute values. The parser traverses the tag sequence and creates corresponding node objects according to the tag types of the tag sequence. The syntax analysis phase includes: The standard HTML parser reads the decomposed tags, obtains the nesting relationship between the tag types according to the syntax rules of the HTML document, establishes parent-child links between node objects according to the nesting relationship, and combines all node objects and parent-child links between node objects into a document object model tree; The specific structure of the Document Object Model tree includes a root node, element nodes, and text nodes, where element nodes also include a set of associated attributes: The root node includes fragment node objects of the HTML text sequence and temporary container elements; Element nodes include table container nodes, table row group nodes, table row nodes, and cell nodes; Text nodes are obtained by merging text strings and are used to store the text content that the user can actually see, serving as child nodes of cell nodes; The attributes include standard attributes, style attributes, and custom data attributes. Each attribute set includes the element data, standard attributes, style attributes, and custom data attributes of each corresponding element node.

[0009] Preferably, step S22 specifically includes the following sub-steps: Step S221: Initialize the cursor pointer used to traverse the document object model tree in memory, and initially position the cursor pointer to the root node of the document and the highest-level container node in the current text selection area; Step S222: Initialize the context stack in memory. The context stack is a linked storage and is used to temporarily store references to table container nodes during the depth-first traversal process. Step S223: The depth-first traversal process specifically includes: The document object model tree is traversed using a cursor pointer in a depth-first manner, and the node type identifier of each node in the traversal is read. When a node type identifier is identified as a table container node identifier, the table data object is initialized in memory and pushed onto the context stack. When a node type identifier is identified as a table row node identifier, the table row data object is initialized and linked to the table data object at the top of the current context stack. When the node type identifier is identified as a cell node identifier, the cell attribute extraction process begins. The cell attribute extraction process includes the following sub-steps: Step S2231: Read the standard HTML attributes of the identified cell nodes. The reading logic specifically includes: When reading the colspan attribute value, convert the colspan attribute value to an integer type to record the number of columns that the cell spans horizontally; When reading the rowspan attribute value, convert the rowspan attribute value to an integer type to record the number of rows that the cell spans vertically; When reading the width and colwidth properties, the values ​​of the width and colwidth properties are parsed to determine the display width of the cell; If the values ​​for the colspan, rowspan, width, and colwidth attributes are all absent, default values ​​will be assigned according to the preset rules, which stipulate that the span is 1 by default. Step S2232: Parsing the attributes of the diagonal header includes: Check the class name list of the current cell node, compare the read class name string with the preset slash style identifier. If the class name string and the slash style identifier are exactly the same, it means that the match is successful, and set the slash header enable status field to a valid value. If the class name string and the slash style identifier are not exactly the same, it indicates a match failure, and the slash header enable status field is set to empty; Parsing the multi-directional border properties includes: Read the style attribute string of the cell node, use a string parsing algorithm to cut the style attribute string into multiple style declaration fragments with semicolons as delimiters, traverse the style declaration fragments, filter out the declarations with the attribute name border and those starting with border-, get the border declarations in each direction, parse the value of the border declaration, identify and separate the substrings representing line width, line type and color, map the separated line width value to the width attribute field, and map the line type value to the type attribute field; If the border definition required by the user is not found in the style property string, check if the corresponding CSS class name exists. Step S2233: Normalization process specifically includes: After extracting the raw data, all attribute values ​​are normalized. For pixel value strings, the numerical value and unit are separated. If the unit is missing, it is filled with px by default. If the unit is not px, the original unit string is retained or it is converted into a px value according to the font measurement of the current context. Convert color values ​​to a standard hexadecimal format; Perform null value validation on missing attributes and fill in the default border type and preset default line width; Step S2234: Summarize all the attributes and extended attributes extracted and processed in the above steps. The attributes include column span, row span, and column width. The extended attributes include diagonal header identifier, left border type, right border type, top border type, bottom border type, left border width, right border width, top border width, bottom border width, and cell vertical alignment. Instantiate a key-value pair collection object in memory and write the above properties with predefined key names respectively; The encapsulated cell nodes are appended to the list of child nodes of the table row data object at the top of the current context stack according to their original order in the document object model tree. When the traversal of the table row nodes is finished, the table row data object is appended to the table data object, and the structured intermediate representation is output.

[0010] Preferably, step S23 includes the following sub-steps: Step S231: Traverse the structured intermediate representation generated in step S22, read the type identifier of each intermediate representation object in the structured intermediate representation, use the node factory pattern of the editor core to find the corresponding node definition pattern according to the type identifier, and call the constructor to instantiate the specific editor node instance in memory; Type identifiers include tables, table rows, and cells; When the type is identified as cell, a cell node instance is created for full editing. The cell node instance includes cell node data and inherits the prototype methods defined by the editor. Step S232: Perform attribute injection operation on each newly created cell node instance, mapping the extended attributes extracted from the intermediate representation object to the node attribute fields of the editor node instance; Attribute injection operations specifically include diagonal header injection and multi-directional border injection: The diagonal header injection includes: assigning the value of the diagonal header enable status field in the intermediate representation object to the property of the same name in the editor node instance; if the diagonal header enable status field in the intermediate representation object is empty, then initializing the node property field to the disabled status value. Multi-directional border injection includes: according to the four dimensions of top, bottom, left, and right, the extracted border type, border width, and border color are written into the style attribute set of the editor node instance to form a key-value pair storage structure. Step S233: Reconstruct the parent-child links between nodes based on the hierarchical relationships recorded in the updated structured intermediate representation; Add the filled cell node instances to the child node list of the table row node instances in sequence, and then add the table row node instances to the child node list of the table node instances to obtain the editor node system.

[0011] Preferably, step S24 specifically includes the following sub-steps: Step S241: Check the diagonal header attribute value of each cell node instance, compare the diagonal header attribute value with the predefined allowed style whitelist, and if the diagonal header attribute value exceeds the range of the allowed style whitelist, reset the diagonal header attribute value to the default value, which is to not display the diagonal. Step S242: Check the border definitions in each direction in the node attribute fields: When the direction defines the border width but the border type is missing, it will be padded with a solid line by default. If a border color is missing, it will be filled with the default border color. When the border width is zero or the border type is none, clean up the corresponding redundant color and style data. Step S243: Perform topology calculation on the overall grid structure of the table. The topology calculation includes rectangle integrity verification and overlap detection. Rectangular integrity verification includes: calculating whether the table forms a complete rectangular grid based on the column span and row span attributes and the mathematical properties of rectangles; Overlap detection includes detecting whether multiple cell node instances overlap spatially; When a complete rectangular grid is not formed or multiple cell node instances overlap in space, it indicates a structural anomaly. By splitting the erroneous merged cells and filling in the missing placeholder cells, the table is forced to restore to a normal grid structure.

[0012] Preferably, step S25 specifically includes the following sub-steps: Step S251: The editor inserts the verified and corrected complete table's editor node system as an atomic operation into the current document's editor state, updating the virtual document tree inside the editor; Step S252: Establish the editor node system as a single source of fact, establish a one-way dependency mechanism, define the view layer as a pure function mapping of the model layer, prohibit bypassing the editor node system to directly modify the document object model tree, and all style changes must be carried out in the order of modifying the node attribute fields in the editor node system, and then the model changes triggering view updates. Step S253: Trigger differentiated rendering. When the state of the editor node system changes, the editor kernel triggers an update event. The view layer receives the difference between the new virtual document tree and the old virtual document tree, identifies that only the table part has changed, and generates the corresponding HTML tags, class names and styles through the renderer according to the extended attributes in the editor node system. The document object model tree in the browser is updated, so as to present a table with complex styles on the screen. Step S254: Establish input / output closed-loop listening. At the same time as rendering is completed, attach event listeners to the nodes of the document object model tree. When the user performs an operation on the interface, the operation is intercepted and converted into an instruction to modify the model properties.

[0013] Preferably, the view rendering mechanism in step S3 specifically includes: The view rendering mechanism specifically includes: Step S31: The rendering layer obtains the editor node instance corresponding to the target table cell from the current editor node system, and reads the node attribute fields stored in the editor node instance. The node attribute fields include attributes and extended attributes. Step S32: Obtain the editor node system of the current table cell, and determine whether special styles are enabled based on the node attribute fields in the editor node system. The special styles include diagonal headers and multi-directional borders. When special styles are not enabled, the standard rendering process is executed directly. When a special style is enabled, the rendering layer traverses the extended properties in the editor node instance and checks whether the enabled status field of the slash header stores a valid class name identifier. If it does, the standard rendering process is executed. Check the multi-directional border properties to determine if there are any valid non-default values ​​for the border type, border width, and border color fields in the left, right, top, and bottom directions. If so, execute the standard rendering process. Step S33: When the slash header enable status field is a valid value, the rendering layer maps the value of the slash header enable status field to the class name identifier of the document object model element; When a valid border definition exists, the rendering layer combines the border type, border width, and border color in each direction to generate an inline CSS style string that conforms to CSS syntax (style="border-top: 1px solid red;"). Combine the class name identifier and the inline CSS style string to form the rendering description; Step S34: The rendering layer maps the calculated class name identifier and inline CSS style string to the style identifier of the document object model node. The mapping process includes: By comparing the new virtual document tree and the old virtual document tree using a difference comparison algorithm, cell nodes whose attributes have changed are identified. The generated rendering description is applied to the document object model tree in the browser. This process only modifies the properties and styles of the corresponding document object model elements, without re-rendering the entire table or document. Step S35: The browser's style engine parses the HTML to build the Document Object Model (DOM) tree and parses the CSS to build the CSSOM tree. The DOM tree and CSSOM tree are then merged to generate the render tree.

[0014] Preferably, step S4 includes: Step S41: The user triggers an interactive command through the editor interface. The interactive command can be triggered by the user clicking a function button located in the toolbar or table style settings panel. The state change process includes interactive commands that directly modify the diagonal header enable state field and multi-directional border attribute in the editor node instance. The editor kernel captures this data change and broadcasts the state change event. Step S42: The renderer performs snapshot comparison, description recalculation, and minimizes changes based on the state change event; Snapshot comparison includes: comparing snapshots of node attribute fields before and after the change, and identifying the types and scope of the changed attributes; The description recalculation includes: after detecting a change in a node attribute field, the renderer recalculates the rendering description information corresponding to the target node based on the node attributes and the view rendering mechanism; Minimizing changes includes: determining, through a minimum change set calculation mechanism, that the current state update only involves attribute changes to the target cell node; Step S43: The view layer updates the attributes of the document object model tree element corresponding to the target cell according to the latest rendering description. The browser style engine automatically triggers the style recalculation process and synthesizes the new rendering result to the page display layer. Step S43 specifically includes the following sub-steps: Step S431: The view layer performs a synchronous update operation at the document object model level, and the browser engine takes over subsequent rendering. Step S432: The view layer updates the attributes of the document object model element corresponding to the target cell based on the latest rendering description information. The update operation specifically includes: Update the class name identifier of the element, and add or remove the class identifier of the slash header; Synchronously update the custom data attributes associated with this state; Keep the original node structure of the document object model tree unchanged, and do not introduce any additional child nodes; Step S433: After updating the attributes of the elements in the Document Object Model tree, the browser engine automatically triggers a style recalculation process, which specifically includes: Match the current document object model tree elements to the new CSS selector rule; The browser engine generates a new rendering result based on this selector rule, using pseudo-element drawing to generate the visual effect of a diagonal table header.

[0015] The beneficial effects of this invention are as follows: This invention can achieve complex table styles without changing the Document Object Model (DOM) tree, avoiding the structural redundancy and rendering performance degradation problems caused by nested multi-layered DOM models in traditional solutions. Styles are expressed through an attribute model, which can be persistently saved, parsed, and restored, effectively avoiding content loss during copying, pasting, and persistence. It enables the expansion of the node attribute model, allowing for easy expansion of more cell visual effects in the future, and has broad application value. It supports a WYSIWYG interactive experience; the command-driven state change model makes operation intuitive and feedback timely, and does not damage the selection area, cursor, or text structure during style switching. The renderer only performs mapping based on model changes and does not participate in business logic judgments, reducing front-end computational costs and improving system stability. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a table cell style rendering and interaction method based on node attribute extension, provided in an embodiment of the present invention. Detailed Implementation

[0017] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0018] Reference Figure 1 As an embodiment of the present invention, a method for rendering table cell styles based on node attribute extension is provided, comprising the following steps: Step S1: Extend the node attribute model of the table cell in the rich text editor, add the diagonal header attribute and multi-directional border attribute, and establish an extended node attribute model with the ability to express complex styles. Step S2: Receive the HTML text sequence and convert it into a document object model tree. Extract the standard attributes of the cell nodes through depth-first traversal and parse their style features to map them to the extended node attribute model. The extracted attributes are normalized and their topology is verified to construct an editor node system that serves as the single source of facts for the editor. Step S3: Generate a rendering description based on the attribute status of the cell nodes in the editor's node system; When a valid value is detected for an extended property, the diagonal header property is mapped to a class name identifier that controls the drawing of pseudo-elements, the multi-directional border property is combined into an inline CSS style string, and the final render tree is generated. Step S4: Respond to user interaction commands, update the corresponding attribute fields in the editor node system, trigger state change detection, calculate the minimum change set by comparing the node attribute snapshots before and after the change, and perform local attribute updates.

[0019] Through the above mechanism, this invention implements a command-driven state change model at the interaction level, where all style changes are completed through node attributes, avoiding direct manipulation of the document object model; rendering and logic are decoupled, with the renderer only performing mapping based on model changes and not participating in business judgments; browser native rendering collaboration fully utilizes the style engine to complete visual drawing, reducing front-end computing costs; and the stability of the editing experience, without destroying the selection area, cursor, and text structure during style switching.

[0020] The extended table cell node attribute model specifically includes: The newly added diagonal header attribute is used to indicate whether the diagonal header effect is enabled in the table cell. The attribute field is a class name identifier used to control the style. The newly added multi-directional border attribute describes the border style, type, and width in the top, bottom, left, and right directions, and supports asymmetrical and user-customized border effects. The hierarchical structure of the node attribute model adopts a key-value pair format, which specifically includes attribute fields: column span, row span, column width, background color, diagonal header identifier, left border type, right border type, top border type, bottom border type, left border width, right border width, top border width, bottom border width, and cell vertical alignment.

[0021] This model structure enables cells to express complex styles, and its attribute hierarchy is clear, making it easy to expand and maintain.

[0022] In this embodiment, the core lies in extending the attributes of the table cell nodes of the rich text editor, enabling them to carry complex style information. The extended attributes specifically include the diagonal header attribute and the multi-directional border attribute. The diagonal header attribute is used to indicate whether the cell has diagonal lines enabled. This attribute is defined as a specific field (lineClass), whose value corresponds to the style class name used during front-end rendering. The multi-directional border attribute is used to support asymmetrical and personalized border effects, including border types and line width attributes in four directions: top, bottom, left, and right. Specifically, it includes left border type, right border type, top border type, bottom border type, and corresponding left border width, right border width, top border width, and bottom border width. The node attribute model uses a key-value pair data format (JSON object). Its hierarchical structure includes a node type identifier (tableCell) and an attribute set. The attribute set includes basic attributes such as column span, row span, column width, and background color, as well as the newly added diagonal header identifier and detailed parameters for borders in each direction. This model structure serves as the sole data source within the editor, enabling cells to express complex styles and supporting subsequent editing, rendering, and state management.

[0023] By explicitly defining the specific fields (such as lineClass and borderTopWidth) and their hierarchical structure of extended attributes, cells are able to express complex styles such as diagonal headers and multi-directional asymmetrical borders. This clear key-value pair structure not only facilitates data storage and parsing but also provides a flexible interface for future expansion of more style attributes, enhancing the system's maintainability and scalability.

[0024] Step S2 specifically includes: Step S21: Receive the HTML text sequence from external input, and convert the HTML text sequence into a Document Object Model (DOM) tree using a standard HTML parser. The DOM tree only serves as a data extraction carrier and does not directly participate in the editor state construction. Step S22: Initialize the cursor pointer and context stack, perform a depth-first traversal of the document object model tree, locate the table container node, row node and cell node level by level, extract standard attributes and parse extended attributes, and encapsulate them into a structured intermediate representation after normalization. Step S23: Traverse the structured intermediate representation, instantiate editor nodes using the node factory pattern, accurately inject the extracted extended attributes into the node attribute fields, and reconstruct parent-child links according to the hierarchical relationship to reconstruct a complete editor node system that conforms to the editor specification. Step S24: Perform state verification and correction on the editor node system, and forcibly repair abnormal structures to ensure the legality of the editor node system; Step S25: Atomize the verified editor node system and insert it into the editor state, establish the editor node system as a single source of fact, identify changes and generate rendering descriptions through difference comparison algorithm, minimize the update of the document object model tree, and attach event listeners to intercept user operations and convert them into model modification instructions, thereby realizing an input-output closed loop.

[0025] The parsing process follows the HTML5 specification, ensuring that the generated Document Object Model (DOM) tree conforms to the browser's parsing rules in structure. This DOM tree serves only as a carrier for subsequent data extraction and does not directly participate in the editor state construction, thus guaranteeing the stability and universality of the parsing process.

[0026] This embodiment describes the data parsing and state restoration process from HTML text to the editor node system. The complete data parsing and state restoration process is divided into five stages: parsing HTML text into a Document Object Model (DOM) tree, converting the DOM tree into a structured intermediate representation, mapping the intermediate representation to the editor node system, verifying and correcting the state of the editor node system, and driving rendering and editing using the editor node system. This process ensures the consistency between the editor's internal state and the HTML content, guaranteeing the style integrity of the content during storage, copying, and importing.

[0027] By defining a complete data parsing and state restoration process from HTML text to the editor's node system, it is ensured that external data can be accurately converted into a recognizable and operable model state within the editor. This effectively solves the problem of style loss during data transmission in traditional solutions, guaranteeing the consistency and integrity of the content.

[0028] Step S21 specifically includes the following sub-steps: Step S211: Receive the externally input HTML text sequence through the clipboard interface, file import interface and network transmission interface, and perform cleaning and preprocessing operations on the HTML text sequence. The cleaning and preprocessing operations include removing script tags that cause security risks, unifying the character encoding format, and filtering out illegal control characters that are not supported by the editor, so as to obtain a clean HTML text sequence to be parsed. Step S212: Invoke the standard HTML parser built into the runtime environment (browser engine and server-side rendering engine) to parse the HTML text sequence to be parsed. The parsing process includes a lexical analysis stage and a syntax analysis stage. The lexical analysis phase includes: The standard HTML parser scans the HTML text sequence to be parsed, decomposes it into independent tag sequences, and the tag types included in the tag sequence include start tags, end tags and text content. The start tags also include attribute names and attribute values. The parser traverses the tag sequence and creates corresponding node objects according to the tag types in the tag sequence. In the syntax analysis phase of step S212, the standard HTML parser executes a tree-building algorithm that maintains an open element stack. When the parser receives a start tag from the lexical analysis phase, it creates a corresponding DOM element node object based on the tag name. If the tag contains a list of attributes, the parser populates the attribute key-value pairs into the attribute set of the newly created node object. Subsequently, the parser pushes the node object onto the open element stack and attaches it to the child node list of the current top element, thus establishing parent-child links. When a text tag is received, the parser creates a text node and inserts it into the current node. When an end tag is received, the parser pops the corresponding element from the stack, completing the construction of the node and its subtree.

[0029] The syntax analysis phase includes: The standard HTML parser reads the decomposed tags, obtains the nesting relationship between the tag types according to the syntax rules of the HTML document, establishes parent-child links between node objects according to the nesting relationship, and combines all node objects and parent-child links between node objects into a document object model tree; The specific structure of the Document Object Model tree includes a root node, element nodes, and text nodes, where element nodes also include a set of associated attributes: The root node includes fragment node objects of the HTML text sequence and temporary container elements; Element nodes include table container nodes, table row group nodes, table row nodes, and cell nodes; Text nodes are obtained by merging text strings and are used to store the text content that the user can actually see, serving as child nodes of cell nodes; The attributes include standard attributes, style attributes, and custom data attributes. Each attribute set includes the element data, standard attributes, style attributes, and custom data attributes of each corresponding element node.

[0030] During the syntax analysis phase, the standard HTML parser automatically handles common HTML syntax errors such as non-closed tags and incorrect nesting order, and uses a fault-tolerance mechanism to correct malformed HTML fragments into a compliant tree structure.

[0031] Fault tolerance mechanisms include tag auto-completion, fostering mechanism, formatted element reconstruction, attribute normalization, and forced construction of root element; The syntax rules for HTML documents are based on the existing standard document syntax rule library. The root node, as a container for the entire tree, is usually a document fragment object or a temporary container element (DIV container). It is not directly mounted to the rendering tree of the current page, but floats in memory as the entry point for data extraction. The element nodes are the main nodes that form the tree skeleton, corresponding to HTML tags. In the table scenario of this embodiment, the table container node corresponds to the table tag, which is located at the top of the hierarchy and contains the global style attributes such as the width and height of the entire table. The table row group node corresponds to the table header, table body and table footer tags, which are used to logically group the rows. The table row node corresponds to the row tag, which is the direct parent container of the cell and determines the horizontal arrangement order of the cells. The cell node corresponds to the standard cell and the table header cell tag. It is the most core leaf node container in this invention. It encapsulates the specific text content and the style attributes to be extracted. The style attributes include the diagonal table header identifier and the border style. Text nodes are located inside cell nodes and store the text content that the user can actually see. Standard HTML parsers merge consecutive text characters into a single text node, which exists as a child node of the cell node. Standard attributes include the number of columns spanned, the number of rows spanned, and the width value; The style properties are inline CSS strings stored in the style property, which is the key source for extracting the multi-directional border properties; Custom data attributes are those prefixed with "data-" and are used to store business logic states, including the enabled status of diagonal headers and the border effects of multi-directional border attributes.

[0032] The generated document object model tree is not a flat data collection, but a logical tree with strict hierarchical relationships; The document object model tree generated during the above parsing process is strictly confined to a temporary buffer in memory, and it is physically isolated from the main document object model tree that the editor is currently displaying to the user.

[0033] The parsing process does not trigger a browser repaint or reflow of the main page, avoiding page flickering or performance fluctuations. The Document Object Model (DOM) tree serves only as temporary intermediate processing data, used to convert unstructured strings into a traversable object graph. Once subsequent steps have extracted the required business data (structured intermediate representation) from it, the tree structure is destroyed or garbage collected, retaining no state references, thus ensuring the purity and stability of the editor's core data model.

[0034] By leveraging the lexical and syntactic analysis capabilities of a standard HTML parser, combined with error-tolerance mechanisms, external HTML text from diverse sources, potentially containing formatting errors, can be reliably converted into a canonical Document Object Model (DOM) tree. This not only improves the system's compatibility and robustness but also avoids impacting the main page's rendering performance through memory isolation mechanisms.

[0035] Step S22 specifically includes the following sub-steps: Step S221: Initialize the cursor pointer used to traverse the document object model tree in memory, and initially position the cursor pointer to the root node of the document and the highest-level container node in the current text selection area; Step S222: Initialize the context stack in memory. The context stack is a linked storage and is used to temporarily store references to table container nodes during the depth-first traversal process. The context stack is used to maintain the parent-child nesting relationship of data structures during the transformation process.

[0036] Step S223: The depth-first traversal process specifically includes: The document object model tree is traversed using a cursor pointer in a depth-first manner, and the node type identifier of each node in the traversal is read. When a node type identifier is identified as a table container node identifier, the table data object is initialized in memory and pushed onto the context stack. When a node type identifier is identified as a table row node identifier, the table row data object is initialized and linked to the table data object at the top of the current context stack. When the node type identifier is identified as a cell node identifier, the cell attribute extraction process begins. The cell attribute extraction process includes the following sub-steps: Step S2231: Read the standard HTML attributes of the identified cell nodes. The reading logic specifically includes: When reading the colspan attribute value, convert the colspan attribute value to an integer type to record the number of columns that the cell spans horizontally; When reading the rowspan attribute value, convert the rowspan attribute value to an integer type to record the number of rows that the cell spans vertically; When reading the width and colwidth properties, the values ​​of the width and colwidth properties are parsed to determine the display width of the cell; If the values ​​for the colspan, rowspan, width, and colwidth attributes are all absent, default values ​​will be assigned according to the preset rules, which stipulate that the span is 1 by default. Step S2232: Parsing the attributes of the diagonal header includes: Check the class name list of the current cell node, compare the read class name string with the preset slash style identifier. If the class name string and the slash style identifier are exactly the same, it means that the match is successful, and set the slash header enable status field (lineClass) to a valid value. If the HTML text does not contain slash information, the slash header enable status field will be empty, and the editor will treat it as a normal cell, ensuring compatibility with standard HTML. If the class name string and the slash style identifier are not exactly the same, it indicates a match failure, and the slash header enable status field is set to empty; Parsing the multi-directional border properties includes: Read the style attribute string of the cell node, and use a string parsing algorithm to split the style attribute string into multiple style declaration fragments using semicolons as delimiters; Iterate through style declaration fragments, filtering out declarations with the property name "border" and those starting with "border-". For the filtered declarations, execute the mapping resolution logic, which specifically includes: The direction is determined by the suffix of the attribute name; for example, border-top corresponds to the top border. The attribute value string (e.g., "1px solid red") is split by spaces, and regular expressions are used to identify each component. Values ​​containing "px" or "em" units are identified as line width, those matching the keywords "solid" or "dashed" are identified as line type, and those matching hexadecimal and "rgb" formats are identified as color. The parsed line width, line type, and color are assigned to the corresponding independent fields in the extended node property model. For example, from "border-top: 1px solid red", "1px" is parsed and assigned to the top border width field (borderTopWidth), "solid" is assigned to the top border type field (borderTopType), and "red" is assigned to the top border color field (borderTopColor). Similarly, the bottom, left, and right directions are parsed independently, thus converting the CSS standard shorthand properties into 12 independent properties in the model, achieving precise control over asymmetrical borders.

[0037] Get the border declarations in each direction, parse the values ​​of the border declarations, identify and separate the substrings representing the line width (1px), line style (solid, dashed, double) and color, map the separated line width values ​​to the width property field (borderTopWidth), and map the line style values ​​to the type property field (borderTopType). If the border definition required by the user is not found in the style property string, check if there is a corresponding CSS class name to ensure that border information is fully captured from multiple possible storage formats. Iterate through style declaration fragments, first looking for shorthand properties with border as the key name. If they exist, parse their values ​​and apply them to the default border settings in the top, bottom, left, and right directions. Filter out declarations with the property name "border" and those starting with "border-" to override the settings for the corresponding direction; When parsing the value of the border declaration, a regular expression matching extraction algorithm is used instead of simple space splitting. Specifically, this includes: firstly, using regular expressions to match and extract the color function within the brackets (e.g., rgb(0, 0, 0) or rgba(...)), and then temporarily storing it as a whole; Split the remaining string using spaces as the delimiter; Step S2233: Normalization process specifically includes: After extracting the raw data, all attribute values ​​are normalized. For pixel value strings, the numerical value and unit are separated. If the unit is missing, it is filled with px by default. If the unit is not px (em, rem, pt), the original unit string is retained or it is converted into a px value according to the font measurement of the current context. Convert color values ​​to a standard hexadecimal format; Perform null value validation on missing attributes, and fill in the default border type (no border) and preset default line width according to the initial default editor configuration to ensure that the generated intermediate data is complete and usable.

[0038] Step S2234: Summarize all the attributes and extended attributes extracted and processed in the above steps. The attributes include column span, row span, and column width. The extended attributes include diagonal header identifier, left border type, right border type, top border type, bottom border type, left border width, right border width, top border width, bottom border width, and cell vertical alignment. Instantiate a key-value pair collection object (JSON object) in memory, and write the above properties with predefined key names respectively; The encapsulated cell nodes are appended to the list of child nodes of the table row data object at the top of the current context stack according to their original order in the document object model tree. When the traversal of the table row nodes is finished, the table row data object is appended to the table data object, and the structured intermediate representation is output.

[0039] The property name is border and the declarations that begin with border- include border-top, border-bottom, border-left, and border-right, with the directions being top, bottom, left, and right, respectively.

[0040] The relationship between style declaration fragments and border declarations includes the relationship between sets and subsets, as well as the relationship between filters and those being filtered. The relationship between sets and subsets specifically includes: A style declaration fragment is a collection as a whole. A style declaration fragment refers to all the independent CSS property definition units obtained by cutting the inline style string of the cell node (such as style="color:red; border-top:1px solid; width:100px") with semicolons ";". It contains all the styles defined on the cell, such as font color, background color, width, height and border. Border declarations are a subset. A border declaration refers to only those specific fragments in all style declaration fragments whose property names begin with "border-", which contain only the multi-directional border style data of interest in this invention.

[0041] The relationship between screening and being screened specifically includes: The style declaration fragments are used as the input source. All style declaration fragments are obtained through a string splitting algorithm. This is the first step in data extraction, and its purpose is to discretize long strings. Border declarations are the result of filtering. All the style declaration fragments mentioned above are traversed, and character matching checks are performed using the keyword border-. Only fragments that meet the conditions will be recognized as border declarations and enter the subsequent parsing process (separating line width, line type, and color).

[0042] In this embodiment, for example, the style string of the cell is: style="color:#333;border-top:1px solid red;font-size:14px;border-left:2px dashed blue;" After cutting, the style declaration fragments are obtained: color:#333, border-top:1px solid red, font-size:14px, and border-left:2px dashed blue; After filtering, the border declarations are: border-top: 1px solid red and border-left: 2px dashed blue. Predefined key names such as lineClass and borderLeftType; The final Document Object Model (DOM) tree is a tree-like intermediate representation of data that fully describes the table structure and style. The aim is to reduce the visual representation on the DOM to the logical properties within the editor.

[0043] String parsing algorithms specifically include: Use semicolons as delimiters to split the inline style string into multiple independent arrays of style declaration strings; Iterate through the array and use regular expressions or string matching to filter out declarations whose property names begin with "border-".

[0044] For each selected border declaration, the attribute name and attribute value are separated by a colon. The attribute value portion is further split using spaces as delimiters.

[0045] Iterate through the split attribute value items and identify each element using a predefined pattern: Line width matches strings that contain numbers and end with the unit px or em (e.g., 1px). Line type matching is a predefined set of line type keywords (such as solid, dashed, dotted). Color matching hexadecimal codes, RGB / RGBA functions, and standard color names; The mapping process assigns the identified line width, line type, and color values ​​to the corresponding fields (such as borderTopWidth, borderTopType, and borderTopColor) in the intermediate representation object.

[0046] The hierarchical approach includes a depth-first traversal process following the parent-child hierarchy of the document object model tree, proceeding from the outside in and from top to bottom. Specifically, the depth-first traversal process strictly follows the logical order of the table container, table rows, and cells. The specific hierarchical breakdown includes: The first level is for locating the table container. The traversal cursor starts from the root node (document fragment), searches for and locates the table container node. At this level, the existence of the entire table is identified, and the context of the traversal is established. The second level involves traversing the table rows, entering the table container node, traversing its child node list, ignoring unstructured nodes, and accurately locating the table row node. At this level, a row index is created to determine the vertical position of the data. The third level is to locate the cell, enter the interior of each table row node, traverse the child nodes of that row, locate the cell node, and at this level, create the column index to determine the position of the data in the horizontal direction; By using this progressive traversal method, not only can the cell attributes (diagonal lines, borders) be extracted, but the spatial coordinate relationship of the cell can also be implicitly captured at the same time (i.e., which row and which column it is), thereby ensuring that the final generated structured intermediate representation can accurately restore the two-dimensional grid structure of the table, rather than just scattered data points.

[0047] By employing depth-first traversal and a context stack mechanism, efficient scanning and data extraction of the document object model tree are achieved. In particular, the step-by-step extraction of cell attributes and string parsing algorithms can accurately separate the detailed parameters of multi-directional borders from complex inline style strings, ensuring that complex style data is completely and accurately captured and converted into a structured intermediate representation.

[0048] Step S23 includes the following sub-steps: Step S231: Traverse the structured intermediate representation generated in step S22, read the type identifier of each intermediate representation object in the structured intermediate representation, use the node factory pattern of the editor core to find the corresponding node definition pattern according to the type identifier, and call the constructor to instantiate the specific editor node instance in memory; Type identifiers include tables, table rows, and cells; When the type is identified as cell, a cell node instance is created for full editing. The cell node instance includes cell node data and inherits the prototype methods defined by the editor. Step S232: Perform attribute injection operation on each newly created cell node instance, mapping the extended attributes extracted from the intermediate representation object to the node attribute fields of the editor node instance; Attribute injection operations specifically include diagonal header injection and multi-directional border injection: The diagonal header injection includes: assigning the value of the diagonal header enable status field in the intermediate representation object to the property of the same name in the editor node instance; if the diagonal header enable status field in the intermediate representation object is empty, then initializing the node property field to the disabled status value. Multi-directional border injection includes: according to the four dimensions of top, bottom, left, and right, the extracted border type, border width, and border color are written into the style attribute set of the editor node instance, forming a strongly typed key-value pair storage structure to ensure that each style dimension has an independent storage field and does not interfere with each other; Step S233: Reconstruct the parent-child links between nodes based on the hierarchical relationships recorded in the updated structured intermediate representation; Add the filled cell node instances to the child node list of the table row node instances in sequence, and then add the table row node instances to the child node list of the table node instances to obtain the editor node system.

[0049] The specific process of instantiating a concrete editor node instance in memory by calling the constructor includes: Based on the node definition pattern, an independent, operable editor node object representing a specific document element (a table cell) is created in the computer's dynamic random access memory by executing an initialization program code called a constructor. A constructor is a special piece of program code whose sole responsibility is to initialize a newly created object; When the node factory pattern in step S231 determines that a cell node needs to be created, it will find and execute the constructor code that is bound to the cell node type. Memory refers to the computer's RAM, which is where data is temporarily stored during program execution; Instantiation represents the process of transforming a node definition pattern into an editor node instance. The node definition pattern describes what attributes a node should have. The editor node instance includes all attribute data (slashes, borders) injected from the structured intermediate representation, as well as common methods inherited from the editor definition, such as those used to handle user selections and respond to editing commands. This makes it an object that the editor's core logic can directly manipulate. According to the requirements of the constructor, the operating system allocates a contiguous block of memory with a unique address. This space is large enough to accommodate all the attributes specified in the node definition pattern. If there are 10 cells in the document, 10 independent instances will be created, each with its own memory address and independent attribute values; It describes a dynamic creation process that reads the node definition pattern, executes the constructor assembly instructions, and builds independent editor node instances with complete data and functions in computer memory. These editor node instances will eventually be assembled into a complete document model tree.

[0050] Ultimately, this forms a complete editor node system that conforms to the editor's internal data structure specifications.

[0051] By employing the node factory pattern and attribute injection mechanism, the structured intermediate representation is transformed into fully functional editor node instances. This achieves a qualitative change in data from a transmission state to an editing state, enabling the extracted style data to be more than just a static display; it becomes a dynamic attribute that can be directly manipulated and modified by the editor's core logic, laying the foundation for subsequent interactive editing.

[0052] Step S24 specifically includes the following sub-steps: Step S241: Check the diagonal header attribute value of each cell node instance, compare the diagonal header attribute value with the predefined allowed style whitelist, and if the diagonal header attribute value exceeds the range of the allowed style whitelist, reset the diagonal header attribute value to the default value, which is to not display the diagonal. To prevent CSS injection attacks or rendering errors; Step S242: Check the border definitions in each direction in the node attribute fields: When the direction defines the border width but the border type is missing, it will be padded with a solid line by default. If a border color is missing, it will be filled with the default border color. When the border width is zero or the border type is none, clean up the corresponding redundant color and style data. Keep the editor's node system simple; Step S243: Perform topology calculation on the overall grid structure of the table. The topology calculation includes rectangle integrity verification and overlap detection. Rectangular integrity verification includes: calculating whether the table forms a complete rectangular grid based on the column span and row span attributes and the mathematical properties of rectangles; Overlap detection includes detecting whether multiple cell node instances overlap spatially; When a complete rectangular grid is not formed or multiple cell node instances overlap in space, it indicates a structural anomaly. By splitting the erroneous merged cells and filling in the missing placeholder cells, the table is forced to restore to a normal grid structure.

[0053] A normal mesh structure is an overall mesh structure without any structural anomalies.

[0054] Through state verification and correction mechanisms (such as whitelist comparison, default value completion, and topology calculation), a rigorous security check is performed before data enters the editor's core state. This effectively prevents illegal data (such as CSS injection attacks) or structural anomalies (such as incorrectly merged cells) from causing the editor to crash or rendering errors, significantly improving the system's security and stability.

[0055] The rectangle integrity check specifically includes: establishing a virtual two-dimensional Boolean matrix based on the column span and row span attributes, and marking the occupied coordinate points; Overlap detection includes detecting whether multiple cell node instances attempt to occupy the same coordinate point in the matrix; When a complete rectangular grid is not formed (holes exist in the matrix) or overlaps occur, a repair strategy is executed. The repair strategy includes: For overlapping areas, retain the span of the cell that appears earlier in the DOM order and truncate the overlapping span of subsequent cells; for matrix holes (missing placeholder cells), insert blank cell nodes with only basic attributes into the corresponding row nodes to fill them until the matrix is ​​full, forcing the table to return to a normal grid structure.

[0056] Step S25 specifically includes the following sub-steps: Step S251: The editor inserts the verified and corrected complete table's editor node system as an atomic operation into the current document's editor state, updating the virtual document tree inside the editor; This step aims to securely integrate the completed static data model into the dynamic editor runtime environment; The editor kernel creates a transaction object containing the newly generated table editor node system. This transaction object encapsulates the intent to modify the document structure, ensuring the atomicity of the operation. That is, the modification either succeeds completely or is rolled back completely, preventing intermediate states of inconsistent document status. The editor state manager receives the transaction object and applies it to the current editor state. If the current operation is paste or import, the content within the current selection is replaced with the new table editor node system; if the current operation is initialization, the root document is populated with the current transaction object. As the editor's state is updated, the virtual document tree maintained internally by the editor synchronously completes the insertion and linking of nodes. At this point, the nodes with diagonal headers and multi-directional border attributes have officially become part of the editor's core data.

[0057] Step S252: Establish the editor node system as a single source of fact, establish a one-way dependency mechanism, define the view layer as a pure function mapping of the model layer, prohibit bypassing the editor node system to directly modify the document object model tree, and all style changes must be carried out in the order of modifying the node attribute fields in the editor node system, and then the model changes triggering view updates. This step defines the data flow architecture to ensure data consistency and maintainability, specifically including: The one-way dependency mechanism is as follows: at the architecture level, the view layer is defined as a pure function mapping of the model layer (View = f(Model)). This means that for any given editor node system state, the view layer must and can only generate a uniquely determined document object model tree structure. Block or intercept any operations that bypass the editor's node system and directly modify the browser's document object model tree. For example, prohibit changing the border color of cells by directly manipulating the document object model API. Establish a unique style change path, meaning that all style change requests (such as a user clicking a toolbar button) must first be converted into modifications to node attribute fields in the editor's node system (such as modifying the value of the lineClass field), and then the view update is driven by the change in the model state.

[0058] Step S253: Trigger differentiated rendering. When the state of the editor node system changes, the editor kernel triggers an update event. The view layer receives the difference between the new virtual document tree and the old virtual document tree, identifies that only the table part has changed, and generates the corresponding HTML tags, class names and styles through the renderer according to the extended attributes in the editor node system. The document object model tree in the browser is updated, so as to present a table with complex styles on the screen. This step is the core execution stage for transforming the logical model into a visual representation, and specifically includes: Once the state of the editor node system changes, the editor kernel triggers an update event. The rendering engine compares the old and new virtual document trees using a difference comparison algorithm to accurately identify the range of nodes that have changed (for example, only identifying that a specific cell node has changed its attributes). For the identified changed nodes, the renderer reads their latest extended properties; If the slash header attribute is found to be valid, the renderer generates an HTML tag description containing the corresponding class name (such as class="line"). If the multi-directional border property is read, the renderer will combine the width, shape, and color properties of the border to generate an inline CSS style string (such as style="border-top: 1px solid red;"). The renderer performs a minimized update of the Document Object Model (DOM) tree in the browser based on the generated rendering description. This process only modifies the properties or styles of the corresponding DOM elements without re-rendering the entire table or document, thus instantly presenting a table with complex styles on the screen.

[0059] In steps S253 and S42, the difference comparison algorithm is used to efficiently compare the old and new virtual document trees. To achieve high performance (O(n) complexity) in real-time editing, the algorithm is based on strategies including same-level comparison, type detection, and attribute comparison. Same-level comparison includes: comparing nodes pairwise only at the same level, without detecting movement across levels, based on the assumption that node movement across levels is extremely rare in web applications.

[0060] Type detection includes: when the types of the old and new nodes are different (e.g., div becomes p), it is directly determined to be a replacement, the old subtree is destroyed and the new subtree is rebuilt, and the child nodes are no longer compared in depth.

[0061] Attribute comparison includes: when nodes are of the same type (e.g., both are tableCell), the algorithm compares their attribute sets; Add a new attribute that the new node has but the old node does not, and perform the add operation. If an attribute exists in the old node but not in the new node, perform the removal operation. If the attribute name is the same but the value is different, perform the update operation. In this invention, the focus is on comparing lineClass and border-related extended properties.

[0062] In list comparison, the unique key value of a node is used to identify whether the node has been moved, inserted, or deleted, thus avoiding unnecessary reconstruction.

[0063] Step S254: Establish input / output closed-loop listening. At the same time as rendering is completed, attach event listeners to the nodes of the document object model tree. When the user performs an operation on the interface, the operation is intercepted and converted into an instruction to modify the model properties.

[0064] This step aims to close the interaction loop and achieve a WYSIWYG editing experience, specifically including: While the renderer renders the node to the document object model tree, it automatically attaches user interaction event listeners, namely mouse click, hover, and drag events, to the corresponding document object model node. When a user interacts with the table on the interface (clicks the diagonal header button or drags to adjust the border), the listener captures the physical action. The captured operations are transformed into semantic editing instructions. For example, a click action is transformed into an instruction to toggle the slash attribute. This instruction is sent to the editor kernel to modify the attributes of the editor's node system.

[0065] Modify the differentiated rendering that triggers step S253 again, thereby forming a process of user operation, instruction conversion, model update, driving rendering, and view update, ensuring that the data of the editor node system and the interface seen by the user are strictly synchronized at all times.

[0066] By employing atomic state replacement and a one-way dependency mechanism, the editor node system is established as the single source of truth. Combined with differentiated rendering and closed-loop input / output monitoring, this ensures that the view layer is always a faithful reflection of the model layer. This avoids the inconsistency risks associated with direct DOM manipulation and achieves a real-time closed loop between user actions and model updates, guaranteeing a smooth editing experience.

[0067] The view rendering mechanism in step S3 specifically includes: The view rendering mechanism specifically includes: Step S31: The rendering layer obtains the editor node instance corresponding to the target table cell from the current editor node system, and reads the node attribute fields stored in the editor node instance. The node attribute fields include attributes and extended attributes. Step S32: Obtain the editor node system of the current table cell, and determine whether special styles are enabled based on the node attribute fields in the editor node system. Special styles include diagonal headers and multi-directional borders. When special styles are not enabled, the standard rendering process is executed directly. When a special style is enabled, the rendering layer traverses the extended properties in the editor node instance and checks whether the enabled status field of the slash header stores a valid class name identifier. If it does, the standard rendering process is executed. Check the multi-directional border properties to determine if there are any valid non-default values ​​for the border type, border width, and border color fields in the left, right, top, and bottom directions. If so, execute the standard rendering process. The standard rendering process consists of steps S33 to S35. Step S33: When the diagonal header enable status field is a valid value, the rendering layer maps the value of the diagonal header enable status field to the class name identifier of the document object model element so that the CSS stylesheet can draw the diagonal effect accordingly. When a valid border definition exists, the rendering layer combines the border type, border width, and border color in each direction to generate an inline CSS style string that conforms to CSS syntax (style="border-top: 1px solid red;"). Combine the class name identifier and the inline CSS style string to form the rendering description; Without adding new node structures to the document object model tree or changing the original semantic hierarchy of the table, calculate the required visual parameters and generate a rendering description. Step S34: The rendering layer maps the calculated class name identifier and inline CSS style string to the style identifier of the document object model node. The mapping process includes: By comparing the new virtual document tree and the old virtual document tree using a difference comparison algorithm, cell nodes whose attributes have changed are identified. The generated rendering description is applied to the document object model tree in the browser. This process only modifies the properties and styles of the corresponding document object model elements, without re-rendering the entire table or document. Step S35: The browser's style engine parses the HTML to build the Document Object Model (DOM) tree and parses the CSS to build the CSSOM tree. The DOM tree and CSSOM tree are then merged to generate the render tree.

[0068] The browser is responsible for parsing HTML to build the Document Object Model tree, parsing CSS to build the CSSOM tree, and then combining the two to generate the render tree. Based on the updated class name identifiers and inline CSS style strings, the browser finally calculates the layout and draws elements with diagonal headers and multi-directional borders onto the screen to achieve a WYSIWYG (What You See Is What You Get) effect.

[0069] By using an attribute-driven view rendering mechanism, class names or inline styles are generated only when needed, without altering the DOM structure or adding nested nodes. This not only enables WYSIWYG rendering of complex styles but also significantly reduces the browser's rendering burden and improves page performance by maintaining the simplicity of the DOM tree, especially when handling large tables.

[0070] Step S4 includes: Step S41: The user triggers an interactive command through the editor interface. The interactive command can be triggered by the user clicking a function button (such as the diagonal header toggle button) located in the toolbar or table style settings panel. The state change process includes interactive commands that directly modify the diagonal header enable state field and multi-directional border attribute in the editor node instance. The editor kernel captures this data change and broadcasts the state change event. Step S42: The renderer performs snapshot comparison, description recalculation, and minimizes changes based on the state change event; Snapshot comparison includes: comparing snapshots of node attribute fields before and after the change, identifying the changed attribute types and scope of effect (e.g., identifying the switching of the diagonal header attribute between enabled and disabled states). The description recalculation includes: after detecting a change in a node attribute field, the renderer recalculates the rendering description information corresponding to the target node based on the node attributes and the view rendering mechanism; Minimizing changes includes: using a minimum change set calculation mechanism to determine that the current state update only involves attribute changes to the target cell node without rebuilding the entire table or document structure; Step S43: The view layer updates the attributes of the document object model tree element corresponding to the target cell according to the latest rendering description. The browser style engine automatically triggers the style recalculation process and synthesizes the new rendering result to the page display layer. The renderer, as a view layer component within the editor, subscribes to document state change events; Step S43 specifically includes the following sub-steps: Step S431: The view layer performs a synchronous update operation at the document object model level, and the browser engine takes over subsequent rendering. Step S432: The view layer updates the attributes of the document object model element corresponding to the target cell based on the latest rendering description information. The update operation specifically includes: Update the class name identifier of the element, and add or remove the class identifier of the slash header; Synchronously update the custom data attributes associated with this state; Keep the original node structure of the document object model tree unchanged, and do not introduce any additional child nodes; Step S433: After updating the properties of the elements in the Document Object Model tree, the browser engine automatically triggers the style recalculation process, which specifically includes: Match the current document object model tree elements to the new CSS selector rule; The browser engine generates a new rendering result based on this selector rule, using pseudo-element drawing to generate the visual effect of a diagonal table header.

[0071] Pseudo-element drawing methods specifically include: Set absolute positioning on the ::before pseudo-element of the cell to cover the entire cell, and apply a linear gradient background (linear-gradient) as the background image. By calculating the gradient angle or setting the gradient boundary (e.g., linear-gradient(to top right, transparent 49.5%, currentColor 50%, transparent 50.5%)), a diagonal line running from the bottom left to the top right corner is visually simulated. This method can adapt to changes in the width and height of the cell without requiring real-time JavaScript redrawing.

[0072] This rendering process does not rely on additional child node structures, nor does it change the original semantic hierarchy of the table, achieving true WYSIWYG rendering. Furthermore, by reducing the nesting depth of document object model nodes, it significantly improves rendering performance.

[0073] In this embodiment, the rendering layer generates the corresponding document object model representation based on the node attribute fields in the editor node instance. The algorithm uses the editor node system as the only data source and adopts an attribute-driven rendering method to map the style attributes of table cells to the corresponding visual representation.

[0074] The entire process is handled by the browser engine's native mechanisms without any additional script intervention. The new rendering result is then composited onto the page display layer, instantly displaying the styling enable or disable effect on the user interface. Interactive commands are provided; when a user triggers a command, node attributes are updated immediately; the renderer receives the changes and automatically triggers a re-render; the front-end interface immediately displays the new table style using a minimal change set calculation mechanism. The entire process requires no page refresh or document re-parsing, offering intuitive operation and timely feedback.

[0075] This embodiment details the implementation mechanism of user interaction commands. Taking the command to switch the diagonal table header as an example, the entire interaction process is designed to be so seamless that it does not require refreshing the page or re-parsing the document. The specific process is as follows: Minimal changeset calculation and local update specifically include: Step A1: Obtain the editor node system before the target update step, create an attribute snapshot object prevProps for the target cell node and its related rendering attribute fields, execute the user command and update the node attributes, and then create a modified attribute snapshot object nextProps. The attribute snapshot object includes lineClass and the width, type, and color fields of the four-way border. Step A2: Compare prevProps and nextProps, and calculate the difference set diffKeys for the key names: If a key exists in nextProps and is different from the value of prevProps, it is considered an update; If a key does not exist in nextProps but exists in prevProps, it is recorded as deleted / reset; If a key is the same in both, ignore it; Obtain the attribute difference description deltaProps; Step A3: Based on the preset node attribute DOM representation mapping rules, convert deltaProps into rendering description increments: For changes to lineClass, generate an incremental update description of the target DOM element's className; For changes in border-related fields, generate incremental update descriptions for the corresponding border-top / right / bottom / left sub-items in the style of the target DOM element; Unchanged text content and child node structure do not generate any updated descriptions; Step A4: Arrange the rendering description incrementally into a minimal set of update instructions, PatchList. The set of instructions includes: UpdateAttributes(targetDom, classDelta) and UpdateStyle(targetDom, styleDelta), and only contains update operations corresponding to the keys involved in deltaProps. UpdateStyle incrementally writes or clears the style declaration of the target DOM element according to the CSS attribute key, without affecting other style declarations not involved. Step A5: Send PatchList to the view layer to perform a local DOM update, and save nextProps as a baseline snapshot for subsequent updates, for use in the next difference calculation.

[0076] The driving view layer performs local property updates only on the document object model element corresponding to the target cell.

[0077] In this invention, the renderer is a view layer component used to map the node attributes of the editor node system to DOM attributes and CSS styles and perform local updates.

[0078] By employing a minimum change set calculation mechanism and a difference comparison algorithm, the system achieves highly efficient response to interactive operations. It can accurately identify attributes that have only changed and update only the corresponding DOM elements, avoiding the performance overhead of a full repaint. This allows users to receive millisecond-level real-time feedback when performing operations such as style switching, greatly enhancing the user experience.

[0079] This invention achieves complex table styles without altering the Document Object Model (DOM) tree, avoiding the structural redundancy and rendering performance degradation issues caused by nested multi-layered DOM models in traditional solutions. Styles are expressed through an attribute model, allowing for persistent storage, parsing, and restoration, effectively preventing content loss during copying, pasting, and persistence. The invention also expands the node attribute model, enabling easy future expansion of more cell visual effects and broad application value. It supports a WYSIWYG interactive experience, with a command-driven state change model that makes operations intuitive and feedback timely, without disrupting selections, cursors, or text structure during style switching. The renderer only performs mappings based on model changes, without participating in business logic, reducing front-end computational costs and improving system stability.

[0080] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0081] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the protection scope of the present invention.

Claims

1. A method for rendering table cell styles based on node attribute extension, characterized in that, Includes the following steps: Step S1: Extend the node attribute model of the table cell in the rich text editor, add the diagonal header attribute and multi-directional border attribute, and establish an extended node attribute model with the ability to express complex styles. Step S2: Receive the HTML text sequence and convert it into a document object model tree. Extract the standard attributes of the cell nodes through depth-first traversal and parse their style features to map them to the extended node attribute model. The extracted attributes are normalized and their topology is verified to construct an editor node system that serves as the single source of facts for the editor. Step S3: Generate a rendering description based on the attribute status of cell nodes in the editor's node system; When a valid value is detected for an extended property, the diagonal header property is mapped to a class name identifier that controls the drawing of pseudo-elements, the multi-directional border property is combined into an inline CSS style string, and the final render tree is generated. Step S4: Respond to user interaction commands, update the corresponding attribute fields in the editor node system, trigger state change detection, calculate the minimum change set by comparing the node attribute snapshots before and after the change, and perform local attribute updates.

2. The table cell style rendering method based on node attribute extension as described in claim 1, characterized in that, The extended table cell node attribute model specifically includes: The newly added diagonal header attribute is used to indicate whether the diagonal header effect is enabled in the table cell. The attribute field is a class name identifier used to control the style. The newly added multi-directional border attribute describes the border style, type, and width in the top, bottom, left, and right directions, and supports asymmetrical and user-customized border effects. The hierarchical structure of the node attribute model adopts a key-value pair format, which specifically includes attribute fields: column span, row span, column width, background color, diagonal header identifier, left border type, right border type, top border type, bottom border type, left border width, right border width, top border width, bottom border width, and cell vertical alignment.

3. The table cell style rendering method based on node attribute extension as described in claim 2, characterized in that, Step S2 specifically includes: Step S21: Receive an externally input HTML text sequence and convert the HTML text sequence into a Document Object Model (DOM) tree using a standard HTML parser. The DOM tree serves only as a data extraction carrier and does not directly participate in the editor state construction. Step S22: Initialize the cursor pointer and context stack, perform a depth-first traversal of the document object model tree, locate the table container node, row node and cell node level by level, extract standard attributes and parse extended attributes, and encapsulate them into a structured intermediate representation after normalization. Step S23: Traverse the structured intermediate representation, instantiate editor nodes using the node factory pattern, accurately inject the extracted extended attributes into the node attribute fields, and reconstruct parent-child links according to the hierarchical relationship to reconstruct a complete editor node system that conforms to the editor specification. Step S24: Perform state verification and correction on the editor node system, and forcibly repair abnormal structures to ensure the legality of the editor node system; Step S25: Atomize the verified editor node system and insert it into the editor state, establish the editor node system as a single source of fact, identify changes and generate rendering descriptions through difference comparison algorithm, minimize the update of the document object model tree, and attach event listeners to intercept user operations and convert them into model modification instructions, thereby realizing an input-output closed loop.

4. The table cell style rendering method based on node attribute extension as described in claim 3, characterized in that, Step S21 specifically includes the following sub-steps: Step S211: Receive the externally input HTML text sequence through the clipboard interface, file import interface and network transmission interface, and perform cleaning and preprocessing operations on the HTML text sequence. The cleaning and preprocessing operations include removing script tags that cause security risks, unifying the character encoding format, and filtering out illegal control characters that are not supported by the editor, so as to obtain a clean HTML text sequence to be parsed. Step S212: Call the standard HTML parser built into the runtime environment to parse the HTML text sequence to be parsed. The parsing process includes a lexical analysis stage and a syntax analysis stage. The lexical analysis phase includes: The standard HTML parser scans the HTML text sequence to be parsed, decomposes the HTML text sequence into independent tag sequences, and the tag types included in the tag sequence include start tags, end tags and text content. The start tags also include attribute names and attribute values. The parser traverses the tag sequence and creates corresponding node objects according to the tag types of the tag sequence. The syntax analysis phase includes: The standard HTML parser reads the decomposed tags, obtains the nesting relationship between the tag types according to the syntax rules of the HTML document, establishes parent-child links between node objects according to the nesting relationship, and combines all node objects and parent-child links between node objects into a document object model tree; The specific structure of the Document Object Model tree includes a root node, element nodes, and text nodes, where element nodes also include a set of associated attributes: The root node includes fragment node objects of the HTML text sequence and temporary container elements; Element nodes include table container nodes, table row group nodes, table row nodes, and cell nodes; Text nodes are obtained by merging text strings and are used to store the text content that the user can actually see, serving as child nodes of cell nodes; The attributes include standard attributes, style attributes, and custom data attributes. Each attribute set includes the element data, standard attributes, style attributes, and custom data attributes of each corresponding element node.

5. The table cell style rendering method based on node attribute extension as described in claim 3, characterized in that, Step S22 specifically includes the following sub-steps: Step S221: Initialize the cursor pointer used to traverse the document object model tree in memory, and initially position the cursor pointer to the root node of the document and the highest-level container node in the current text selection area; Step S222: Initialize the context stack in memory. The context stack is a linked storage and is used to temporarily store references to table container nodes during the depth-first traversal process. Step S223: The depth-first traversal process specifically includes: The document object model tree is traversed using a cursor pointer in a depth-first manner, and the node type identifier of each node in the traversal is read. When a node type identifier is identified as a table container node identifier, the table data object is initialized in memory and pushed onto the context stack. When a node type identifier is detected as a table row node identifier, the table row data object is initialized and linked to the table data object at the top of the current context stack. When the node type identifier is identified as a cell node identifier, the cell attribute extraction process begins. The cell attribute extraction process includes the following sub-steps: Step S2231: Read the standard HTML attributes of the identified cell nodes. The reading logic specifically includes: When reading the colspan attribute value, convert the colspan attribute value to an integer type to record the number of columns that the cell spans horizontally; When reading the rowspan attribute value, convert the rowspan attribute value to an integer type to record the number of rows that the cell spans vertically; When reading the width and colwidth properties, the values ​​of the width and colwidth properties are parsed to determine the display width of the cell; If the values ​​for the colspan, rowspan, width, and colwidth attributes are all absent, default values ​​will be assigned according to the preset rules, which stipulate that the span is 1 by default. Step S2232: Parsing the attributes of the diagonal header includes: Check the class name list of the current cell node, compare the read class name string with the preset slash style identifier. If the class name string and the slash style identifier are exactly the same, it means that the match is successful, and set the slash header enable status field to a valid value. If the class name string and the slash style identifier are not exactly the same, it indicates a match failure, and the slash header enable status field is set to empty; Parsing the multi-directional border properties includes: Read the style attribute string of the cell node, use a string parsing algorithm to cut the style attribute string into multiple style declaration fragments with semicolons as delimiters, traverse the style declaration fragments, filter out the declarations with the attribute name border and those starting with border-, get the border declarations in each direction, parse the value of the border declaration, identify and separate the substrings representing line width, line type and color, map the separated line width value to the width attribute field, and map the line type value to the type attribute field; If the user-required border definition is not found in the style property string, check if the corresponding CSS class name exists. Step S2233: Normalization process specifically includes: After extracting the raw data, all attribute values ​​are normalized. For pixel value strings, the numerical value and unit are separated. If the unit is missing, it is filled with px by default. If the unit is not px, the original unit string is retained or it is converted into a px value according to the font measurement of the current context. Convert color values ​​to a standard hexadecimal format; Perform null value validation on missing attributes and fill in the default border type and preset default line width; Step S2234: Summarize all the attributes and extended attributes extracted and processed in the above steps. The attributes include column span, row span, and column width. The extended attributes include diagonal header identifier, left border type, right border type, top border type, bottom border type, left border width, right border width, top border width, bottom border width, and cell vertical alignment. Instantiate a key-value pair collection object in memory and write the above properties with predefined key names respectively; The encapsulated cell nodes are appended to the list of child nodes of the table row data object at the top of the current context stack according to their original order in the document object model tree. When the traversal of the table row nodes is finished, the table row data object is appended to the table data object, and the structured intermediate representation is output.

6. The table cell style rendering method based on node attribute extension as described in claim 3, characterized in that, Step S23 includes the following sub-steps: Step S231: Traverse the structured intermediate representation generated in step S22, read the type identifier of each intermediate representation object in the structured intermediate representation, use the node factory pattern of the editor core to find the corresponding node definition pattern according to the type identifier, and call the constructor to instantiate the specific editor node instance in memory; Type identifiers include tables, table rows, and cells; When the type is identified as cell, a cell node instance is created for full editing. The cell node instance includes cell node data and inherits the prototype methods defined by the editor. Step S232: Perform attribute injection operation on each newly created cell node instance, mapping the extended attributes extracted from the intermediate representation object to the node attribute fields of the editor node instance; Attribute injection operations specifically include diagonal header injection and multi-directional border injection: The diagonal header injection includes: assigning the value of the diagonal header enable status field in the intermediate representation object to the property of the same name in the editor node instance; if the diagonal header enable status field in the intermediate representation object is empty, then initializing the node property field to the disabled status value. Multi-directional border injection includes: according to the four dimensions of top, bottom, left, and right, the extracted border type, border width, and border color are written into the style attribute set of the editor node instance to form a key-value pair storage structure. Step S233: Reconstruct the parent-child links between nodes based on the hierarchical relationships recorded in the updated structured intermediate representation; Add the filled cell node instances to the child node list of the table row node instances in sequence, and then add the table row node instances to the child node list of the table node instances to obtain the editor node system.

7. The table cell style rendering method based on node attribute extension as described in claim 3, characterized in that, Step S24 specifically includes the following sub-steps: Step S241: Check the diagonal header attribute value of each cell node instance, compare the diagonal header attribute value with the predefined allowed style whitelist, and if the diagonal header attribute value exceeds the range of the allowed style whitelist, reset the diagonal header attribute value to the default value, which is to not display the diagonal. Step S242: Check the border definitions in each direction in the node attribute fields: When the direction defines the border width but the border type is missing, it will be padded with a solid line by default. If a border color is missing, it will be filled with the default border color. When the border width is zero or the border type is none, clean up the corresponding redundant color and style data. Step S243: Perform topology calculation on the overall grid structure of the table. The topology calculation includes rectangle integrity verification and overlap detection. Rectangular integrity verification includes: calculating whether the table forms a complete rectangular grid based on the column span and row span attributes and the mathematical properties of rectangles; Overlap detection includes detecting whether multiple cell node instances overlap spatially; When a complete rectangular grid is not formed or multiple cell node instances overlap in space, it indicates a structural anomaly. By splitting the erroneous merged cells and filling in the missing placeholder cells, the table is forced to restore to a normal grid structure.

8. The table cell style rendering method based on node attribute extension as described in claim 3, characterized in that, Step S25 specifically includes the following sub-steps: Step S251: The editor inserts the verified and corrected complete table's editor node system as an atomic operation into the current document's editor state, updating the virtual document tree inside the editor; Step S252: Establish the editor node system as a single source of fact, establish a one-way dependency mechanism, define the view layer as a pure function mapping of the model layer, prohibit bypassing the editor node system to directly modify the document object model tree, and all style changes must be carried out in the order of modifying the node attribute fields in the editor node system, and then the model changes triggering view updates. Step S253: Trigger differentiated rendering. When the state of the editor node system changes, the editor kernel triggers an update event. The view layer receives the difference between the new virtual document tree and the old virtual document tree, identifies that only the table part has changed, and generates the corresponding HTML tags, class names and styles through the renderer according to the extended attributes in the editor node system. The document object model tree in the browser is updated, so as to present a table with complex styles on the screen. Step S254: Establish input / output closed-loop listening. At the same time as rendering is completed, attach event listeners to the nodes of the document object model tree. When the user performs an operation on the interface, the operation is intercepted and converted into an instruction to modify the model properties.

9. The table cell style rendering method based on node attribute extension as described in claim 1, characterized in that, The view rendering mechanism in step S3 specifically includes: The view rendering mechanism specifically includes: Step S31: The rendering layer obtains the editor node instance corresponding to the target table cell from the current editor node system, and reads the node attribute fields stored in the editor node instance. The node attribute fields include attributes and extended attributes. Step S32: Obtain the editor node system of the current table cell, and determine whether special styles are enabled based on the node attribute fields in the editor node system. The special styles include diagonal headers and multi-directional borders. When special styles are not enabled, the standard rendering process is executed directly. When a special style is enabled, the rendering layer traverses the extended properties in the editor node instance and checks whether the enabled status field of the slash header stores a valid class name identifier. If it does, the standard rendering process is executed. Check the multi-directional border properties to determine if there are any valid non-default values ​​for the border type, border width, and border color fields in the left, right, top, and bottom directions. If so, execute the standard rendering process. Step S33: When the slash header enable status field is a valid value, the rendering layer maps the value of the slash header enable status field to the class name identifier of the document object model element; When a valid border definition exists, the rendering layer combines the border type, border width, and border color in each direction to generate an inline CSS style string that conforms to CSS syntax (style="border-top: 1px solid red;"). Combine the class name identifier and the inline CSS style string to form the rendering description; Step S34: The rendering layer maps the calculated class name identifier and inline CSS style string to the style identifier of the document object model node. The mapping process includes: By comparing the new virtual document tree and the old virtual document tree using a difference comparison algorithm, cell nodes whose attributes have changed are identified. The generated rendering description is applied to the document object model tree in the browser. This process only modifies the properties and styles of the corresponding document object model elements, without re-rendering the entire table or document. Step S35: The browser's style engine parses the HTML to build the Document Object Model (DOM) tree and parses the CSS to build the CSSOM tree. The DOM tree and CSSOM tree are then merged to generate the render tree.

10. The table cell style rendering method based on node attribute extension as described in claim 1, characterized in that, Step S4 includes: Step S41: The user triggers an interactive command through the editor interface. The interactive command can be triggered by the user clicking a function button located in the toolbar or table style settings panel. The state change process includes interactive commands directly modifying the diagonal header enable state field and multi-directional border attribute in the editor node instance. The editor kernel captures this data change and broadcasts the state change event. Step S42: The renderer performs snapshot comparison, description recalculation, and minimizes changes based on the state change event; Snapshot comparison includes: comparing snapshots of node attribute fields before and after the change, and identifying the types and scope of the changed attributes; The description recalculation includes: after detecting a change in a node attribute field, the renderer recalculates the rendering description information corresponding to the target node based on the node attributes and the view rendering mechanism; Minimizing changes includes: determining, through a minimum change set calculation mechanism, that the current state update only involves attribute changes to the target cell node; Step S43: The view layer updates the attributes of the document object model tree element corresponding to the target cell according to the latest rendering description. The browser style engine automatically triggers the style recalculation process and synthesizes the new rendering result to the page display layer. Step S43 specifically includes the following sub-steps: Step S431: The view layer performs a synchronous update operation at the document object model level, and the browser engine takes over subsequent rendering. Step S432: The view layer updates the attributes of the document object model element corresponding to the target cell based on the latest rendering description information. The update operation specifically includes: Update the class name identifier of the element, and add or remove the class identifier of the slash header; Synchronously update the custom data attributes associated with this state; Keep the original node structure of the document object model tree unchanged, and do not introduce any additional child nodes; Step S433: After updating the attributes of the elements in the Document Object Model tree, the browser engine automatically triggers a style recalculation process, which specifically includes: Match the current document object model tree elements to the new CSS selector rule; The browser engine generates a new rendering result based on this selector rule, using pseudo-element drawing to generate the visual effect of a diagonal table header.

Images