Comments (14)
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..
from ui_alchemy-rails.
+1 to andyfitz
from ui_alchemy-rails.
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.
from ui_alchemy-rails.
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.
from ui_alchemy-rails.
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 )
from ui_alchemy-rails.
Is .btn in leiu of .button ? We already have a .button so wondering why we need to switch to this other format?
from ui_alchemy-rails.
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)
from ui_alchemy-rails.
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.
from ui_alchemy-rails.
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?
from ui_alchemy-rails.
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)
from ui_alchemy-rails.
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.
from ui_alchemy-rails.
So I guess this is a write a style rule for .btn, .button, input[type=button]{...}
but not input[type="submit"]{...}
from ui_alchemy-rails.
https://www.redhat.com/archives/converge-ui-devel/2012-September/msg00002.html - discussion happening on the mailing list
from ui_alchemy-rails.
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.
from ui_alchemy-rails.
Related Issues (20)
- Renaming project HOT 48
- First-use interactive tours
- Icons HOT 4
- Multiple Select HOT 2
- Date Picker HOT 2
- Number Input
- File Chooser
- Select Box
- Range Input
- Checkbox and Radio
- Progress Bar
- Resizable
- Dialog
- Alchemy gem doen't have a description and summary. HOT 3
- Make the Login Page easier and clearer to implement with instructions
- Need global namespace variable hook
- menu navigation system needed
- rubygem-alchemy fails to build on Fedora 17 HOT 1
- Allow font URLs to be configurable through SCSS variable.
- Login and Password resets workflow proposal HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ui_alchemy-rails.