Show HN: Laptop.css
jjkaufman.github.io
jjkaufman.github.io
The idea is you can use it as part of your test / build process to generate deterministic(ish) image assets...
On this note, the worst offender in my opinion is Voyager for Laravel [1], where the "play" button has been put over a screenshot of the product, but when you click on it there's a 90 second video of a guy talking about the product. So. frustrating.
:root {
--laptop-content: ...
Huh. Interesting that I never noticed that CSS supported variables like this. I haven't worked on a Web front-end for some time, but I see that this has been pretty portable since late 2017. I remember that one of the big points of using CSS preprocessors like Sass was being able to use variables. Now, it seems they're a little less useful.It seems to me a lot of frontend developers has a hard time wrapping their head around the fact that there exist millions of users who prefer other browsers than Chrome :-/
Full disclosure: I sometimes work on frontend myself, I have talked to such developers.
Should you care? I think yes. I don't want the internet to be at the whims of a single entity. It's like authoritarianism vs democracy or having a monopolistic market vs a competitive one. What's best for the tech ecosystem isn't something the average developer thinks or cares about, though. When I show my co-workers how our front-end breaks when using Firefox, they often mistake my concern of portability to be favoritism towards Firefox. I'd use other browsers, but it would just make it harder to convince them to take the bugs seriously.
Edit: if any frontend/web developers today reads this, please do use Firefox for development. I'll tell you why:
I can only remember a single time that I wrote something in Firefox that didn't also work in the latest IE, Chrome and Edge.
Web developers I work with who use Chrome however seems to constantly have to go back and fix stuff that doesn't work anywhere but Chrome, exactly like web developers who developed in Frontpage and IE had to.
If you don't want to spend time with regressions from QA and you don't want to look unprofessional, develop on Firefox.
The happy feeling you get from doing something good for the web is a bonus.
Will update to make it clear.
https://github.com/MadLittleMods/postcss-css-variables
There’s also plugins for nesting and mixins if you want a more complete SASS replacement which seems to be the toolset the industry is moving towards.
The most popular PostCSS library is autoprefixer which is also helping with the transition to future CSS without all of the browser baggage. https://github.com/postcss/autoprefixer
1) Cascade (follow inheritance through the DOM)
2) Can be changed at runtime for things like toggling a dark theme
Preprocessors are still useful for other things, though. My #1 reason for using them is nested selectors, which for reasons I cannot understand haven't made it into native CSS yet.
As I understand it, browsers don't look at a selector and navigate, but rather go node by node and see what selectors match. Having complex selectors that require looking at parents and siblings is worse, performance-wise, than having a simple selector. I imagine nested selectors don't make it into CSS, because people don't want to further encourage the use of complex selectors.
Here, this is where I read about that:
https://web.archive.org/web/20150304005354/https://developer...
.container {
.line {
input {
}
button {
}
}
}
corresponds to: .container .line input {
}
.container .line button {
}
So there could just be a really simple internal translation step, if that's needed for performance reasons.It's more efficient, in the case of a complete selector like "#person_name", to simply see if a given node has that id.
This makes simple selectors more favorable than complex selectors that depend on node hierarchical interrelationships, so it's best to have a syntax that favors having simple selectors, than a syntax that encourages bad, complex selectors.
There's also the fact that complex selectors are more dependent on the structure of the DOM, so they could also be considered bad practice from the angle that the selector might needlessly tie them to a structure that semantically their styling shouldn't depend on. From the readability side, it's also easier for a developer to find affected nodes when reading simple selectors like `#foo` or `.bar` (they just need to search for the identifier with grep or the like) than when reading complex ones that require them to look into the structure of the document.
I don't think it's unreasonable to think that languages are designed to encourage what people would consider to be good practices. After all, if developer power trumped all, we could replace HTML and CSS with Javascript (and we do when either HTML or CSS don't suffice), but HTML and CSS exist to improve readability for developers and the ability for browsers to optimize their implementation.
That said, there are things like BEM (http://getbem.com/naming/) which have popped up to try and maintain that general pattern while trimming down the performance cost. I'm just not sure what that cost actually looks like, impact-wise.
In any case, I found this Editor's Draft[1]. I don't know what the current plans are for it, though.
https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_c...
And the CanIUse table:
https://caniuse.com/#feat=css-variables
I look forward to starting to use this in 2024.
Along with the 90%+ prevalence of it working on browsers, isn’t the joke mostly moot? Besides Chinese browsers and old IE/Edge, support seems to be fine. I don’t know exactly what Microsoft is doing with Edge Chromium on Windows 7/8, but if that’s pushed through more, the support is essentially universal if you’re not targeting the two Chinese focused browsers.
I don't think I have ever even considered using `white-space: pre` with generated content. Really fun, really cool!
If you could add more style options of devices like macbook, imac, few PCs, tables and mobiles it would be so great!