They're popular because clients beg for them. You can show them a thread of people ranting about a particular layout practice, and you can speak passionately against something, but if they want it, they do not relent.

"^top" links, share icons, all that stuff - clients will not give up until they get it all.

(Source: Designed sites for clients since there were first images in web browsers 20+ years ago.)

> Take me back to the static web.

I used to enjoy doing Web 1.0 development.

Nowadays I always push for native applications, unless the customer wants otherwise.

Browsers should have stayed pure HTML/CSS.

FWIW sticky headers are completely doable in pure HTML/CSS.

  .header {
    position: fixed;
    top: 0;
    left: 0;
    width: 100%;
    background: goldenrod;
  }

> Even worse, when you click to an anchor section on a sticky-header page, the title of the section is hidden by the sticky header.

This, especially. If the browser were somehow informed about the header in a semantic way, it could avoid this.

The fix is to shift the anchor to above the header.

Can you elaborate on what you mean by this? Because I can think of a couple of meanings of "above" there, none of which seem like they'd have the desired effect.

It confused me at first too, but now I think I know what he means. Before the header you're linking to - h3 or whatever. Link to some content enough above that header to compensate for the sticky header.

That seems like an awkward semantic break to compensation for presentation, as well as error-prone in size-matching.

Better if the browser knew about the header and could position the linked anchor accordingly. In the absence of any facility to do that, just ditch the header.

It actually is possible to do - you can use CSS to move the position of the anchor tag. If I recall there were some extra CSS properties needed to make it work, but it can be done.

yeah, or just

  * {margin:2em}

That would break the most common method of centering the main content (margin-left: auto; margin-right: auto)

Not necessarily. A more specific selector overrides a less specific one, and a later selector overrides an earlier one.

NYT actually takes the page-down/lines of text problem into account. Odd that others haven't copied.

Now that both position: sticky and Scroll Snap Points from CSS are landing in browsers, those complaints will hopefully be resolved. Scrolling is much better off left in the hands of CSS than JS.

NYT is pretty obnoxious in other ways, though, especially with a touchscreen. If you click and drag to highlight something, it navigates to a different article. If you double-click to select a word, it changes the text size. If you accidentally hit the left or right arrow key while trying to scroll up or down, it again tries to load the next article.

And it's not possible to select text at all on Mobile.

I've taken to using alternative links (archive.is, archive.org, outline.com) for sharing the articles simply because it's too much of a PITA to manage the NYTimes.com page itself.

nytimes.com also hijacks the left/right arrow to advance to the next article, and used to do a thing where if you multi-click to select a paragraph it would jiggle the font size.

Firefox takes full-width fixed headers (and footers?) into account when you scroll with page up/down or space bar.

Speaking of anchors. HN behaves a bit oddly there when going back to a specific comment in a tree with folded branches. Also, the search page hijacks the up key to send me to the top of the page...