typst / typst/typst

Do not allow not passing a body to an HTML element function

Open
#6,855 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

change request html scripting
Dominant language
Rust
Stars
56.1k
Forks
1.7k
Avg merge
3d 10h
Merged PRs (30d)
22

Description

Description

HTML element functions (functions of the html module that return an html.elem, part of the typed HTML API) that accept a body should not allow not passing it.

Use Case

HTML element functions can be called without specifying a body. For example, the calls html.div() and html.html() are valid, and equivalent to html.div[] and html.html[] respectively.

This can be confusing as no error is emitted in the following case, where .with was unintentionally omitted:

#show: html.html(lang: "en")

I believe it is better to be explicit and pass an empty body if wanted rather than not getting an error when no body is provided.

Note that some standard library functions that accept a body already require that body to be provided (e.g., place, align, link), while others don't, like block, box, or rect whose bodies are not only optional but also settable.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the typed HTML API's HTML element functions and compare their body handling with standard-library functions such as place, align, link, block, box, and rect. Determine which HTML functions should require an explicit body while preserving intentionally optional or settable bodies. Done means calls such as html.div() and html.html() produce an error, while explicit empty bodies remain valid.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
compilers
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.