WebRPG: Automatic Web Rendering Parameters
Generation for Visual Presentation

Web design is centered on visual presentation, i.e., the manipulation of CSS code. The complexity of CSS coding practices, including a wide range of selector options, makes the automatic generation of CSS code challenging [26]. To facilitate the model for learning web design, we standardize CSS by converting it into rendering parameters (RPs), which can be transformed back into CSS, with additional details in Sec. A.1. Consequently, the WebRPG task is defined as follows: given the HTML code, generate rendering parameters for each web element. Specifically, given a web page $\mathcal{X}$, whose HTML code is $\mathcal{H}$, it consists of a set of elements $\mathcal{X}=\{X_{1},X_{2},\ldots,X_{S}\}$, where $S$ is the number of elements in $\mathcal{X}$. The visual appearance of element $X_{i}$ is controlled by a set of RPs denoted as $P_{i}=\{p_{i}^{k}\mid k\in\mathcal{W}\}$, where $\mathcal{W}$ indicates the indices for all RPs, and the complete set of RPs for $\mathcal{X}$ is $\mathcal{P}=\{P_{1},P_{2},\ldots,P_{S}\}$. Therefore, the primary objective of the WebRPG task is to create a function $f$ that generates RPs based on HTML code, that is, $f:(\mathcal{H})\mapsto\mathcal{\hat{P}}$, where $\mathcal{\hat{P}}$ represents the estimate of $\mathcal{P}$.

The term “Rendering Parameters (RPs)” is employed to collectively describe the parameters controlling the visual appearance of each web element on the browser, as defined by CSS properties. Layout and visual style are crucial in the design of web pages [67, 60], leading us to summarize 13 common CSS properties, divided into 3 categories as follows.

• •

  Layout properties include left, top, width, and height.

• •

  Text properties include font-style, font-weight, font-size, line-height, text-align, text-decoration, and text-transform.

• •

  Color properties include color and background-color.

Various formats are available for web developers to define CSS properties. To standardize, we adopt the values computed by the browser [47] as the reference. Specifically, the values related to position and size are uniformly measured in integer pixels, and the values related to color correspond to 46 widely used colors. The vocabulary for all rendering parameters is available in Sec. A.1.

Raw web pages cannot provide straightforward supervision for RPs. Thus, several pre-processings are conducted. Headless chrome⁴⁴4https://developer.chrome.com/blog/headless-chrome/ is used to render web pages and selenium⁵⁵5https://www.selenium.dev/ is employed to store HTML with only visible elements and record each element’s selected CSS properties. Note that elements in this paper mean nodes in the DOM⁶⁶6https://www.w3.org/DOM/DOMTR tree. The elements are stored following the DOM tree’s pre-order traversal. Since many web pages retain thousands of elements, we treat elements with a certain number of children as sub-pages with the semantic and hierarchical integrity preserved. The sub-pages are further cleaned while keeping the visual appearance, including removing uncommon HTML tags and intricate components like carousel images, as well as placing sub-pages at the top-left corner of the browser. Additionally, we only consider static components. Our models disregard the image on web pages, preserving only $\textless$img$\textgreater$ tags. To guarantee data quality, a specific Visual Complexity (VC) metric is introduced to assist in filtering samples. The metric integrates three dimensions: color, size, and alignment, inspired by previous works [1, 15]. The definition of the VC metric is provided in Sec. A.2.

To accommodate the requirement for offline rendering, the Klarna dataset [22] is utilized to build our WebRPG dataset. The Klarna dataset, initially used for web information extraction, comprises 20K English product pages from 3K e-commerce sites, ensuring domain-specific diversity. The dataset stores all pages in MHTML⁷⁷7https://en.wikipedia.org/wiki/MHTML format, enabling offline rendering of the original pages in browsers with high fidelity.

The pre-processing in Sec. 4.1 is applied to the web pages with the browser canvas size setting to 1920*1920 pixels, generating sub-pages containing between 32 and 128 child elements. The token length for each sample (sub-page) does not surpass 512. The size of RP vocabulary is 1993. The samples with a VC below 0.1 are filtered out. After preprocessing, our dataset includes 88,418 samples, split into training and testing sets at an 8:2 ratio. Our dataset exceeds the size of established graphic design datasets such as CLAY [38] (50K samples) and RICO [44] (43K samples), ensuring it can meet our objectives. Screenshots of some samples are shown in Fig. 2. More details are provided in Sec. A.3.

As indicated in Sec. 3.1, the WebRPG task is formulated as a function that generates rendering parameters (RPs) for each web element based on the HTML code. Inspired by classical generation methods [57, 50, 56], we employ a latent generation approach. In the approach, VAE is leveraged to compress all RPs of an element into latent space representation (Sec. 5.2), and a generative model (Sec. 5.4) generates the latent vector based on the given HTML embeddings (Sec. 5.3), which is then decoded back into RPs by the decoder of VAE. The key components of our method are shown in Fig. 3.

Assume a web page consists of $S$ elements, with the appearance of each element $X_{i}$ determined by $\mathcal{W}$ rendering parameters $P_{i}=\left\{p_{i}^{k}\mid k\in\mathcal{W}\right\}$. The WebRPG model necessitates the processing of $S\times\mathcal{W}$ values for both input and output. Expanding all $p_{i}^{k}$ of $X_{i}$ into a one-dimensional sequence, as per graphic design methods [24, 35], leads to excessively long input and output lengths. To mitigate this challenge, we utilize VAE to compress the rendering parameters into a latent space. This ensures that the input length for the generative model correlates solely with $S$.

More precisely, given the RPs of an element $P_{i}\in\mathbb{R}^{\mathcal{W}*V}$, where $V$ is the size of RPs vocabulary (Sec. 3.2), and the corresponding latent vector is $Z_{i}\in\mathbb{R}^{d}$. We denote the generative distribution as $p_{\theta}(P_{i}\mid Z_{i})$ and the posterior as $q_{\phi}(Z_{i}\mid P_{i})$, respectively. The learning objective of VAE is expressed as:

where $\theta$ and $\phi$ are the encoder and decoder parameters, $\mathbb{E}$ indicates the expectation, $\mathrm{KL}$ is the Kullback-Leibler divergence, and $\lambda_{KL}$ is the hyperparameter to balance the two terms. The encoder and decoder of VAE both consist of a multilayer perceptron with five layers. To ensure that the latent space encompasses as many element appearances (i.e., combinations of RPs) as possible, the VAE is pre-trained using synthetic data.

The visual presentation of a web page should be in harmony with the content and structure dictated by its HTML code. To this end, we design an HTML embedding that captures the essential information in the HTML code, establishing the input feature for the generative model (Sec. 5.4). HTML code essentially encompasses hierarchical information among elements and the textual content of each element [10]. The character count of each element is also crucial, as the size of an element generally exhibits a positive correlation with the length of characters. Therefore, our HTML embedding integrates three facets of information: semantics, hierarchy, and character count. Precisely, for an element $X_{i}$, its HTML embedding $H_{i}\in\mathbb{R}^{d}$ is defined as:

where $H_{i}^{\text{Sem}}$, $H_{i}^{\text{Hier}}$ and $H_{i}^{\text{CharC}}$ denote the semantic, hierarchical and character count embedding respectively, and $\Lambda^{\circ}()$ is the linear projection layer.

Semantic embedding: The MarkupLM_large model [41], a language model explicitly pre-trained for web understanding, is employed as the semantic extractor. Specifically, given an element $X_{i}$ with HTML code tokens $X_{i}=\{x_{i}^{j}\mid j\in\mathcal{L}\}$, where $\mathcal{L}$ denotes the token length, we calculate the semantic embedding of $X_{i}$ as $H_{i}^{\text{Sem}}=\text{Pool}(\text{MarkupLM}(x_{i}^{1},x_{i}^{2},\ldots,x_{i}^{\mathcal{L}}))$, where $\text{Pool}(\cdot)$ denotes an average pooling operation.

Hierarchical embedding: The XPath embedding layer [41] is employed to model the hierarchical information of elements, taking their XPath expressions as input. XPath⁸⁸8https://www.w3.org/TR/xpath-31/ is a query language for selecting elements from a web page, which is based on the DOM tree and can be used to easily locate an element. Specifically, for an element $X_{i}$ with its corresponding XPath expression $xp_{i}$, we compute the hierarchical embedding directly as $H_{i}^{\text{Hier}}=\text{XPathEmb}(xp_{i})$.

Character count embedding: We establish a mapping mechanism that translates the raw count of characters into dense vector space. For an element $X_{i}$ with the content of $k$ characters, the character count embedding is calculated as $H_{i}^{\text{CharC}}=\text{EmbCharC}(k)$.

Two generative models are implemented: autoregressive and diffusion model.

Autoregressive Model (AR): To enhance the model stability during training, a masked latent vector $\mathcal{Z}_{mask}$ of real RPs is introduced inspired by BART [36] and MaskGIT [4]. $\mathcal{Z}_{mask}$ is constructed in two steps. Firstly, the real RPs are encoded into the latent vectors with the VAE encoder, i.e., $\mathcal{Z}=\theta(\mathcal{P})$. Then a special $MASK$ vector and a binary mask $M=\{m_{i}\mid i\in S\}$ are utilized to partially substitute the real latent vectors with the $MASK$ as $Z_{mask,i}=m_{i}\cdot MASK+(1-m_{i})\cdot\theta(P_{i})$.

Here $M$ is generated using a mask scheduling function $\gamma(r)\in(0,1]$ following MaskGIT [4], and the $MASK$ vector is a learnable parameter with the same shape as $Z_{i}$. Additionally, it is important to highlight that during inference, all $Z_{i}$ are masked, i.e., $M=\{m_{i}=1|1\leq i\leq S\}$.

As depicted in Fig. 3, the model inputs the sum of $\mathcal{Z}_{mask}$ and $\mathcal{H}$ to generate $\hat{\mathcal{Z}}$, which is then decoded by the VAE decoder as $\mathcal{\hat{P}}=\phi(\hat{\mathcal{Z}})$. The VAE and generative models are trained jointly, thus the training loss is as follows:

where $\psi$ is the parameters of the generative model.

Diffusion Model: Diffusion models [21, 48, 75] have recently emerged as a new class of generative models with high performance. These models are characterized by forward and reverse Markov processes of length $T$. In our rendering parameters compression (VAE) model, rendering parameters $\mathcal{P}$ are encoded into a latent space, i.e., $\mathcal{Z}=\theta(\mathcal{P})$. These latent vectors $\mathcal{Z}$, which align more closely with a Gaussian distribution, improve compatibility with the noise distribution in diffusion models. Following successful models [11, 57, 59], our diffusion model can be interpreted as an equally weighted sequence of denoising autoencoders $\mathcal{E}(\mathcal{Z}_{t},t,\mathcal{H});t=1\ldots T$, which are trained to predict the noise $\boldsymbol{\epsilon}\sim\mathcal{N}(\mathbf{0},\mathbf{I})$ in $\mathcal{Z}_{t}$. The $\mathcal{Z}_{t}$ is obtained from a forward process starting from $\mathcal{Z}_{0}$ (where $\mathcal{Z}_{0}=\mathcal{Z}$), defined as $\mathcal{Z}_{t}=\sqrt{\alpha_{t}}\mathcal{Z}_{t-1}+\sqrt{1-\alpha_{t}}\boldsymbol{\epsilon}$, with $\alpha_{t}$ being a predefined set of coefficients. As illustrated in Fig. 3, $\mathcal{Z}_{t}$ and $\mathcal{H}$ are added and input into the model. Our diffusion model employs the standard variational lower bound objective as its training loss, and we jointly optimize the VAE, leading to the overall loss function:

During inference, the predicted $\mathcal{\hat{Z}}$ is progressively obtained through a reverse process, expressed as $\mathcal{Z}_{t-1}=\frac{1}{\sqrt{\alpha_{t}}}\left(\mathcal{Z}_{t}-\frac{1-\alpha_{t}}{\sqrt{1-\alpha_{t}}}\boldsymbol{\epsilon}_{\psi}(\mathcal{Z}_{t},t,\mathcal{H})\right)$. Subsequently, $\mathcal{\hat{Z}}$ is decoded to $\mathcal{\hat{P}}$ via a single pass through the VAE decoder $\phi$. Additionally, $\mathcal{Z}_{T}$ is random Gaussian noise.

Three metrics are utilized to assess the quality of the generated rendering parameters. Fréchet Inception Distance (FID), Element Intersection over Union (Ele. IoU), and newly introduced Style Consistency Score (SC Score) enable the evaluation of the overall appearance, layout, and style of generated web pages respectively. As indicated in Sec. 3.2, “layout” refers to layout properties, while “style” encompasses text properties and color properties.

Two baselines are implemented: autoregressive (WebRPG-AR) and diffusion model (WebRPG-DM). The VAE, hierarchical embedding, and character count embedding are jointly trained with the backbone, and the semantic embedding is produced by frozen pre-trained MarkupLM_large [41]. The XPath embedding layer is initialized following Li et al. [41]. All baselines are based on Transformer [63] and have approximately 50M of parameters to ensure fair comparison, whose hidden dimensions are 128. The dimensions of latent vector and HTML embedding $d$ is 128. For optimization, AdamW [45] is used with a learning rate of 1.2e-4. All models are trained for 1M steps with a batch size of 300.

Additionally, LLMs have been gaining adoption in different domains. We assess GPT-4 [70, 51], StarCoder2-7b [46], DeepSeek-Coder-6.7b [18], CodeLlama-13B [58] on the WebRPG task. GPT-4 is one of the state-of-the-art LLMs, while the others are open-source models known for code generation. Due to limited resources, we randomly select 10% of test samples. The prompt template employs in-context learning [3], incorporating a task description, three demonstrations, and a test instance. Further details are available in Sec. A.5.

We present quantitative results in Tab. 1 and qualitative results in Fig. 4. Regarding the results of real data, in addition to the normally rendered web page (Tab. 1, “Real Web Pgae”), we also report the web page rendered using only HTML code (Tab. 1, “Plain HTML”). Since the browser would apply default CSS when custom CSS is absent, some models perform worser than the plain HTML due to unreasonable generated RPs. The FIDs for real data are calculated between the test set and other real web pages.

The experimental results show that WebRPG-AR consistently surpasses other baselines. Its sequential decoding mechanism allows for more refined control based on previously generated results [13, 68]. As shown in Fig. 4 a, b, e, WebRPG-AR demonstrates impressive visual quality in detail.

The performance of WebRPG-DM is suboptimal across all metrics. It only tends to produce standard web visual presentations in simpler cases, as illustrated in Fig. 4 e, such as bolding prices, adding background color to buttons, and aligning a few elements. This implies that diffusion models may be inappropriate for this task. There are two plausible explanations: First, unlike images and videos in Euclidean space, web elements are non-Euclidean due to their hierarchical arrangement, while diffusion models are confined to Euclidean space [33]. Second, the WebRPG task demands meticulous adjustments and detailed control for realism, a limitation of diffusion models [43].

GPT-4’s performance on the WebRPG task surpasses that of WebRPG-DM and falls short of WebRPG-AR. Open-source LLMs underperform compared to GPT-4. As illustrated in the Fig. 4 a,b,e, GPT-4 can effectively handle element styles, such as adding background colors to buttons and applying distinct colors for prices. However, the performance of GPT-4 in layout is limited. As demonstrated in Fig. 4 a-c, GPT-4 tends to generate simplistic vertical arrangements when faced with complex HTML structures. With regular HTML, as depicted in Fig. 4 e, GPT-4 achieves a layout that is similar to the real page. Therefore, we conclude that GPT-4 demonstrates basic capability in WebRPG tasks with regular HTML, but its performance with complex HTML is less effective. Additionally, we notice that LLMs do not generate RPs for all elements, causing many to use the browser’s default CSS, resulting in performance similar to plain HTML.

It is worth noting that WebRPG-AR exhibits the ability to render diverse web pages. For example, Fig. 4 d shows WebRPG-AR’s creation of a page with a vertical layout (originally horizontal), preserving the pattern and order consistency across four groups. This finding suggests that the model successfully learns web design knowledge and applies it effectively to render web pages from HTML code. Further cases are available in Sec. B.1.

Furthermore, we calculate the FID on screenshots of rendered web pages, following conventional image generation practices [55, 57]. The results, shown in Sec. B.2, are consistent with Tab. 1. Additionally, we conduct a human evaluation, detailed in Sec. B.4, with results that also align with Tab. 1.

We conduct a series of ablation experiments based on WebRPG-AR, as shown in Tab. 2. #1 uses a one-dimensional flat input instead of VAE. #2 removes $\mathcal{Z}_{mask}$ (in Sec. 5.4). #3 and #5 respectively remove the corresponding embedding layers, while #4 substitutes hierarchical embedding with one-dimensional positional embedding. Additionally, we visualize some cases from #3, #4, and #5 in Fig. 5. All models are trained to convergence following the settings in Sec. 6.2.

The results of #1 demonstrate the effectiveness of using VAE for rendering parameters compression. Although #2 is comparable to #6, the incorporation of $\mathcal{Z}_{mask}$ enhances the model stability during training. The results of #3, #4, and #5 reveal that all three embeddings play critical roles in web design. Hierarchical embedding helps layout arrangement significantly. The simplification to 1D positional embedding leads to a disorganized layout, as illustrated in Fig. 5 c. Semantic embedding enhances the model with the capacity to perceive semantic relationship. For example, as Fig. 5 b shows, the model struggles to horizontally align elements like “select a color” and “sunshine,” suggesting challenges in identifying key-value pairs without semantic information. Character count embedding helps to predict appropriate element sizes for full content display, as in Fig. 5 d, where a narrow “price” and “sunshine” width leads to incomplete text display.

To investigate the boundaries of the model’s capabilities, we analyze several failure cases generated by WebRPG-AR. The left side of Fig. 6 reveals that both layout (Ele. IoU) and style (SC Score) metrics decrease with an increase in the number of elements or the average depth of elements within the DOM tree. This trend may be attributed to two factors: the inherent complexity of a page increases with more elements or greater depth, and the training set lacks web pages with a large number of elements or significant depths (details in Sec. A.3). Regarding error types, layout issues mainly include misalignments and overlaps, as shown in Fig. 6 a and b. For style, the model struggles to recognize web page elements with identical semantic functions, such as the “Add to Cart” buttons illustrated in Fig. 6 c, which should appear identical. Moreover, we observe two primary error scenarios: elements positioned at the end of the HTML code tend to be more error-prone, as seen with the element in the bottom right corner of Fig. 6 b, likely due to the characteristics of the autoregressive model [12]; additionally, pages with large-scale images pose challenges, as shown in Fig. 6 a, since the model does not take the original images as input. The discussion above highlights the need for further research.

Recently, LLMs have enabled the possibility of automatically generating HTML code [39]. Consequently, we hypothesize that integrating LLM into a WebRPG system could facilitate a fully automated web development workflow. We employ GPT-4 [70, 51] to validate this hypothesis. As Fig. 7 illustrates, WebRPG-AR effectively creates visual presentations of web pages based on generated HTML, demonstrating the potential of a fully automated web development workflow through the integration of LLM and WebRPG. Additional cases and the prompt for automatically generating HTML are provided in Sec. B.3.

As described in Sec. 3.1, we utilize rendering parameters to standardize CSS due to its code complexity. The examples in Fig. 8 demonstrate this complexity. As shown on the left side of Fig. 8, CSS can be utilized in different forms¹⁰¹⁰10https://www.w3schools.com/css/css_howto.asp: Inline Styles for direct HTML element styling via the “style” attribute; Internal Style Sheets using “$\textless$style$\textgreater$” tags within HTML documents; and External Style Sheets linking to CSS files externally. The middle of Fig. 8 showcases various CSS selectors¹¹¹¹11https://www.w3schools.com/css/css_selectors.asp, including simple tag, class, and ID selectors, as well as complex attribute and descendant selectors. Furthermore, CSS follows certain rules regarding inheritance and overrides¹²¹²12https://developer.mozilla.org/en-US/docs/Web/CSS/Inheritance. An example on the right side of Fig. 8 shows how the .highlight class’s red color is overridden by the more specific ID selector #main-content p, turning the color green.

The complexity of CSS makes direct generation of CSS impractical. Even parsing CSS code to obtain WebRPG task labels is challenging. Since browsers compute the final applied CSS property values (i.e., rendering parameters) for each element based on HTML and CSS to render web pages, we propose extracting each element’s RPs directly from the browser, as described in Sec. 3.2. This approach bypasses the need to parse CSS code, achieving the standardization of CSS.

In practice, we follow the pre-order traversal order of the DOM tree to assign a unique ID to each element, achieved by modifying the class name, as shown on the left side of Fig. 9. We organize the rendering parameters using JSON, where the key is the element’s ID, as illustrated in the middle of Fig. 9. RPs can also be transformed into CSS, utilizing class selectors only, as demonstrated on the right side of Fig. 9.

Additionally, the complete vocabulary of all rendering parameters is detailed in Tab. 3, and index ranges of each rendering parameter are presented in Tab. 4.

The Visual Complexity (VC) metric integrates three dimensions: color, size, and alignment. For any given web page, the three dimensions are defined as follows:

Color: The color metric measures the richness of colors and is defined as:

where $N$ is the number of elements, and $C_{c}$ and $C_{bg}$ are the counts of unique color and background-color attributes respectively.

Size: The size metric measures the diversity of sizes among web page elements. In particular, it calculates the size diversity for all $N^{\prime}$ parent elements and then computes the average. The formula is as follows:

with $NC_{i}$ and $DS_{i}$ being the count of child elements and their distinct sizes for element $i$, respectively.

Alignment: The complexity of a web page inversely correlates with the number of pairwise alignments [15]. To simplify, this metric applies only to leaf nodes. The calculation formula is as follows:

where $N_{leaf}$ denotes the number of leaf node elements, and $ALG_{ij}$ is a binary indicator of alignment (1) or misalignment (0) between elements $i$ and $j$.

The overall VC is the sum of three metrics: $VC=VC_{\text{color}}+VC_{\text{alg}}+VC_{\text{size}}$.

The distribution of Visual Complexity (Sec. A.2) values across all samples is illustrated in Fig. 10. In our dataset, samples with a VC value of less than 0.1 are filtered out, resulting in a remaining subset where the VC distribution is relatively concentrated and approximates a normal distribution, thereby helping to mitigate the impact of extreme samples on training. Additionally, to further investigate our dataset, we visualize two crucial statistical values, element count and the average depth of elements, in Fig. 11. This visualization indicates that the dataset lacks samples containing a large number of elements or considerable element depths.

As described in Sec. 6.1.1, the FID model is a binary classifier, incorporating a VAE described in Sec. 5.2, four transformer layers, and a classification header. A special CLS vector is utilized as the classification feature, representing all RPs. The rest of the input is the same as the model in Sec. 5.4. Three kinds of noise are designed to pollute the real data, namely perturbing the original values with a fixed variance, randomly substituting elements with synthetic ones, and randomly swapping elements. The specific FID models for layout and style, namely FID_layout and FID_style, are trained by masking irrelevant inputs. Specifically, FID_layout processes only the layout, masking the style, and FID_style processes only the style, masking the layout. The FID models for overall, layout, and style, achieve classification accuracies of 88.8%, 95.5%, and 92.4%, respectively.

The backbone of WebRPG-AR consists of 6-layer transformers for both encoder and decoder, and WebRPG-DM is a 12-layer U-ViT. The mask scheduling function $\gamma(r)$ is a cosine function, the time steps $T$ in diffusion follows [21] with a value of 1000, and $\lambda_{KL}$ is set to 1e-6. For optimization, AdamW [45] is used with a learning rate of 1.2e-4, $\beta_{1}$ of 0.9, and $\beta_{2}$ of 0.99.

The prompt template for the LLMs experiment in Sec. 6.3 is detailed in Tab. 5. Due to the extensive length of textual representation for each element’s RPs, as shown on the right side of Fig. 9, we opt to have LLMs directly generate the CSS code. The specific steps for conducting the LLMs experiment are:

1. 1.

   Use the prompt to generate CSS code via LLMs.

2. 2.

   Use a browser to render the web page with the given HTML and the CSS code generated by LLMs.

3. 3.

   Extract the RPs for all elements, employing the method in Sec. 4.1.

4. 4.

   Evaluate these RPs using the metrics in Sec. 6.1.

We present additional results from WebRPG baselines in Fig. 12. These results exhibit the performance of all baselines comparable to that outlined in Sec. 6.3. Additionally, Fig. 13 displays the web page variants generated by WebRPG-AR based on the same HTML, each produced through individual inferences. The differences in layout and style among these variants indicate that WebRPG-AR can generate diverse web pages while maintaining semantic coherence.

The FID on screenshots of rendered web pages is shown in Tab. 6.

Fig. 14 showcases more cases of WebRPG-AR creating visual presentations of web pages based on HTML code generated by GPT-4. The prompt template for automatically generating HTML is in Tab. 7. The prompt encompasses human-authored descriptions of web design ideas, with an example shown in Tab. 8.

We conduct a human evaluation using pairwise comparisons. We randomly select 100 test samples and generate visual presentations using WebRPG-AR, WebRPG-DM, and GPT-4. Five human annotators evaluate each pair to determine the superior presentation or if there is a tie. The results, shown in Fig. 15, align with the objective evaluations in Tab. 1.