I just noticed that the look of the form elements in Chrome has changed. I couldn't find any explanation with a quick search. Even the official Chrome's blog doesn't mention anything. I must say, the new look feels a bit foreign.
I would like to find out the reason behind the change. My guess would be that it has something to do with rendering speed. Is there the official benchmarks of the old look vs new look.
The speed might not be the reason. Does anyone know the official reason?
I didn't look into the official reason, but I noticed that checkbox elements are now vector graphics so they can scale/resize (like in the newer Internet Explorer).
The Chrome changelog probably has the answers you seek, but I'm guessing they wanted them with more consistent usability/presentation across platforms instead of using the OS' native look and feel.
Assuming I already have valid code, is there a tool or plugin that I can use to evaluate my website code and highlight areas where different browsers could potentially display the code differently? I am aware of websites like browsershots and I have VMs to test, but I'm wondering if there is something to shortcut the process by looking at the code and warning of well known cross-browser compatibility red flags.
For example, when using CSS which is not universally supported yet. The following is valid CSS 2.1:
display: run-in;
Validators which are aware of CSS 2.1 will pass it with flying colors, but really, a red flag should be thrown, indicating that it does not work in Firefox 3. On the other hand,
border-radius: 10px;
is actually pretty well supported in updated browsers, even though it is CSS3.
This is new in Javascript, but is also passed by validators:
getElementsByClassName();
but it would be better if a warning popped up notifying me it won't work in IE8.
Another example is well known rendering bugs, which can be triggered by weird (valid) situations. I understand there is no replacement for opening up the website in every single browser on every system to really see how it works, but I am just wondering if there is some tool that can help check that I'm writing interoperable code as I go, so that I can test more frequently in the development process and spend less time working out bugs later.
Unfortunately, the answer is no.
I once started looking into creating a tool exactly as you describe. The reality is that most libraries like jQuery actually make use of browser incompatibilities and different interpretations of standards (or ignoring the standards).
So, if you're using any of the standard libraries then you'd receive tons of warnings and actually get very little out of it. The amount of spam simply will shadow the actual bug you might have introduced.
What matters more is whether the incompatibilty actually affects the end result. Hence we went for what-you-see-is-what-you-test method instead of static code analysis.
Is there any tool that allows you to automatically test page under different browser and make sure CSS looks good?
P.S. I know it sounds impossible, but maybe there are some solutions (like taking screenshots and comparing them)
https://browserlab.adobe.com/ - adobe id is needed, but it's free.
and
http://netrenderer.com - just for IE.
Both only take screenshots, but with a very little delay.
also for ie http://www.my-debugbar.com/wiki/IETester/HomePage - It's still in alpha state so it can only be trusted to a point.
Personally though, I pretty much have every browser in my comp so I can test things out in the actual browser. Plus all of the major ones do have web dev tools so.. if you can download all the browsers that's a good choice.
And I really just test all around functionality. For example if text is little different in some browsers then so be it, as long as it doesn't get cut or anything.
Tried BrowserStack? http://www.browserstack.com/
There was some other site I occasionally used to use that returned a set of images, but I can't remember what it was, and it wasn't always accurate.
You can use http://browsershots.org/ to create screenshots on all types of devices and browsers. This might be what you are looking for.
I would like to know if it is possible to modify Chrome or Firefox display settings, so that it would only show rectangles of HTML DOM objects? What I want to do is to decrease rendering engine job amount as much as possible, so it would only build layout of the page.
People usually refer to this mode of operation as "headless" (i.e. without UI).
Usually there's an additional requirement - to be able to run it server-side without the usual for client software installed. If you're running it client-side, I wouldn't bother about optimization, it shouldn't give you a big win anyway.
Otherwise, try searching using that term. I've seen it asked for several times, but haven't seen a working out-of-box solution.
[edit] just saw http://hg.mozilla.org/incubator/offscreen, which seems to be a headless version of Mozilla.
I wouldn't go as low-level as modifying the renderer. Instead, I suggest you use Firefox's Greasemonkey to replace the elements from the page with whatever it is you need. You'll need to know a bit of JavaScript, but it's not that hard.
However, this will only work on client side. If you want to do this on server-side ( so that it will work on any page a user requests through your own ), my guess is you'll need to grab the page's content in a string, and then modify it using a HTML parser.
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.