Is there an online CSS optimizer equivalent to Googles JavaScript Closure Optimizer.
I've found plenty of CSS compressors online, but I'm looking for a CSS optimizer ... where it actually removes redundant/conflicting attributes
Online tools based on csstidy: www.codebeautifier.com or www.cleancss.com.
And perhaps CSS Redundancy Checker might be useful for you. It's a Ruby script that will take CSS rules, and a set of HTML files, and will tell you what you aren’t actually using.
Personally, I wouldn't trust any CSS optimizer such as you describe. Any time I have ever tried one, and I've tried a few and even tried to write one, it has resulted in CSS problems on pages I've created.
For one to actually remove conflicting selectors, it would really have to understand how you would like such conflicts resolved — which ones are "right" and which are "wrong" — and that is something you have to eyeball to decide. Even removing "redundant" selectors is fraught with peril, unless you have repeated selectors verbatim. And any CSS hacks you have employed (not good practice, but sometimes unavoidable) can be destroyed.
I'm not saying this kind of thing is impossible, just that it's VERY hard to do and you should absolutely expect to regression-test all your pages after using one.
You could make such a service by using the relevant parts of an open source rendering engine such as WebKit or Gecko.
Infact....
CSSTIDY
never used it myself though
it is open sourced and provides you the ability to use it with php, it also uses no regular expresions so is compatible with css2
Check out Dust-me it's a firefox extension that will at least remove unused selectors. I suspect it might be a combination of these that'll get the job done.
https://csscompressor.net gives an audit of the changes it has made.
Be careful when using some hacks eg for IE6, as they may cause a failure
Related
Say there are selectors in a stylesheet that have no style info in them, so they are effectively empty (have no style declarations):
.main-menu {}
Will the browser still search for them?
My gut feeling is that it will depend on the browser, so an 'intelligent' programmer would say 'if selector empty don't bother' but not all browsers will have this kind of enlightened implementation. Had a quick search and couldn't find anything, was wondering if anyone on here knew anything regarding this...
Best practice i'm sure is to not have selectors with empty declarations, as they are a waste of space and time, does W3 say anything about this?
Thanks!
As a matter of fact, having empty CSS rules can actually serve to work around some bugs in certain browsers, and cause bugs in others. So there is evidence to suggest that, for at least two independent implementations anyway, the parser does not outright ignore CSS rules with empty declaration blocks.
As for best practice? Leave them out as all they would normally do is take up unnecessary bytes, and if you have a very good reason to use them, it's not a bad idea to add a comment explaining their purpose.
When users visit my website, they don't care about how perfect or how much standard the page is coded. They only care about whether it works or not.
There are tags that are deprecated but have consistent behavior throughout all major, minor, and very minor browsers. They work now and will work in the future. (I'm not talking about optional tags like <marquee> and <blink> which will probably be removed in the future since their non-existence doesn't break pages.) The tags I'm talking about are for example:
<center> (used by google.com homepage, yes and it's May 2014)
<body bgcolor=, alink=, vlink=, link= (all used by google.com)
<font size= (also used by google.com)
If my HTML generator produces tags like <body bgcolor=black>, it is guaranteed to work for near 100% of users.
If it instead produce CSS like background:black;, it will be supported by lesser users compared to <body bgcolor=black>. (Start with https://superuser.com/q/732669/78897 and https://superuser.com/q/447269/78897, though I'm sure they are not the only ones in the whole world.)
Bear with me, this is a real question based on a true problem. Exactly what are the real disadvantages of having these tags as output?
Potential disadvantages include the following:
1) Your customer might actually care about how standard the code is. Maybe not now, but in the future. Maybe for questionable reasons, but still.
2) Deprecated constructs do not always work consistently. For example, align=center attribute set on a table may have different effects depending on browser mode. This is a relatively weak argument, though, since the browser practices have been described rather well in HTML5 CR and you can manage the potential problems. (Besides, even CSS settings may work inconsistently.)
3) There is no guarantee that deprecated features will be supported by all future browsers. On the other hand, the same applies to standard features. In practice, very few features that have been defined in HTML specifications have actually been removed from browsers. (Regarding tags, I think basefont is the only case.) All the examples mentioned, and also marquee, have been described in HTML5 CR as “obsolete” but still well-defined, and according to HTML5 CR, browsers are expected, and partly required, to support them all.
4) Your colleagues (designers/developers/...) may regard your code (and you) as old-fashioned, non-semantic, and whatever.
5) Code maintenance and development may be more difficult. If you have 1,000 pages with <body bgcolor=black> and the customer says they want a somewhat different background color, you would need to edit each page. This argument is, however, weaker than it seems to be. First, how often do such things actually happen? Second, if the pages have actually been generated using suitable tools, perhaps you just need to change the value of one parameter and regenerate them (or just let servers do that, if the pages are dynamically generated). Third, if you have a link element on all pages, referring to basic style sheet for the pages, as you normally should, you just need to add one rule to that style sheet. It is easy to override presentational HTML attributes with CSS.
To summarize, the practical arguments against your approach are rather weak. The most important arguments relate to coding style and principles.
I've added some more disadvantages:
Another disadvantage of using those tags is site bandwidth. When you put in html center, bgcolor and similar tags every time browser needs to load the whole content even if on every page those tags are the same or even if user visited this site many times. But when you place design in css file browsers may cache those files (especially when you set headers properly) so they only load html and images (if no cache is set).
One another thing is that if you decide to redesign the site/style new elements, it's much easier to put changes only in CSS files. It's possible in future you won't be doing those changes on your own or other companies/freelancers will be doing them and it will be much easier for them to make changes in the site. So the site will be cheaper to maintain.
In addition if html / php code is poor (or site is very complex) and many "visual conditions" appear in many files (for example on one page you decide to use one colour and you put it in HTML, on the other another colour) and something goes wrong it will be much easier to find the problem because you may simple cut some css and check where's the problem.
The disadvantage is when one of the major browsers chooses to get rid of the deprecated tag in a future release.
The advantage of using CSS over tags is that you can change the whole web site look and feel in a simple move.
Consider people that require larger font sizes. Colour blindness and also enable the most use of screen readers.
Even those consistent behaviour tags may be removed from browser. What if you would like to create HTML5 website? Then you will need to learn everything from scratch and change literally everything for your website to make it work because you never know if those tags will be supported in HTML 5 in future or only in older HTML documents
CSS provides easier maintenance, for one; client decides they want some elements aligned left instead of center? Change your css rule and poof, you're done. But if you're using old-school valign and such? Get ready to go change every single instance of that in the file(s).
When it comes to my markup, I'm anal. It always has to be perfectly indented, easily readable to me, and 100% valid with the W3C. Often time, when viewing the markup of other websites, I'm appalled with the lack of effort by the developer to try to and keep their markup in the browser clean, organized, and valid.
On the flip side, there's a lot of people who will force all their markup on to one, continuous line for the size saving benefits. This annoys me as well, though not to the same extent because it is done with a purpose. But for the most part, it seems like no developer ever actually looks at their markup in the browser and does anything about it.
Understanding that, to the parser in the browser, indents and spaces (usually) don't matter, how should I be handling my markup? Is it worth the extra time to get my markup perfectly easily readable to humans as well as the browser? Are all my \t's and \n's being used in vain?
There are some browsers who has bugs that renders indented well formed html completely wrong. Such as some versions of Internet explorer with tables and images.
Other than that, i try to keep sane indention, I don't spend to much time with it, just enough to make it easy to debug.
Is it worth the extra time to get my markup perfectly easily readable
My answer is no. The arguments:
Whoever tries to look at the code probably will want modify it so, for editing the code you need good code editor with code formatting (e.g. Netbeans). You'll very soon need other features like, syntax coloring.
Some users might prefer other type of formatting than you.
Anyone interested in readable HTML may use Tidy (of Tidy extension to Firefox) to format it.
It's a performance issue too: additional overload of formatting + stripping whitespace (and minifying when possible) will speed up the site. It's very important for sites with high traffic.
It's worth the effort imho since it helps you understand what exactly is going on in your html page, and that's definitely worth something.
If we want to write clean, elegant code in general this means we should want to generate nice, clean elegant html as well, not?
Not sure if this answers your question, but as long as the code is valid by W3C, is structured as intended. As far as your view-ability of the code (like view source) structure, that's really up to you, but I would not add too much clutter (comments etc). Use the correct DOCTYPE for your markup and you should be fine with that. I don't see any reason to "waste" time on making the source code from the browser "book" readable. The view source would only be beneficial to you so you can quickly see what's happening at a glance through source view.
I like to correctly format my markup, and I think it makes it easier to manage when I do.
Then again, I use ASP.NET and a lot of markup is generated through various controls and classes. In this case, I've decided it is not worth trying to track down each mis-aligned markup and see if something can be done to get the associated control to produce the correct result.
In short, nicely formatted markup is worth it if it can be accomplished without a huge effort.
Yes, in my opinion it is worth. It will be easier to maintain, for you and for other collegues, now and in the future.
About the disadvantage of lower performance, why not to develop a well indented and commented source file and to generate a minimized version to run on the server? It can be acheived with a simple series of regex replacements.
So I've read this article and from what I understand, each native browser widget is actually a combination of basic elements, styling and scripts. This begs the question - if they are consisted of basic building blocks, does that mean that there is a way of customizing them through JavaScript? And I don't mean in the replacement sort of way, as some JavaScript libraries/plugins do - simply by accessing their "Shadow DOM" properties and adding some CSS styles to them, for example. Also, this page has some use cases, but nothing practical.
Anyone ever tried anything like this? Is it possible at all? Downsides?
Thanks.
My main concern would be that the implementations of the shadow DOM would be different between browsers and then you are basically back to needing some sort of library to deal with it. I'm not sure if that is the case, but its worth considering. Also, given that there are so many widget libraries available and that is the standard way of handling most of these issues, is it worth taking on a whole new set of unknown issues instead of just working with known elements?
The question covers most of it, but I'm trying to present a well articulated argument towards a senior developer who wants to abandon conditional stylesheets altogether (IE6, mobile, etc). Bear in mind we're not actually eliminating IE6, just the stylesheet.
Or am I being crazy and should just accept this?
What is the alternative? CSS hacks?
I have conditional stylesheets for IE7 and IE6. This compartmentalizes fixes for those specific browsers. When making changes, it easily lets you test/fix in standards browsers, test/fix in IE7, then test/fix in IE6. Testing flows more naturally. It doesn't break standards, it's easy, and it's basically free. It makes more sense to explain why you wouldn't use them.
You may want to look into the Yahoo Reset CSS Library. It has eliminated the need for conditional stylesheets on many of the projects I've done.
If you can meet your needs without conditional style sheets, then by all means it's a good idea to have a single style sheet for all browsers. However, if you cannot do this without losing functionality, then a pretty good argument would have to be presented to justify going to a single style sheet.
You shouldn't. With enough work, both of the popular browsers can be made to render a page the same way. Take mine for example - Complex yet simple at the same time.
[edit: changed 'never' to 'you shouldn't', having thought the title said 'when']
Because IE 6 and IE 7 are broken in various well known ways. Conditional Stylesheets that modularize the fixes are the easiest and supported way to deal with these breaks.
When you say your senior developer wants to "abandon" conditional stylesheets, what exactly does that mean?