Two examples of hover styles on images
alexwlchan.net
alexwlchan.net
Sigh. We managed to raise a generation for which an instant interaction on a 1000+MHz multi-core gpu-accelerated 1000+MB/s io system feels snappy and that’s special. Good job, goob job.
you could add a negative margin to offset the border, or an always-on transparent border that only changes colour when you hover – but those can interfere with other CSS rules
The worst part of CSS is its globalness. You can’t have two paddings sourced from different subsystems, can’t name a border so you could address it specifically (e.g. as in el:border(myhover) {background: <gradient>}). CSS is so poor and antipattern and nobody bats an eye. You write an article like this and already see all these fragile hacks advices coming in, normalized by years of stockholming through even most basic layouts.
For some "web developers", this is literally how they create a page:
import React from 'react';
function App() {
return (
<div>
<h1>Hello world!</h1>
<p>This is my HTML page.</p>
</div>
);
}
export default App;For some "systems developers" this is literally how they create a program:
#include <stdio.h>
int main(int argc, char *argv[]) {
println("Hello world.");
}
Anyway, your comment feels like a straw man; I don't know anyone who actually believes what you're claiming, nor is this sentiment anywhere on HN. The closest things are discussions about whether your website should work with JS disabled whenever a too-clever website is linked.
Nah they're right. There's developers, in major corporations right now, who literally have no idea that you can just put HTML in a container and who are so drunk on node.js that they LITERALLY DO NOT UNDERSTAND what something like nginx, traefik, or Caddy is for.
These people are building healthcare systems.
https://stackoverflow.com/questions/39979816/how-was-jquery-...
https://github.com/jquery/sizzle
If you think that's wild, before there were dev tools in every browser, there was only Firebug (yes, there was only `alert` before that, we didn't even have `console.log`):
Added: And it was not a deliberate choice but kind of a necessity.
But global-ness is what you want from design directives. You want all your buttons to look the same, your links consistent. You want to define your base fonts once and then not have to worry about it for the rest of the build. You want to have your vertical rhythm (line spacing) repeated on most pages. You want most pages to have the same background and foreground colours. CSS syntax gives you all that for free.
Giving multiple elements the same border definitions is easy:
elem,
another-elem,
.some-class,
#just-this-one {
border: whatever;
background: swoosh;
}
I accept that managing things like the shared border example can get fiddly. SASS made it easier; some flavour of react-plus-css-helper-library thing can make it easier, kinda, if you squint. But it's actually _very_ simple to write the basic core idea in plain CSS. Personally, I feel that the discipline required to manage larger CSS codebases isn't that different than the discipline required to write good JS or TS; we just have a habit of pretending we shouldn't need to do that and wishing someone else would (via a library, or changing the standards). I don't know why we're happy doing it in JS or TS, but not CSS.
fooModule.*(x),
bar(x),
Math.floor(x) {
if (x === 42) return “oops”;
return thisfunc(x);
}
// elem.css
elem {
use border-bg from “./bbg.css”;
}
// html
<div>
import elem from “./elem.css”
<elem/> // has it
</div>
<elem/> // doesn’t
I was arguing that global declarations are useful. Your example is intentionally differentiatiating similar elements, and placing the specialisation inline with the DOM declaration.
So far these seem more like style preferences. I can’t infer the “anti-patterns” you’re concerned about, nor how your version solves them. Could you expand some?
Personally, I much prefer keeping the layout and style code out of my JS/behavior code. It makes both easier to read.
A line of code affects an element if written locally. That’s lexical scoping.
You can only runtime-check with aspect. You can statically infer with lexical scoping, cause all effects are specified in that scope.
My second example is solving the same problem, adding a common border and background to an element declaration.
My first example is solving the same problem too, adding a common behavior to a set of functions.
Lisp (and I think SmallTalk) give us a rich history of developing against the runtime. I don't see why we should avoid it in the browser. The dev tools are very good, and have been fairly good since the '00s.
In my current team, we type check our CSS-in-JS (CSS-in-TS I suppose). It doesn't add much value. It can't tell you if the style rules are compatible with each other, if they'll conflict, if the cascade will force an effect you didn't intend the current snippet to produce. I am sure you're going to tell me that CSS is bad because it allows that kind of problem... but that's how visual design works! Every element contributes to the whole. Designers work from the outside in, and also from the inside out, rebalancing and refactoring as they go. CSS is a fairly good analog of that.
Good, means I’m almost there! All true.
but that's how visual design works!
That’s how CSS works, not visual design. It mixes all together and you can’t even design a generic container because its customization will affect the inner content containing that type of a container. And all its custom margins will fight with its own margins-as-a-child. And you can’t properly outline it in-parent without reserving space in advance and dealing with shattered layout, or using half-baked “outline:”. This only worked for a non-recursive text. It was designed for text.
I have worked as a designer many years ago btw. Corel draw, pagemaker, autocad, etc. I could place elements, group them, place two groups by distance between centers of their main content groups, stick them to arbitrarily angled guidelines. I wasn’t the autocad guy (more corel + vba) but I’ve seen how people work with it. CSS is like a $0.5 paper doll dress-up toy compared to these industrial CNCs. It’s not a pinnacle of design, it’s below mediocre at best.
There are alternatives like constraints, alignments and so on that could be simply included into CSS next. But the stubborn sandcastle-model obsessed committee can’t add more than one practical thing per decade, because everyone will migrate asap. Their reasoning makes sense sometimes, but don’t try to put css on a pedestal, it’s a heavy tradeoff, not a win.
Could those CAD packages auto flow live text around the objects? Could you dynamically add new objects to your presentation in response to data and user interaction, and have them lay out perfectly according to your rules?
The paddings issue can be fiddly, but a little discipline can help. You've got two different width-calculation schemes to choose from. Flex & grid remove the need for most margin-wrangling and layout hacks. You can create relationships between objects and parents, and rotate/scale/translate groups of objects in 3D. You can flow text around irregular shapes. You have LOTS of control over fonts these days (I can't keep up with all the new font rules).
It may not be the pinnacle, but it's quite a reasonable compromise that's very easy to get into (admittedly hard to master, but so is most coding).
> That’s how CSS works, not visual design.
Visual design definitely, often employs a set of top-down ideas/rules, modified by sub-rules and ad-hoc exceptions.
> It mixes all together and you can’t even design a generic container because its customization will affect the inner content containing that type of a container. And all its custom margins will fight with its own margins-as-a-child.
If the paddings of your generic container don't suit some uses of that container, then maybe it's not as generic as you thought.
Also, this is pretty easy to do:
.generic-ish {
some: rule;
}
.generic-ish > .generic-ish {
some: !rule;
}> Outline is a line outside of the element's border. Unlike other areas of the box, outlines don't take up space, so they don't affect the layout of the document in any way.
If you s/border/outline in the dev console on the image you get what you want.
For the icons, I don't understand why the author believes that they need to have two copies of the icon inside the SVG. You can style every property of every element using CSS. If your icon is a single path element, it should remain a path element and be styled something like this:
svg.social path { fill: gray; }
svg.social:hover path { fill: #8df; }
.icon:not(:hover) {
filter: grayscale(1);
}Which, to be fair, is a pretty high cost. The consistency of the greys that only differentiate on hover is half the aesthetic value of the effect.
<svg><path d=“” fill=“currentColor” /></svg>
element { color: hsl(0 0% 0%) }
One advantage is that you can target the parent element and the SVG will change automatically.
You can also create multiple “shades” by having currentColor on multiple paths with different opacity.
outline: solid 10px red;
> ..., or an always-on transparent border that only changes colour when you hover – but those can interfere with other CSS rules
Next week: How to run your Docker React Node Babel Webpack Svelte grocery list application at the EDGE using Kubernetes on AWS serverless EC2 instances with Cloudflare workers.
EDIT: I forgot we're gonna use Bootstrap too.
<button class="bg-blue-600 px-4 py-3 text-center text-sm font-semibold inline-block text-white cursor-pointer uppercase transition duration-200 ease-in-out rounded-md hover:bg-blue-600 focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-blue-600 focus-visible:ring-offset-2 active:scale-95">Hello world!</button>
It works in TFA.
img{border: 10px solid transparent;transition:border 0.3s}
a:hover img{border: 10px solid red;}