Friday, 23. May 2008, 10:31:39
device, www, Opera Mini
Opera has
published some stats on phone use with Opera Mini the first quarter this year (based on the URL this seems to be a front page rather than a quarter report 2008/I, so if you read this post later the content may no longer match). To what extent this can be generalised to phone browsing in general is less clear.
The first graph, cumulative users per month, isn't very interesting unless you're into marketing or wonder how well Opera Mini fares, even then it is less useful than the two other graphs for page views and data consumed that tells something about how much it is used as opposed to how often it is installed, and the use grows considerably faster than the number of installs. The consumption table is particularly freaky, what happened in December that almost doubled the traffic (and increased the number of pageview by almost a half)? In November Mini 4.0 was released. That the data consumption increased faster than the number of pages viewed would either mean that people were viewing more advanced (or bloated) pages than they did before, that the data compression is less efficient than 3.0, or both.
The bigger story is that five times as much traffic is handled this March than a year ago, and though the columns are too small to measure precisely that in turn was five times as much as March 2006. So will the current 1 terabyte of data every day turn into 5 terabytes by 2009? By the guesstimate that
Opera Mini uses a quarter of Norway's bandwidth, they should be using five quarters of the bandwidth by then...
Of more general interest would be which sites are visited, but I am missing the PC top 10 for the different countries to compare results. The variability from a country to the next is pretty high, possibly higher than desktop. I also wonder how the sites are classified.
If social network sites are relatively more commonly accessed on a phone than on a PC, it would fit my tenet that a phone is a more social device than a PC. A high number of searches wouldn't be surprising either, you get the answer where you are, and now you have a fair chance of getting the answer before you forget the question too.
Tuesday, 13. May 2008, 09:52:30
web 2.1, www, standards, markup
...
This post is a reaction to
xErath's comment to an earlier rambling.
Originally posted by xErath:
There's enough info online about the deficiencies of ooxml. I don't need to quote them here.
Just to have it over with, we agree. I may be a Microsoft groupie at heart, but I don't have time for OOXML. People who want to discuss OOXML should feel free to do so, elsewhere. More interesting is this part:
HTML5 is a big patch over HTML4, made to be backwards compatible with the complete mess that is the web.
ODF on the other hand is a clean approach to define an abstract model of document formats. Then ODF has many features that html5 will never have nor will make any sense. I doubt html5 will ever include native spreadsheets support, slide transitions, page footers and headers... you name it. ODF will not support local databases nor globalStorage.
First, I have come to realise that the phrase "it is a complete mess" is a shorthand for "it works very well, and I don't think it should". In fact the Web is a remarkably sane place. We have millions of monkeys making Web code every day, and it works. The Web is more like an ecosystem than an engine, you don't stop and "repair" it, it is survival of the fittest. If you look at Web code written today and ten years ago the old code was worse and still achieved less. The Web has evolved and it keeps evolving.
Read more...
Monday, 12. May 2008, 06:46:33
Opera, PROWAS, www, Praha
At least until tonight when we, if in Prague,
will find out. Opera's Håkon Wium Lie (
nice interview), will count down to its doom.
Friday, 11. January 2008, 21:09:00
past, iCab, www
By the end of last year one long-standing competitor to Opera ceased to develop its browsing engine. No, I am not thinking of Netscape, that browser was dead when it was bought by AOL, but an old Opera favourite,
iCab. From now on iCab will use WebKit as the engine, in effect turning it into a WebKit skin, like OmniWeb before it. This is more sad and nostalgic, OmniWeb was always about the UI anyway, while iCab showed that two skilled and dedicated programmers could compete in making a browser that (some) people actually wanted to use.
This is not to say that it wasn't a sensible, rational, and reasonable business decision. iCab can prosper more easily now that as tiny team can focus on the one thing closest to their users, and leave site compatibility to the much larger group of WebKit developers and evangelists. My next
will be on them. However, this leaves the choice on the Mac platform to three, WebKit (Safari, OmniWeb, and now iCab), Gecko (primarily Firefox, but also Camino and others), and Presto (Opera). In general the trend on any operating system is less choice, not more, and this trend is likely to continue. There is unlikely to be a radical new browsing engine in 2008 or in 2009, the choice is instead going to be among the existing ones.
Saturday, 30. July 2005, 14:19:43
www, interoperability
As
Olli mentioned, Chris Wilson has
expounded on important interoperability bug fixes in the future IE7. This list of bug fixes will remove a lot of cross-browser headaches, but ironically fixing them will also add some new ones.
CSS can to a large degree adapt to browsers with a wide range of capabilities by virtue of its compatibility rules. Even proprietary extensions like IE's filters cause no problem with other browsers, they just ignore them. Unfortunately implementation bugs can ruin this cross-browser harmony. Netscape 4 had some notorious bugs, including crashes, that set back the uptake of CSS for years. It can also be hard do design around the lack of some crucial features like CSS selectors.
With an IE7 with substantially less CSS 2.1 bugs than IE6 but substantially more than Opera/Firefox/Safari (none of which are completely bug-free, though I would claim we are quite good), there is one more browser combination to work around.
The saving grace is IE's excellent
conditional comments. They prevent much uglier CSS hacks that would otherwise be used. CSS hacks practically always have unintended side-effects. They also stick around long after their sell-by date, and they are plain ugly.
I sometimes wonder if we should have similar conditionals. It is fairly hard to make rules that target Opera 8 exclusively. Some have used capabilities like us being the only browser supporting Media Queries right now, but this will have
negative consequences. We could add some sniffability ourselves, like e.g. @opera 8 {/* Only processed by Opera 8, ignored by all other compliant browsers */} or even conditional comment support of our own.
Then I remember how much I detest browser sniffing, which over time seems destined to cause more harm than good, and come to the conclusion that encouraging this will likely not be in our own best interest or of the Web at large.
Wednesday, 13. April 2005, 12:06:08
acid2, www
The otherwise honourable
Acid2 test dredged up something I had hoped I wouldn't see again. Most tests are CSS tests, parsing and layout, but they also threw in an old misfeature from HTML's past. If you look at the test's source code you will find "ERROR". An HTML comment followed by "ERROR", right? No, unlike in the more modern XML "" are not comment delimiters, "--" is. In SGML so ERROR is actually a part of a long comment. Easy to see, isn't it?
In theory
HTML is a SGML application so SGML rules apply. In practice there has never been a SGML web browser and there never will. For a long time Opera was alone in supporting some SGML-isms like "--" comment delimiters until we removed them around Opera 5 or 6, but Opera wasn't even close to being a SGML browser so all we did was to add quirks and give no benefits.
Mozilla later made exactly the same mistake as we did and they are still doing it. This causes an interoperability problem as Mozilla will fail on this comment and other browsers don't. The obvious solution would be for Mozilla to change their browser, but WaSP opted for the other option instead. If that view wins through web developers will be bound to count their hyphens. Any multiple of four is good, anything else is bad.
Monday, 28. March 2005, 10:55:14
www
New member beckfield started two threads on XSLT and Opera, one
civil, one
less so. That is fairly topical as the recent buzzword
AJAX (no relation) includes XSLT and Opera does not.
There is no discussion about XSLT on the server side, transformations is what web servers do, but client-side transformations would put XSLT into another role. XSLT will have to think like a client and is it up to the task?
This has not been an issue due to the dearth of XSLT-enhanced web pages, there is just a handful sites on the web though Google Maps is one of those, but as far as I know nobody has studied this. Where does client-side XSLT really fit in with the Web UI (HTML, CSS, JS) and how well does it adapt to the user's environment?
Thursday, 17. February 2005, 22:50:07
www, web forms
Forms handling is among the most important functions in a browser, the HTML 2.0 forms are seriously outdated and
news.com.com considers the forms alternatives. As I see it there isn't a conflict Web Forms 2.0 vs XForms. Web Forms is designed
partially XForms compatible. There are substantial differences that run deeper than on the syntactic level (such as the names of the elements) and there is no tool today that can automatially turn arbitrary XForms forms into Web Forms. Some, probably most, forms will be very similar in the two languages both in structure and functionality and could be converted easily.
Wednesday, 24. November 2004, 18:29:34
markup, www, w3c
Yesterday I finally left the HTML working group. While it was a recent discussion that made me ask myself what was the point in staying, I have grown more disenchanted over the years.
Unlike
some I don't agree that
XHTML 2.0 is an unmitigated disaster. There is much good stuff in the spec. It is also the first structural work on HTML since
HTML 4.01, five years ago. In the meantime the focus has been to make HTML XML-compatible and to split HTML into modules. Whether HTML is formulated in XML or in some kind of SGML matters, but it isn't important relative to how the language itself should evolve. HTML 4 is overdue for an update.
XML (and thus XHTML) has two obvious advantages. It separates between syntax errors (well-formedness) and expectation errors (validity), and the character set of the document is not in doubt. The XHTML modularization itself isn't that useful for practical purposes where
the conformance rules and the implicit fallback principle (ignore what you don't understand) is what you need. A side effect of the work on XHTML 2.0 is that XHTML Modularization will be updated to actually describe the modules in the document itself, and not by reference to HTML 4.01 as has been the case up until now.
The
revolutionary aspect of XHTML 2.0 was overdone. I don't think the W3C, or browser vendors, or web editor vendors, or any other organization or group has control over the web or its formats. I don't overly worry about Microsoft either. They tried to replace the web before and failed spectacularly. They might try again, but if they do they will fail again. The web is the world's largest installed base. It will change, but not on command. A decade ago change by decree might have been feasible, but this is the difference between shepherding a flock of hundreds of
sheep and one of several billions. That flock goes where it wants to go, not where we want it to go.
Friday, 21. May 2004, 14:36:38
markup, wap, www
One common statement from the WAP advocates (who, like the World War I veterans, are getting fewer by the year) is that WML is a more compact language than (X)HTML. Not so. It is a simpler language, you don't need an as advanced browser to handle it, but the WML source is actually more bloated than HTML precisely because it is a simpler language. Since WML 1 doesn't even have the headline elements ('h1' to 'h6'), you can't use code like <h2>A subhead</h2>, you have to do something like
<big><big><b>A subhead</b></big></big>. Not only do you lose the useful information that "A subhead" is a headline, you need more markup to say less.
There are some byte optimisations, WML align="c" is shorter than align="center", though using CSS would be even shorter than either of the two. HTML has some inefficient quirks, 'strong' and 'b' are used for the same purpose, and 's' and 'strike' are two elements for the same visual effect. Sometimes old-style WML too use more verbose syntax, like <anchor>link text<go href="url"></anchor> for <a href="url">link text</a>. More usefully WML has a compressed non-XML format confusingly called "binary XML" that gives considerable savings when the page is sent uncompressed from server to client. When sent compressed the gains would be minor.
The WAP graphics format WBMP is the only uncompressed format you will find on the web. Again designing for simplest possible processor doesn't make for a compact format. The saving grace is that only black and white are allowed, WBMP images are supposed to be tiny, and that it doesn't matter much if the data stream is compressed anyway.
Now, in the real world a WML page may be a few KB, while the source code for a news site like cnn.com might run into over a hundred, with the graphics clocking in hundreds more. Surely the WML page gives more news for the byte. Yes, it does, but that is not due to WML being a more compact format, but due to the WML page being crafted for small size. An equivalent HTML page will always be smaller, and an HTML+CSS page smaller still.
So why is the news page so huge? In a word: over-specification. If you look at the source code of a typical news page you will have a hard time finding the news items themselves for all the markup. Not only will you find the source filled with fonts and nested tables, the same effect is specified multiple times. Why is this so? Obviously the economics of serving and receiving web pages has not had a major role in the design. News sites have learned to serve simpler and smaller pages in times of major events where the surge of interest might overload the server, but when the crisis is over they return to the old design. The pages may be bloated, but they are tested and they generally look the same in every browser. Furthermore the code in some cases have passed the point of no return, they have grown so complex that any change will have unforeseen consequences. This particularly applies to JavaScript. Removing lines of script requires reading and understanding the existing body of code, adding even more lines does not. The script is now destined to continue growing until it collapses under its own weigth.
