Skip to content

fix: definition list in Chrome - #3219

Merged
GuillaumeGomez merged 1 commit into
rust-lang:mainfrom
pinage404:definition_list_fix_chrome
Sep 15, 2026
Merged

GuillaumeGomez merged 1 commit into
rust-lang:mainfrom
pinage404:definition_list_fix_chrome

Conversation

@pinage404

@pinage404 pinage404 commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

Hello,

When there are several definitions (<dd>) for a term (<dt>), definitions (<dd>) are prefixed with a number

When there are several terms with both several definitions, the number was not incremented the same way in Firefox and Chrome

Tested with version 0.5.4 and the current main branch

The behaviour was good with Firefox

But the number wasn't resettled with definition term (<dt>) in Chrome

I saw this warning on MDN

Warning: There is a difference between counter-reset and counter-set properties. After creating a counter using counter-reset, you can adjust its value by using the counter-set property. This is counterintuitive because, despite its name, the counter-reset property is used for creating and initializing counters, while the counter-set property is used for resetting the value of an existing counter.

https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/counter-reset#description

I tried to change in the code, it aligned the behaviour of Chrome on the Firefox

Code to reproduce the bug

# Example

Foo
  : should be 1
  : should be 2
  : should be 3

Bar
  : should be 1
  : should be 2
  : should be 3

Before this patch
  : Works with
    : Zen Browser 1.21.16b (Firefox 154.0.1) (64 bits)

  : Does not work with
    : Chromium Version 152.0.7977.64 (Build officiel)

After this patch
  : Works with
    : Zen Browser 1.21.16b (Firefox 154.0.1) (64 bits)
    : Chromium Version 152.0.7977.64 (Build officiel)

Render :

Before After
before after

I only tested on Linux with :

  • Zen Browser 1.21.16b (Firefox 154.0.1) (64 bits)
  • Chromium Version 152.0.7977.64 (Build officiel)

I didn't do any others checks

@rustbot rustbot added the S-waiting-on-review Status: waiting on a review label Sep 9, 2026
@GuillaumeGomez

Copy link
Copy Markdown
Member

Seems good to me, thanks! Please add a GUI test.

@GuillaumeGomez GuillaumeGomez added S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. and removed S-waiting-on-review Status: waiting on a review labels Sep 14, 2026
@pinage404

Copy link
Copy Markdown
Contributor Author

I don't know what should i check neither where / how i can check

Do you have clues ?

@GuillaumeGomez

Copy link
Copy Markdown
Member

If it's present in the text, you can check with assert-text. If not, maybe the element itself has the information?

@GuillaumeGomez

Copy link
Copy Markdown
Member

I couldn't figure out a way to check that with the GUI test as it's a CSS only value, computed by the web browser. So yeah... Please remove the last commit, I'll make one last review pass afterwards to confirm I didn't miss anything and then merge.

@pinage404
pinage404 force-pushed the definition_list_fix_chrome branch from 44c15dd to fd391c8 Compare September 15, 2026 11:40
@GuillaumeGomez

Copy link
Copy Markdown
Member

Looks all good to me, thanks!

@GuillaumeGomez
GuillaumeGomez added this pull request to the merge queue Sep 15, 2026
Merged via the queue into rust-lang:main with commit 02b270b Sep 15, 2026
39 checks passed
@pinage404
pinage404 deleted the definition_list_fix_chrome branch September 15, 2026 12:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants