Both cases in your first example reek of not knowing enough CSS to be styling a H!... since filling available width is what block level tags do, the width:100%, calc, and margin auto are all pointless junk. Remove the two widths, put the margin:0 50px; on the H1, and be done with it. You won't even need to play with box-sizing.

On the whole calc is one of those things I wish CSS had 20 years ago, but now that we have box-sizing I no longer see a use for.

... and those who do seem to see a use for it are out there slopping together pixel layout pages (telling users with accessibility needs to go plow themselves), use DIV for what should be a FIELDSET, slop ID's onto inner containers that are redundant to their parent, probably aren't using a reset, lack proper for/id relationships between LABEL and INPUT, and use calc where, well... that's box-sizing's job.

Or just go full Gungan being unable to do simple math (like dividing 100 by 4) for themselves.

It doesn't seem to make styling easier, it just seems to be for the fools who think the answer to everything is to just "throw more code at it". Hence why like CSS variables it exists for the people who are in love with using 500k of CSS to do 32k's job.

Seriously, just lose the DIV for nothing, and since — unless you use the new SECTION rules that no legitimate UA actually supports — there should be only ONE H1 on a page…

h1 {
margin:0 1.5em;
padding:1em;
background:#059;
color:#FFF;
}

Pay close attention to the use of ACCESSIBLE metrics (em) and colour contrasts that actually meet WCAG minimums… and how ridiculously absurd the amount of code you were throwing at that actually was.

Just like your second example which first off needs a rewrite to use proper semantic/accessible markup:

<form id="writeSomething">
<fieldset>
<label for="writeSomething_text">Write something below:</label>
<input type="text" id="writeSomething_text">
</fieldset>
</form>

And assuming a reset (that should be nulling fieldset border) is in use:

#writeSomething,
#writeSomething input {
box-sizing:border-box;
}
#writeSomething {
width:25%;
border:1px solid black;
padding:0.3em;
}
input {
display:block;
padding:0.2em 0.5em;
width:100%;
}

Side note, in production I tend to set box-sizing:border-box on everything now.

I’ve yet to see an example in which calc is actually needed or doesn’t make the code MORE complicated.

Box-sizing pretty much answers more cleanly any problem I could see calc actually solving.

NOT that I’d actually deploy a 25% width given you’d spend half your live screwing with it on the media queries, I’d set a max-width in EM and use either float or flex to let the sibling-placement elements be fully fluid for the remainder… likely flex with flex-wrap enabled so one might not even need media queries.

Remember, % widths are fragile and make queries harder to build, PX metrics are inaccessible junk which is why your fonts, paddings, margins, elastic widths, AND media queries should all be done in EM, and don’t waste time hardcoding an element’s natural behavior or the default behavior of things like display:block;

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store