Move to border-box as the default CSS setting for skin elements

[heff]

We probably need to think through this a bit, but border-box can make certain things easier. It's not the default in most browsers though so it also might not be the best for making skinning easy, if most people are used to content-box.

@mmcc, @gkatsev

[gkatsev]

It's not the default anywhere and probably won't be ever or at least any time soon.
However, a lot of people are using the "shim" from http://www.paulirish.com/2012/box-sizing-border-box-ftw/ to have it everywhere.
Also, while people may be used to content-box, that is out of necessity. border-box is a lot nicer to work in because it is actually intuitive unlike content-box.

[albell]

+1. There are certain responsive techniques that are simply impossible with content-box. This is the one of the few things that ancient IE got right.

Whoever tackles this overhaul, I would also like to see the core CSS, the default skin, and the LESS mixins factored out into three separate @import build files. And in the dist files, the core CSS should be come first, conceptually. The sequence is switched now, for no reason that I can see.

[heff]

IE < 8 default to border-box! :) And by default I mean there's no other option. Actually since the original skin was built to work in both models there are probably a number of areas we could simplify.

factored out into three separate @import build files

@mmcc has talked about doing this. Right now we use the full less file for the designer which can't do imports. But we've talked about other options.

for no reason that I can see

To put the styles people should be changing first, and the ones they shouldn't be changing last. Separating concerns will help that.

[gkatsev]

The designer could have three sections or just concat the 3 files before displaying them.

[albell]

The designer could have three sections or just concat the 3 files before displaying them.

Right, also putting the core CSS in the designer just makes things bloated, and scrolling heavier. There could be some kind of "edit core" button in the UI for people who actually needed to go there.

If we can agree on an approach I will tackle the stylesheet as is. The big question is what selector approach to use. box-sizing doesn't inherit by default. So if you have some in-page component that you want to use a specific box model throughout its tree, you have to set the property for every single element within that component. You can do this by either using the star selector:

.video-js, .video-js * {box-sizing: border-box}

or by exhaustively declaring every single component ever created, like:

.video-js,
.vjs-tech,
.vjs-poster,
.vjs-poster img,
.vjs-text-track-display,
.vjs-text-track,
.vjs-subtitles,
etc etc {
box-sizing: border-box
}

Both work. The disadvantage of the first is selector performance. Since selectors are parsed right to left, the reverse of the way humans read them, this is not great, because it initially grabs everything on the page, then filters it all the way to root. I don't have hardcore data on this but it seems everybody warns against it. The disadvantage of the second pattern is its verbosity (the list currently runs to about 65 selectors, including pseudo-elements) and maintenance demand, arguably not a big deal but I understand the objection. I lean towards option 2 despite its ugliness. Thoughts?

Not that this isn't an issue if the reset uses inherit to reset the model globally, e.g.:

http://css-tricks.com/inheriting-box-sizing-probably-slightly-better-best-practice/

which was dreamed up to tackle this very problem, but frameworks generally haven't gotten there yet so we obviously can't count on that.

[mmcc]

This is probably taking a bit of a detour on this topic, but I took a stab at breaking up the stylesheet into more manageable pieces over the weekend. Let me know what you think: https://github.com/mmcc/videojs-default-skin

@heff and I also discovered you can @import remote files via HTTP in Codepen, which is something we've been thinking about using in place of the designer anyway, so the concat stuff is kinda a moot point.

[gkatsev]

Selector performance isn't really something to worry about, really, nowdays.
But following css-tricks's advice, I'd go with:

.video-js {
  box-sizing: border-box;
}
.video-js *,
.video-js *:before,
.video-js *:after {
  box-sizing: inherit;
}

@mmcc do we have an issue to track splitting the files up? If not, we should make one.

[albell]

Selector performance isn't really something to worry about, really, nowdays.

Yeah, that might well be true. I just looked again, five years later, at:

http://www.stevesouders.com/blog/2009/06/18/simplifying-css-selectors/
http://stevesouders.com/efws/css-selectors/universal.php

On the second page, Chrome reflows in 0 ms, FF in 20. Instantaneous. Great. I do remember older browsers choking a bit on this though. Souders' graph in the first link seems to show things start to perform OK starting with IE8. There are still a bunch of warnings about * floating around the web though, e.g.

https://developer.mozilla.org/en-US/docs/Web/CSS/Universal_selectors

says:

"Note: Use the universal selector very carefully, as it is the most expensive CSS selector in terms of webpage performance."

Is there consensus that it's okay to use nested now? If we're going to use the star selector I'd like to use:

.video-js, .video-js * {box-sizing: border-box}

and set the value directly because it pollutes the inspector less with that huge scrolling cascade of inherited styles. Aesthetics, really.

[gkatsev]

The general consensus is not to worry about selector performance. It is almost always not the issue. If we find it to be an issue, we can look into changing it.

[mmcc]

New issue opened: #1492