Does anyone know of software or a webservice that can read your stylesheet and html/php, and profile your CSS? By that I mean indicating which clauses or rules are never used, and so on.
After doing several serious redesigns on a fairly complex website, I'm sure there are some old skeletons hiding away, making my code clunkier and less readable, doing absolutely nothing, setting rules for divs and spans long since removed.
The 'Dust-Me Selectors' Firefox plugin is quite helpful for finding unused rules, it can test individual pages and spider entire sites.
Well, I've found something interesting. Using the "Audits" tool as part of the Chrome developer tools, you can find out which CSS rulesets are extraneous.
It's quite basic - it doesn't even point to the line number each of these rules are located from, but it is better than nothing. Hope this helps.
Try using firebug, the firefox extension. It will tell you what rules aren't being used and which ones are unnecessary.
Related
I've been using XHTML for about 3 years now, and didn't care much about HTML5 and CSS3 arrival. Several months ago I've stumbled upon HTML5 Boilerplate and I'm starting to get very interested in it right now.
The only thing I can't find yet is drawbacks of using this set of best practices. I know, that the main goal of it to make site look the same on wide variety of browsers, but is there something I should be aware about?
Is there something I should be aware about?
Yes, definitely. It's not a plug-and-play thing. Or at least, it could be like that but it hasn't been conceived for that. And if you use it this way you can't enjoy its best. Boilerplate is very flexible and you have to learn how to customize it. Full stop.
My personal suggestion is to start experimenting with it and study the features it has to offer. Luckily for us it's well documented and you can learn a lot. Not only the boilerplate itself, but also the rules and best practices about HTML5, CSS3, resources loading and related issues/workarounds on performances, browsers quirks and how to fix them, tricks for mobile development, polyfills and conditional loading and a lot of other crazy stuffs. Once you are aware of its possibilities, if you'll find drawbacks you'll be able to customize the base boilerplate.
Start from here, read the docs, follow every link and don't be tempted to take shortcuts. It takes time, but you'll be rewarder very well. If you have troubles ask.
For something more concrete, a drawback I found very quickly (but someone consider this a plus) is that the boilerplate doesn't provide a CSS grid. Not a huge problem, I discovered that adapt.js is easily integrable, so I replaced normalize.css with adapt.js's reset stylesheet and used the grid.
Two things I noticed couple months back is the way javascript gets loaded at the bottom of the body. I'm not a big fan of this if not only it looks dirty. Also I tested the loading myself and didn't notice any better loading of javascript. In fact it ran a couple ms slower on a huge script.
Also the normalize.css I tried couple of times but found myself restyling more paddings and margins than before. Which is normal ofcourse since it's goal is somewhat similar but a different approach. I changed this to Eric Meyer's reset.css just because I'm used to it.
I really like the modernizr script and the way to implement things for x-browser results.
Google Analytics implementation for example.
Another small thing I remember was the placing of the title tag. I changed it to the top position for SEO reasons.
I need to render some HTML content (created by the application) and I'm wondering whether I should use QTextBrowser or QWebView. Although they seem quite similar, the doc doesn't discuss the differences between then.
I guess QWebView is almost a full-featured browser, but how about QTextBrowser? Does it also use webkit? Am I likely to run into some limitations if I use it?
QTextBrowser supports only a subset of HTML and CSS, documenation see here.
It has the advantage that it is lightweight, QWebView uses a lot more code and ressources.
Some more information The answer is accurate, however I feel compelled to complete it with some more info (OP). As a warning, read through the provided link to get the tags and styles that work. em sizes don't seem to work at all so set all your sizes in pixels; HR styling is extremely limited; bottom-border styling is not available (which could have been a good alternative to HR); . So don't do your design in Firefox and expect it's going to work in Qt. It most likely won't. Check the ref when things don't work as you except and tweak as you go. Eventually, it's probably possible to do many designs with QTextBrowser but it's better to check as you go.
I was looking at the www.google.com in Firebug and noticed something odd: The Google logo is centered using a center tag.
So I went and checked the page with the W3C validator and it found 48 errors. Now, I know there are times when you can't make a page valid, especially when we're talking about something like www.google.com and you want it to be as small as possible, but can someone please explain why they use the center tag?
I attended a panel at SXSW a few years ago called "F*ck Standards" which was all about breaking from standards when it makes sense. There was a Google engineer on the panel who talked about the Google home page failing validation, using deprecated tags, etc. He said it was all about performance. He specifically mentioned layout rendering with tables beating divs and CSS in this case. As long as the page worked for their users, they favored performance over standards.
This is a very simple page with high traffic so it makes sense. I imagine if you're building a complex app that this approach might not scale well.
From the horse's mouth.
Because it's just the easiest, most concise way to get the job done. <center> is deprecated, for sure, but as long as it's still supported, you're likely to still see them using it.
Shorter than margin:0 auto. Quicker to parse. It is valid HTML4. No external dependencies, so less HTTP requests.
Usability is NOT validity.
Google Search's biggest achievement has been to build a site which is easy to use, and can be widely used. Now, if Google achieved this with a page which does not validate, well, there's a lesson there to learn.
I think a better question to ask would be "why would Google make it validate if it works fine?" It makes no difference to the user.
There has been speculation and discussion about whether this is intentional; the basic test carried out in the first link does result in a smaller page, and even gzipped, through millions of page views it theoretically stacks up. I doubt that's the reason though: it was created, tested on many browsers at the time, it worked, and continues to work.
Google's breaks validation in many ways on their home page. The very likely real reason - they are all about speed and bandwidth costs. Look at the size of the home page HTML particularly after Gzip is applied at the packet level. They are clearly trying to avoid packet fragmentation (which will mean more bandwidth) and willing to do whatever it takes to get it (identifier shortening, quote removal, deprecated tags, white space removal, etc.
If you look at this just as a validity question, fine but they break the rules on purpose if you don't assume this of course you may jump to a negative conclusion. BTW you can further optimize their pages both in positive and negative manners but why once inside the typical packet size it is somewhat pointless.
They also use other deprecated presentational tags like font and u. My guess is it makes the page quicker to load then using an external stylesheet and allows it to work on more platforms.
It's deprecated, sure, but I think simplicity is the answer to your question.
I've been a web developer for quite some time and what has helped me in learning is to visually see what is going on.
That's the reason for Tools like Aardvark, Web developer, Firebug and many others.
But when i saw the Gecko Reflow Videos they just blew my mind.
Then my question is, is it possible to truly debug html (step through each element)? Or come close to it?
What i've been doing a lot is to use Aardvark and remove elements but Aardvark has its issues with "background" and same size elements and not being able to target those.
UPDATE: I've been trying to write a good update for this question since it has left me thinking about it more. But since English isn't my primary language its been tough.
In the past years it's been the browsers who have had the task of being compatible with the standards. As they get closer to that goal, it is us who should be thinking about what we can truly create when browser compatibility is minimal, and if there are techniques we can utilize that makes rendering a page faster.
We can think of the past decades as the early years of HTML/CSS, where the main goal was just to get the thing to work. Now we should be looking for techniques that speed up the current process. An example of this is in the video above where the Gecko engine is running through the code twice. Why is that? And are there other instances where its doing unnecessary things (even though they work and are compatible)
This is something that clearly needs to be tested to be confirmed, hence my original question of a true debugger.
My $0.02:
"True" HTML debugging, in the sense you're talking about, is not technically possible, because there is no requirement of HTML user agents (web browsers) to render HTML elements in a particular order, nor is there anything like an atomic unit of execution like a "statement".
For instance, when rendering a table, should a user agent reserve space for each <tr> before rendering their child <td>s (breadth-first)? Or should it render each child <td> and each <td>s child and so forth (depth-first)? In practice, user agents make all kinds of guesses to try to render pages as quickly as possible. In other words, there would be no guarantee that debug-order will match actual render-order, nor should there be.
HTML can be thought of as an declarative language in this sense, in that it specifies what should be done (the page rendered to spec) but not exactly how to do it (exactly which order to render elements to the screen). In general, it's best to assume that everything happens at once, although the W3C does give some tips on speeding up <table> rendering based on how user agents should render <table> elements.
IMO, the webdev toolbar and Firebug are the best we've got, where we can edit/disable specific HTML elements and CSS rules.
ok - serious answer.
Judging by the comments on the sites that I've followed from that link, I think that you and I know that there probably isn't. There are a lot of smart blokes and blokettes on those threads, and they all seam to point towards the "no, this is all clever $4!# that wont help us in understanding rendering.
However, I think that what your question might want to emphasis is that rendering at a browser level is very interesting.
Let me just throw this one out there. Do you think that putting body { overflow: scroll; } as a default might speed us up just a little???
In my professional opinion, there's really only one effective tool for time-factoring / assessing / debugging within the html milieu: The WebDev Iterator
Personally, I feel as long as your HTML validates to W3C spec, isn't that all that matters? One should develop their HTML to spec and let browser companies worry about their bugs (which are pretty rare these days) than to focus on old browser mistakes of the past.
HTML Validator plugin for Firefox (aka Tidy) is all any web developer needs to see if their markup is correct, what's wrong, and where it's wrong.
Even if you could do true debugging, each browser parses HTML it's own way, so even if you could step through Firefox to see how a rendering bug occurs, that won't help you with IE or Safari/Chrome at all because they execute parsing in their own manner. This isn't like PHP, .NET or Java where the parsing of the code is the same for everybody, debugging makes sense there.
Then my question is, is it possible to truly debug html (step through each element)? Or come close to it?
You could probably step through the page rendering process by running Firefox under gdb, or modify an open-source browser to have a "step" button, but I really doubt this will achieve anything useful.
CSS isn't that complicated, everything is basically a box, with a width/height/padding/margin.. The problem with web-development (CSS particularly) is every browser implements rendering slightly differently (some more differently than others)..
If you want to know the render-order to speed your page load up, I'd say you're going about this the wrong way.. The browser rendering the page probably accounts for maybe 5% of the load time, the rest is page-generation time and network latency.
You could possibly shave 2ms of your page load by reordering some tags and using a different CSS positioning method.. or you could reduce the page-generation time by 200ms by caching, and half the network latency by setting up a second web-server nearer your users.. Compressing your logo better, or minifying your javascript would most likely improve load-time (universally, across all browsers!)
Basically, if you're concerned about load time, there are much better places to start. If you're concerned about how the page is being rendered, Firebug(-Lite) and http://browsershots.org (or a virtual machine or two) are all you need!
I'm looking for feedback on peoples experiences with developing sites that work across browsers. It seems to me there are at least two obvious ways to approach the task of making your site/webapp work across browser:
Constantly test across all supported browsers every step of the way; or
Pick a browser, get everything working in it as a reference implementation and then make all the other browsers match the reference implementation.
Each approach has an obvious drawback -- the problem with #1 is that you end up doing a lot of unnecessary work -- especially if you are developing a webapp that is going through a lot of iterations/prototyping/spikes etc. You will make a bunch of stuff work across browsers that will subsequently be discarded/removed.
The disadvantage to approach #2 is that while it makes the initial development much quicker and more painful it makes it much harder to figure out where some of the specific errors arose, especially for more complex issues -- whereas if you had been developing for all browsers at once you should catch it right away and know what change(s) introduced the problems.
A somewhat obvious third option would be a hybrid approach, but it seems to me that you would end up losing more by experiencing both of the problems with #1 and #2 than you would gain from the benefits of doing both.
What have you found to be the most effective way(s) to approach this challenge?
I’ve found that if you get too deep into developing a website without looking at other browsers you’ll quickly get to a place that is too much of a headache to debug. I consistently open my web pages in all the browsers I care about.
I strongly suggest you verify all browsers each time you make a large change to the site.
Make it work with all browsers up front. This will mean extra testing during development but will cause you less pain later. I find it's usually easier to diagnose problems if I've just developed the thing, rather than coming back later and trying to figure it out...along with a list of other issues.
It partly depends on whether you know it's going to have to work in all browsers up front. If you do, then you really are better off just making it cross-browser to begin with. You don't need to test that everything is 100% compliant every step of the way, but you should code toward that.
And really, it's not that hard, especially what with JS frameworks like jQuery and Dojo around that take care of the scutwork. If you find yourself continually battling one browser or another, you might want to reconsider your design, as you may have chosen to do things in a way that is inherently more difficult to do when cross-browser compatibility is important.
Well, you do #1, but you do it whilst greating a style guide. A litle bit like this: http://www.sitefromscratch.com/content/html-xhtml-css-testing.
So when designing a new site or design, you create a page containing the desired HTML for all the visual elements that will be used on your site. Ignore style for now, just use the HTML that makes the most sense.
Then you style it. Preferably, your style guide would be all on 1 page so it can be open in each browser you're supporting and all you need to do is hit refresh between changes, (avoid opting for several pages, because it will take you longer to inspect them all).
When you build your site, build from the style guide. If it's not in the style guide, add it and test it there first. If you discover a problem when building the site, (perhaps you didn't consider a particular element when it wrapped, for example), replicate and fix the problem in the style guide.
Here's the killer advantage: A new version of one of your supported browsers is released, what would you prefer to test, your entire site, or the style guide?
So that's the CSS taken care of, now you need to do that all over with your generic JS functions, if any.
I created an interface compatibility layer between the browser and my code - basically, I wrapped certain functionality and made the wrappers determine what javascript/html was needed.
As browsers change, you change this compatibility layer and you can leave the rest of your code alone.
If you have this layer in your architecture, the answer to your question becomes "whenever you want".
If you can get an enterprise lock-in then multiple browser support can become less of an issue, e.g. if your customers are all companies using Internet Explorer then why build the site to look good in Safari or Chrome?
If though you are making something for the general public then there is a hybrid approach I'd use which is that I use one browser to get all the functionality there and working and then test across browsers when I'm in that "pretifying" phase of the project. Initially the key is for it to work, then it has to look good.
I don't think I could see a logic to testing across all browsers as I initially fill out a form or do some other basic functionality as it could be a big productivity drain to test across at least a few browsers, e.g. IE 6 & 7, Firefox 2 and 3, Opera 9.5, Safari, and Chrome if one wants to get all the big boys, and at least a couple O/S as Safari on a Mac can be different than Safari on Windows, which is a lot of tests even for just one or two pages. On the other hand, near the end, this is when I can refactor my CSS and inline styling and make the code better for handing off for someone else to maintain, archive until a service pack project is planned, or keep some documents just in case something has to be done. Also, by waiting to clean things up, I can have more confidence in the final UI parts as these can evolve and change considerably over a short period of time.
I usually start out ensuring that all the HTML and controls that I write/use adhere to the specification.
Tools-->Options-->Text Editor-->HTML-->Validation-->Check Show Errors and choose your Target
This starts me out on a solid base. I functionally test new features in a single browser and then about once/twice a day test the full set of them across all browsers.
Using this approach, CSS and JS are the usual suspects when something isn't right, its rare that it's the actual HTML markup.
If you can do it right the first time. Do it then. It will probably never be right later.
Depends mostly on your experience, which could be applied to any programming activity including this one. If you know in advance what likely pitfalls you're going to have to avoid (eg. in cross-browser development, don't make it hard on yourself by trying to do something that is going to be a hassle in a different browser), then you can probably safely develop everything in one browser and then go in after it's done and tweak things to get it working everywhere.
I usually advise junior developers to keep all browsers open during development and to refresh each browser when making changes, but I myself tend to write everything with Firebug for support and then go back and see how it's doing in IE7 (etc) afterwards. Since I've been doing this for several years, most of the time I can predict what's going to be causing a headache and often immediately know where to look to fix it.
If you are new to Web Design/Development then getting things right in different browsers can be a chore at times.
However, it's really not that hard to get a website working in every major browser and coded towards the W3C standard. In my opinion EVERY designer/developer should do this out of principle, otherwise they are no better than they were in the IE years.
Develop cross-browser code, make sure it validates and never think about designing for one browser again.