Body Margin 8px | Hacker News Reader

Body Margin 8px

miriamsuzanne.com

177 pointsmarban34 comments

It makes sense as HTML was a document format. Document: thing you print, in this case on 90s printers. You need a margin!

The genius is you get a reasonable reading experience out of the box with default styles.

Noone wants their first character kissing the browser window frame.

I am betting what is old is new and 8px borders will come back in fashion.

"A thing you print" just isn't the definition of a document.

We obviously put margins on stuff, but never at the body element for many reasons. Padding would be better for example. The margin only makes sense if you don’t apply any further styling.

Margins collapse

if you have h1 with top margin 10px, and body margin 8px, it "adds" up to 10px, not 18px.

Once you write article-based sites, without a random navbar that people don't want, then it can become quite nice

I hate it when a site has no margin and everything pushes up against the edge of the browser. It's hard to read and annoying as all get out so I think if you are going to remove the default of margin: 8px you should probably replace it with something sensible that prevents running up against the edge of the browser.

Agree but it makes it cumbersome to do full bleeds

Sometimes I send a site owner a note when this happens but that's usually met with "what device are you using?" or "you're using a non standard resolution" or something.

Somewhat related.(if you squint hard)

@Google, @Youtube. Please FIX your video-player controls. Add a MARGIN to the on-screen display:

You know the "little" go-fullscreen-button on the bottom-right of the video that sits 0.0000000001mm above the 'interactive' timeline.

How many times I've pressed the 'timeline' instead of the fullscreen-button and then 'ended' the video and had to actually go into my youtube-history to reload video.

If you going to judge my websites with CLS,LCP and all that you can do better with UI as well.

Oh don’t start it! Youtube player ui alone is so broken as if they consulted a donkey to create it.

Timeline may receive a focus (blue outline) so that when you later press up/down to adjust volume, it instead jumps 5 seconds away.

You cannot click on 0:00, because it’s inaccessible for some reason. But you can do that by accidentally pressing numpad 0 instead of or together with a right arrow.

If you are seeking a frame by thumbnail and move away the slightest, thumbnails disappear. Or they never load, but youtube shows you any previous frame instead of a black box, even if it is 50 minutes away.

If you miss your cursor on a tiny volume bar, it scrolls to description. Arguable but annoying.

They can’t figure out how to hide a cursor after a while, so you have to move it to the right and ignore 1x10 bar on your screen.

And instead of showing a map of options in the settings button, it presents a stupid hierarchical menu, so you have to pause video every time to figure out what you need to click on.

I could go on with entire ui, but chances that this will be fixed is zero, because some manager once “proved” something about it all likely.

My most favourite YouTube player usability WTF was keyboard play state toggling with focused play/pause button.

It is actually fixed at this point, but for a very long time there was a 'collision' (respective parallel processing) of the page-wide space-bar handler that toggles playback and the actual "click" event handler of the play/pause button that can be triggered with the space key as well. As a result, if you started play by clicking the play button under seeker (focussing it in effect) and later decided to pause the video by pressing the space-bar, it briefly paused the video (play->pause from the button click handler) and immediately triggered pause->play from the global handler (or other way round). So to actually pause the video with keyboard you had to shift-tab away from the invisibly-focussed (!) play button to the seeker and only then used the space key to trigger the global handler alone.

It always left me flabbergasted how such blatant UX flaw could remain unattended in such prominent service for that long.

Right !! Even if they do nothing else but just make everything that is clickable x5 bigger. It would already improve things x10.

> But you can do that by accidentally pressing numpad 0 instead

This "feature" always trips me up. For those unaware, pressing 0 through 9 will jump the playhead to 0% through 90% of the timeline, respectively. I can understand wanting to immediately jump to the beginning of a video, but who is ever going to know that they want to jump to exactly the 40% of the timeline of a video? In some videos that might be 30 seconds in; in others, 30 minutes. Having 1 jump you to the 1:00 mark, 2 to 2:00, etc would make far more sense as the vast majority of videos are 9 minutes or shorter anyway - but either way, it won't stop me from accidentally jumping to some random point in the video by either me or my cat accidentally tapping a number key, and then me trying to figure out where in the hell I was at in the timeline before it happened so I can keep playing the vid from where I left off. The whole thing's an anti-feature.

This is the kind of stuff that makes me feel like learning frontend is more similar to learning history than learning math

Really fun read :)

I’d say it’s more like painting… a bit of both plus the end result has to be “good” for the tech(nique) to matter.

That's a very accurate statement for what it was like 5 to 10 years ago. But nowadays with resets, saner modern browser APIs, polyfills, build steps, and frameworks, compiled into starter projects, it's much more systematic.

The math required for building most websites is elementary school level anyway.

> I’m not sure if there’s a more recent version somewhere, but I couldn’t find it?

It’s in the HTML spec now, https://html.spec.whatwg.org/multipage/rendering.html, broken up into smaller pieces, and with more prose around it.

There’s a lot more of it than the old one, partly due to newer stuff, partly due to CSS being able to express things that it couldn’t in the past, and partly due to covering stuff that was just missing back when it was part of the CSS spec (e.g. nobr clearly and obviously implies white-space: nowrap, but that was missing from the old user-agent stylesheet).

Some parts end up prose descriptions instead of simple rules, too, as is seen in the titular body margin, which is described in <https://html.spec.whatwg.org/multipage/rendering.html#the-pa...> as coming from several attributes, with 8px being a fallback.

> That initial value is the same for all elements across the entire web. The initial value of display is inline, and the initial value of every margin property is 0.

What? Pre and H1 do not have an initial margin of 0 and plenty of elements do not have an initial display of inline

Confused.

That is before any default or user styles are applied, which are in turn overwritten by author styles.

(Think of the default values of a base object or base class, which are then overwritten by the constructor or more specific methods.)

The three paragraphs that follow explain, including

> This is why we need browser styles, which provide different defaults from one element to the next. Some elements should be display: block (divs, paragraphs, lists, headings, etc), and some of those elements should have margins on them to improve readability.

If you apply the rule

  h1 {
    display: initial;
    margin: initial;
  }

you’ll get an inline h1 with no margin.

This is the difference between the *initial* value, which is the SAME for all elements, and the *default* value, which is based on the user-agent stylesheet. Every property has one single "initial" value, which doesn't change from element to element, but can get overridden by the user-agent for individual elements.

Comments mention printing, but the simple reason is that there is always some margin/padding around text in GUI controls. Look at text inputs, list boxes, menus, dialog boxes, Windows Notepad, whatever. So the client area of the first web browsers of course did the same and added some margin around the rendered text. Once web pages were enabled to specify a margin on their own, the previously existing margin became the default.

Is it just me or is the scrolling on that site horrendously laggy?

It's not just you. After expanding the historic base stylesheet, Chrome even crashed for me (using a Pixel 6).

Works much better in Firefox than Chrome for me.

Perhaps disable the CSS, if you can stand the 8px margin :)

It works fine in Edge, using the same engine as Chrome.

Yep, website is unusable for me in Chrome due to scrolling lag.

It makes sense as HTML was a document format. Document: thing you print, in this case on 90s printers. You need a margin!

The genius is you get a reasonable reading experience out of the box with default styles.

Noone wants their first character kissing the browser window frame.

TIL there is a W3C default stylesheet. I’ve been doing web development since the mid-90s, but this is the first I’ve heard of this.

This website is instantly heating up my laptop and scrolling through it is far from smooth, like 10 FPS.

There a certain argument to be made that the 8px margin may be essential to the success of the entire internet. What if it would not have taken off in the 90s if people didn't like how it printed off?

Great, we’ll written read.

This strikes me as a pretty meaningless position. I kept waiting for the punchline, and got nothing.

Reply on news.ycombinator.com