Optimizing Page Loading in the Web Browser

Interessanter Artikel, der unter anderem kurz auf die SCRIPT-Tag-Problematik eingeht.

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.

[snip]

It turns out that figuring out ‘all the associated resources’ is the hard part of the problem. The browser does not know what resources it should load until it has completely parsed the document. When the browser first receives the HTML text of the document it feeds it to the parser. The parser builds a DOM tree out of the document. When the browser sees an element like <img src> that references an external resource it requests that resources from the network.

Problems start when a document contains references to external scripts, <script src>. Any script can call document.write(). Parsing can’t proceed further 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 effect of the 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.

[snip]

(Via Surfin‘ Safari.)

YUI 2.5.0 Released — Big upgrades to DataTable, new Layout Manager, Flickr-style multi-file Uploader, and more

YUI 2.5.0 Released — Big upgrades to DataTable, new Layout Manager, Flickr-style multi-file Uploader, and more: „

The YUI Team just released version 2.5.0 of the library. We’ve added six new components — Layout Manager, Uploader (multi-file upload engine combining Flash and JavaScript), Resize Utility, ImageCropper, Cookie Utility and a ProfilerViewer Control that works in tandem with the YUI Profiler. This release also contains major improvements to the DataTable Control and new Dual-Thumb Slider functionality in the Slider Control. Here are the highlights:

  • DataTable Control: Jenny Han Donnelly has been joined by Luke Smith for this development cycle, and we’re all thrilled with what they’ve produced. DataTable in 2.5.0 gets a more robust markup structure that allows greater control over all aspects of the table. This release also includes major performance enhancements, improvements to the fixed-header implementation for vertical scrolling, built-in support for horizontal scrollling, an all-new Paginator class, support for drag-and-drop column reordering, and a new set of column APIs with hooks for showing, hiding, adding and removing columns.
    The DataTable and its new show/hide column interface.
    DataTable has been one of YUI’s most popular and important components since its debut, and this is its strongest release yet. If you have existing DataTable implementations that you want to upgrade, take a look at the new User’s Guide, as it has some detailed notes about API changes. The DataTable examples roster is another nice place to check out the new code in action.
  • The YUI Layout ManagerLayout Manager: Dav Glass has a lot for you to enjoy in 2.5.0, but top billing goes to his new Layout Manager. Layout Manager eases development of multipane UIs that take up either the full viewport or the full canvas of any block-level element. Layout Units within a layout are resizeable, collapsible, removable and swappable; transitions between expanded and collapsed states have built-in animation support. Whether you’re creating a full-screen application like Yahoo! Mail or a rich multi-pane pop-up, Layout Manager is a great place to start.
  • Uploader: If you’ve ever built a UI for uploading files via a browser, you know what the big pain points are: One file at a time, no easy way to track upload progress, no programmatic access to file metadata, etc. The new YUI Uploader addresses these issues and others, allowing for the creation of more powerful, intuitive, and responsive file upload experiences. Allen Rabinovich of the ASTRA Library team did the legwork on this one, and it’s the same code that underlies the Flickr Uploader. Uploader is our second JavaScript/Flash hybrid control (following on the heels of the Charts Control in 2.4.0).
    The YUI Uploader is the same code that drives Flickr's multi-file photo uploading interface.
  • Resize Utility: Layout Manager is built upon a new YUI utility, Resize. Dav’s Resize Utility formalizes the support that YUI Drag & Drop has long provided in example form and makes it easier for you to make any block-level element resizeable. Resizing can be implemented directly (the resized element resizes in real time during the interaction) or by proxy (a proxy element visualizes the interaction until its conclusion, at which time the resized element snaps to its new size).
  • The YUI ImageCropper ControlImageCropper Control: The Resize Utility makes a lot of things easier — and one of those is the implementation of an ImageCropper interface, which Dav built out on top of Resize for 2.5.0. Take a look at the examples and be sure to check out the support Dav provided for modifier keys in this very desktop-like UI control.
  • Cookie Utility: When he’s not busy writing books or working on My Yahoo!, Nicholas C. Zakas is cranking out new code for YUI. In 2.5.0, he contributes the Cookie Utility, a simple but powerful component that helps you get maximum mileage out of your limited cookie space. Because browsers limit the number of cookies you can set per domain (and because that limitation can sneak up on you if you manage a large site with many subdomains), the Cookie Utility supports ’sub-cookies.‘ Sub-cookies pack multiple name-value pairs under the umbrella of a single cookie, expanding the number of data points that you can store in cookie space.
  • ProfilerViewer Control: 2.4.0 saw the release of Nicholas’s Profiler, a headless, cross-browser kit for profiling JavaScript functions. To make it easier to access and interpret the data that Profiler collects, we’ve added a ProfilerViewer Control in 2.5.0 that sits on top of Profiler and visulizes its accrued data. ProfilerViewer leverages the Charts Control and the DataTable Control. Taken together, Profiler and ProfilerViewer provide another arrow in the development quiver that includes tools like Firebug’s integrated profiling interface.

    The ProfilerViewer interface.

  • The YUI Slider Control now has dual-thumb support.Slider Control with Dual Thumb Support: Supporting dual-thumb interactions in our Slider Control has been on our list for awhile, and Luke took the opportunity to get this out to you in 2.5.0. Sliders are ‘finite range controls’; dual-thumb sliders allow you specify a sub-range within the control’s larger range. The classic use case for dual-thumb sliders is on shopping sites, where such controls can allow users to filter results based on price range. Check out the User’s Guide, example, and the new Slider Cheatsheet (which has a second page dedicated to dual-thumb implementations).
  • We’re using this release to promote the following components from beta to GA status: ColorPicker Control, Get Utility (for cross-domain, dynamic loading of script and CSS files), JSON Utility, ImageLoader Utility, and YUI Test Utility. These promotions reflect the maturity of those components and their very low bug traffic. As always, we’re releasing all new-for-2.5.0 components under the beta moniker, and we’re looking forward to your feedback on those once you get a chance to try them out.
  • Full details on the release, including a rollup of the changelog for all components and a bug/feature manifest, are available in Georgiann Puckett’s update to the YUI developer forum this morning.

One More Thing…

YUI now ships with more than 270 examples, many of which are accompanied by full tutorials to help you get started using YUI. And while individual examples are good, we’ve gotten a number of requests to create an über example, one that pulls in and makes use of a wide range of YUI components in a single sample application — while still being YUI-centric and not littered with noisy implementation logic.

The incomparably prolific Dav Glass rose to the challenge for 2.5.0 with a complex, multi-component example that uses Layout Manager as its basis and Yahoo Mail as its inspiration.

Dav Glass's multi-module YUI application example.

Let’s Celebrate!

We’re excited to get 2.5.0 out the door and, as luck would have it, we’ve got a fantastic excuse to celebrate. YUI’s (and the Yahoo Pattern Library’s) second anniversary party is coming up next week (February 26, 5 p.m., Sunnyvale), and we’d love to have you join us. Sign up on Upcoming to let us know you’ll be stopping by at Yahoo! HQ for some beer and general revelry. We look forward to showing off some of the stuff you all have been doing with YUI in the past two years and we’ll talk a bit about where Patterns and YUI are headed from here.

(Via Yahoo! User Interface Blog.)

Internet Explorer 8 führt neues Meta-Tag ein

»Die Entwickler des Internet Explorer 8 um Chris Wilson haben zusammen mit dem Web Standards Project (WaSP) einen neuen HTML-Header entworfen, mit dem eine Webseite angeben kann, zu welchen Browserversionen sie kompatibel ist. Ein Hinweis wie:

<meta http-equiv="X-UA-Compatible" content="IE=8" />

soll dem Client künftig signalisieren, dass die Seite unter dem betreffenden Browser korrekt gerendert wurde. Falls möglich, kann der Client dann seine Darstellung den jeweiligen Eigenheiten des spezifizierten Browsers annähern. Es wird auch möglich sein, mehrere Browser zu nennen (zum Beispiel „IE=8;FF=3“) oder den Header per HTTP zu setzen.

Das Tag soll das Problem lösen, dass künftige Browserversionen möglicherweise Webseiten anders darstellen werden als aktuelle, was die Zukunftssicherheit von Webseiten gefährde, so WaSP und das IE-Team. Es soll das bis jetzt praktizierte Doctype-Umschalten ablösen, bei dem ein Webdesigner durch Setzen eines standardkonformen Doctypes bestimmt, ob der Browser den standardkonformen oder den rückwärtskompatiblen „Quirksmode“ wählen soll; die Grenzen dieses Doctype-Umschaltens hätten sich bei der Einführung von Internet Explorer 7 gezeigt, als plötzlich zahlreiche Websites nicht mehr wie gewünscht angezeigt wurden, obwohl sie diese Methode nutzten.

Kritische Stimmen meldeten sich sofort in großer Zahl zu Wort; tatsächlich erinnert das Tag an die weitgehend vergangenen „optimiert für …“-Hinweise oder an die Versuche, verschiedenen Browsern verschiedene Versionen der Website zu präsentieren. Allerdings weisen Webstandard-Experten wie Peter-Paul Koch von Quirksmode.org und die CSS-Autorität Eric Meyer (der zugunsten des X-UA-Compatible-Headers Stellung bezogen hat) darauf hin, dass der Vergleich unzutreffend sei. Dennoch drohen nach Meinung vieler Kommentatoren dem Web und den Browserentwicklern durch die Einführung dieses Tags kaum beseitigbare Altlasten, die eine Orientierung an zukunftssicheren Webstandards statt an Browsereigenheiten hätte verhindern können. Ob andere Browserhersteller den X-UA-Compatible-Header auch auswerten wollen, ist derzeit noch offen.« (via heise.de)

Introducing xdebug

Introducing xdebug: „This article is the first installment of a five-part series of articles covering xdebug, a free and open source swiss army knife tool for PHP developers. xdebug is a PHP extension created by Derick Rethans, one of the PHP core developers. This week, we will show you how to install xdebug and introduce you to some of the basic features. In the subsequent parts of this article series, we will have a closer look at one of xdebug’s main features, namely tracing, profiling, debugging, and code coverage.

(Via Zend Developer Zone.)

OpenID 2.0 ist fertig

OpenID 2.0 ist fertig: „OpenID erlaubt es Nutzern, sich mit einer URL bei verschiedenen Websites zu authentifizieren statt jeweils einen eigenen Login-Namen und Passwort festzulegen. Dabei handelt es sich bei OpenID um einen offenen Standard, der dezentral umgesetzt wird, so dass z.B. auch das eigene Blog oder der vorhandene Account bei einem Internet-Provider zur Authentifizierung genutzt werden können. Die Version 2.0 der Spezifikation unterstützt unter anderem Directed Identity. Statt ihrer OpenID müssen Nutzer damit zur Authentifizierung auf einer Website nur noch ihren OpenID-Provider angeben, was die Nutzung vereinfachen und Sicherheit verbessern soll. (OpenID)“

(Via Golem.de.)

In All Fairness … Internet Explorer Still Stinks

In All Fairness … Internet Explorer Still Stinks: „

This is the story of how SitePoint tried to give Internet Explorer a fighting chance … and it lost anyway.

If you’ve been paying attention, you’ll have caught the subtle (and not-so-subtle) hints that SitePoint has been quietly working on a series of references, beginning with The Ultimate CSS Reference.

position property sneak peek

What hasn’t been revealed (until now) is that this reference will be released not just as a slick SitePoint book, but also as a freely-accessible Reference section right here on sitepoint.com! Our aim with this project is to produce the definitive CSS reference, both on the Web and in print.

Obviously, a big part of assembling this reference has been compiling browser compatibility information. And although our hard-working authors might disagree, one of the trickiest parts of the project has been determining how that information should be presented.

The Inherit Issue

A good example of this is the inherit value, which according to the spec is supported by all CSS properties. A little over a year ago, David Hammond’s site that rates browser standards compliance generated an uproar on Chris Wilson’s blog when it counted the lack of support for inherit as a point against IE for each and every CSS property.

Our reference will similarly indicate the level of support for each property in each of the major browsers, but what level of support do we indicate for IE, which doesn’t support the inherit value? Do we count this as a failing in IE’s support for each and every property, or do we set that aside as a single unsupported feature, and rate IE’s support of properties in the absence of inherit?

On the one hand, declaring that IE fully supports a property when one of its supported values doesn’t work could be seen as misleading. On the other hand, if the best support level we can list for any property in IE is ‘partial’, then you can’t tell at a glance when IE does fully support a property (within the limitations of its CSS implementation), and our reference becomes that much less useful.

After lengthy discussion with the authors, we decided to treat inherit as a separate unsupported feature, and to list properties that would work perfectly in IE if not for inherit as fully supported. The vote was certainly not unanimous, but I felt like we were doing the right thing by IE—giving the work that Microsoft did in IE7 a chance to shine.

Except … it didn’t

position property compatibility table

In ignoring inherit when rating property support, our intention was to enable the many newly-supported CSS features in IE7 to show up in our compatibility tables.

After all, IE7 now supports position: fixed across all elements, completing (except for inherit, of course) support for that property. And IE7 introduced plenty of other new features, such as support for the child selector (>). It would be nice for our compatibility tables to reflect this, we thought—naively, as it turns out.

Once the authors had compiled all this compatibility information, what we discovered was that arguing about the difference between ‘partial’ and ‘full’ support in IE had been an academic exercise … because the vast majority of CSS features are too buggy in IE to rate either!

The position property does support fixed in IE7, but setting this property to anything but static causes that browser to mess up the stacking of overlapping elements by incorrectly establishing a new ’stacking context’, so we are forced to rate this property as ‘buggy’.

child selector compatibility table

And Microsoft did implement the child selector as a brand new feature in IE7, but even in this golden age of standards, this new feature came with obvious parsing bugs (e.g. A > /* comment */ B will fail to work).

After racking my brains for a CSS feature that would have newly achieved ‘full’ support in IE7 without being afflicted by bugs, I happened upon the dimension properties. width and height had serious bugs fixed in IE7, and IE7 added support for min-height, max-height, min-width, and max-width. And as of the current draft of our CSS reference, these properties are listed with ‘full’ support in IE7! Hooray!

Sadly, a little research has revealed reports of a bug in IE7 that affects all of these properties. We have yet to confirm this bug, but if it’s the kind of thing that will impact real-world use of these properties, they’ll lose their ‘full’ rating as well.

Internet Explorer Still Stinks

All this adds up to Internet Explorer making a very poor showing in our compatibility tables, despite us going out of our way to give it a fighting chance.

CSS features that we can honestly list as having ‘full’ or even ‘partial’ support in IE are few and far between (color is one, font-size is not). Most of them are ‘buggy’, even in IE7 … and we expect even more IE bugs to come out of the woodwork once we release the Web version of the reference for public comment.

Obviously, with IE7 Microsoft made great strides in correcting the most glaring and painful issues that plagued developers in IE6. But the unavoidable truth revealed by this reference is that Internet Explorer is still miles behind the competition.

Perhaps the new layout engine and other improvements coming in IE.Next will make up some of the difference … or perhaps Microsoft just isn’t interested in fixing (and in the case of IE7, avoiding) bugs that aren’t painfully obvious.

This article provided by sitepoint.com.

(Via SitePoint Blogs.)