Blog

The state of CMSs: traditional, headless or decoupled?

posted by Alessandro Lo Verde

Headless CMS is a term that has been on everybody’s lips recently, along with Content as a Service and Decoupled CMS. Actually, these three concepts are very closely related; you can’t talk about any of them without citing the others as well but, for a better insight on the topic, talking about the idea of Content as a Service is a good starting point.


Content as a Service (CaaS)

The first CMSs were born in the early 2000’s as authoring tools to create and manage websites: everybody surfed the web with a desktop computer or, to a lesser extent, with a laptop so the final output was the standard HTML page. As technology progressed and modern smartphones hit the market, some developers argued that the content had to be delivered to users in a mobile-friendly and optimized way. Taking a standard html page, with large images optimized for desktop view, and heavy-loading scripts and assets and therefore tweaking it for a good mobile view, is a waste of resources that are quite scarce on mobile phones (especially when the mobile hype started). But there are not just mobile phones out there; new devices enter the market even as we speak, like watches or smart-home devices and many more will add to that list in the very near future. This is what Content as a Service is about: have the content produced just once and then delivered to every device in the best individual format, namely breaking the strong dependency between the content creation and its output display.

Sever the head for more flexibility

If we apply the concept of Content as a Service to the logic of a CMS, we start figuring out what a headless CMS is about. In a standard CMS we have a content creation layer, a repository (a database) and a delivery layer. The latter has the purpose of turning the data from the repository into real HTML pages. In a Headless CMS we don’t have the delivery layer (the “head” of our CMS): the content is stored in and delivered from a repository as structured data (often JSON) using a RESTful API. One could wonder what happens to the data at this point, and that is the concept of a headless CMS: the data simply does not go anywhere, it’s fetched by the front-end client by means of the API provided, so that the output is optimized for every device instead of having a single output, tweaked and scaled in multiple versions.

Of course, building a custom front-end means more work but we make a huge leap in terms of flexibility, when we need the data to be displayed on different outputs (the terminals of an airport could use the same data on the website as well) or when a company has specific needs for the front-end and a traditional CMS’ approach would be too limiting. On the other hand, using a headless CMS does not fit every situation and can lead to a meaningless increase in costs and time: a company’s presentation website, even a complex and highly interactive one, can make a good use of the traditional CMS’ presentation layer with a good built-in responsive strategy.

Headless or decoupled?

So, we have now a separation between the content creation process and the delivery to one or several platforms by means of APIs: basically the headless CMS, once it has delivered the content that was queried, has completed its task. It's now up to the custom front-end to take care of what will be following. Sometimes it is better to extend this approach and take care of what’s happening after and, in this case, we are moving into the territory of decoupled CMSs

Why just one head?

Scrivito has a very nice and powerful content management interface (the delivery layer we were talking about before) and it spots a high degree of customization that perfectly fits in most of the cases when one could think about making a custom front-end (something that does not come lightly, from the costs point of view). But Scrivito supports multiple heads, therefore becoming the perfect solution for companies that want to build a dedicated front-end for a particular device (wearables, for example) without loosing all the advantages of a powerful and fully-customizable content management interface. 

Grill.rb and Grill.js

posted by Alessandro Lo Verde

Suppose that you want to buy a grill to have a small party with a couple of friends, and then you realize that you’ve placed the wrong order since a monster sized grill arrives at your door. You probably want to send it back, trying to explain that the size was missing from the item’s description, or explain that you just made a mistake with this order. But Ruby on Rails evangelist, Marcin Wierzbicki, had another idea: why not call some developers and have them gather around this giant grill, cooking, drinking and talking about their favorite topic, programming? 


Then, sometimes, things become bigger…

This small barbecue meeting has since grown and evolved into what is now Grill.rb and Grill.js: Poland's first outdoor conferences about Ruby on Rails and Javascript. Several speakers, plenty of food, nice after party and a cosy atmosphere. The conferences’ setting was the beautiful polish city of Wrocław, on the river Oder. The first event, about Ruby on Rails, started indoors at 13:00 on July 1st, since the weather forecasts were pretty pessimistic about an open-air conference. Ultimately, the weather was totally fine and the grill was great, with plenty of food; not only meat but a fine selection of vegetables and cheese available as well: that was the most awaited moment of the conference, of course. The second conference, about Javascript, was held the following weekend, on July 7th, and started a bit later; but it included two barbecues!

Grill.rb

The first day of Grill.rb had many interesting talks, starting with the hidden cost of building and maintaining a microservices architecture. After the barbecue it was time for Ruby security and the consequences of having a loose one. Then came the Open Space, a moment devoted to spontaneous, loosely moderated discussion groups, hosted by Marcin Wierzbicki, the main organizer of Grill.rb. The last two talks were a passionate introduction to Rom-rb 4.0 and an interesting clarification about the advantages of Continuous Delivery. Sunday began with a presentation of the upcoming Ruby 3.0 and afterwards the focus turned to Javascript and its relationship with Ruby. The second to last talk was about the dark kind of magic you may end up with after monkey patching Ruby on Rails, while the last one was by David Császár, from Infopark, who gave an overview of his personal experience with coding style at Infopark, and how his teams went more productive using Rubocop.


Grill.js

The themes discussed were pretty hot: Redux and how to handle its side effects and its integration with Typescript, the way to achieve native experience with progressive web apps and, of course, React. There was a lot of interest around React and Fiber, Continuous Integration Workflow and performance improvement were the topics discussed. Infopark was, once again, on site with one of our JS experts, Tomasz Przedmojski, who held a humorous and light-hearted take on certain anti-patterns and bad practices in JS projects.

It’s partytime!

After each event was the after party at the Mleczarnia pub, a basement bar offering local craft beer and the (highly appreciated) traditional polish vodka (Żubrówka Black Czarna). Plenty of space had been reserved for the conference attendees – basically everybody was there. There was an after-after party later, but only the bravest went there.

The conferences were a clear success and, as Dave reported: “if this had been outdoors completely, it certainly would have been the greatest Ruby conference of all times”. As mentioned before, it all started as a small meeting between friends with a passion in common: programming. Sometimes great things grow from humble beginnings, and Grill.rb & Grill.js are perfect examples of this. Marcin's passion has helped launch one of the EU’s best Ruby and Javascript events and we look forward to taking part in next year’s event.

Just a little souvenir

Nuremberg Airport Website: A Scrivito Case Study

posted by Alessandro Lo Verde

There are good CMS's out there, and many are fine tools to make blogs, websites for small business and even for a medium-sized one; but can they handle a large website, with a lot of data interaction that comes from external sources? What comes up if you need to build an intranet as well? Scrivito rose to the challenge and was able to handle every request and then some.


One data source, several outputs

Short story: the Airport of Nuremberg was in need of a massive redesign for its website and they needed it in just two months. As one can guess, developing an airport’s website is not child’s play: you need to provide the user a flight board that retrieves data in real-time and in the most reliable way, users expect to be able to book flights (and possibly cars, hotels and more), multilingual is a must and of course, security is a major issue. It’s quite a challenging task and if you start developing with the wrong tools, you will soon find yourself painted into a corner, but the development team at Infopark was quite confident to have the right ones at their disposal since Scrivito is pretty different from the standard PHP-based CMS. The Scrivito CMS has been built for Ruby on Rails web applications, with two claims firmly embedded in its foundations: power and flexibility. With the aid of a Ruby programmer, you can do almost anything, and Scrivito really stands up when it comes to data-mapping and an extensive use of dynamic content.

With powerful and flexible API integrations and thanks to Rails Stack technology, building up multi-source widgets that get data from multiple sources is perfectly possible with Scrivito. Widgets can be reused anywhere on the website, sharing and processing the same data, therefore giving the website user a more comfortable and reassuring experience. 

Everything in one place

The booking widget is probably the most visible feature of the Nuremberg Airport website; it connects to the airport’s airlines database and retrieves the data for displaying it in different contexts. But with the table widget is possible to achieve even more, gathering the data from all of them and merging then all together into a dynamic a table. Thanks to this flexible table widget, it is possible to combine features to create new interactive functionality. Users can select a destination, check the routes to that destination, book a flight, search for a hotel, check how to get to the hotel, rent a car, book a parking space etc., etc., etc. One great advantage of Scrivito widgets is that they can be easily reused across the website and are highly customizable, giving the client a high degree of control over the website.

Some clients have special requirements and the Airport of Nuremberg was no exception. They needed to be able to manage emergency situations, and events such as these have to be carefully considered in a sensitive environment like a passengers airport. The Infopark team built for that purpose a Security Center; a control panel where the airport’s operators can enable/disable features and handle emergencies situations.

Not just one website

Of course an airport’s website requires more than just one language: no problem at all since Scrivito has built-in multi-language support that allows editors to manage several different language versions of a website, sharing the same data.

There is also a multisite feature built in Scrivito that has been used to build and manage an intranet as well; to ensure the high security level required by intranets, all information is shared with the website through web services, keeping the two platforms separate, while allowing the editors to write content just once.

Choosing the right tools to build up a large and complex website does not only mean that CTO's and developers should consider the features available, but also check to see if they are easy to use. If you have powerful features at your disposal, but they are accompanied by a steep learning curve that requires editors to be intensely trained before using them … well, your costs may increase beyond expectations. Building up the Nuremberg Airport website and intranet was not an easy task and the deadlines were strict as well; but thanks to Scrivito’s easy-to-use interface and its high level of flexibility, the Infopark team has another satisfied client on its record.

The Magic of Viewport Units

posted by Alessandro Lo Verde

Viewport Units are a fine addition to the new CSS3 properties and allow us to calculate dimensions according to the actual size of the viewport, instead of the parent element (as it’s always been so far). There is a new precious tool for better and easier responsiveness that leads the way to a new approach, not only to the process of layout building, but also to web typography. 


Viewport width and height: an overview

Viewport Width (vw) and Viewport Height (vh) are units that define a relationship to the width or, respectively, the height of the viewport, and each of these units represents 1% of the total viewport . So we have:

    1vh = 1% viewport height
    1vw = 1% viewport width
    100vh = viewport height
    10vw = 10% viewport width

At first glance, one might wonder whether there is any difference between width= 100vw and width= 100%; of course there is, and it’s a pretty big one. An element that has 100% width is exactly as wide as its container while another one with a width of 100vw will always have the size of the viewport.

This becomes more clear when considering the height, since a block level element, for its default behaviour, will widen itself as much as possible, but it will be just high enough for the content to fit in. An element with a height of 100% will cover the viewport only if its parent does, something you can achieve by assigning a 100% width to the html and body element; an element with a height of 100vh will always extend to the browser window’s height. 

There’s an intuitive and quick use for Viewport Height, namely if we need a series of layers with a nice background image that covers the viewport entirely: just setting the layers' height to 100vh plus a combination of background-size: cover; and background-position: center; will give us what we want on mobile as well without major adjustments.

But wait, there’s more: vmin and vmax

Vmin and vmax complete the specification of the Viewport Units. They express a percentage of the viewport’s largest (vmax) or smallest (vmin) side. Vmax is always the longest side of our window and it will be the width when we keep a mobile phone in landscape mode but, if we put it in portrait mode, vmax will become the height.

A headline that really fits

It’s a popular trend to have one big presentation headline just on the homepage of a website, but it always requires heavy resizing when we switch to mobile phones. In addition, one should provide an extra rule for the mobile screen’s orientation, since a headline that fits when we are in landscape view, will definitely be too large when we put the phone in portrait mode. 

We can solve this problem by binding the headline’s font-size to vmin; since it’s always the shortest side of the viewport, it will fit the screen even if we change the orientation. It’s highly recommended to use vmin instead of vmax since the former has better support. 

Viewport-based typography: a quick note

With the many devices and resolutions we need to consider in our development flow, using a fixed font size is certainly not a good idea, since it will inevitably be too small or too big for a large number of users. Usually, web designers solve this problem with media queries, setting up breakpoints for mobile, small screens and big ones: it’s an approach that usually brings positive results but it’s not easy to maintain, and it would be nice to have a rule that can define a size that fits all.

Viewport Units can surely aid on that topic, since they are bound directly to the viewport size, but binding the font size directly to a fixed percentage of the viewport (1%, for example) does not lead to optimal results. If we define font-size: 1vw, it will be definitely pretty good at medium resolutions, it’s 16px at 1600x1200, but totally unreadable on mobile when it’s shrunk to less than 4px. It would be much better if we could define a base font size and increase it according to the viewport:

body { font-size: calc(12px + 0.3vw) }

This returns a font size of roughly 13px on mobile, 15px on a 1024px resolution and 17px on a screen that is 1680px wide. However, some compatibility issues related to window resizing have been reported, so the following equivalent statement should have better support:

body { font-size: calc(75% + 0.3vw) }

How safe are they for today’s use?

Nowadays, almost every CSS3 property has a good overall support, and viewport units follow this trend with only IE8 and old iOS and Android versions (5.1 and 4.3, respectively) that lack full support. However that doesn’t mean that within the supported browsers everything is fine: the most serious issue relates to the scrollbars that are erroneously computed into a 100vw declaration (Firefox doesn’t have this issue) and this often requires an overflow-x: hidden fix. In addition, vmax is unsupported by IE9 and other more recent browsers (noteworthy is that it’s sister property, vmin, is fully supported).

The availability of the exact viewport height and the possibility to use it in production has always been one of the most awaited CSS features; combining calc() and viewport units helps us climb one step further towards full layout control. With the aid of Flexbox, and the upcoming CSS Grid, we could consider the process almost complete: time to move on to a new challenge!

Scrivito 1.10.0 Release Notes

posted by Andreas

More options for creating, copying and moving pages

For making the life of editors even easier when creating pages, we've added several items to the page menu and made the wording more consistent. There are three new menu commands:

The Add subpage command lets you add a subpage to the current page, provided that the current page is part of the page hierarchy (i.e. that it has a path).
After issuing the well-known Copy or move page command for the current page, you can now also paste or move this page as a subpage, either directly underneath the current page (paste) or elsewhere (paste or move). For this, the corresponding new menu items Paste as subpage and Move here as subpage are available, again provided that the target page has a path.

Further improvements and bugfixes

  • More flexible attribute defaults
    When a user creates a page or a widget in place, its attributes can be initialized. If, for example, the author attribute of a new page should be prefilled with the user's name, you can achieve this by defining the default_for callback of the underlying page model class accordingly. Next to the current user, Scrivito now also passes the page the user is viewing to the callback. This enables you to assign attribute defaults based on properties of the current page, e.g. its model class or its location in the page hierarchy.

  • Updating binaries from temporary files
    Using Ruby, it is now possible to upload remote binaries to CMS objects directly, i.e. without first downloading them to regular files. For this, a Tempfile is now accepted when updating a CMS object:

    # Download an image to a local Tempfile
    require 'open-uri'
    tempfile = open("https://upload.wikimedia.org/wikipedia/commons/c/ce/Example_image.png")
    
    # Upload the temporary file to Scrivito
    @obj.update(blob: tempfile)

    See the Binary#upload class method for details and examples.

  • Fixed reloading of strings and enumeration values
    Scrivito's in-place editors let you edit content directly on a page or in the properties dialog of a page or widget. As a developer, you can have the contents of some of those editors reloaded after editing to always reflect their current values. Applying this to the string and enum editors caused a JavaScript “Unhandled rejection error”, which has been fixed.

  • More consistent autoloading for better compatibility
    A bug with Rails' eager loading has been fixed. Previously, the Scrivito SDK used a mix of plain Ruby autoload and Rails autoload_paths to load its code. Now scrivito_sdk relies solely on Rails autoload_paths, which makes the SDK compatible with sidekiq.

  • Improved link and linklist in-place editors
    The editors for link and linklist attributes now properly handle double quotes in link titles and link URLs.

  • Image editor available again in editing mode
    If an image object is selected from the changes list in editing mode, the built-in image editor is now available again in the image's resource dialog. The same applies to the image's details dialog opened, for example, via the Content Browser.

Reverse Box Order on Mobile

posted by Alessandro Lo Verde

It’s a pretty common trend for many presentation websites to have a 3-column “feature box” where products or features are showcased. Since on mobile they would be squeezed too much, it’s a best practice to make these boxes 100% wide and place them one under each other, following the same order, from left to right but in a top-down direction. Now, although changing the box order on mobile devices is rarely requested, what if we were asked to do this? How can we solve this? With Flexbox!


Meet a slightly grumpy friend: Flexbox

The Flexible Box Module (Flexbox) is a CSS3 module (a set of properties) that provides a new and more powerful way to arrange, distribute and fit elements into a container. Although this is one of the most interesting features in CSS3, its adoption rate has been pretty low in the past because of many reasons. It’s not supported by IE9 and, when Microsoft dropped support for IE8, leaving IE9 behind as well was often considered not acceptable: with Flexbox being a layout module, you can not easily provide efficient fallbacks. The second reason is about the syntax: it has changed many times, leaving developers in chaos and confusion. Even today, if you need to have extensive support, the syntax is so complicated that is best to rely on SASS/LESS mixins that can take care of the different vendor prefixes. Last but not least… Flexbox can be really hard to understand, and some odd behaviors often show up unexpectedly unless you have studied it in detail.

But all these struggles aren’t in vain since Flexbox is a set of powerful and useful properties that will change the way to build layouts, and they will also rapidly solve some troubles that would be hard (or impossible) to solve without them.

A pretty common scenario …

After this long, but unavoidable introduction, let’s get back to our task of having to arrange the boxes inside our “feature box” in a specific order on mobile devices only. Don’t even start thinking about some overly complicated relative/absolute positioning tricks; the order property from the Flexible Box Module will easily solve the issue. We can simply assign a position index to each box using the order property:

.box:first-child { order: 3 } .box { order: 2 ) .box:last-child { order: 1 }

This causes the last box to become the first. Please note that elements without this property will simply stay on top of the order ladder. 

One last note about support

This property is widely supported: very well on the mobile side, back to very old iOS and Android versions (3.2 and 2.1 respectively), and nicely on desktop as well, with only IE9 cut off, but one point to consider is that, as mentioned before, the syntax varies and can be categorized into: old, hybrid, modern and new. 

#featureBox { display: -webkit-box; ⇒ iOS up to 6.1 and Android up to 4.3, Safari 6     display: -ms-flexbox; ⇒ IE10     display: -webkit-flex; ⇒ Safari up to 8 and iOS up to 8.4 display: flex; ⇒ Current implementation } .box { -webkit-box-ordinal-group: 1; ⇒ iOS up to 6.1 and Android up to 4.3, Safari 6 -ms-flex-order: 1;      ⇒ IE10 -webkit-order: 1; ⇒ Safari up to 8 and iOS up to 8.4 order: 1; ⇒ Current implementation }


Flexbox probably isn’t the most straightforward and easy to learn CSS3 property, but it’s surely the most powerful, since it’s not a single property but an entire set we can use to shape our layout in ways we could only dream of before. Just keep an extra eye on the nasty syntax.

Getting Out of the Fixed Container

posted by Alessandro Lo Verde

Most of today's websites use a wrapping container element on their pages – for good reason: it’s handy to have an element that surrounds the content, allowing it to shrink and expand to given breakpoints. But our beloved container can sometimes be a prison (and not even a golden one) when we want a full-screen element in our boxed layout. So the question becomes, how can we solve this before there is a prison break?


Out of the wrong path

If we’re working on an almost static website, we could just wrap everything except the full-width element; not a handy solution since we give away the benefits of using a container. Additionally, this is hard to apply in the strict enforced environment of a CMS where the layout is fixed and wrapped in a fixed container by default.

When trying to find a solution, one early approach could be to use negative margins that equal the positive margin on each side of the container. So if we have a container that takes 80% of the viewport, we can assume that the margins are 10%, and we may be tempted to give our full-width box a -10% margin on each side. The result clearly shows us that we failed, but why?


A common misconception

An element’s margins are calculated based on the width of its parent, so the 10% margin of the container is 1680px * 10% = 168px (in this case the resolution is 1680px) but if we set the same margin on the full-width box it will be (1680px * 80%) * 10% = 134,4px, and this is where our solution fails.

To calculate the right margin, we must use the ratio between the container and its margin, then we divide the viewport (100%) by the calculated ratio. In our case, it’s 80% / 10% = 8, and then 100% / 8 = 12,5% – that’s what our negative margin ought to be.

#container { width: 80%; margin: auto 10%; } .box-fullWidth { margin-left: -12.5%; margin-right: -12.5%; }

With a container width of 60% we would have: 60% / 20% = 3 and 100% / 3 = 33.33%:

#container { width: 60%; margin: auto 20%; } .box-fullWidth { margin-left: -33.33%; margin-right: -33.33%; }

So, problem solved? Sorry to say, but this solution only works if your container has a fixed width expressed as a percentage; the typical CMS container is something like: max-width: 1170px, which doesn’t let you calculate the margins.


A more flexible solution

So we need a more flexible solution that can be applied to the containers typically used in common CMSs, and we actually have it, thanks to CSS3 and the new Viewport Units. For someone who hasn’t ever heard of Viewport Units, they are powerful and nicely supported CSS3 units that refer to the width (vw) or the height (vh) of the viewport which is much more handy than percentages that refer to the element’s parent instead.

Back to our problem, the way to solve it is to push the edges of our full-width element towards the edge of the viewport, by means of a negative margin that equals the one we have between the element and the viewport, and with the help of Viewport Width (vh) and calc() we can reach our goal with ease:

.box-fullWidth { margin-left: calc(-50vw + 50%); margin-right: calc(-50vw + 50%); } 

First, we move our box out of the page by half of the viewport (100vw = 100% of the viewport width), and then we push it back again by half of its width.


One last issue, with a reasonable solution

Unfortunately, there’s an issue with this solution that pops up unexpectedly in case the content of our box triggers a vertical scrollbar; with much dismay, we could see a horizontal scrollbar appearing as well. The reason for this is that the specification for the Viewport Units states that if the root element has overflow: auto (which is the default value) the scrollbars aren’t taken into account when computing the viewport width. So, has all of this struggle been in vain? No, there’s a pretty much acceptable solution for that: setting overflow-x to auto on the root level will prevent that unwanted behavior.

html, body { overflow-x: hidden; }

Since the support for Viewport Units is overall good (starting from IE9), we can safely employ this solution; using overflow:hidden so it should not normally affect our layout’s behavior. Just note that if you are using jQuery’s scrollTop() you need to trigger it on document instead of on body or html.

Finally we can use CSS3 in its full glory: it seems obvious today but the time when you had to overload the website with hacks, fallback and polyfills was just yesterday. Lots of new properties are now at our disposal and, not only they’re changing the way we conceive layouts, but they help a lot in solving everyday CSS struggles. 

Let's Embrace CSS3 Calc()

posted by Alessandro Lo Verde

Powerful and widely supported, this handy CSS3 property helps save us from headaches when dealing with layout and box model.

Back in the day, everything on the web was coded in pixels, but as the desire for flexible design arose, font sizes were frequently defined in ems and more recently in rems. With several units at hand, designers and developers started to dream of being able to combine them and make basic computations. Calc() made this dream come true, allowing mathematical expressions like addition (+), subtraction (-), multiplication (·), and division (÷) to be used as component values. So, if we need to divide a container into 3 boxes, instead of { width: 33.333% } we could write { width: 100% / 3 }.

A couple of nasty problems solved

The example above does not seem so life-changing, but calc() unveils its real power with the possibility to combine absolute and relative units. If we need to divide a container of unknown width into 3 equal boxes but… each box should have a 20px margin, well we’re in trouble until calc() comes to the rescue. We could simply write:

.box { width: calc(100% - 40px); } 

Note that we need to subtract 40px since our 20px margin is on both sides. 

As our container shrinks, the boxes retain their margins. 

Another great use for calc() is when we want to give a margin to a flexible element that’s allowed to expand up to 100%. We need to set this element’s margin to auto if we want it to be centered, but we also want it to have a minimum distance of 2em from the edge of the container:

.box { width: calc(100% - 2em); margin: 0 auto; }

In this last example we have a fixed-height element with two other elements inside; one fixed, and the other one that expands to cover all of the remaining space. You could try something like this:

#container { width: 200px; height: 600px; margin: auto; } .box-1 { height: 140px; } .box-2 { height: 100%; }

However, the second box will overflow the container, and this is not what we usually want. Setting the height of the second box to calc(100% - 140px) will solve the problem brilliantly.

Life is easier with calc()

The examples above greatly show how calc() solves issues that cannot be solved otherwise (except with SASS/LESS of course), but there are many situations in which calc() will make your life just a bit easier. Consider this quite common case: a box of a given height that needs to be centered in a 100% height container. Normally, we shift the box down by 50% of its parent’s height and then shift it up by half of its height:

.box {  height: 100px; margin:auto; position: relative; top: 50%; transform: translateY(-50%); }

Here, calc() lets us condense the code which makes it easier to understand and maintain it (though the above definition comes in handy if we don’t know the height of the box).:

.box {    height: 100px;   margin:auto;   position: relative;   top: calc(50% - 50px); }

If we are feeling a bit lazy (we all have those days on occasion) we could make calc() do some calculations for us:

.box { width: calc(100% / 6) } 

This is much clearer than:

.box { width: 16.666666667% } 

Syntax, rules and errors

Special attention must be given to the syntax: There must be no space between the function name and the opening bracket, addition and subtraction signs must have white space around them, so:

.box { width: calc (100% - 40px) } 

and

.box { width: calc(100%-40px) } 

are both invalid; the correct syntax is:

.box { width: calc(100% - 40px) }

As you may have expected, dividing by zero is not possible.

Compatibility

Compared to other CSS3 properties, the compatibility grade for calc() is pretty good: on the desktop side, Firefox, Chrome, Safari and Opera support it fully since 2012, while IE decently supports it starting at version 9. Speaking about mobile, iOS fully supports it from version 6.1 (prefixed only for that version), while Android has introduced support for it starting with version 4.3 but lacks the ability to perform multiplication and division. The Chrome browser for Android supports it fully.

There are still issues to take into account when dealing with calc(). Most browsers do not support it when used in table cells, IE 9 does not support it when used with background-position, and when using any IE version, you may encounter problems with transform, generated content (:before, :after), box-shadow and when using transitions. It’s also noteworthy that expressions utilizing calc() and viewport units (vh, vw) are not re-evaluated after resizing browser windows in Safari 6 and 7 (applies to desktop as well as mobile versions).


CSS3 has always scared some people: it has a lot of interesting possibilities but some lack IE8 support. It was still widely used in some places and using the principle of “graceful degradation” has always been a risky path to follow. Now that support for IE8 has been ended we can use most of the CSS3 features safely, including calc() and this dramatically extends the box model possibilities.

Web Typography Done Right

posted by Alessandro Lo Verde

Typography is often a mixed blessing for the web: Developers tend to overlook it since it does not play an important part in their interests, and designers sometimes are disappointed about the limits of the web, compared to print design.

And yet typography is what truly makes the difference these days since more and more websites focus on textual information instead of crowding the pages with full-size background images and Flash elements: after all, we are not in 2007 anymore.

Have a cup of coffee and think about the font first

Choosing a proper typeface is one of the most important starting points when dealing with the design of a new website, and at the same time, it's still a field in which substantial mistakes can be made. Developers with little or no design knowledge may assume that only the standard MS Word fonts should be used, thus opting for Arial or Verdana. While professional designers will simply reject that choice since there are many other fonts which look much better for use in body copy.

Let’s make it clear: There’s nothing terribly wrong with Arial or Verdana since they were designed to look sharp and clear on a monitor even at small sizes. Often we cannot say the same for other print designers’ top-pick fonts that on a monitor look messy and blurred if used in small sizes. But Arial and Verdana bring two problems: the first is that they don’t look alike on Windows and MacOS, and second is that they are so widely used (often in unspecialized environments) that they will make your website look like millions of other websites from the past (and not that professional, right?).

So far, the best option is to use a free web font, even better if served by a CDN, like Google Fonts. Open Sans, Source Sans Pro, Ubuntu, Roboto and many others are really good fonts that look consistent on Windows and MacOS. They are easy to implement too; just keep in mind that, since they are so good, everybody is using them now, and in a short span (trends are running fast, you know) they will eventually look as boring as Arial and Verdana. So why not buy your font? There are many inexpensive and fantastic fonts available, designed specifically for web use, that for less than 50$ will give you that spark of individuality that will make you stand out.

One last hint: A lot of designers and developers are working on MacOS and don’t bear in mind that ClearType, the text-rendering engine of Windows, produces slightly thinner fonts. So, if you choose one of these super-stylish-ultra-thin fonts, use it only for big headlines; otherwise, it will be almost unreadable. And don't forget to run real cross-browser testing since it’s the only reliable method if you want to target the widest audience in the best way possible.

Paragraphs in order, please

When you visit a website that looks professionally composed you may be tempted to borrow some of its features, such as the fonts. But if you’re wondering why your text doesn’t look as appealing, you should consider reviewing a couple of paragraph settings. The most important being surely the leading or vertical spacing. It sets the vertical rhythm of your text and its value should be not too high or too low. Don’t set it in pixels, because if you scale the text within certain resolutions (a good practice), the leading won’t scale accordingly, creating an awkward feeling. Set leading spacing in em instead; a value between 1.25 and 1.5 should be fine.

You also have the possibility to modify tracking (letter-spacing in CSS) to improve the readability or the appeal of some typefaces (a common trend nowadays) but this requires a well-trained eye, especially when working on the body copy.

And please do not justify text: Although it has always been common practice in print design (and a must in MS Word), in web design you don’t have hyphenation (well, let’s talk about that later). Also, you lack all the sophisticated instruments that Adobe InDesign uses to make the lines look balanced. So, text justification in the web will almost always give an unpleasant and hard-to-read result.

Justified text

Left-aligned text (default mode)

Justified text with hyphenation (not widely supported)

One last note about hyphenation. It’s not true that you can’t use it at all but overall support is not good (Chrome can, at present, only handle it on Mac, for example) and you have to rely on a combination of hyphens and word-break properties for decent coverage. If you need to use hyphenation with a certain degree of reliability, you can try Hyphenator.js.

There’s more hidden in the keyboard

Good text is made even better with small details. Not using the right glyphs for some special characters can make your perfect post start to look sloppy. Here’s a short list:

  • Use “smart quotes” instead of ”dumb quotes”.
  • En-dash (-) and em-dash (–) look different.
  • Don’t be scared to use accents: résumé is much better than resume.

If you are on a Mac, don’t be lazy: it’s really easy to access special characters like ÷. And you can also quickly type all the ä, ü, ø, ç … of these stylish European languages.

A note on mobile typography

We can't have a post about typography without mentioning mobile web design best practices. When setting up a font scale system, a typical error is to define for mobile viewports a font size that is smaller than the one used for low-resolution laptops. While this has a certain logic to it (the lower the viewport resolution, the smaller the font), it will make the text too small and hard to read since a mobile phone’s screen is not a shrunken laptop screen but rather a small portion of it. So if 10 – 12px could be a good font-size for a 1024 – 1280 resolution, it would be recommended to use 12 – 14px on a mobile phone.

Finally, try to avoid long text boxes. The ratio between the font size and the text box differs dramatically from desktop to mobile, and while your post could comfortably fit your laptop screen, on your phone it may require you to scroll several times before reaching the end. Eventually, it may be perceived as too long and, possibly, skipped. Of course we cannot write different text for desktop and mobile, but we can use a clever trick: our brain perceives a post as too long depending on the time it takes to reach a breakpoint rather than its real end, so we can use sub-headlines more often to make our brain take a break before continuing. 


Thankfully there are lots of inspiring possibilities that were pretty much a risky adventure in the not so distant past. Working with text on the web is definitely more playful now, and the only price to pay is following just a few simple rules. A pretty fair bargain, don’t you think?

Search Usergroup Berlin at Infopark

posted by Alexander Pepper

Recently, we were fortunate to host the Search Usergroup Berlin at our office.

I gave a talk, presenting how we operate Elasticsearch in production and what we've learned over the years. For those who could not make it, we have made a recording of the live stream as well as the slides available for you to check out at your leisure. Thank you to everyone who came out and helped make this night a great success!