Jokes aside - and I absolutely love this - is there actually a good (S)CSS library, with freely-licensed configurable template imagery, that lets you say "I want this image to be displayed as the screen of an high-resolution photograph of a MacBook/iPad/whatever, sized so that the photograph of the device itself itself fills its container?" It's surprisingly hard to find, and I recently had to roll my own, transparency mask and all.
This doesn't answer your question with regards to devices, but for screenshots involving browsers, I believe that Screely is the best/fastest/easiest thing out there to use.
I always find this very frustrating, how hard can it be to put a demo (or even just a screenshot) of your product? Did they not think someone visiting their site would want it?
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.
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.
On average? No. It's easier for developers to target only one platform and switching browsers is easy enough for the average user that developers don't see much problem in putting the blame on the browser. Chrome also has greater marketing power backing it than other browsers, so it's the easy choice. That's what happens.
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.
Sad thing is we fought so hard back in 2006-2009 to get to get past bosses and clients who wanted us to just make it work in IE, and here we are a decade later and those who should be building on our work are tearing it apart by carelessness.
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.
I'm full-stack, as they say, but have been working almost exclusively on the back-end for the last couple of years. I don't think I remember a time when I did something in the front-end that resulted in it working in Firefox but not on Chrome, so you might be right, but I may also simply not remember.
Frontend developers have been using PostCSS for the transition period until this is fully adopted (which is a library set similar to Babel for adopting future JS, as well as experimenting with new CSS language level ideas):
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
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.
> 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.
No, I think you misunderstood. The concern is not for the translation, but rather that for every <input> node, it would have to check if it has an ancestor node that has the class "line", and then an ancestor node that has the class "container".
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.
Hmm. Interesting reasoning, but I'm not sure whether that would actually be a basis for this kind of design decision. Do you have a source where this was mentioned in the context of a proposal?
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.
It's certainly not bad practice from a semantic/structural perspective. Contextual selectors become absolutely essential the moment your DOM becomes at all modular.
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.
I don't mean that structure in selectors should never be expressed, but I do think that selector complexity should be avoided. Nesting seems to encourage selectors of arbitrary depth, while having them always start with no context seems to discourage making them too deep.
In any case, I found this Editor's Draft[1]. I don't know what the current plans are for it, though.
The caniuse site itself doesn’t properly work on my modern updated iPhone. The modals won’t go away. If a modal appears and it’s hidden behind the footer, I can’t read the rest of it. Yet it seems to be a site widely used and referenced.
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.
This is a problem specific to your iPhone — perhaps an over-zealous content blocker? If you can figure out what's different from a clean install, report it at https://github.com/Fyrd/caniuse/issues.
Adding an animated image of Steve Balmer and Bill Gates dancing at the Windows 95 launch is guaranteed to get an extra 10 points on Hacker News. It's just science.
This is quite useful, but frankly I doubt many would be willing to put the ASCII style laptop on their web site. Literally a week ago we had to design a bootstrap carousel inside macbook pro laptop here: https://berlioz.cloud
If you could add more style options of devices like macbook, imac, few PCs, tables and mobiles it would be so great!
37 comments
[ 2.9 ms ] story [ 76.8 ms ] threadThe idea is you can use it as part of your test / build process to generate deterministic(ish) image assets...
https://www.screely.com/
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.
[1] https://voyager.devdojo.com/
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/jhildenbiddle/css-vars-ponyfill
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...
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.
[1] https://tabatkins.github.io/specs/css-nesting/
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!