Split out the hero component into a separate definition file and improve it.
The <hero> component was initially included in the guise-skeleton-base.css file, and it has some complex interactions with something else called banner which changed the size of the hero component. Now that the approach of components and layouts has congealed somewhat, we should make <hero> be an actual component. We need to untangle its interactions with banner, and allow size specification somehow using the semantic sizes created in GUISE-18. (Maybe reopen to provide line/block sizes.)
The hero needs to have its immediate children expand by default to fill remaining space, except for <header> and <footer> immediate children. Having a default layout is proving difficult to play nicely with explicit layouts, so the hero's main raison d'etre is to fill the entire view. It will still need a layout specified (unless default flow is desired).
By default the size will be equivalent to size-full. Rather than using a banner class, we'll change the size using other size designations such as size-subordinate.
There is no such selector as |~=, though.
We could try something clever to reproduce this CSS selector functionality:
This selects any layout coming at the beginning of a class attribute, or in the middle if preceded by a space. The theoretical problem is that it shouldn't match if the user separates class tokens with another form of whitespace, such as a tab or a newline. (This might happen not just by manual editing but by the page being generated by a templating engine, for example.) In that case the selector shouldn't work. Oddly though it does seem to work (at least on Firefox and Chrome and I don't know why. I've opened a question on Stack Overflow (as of yet with no response). Without understanding fully why this works I'm almost scared to risk it.
There's been no reply on Stack Overflow as per the class attribute normalization question, but we need to move forward on this and get something working. My best guess is that this will turn out to be that most browsers probably normalize like in XML but that was never put in the specifications. Even so, this solution would be less than ideal. And I don't like the attribute selection so much; the "contains" selector will not be as efficient.
Still we need to get un-stuck, and we can consider this a provisional solution. It's likely I'll want to come back and use something better, but hopefully that can be done transparently, with no change in usage or behavior.
Still no replay on Stack Overflow (even with a bounty). Looks like nobody knows.
But more thinking on this yields the question: do we really want a default layout for a hero component? At first I was thinking that hero and maybe even all the containers might benefit from default "layouts" (or at least default layout functionality, as we can't assign a class to a component by another class), which could be overridden with explicit layouts. But hero component have varied layouts in the wild. And a user may even want to have normal flow layout—why make it difficult for a user to remove the layout?
The same might be said of the card component. What layout do want by default? It seems that the Bootstrap card, the Bulma card, and the Foundation card all have a default layout of sorts. But would we really want to impose a layout on cards? Isn't the other frameworks' "default layout" merely just a vertical flexbox layout with a header and maybe footer?
We run the risk, though, of nothing having any layout, and indicating layout- for everything. This would be literally bringing layout into the content; it would prevent components from being pliable; we couldn't set up a general card, for example, and have different skins change the layout. But do skins radically change the layout? Or do they only tweak the color and font and such? And I suppose a skin could override a layout. (But wouldn't we want an explicit layout to override a skin?)
I think at least hero is something to general that we may not want to impose a layout. It really is just a container, and making it a "hero" really just makes it fill up the viewport. So we could remove the default layout.
Then we're back to the same problem with padding, though. If we want to nest a panel inside the hero to get padding, we would need to give the panel a layout-flex along-block. (We could add panel at the hero level, but then we have the problem of whether we allow double components or whether we have some sort of padding mixin.) I guess for the moment we can just give a hero layout-flex along-block for nesting and see how that goes.
So does this mean that there is a more explicit separate category of things called "containers" that have no layout, and maybe even card is one of them? Do we need to pull them out separately in the web site?
My best guess is that this will turn out to be that most browsers probably normalize like in XML but that was never put in the specifications.
I think I guessed wrong, and I didn't even fully understand what was happening. It turns out that attribute normalization was occurring because I was testing from a local XHTML5 file, and the browsers were simply following XML attribute normalization rules. Served as text/html, no normalization occurs. So this approach wouldn't work anyway.
The original hero makeover proposal was to have it fill the space with optional header and footer:
This capability seems to be covered right now with a flex layout along-block, but only if the component is a <section>. This may need to be revisited.