Thursday, November 29, 2007

Better late than never

St Bride Library has re-opened. Over the last few months, I have spent a lot of my free time carting heavy trays of metal type, boxes of wood blocks, and manner of miscellaneous oddments around the building. I wasn't the only one, either. Inevitably the heaviest things seemed to need to travel down a lot of stairs. But it is all worthwhile now that the new reading room is decorated, the shelves are in, and the books back on them. Fantastic!

Monday, November 19, 2007

Two years of the Open Rights Group

http://www.openrightsgroup.org/2007/11/19/open-rights-group-our-first-two-years/

A remarkably level-headed crew who are influencing policy for the better. Long may ORG continue!

Saturday, November 17, 2007

Early MacBookPro install disk won’t allow OSX to be installed on a new blank HDD

I was bemused to discover that OSX could not be installed on a brand new hard disk drive I had just installed (because of a message in the installer, ‘Mac OS X cannot boot from this volume’, no matter how I specified the volume I had created with Disk Utility). I’ll spare you the suspense – the action below fixed the problem and it should work for other folk with the same problem, as long as they are prepared to use the command line.

Note that the reason for the failure to install is that the ‘Intel’ macs need to have their boot disks partitioned with a scheme known as GUID. In the version of Disk Utility that’s on my install disk, there is simply no way to specify this, because it is done using the ‘options’ sub-window accessed from the ‘options’ button on the ‘partition’ screen . That button isn’t just greyed out, it’s missing altogether when the HDD is selected in the left-hand list of disks. Which makes it rather difficult to press.

OK, so the cure:

  • Verify that you really do want to start from scratch
  • Boot off the install disk (you’ll be doing this already, or you are reading the wrong post)
  • Choose ‘Terminal’ in the ‘Utilities’ menu
  • Then read ‘Explanation and guidance’ below, and substituting the correct values for your setup, type:
    diskutil partitionDisk /dev/disk0 1 GPTFormat JournaledHFS+ my-hard-disk 111G
    It’s all on a single line and you need to hit return at the end to make things happen.
  • You should see progress information, followed by a neat table giving the new formatting that has been applied
Quit Terminal and you should now be able to proceed with the install.

Explanation and guidance



‘/dev/disk0’ is how the operating system refers to the first whole disk in the system. For a MacBook Pro without external stuff attached, this is correct for a newly-inserted replacement internal HDD.

Then, the ‘1’ here signifies that you want one volume only on the drive.

Then, replace ‘my-hard-disk’ with the volume name you want to use (this is the name of the disk as it appears in the finder – it’s in fact a volume, and you could have many more than one, but that’s beyond this post).

Finally, replace ‘111G’ with the size of the disk in gigabytes. It’s usually about the same as the disk, and as the partitioning software will stretch a single partition to fill the disk it doesn’t matter too much. 111G was the value I used for my 120GB Seagate Momentus HDD, because I already knew that it wasn’t really 120GB (again, the reason for that is beyond this post).

Good luck!

Thursday, November 15, 2007

Tables in forms: an [X]HTML conundrum

Question: what does this mean?


<!ELEMENT table
(caption?, (col*|colgroup*), thead?, tfoot?, (tbody+|tr+))>
<!ELEMENT caption %Inline;>
<!ELEMENT thead (tr)+>
<!ELEMENT tfoot (tr)+>
<!ELEMENT tbody (tr)+>
<!ELEMENT colgroup (col)*>
<!ELEMENT col EMPTY>
<!ELEMENT tr (th|td)+>
<!ELEMENT th %Flow;>
<!ELEMENT td %Flow;>

<!ELEMENT form %form.content;>

<!ENTITY % form.content "(%block; | %misc;)*">

<!ENTITY % block
"p | %heading; | div | %lists; | %blocktext; | fieldset | table">

<!ELEMENT fieldset (#PCDATA | legend | %block; | form | %inline; | %misc;)*>


Answer: it's a selection of parts of the XHTML 1.0 DTD[0] and it requires that:
  • table elements can only contain other table elements until you reach td and th elements (which are largely interchangeable in DTD terms);
  • fieldsets can only contain block elements like headings, paragraphs and entire tables.

In addition, accessibility concerns[1] require that:
  • fieldsets are used to group form inputs together[2], to create a human-comprehensible and navigable structure (this is analagous to the typographical and gestalt formatting tat we would use in a well-designed printed form). W3C advise HTML authors to 'Divide large blocks of information into more manageable groups';
  • the XHTML generated conforms to the DTD (is valid for the flavour of HTML used). Otherwise the page won't display predictably, so that's good.

The corollary of these requirements is that tables cannot be used to lay out a table form, unless each fieldset is contained within a single cell (td|th). Trouble is, the whole point of the table is usually to use the cells to discriminate between items; one of the chief discriminations would be between a 'container' like a category or a question and the elements that are contained, like the set of answers (usually represented by a set of checkboxes or radios, though there could be a mix including drop-downs, text boxes or whatever.

I think this is a real weakness in the XHTML DTD. It does not appear to be changing in XHTML2 or HTML5[3,4], and that's reasonable given that these are evolutionary updates and the problem here looks like it is part of the 'layout tables are bad' mantra (there's currently a note on http://www.w3.org/html/wg/html5/ that says 'we need some editorial text on how layout tables are bad practice and non-conforming' - and that's good). In fact, the problem is a different one: designers need to be able to rationise layout of complex data in various ways; tables can be legitimately used to do this; and sometimes that rationalisation is in the context of asking questions with a form. Because a form has its own, complex element structure, there's a problem when the form and the table are interleaved. Currently that problem is solved by restricting the degree to which the table and the form can be interleaved (wrap the form around the table and then place fieldsets inside td or th elements). I believe what's required is to allow fieldsets to wrap around tbody or tr elements.

One final point: it appears from the definition of fieldset in [0] that you can put a form inside it. Interesting, given that a form cannot contain another form (that's the intention of two comments: '<!-- forms shouldn't be nested -->' and '<!-- form uses %Block; excluding form -->', both in [0]). So should a fieldset go outside a form, and in this case what's the use? Explanations welcomed.

References


0. http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict
1. http://www.w3.org/TR/WCAG10-HTML-TECHS/
2. http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-grouping
3. http://www.w3.org/html/wg/html5/#forms
4. http://www.w3.org/html/wg/html5/#tabular

Edits: 2008-07-08: corrected table to form

Thursday, November 01, 2007

Look out, Tower 42

Site of the day skyscrapernews.com has details of a new building development that may well be blocking out the sun in my back yard.
http://www.skyscrapernews.com/news.php?ref=1179 | Tower 42, yesterday