More on @font-face

Since Paul Irish's great effort on a bullet proof syntax, I have seen a lot of excitement about @font-face and the long looked after cross browser web fonts.

It is taking shape and more people are putting extra thoughts in it to make it reliable, usable and ensure all the craze is not going to turn into a wild usage and broken web pages:

• So, Paul Irish kicked the ball with a nice CSS declaration that makes @font-face accepted by all browsers, without unnecessary HTTP requests, no scripting and not event a conditional comment,
• Steve Souders went deep into the performances issues raised by @font-face,
• User Agent Man took the aesthetic and legal point of view, and expressed some concerns about bad practices,
• Font Squirrel provides the fonts and the tools,
• and Robert Accettura found some good hacks, already, @font-face as spam blocker and on using base64 encoded font data in url.
  

Now, we are almost ready for spreading the use of web fonts, keeping these considerations in mind:

@font-face is supported by:

• IE from version 4 (!!!?) using EOT converted files
• Firefox from version 3.5, Safari from version 3, and Opera from version 10 using TTF or OTF files
• Chrome, being Webkit based, supports it but... it's been disabled. It is possible to force Chrome to accept @font-face by feeding it SVG font files. Hopefully it will not be long before they join in the rest.

This "apparently" covers about 80% to 90% of all browsers in use.

Font Squirrel provides ready-made packages including EOT and TTF (or OTF) files. They also run an on-line converter to create you own package, this time including a SVG version of the font. The great advantage with them is that they took care of checking the licenses so you do not have to.

The alternative is to use command line converters:

• ttf2eot at http://code.google.com/p/ttf2eot/ (Windows/Linux)
• ttf2svg using Batik (Java)

Note 1: SVG font files often embed to many characters, ending up being twice as big as a TTF file. You can use the converter options to subset it and reduce the file size. I use the following options with Batik for a reasonable extended western character set:

java -jar batik-1.7\batik-ttf2svg.jar myFont.ttf -l 0 -h 255 -id myFont -o myFont.svg

Note 2: I found the Line Feed character is not present in the converted SVG fonts I used. Chrome, instead, displays the "missing-glyph" entry, which is usually very ugly. To fix that, you can edit the SVG file and add the following entry:

<glyph unicode="&#x0a;" glyph-name="uni000A" horiz-adv-x="560" />

where the horiz-adv-x value is equivalent to the "space" character one.

Note 3: The ID specified in the <font> tag of a SVG font is necessary for the CSS declaration.

Also:

Font files are heavy and many (four separate files if you want to cover regular, bold, italic, bold-italic): optimize them, subset them, cache them, use gzip where possible and limit the number of fonts on you pages (on a design point of view, it is better anyway).

FOUT (Flush Of Unstyled Text) is inevitable for now: it can be improved though, by following the above recommendations.

Not all fonts, even free, can be legally embedded in a website: check the licenses.

Internet Explorer ("Again!" I hear you say) can be a bit reluctant as discovered by Steve Souders (with a bit of my help, I must proudly say): @font-face should come before any <script> tag or IE will hang up, displaying nothing until the font is loaded!

Not all fonts are suitable for main content: a font can be very pretty in 30px but could be difficult or even painful to read when used over 10 paragraphs at 12px. Webkit browsers will usually make a good job at anti-aliasing text, IE and Firefox are a bit more lazy. If the font is of good quality, the result can be pleasing: test and chose carefully. I found Cantarell to be "quite" suitable for content text. If you like it, you can download the package I prepared (all variations, fixed SVG)

You need to define four variations of the same font if you want to use text styling (bold, italic): IE and Opera will generate their own (approximative) interpretation of bold and italic from the regular font. Firefox and Webkit will need properly declared variations so you can use <b> and <i> tags or CSS "font-style" and "font-weight" properties. IE and Opera will also benefit from these variations as they are more accurate than the automatic approximations. Have a look at the code on my test page to see how I declared these variations.

Lastly, this is my own opinion: keep it fresh and simple. Do not over do it, too many fonts can mess up a design and become confusing for a reader. As a rule of thumb, one or two fonts for titles and headers + one clear and readable font for the content should be plenty enough.

Good luck.

Background-color inheritance in IE

I bumped again in this today, but took the time to find some workaround.

Someone did that to the main style sheet of the open source portal I am working with:


td {
background-color: #fff;
}


Since my application sets background-color on rows (tr), all my tables were white.

The workaround should be as easy as:


td {
background-color: inherit;
}


But, Internet Explorer is known for explicitly ignoring the inherit value when it comes to background and background-color.

What it does understand though is the "transparent" value. Transparent, in IE language, means the colour of the closest relatively positioned parent with a defined background-color.

Final workaround is then:


tr {
color: red;
position: relative;
}

td {
position: relative;
background-color: transparent;
}


Still improving

Not a giant leap but a small step for PageLayer: version 1.0.1 has been released to help current users with a few glitches that bugged them. In the process, I have improved the support for latest browser releases (Firefox 3 and IE8).

I am going to spare more time working on the next release as Pagelayer is gaining some attention and I want to make sure it's up to the expectations.

I always feel the same pleasure to update my demo site in a split second from Firefox and I hope I will share this with more people around.

PageLayer Version 1.0

It has been a long time since the last post and PageLayer development has been slowing down as I was busy with more work. Anyway, I found some free time to fix a few glitches and decided to release PageLayer version 1.0. Because it is now stable and in production (limited, but production none the less), I though it was the right time to reach that mark.

It was hard work for one year, and I consider this version 1.0 as an achievement: a sort of celebration. The package is complete and fully working. Distribution from a single point server works wonder and the application is updated seamlessly. Integration with other JavaScript components (i.e. LightBox; Google Analytics) is going smooth and PageLayer appears to be stable and usable on many different browsers and platforms.

From now on, I will continue to improve PageLayer but on a slower basis as I am starting in a full time position again.

One of the direction I might follow is to forget about the floating elements and go for some absolute positioning: users are confused with blocks that behave strangely to them. Floating HTML elements can be tricky and may not be the answer to an easy editing solution.

As many people around, I am having a hard time with the integration of the application's core features and the browsers native editing mode (designmode). The split between the two behaviours can be confusing and PageLayer needs more transparency on that point.

Also, users request more high level features to help during layering and editing: a single button to split a long text in two column of the same size, snaping blocks to help with drag and drop, etc.

Finally, I need to re-consider the distribution process and might give a try at "Application as a Service": PageLayer must be hosted and reachable to everyone with a simple registration process.

So I am not finished with PageLayer (I will probably never be). I am glad I got to that point and still managed to stay sane. Now, as a Front-end Architect I will continue to improve my skills hopefully for the benefit of PageLayer in a near future.

PageLayer in Production

With the version 0.4, PageLayer has now reached the production stage!

It has been running nicely for a few weeks now on a first official website and feedback is really positive. To make the experience a bit more fun, the end users work on Mac: a few fixes had to be made but it now runs smoothly in Firefox 2.0 or Safari 3, in French with UTF-8 and the PHP back-end.

The second production site is to be launched this week. And more to come quickly as it is easier than ever to build websites with PageLayer.

This is the validation long awaited to officially launch the distribution: license program to start very soon now. Version 0.4 is still considered as "Beta" but will be turned into solid 1.0 as soon as usability and features are approved.

Check out the license page at www.pagelayer.com

PageLayer Version 0.4

A new release!

Version 0.4 brings in some of the most needed features to make PageLayer a complete production tool.

The "link creation" icon now launches a nice new window to create pages, empty or from template, link to a document or just type some url.

The "Includes" engine has been completely re-factored too:
- A included file can now be updated: changes are immediately visible on very pages that use the same include (i.e. navigation )
- Or just protect an include to make it un-editable: that's handy for forms.

Lot of things have been added, updated or fixed to make PageLayer even easier and more comfortable to use.

Check it out at www.pagelayer.com

PageLayer 0.3

It's live: PageLayer version 0.3, with plenty of new features and improvements:

• Integrated history: to Undo/Redo any changes
• Improved user experience (Drag & Drop, Resizing, Text Editor, Image Editor)
• Improved readability with new color scheme, new UI skin and icons
  
• New building blocks, more simple yet robust and useful
  
• User interface feedback through color codes in the Tool bar
  
• Improved stability, hundreds of bugs fixed

The demo is online so feel free to give it a try.

I am really proud of this software and the way it improved in the past few months. I surprised myself having great fun using it: as a programmer I tend to prefer messing around in the code to fix my websites but it's so much easier with PageLayer! :)

PageLayer is starting its product life with some real life projects to be launched soon. The feedback from the first users will be invaluable to the future development of PageLayer.
For now PageLayer will be distributed along with web design and development services to ensure a smooth integration. But as soon as it hits the commercial requirements, the licensing program will start and PageLayer will be made available for distribution.

Stay tuned: it's happening soon.

{width: 100%; float: left;} and Crash!

during the stressful process of testing and finalizing version 0.3 of PageLayer I suddenly ran into the Internet Explorer bug of death! During a block "drag and drop", the browser happened to crash violently, randomly and with no more explanation than the terrible "Internet Explorer has encountered a problem and needs to close..." message and an obscure reference to MSHTML.DLL

This is probably the worst thing that can happen to a web developer and I felt rather depressed at this point.

After several hours of desperate googling, testing, code commenting and the usual swearing that comes with that sort of event, I narrowed the problem down to a CSS file. That was one of the most frustrating bug hunts I had to do for quite some time: commenting CSS declarations and testing for several minutes every time, to see if a random bug would appear, while not being sure if it was fixed or just not happening. Grrrgh!

The problem lay in a class that gave a width of 100% and a float left property to my demo site's footer. I found some people talking about this, after I found the problem myself but it does not appear to be a very well known problem. The crash occurred when dragging blocks around in PageLayer, slightly changing the width of the main DIV container. Apparently, IE could not cope with this variation and adjust the width of the floating footer.

It's fixed now but I caught myself remembering the good old time of tables.

Floats Wrapping Priority - Internet Explorer vs Firefox

I ran into this problem while trying to make the PageLayer toolbar to behave properly.

The toolbar is a collection of float left divs containers (toolsets) embedding other float left divs (buttons / links). In a way, it has an onion skin structure: floats inside floats inside ... floats.

The problem is, as you can see in the screenshot, about priority: Firefox makes the outer divs wrap first (what you expect), Internet Explorer makes the inner divs wrap first (what you execrate).

I could not find much help online as it appears not to be a very well known problem (?).

The (very bad) solution I have got so far is to "clear right" the innermost divs which has for effect to make the containers (toolsets) to wrap properly but to lock the cleared divs: they do not wrap anymore in IE.

As anyone worked out a good solution for this problem? I'd like to hear about it!

PageLayer's Inline Image Editor

Here is a short video demonstration of the image crop/resize feature in PageLayer. That sort of manipulation usually requires an extra software as Photoshop to get the image right before integrating to the webpage. In PageLayer all of this is done inline, directly in the web page. Have a look at the video and go have a try with the demo at http://www.pagelayer.com

Note: sorry for the french accent, I am working on that.