Setting Default Styling for Custom UI Components

I thought I’d share a challenge I’m facing at the moment. A lot of modern JavaScript frameworks like React and Angular encourage building reusable UI components. Using JavaScript and HTML templates seems like an excellent approach to development on larger sites but styling these components can bring a few issues.

Browsers can handle styling standard HTML web components, like <select> or <button>. They may vary in how they display these but they all have a default way which can then be overwritten with CSS. This is stored as a kind of internal CSS class in the browser and is easy to overwrite as it has almost zero specificity. Adding an element selector ‘select’, a class ‘.picker’ or an id ‘#picker’ will easily take control over the styling.

The problem arises when we create custom components that don’t have any default, zero specificity styling. Any styling that we do add when we design components has specificity so we immediately have a fight on our hands for which styling declaration gets control. We need some level of default styling, usually for layout as much as anything, to ensure that the browser cannot just show a mess of HTML elements.

Here are a few examples of how default component styling could be set and the problems associated with each approach.

  1. Setting the CSS in an external stylesheet

    We set the styling in its own CSS file. I’d say that this is the approach used by most UI tools like Bootstrap or jQuery UI. Various HTML elements in the component are given classes, which can be overwritten.

    The problem is that they can only be overwritten by using higher specificity or by making sure that the overwriting style comes after the external CSS in the document’s source order. It also means an additional HTTP request to load a usually small amount of styling data.

  2. Setting the style in a style attribute

    We could add style attributes directly into the HTML tags. The problem here is obvious – super high specificity. This makes the styling very difficult to overwrite. You’re pretty much forced into using ‘!important’ declarations in your CSS, which not only feels wrong but really leaves you with nowhere to go.

    It goes against the separation of concerns – content and styling but as this is intended to be default styling, which we would hope to overwrite, I’m not sure this matters.

  3. Setting the style in a HTML <style> tag

    We could place a block of HTML with <style> tags directly before or after the component HTML so that it effectively ships together. Placing <style> tags in the <body> was invalid in HTML4 but, if I’ve understood it correctly, can be used in HTML5 by using the scoped attribute, e.g. <style type=”text/css” scoped></style>. Browser support for this to be properly valid is not great at the time of writing (early 2016) – we get warning messages in consoles or code editors – but it seems to display as intended.

    The problem with this approach is that the style is declared in the <body> whereas the overwriting CSS is probably declared in the <head> and so will not overwrite it without upping the specificity.

    W3C Recommendation – Stylesheets
    W3C Recommendation – Style Scoped

  4. Setting the style with JavaScript

    The final option is to set styling using JavaScript, which effectively just inserts style attributes into the component’s HTML elements like in approach 2.

I’m wondering if there may be a solution where we have a default styles object which defines style properties in our existing component JavaScript file. We then check to see what styling is applied using the browser’s getComputedStyle() function. For each of the properties we check if a rule is already set, presumably by CSS that is in the <head>, and if not we apply the style from the object. It’s almost like required validation for styling. I don’t imagine it’s going to be very efficient but it may be a way of ensuring a minimum level of styling without restricting additional styling via CSS. Assuming that our script file is at the end of the <body>, by using only the existing resources we could save an additional HTTP request.

Developing in Codepen

A look at why and how I use Codepen for front end development work.

Background

I work on a web app with a development team. We use AngularJS with a RESTful API. My role is looking at the design and UX side of things and scoping out how a new feature will look and behave in a web browser, or, I should say, in various browsers at different screen sizes.

I generally do my work up front. I’ve always been a design in HTML and CSS kind of guy. To me, with my skill set, working in a graphics editor takes as long as coding it so it makes little sense for me to do the work twice.

Until recently, I’ve been using static HTML and then another developer has added the binding and data. Where the feature is on a new screen I can go a step further and create a dummy data object, to represent the data returned from the API, and actually do the binding as well as create any custom behaviour.

Working on existing screens has been much more difficult. It’s almost impossible to add new data, binding and behaviours without breaking the existing code. To use a dummy data object I need to intercept the real data retrieval and replace the object, which stops the page working when wired up again. However I work things, I’m having to check in code which is not releasable.

A new way of working

I’ve started using Codepen to abstract away the new feature. I set up a new pen, import any existing dependencies and then create the HTML, CSS and JavaScript for the new feature in isolation.

This means that the original project code does not get touched and broken. As the next developer brings in any model/schema changes he/she can bring in my front end code so we don’t have any breaking check-ins.

By importing the dependencies – JavaScript libraries, CSS – we avoid any clashes or inheritance issues and additional work trying to integrate my code.

It also means I can give the new feature my full attention without having to use other parts of the screen, for example, if I’m working on a modal window, I don’t have to go through the usual page processes in order to call it.

I’m using Codepen in the way it was intended, as a front end playground, an environment where I can experiment with different ways of doing things. The results are displayed in a frame, updated instantly as you type, which makes working much faster – no more manual refreshing or rebuilding.

From what I’ve described up to this point, this abstraction could be done by making a copy of the page but copying the HTML page, the CSS and JavaScript and changing all of the references between these files is quite a headache. Believe me, I’ve been there enough times.

One of the massive advantages of Codepen for a designer is the ability to fork pens, so you just hit one button and you’ve got an exact copy of the pen you were working in, making it very easy to create a few variations of a design.

As each pen is available on a public URL it’s easy to share designs with colleagues or clients and they can see a working prototype – much better than a static screenshot. It also means that links can be embedded in documentation. Personally, I feel that now web animation has become mainstream, it’s important to be able to show how screen elements transition between states, how things appear/disappear and demonstrate where the user’s attention is drawn through processes. Static screenshots just don’t cut it any more.

Final point. Designing in the browser with work stored in the cloud is awesome for design. I could be out and about and suddenly see some inspiration for something I’m working on or get a new idea. Rather than hope I’ll remember it, I can quickly create a new pen or fork an existing one and add some code or notes there and then from a phone or tablet. I don’t have to hope I’ll remember or wait until I’m back at my desktop. It’s exactly what the web should be.

What I Learned in 2014: Part 3 – The Best of the Rest

This is the final part of a three-part article looking back on new things I’ve discovered in 2014. This part is just a round up of all the other bits and pieces not mentioned in the other parts and a bit of a look forward to 2015.

Google Analytics

I’ve used Analytics for years but haven’t really used it in any depth for the last couple of years. It’s changed. Quite a lot. All in a good way. It can do a lot more now than before. It seems to be moving closer towards the Webmaster Tools and used well can actually help you improve not only the user experience through design but also the performance of your site through the Behaviour > Page Speed data and suggestions.

ASP.NET MVC

I don’t do a lot server side but colleagues of mine have made excellent use of the EditorFor functionality and partial views to create reusable dynamic page components.

My biggest discovery has been Bundling and Minification of JavaScript and CSS assets. It allows you to create bundles of files and then concatenates them into one long file before minifying it and changing the references. This could mean one single request for all JavaScript, which is then cached – much better for performance and page loading times.

Responsive Web Design

I still feel like I’m quite new to this but have made some good progress this year. I now understand the basics of mobile and viewport sizing and scaling. I’ve also got the hang of media queries for changing font-sizes and positions of elements based on screen width. I’ve kind of taught myself by looking at the code of sites that do it well rather than by using any tutorials. It seems to be a good shortcut for now. There’s definitely a lot more to learn here but I’m pleased how painless it’s been so far.

Brackets

I’ve recently started using Adobe Brackets, which is an open source code editor available from brackets.io. It’s got everything I need, looks good and from the progress I’ve seen in its first few months it’s going to move pretty fast. The thing I love about it is that it’s built in front end technologies – HTML, CSS and JavaScript.

To Do List for 2015

So, now I see how much I’ve learned in the last year it’s time to start thinking about what’s next for 2015.

One obvious area for me is learning more about SVG. It would be nice to reach a point where any graphic that isn’t a photo could be created in CSS or SVG. I’d quite like to move away from icon font libraries in favour of SVGs to reduce a bit of bloat.

The other big area is responsive web design, in particular responsive images. Sending large images to mobile devices is bad news and should be a quick win on the performance front.

I’m sure there will be a lot more that crops up in 2015 as I find a need for it and I may even start learning things that haven’t even been created yet.

I hope I can help others to learn more too in 2015.

What I Learned in 2014: Part 1 – HTML, CSS, Fonts and Images

I thought I’d take a look back through all the new tech that I’ve learnt in 2014. Most of it is genuinely learning new things from scratch but some is polishing up on things I haven’t used for a while or taking things further than I had before. It’s a much longer list than I had expected so I’ve broken it down into 3 articles. Hopefully, it’ll be handy to come back to in the future when I’ve forgotten it all again.

HTML

I’ve discovered a couple of new things in HTML5. As they’re APIs I uess they’re really Javascript more than HTML. I’ve learned a bit about the Speech API – speech synthesis (turning text content into audio) and speech recognition (turning microphone input into text). It’s still early days and, at the time of writing, only works in Chrome but has some exciting possibilities for both greater accessibility and the ability to use the web without having to look at a page.

My other discovery this year has been the progress element for adding a progress bar to a page. All browsers make these look very different by default but it’s not too hard to style them for consistency if that’s what you want. Like many other HTML5 elements it has nice fallback syntax for non HTML5 browsers.

CSS

I’d previously only used transitions for adding a bit of a delay into hover effects but it’s great for changing the size or position or page elements too. It works very nicely combined with transform:rotate. I’ve actually found a great practical use for transitions in creating a multi-state button, which changes from displaying “Save” to “Saving…” and then “Saved” with different styling for each state.

I’ve now learned how to do proper keyframe animations in CSS without the need for any Javascript. The possibilities are endless. Just need to make sure I’m not chucking them in everywhere for the sake of it.

It’s been a while since I’ve had to deal with print media styling. I was hoping things would have improved in the last few years but still find it quite tricky. I found myself having to use a lot of !important in my properties to gain control. Maybe considering print later in the design process rather than from the outset was a mistake with hindsight?

Fonts

I’ve started making full use of web fonts, particularly Google Fonts. The basic implementation is very easy, just a link to an external CSS file which loads the font-face, but they’re not always consistent across operating systems and browsers so it takes quite a bit of testing to be sure your chosen font will appear nicely across the board. Working out whether to install additional font variants for bold and italic or whether to just let the browser apply its own faux bold and italic effects is another issue. Given the extra HTTP requests and page weight I’m tending to stick with “web safe” fonts for body text and only use web fonts for headings or elements requiring a bit more styling.

I’ve found that I can actually create my own font variants by playing around with the CSS letter-spacing property, using things like letter-spacing:-1px, on “web safe” fonts.

Images

I haven’t learned much new with images but have found a couple of handy new techniques. I’ve started using base64 format for smaller images instead of referencing external files. This means putting the file data into a continuous stream of characters in the CSS file instead of using a path another file. This still gets cached as part of the CSS but prevents an additional HTTP request. As base64 format is actually a little bigger in file size than refreencing the image directly it only makes sense for smaller files. For larger files it makes more sense to benefit from the smaller file size at the expense of the extra request. Good CSS editors will also show you a preview of the image as you hover over the base654 code, which is handy as it’s completely unintelligible.

I’ve started using some very basic SVG. It seems fairly straightforward but I’m still not sure about the sizing and scaling. One for next year.

Introducing… Dinowebs.net

DinowebsAs a web developer and programmer I’m always on the look out for solutions to little problems. How do I do that? How can I make that do this without X, Y and Z happening? You get the idea.

My first port of call is always Google. The way I see it is that I’m unikely to ever have a technical requirement that somebody else hasn’t had before. In fact, it’s highly likely that hundreds, even thousands of people have faced the same challenges. By using the right search terms on Google I can usually find the answers to my problems. This inspired me to build a technical blog. It’s my way of sharing what I’ve learnt and, hopefully, helping someone else out.

As well as trying to help others it’s also tremendously useful to me. Every time I overcome an obstacle I write about it and provide the solution giving code examples where I can. It’s very handy to just be able to just come back to it rather than try to remember things that I’ve done in the past. I also use the site for setting up links to resources I like and use. Again, it just saves me time looking for things.

My site is called Dinowebs, http://dinowebs.net. The site covers all sorts of coding and web development subject matter. Please take a look.