Video.js 5.0 skin and DOM changes

[mmcc]

Aside from the new default base theme we've been working on, there are some other changes we need to consider for semantic / accessibility / other reasons. Opening this to be the canonical place for such things, starting with the <button> debate.
#1499 / #1932 / #841 - Discussion around buttons / Working research spike implementing buttons
#982 / #1952 - Fluid width / responsive design
#1444 / Move to border-box as the default
#1492 / Stylesheet organization
#1553 / Volume Control

[heff]

It'd be great if we could open the door for lots of loader options.
e.g. http://connoratherton.com/loaders

[mmcc]

I've done a little work towards this, and while not impossible, these kinds of loaders would take a bit more work. The kicker is that a lot of these fancier loaders require a bunch of divs:

<div class="loader">
  <div class="loader-inner ball-grid-pulse">
    <div></div>
    <div></div>
    <div></div>
    <div></div>
    <div></div>
    <div></div>
    <div></div>
    <div></div>
    <div></div>
  </div>
</div>

Our current loader can easily be replaced with any single element loading thingy. An easy way to expand this to other loading options would be to allow for specification of the number of divs in the loading el.

[heff]

Yeah that makes sense. I was thinking we might look into how we could make the loader more configurable for different use cases, or even include multiple loader components, but that might be too much to take on for 5.0.

[mmcc]

My preference is to keep things purely CSS, but a dead simple way to do that would be to include more divs than we need and just display: none; the ones that aren't used by the loader. Seems a little hacky, though. I agree, it'd be nice to easily give more (customizable) loader options.

[dmlap]

+1 for pure CSS (some of those loaders are pretty cool looking, though)

[OwenEdwards]

EDIT: Moved to #2155.

Re: Keyboard access to buttons/controls, in #1932, @heff wrote:

we already support both spacebar and enter on our div buttons

That's true for buttons, but the way that menus are handled means that they are not keyboard accessible (I don't know about Dragon Naturally Speaking access - maybe @gdkraus has some insight?) Click propagation is prevented through the Menu component, but keyboard interaction is not, so, for example, pressing Enter on the captions button effectively clicks on the top menu item (often 'captions setting'), and pressing Enter on one of the other menu items doesn't behave correctly. (Actually, I notice that clicking on the menu button, rather than a menu item, seems to select the top menu item)

EDIT: Menus ought to work like W3C 'using ARIA menus', and the OAA Accessibility Menubar example. (I'm looking at this right now.)

[heff]

Closing. Everything here is finished except the button task which is under issue #2136. We also need an accessibility milestone per @OwenEdwards comment.