further standardize key views
Ticket
+issues
.content is always in body div, meaning it often wraps stuff that is not, strictly speaking, card content.
the class "content" has a poor name, likely to conflict with other systems
in content view, there are two nested divs that are basically redundant. to style content inline, both must be altered.
+solution
image in +discussion outlines changes:
- rename .content to .card-content for consistency
- use just one div to wrap content in content view
- get rid of view-specific content classes (eg .titled-content), because content has a consistent relationship to view and can be specified in other ways (eg .titled-view > .content)
- only add .card-content to card-body when it actually contains card content and only card content ( not in denial, options, etc)
- add set classes wherever there is content, so that standard selector pattern for content becomes, eg, .SELF-menu.content
This image should be a conversation starter...
Learning about this from Ethan right now on Circle 28: styling views - great stuff!
Curious about the name of this ticket - what is a "key view" and why is this not something like "reorganize HTML tag classing" ?
it's not a great name. I meant "key" colloquially (as in important); there's no central wagn meaning. When I named it, I didn't know how much of it would be about tag classing v tag structure v refactoring old methods to use standard view methods. Ended up being a little bit of all that.
Probably stuck with this name for now, since I emailed a few people with links to it. An argument for using id-based links in some contexts...