Buttons

[ehelms]

This is to track the discussion and design of buttons.

[andyfitzsuse]

I'd like to support the bootstrap styntax (not use their framework but keep their classing schema supported with out stuff )

<a class="btn btn-primary btn-large btn-success" href="#"> a button </a>

would make a large green primary button..

[jcoufal]

+1 to andyfitz

[andyfitzsuse]

ok so the class .btn will do the obvious

a.btn{display: inline-block; padding $block-padding; border: 0; outline: 0; text-shadow: 0; margin: $block-margin}

the other classes like .btn-success will just do colours and text-shadows
{background-color: lighten($rh-green, 20%); color: darken($rh-green, 50%)}

.btn-small and .btn-large will alter the padding with potential consideration for font-size and line-height

basically all bootstrap classes should be supported and we'll add the conditionals like .icon which would add padding-left: 3em; as a placeholder for icon classes like .icon-star to create :before pseudo element insertions of icons.

I'll write this stuff up in a code pen.

[ehelms]

Will .btn be generically supported? There are instances where using the <input type="submit"> is useful and in some cases need to be supported for non-javascript based form submission.

[andyfitzsuse]

input[type=submit](with no classes) will share the same rules as <a class="btn btn-primary ">... by default
I dont mind hand-holding for those cases where we forget to class but it should be limited to good - non conflicting guesses.
eg input[type=button], button, a.btn{/*the same rules should be applied here */}

We'll have to define the generic styles in the cascading order before we define the btn-* syntax style classes classes; otherwise using .btn-* wont overwrite the defaults .

One thing to note is that the more base-level rules we write, the less DRY this becomes. we'll effectively be rendering the defauly background-color of an input[type="submit"] and then overwriting it with background-color: $rh-green; when we add the class .btn-success

To answer your original question . yes .btn will apply those rules to anything you set it on (which includes <input type=*) however I wouldn't go doing <section class="toolbar btn btn-success" > for obvious reasons ( a toolbar is not a button )

We could write our code in a way that restricts our classes to set html elements but it would slow down client processing and make our sass a little more complex (because we would be constantly defining the safe elements for a given rule )

[knowncitizen]

Is .btn in leiu of .button ? We already have a .button so wondering why we need to switch to this other format?

[andyfitzsuse]

We could keep it the same. I understand hungarian notation is not everyone's favourite (we can afford the extra bytes)
I only suggest this because it's syntax matches bootstrap . Which could make onboarding new devs a little easier.

Supporting both is fine but we should keep it to just the two (.button .btn)

[ehelms]

You will always find me leaning towards as being explicit as possible. That being said, I can understand how both using de-facto standards and Hungarian notation that is quite evident have their uses.

[andyfitzsuse]

I'm very much with you on that
(I'd prefer the obvious .button) but of course the web isn't all English and now that bootstrap is getting some sort of critical mass, we're going to encounter those who only know the syntax they've already learned.

I reckon it's worth it for us to support bootstrap classes 1:1 but also add in our own full-named classes as a safeguard. Just keep it to the two and no more agreed?

[jtomasek]

Is having input[type=submit](with no classes) defaultly sharing .btn styling a good idea? I lean more towards not doing this because if we want to use submit in a different way than button, we'd have to reset the btn styling on it.

Also keep in mind that it's not possible to use pseudo elements (such as :before to set an icon) on input tag. The solution is using button tag as submit instead, although I am not sure about browser support. (http://api.rubyonrails.org/classes/ActionView/Helpers/FormTagHelper.html#method-i-button_tag)

[andyfitzsuse]

You're quite right. good catch! generic styles opens a whole can of worms which we are really not ready to deal with.

not all form elements allow pseudo elements

leaving the default as unstyled might motivate us to fix the haml.

you can use the failover background-image icon method but that would really suck to write a massive exceptions list just for the use case....

input[type=submit]{} should either have a single specific rule that is visually distinct. or preferably un-styled completely.

What worries me is that we shouldn't be specifying a.btn, button.btn{} rules but rather just .btn and documenting which elements it is supported for. Element prefixed CSS rules are slower in the browser and it just makes for uglier selector code for us.

[andyfitzsuse]

So I guess this is a write a style rule for .btn, .button, input[type=button]{...} but not input[type="submit"]{...}

[andyfitzsuse]

https://www.redhat.com/archives/converge-ui-devel/2012-September/msg00002.html - discussion happening on the mailing list

[ehelms]

Closing due to acceptance of https://github.com/Katello/converge-ui/pull/73
Any bugs or enhancements should be opened as new issues or pull requests.