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

Ticket

 
+issue

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

 

 

 

+discussion

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