Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "inline-block"
-
Question: What's the difference between display: block and display: inline?
Me: Thanks for your time...8 -
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??!?!?!?10 -
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.14 -
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 model12 -
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.9 -
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)5 -
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>8 -
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. -
I'm in a big fat fucking stinking rut, as in progress on this project has absolutely stagnanted.
Gonna rubber face your duck now **UNZIPS** excepts I don't have zippers, as joggers are the one true way; fake Adidas til I fucking drop.
Brain damage aside, I understand both how I've layed out the data and what I'm supposed to do with it. We have a virtual machine, an array of instructions and arguments for a given process within it, and we need to walk this array and map values to registers.
We also need to spill values inside registers to stack, IF they are required at a further point within that block. This also isn't terribly complex. We simply look forward in the array and see if the value is an argument to any instruction that *needs* this value to be loaded (ie, within a register).
So this implies multiple iterations; we need to better understand how one particular value is used throughout an F before we can make a final decision on how many registers and stack space are actually needed for the whole block.
Here's where it gets tricky. If there's a call, we need to be certain that the symbol being invoked has already been fully processed. Besides the obvious fact that recursion fucks me up, there's another matter: say a private method gets invoked by another private method. We can take advantage of this, by which I mean, sacrilege incoming so put on this toga.
Looking at the output for C compilers, it would seem this is not done in practice, I would assume because it's a pain in the ass. But when you have the guarantee that F will only be called internally, as that's what "private" means, there's two ways it can go:
0. It's well below the 13-20 cycle threshold, so you inline the fucker. No suprises there.
1. It's a more involved affaire, and invoked in more than one place, so you don't inline it. Codesize matters.
Recursion and [1] are the big deal things holding me back. Not because it's too hard, like I said this is kindergarten level abstraction. I'm just slow and fanatical, which is how I prefer to spell "constant obsessive paranoid delusions". I can see the potential optimization I can pull here, so I'm stuck trying to figure it out.
Idea would be, handling the register allocation and stack spill for an internal-internal (or deep internal; what we like to call a "guts" method) in synchronization with the *calling* processes. This is, fundamentally, violating all conventions -- but so under the hood no one will notice.
Let me give you an example. If we were to pass some value to a function, expecting to mutate it and get a different value back, in a lot of cases it'd be stupid to make an implicit copy by using two registers, one for input and another for the output. Dude, it's one cycle. Multiply it by a million, say sixty times per second, for every time you __needlessly__ make a copy of a value that we've already stated is mutable.
Clearly unacceptable. This is, in the strictest sense, everywhere in every single codebase. Premature micro optimization is the root of all goodness, God is great and praiseworthy. So how do we go about it?
Answer is I know and I don't know. By which I mean to say, this very thing I've done by hand. Assembly is fun. Now the issue is teaching a calculator how to do it. Not so fun.
There is a dependency chain between processes, as I believe I've kind of alluded to. I'm trying to make decisions on the side of the caller depending on the details of the callee, which is why recursion is rawdogging my soul. This is the same situation, it's inverting the direction of one or more links in the dependency chain, which makes no fucking sense.
And yet it does.
Brain, explain yourself.
How do *you* handle this without crashing?
Brain?
<<ME STEWPED; BEEP-BOOP>>
Alright then, that was a useless attempt at fuckery. Let's have a nap then, maybe it'll come to me in the morning. That's what I've been saying to myself for almost a month now.
Perhaps it is a hardcoded fuk.1 -
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 🤔15 -
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.3