html icon indicating copy to clipboard operation
html copied to clipboard

Remove UA styles for h1 in article, aside, nav, section

Open zcorpan opened this issue 9 months ago • 12 comments

Fixes #7867

  • [x] At least two implementers are interested (and none opposed):
    • Gecko
    • Chromium https://github.com/whatwg/html/issues/7867#issuecomment-2125552252
    • WebKit https://github.com/whatwg/html/issues/7867#issuecomment-2124317504
  • [x] Tests are written and can be reviewed and commented upon at:
    • https://github.com/web-platform-tests/wpt/pull/51673
  • [x] Implementation bugs are filed:
    • Chromium: https://issues.chromium.org/issues/394111284
    • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1885509
    • WebKit: https://bugs.webkit.org/show_bug.cgi?id=292765
  • [x] Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
  • [x] MDN issue is filed: https://github.com/mdn/content/pull/37827 and https://github.com/mdn/content/pull/39582 (MDN page)
  • [x] The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)


/rendering.html ( diff )

zcorpan avatar Mar 05 '25 10:03 zcorpan

[ ] Implementation bugs are filed:

  • Chromium: …

https://issues.chromium.org/issues/394111284

mfreed7 avatar Mar 07 '25 01:03 mfreed7

So, this seems pretty absurd and the absolute opposite of what should be done, not to mention breaking compatibility with existing webpages, so it should obviously be rejected.

Originally HTML was designed terribly, with arbitrary ad-hoc h1, h2, h3, h4, h5, h6 tags with an absurd fixed choice of 6 levels instead of the obviously correct design of <section><title>Abc</title><section><title>Def</title>, which allows arbitrary levels with a uniform syntax, and allows subdocuments to be documents.

Later some better designers started to work on HTML, and conceived of a design that would be an extension of both the horribly designed status quo and the correct design, being the <section><h1>Abc</title><section><h1>Def</title> design, i.e. the correct design using h1 instead of title, with the natural generalization of having hN inside M section be an N + M level heading, which allows to put documents created in the terrible design with h1/h2/h3 in documents made with the proper <section> design seamlessly.

Now it seems that again terrible designers are taking over, and seem to want to revert to the initial horrible design while breaking the <section> element as well as the obvious principle that it should be possible to copy-and-paste a document into another and have it rendered properly, rather than having the subdocument headings look like main headings.

The idea of requiring the website to specify "font-size" and "margin-block" is completely absurd, since those are presentational styles with no relevance to semantics and should be something that ideally the user agent would not honor at all (why should the website be allowed to decide the heading font size?!?), that the websites cannot possibly correct set (how can it know how large the user wants an heading to be?!?) and certainly cannot be a criteria for HTML document validity.

Reject this abomination.

kytans avatar Apr 11 '25 06:04 kytans

@kytans, I've hidden your comment as abuse, and encourage you to review https://whatwg.org/code-of-conduct before engaging further with the WHATWG community. Any further violations will result in at least a temporary ban.

domenic avatar Apr 11 '25 06:04 domenic

I think we can land this, see https://github.com/whatwg/html/issues/7867#issuecomment-2893403198

zcorpan avatar May 20 '25 09:05 zcorpan

So Chrome will only follow once it's been 100% in Firefox stable for some time and apart from the warning hasn't experimented with this yet? If so I'd like to defer merging to @domenic. We might need a better way to decide these things. The main thing I'm concerned about is wasting cycles of people on the outside who assume it's happening based on a change to the HTML standard when we're in fact not that certain.

annevk avatar May 20 '25 12:05 annevk

The main thing I'm concerned about is wasting cycles of people on the outside who assume it's happening based on a change to the HTML standard when we're in fact not that certain.

That's much appreciated!

AtkinsSJ avatar May 20 '25 13:05 AtkinsSJ

So Chrome will only follow once it's been 100% in Firefox stable for some time and apart from the warning hasn't experimented with this yet?

That's roughly right, yes. We've had the deprecation warnings going for several milestones and haven't heard any issues. But I'd like to wait until this is shipped at 100% for at least a milestone in Firefox before we start the process in Chromium. Having said that, it looks pretty likely to go ahead, at least to me.

mfreed7 avatar May 20 '25 15:05 mfreed7

We do have a few of these sorts of things recently, where everyone's on board but is unsure on the compat implications. (https://github.com/whatwg/webidl/pull/1465 is another.) My tendency is to be more aggressive about merging, but I'm hearing hesitation from others... so I don't really know where that leaves us.

domenic avatar May 21 '25 01:05 domenic

I'm OK with waiting here until another browser has decided to ship. But yeah, it seems we should discuss the meta issue.

zcorpan avatar May 21 '25 08:05 zcorpan

Maybe something along these lines:

  1. If multiple browsers are landing patches and little fallout is expected, as was the case with escaping < and > in attribute values near the end, let's proceed and align the standard assuming success.
  2. If other browsers are wary but supportive, let's wait until one browser has actually shipped the new behavior before aligning the standard. (Which means once Firefox 140 ships we'd land this PR and assume eventual success.)

annevk avatar May 21 '25 14:05 annevk

Maybe something along these lines:

  1. If multiple browsers are landing patches and little fallout is expected, as was the case with escaping < and > in attribute values near the end, let's proceed and align the standard assuming success.
  2. If other browsers are wary but supportive, let's wait until one browser has actually shipped the new behavior before aligning the standard. (Which means once Firefox 140 ships we'd land this PR and assume eventual success.)

+1 to this approach. This (#2) is also roughly what we did for mutation events.

mfreed7 avatar May 22 '25 16:05 mfreed7

For any following along, I've posted https://github.com/whatwg/sg/pull/253 to attempt to encapsulate the above guidance into the working mode.

domenic avatar May 23 '25 04:05 domenic

Per discussion in https://github.com/whatwg/html/issues/7867#issuecomment-3051816331, Firefox has shipped this to stable for 2 releases at 100%. That meets the bar we've discussed above, so I think this is ready to merge.

I'll plan on doing that by Monday Japan time unless more discussion happens in the meantime.

domenic avatar Jul 10 '25 02:07 domenic

@domenic ping to get this merged? :)

emilio avatar Jul 18 '25 14:07 emilio