position: absolide;

Or why you should still use the minimal-ui value in the viewport meta

If you have developed a webapp in the last year you probably used a meta viewport like this:

<meta name=”viewport” content=”width=device-width, user-scalable=0, minimal-ui”>

in order to gain a little more real estate for your application reducing the chrome of mobile Safari to minimal terms.

Just as a reminder, starting from iOS 7.1, setting the value minimal-ui in the meta viewport force mobile Safari to display the small version of the address bar and to hide the action bar at the bottom of the screen.

It’s a little piece of magic because you can get back a lot of space for your application; it’s a huge 13% more vertical pixels.

I was happy with it even if is not so clear that users have to touch the address bar to reveal the action bar at the bottom.

Bad News

With the release of iOS 8 Apple removed the minimal-ui value so you can’t get this 130 retina pixels back when you load your application.

The standard scroll behaviour is the same you got before the minimal-ui revolution: when scroll down the top bar shrinks and the bottom bar disappears; when scroll up (or tapping the address bar or the bottom of the screen) the bars come back to the normal state.

This simply means no more “fullscreen” for webapps.

Good News

While a lot of devs remove the minimal-ui value from their meta tags I think is a good idea to leave it in place because it is not completely useless.

Not every single iPhone owner will upgrade to iOS 8. I don’t want to judge who does not wants to upgrade but a lot of iPhone 4 and 4s users still stay with iOS7 and, most important, still stay with a shorter screen.

The iPhone 4 and 4s screen is 960 retina pixels height. In mobile Safari you have 742 available pixels with the normal chrome and 880 pixels with the compact chrome.

Starting from iPhone 5 the screen is 1136 pixels height. In mobile Safari you have 918 available pixels with the normal chrome and 1056 pixels with the compact chrome.

This means that with an iPhone 4 with a minimal-ui enabled meta viewport, and iOS 7 still on device, you have almost the same vertical space of a full-chrome iPhone 5 with iOS 8 — 880 vs 918, just 38 retina pixels (or 19 CSS pixels).

It’s pretty the same space with just a little word.

While testing some sites I'm working on on different devices I noticed that Google Chrome for Android doesn't render web fonts from Webkit (at least on my test device, a Samsung Galaxy SIII).

Looking at the browser and OS support table on Typekit website Chrome and other Android browsers are supported since the version 2.2 of the Google's OS and trying the same site on the default browser everything was ok.

So What's Wrong With Chrome and Typekit?

Digging down I've discovered that not all fonts in my sites have the problem; only the fonts on which I added the variation-specific names option are rendered with the next font in the stack.

According to the Typekit instructions:

The variation-specific name will be undefined in browsers that don't have these issues, so they will use the full family name that comes second in the stack.

Unfortunately this seems not so true on Chrome on Android but, however, is not a big issue.

The Solution

All you have to do is to use the variation-specific names ONLY in IE8< declarations.

You can use any technique you prefer for serve IE8< specific font-family declarations but I suggest HTML conditional classes which allow you to build faster and more maintainable solutions nesting the selectors in SASS and Compass or using mixins to do the job for you.

Example Time!

Using the same example on Typekit page seen before you have to change this:

#post-title { font-family: "proxima-nova-n6", "proxima-nova", sans-serif; font-style: normal; font-weight: 600; }

Into this:

#post-title { font-family: "proxima-nova", sans-serif; font-style: normal; font-weight: 600; } .lte-ie8 #post-title { font-family: "proxima-nova-n6", "proxima-nova", sans-serif; }

Or, in SASS, like this:

#post-title { font-family: "proxima-nova", sans-serif; font-style: normal; font-weight: 600; .lte-ie8 & { font-family: "proxima-nova-n6", "proxima-nova", sans-serif; } }

And everything will works fine. If not, let me know what is your device and the URL where I can see the problem.

The best thing working on a Spotify app is the sense of discovery because the lack of documentation* and use cases to search through when something doesn't work. It's like the 2000's when not everything was already blogged. The worst thing is the lack of support for some modern web features. If I can understand the reasons why VIDEO and AUDIO support is disabled I understand less why webfonts does not render. Searching the web I've found an old answer on Stack Overflow that explains why webfonts are not supported but does not provide a solution. So I've started searching a solution without success. When I almost was at the point of using Verdana for everything I remembered the quirks between Webkit and webfonts; starting with the bad rendering of the woff format and the inline-block white-space bug and I remembered that for both the problems the solution was to use SVG fonts. So I've tried to serve only the SVG format in the @fontface declaration and: ta-dah! It worked!

Conclusions

If you want to use custom webfonts in a Spotify app follow this simple steps:

design with fonts you like;

find or generate only the SVG version of the font;

use a standard @font-face declaration in your CSS specifying the SVG format only;

enjoy the webfont perfectly rendered (even better than with woff format).

Test app

If you want to give it a try you can download a test app I've built from github.

Let me know if you find bugs or if this solution doesn't work for you.

Once released the Unlimited Grid Layout Boilerplate (UGLB from now on) I've received a little amount of feedbacks. One of this feedbacks comes from Zoran Jambor, the editor of CSS Weekly. He substantially said that people need some built in methods to navigate through the pages. So I started build some Javascript APIs to give a more structured package to developers.

Expanding

Writing the navigation API took very little time but just after that was complete I've understood that this boilerplate had to be something bigger. It had to be a full-featured presentation tool and, why not, a framewok for build some type of websites.

I started adding features to manage not only the navigation from page to page but also fragments management and expanding the APIs to configure the framework with a few commands.

I didn't want to include dependencies, because I want to let every developer to build on top of the framework using his preferred set of libraries. So I've decided to implement all the animations, slides and fades with native CSS3 transitions; easy to remove in case they need to be substituted by animation libraries like GreenSock or others (but I strongly reccommends GreenSock).

This driven me to the decision to not support too old browsers who degrades to a simple version with less features (i.e. without animation in IE9) or directly to the the UGLB without problems.

Packaging

After some weeks of writing, testing, refactoring and testing I was ready to release a basic version of the framework with all the logics and APIs documented on Github, but at that moment, looking at others presentation frameworks, I've decided that I needed a basic presentation that drives users to the learn about the framework direct from it.

This was the most difficult task for me because I've restarted the work at least three times before finding the right way that was, ironically, the simplest one.

But soon I realised that that was too much complicated and too less useful for visitors who need to understand whether the framework can be useful for their own purposes in a short time. Then I've simplified, simplified and simplified until I've built the current sample presentation.

And I had to style this presentation so I've included a basic theme with some simple media queries so it is not only fluid but also responsive.

Naming

And after I finished this presentation I still need a name for the framework.

I choose Flowtime, because I've built this framework to navigate through slides with just one key, optimizing the time to go from the the start to the end and reducing the complexity of the control system.

I like to think that, with Flowtime.js, speakers can build great and detailed presentations focusing on the speak and not on "what's-the-key-I-need-to-press-to-go-to-the-right-slide".

Maybe I'm right, or maybe I'm wrong, but here we are!

Ok, let's see Flowtime in action!

You can take a look to the sample presentation to quick learn about the basic features.

And you can dive into the documentation and the configuration features looking at the source code on Github.

Using inline-block instead of floats on elements is – IMHO – a better layout choice but it requires some tricks to remove the white space between element.

Chris Coyier has collected a very comprehensive list of techniques to fight the space between inline block elements; if you want to know why this space is rendered and how remove it I suggest to read his post.

The font-size: 0; and font-size Reset Technique

My favourite technique consists in setting the font-size: 0; property on the parent and then resetting the base font size on child elements. I prefer this one above others because is less empyric than use an arbitrary negative spacing between words or letters and because involves a single property instead of two or more.

Unfortunately also this technique has a drawback; in Safari for Windows the white space does not collapse.

As said by Philip Walton in his comment this bug makes the technique unusable. But now I found a solution, or, rather, I discovered that the fix to solve the font rendering issue in Chrome solves also this problem.

The SVG Solution

Font Spring published a fix to improve the rendering of webfonts in Chrome. I used this technique in a demo and a friend asked me why in my implementation the spaces were gone even in Safari.

Looking for an explanation in the only way it ever worked – dismantling the CSS one rule at a time – I notice that serving the SVG version of the webfont before the Woff one also fixes this problem.

To better test the technique here is a demo.

The first row of "things" have a regular, standard, @font-face rule applied to the parent element; look at that page with Safari for Windows to see that the space between element is still here.

Then take a look at the second row of elements. I've applied to this element a modified @font-face rule as explained in Font Spring post, serving SVG before Woff. If you look at that page with Safari for Windows you can notice that the spaces were correctly collapsed.

[quote] Now, the trade-offs

As explained in the Font Spring post there are three trade-offs. Honestly I think that the first two are acceptable and the third is not a Safari issue and then we will think about it when Chrome will improve the font rendering.

And what if I'm wrong?

As promised I released the Flex Box Layout Module version of the Unlimited Grid Layout Boilerplate.

I would wanted to build a version compatible with old and actual Flexbox model's syntax but it was not possible to make a correct version with the syntax of 2009.

Anyway, I agree with Chris Coyier when he say: "Despite more support, it's not smart to be using the older syntax". So I decided to release only the new syntax version hoping that browser vendors realease soon a version which supporting the specification.

As in the, now named, inline-block version, look at the demos is the best way to learn about this technique. Warning: Chrome 21 or Opera 12.10 browsers required .

Unlimited Grid Layout Flexbox Demo — Ordered by Columns

Unlimited Grid Layout Flexbox Demo — Ordered by Rows

As you will see in the css, which is fully commented, this version in much more simpler than the inline-block one.

Only two properties are involved in this version and both are on the container responsible of stacking pages horizontally.

They are: display: flex; and flex-flow: row nowrap;.

The display: flex; property triggers the Flexbox layout on the container and the flex-flow: row nowrap; place the child elements in a row and prevents them to wrap around.

Without any other declaration the container's width  will be divided equally by all the child elements, as defined in the Flexbox specifications. To override this behavior we have to add the declaration min-width: 100%; to every child element.

Update! To force the boxes to be as wide as the container we have to add the declaration flex: 0 0 100%; to every child element.

The flex declaration is a shorthand for flex-grow, flex-shrink and flex-basis properties.

Setting the flex shorthand to 0 0 100% we stop the flexbox to trying to redistribute free space across elements and force the initial width of every box as 100% of the parent's width.

Thats it! Really, really simple.

The drawback is the inexistent support by current browsers. At the time of writing only Chrome 21+ and Opera starting from v12.10 browsers support the properties needed to achieve the result.

Ok, now we can wait that browser vendors will support soon the new W3C Reccomendation but, meanwhile, if anyone would use this boilerplate in a production project I reccommend the inline-block version.

I hope you can find this boilerplate useful even if it cover just a really particular layout. If you have any suggestions or if you build an working old flexbox syntax version od this code, please, let me know.

* Updated with the Flexbox version.

During my work as a frontend developer I coded many sites with a full page layout, both before and after the Flash decline.

Coding this type of layout was, every time, one step forward towards a better and more maintainable CSS structure; however, even if every single length was expressed as a relative and flexible unit, we need to know the number of pages.

For example: if we have an horizontal structure of 6 pages we set the pages’ container width to 600% and every single child page width to 16.66%. But if the number of pages changed to 5 or 7 we have to edit the CSS.

Even if we built the section wider than needed, for example setting the container to 1000% and the single pages to 10%, we can’t be sure that the number of pages never changed to a higher value.

With this problem in mind I’ve searched a solution to compose a full-page grid layout that doesn’t need to know how many pages compose the site; so if I need to add or remove pages at runtime the structure adapts itself to contain the new content.

The result is my new Unlimited Grid Layout Boilerplate; a brand new application of simple basic CSS rules that allow developers to build flexible full-page sites with the flexibility to add or remove pages, or even entire sections, without breaking the layout. The current version, the 1.0a, uses two simple declarations to achieve the task.

white-space: nowrap; on the container of the horizontal structure, and display: inline-block; on the inner pages.

These two declarations prevent child pages to wrap. Now we have an horizontal flow which generates a native scrolling and that can continue to infinite. If we don’t need the scrollbars we can simply remove them with an overflow: hidden; declaration and control the panning with javascript.

Considering that a demo is worth more than 1000 words let’s see two implementations of this boilerplate: but before, let me say just two words (so eventually the words will be 1002) about this proper demo.

The demo runs slow on webkit browsers because of an issue with background-size property; try the demo on Firefox or (strange but true) in Internet Explorer to have the best experience; anyway, the background-size declaration is just for eye candy and the layout complexity may vary in the real world.

In Internet Explorer the control panel in the upper right corner does not work because the lack of support of querySelector API; so if you look at the demo in IE you can see only a 3x3 grid. Sorry about this but it’s a demo and I didn’t want include any external library like jQuery.

The demo uses text-shadow and multiple backgrounds properties only for presentation purpose, so I’ve build the demo on graceful degradation concepts: in IE you can’t see any shadow on text and in IE 8 or less you can’t even see any background image or background colour but you can still explore the functionality of the boilerplate with the base grid; even in IE 7.

The CSS is fully commented so you can take a look directly at the code to discover the tricks. The CSS is separated in tree parts; only the first part, the structure, is really important for our scopes; the second part, the eye candy, is for the beauty side of the demo; and the last one, the demo logic, it’s only to dress the control panel and the credits.

This boilerplate works well in Safari Mobile and Chrome Mobile (tested on iPhone and iPad with iOS6) but in the (current) demo you will not see the numbers in background like in the desktop browsers because the background-attachment: fixed; doesn't works as expected. If you test the boilerplate on other mobile browsers or devices, please, let me know the results.

Ok, now it’s demo time! Let’s see two implementations, one ordering pages in columns and one ordering pages in rows.

Unlimited Grid Layout Demo — Ordered by Columns

Unlimited Grid Layout Demo — Ordered by Rows

Do you like it? I hope you do. Feel free to experiment with the code and use it in production if you feel comfortable with it. If anyone makes a website or a webapp based on this boilerplate, please, let me know; I will appreciate.

Just one thing. The “a” in the version number (1.0a) means that there will be also a “b” version that achieve the same result using not the inline-block display property but the, less supported at now, flexible box layout model. This second demo will not be more complex than that one, but the changes in the flexbox and the lack of a solid support from browsers mades me delay this version.

It is possible to make full CSS fluid squares without images hack or javascript workarounds?

YES! Just think how paddings (and margins) works in the box-model definition.

If the vertical paddings (and margins) are specified in percent (%) values the size is a percent of the width of the containing element.

So if you write:

width: 50%; height: 0; padding-bottom: 50%;

you get a fluid square box with only a three row CSS declaration.