Determining a table cell’s x and y position/index

When working with HTML tables, we often want to extract the column and row index for a particular cell. Easy enough, surely — just use row.rowIndex and cell.colIndex, right? Well, no.

The spanner in the works

…is the presence of cells that span rows or columns (apologies for the terrible pun). For example, in the following table:

a b c d
e f g
h i j
k l m n

the column index of cell “g” is reported by the browser to be 2 — when in fact it should be 4!

The solution

Fortunately, there is a solution. The code below is based on this very old example by Matt Kruse. I updated it, tidied it up, and MooTools-ified it.

Usage

Simply call “getCellCoords” on the (header) cell you’re interested in. This will return an object containing “x” and “y” members — the column and row index, respectively.

The code

(Un)quoted HTML attributes

In HTML, it’s perfectly valid to write something like this:

<p class=alpha>Lorem ipsum dolor sit amet etc.</p>

Indeed, Internet Explorer 7 and 8 favour this approach. Whereas Firefox, for example, would return the above as

<p class="alpha">Lorem ipsum dolor sit amet etc.</p>

when retrieving it using innerHTML, IE 7 & 8 only quotes attributes that satisfy certain criteria:

  • Any attributes that contain spaces;
  • Some magic set of standard attributes, such as href;
  • Any custom attributes you may have specified.

Unfortunately, however, this doesn’t constitute well-formed XML. In the software I develop at work, we produce PDFs that can include user-generated HTML. To do this, we use XSL:FO — an XML-based system. You can see where this is going: the backend requires valid XML, but the frontend is sending through HTML. The simplest way to fix this is with a simple regex, like so:

var s = '<p class=alpha>Lorem ipsum dolor sit amet etc.</p>';
s = s.replace(/=([^"'`>\s]+)/g, '="$1"');
// s === '<p class="alpha">Lorem ipsum dolor sit amet etc.</p>'

Bear in mind that this regex is by no means perfect. It will, for example, convert this:

<p class=alpha>Lorem ipsum</p>
<p>dolor sit=amet</p>

into this:

<p class="alpha">Lorem ipsum</p>
<p>dolor sit="amet</p">.

…which is obviously not what we want. I spent a while trying to come up with a regex that would solve this problem, but I stopped pretty soon. What’s really needed here is a parser: something that can take in the tag soup that Internet Explorer produces, and produce valid XHTML (which is valid XML). A quick search reveals myriad implementations in various languages — Python, Java, even JavaScript.

So, after all that, what’s the take-away from this post? Just this: web browsers (slightly older versions of Internet Explorer in particular) are imperfect. XML was borne out of HTML, and is much less forgiving; whether or not its strictness is a good thing is up for debate. I guess that it’s a bit like reading Shakespeare nowadays: you can pretty much understand it, but every now and then you have to reach for a dictionary to make sense of what’s going on. Of course, when you don’t understand something in Shakespeare, you don’t fall over in a heap, but let’s not stretch the analogy too far.

In brief

When retrieving the innerHTML of an element (or using contenteditable), Internet Explorer doesn’t always wrap attribute values in quotes. The solution to this is not a magnificently obtuse regex, but a tag-soup parser that can return valid XML.

Theme update (again!)

And so, for the third time this year, I’ve completely re-themed this site. Taking a very different tack from the last theme, I’ve tried to keep this one as simple as possible, with just a few subtle touches here and there to add interest. The palette is more subdued, which hopefully means that reading the text is a more pleasant experience. I’ve also done away with the multi-column body text in favour of a fixed-width design.

At the same time, though, I have endeavoured to use some of the new features available in modern web browsers — gradients, shadows, transitions, generated content, and so on. I’m fairly happy with the result — I think it’s a clean, unobtrusive theme that’s not too in your face. Feedback and criticism welcome! 😀

Generative Music

Continuing my HTML5 and canvas experiments, I’ve put together a generative music system. Essentially, a series of particles move across a field, occasionally triggering sounds — the sound triggered depends on their location in the field.

There is, of course, a little bit more to it than that. Under the hood, I’ve got a series of HTML5 Audio objects that are used to provide polyphonic audio using a simple round-robin algorithm (I encoded the audio in OGG, so you’ll need to use an OGG-friendly browser, like Firefox). The particles are much simpler than those in my previous canvas dalliance, in that they don’t swarm, and their motion is more linear.

Canvas Swarms

I’ve been meaning to start playing with the HTML5 <canvas> element for a while now, and yesterday I took the opportunity. I translated a Processing sketch I made a while ago into JavaScript (with a few minor enhancements).

Essentially, 1 to 3 swarms of particles move around the canvas, reproducing when the conditions are just right, and dying of old age. Quite simple, but the patterns produced can be really quite pretty.

One interesting thing that I discovered whilst doing this is that you can’t pass around a canvas’ context at the instantiation of a MooTools class — it complains about wrapped natives. That’s why, if you like in the source JavaScript, you’ll see me pass the actual context around to various functions. I’d be interested in hearing if anyone has a workaround for this, because this is, well, a bit clunky.

HTML: IE file submission

I’ve been bumping up against an interesting bug in Internet Explorer recently, and, having just found the solution, thought I’d share it with you.

The problem is that in Internet Explorer (tested 7 & 8), when your document is in quirks mode, uploading a file sometimes just sends through the file name, without the actual body of the request. Put the document into standards mode, and it all works. It should be noted that this is when you’re dynamically setting up the elements used with JavaScript.

The cause? In quirks mode, the enctype attribute isn’t supported. So whilst setting “encType” on the form element to the correct “multipart/form-data” will indeed set this attribute, it won’t actually cause the upload to include the file. Instead, you need to set the encoding attribute to this value, too. It certainly doesn’t help that the MSDN article on the <input type=”file”> element tells you to set “enctype”, but makes no mention of “encoding”.

I couldn’t find any reference to this problem on the intertubes (although maybe I just didn’t look hard enough), so hopefully this will help someone.

Input elements that fill their container

Previously, this post advocated the use of “text-indent” on a padding-less, border-less, 100% width input. This works, but it’s quite clunky, and old versions of IE don’t support text-indent, so it just looks bad. A much better solution is to

Just use box-sizing.

As pointed out in the comments, the simplest solution is to simply change the box-sizing model of the input element to “border-box”, rather than the default “content-box”. In the example below, I’ve given the containing div a 4px whiteborder.

<div style="background:#000; width:200px; border: solid 4px #fff;"><input  style="-moz-box-sizing: border-box; box-sizing: border-box; display: block; padding: 4px; width: 100%; height: 100%; background: #fff; opacity: 0.5; border: solid 1px #666;" type="text" value="text input"/></div>

Note that for Firefox, you still need to use the -moz- prefix; it’s supported unprefixed in all the other major browsers, though.

Updated 2012-08-03.

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

Property Gecko Webkit Trident Presto
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-rule column-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:

//Element[substring(Child, 1, 3)='abc']

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:

xd = new ActiveXObject('msxml2.DOMDocument.6.0')

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:

xd = new ActiveXObject('msxml2.DOMDocument');
xd.setProperty("SelectionLanguage", "XPath");

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):

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');
}

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 1 Span 1
Cell 2
Cell 3 Span 2
Cell 4

New theme!

I’ve finally got around to replacing the placeholder theme I had on the site. The new theme that I’ve made is much cleaner, simpler, and fresher.

This new theme is built around the Sandbox WordPress theme. Sandbox provides you with a really well marked-up document, with appropriate classes, ids, and so on where you need them — essentially, it lets you build the entire theme in CSS without having to worry about the markup, and in so doing, encourages you to build a CSS-only design. I’m proud to say that this design is wholly CSS — there is no extraneous markup, and there are also no browser-specific hacks or files: everything is contained in a single CSS file and about five images, for a total size of around 40kB.

I should also note once again that Firebug is, perhaps, the best tool for web development, be it design or coding — about 90% of the styling was tested in the browser using Firebug before being applied in the CSS file itself.

Comments, questions, or criticisms of the new design? Just leave them in the comments.