I use Sass for larger projects. I try to always start with vanilla CSS and move to preprocessing when I feel I need it. I want to switch to PostCSS + cssnext, but I haven't found the time yet :(

I think the primary reason for it is JS developers that feel out of their comfort zone with CSS, so they're trying to bring it to JS. I think it excludes people who don't know JS, it increases the barrier to entry for working on a project, and over time it ends up being more of a problem than a solution because you often need the very concepts you are trying to avoid that way (e.g. cascading and inheritance).

Hopefully CSS variables & scoping will help with this. CSS variables are perfect for making CSS depend on JS without moving all of your style into JS. You just set the variable in JS and do everything else in CSS. It could even be separate people writing the two. Scoping will help with encapsulation.

Encapsulation and dynamic variability are the two primary arguments I hear for CSS in JS, so hopefully we're on our way to getting rid of this terrible practice.

Atom. It's hackable like Sublime, but it doesn't go to the extreme of using config files for everything. Also, it's much more maintained, and it's open source. I keep Sublime around as well, and use it to open really large files, since Atom is still slow with that.

I do agree that a lot of it seems to be JS developers who are used to working imperatively (a series of commands) and cannot understand CSS due to its declarative nature. It's too different from what they know, and they're out of their comfort zone, so they're trying to bring it in it by moving everything to JS. For non-programmers, declarative languages are actually easier to deal with, because they don't have to care about ordering and state (e.g. compare :hover to mouseenter/mouseleave). This is why I think it's very important to be able to do things from CSS, without forcing everyone to learn JS: there are actually many people who are great at HTML & CSS and find JS hard or impssible. There are no official statistics on their exact number, but it appears that they are at least 50% of HTML/CSS authors. There is a recent movement to add JS APIs for things without a CSS counterpart because it's easier for browsers and "everyone knows JS anyway". I think we should fight this trend.

However I'm fully aware that CSS is a bit of a mess. I love it, kind of to how you love your best friends: they have some terrible habits, but they also have redeeming qualities, otherwise they wouldn't be your friends. CSS was originally designed for simple documents, not applications, and we're trying to make it something it was not designed for. However, we cannot change anything because we would break existing websites, so we are just adding and adding to it and it has become quite a messy, inconsistent pile of stuff. Even things we do realize were mistakes (e.g. margin: auto for centering, or border-radius instead of corner-radius) we can't fix because it would break websites.

Lastly, people have different performance expectations from CSS, which influences what is possible with the language. In JS the onus is on you not to create an infinite loop. In CSS, the language must actively prevent it. Therefore, there are many features that would simplify a ton of CSS tasks (e.g. element queries or referring to other properties), but because of the remote possibility of cycles, we cannot add them to the language. Also, even without cycles, if a feature cannot be implemented in a way that makes it blazing fast, it just doesn't get added to the language. Parent selectors are an example of this (yes, they are in Selectors 4, but will only be available in querySelectorAll).

All these issues result in CSS being incredibly confusing to work with, and only the first one is actually the author's fault. At work people often come to me with CSS problems that seem simple, so they blame their inability to solve them to their poor CSS knowledge. More often than not, it turns out that the simple thing they were trying to do is actually not possible without JS or markup changes. I always find it embarrassing when I have to tell them that.

Thank you, glad you like my book! Could you clarify your question a bit? The 3 things I would like to change …in standards? …in web development? …in the world? …something else?

Thank you! So glad you enjoyed it!

Actually, most of my day-to-day work is not that different from a typical JavaScript developer: I go to the office, I write JS all day, I go home. Sometimes I think a bit as well or have meetings where we all think about the design of what we're building. Pretty standard, right? In HCI research, you typically build a system, then test it with a user study, then publish a paper about it. The exact percentages for each differ per researcher. In my case, it's about 75% development, 10% user studies, 10% brainstorming, 5% paper writing. This is a bit more development than most HCI researchers, as I want to release my work to the public just like another open source library, and I want people to be able to use it in their projects. Many (if not most) HCI researchers produce prototypes, built primarily for research. This is not wrong, just a different way to work: As a researcher, your primary job is to produce ideas. Time spent fixing bugs, is not time spent on ideas. On the other hand, time spent fixing bugs could mean more people using your ideas. It's a balance, and every researcher picks a different point on that spectrum. Hope this answers your question! :)

As I wrote in my blog post about it, it was basically a cleanup of several helper methods I had developed over years, plus my idea for wrapper-free DOM chaining.

You might need to be a little more specific than that :)

1. My inspiration is almost always my own needs, I usually make things to scratch my own itch and put them out there hoping that others might have the same itch :)

2. I highly value human readable code, so I don't really use any of those, as I don't like the result. Of course over time I have developed a few strategies to keep my code DRY and maintainable, but I don't think what I do fits in any of these schemes.

3. I polyfill when necessary, and I ADORE polyfill.io because it takes all the hassle and extra weight away from polyfilling. For FOSS projects though, I think supporting the two latest versions of every browser (and no IE, just the latest Edge) is perfectly sufficient. Developers don't typically use older browsers. Any complaint I had about the websites of my open source libs not working on older browsers was from developers testing them there for the sake of it, not because they actually used that browser. So these days I reply to those complaints with "Thanks for the report, is this the browser you actually use?", to which they tend to back off and admit it isn't.

4. There are still inconsistencies and browser bugs, but the situation doesn't compare to when I started in 2005 (and think that that was the tail end of what we know as the browser wars!). These days, if there's a difference between browsers, it's either because one of them implements something and the other one doesn't, or because you hit some obscure edge case (I hit many of those, but I think I'm an exception there). When I started, ANYTHING you did on the Web, you hit browser bugs. A good developer back then wasn't one with good knowledge of the specs, it was one with good memory of all the browser bugs. We're way past that now.

5. I imagine how awesome it will be once I finish what I'm working on and people can actually use it, what they will make with it etc.

6. I go to a nice restaurant (see my answer to Juanita above) :)

Haha, nice one!

If we're talking about things already in (reasonably mature) specs, it would be one of these:

• conic-gradient()
• attr() everywhere
• :focus-within
• backdrop-filter
• CSS rule nesting

But hey, it's a magic wand, so maybe things don't have to be in specs yet or even be implementable! In that case, it would be one of the following:

• :has() everywhere, not just in JS
• var() to refer to ANY property, not just custom properties
• element queries and generally style queries
• Making custom properties animatable right in CSS, no JS required

I’m afraid I haven't really thought about this, as I'm not that into VR (yet?). There is WebVR however, which has some browser support: https://webvr.info Perhaps if you ask the people involved in that project, they can give you a better answer!

Because right now we have a ton of technologies, and browsers are literally playing catch-up with the specs. There simply aren't enough browser developers to implement everything right now. This is seen even more acutely on smaller browsers with even fewer resources, like Mozilla or Opera (before they switched to Chromium). Even though specs also take a long time for different reasons, it's still much quicker to design a new feature than to implement it. Think of how long it takes you to think about what you want to code and compare that to how long it takes you to actually code it. See what I mean?

Also, since they have to prioritize, sometimes browsers hang back to see what other browsers will do. Sometimes they implement very early, but the spec changes over time so their early code ends up not being compatible with the eventual standard and needs to be revised or totally replaced (this is what happened to Microsoft with Grid Layout). With finite resources, browsers have to prioritize which features to work on next and this is where developers can have a voice, most browsers now listen to developer demand when deciding on prioritization. For example, Microsoft has a uservoice that they use to decide what they implement next: wpdev.uservoice.com/forums/257854-microsoft-edge-…

fantasai, a very prolific CSS spec editor, wrote a series of articles a couple years ago going into how the CSS WG works, in a lot of detail: fantasai.inkedblade.net/weblog/2011/inside-csswg

As to your specific question, typically someone suggests it, and if there are enough use cases and it's possible to implement performantly by browsers (not everything is, e.g. parent selectors), it gets accepted. This is where you, as a developer can help: If there is a feature you really want in CSS, collect as many use cases as you can and post in our repo: https://github.com/w3c/csswg-drafts/issues If you make a good case, with enough evidence from around the Web that this is needed, it could get in! However, keep in mind that even things that get accepted often don't really make it or take years. Getting something accepted is not enough, a spec editor needs to put the effort in to write the specification for this new feature, which is very hard work. So, if there's no editor that is interested enough, it could stall.

About Prism: Glad you like it! It started from dabblet.com, the HTML & CSS playground I built in 2012. It was an evolution of a crude script I had written to highlight code on my presentations (you can find its origins in the CSSS repo: github.com/LeaVerou/csss/blob/gh-pages/plugins/co… — CSSS is my presentation framework). Eventually I realized it might be a good idea to clean it up and release it as a separate script, and it became way more successful than any of the scripts it originated from.

About my favourite pastime (I assume you mean besides making stuff): I really love food. I like trying new things at restaurants, the more adventurous the better (my Instagram feed is literally over 90% food pictures and ratings) and I really enjoy cooking together with my partner, although we are not particularly experienced cooks yet. We're both really into food though, so we're getting better at it :)

Note that even on caniuse, this is described as a "non-standard method of styling scrollbars". Browsers have their own proprietary methods of styling them, but there is no standard. Therefore, I can't really blame Mozilla for not implementing a specification that doesn't exist.

Now, you may ask: "Why doesn't it exist?", to which I have no good answer. It's tricky to specify something that will work well across all possible scrolling mechanisms on all devices and OSes, which is similar to the reasons why we don't have a standard for styling form controls yet. It has been discussed briefly in the CSS WG though, and we do recognize that authors have a need for it, so I'm a little hopeful that we will see a spec for it in the near future. Fingers crossed!

About hyphens, you have to use them, whether you like them or not, otherwise your custom element is invalid. I don't like upper case characters in tags, but that's just personal aesthetics, there's no rational reason behind it.

About web components, I really love the ideas and can't wait for wider browser implementation. I'm especially excited for HTML Imports, though Mozilla has been stalling that one. It's really bad for usability to have to tell people to import a bunch of files into their page to use your library, whereas with HTML imports they just import 1 file, nice and clean.