browsers, standards
In a recent message to the webkit-dev mailing list, Dean Jackson outlined some details about plans to enable CSS Transitions (and related WebKit-specific CSS visual effects) on SVG properties in WebKit.
Excerpt:
We have plans to allow transitions on SVG properties:
https://bugs.webkit.org/show_bug.cgi?id=21586
I predict that bug will probably get Animations working at the same time (in the engine there isn’t a huge difference).
Of course that will only work for SVG’s style properties, not the attributes (like cx/cy for the positioning of a circle).
Transforms and 3D Transforms were written to be as compatible with SVG as possible. 2D transforms could reasonably apply to SVG (except the SVG specification says transform is an attribute, not a property). 3D transforms are slightly trickier because they could change the SVG rendering model for drawing order. The SVG WG at W3C are currently looking into this - we hope they come up with something that is compatible with what we have proposed.
For more context and a few more details, see the full text of the message.
To follow progress on this work, you can subscribe to WebKit bug 21586.
2009-03-02 ·
browsers, standards
If you don’t know what the getBoundingClientRect method is, you can read about it at the Mozilla Developer Center site or at the Microsoft Developer Network site — or better yet, read what John Resig has to say about it.
WebKit was the last remaining major browser engine that lacked support for getBoundingClientRect (and for the related getClientRects method) — until yesterday, when Sam Weinig landed support for it in WebKit too.
In my book at least, adding another useful supported-across-all-major-browsers feature to the open Web platform is a pretty cool thing. And as far as why this feature in particular is a worthwhile addition, well, you might want to go back on read John Resig’s write-up about it; title: getBoundingClientRect is Awesome.
2009-02-12 ·
browsers, standards, html5
The Database panel in WebKit’s Web Inspector now allows you to examine HTML5 per-origin client-side persistent data (name-value pairs) associated with a particular Web application — both localStorage data and sessionStorage data. That’s in addition to the ability it already had for allowing you examine per-origin/application client-side SQL data.
If you want to play around with it, feel free to play around with this: simple localStorage demo app. That demo app is a copy of one that Hixie set up at the WHATWG site — with one modification: I added a Delete button so that you can remove items (name-value pairs) and see the results reflected in Web Inspector.
It seems we have Nokia’s Yael Aharon to thank for submitting the patch that added this capability. I’d also guess that, as Yael suggested in the the WebKit bug report associated with the change, the Databases panel will eventually simply renamed Storage.
I’d also guess that capabilities will eventually be added for changing the name-value data directly from within Web Inspector (instead of being limited to only examining the data) — similar to the way that Web Inspector and similar developer tools in other browsers already allow you to change CSS properties and contents of the DOM.
Anyway, here’s hoping that developer tools in other browsers will at least also add the same kind of capabilities that Web Inspector now has for examining client-side persistent data.
2009-02-09 ·
browsers, standards, events
At the moment, I’m participating in a State of the Web 2009 panel discussion at Web Directions North. Lars Erik Bolstad from Opera is on the same panel and has just announced that Opera has developed a new ECMAScript/JavaScript engine named Carakan that uses a register-based bytecode instruction set and that’s 2.5 times faster on SunSpider than the previous JS engine in Opera, named Futhark.
And by providing an experimental implementation of a mechanism that eliminates the need for a bytecode-interpreter step — by compiling directly into native code — it has the potential to provide even more dramatic speed improvements. On the order of 5 to 50 times faster.
2009-02-05 ·
comments off
events
I’m at the Web Directions North event in Denver this week. I did a presentation at the “Ed Directions” pre-event yesterday and afterwards had a great dinner discussion with many of the folks involved in that.
Earlier today, John Allsopp asked me if I’d take part in the panel for the State of the Web 2009 discussion in the afternoon, along with Chris Wilson, Dan Connolly, Lars Erik Bolstad from Opera, Scott Fegette from Adobe, and John himself. So, very much looking forward to that.
I knew Manu Sporny and Christian Heilman would be here, and was glad to have a chance to finally meet them and talk with them during a break this morning. Among the other folks I’m looking forward to meeting here are Brad Neuberg and Dion Almaer. And have not seen my friend Ryan Sarver here yet, but I know he’s going to be here, so will be great to see him.
Tomorrow morning I’ll be doing my Web standards and the browser landscape: The year in review, the year ahead presentation. I guess I should probably get around to finishing up the slides for that…
2009-02-05 ·
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 ·
« Previous entries ·
Next entries »
