Infinite Loop

A Web Design Blog by Davide L Rizzo.

[davidelrizzo]

Is the 'Cascade' in CSS obsolete?

In the early days of the web we had basic tags and styling attributes. The styling was tied directly to elements and whenever we wanted to style something the same way again all the styling code had to be copied.

Then came the wonderful world of CSS. Where we could separate the styling from the markup and reuse many times without duplication. The first thing people did was attach classes like "red2" which we soon realized wasn't easy to reuse and didn't take advantage of the separation of markup and style.

As CSS evolved we started thinking semantically and logically. Don't use ids, name classes logically as to what patterns are so they are both human readable and ready to use again later. Classes like "nav" and "col-4" were neat and clean and let us style over the basic tags which were still needed for proper semantics and accessibility. However they were still a bit loose, a project could have many navs which may be styled differently in different places. People coding on different libraries could independent use the same class names for different purposes.

Now we are moving to Styleguide and Component driven design in which you design reusable patterns that can be slotted in anywhere. Patterns using BEM or SUIT class names such as "sg-Btn--small" or "sg-Table-head--dark" clearly identify the library it came from, the component, sub-element and the styling variant in one go. It also dramatically reduces the levels of selector specificity making  easier to customize your base level CSS later.

The very purpose of component based design and naming is that your styling does not bleed into other patterns not even children with the same tags. The task of the proposed Shadow DOM is to enforce this in web components, until then we carefully name our components to stop the styles cascading. It may make our naming a little more verbose but it is much better encapsulation of patterns and much easier to reuse without unexpected style creep.

In a sense, best practice is now is reduce or eliminate the cascading ability of CSS entirely.

[davidelrizzo]

Web icon comparison

I am in the middle of tackling the issue of serving & storing icons in a flexible consistent way across multiple brands, apps and sites. The icons will mostly be used as background images.

Here are the main issues I am facing:

Multi coloured icons - must support this for some brands

Large variations of colour & size - at least 6x sizes and up to 10x colours

IE8 & Retina support - I need to support both

Client side efficiency - download bloat & http requests

Maintainability - for designers to build and export

Ease of use - for developers to implement icons front-end

There are 3 broad methods to tackle them, on exploring all three they all have problems and benefits in some aspects. Here is the breakdown:

PNG images

Multi coloured icons - no problem

Large variations of colour & size - huge undertaking to save every permutation of colour & size

IE8 & Retina support - IE8 does not support background-size so alternate image paths have to be used every time, wasteful download for retina images.

Client side efficiency - very poor, either a separate HTTP request for each icon or huge inefficient sprites. Large downloads for retina images inefficient. 

Maintainability - ok if you set up good templates for both design and export. Custom sprites introduce much more complications

Ease of use - Would need a mixin to serve alternate large retina image and standard for IE8

SVG images

Multi coloured icons - no problem

Large variations of colour & size - only need to store colour variants

IE8 & Retina support - retina no problem, need PNG fallback for IE8 and variable image size on that browser is still a huge issue

Client side efficiency - quite efficient using Grunticon

Maintainability - ok if you set up good templates for both design and export

Ease of use - Sizing in IE8 is still a big problem (if you don't have to support IE8 this is a non-issue)

Font icons

Multi coloured icons - quite difficult

Large variations of colour & size - no problem

IE8 & Retina support - no problem

Client side efficiency - some inefficiencies as with sprites

Maintainability - quite difficult to maintain and update custom fonts for different brands/apps with icons added and changing frequently

Ease of use - Cross browser consistency may be an issue but overall ok.

Here the the summary chart, looks like SVG is the winner by a whisker.

[davidelrizzo]

Date input, what a mess - Part 2

Nearly a year since my last post on what a disaster the date input is and I am still no closer to a solution. I did a fairly detailed analysis from a UX and front-end perspective on what options are out there from the native HTML5 implementations; desktop and devices, to some of the more popular JavaScript plugins and Polyfills.

Hopefully the following table will help anyone else trying to make a decision on which path to take. Date input comparison

One of complexities I discovered was a usability issue based on the intended date range. For example a user intending to enter a date in a range +/- a few months is helped greatly by a calendar widget. However if they wish to select a date of birth back 20+ years a calendar will make the task more difficult. Surprisingly in this case people will still go for the calendar if it's there even if typing the date is possible and easier. One thing I am sure of though, the days of perfectly styled calendar widgets is over. Unless browsers start allowing us to customise the look of the calendar we need to let it do its thing and focus on consistent cross-browser functionality and validation not consistent design (which in some cases can be detrimental).

[davidelrizzo]

Consistent height button rows

You'd think that by now something as common as a row of buttons with consistent size and positioning would be a simple thing. When tackling this recently I discovered a whole world of pain.

I wanted buttons to have a uniform width (so they'd aligned nicely in a grid) and have a uniform height (at lest on the same row). The buttons needed to wrap onto the next line for smaller screens and the text needed to vertically aligned to the middle of the button.

The following demo is my investigation into the options and my first real dive into flexbox. Overall flexbox worked amazingly achieving exactly what I wanted with no additional markup but the support is incomplete even in latest Firefox (23.0). For my real world project I went with the fixed hight (inner extra table-cell) approach because I needed to support IE8.

See CodePen Demo

[davidelrizzo]

We would all love to live in a world where any design can be translated into clean beautiful code. But we still have real world issues like IE and the technical capabilities of devices. Designers need to be aware of them to build the best experience given all of these constraints.

Designers who do not consider code and technical constraints do not take in these real world issues. For example it may be perfectly fine and more engaging to have a different typefaces on every page of a printed magazine. Do the same on the web and the technical constraints of the medium may mean that the result is slow and painful despite the design aims.

[davidelrizzo]

What we really need is a 'relative' media query.

So I was just thinking, media queries are good when we want to make a design pattern work differently in different screen sizes. But it is not helpful when a pattern needs to work with and without a left nav or in two different places that have variable widths that have nothing to do with screen sizes. What we really need is some sort of query relative to the container of module you are designing. That is the only way we will be able to write truly modular front-end design. Looks like I am not the only person to think this, here are some articles on the same topic:

http://ianstormtaylor.com/media-queries-are-a-hack/

http://www.jonathantneal.com/blog/thoughts-on-media-queries-for-elements/

[davidelrizzo]

Strong Layout Systems by Eric Meyer: Eric explains how we have hacked our way through web layout with positioning and floats trying desperately to get some of the functionality we used to have with tables. It looks like flexbox is the way forward and I for one welcome any move that will enable us to position things with complete control while still maintaining content semantics.

[davidelrizzo]

I thought NO!, then I winced, then I cringed then I gave in.. they are pretty much all correct and I have done them all at one time or another. 

After 10+ years of front-end web design I have learnt things the hard way many times. In the old days before all these helpful blogs, stack-exchanges and how-to sites CSS coding was more a matter of trying one property:value after another until IE6 would do what you want and hope the other 'new' browsers would work too.

But I think more people make these errors because either they don't fully understand what a property does or they don't know a better property exists. As someone said CSS is very easy to pick up but very difficult to master!

[davidelrizzo]

Date input, what a mess!

All I ask for is a cross-browser, mobile friendly, simple way for users to enter a date.You would think that the web would be mature enough these days to have figured that one out. But with the injection of mobiles I'm not sure there is a 'best practice' solution at all any more. Lets go through the options:

HTML5 <input type="date" /> This is certainly the most semantic and clean solution, but behaves wildly different in the modern browsers.

Chrome (v23) recently implemented a date picker. The field has the placeholder Day/Mont/Year and a little arrow and there is no ability to change that even if you set a value for the default date it does not show up. The picker does default to that date value at least. The selected result is given in the format dd/mm/yyyy which localised to your preference in Chrome which is pretty cool (mm/dd/yyyy if you are in the US for example)

iOS shows no placeholder or default value. The Barrel Roller is a good tool and now very familiar to iPhone users. The strange one is that the date selected is given in the format 'Jan 1, 2012' which will automatically invalidate any dd/mm/yyyy format validation you may have. To much frustration I discovered that jQuery Validate has a bug so that any field with type='date' will be validated as '##/##/####' even if you set that field to ignore validation!

Android (tested on a 4.0.4 Galaxy SIII) shows no placeholder or default value, has its own date roll selector and inputs the date as yyyy-mm-dd.

IE, Firefox and Safari simply treat it as a text field, with no picker or validation of any kind.

3 Fields styled as one dd/mm/yyyy with auto-tab The auto-tab method I went over in one of my recent posts. It works pretty much everywhere except iOS which seems has a ban on focusing fields using Javascript in any way. (this is also terrible for inline validation). While it is still usable in iOS it is not the most friendly, having to click on each field separately. There are also non-intuitive actions when there is a value already present. You may expect it to select an entire field's text on click and replace all three as you type, which is possible but takes a fair bit more JavaScript to get it right. The end value for this will still need to be validated.

Marked input Marked input is when you have one text field that detects when you type each character placing slashes '/' to style the input as a date. I found this method to work everywhere except on my phone (Android 4.0.4) where it was buggy to the point of not being usable. The other minor issue is that unless you fill non entered inputs with another character such as underscores (eg. 01/1_/____) the width of the text jumps around as you type and is a little annoying. The end value for this will still need to be validated.

Emulated barrel roller I had a go implementing mobiscroll a Javascript barrel roll emulator. This is a fairly robust solution. The main issue is that it is not a familiar solution for desktop users. Other minor issues were that I found it slightly buggy on older Android devices (although still usable) and when you switch a phone to landscape mode the 'Set' and 'Cancel' buttons are completely hidden. This could in theory be changed with restyling.

Old school 3 dropdowns The old fashioned approach of a DD, MM and YYYY select fields, which is pretty much the standard for older forms. The big advantage is that this solution works everywhere every time. The main issue being that scrolling is often very long. The final date still needs to be validated too.

Open text field This solution can work but to make it user friendly you need some very robust and flexible validation, eg. dd/mm/yyyy, yyyy-mm-dd, d Month YY and ddmmyyyy are all valid options from a user point of view.

So there are a few options. The semantic in me wants me to just use the HTML5 date but it does require some work to make it smooth across all browsers. Here is some interesting further reading: Can the HTML5 date input field survive?

I think in this case it is up to personal preference and which tool works for your exact circumstance.

[davidelrizzo]

CSS Yin-Yang with 1 html tag

Mind = blown.

I guess I just never thought you could make that shape so simply.

Many more from: http://coderwall.com/p/xrxaxa

[davidelrizzo]

Toggle Buttons

It seems like toggle buttons are all the rage now. With the onset of mobile design big buttons are much more friendly than tiny radio and check boxes and it seems that with native iOS controls working that way, large buttons are now an acceptable method of replacing them.

I had a a go at designing these radio buttons with large toggle buttons. With the intention of keeping the code minimal and semantic and having a non JavaScript fallback. My idea was to style the <label> as a button and toggle its state whenever the radio associated with it is checked. This can be done with JavaScript or even without using the CSS3 sibling selector "+". It uses virtually the same amount of HTML you would need for ordinary radio inputs. 

This technique could easily be used for checkboxes too or replacing the radio or checkbox with custom background imaged embedded in the label.

One gotcha I found is that iOS devices do not allow a user to click a label to select its associated input. Even if the label has a 'for' attribute. You can overcome this by adding an empty onclick="" to the label (for some strange reason)

Toggle button JSfiddle

[davidelrizzo]

Can we please just drop "the fold"

I have been working in web design for nearly 10 years, and people (mostly from marketing and print backgrounds) still ask me where the 'fold' is.

Please.. please do not ask me that question. This is why:

a) Where the fold actually is: The fold is the bottom of the browser window, below which you have to scroll to see content. If you really really must know where it is, detect it with JavaScript and create dynamic content to work around it. Otherwise the answer is 'it depends'. There is no such thing as an 'Average' screen resolution 85% of people (worldwide) have screens larger than 1024x768 and the most important factor is that Screen Resolution ≠ Browser Window, many people with large monitors (including myself) browse with small arbitrarily sized windows, sometimes multiple different sized ones open at the same time.

    Visual representation of 500 browser visits to CSS Tricks:  

When you factor in tablets and mobiles (15-25% and growing rapidly), there is now a growing base of customers who (can) view in tiny screen sizes as well. And don't even get me started on where the scroll is on emails, preview pane sizes for email are about as varied as cats on the internet. This all points to the fact that 'the fold' is an incredibly blurry range that varies wildly based on hardware, software and user preference.  

b) Is knowing where the 'fold' is even useful? Don't get me wrong, I am a strong advocate of Information Architecture and just like a newspaper it generally makes sense to keep important content towards the top of the page (some of the time). But designing a page around some invented bottom line is just making your user (and web designer) suffer. Lastly, research has shown time and time again that people are happy to scroll... right to the bottom if they need to.

So please, don't restrict your design for a print legacy myth that does not apply to web pages. There.is.no.fold 

[davidelrizzo]

Formatted Date of Birth Field

I recently had a look at a best practice date of birth field. I'm talking DD/MM/YYYY type inputs. Lets have a look at the aspects of this input:

Data entry method

The most common technique I have found is using drop-down lists for each number. I believe this offers a poor experience as the user may have to scroll quite a bit, slow and slower on mobil. The older a user is the more they have to scroll.

At first glance you would assume a date picker is the best solution for any date. However this turns out to be a poor user experience for date of birth as the picker defaults to the current day or something like 01/01/2012 which is inevitably years away from you birth year.

So text input seems to be the simplest and easiest method in the end. Date of birth is a very commonly entered value and users are likely to be quite quick at typing it out so this seems the best approach.  

Formatting and Separators Even once narrowed down to text input there are several approaches. Allowing or requiring the user to enter the separator (forward slashes) is only making things more difficult. There are some approaches that use JavaScript to input them into the field, but I think this is overkill, the simplest approach is simply to supply 3 input fields and style it as if it was one big box. This is quite intuitive when you use it.

The separators can be added as text, images or pure CSS styling. The most elegant solution would be to add them as pseudo element but unfortunately you can't add an :after pseudo element to a closed tag like input.

Auto-tab One option is to have the input jump the cursor position to the next box once you have entered the full number of digits for each field. This further re-enforces the impression that you are typing in one field. You need to be careful however that this works for your users and that it behaves as expected on mobile & tablet if that is applicable to you.

Input type The type attribute can simply be set to text , alternately you can have a play with the HTML5 values. Number would be the most semantically correct, however some browsers  (no I'm actually referring to Chrome for once) do strange things with this. eg. Chrome places a comma after ever 3 digits and also numeric stepper buttons that do not work in any way in this case. For mobiles using the number or tel type in most cases makes the on-screen keypad display as numbers only, which is advisable.

Validation I won't go into too much detail here but validation not only has to check that each individual number is within bounds (easy with day and month, but how old and young a user will you accept), but also that the combination of all three inputs make a valid date. Also consider preventing any input that is not an integer, prevention is usually better than an error message.

Here is a jsFiddle for the final Formatted Date of Birth Field that I built showing one version with JavaScipt auto-tab and one without.

enjoy!

[davidelrizzo]

Web Design Priorities

When working on any web project big or small there are a number of factors you need to consider carefully. I am referring to web design specific priorities not general project priorities like time, money, resources etc.. This is rough list of the main ones I think through before starting any project. In an ideal world we would try to give them all top priority but in reality this can rarely be done, often achieving one will mean compromising on another.  

Functionality The site (or App) needs to do the things required of it. Most times this has the highest priority but sometimes there are lesser functions that are nice-to-have.

Design/Graphics The site needs to be aesthetically pleasing. Sometimes this is important enough to trump usability or even functionality. Design is usually the number one culprit for reducing other priorities in this list. As a web designer gains experience and as browsers support fancier code this becomes easier. Sometimes design can be too low of a priority. I can't tell you how many boring back-end web services I have seen where the lack of design ends up eroding the usability. 

Usability The site needs to be easy and intuitive for people to use. Other priorities often reduce usability more than we would like, usually design. Web designer can over time get a feel for decent usability but absolutely nothing beats real user testing.

Accessibility There is almost no situation where a web designer will know the exact skill-set of all users and exact software/hardware used to view a site now and into the future. Therefore you should build for as broad a range of users as possible.  Accessibility falls under four broad categories:

Users: The technical skill, age, gender, cultural background, physical and mental abilities of your users can all impact the site design. From element size to colour, text, images, sound and video, all these things can make your site more or less accessible to certain user groups.

Software: What browser is the site being viewed in, what plugins do they have Flash, JavaScript? It is virtually impossible to support all browsers, you need to make a call on what percentage of users will not be supported. Using Progressive Enhancement is the preferred method of catering to both old and new technologies while enabling content/function to the widest possible base.

Hardware: Is the site being viewed on a PC with a huge monitor, laptop, tablet, mobile? Do they have fast, slow or even persistent internet speed? Sites should always be as fast to load as possible, load only parts that the user wants as they need them where possible. The technique of Responsive Design is quickly becoming the preferred method of supporting varying devices and screen sizes. 

Search Engine Optimisation: While not technically a facet of Accessibility, if no one can find your site it will not be accessible to many people at all. The layout, content and code of site may be impacted by SEO depending on its priority.

Maintenance Even if a site perfectly meets user and client needs it may be a nightmare to maintain. Depending on the skills and tools available to those maintaining and building the site priorities may be compromised to achieve a site that can be maintained sufficiently. Code, files and names should all be as clean, neat, concise, valid, logical and Semantically Correct as possible.  

At the end of the day all web site design involves compromises. It the the job of a good web designer to choose and win the right battles.

[davidelrizzo]

I remember sometime back around 2001 when I discovered CSS Zen Garden, it changed the way I saw the web forever. A site who's style could drastically change with no change of HTML, at the time it was a revolution! CSS 1k is a similar project in which the CSS file can be no larger than 1k. Pretty impressive.

[davidelrizzo]

Clinically what I do is "Allow people to interact with Machines", in essence what I do is "Design experiences". The truth is somewhere in between. Great and inspiring article.. 

[davidelrizzo]

Is the most advanced tool the right one for the job?

I recently had a colleague advise me to use SASS rather than plain old CSS. I have seen it around for a while but until now it never really grabbed me. SASS and its newer variant SCSS is a metalanguage for CSS which lets you add programming style variables and functions to CSS. This is a really brilliant idea, by allowing you to add object-oriented type mechanisms to CSS you could in theory build far more complex CSS in fewer lines of code and maintain it with less difficulty.

Sounds great so far, so what could possibly be the drawbacks? Firstly you need to install a Ruby compiler to get the .scss/.sass extension to work. Not to difficult.

Secondly .scss files compile into .css, so I imagine that if anyone edited the raw CSS, you would have versioning issues when going back to the SASS. This could be an issue in an team where separate developers have access to the same files especially if some don't know anything about SASS.

Lastly it is only really more efficient if you are already familiar with the advanced programming concepts which it offers. If team members have varying degrees of coding expertise, moving to a more advanced language may add another hurdle to maintenance.

So I will do a little more investigation before I jump on board the CSS framework bandwagon. Ohh, I just discovered LESS and XCSS, looks like a late night for me.