Friday, April 25th, 2008
Category: Browsers
, CSS, Safari
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!
CSS:
-
-
@variables {
-
CorporateLogoBGColor: #fe8d12;
-
}
-
-
div.logoContainer {
-
background-color: var(CorporateLogoBGColor);
-
}
-
(via Dylan Schiemann)
Category: Browsers, Safari
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:
HTML:
-
-
<img src=”kate.png” style=”-webkit-mask-box-image: url(mask.png) 75 stretch;”/>
-
And we will now see even more rounded corners:
HTML:
-
-
<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:
HTML:
-
-
<img src=”kate.png” style=”-webkit-mask-image: url(circle.svg)”/>
-
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 ;)
Tuesday, April 15th, 2008
Category: Browsers, CSS, Safari
Dave Hyatt, the one person I would love to get to TAE to join the other browsers, posted about CSS gradients in WebKit:
CSS:
-
-
-webkit-gradient
(<type>, <point>
[, <radius>
]?, <point>
[, <radius>
]?
[, <stop>
]*
)
-
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).
Thursday, March 27th, 2008
Category: Browsers, Safari, Performance
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.
Category: Safari, Standards
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? :)
Monday, March 24th, 2008
Category: Browsers, Safari
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.
Tuesday, March 18th, 2008
Category: Browsers, Safari
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)
Thursday, March 6th, 2008
Category: Safari
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.
Friday, February 29th, 2008
Category: Browsers, Firefox, Safari
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.
Monday, February 11th, 2008
Category: Browsers, CSS, Safari
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:
JAVASCRIPT:
-
-
/*
-
* 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.
Friday, January 25th, 2008
Category: Utility, Safari, Debugging
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?
Monday, December 24th, 2007
Category: Browsers, Safari, Performance
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.
Wednesday, November 28th, 2007
Category: CSS, Tip, Safari
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:
Friday, November 16th, 2007
Category: 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
Tuesday, November 13th, 2007
Category: HTML, JavaScript, Safari
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:
HTML:
-
-
<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:
HTML:
-
-
-
function playPause() {
-
var myVideo = document.getElementsByTagName('video')[0];
-
if (myVideo.paused)
-
myVideo.play();
-
else
-
myVideo.pause();
-
}
-
</script>
-
<input type=button onclick="playPause()" value="Play/Pause"/>
-
You can also tie into events:
JAVASCRIPT:
-
-
myVideo.addEventListener('ended', function () {
-
alert('video playback finished')
-
} );
-
and programatically do your thing:
JAVASCRIPT:
-
-
new Audio("song.mp3").play();
-
One key issue has always been the codec game and royalties to mpeg.
Monday, October 29th, 2007
Category: CSS, Safari
