Figure: Matrix of properties for text decoration and possible values according to CSS Text Decoration Level 3.

text-decoration-line – types of decorative underlines

It tells us what type of underline will be used.

Possible values:

text-decoration-line: none |
  [ underline || overline || line-through || blink ]

In the central Europe you probably want to often use the underline option. The blinking value blink is considered old-fashioned and the modern web browsers do not support it. Thank God.

The notation with blocky brackets and logical operator marks or (||), which I took from the specification, says that it is possible to use multiple values, for example <code>text-decoration-line: underline overline<em>.</em></code> The value line-through is set in HTML values in default styles of web browsers <s>, <strike> or <del>.

This feature has full support when we leave out the value blink.

text-decoration-style – underline style

It sets the text decoration style - for example, one line, double line, dotted line or wavy line:

text-decoration-style: 
  solid | double | dotted | dashed | wavy

It is used only at the time and only if some of them are defined text-decoration-line.</em>

The value wavy is cool, for example for highlighting the mistakes in words.

This feature has full support in modern web browsers.

text-decoration-color – the color of decoration

The color that we use for decoration. It could be the current color or any color of your choice.

text-decoration-color: <color>

<color> could be current color or any color of your choice.

This is something that all modern web browsers can do.

Let’s look at the features in the latest CSS specification for text decoration.

Figure: The latest CSS Text Decoration Level 4 features that won’t work everywhere.

text-decoration-skip-ink – to prevent line crossing

The feature that specifies if the decoration line will be in punctuated, so there wouldn’t be any crossings with the text curves.

text-decoration-skip-ink: auto | none

In the default styles of modern web browsers there is a setting text-decoration-skip-ink:auto, so usually we don’t have to deal with this. Just in case that we would like to turn it off. But I have no clue why would we do this in common situations.

Originally it used to work in the specification as text-decoration-skip, but now the feature has been deleted - it will be divided into more sub-features.

This feature has full support in modern web browsers.

text-underline-position – the position of decorative line

Where the decorative line appears:

text-underline-position: auto |
  [ under || [ left | right ] ]

The values left and right are meant for Asian languages, that are noted down vertically (Chinese, Japanese, Korean,…)

For us, the value under is interesting, it will issue the underline under the letter outline (the part of a letter that goes down under the usual line such as p, y or j).

It is recommended to use this in mathematical or chemical texts so that the decorative line wouldn’t interrupt the numbers in lower indexes.

This feature is not supported by Safari.

text-underline-offset – the offset of decoration

It defines the shift of decoration line from its original position:

text-underline-offset: auto | <width>

It acts differently according to text-underline-position. When it comes to underline the movement goes down, but with overline the movement goes up.

The value width is recommended to use in em unit, so it would adapt to the size of the text.

This feature is supported by Safari and Firefox, but not Chrome.

text-decoration-width & text-decoration-thickness – the width of decoration line

To set the width of decoration line, we have two properties:

text-decoration-width: auto | <width>;
text-decoration-thickness: auto | <width>;

While:

• text-decoration-width is standard according to CSS Text Decoration Module Level 4, but no browser can actually do it.
• text-decoration-thickness is not that standard. However, it is supported by Safari and Firefox, but not by Chrome. If you would like to try this, <width> is recommended again in em to adapt to the size of the text.

text-emphasis – the position of emphasis (not interesting for Western countries)

This shortcut of features is helpful only for east-asian and other exotic languages again, that is why I will not explain it any further. It draws the accent dot above, under or next to the text.

These features belong here: text-emphasis-style, text-emphasis-color, text-emphasis-position and text-emphasis.

The order of rendering

Since we got more CSS features that decorate the text, it’s good to know the order of their depiction. We’ll look at them in order from those that render from the bottom, shades, upward.

• shades (property text-shadow)
• underline (feature text-decoration-line)
• overlines (feature text-decoration-line)
• text itself
• emphasis marks (feature text-emphasis)
• line-through (feature text-decoration-line)

According to this list, the browser will solve the conflicts in the depiction of text curves and its decorations.

Example with all of the features

In the final CodePen we will sum up all the features and their support in web browsers in an overview table:

CodePen: cdpn.io/e/zYxMKJB

As you can see, in the current version of CSS even the usual text decorations can be quite a challenge.

Figure: The object-fit and object-position properties determine how the inserted media behaves when its dedicated space becomes smaller or larger.

Let’s show it on a simple example.

We have the following HTML:

<img class="img img--cut" src="image-300x300.jpg"
  width="300" height="200" alt="Image…">

CSS:

.img--cut {
  object-fit: cover;
  object-position: bottom;
}

And let’s explain:

• The image has natural dimensions of 300x300 pixels, but it is only allowed to occupy the height of 200 pixels in HTML, see the height property.
• object-fit:cover indicates that the image should be stretched over the entire area of the <img> element so that there is no space left. See object-fit.
• object-position:bottom specifies the alignment to the bottom edge of the <img> element surface. See object-position.

Object-fit values

Specifies how to fit the external media to an area specified by the width and height properties in HTML or CSS.

Figure: Object-fit property values applied to an image of 150 × 150 pixels.

This is very similar to embedding images to background using the background-size property.

Figure: In practice, the most useful value is object-fit:cover.

Object-position values

Defines where will be the element positioned by using object-fit. It has exactly the same values as the background-position property.

Figure: Examples of object-position property values.

Let’s look at examples of values.

Use in practice

• Both properties are very useful for enforcing aspect ratio when we have images with different shapes and sizes saved on the server.
• Object-fit video background works as well. The same with iframe does not.

Support in browsers

Since the Edge explorer has been upgraded to the Chromium rendering engine, only Internet Explorer 11 does not support these properties.

By the time I am writing this article, Internet Explorer still has a significant share of users in some countries (like for example here, in the Czech Republic), so it will be necessary to sort out the fallback.

caniuse.com/object-fit

How to solve the problem in Internet Explorer:

1. Instead of object-fit/object-position embed the image to the background by using background-size/background-position. Alternatively, you can play with the transform property and with absolute positioning (See StackOverflow).
2. For IE11 use polyfill - fregante/object-fit-images. I do not recommend it much, because it slows down the rendering performance in the already slow Explorer.
3. Detect a non-supporting browser (eg. using the Modernizr library) and deploy a workaround. For example, StackOverflow offers a solution to change <img> to <svg> and resolve the problem in it.

Paul Bakaus: “We’re optimistic that AMP can democratize the development of excellent UX.”

That means you almost never have to write JavaScript – which is a feature, not a bug. It also means that AMP can for the most part guarantee good performance, so you don’t need to track perf budgets anymore, a massive time saver. The AMP core library lives on a CDN, so we can ship updates to billions of pages overnight, and improve your website without any redeployments or work on your side. And with amp-script, amp-bind and amp-list, you have powerful interactivity at hand when you need it. In the end, we’re optimistic that AMP can save lots of maintenance and bug fixing time, and therefore democratize the development of excellent UX, as not everyone has the money to pay 5 frontend performance engineers.

“Figuring out a way to measure whether a page is fast is an incredibly complex problem”

Various important members of the community are encouraging Google to give the benefits of AMP sites to regular fast sites. I know the AMP team is already addressing this, but I’m afraid not everyone understands the full range of issues. In particular, what would regular websites have to do to get the benefits?

Jeremy’s blog post was interesting as he walked through the problem space the same way the AMP team has done before, and to his credit, after asking the right questions he arrived at the right set of problems that need to be solved.

He also said that he’s “sure smarter folks than [him] can figure that stuff out”, but the problem is that Jeremy is either underestimating his smartness or overestimating ours: Figuring out a way to measure whether a page is fast or not seems easy on the surface, but is an incredibly complex problem.

Paul Bakaus: “AMP is not a JS framework, we’re an HTML framework.”

We’re slowly making progress with metrics such as largest contentful paint, but it’s only the tip of the iceberg. Take, for example, run time performance: In order to accurately measure whether a page is fast when interacting with it, during crawl time a bot would have to interact with it, and probably for quite a while. Not only does that crawl get incredibly expensive, it gets worse as without cache, we could not trust the page stays fast, so a platform like Google would have to re-validate multiple times a day.

I didn’t even talk about privacy preserving pre-rendering, the main reason AMP pages have to be hosted on a proxying cache. Signed HTTP exchanges is a promising standard to decouple identity and serving of documents, and could be used to bring privacy-aware pre-fetch to non-AMP content, as long as we also solve the metric issue. And of course, all browsers have to buy in.

In many ways, I’m hoping this day comes rather sooner than later, because it will reveal just how much work AMP does to ensure great UX, and when publishers see how hard it is to implement from scratch with underlying standards, AMP might suddenly seem more attractive!

Paul, you mentioned problems with non-existent metrics and crawler performance when measuring them. But there is already a Chrome UX Report, a database of real-user experiences of the page-speed metrics. Yes, unfortunately, it only provides a small number of metrics so far, but couldn’t this database provide information if a page is fast enough?

The Chrome UX report could definitely be a building block for this. It doesn’t measure runtime performance yet, which is a gap here that we’d need to address, and another issue is the developer workflow: If you’re building a new site, and want to know whether your content is eligible for pre-rendering or not, you would have to wait a few weeks until you’d know. The AMP validator gives you this guarantee instantly.

Lighthouse is an interesting middle ground but is much less of a guarantee for great performance than real-world reports. All of these tools and metrics have their pros and cons – I believe it’ll end up being a combination of various tools and metrics.

“Turning AMP into an all-around great framework for content websites”

Congratulations on JavaScript in AMP – the new amp-script component. I was also intrigued by the “AMP bento” project, which will eliminate the need to use the AMP runtime, the main JS library, and improve performance when using the framework on regular websites. How far is it and what are the other bigger plans with AMP?

We’ve just recently started to make decent progress with Bento. It’s an incredibly complex project, as it effectively requires a rewrite of AMP, one that makes AMP even more modular than it already is.

Currently, AMP expects to be in total control of the page and its DOM, and the main AMP library (our devs call it runtime) needs to be loaded along with subsequent components.

So if you wanted to use amp-sidebar on a site running, say, Angular, you could already kinda do it today, but it would be inefficient and error-prone, as you would have to load the whole runtime just to show a sidebar, and would need to be careful about not mutating the DOM after the sidebar has been rendered.

The Bento rewrite of AMP isolates components much better from each other, introduces a new lifecycle management API and will make components feel much more like traditional web components.

It’s important to note that Bento AMP has one specific purpose: To allow people to gradually upgrade to 100% AMP. Even with a 90% AMP site, developers don’t get the caching and pre-rendering benefits, which would be a shame. So we’re hoping Bento will make it easier to convert over time.

We have plenty of plans to improve AMP, but most can be categorized as turning AMP into an all-around great framework for content websites. We’re convinced that it’s too hard to build great stuff on the web today, and want to do our part to help. Stay tuned!

Thanks for the interview and wish you a pleasant stay in Prague!

Let’s go through those sites.

It’s a gallery of beautiful and creative websites that use… well… just the layout grid and Bootstrap buttons.

Yes, I’m not kidding – they mostly do not make use of more components from Bootstrap.

Presentation sites: The unlocked potential of Bootstrap

The above-mentioned sites also exist here in the Czech Republic. When I’m asking their authors why they used Bootstrap when they only need its layout grid, their answer is:

It was the client’s wish.

It’s true – it is popular among clients to fall for an illusion that using Bootstrap will save the budget. However, if the custom design of the project is not adapted to the design system (hidden in Bootstrap), the use of the framework is very inefficient.

Bootstrap really has a potential to be used on websites, however, I never hear that one correct reason to do so. It would go something like this:

From all existing design systems, Bootstrap was the best choice. We discussed it with the designer, changed a few things in Bootstrap’s design system and we use a large part of the framework components.

The reason why I will never hear such a reason is hidden in the following fictional quotes:

• Bootstrap’s design system is invisible. There is no public documentation. It can only be noticed by more experienced and design-savvy developers. It is partly hidden in the code and partly does not exists.
• Designers do not see the system. They can’t learn the graphics principles on which Bootstrap is built. There is no documentation which could suggest a sensitive way to edit design principles for a specific project. The adjustments designers then make are sometimes missing the Bootstrap principles. They misunderstand Bootstrap.

What does the red button mean?

To make clear what I mean by using the term design system, let’s take a look at the following modal window built using Bootstrap.

Now tell me: What’s wrong with the design of the user interface?

I’ll let you think…

Just a bit more…

Now, please think it over. The “Close” button has the wrong color, right? And why? Because the red (created by the .btn-danger class) is designed for risky operations that can, for example, erase data for the user. It was not created for closing the window, which has lower priority than “Save changes”.

Probably.

I say “probably” because we don’t know where the truth is. Bootstrap has no documentation of the meaning of color, as well as no documentation of the meaning of anything. No button page or anything like it.

Bootstrap does not have a design system documentation. It does not have a style guide. So there is no order in Bootstrap’s design – not for designers and not for most developers.

If you take a look at the map of the web tools for designers and developers, it simply occupies the place for the UI library:

Now let’s compare Bootstrap with Material Design

New to Bootstrap’s segment was Google Material Design. If we’d like to implement a button using Material Design, we will learn, for example, that there is a priority scale:

Other important information is that the location of a button, its shape, color, or location affects the position in the hierarchy:

Yes, besides being a UI library, Material Design is a well-documented design system:

So, if a designer works with Material Design, he is ready to design a web interface based just on this framework. Then a developer can easily implement it.

If a developer works with Material Design (and reads the documentation), then he will make much less designing errors.

This is the strength of Material Design and the weakness of Bootstrap.

Bootstrap has better technical documentation, but the style guide is missing

I’m far away from something like “run away from Bootstrap and let’s use Material Design now”.

Material Design has its own problems. The technical documentation of the Bootstrap buttons is exhausting. There are, for example, the following information:

• All modifications including code samples
• Possibilities of using different HTML tags
• Accessibility aspects
• Warning about browser problems
• Javascript API documentation

…and much more. The technical documentation of Material Design is basic and insufficient.

If I make things much simpler than they actually are, Material Design may be more interesting for teams where designers collaborate with developers on a product. Bootstrap, on the other hand, can be more suitable for solitary developers who are working on both the UI design and its implementation. They will really appreciate the detailed technical documentation.

Bootstrap 4 is simply the most sophisticated UI library for the web, however, it lacks the style guide and documentation of the design system.

In your WebExpo’s presentation summary, I see that we can forget about the fact “that you have to code email like it’s 1999 and everything has to be styled inline and built with table layouts”. Is it really possible to remove inline styling and <table> tags when dealing with Outlook?

Since Gmail made an update last September, over 95% of emails opened now support embedded <style> block, including Outlook. It’s still best to include some basic inline styles to cover that other 5% but most of it can now be moved.

For <table>s it’s 94% that work without them. And only Outlook holding us back. Most email devs are using conditional comments in their code these days so the tables will only appear in the code for Outlook, and I’m working on a project currently that removes 100% of tables but still rendering fine in Outlook.

I like the idea of the API I saw in your product called Rebel. However, isn’t it a bit limiting for devs to choose from ready-made templates only? Most of the clients I know (and designers too) want to design their own custom templates.

Through our API we offer a huge amount of customisation, down to every individual element in the interactive components. We also allow custom HTML to be added by our customers. And we have a new update coming that will allow for basically any email layout to be created via nothing but JSON.

How does Rebel work together with existing newsletter workflows and tools like MailChimp?

We sit alongside the ESP’s, we generate the email code and export it as an HTML file. This can then be uploaded manually or in some cases passed automaticall into the ESP ready to be sent. Once the email is sent we collect analytics on every interaction in the email, these results can be viewed on our dashboard or integrated directly into your existing software.

And the last question: I’m glad you are talking about accessibility in e-mails. It is related to my ongoing WebExpo’s talk about accessibility code patterns. Will you have time to discuss this topic in your talk?

Last year was the first time I’d really heard any talk about accessibility in email, but now it’s a hot topic in the community. I’m doing my best to spread the word along with a few other great email developers. I will be covering it a little in this talk but I’m also working on a full talk about accessibility in email for another time.

Thanks for the excellent Perch CMS! I use it and I’m very happy about it. Are you planning any major innovations which are not publicly known?

We are currently working on a redesign of the UI which will ship with Perch 2.9. I’ve written a couple of posts about that process.

• Rebuilding the Perch UI - not your usual redesign
• Rebuilding the Perch UI - creating a pattern library

I noticed you’ve been in Prague. It’s something special, what you’re looking forward to?

I’m looking forward to visiting Prague itself - I have been before but was at a conference outside of the city in a business hotel so didn’t really get to experience Prague itself. At WebExpo I like the fact there are talks on business, development and design as these are all strands I think are important.

Thank you for the interviews and I am looking forward to your speech on Saturday afternoon.

Rachel’s speech: The right layout tool for the job.
Photo credits – author: Jeffrey Zeldman, published under CC-BY-2 licence.

Harry, I’m looking forward to your speech! Just imagine this: one part of the CSS code on one of my projects is terribly old. You know, it is the place you don’t want to go after dark. Is it possible to recommend the first three steps that should anyone with a similar problem do?

I help clients refactor old CSS a lot, and the three key steps are usually all the same: The Three I’s.

Identify

It’s all well and good knowing that ‘your CSS is a mess’, but which bits specifically? Which parts of your codebase are causing you problems right now? Which ones will be the quickest to refactor? Which parts will provide you with the most benefit once refactored? It is important to identify prime candidates for refactoring.

For example, the CSS for your nav might be cumbersome and hard to work with, but if the nav works correctly, is accessible, and you rarely have to edit the CSS for it, refactoring it will not provide you with much value. However, your layout/grid system might be incredibly fragmented and inconsistent, it might have cross-browser issues, its responsiveness may have been bolted on as an afterthought, and of course it is probably used extensively and frequently, so you might get a lot of value from tackling that first.

Isolate

Once we have identified candidates for refactoring, we need to isolate them before and during working on them. Suppose we have decided to refactor our layout system first, we should rewrite this in isolation, outside of our project.

In order to do this, open a new jsFiddle, Codepen, etc. and begin work there. Do not refactor features back into a stale codebase, as doing so runs the risk of making use of legacy CSS that may itself be refactored in future. For example, we might be using a traditional reset in the current project, which may be replaced by Normalize.css in future—we don’t want to build our brand new layout system on top of a reset that will be removed in six months time).

Build the new/refactored version of your feature in complete isolation so that you know it is well encapsulated, and it’s making use of any legacy.

Implement

The final step is to implement your refactored feature. Copy and paste the jsFiddle CSS into the relevant part of your project, and see what happens. 90% of the time, you’ll find that there are some problems: conflicts with existing CSS, naming collisions, existing styles leaking into your new code, etc.

We tackle these details at implementation stage, and we need to give careful consideration as to where we place the fixes. If the fix solves a problem with the layout system itself, it is usually best to place the fix in the layout system’s partial. If the fix addresses problems arising from conflicts with legacy code, it is often best to place it in a Shame.css file. This keeps the legacy fix away from greenfield CSS, meaning it will be much easier to remove once we’ve refactored whatever legacy was causing the problem in the first place.

Author’s note: as you may have noticed, Harry wrote detail blog post on the topic after answering my question.

I follow your ITCSS activities. Is it possible to briefly describe how it is different from the existing methodologies – for instance from SMACSS?

Of all of the CSS methodologies available, ITCSS is most similar to SMACSS. It deals with types, or Layers, of rules, and strikes a balance between inheritance and encapsulation models.

The key idea of ITCSS it to use CSS’ inheritance-led design to our advantage, ordering our CSS in a very specific and particular way (based upon three key metrics). This paradigm allows us to extend and grow projects very easily, and allows for a greater number of people to contribute to the codebase in a very safe manner. It’s also compatible with any view libraries, or Web Components, or tech stacks you like.

ITCSS borrows paradigms from lots of different areas, but leaves almost everything completely optional. For example, I use ITCSS with BEM naming, and OOCSS-based structural CSS, but neither are mandatory for someone to be considered ITCSS compliant.

ITCSS also has a more granular approach, breaking (S)CSS rules down into seven default categories that can be extended (but never reordered) depending on your needs.

And finally - have you ever been to Prague? Are you looking forward to anything in particular?

I haven’t! There isn’t anything in particular, but I am excited for Czech beer, and exploring the city! I’d love any recommendations you might have…

Thank you for the interview and am looking forward to your speech!

Harry Roberts photo credits – author: Andreas Dantz, published under CC-BY-2 licence).

• What is Flexbox?
• Flexbox: Practical Examples
• [Updated] Flex Container Properties
• [Updated] Flex Item Properties
• Flexbox Browser Support
• [New] What Is Good To Know about Flexbox
• Interesting Links to Flexbox

Each property is now illustrated with a picture and demos from Codepen.io are attached.

Read it online or buy it as an ebook.

How To Think When Designing The Main Navigation?

Design the navigation as simple as possible. When designing the website structure, apply the Mobile First approach. Simply forget about twenty-six items in the main navigation and about the second and third level. This will save your butt when designing the website. 

Design the website as if the navigation was not there. It is absolutely clear that on the smallest devices, we will have to hide a part of the menu. Therefore, we have to start designing websites without it. Just duplicate the navigation scheme in the content and place something like the site map on the homepage.

If you can fit the whole navigation in, show it on mobiles as well. It may sound a little funny, but the world is full of menus with 4 items that hide the menu under a hamburger icon just because it is cool. If the resolution is high enough, just show the menu. 

If you can’t show the whole navigation, consider using different design patterns than the show / hide pattern. I suggest you take a look at The Priority+ Navigation Pattern. 

And if nothing of this works, then choose the show / hide design pattern – the one we call a hamburger, based on the icon shape.   

Keep reading - by choosing the hamburger design pattern, you are very likely to run into a lot of problems. 

The Hamburger Icon Is a Troublemaker, But We Need it

The hamburger icon and hiding the navigation has recently been under fire from critics. I say that on some websites we can’t do without it and web design as a discipline needs it. 

It is well-known that icons take time for people to get to know them. The mankind was not born with the knowledge of what the play, pause and stop icons stand for. 

One of the main reasons we’re able to use these symbols (play, pause and stop) unlabeled is the fact that it worked its way into our cultural repertoire thanks to continued repetition on tape decks and VCRs.
– Andy Budd, In defence of the hamburger menu

The hamburger icon is relatively new and it gets even more complicated when you consider operating systems and their native apps. These apps use various icons for opening the navigation (hamburgers, kebabs, meat balls…). Users simply don’t know what these icons stand for. 

Earlier in the text, I said we need the hamburger icon in web design. Therefore, we have to educate users by using test labels. 

In the age of minimalism and flat design, it is also important to say that an icon should look like a button. 

Does The Hamburger Icon Reveal What It Represents?

Every icon is an abstract simplification of what it triggers. In the case of the hamburger icon, it stands for a list of items. This may correlate with a simple navigation with items stacked onto each other. However, it may also reveal a multilevel menu or a whole secondary content as we can see at the website of the Czech magazine Respekt. This is just not right. 

If we don’t want to discourage our users, we should use the hamburger menu icon as an abstract simplification of the content it represents. 

In connection with this issue – my Czech fellow Adam Fendrych is saying that it might sometimes be beneficial to replace the “Menu” label with something that describes the content we will find when opened, e.g. “Categories”, “Recipes”, etc. 

What To Do If a Hamburger Icon Must Be Used?

Some websites can display the whole navigation on mobiles, some do not even need it and some use a better navigational pattern - item prioritization. 

Therefore, we are left with websites where hiding the menu, or its part, is simply inevitable - especially when talking about really small screens, e.g. 240 pixels. Well, in that case we will need some icon to do that, won’t we? 

In conclusion, the hamburger icon is a good thing, but the following conditions must be met:

1. We should not use the icon for showing content it does not represent.
2. We should label the icon as “Menu”, especially when the target group is not “geekish”.
3. We should not hide the navigation on screens where at least a part of it can be displayed.
4. We should make sure the area around the icon looks like a button.

html {  
  box-sizing: border-box;  
}

*,  
*::before,  
*::after {  
  box-sizing: inherit;  
}

@at-root {  
  @-ms-viewport { width: device-width; }  
}

body {  
  -ms-overflow-style: scrollbar;  
}

a,  
area,  
button,  
[role="button"],  
input,  
label,  
select,  
summary,  
textarea {  
  touch-action: manipulation;  
}

fieldset {  
  /* Chrome and Firefox setting here  
     min-width: min-content */  
  min-width: 0;  
}