Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Laptop.css

jjkaufman.github.io

Post reply on HN
Print view View original

31–38 of 38 posts

Re: Show HN: Laptop.css

#31

Post by _bxg1 »

jolmg wrote: post #29
_bxg1 wrote: post #27

Earlier quoted context omitted.

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

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?

Re: Show HN: Laptop.css

#32

Post by jolmg »

_bxg1 wrote: post #31
jolmg wrote: post #29

Earlier quoted context omitted.

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

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?

No, like I said, I only imagine this is the case.

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.

Re: Show HN: Laptop.css

#33

Post by eitland »

jolmg wrote: post #28
eitland wrote: post #26

Earlier quoted context omitted.

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.

I didn't intend it on you personally jolmg, but rather generally frontenders who read it :-)

Will update to make it clear.

Re: Show HN: Laptop.css

#34

Post by _bxg1 »

jolmg wrote: post #32
_bxg1 wrote: post #31

Earlier quoted context omitted.

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?

No, like I said, I only imagine this is the case. 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 s…

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.

Re: Show HN: Laptop.css

#35

Post by jolmg »

_bxg1 wrote: post #34
jolmg wrote: post #32

Earlier quoted context omitted.

No, like I said, I only imagine this is the case. 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 s…

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.

[1] https://tabatkins.github.io/specs/css-nesting/

Re: Show HN: Laptop.css

#37

Post by rubenhak »

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!

Re: Show HN: Laptop.css

#38

Post by rubenhak »

rubenhak wrote: post #37

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!

and most important, don't forget the iWatch 5 :)
Post reply on HN