css posts page 3

IE 10 and CSS Grid Layout

in

IE 10 has recently graduated from beta and is now the current official release. It started out Windows 8 only, but now is available on 7 as well as a preview release. Hopefully that will allow it to grab more IE users quickly. IE, which has long been the bane of web developers, has been getting better and better with each release. IE 6 has always been a pain to develop for, having many bugs/quirks in rendering pages. In all but fairly simple sites, it always took me a fair amount of time to fix after getting things looking right in other browsers. Luckily, the market share is low enough that at work we don’t even worry about it anymore. IE 7 was better. Using a subset of HTML4/CSS2 level development, I usually have had to do only minor tweaks unless the sites were fairly complex. Luckily, It’s share is almost to the cutoff point where we stop developing for it as well. With IE 8, I’ve been able to do most HTML4/CSS2 level stuff without worries. display: inline-block;, :before, :after, onhashchange, etc. It still remains a limiter in using some selectors and in making use of HTML5/CSS3 level techniques, though using an HTML5 shiv and CSS3 PIE or allowing for progressive enhancement to skip over some features in it works rather well. IE 9 has brought some HTML5/CSS3 stuff to the table, like selectors, HTML5 semantic elements, SVG, though it’s missing some important ones, like CSS3 columns and HTML5 form stuff. Since I develop to support IE 8 usually without browser specific tweaks, IE 9 basically works automatically, and has some style enhancements over 8.

And now there’s IE 10. IE 10 has added a lot more and is finally coming close to other browsers in implementing the not-yet-fully-standardized standards. It’s still missing some good ones, but the list of things that have to be skipped, worked around, etc, for IE’s current version has shrunk a good bit. It even implements some features that others haven’t yet.

The big one is the CSS3 grid layout module, which is the one I’m most excited about for the future. This module is pretty close to allowing for a real decoupling of markup from style that CSS has promised finally for page layout.

Continue reading post "IE 10 and CSS Grid Layout"

HTML5: The Progress Element

in


I decided to attempt to use another new HTML 5 element on a site, the <progress> element. This element is used to show the completed progress of a task, perfect for the tasks in a project management application we are making at Cogneato. I wanted it to have the same appearance for all modern browsers, a visual bar indicating percentage complete of a fixed width total bar. As always, this required some special handling for different browsers. Because of the complications, I needed to output different markup for different browsers, so I made a PHP function using server side browser sniffing to give me the proper output. The convoluted function looks like this:

<?php
$glbProgressWidthModifier=0.8;
function generateProgress($value){
    global $glbProgressWidthModifier, $ischrome, $issaf, $isie, $isie9;
    $value = $value * 100;
    ob_start();
?>
<?php if(!$ischrome){ ?><div class="progresswrap">progress  value="" max="100" class="elmprogress" style="width:px;"><span>%</span>></div><?php } ?>    
<?php
    $fncReturn = ob_get_contents();
    ob_end_clean();
    return $fncReturn;
}

with a global width modifier to set the width of the total bar, where 1 means 100px, and various is… variables set elsewhere based on the sniffed browser. It will return the HTML output given a numeric value between 0 and 1 representing percentage complete, like echo generateProgress(0.85).

Continue reading post "HTML5: The Progress Element"

CSS3: Text Rotation Rendering Problems

in

As mentioned in another post on css rotation, I had some issues with rotating text. On the Amy’s Shoes site, now live [no longer our design], I use transform:rotate(); for CSS3 capable browsers and the matrix filter for IE to rotate various elements.

In IE, I had noticed that the text was somewhat blurry when rotated, especially for smaller font-sizes. I hadn’t noticed, though, that the rotated text also rendered poorly in Firefox for Windows and Safari for Windows. They render the text with messed up kerning and letter positioning, so that it can become illegible on smaller text and even have overlapping letters. Not in Opera in Chrome, just those browsers. I test Firefox and Safari on Mac only, since rendering of most things is exactly the same. Evidently not the case with rotated font rendering though, and I will have to keep this in mind and test the new CSS3 features more thoroughly.

Because of this issue, I made my first ever style sheet targeting an entire operating system (Windows), since the rotation was not working on so many Windows browsers. The stylesheet simply removes the rotation on the main body text and repositions things slightly so that the layout still works. We were considering doing image replacement for the menu and button text on Windows as well, but haven’t gone that far yet, as the larger text doesn’t look nearly as bad. The rendering is also slightly messed up on Firefox for Mac, but not too bad to use.

We’re not sure why the rendering is so bad on those Windows browsers. For IE, it is likely the way it handles the matrix filter. For Safari and Firefox, it may have something to do with the way Windows deals with fonts compared to how Mac does. Maybe Chrome and Opera somehow bypass the rendering issue. I don’t know what’s up, but this and the other issues mentioned in the previous article suggest that, unfortunately, rotation of text is still not to the point where it can be indiscriminately used, and is best used in a way where the unrotated version still works fine, because that will need to be done for some browsers.

CSS: IE Shadows and Rounded Corners With HTC

in

[Update Synopsis] I’ve improved color support, now working for hex, rgb, and rgba at the beginning or end, re-added Nick’s text-shadow support while giving it the same color support as box-shadow, and added an -ms- prefix to target IE for these properties with. I’ve made a simple example page and you can find the file for download in this Google Groups thread. [/Update]

At Cogneato we use a lot of drop-shadows on elements in our designs, and a number of sites use rounded corners as well. In the past, images had to be used for shadows and rounded corners, using a variety of techniques and often adding to page weight and requiring new images be made for site changes. But CSS 2 and 3 introduced properties text-shadow, box-shadow, and border-radius to handle these display niceties without images. These have slowly gained support among browsers, and now, with vendor specific versions, are supported by the most used non-IE browsers. But IE still offers no support for them up to version 8.

HTC’s (basically javascript that can be attached to CSS selectors in IE) have been used to handle a number of IE issues, and Remiz Rahnas created one to support these CSS properties. It has been updated by Nick Fetchak and moved to Google Code. It allows you to add behavior: url('ie-css3.htc'); to any elements with those properties and the properties are automatically applied in IE. It works rather well, though it does still have some issues. For instance, on sites with fading and other animations like the one I started using this on at Cogneato, the shadows don’t fade or move with the rest of the content.

Another issue I had with the script is its handling of the color attributes of the box-shadow property. If you place the color attribute before the unit declarations like I do (ie box-shadow: #123456 5px 5px 5px;), the htc doesn’t work at all. This was easy to change in the htc to get working. It uses regex, so I just removed the ^ character, which denotes the beginning of a string, so the regex could be matched anywhere in the property.

It also happens that the htc doesn’t support color for shadows.

Continue reading post "CSS: IE Shadows and Rounded Corners With HTC"

The Case for DOM Element Insertion With CSS

in

CSS provides the “content” property for inserting content into documents, usually before or after elements. This can be bad if the content inserted is not strictly for presentational purposes, but when it is, it can be a very useful tool for changing a sites appearance with only CSS.

The property can be used to insert strings, images, even counters. Unfortunately, DOM elements cannot be inserted. Why would you want to insert DOM elements? Doesn’t that go against the separation of content and presentation even further than the “content” property already allowed?

Ideally, in marking up a document, one should not need to consider presentation at all, only the proper elements to stick a given block of content into. The CSS would be created separately and form those elements into any appearance desired. There are a lot of reasons this can’t currently be done, including sort order and hierarchy. Another is the limit of what is available to be styled in the HTML document.

Continue reading post "The Case for DOM Element Insertion With CSS"