I am lookg for a tool, plugin that is able to check on my web-deployment if in the css stylesheets is any class that is never used.
Everything I found was just interpreting the current displayed site, which therefor is still much work to check everything..
Dust-Me Selectors
Dust-Me Selectors is a Firefox extension (for v1.5 or later) that finds unused CSS selectors.
http://www.sitepoint.com/dustmeselectors/dustmeselectors-2.2.zip
"It extracts all the selectors from all the stylesheets on the page you're viewing, then analyzes that page to see which of those selectors are not used. The data is then stored so that when testing subsequent pages, selectors can be crossed off the list as they're encountered."
Related
I'm using XHTML (strict) to create a webpage - I cannot use HTML5 yet. When I run my CSS code through CSS Lint, I get the warning "Don't use IDs in selectors" several times.
I'm not sure why I'm getting these warnings. Should I be exclusively using classes instead of id's? I appreciate HTML 5 has the option to use semantic tags, but for now I need to stick with XHTML. Can anyone help?
You're perfectly fine to use IDs instead of classes. A lot of HTML validators would tell you otherwise, because they're written by people who don't like it.
It's entirely a style preference, and stating is as a rule is nonsense. Using IDs to style your HTML is perfectly valid CSS.
For more on this, see CSS Lint Is Harmful.
Using ID's have a very strict specificity issue. Realistically, according to the standards, you can only use an ID once in any given HTML document. That doesn't mean you can't use ID's as styling selectors, though, it does come with dangerous pitfalls in larger projects. They're fine if you're using them as targets in Javascript. Go crazy.
CSS Lint is basically telling you that ID selectors are very, very specific in targeting elements and in return, you end up with problems later down the line dealing with CSS specificity. Class selectors are reusable and have much looser specificity. CSS Lint may be harmful, but in the eyes of many professional developers, styling with ID's doesn't have anything different that a class selector doesn't have, so why use them if they're causing specificity issues? Read this and this. They are both fantastic articles on why ID's are not cool for CSS. It is a personal preference, but, making your CSS very specific is a front-end disaster in all real-world cases web development.
For refactoring purposes, I am trying to find all unused css style definitions on my website. After googling a while I found various tools like Google Chrome's Audit feature or the Firefox add-on called "dust-me selectors": How can I find unused images and CSS styles in a website?
For me these tools don't work because:
While running, they will only trigger Chrome or Firefox specific css, which means other code like e.g. styles for IE-specific stuff which is included via IE conditional comments, will be marked as being unused although that's not true.
These tools will only work for the page that I am currently looking at. So if I have 1 big css file for all my pages, these tools will mark a decent amount of styles as being unused for the one page I am looking at although they could be required on other pages because switching pages will make these tools "forget" they last state.
Are there any free tools out there that let me find unused css styles taking cross-browsers and multiple pages into consideration?
Just use below link to search unused css Remove Unused CSS
I can style visited links with a:visited. I want to the same for links to pages I have in my browser favorites.
I wonder if Firefox has a pseudo-class for that.
Then I could style them with the addon "Stylish".
There's a good reason this doesn't exist: It can be used in conjunction with getComputedStyle to invade your privacy (using javascript to report what you may have bookmarked).
This was also a problem with the :visited selector and Mozilla rectified it:
http://hacks.mozilla.org/2010/03/privacy-related-changes-coming-to-css-vistited/
I suppose they could do the same for :bookmarked or something, but as of now this doesn't exist.
I wonder if Firefox has a pseudo-class for that.
I could not find anything in this list of Mozilla-specific CSS extensions that does what you want, so most likely there isn't such a pseudo-class.
There is definitely no such pseudo-class in standard CSS, though, but I think you already know that since you're asking specifically about a Firefox extension.
I have two issues I have ignored so far, but I will really appreciate some light shed onto them.
First: how can I solve differences between Safari, Chrome and Firefox and the various tags that their engines render differently? Should I just write down the right attribute for each in the same css rule? Is there no better way?
Is there a way to separate the CSS sheets for these browsers as I am doing for IE? Is this recommended?
Second: What about CSS3 attributes? Should I just write them again in the same rule after the CSS2 attributes?
Will this cause problems validating the CSS with WC3?
Welcome :)
If you start without the prefixes, you should write the code, generally, with all the semantically appropriate tags, first.
Then, you can decide what your goals are.
If you want W3C compliant CSS files, then you'd need to strip out the vendor specific prefixes by default. This would then allow the latest browsers to pick up the standardised CSS properties if they support them.
This will target less of your market than you might wish, so then you should ask if progressive enhancement is a possibility. If you can reasonably enhance the visuals by using css applied after the page has loaded, such as applying styles with jQuery, MooTools or Prototype libraries AND these libraries are already serving a purpose in your website, then you could apply additional styles with those libraries (and possibly use them in conjunction with Modernizr to determine which elements you may want to additionally support.
However, it's likely that a browser will skip a property it doesn't understand and will render the ones that it does, so I'd suggest that if you code it to W3C Standards first and then add in your additional vendor prefixes 'before' the final (correct) one, then you'll likely have satisfied reasonable measures to be compliant and meet design needs.
Edit:
There is a little bit of confusion between validation results from:
http://validator.w3.org/
and writing valid code related to vendor prefixes to get CSS effects cross-browser:
List of CSS vendor prefixes?
for working on some cross-browser CSS, you might find http://csspie.com, for IE compatibility with some CSS3 properties, useful along with http://www.colorzilla.com/gradient-editor/ for cross-browser gradients and http://cssplease.com for code that gives you alternative vendor prefixes, including different versions of IE support for many different properties.
In terms of validation, here's what W3C says about it: (see comments here: W3 VALID cross browser css gradient,) and official docs here: http://www.w3.org/TR/css3-syntax/#vendor-specific
If you code according to the specifications first and test your code out against that and then add in your vendor prefixes to get the same effects on the browsers you want to support (see progressive enhancement: What is Progressive Enhancement?) then you can be more confident that your code is supporting the appropriate standards, adding value to those with more advanced browsers and still useful for those without additional features (see also WAI III compliance, 508 compliance and others if you want to write a more inclusive site).
Caveat: Web Apps may not always be inclusive or follow these guidelines depending on who the audience is.
If you are using jquery on the site you may want to look into PrefixFree. It's a script that adds the vendor prefixes for you, so for example your put border-radius:6px; in yor css and it reads the browser and adds the appropriate vendor prefix for you via js. I like it cause it keeps my css docs more readable.
This question already has answers here:
Detecting IE version using CSS Capability/Feature Detection
(18 answers)
Closed 5 months ago.
So in my interweb travels of evaluating other programmer's CSS I've noticed a bunch of people using the underscore or asterisk hack that is vendor specific to IE browsers for debugging purposes though W3C does not parse this as valid CSS.
I personally prefer comment conditionals where you can at least defer to IE specific CSS that is valid but I guess the only issue with that would be addition of extra CSS.
So I'm curious about a consensus of what you prefer and the positive or negative implications of each method.
Comment conditonals or IE vendor specific hacks?
PS - Honestly this should be titled do you support IE layout or not :-)
Conditional style sheets are the way to go. The word hack itself implies that you're doing something that you shouldn't. But a few short words on both:
Conditional style sheets
(+) Cleaner CSS code
(+) Easier to manage
(+)Easiey to understand for other developers
(+) CSS validates
(-)More CSS files (thus more server load)
Hacks
(+) Faster (possibly)
(-) Messes up your CSS
(-) CSS doesn't validate
(-) Very unclear for other developers (especially non-experienced one's)
(-) Could cause problems with newer versions of IE
I prefer the conditional comments, because it makes your page still validate. I could imagine, however, that you use the vendor hacks, because you won't need an extra css file, saving a request per page loaded (if not for caching, of course). Then again, the css files are cached, and if you use your conditionals wisely, you can make a separate file per IE version, copying hacks if they are needed for more than one version. That way, you need at most one extra css per page, which is then cached as well, thus minimizing the extra load.