Pith. sign in

REVIEW 3 major objections 6 minor 39 references

Does It Render Everywhere? A Study of Cross-Environment Compatibility in MLLM-Generated Webpages

T0 review · 3 major / 6 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read AI-generated webpages are not cross-environment reliable: 68% fail in at least one of nine rendering environments, mostly from missing viewport meta tags and inflexible wrapping.

desk verdict Worth engaging: a genuinely useful first empirical study of cross-environment compatibility in AI-generated webpages, but the headline 68% prevalence figure is computed after dropping 47% of generated outputs and should be qualified or bounded before publication. read the letter →

arxiv 2608.12518 v1 pith:EBYUS4Z7 submitted 2026-08-12 cs.SE

Ziyun Guo , Jingyu Xiao , Yuqiang Sun , Yintong Huo This is my paper · ORCID
classification cs.SE
keywords cross-environmentcompatibilityUI-to-codegenerationmultimodallargelanguagemodelswebrenderingreliabilityresponsivedesigndetectionempiricalsoftwareengineeringAI-generatedwebpages
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that current UI-to-code evaluation, which checks whether an AI-generated page visually matches a design in one fixed browser and device, misses a crucial deployment property: whether the page still renders correctly in other environments. It builds the first dataset of annotated cross-environment rendering pairs for AI-generated webpages, with 2,032 instances from 254 pages produced by eight generation tools and rendered in nine browser-and-device environments. The headline finding is that 68% of generated pages fail in at least one environment, roughly 1.7 times the failure rate of human-written pages, and that most failures are page-level breakages caused by a few recurring code omissions. The paper also shows that common visual-fidelity scores do not predict these failures, and it proposes a lightweight detector, XCompat, that achieves F1 0.903 on held-out pairs. A sympathetic reader would take the paper as establishing compatibility as a first-class quality dimension for AI-generated front-end code.

What carries the argument

The paper's core object is the rendered-pair comparison: each generated page is rendered in a reference environment and in eight target environments, and each pair yields a screenshot and a post-render DOM tree, meaning the structural document model after layout. The dataset generated from these pairs, with human labels following a two-level taxonomy of page-level and element-level failures, is what carries the prevalence and symptom claims. XCompat carries the detection claim: a page-level module checks viewport metadata, content fill, horizontal overflow, whitespace, and DOM-element overlap, while an element-level module compares matched elements' bounding boxes, aspect ratios, and visibility states; the two module outputs are combined with a logical OR to flag a pair as incompatible.

What would settle it

Render all 480 generated pages, including the 226 currently excluded, across the same nine environments and label them with the same annotation protocol; if the incompatibility rate over the full set falls near or below the 40% human baseline, the headline prevalence is an artifact of the filtering.

Watch

Extended reading notes

Core claim

The paper's central claim is that cross-environment rendering compatibility is a largely independent quality dimension of AI-generated front-end code, one that single-environment visual-fidelity benchmarks do not capture. On a corpus of 2,032 annotated rendering pairs built from 254 generated pages across nine browser-and-device environments, 68% of AI-generated pages show at least one compatibility issue, compared with 40% of human-authored pages; cross-device failures dominate, with 67.5% of pages showing device-only failures versus 1.0% browser-only failures. The failure taxonomy places 88.3% of incompatible pairs in page-level classes—shrink-to-fit, initial scale mismatch, whitespace anomalies, overflow, and overlap—and root-cause analysis attributes most breakage to missing viewport meta tags (46%) and missing flexible wrapping (29.5%), even though responsive constructs are present in 97.5% of pages. The paper also claims that a lightweight detector combining screenshots and post-render DOM trees reaches F1 0.903 on a held-out test set, surpassing existing structural tools and LLM-based baselines.

Load-bearing premise

The study's prevalence figure rests on only the 254 static pages that rendered successfully, because the 226 excluded pages—blank, malformed, broken, or dependent on interactive behavior—were never analyzed.

Editorial extensions

If this is right

  • Pages scored highly by single-environment fidelity metrics can still fail in other environments, so benchmark scores need to be supplemented by a multi-environment compatibility pass before deployment decisions are made.
  • Because cross-device failures outnumber cross-browser failures, generator improvements should target viewport adaptation first.
  • The dominant root causes are two simple omissions, so a repair step that inserts a viewport meta tag and adds wrapping rules could eliminate a large share of observed failures.
  • The offline detector's cost of about 0.13 seconds per comparison makes it practical to run compatibility checks across an entire generation corpus.
  • LLM-based detectors lose accuracy when given full-page screenshots in addition to DOM snapshots, suggesting that single-signal inputs may be preferable for automated triage.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the same small set of code omissions causes most failures, a targeted repair model—not proposed in the paper—could be trained to insert viewport meta tags and wrapping rules, and its effect on the 68% rate would be a direct test of the root-cause analysis.
  • The study's static-page filter excludes interactive layouts; rendering those pages would likely raise the incompatibility rate, since collapsible menus and other dynamic behavior add environment-dependent states that the current corpus cannot measure.
  • Since neutral prompts were used, prompting generators to include viewport meta and responsive wrapping is a cheap, testable intervention that could close much of the gap to the human baseline.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. This paper presents WebCompat, a dataset of 2,032 annotated cross-environment rendering pairs built from 480 candidate pages generated by eight AI tools from 60 source pages, each rendered in nine environments. The authors report that 68% of generated webpages have at least one compatibility issue, that cross-device failures dominate cross-browser failures, that 88.3% of failures are page-level, and that missing viewport meta tags and missing flexible wrapping are the dominant root causes. They also propose XCompat, a DOM- and screenshot-based detector, reporting an F1 of 0.903 on a held-out test set, and compare AI-generated pages with human-authored pages. A key design decision is that 226 of 480 generated pages are removed before annotation, and the prevalence analysis is conducted on 203 of the 254 remaining pages.

Significance. If the results hold, this is a timely and useful contribution: it defines a new evaluation dimension for UI-to-code generation, provides a reusable benchmark with high inter-annotator agreement, and ships an efficient detector with a held-out evaluation and a threshold sensitivity analysis. The taxonomy of symptoms and root causes is practically informative, and the comparison to human-authored pages is a reasonable baseline design. The main caveat is that the headline prevalence and the AI-versus-human comparison depend on the page-filtering protocol; this needs to be resolved before the quantitative claims can be taken at face value.

major comments (3)
  1. [§III-B3 / §IV-A, Finding 1 and Table III] The headline '68% of generated webpages' is the rate on 139/203 pages from the empirical split, after Stage 3 removed 226 of 480 generated outputs (47%). The excluded categories include blank pages, malformed HTML, rendering/capture failures, and layouts that depend on unsupported interactive behavior. The compatibility of these excluded outputs is not analyzed, so the denominator is a curated subset of valid static pages, not the full set of generated outputs. Bounding the excluded outputs gives a range from 139/480 = 29.0% (if all excluded pages are compatible) to 365/480 = 76.0% (if all are incompatible); the lower bound is below the paper's own 40% human baseline, so comparative Finding 2 is not robust to the filtering step. The exclusion of interactive layouts is especially non-neutral because such pages likely come disproportionately from Design2Code-Hard and may have a different compatibility profile. Please report the prevalence as conditional on the static, valid-page protocol and either annotate the excluded pages or provide explicit bounds and a discussion of how the filtering affects Findings 1-3.
  2. [§IV-A, Table III] The per-tool incompatibility rates are based on very small page counts (v0 is 5/19, Cursor is 11/14, Direct-GPT5 is 43/43), and no confidence intervals or per-tool hypothesis tests are reported. The statement that 'the best-performing v0 stands at 0.26' is therefore not strongly supported; the exact binomial 95% interval for 5/19 is roughly 9-51%, which overlaps the rates of several other tools. Please report confidence intervals or exact binomial intervals for the per-cell rates and avoid categorical tool-ranking claims unless the sample sizes support them.
  3. [§V-C, Table VI] The detector is evaluated on a held-out test set, which is good practice, but the reported F1 and accuracy are point estimates over 408 pairs with no confidence intervals, and the sensitivity analysis varies each of the three heuristic thresholds over only two nearby values. Since the failure study in §V-E acknowledges that five false negatives are due to 'conservative thresholds,' the claim that threshold choice does not change predictions is too narrow. Please report confidence intervals for the main metrics and a broader threshold sweep, or state clearly which thresholds are fixed protocol choices rather than tuned parameters.
minor comments (6)
  1. [§III-B3] The filtering step is described in one sentence; with 47% of the data removed, reproducibility requires a breakdown of the number of pages removed in each excluded category.
  2. [§IV-A] The sentence 'DCGen-GPT4 achieve the two highest fine-grained visual scores' should use 'achieves' to agree with the singular subject.
  3. [§V-C] The phrase 'meaning it can detect 91% compatibility issues' is imprecise; F1 = 0.903 is not a recall rate. Use the reported recall (0.889) or phrase the sentence in terms of F1.
  4. [Figure 4] The legend text 'XBI and XBI: 1 (1.7%)' should read 'XDI and XBI: 1 (1.7%)'.
  5. [§V-E] There are minor grammar errors: 'Five cases involves' should be 'Five cases involve', and 'Three cases visually appeares' should be 'Three cases visually appear'.
  6. [Table VI and elsewhere] The tool name is spelled inconsistently as both 'REDECHECK' and 'ReDeCheck'; please use one form consistently.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the 68% prevalence is a human-annotated measurement on a defined static-page subset, and XCompat is evaluated on a held-out 20% split with thresholds fixed on the training split.

full rationale

The paper's central claims are empirical measurements rather than derivations from definitions. The 68% incompatibility rate is obtained by human annotation of rendering pairs (Section III-B4, Algorithm 1, Cohen's kappa 0.9506); it is not computed from a model fitted to the labels. The comparison to human-authored pages (Finding 2) uses the same rendering and annotation pipeline and is statistically tested. XCompat's design is informed by the empirical taxonomy, and its thresholds and prompts are selected on the 203-page empirical split; however, the paper explicitly fixes configurations and evaluates on a separate 20% held-out test split (Section V-B1), reporting F1=0.903/accuracy=0.953 there. This is a standard train/test separation rather than fitted-input-called-prediction. The self-citations (DCGen [10], UIBenchkit [31], and other co-authored benchmarks) are used as data sources or evaluation tooling, not as proof of the paper's conclusions, so they are not load-bearing. The only notable concern is external validity: Section III-B3 filters out 226 of 480 generated pages (blank, malformed, rendering-failure, or interactive-dependent), and the abstract's 68% is computed only on the remaining 254 valid static pages. That limitation affects how the prevalence claim generalizes to all AI-generated output, but it does not make the derivation circular, because the filtering criterion is not defined in terms of the compatibility outcome and the reported rate is a conditional measurement, not a tautology. No circular step satisfies the 'exhibits the specific reduction' standard.

Assumptions & free parameters 3 free parameters · 5 assumptions · 0 invented entities

The central prevalence claim rests on the validity of the rendering service, the manual compatibility definition, and the heavy page filtering. The detector adds three hand-set numeric thresholds. No new theoretical entities are introduced.

free parameters (3)
  • viewport width threshold (default near 800 px) = 800 px (sensitivity tested 760-840)
    Used in XCompat Page-Level Analysis to detect viewport adaptation failures; chosen by authors on the empirical set.
  • content fill ratio threshold = 0.75 (sensitivity 0.70-0.80)
    Heuristic to detect initial scale mismatch and whitespace anomalies in XCompat; set on the empirical set.
  • mobile wide content threshold = 2.0 (sensitivity 1.8-2.2)
    Heuristic to detect horizontal overflow in XCompat; set on the empirical set.
assumptions (5)
  • domain assumption BrowserStack rendering is a faithful proxy for real-world browser and device behavior.
    All screenshots and DOMs are captured via BrowserStack; no comparison to physical devices is reported (Section III-B3).
  • domain assumption The annotation procedure (Algorithm 1) correctly separates intended responsive adaptation from compatibility failure.
    The operational definition relies on human judgment; inter-annotator agreement is high but the ground truth remains subjective (Section III-B4).
  • domain assumption Excluding 226 of 480 generated pages does not materially bias the reported prevalence rates.
    The filtering step removes blank, malformed, and interaction-dependent pages without analyzing their compatibility, so the surviving 254 pages define the scope of the 68% figure (Section III-B3).
  • domain assumption The 60 source pages from DCGen and Design2Code-Hard are representative of UI-to-code inputs.
    Generalization beyond these two benchmarks and 60 designs is assumed (Section III-B1).
  • domain assumption Webpages generated from the same 60 source pages by different tools can be treated as independent samples for the Fisher exact test.
    The AI-vs-human comparison in Section IV-A2 uses per-page counts, but pages are correlated through shared source designs and generator families.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Does It Render Everywhere? A Study of Cross-Environment Compatibility in MLLM-Generated Webpages." pith.science (2026). https://pith.science/paper/EBYUS4Z7

@misc{pith2026260812518,
  author       = {Pith},
  title        = {Pith review of: Does It Render Everywhere? A Study of Cross-Environment Compatibility in MLLM-Generated Webpages},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EBYUS4Z7}},
  note         = {Machine review of arXiv:2608.12518}
}
read the original abstract

Multimodal Large Language Models (MLLMs) have been increasingly adopted to automate webpage generation from visual designs (e.g., screenshots). However, existing evaluations are limited to visual fidelity assessment under a fixed browser-device configuration. Such a setting overlooks the cross-environment rendering compatibility for real-world deployments. To address this gap, we present the first systematic empirical study of cross-environment compatibility in AI-generated webpages. Specifically, we construct WebCompat, a dataset of 2,032 annotated instances, comprising webpages generated by 8 representative AI tools, each rendered across 9 browser-and-device combinations. We analyze the prevalence of compatibility issues, their user-perceptible symptoms, and underlying code-level root causes. Our findings reveal that 68% of generated webpages exhibit at least one compatibility issue, underscoring the pervasive reliability concerns surrounding MLLM-generated front-end artifacts. The most prevalent symptoms are failures that disrupt the entire page layout (88.3%): pages shrink directly to fit the target screen with too small fonts, or exhibit scale mismatches that produce cut-off content. Failures localized to individual elements, such as image distortion or missing components, are comparatively less common (13.4%). Furthermore, although most MLLMs incorporate responsive design patterns into the generation, they fail to properly implement these codes. Guided by the findings, we develop XCompat, a lightweight offline compatibility issue detector that combines visual screenshots and the structural DOM tree for analysis. It achieves an F1 score of 0.903 on the WebCompat-test, outperforming the existing compatibility checking tools and LLM baselines. All datasets and tools are released to support future research on rendering reliability in MLLM-based front-end code generation.

Figures

Figures reproduced from arXiv: 2608.12518 by the authors.

Figure 1
Figure 1. An example showing that correct rendering in one environment [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Overview of the WebCompat construction pipeline. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Distribution of rendering pairs across the various generators. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Distribution of XBI, XDI, and issue-free pages for human-written and [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Subclass of A1 (Viewport adaptation failure). [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 7
Figure 7. Figure 7: Examples of Class B element-level incompatibilities: B1 (image [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

39 extracted references · 28 canonical work pages

  1. [1]

    Mllm-based ui2code automation guided by ui layout information,

    F. Wu, C. Gao, S. Li, X.-C. Wen, and Q. Liao, “Mllm-based ui2code automation guided by ui layout information,”Proceedings of the ACM on Software Engineering, vol. 2, no. ISSTA, pp. 1123–1145, 2025

    work page 2025

  2. [2]

    Designcoder: hierarchy-aware and self-correcting ui code generation with large language models,

    Y . Chen, X. Yu, S. Ding, Y . Zhang, C. Shi, J. Du, and L. Chen, “Designcoder: hierarchy-aware and self-correcting ui code generation with large language models,”Information and Software Technology, p. 108214, 2026

    work page 2026

  3. [3]

    Web2code: A large-scale webpage-to- code dataset and evaluation framework for multimodal llms,

    S. Yun, H. Lin, R. Thushara, M. Q. Bhat, Y . Wang, Z. Jiang, M. Deng, J. Wang, T. Tao, J. Liet al., “Web2code: A large-scale webpage-to- code dataset and evaluation framework for multimodal llms,”Advances in neural information processing systems, vol. 37, pp. 112 134–112 157, 2024

    work page 2024

  4. [4]

    Designrepair: Dual-stream design guideline-aware frontend repair with large language models,

    M. Yuan, J. Chen, Z. Xing, A. Quigley, Y . Luo, T. Luo, G. Mohammadi, Q. Lu, and L. Zhu, “Designrepair: Dual-stream design guideline-aware frontend repair with large language models,” in2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE, 2025, pp. 2483–2494

    work page 2025

  5. [5]

    Screenshots and Files,

    Vercel, “Screenshots and Files,” [Online]. Available: https://v0.app/docs/ screenshots, accessed: Jun. 18, 2026

    work page 2026

  6. [6]

    Build Software with AI Agents,

    Cursor, “Build Software with AI Agents,” [Online]. Available: https: //cursor.com/product, accessed: Jun. 18, 2026

    work page 2026

  7. [7]

    Design2code: Benchmarking multimodal code generation for automated front-end engineering,

    C. Si, Y . Zhang, R. Li, Z. Yang, R. Liu, and D. Yang, “Design2code: Benchmarking multimodal code generation for automated front-end engineering,” inProceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers), 2025, pp. 3956–3974

    work page 2025

  8. [8]

    Interaction2code: Benchmarking mllm-based interactive webpage code generation from interactive prototyping,

    J. Xiao, Y . Wan, Y . Huo, Z. Wang, X. Xu, W. Wang, Z. Xu, Y . Wang, and M. R. Lyu, “Interaction2code: Benchmarking mllm-based interactive webpage code generation from interactive prototyping,” in2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE Press, 2025, p. 241–253. [Online]. Available: https://doi.org/10.1109/A...

    arXiv 2025

Show all 39 references
  1. [9]

    Designbench: A comprehensive benchmark for mllm-based front-end code generation,

    J. Xiao, M. Wang, M. H. Lam, Y . Wan, J. Liu, Y . Huo, and M. R. Lyu, “Designbench: A comprehensive benchmark for mllm-based front-end code generation,”arXiv preprint arXiv:2506.06251, 2025

    2025

  2. [10]

    Divide-and-conquer: Generating ui code from screenshots,

    Y . Wan, C. Wang, Y . Dong, W. Wang, S. Li, Y . Huo, and M. Lyu, “Divide-and-conquer: Generating ui code from screenshots,”Proceed- ings of the ACM on Software Engineering, vol. 2, no. FSE, pp. 2099– 2122, 2025

    2025

  3. [11]

    Taming android fragmentation: Characterizing and detecting compatibility issues for android apps,

    L. Wei, Y . Liu, and S.-C. Cheung, “Taming android fragmentation: Characterizing and detecting compatibility issues for android apps,” inProceedings of the 31st IEEE/ACM international conference on automated software engineering, 2016, pp. 226–237

    2016

  4. [12]

    Conffix: Repair- ing configuration compatibility issues in android apps,

    H. Huang, C. Xu, M. Wen, Y . Liu, and S.-C. Cheung, “Conffix: Repair- ing configuration compatibility issues in android apps,” inProceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2023, pp. 514–525

    2023

  5. [13]

    Seeno- maly: Vision-based linting of gui animation effects against design- don’t guidelines,

    D. Zhao, Z. Xing, C. Chen, X. Xu, L. Zhu, G. Li, and J. Wang, “Seeno- maly: Vision-based linting of gui animation effects against design- don’t guidelines,” inProceedings of the ACM/IEEE 42nd international conference on software engineering, 2020, pp. 1286–1297

    2020

  6. [14]

    Owl eyes: Spotting ui display issues via visual understanding,

    Z. Liu, C. Chen, J. Wang, Y . Huang, J. Hu, and Q. Wang, “Owl eyes: Spotting ui display issues via visual understanding,” inProceedings of the 35th IEEE/ACM international conference on automated software engineering, 2020, pp. 398–409

    2020

  7. [15]

    From ui design image to gui skeleton: a neural machine translator to bootstrap mobile gui implementation,

    C. Chen, T. Su, G. Meng, Z. Xing, and Y . Liu, “From ui design image to gui skeleton: a neural machine translator to bootstrap mobile gui implementation,” inProceedings of the 40th International Conference on Software Engineering, 2018, pp. 665–676

    2018

  8. [16]

    Automated cross-browser compatibility testing,

    A. Mesbah and M. R. Prasad, “Automated cross-browser compatibility testing,” inProceedings of the 33rd International Conference on Soft- ware Engineering, 2011, pp. 561–570

    2011

  9. [17]

    Webdiff: Automated iden- tification of cross-browser issues in web applications,

    S. R. Choudhary, H. Versee, and A. Orso, “Webdiff: Automated iden- tification of cross-browser issues in web applications,” in2010 IEEE International Conference on Software Maintenance. IEEE, 2010, pp. 1–10

    2010

  10. [18]

    X-pert: Accurate identification of cross-browser issues in web applications,

    S. R. Choudhary, M. R. Prasad, and A. Orso, “X-pert: Accurate identification of cross-browser issues in web applications,” in2013 35th International Conference on Software Engineering (ICSE). IEEE, 2013, pp. 702–711

    2013

  11. [19]

    Combining crawling and differencing to better detect cross- browser incompatibilities in web applications,

    ——, “Combining crawling and differencing to better detect cross- browser incompatibilities in web applications,” inProceedings of the 5th IEEE International Conference on Software Testing, Verification and Validation (ICST). IEEE, 2012, pp. 171–180

    2012

  12. [20]

    Browserbite: cross-browser testing via image processing,

    T. Saar, M. Dumas, M. Kaljuve, and N. Semenenko, “Browserbite: cross-browser testing via image processing,”Software: Practice and Experience, vol. 46, no. 11, pp. 1459–1477, 2016

    2016

  13. [21]

    Automated layout failure detection for responsive web pages without an explicit oracle,

    T. A. Walsh, G. M. Kapfhammer, and P. McMinn, “Automated layout failure detection for responsive web pages without an explicit oracle,” inProceedings of the 26th ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). ACM, 2017, pp. 192–202

    2017

  14. [22]

    Uicopilot: Automating ui synthesis via hierarchical code generation from webpage designs,

    Y . Gui, Y . Wan, Z. Li, Z. Zhang, D. Chen, H. Zhang, Y . Su, B. Chen, X. Zhou, W. Jianget al., “Uicopilot: Automating ui synthesis via hierarchical code generation from webpage designs,” inProceedings of the ACM on Web Conference 2025, 2025, pp. 1846–1855

    2025

  15. [23]

    Waffle: Fine-tuning multi- modal model for automated front-end development,

    S. Liang, N. Jiang, S. Qian, and L. Tan, “Waffle: Fine-tuning multi- modal model for automated front-end development,” inProceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), 2025, pp. 24 786–24 802

    2025

  16. [24]

    Efficien- tuicoder: Efficient mllm-based ui code generation via input and output token compression,

    J. Xiao, Z. Zhang, Y . Wan, Y . Huo, Y . Liu, and M. R. Lyu, “Efficien- tuicoder: Efficient mllm-based ui code generation via input and output token compression,”arXiv preprint arXiv:2509.12159, 2025

    2025 arXiv

  17. [25]

    Comuicoder: Component-based reusable ui code generation for complex websites via semantic segmentation and element-wise feedback,

    J. Xiao, J. Qin, S. Li, M. H. Lam, Y . Wan, J.-t. Huang, Y . Huo, and M. R. Lyu, “Comuicoder: Component-based reusable ui code generation for complex websites via semantic segmentation and element-wise feedback,”arXiv preprint arXiv:2602.19276, 2026

    2026

  18. [26]

    From runnable to shippable: Multi-agent test-driven development for gener- ating full-stack web applications from requirements,

    Y . Wan, T. Liang, J. Xu, J. Xiao, Y . Huo, and M. R. Lyu, “From runnable to shippable: Multi-agent test-driven development for gener- ating full-stack web applications from requirements,”arXiv preprint arXiv:2605.17242, 2026

    2026 arXiv

  19. [27]

    Browserstack,

    BrowserStack, “Browserstack,” https://www.browserstack.com/, 2026, accessed: 2026-06-29

    2026

  20. [28]

    Gpt-4 technical report,

    J. Achiam, S. Adler, S. Agarwal, L. Ahmad, I. Akkaya, F. L. Aleman, D. Almeida, J. Altenschmidt, S. Altman, S. Anadkatet al., “Gpt-4 technical report,”arXiv preprint arXiv:2303.08774, 2023

    2023 arXiv

  21. [29]

    Gpt-5.1: A smarter, more conversational chatgpt,

    OpenAI, “Gpt-5.1: A smarter, more conversational chatgpt,” https: //openai.com/index/gpt-5-1/, 2025, accessed: 2026-06-29

    2025

  22. [30]

    Gemini Canvas: Write, Code, and Create in One Space with AI,

    Google, “Gemini Canvas: Write, Code, and Create in One Space with AI,” [Online]. Available: https://gemini.google/overview/canvas/, accessed: Jun. 18, 2026

    2026

  23. [31]

    Uibenchkit: A unified toolkit for design-to-code model evaluation,

    C. T. Le, T. O. Y . Siang, J. Xiao, Y . Wan, and Y . Huo, “Uibenchkit: A unified toolkit for design-to-code model evaluation,”arXiv preprint arXiv:2605.13141, 2026

    2026 arXiv

  24. [32]

    Browser market share worldwide,

    StatCounter Global Stats, “Browser market share worldwide,” https://gs. statcounter.com/browser-market-share, accessed: 2026-06-28

    2026

  25. [33]

    Desktop operating system market share worldwide,

    ——, “Desktop operating system market share worldwide,” https:// gs.statcounter.com/os-market-share/desktop/worldwide, accessed: 2026- 06-28

    2026

  26. [34]

    Learning transferable visual models from natural language supervision,

    A. Radford, J. W. Kim, C. Hallacy, A. Ramesh, G. Goh, S. Agarwal, G. Sastry, A. Askell, P. Mishkin, J. Clarket al., “Learning transferable visual models from natural language supervision,” inInternational conference on machine learning. PmLR, 2021, pp. 8748–8763

    2021

  27. [35]

    Image quality assessment: from error visibility to structural similarity,

    Z. Wang, A. C. Bovik, H. R. Sheikh, and E. P. Simoncelli, “Image quality assessment: from error visibility to structural similarity,”IEEE transactions on image processing, vol. 13, no. 4, pp. 600–612, 2004

    2004

  28. [36]

    Bleu: a method for automatic evaluation of machine translation,

    K. Papineni, S. Roukos, T. Ward, and W.-J. Zhu, “Bleu: a method for automatic evaluation of machine translation,” inProceedings of the 40th annual meeting of the Association for Computational Linguistics, 2002, pp. 311–318

    2002

  29. [37]

    Webdevjudge: Evaluating (m) llms as critiques for web development quality,

    C. Li, Y . Zheng, X. Huang, T. Fang, J. Xu, L. Chen, Y . Song, and H. Hu, “Webdevjudge: Evaluating (m) llms as critiques for web development quality,”arXiv preprint arXiv:2510.18560, 2025

    2025

  30. [38]

    A coefficient of agreement for nominal scales,

    J. Cohen, “A coefficient of agreement for nominal scales,”Educational and psychological measurement, vol. 20, no. 1, pp. 37–46, 1960

    1960

  31. [39]

    Layout cross-browser failure classification for mobile responsive design web applications: Combining classification models using feature selection,

    W. M. Watanabe, D. A. Dos Santos, and C. De Oliveira, “Layout cross-browser failure classification for mobile responsive design web applications: Combining classification models using feature selection,” ACM Transactions on the Web, vol. 17, no. 4, pp. 1–34, 2023

    2023

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.