barryvan

Tag: browsers

  • CSS Columns

    In this post, I will walk through the new columns specification that arrived in CSS 3. I will show you the current implementation state of columns in the four major rendering engines: Gecko (Firefox), Webkit (Safari & Chrome), Trident (Internet Explorer), and Presto (Opera).

    Before we get on to platform-specific issues and workarounds, though, we’ll look at the various CSS properties available for working with columns.

    For more in-depth information on columns, you should check out the W3C working draft and Mozilla’s MDC page on columns. The Webkit blog also has an article, but it’s not particularly informative.

    Contents

    I will add more to this entry as I discover more about columns — the goal is to make it an easy-to-understand reference.

    Browser capabilities

    PropertyGeckoWebkitTridentPresto
    column-count-moz-column-count-webkit-column-count✗✗
    column-width-moz-column-width-webkit-column-width✗✗
    columns✗-webkit-columns✗✗
    column-gap-moz-column-gap-webkit-column-gap✗✗
    column-rule-color-moz-column-rule-color-webkit-column-rule-color✗✗
    column-rule-style-moz-column-rule-style-webkit-column-rule-style✗✗
    column-rule-width-moz-column-rule-width-webkit-column-rule-width✗✗
    column-rule-moz-column-rulecolumn-rule✗✗
    column-span✗✗✗✗
    column-fill✗✗✗✗
    break-before✗✗✗✗
    break-inside✗✗✗✗

    Browsers used for testing: Firefox 3.5.4 (Windows), Safari 4.0.2 (Windows), Internet Explorer 8.0.6001, Opera 10.00 (Windows)

    Please let me know if this table is inaccurate, and I will update it.

    Browser bugs

    These are the bugs that I have encountered using CSS columns — if you know of more, please let me know, and I’ll add them to these lists.

    Gecko bugs

    • Specifying an “overflow” (or “overflow-x” or “overflow-y”) property on an element with columns prevents the column rule from being rendered at all.
    • Column rules occasionally don’t render, regardless of the “overflow” property.
    • There is no way to break columns.

    Webkit bugs

    • Pixel creep: Pixels from a later column can creep back to the bottom of the previous column. This can happen with plain text, but it is much more noticeable when you use a non-layout altering effect like text-shadow or box-shadow.
    • Text that overflows the column horizontally is chopped off
    • There is no way to break columns.

    Properties

    column-count

    Value: | auto
    Initial value: auto

    If you don’t set the column-width property, column-count specifies the number of columns into which the content should be flowed.

    If you specify column-width, column-count imposes a limit on the maximum number of columns to be rendered if you supply a numeric value.

    column-width

    Value: | auto
    Initial value: auto

    This property indicates the optimal column width — columns may be rendered narrower or wider by the UA, according to the available space.

    If column-width has the value “auto”, then the width of the columns is determined by other means (for example, column-count).

    columns

    Value: column-width && column-count

    The columns property is a short-hand property, used to set both column-width and column-count simultaneously.

    column-gap

    Value: | normal
    Initial value: normal

    Use column-gap to specify the size of the gutter that lies between columns. Most UAs will render “normal” as 1em.

    column-rule-color

    Value:

    When a column-rule is specified, you may use column-rule-color to set the colour for the line drawn between columns. This property is approximately equivalent to the various border-(?)-color properties.

    column-rule-style

    Value:

    By using column-rule-style, you may determine how the line between columns is to be rendered, if at all. Similar to border-(?)-style.

    column-rule-width

    Value:
    Initial value: medium

    column-rule-width sets the width of the line rendered in the gutter between columns. Basically, it’s the same as the border-(?)-width properties.

    column-rule

    Value: column-rule-width && column-rule-style & & column-rule-color

    Shorthand for setting all three column-rule properties.

    column-span

    Value: 1 | all
    Initial value: 1

    By using column-span, you can allow an element to span either the entire set of columns, or none at all.

    Note that you cannot set an arbitrary number of columns to span — this property essentially ‘interrupts’ the column flow and restarts it below the spanned element.

    column-fill

    Value: auto | balance
    Initial value: balance

    If you have set a height for your columnified element, setting column-fill to ‘auto’ will cause the columns to be ‘filled’ in turn, rather than have the content balanced equally between them.

  • Internet Explorer DOMDocument & XPath

    I discovered a couple of interesting things about Internet Explorer’s MSXML2.DOMDocument object. It turns out that there are essentially two “production-quality” versions of it available: 3.0 and 6.0. Version 6.0 is much the better version, but it’s quite new, and not available on all systems. This means that in IE7 and IE8, instantiating a new MSXML2.DOMDocument object gives you version 3.0.

    Now most of the time, this isn’t a problem. Today, though, I was constructing an XPath expression that used the substring() function; something like this:

    [sourcecode language=’xml’]//Element[substring(Child, 1, 3)=’abc’][/sourcecode]

    This will pull all Elements with a Child element whose value’s first three characters are “abc”. Not particularly complex. It turns out, though, that version 3.0 or the DOMDocument doesn’t actually use XPath as its default language: it uses a bastardised version of XPath called “XSLPatterns”, which just so happens to not support the substring() function at all.

    So how do we deal with this situation? One way is to always instantiate version 6.0 of the DOMDocument:

    [sourcecode language=’javascript’]xd = new ActiveXObject(‘msxml2.DOMDocument.6.0′)[/sourcecode]

    The problem with this approach is that, like I mentioned earlier, you can’t always be guaranteed that your users will have version 6.0 installed (even though it’s a free download). The safer way to deal with this problem is to switch the expression language to XPath in your 3.0 object:

    [sourcecode language=’javascript’]xd = new ActiveXObject(‘msxml2.DOMDocument’);
    xd.setProperty(“SelectionLanguage”, “XPath”);[/sourcecode]

    The advantage of this approach is that you’re not specifying a version, so when MS eventually changes the default to 7.0 (or whatever), your code will work without a problem.

    For more information on this, check out  this blog post from Microsoft’s XML team, which goes into a little bit more detail.

  • Javascript-generated tables and rowspan

    At work, I’ve recently been putting together a nice little calendar-like utility using Javascript. Basically, it has to generate a table consisting of cells which may span multiple rows. Surely the solution is simple enough: just set the rowspan on each td as we create it. Unfortunately, that doesn’t work, at least not in Firefox.

    It appears that in Firefox, if you create a td and set its rowspan to some value when there are no rows for it to expand into, the attribute will be completely ignored, even if you add rows afterwards! Needless to say, this is very annoying. The solution? Build your table backwards.

    The code I have now is something like this (note that I’m developing using the Mootools framework):

    [sourcecode language=’javascript’]var tbl = new Element(‘table’);
    var trs = [];

    for (var i = 0; i < 4; i++) { var tr = new Element('tr'); tr.grab(new Element('td', { 'html': 'Cell ' + i })); if (i % 2 == 0) { tr.grab(new Element('td', { 'rowspan': 2, 'html': 'Span ' + (i / 2) })); } trs.push(tr); }for (var i = trs.length - 1; i >= 0; i–) {
    tbl.grab(trs[i], ‘top’);
    }[/sourcecode]

    What does this code do? Well basically, we’re creating a table with ten rows and two columns; the cells in the right-hand column each occupy two rows. The result will be something like this:

    Cell 1Span 1
    Cell 2
    Cell 3Span 2
    Cell 4

  • Web developer tools

    In this post, I’ll outline some of the web developer tools available in the major browsers: Firefox, Internet Explorer, Opera and Safari. This is a wholly subjective post, based on my experience as one of two developers on a very large AJAX application at Saron Education.

    Firefox

    Firefox has arguably got the best web development tools available, all of which can be downloaded from the Firefox Addons site. The two which I find most useful are the Web Developer Toolbar, by Chris Pederick, and the often-copied Firebug (official website), which itself sports a variety of addons.

    Web Developer Toolbar

    The web developer toolbar is useful for quickly enabling and disabling features of your site, checking CSS, emulating mobile browser rendering, and controlling Firefox more precisely. Personally, I find its most useful features are the ability to:

    • Disable the browser cache entirely, which removes the need for Control-Refresh or cache-clearing;
    • Outline deprecated elements, or any particular set of elements in a variety of fashions, which is very useful for updating old sites;
    • Extract colour information from the current website; and
    • View the cookie information for the current site.

    Download the Web Developer Toolbar

    Firebug

    I sometimes wonder how I ever managed to develop web applications without Firebug. Firebug allows you to alter CSS styles on the fly, edit the HTML contents of the page on the fly, visually watch the DOM being changed by your scripts, debug your scripts, type and run JavaScript straight from the browser, visualise network activity, inspect XMLHttpRequests, and much much more besides. Firebug is, in my experience, the most mature, stable, and efficient of all the tools in this survey.

    The features of Firebug which I find most useful are:

    • The ability to ‘inspect’ the DOM visually (by clicking on elements within the page), then alter their attributes, styles, and even their content dynamically;
    • The ability to watch the effects of DOM alterations by running scripts;
    • The console, with which you can craft and run JavaScript which is run as though it were part of the page itself;
    • The network monitor, which allows you to view all the POSTs and GETs your XMLHttpRequests create.

    Download Firebug

    Internet Explorer

    Until IE 8, the tools available to developers in IE were woeful at best. Fortunately, however, Microsoft has got their act together, and mimicked Firebug for version 8. The features made available in this tool include

    • The ability to interrogate the DOM to view style information about elements (changing attributes and styles hardly ever seems to work in the latest Beta, so viewing them is all you can really achieve);
    • A console, with which you can craft and run Javascript as though it were embedded in the page;
    • Javascript debugging.

    Unfortunately, these tools are still very much in beta, and are very buggy. As I mentioned, altering element attributes and styles hardly has any effect. Also, the CSS inspection system is poorly laid out and often just plain wrong. The console is well-implemented. The entire system is definitely a step in the right direction, but it suffers from bugs and lack of innovation. Also, it seems to slow down and destabilise the entire browser.

    Internet Explorer 8’s developer tools are built in; access them with the F12 key.

    Opera

    Opera’s developer tools, codenamed ‘Dragonfly’, sit between Firebug and IE in terms of functionality and facility. The DOM inspection and manipulation tools work really well (as well as Firebug), and are more immediately configurable, thanks to a variety of toolbar buttons. Dragonfly doesn’t have a console; rather, it uses a ‘command line’ interface. The difference is that where the console in Firebug and IE has seperate areas for input and output (what you type and what it does), the command line mixes these two together, much like a Unix shell or DOS. Personally, I prefer the console paradigm, but it’s much of a muchness.

    Opera’s Dragonfly is built in; access it by going to Tools -> Advanced -> Developer tools.

    Safari

    As with most Apple products, the developer tools in Safari are very pretty. There is a console akin to that in Firebug and IE, and you can inspect and manipulate the DOM. Unfortunately, however, the tools are quite buggy, and often fall down. Whilst the tools are very pretty, they don’t seem to be as stable even as IE 8’s.

    Safari’s web developer tools are built in; access them enabling the develop menu from the Advanced tab of the config, then choosing the appropriate menu item from the Develop menu.

    Conclusions

    Whilst Firebug is still by far the best tool available for web developers, the widespread development of tools by browser developers means that cross-browser debugging and development is becoming ever easier. Hopefully the tools will foster competition, so that feature sets and stability improve in all the tools.