Philip Walton

> for what I'm doing (a pretty complex web app with an almost desktop-style GUI with a bunch of buttons, text inputs and checkboxes everywhere)

Right. There's different contexts between an application an a (hyper)text document.

What's good semantic markup for one, will generally be bad for the other.

It's admirable (and desirable) to strive for adaptive layout and accessibility in applications - but they need a different type of framework than documents made for browsers. The browsers straddle this divide rather uncomfortably - being in part hypertext document browsers, and in part virtual machines for running general applications.

Approaches like web components[1] might help us move toward a standardised reality for "applications that happen to run in the browser", while css and html are still (more and more anachronistically) (hypertext) document markup and layout tools.

If you want to make a Web page/site (like alistapart.com) that's great. Swim with the current and draw inspiration from stuff like css zen garden[2]. With flex box, you can burn[4] most of the old complicated grid layout stuff, and comparatively easily make great sites.

That doesn't really help if you're a "front-end developer" making "apps" though. Even the few that make an effort to color within the lines are still fighting the browsers and the standard, trying to fit a code-on-demand app into a REST shoe[3].

[1] https://www.webcomponents.org/

[2]…

When you fork a Github project, you'll have to examine the code to see what it's doing and how.

With HTML and CSS, it's mostly visual but you can find improvements on semantics or simplifying what's there. If you can improve performance by rewriting a javascript function into CSS, such as animations, submit a pull request with your suggestions.

With Javascript, look for bugs and improve the code that's written. Javascript easily becomes a mess and is often referred to as spaghetti code when it becomes hard to manage.

Overall, look for ways to simplify the code, even if it means more code overall although usually it means less code.
Two examples:

https://philipwalton.com/articles/untangling-deeply-nested-promise-chains/

http://www.heydonworks.com/article/on-writing-less-damn-code

Bear in mind that BEM (CSS-wise) is just a nomenclature. What it addresses is exactly excessive nesting and dependence between mark-up and styling.

It roughly means that you imply structure via naming conventions instead of nesting (e.g. if you have a box inside a block, you'd style it via single class such as .my-block__my-box, instead of the traditional nesting approach .my-block .my-box). You can - and should - still use SASS (or other preprocessor) with BEM.

Some interesting resources regarding this:

http://philipwalton.com/articles/css-architecture/

http://philipwalton.com/articles/side-effects-in-css/

http://philipwalton.com/articles/extending-styles/

http://benfrain.com/the-ten-commandments-of-sane-style-sheets/

> But the big fixes to layout have been harder to specify and agree upon. They've been in the works for many years, but it's taken a while to figure out how they really should work, and which parts should be fundamental. It looks like it's getting a lot closer; the CSS Grid Module

Although lower-level and not as modular, flexbox can already be used with great success for a number of layout sections (media objects, vertical centering, input inserts) or full layouts ("holy grail", sticky footers and grids): http://philipwalton.github.io/solved-by-flexbox/

Flexbox is a CR, and it's starting to get pretty well supported: http://caniuse.com/#feat=flexbox

This lets you provide an implementation for a CSS feature that is perhaps not yet implemented by browsers, or maybe never will be.

You could always do this with Javascript, and some people have been. See: https://philipwalton.github.io/polyfill/

But this lets you do it in a less hacky, and especially, more performant way.

The author of that JS CSS polyfill library above actually wrote in 2016 how that approach was proving a bad idea, and the right way to do this was the houdini API... I guess we've been waiting for it since 2016? This is the first I had heard of it. https://philipwalton.com/articles/the-dark-side-of-polyfilling-css/

I like how he explains separating layout from presentation. When writing the layout code, keep in mind how its coupled to the HTML.

This link mentions how "layout" like z-index is coupled to the structure of HTML, because nesting elements creates new stacking contexts (Z-index is hierarchical - an element's z-index only controls it's depth within the current context, not the overall document).
http://philipwalton.com/articles/what-no-one-told-you-about-z-index/

This one advises using "js" prefixed classes for JS, so the JS is only coupled to the HTML & not the CSS:
http://philipwalton.com/articles/decoupling-html-css-and-javascript/