WordPress is used by many different audiences. It is used by people who do not know much about code, as well as by experienced programmers¹. Expectations of plug-ins therefore vary.

Some want plug-ins to automatically do everything. If they use a plug-in to integrate their Twitter stream into WordPress, they expect the plug-in to not only pull tweets from the Twitter API, they also want the necessary mark-up and CSS to display tweets in the front-end. Others will only expect a plug-in to do a specific task, leave front-end hooks for developers to output data surrounded by their own mark-up, styled by their own CSS and made interactive with their own scripts.

My ideal WordPress plug-in is of the latter type. I write my own templates (mark-up, stylesheet and scripts). Then, in the mark-up, I simply replace all dummy strings of text with template tags. My ideal Twitter plug-in, for example, would take care of fetching tweets from Twitters API, and it would then expose an API to output tweet data (the tweet itself, its date, its author, avatars etc), allowing a developer to output the relevant strings of text where required.

When I add a new plug-in (or a client requests one to be installed), I have made it a habit to make sure it does not add any CSS or JavaScript (plug-ins can add assets through wp_head() and wp_footer()). If it does, I usually undo the behaviour and add CSS or script to fit within the existing code.

¹ And some experienced programmers will never touch WordPress (different discussion)

---

Originally posted as Scripts and stylesheets in WordPress sites on Hidde's blog.

Reply via email

CSS Grid Layout has been coming for a long time, browser support seems to be on its way (at last!). This is great news! It means we can soon use ‘just’ CSS to describe our lay-outs. But, arguably, this leaves us with a naming problem.

‘Just CSS’ vs classnames for lay-out

In the current situation, many lay-outs on the web work with a combination of classnames-for-layout-purposes and CSS to go with it. In the future, with CSS Grid Layout, classnames can just declare what a thing is. They then leave it to CSS entirely to describe how the thing is layed out. As Rachel Andrew points out in her recent 24 Ways article, this may mean the end of container, row and col-* type of classnames:

(…) my hope is that it will be the layout frameworks that tie our design to our markup. They have been a necessary placeholder while we waited for a true web layout system, but I believe that in a few years time we’ll be easily able to date a website to circa 2015 by seeing <div class="row"> or <div class="col-md-3"> in the markup.

CSS Grid Layout is awesome, because it would provide web page layout with a separation that the makers of the web always encouraged authors to follow:

• HTML is for what it is (structure)
• CSS is for what it looks like (style)

But I feel that this leaves us with a problem not easily solved: how can we sensibly sname page areas? In examples of Grid Layout, there is usually a header, main content, sidebar and a footer. In reality, there can be lots of different combinations of column widths. There are usually many variations, possibly more than we could possibly come up with classnames for.

Naming page areas

When using classnames-for-layout-purposes, page areas are defined by presentational classnames that do not require further naming. We just name the components inside the containers, and give their wrappers/containers presentational names to form a grid structure.

If we want to peruse the semantic classnames we have added to page areas to lay things out, we’ll need to give them sensible names. We can then apply grid CSS to each of them (and could do this reusably/automatically by clever preprocessor usage).

My argument is that coming up with such names could prove quite hard: what’s a thing called that has a 35% column and a 65% column, in which the latter column is divided into four? Arguably, names like col-6, or even col-md-6 are easier to work with (and yes, I’ve frowned upon them for long).

Making it easy to work with is probably what we are discussing here. It’s mostly an issue between developers, for the browser or user doesn’t experience what we call things. They can benefit from separation between semantic usages of HTML elements and separation of concerns generally, but classnames aren’t read out by screen readers (like a title attribute), used to construct the accessibility tree (like some attributes are) or linked to by users (like IDs).

Conclusion

So I think there are two views, really. Some will argue we should think of our grid as a system separate from the rest of a site’s front-end, and as a thing that we can leave for months without touching it. In this case, when regarded as a separate thing, presentational grid classnames are seen as okay. Others will say grid-structures should just arise from grid definitions that belong to each semantically classed component. Especially for those, CSS Grid Layout will make it a lot easier to do this.

---

Originally posted as Declaring grid layouts with ‘just’ CSS on Hidde's blog.

Reply via email

Grids… for long I have thought they are the trivial bit in front-end development. Many sites do not have much variation in column widths, so to use a ‘grid system’ would be a clear violation of the KISS principle. Now I think complex grid systems can be of great use in component-based front-end builds.

Note that the following may soon be obsolete, when we start describing layout in CSS using CSS Grid Layout (not widely supported at the time of writing)

My view is this: for large websites and organisations, in addition to having a component system, it makes sense to have one agreed-upon, shared-between-projects grid system.

What is a grid system?

By ‘grid system’, in this article, I mean a set of CSS rules written for the purpose of declaring grids in mark-up. These can be hand written, or generated by preprocessors (in which case they can be generated with custom options to fit a project better). Some agencies I worked with have rolled their own. Others use an open source one, such as Bootstrap’s.

Spanning columns through classnames

In this kind of grid system, grids are declared using classnames on HTML elements. Usually classnames are given to each row of columns, and then to each column within that row. A grid has a number of ’virtual’ columns (e.g. 12 or 16). Specific elements span a number of these virtual columns, e.g. a main column could be the first 8 out of 12, then the sidebar could be remaining last 4. In mark-up, classnames of each actual column determine how many virtual columns are spanned.

Complex structures full of features

Grid systems are, more often than not, convoluted structures of code. Not only do they contain percentages for any combination of columns imaginable, they often also have options to ‘skip’ columns, so that an element can start spanning columns after the columns it has skipped. Many also contain percentages per breakpoint, so that you can have different sets of columns per breakpoint. This results in many classnames; time consuming to write, or if generated, buried away in your preprocessor output.

As opposed to the introducing-columns-when-required approach

Note that there are other ways to go about columns and widths in websites. You could just add CSS rules for each grid variation required (eg, you would be done by just writing one for doubles, one for quarters, and perhaps one for three quarters). This is how websites have been built for a long time. I used to prefer this approach — depending on the project, I sometimes still do. It uses a lot less CSS and is very KISS.

How do they fit in component-based front-ends?

The cool thing about component-based front-ends is that none of the component code is committed to specific widths. The width of a component is determined by the container it happens to exist in. Or, if it does not sit in a container, by the window or viewport width.

If your team decides to build pages using a grid system, this is their role: they force what the width is of any components that occur in the page.

To have a super complex grid system, with perhaps more classnames generated than you might actually need, requires clear advantages to be worthwile. The amount of classnames comes with weight: Bootstrap’s default grid system is 8KB (minified). Yet, advantages do exist:

Separation of generic, reusable components and specific, non-reusable widths

You don’t want the development of a new component to involve widths, the width of things will be decided in the context of the page grid and the viewport it exists on. Therefore, a separation between things and their widths makes sense. If the grid is separate, it makes sense to be a powerful (or complex) system that fits many cases, rather than something that is decided case by case.

Great for teams in agencies or organisations

As a team (in an agency or elsewhere), it makes sense to use the same grid system or grid system generator for all projects, with only changes to their setup (eg number of columns, nature of breakpoints). This is not about developer convenience, it is about organisational consistency. You’re making sure all teams in your organisation do the same thing with their widths, just as they do the same thing with their components.

Conclusion

The main benefit of an agreed-upon, shared-between-projects grid system is this. For an organisation, a great level of consistency can be achieved if widths in all of their sites come from one system (just as it helps if components for all of their sites come from one system).

Does that mean I think one grid system will fit all? No, adjustments are probably required sooner or later. That would mean new versions of ‘the grid system’ would get released. All projects within an organisation would be using ‘a’ version of ‘the grid system’. If this happens to be not the most recent version, the project team can decide whether to update to the latest version or not.

---

Originally posted as The role of grid systems in component-based front-end builds on Hidde's blog.

Reply via email

The next problem being solved for the web is not having the network: apps that work offline. I think when designing such apps, we should consider user intent, and in particular what a user intends to be available offline.

Web apps that work offline will download themselves into a user’s cache: their assets, their core app code, et cetera (see also: service worker). When the app itself is offlinified, the next choice is: which content should we make available offline? I think we should consider letting our users decide.

My newspaper app lets me download newspapers and requires no further connectivity once the download is completed. As a user, this allows me to download a newspaper to my tablet before I leave home, take a seat in a local train and start reading. Great for commuting. It lets me not worry about the network. In theory, my tablet might have 3G, or could connect to the train’s WiFi system. In reality, that would probably result in me struggling to get any data when the train is in a tunnel, or trying to battle the train WiFi’s registration page. The alternative, downloading the paper on my home WiFi, which I know works, is much better. For this to go smoothly, it is crucial the newspaper app has a ‘download for offline usage’ button.

A music subscription service I use, offers me the ability to have some music available offline. I use this feature a lot. If I need to catch the airport bus, I want to listen to that new album that came out. I know which. If I’m going for a long drive, I might make a playlist to listen to whilst driving in the UK’s beautiful, but not always well-networked country side. I create the playlist at home, and want it to be available on the go. So I think my music app with offline capability should let me choose what to make available offline. Spotify has a toggle that sets playlists to ‘available offline’, but it does not have UI to let a user download specific music (it behaves more or less like a hint). It will decide, based on how much connectivity and storage the device has. This makes sense, as often connectivity and storage are big uncertainties for the developer that builds the app, but it gets in the way of user intent.

Some apps choose to offlinify the last x items (eg a news site), or the content that the user has visited (eg an encyclopedia). The latter is a form of user intent, the former is unrelated to it. Naturally, depending on context, these can be a good strategies, too.

For the news and music player examples, honouring user intent can hugely improve a user’s experience. It may very well be possible to let the app decide what to offlinify when, but maybe your user just wants a particular thing to be offline. Today’s newspaper. Or, for that matter, last Tuesday’s issue, because their grandmother appears in it. This artist’s new album. This episode of that podcast. This A List Apart article.

Technically, it is far from trivial to do for a web app. Without going into too much detail: you don’t know if your user/their browser will have cleared their/its cache, or how much storage they have available.

In summary, I think if our app makes itself available for offline use, we should consider giving our users a choice in which content to make available offline.

---

Originally posted as Offline apps and user intent on Hidde's blog.

Reply via email

Web Components will allow web developers to create their own elements: custom elements. Last week I attended the Web Component panel and accessibility break-out at Edge Conference, and left both sessions full of questions. One was: what kind of custom elements do we need?

The idea of Web Components and specifically their custom elements, is that you no longer depend on the browser to provide you with elements: you can bring your own. Many blog posts about the subject emphasise how exciting this is. Yes, this is exciting new tech. It gives website owners lots of freedom, but also a big responsibility. I think Web Components have their use case for the web at large, but I can’t help but feeling that for many websites, it will be too costly to create and unnecessary to use custom elements.

Existing HTML elements come with benefits

Many of the existing, standardised HTML elements come with semantics, and browsers can do all kinds of smart things with them. Some examples:

• The <select> element lets a user pick one option from a list of options. Every browser can decide how to represent this best. My phone shows a fruit machine style thingy, an old-fashioned Windows style selector is shown on old Windows machines, and easy to recognise for users of such machines. A future version of Siri may be able to talk us through the options, in fact, some assistive technology already does this.
• The <video> element lets a developer point to a video, or indeed a couple of videos in different formats. The problem of how to play the video is then solved by the browser. Each browser chooses the best video player it can offer, and lets the user watch the video in it.

With existing HTML elements, the browser takes care of a lot of your accessibility, usability and design.

Custom elements come with responsibility

Contrary to most existing elements, a <custom-element> is much like a <div> : it has no meaning to the browser, so browsers have nothing built-in to deal with it. It doesn’t expose to the accessibility tree, has no usability or default appearance. Indeed, this is what a component creator has to take responsibility for themselves:

• accessibility / semantics
• usability
• what it looks like

For each platform.

The Gold Standard gives a great checklist for making Web Components “to be as predictable, flexible, reliable, and useful as the standard HTML elements”.

To increase a component’s accessibility, one could provide meaning through ARIA roles and properties. Or, if we use native elements within our components, we can have our cake and eat it too: when embedding existing elements, you would inherit their benefits. I have not been able to find a definite resource confirming this can be done.

It is probably not easy to create a custom select or date picker that works as well as its native equivalent.

To provide usability, you would have to provide ways to interact with your element for whichever method your user chooses (or is forced to use by personal or indeed corporate circumstances). This is hard, because in most cases, as a website, you do not know a lot about the circumstances under which you are accessed. It is probably not easy to create a custom select or date picker that works as well as its native equivalent.

Design means designing for many different contexts: phones, watches, desktops, etc. And there are probably going to be contexts that we currently don’t know of: a future fridge with a web browser will probably know how to most suitably render a <select>, but it will not know how to deal with your <custom-datepicker> .

Chris Heilmann once said it makes sense to use what already works and build on top of that. I think this applies to custom elements, too. They would only have benefit, if they combine existing elements to bring something we need that does not exist yet.

Does building Web Components sound complex? In the Web Components panel, Google’s Alex Russell noted that “tooling will save you”. Tools can make it much easier to build better Web Components, for example by making them render both on the server and the client for progressive enhancement. But aren’t tools the problem?

Benefits of Web Components

Web Components are not just hard to build well, there are also many benefits to using them.

With Web Components, browsers (will) give website owners the power to bring their own elements. This gives a lot of freedom and is a big addition to the web as a platform. It is innovation we should welcome.

Web Components also bring developers the convenience of style/DOM encapsulation: if you work on a custom element’s CSS, you know it is only going to apply to that component.

Thirdly, a Web Component can be very portable: once you have created a <custom-element> and built all its behaviour and style, you can then use it where you like. As Peter Gasston noted in the EdgeConf Slack channel, “[They take] more effort to build, less effort to use”.

A fourth advantage of Web Components is for search engines: they can potentially start recognising widgets if they are used enough throughout the web, which would improve their search result listings.

An additional benefit of Web Components as a project is that it helps find missing platform APIs (a fascinating project by Domenic Denicola).

What kind of custom elements do we need?

In summary, custom elements can be good for the web as a platform, for developers and potentially for users, too. But building custom elements that are accessible, well-designed and easy to use on all platforms, is not going to be easy, or cheap. So what kind of custom elements do we need?

Building custom elements that are accessible, well-designed and easy to use on all platforms, is not going to be easy, or cheap

Some say custom elements will be a bit like jQuery plug-ins: you need a carousel in your page, but instead of building it yourself, you peruse a third party carousel. You want your content to appear in tabs, so you go and use a third party tabs script. Instead of borrowing someone’s CSS and JS, you borrow their <fancy-carousel> or their <the-ultimate-awesome-tabs> , which have their styles and scripts nicely hidden inside their Shadow DOM. We should take care choosing only properly built ones. Also, we should be careful not to repeat the “just another plugin doing $x” mistakes.

I have the feeling that custom elements make most sense for huge companies that have many different websites and apps that have or should have shared elements. Google, who came up with Web Components, have a search engine, maps, Word processing tools, online storage, a social network, an operating system and many other products. It makes lots of sense for them to want to share many of their controls across their products. And they have plenty of designers and developers available to work on the usability, accessibility and design of such components, so it is more feasible for them to do it well (and even they do not have unlimited time and resources).

The same probably goes for big social network enterprises like Twitter and Facebook. They could create things like a Twitter timeline widget for people to embed in their site. Currently, I advise clients against using those, as they come with privacy and performance issues. If offered as a custom element, these issues might still be there, but now buried away in the Shadow DOM. Instead, offering the data as JSON, as Twitter used to do, would probably be more helpful for developers. But I guess that would add less value for Twitter’s shareholders.

Or perhaps media organisations like the BBC. Their video player seems a huge part of what they do, so they might have time to work on a custom element for it, that plays video exactly in the way they need it. For their own site(s), they have many, or perhaps for people to embed elsewhere.

Web Components could also bring a big benefit to people that create ‘apps’, websites where people go to do stuff, or maybe even games. They might need very specific controls, that do not exist in browsers yet.

How about smaller sites?

I’m not sure about the use case for smaller websites. One of the messages of Web Components seems to be that we can soon control style and behaviour of all the elements. But that’s not the full story: it is also very hard to do it well. I am afraid we will end up with lots of badly built components, if we do not tell the full story. What if web agency clients start asking for cool, custom-designed and custom-behaving components, and the teams tasked with creating them do not have the budget to meet the Gold Standard? Should we instead trust the capabilities of larger, Bootstrap-like projects, and use their components?

What if web agency clients start asking for cool, custom-designed and custom-behaving components, and the teams tasked with creating them do not have the budget to meet the Gold Standard?

Some have suggested Bootstrap and Foundation should start converting their components into Web Components, but I fail to see how that would solve a problem people actually have. It would be interesting to do it as a research type of thing, but to make them the main way to use Bootstrap or Foundation components just feels wrong.

I’m not convinced either, that every company should come up with custom elements for all the things, just because they can. Most elements can be built very well with existing HTML, without costing as much design and development time. I feel many web projects will hardly have a use case for utilising custom elements, or the budget for creating them. They would overcomplicate things. It still feels like eating a 5 course dinner when all you wanted was a salad.

I hope Web Components will get used by those companies that have genuine use cases for which the current set of HTML elements cannot provide. That will help push the web forward, and potentially add new ways of interacting with the platform. We are given the chance to add new elements, before WHATWG, W3C or browser vendors have the time to do so. Or the chance to create elements that would not be suitable to be part of the web standards, yet very useful to one organisation’s strategy. But before that can happen, what we need most is agreement amongst browser vendors.

So, what kind of Web Components do we need? Well-thought-through additions to the existing set of HTML elements, solving problems that aren’t solved by existing elements: yes, please. Many variations on improvements of existing elements like checkboxes and selects? As far as I am concerned, probably not. New elements built without considering accessibility or the huge diversity of browsing contexts? No, thanks.

Update 03/07/2015: Peter Gasston points out on Twitter that a lot of potential value is in the use cases we haven’t thought of yet. This is probably true, I may have to adjust my view when such cases arrive.

---

Originally posted as What kind of Web Components do we need? on Hidde's blog.

Reply via email