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
-
css quick maffs
so you did this:
.foo:hover {
transform: scale(1.1);
}
and now ugly scrollbar is there when the element is scaled.
No, don't do overflow: hidden. There's a better way. Instead, do this:
.container {
padding: 1rem;
box-sizing: border-box;
}
the element total width is calculated based on the width of its content. That's true unless you specified width and height explicitly (if you did so, you're a doofus, I'm sorry).
Scaling makes content somewhat larger. With border-box, paddings work differently with the total width.
By default, if you set width to say 100px, and paddings are 20px, total width will be 140px — it's your 100px of content plus two paddings of 20px. width property set the width of the content, not the total width.
With border-box, width property sets the total width. So if you set width to 100px and paddings to 20px, total width would be 100px, just like you set it, and content will be 60px wide — it's 100px minus 20px times two.
The key part is it doesn't end with explicit width. The algorithm remains. When some node is rendered, its total width is calculated. When you use border-box, the total width will stay the same even if your content grows by some value that is less than your paddings. So, your content was 100px, you scaled it, and it became 110px. Well, then that extra 10px will be subtracted from your paddings, and they will be 15px each instead of 20px.
No more ugly scroll bar. Yaaay!
aight bye8 -
Oh boy do I sure love designing site layouts for mobile! The limited screen space makes me think about what's absolutely necessary to have on screen at any given time, and I need to account for both portrait and landscape. I love a good challenge - aaaand done! Time to check it out.
Ah, fuck, the browser has completely disregarded the text sizes I specified and headers of any size take up the entire screen space.
Ah, fuck, the browser has decided that 4 pixels of padding should be 32.
Ah, fuck, the browser has made the executive decision that images should be whatever size it's in the mood to display today.
Ah, fuck, all this enormous text has also wrapped itself to one letter per line.
Just a wild thought here: maybe mobile browsers should actually respect CSS rules.2 -
Right, that's fucking it. Enough. I'm all for learning new technologies, frameworks, and development protocols, but my time on this earth is limited and at the end of the day if I'm having to spend DAYS AND FUCKING DAYS just scouring through obscure forum posts because the documentation is shit and just hitting ONE FUCKING PROBLEM AFTER ANOTHER then there comes a point at which the time investment simply isn't worth it. I HATE throwing in the towel because some FUCKING CUNT code problem has got the better of me, but fucking sense must prevail here.
Laravel fucking Mix. Do any any of you use this shit on Windows? Because I take my fucking hat off to you. I'm done with it.
Oh, so your server uses 'public_html' instead of 'public' does it? Well, of course you can just set
mix.setPublicPath('public_html'); then can't you?
No, you can't. Why? Because fuck you, that's why. Not only do you have to hard-code your fucking public directory into each specified path, additionally you have to set
mix.setPublicPath('./');
Why? Because fuck you, that's why. It took me the best part of two days to discover that little nugget of information, buried at the bottom of some obscure corner of the internet in a random github issue thread. Fuck off.
Onto next problem. Another 5 hours invested to extract some patchy solution that I'm not at all happy with.
Rinse, repeat.
Make it work with BrowserSync by wrapping your assets like so:
<link rel="stylesheet" href="{{ mix('/build/css/main.css') }}">
Oh oh oh but "The Mix manifest does not exist"... despite a fresh install of Laravel 5.6 and all relevant node modules installed... follow some other random Github thread with a back and forth of time-consuming suggestions for avenues of experimentation, with no clear solution.
Er no, fuck off. I'm going back to Grunt and maybe I'll try Webpack/Mix in another year or two when there's actually some clear answers, but as it stands this a wild goose chase into a fucking black-hole and I've got better things to do with my precious time. Go die.5 -
<!doctype confusedRant 😕>
Plot: we need to release our website in two weeks which holds at least a thousand pages. All these pages are manually migrated from the old website, which doesn't have a database. Current status: 650 pages/1000 are completed, 40 different templates need to be adapted. I'm alone on these templates, my colleagues create the pages and fill the new database
So I'm working on the templates a WebDev coded for our website on a licensed CMS, and had this decently simple html block that looks like a square and consisting of roughly this (Emmet style):
a.area > blockquote > strong.title + p
After adding another <a> element inside the p, I noticed that my <a> wouldn't display and bust the whole look of the square.
Just for more details, the CSS the dev made is ultra specified (meaning each element is too precisely "described" : div.class .child .child2 { /* styles */ } when it could be .class .child2 for example). Also, the templates he made need to be compatible with any "module" the website has, thus the need of this high specificity
So I fired up the DevTools to check what happened, and had:
Expected: a.area > blockquote > strong.title + p > a
Actual result: some new a.area were wrapping the <strong>, the <p> and the <a> I just added. The source code was not showing any of this but just the rules I initially wrote - the expected result
Wtf?! I thought the JS the dev made was adding elements. I disabled said JS, and bam, these a.area were still wrapping everything!! What black magic would add these stupid tags I never asked for.
So I went looking in the CSS files in case some wizardry was happening, but everything was OK.
I tried changing my structure, changing tag (swapping a.area to p.area or without .area), HTML just said "nope, have those please".
Eventually I rewrote my own module out of frustration after three quarters of an hour fiddling with this stupid "module". I hate losing time for such shenanigans and under a lot of pressure because of deadlines.
Still haven't figured why those <element>.area would wrap everything out of nowhere...3 -
Aaaah, my delighted daily dose of wonderfully not-written-by-me CSS I have to edit from time to time...
I always feel so enlightened after spending time in those files.
2
Top Tags
Weekly Rant
View