Can a CSS selector address line heights? - css

I want to make a CSS stylesheet that allows completely inexperienced users (using WYSIWYG editors) to have PDF icons next to PDF links. However, this can lead to unwanted stretching of the image with different font sizes. Is there any way I can tell what font size the user has applied to these anchors to then apply the correct icon?
I'm hoping for something as simple as this:
:link[href$=".pdf"]::after,
:visited[href$=".pdf"]::after{
background-size: 1em !important;
background-repeat: no-repeat !important;
background-position: 100% 50% !important;
color:inherit !important;
content:" " !important;
padding-right:1.5em !important;
text-decoration:inherit !important;
}
:link[href$=".pdf"]::after,
:visited[href$=".pdf"]::after{
background-image:url('/images/MIME_PDF_16px.png');
}
:link[href$=".pdf"][style.line-height>16px]::after,
:visited[href$=".pdf"][style.line-height>16px]::after{
background-image:url('/images/MIME_PDF_32px.png');
}
:link[href$=".pdf"][style.line-height>32px]::after,
:visited[href$=".pdf"][style.line-height>32px]::after{
background-image:url('/images/MIME_PDF_48px.png');
}
:link[href$=".pdf"][style.line-height>48px]::after,
:visited[href$=".pdf"][style.line-height>48px]::after{
background-image:url('/images/MIME_PDF_64px.png');
}
:link[href$=".pdf"][style.line-height>64px]::after,
:visited[href$=".pdf"][style.line-height>64px]::after{
background-image:url('/images/MIME_PDF_128px.png');
}
Alternatively, something like this would be nice:
:link[href$=".pdf"]::after,
:visited[href$=".pdf"]::after{
background-size: 1em !important;
background-repeat: no-repeat !important;
background-position: 100% 50% !important;
color:inherit !important;
content:" " !important;
padding-right:1.5em !important;
text-decoration:inherit !important;
}
:link[href$=".pdf"]::after,
:visited[href$=".pdf"]::after{
background-image:16px 16px url('/images/MIME_PDF_16px.png'),
32px 32px url('/images/MIME_PDF_32px.png'),
48px 48px url('/images/MIME_PDF_48px.png'),
64px 64px url('/images/MIME_PDF_64px.png'),
url('/images/MIME_PDF_128px.png');
}
If no such selector or value exists, then should I propose it to the W3C? Would this go against the philosophy of CSS?

The problem with a selector that selects by a style property, it is often said, is that it can lead to infinite loops. For example, a selector with a property that attempts to set that same property to another value and back:
[display=block] { display: none; }
[display=none] { display: block; }
It's been proposed several times, I think, and met with rejection. There are of course several counter-arguments and points, such as forbidding the same property from being set in the rule at all, etc, but those are outside the scope of your question so I shan't elaborate. If you search the mailing list archives, you should be able to find numerous discussions on this matter.
FWIW, Image Values level 4 actually makes mention of an image-set() function that allows you to specify different images for different resolutions, and I believe some semblance of an implementation can be found in WebKit browsers (naturally, as -webkit-image-set()). However, I don't think it's designed to scale with font sizes per se; it's meant for scaling with resolution from what I can see, which may or may not be a different issue.
I suppose the safest bet here is to use a vector image format, like SVG, that scales down gracefully yet retains its integrity in large sizes. That way, the image worries about scaling itself so you don't have to. Judging from your code, I gather that browser support won't be much of a concern: IE9 supports SVG images just as well as the rest of your CSS code.
Oh and, since we're talking about selectors here, :link and :visited will only ever be satisfied by a[href] in HTML. You can make your selectors less redundant by removing those pseudo-classes altogether if you don't need the pseudo-class specificity, since you already have the appropriate href attribute selector. So instead of this:
:link[href$=".pdf"]::after, :visited[href$=".pdf"]::after
You can simply do this:
a[href$=".pdf"]::after
Or even this:
[href$=".pdf"]::after

Related

Questionning a technique for preloading images (typically used as background images for hover state)

This technique for preloading several images entails the following CSS:
#preload_area {
background-image: url(someimage.jpg);
background-image: url(someimage2.jpg);
width: 0px;
height: 0px;
display: inline;
}
However, will someimage.jpg actually be loaded? I would have thought it would simply be ignored hence not loaded after being overriden by the rule with someimage2.jpg in the next line.
You are right, the first background-image would be ignored. However, you can use something similar since CSS3 supports multiple backgrounds:
background-image: url(someimage.jpg), url(someimage2.jpg);
Supported by every broswer since IE8 – http://caniuse.com/#feat=multibackgrounds

CSS - Text link larger than buttons

I have a style for inputs on my page, with some basic padding and font size, I tried applying the same style to a link, but for some reason the link is always larger (height) than the button no matter what I do, even with the exact same text and font size, I tried doing display: block but that just makes the button the width of the screen.
Here is the CSS:
.button{
padding: 10px 15px 7px 15px!important;
font-size: 16px !important;
color: white;
cursor: pointer;
border-radius: 2px;
text-decoration: none;
}
.button-3{
background-color: #ff4d4d;
border: 1px solid #ff4d4d !important;
}
I've looked at the Chrome styles panel and confirmed the font / padding is being used (it's not strikken through).
Here is what it looks like:
Looks like the issue is because:
You aren't using a CSS reset.
The line-height needs to be the same.
Make sure you give a consistent line-height to both. For now, set in the both:
line-height: 1.5;
This should fix it. Also, you can compare both the styles with the computed ones, to check if there's anything else being set. Since you say <button>, it might also have some border.
Also, like I guessed, you are also giving border and same colour as background to the button, making it look 2px bigger.
When you open the Developer Tools, try comparing the Computed Styles part:
To avoid this kind of stuff I always set the font family I used.
Take a look at this example: https://fiddle.jshell.net/tnr0jxka/
You also might want to consider adding:-webkit-apperance:none;-moz-apperance:none; to this kind of css, it will save you big time in cross-browser experience.
Buttons do not inherit the global styling automatically.
So, setting font-size of button explicitly will solve the problem
see this solution for more info

Strange behaviour of tileable background beneath div

I have a tileable wood pattern as background in an html page. The background looks perfectly seamless when viewed in Photoshop or any other software, but on the html page it looks discontinuous at the points where my main div element begins and ends.
Here's a preview: http://i.imgur.com/eTQthA2.png
This anomaly persists across different browsers. (I have tested in latest versions of Firefox, Chrome and IE.) What could be the reason behind this?
Let me know if you want to look at a specific part of the code.
Edit:
Solved the problem. When asked to post the CSS I noticed that I used the selectors body, html to apply the background-image. Removing html from the selector did the bit.
CSS:
body, html {
margin: 0;
padding: 0;
font-size: 13px;
font-family: 'Open Sans', sans-serif;
color: #455d76;
background-image: url("images/bg.png");
background-repeat: repeat-x repeat-y;
text-shadow: 0 1px rgba(255, 255, 255, 0.8);
}
First of all whenever asking a question, you should post your code here and not give link to a preview image or your website, because it makes us tough to solve your question.
Coming to your question, from the image it looks like you are using background-image property for different element like say for example div for header, main, and footer, so instead declare that property for body tag instead, in your CSS
body {
background-image: url('whatever.png');
background-repeat: repeat;
}
Fixed the issue. I had used 'body, html' as selector while specifying the background property. Removing 'html' from the selector (ie, leaving just body) did the bit.
(Thanks Mr. Alien, you were right about the background-image property being declared for different elements, ie, body and html in this case.)
Thanks to everyone who answered/commented. :)

Load sections of a css file depending on the browser

There are buttons on my website that look overly skinny in Chrome compared to Firefox. The button's HTML looks like: <button name="shutdown" type="submit" value="df" class="boton"> Press </button>
My CSS attempt looks like:
.boton {
font-size: 17px;
color: #000;
background: #ee3333;
background: rgba(225, 50, 50, 0.6) !important;
font-family: lucida console;
border: 1px solid #FF4444;
padding: 2px;
-moz-border-radius: 7px;
border-radius: 7px;
cursor:pointer;
}
.chrome .boton
{
padding: 5px !important;
}
I'm not sure if I'm doing this right. ".boton" does indeed change the style of the button, but the padding doesn't change in Chrome. What's wrong here?
The reason that the padding isn't applying to the element is due to the fact that there is no chrome class assigned to any element. There are various hacks around certain Vendor-Specific styles, see this article, but no browser applies a class of .chrome or .moz or anything like that.
However, to achieve more "horizontal" padding, you can use the -webkit-padding-start(padding-left) and the -webkit-padding-end(padding-right). Currently I do not believe there is full padding, or vertical padding for these yet. Be sure when using these to write the -webkit-padding-start, or whichever rule you use, after your padding rule. Otherwise the latter will overwrite the former and both will be lost.
Unless you've also added some browser sniffing that adds the class .chrome etc. to the body that class has no effect.
On the other hand the box model of Firefox and Chrome is not radically different, but the defaults for padding, border, margins etc. may be different. Just explicitly set those values and they should most likely render the same (give or take a few pixels because of different rounding errors). You should not need to add custom css for each browser (but if you use experimental css features like -moz-border-radius and -webkit-border-radius with vendor prefixes you should use all of them in at the same time; the others will ignore the unknown properties).
The different versions of IE (Internet Explorer) do have a radically different box models, and if you cannot get some version of IE to render something correctly with the standard css you should use conditional comments to include IE specific css overrides after the main css file.

Which of these CSS selectors "cancel" each other out?

I found a neat example of Showing Hyperlink Cues with CSS. But in the CSS of the example, there are three separate styles that in my head should do mostly the same thing. Or at least, I should not have to use all of them in my opinion. But I'm not sure I get them all. Here they are:
/* all A tags whose REL attribute equals pdf */
a[rel='pdf'] {
padding-right: 18px;
background: transparent url(icon_pdf.gif) no-repeat center right;
}
/* all A tags whose REL attributes has the letters pdf somewhere mixed in*/
a[rel*='pdf'] {
padding-right: 18px;
background: transparent url(icon_pdf.gif) no-repeat center right;
}
/* all A tags whose REL attribute contains the value pdf, seperated from other values with a space */
a[rel~='pdf'] {
padding-right: 18px;
background: transparent url(icon_pdf.gif) no-repeat center right;
}
I'm thinking I can possible replace the first two with the last one, but again, I'm not 100% sure I understand how these works. Anyone care to shed some light on this?
My question is concretely this: Can I skip one or two of these and still get the same result on all my links?
At a first glance, the second one should also cover the first and third. But the problem is that there might be a browser that doesn't support the second version and thus needs the first one.
But why would you want these three? If the first should work, then stick with that one. If that one isn't supported, the others won't be supported for sure.
I would almost make Venn diagrams of it...
All rel='pdf' are overruled by rel~='pdf'
All rel~='pdf' are overruled by rel*='pdf'
For example:
[rel*='pdf'] will style rel="pdfdoc", while [rel~='pdf'] and [rel*='pdf']
will not
Both [rel*='pdf'] and [rel~='pdf'] will style rel="pdf doc", while [rel='pdf']
will not
All selectors will style rel="pdf"
Not all browsers can handle these CSS3 selectors, I think that's why rel='pdf' was added. You could remove rel*='pdf' if you don't want to style links that contain pdf in the rel attribute.
This one covers all use cases:
/* all A tags whose REL attributes has the letters pdf somewhere mixed in*/
a[rel*='pdf'] {
padding-right: 18px;
background: transparent url(icon_pdf.gif) no-repeat center right;
}
Since it matches pdf anywhere in the text.

Resources