Showing all entries with tag: browsers
browsers, standards, html5
Ian Hickson, the editor of the current HTML5 draft, posted an Error handling in URIs message to the uri@w3.org mailing list outlining some issues related to browser error handling behaviour for URIs, and to IRIs and character encodings other than UTF-8 — and asking, “Is there any chance that the URI and IRI specifications might get updated to handle these issues?”.
That posting and question spawned some spirited discussion, with messages from Julian Reschke, Anne van Kesteren, Tim Bray, John Cowan, Frank Ellermann, and Martin Duerst, and provoking some comments like the following one:
That’s kind of what I said already, and why I guess that HTML5 will never fly: It tries to reinvent the Web, if not the Internet.
…and from Ian to the above, the following response:
Actually we’re trying to not reinvent the Web, but to document it, so that browser vendors can write browsers that handle existing Web content in a fashion compatible with legacy UAs without reverse-engineering each other.
(It’s true that this is requiring defining things that are at odds with existing specifications, but that’s mostly because those specifications aren’t in fact in line with real usage…)
2008-06-25 ·
browsers, standards
Microsoft’s lead PM for XHR/Ajax sneaks in some FUD in a new Securing Cross Site XMLHttpRequest posting on the IE Blog that otherwise gives a succinct and fairly balanced overview of the shared problem case that various competing “cross-site request” spec proposals (Microsoft’s XDR/XDomainRequest proposal, the W3C Access Control for Cross-Site Requests draft, and Doug Crockford’s JSONRequest) are all trying to solve.
It’s great to see that Sunava includes in that posting a call to join the W3C Web Applications Working group. It’s less great to see the following sentence in the posting:
As can be expected with securing a large cross section of cross domain scenarios, a number of concerns have been identified with the CS-XHR [W3C Access-Control for Cross-Site Requests] draft by the web development community, the IE team members and members of the Web Apps Working Group.
What’s not great about that sentence is what it obscures:
- many of the “concerns” raised about the Access-Control spec have been little more than FUD
- a number of the non-FUD concerns were based on simple misunderstandings of the spec
- the remaining concerns have already been addressed/rebutted repeatedly by implementors such as Jonas Sicking (who wrote the code for the Access-Control support in Mozilla), Kris Zip, and others
- a number of detailed and substantial concerns have also been identified with the Microsoft XDomainRequest proposal (by Kris Zyp and several other people), but those concerns have yet to be adequately addressed in any responses from Microsoft
We (the W3C WebApps WG) will be having a face-to-face meeting next week in Redmond (hosted by Microsoft) to continue the discussion.
2008-06-24 ·
mobile, browsers
UPDATE: See full comments at end from Bradley Morrison and Mark Baker. Excerpted:
Bradley: “No, it doesn’t mean that at all :) Please don’t read into my message on the WebKit mailing list - I was just cleaning up some stale bugs in the WebKit bug database… Nothing more, nothing less!”
Mark: My information is that a new S60 port based off a much more recent branch will be realeased in the next couple of months.
And here’s my original posting that Bradley and Mark were responding to:
A message from Eric Seidel yesterday on the webkit-dev mailing list notes that:
There has not been a checkin to the S60 port in over 8 months… As far as I can tell, the port is dead… Does anyone know the status of the port? If the port is in fact dead, I would like to suggest that we tag (with some keyword, or component) all of the remaining S60 bugs and close them.
Bradley Morrison from Nokia, while noting that “I don’t work on the project myself”, then replies to say:
I’ve just tagged with a keyword & closed (to INVALID) all s60 bugs.
Does this mean that the S60 WebKit port is in fact dead?
2008-04-11 ·
browsers
I really like the fact that I’m able to get notifications of changes to the HTML5 draft through the WHATWG twitter account, so over the weekend — inspired by that and working from an initial code fragment that Hixie sent me that help me get started — I wrote a simple Perl script that watches in (reasonably) near-real time for new checkins/commits to a particular Subversion repository, then takes the change description for each new checkin, re-formats it a bit, and finally posts it as a status-message/tweet to a Twitter account.
I guess the script could be of some general use, but the main reason I wrote it was to be able to have another way (that is, other than e-mail) to keep up with checkins to the WebKit code repository. So I took the liberty of creating a WebKit user at Twitter (username: webkit) and configured things such that the results end up there. If you’re interested, head over and take a look.
I’m not a member of the WebKit project, and don’t want to be the real owner for that Twitter account, so next step is hopefully to hand over the keys for it to one of the WebKit project leads. It may be that the project could want to have a webkit Twitter account for some other purpose (what else it could be useful for, I’m not sure, but maybe something), and have the changes go to a different account. If so, I’m happy to change the setup. Initially, I actually tried to create an account with the username webkit-changes — to match the mailing list of the same name, and to make the purpose of the account clear — but Twitter unfortunately doesn’t seem to allow usernames with dashes in them… I guess webkit_changes or webkitchanges are other options, though neither seems very attractive.
2008-04-08 ·
mobile, browsers
It’s really encouraging to see a vendor of one of the most important application development frameworks for mobile devices making support for modern Web technologies a central part of that framework — and even going so far as to prominently highlight that support in their product messaging.
What I’m talking about is this: Trolltech is currently featuring news to related Webkit on their homepage, in a banner that reads, Qt WebKit Integration brings Web 2.0 services to mobile phones. The banner links to an Announcing the Qt WebKit Integration summary page that gives more details, which in turn links to a press release and a WebKit in Qt and Qtopia white paper.
Note that this is not an announcement of a new browser; instead, it’s news about how Qt provides developers with the ability to easily integrate interactive Web content — real Web content, over HTTP from remote sites — in any applications they build with Qt.
Here’s an illustration borrowed (stolen) from the Trolltech site:
This is not something totally new, because it seems (as far as I can see) very similar to the way that Mac OSX developers can use WebKit to embed web views in Max OSX applications. And I guess that that’s also something that Microsoft Windows developers have been able to do using the Trident engine (the Web engine that Microsoft Explorer uses as its back end.
But as far as I know, it’s not something we’ve seen on any mobile platforms yet. At least not with a major Web engine (major being one of WebKit, Presto, Trident, and Gecko). And at least not widely deployed. I know that there is a related vision behind Opera Platform — but that’s not an integrated application framework on the scale of Qt.
Anyway, if Trolltech is successful with this — if Qt application developers start to make good use of it — it has some potential to help alter the way that developers and users make use of Web technologies — “mobile browsing” without the browser, and more than just simple widgets. And by Web technologies I mean not just HTML and simple CSS, but also stuff like real (asynchronous) DOM scripting (Javascript/Ajax), SVG, and client-side XSLT (all of which WebKit supports). Lars Knoll describes it like this:
The Qt WebKit Integration helps developers to combine live web content with mobile and desktop applications. This erodes the boundaries between the desktop, mobile phones and the Web. It also enables graphics and Web designers to join developers in making user interfaces more advanced than ever – no matter which device or desktop application you are using.
2008-02-12 ·
browsers
For quite a while I was keeping my WebKit/Safari up to date by building from the latest sources checked out from the WebKit Subversion repository or by manually installing the lastest nightly build. Then Maciej Stachowiak pointed out NightShift to me and I’ve been using that since.
NightShift is a simple but very useful Mac OSX application that automatically downloads and installs the latest WebKit nightly build so that you don’t need to do it manually.
As far as why you might want to run WebKit to begin with, well, if for no other reason, you might want to try it just to be able to have access to WebKit’s Web Inspector tool. It’s basically a DOM/CSS/properties inspector similar to those in other browsers. But there are a couple of things that make it different:
- Inspect Element
- You can open Web Inspector by right clicking anywhere on a page and choosing Inspect Element from the context menu. The Web Inspector appears and highlights the corresponding DOM node, with the normal interactive DOM tree view to give you access to the rest of the DOM.
- The Firebug extension for Mozilla/Firefox provides the same kind of context-menu Inspect Element function, but the WebKit feature has the big advantage of being, well, a feature (that is, actually integrated into the core product, instead of requiring installation of an extension).
- Re-root the DOM-tree view
- One problem with display of DOM trees is that in a complex page with deeply nested content, you can end up a with tree view with some severe indentation and that really gives you more information at one time than you really need. So what Web Inspector does is to give you a way to “re-root” the DOM tree view so that the view is reduced to just whatever part of the DOM tree you actually want to examine at that particular time. To cause Web Inspector to re-root the DOM tree view, you just double-click in Web Inspector on whatever DOM node you want to make the new root; then the rest of the tree disappears and you just have a view of that node and its child nodes. Sweet.
2007-05-25 ·
mobile, browsers
So at the end of last month, Stefan Constantinescu over at Ring Nokia posted a blog entry with a screenshot of an “S60 UI Evolution” slide from a presentation that ended up being cancelled but that was supposed to have taken place at the recent S60 Summit in Madrid. One of the bullets on the slide says, Touch User Interface for new kinds of products.
I didn’t pay so much attention to that news until a week or so later when, while reading through mail from the webkit-changes list, I came across the commit message for WebKit revision 21303, which is related to WebKit bugzilla 13561. The description for both the commit and the bugzilla item reads:
S60 3.2 Touch: Scrolling initial implementatoin
So I guess this means we’ll eventually be seeing a version of the WebKit-based S60 browser shipping on devices with the S60 Touch UI and making use of that touch UI. Nice.
2007-05-25 ·
comments off
mobile, browsers
It’s just after 3:30 am here in Singapore and I’m headed to the airport soon to catch a 6:45 flight back to Tokyo. I’d be starting to rethink the “travel ain’t so bad after all” statement that I made the other day — except for the fact that I saw something here that made me remember one of the other not-so-bad things about traveling: It provides some nice surprises now and then.
One particular surprise of this visit came in the form of a TV commercial for Singtel’s mobile data services.
The commercial showed a woman standing in around in some public place outdoors in the city, obviously waiting for somebody who hadn’t shown up. The voice-over says something like, “So your date has stood you up and you’re standing around with nothing to do…” and something else implying the idea of “don’t let yourself get stuck in this situation”.
So then the commercial cuts to a scene that instead shows the same woman spending her stood-up-for-date waiting time productively: She’s now shown using a Nokia E61 — what’s more, what she’s doing on it is browsing the Web on it. And she’s shown not browsing a WAP site, but browsing a full Web site using what I guess is Nokia’s WebKit-based S60 browser. The implication from the voice-over and the images is that the value of the device is that it’ll let you get to any Web content you want, any where you want, any time you want (hey, that idea sounds familiar for some reason…).
That one commercial had the effect of raising my appreciation for Singtel about 1000 percent. I can’t say that I have seen (or even know of) any carrier in the world running TV commercials to encourage users to do browsing of the full Web from their mobile devices — but here’s hoping there will be more of them.
The E61 seems to be a very popular device in Singapore these days. My friend Lucian Teo has one, and I spotted a number of other users in the wild here.
By the way, the little Web-standards event that Lucian and I both spoke at went very well. Great presentation from Lucian, and some great questions from the audience. I’ll write up some more about it once I get back home.
I’m hoping I’ll get back to Singapore again soon. Hopefully my next visit will bring some even nicer surprises than the Singtel browse-the-full-Web-on-your-mobile commercial…
2007-01-17 ·
mobile, browsers
Cameron Moll’s take on the iPhone hype: Why iPhone won’t revolutionize the mobile web landscape. Below, his main points (which Cameron, being the keen-minded designer that he is, calls out with boldface run-in heads to make them easy to spot), and my comments on them.
- Content zooming isn’t new.
- Amen to that. As Cameron points out:
The technology to see an entire web page and zoom in/out — “adaptive zooming”, “mini-map navigation”, what have you — has existed, to my knowledge, for some time now (at least a year?). Additionally, Opera has been developing similar technology for non-desktop browsers, notably of late in the version for Nintendo Wii.
- Data costs will continue to plague subscribers
- Yep. And that’s not a problem the iPhone nor Apple nor any device manufacturer nor browser vendor can solve. The you-know-who-they-are entities who control such things are the only ones who can. And unless/until the data costs go down, doing anything more than casual mobile browsing on the iPhone or any other device is not yet economically feasible in a lot of places.
- Context is still king
- Cameron’s elaboration: “If iPhone isn’t GPS-enabled, that is to say it can tell where I’m at rather than typing in my location, it doesn’t radically alter the existing experience anyway.” Word.
- iPhone owners won’t be the typical mobile web user
- Right. Cameron points out: “India is outpacing all other countries in mobile subscriptions growth, but don’t expect them to be iPhone owners anytime soon”. So the iPhone is hardly going to change the world. Unless you’re one of the people who live in the San Francisco Bay or Silicon Valley area and you think that’s the extent of the known world.
2007-01-11 ·
mobile, browsers
Media reports about the iPhone note that it has Safari installed, but don’t provide any real details. I would guess that it must have a different UI than the Safari that runs on Mac machines, but I haven’t had time to watch the videos yet to see. I’m wondering what display-mode options it provides (if any) — something similar to the Nokia S60 browser’s “mini map”, or like Opera’s small-screen rendering or fit-to-width?
Update: OK, so it looks like it displays pages in the same layout as you’d see them in in a desktop browser, then uses some smart and slick zooming to let you focus in on whatever part of the page you want to view. As noted in some of the media reports, it’s much like the zooming features in Opera running on the Wii. Very much like.
Update: See the iPhone writeup over at the WapReview site.
Update: See Peter Harbeson’s This is my iEntry over at the S60 browser blog. Peter has the following to say about Apple’s claim about iPhone Safari being “the most advanced web browser ever on a portable device…”:
Maybe it’s just me, but wouldn’t you think that since our browser and Safari are pretty much the same thing…
2007-01-10 ·
·
Next entries »
