skip to main content

TAMU Webmaster's Blog


Information and insight from the A&M Webmasters

Browsers/Plug-ins

Browser Support

Departments and offices on campus will frequently ask to consult with us whenever they begin a new redesign process (we love talking to you, please continue to do so.)  One of the most frequent questions that comes up, despite being a topic that has been rehashed a dozen times in the last two years, is which browsers have to be supported.

My answer usually surprises folks — “all of them.”  This is my attention grabber that then lets me make a point and go into a longer explanation of content, the levels of accessibility, usability,  “browser support,” and the differences between these terms.

As a public university we have an obligation to make our information available to everyone, and as a web professional I think we have a mandate to do the same.  So the informational content of the page should ideally be accessible no matter what user agent the visitor decides to use — the latest version of IE, Safari on iPhone, JAWS speech reader, lynx textual browser, or even Netscape 1.0.    All of these can render the basic HTML that delivers the content, so there is no reason the site design should be such that the information is not delivered.

Note that the above makes no reference to what the page looks like.  Indeed, on various user agents it will almost certainly look different, possibly even bad.  But the information is there and is available.  Only once this bar has been met should we get into the question of what most of us mean by browser support — those which we want the general appearance and experience to be the same.

This, then, limits us to browsers that support web standards plus those for which we are willing to make exceptions and add hacks… largely IE 6.  Analytics shows us that usage of IE 6 has finally fallen to a low enough percentage that we need no longer consider it mainstream.  Unfortunately it is still high enough that it can’t be ignored.

I don’t buy into the argument that a site has to look and act exactly the same for every visitor on every device.  Minor differences are expected as each rendering engine treats the base HTML and CSS slightly different.  So let’s extend that concept and go back to content accessibility – can we create an experience in IE 6 in which the content is delivered and the page looks OK?  Not perfect, not exactly what other browsers will see, but good enough to deliver your information and not create a negative experience or perception of our organization.  That can be done easily enough using IE conditional comments and a separate style sheet to overwrite and tweak the default style.

So, long answer to a short question.  “Do we have to support IE 6?”  Yes… so long as you understand that support doesn’t necessarily mean providing the same experience as modern browsers, it just means making sure those who insist on using it can still get your information and not be turned off by the process.

Tags: , , ,

Friday, January 29th, 2010 Browsers/Plug-ins No Comments

Local Validators (HTML, CSS, RSS/Atom) Live!

Drum roll please! The webmasters group is proud to bring you local copies of all three validators! The HTML validator has been up for a while. You can find it by going to http://validator.tamu.edu/w3c-validator/.

The second validator, which admittedly took us a while to bring up, is used to validate CSS 1 and 2 and is available at http://validator.tamu.edu/css-validator.

The final validator – a little bonus for being so patient with us on the CSS validator – is the RSS/Atom feed validator available at http://validator.tamu.edu/feedvalidator/. Try this example (one of our feeds) to see the results.

Sure, you could use the external services available at http://validator.w3.org, but your site will have to be exposed through the firewall. The beautiful thing about our local validators is that they are fast, useful to sites not available through the firewall (test and dev sites), and can be entered into Firefox and Opera as the default validators when using plugins such as the Firefox Web Developer Toolbar.

Tags: , , , , ,

Web Development Tools and Local Validators

Nick DeNardis over at .eduGuru recently wrote a post on web development tools. These browser plugins and websites help developers with issues pertaining to website validation, link checking, accessibility, page performance and more. He listed the W3C Markup Validator (aka HTML Validator), but did not list the W3C CSS Validator or the Feed Validator. He did list some browser plugins that will do similiar validation.

I’d like to add one thing to his list for universities in general – running a local copy of the W3C validation services is very valuable. We already run a local copy of the Markup Validator and will very shortly have local copies of the CSS validator and Feed Validator running as well. Having a local copy really helps when validating sites that are still behind the firewall and not accessible via URL to the W3C copy.

You can also set Firefox to use the local copies of the validators as well which will usually lead to faster validation results. It is a good idea for any web developer to take a look at Nick’s list and play with some of the tools you haven’t seen before.

Tags: , , , ,

Wednesday, January 14th, 2009 Accessibility, Browsers/Plug-ins, Future Projects, HTML 1 Comment

Beware the Browser Cache

Browsers cache .css pages. We all know this, but sometimes they keep hold of them longer than they should, and each browser’s differing behavior is not well documented. Add on to this the ability of users to customize how their browsers handle cached information and you quickly develop a sticky situation.

We got caught by this today when we posted the university closings to the university website. Not long after the announcement went up we got a call saying that the notice had first appeared with maroon links, and then after they refreshed the page the links had turned yellow. It was immediately obvoius that their problem was a caching issue, but why? Because we made the updates to the bottom of the standard style sheet and since their browsers kept hold of the cache for too long (even between browser restarts.) The new styles were not loaded until they refreshed their page. Easy to solve – create a new .css file that nobody had ever downloaded and link it from the front page. Problem solved, now everybody gets the right styles. But lesson learned the hard way – if you have a change that you want to absolutely positively guarantee that everybody sees right away, you MUST rename the .css file, put it in a different .css file, or do something to defeat those over-stngy browser caches.

Have a safe weekend, and don’t forget about the Web Accessibility Showcase next week…

Thursday, September 11th, 2008 Browsers/Plug-ins, www.tamu.edu 1 Comment

Campus HTML Validator in Firefox and Opera

We recently put up the Texas A&M copy of the W3C HTML Validator at http://validator.tamu.edu/w3c-validator/. This allows us to check websites against the validator that are not accessible outside the firewall. You can also use browser plugins for FireFox (such as Web Developer) and Opera to validate HTML by uploading a copy of what is currently displayed in your browser to the validator service.

› Continue reading

Monday, April 21st, 2008 Browsers/Plug-ins, Miscellaneous No Comments

Screen resolution, page size and download time

In the past, Web design was geared around meeting fixed screen widths and resolutions. Current trends involve an understanding that the Web is fluid and not a piece of paper with boundaries. That being said, the graphic intensity and coding complexity for Web page complexity has grown along with bandwidth speeds.

Instead of specifying a screen size or a Kilobyte limit for file sizes, attention needs to be paid toward the user experience across the board. So in regards to page size and download times there are a few points to keep in mind.

  • Don’t use “best viewed at [screen resolution]” on pages. It’s not so much the screen size as it is the browser window size. Most people will not maximize their browser window out to its farthest reaches because they want to still be able to access the other windows easily. Consider a fluid design methodology that uses percentages to allow for browser resizing.
  • Don’t use “best viewed using [browser]” on pages. It should not ever fall back on the user to have to use a certain browser to access pages. While there are recommendations on standards-compliant browsers, design and development should entail cross-browser and cross-platform testing to ensure a consistent user experience.  When these things are in conflict, content is king.  With CSS it should be possible to gracefully degrade how the page looks without losing access to the whole content.
  • Don’t assume everyone has high-speed access. It is true that access to high bandwidth service has greatly increased, but there are still a large number of people with dial up or other slower connection speeds. Part of the university’s and System’s responsibilities is to provide education and outreach, especially to rural areas and underrepresented populations, so pages need to be optimized to minimize download time. This should include a discussion on the use or limit of images in relation to the page’s overall download time.

Browsers and Plug ins

These recommendations are intended to help the campus community optimize their experience with University web sites and make informed decisions about the many available browsers.

Preferred Standards Compliant Browsers

First and foremost, a Web experience ought to be consistent across browsers. Designing to the needs on one particular browser is bad development practice.  However, looking over browser statistics for the university and by looking over what’s supported and secure, we can make recommendations toward browser sets and versions. The preferred version will always be the latest version of the browser, but as long as there is vendor support for a version of their product, it still must be taken into consideration and testing during development of a site.

There is no requirement, though, that Web pages be presented identically on different browsers or versions of a browser. Developers are urged to test across older versions and gracefully degrade their sites such that content is still visible and usable even if the display is not the same.

› Continue reading

Tuesday, June 12th, 2007 Browsers/Plug-ins, Style Guide No Comments

Categories

Archives