18

I know that this idea has come up before - notably here and here - but no solution seems to have been given. It was largely seen as either a 'nice-to-have-but-impossible' or 'stupid idea'.

My thoughts were using jQuery to calculate computed values and compare them to expected values. For example, I could have <h1>This is a header</h1> and in theory, I should know it's font-size, colour, font-weight, etc. I can use jQuery to check that it is actually that font-size, and if not, return an error.

The advantage of this is that I don't have to sit with a checklist going through each browser - 'Is this header bold? Are these links underlined? Is this column 110px wide?' - every time I make a CSS change.

My question - is that a feasible idea? What are the major problems in implementing something like that? Has anyone done something like that before?

EDIT: Any thoughts on how to actual render the errors are welcome too. I thought of using a JavaScript file in the header of the relevant page and then adding content to the page, kind of like Firebug's on-page version. However, I'm worried that could then affect the rendering of the page. Alternatively, I could log it to the console, but I don't think IE6 has a proper console, and opening every console of every browser for every page-under-test seems a bit annoying as well.

Community
  • 1
  • 1
Dan Blows
  • 20,846
  • 10
  • 65
  • 96
  • 1
    I'm sure it's possible, but you will have to be aware of some browser differences: for example, if a div has a background color of blue, IE will say it is blue, and Chrome will say it's #0000FF – Peter Olson Apr 19 '11 at 00:42
  • Hmm, good point. So I guess I would need to have a library which standardises the attributes before it checks them. – Dan Blows Apr 19 '11 at 00:48
  • 1
    There's no real need to check for *every* css change you make, just get the whole thing working in one browser, then bug-fix for the others after. – Wesley Murch Apr 19 '11 at 01:14
  • there seems to be a way to identify a users browser by code once you get the main code down you could try to use the if in html to identify the users browser then let it adjust the code based on that. if that is what you are trying to do. – CMS_95 Oct 14 '13 at 00:38
  • It's unclear what your question is, you already know you can use jQuery to get the computed styles and check that things look the way you want... Write the test, ask a question if you have a problem. Theoretical questions are not a good fit for SO, and should be asked at http://programmers.stackexchange.com/ – Ruan Mendes Oct 23 '13 at 23:39

4 Answers4

10

Even if there was a way to do this, I would still feel the need to check manually.

The examples you gave aren't the types of things to typically worry about, but mostly positioning and box-model stuff. If I say h1{color:red} I feel pretty confident that it's going to be red in IE.

Getting the computed values isn't really going to help with finding out how they are rendered, it actually sounds like more work overall than just firing up IEtester. With a bit of experience you quickly learn the types of things you need to check for cross browser compatibility, and with browsers getting better and better, it's becoming less and less of an issue.

One technique that can help: Design in IE. Yes it sucks for sure, but you'll usually find that when you get it working in IE7 and then test in FF, IE8 or IE6 - it's pretty close or the differences are an easy fix compared to testing in say Chrome, and then double checking in IE7. I know that "cross browser" encapsulates more than just IE, but let's not kid ourselves; IE is the problem browser and the most widely used.

In conclusion: If there were a tool for this, it would have to be REALLY AMAZING to keep me from checking in a real browser. I think that's why people are pointing to Selenium as the solution to this.

Wesley Murch
  • 101,186
  • 37
  • 194
  • 228
  • sad to say, but I think you're idea about designing in IE is really great. :) – Andbdrew Apr 19 '11 at 01:13
  • 1
    I agree that I would never have the confidence to 'assume' the CSS was working just because it passed my tests. However, I find that some small changes introduce bugs that get overlooked when checking 9 browsers. For example, a while ago, I accidentally set the hover colour of some links in the footer to white on a white background in IE6. It was like it for about 2 months before I noticed. That's the kind of mistake I want to spot automatically and quickly, because it's so time-consuming and difficult to detect manually. – Dan Blows Apr 19 '11 at 01:27
  • @Andbdrew - for a moment, I thought you wrote 'IE is really great'. – Dan Blows Apr 19 '11 at 02:12
  • @Blowski, From reading the comments - I really can't see how the amount of code writing and debugging you'd be willing to do to "test" your css could possibly offset the time you'd spend simply checking in browsers, and ***knowing*** that it works. I can't even visualize how this would work. – Wesley Murch Apr 19 '11 at 02:56
  • the code "

    does not appear to work in IE, Firefox, Chrome. IE has a decent base ground

     – CMS_95 Oct 14 '13 at 00:51
2

hmmm... Let the audience dictate what you test, and make that part of your client relationship.

What are your traffic sources? View the Logs, Analytics, etc. I honestly don't care what it looks like in Opera (for example), if traditionally, Opera equates to 1% of overall traffic - unless that's the client's fav browser, but you get the point - sweat the few that matter, not every single one that's available.

On one hand, I think the idea is pretty cool, but I wouldn't trust it - it'd be obsolete 2 months after each update (that's a little sarcastic, but still)...I'd end up looking with my own eyes. The whole idea kind of sounds like an automatic shoe-lacer, or something - rather moot to me. Besides, "I tested it with 'Kick@cSS'!!" will never get you out of hot water with a client.

If you're following standards, testing and debugging is generally pretty quick (as long as you're testing as you go). Don't wrap your block elements with in-line elements, etc. will help keep things moving smoothly, and everyone happy and compliant as well.

Dawson
  • 7,567
  • 1
  • 26
  • 25
  • If you spent 1 hour a day tying your shoelaces, wouldn't you want to automate it? – Dan Blows Apr 19 '11 at 02:47
  • @Blowski: `If you spent 1 hour a day tying your shoelaces, wouldn't you want to automate it?` Once you get the hang of it, it only takes a minute or two :) – Wesley Murch Apr 19 '11 at 03:01
2

I have posted the same answer to a related/similar question: Automated testing of CSS and HTML front-end coding

If you're looking for a tool that's built for regression testing check out:

https://github.com/bfirsh/needle

It basically takes screenshots of the parts you select (check their example) and compares them. If they're too different from each other, the test will fail. It's using Selenium, so you might as well check for other assertions, like z-indizes, font-sizes, etc.

Community
  • 1
  • 1
Kevin Smith
  • 747
  • 1
  • 6
  • 13
-1

The advantage of this is that I don't have to sit with a checklist going through each browser - 'Is this header bold? Are these links underlined? Is this column 110px wide?' - every time I make a CSS change.

Sure, but the secret is that you don’t have to do that now.

If this header isn’t bold, then no-one’s going to die, or lose any money. Someone will notice*, and it’ll get fixed, with minimal effort.

You’re better off spending time designing your CSS so that your styles are isolated (and thus unlikely to cause difficult-to-trace errors) than writing automated tests for every element on every page on your site.

The amount of effort you’d need to get something like this working is disproportionate both to the difficulty of getting the code right (which isn’t much), and the consequences of getting the code wrong (which isn’t much either).

More practically, how would you specify the kind of tests you're describing? You'd need to tell the test runner which elements it should check, and what each element's style should be. That's what CSS does. Maybe your definitions for which elements to check could be much more specific your CSS selectors (e.g. select each element on each page individually), but that would be very time-consuming, both to write initially and to maintain.

(Just to elaborate on the necessary effort: for the cross-browser rendering tests you’re describing, you’d have to run actual web browsers (using something like Selenium), meaning you’d need multiple machines (for IE), all of which have to be accessible to your testing framework. This would be a nightmare to run personally, and very computationally intensive to offer as a service — just ask the guys who run Litmus.)

Sorry that this isn’t really an answer to your actual question, but test-driven development can be a bit of a religion, in the sense that people get very inspired by the idea of it (which is admirable) without really understanding how it works, or where it actually offers a decent return on your time.

* (Or, as I’ve experienced more frequently, no-one will notice, and you’ll spend a few seconds pondering the pointlessness of your professional existence before reaching for your third beer of the morning.)

Paul D. Waite
  • 96,640
  • 56
  • 199
  • 270
  • @Blowski: in that case, you’ve signed up to an insane contract that loses you money for tiny mistakes that take 60 seconds to fix, and despite that, you’ve failed to spend 3 seconds *looking* at the site you’re writing CSS for to check that the headings are bold. If those things are true, you might want to focus on them before confusing yourself further trying to set up automated CSS testing. – Paul D. Waite Apr 19 '11 at 01:52
  • @Blowski: On a mostly unrelated note, [you have 72 HTML validation errors on your home page](http://validator.w3.org/check?uri=http%3A%2F%2Fwww.blowski.com%2F&charset=%28detect+automatically%29&doctype=Inline&group=0). Thankfully, in that case your client is you :) – Paul D. Waite Apr 19 '11 at 01:55
  • @PaulD.Waite - relying on "hope the client doesn't notice and that it's a quick fix if they do" doesn't seem to be the best approach to development. Equally, the whole point of my post is that testing CSS is very time consuming, and I'm wondering if there's a quicker way of doing it, so saying "just look at the browser" is the same as saying to a software programmer "don't bother with unit tests - just use the software to check it works". I agree that it might end up being more hassle than it's worth, but that's why I'm asking. – Dan Blows Apr 19 '11 at 01:56
  • @Blowski: sure, I take your point in general. It’s just that for CSS issues that are simple enough to be testable, your test code would tell the computer what the page should look like, preferably in a declarative fashion, and that’s exactly what CSS already does. Good test cases specify the output required from some code (often given a specific input), so that the programmer can change *how* the code produces the output, without worrying that it‘s still correct. That doesn’t apply to bold headers and underlined links. Your test code would literally duplicate your CSS, in longer form. – Paul D. Waite Apr 19 '11 at 02:03
  • @PaulD.Waite - exactly what I want to do with CSS testing. The 'output' is whether the header is bold, the _how_ is the CSS itself. I want to be able to change the CSS without worrying that I've just unbolded a header in IE7. – Dan Blows Apr 19 '11 at 02:06
  • @Blowski: but how would you specify that a specific header should be bold, other than with a CSS selector and `font-weight: bold`? With declarative code like CSS, the what and the how are the same thing. – Paul D. Waite Apr 19 '11 at 02:08
  • @PaulD.Waite - I'm thinking of doing something like `$.assertTrue('h1', 'font-weight', 'bold')` with jQuery. – Dan Blows Apr 19 '11 at 02:10
  • @Blowski: right, but that’s semantically identical to `h1 { font-weight: bold; }`. It’ll guard against you accidentally deleting a bit of your CSS file, but as far as I can see, that’s about it. – Paul D. Waite Apr 19 '11 at 02:16
  • @PaulD.Waite - jQuery will return the current state of the element, not what's in the CSS file. For example, if I have `h1 {font-weight:bold}; .header {font-weight:normal}` and I accidentally assign `

    `, my header is now not going to be bold. While obvious in that case, especially since it will be like that in every browser, there are much more subtle mistakes that might only apply to one small area of the page in only one browser. You're right that it's not _that_ big a deal, but it would be nice to have a quick means of spotting it before the client does.

     – Dan Blows Apr 19 '11 at 02:23
  • @Blowski: sure, but imagine that, within your site, there’s another place where you’ve got an `

    ` tag that *should* have `font-weight: normal`. How does your jQuery test code distinguish between that, and `

    `?

     – Paul D. Waite Apr 19 '11 at 10:52
  • @PaulD.Waite That's a very good point, I would have to work out a way for jQuery to distinguish between different elements, which might mean adding classes or IDs merely for the purpose of testing. That wouldn't be an ideal solution. However, the TDD motto is "If it's hard to test, it's badly coded", and I see no reason that shouldn't apply to CSS. – Dan Blows Apr 19 '11 at 11:12
  • @Blowski: for me, the reason it doesn’t apply is that CSS isn’t a programming language. With test-driven development, you design e.g. a class, picking method names and defining outputs, then write your tests to check that those methods return what you expect from the input you provide. Well-coded classes have specific, granular methods, so they’re easy to test. The closest analogy in CSS is having class/id names for most of your styles, and if you’ve got that, then your tests are just restating your style blocks, and are thus redundant. – Paul D. Waite Apr 19 '11 at 13:39
  • @Blowski: the tests you’re describing seem to be aiming at a certain class of mistakes, e.g. misapplying a class in your HTML. You might want to list which specific errors you want to guard against; it might then be easier to figure out what your testing would look like. – Paul D. Waite Apr 19 '11 at 13:40
  • @PaulD.Waite - misapplying classes, IDs, setting a value higher up the cascade which has unintended effects further down, relative sizes going wrong, adding something above with too much specificity, accidentally deleting something from the CSS file. These are all mistakes which I make repeatedly, and I want to know about them as quickly after I've made them as possible. Plus, with TDD, there's the idea of doing 'the simplest thing possible to pass the test', and that's something else that a system of this kind would help with. – Dan Blows Apr 19 '11 at 16:51
  • @Blowski: sure. I guess for those sort of errors you’d want your tests to uniquely identify the exact elements (e.g. this link in this footer), then check that they match a given design. So you’d have very very specific element selectors in your tests, to catch errors in your selector use in your actual CSS. That makes sense. (I still think it’d be wildly impractical to set up, but those sort of issues can be made easier over time, so we might see something like this some day.) – Paul D. Waite Apr 20 '11 at 09:42
  • @CS_STEM: I've no idea how JS Fiddle relates to either my answer, or the original question. – Paul D. Waite Oct 10 '13 at 08:33