There has been a fair bit of discussion on the WHATWG HTML 5 list around whether or not browsers should ‘sniff’ for video types instead of relying on the HTTP Content-Type header. There are some reasonable arguments on both sides, sniffing is unreliable and can introduce security problems, but a lot of servers default to incorrect Content-Type headers and it’s too hard to configure them.

Having watched that debate go on for a week or more, I found it quite interesting and timely to see a support case come in specifically complaining that we’d gotten one of our Content-Type headers wrong. It turns out that we’d been serving up a JavaScript file as text/html but since it was included via a script tag, browsers always treated it as text/javascript anyway and everything worked. The catch is, Tivoli Access Manager was then set up between the client and the server of this JavaScript and it actively filters all HTML pages. Naturally, filtering JavaScript as if it was HTML tends to break stuff.

One of the most difficult situations to work with is when your output needs to be rendered using Flash. The HTML support in Flash is absolutely horrendous – worse even than in most email clients. Contrary to popular belief, Flash does support P tags. You will however need to ensure the text field is set to multiline. The BR tag is also only supported in multiline fields. The problem most people hit is that Flash doesn’t support the margin-top and margin-bottom attributes so you can’t get rid of the blank line between paragraphs.

One of the common reasons people want to avoid P tags in content is because the field is designed to hold just a single paragraph, so having multiple P tags inside the content would break the template layout when it’s rendered. Usually the template renders the content as something like:

<p><%= fieldContent %></p>

In that case, where the output is the only thing within the paragraph, the best solution is to leave the paragraph tags in editor content and remove them from the rendering template. That gives the editor the context it needs to work well and avoids a lot of potential problems with rendering the content. If however, you’re including some extra content in the same paragraph then the situation is more difficult, e.g. your rendering template is more like:

One thing that many people don’t realise, is that the distinction between paragraphs and line breaks isn’t unique to HTML. In fact, it’s a distinction that people have been working with quite happily for a very long time – Microsoft Word has supported the two concepts right from it’s very first version. With the more recent versions of Word, the default paragraph spacing is zero, so line breaks and paragraphs look the same, even though there is an important semantic difference. You can still see the difference if you show the non-printing characters:

A few days ago I talked about the Email and P Myth, but didn’t explain why it’s so frustrating for editor developers that people keep wanting to use BR tags instead of P tags. It’s not actually because we’re fastidious about using the correct semantic HTML, though obviously we do recommend that, it’s because a lot of concepts that user’s expect simply aren’t possible to implement sensibly if you don’t use the correct paragraph level elements.

Back when git and GitHub were relatively new to the mainstream, there was a big discussion about how it promoted forking and was potentially bad for community building. Since then GitHub has well and truly proven that it can successfully support significant community and very successful projects. Looking around GitHub though, it’s clear that not every project successfully builds community there and the tendency to fork can still become a problem.

One of the greatest frustrations for anyone who develops an HTML editor is the constant supply of people who are convinced they want to use BR tags instead of P tags. Most of these are just people who don’t want “double spacing” and they’re happy once you give them the magical CSS incantation:

p {
  margin-top: 0;
  margin-bottom: 0;
}

The other group however are people writing HTML emails who insist that P tags are completely incompatible with some email clients and cause rendering problems. At one point it seems that Yahoo! Mail really did strip them entirely but now it just applies a different default CSS styling (ironically, the magical CSS above that removes the extra spacing). So if you naively use P without specifying the padding you want, some clients will display a blank line between paragraphs, others, notably Yahoo!, will push all the lines immediately under each other. The solution is of course the opposite magical CSS incantation:

I had written up a long, comprehensive and timely set of thoughts about what went wrong with Google Wave, but WordPress ate it so you’ll have to take my word that it was awesome and instead put up with this rather late and significantly shorter thought.

There are lots of opinions around about why Wave failed, and they show that it was a combination of a lot of factors from poor UI, inexplicable purpose, unreliability and simply combining too many technologies that didn’t always fit (e.g. people don’t always want what they type to be shared immediately but real time collaboration was forced on them). Certainly I experienced most of those downsides, but the thing that really drove me crazy about Wave was it’s primitive support for notifications.

It would be hard to have not noticed the on-going debate around “open core”. From what I can tell, it largely, but not completely, boils down to concerns about a product being called “open source” if the core that’s open source is generally unusable without the commercial-only additions. Mostly, people are ok with there being separate commercial-only plugins or tools provided so long as the open source product can stand alone and be useful and effective. Dave Neary hits on what I think is a key warning sign that a product is using a damaging open-core model:

Despite all the hype about how everyone’s making advertising more targeted and therefore more useful to people, you still get gaffs like this one:

The advertising industry is booming and ads are popping up in more and more places, but the quality of ads are still really bad. It’s no wonder ad blocking technology has become so popular.

It’s not often I say things like this, but oddly today’s problems are Firefox exclusive. It turns out that prior to Firefox 3.5 Range.extractContents is subtly but, for my uses, devastatingly broken. Basically, on any browser except those earlier versions of FireFox the test below should pass:

test('range.extractContents', 2, function() {
  var item1, item2, list, r, fragment, test;
  test = document.createElement('div'); 
  test.id = 'test';
  test.innerHTML = '<ul><li id="item1">Item 1</li><li id="item2">Item 2</li></ul>';
  document.body.appendChild(test);

  item1 = document.getElementById('item1');
  item2 = document.getElementById('item2');
  list = item1.parentNode;

  r = document.createRange();
  r.setStart(list, 0);
  r.setEnd(list, 1);
  fragment = r.extractContents();
  list.appendChild(fragment);

  ok(item1 === document.getElementById('item1'), 'Item 1 must not be cloned');
  ok(item2 === document.getElementById('item2'), 'Item 2 must not be cloned');
}

Basically, extractContents should remove the nodes within the range from the document and give them to you in a DocumentFragment (so you can put them somewhere else usually). The key requirement is that they be the same nodes unless only a part of the node is within the range, at which point the node should be shallow cloned and split.

Note to self: if you ever want to get a simple list of people who have committed to a git repository, the command you want is:

git log --format='%aN <%ae>' | sort -u | uniq

Or for just the e-mail address:

git log --format='%ae' | sort -u | uniq

Or for just the name:

git log --format='%aN' | sort -u | uniq

This is in the help manual but it’s way down the bottom so takes ages to read through to find it.