Tetris and The Power Of CSS | Hacker News Reader

Tetris and The Power Of CSS

heydonworks.com

220 pointsnej46 comments

I love CSS's pseudo-selectors. In my opinion, they are the best part of CSS3 and are generally great.

However, I think the author's jabs at CSS pre-processors and their adherents are unsubstantiated and a little unfair. I don't see how using SASS precludes you from knowing about or using complex selectors. As the author points out, SASS is merely an efficient and more intuitive way to write classic CSS. The good parts of CSS are still the good parts of SASS, and by definition every feature of CSS is a feature of SASS. It doesn't really follow that using SASS predisposes you to be less knowledgeable about regular CSS.

If anything, people using SASS likely use many more complex styles and work on larger projects, and are probably know more about and actively use more aspects of CSS than do people who don't have a need for SASS.

Not only that: if the author wanted to extend the trick for N-column grids, then they'd probably need to use a CSS preprocessor to output the final CSS rules (e.g. for N=5, the widths would be 20% and there'd be 4 special :last-child:nth-child rules).

Am I the only one who clicked the link expecting to see the Tetris in pure CSS?

AskHN: is there a good online resource that actually explains the layout mechanics of the modern browser? Not a comprehensive CSS reference (there're lots of them) but fundamental principles? lmgtfy's welcome.

Is something like (https://developer.mozilla.org/en-US/docs/Introduction_to_Lay...) what you were looking for? Or Were you looking more for how the browser reads CSS and sticks that into a formatting context? For the latter, I would suggest visiting https://developer.mozilla.org/en-US/docs/Web/CSS and poking around the key concepts a bit

Here you go: http://learnlayout.com/

So did i. You are not alone. Heck even OP knows people would come for that. But still, pretty cool post. My CSS-writing colleague asked me this the other day, wrote the mathematical part of the code for him. though i used the n%3 == 1 method.

Though know that i think of it, i think he ended up using JS for this :/

Not sure if it's what you had in mind, but I found both his advanced and basic tutorials to be really good (different audiences though, there is no "medium" tutorial to bridge it :-) )

http://learn.shayhowe.com/advanced-html-css/

I expected it, which is why it took me a while to actually click it. To quote the author

> Did you think I was actually going to recreate Tetris in CSS? Sorry, no. Nobody needs to do that.

I mean that stuff is usually pretty awesome, but we've had more than enough playful experiements and this was far more valuable and the title is imo a disservice to this.

Geoffray Warnants did a simple CSS3 Tetris in 2011: https://developer.mozilla.org/en-US/demos/detail/tetris-css3...

Great article on what is definitely a couple of nice and powerful features. For those new to nth-child and last-child, they are both IE9 and above features [0] [1] (of course, all non-IE browsers have proper support).

[0] https://developer.mozilla.org/en-US/docs/Web/CSS/:nth-child

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/:last-child

It staggers me when basic things like this are so late in the IE support game. I mean, IE6 - fair enough. And complicated, new layout stuff (columns, flexbox) - fair enough too. But selectors based on the index of an item in a list?! Why the hell did MIcrosoft drag their feet for so long and screw us all over - I can just imagine having to wait another 5 years before I can actually use this stuff...

http://selectivizr.com/

That requires javascript, so is appropriate for 'nice to have' design elements, but not for core layout, etc.

I love this article except for the argument it makes about preprocessors. While I agree with the author that preprocessors do not replace the need for a deep understanding of CSS3, that doesn't mean that preprocessors are useless or bad; hell, the ability to nest rules alone saves me hours and hundreds of LOC.

I don't think the author is suggesting they are useless or bad.

Great article, however I won't be satisfied until someone provides me with a working CSS-only Tetris. Hmph!

tldr:

    li:nth-child(3n + 1):last-child {
       float: none;
       width: auto;
    }

    li:nth-child(3n + 2):last-child {
        width: 66.666%;
    }

i feel this should be a problem that's going to be solved by flex-box.

I feel like the solution presented is the correct one. Using flex-box divs for everything won't be an improvement over table layouts.

Yes it will because you have separated layout from content

Thanks for giving some credit to plain old CSS. I've used SASS & am starting to use LESS but I'm really appalled when job interviewers give me a strange look when I say I don't use them religiously.

Same with COffeeScript... let's get real, pre-processing is great and all but there are tons of scenarios where it's not worth it just to get around writing extra sets of brackets or duplicating a bit of CSS.

Surely there are logic-intensive places where it is a huge boon but then I'm surprised I don't see more people advocating the absolute need for something like Dart rather than pre-processors.

Anyway, I feel like when you go to corporate work they want you to know atomic level ("how do various browsers interpret this bit of css") whereas its the smaller companies who want to know how many lines of code you saved by using syntactic sugar ("do you use LESS or SASS?"). They're way impressed if you use it even if it's just saving you 10 lines of code per project... Just an observation about pre-processing / interviewing / code hipsterdom. :D

You're lucky. In the interviews I go to they haven't even heard of SASS or LESS.

Heh it's because I was in the RoR world... now that I'm in IBM Java-land I'm sure I won't be hearing it for a while.

Eh, trust me I do miss it because I love open source and I think it's more fun to choose your own libraries/frameworks, but man do the interviews get annoying... I found tons of average pay junior level jobs in RoR that really gave me a hard time in interviews for not knowing yet another Backbone-esque js library & they act like it requires such high intellect that letting me learn on the job would be a gamble or something. When I switched to the Java world I got picked up at higher pay with a no-hassle interview just based on my GPA & prior achievements (I have a master's degree in audio signal processing -- & yes, RoR'ers still often could not take it on faith that I would be able to comprehend their js preferences).

Bottom line is there are powerful tools in both camps (corporate tools v. open source) but I found that open source interviewers reaaaaally needle you even though they have less $$ to offer. And in the end they won't invest in talent, they all seem to just be looking for a senior dev who is down on his luck.

Can't say I wouldn't work at an open source shop if it wasn't the right fit, just saying it can be a bit more hostile than advertised. Those folks are very picky and often looking for a golden goose at entry level salary.

Anyway, just my limited experiences. I believe coding and work should be fun, but I'm pretty sure we need to set our sights on a real white whale instead of all these BS semantics.

CoffeeScript is much much more than just avoiding extra brackets. Anyone avoiding it because of the hype should do themselves a favour and check it out before dismissing it. I can't quantify the amount of time I've saved both reading and writing CS instead of JS, but it's gotta be in the 10-20% range.

And please, can we drop the "hipster" meme around new languages/tools? People experiment and adopt promising new technologies because they see a benefit to using them.

I really don't get why this article starts off with a rant about less and sass. What do pre-processors have to do with anything demonstrated? Do they make these things harder somehow?

I know of this pseudo-selector. I've avoided really using it because of IE though.

I'm sort of in the same boat as you in that I have to support IE8 for one of my projects. However, these selectors are often used to simply enhance the appearance of something, so the lack of IE8 support isn't a big deal. Basically, I let certain styling gracefully degrade instead of simply not using the newer CSS rules.

To be fair, in all of my side stuff I ignore IE completely, but at work I've been tasked almost exclusively on the JS with IE8 support, so I haven't had to worry about it. Great point though!

While I agree with the premise that css preprocessors are overused, I can't stress enough that the use of complex css selectors is a really bad idea. Not only can it kill performance (or at least make it hard to reason about) it encourages tight implicit coupling between the style sheet and the document which generally leads to hard to maintain front ends.

Is there a better way to solve the problem presented? Because I think the author does it with about the least amount of coupling possible, and that's to be applauded.

The "last" class he mentioned is a better solution. His only reason against it was "complex template logic is bad". If you're using a sufficiently powerful system for managing the Dom it's usually much easier to manage the complexity of the "last" class. It's fast and easy to tell at first glance which styles will be applied, and refactoring is easy as a result.

His mention of separation of concerns is, IMO a common misunderstanding of what that term means. The coupling has to be made somewhere after all and it's better to choose the more performant and more explicit way.

I'm not a big fan of the 'last' class approach since it's redundant and pollutes the markup. YES, it only does this to a very small extent, but when we're talking about which solution is 'better', I think it weighs pretty significantly. I don't see anything inherently tricky maintenance-wise in his approach.

What happens when you change the structure of the markup? How do you know for sure which rules apply to the stuff you're changing?

> While I agree with the premise that css preprocessors are overused

I'd like to know how one maintains a huge modular css code base without any sort of preprocessor.

Preprocessors are here because CSS sucks, and no standard committee seems to want to fix it. That's why people built these tools right, to solve a problem nobody was going to solve for them.

That's exactly the same thing with javascript. If javascript was decent we would not need all these compile to javascript languages.

These tools bring diversity and choice to a poor plateform with shamefull languages that are not evolving very fast. You cant fix it just by adding features without fixing the core. that's what preprocessors are for and it's ok to abuse them without shame.

EDIT:

my point is "it's good enough" isnt good enough, in a time where we are supposed to maintain complex front-end projects and asset pipelines, that work on different devices that have their own idea of how to implement (poorly written) standards.

Well, I think JavaScript is good enough (I do prefer Python though) and we certainly don't need compile-to-JS languages like CoffeeScript (which IMO just takes a somewhat-ambiguous syntax and makes it more ambiguous). TypeScript is somewhat of an exception, but I view it less as a language (since it doesn't change runtime semantics afaik) and more of hints to a linting tool.

The problem with CSS preprocessors is that they are simultaneously too powerful and not powerful enough. That is, things like SASS mixins and nesting make it easy to make mistakes (specificity overload and huge stylesheets are the two big ones). At the same time they don't change runtime semantics so you can't fix the biggest problems in CSS like specificity wars, finding dead selectors and namespacing.

I do like variables and expressions though (mainly for colors and grid units).

The way you maintain a big modular codebase is to make your stylesheets really stupid and build the smarts into whatever is generating the DOM. The tools we have for generating DOM are both far more mature and we have more control over the semantics of the runtime.

I'll toss my 2 cents in. People often forget that one of the biggest components of UX is page rendering speed. This solution while addressing a visual inconsistency will slow down the page considerably.

I wouldn't say "considerably" for most pages. From what I've read, complex CSS selectors won't have much of an appreciable impact on your average site/page.

http://stackoverflow.com/a/12279783/179609

Pseudo classes are very slow. Take a look at the bottom of the table he had using more complex attributes. The bottom line is that when we don't know how many elements are going to be cycled, it's a good practice to think in terms of worst case scenario.

Would it be better to adjust the first element rather than the last one, as the first element is most likely to be the most important?

I think it's just for effect - the point of the article is determining which elements to act on. The author mentions you could just apply centering to the element instead.

Depending on the logic in the site, that may be true. However you can't use the technique used here verbatim, as it relies on being able to use the last element and the nth element together to determine the number of elements and whether or not the element should be stretched.

"Did you think I was actually going to recreate Tetris in CSS? Sorry, no. Nobody needs to do that."

What a major let down :(

Aww, I was expecting a game of tetris in CSS.

But awesome all the same

Is it a new thing? I zoom OUT for many articles that are shared here in order to read them easily.

I think it's a responsive trend. Many sites even think my 1280x800 screen size is small and notch me into a mobile friendly view. Which is good for me as I normally zoom by about 125%. Personally 16px is comfortable for me with my resolution at about 1/2 metre.

I fix the font size and font in Firefox and state a preference in Chrome (seems to get overridden). I have a default zoom of 125% for Chrome, but it's starting to look like I can ditch that soon, as author's are changing their designs.

Sometimes resizing the window can lead to something more pleasing (font sizes can also change depending on the window size.) Resizing the browser doesn't play that well with tabs - resize one and you resize them all.

“You can please some of the people some of the time all of the people some of the time some of the people all of the time but you can never please all of the people all of the time.” ― Abraham Lincoln

In general though responsive sites are better for me.

When I say 16px is comfortable for me, I'm referring to font-size.

Reply on news.ycombinator.com