Question: What's the difference between display: block and display: inline?

Me: Thanks for your time...

Me every time I have to adjust the css:

*center that div*
*hit refresh*
Fuck, now that button is over there.
*adjust the padding and kajigger with the margin a little*
*hit refresh*
Ah, I'm an idiot. I forgot to set the display to inline-block.
*adjust the display*
*hit refresh*
WHY THE FUCK IS THE BACKGROUND RED NOW??!?!?!?

90% of rants about CSS are just people who don't even know CSS2 properly and never heard of CSS3.

That's like crying about not having a nice car without even owning a drivers license. Bullshit.

why does this seem to fix everything?

display: inline-block is a work of satan

The longer I work on front-end the more controversial my opinions become:

- Styling a button with display:flex is dumb.
- The DOM is not hard, unlike what the React team wants to have you believe.
- Specifying a <form> action matters, even if it's empty
- ES5 was the real JS revolution, ES6 mostly sugar-coated marketing
- Disciplined BEM (S)CSS is simple and flexible enough for most needs (vs CSS-in-JS, CSS modules)
- If editor support for Jsdoc were as advanced as Typescript, you wouldn't need the latter.
- There are cases where using floats and inline-block displays is better than the flex CSS box model

Me: *opens devTools*
Firefox: yea bro lemme just ..uh.. hmm yeah so this is the css for the element, see?
Me: Thanks.
Me:
Me: this makes no sense, why would I ever do that?
Firefox: also you can't have width on an anchor tag. I can't put that rule into effect
Me: I didn't put any width on your inline element, you sure about that?
Firefox: yea try using display: inline-block
Me: No. I'll just delete that. *checks file*
Me: Maybe that line is wrong because IT DOES NOT FUCKING EXIST!

What is this shit? I just restarted you! What else do you need, a reinstall? Drink too much over the holidays?

It's like the css editor has become a shallow tray with rules on it, and as soon as you bump it a little everything spills over and then Firefox just thinks oops, I've got this font-size: 200% lying around, lemme stick this into the hr tag which makes sense because THERE CAN'T BE ANY TEXT IN IT.

You can kill me now...

.entry-item
position: relative
display: inline-block
float: left
width: calc(25vw - (204px/4) - (320px/4))
height: calc(25vw - (204px/4) - (320px/4))
overflow: hidden

@media(max-width: 1600px)
width: calc(33.333vw - (204px/3) - (320px/3))
height: calc(33.333vw - (204px/3) - (320px/3))

@media(max-width: 1440px)
width: calc(33.333vw - (48px/3) - (320px/3))
height: calc(33.333vw - (48px/3) - (320px/3))

@media(max-width: 1200px)
width: calc(50vw - (48px/2) - (320px/2))
height: calc(50vw - (48px/2) - (320px/2))

@media(max-width: 1024px)
width: calc(50vw - (48px/2))
height: calc(50vw - (48px/2))

@media(max-width: 720px)
width: calc(50vw - (24px/2))
height: calc(50vw - (24px/2))

@media(max-width: 580px)
width: 100%
height: calc(100vw - 24px)

display : inline-block;
AKA, voodoo magic for css

This sort of CSS failure:

div { display: inline-block; width: 50%; }
span { display: inline-block; width: 50%; }

<div>go left</div>
<span>go right dammit</span>

her: he's probably thinking about other girls
me: *in CSS, both "display: inline-block" and "display: inline block" are perfectly valid things and they even mean the same*

I wasn't happy with one of our UI views for editing a database query that consisted of about 50 fields ("editing" being the operative term here, not just viewing. It had to be two-way). Everything was hardcoded and defined manually, with each block of ~10 lines being repeated and mostly identical apart from the occasional double inline field and name of the variable. It had "just ended up that way" over time due to the variable names in the UI being different than the names of the variables that came from the API.

I decided to overhaul it all where I defined the different input components and which fields should be included, then made a function which would generate the page based on these definitions. It was about 500 lines of modularized functions and classes where the class for the actual view was about 50 lines- compared to the 1400+ lines of the previous version.

But, it didn't work. It should, but it "just didn't". There was no error. All I got was a blank, solid white page. I could make a drastic change or try something completely different and I would get the same error, same blank page. API fetch succeeded, value assignments succeeded, the object exists, but if you iterated it it was... empty.

I started getting really discouraged that I had made it too abstract. Maybe I actually made it more complex and unreadable than before. Maybe just hardcoding it all was the better solution after all. Maybe I had gone against KISS and overdesigned it.

I was up pretty late and everyone had gone home. When the last guy left there was that mood where "yeah if I can't make this work we'll just use the current version...".

Turns out I had tried iterating over a property of the set of fields to render, rather than the entire collection. In the old method the variables were a member of an object, but now they were its own object, a change I had made to isolate the set of values which were to be viewed/edited and make them easier to pass back and forth. This member existed since I hadn't cleaned it out yet, but it was empty.

I had been banging my head against this for a whole day and I was ready to admit I had made a mistake and wasted my time before discarding it all, but then I backspaced this one property and the interface went from empty to rendering perfectly and with all functionality intact. I swear god rays were coming out of my screen.

Javascript really needs a way to define consts for a block 1 level up.

So instead of

const el = wide ? els.wide : els.tall

You can do

if (wide) const el = els.wide
if (!els) const el = els.tall

// etc..

Just makes chaining and backup values way easier than inline conditionals 🤔

Rustfmt doesn't support inline function calls with a block last argument unless the last argument is an array literal or lambda. Dedicated support for arrays is obviously intended for XML-like trees where a factory takes a number of arguments and then a list of children, and the use cases for block last lambda argument don't need explanation, but what I don't get is how did no one catch on that this is a useful pattern that should perhaps be generalized? Why can't I produce the same behaviour for a function call in the last position.