1. A new home

    I’ve finally pulled the plug on the custom-built Rails CMS that I was using to power my site, and moved (most of) what little I’ve actually ever written over to Tumblr.

    Mentally it’s been a hard barrier to cross for me; I’ve always been a believer in hosting your own stuff, and not handing the keys over to a third party. But I just can’t justify taking the time to update and maintain something that I barely ever use.

    So Tumblr it is, and without that particular stress maybe I’ll have a little more time to actually make stuff, which is what I really enjoy doing anyway.

    1 year ago  /  0 notes

  2. Putting the Development into Front-end Development

    Rebecca Murphey recently wrote a post entitled ‘A New Baseline for Front-end Developers’. It’s a great post, and it nicely echoes some of the feelings I’ve been having recently about how this little thing we call ‘front-end development’ is changing.

    You see, up until quite recently, front-end development hasn’t really been about programming. Marking up content, adding styling via CSS, a bit of copy and paste scripting here and there for interactivity, FTPing up to the server… all very declarative, informal, and ‘un-programming’ like. And this has been a great thing - the fact that you don’t need a full-on neck beard and a Computer Science degree to pull together a simple web page is undoubtably one of the most important and beautiful things about the web.

    However… the web is moving forward at great speed, and our sites are increasing in size, scope and complexity. In order to be able to deliver professional front-end systems that are adaptable, scalable and maintainable I really believe that we need to stop being afraid to treat front-end development as development, and embrace new ways of working that are appropriate to the scale of the task at hand.

    I’m not going to go into any detail about what I think those systems and tools are - Rebecca does a great job of outlining many of them in her post, so I won’t repeat it all here. But what I do want to emphasise is this: Front-end development is growing up, and in the years ahead the average front-end development workflow is going to start looking a lot more like a ‘proper’ programming workflow. If you want to still be relevant as a front-end developer in 2015, you need to start thinking like a programmer and getting to grips with programmer tools and ideas, because modular architectures, pre-processors, version control, testing and the like are all going to be essential skills for a professional front-end developer to have.

    Some people seem very apprehensive of this idea, possibly because there are a lot of more design-focussed front-end developers out there who feel uncomfortable with a more ‘programmery’ way of working. But many of these tools are actually very straightforward to use once you break the mental barrier of using the command line, for instance, and many concepts such as creating modular CSS architectures can really help you think in a more structured, organised way about design, too.

    In short: Don’t be afraid to embrace the development part of front-end development. You are going to be left behind if you don’t.

    1 year ago  /  1 note

  3. Content Management, Markup and Doing it Wrong

    A few days ago I put out a poorly worded tweet about my feelings towards content management systems that leave traces of their own HTML in the frontend markup of the sites that they power. I said:

    If I can tell what CMS you are using by looking at your markup, you are doing it wrong.

    Of course, my emphasis here was all wrong - it sounded like I was putting blame at the feet of the user, rather than the CMS, which is not at all what I intended. After getting a few questioning responses, I tweeted a clarification:

    To clarify: If I can tell what CMS you are using from looking at your markup, *your CMS* is doing it wrong.

    What am I talking about here? In my mind — and in vastly oversimplified terms — a CMS should exist to provide a nice way to store structured data, map URLs to some kind of template/page and give you access to the data stored within it via some sort of templating language.

    It is definitely not the job of the CMS to wrap that data in it’s own markup. How can it be? It can’t know ahead of time how I want my markup structured. It doesn’t know the template context that I’ll be using that data in, or how I like to write my markup. It doesn’t know wether I want to use double quoted attribute values, or if I want to add microformats when I output it, or whether I’ve decided to use an OOP-style CSS strategy (and it’s accompanying bevy of classnames) for my project.

    So let’s step back a little and look at the different ways that a CMS can include markup in their output. I’ve started by lumping them all together, but that is a little unfair - some CMSs do this in ways that are far more toxic than others.

    Starting at what I see as the optimum end of the spectrum we have content management systems that quite literally provide you with a blank slate - no default templates, no default markup. ExpressionEngine is a good example of this kind of CMS. It gives the developer a templating language powerful enough to extract content from it’s structured data store (the structure having previously been defined by the user) and you have complete control over what markup you choose to wrap around the discrete chunks of content. It has a powerful plugin architecture, but instead of these plugins providing direct HTML output, they typically just extend the templating language to give you extra tags to work with, so you can once again use your own markup to display the content with.

    Then we have systems like Wordpress, whose templating language similarly attempts to provide you with access to the discrete items of data within it’s database. However, this templating API often returns content ready wrapped in HTML, such as when retrieving a list of categories or pages. Thankfully you can often customise this markup by passing extra variables into the function that is being used to retrieve the data, but this still feels inelegant to me - why jump through all these hoops when you could just give me back the data and a standard way to iterate over it and then I could build my own markup around it?

    A perhaps bigger issue is that because the Wordpress core has set the expectation that generating output in this way is a good way to do things, plugin makers have followed this convention, but often with less regard than the core dev team for providing ways to override the default HTML output that they produce. So by using these plugins you are relying on the (often pretty shaky) frontend development expertise of the plugin developer to craft your markup for you. Not ideal.

    And then towards the other end of the spectrum we have systems such as Drupal, which output large swathes of HTML by default, and often with little or no regard for correct use of semantics or for giving the developer the ability to override the markup with their own, or even customise small parts of it, such as the class names used. Each third party plugin typically brings it’s own large chunk of HTML output with it, which often reflect the plugin authors own style of writing HTML and which rarely (if ever) meshes seamlessly with the other generated output that is sits within.

    Now, don’t get me wrong. I do think there is a place for content management systems that come with pre-packaged templates, such as Wordpress with it’s default themes. Obviously there will always be a large number of non-tech savvy people who want to set up a blog and don’t want to have to learn a bunch of markup to do so. But the templates should be just that, templates - and they should be directly editable as such. No one should have to go passing umpteen arguments into a function to customise the classnames attached to their unordered lists.

    And, perhaps more controversially, I think that professional frontend web developers, those who really understand the difference between good and excellent frontend development, should steer away from these content management systems (or else be prepared to spend hours digging around in their internals to wrangle the markup to fit their own standard and style).

    Yes, generated markup can save you time. But you can easily create a library of reuse-able template components for a CMS like ExpressionEngine that give the same time saving benefits but which is written in your own style, and more importantly can be easily customised to fit specific use cases - adding microformats, removing superfluous class names, or single quoting those attribute values… should you feel like it.

    In short, I think that markup is too important to be left in the hands of the people who make content management systems. They all too often don’t care enough about it, and they can never know the context that you will be using it in, and so in my opinion they shouldn’t be trying to guess.

    2 years ago  /  0 notes

  4. jQuery URL Parser v2.0

    I finally found some time to rewrite my jQuery URL parser plugin over the last couple of days. The new version (v2.0) is up on Github now, and is pretty much a ground-up rewrite so should be much nicer to work with.

    It’s got a much nicer and more consistent API now, and has some added functionality over the first version, including being able to get parameter values and/or segments from the fragment (anchor) part of the URL.

    The docs should explain it all in more detail - any bug reports, queries or feature requests please add to the project’s Github issue queue. And please note that this new version is not backwards compatible with the 1.x branch!

    jQuery URL Parser on Github

    2 years ago  /  1 note

  5. On variables and mixins in CSS

    So in a previous post I talked briefly about my ‘wishlist’ for CSS3 (or beyond) – additions to the language that I would really like to see implemented in order to give us a better, more flexible way of tackling a wide variety of issues.

    Out of the five things I mentioned – Basic math, delegation, positioning model tweaks, constants, mixins – the last two are perhaps the most straightforward. Whilst in the post I talked about better tools for problem solving, variables and mixins are really more about being able to write cleaner, more maintainable and flexible CSS code with a better separation from the associated HTML.

    I’m going to go into a little more detail on what I actually mean when I talk about variables and mixins in CSS, how they could help us write better code, and why they haven’t yet been (and may never be) implemented.

    Constant Variables

    Before I start talking about variables in CSS, a quick word on terminology: I use the term ‘variables’ here because it has gained some popularity, but it would really be more correct to describe them as ‘constants’; their value, once assigned, is not expected to be mutable over the course of the document.

    So, the basic concept is that you would be able to define a variable that holds a value (such as a hex colour, or a width) and then be able to use the name of that variable to refer to it later on in the stylesheet. So you could do something like this:

    That way, when your company rebrands, to change the branding colours and fonts throughout the site you would be able to update the value of just one or two variables, rather than having to trawl through your stylesheets looking for instances of that colour or font-family.

    Sounds good doesn’t it? This idea is certainly not new, and has cropped up repeatedly in one form or another over the last ten years or so. A few members of the W3C have even written a detailed spec for it, and it was even implemented in Webkit nightlies for a while (it was removed because it’s implementation in Safari would have been “hugely popular”, but they didn’t feel confident enough that the spec wouldn’t change in the future and thus leave them having to support an outdated implementation).

    Yet this concept keeps on getting repeatedly shot down on mailing lists and influential people in the W3C such as Bert Bos (one of the original formulators of CSS, nonetheless) have written at length about why this idea will not get included in the spec anytime soon, if ever.

    This is a real shame, in my opinion. There is a clear demand for this feature in CSS, and the arguments made against it just don’t work for me. Some of Bert Bos’ arguments in the aforelinked essay seem almost laughable:

    ”…it is quite likely that somebody who is trying to learn CSS will give up learning it when he sees that style sheets that occur on the Web don’t actually look like the tutorials he started from.”

    …which sounds like an argument against progress in any web development language (or in any other programming language at all for that matter!) and is clearly nonsense – what about all the new additions to CSS to be implemented as part of the CSS3 spec, for instance?

    He also talks about the ‘implementation effort’ of including variables/constants in CSS. This is another argument that I have no time for – I just don’t think that (within reasonable limits) the W3C should be concerned with how difficult features are to implement. The Webkit nightlies implementation has already shown that this is achievable, and if this was to be included as part of the official CSS spec then I have no doubt that browsers manufacturers would scramble to implement it, effort required or not.

    The only serious issue with this idea, in my mind, is backwards-compatibility. Older browsers that didn’t support this feature would ignore rules specified in this way, so there would need to be some way of providing a fallback. I’m confident an acceptable solution can be found to this; and in the meantime at least if there was a officially supported spec then the gap could be temporarily filled with ‘standards compliant’ CSS pre-processors, rather than having the mishmash of non-compatible CSS pre-processor implementations that we have today.

    Mixin it up

    So, on to mixins. A mixin is an author-defined rule-set that can be ‘mixed-in’ to other sets of rules for particular selectors. The LESS CSS pre-processor implementation of mixins looks like this (from their documentation):

    What is happening here? Well firstly, we are defining a rule-set with a class selector of ‘bordered’ in the usual fashion. Then, in the .post a rule-set you can see that the class name has been used inside the braces – indicating that the rules defined in the .bordered class are to be imported into the .post a rules at that point.

    It’s possible to do something very similar to this today; in fact I use it all the time – I split my rule-sets up into discrete chunks using class names, and then apply those one or more of those classes in the HTML markup to achieve the desired result. However, this has one big problem associated with it: it breaks the paradigm of the separation of style and content, and ties our markup and styles together in a way that wouldn’t be necessary if we could use mixins in our CSS.

    Again, there are many people both for and against the ideas of mixins being added to the CSS spec. In fact, Bert Bos’s arguments in his article could probably be equally applied to mixins. However the advantages of having the ability to be able to define class-based style rules and then have them available to use as part of compound rule-sets seem obvious to me; helping us stick closer to DRY principles, reducing maintenance, helping to ensure consistency within sites, and removing a common dependence on markup would all be good things, would they not?

    In summary

    What I would like to see is a way to cut down on the amount of CSS I write, and make it more portable, more flexible and more maintainable. I think that variables and mixins in CSS would help that become an achievable goal. There are many others who feel similarly; I just wish that it didn’t seem like the W3C had completely closed out the subject of additions such as these to the CSS language.

    A quick footnote on CSS pre-processors:

    I have mentioned ‘CSS pre-processing’ various times above; basically this refers to the server-side parsing of CSS code before it is output to the browser (cached, hopefully!). This is a way that some of these features can be used today – the rules are included in the stylesheet, they are converted to ‘normal’ CSS by the pre-processor, and then the browser can parse the stylesheet as per usual.

    Pre-processing has been recommended by various members of the W3C and others as the preferred way to use features like these without them having to be added to the spec. Which is fine, except many people don’t want to use a server-side technology to do this, or can’t, for technical or access reasons. And another problem with them is that they are not working to any particular spec – all the implementations vary greatly, so your CSS code instantly becomes non-portable and your knowledge non-transferable.

    4 years ago  /  0 notes