Sign up Sign in Samples Blog contact support
further standardize key views



.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.




image in further standardize key views+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...

139897 original

Learning about this from Ethan right now on Circle 28: styling views - great stuff!

--John Abbe.....2013-09-19 18:21:06 +0000

Curious about the name of this ticket - what is a "key view" and why is this not something like "reorganize HTML tag classing" ?

--John Abbe.....2013-09-25 08:53:19 +0000

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...

--Ethan McCutchen.....2013-09-25 16:07:27 +0000


+Relevant user stories