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.
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
Is there a general best practice for the order of rules in CSS preprocessors like Stylus or SASS?
Is it better to first add the rules for the different types of the same element and then afterwards add the children of that element:
header
&.fooBar
float left
nav
background-color #fff
Or is it better to first add the children and afterwards add the parent's classes etc. like this:
header
nav
background-color #fff
&.fooBar
float left
No, there isn't general best practice for such a thing.
What's really important is to make up your mind and be consistent. Create coding guidelines in your company. Make a list of rules and stick to it, so everybody knows what to expect.
NOTE: the motivation behind this post is solely to understand CSS better. CSS remains mostly voodoo to me (despite hours and hours and hours of studying it), and I'm certainly not looking for any more voodoo (i.e. more "workarounds" or "hacks"). I'm looking for insight into CSS.
I have found two approaches for centering a div within its container. (Throughout this post I'll call the div to be centered #inner-div.)
The first approach is based on giving #inner-div the spec margin:0px auto;; the second one consists in giving #inner-div the spec display:inline-block.
AFAICT, the margin:0px auto approach also requires explicitly setting the width of the div, as illustrated in this jsFiddle; the key bit of CSS is
#inner-div {
margin:0px auto;
width:100px;
}
(To see what happens if the width specification above is omitted, see this jsFiddle.)
Similarly, AFAICT, the display:inline-block also requires 1) giving the spec text-align:centered to the element containing #inner-div, and 2) preventing the extraneous bottom-margin that the display:inline-block entails for #inner-div (this could be achieved, e.g., by giving the spec vertical-align:top to #inner-div and, AFAICT, any additional descendants with display:inline or display:inline-block). See this jsFiddle, in particular the following bits of CSS:
#outer-div {
text-align:center;
}
#inner-div {
display:inline-block;
vertical-align:top;
}
I find both approaches problematic. The second approach is clearly problematic, since the display:inline-block gives the affected div text-like semantics, resulting in unexpected behavior (like the seemingly gratuitous bottom margin mentioned above).
The first approach, on the other hand, requires the specification of #inner-div's width. This precludes the possibility of having this width specified implicitly by the widths of the contents of #inner-div. I don't like this: I often need to center divs whose width is difficult for me to determine, even at run-time (e.g. this width may depend on font-metrics, or the way the flow works itself out within #inner-div, etc.). After all, as the jsFiddle's given in this post show, the browser already computes the height of the #inner-div based on its contents (IOW, one doesn't have to explicitly specify #inner-div's height for the browser to do the right thing). Why can't the browser also compute #inner-div's width?
It seems to me that any reasonable layout system would allow one to say to the browser: "figure out the width of this div, based on the width of its contents, and center it within its container".
My question has two parts:
I'm looking for a well-informed confirmation that CSS really does not provide any way to direct the browser to compute the width of a div (based on its contents) and then center said div within its containing element; and
if the answer to the last question is "yes", is this so merely due to poor design on the part of the creators of CSS, or is there a good reason for CSS not to support this natural (to me at least) functionality?
Note: these are difficult questions; the second, in particular, requires not only a a command of the CSS standard, but also an understanding of the design of CSS itself: a pretty tall order!
Without a given width to work with, how would the browser know how to calculate the flow wrapping? It would be nice to tell the browser to 'make it look good', but they just aren't that smart. I feel your pain though; a fixed minimum width with a on-overflow-expand would make life easier.
How about setting the width as a percentage of the page width, or setting it dynamically with script?
I agree setting the div to a inline-block/table-cell/whatever introduces more trouble than it is worth.
BTW "margin: auto;" is enough, "margin:0px auto;" seems contradictory.
I have used CSS pseudo-element selectors like many others, mainly just to say I've used them.
But I am racking my brain and struggling to come up with a reason for their place alongside markup.
Take the following example:
<p>Hello</p>
p::after {
content: "*";
}
What is the advantage of using this over using <span> tags?
Am I missing the point of ::before and ::after? Is there some rock solid reason for using them over pre-existing semantic markup?
The CSS2.1 spec says this about generated content:
In some cases, authors may want user agents to render content that does not come from the document tree. One familiar example of this is a numbered list; the author does not want to list the numbers explicitly, he or she wants the user agent to generate them automatically. Similarly, authors may want the user agent to insert the word "Figure" before the caption of a figure, or "Chapter 7" before the seventh chapter title. For audio or braille in particular, user agents should be able to insert these strings.
Basically the purpose is to minimize pollution of the content structure by "content" that is otherwise more suited as presentational elements, or better to be automated.
If you're talking about :before and :after: They're used as presentational elements for cases where adding more elements into the actual document would be mixing structure with appearance. A few cases I've seen:
Bullets in bulleted lists
Quotes around q elements
Stylish shadows
Decorations and the beginning or end of text
These particular pseudo-elements are designed to add “content” that’s actually just a visual aid.
The prime example is adding quote marks around the <q> element, which Firefox does using these selectors in its default stylesheet. Some people also use them to clear floats.
You shouldn’t use them for actual content, despite the name of the CSS content property, as non-visual user-agents (i.e. screen readers) should ignore them.
I’ve never come up with much use for them, although I did once use them to add little Unicode icons to hovered links on a personal site — like you, pretty much just to say I’d used them.
Honestly, the only worthwhile useage is to force elements to have the correct size in the dom. Use this code for example:
<div class="container">
<div>this div is floated left</div>
<div>this div is floated left</div>
</div>
Typically you would have to specify an exact or min height for the .container div. if you were to apply ":after" with some very simple css, any background you applied to the .container would actually show up (in almost every browser) properly, with few to no shims.
.container:after{
content:'.';
height:0;
line-height:0;
display:block;
float:left;
visibility:hidden;
}
Now try that example, applying a background color or image, and you'll see that the .container div always has the appropriate height (which would be the total combined height of the inner contents) even if all the inner html is floated (as is the case in most ul/li css buttons).
I also use an after on every div that I wrap all my content in per html page. This is due to the possibility that all of the content on a given page could be floated, and I want to make sure that my content div always has the correct size/padding with the appropriate background.
CSS3 Pseudo Selectors also include essential ones like :link, :hover, :active, :focus, :first-child, :nth-child. It's impossible to make a useful site without most of these.
As for the less commonly used pseudo-selectors like :after and :before, they're useful in certain cases where the content is dynamically generated and you want to insert something before a specific element or tag.
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.