The WaSP Buzz writes that once the Opera web browser passes the Acid2 test on the desktop, the mobile version will pass it too.

OK, that makes sense. AFAIK they have one rendering engine that they use across platforms. If the Windows, Linux and Mac versions display sites identically (aside from fonts and form controls), there’s no reason to assume that the version for cell phones and PDAs will be any different. What’s interesting here is the link to a forum thread on Opera’s Acid2 progress.

I recently stumbled across an old copy of the Demoroniser (which my American-trained sense of spelling keeps trying to spell as demoronizer), a script designed to correct some of the, well, moronic HTML generated by Microsoft Office. Aside from flat-out coding errors, Office would use non-standard characters for things such as curly quotes or em-dashes that would only show up on Windows computers. If you viewed these sites on a Mac, a Linux box, a Palm, etc., they would seem to be missing punctuation everywhere. His solution was to convert these to their plain-ASCII equivalents.

Over the last year or so, WordPress and A List Apart have converted me from “stick with the lowest common denominator” to “let’s show real typography.” Since the days of the Demoroniser, Unicode has become a standard part of HTML, so modern browsers* can either display a full range of characters or convert them to something they can display. You probably won’t be able to see Chinese text in Lynx, but a properly encoded curly quote—“ or ”—will show up as a plain old ".

For one thing, real typography looks much nicer. Continue reading

While trying out the latest Opera 7.60 preview, I ran into a couple of of weird CSS bugs. It turns out they’ve both been around a while—one since 7.5 and one since 7.2. And they’re both related to problems with li:first-line.

In CSS, :first-line lets you apply style to (not surprisingly) the first line of an element. So if you say something like li:first-line {color: red} you should see the first line of every list element turn red. It’s got fairly wide support at this point—even IE 5.5 can handle it—but it seems some bugs crept into Opera 7.

The first one I noticed was fairly simple: If you have something in the form:

<ul>
  <li><a href="somewhere">Link</a></li>
</ul>
<p>More text<p>

…and you apply style to li:first-line, then the underlining for the link continues to the end of the page. Here’s an example of case 1.

Then there’s the really weird one. Continue reading

Via Weblog about Markup & Style:

Dive Into Mark provides an excellent example of why a browser shouldn’t second-guess file types.

Safari content sniffing for XHTML

It’s a screenshot of Safari looking at a text document… but the first line mentions XHTML, so it’s decided that’s what it must be. I’ve had lots of trouble with Internet Explorer doing the same thing, and Safari’s been aiming at bug-for-bug compatibility in order to “break” as few sites as possible.

[Edit: After the source blog was taken down, I grabbed the screenshot from archive.org and uploaded it here.)