CSS Standards - Are there any out there?

You know them… You love them… Standards.

Ok, so some people love them. Others? Not so much. And it shows. In the wonderful world of web development, there are a multitude of things that developers struggle with. For starters, there are 79 browsers out there today. That’s quite a few. Now granted, there are only a few layout engines:

  • Gecko is developed by the Mozilla Foundation for Firefox.
  • KHTML is developed by the KDE project, primarily for use in their Konqueror browser.
  • Presto is developed by Opera Software for use in the original Opera, now referred to as Opera Presto.
  • Tasman was developed by Microsoft for use in Internet Explorer 5 for Macintosh.
  • Trident, which was a code name for Mshtml.dll, is developed by Microsoft for use in the Windows version of their web browser, from Internet Explorer 4 to current.
  • WebKit is a fork of KHTML by Apple Inc. used in Apple Safari, Chromium and Google Chrome.
  • Blink is a 2013 fork of WebKit by Google used in Chromium, Google Chrome and now Opera.
  • Servo is an experimental web browser layout engine being developed cooperatively by Mozilla and Samsung.

There may be a few others, but as you can see, even from this list, they are typically forked from one of these. This set alone provides a ton of variation needed to be taken into consideration when laying out your pages and site in general. Especially when it comes to today’s web and responsive, adaptive, and interactive site demands. To top it off, a browser may keep numerous versions of their web browser “alive”. Each of which has its own demands.

(Ehemm… IE)

So back to standards…

Why is so hard to keep them? The web world is a fast paced world. The development world is even faster. A developer is expected to develop an amazing piece of work for a client in a short amount of time and do it all within a reasonable budget. Reasonable is a very operative word here as this word holds vast differences in designer, developer, and client minds. All this means that often times, a developer is jumping into an older code base (for redesigns), in and out of their own code (on fresh builds), or quickly editing something live (EEK!). Fast paced… In and out.

Bootstraps, Libraries, and pre-built themes have definitely helped the designer, developer, and client in many ways, but even with these, variation can sometimes kill a design. Take a look at the current, widely used bootstrap. This is one of the best things that has happened for developers in terms of cutting development time, markup time, and shorter deadline demands. However, there are many things that can create headaches in this. For example, look at updating bootstrap. The current version, at the time of writing this, is 3.3.1. As the browsers and technology used improve, there are new classes, pseudo-classes, techniques, etc. that can be used. jQuery is also ever changing. This can greatly effect your site and UI, (User Interface), which in turn changes how users feel about the site when they visit it. If you have an older build and decide to update to the newest release, you might notice a lot of your design elements look different or act different.

Updating is not a big deal, but it could be made much easier if simple standards were followed. Download the latest copy of bootstrap and look through the CSS inside. If you have a copy of an older version, compare the two files with a comparator such as Beyond Compare. Even the classes and ids that are mainly unchanged are off. This makes it harder to rewrite or correct updated mishaps for a theme, previous design, etc.

Where are you going with this?

Why not do something simple to help correct the issues? If the styles were alphabetized they could be compared quite quickly. Not only could they be compared, but edited, built, updated, etc. Take a look at one of the button classes used in bootstrap.

<code>.btn {
    display: inline-block;
    padding: 6px 12px;
    margin-bottom: 0;
    font-size: 14px;
    font-weight: normal;
    line-height: 1.42857143;
    text-align: center;
    white-space: nowrap;
    vertical-align: middle;
    -ms-touch-action: manipulation;
        touch-action: manipulation;
    cursor: pointer;
    -webkit-user-select: none;
       -moz-user-select: none;
        -ms-user-select: none;
            user-select: none;
    background-image: none;
    border: 1px solid transparent;
    border-radius: 4px;
}

This could be much easier written and read if it were alphabetical.

<code>.btn {
    background-image: none;
    border: 1px solid transparent;
    border-radius: 4px;
    cursor: pointer;
    display: inline-block;
    font-size: 14px;
    font-weight: normal;
    line-height: 1.42857143;
    margin-bottom: 0;
    padding: 6px 12px;
    text-align: center;
    touch-action: manipulation;
        -ms-touch-action: manipulation;
    user-select: none;
        -webkit-user-select: none;
        -moz-user-select: none;
        -ms-user-select: none;
    vertical-align: middle;
    white-space: nowrap;
}

Now if you need to modify or add something, you can go directly to the area it would/should be in for the element. There is no need to hunt for something or search to see if it has been included yet. This also removes a very common thing I see regularly in larger library builds or builds which are performed in teams. Duplication. Duplicated attributes, especially in larger class elements are atrocious. Take a look at the following and you can see where the btn class has been edited or appended to at least twice (assuming).

.btn {
    display: inline-block;
    cursor: inherit;
    padding: 6px 12px;
    margin-bottom: 0;
    border: none;
    font-size: 14px;
    font-weight: normal;
    line-height: 1.42857143;
    text-align: center;
    border: 1px solid transparent;
    white-space: nowrap;
    vertical-align: middle;
    -ms-touch-action: manipulation;
        touch-action: manipulation;
    cursor: pointer;
    -webkit-user-select: none;
       -moz-user-select: none;
        -ms-user-select: none;
            user-select: none;
    display: inline;
    background-image: none;
    border: none;
    border-radius: 4px;
}

You can see that there are multiple double entries in the class example above. The display, cursor, and border attributes have all been duplicated. Border has actually been duplicated 3 times, 2 of which were the exact same.

I could be over thinking things a bit, but it just seems to me that we all need to think about what we are making before we put it out there. Does anyone have contrary thoughts as to why this would be a bad practice? I would welcome the discussion. I think it's important to keep an open mind and be responsive to learning new things and ways to do things. 

Happy markup and happy coding!

Share this post

Comments

comments powered by Disqus