Browser rendering engine specification driven code generation method, system and computer readable storage medium

Abstract

This application discloses a method, system, and computer-readable storage medium for generating browser rendering engine specification-driven code. The method includes: converting the natural language text of the W3C CSS specification into a structured domain-specific language intermediate representation file. The domain-specific language intermediate representation file contains at least one structural block, and each structural block maps to one or more functions of CSS modules in the W3C CSS specification text. The method further involves parsing the domain-specific language intermediate representation file, extracting the structural blocks, and generating browser rendering engine specification target language code based on the type of the structural blocks. The generated browser rendering engine specification target language code is identical for all domain-specific language intermediate representation files. This application bridges the W3C CSS specification clauses with the target implementation code through the domain-specific language intermediate representation, achieving automated code generation and avoiding repetitive manual writing.

Description

Technical Field

[0001] This application relates to the field of computer browser engine and compiler technology, and in particular to a browser rendering engine specification-driven code generation method, system, and computer-readable storage medium. Background Technology

[0002] In the internet domain, the reason why different browsers can display web pages almost identically is mainly because each browser's rendering engine follows the same CSS specification (W3C CSS, World Wide Web Consortium Cascading Style Sheets, hereinafter referred to as the CSS specification), which controls the appearance and style of web pages. Existing web browser rendering engines, such as the common Chromium / Blink, WebKit, Firefox / Gecko, and Servo, all need to implement hundreds of W3C CSS specification rules. As of 2026, the W3C CSS working group maintains more than 80 independent CSS module specifications (CSS Color 4, CSS Flexbox 1, CSS Grid 2, CSS Masking 1, etc.), each module containing dozens to hundreds of specific rules, covering multiple subsystems such as layout, paint, animation, color, and fonts. These rules are implemented by different browsers as their respective browser rendering engine code.

[0003] However, current browser rendering engines typically implement CSS rule code entirely manually. For example, the Chromium / Blink browser engine uses C++ to write modules such as ComputedStyle and LayoutNG, WebKit uses C++ to write modules such as RenderStyle and RenderBlock, Firefox / Gecko uses C++ / Rust to write Stylo (Rust) and the old Gecko C++ modules, and Servo uses Rust to write modules such as style, crate, and layout. This manual approach to browser rendering engine code inevitably leads to different browser engines writing their own code to implement the same CSS specification, resulting in repetitive work across engines. Furthermore, different developers' interpretations of the same W3C CSS specification clauses lead to discrepancies in their implementations. There is an urgent need for a method to automatically generate CSS specification code to address these problems. Summary of the Invention

[0004] This application provides a method, system, and computer-readable storage medium for generating browser rendering engine specification driver code, which addresses the problems existing in the prior art regarding browser rendering engine specification driver code generation.

[0005] On the one hand, the browser rendering engine specification driver code generation method provided in this application includes: The W3C CSS specification's natural language text is converted into a structured Domain-Specific Language (DSL) intermediate representation file, which contains at least one structure block that maps to one or more functions of each CSS module in the W3C CSS specification text. The Domain-Specific Language (DSL) intermediate representation file is parsed, the structural blocks are extracted, and browser rendering engine specification target language code is generated according to the type of the structural blocks, wherein: the Domain-Specific Language (DSL) intermediate representation file is the same, and the generated browser rendering engine specification target language code is the same.

[0006] Preferably, the step of converting the natural language text of the W3C CSS specification into a structured Domain-Specific Language (DSL) intermediate representation file specifically includes: using a Large Language Model (LLM) to convert the natural language text of the W3C CSS specification into a structured Domain-Specific Language (DSL) intermediate representation file, and reviewing the Domain-Specific Language (DSL) intermediate representation file to form a true source file for the (DSL) intermediate representation.

[0007] Preferably, the method further includes automatically injecting the target language code into the browser rendering engine during runtime via a build system.

[0008] Preferably, the step of automatically injecting the target language code into the browser rendering engine during runtime via the build system specifically includes: Build a monitoring script to monitor changes to the Domain-Specific Language (DSL) intermediate representation file; When a change is triggered, the target language code is regenerated and output to the build directory; Import the target language code regenerated in the build directory when the browser rendering engine is running.

[0009] Preferably, the method further includes: performing domain-specific language (DSL) intermediate representation file syntax checking during the compilation and parsing phase, and / or performing registry consistency checking during the compilation and verification phase, and / or performing type checking on the generated target language code during the target language generation phase, and / or performing reference implementation baseline testing on the rendering results of the target language code.

[0010] Preferably, the method further includes: The target language code is connected to the algorithm code in the browser rendering engine code through a slot function interface.

[0011] On the other hand, the browser rendering engine specification-driven code generation system provided in this application includes an intermediate representation file generation module, an intermediate representation file parsing module, and a target language code generation module, wherein: The intermediate representation file generation module is used to convert the natural language text of the W3C CSS specification into a structured Domain-Specific Language (DSL) intermediate representation file. The DSL intermediate representation file contains at least one structure block, and the structure block has a mapping relationship with one or more functions of each CSS module in the W3C CSS specification text. The intermediate representation file parsing module is used to parse the domain-specific language (DSL) intermediate representation file and extract the structural blocks; The target language code generation module is used to generate browser rendering engine specification target language code according to the type of the structure block, wherein: the Domain-Specific Language (DSL) intermediate representation files are the same, and the generated browser rendering engine specification target language code is the same.

[0012] Furthermore, embodiments of this application also include a computer-readable storage medium generated in accordance with the foregoing scheme.

[0013] Compared with existing technologies, the embodiments of this application bridge the W3C CSS specification clauses with the target implementation code through a Domain-Specific Language (DSL) intermediate representation, achieving automated code generation and avoiding repetitive work caused by manual coding. Furthermore, by using the same DSL intermediate representation logic, the final generated target code maintains consistency across different browser rendering engines, thus achieving excellent technical results. Attached Figure Description

[0014] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a summary flowchart of the browser rendering engine specification driver code generation method according to an embodiment of this application; Figure 2 This is a schematic diagram of a DSL intermediate representation file structure according to an embodiment of this application; Figure 3 Four types of verification diagrams provided for embodiments of this application; Figure 4 This is a schematic diagram illustrating the rule and algorithm separation architecture design in an embodiment of this application. Figure 5 This is a system architecture diagram for generating browser rendering engine specification driver code in an embodiment of this application. Detailed Implementation

[0015] To address the problems existing in the prior art, this application provides a method for generating browser rendering engine specification-driven code. This method constructs a Domain-Specific Language (DSL) intermediate representation file (hereinafter referred to as Domain-Specific Language or DSL) and connects the content of this representation file with the W3C CSS specification content and the target language code content, thereby achieving an automated code generation process. The solution of this application will be described in detail below with reference to embodiments. (Reference) Figure 1 The figure shows a summary flowchart of the specification driver code generation method according to an embodiment of this application.

[0016] Step S11: Convert the natural language text of the W3C CSS specification into a structured domain-specific language (DSL) intermediate representation file. The DSL intermediate representation file contains at least one structure block, which corresponds to at least one function of a CSS module in the W3C CSS specification text. The purpose of this step is to structure the CSS specification's natural language file. The resulting DSL intermediate representation file contains one or more structural blocks, which correspond to various functionalities within the CSS module. Here, "functionality" can be understood more broadly as representing the role it will play in the overall target code generation. These structural blocks precisely, but in a platform-independent manner, describe the requirements of the W3C CSS specification. See also... Figure 2 This diagram illustrates the structure of a DSL intermediate representation file. In this diagram, the structural blocks in the DSL intermediate representation file can be divided into three categories: metadata blocks, binding declaration blocks, and functional blocks (such as rule blocks, formula blocks, value mapping blocks, attribute extraction blocks, child node classification blocks, and pipeline template blocks). The function of each block is briefly explained below: (a) Metadata block (YAML block): Used to record W3C specification identifiers (such as css-color-4), chapter numbers (such as §11), and specification URLs, thereby facilitating the establishment of a traceable mapping between CSS specifications and generated code; (b) Binding declaration block (w3c-bind block): This block declares the runtime context type (root), flags type, and the mapping between CSS properties and engine internal slots (property-map). During subsequent compilation, the binding declaration block can define the mapping between CSS property names and browser rendering engine internal slot identifiers through the property-map field. (c) Rule block (w3c-rule block): Used to describe "condition-action" rules, in the format of @when <condition condition> @then set <FLAG flag>, which means "when a certain attribute meets the condition, set the corresponding rendering flag". In subsequent compilations, the compiler translates it into conditional judgment statements and bit flag setting function calls. Here, the "condition" supports multi-condition AND logic combination and negation (IS NOT); (d) Formula block (w3c-formula block): Used to describe mathematical calculation formulas, including typed input parameters (@input), output declarations (@output), calculation steps (@let expressions), and return values (@return), such as the DeltaE distance formula for gamut mapping. In subsequent compilation steps, the compiler can translate it into a typed pure function according to this syntax description. Both the input parameters and the return values have type annotations, and the calculation steps are translated into local variable bindings; (e) Value mapping block (@map block): Used to describe the mapping rules from CSS values to internal types of the engine, supporting conditional branches (if <cond> : <expr1>else: <expr2>) and default value (_ → <default>) (f) Attribute extraction block (@extract block): Used to describe declarative rules for extracting attribute values ​​from the engine ECS (Entity-Component-System) data model, eliminating the need for handwritten data access boilerplate code; (g) Child node classification block (@classify block): Used to describe the priority rules for classifying child nodes according to CSS property values ​​(position, float, display, etc.); (h) Pipeline template block (@pipeline block): Used to describe the complete layout pipeline skeleton—initialization, child node traversal, dispatch, refresh, finalization, etc.

[0017] These structural blocks reside in the DSL intermediate representation file, which can exist in various formats, such as Markdown. This format makes the structural blocks easy to read and write, allowing developers or reviewers to easily view and edit these files. Simultaneously, Markdown's code block syntax (such as w3c-rules) can be effectively used to wrap structured DSL code, mixing natural language descriptions (such as headings and lists) with machine-readable DSL code blocks in the same file. Thus, the filename can be defined as ".v2 / v1.spec.md". The DSL intermediate representation file serves as a bridge between the "specification" and the "code," and its syntax construction can be implemented in various ways under deterministic requirements. Examples of different structural blocks are illustrated below: (1) Rule syntax (w3c-rule) @rule<rule_name> : @ref <spec-id> § <section> @when <slot-name>is [not] <value> [AND <slot-name>is [not] <value>]* @then set<FLAG_NAME> Semantics: Set the specified bit flag when all @when conditions are met.

[0018] (2) Formula syntax (w3c-formula) @formula<formula_name> : @ref <spec-id> § <section> @input <param> : <type> , # <comment> ... @output <result> : <type> # <comment> @let <var> = <expression> ... @return <expression> Semantics: Define a typed pure function with type annotations for both input and output, and bind intermediate steps using @let.

[0019] (3) Value mapping syntax (@map) @map <name> ( <inputtype> → <outputtype> [, <param> : <type>]*): @ref <spec-id> § <section> <inputvariant> → <outputexpr> <inputvariant>→ if <cond> : <expr1>else: <expr2> _ → <defaultexpr> Semantics: Exhaustively enumerates all variations of the input enumeration, maps to the output type, and supports conditional branching.

[0020] (4) Attribute extraction syntax (@extract) @extract <name> : <field> : <source> [→ <typeconversion> ] [| <default>] The source type can include ir. <field>[Layout Input IR field], hot(entity). <field>(ECS hot component field), computed32(entity, <propid>(Compute style pool query), ir. <field> & <mask>(Bit flag check).

[0021] Semantics: Declarative descriptions of the rules for extracting attribute values ​​from the engine's ECS data model, which the compiler translates into structure definitions and constructors containing all data access logic.

[0022] (5) Child node classification syntax (@classify) @classify <name> ( <param> : <type>, ...): @ref <spec-id> § <section> <category> : <condition> <category> : <condition>AND NOT <prev_category> <category>: _ # default Semantics: Child nodes are categorized according to priority order, which the compiler translates into an enumeration definition and a priority chain judgment function. "_" indicates the default branch.

[0023] (6) Pipeline template syntax (@pipeline) @pipeline <name>: @params: <param> : <type> @heat: <stmt> @collect_children(entity): flatten: <display_value> @for_each child: @classify → <classify_name> @dispatch: <category>→ slot::<algo_name>(...) ... @finalize: <stmt> Semantics: Describes the complete layout pipeline skeleton, such as parameter declaration, initialization, child node collection (including display:contents flattening), classification and dispatch, and finalization. The compiler translates it into a complete function containing traversal loops, classification judgments, and slot function calls.

[0024] (7) Binding declaration syntax (w3c-bind) root: <contexttype> flags-type: <flagstype> property-map: <css-property>:<slot_id> Semantics: Declares the binding relationship between the file runtime context and CSS properties to engine data slots.

[0025] Regardless of the DSL rule syntax structure used to convert natural language into an intermediate representation file, in this application, this step has at least the following characteristics: (1) Structured: Unlike plain text specifications, this document is not vague. It structures the rules through specific DSL syntax (such as @when...@then).

[0026] (2) Traceability: Each structural block in this document can be linked to the original W3C specification section via the @ref tag, enabling bidirectional traceability.

[0027] (3) Determinism: Once the file is manually reviewed and approved and added to the database, it becomes the "SingleSource of Truth". All subsequent code generation is based on it, ensuring the determinism and reproducibility of the generation process.

[0028] (4) Human-machine readable: As mentioned above, it can be based on Markdown format, which is easy for humans to read directly. At the same time, because it contains structured DSL code blocks, machines (such as DSL compilers) can parse it accurately.

[0029] The above steps of converting the W3C CSS Natural Language Specification text into a DSL intermediate representation file can be implemented in several ways. For example, the DSL intermediate representation file can be written manually. Of course, a more efficient way is to use automated tools, such as LLM (Large Language Model), to achieve this. However, it is worth noting that in this embodiment, the role of LLM is a "translation aid" rather than a "code generator." The DSL intermediate representation file output by LLM is included in version control after manual review, becoming a deterministic source of truth. All subsequent code generation is completed by the compiler, no longer involving LLM. This eliminates the uncertainty of LLM through manual review, thus limiting the uncertainty to this stage. This is fundamentally different from the existing technology that uses LLM to directly generate code: the latter's LLM output is directly used as the final code, which cannot guarantee determinism and type safety. In this embodiment, the LLM output is merely a DSL intermediate representation file, which can only be converted into the final code after subsequent compiler work.

[0030] Step S12: Parse the DSL intermediate representation file, extract the structural blocks, and generate browser rendering engine specification target language code according to the type of the structural blocks, wherein: the DSL intermediate representation files are the same, and the generated browser rendering engine specification target language code is the same.

[0031] The intermediate representation file of the DSL generated in the preceding steps is parsed to extract all structural blocks, and target language code is generated according to the type of structural block. For example: If it is a rule block (w3c-rule block), the generated target code is: if conditional statement + bit flag setting function call; If it is a formula block (w3c-formula block), the generated target code is: a typed pure function with type annotations for both parameters and return value; If it is a value mapping block (@map block), the generated target code is: a match expression that exhausts all enumeration variants; If it is an attribute extraction block (@extract block), the generated target code is: structure definition + constructor, including ECS ​​query and default value population; If it is a child node classification block (@classify block), the generated target code is: enumeration definition + priority chain judgment function; If it is a pipeline template block (@pipeline block), the generated target code is a complete function skeleton, including the entire process from initialization to traversal, dispatch, refresh, and termination; If it is a binding declaration block (@w3c-bind block), the generated target code is: context type aliases and property-map constant table.

[0032] This application's embodiments construct an intermediate representation file based on the syntactic description between the W3C CSS specification's natural language text and the target language code. Based on the mapping relationship of this intermediate representation file, it ensures that the same input produces the same output, achieving fully automated code generation. This avoids the significant amount of repetitive work caused by different browser engines implementing their own CSS specifications, as well as implementation discrepancies due to different developers' understanding of the specifications. During code generation, the intermediate representation file is relied upon, which adopts the same structural pattern for different rules, ensuring consistency in the generated code. Simultaneously, it enables traceability of specification clauses and code structure. Since each generated code line establishes a bidirectional mapping between W3C specification clauses and code structure based on the intermediate representation file, when the W3C specification changes, the affected DSL rule files and the location of the generated code can be accurately located. This reduces the cost of searching the scope of specification changes from hours to seconds, thereby avoiding the reliance on developers and unstructured references in code comments in existing code tracing techniques, significantly improving the efficiency of specification change tracking.

[0033] After the code is generated in the above embodiments, this application embodiment can also execute step S14, that is, automatically inject the generated code into the browser rendering engine runtime through the build system (Build.rs). The specific steps may include: (a) Build a script to monitor changes to the DSL intermediate representation file and registry file (cargo:rerun-if-changed). (b) When the change is triggered, the compiler is invoked to regenerate the target code and output it to the build directory (OUT_DIR / xhtml_generated / ). (c) The browser rendering engine runtime code includes the generated code through the include! macro, which is then seamlessly combined with the handwritten algorithm code.

[0034] In the above embodiments, to achieve better technical results, step S13 can be added before step S12 to perform a security check on the generated DSL intermediate representation file. The security check can be multifaceted. The type security check is described below. To perform type security verification, a type verification benchmark needs to be constructed first. In this embodiment, three registry entries are maintained, see [link to relevant documentation]. Figure 3 As shown, the type security verification benchmark for DSL references includes: (a) Type registry (types.v1.json): Defines the type names available in the DSL intermediate representation file and their mapping to the target language (e.g., Rust) type paths. Supports types such as enumerations (with variant definitions), structs (with field or component definitions), bitflags, and handles; (b) Data Slot Registry (slots.v1.json): Defines the engine's internal data slots that can be referenced by property-map. Each slot has a type (reference type registry) and a writability flag. (c) Algorithm registry (algos.v1.json): Defines the signatures of engine algorithm functions that can be called by the DSL, including a list of parameter types, return type, and purity flags (pure / impure / read_only).

[0035] The verification is performed using three registry entries. The verification rules can be set as follows: Rule 1: The type names referenced in the formula block @formula and the rule block @rule must exist in the type registry; otherwise, the compiler will report an error. Rule 2: The slot name referenced in the property-map must exist in the slot registry; otherwise, the compiler will report an error. Rule 3: The algorithm name called in the pipeline template block @pipeline must exist in the algorithm registry and the parameter types must match; otherwise, the compiler will report an error. Rule 4: All verifications are completed at compile time, and there is no silent fallback at runtime.

[0036] The aforementioned registry type verification can be performed in conjunction with target compiler type checking to achieve "double verification." This double verification eliminates the uncertainty risks associated with directly generating code using the LLM. In fact, besides performing registry consistency checks during the compiler verification phase, in this embodiment, syntax checks (checking block structure integrity, keyword correctness, indentation conformance, etc.) can be performed on the DSL intermediate representation file during the compilation and parsing phase; type checks can be performed on the generated target language code during the target language construction phase (e.g., type checking of the generated Rust code using `cargo build`); and baseline testing of the rendered target language code can be performed during the testing phase. See also... Figure 3 As shown, the above four types of verification (checks) actually constitute a four-layer verification closed loop: DSL syntax checking → registry consistency verification → compiler type checking → Chrome baseline testing, thus forming a complete correctness guarantee chain from syntax to semantics to runtime. In particular, "reference implementation baseline testing" can detect rendering inconsistencies caused by biases in specification understanding. The workflow of reference implementation baseline testing can include the following steps: First, use an automation tool (Puppeteer) to render test cases in Chrome, recording the precise layout coordinates and calculated styles of each element as a JSON baseline file; Then, let the browser rendering engine use the generated code to process the same test cases, and compare the results with each element in the JSON baseline file; By comparison, any deviation can be located to the specific CSS property and the intermediate DSL representation file. Based on the mapping relationship of the block structure in the file, the CSS rule content can be located, thus forming a complete traceability chain from "rendering deviation → rule file → W3C specification clause".

[0037] In the above embodiments, to achieve better results, a "rules and algorithms" separation architecture design can also be considered. See Figure 4 This diagram illustrates a schematic design for a rule-and-algorithm separation architecture. In this scheme, the browser rendering engine code is divided into two categories: one is rule-based code (rule code), which is automatically generated according to the steps in the aforementioned embodiments. This code may include: mapping CSS property values ​​to the engine's internal representation (@map) code, conditional judgment and setting of rendering flags (w3c-rule) code, attribute extraction and data access boilerplate (@extract) code, child node classification logic (@classify) code, pipeline orchestration skeleton (@pipeline) code, mathematical formula calculation (w3c-formula) code, etc.; the other category is algorithm code. This code can be manually written by engineers and stored in a separate directory (e.g., layout / algo / ). This code may include: margin collapsing algorithm code, flex distribution algorithm code, grid track sizing algorithm, float placement algorithm code, inline formatting context code, etc. These two types of code can be connected via a slot function interface: the pipeline skeleton calls slot::xxx() at a fixed position (the compiler ensures that the signature of the slot function called by the pipeline skeleton is consistent with the declaration in the algorithm registry). By separating the two types of code, on the one hand, the proportion of automatically generated code can be maximized, achieving full automation of rule code changes. For example, the proportion of the first type of code in the browser rendering engine code can be 60%-70%, and the proportion of the second type of code can be 30%-40%; on the other hand, the flexibility of code implementation is also guaranteed.

[0038] The following explanation, with reference to specific embodiments, further illustrates the points. As mentioned in the background section of this application, the W3C CSS working group maintains over 80 independent CSS module specifications, including CSS Color 4, CSS Flexbox 1, CSS Grid 2, CSS Masking 1, etc. The implementation process will be illustrated below using these specifications as examples.

[0039] Example 1: Code implementation of CSS Color 4 opacity rule The original W3C CSS specification (CSS Color 4 §11) is as follows: > opacity: 0 — The element is fully transparent (invisible) > Values ​​between 0 and 1 indicate intermediate transparency levels The above natural language was then converted into a DSL intermediate representation file, css-color-4__opacity-alpha.v2.spec.md. This intermediate representation file contains the following structural blocks: (1) Metadata block (YAML block) w3c-spec:css-color-4 / Recordation specification identifier w3c-section: "11. Transparency" / Standard section number (2) Binding declaration block (w3c-bind block): root: RuleContext / Context Type flags-type: PaintRunPlanFlags / Flag type property-map: / Mapping relationships opacity-is-zero: ir_opacity_is_zero opacity-is-full: ir_opacity_is_full (3) Rule block (w3c-rule block): @rule fully_transparent: @ref css-color-4 §11 @when opacity-is-zero is true / condition description @then set FULLY_TRANSPARENT / action description @rule opacity_partial: @ref css-color-4 §11 @when opacity-is-zero is not true AND opacity-is-full is not true @then set OPACITY_PARTIAL These structural blocks are parsed by the compiler, and the extracted structural blocks are used to generate target language code. Here, we take Rust as an example to generate target code: Rust code generated by the DSL compiler: / / Generated from css-color-4__opacity-alpha.v2.spec.md / / W3C ref: css-color-4 §11 / / / fully_transparent — css-color-4 §11 #[inline] fn rule_fully_transparent(ctx: &RuleContext, flags: &mutPaintRunPlanFlags) { if ctx.ir_opacity_is_zero { / / @when opacity-is-zero is true flags.insert(PaintRunPlanFlags::FULLY_TRANSPARENT); / / @then set } } / / / opacity_partial — css-color-4 §11 #[inline] fn rule_opacity_partial(ctx: &RuleContext, flags: &mutPaintRunPlanFlags) { if !ctx.ir_opacity_is_zero &&!ctx.ir_opacity_is_full { flags.insert(PaintRunPlanFlags::OPACITY_PARTIAL); } } Example 2: Code Implementation of the CSS Color 4 Gamut Mapping Formula Original W3C Specification (CSS Color 4 §13.2): > The CSS gamut mapping algorithm uses DeltaEOK, the Euclidean distance in OKLab color space > Mathematical definition: ΔE_OK = √[(L1 - L2) 2 +(a1 - a2) 2 +(b1-b2) 2 ] The above natural language is then converted into a DSL intermediate representation file. This intermediate representation file contains the following structural blocks: Formula block (w3c-formula block) @formula delta_e_ok: @ref css-color-4 §13.2 @input l1: f32, # OKLab L of color 1, [0, 1] a1: f32, # OKLab a of color 1 b1: f32, # OKLab b of color 1 l2: f32, # OKLab L of color 2 a2: f32, # OKLab a of color 2 b2: f32 # OKLab b of color 2 @output delta_e: f32 @let dl = l1 - l2 @let da = a1 - a2 @let db = b1 - b2 @return sqrt(dl * dl + da * da + db * db) The compiler parses the structure blocks, extracts the structure blocks, and generates target language code. Here, we take Rust as an example to generate target code: Rust code generated by the DSL compiler: / / Generated from css-color-4__gamut-formulas.v2.spec.md / / W3C ref: css-color-4 §13.2 / / / DeltaEOK — Perceptual color distance in OKLab space #[inline] fn delta_e_ok(l1: f32, a1: f32, b1: f32, l2: f32, a2: f32, b2: f32) -> f32 { Let dl = l1 - l2; Let da = a1 - a2; let db = b1 - b2; (dl * dl + da * da + db * db).sqrt() } Example 3: CSS Value Mapping Code Implementation The contents of the DSL intermediate code file include: @map clear_kind(ClearValue → ClearKind, dir: Direction): @ref css2 / visuren §9.5.2 Left→ Left Right→ Right Both → Both InlineStart → if dir==Rtl: Right else: Left InlineEnd→ if dir==Rtl: Left else: Right _ → None Generated Rust code: / / Generated from css-page-floats-3__float-clear.v2.spec.md / / W3C ref: css2 / visuren §9.5.2 #[inline] fn _map_clear_kind(input: ClearValue, dir: Direction) -> ClearKind { match input { ClearValue::Left => ClearKind::Left, ClearValue::Right => ClearKind::Right, ClearValue::Both => ClearKind::Both, ClearValue::InlineStart => if dir == Direction::Rtl {ClearKind::Right} else { ClearKind::Left}, ClearValue::InlineEnd => if dir == Direction::Rtl {ClearKind::Left} else { ClearKind::Right}, _ => ClearKind::None, } } Example 4: Attribute Extraction Code Implementation The contents of the DSL intermediate code file include: @extract flow_context: direction: ir.direction → Direction| Ltr writing_mode: ir.writing_mode → WritingMode | HorizontalTb trim_block_start: ir.margin_trim & MARGIN_TRIM_BLOCK_START trim_block_end: ir.margin_trim & MARGIN_TRIM_BLOCK_END container_display: hot(entity).display | display::BLOCK Generated Rust code: struct FlowContext { direction: Direction, writing_mode: WritingMode, trim_block_start: bool, trim_block_end: bool, container_display: u8, } fn _extract_flow_context(world: &World, ir: &LayoutInputIR, entity:Entity) -> FlowContext { FlowContext { direction: _map_direction_layout(ir.direction), writing_mode: _map_writing_mode_layout(ir.writing_mode), trim_block_start: (ir.margin_trim & MARGIN_TRIM_BLOCK_START)!= 0, trim_block_end: (ir.margin_trim & MARGIN_TRIM_BLOCK_END) != 0, container_display: world.get:: <stylehotcomp>(entity) .map(|h| h.display).unwrap_or(display::BLOCK), } } The above content provides a detailed description of the method embodiments of this application. Correspondingly, this application also provides system embodiments. See also... Figure 5 This figure illustrates a structural block diagram of a browser rendering engine specification-driven code generation system. In this system embodiment, system U50 includes an intermediate representation file generation module U51, an intermediate representation file parsing module U52, and a target language code generation module U53. Specifically: the intermediate representation file generation module U51 converts the natural language text of the W3C CSS specification into a structured Domain-Specific Language (DSL) intermediate representation file. The DSL intermediate representation file contains at least one structural block, which maps to one or more functions of each CSS module in the W3C CSS specification text. The intermediate representation file parsing module U52 parses the DSL intermediate representation file and extracts the structural blocks. The target language code generation module U53 generates browser rendering engine specification target language code based on the type of the structural blocks. The same DSL intermediate representation file generates the same browser rendering engine specification target language code. This system embodiment achieves the same technical effects as the aforementioned method embodiment; to avoid repetition, further details are omitted here. Of course, the system embodiment can also be optimized according to the various optimization schemes described in the foregoing method embodiments, and the optimized embodiment can also achieve better results. Furthermore, the technical solution of this application can be formed on a computer-readable storage medium to form a computer program.

[0040] The embodiments of this application can achieve all the inventive objectives using the aforementioned software; therefore, the software portion has been primarily described. Those skilled in the art should understand that the embodiments of this application can be provided as an apparatus, system, or related computer program product. Therefore, this application can be implemented entirely in hardware, entirely in software, or in a combination of software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0041] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0042] 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.

[0043] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0044] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0045] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0046] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0047] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0048] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.< / stylehotcomp> < / flagstype> < / contexttype> < / stmt> < / category> < / stmt> < / type> < / name> < / category> < / condition> < / category> < / condition> < / category> < / section> < / spec-id> < / type> < / name> < / mask> < / field> < / propid> < / field> < / field> < / default> < / typeconversion> < / field> < / name> < / defaultexpr> < / expr2> < / cond> < / inputvariant> < / outputexpr> < / inputvariant> < / section> < / spec-id> < / type> < / outputtype> < / inputtype> < / name> < / expression> < / expression> < / var> < / comment> < / type> < / result> < / comment> < / type> < / section> < / spec-id> < / value> < / value> < / section> < / spec-id> < / default> < / cond>

Claims

1. A method for generating browser rendering engine specification-driven code, characterized in that, The method includes: The W3C CSS specification's natural language text is converted into a structured domain-specific language intermediate representation file, which contains at least one structure block that maps to one or more functions of each CSS module in the W3C CSS specification text. The domain-specific language intermediate representation file is parsed, the structural blocks are extracted, and browser rendering engine specification target language code is generated according to the type of the structural blocks, wherein: the domain-specific language intermediate representation files are the same, and the generated browser rendering engine specification target language code is the same.

2. The method according to claim 1, characterized in that, The process of converting the natural language text of the W3C CSS specification into a structured domain-specific language intermediate representation file specifically includes: The W3C CSS specification's natural language text is transformed into a structured domain-specific language intermediate representation file using a large language model, and the domain-specific language intermediate representation file is reviewed to form the domain-specific language intermediate representation true source file.

3. The method according to claim 1, characterized in that, The method also includes automatically injecting the target language code into the browser rendering engine during runtime via a build system.

4. The method according to claim 3, characterized in that, The process of automatically injecting the target language code into the browser rendering engine through the build system specifically includes: Build a monitoring script to monitor changes to the domain-specific language intermediate representation file; When a change is triggered, the target language code is regenerated and output to the build directory; Import the target language code regenerated in the build directory when the browser rendering engine is running.

5. The method according to claim 1, characterized in that, The method further includes: During the compilation and parsing phase, syntax checking of the domain-specific language intermediate representation file is performed, and / or... Registry consistency checks are performed during the compilation and verification phase, and / or, During the target language generation phase, type checking is performed on the generated target language code, and / or... Baseline tests are performed on the rendering results of the target language code to reference the implementation.

6. The method according to claim 5, characterized in that, The baseline test of the rendering results of the target language code specifically includes: Use automated tools to render test cases in the browser engine, and record the precise layout coordinates and calculated styles of each element as a JSON baseline file; Use the browser's rendering engine to generate code that processes the same test cases, and compare the results element-by-element with the JSON baseline file. Based on the comparison results, locate the domain-specific language intermediate representation file and CSS rule content.

7. The method according to claim 1, characterized in that, The method further includes: The target language code is connected to the algorithm code in the browser rendering engine code through a slot function interface.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 7.

9. A browser rendering engine specification-driven code generation system, comprising an intermediate representation file generation module, an intermediate representation file parsing module, and a target language code generation module, wherein: The intermediate representation file generation module is used to convert the natural language text of the W3C CSS specification into a structured domain-specific language intermediate representation file. The domain-specific language intermediate representation file contains at least one structure block, and the structure block has a mapping relationship with one or more functions of each CSS module in the W3C CSS specification text. The intermediate representation file parsing module is used to parse the domain-specific language intermediate representation file and extract the structural blocks; The target language code generation module is used to generate browser rendering engine specification target language code according to the type of the structure block, wherein: the domain-specific language intermediate representation files are the same, and the generated browser rendering engine specification target language code is the same.

Images