In preparation of the Grid Layout Workshop in Amsterdam this Friday, I read the grid spec. I highly recommend doing this.

This specification is a great read, even for those not familiar with reading CSS specs. It first introduces all the concepts with comprehensible examples, and then dives into the syntax in more detail (including diagrams that show exactly which properties can be used how, available shorthand syntaxes and the algorithms used to decide about sizing and alignment).

Why?

“We already have many clever combinations of HTML, CSS and JavaScript to do layout”, I hear you think, “so what do we need Grid Layout for?” All layout mechanisms we have used to date come with specific problems. Floats need clearing, inline-block grid elements need comments to remove spaces and make widths work, and tables misused an HTML element for layout. CSS Grid Layout addresses our layouting problems, and lets us ‘divide available space for layout into columns and rows using a set of predictable sizing behaviors’. Yeah!

New terminology

The grid spec introduces a number of new terms. A grid is a set of lines that divides the grid container. Within the grid container, columns or rows exist between the lines. Columns and rows can both be referred to as grid tracks. On the grid, each cell is called a grid cell. One or more cells can form a grid area, which can be occupied by grid items.

I found it a bit confusing at first to see the difference between grid areas and grid items, but as I understand it, grid items are the bits of content that authors can specify to live in a specific grid area.

More alignment options

Some of the best new CSS properties that were introduced in flexbox, also work on grid containers (justify-items, align-items), grid items: (justify-self, align-self) and the grid itself (justify-content, align-content).

See also: fantasai re: “Too Many Alignment Properties”

Naming lines and areas

With grid-template-columns and grid-template-rows you can not only specify how much space each grid cell takes up, you can also give the lines surrounding them names. So for a 3 column layout with a width of 25%, 50% and 25% respectively, you do something like:

grid-template-columns: 25% 50% 25%

And if you want to lines surrounding the 50% area, you do:

grid-template-columns: 25% [start-main-area] 50% [end-main-area] 25%

so that you can set a specific bit of content to live in the 50% area between ‘start-main-area’ and ‘end-main-area’.

You can also define names for the areas themselves, using the ASCII art method (if a word appears multiple times, it means it spans multiple columns/rows):

grid-template-areas: "header header header"
                     "main main sidebar";

so that you can set a specific bit of content to live in the ‘header’, ‘main’ area or ‘sidebar’.

fr

The fr unit can be used to define flexible lengths and represents a fraction of the free space in the grid container. I think this is how it relates to auto: if all lengths are set auto, that would be equivalent to them all having 1fr, but if they have different amounts of fr, the fr unit gives more control as they can give some grid tracks more space than others.

Changing visual order

The grid spec frequently talks about the order keyword, which lets you visually change the order of your document (this property also exists in flexbox).

This makes that there are now two different orders to keep in mind:

• document order / source order (this is what you see when you view source)
• order-modified document order (this is the document order with all the ‘order’ properties in your stylesheet(s) taken into account)

Browsers are supposed to paint in the order-modified document order (this is also good to know for if you’re setting z-index).

The spec emphasises that order will only change your visual order, and not update speech order (for people that have your page read out to them) or navigation order (for people that use keyboards to navigate). Therefore it is important that the source order is sensible (this is an important accessibility concern).

Auto

Lots of things within grids can happen automatically. This is a bit complex to get your head around, but it is rather exciting (if you have not seen it, I can recommend fantasai’s CSS Day talk on defining auto). The good news is: to use grids, you do not need to know how the auto algorithms work, they just do.

With grid properties, you can set your grid exactly how you want it to be (‘explicit grid’). If you forget something or position an element outside of the bounds of your grid, the grid algorithm will create ‘implicit’ grid tracks.

Grids in grids

Grid items can be grids themselves (they are then ‘subgrids’), but this is still being discussed by the CSS Working Group. With display: subgrid, the subgrid would be able to inherit the cols/rows of its parent.

Thoughts

This is exciting! I really look forward to using CSS grids in my daily work.

I do think the transition to actually using the new properties for page layout will come with some problems, especially around giving grid areas names that can be shared across everyone working on the same site, and letting grid areas be occupied by components (as component libraries are the deliverable of many front-end developers these days).

And if that all works, should we give content managers controls to set content to flow in specific columns (perhaps the CMS would show a representation of the grid on various different viewports?).

Originally posted as Notes on CSS Grid Layout on Hidde's blog.

Reply via email

In “Meaningful CSS: style like you mean it”, Tim Baxter argues for replacing CSS approaches that heavily rely on classnames with a markup-centric approach. I think adding styling to HTML elements is hugely beneficial, but works best when combined with a class-based approach. We need a bit of both.

In his article, Tim explains that in the past few years, HTML (especially when enriched with ARIA) has become much more expressive. So expressive, that we can throw away class-based approaches to styling. We can just style on HTML elements themselves, he says.

Your team’s standards vs web standards

The challenge in CSS is to find a way to apply the styles you want to the things you want to apply them to. Classes let you give your things any name. Classes are to “[represent] the various classes that the element belongs to”, says the HTML standard. With a ‘class-based approach’, I mean approaches like OOCSS and BEM, that recommend you to define components or objects with just or mostly classnames.

The most-used argument for a class-based approach to CSS is that it makes things easier for teams. Once a team agrees on the preferred nomenclature for a thing, they can consistently use those names within their team.

But consistent standards already exist, in the form of web standards. Why not make those the baseline? Tim Baxter also says this:

if there is any baseline level of knowledge we should expect of all web developers, surely that should be a solid working knowledge of HTML itself, not memorizing arcane class-naming rules

Yes, let’s add styling to HTML where we can! This is wonderful, because web standards for markup were made through a long process of mailing lists, IRC discussions and face to face meetings. They have already gone through the trouble of defining what things are on the web.

Web standards define the difference between inputs for phone numbers and those for email addresses. They define the difference between a definition list and an unordered list. And the difference between quotations and paragraphs.

We need a bit of both

Adding style rules to native HTML elements, and use the power of some of the many attributes HTML comes with, sounds very sensible to me. Because the web standards people have already defined and documented what things mean in HTML, we can just use those semantics and be done with it. This also aids your users. Some of them may be using a screen reader or search engine to access your site.

But there is a problem here. The issue with using ‘just’ HTML to apply CSS, is that HTML is simply not as expressive as the design languages that often underly our web projects. Many web projects contain various instantiations of the same, meaningful HTML elements. In such projects, the meaning cannot come just from the elements themselves.

To be more precise, I think avoiding class-based approaches does not align with how web teams collaborate.

Some examples

Web standards document:

• what a form is

Our project’s design language contains:

• a newsletter form
• a search bar
• a contact form
• a poll (why not?)

These are all different types of forms, and would often not benefit from sharing style rules. The interaction designer has had user tests done and decided to do labels next to inputs in the contact form, and make the search bar expand when you click it. They’re all forms, but they’re all different.

Web standards document:

• what an input with the type ‘submit’ is

Our project’s design language has:

• the newsletter signup submit
• the search button
• the ‘Contact us’ form’s submit
• the button to submit your choice in the poll

Again, I think their is much more difference in meaning than we can ever distinguish between with styling just <input type="submit"> .

We can design beyond the list of available HTML elements

If we expect to be able to style just HTML elements, we should only allow designers to design one style for each HTML element. We would just hand them the list of available HTML elements, and they would create a design for each. That would be an insane process to follow. Unrealistic, too. Interaction designers have user journeys to worry about, they need to keep track of the whole picture.

Designers for the web, rightly, design more than just individual HTML elements. This is why, for front-end developers, it makes sense to use classes like .form--newsletter, .form--search or .form--contact. Or, depending on whether they differ a lot, .newsletter, .search-bar and .contact-us.

I have built websites where all the forms look the same, all the tables look the same and all the quotes looks the same. In those projects, they really exist, classnames are mostly unnecessary. Yet, most larger web projects are not like that. They have a lot of variations and for their meaning they cannot rely on HTML elements alone.

We have to be pragmatic about this. We should collaborate on websites that go beyond just what native HTML elements have to offer. Creative combinations of markup can bring our users a great experience. Classes aid creative combinations.

Using classes to draw distinctions

So, I think we need to define blocks with classes, so that we can distinguish between all the different components that are in our project’s design language. There is no harm in adding classes for variations of those blocks, or elements within the blocks. After (a lot) of initial scepticism, I quite like BEM and have seen it work (but as with all best practices, it is good to be critical, the problems they solve may not be your problems).

Classes are essential to do the work we need to do: style websites with a varied design language that creatively uses combinations of HTML elements. But using lots of classes should not stop one from using meaningful markup. CSS experts should always also be markup experts.

Conclusion

I really liked Tim Baxter’s article about styling with HTML elements and attributes, mostly avoiding classnames. It provokes thought and is a welcome alternative to the let’s-add-classes-to-all-the-things consensus. And I agree, adding styling to HTML elements is powerful, as they have inherent meaning that is specified in a standard.

But I think HTML and ARIA are (still) not expressive enough to draw the distinctions our designers draw. Classnames are essential in making such distinctions. The best approach, imho, would be to combine both classes and meaningful markup.

Originally posted as Collaborative CSS on Hidde's blog.

Reply via email

If one phrase from Bram Stein’s excellent Fronteers Spring Conf talk stuck with me, it was ‘always have a font loading strategy’. The point he made was that if you use custom web fonts in CSS, you should not rely on browser default behaviour, as that will often mean users see white pages with invisible text in case of font loading failure.

In his article ‘Web fonts for president’, Zach Leatherman compares font loading strategies (or, mostly, lack thereof) of the 2016 US election candidates. What a great idea! It’s a very interesting read!

Bram Stein describes how to use his Font Face Observer on his blog.

(I realise this blog currently lacks a font loading strategy, since I recently updated the typeface, I’m working on that)

Originally posted as Font loading strategies on Hidde's blog.

Reply via email

On Friday 1 April I attended Fronteers Spring Conference at EYE in Amsterdam. The first of its kind, after 8 two day conferences in autumn. IMHO, this one day spring thing is a fantastic format worth pursuing again!

Fronteers has in recent years always taken place in Tuschinski, an old cinema with a very cool interior, an eclectic mix of styles like art deco and Jugendstil. Cinema equals comfy seats. The cool thing about the new venue, also a cinema, was that most of us had to get on a boat (for five minutes or so) to get there.

The day was all about web performance (hashtag #perfmatters): making websites faster. It was divided into three sections, each with three 20 minute talks: the first on visual performance, the second on performance and accessibility and the last technical performance. Each section ended in a panel discussion with MC, eh, host, Phil Hawksworth. The day was then concluded with a keynote talk about money and the business case for web performance.

Visual performance

Tobias Ahlin started the day off with some great tips for better performing animations (slides). He recommended to only ever animate opacity, transform and translate properties, and suggested the use of pseudo elements to resemble animating other properties. An example: you cannot transition/animate border, but you can add a pseudo element, make it look exactly like a border and transition/animate that instead.

Paul Bakaus discussed the perception of performance. How a person experiences speed, he argued, may be a more important thing than actual, measurable numbers. Long activities, he said, can be memorised as short, and short ones can be memorised as long. He also emphasised how important context is for this: where and how you experience time can also influence what you feel about an interaction taking a certain time.

Bram Stein then talked about web typography, and more in particular the timing of custom font loading (slides). Browsers (and developers) make choices about what to do when your CSS wants to use a font that is not on the user’s system, the main options being FOIT or FOUT. FOIT is the flash of invisible text: a white screen until the requested font has downloaded. FOUT is the flash of unstyled text: rendering content in a fallback font until the requested font is downloaded and available. I could not agree more with him that FOUT is the best strategy: displaying any content at all is more important than displaying it in your font of choice. Web fonts are an enhancement. Bram stressed we should optimise how browsers load fonts with code, as most browser’s defaults are not great. This can be done with prefetch headers, the Font Loading API or its polyfill, Stein’s own Font Face Observer.

Accessibility

Marcy Sutton talked about ensuring accessibility in apps that rely on JavaScript (slides). To get websites to perform well and accessibly, she encouraged us to think about how you impact users (eg those that want or have to interact with their keyboards or assistive tech). This means we should not only focus on the DOM tree, but also on the accessibility tree. In terms of performance, if your app relies on JavaScript to be usable with a keyboard or AT, she stressed, make sure this JavaScript is in the critical path and load it before the rest of your app. She also recommended to prefer native elements above custom ones, as they often come with free accessibility benefits. I feel this is especially important when thinking of Web Components.

Karl Groves said that an important reason that we optimise for performance is because our clients want it and they’ll leave our sites or refrain from buying our stuff if we don’t and our website takes too much time before it becomes accessible. He said research (on physical businesses) showed that up to 83% could indeed leave a business if they had difficulty accessing it, and that this applies to the web. The most important question he said developers should ask is: “What is this thing and what does it do?”. This makes lots of sense, because the answers to those questions will likely remain the same whatever the device/context/user. Like Marcy, Karl mentioned the benefits of using native elements, and he showed an awesome video that compares how ATs make sense of real <select> elements and their jQuery UI counterpart.

Estelle Weyl talked about how responsive web design is not (only) about making it ‘squishy’: with sites getting larger in file size, page weight really matters (slides). An example she showed is that of YouTube Feather, a super light replica of YouTube (100k instead of 1200k) that someone at Google made. She also explained how responsive images save time in both decoding and transferring, and said we should consider our user’s battery lives. Design, Estelle concluded, is not about making it pretty, it is about making it usable and intuitive (and I guess that includes fast).

Technical performance

Yan Zhu went into the speed of TLS: when it was first on the table, people said it should not be deployed as it would be too slow. This is changing, with the likes of Netflix (which accounts for a huge part of bandwidth usage, especially in the US) switching to HTTPS. She said session resumption makes TLS less expensive by saving roundtrips. HTTP2 will also have impact as it allows multiple TLS connections at ones (and all regular supporting browsers will require HTTPS for it). HTTPS has in recent months become much easier to deploy on any site, with the public launch of Let’s Encrypt, which has issued over 1.4 million certificates since its launch, which, in number, makes it one of the largest CAs out there.

Tobias Baldauf showed us some very clever tricks to get better performing images, including those ‘hero’ images that we all love. There were three parts to his proposal: use HTTP2, use progressive JPGs and optimise the ‘scan levels’ in those JPGs. Tobias showed a number of comparisons showing real speed differences between HTTP1.1 and HTTP2, and between progressive JPGs / optimised progressive JPGs and ‘regular’ JPGs. With HTTP2, progressive JPGs and optimised scan levels, he showed, you can get a recognisable image on screen after only 15% of the image has downloaded. Wow.

Fronteers veteran Mathias Bynens blew everyone’s mind by explaining a very different phenomenon related to comparing the timing of downloads: the so-called timing attack (slides). He showed a number of different ways this can be used, but the main idea comes down to making requests to a site you think your victim visited, and use differences in server response times to find out about their status on that site (e.g. that they are logged in, have an account, or even have a certain age).

Round-up

Kristian Sköld ended the day with an interesting keynote about a subject that was hardly discussed in the other talk: money. If you need your organisation’s support for spending time on web performance, you will want to make a business case and discuss money, as that is likely what the management will want to know about. Whatever you do, there should be a business case behind it, Kristian said. If you correlate pageviews/load time statistics with bounce rates, you will likely find that more people bounce if the site takes longer to load. This is a metric marketing/business people can work with and ultimately, approve the budget for. If better performance can shave money off the marketing budget, Kristian explained, making more money available to the IT/web department becomes simple math.

My takeaways:

• We should be conscious of and minimise the amount of bytes we send down the wire
• Page speed is not just numbers, perception can also be a factor
• Fast websites do not have to be insecure: TLS is getting faster (so fast that Netflix is moving to it) and HTTP2 (HTTPS-only in all major browsers) lets us benefit even more from progressive JPGs
• Fast websites do not have to be inaccessible: resources that aid accessibility should be part of the critical path and if we use native elements, we get a lot of accessibility for free
• Paying attention to the amount of bytes sent to users can also help evil companies to track them

What a fantastic day this was. We learned about keeping file sizes down and minimising bytes sent over the wire, about using the right tools for the right job and about advantages of HTTP2 and HTTPS. There were both specific and general talks about web performance issues, and as many as three accessibility talks. Lots of variety! Well done, team Spring Conference!

Other posts about the Spring Conference

• Tom Hartwig’s takeaways

Originally posted as Perf mattered at the Fronteers Spring Conference on Hidde's blog.

Reply via email

When I started out learning to build websites, the web world was just moving from adding style declarations to every single element, to a generalised approach where one small-ish set of rules would apply to all of a website’s pages.

We transitioned from meaningless markup:

<font size="-1">A smaller heading1!</font>

to markup that described an element’s position in the page structure:

<h3>A smaller heading</h3>

This was the magic of CSS: because our markup had meaning, we could contain the style of all the elements in just a small set of rules that would sort of automatically work for new pages.

Styling things that don’t even exist yet

With CSS, you don’t just style that heading, you style the general thing ‘heading’, including the ones on pages that don’t exist yet, with lengths you hadn’t imagined yet.

Preparing for the unexpected is a large part of the art of authoring stylesheets. We don’t know what device a user is going to pick, we don’t need to know, but if it’s got a certain screen width, we can write rules to adapt the lay-out.

Cascade blaming

In modern approaches to CSS, some portray the cascade as a nuisance. In his (well-considered) article about REMs vs EMs (seriously, read it, it is good!), Zell Liew says:

What throws people off is that 1em can take on different values in different parts of the code

Harry Roberts responded to this on Twitter:

This, in a nutshell, is why I hate ems.

So about this ‘taking on different values on different parts of the code’: in any programming language that would be bad, a side effect, a bug, a problem. But for CSS, a declarative language, it is arguably the whole point of it. CSS is made to have a cascade: behaviour that inherits style declarations based on priorities.

I would argue the benefit of CSS is that it does unexpected things. Instead of having to style every heading individually (result: expected behaviour), it will style each heading for us, including the ones that don’t exist yet when we’re writing the style rule (result: unexpected behaviour).

This is something you need to keep in mind when writing stylesheets. Harry replied that the cascading behaviour of ems is ‘cognitive overhead’ that ‘isn’t worth it’. I concur it is cognitively challenging, and education is important (Harry personally does a lot of great CSS education), but so are many things in web development.

Complexity in CSS vs complexity in preprocessors

The benefit of cascading as a cognitively challenging thing: it is clearly defined in specifications.

Many features of the modern day CSS approach, such as custom mixins and functions, are defined by the (very smart) people behind projects like Bootstrap, Bourbon, Inuit et cetera. They, too, bring cognitive overhead, but have only their documentations to refer to for help.

Where the spec-defined complexities have always been explained in the spec, and books by people like Eric Meyer and Andy Clarke, many modern-day complexities in CSS are harder to learn. Arguably, they bring more cognitive overhead.

Originally posted as Cascading and cognitive overhead on Hidde's blog.

Reply via email