I have declared common css classes for common margin and padding classes in my css so that i can use them without making other css declarations too specific.
For example :
.padTB5{padding:5px 0;}
.pad10{padding:10px;}
.mTop10{margin:10px 0 0;}
.mTop5{margin:5px 0 0;}
Is this method right??
If not then why?
If yes then which is better margin or padding? (I know margin issues with browsers)
Please guide... thanks in advance :)
This is bad practice as classes should be semantic - that is they should describe the type of thing you are styling. For example "blog-header", "primary-this", "secondary-that" etc.
In practice, the downside to using classes as you describe is that if your visual design changes and you need different sized margins or padding, then you will need to change the class names too - which means changes to both the CSS and HTML. Or if you just change the CSS then the class names no longer describe what they're for. This approach is not much better than using inline styles.
Margins and padding are different things and behave in different ways. Margins can collapse in certain circumstances whereas padding doesn't. Padding will include background images or colours whereas margin doesn't. Borders will display between padding and margin.
In my opinion, this is not optimal, unless you do it right.
In your markup, you now have something like this:
<div class="pad10 mTop10">
and you have that all over your site.
What if you want to change your CSS to have a little extra margin/padding?
.pad10 { padding: 12px }
.mTop10 { margin: 12px 0 0 }
Oh. Those class names aren't looking so sensible anymore: you have to either put up with wrongly named selectors, or go Find and Replace in all your files.
What if you decide that some elements with .pad10 need to have red text?
.pad10 { padding: 12px; color: red }
Now the class name makes even less sense.
It might be alright to do this type of thing if you also apply a relevant (semantically sensical) class/id to each element in your HTML:
<div class="contactErrorMessage pad10 mTop10">
because that way, at least you can do:
div.contactErrorMessage { color: red }
You shouldn't do that. Naming classes like left or margintop20 is unadvised. You should use classes like content or sidebarBox, that describe the content.
Let's say you want to change the margin-top from 10px to 1em. Using your method either
mTop10 will have margin-top: 10px;
or you have to change your className to mTop1em
None of this is good.
See w3.org goodclassnames about this.
Also see w3.org about box model for margin, padding.
Margin is different then padding. Margin is the space out side the box, padding is the space inside the box. Both margin and padding are cross browser compatible. Your declarations are correct although it is not a recommended practice to create classes for margins or padding. One good use to this is creating a class for rounded corners or shadows, where you can quickly apply round corners by specifying the round corner class.
Related
I try to reduce the size of a cell in an sap.ui.table around the input field.
In the screenshot below you see marked in green what I want to reduce.
As you can see I managed to reduce the font size and for "debugging purpose" I changed the background to red.
My Style.css:
.test_maybe_he input {
font-size: 0.75em !important;
background-color: #ff0000 !important;
padding-left: 0px !important;
margin-left: 0px;
}
I tried a minus margin, but it only moves the content of the input field and not the input field itself to the left.
My view itself has the class sapUiSizeCompact, still I think there is too much space around and since I have a lot of columns it does not fit to the screen.
Maybe someone has had the same issue and wanted to make a larger table editable and found a solution to reduce unnecessary space. Maybe as a sidemark, it doesn't need to work on a non desktop screen, too. (I try to move from a webdynpro abap to this sapui5 app.)
I appreciate your tips and hope to learn. Maybe some jQuery is necessary to do it?
Here the Plunker it's a little rough and not tailored to the exact point, but it should bring across the point.
I am not sure the standard CSS classes will help you because the padding is generated on a very low level. sap.ui.table.Column doesn't have the property class or styleClass, so you cannot hook up there. sap.ui.table.Table is too high level. Applying a standard CSS class there will affect the table itself, not its columns and cells.
What you can try is giving your table a custom CSS class.
<t:Table id="table0"
...
class="myVeryCompactTable">
then you can remove the padding in your CSS file
.myVeryCompactTable.myVeryCompactTable .sapUiTableCellInner {
padding: 0;
}
I used myVeryCompactTable twice to increase specificity (so I don't need !important). You can ofc use other ways to increase the specificity.
Result looks like this
I have what I can only assume is a pretty generic CSS queston...
Let us imagine for a moment we have the following:
body{
background-color:blue;
color:white;
padding:2px;
}
Let us also assume we have this as well:
body{
color:white;
background-color:blue;
padding:2px;
}
With all that in mind, is there any particular structure, orientation or proper placement to CSS style elements-with respect to the placement of that element's styles and what line that style should be on?
Put another way, is there any "Standard" that dictates the background color in those two examples must be the first declaration made? Or is the arrangement of element styles completely arbitrary?
I came here to pose this seemingly trivial question to you masters of the CSS world as I am trying to fully understand CSS. It occurs to me, I can not find any documentation that specifically covers CSS syntax-with respect to proper writing form. Also, it seems to me that if CSS stands for Cascading Style Sheet that the styles placed in/on an HTML element would best be served if they were to maintain some sort of consistency with the styling of a page/section/etc all alongside the HTML, right?
Any help you could offer would be greatly appreciated!
There's nothing in CSS that requires the styles in a single declaration to be in any particular order. It makes sense to organize them in some way, and Mature's way is as good as any. (I usually think of it as "create the element, then position it," meaning I reverse his 1 and 2.)
The exception to this is when you specify the same style in more than one way for the same declaration. If you look at mature's item 6, what he's saying is that some browsers won't understand box-shadow and will understand webkit-box-shadow. You should set it up so that browsers that understand both should use box-shadow, and you do that by putting it last. If you have two equally specific declarations, the one that is encountered last will apply. (For more information, see this.)
Only one "standard" is possible in this case (with unambiguous order): You can sort properties alphabetically to help yourself and another have a fast search in.
OR more abstract: The overall logic of the sort "from the General to the local and less important". It is recommended to arrange the properties in the following order:
Position of the element relative to the others:
position, left/right/top/bottom, float, clear, z-index.
Size and padding:
width, height, margin, padding..
Border, it partially refers to the size and can be added to 1-st.
General design: list-style-type, overflow..
Colors, fonts and style design: background, color, font..
The property without prefix is written last.
Example:
first: -webkit-box-shadow:0 0 100px 20px #000;, then:
box-shadow:0 0 100px 20px #000;. This is to ensure that the standard (final) implementation is always more important than the temporary browser implementation.
In css, files are rendered from the bottom up, so whatever is below the other will be implemented. That is the only order based rules I can think of.
However, you can use "!important" to overide an element that is taking precidence lower in your css file. (If both styles have "!important", the lower one once again will take precedence.)
Just let me know if you have any questions.
I have seen a lot of css which uses margin-right: -4px to get rid of the space between inline-divs. Why is -4 being used? And is it going to work everywhere?
-4 is used when the width of a space is 4 pixels. It's completely arbitrary, completely dependent on the font metrics (family, size, etc), and therefore by definition not going to work everywhere.
It's this utterly arbitrary value that makes this one of those workarounds that really highlights the fatal flaw of using inline-blocks for (horizontal) block layout in the first place.
This is how inline-block works. if you want your divs stay in the block but be inline you can use inline-block, there are more tricks to fix this, one of them is margin-left: -4px, you can find more from the link here:
https://css-tricks.com/fighting-the-space-between-inline-block-elements/
I suggest to use CSS Grid to create blocks for layout. Here is a website to find some example for CSS Grid:
https://gridbyexample.com/examples/
In Chrome and Safari, the following CSS problem occurs:
ul, li and a or link have a default CSS property that pushes everything vertically away. I have fiddled with the following properties:
font-size
margin-right
padding
color
text-decoration
margin
padding
border
display
list-style
vertical-align
line-height
line-height
font-style
margin
font-variant
padding-top
padding-bottom
margin-top
margin-bottom
And nothing seems to prevent the problem.
I've downloaded the CSS reset by Yahoo, but I'm unsure how to use it properly.
I haven't pursued that because I don't know that it would solve my problem anyway.
I've looked at your Fiddle and I'm slightly confused. You say things are being pushed away vertically, but I don't see that happening at all.
The only thing I see which could even somewhat meet that description is the fact that your links are on separate lines.
If this is the problem, the solution very simple: divs are block-level elements. This means that they default to 100% width and are designed to break onto a new line before they start, and onto a new line after. This is the behavior of display: block; and is built-in to the default styles of a div.
To fix this, apply the following style:
#headernav div{ display: inline; }
This, however, is the least of your problems. The code you copied into the fiddle lacks a closing tag for one of the div elements, which could cause unpredictable behavior in older browsers. You have two divs with the same ID, which is a major no-no.
In this update to your fiddle I have fixed the HTML problems you have. Note that 'tempLink' is now a class, and is targetted by a '.' in CSS, not the '#' that indicates an ID.
I have applied the above CSS to the class tempLink, instead of any div within your headernav.
Note in that fiddle that your two links are now side-by-side. You can control the horizontal spacing between them with margin and padding (target the tempLink class).
As Adrift mentioned it would be a lot easier to diagnose if you use jsFiddle. That being said, have you tried display: inline-block or float: left?
I have an issue that terrorizes me in my sleep, unrelentingly . If you have an attainable solution and care to share it, please do; I'd like to have a normal night of sleep again.
On my latest project, there are multiple times when I will need to have 4 or 5 elements floated next to one another. Each element must be sized using percentages (%) but must also have border-right: 1px solid #000.
Once upon a time, I would normally size each element with percentages, then create a child element that would have all of the styling properties that the parent probably should have had, including the border-right. This solution isn't ideal, however, because it involves a lot of unnecessary markup.
A co-worker then directed me to another solution. When an element has a width that is sized using %s, and also needs to have border-right: 1px solid #000, apply margin-right: -1px as an offset. And while it works, it created another issue for me (which is why we're here, together, in union).
When zooming out in any of the major browsers (ctrl mousescroll, ctrl -), the floated elements that have been the focus-of-discussion tend to dance around a bit; the last element toggles between breaking to the next line and then snapping back. Please refer to the image below:
The reason this should be addressed is because the scope of the project has the potential of serving people from many different demographics (especially those who may need to scroll in, or out for that matter, to make the text larger or smaller). A very broad project, indeed.
How can I reach my goal highlighted in the example above?
How can I have 4 or 5 or more (or less) bordered elements floated next to one another, sized proportionally using %s, WITHOUT them breaking form?
You can use the experimental box model CSS3 declaration to have the borders detract from the elements width instead of adding on to it. This should prevent the problem. Quirksmode has a nice write up on it. It is supported by IE8/9 and current versions of webkit, opera and ff.
li {
-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
box-sizing: border-box;
}
The basic issue here, I think, is that you're 'misusing' the width property - width is supposed to control inner boxes, not the size of outer boxes. That is, your borders are supposed to be added on to your boxes, not included in the calculated width.
The result is that you don't have many choices beyond either:
Using Javascript to do some fancy recalculation,
Seeing if you can trigger quirks mode and use the IE5 box model (NOT a good idea),
Replacing borders several background images in lots of stacked divs (not nice), or,
Floating 20% width containers, then putting width:auto divs (not width:100%) with borders in the parent floats.
I know solution 4 sounds horrible, and means non-semantic markup, but it's a common kludge and one that other developers will probably understand (too) well.
This may sound horrible, but why not use a background image to create the border?
.box_20_percent {
width:20%;
float:left;
padding:0;
background-image:url([one_pixel_colored_image]);
background-repeat:repeat-y;
background-position:right
}
This should leave the "border" out of the resize calculation altogether.
If you declare the border-width and negative margin in ems instead of pixels, there is no wrapping/jumping. I realize this may be cold comfort since it would compromise your design somewhat, but it works!