I gave up on using CSS for form styling when I hit snags like requiring 3 textboxes adjacent to one another (like a phone number) or a dropdown list next to a textbox. I just couldn't come up with a reliable way to style it without good ol' TABLES.
I'm thinking about going back to CSS for form styling; I don't know:
Whether it's more usable to have captions on top or on the left of the field.
How to style the things so they place nicely even with a couple of adjacent form elements.
References? Is this still a pipe dream?
You mean like this?
Basically we create a pseudotable
.mxrow {
clear: both;
width: 100%;
height: 50px;
}
.mxcell {
float: left;
padding-top: 10px;
padding-bottom: 10px;
height: 26px;
}
.mxcell_firstcell{
width: 25%;
}
And the markup would be
<div class = "mxrow">
<div class = "mxcell mxcell_firstcell"><input element /></div>
<div class = "mxcell mxcell_secondcell"><another form element/></div>
</div>
The individual cell classnames serve to apply specific css (my markup is a grid)
There are a couple of CSS templates designed specifically for laying out forms.
vessess.com
Uni-form
I hope this helps point you in a productive and awesome direction. Take care.
No, it is very possible, and I (and many others) have been doing it for years.
Look at float: (left|right) and display: (inline|inline-block).
Other people give you some valid suggestions... if you still have problems you can try a form css framework like formee... http://www.formee.org/
Related
TL;DR: Wondering if there's a CSS property that can break content where HTML doesn't naturally:
Baby
Buggy Bumpers
instead of
Baby Buggy
Bumpers
The only way I can think of to do it is to add where you don't want the line to break, but I'm working in WordPress, which strips those.
This is to graphically style a site's name on the home page. The site name is part of the nav, so it's inside an <li>, using grid layout.
Luckily in my case, setting the width with a dimension that is relative to the font size seems to break the way I want at all viewport widths:
.my-brand a {
width: 16ch;
text-align: end;
}
white-space: nowrap and such elements won't work with the "baby buggy bumpers" example because the need is to break after one specific word. Just wondering if there's some way to specify in a way similar to nth-child(2).
Made a Codepen to play with.
If you can't use Javascript and can't add tags in the string like :
<div class='string'>
Baby<span>Buggy Bumpers</span>
</div>
It only remain "hacky" CSS solution. There is one using pseudo-elements :
HTML :
<div class='string'>
Baby
</div>
CSS :
.string{
width: 11ch;
text-align: end;
font-size: 2em;
}
.string::after {
content: "Buggy Bumpers";
color: red;
display:block ;
white-space:nowrap;
}
Live exemple : https://codepen.io/camillewemajin/pen/JjWzWzN
But that's not really clean for many reasons, like SEO...
My website has a number of standard constructs in it, like tables and buttons and so forth. In some cases, I want one instance of a construct to be marked up one way and a different instance of the same construct to be marked up a different way. How do I write the CSS to accomplish that?
For instance, I have some checkboxes that I use for the Checkbox Hack that need to kept invisible or hidden offscreen and some other checkboxes that are real checkboxes that are used on forms. What's the best way to write the CSS so that I can distinguish between the two types of checkboxes and mark them each up differently?
Right now, I have the checkboxes used in the Checkbox Hack marked up like so:
input[type=checkbox] {
position: absolute;
top: -9999px;
left: -9999px;
}
This has the unfortunate side-effect of hiding my "real" checkboxes entirely.
I've learned my CSS in a slightly haphazard fashion so I never learned the standard approach(es) to this common situation. Could someone enlighten me on the best way to handle this?
You could use CSS classes.. for exmaple
input[type=checkbox].special {
position: absolute;
top: -9999px;
left: -9999px;
}
that way, only checkboxes that have class="special" will be affected.
Yotam Omer is right, you should use classes. I do it this way:
.hide {
display:none;
}
then all you have to do is add the class "hide" to the checkboxes/other elements you want hidden.
<input type=checkbox class=hide>
I'm making a friends list script for an online browser game I play. I have 4 divs I need within the wrapper: 1) List of friends, 2) Add Friend, 3) Friend requests, 4) Chat. I figured out how to get the first two, but I need advice adding the rest. Here's what I have so far and what I want to add:
What would be the best way to add the two divs on the right? Should I make some sort of table of the 4 divs?
My css for the two divs both look something like this:
position: relative;
width: 40%;
height: 70%;
top: 5%;
left: 2%;
border: 1px solid blue;
If anyone can give me insight on a good way to accomplish this setup I'd greatly appreciate it. Here's a fiddle of the basic outline I have so far: https://jsfiddle.net/kfupd6hb/1/
You can use float:left; attribute of css.
I've updated ur fiddle..
Somehow i'm unable to create a link here that's why providing link in comment.
I suggest using display:inline-block; to get the <div>'s side by side, you can make a really perfect grid with that property.
Note: I use the word Module which in BEM is called a Block. Also using modified BEM naming convention BLOCK__ELEMENT--MODIFIER, please use that in your answer as well.
Suppose I have a .btn module that looks something like this:
.btn {
background: red;
text-align: center;
font-family: Arial;
i {
width:15px;
height:15px;
}
}
And I need to create a .popup-dialog module with a .btn inside of it:
.popup-dialog {
...
.btn {
position: absolute;
top: 10px;
right: 10px;
}
}
In SMACSS and BEM, how should you handle positioning a module inside of a module?
In your answer, please identify the correct solution, and analyze the following approaches as well: (note that all of the examples below build upon or modify the above CSS)
Approach 1
[ override the original .btn class inside of .popup-dialog ]
CSS:
.popup-dialog {
...
.btn { // override the original .btn class
position: absolute;
top: 10px;
right: 10px;
}
}
Markup:
<div class="popup-dialog">
...
<button class="btn"><i class="close-ico"></i> close</btn>
</div>
Approach 2
[ add a subclass inside of .popup-dialog ]
CSS:
.popup-dialog {
...
.popup-dialog__btn {
position: absolute;
top: 10px;
right: 10px;
}
}
Markup:
<div class="popup-dialog">
...
<button class="btn popup-dialog__btn"><i class="close-ico"></i> close</btn>
</div>
Approach 3
[ subclass .btn with a modifier ]
CSS:
.btn--dialog-close {
position: absolute;
top: 10px;
right: 10px;
}
Markup:
<div class="popup-dialog">
...
<button class="btn btn--dialog-close"><i class="close-ico"></i> close</btn>
</div>
Approach 4
[ subclass .btn with a layout class ]
CSS:
.l-dialog-btn { // layout
position: absolute;
top: 10px;
right: 10px;
}
Markup:
<div class="popup-dialog">
...
<button class="btn l-dialog-btn"><i class="close-ico"></i> close</btn>
</div>
Having struggled with the issue in a recent large-scale project myself, I applaud you to bringing this to attention on SO.
I'm afraid that there's not a single 'correct' solution to the problem, and it's going to be somewhat opinion-based. However I will try to be as objective as possible and give some insight in regard to your four approaches on what worked for my team and what didn't.
Also I'm going the assume the following:
You're familiar with the SMACCS approach (you read the book and implemented it in at least one project).
You're using only the (modified) BEM naming convention for your CSS classnames, but not the rest of BEM methodology development stack.
Approach 1
This is clearly the worst approach and has several flaws:
It creates a tight coupling between .popup-dialog and .btn by using context-based selectors.
You are likely going to run into specificity issues in the future, supposed you will add additional .btn elements in the .popup-dialog in the future.
If somehow you'd need to use classnames unaltered, I'd suggest at least reducing the depth of applicability by using direct child selectors.
CSS:
.popup-dialog {...}
.popup-dialog > .btn {
position: absolute;
top: 10px;
right: 10px;
}
Approach 2
This is actually quite close to our solution. We set the following rule in our project and it proved to be robust: "A module must not have outer layout, but may layout its submodules". This is in heavily inspired by #necolas conventions from the SUITCSS framework. Note: We're using the concept, not the syntax.
https://github.com/suitcss/suit/blob/master/doc/components.md#styling-dependencies
We opted for the second option here and wrap submodules in additional container elements. Yes, it creates more markup, but has the benefit that we can still apply layout when using 3rd party content where we can't control the HTML (embeds from other sites, etc.).
CSS:
.popup-dialog {...}
.popup-dialog__wrap-btn {
position: absolute;
top: 10px;
right: 10px;
}
HTML:
<div class="popup-dialog">
...
<div class="popup-dialog__wrap-btn">
<button class="btn"><i class="close-ico"></i> close</button>
</div>
</div>
Approach 3
This might seem clean (extends instead of overwrites), but isn't. It mixes layout with module styles. Having layout styles on .btn--dialog-close will not be useful in the future if you have another module that needs to have a different layout for a close button.
Approach 4
This is essentially the same as approach 3 but with different syntax. A layout class must not know about the content it lays out. Also I'm not to keen on the l-prefix syntax suggested in the book. From my experience it creates more confusion than it helps. Our team dropped it completely and we just treat everything as modules. However If I needed to stick with it, I'd try to abstract the layout completely from the module, so you have something useful and re-usable.
CSS:
.l-pane {
position: relative;
...
}
.l-pane__item {
position: absolute;
}
.l-pane__item--top-right {
top: 10px;
right: 10px;
}
.popup-dialog { // dialog skin
...
}
.btn { // button skin
...
}
HTML:
<div class="popup-dialog l-pane">
<div class="l-pane__item l-pane__item--top-right">
<button class="btn"><i class="close-ico"></i> close</button>
</div>
</div>
I wouldn't fault anyone for this approach, but from my experience not all layouts can be abstracted in a reasonable manner and have to be set individually. It also makes it harder for other developers to understand. I'd exclude grid layouts from that assumption, they're easy enough to grasp and very useful.
There you have it. I'd suggest trying the modified Approach 2 for the reasons stated above.
Hoping to help.
BEM
If you don't modify .btn inside .popup-dialog first approach is the best.
If you need some .btn modifications, according to BEM methodology you have to use modificator class, like .btn_size_s
If you have modification not directlly connected with .btn, and you doubt whether may be reusable in future, for example you have to float .btn to right only in popup, you can use mixin like .popup-dialog__btn
SMACSS
Again if you need just place one block inside other -follow first approach.
If you need any modifications, there 2 ways : subclasses and descendant selectors.
If you modification may be reused in future - use subclasses, like .btn-size-s.
If modification is tightly connected with some specific module - better use descendant selectors.
UPDATE:
Add few points to clear my answer:
Firstly, Approach 4 is unacceptable - you mix module with layout it is bad practice, as Layout classes in charge of grids and page sections geometry, Module is independent from Layout and should know nothing about section it placed.
Now let me comment other approach and what is the best usage of it:
Approach 1 - Consider following case: You have Popup Module with 'close' Button Module. Popup do nothing with Button, no modification, no floats or margings, its just its child. This is the case this approach is best.
Approach 2 - Another case: Popup has child Button, but we have to add extra top margin and float Button to the right. As you can see this modification tightly coupled with Popup, and cant be usefull for other modules. Such 'local' modifications best usage of this approach. in BEM this approach as also known as mix
Approach 3 - Final case: Popup with child Button, but we need bigger Button, such modificated button can be reused and may be usefull for other Modules and pages.
In BEM its called modifier
To mark main difference between A2 and A3, lets remove Button from Popup and place it somewhere else . A3 will still affect Button, A2 not.
So to work with module as child you can use A1 or A2, A3 should be used in case on module modification independently from context.
First off, I want to clarify that a button, by definition in BEM, is an ELEMENT not a BLOCK. So if you were to tackle this problem using the BEM methodology then this issue becomes a bit simpler.
Secondly, I agree with mlnmln's solution (Approach 2) as it defines the element variation within the block, which is unique to the block itself. However, if an element variation like this button exists outside of the popup-dialog block, then you would want to take Approach 3 and apply a naming convention that allows for global usage.
There is another convention that maybe suits your needs: https://ncss.io
Goal:
A predictable grammar for CSS that provides semantic information about the HTML template.
What tags, components and sections are affected
What is the relation of one class to another
Example:
<div class="modal-dialog">
...
<div class="wrapper-button-dialog">
<button class="button-dialog">close</button>
</div>
</div>
In my web app I use several CSS classes to write less code. I use them quite often in the markup to add single property or two in some cases.
These are the following
.clear { float: none; clear: both; }
.fl_l{ float: left; }
.fl_r{ float: right; }
.ta_l{ text-align: left; }
.ta_r{ text-align: right; }
.no_td:hover { text-decoration: none; }
What similar classes do you use? Have you ever seen this technique in other projects?
Sorry to post an answer on such an old question, but I think this is a bad idea. Maybe for a specific set of problems, it fits the bill. My thinking is that CSS is where the style information should be. By doing what you suggest, you are essentially just using the style attribute in html and therefore mixing content w/ style information. This is a bad idea because if one day you decide to change the style completely, you will have to go in and also update the HTML by removing most of the classes.
For example, if you have HTML like this (say for an abstract that is used many times within the page):
<p class="abstract ta_l mb10">
Lorem ipsum dolor set.
</p>
And one day you decide to change how that abstract looks: for example, you don't want it to be "text-aligned:left" anymore and no margin bottom (that's presumably what mb10 would be... i've seen this being used before), you would have to go in and change the HTML.
Now multiply this by 10 elements you have to change. What if it was 50? What if you were doing a complete redesign? shudder.
CSS provides a way to select multiple elements with one simple query and give them an appropriate style that is easily changed from a centralized location. By using these "helper" classes, you are making the maintenance of this project a nightmare for the next developer.
Instead, if you have HTML like this:
<p class="abstract">
You should sign in or something!
</p>
and CSS like this:
.abstract {
margin-bottom: 10px;
text-align: left;
}
you could just change that one rule to this:
.abstract {
text-align: right;
margin-bottom: 0;
}
and be done w/ it! For all 50 elements!
just my 2 cents
-- from someone who just got burned by this.
yeah, if you don't use common classes like you do then your CSS files get extremely large and every class becomes extremely specific
some other common classes...
.split { float: left; width: 50%; }
.center { text-align: center: margin: auto; display: block; }
.bold { font-weight: bold; }
.top { vertical-align: top; }
.bottom { vertical-align: bottom; }
Restore the flow after a floating element:
.clearfix:after
{
clear:both;
content:".";
display:block;
height:0;
line-height:0;
visibility:hidden;
}
Everyone has their own preferences and it also depends on the nature of your application. That said, I do personally tend to reuse a base.css that I port from application to application as a starter style component. Within it I also implement Eric Meyers css reset statements which make development across browsers much easier.
If you are genuinely interested in finding out how professional css frameworks are formed then its probably worth your while downloading and reviewing the following:
960 grid css framework
Blueprint css framework
I like to stay away from what you describe as common class names, keeping as much style-related information away from the HTML as possible. As mentioned by hunter, this does mean selector lists can sometimes get long, but I don't find it a problem.
If I were to use a common class name for clearing floats (the only one of the examples given that I usually might), I'd more often than not use something like .group - the word group at least has some small amount of semanticity attached to it (a group of things that likely belong together). This was suggested by Dan Cederholm.
There are sometimes other considerations that may mean it's either okay or not okay to use class names like this. For example, if your layout changes depending on viewport size via media queries, you may not want something to be styled the same at all times meaning the class name looses its usefulness as you have to be specific with your selectors anyway. Another example would be if the HTML is content-managed by a non-techie client who may not keep your classes intact.