I know there are several questions concerning unused CSS already, e.g.
How can I find unused images and CSS styles in a website?
or
how can i find unused css in ajax app?
As I understand from these questions and the answers given there it is currently not possible to automatically check for unused CSS for a complete webapp. The problem seems to be that it is nearly impossible to get all HTML that could ever be generated, even if you have access to the source code.
Also note that in my case I want to verify that some CSS is not used rather than finding it in the first place.
Still I guess removing unused CSS is a common task. So how is it done in real-life? I actually have to do this for a larger project. My current plan is to remove some CSS, test it manually and then wait for bug reports. I really hope there is a better way.
Edit: I just realized that this question is not really CSS specific. So when I broadened my search I found What is the best way to remove dead code from your application?. The answer given there mainly says it "is only possible with a really extensive set of tests" (which is not an option for me).
There is no exact solution, but a good workaround I found on css wizardry:
Add something like this to your css:
#suspicious_selector {
background-image: url('/assets/img/dead/suspicious_selector.gif');
}
After some time check for requests to that file. If there were no requests, it is mostly safe to remove the selector.
I need to implement a flexible styling system for web pages that are created by users of my web application.
Ideally I would like to allow them to use CSS. Is linking to a style sheet at a user defined url a Bad Idea? Why? Is it possible to do this safely?
What would your approach to this be? I am trying to avoid building a style 'editor'. Though using an off the shelf one might be an option, suggestions?
Is it possible to do this safely?
Depends on how you define "safely". An external style sheet could make things look ugly, or play shenanigans with existing control elements on the site. You won't be able to prevent that as it's going to be impossible to detect. Here is a nice overview of malicious things one can do that way.
Also, obviously, CSS can trigger requests to any kind of URL by setting a background-image or similar. The browser will notice if the URL is not a valid image resource but the request will always happen. This way, one could provoke a password prompt to come up that the site's user may mistake for his own login prompt.
I'm not aware of any scripting attack vectors through CSS, although I'm pretty sure that IE's behavior could be one. I would definitely strip out those.
There is a related question on Stack Overflow but none of the vulnerabilities pointed out in the accepted answer works with pure external style sheets.
Yes. It can be a vector. This bit livejournal.
LiveJournal contains a flaw that allows a remote cross site scripting attack. This flaw exists because the application does not validate CSS style attributes in the '/cgi-bin/cleanhtml.pl' script before being saved. This could allow a user to create a specially crafted URL that would execute arbitrary code in a user's browser within the trust relationship between the browser and the server, leading to a loss of integrity. Read more at osvdb.org/21896
Caja's Attack Vectors Wiki explains how expression and moz-binding and similar mechanisms can allow arbitrary code execution.
Effect
Crafted CSS stylesheets can execute unsanitized javascript in the global scope on some browsers.
...
Versions
IE 5 and later (but not IE 8 or later in "standards mode").
Mozilla/Firefox, versions not known.
Example
<div id='oDiv' style='left:expression(alert("hello"), 0)'>
Example DIV
</div>
node.style.cssText = 'left:expression(alert("hello"), 0)';
<input style='-moz-binding: url("http://www.mozilla.org/xbl/htmlBindings.xml#checkbox");'>
div {
-moz-binding: url(data:text/xml;charset=utf-8,%3C%3Fxml%20version%3D%221.0%22%3F%3E%0A%3Cbindings%20id%3D%22xbltestBindings%22%20xmlns%3D%22http%3A//www.mozilla.org/xbl%22%3E%0A%20%20%3Cbinding%20id%3D%22xbltest%22%3E%3Ccontent%3EPASS%3C/content%3E%3C/binding%3E%0A%3C/bindings%3E%0A);
}
node.style.MozBinding = 'url("http://www.mozilla.org/xbl/htmlBindings.xml#checkbox")';
<ul>
<li style="behavior:url(a1.htc) url(a2.htc)">List Item</li>
</ul>
Is it possible to do this safely?
Yes. You can white-list CSS properties and strip out any you don't judge to be safe.
Caja defines white-lists in JSON format that allow a large subset of CSS to be used while banning those that might execute code.
I just worked out, by trial-and-error, that IE 7 has an upper limit of 32 stylesheet includes (i.e. tags).
I'm working on the front-end of a very large website, in which we wish to break our CSS into as many separate files as we wish, since this makes developing and debugging much easier.
Performance isn't a concern, as we do compress all these files into a single package prior to deployment.
The problem is on the development side. How can we work with more than 32 stylesheets if IE 7 has an upper limit of 32?
Is there any means of hacking around this?
I'm trying to come up with solutions, but it seems that even if I loaded the stylesheets via Ajax, I'd still be writing out tags, which would still count towards the 32-stylesheet limit.
Is this the case? Am I stuck with the 32-file limit or is there a way around it?
NOTE: I'm asking for a client-side solution to this. Obviousy a server-side solution isn't necessary as we already have a compression system in place. I just don't want to have to do a re-compress every time I make one little CSS change that I want to test.
Don't support IE7.
To avoid confusion: I'm not seriously suggesting this as a real solution.
Create CSS files on the server side and merge all files that are needed for this certain page.
If you are using Apache or Lighttp consider using mod_concat
Write your stylesheet into an existing style block with JavaScript using the cssText property, like this:
document.styleSheets[0].cssText += ourCss;
More info here:
https://bushrobot.blogspot.com/2012/06/getting-around-31-stylesheet-limit-in.html
At my last company we solved this by mashing all the CSS into one big document and inserting a URL in the web page that referenced that one-shot document. This was all done on-the-fly, just before returning the page to the client (we had a bunch of stuff going on behind the scenes that generated dynamic CSS).
You might be able to get your web server to do something similar, depending on your setup, otherwise it sounds like you're stuck with only 32 files.
Or you could just not support IE7 ;)
What is the benefit of writing meaningful css .class and #id names? Do screen readers speak to help the user understand the meaning and purpose of content inside the tags?
Generally-speaking, it's beneficial for the developer/designer only.
Again, as all your recent questions on semantics, the answer stays the same:
It all depends on the data-context of the entity in question.
If your element holds a meaningful field, it is useful to assign it a class (even if you do not want to apply CSS to it) just to easily define that particular field:
<span class="username">Andrew Moore</span>
Doing so has the following advantages:
It easily identifies the field's content in your code.
It increases maintainability.
It helps parsers and third-party applications to fetch this field's value.
Microformats are just a larger example of this. Simply put, they are a set of pre-defined elements and attributes that hold a particular set of data, meant to ease parsing by third-party tools.
Other answers are good, but I will focus on the scraping/third party tools aspect here.
Case 1 is spiders and crawling like search engines. If they parse your page and see something like id="username", they will be more likely to figure out some meaning in that than id="div-style-32". Granted, I'm not sure Google is doing this sort of thing now, but it could be if more people were better about it.
Case 2 is people writing scripts to pull down the HTML and process it in order to extract its content as data. Pretty much anyone who wants to do this can with any markup, its just a matter of how annoying it is. Cleaner and more well described markup allows the scraper script to more easily find the information it needs due to it's increased semantics.
This also includes things like browser extensions or Greasemonkey scripts that allow users to alter the behavior of the site. It will be easier to create these modifications with cleaner markup.
But if you don't want people scraping or modifying your site with client side extension, there is little you can do about from a technical standpoint. You can't stop it, you can only make it more of a pain in the ass. And the benefits of maintainability for the site developers are huge. So really, why not?
In short it makes all the different things you or others could do with your site easier to do.
You don't do it for the machines but for the humans.
If we only cared about machines we'd still be coding in assembly :)
Developing websites are time-consuming. To improve productivity, I would code a prototype to show to our clients. I don't worry about making the prototype comform to the standard. Most of the time, our clients would approve the prototype and give an unreasonable deadline. I usually end up using the prototype in production (hey, the prototype works. No need to make my job harder.)
I could refactor the code to output valid HTML. But is it worth the effort to output valid HTML?
It is only worth the effort if it gives you a practical benefit. Sticking to standards might make it easier to build a website that works across most browsers. Then again, if you're happy with how a website displays on the browsers you care about (maybe one, maybe all), then going through hoops to make it pass validation is a waste of time.
Also, the difference in SEO between an all-valid html website and a mostly-valid html website is negligible.
So always look for the practical benefit, there are some in some situations, but don't do it just for the sake of it.
Yes. It's hard enough trying to deal with how different browsers will render valid HTML, never mind trying to predict what they'll do with invalid code. Same goes for search engines - enough problems in the HTML may lead to the site not being indexed properly or at all.
I guess the real answer is "it depends on what is invalid about the HTML". If the invalid parts relate to accessibility issues, you might even find your customer has legal problems if they use the site on a commercial basis.
Probably not if you have a non-complying site to begin with and are short on time.
However, and you won't believe me because I didn't believe others to begin with, but it is easier to make a site compliant from the start - it saves you headaches in terms of browser compatibility, CSS behaviour and even JavaScript behavior and it is typically less markup to maintain.
Site compliance (at least to Transitional) is pretty easy.
Producing compliant HTML is similar to ensuring that you have no warnings during a compilation - the warnings are there for a reason, you may not realise what that reason is, but ignore the warnings and, before you know where you are, there as so many, you can't spot the one that's relevant to the problem that you're trying to fix.
If you use Firefox to view your web pages, you'll get a helpful green tick or red cross in the bottom right hand corner, quickly showin you whether you've complied or not. Clicking on a red cross will show you all of the places where you goofed.
Some of the warnings/errors may seem a bit pedantic, but fix them and you'll benefit in many ways.
Your page is much more likely to work with a wider range of browsers.
Accessibility compliance will be easier (You'll have 'alt' attributes on your images, for example)
If you choose XHTML as a standard, your markup will be more likely to be useful in an AJAX environment.
Failure to do this results in unpredictability.
One of the biggest problems with web browsers is that they have perpetuated bad habits (And still do, in some cases) by silently correcting certain markup problems, such as failure to close table cells and/or rows. This single fact has resulted in thousands of web pages that are not compliant but 'work', lulling their developers into a false sense of security.
When you consider how many things there are that can go wrong with a website, being lazy when it comes to compliance is just adding more problems to your workload.
EDIT: having read your original post again, I notice that you say you don't bother with compliance when working on a prototype, then you go on to say that you usually use the prototype in production - this means that it's not strictly a prototype, but a candidate.
The normal situation in such circumstances is that once the customer accepts a candidate, no time is allocated for bug fixing or tidying up, thus strengthening the argument for making the markup compliant in the first place.
If you won't be given time later, do it now.
If you are given time later, then you had the time to do it anyway.
If you want your sight to be accessible to people with and without disabilities, as well as external systems, then yes, you should definitely make sure you output valid HTML.
It's easy to test your HTML with automatic validators.
I'll add to what Mike Edwards said about legal ramifications and remind you that you have a moral obligation too :)
Why not write the prototype in valid (X)HTML in the first place? I've never found that to be more of an effort than using invalid HTML. Producing valid XHTML should be a trivial task. (On the other hand, producing semantically meaningful XHTML might be more taxing.)
In short, I see no advantage whatsoever in using invalid HTML for prototypes.
I honestly dont know why it is extra effort to do standards based HTML. It's not as if it's hard and you should be doing it as a matter of professionalism.
If you paid someone to build you a house and he cut corners out of laziness, that you didnt notice at the time, but in 10 years cracks appeared in your walls, would you be happy?
Valid HTML just to be able to have a badge on your site - no.
Having "valid HTML" in the sense of "HTML that works on every major browser or browser engine" - yes.
Absolutely. Invalid code can cause all sorts of weird behaviors, and errors which don't obscure those that do when you get a validation report.
Case in point:
A yellow background was spilling out of a list of messages and over the heading for the next list of messages - but only in Internet Explorer.
Why? The background was applied to a list item, but the person who wrote the page had written it as a single list with a heading in the middle. Headings are not allowed between list items and different browsers attempted to recover from it in different ways. Internet Explorer ended the list item (with the background colour) when it saw the start of the following item (after the heading), while other browsers ended it when they saw the end tag for the first list item.
It was the only validity error on the page, so it took only a couple of minutes to track down the problem and fix it.
Because, if you stick to standards, your work will be compatible in the future. User Agents will strive for standard compliance and their quirks non-compliance mode will always be subject to change. This is the way is supposed to be.
Unless you're into that whole IE8 broken standards perpetuation thing that they want to enable by default. -- that's another argument.
Webkit, Gecko, Presto? (is that opera's engine?), and the others will always become more compliant with every release.
Unless your html work is in a IE embedded browser control, then there's really no reason to output valid html as long as it renders.
In my opinion the key criterion is "fit for purpose" - If your clients want something for a small/internal market (and don't care if that alienates potential customers who have disabilities or use less-common browsers) then that's their choice.
At the same time I think it's our (as developers) responsibility to make sure they know the implications of their decisions - Some organisations will be bound by legislative requirements that websites be useable by screen readers, which typically means standards-compliant HTML.
i believe making valid html outputs wont hurt your development time that much if you've trained yourself to code valid html from the start. for one, its not that hard to know which tags are not allowed within an elementand the required attributes in a tag are sometimes the ones you'd really need anyway - i believe these are the main errors that makes your html invalid, so why not just learn them as early as now if you plan to stay on the web for long?plus outputting valid html can help boost your sites ranking
There are two rules for writing websites:
The site must work for your users.
The site must work for your users.
To meet the first rule, you have to code such that your site renders correctly when using Internet Explorer. Unless you have the freedom to alter your site design to use only those features that IE renders correctly, this means writing invalid HTML.
To meet the second rule, you have to code such that your site renders correctly when using screen-readers and braille screens. Although some newer screen readers can work with IE-targeted sites, in general this means writing valid HTML.
If you're working on a small project, or you're part of a large team, you can code a site that outputs IE-targeted HTML for IE, and valid HTML otherwise. But if you're taking on a medium-to-large project on your own, you have to decide which rule you're going to follow and which one you're going to ignore.
UPDATE:
This is getting voted down by users who think you can always get away with valid HTML in IE. That may be true if you have the flexibility to change your design to get around IE's shortcomings, but if a client has given you a design and you have to get it working, you may have to resort to invalid HTML. It's sad, but it's true, whatever they might think.