Say the HTML is this

<div id="mydiv" style="border:10px solid #ff0000;">Hello World</div>

then you get the width of the border with this:

var borderWidth =($("#mydiv").outerWidth() - $("#mydiv").width()) / 2;

When you focus a link or some other focusable HTML element, you’ll get some more or less ugly outline which might not quite be what you want. In Firefox it’s for example a dotted border:

To remove this outline e.g. for all links, simply add this CSS:

a {
  border: 0;
  outline: 0;
}

This won’t work for any element in Internet Explorer. You might have to add some none standard attribute:

<a href="#" hidefocus="true">some link</a>

This week Apple show’s off Safari’s HTML5 capabilities … check it out, it’s impressive: Apple HTML5

There is also a page for Google Chrome demonstrating some pretty neat HTML5: Chrome Experiments

Last week a friend of mine was claiming that you can’t easily capture keyboard events on non-input HTML elements such as div or span. The fact is: it is easy.

See this demo:

You can use the arrow down / up keys to move the selection down or up. Find a working demo here.

The HTML:

<ul id="list">
	<li class="list-item" tabindex="0">test 1</li>
	<li class="list-item" tabindex="1">test 2</li>
	<li class="list-item" tabindex="2">test 3</li>
	<li class="list-item" tabindex="3">test 4</li>
	<li class="list-item" tabindex="4">test 5</li>
	<li class="list-item" tabindex="5">test 6</li>
	<li class="list-item" tabindex="6">test 7</li>
</ul>

Really the only trick here is to add a tabindex attribute to each list element. This way it can receive the focus and starts to capture keyboard events.

The JavaScript:

$(".list-item").bind({
	keydown: function(e) {
		var key = e.keyCode;
		var target = $(e.currentTarget);
 
		switch(key) {
			case 38: // arrow up
				target.prev().focus();
				break;
			case 40: // arrow down
				target.next().focus();
				break;
		}
	},
 
	focusin: function(e) {
		$(e.currentTarget).addClass("selected");
	},
 
	focusout: function(e) {
		$(e.currentTarget).removeClass("selected");
	}
});
$("li").first().focus();

The keydown event figures out which key was pressed. If it was the arrow up key it selects the previous element and sets the focus on it. For the arrow down key the following element gets the focus. The focusin and focusout events add or remove a css class in order to make the selection more visible.

You can find the complete code of the example here: http://gist.github.com/410789 or by clicking view source in the demo.

One of the better HTML5 browser tests that I’ve seen you’ll find at

http://html5test.com/

Firefox 3.5.9 on Window XP:

Google Chrome 4.1.249.1045, Windows:

I recently noted that some elements on my page randomly weren’t rendered like I expected even though other elements of the same CSS class were rendered correctly. Looking at the code I noticed that Firefox was adding weird tags to link tags:

<h1>
    <a _moz-rs-heading="" href="/lists/1?locale=en">Gute Weine</a>
</h1>

But not only that. The whole HTML structure was messed up.

The green area highlights a correctly rendered element like it was coded in the plain file. The red area highlights what happened randomly in Firefox.

After a bit of googling it turned out that this false rendering was caused by a mistake from my side: You should not wrap block elements like div and h1 with a link tag. So the HTML really should look more like this:

<li class="list" id="list_19">
    <div class="list_content">
        <h1><a href="/lists/19?locale=en">Einkaufsliste</a></h1>
        <div class="summary">
          <a href="/lists/19?locale=en">
              4 items in total, 3 items done.
              <br>
              Last updated 3 days ago
          </a>
        </div>
    </div>
</li>

In this code a-tags wrap only text elements. img-tag would be fine, too. Other elements you should avoid in order to prevent rendering you don’t expect.

It looks like amongst a lot of other cool stuff HTML5 will bring us also block-level links.

One of the exciting new features of HTML5 is the Canvas element. Today evening I checked out two libraries implementing the Canvas element for the Google Web Toolkit.

• GWT-Canvas by Oliver Zoran
• GWTCanvas as part of the GWT Incubator

I can’t really tell which library is better. Both seem to handle the Canvas API well. The biggest disadvantage at the moment is that you can’t run your code in hosted mode. The Incubator version promises that hosted mode works on Mac systems though. Users of other operating system will probably have to wait for OOPHM (Out Of Process Hosted Mode) which will be released along with GWT 2.0.
In my opinion one argument speaking for using the Incubator version is that this version is maintained directly by Google and that you get a lot more cool features by including the Incubator JAR.

Die New York Times bietet einen neuen Archiv-Service namens Times Machine an.
Nicht nur das Archiv an sich ist interessant, sondern auch die Tatsache wie es umgesetzt ist.

Häufig wird für ein solches Interface Flash eingesetzt. Die NY Times jedoch hat sich die Mühe gemacht, das User Interface mit HTML, CSS und JavaScript umzusetzen. Das Ergebnis lässt sich sehen und hebt sich von den üblichen Flash-Lösungen ab.

Nachdem man Jahr, Monat und Tag ausgewählt hat, wird die erste Seite der Ausgabe angezeigt. Fährt man mit der Maus über die Artikel werden diese hervorgehoben und es erscheint ein Popup mit einer kurzen Zusammenfassung des Artikels und der Möglichkeit das zugehörige PDF zu öffnen.

Einziger Nachteil des Services ist, dass nur einige historische Beispielartikel und die Online-Artikel verfügbar sind. Alle anderen Ausgaben stehen nur Abonnenten zu Verfügung oder über amerikanische Bibliotheken:

TimesMachine is currently available only to home delivery subscribers of The New York Times. If you are not a home delivery subscriber and would like free access to The New York Times page image archive, ask your local librarian for access to Proquest’s Digital Vault.

Schade…

HTML 5 wird benutzerdefinierte Attribute für alle HTML-Tags unterstützen. Das ist praktisch und wird den Code gerade im Zusammenhang mit JavaScript wesentlich sauberer machen. Dazu: HTML5 custom data: A possible savior for the poor, overloaded class attribute?

Line 490, Column 8: ID "links" already defined

Diese Fehlermeldung erscheint bei der Validierung der Hauptseite einer WordPress 2.3 Installation mit aktivierter Widgets Sidebar und aktiviertem Links-Widget.

Der W3C Markup Validator beschwert sich über ein doppeltes Vorkommen der ID “links”.

Möchte man nicht auf das Widget verzichten, lässt sich der Fehler nur durch Editieren der datei wp-includes/widget.php in der Zeile 402 beheben:

function wp_widget_links($args) {
  extract($args, EXTR_SKIP);
  wp_list_bookmarks(array(
    'title_before' => $before_title, 'title_after' => $after_title,
    //'category_before' => $before_widget, 'category_after' => $after_widget,
    'show_images' => true, 'class' => 'linkcat widget'
  ));
}

Einfach die “category_before”-Zeile auskommentieren. Das bewirkt, dass die ursprünglich von der Funktion wp_list_bookmarks vergebene ID und CSS-Klasse verwendet wird.

Ich habe den entspr. Troubleshooting-Eintrag auf WordPress.org erweitert.

In diesem Sinne: “This Page Is Valid XHTML 1.0 Transitional!” ;-p