Live data from Hacker News

Show HN: Laptop.css

jjkaufman.github.io

21–30 of 38 posts

Re: Show HN: Laptop.css

#21
post #6

: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.

Sadly not portable enough if you need to support IE. Give it a few more years though.

Or load a polyfill only for IE11 users so you can write modern code without orphaning them:

https://github.com/jhildenbiddle/css-vars-ponyfill

Re: Show HN: Laptop.css

#23
post #15

Earlier quoted context omitted.

Sadly not portable enough if you need to support IE. Give it a few more years though.

Does frontend developers care? 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.

Re: Show HN: Laptop.css

#24
post #4

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, transparen…

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. https://www.screely.com/

Slightly embarrassing that they don't have screenshots on their site.

Re: Show HN: Laptop.css

#25

Earlier quoted context omitted.

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. https://www.screely.com/

Slightly embarrassing that they don't have screenshots on their site.

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.

[1] https://voyager.devdojo.com/

Re: Show HN: Laptop.css

#26
post #23
post #15

Earlier quoted context omitted.

Does frontend developers care? 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. I…

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.

Re: Show HN: Laptop.css

#27
post #14
post #10

Earlier quoted context omitted.

And unlike preprocessor variables, they: 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.

> 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…

Except that nested selectors trivially convert to traditional selectors. i.e.:

  .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.

Re: Show HN: Laptop.css

#28
post #26
post #23

Earlier quoted context omitted.

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. I…

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 Fire…

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.

Re: Show HN: Laptop.css

#29
post #27
post #14

Earlier quoted context omitted.

> 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…

Except that nested selectors trivially convert to traditional selectors. i.e.: .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.

No, I think you misunderstood. The concern is not for the translation, but rather that for every 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.

Post reply on HN