I was looking for a grunt tool to parse my css and tell me when I can convert longhand css properties to shorthand. My way of thinking that this makes css smaller, easier to understand.
So basically if it will find
.mydiv{
background-color: #000;
background-image: url(images/bg.gif);
background-repeat: no-repeat;
background-position: top right;
font-style: italic;
font-weight: bold;
font-size: .8em;
line-height: 1.2;
font-family: Arial, sans-serif;
}
It would change it to:
.mydiv{
background: #000 url(images/bg.gif) no-repeat top right;
font: italic bold .8em/1.2 Arial, sans-serif;
}
To my surprise I was not able to find such plugin, but on the other side I found a lot of them which convert shorthand properties to longhand. This raised a question:
why do people want to convert their nice and clean shorthand equivalents to longhand? is there any valid reason except:
I like it to be longer
some really outdated browser like IE 7 screws up something. (by outdated I mean IE <=7, chrome, ff, safari 2 versions lower then current)
P.S. also I am not asking for a grunt plugin, if someone knows one, please let me know.
P.P.S I saw this question and the person is concerned with: performance and documentation. I do not care about these things because: people in my team can read and understand shorthand and prefer it, and I know that performancewise (for parsing rules) it makes really tiny difference (if any) and it is smaller in case of bandwidth.
What I am concerned is that may be I will get different representations in some browsers.
Sometimes is necessary, so you can exercise finer control over your styles so that you can create things outside the typical case.
Consider this example of long hand border syntax:
section{
max-width: 60em;
margin: 0 auto;
}
p {
border-color: black;
border-style: solid;
border-top-width: 1px;
border-left-width: 1px;
border-right-width: 1px;
}
This creates a very different border then usual. There is no way to accomplish is such a terse way with short hand alone.
Demo: http://codepen.io/agconti/pen/sixaL
Related
So I made a small change on the page (gesher-jds.org/giving):
Donate Now, Pay Later
to
Donate Now, Pay Later
and now the design of the right calculator has changed (more like the button as I see). How do I fix it? Both of them looked the same (besides the text). I tried to add the code below to the CSS but it still didn't work. What I'm doing wrong?
CSS
a#payLater {
background: #60426c;
width: 100%;
display: inline-block;
margin-top: 20px;
padding: 10px;
text-align: center;
color: #fff !important;
font-size: 20px;
text-transform: uppercase;
letter-spacing: 1px;
font-weight: bold;
text-decoration: none !important;
}
If you apply the styling in the dev tools it works like expected. The reason it does not work in your working environment is probably because your styles are overwritten by different styles. Check the dev tools to see which styles are applied
Potential fixes:
1) Tidy up the "!important" rules.
2) Build stronger selectors -> keyword to look for knowledge [CSS Specificity]
If you set !important in one CSS rule, it'll become hard to overwrite that because !important = 1000 Specificity points so the rule is really strong
I have a site which uses CSS to create drop caps at the start of articles. This works as expected in most browsers, but Firefox (Linux and Android) displays it incorrectly, but only in certain instances.
On most pages, I get correct output, like this (the blue dashed lines at the side are the edges of the container, shown for illustrative purposes):
However, for a handful of pages, Firefox renders it thus:
Notice that there's a large gap to the right of the drop cap, and the text overflows the box by a corresponding amount.
Here's the relevant SASS:
article .first-paragraph {
text-indent: 0;
&::first-letter {
font-size: 300%;
font-weight:normal;
display: block;
float: left;
margin-right: 0.25em;
padding: 0.5em 0.3em 0.3em 0.5em;
background: $primary-color;
color: $background-color;
border-radius: 50em 5em 5em 5em;
font-family: 'Fredericka the Great', $base-font-family;
}
&::first-line {
font-variant: small-caps;
}
}
I have been unable to discover any difference which can account for this behavior. The articles are written in Kramdown-flavored Markdown and processed by Jekyll. The two articles are absolutely identical in Markdown except for the words themselves. And yet, the bug always happens on the same pages. I've tried setting the first few characters to be the same, but to no avail. I've also made the previous content follow the same structure, where there were differences in structure, but it didn't change anything.
Any ideas what might be wrong, or what I may have forgotten to test?
EDIT
I've narrowed the offending CSS down to the following rules:
article .first-paragraph::first-letter {
display: block;
float: left;
margin-right: 0.25em;
padding: 0.5em 0.3em 0.3em 0.5em;
}
If I turn them all off, the problem goes away. If I turn any one of them on, or any combination, the problem is back, except that display: block causes no issues on its own.
If you want to test it further, here's an example page with the bug (at least until I manage to fix it.
The more I think about it, the more I think that there must be something else on the affected pages beyond what I've posted here, which is causing the issue on Firefox on Linux, Windows, and Android. But for the life of me, I can't figure out what that something else is.
When using a <h1> tag for example, is there a reusable formula for getting the outer border of that element to PERFECTLY follow edges of the type? In theory I would expect this to work:
h1{
display: block;
font-family: sans-serif;
font-size: 38px;
line-height: 100%;
height: 38px;
}
So the line height is set to be the same as the absolute text height, which is also the height of the block. However this never works. Here is an example of what does work for sans-serif 38px;
h1{
display: block;
font-family: sans-serif;
font-size: 38px;
line-height: 28px;
height: 35px;
}
Here is another working example.
h1{
display: block;
font-family: sans-serif;
font-size: 25px;
line-height: 19px;
height: 22px;
}
This is all well and good, but it has to be calculated manually in firebug each time. There is no formula I can find to do this.
Additionally, it would be nice if any solution also worked with #font-face fonts, but I understand there is more to take into account there. (like the top alignment that only occurs on Mac).
Does such a formula exist? Is it possible to write one? How about some LESS CSS fancyness?
I agree with #ToddBFisher in the comment, and at this point for me it's more of an usability issue. Consider people can also vary the font sizes in their browsers... in that case using ems would be better. But browsers also render font differently, so something that looks amazing in a mac will look pixelated in a pc. If you want something to look perfect, use images.
Check this other question for more info on line-height: How to achieve proper CSS line-height consistency
Or this one: CSS Line-Height Guide
You can also check the usability stack for discussions about these things: https://ux.stackexchange.com/ There are pretty amazing posts in there.
I have noticed that when I look at a rule I have written say for example:
label {
font-size: 12px;
position: absolute;
padding: 9px;
color: #666;
}
In firebug, it translates as:
label {
color: #666;
font-size: 12px;
padding: 9px;
position: absolute;
}
Basically, reordering the styles. Why?
Is there an 'ultimate' priority I could be putting in my styles to improve load speeds? Ie is there a load order I'm unaware of?
The order of styles in your rule does not matter. Firebug seems to sort alphabetically in your case (it may be incidental).
Of course the order will do play role in this, problematic, case:
.foo {
background: url(foo.png) top left repeat-x;
background-image: url(bar.png);
}
Yes the order matters:
label {
font-size: 12px;
position: absolute;
padding: 9px;
color: #666;
font-size: 15px;
}
The font-size (15px) will overrule the 12px
In general: Yes, order does matter in terms of what properties will actually be set.
You can Google for many links on CSS precedence, for example:
http://www.vanseodesign.com/css/css-specificity-inheritance-cascaade/
But as far as what you see in the debugger - that's not at all significant for how the CSS will actually be rendered. The order of "color", "font-size", "padding" and "position" in this particular class are simply an artifact of Firebug.
Well, as the others stated before, the order is important in letting the browser choose, which rule to use, but in order of performance I haven't heard of something like this. As CSS is just a text file the downloading speed will not be affected. BUt I don't think anyone has examined this topic with some test cases.
When I declare this style for a div:
#fbInner{
position: absolute;
margin: 11.2% 9.7% 0% 26.4%;
width: 63.5%;
height: 54.6%;
overflow: visible;
/*max-height: 190px;
max-width: 490px;*/
font-size: 11px;
font-family: "lucida grande",tahoma,verdana,arial,sans-serif;
color: #FFF;
/*border: solid 2px gray;*/
}
Chrome sets every margin right except of the margin top, which is set much smaller than in other browsers ... strange, all other margins are displayed like it should ...
What is the reason for that?
Is there a workaround that still uses percentages?
Seeing as this is an x-browser css question, resetting the css styles would be a valuable first step - maybe even the solution. You haven't disclosed any HTML code, so I can't know what other tags or styles are affecting #fbInner
In any case, here is the "meyerweb reset" stylesheet: http://meyerweb.com/eric/tools/css/reset/
Link it topmost in your HTML file. It will probably break your site, but that's a good thing. At least it should be equally broken in all browsers now. When you've fixed the look of your page, it should work properly in most/all browsers.