skip to main content

TAMU Webmaster's Blog

Information and insight from the A&M Webmasters


Things Web Developers Should No Longer Do

Note: This is opinion, of course, but what’s your opinion? What would you add or subtract? What web design trends do you think have passed their “sell-by” date?


* infinite scroll
* min-height:100vh
* hamburger menus on desktop
* autoplaying videos
* carousels
* dropdown menus
* modals
* disabling zoom
* gray text in white
* articles split across multiple pages
* scrolljacking
* full-width hero images
* icon fonts
* tables for layout
* browser sniffing
* device detection

(per ‏@aardrian @rogerjohansson @heydonworks and others)


And another perspective:

adrianholovatyApr 27, 2:00pm via Twitter Web Client

How you could tell a site was well-crafted:
2002 all-CSS layout
2003 nice URLs
2005 ajax
2010 responsive
2016 works offline w/ serviceworker

Wednesday, May 4th, 2016 CSS, HTML No Comments

Shrinking Tools for CSS Files

We’ve begun using the Zurb Foundation framework, which includes a 176K stylesheet of everything that you might need just in case you need it. Well, for a recent one-page site, I guess that we probably wouldn’t need very much, so I sought ways to strip out unused CSS.  How much could I shrink the 176K CSS file without breaking the page?

  • Dust-Me Selectors – a Firefox extension that reduced it to 18k, with no noticeable differences in the performance of the page. Unused code could be commented out, or removed altogether.
  • mincss – a Github project that reduced it to a responsive 10.5K, but the responsive slider stopped working.
  • unused-css – a commercial service that reduced it to 73.8k. It removed most of the code from the media queries, so the page was no longer responsive, but  the slider still worked.
  • Chrome Developer Tools – told me how many unused CSS rules I had, but doesn’t produce a cleaned version.

As you can guess, your mileage may vary. Some tools will flag redundant CSS but not unused CSS, or removes code that is only used at certain screen widths, or don’t work with LESS/SASS. But Dust-Me Selectors worked fine for me, for now.

Thursday, October 30th, 2014 CSS No Comments

Worrying About Making CSS Faster

In recent years, I’ve become interested in improving website performance. Chrome Developer Tools (the Network and Audits tabs) make it easier to see bottlenecks and how to fix them.

One of my goals was to use more efficient CSS.  I could have been using * and + in my CSS, but I knew the more calculations and animations the browser has to make, the slower the page will run. Web developer Ben Frain singles out “expensive” features such as box-shadows, border-radius, transparency, transforms and CSS filters as particularly troublesome.

But Frain’s experiments also show that the number of CSS selectors – the size of the CSS file – affects page performance more than the type of selector. His conclusion: “It is absolute folly to worry about the type of selector used.”

So I’m ready to stop worrying. Enter the owl selector, as named by British designer Heydon Pickering because it resembles “an owl’s vacant stare.”

* + * {
	margin-top: 1.5em;

In this case, to enforce the rule, “All elements in the flow of the document that proceed other elements must receive a top margin of one line,” Heydon uses a single line of “axiomatic CSS” that potentially saves having to write dozens of lines of CSS.

And reducing the size of the CSS file does measurably improve site performance. In my next post, I will mention some of the tools I used to do that.

Monday, October 27th, 2014 CSS No Comments

Solving Quirks of Internet Explorer 11

I have a confession: I hacked Internet Explorer 11. And Internet Explorer 10. I moved the search button up one pixel on – but only in IE. It was difficult because, unlike previous versions of Internet Explorer, conditional comments don’t work on IE10 or 11. But I’m not ashamed. True, I was told that if I had any problems with Internet Explorer 10, it must be MY CODE, since Internet Explorer 10 was now bug-free and standards-compliant. So why did the search button look fine on other browsers? The extra pixel was also needed for IE7 and IE9. IE8 required two pixels.

Technically, the media query isn’t a hack, it’s feature detection – though not the kind that Modernizr is famous for.

@media screen and (-ms-high-contrast: active), (-ms-high-contrast: none) {
   #searchButton {
        margin-top: 1px;

That’s the CSS that fixed my search button: There are other ways to target recent versions of Internet Explorer, but this one seemed the cleanest. Microsoft’s recommendation: add a meta-tag <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9"> to make the browser pretend it’s IE9. Except… I don’t want to go back to IE9.

Tuesday, June 17th, 2014 CSS 1 Comment

Testing retina display if you don’t have a retina device

Since everybody is getting new smartphones except me, I need to add high-resolution images to the sites I design – but until now, I couldn’t see what they looked like on a high-resolution device without borrowing somebody’s phone. We use media queries to serve larger images to retina devices, and zooming my browser won’t trigger these media queries.

But there is a way to simulate a retina display on a Firefox browser [EDIT: and another way in Google Chrome].

  1. Go to “about:config”
  2. Find “layout.css.devPixelsPerPx
  3. Change it to your desired ratio (1 for normal, 2 for retina, etc.)

When I run these tests, the pages get so big it’s hard to use Firefox for anything else, but I can quickly tell which images will work on retina (the crisp ones) and which images need to be swapped out (the blurry ones).

I learned another retina solution from Monty Dickerson: use larger images that have half the quality (Photoshop 50) but four times the pixels (100 x 100 instead of 50 x 50).  It’s counter-intuitive, but they aren’t much heavier than traditionally-sized images, yet look much better, even on normal monitors.

Using Monty’s solution, you can check for blurry images by just zooming your browser 200%.

Friday, November 22nd, 2013 CSS, Mobile Web No Comments

Should we continue to support IE7?

While looking through the analytics for yesterday’s post, I decided to take a look at browser use and see how many of our visitors are still using IE7.  We have been doing a lot of behind-the-scenes work on templating style sheets, and to be honest IE7 compatibility has been the last thing on our list — we build the site for everything else and then come back in and add a hacks file to make it work in CSS.  Now that we are spending more of our time working on things like mobile views, I have to ask whether keeping sites working under IE7 is still worth the effort.

The numbers show that we are pretty much inline with national usage figures — about 4.5% of our traffic comes from IE7.  On one hand I would love to say that is enough of a minority that we don’t have to worry about it, but in absolute numbers that is more than 30,000 page visits per month.

I think it might be enough, though, to warrant taking a middle-ground approach.  Do all sites need to look the same in every browser? (correct answer)  We can therefore move forward with our project and realize that we can still design our site to meet current-generation browsers without completely leaving behind IE7.  We can design our sites so that IE7 users don’t get all the bells and whistles, but still get the heart of the content that you are trying to convey.  This is the difference between supporting a browser and optimizing for it.  We can do one without doing the other, make sure that everyone can use our site, but reserving the majority of our time on the experience that will be shared by the vast majority.

Thoughts?  Where does everyone else stand on the issue?

Wednesday, August 15th, 2012 CSS, HTML, Programming 2 Comments

Emergency Site Now Mobile Friendly

A few weeks ago I was in a meeting where we were discussing how to make websites viewable on mobile devices. Since we had already started incorporating responsive design into the last few sites that we have released I mentioned those as examples. After listening to the list, one of my colleagues asked if the university emergency site had been done as well. I had to admit that it was not, and after looking at it on my phone I also had to concede that it was not terribly mobile-friendly either.

While incorporating mobile views into our sites is an ongoing process — we are adding it to new site designs, not retrofitting old sites to it for the sake of being responsive — that really isn’t a good excuse when talking about the emergency site. By its very nature that is one site that should be easily viewable on any device.

I therefore asked Rebecca to look over the page code and add the appropriate style sheet changes to make it mobile friendly. This was a great first project for her, as it let her start with a small project, learn the concepts of responsive design, and see it through to fruition quickly. We didn’t completely rewrite the page in order to include the “mobile first” concept, but the site code was simple enough that overwriting the default in order to create the mobile view wasn’t a big deal.

So I am pleased to announce both that Rebecca has completed her first project and is becoming an important member of our team, and that the university emergency site is now mobile friendly.

Thursday, April 19th, 2012 CSS, Mobile Web No Comments


I mentioned the other day that I was hoping that Jeff would return from the HTML5.tx conference with some good ideas. I wasn’t disappointed. Beyond the traditional HTML5 topics that one would expect, there was also a presentation on using LESS for CSS. I had never heard of the project, but its essence is something I had been considering for quite a while.

Simply put, LESS extends traditional CSS, allowing the use of variables, nested css elements, mixins, and more. I won’t try to explain each case, the LESS website does a great job of providing simple examples. A five-minute read of their site convinced me of its usefulness.

Making the project even more extendable, you can either run LESS client-side by downloading a javascript library along with your LESS code, or you can pre-compile the LESS file into traditional CSS and use that with your website like you would any other style sheet.

Since we are already looking at retooling our development portfolio, it’s a no-brainer that we add LESS into the mix. I have no doubt that it will increase the organization of our style sheets, and thereby increase our productivity (and sanity levels while tracking values within large CSS files.)

Friday, October 14th, 2011 CSS 2 Comments

CSS3: A Revolution in the Making

It isn’t often that I radically change my opinion about anything web related.  I’ve been doing this for so long that I’ve always been able to adapt and adopt new concepts incrementally.  That mindset was completely shattered this week when I finally took a real in-depth look at the cutting edge of CSS3.

I have been watching its development for a while, but never paid it serious attention because without standardized browser support I knew it wouldn’t be anything we could implement.  Maintaining the main university site means making it accessible to the masses, which in turn means coding to a quite low common denominator.  The nature of the sites we work on precludes us from using all the bells and whistles that can be put onto a site catering to a more sophisticated user base.  Most of my thoughts of CSS3 were therefore that it was basically nice, but mostly aesthetic, improvements that could be incorporated into sites — visible to the more advanced browsers and gracefully degrading on browsers that don’t support the technology.  This philosophy is nicely summed up by the webmasters from Wayne State University.

What I’ve seen in the last few days, though, convinces me that I was vastly underestimating the importance of the HTML5/CSS3 combination.  While it admittedly isn’t here yet, I’m now firmly convinced that it will make modern web development (and developers if we don’t learn and adapt) obsolete.   The introduction of CSS2 was problematic to a lot of developers because it forced a break from our traditional linear chain of thinking and implementation.  CSS3 is going to go way past that. Even imagining what can be done with the technology is going to require a new way of thinking, and to be among the leaders that thinking will have to be way outside the box.

As a quick demonstration, take a look at some of the online demos at the WebDesignerWall blog.  (You’ll need Safari or Chrome to get the full effects.)  These are admittedly isolated demos that serve as proofs of concept rather than elements for a live website, but they show that base HTML/CSS can take the place of a lot of the jquery that is seen as leading edge today.  The line between application design and web design is going to get even more blurred as we are able to do more and more with basic styling.  The gap between designers and developers is also going to narrow, as both are going to have to have an increased understanding of the other’s area of expertise in order to do their own job.

Maybe I’m late to the party in this realization, but when I look at the state of so much web development today that barely scratches the surface of CSS2, I can’t help but think that a lot of developers are going to be in for a rude awakening.  It might take a few more years, but we are going to experience a complete paradigm shift, and we need to start getting ready for it now.

Tags: ,

Tuesday, June 8th, 2010 CSS No Comments

eduWEB: Higher Style for Higher Education Websites

Design and usability: that was the focus of the eduWeb conference session led by Stewart Foss, a former college webmaster and founder of edustyle, a showcase for the best higher education web designs.

Here are some of the thoughts I came away with: › Continue reading

Tags: , , , ,

Tuesday, August 4th, 2009 CSS, HTML No Comments