sorted by: recent | see :
popular
Content Tagged with Safari + Ajax
CSS Variables are …. here!
We talked about how CSS variables are next a few months back, and now they are here!
WebKit now has an experimental implementation of CSS variables:
You can test this feature using a WebKit nightly
Once again, via Dylan Schiemann.
SquirrelFish: Technical excitement
Watching people discuss SquirrelFish has been a real pleasure. The WebKit team set the tone with their initial technical detail. Instead of a post saying "We have a fast JSVM now. woohoo!", they told us why it is faster, and what they can work on from here.
The community is continuing the conversation. David Mandelin of Mozilla, who has been doing a great job discussing Tamarin internals, shared his look at SquirrelFish and the improvements: Using a bytecode interpreter, Using direct-threaded interpreter dispatch, Using a register-based bytecode interpreter.
David built microbenchmarks to test out the direct-threaded dispatch and register-based interpreter. I bet Parrot and Dalvik folk are looking at this too (register based).
Take a peak at the bytecodes.
Also, Charles Ying looked at how SquirrelFish is faster than Tamarin, and Mason Chang did the same, comparing SquirrelFish and SpiderMonkey.
SquirrelFish: Details on the new
We posted about the new WebKit JavaScript engine SquirrelFish, and now we have an official announcement that goes into fantastic detail on the beast:
What is SquirrelFish
SquirrelFish is a register-based, direct-threaded, high-level bytecode engine, with a sliding register window calling convention. It lazily generates bytecodes from a syntax tree, using a simple one-pass compiler with built-in copy propagation.
SquirrelFish owes a lot of its design to some of the latest research in the field of efficient virtual machines, including research done by Professor M. Anton Ertl, et al, Professor David Gregg, et al, and the developers of the Lua programming language.
The post then goes into detail on why it is so much faster:
SquirrelFish’s bytecode engine elegantly eliminates almost all of the overhead of a tree-walking interpreter. First, a bytecode stream exactly describes the operations needed to execute a program. Compiling to bytecode implicitly strips away irrelevant grammatical structure. Second, a bytecode dispatch is a single direct memory read, followed by a single indirect branch. Therefore, executing a bytecode instruction is much faster than visiting a syntax tree node. Third, with the syntax tree gone, the interpreter no longer needs to propagate execution state between syntax tree nodes.
The bytecode’s register representation and calling convention work together to produce other speedups, as well. For example, jumping to the first instruction in a JavaScript function, which used to require two C++ function calls, one of them virtual, now requires just a single bytecode dispatch. At the same time, the bytecode compiler, which knows how to strip away many forms of intermediate copying, can often arrange to pass arguments to a JavaScript function without any copying.
And finishes by promising that this is just the beginning, and that we are going to see even faster:
In a typical compiler, conversion to bytecode is just a means to an end, not an end in itself. The purpose of the conversion is to “lower” an abstract tree of grammatical constructs to a concrete vector of execution primitives, the latter form being more amenable to well-known optimization techniques.
Therefore, though we’re very happy with SquirrelFish’s current performance, we also believe that it’s just the beginning. Some of the compile-time optimizations we’re looking at, now that we have a bytecode representation, include:
- constant folding
- more aggressive copy propagation
- type inference—both exact and speculative
- specialization based on expression context—especially void and boolean context
- peephole optimization
- escape analysis
This is an interesting problem space. Since many scripts on the web are executed once and then thrown away, we need to invent versions of these optimizations that are simple and efficient. Moreover, since JavaScript is such a dynamic language, we also need to invent versions of these optimizations that are resilient in the context of an unknown environment.
We’re also looking at further optimizing the virtual machine, including:
- constant pool instructions
- superinstructions
- instructions with implicit register operands
- advanced dispatch techniques, like instruction duplication and context threading
- getting computed goto working on Windows
Performance on Windows has extra room to grow because the interpreter on Windows is not direct-threaded yet. In place of computed goto, it uses a switch statement inside a loop.
Not only is SquirrelFish exciting, but the post itself shows that they get that this is aimed at developers. Great job.
The Sea of Ideas " Blog Archive " Coverflow, anyone?
Using CSS transforms to Build a Coverflow Effect
Webkit's new CSS transforms are hot and developers are really starting to take notice. The ability to rotate and scale DOM elements via CSS has gotten people thinking about new possibilities. LifeRay's Paul Bakaus has been experimenting with the new feature and was able to create a cool iTunes-like coverflow effect that actually flows and animates in real-time, without using canvas or prerendered graphics.
This handy nifty new css feature allows you to do all kinds of 2d transformations on any element on the page, by utilizing custom CSS tags. This means you can rotate and translate DOM elements, but you can also use a generic matrix function to do whatever you want.
So here is where it get’s interesting. The fun thing about CSS Transforms is that they work today, in Safari 3.1, and on the iPhone, not only in one of the nightly builds, so it’s possible to target real-world users.
Paul used jQuery UI to create the actual coverflow widget and jQuery UI’s slider to be able to slide through. You can also navigate through the items by clicking on them or using the left/right keys on your keyboard.
You will need Safari 3.1 or Webkit to see this in action as CSS Transforms is currently limited to the Webkit browser platform.
SquirrelFish: WebKit has a new, fast, JavaScript engine
SquirrelFish seems to be the code name for a new JavaScript engine for WebKit.
You can see performance benchmarks that show a significant increase across the board of tests.
On average the tests show a 4 times improvement (compared to Safari 3.1), with spikes of 12.6x improvements on some access tests, and with the lowest grade of 1.63x for String unpacking.
This is great news. We are now seeing all of the major browsers improving their JavaScript stacks significantly, which means we will be able to do a lot more. If you are building heavy Ajax applications, this is what you dream off, and at the same time you hope that you can stop worrying about older browsers ;)
CSS Variables are next?
How long have you wanted to name colors and such in your CSS instead of having to use search and replace (which breaks if you share the same colors ;) ?
We have a proposal thanks to Daniel Glazman and the ubiquitous David Hyatt.
Since the release of CSS Level 2 Recommendation ten years ago in may 1998, the Web authors' community has been requesting a way of defining variables in CSS. Variables allow to define stylesheet-wide values identified by a token and usable in all CSS declarations. If a value is often used in a stylesheet - a common example is the value of the color or background-color properties - it's then easy to update the whole stylesheet statically or dynamically modifying just one variable instead of modifying all style rules applying the property/value pair. We expect CSS Variables to receive a very positive feedback from both the Web authors' community and browser vendors.
With Dave on the author list, we can expect the following to work on WebKit sometime soon!
-
-
@variables {
-
CorporateLogoBGColor: #fe8d12;
-
}
-
-
div.logoContainer {
-
background-color: var(CorporateLogoBGColor);
-
}
-
(via Dylan Schiemann)
WebKit keeps going with CSS Masks
Wow, get the feeling that they are on a roll with taking Canvas / SVG like use cases, generalizing them, and making them available to people as simple CSS.
First we had CSS animations, and we are now going with CSS Masks which run across images and <video> elements:
WebKit now supports alpha masks in CSS. Masks allow you to overlay the content of a box with a pattern that can be used to knock out portions of that box in the final display. In other words, you can clip to complex shapes based off the alpha of an image.
You now have all of these to work with:
-webkit-mask (background) -webkit-mask-attachment (background-attachment) -webkit-mask-clip (background-clip) -webkit-mask-origin (background-origin) -webkit-mask-image (background-image) -webkit-mask-repeat (background-repeat) -webkit-mask-composite (background-composite) -webkit-mask-box-image (border-image)
The image at the top of the post is made via:
And we will now see even more rounded corners:
-
-
<img src=”kate.png” style=”-webkit-border-radius: 10px; -webkit-mask-image: -webkit-gradient(linear, left top, left bottom, from(rgba(0,0,0,1), to(rgba(0,0,0,0))”/>
-
You can even use SVG as an image input:
This is huge. Web 3.0 will surely be about going beyond big fonts and rounded corners, and will go towards using the same killer masks ;)
CSS Gradients in WebKit
Dave Hyatt, the one person I would love to get to TAE to join the other browsers, posted about CSS gradients in WebKit:
CSS:
So what exactly is a gradient in CSS? It is an image, usable anywhere that image URLs were used before. That’s right… anywhere. :)
You can use gradients in the following places:
- background-image
- border-image
- list-style-image
- content property
The type of a gradient is either linear or radial.
A point is a pair of space-separated values. The syntax supports numbers, percentages or the keywords top, bottom, left and right for point values.
A radius is a number and may only be specified when the gradient type is radial.
A stop is a function, color-stop, that takes two arguments, the stop value (either a percentage or a number between 0 and 1.0), and a color (any valid CSS color). In addition the shorthand functions from and to are supported. These functions only require a color argument and are equivalent to color-stop(0, …) and color-stop(1.0, …) respectively.
This is great stuff. Think about the image repeating tricks you have had to do just to get some of this behaviour. This is much more elegant.
There are a bunch of examples:
And in conclusion, we have a lot more coming:
WebKit now supports a generic architecture for generated images, making it easy to add new generator effects to CSS in the future (lenticular halos, checkerboards, starbursts, etc.). The rules for sizing of these generated images will match whatever is decided for SVG content with no intrinsic size (the two are sharing the same rules right now).
We encourage you to try gradients out and file bugs if you see any unexpected or weird behavior. They will degrade safely in other browsers as long as you use multiple declarations (e.g., specify the image in one declaration and the gradient in a following declaration).
The importance of bandwidth versus latency
Between cranking on Acid 3 tests, the WebKit crew has explained some issues in Optimizing Page Loading in the Web Browser:
It is well understood that page loading speed in a web browser is limited by the available connection bandwidth. However, it turns out bandwidth is not the only limiting factor and in many cases it is not even the most important one.
From the figure it is clear that while available bandwidth is a significant factor, so is the connection latency. Introducing just 50ms of additional latency doubled the page loading time in the high bandwidth case (from ~3200ms to ~6300ms).
Antti Koivisto goes on to explain why latency has such an impact, and how it is related to the browser having to figure out “all the associated resources” for a page, and the bane of document.write():
Problems start when a document contains references to external scripts. Any script can call document.write(). Parsing can’t proceed before the script is fully loaded and executed and any document.write() output has been inserted into the document text. Since parsing is not proceeding while the script is being loaded no further requests for other resources are made either. This quickly leads to a situation where the script is the only resource loading and connection parallelism does not get exploited at all. A series of script tags essentially loads serially, hugely amplifying the effect of latency.
The situation is made worse by scripts that load additional resources. Since those resources are not known before the script is executed it is critical to load scripts as quickly as possible. The worst case is a script that load more scripts (by using document.write() to write <script> tags), a common pattern in Javascript frameworks and ad scripts.
And now where WebKit comes into the picture..... they have put in some nice optimizations:
The latest WebKit nightlies contain some new optimizations to reduce the impact of network latency. When script loading halts the main parser, we start up a side parser that goes through the rest of the HTML source to find more resources to load. We also prioritize resources so that scripts and stylesheets load before images. The overall effect is that we are now able to load more resources in parallel with scripts, including other scripts.
WebKit Passes Acid3
WebKit has a public build that gets 100/100 in Acid3.
I can just see the quibbling between the Apple and Opera teams now, but instead of making this an American election vote, ("but I WON THE POPULAR VOTE" "but that popular vote doesn't matter!") lets just say "great job" to both and move on? :)
Key events and Safari 3.1
There has been a change in Safari 3.1 for how keypress events are handled. John Resig interviewed Yehuda Katz to get the skinny and understand why this was done.
The key comment is:
Use keydown/keyup if you want to know the key that was pressed; keypress if you want to know what text was detected.
John: At first glance through WebKit's changes it appears as if they've significantly crippled the keypress event, is this the case?
Yehuda: People should not have been using the keypress event to get the character that was pressed. That's because the keydown event only provides information about the actual key that was pressed (the A key, the right arrow, etc.), but does not tell the user what character will get added to (for instance) an input box.
Since arrow keys do not get added as text, keydown provides all the information that is needed. There were a couple of quirks with using keydown in certain cases previously which are resolved by their changes that prevent keypress from getting called if keydown's default handling is blocked.
What this means is that if people were using keypress before (and relying on Safari's native results for arrow keys, such as 63232), their code will break. However, this was a bad idea all along; people should use keydown to detect and block non-character keys. My mantra has always been: keydown/keyup if you want to know the key that was pressed; keypress if you want to know what text was detected.
Mihai Parparita is fixing Google Reader.
Also, Dean Edwards noted that Safari 3.1 failed Acid2 (not 3!) in a regression, but it appears a patch has landed.
Safari 3.1 Released
Safari 3.1 has been released, so fire up your software update now (or direct install).
The new release includes features (and many more):
- JavaScript performance improvements
- Standards: Adds support for CSS 3 web fonts
- Standards: Adds support for CSS transforms and transitions
- Standards: Adds support for HTML 5 <video> and <audio> elements
- Standards: Adds support for offline storage for Web applications in SQL databases
- Standards: Adds support for SVG images in <img> elements and CSS images
- Standards: Adds support for SVG advanced text
- Developers: Adds option in Safari preferences to turn on the new Develop menu which contains various web development features
- Developers: Allows access to Web Inspector
- Developers: Allows access to Network Timeline
- Developers: Allows editing CSS in the Web Inspector
- Developers: Allows custom user agent string
- Developers: Improves snippet editor
There are also nice user features like double-clicking a link to open in a new window, trackpad gestures, and caps lock view on a password field.
(thanks to Richard Kimber for the quick tip)
WebKit, GTK, and Qt
Ryan Paul has written about creating rich Internet applications on Linux with WebKit:
The open-source WebKit HTML rendering engine is rapidly gaining ground on the Linux platform where it is increasingly being adopted by conventional desktop applications for content display. Ongoing efforts to facilitate tighter WebKit integration are opening the door for developing rich Internet applications on Linux with the open-source GTK and Qt development toolkits.
The article talks about the HTML 5 video support in GTKWebkit, using Epiphony, Maemo, and OLPC.
Firefox 3 Mac performance gains due to undocumented APIs
Vladimir Vukićević has posted on the performance improvements of Firefox 3 on the Mac, and how one hack, albeit "dangerous" has helped ton. Vladamir says:
While figuring all this out, I noticed that Safari/WebKit didn't seem to be affected by this framerate cap -- the fps meter when Safari was running the same benchmark happily went up beyond 60fps. After I found the plist entry, I checked Safari's plist and was surprised to discover that they didn't have this disabling in there. Doing some more searching, I found this code in WebKit. Apparently, there is a way to do this programatically, along with some other interesting things like enabling window update display throttling (though it's unclear what that means!) -- but only if you're Apple.
All these WK* methods are undocumented, and they appear in binary blobs shipped along with the WebKit source (see the WebKitLibraries directory). There are now over 100 private "OS-secrets-only-WebKit-knows" in the library, many of which are referred to in a mostly comment-free header file. Reading the WebKit code is pretty interesting; there are all sorts of potentially useful Cocoa internals bits you can pick up, more easily on the Objective C side (e.g. search for "AppKitSecretsIKnow" in the code), but also in other areas as a pile of these WK* methods used in quite a few places. Would any other apps like to take advantage of some of that functionality? I'm pretty sure the answer there is yes, but they can't. It's not even clear under what license libWebKitSystemInterface is provided, so that other apps can know if they can link to it.
David Hyatt, the guru lead of Webkit/Safari commented:
The programmatic disabling of coalesced updates should not be public API. It’s actually a very dangerous thing to do. We aren’t really happy with that code in WebKit, but we had to do it to avoid performance regressions in apps that embedded WebKit. Technically it’s wrong though, since we turn off the coalesced updates for any app that uses WebKit! This includes drawing they do that doesn’t even use WebKit.
As for the window display throttling, that was a pref designed for Safari (that we don’t even use any more). It’s not private or magic. It’s nothing more than a pref that we can examine from Safari-land, so linking to that is just silly. ;)
Many of the private methods that WebKit uses are private for a reason. Either they expose internal structures that can’t be depended on, or they are part of something inside a framework that may not be fully formed. WebKit subclasses several private NSView methods for example, and it cost us many many man hours to deal with the regressions caused by the internal changes that were made to NSViews in Leopard.
As you yourself blogged, there was a totally acceptable public way of doing what you needed to do.
For any private methods we use that we think should be public, we (the WebKit team) file bugs on the appropriate system components. Many of these methods have become public over time (CG stuff in Leopard for example). Be careful when you dig into WebKit code, since we may continue to use the WK method even though it’s not public API just because we need to work on Tiger.
Robert O'Callahan is much more aggressive and claims platform tilt:
The source to the WK wrappers is not available; the implementations are in a binary blob library that you download with the Webkit sources. It appears the sole purpose of closing the source to this library is to conceal the signatures of the undocumented framework APIs used by Webkit, presumably so that ISVs like us can't use them.
...
A key part of Webkit on Mac is kept deliberately closed source by Apple. That's unfortunate. Instead of hiding the source, a much more friendly policy for Apple would be to make these APIs public as a matter of course. They may argue that there are unfrozen APIs that they don't want exposed, but there are ways around that, such as by tying symbol names to specific OS versions (CGContextFooBar_10_4?) and promising they'll just not be there in future versions.
It's worth reflecting that if Microsoft was doing this, they'd likely be hauled before a judge, in the EU if not the US. In fact I can't recall Microsoft ever pulling off an undocumented-API-fest of this magnitude.
WebKit flies on my Mac, and Firefox 3 has almost caught up. The end result is that I am pretty happy with how browsers are improving their performance, and I am sure there is a lot more to see.
Native CSS selectors with querySelector
David Smith of WebKit posted about their native implementation of querySelector and querySelectorAll from the W3C Selectors API.
Native CSS selectors in the browsers is going to be a huge boon for us and the Ajax libraries that will be able to use them.
You can use the standard via:
* Get all the elements with class "hot" (duplicating getElementsByClassName)
* A common use for this is as a toggle;
* for example, a search feature might tag results with a class
*/
document.querySelectorAll(".hot");
/*
* Get the currently hovered element
*/
document.querySelector(":hover");
/*
* Get every other element in the <li> with id "large"
* This is mostly useful for doing "zebra stripe" alternating rows.
* Once CSS3 becomes more widespread, doing this directly via CSS will be more practical
*/
document.querySelectorAll("#large:nth-child(even)");
Our favourite libraries can implement the same API and do the hard work in JavaScript if the browser doesn't support it.
Point your new Webkit build at the performance test that they use (based on the mootools one) to see how fast you can be if you are native. Vroom vroom.
Debug apps with Drosera for Windows
We all talk about Firebug, which is a fantastic tool for debugging, but there are some others out there. WebKit comes with Drosera, which until now has been hard to get going on Windows (you could build from source).
Now Drosera is in WebKit nightlies on Windows as Kevin McCullough of Apple told us:
Our JavaScript debugger Drosera is available in the Windows nightlies, and I would love to get some help testing and finding issues. Drosera will not work with the Safari beta, but should automatically connect to the nightly it’s downloaded with. Simply use the run-drosera script that’s now included. I’m excited to bring Drosera to Windows and I hope it becomes a go-to tool for your Windows JS investigating, testing, and development.
Do you care? Are you on Windows and have been jealous of the Apple debugging love?
WebKit gets native getElementsByClassName
getElementsByClassName has always been a pain in the arse for us developers. Why it wasn't implemented natively across the board is something that browser folk can chat about. Not having it available has caused hacks, workarounds, and bugs.
Firefox and Opera support the beast, and now Webkit has joined them:
The advantages of a native implementation are clear:
- No additional JavaScript library files required
- Clearly specified and consistent behavior
- Blindingly fast
How fast? Let’s have a look at WebKit’s shiny new implementation. For testing purposes I wrote a simple benchmark allowing comparison between three different methods for getting elements by their class names. The first is the new native getElementsByClassName, and the last two are both from prototype.js; one uses XPath, and the other is a straight JavaScript/DOM implementation.
Safari CSS Reference
Do you want to have one place that tells you about all of the Safari properties?
Now we have it.
The reference shows not only the standard properties and how Safari handles them, but also all of the -webkit-* properties such as -webkit-border-top-right-radius:
WebKit 3 shows up with the new Safari
With the OS X push of 10.5.1 and 10.4.11, and a new Safari/Win beta, we see the latest and greatest of WebKit in Safari itself.
To kick this off, Maciej Stachowiak has blogged 10 new things in WebKit 3:
- Enhanced Rich Text Editing: And RTE needs help!
- Faster JavaScript and DOM: ~2 times faster
- Faster Page Loading: WebKit 3 is 1.4 times as fast
- SVG: Yay
- XPath: Yay
- New and Improved XML Technologies: XSLTProcessor, DOMParser, XMLSerializer, a better XHR ("incremental updates for persistent server connections")
- Styleable Form Controls: No more native
- Advanced CSS Styling: Text-stroke, text-shadow, and more
- Reduced Memory Use: WebKit 3 uses 14% less memory
- Web Developer Tools: Web Inspector, Drosera
HTML5 Media Support: video and audio tags and scriptability
WebKit keeps on trucking and has added support for the HTML 5 media tags such as <video> and <audio>.
You can add video to a page as easily as:
-
-
<video src="sample.mov" autoplay></video>
-
That is a lot cleaner than the mess of embed/object/JavaScript wrappers that we have today. Also, there is nice scripting support so you can play/pause a video:
You can also tie into events:
-
-
myVideo.addEventListener('ended', function () {
-
alert('video playback finished')
-
} );
-
and programatically do your thing:
-
-
new Audio("song.mp3").play();
-
One key issue has always been the codec game and royalties to mpeg.
Webkit CSS Transforms
Webkit now has CSS Transforms:
Boxes can be scaled, rotated, skewed and translated. The current nightly builds support affine transformations.
A transform can be specified using the -webkit-transform property. It supports a list of functions, where each single function represents a transform operation to apply. You can chain together operations to apply multiple transforms at once to an object (e.g., if you want to both scale and rotate a box).
At the moment transforms do not affect layout, so they are similar to relative positioning in that respect. We are exploring ideas for how to do transforms in ways that could affect layout.
Michael Daines got to work and created the following example that makes the logo bump and grind using this JavaScript:
-
-
HilariousWebkitTransform = {
-
angle: 0,
-
scale: 1,
-
scaleFactor: 1.01,
-
image: document.getElementById("gold-webkit-icon-in-box"),
-
-
animate: function() {
-
this.angle += 1;
-
this.scale *= this.scaleFactor;
-
-
if (this.scale> 2)
-
this.scaleFactor = 0.99;
-
-
if (this.scale <1)
-
this.scaleFactor = 1.01;
-
-
if (this.angle> 360)
-
this.angle = 1;
-
-
this.image.style.webkitTransform = 'rotate(' + this.angle + 'deg) scale('+ this.scale + ')';
-
}
-
}
-
-
setInterval(function() { HilariousWebkitTransform.animate(); }, 10);
-
