The navigator object has been added to the worker scope. It contains the following strings that identify the browser, just as from normal script:
appName
appVersion
platform
userAgent
Workers can now be forcefully killed via the terminate function. Calling this function on a worker will immediately stop the worker’s execution.
Workers may only be created from a worker script that is hosted within the same origin as the parent page.
URIs for subworker scripts and imported scripts are now resolved relative to the parent worker script location instead of the owning page.
Error handling has been reworked according to recent spec changes. A worker script can now define an onerror handler that will be called with an error event with details about the exception. If the handler calls preventDefault on the event object then nothing else happens. If preventDefault is not called then the error event propagates to the parent scope’s (either a worker or the parent page) onerror handler.
Numbers, booleans, and even objects may be passed to postMessage in addition to strings. The only restriction is that objects may not contain functions or cyclical references (since we use JSON under the hood). This simplifies previous code that needed to use the JSON object to manually encode/decode the strings passed to postMessage.
Few web developers truly understand what triggers the long-running script dialog in various browsers, including myself. So I decided to sit down and figure out under what circumstances you’ll see this dialog. There are basically two different ways of determining that a script is long-running. First is by tracking how many statements have been executed and second is by timing how long the script takes to execute. Not surprisingly, the approach each browser takes is slightly different.
He finds that Internet Explorer's warning is based on total statements executed (5 million, and since it's Windows, you can change it via the Registry), Firefox and Safari time the actual script time (10 and 5 seconds, respectively), Chrome is a bit of a mystery, and Opera doesn't appear to have such a mechanism (and interestingly, appears to put its UI on a different thread than page rendering / script execution).
Regardless of the details, the lesson remains the same (again quoting from Nicholas' post):
Brendan Eich, creator of JavaScript, is quoted as saying, “[JavaScript] that executes in whole seconds is probably doing something wrong…” My personal threshold is actually much smaller: no script should take longer than 100ms to execute on any browser at any time. If it takes any longer than that, the processing must be split up into smaller chunks.
At a New Years Eve party, a friend help up a drink and toasted to his company deciding to discontinue direct support of IE 6 in 2009, and letting users know that the site may work better with IE 7 or another latest browser.
Still far too high a percentage and enough to make you grown. Also, the last few pounds are the hardest to lose. The good news for me is that on most Web applications that I personally work, and definitely those that I work on in early 2009 will have much different numbers.
Maybe IE 8, Windows 7, and the great new browser war will help, or maybe some percentage is for lost computer souls.
John Resig has laid out his thoughts on a Web Developer's Responsibility, and it comes down to working with various up and coming browser versions and filing bugs:
It's safe to say that the biggest tax on a web developer is spending so much time dealing with browser bugs and incompatibilities. Thus it has become the favorite past-time of all web developers to complain about having to deal with them. Browser bugs are annoying, frustrating, and make your job incredibly difficult.
Because browser bugs are so frustrating and such a burden on top of normal development it should be the responsibility of every web developer to make sure that the browsers they develop for are able to find and fix their bugs. By taking responsibility for the bugs that you find - and to not assume that "someone else will find it" - will accelerate the rate at which browsers can improve.
The solution to helping browsers is two-fold: 1) Every time you find a browser bug, file a bug report to the respective browser. 2) Actively test your sites in the latest builds of the major browsers.
The vast majority of web developers have never filed a bug report with a browser vendor - or even used a nightly version of a browser - which is a shame. If you think about it there are few who are more qualified to assess what is going wrong in a browser than those who spend every day developing for them.
I'm especially surprised when I see professional developers not filing bugs with browsers, or testing on nightlies. Since one of the primary tasks of most developers is to paper over cross-browser issues it becomes in their best interest to see the number of bugs reduced (and making their job dramatically simpler).
Now, instead of just saying "go do it", John gives information on how to file a bug, where to go to do it, providing a good simple test case, and arguing for a bug.
He then shows examples of bugs that he has filed across browsers, and asks us all to wear them like badges.
So, got any badges? Been frustrated when filing a bug? What's the weirdest bug you have ever seen (sorry, interview question there).
I have had some folks talk to me about responsiveness issues with Firefox 3. I have had a fantastic experience, and currently I run Mozilla nightlies / Minefield / Shiretoka (3.1.*) and WebKit nightlies side by side. I am very happy with the shape that Minefield is in.
Of course, the issue with the extension mechanism with Firefox is that you get a window to the entire world (which has also been a reason that lead to amazing add-ons). Since this is the case a bad add-on can do a lot.
Chrome does a good job showing you basic info about a tab (memory etc). What if we did that and more for add-ons. Give me top for the browser.
Now, this is a lot of engineering away, so can we use the crowd to help out?
What if we created an add-on that would track responsiveness information and send it back (anonymously) to the cloud (say, to Weave). We could use math to work out probable culprits and could even ship that information back to the people using the add-on. Thus, you would then find out that FooAddOn seems to be a culprit that slows down the browser. Maybe it could be called Vacinate-addon.
Then I got talking with Dav Glass who is working on a very interesting proof of concept BrowserPlus Profiler:
A service that analyzes the memory and cpu usage of a web browser. The service can take 1 sample or multiple samples at a specified interval. When sampling at intervals, at most 1,000 samples are taken. If you provide a callback function, your javascript will be called after every sample is taken. If no callback is provided, all samples are stored in an array and returned after start() completes or stop() is called.
The sample object is a map with the following keys (most values are floats):
[sample] - the sample number (1-1,000)
[time] - the string representation of the time the sample was taken
[sys] - the percentage CPU "sys" processes are using
[user] - the percentage CPU "user" processes are using
[ffxcpu] - the percentage CPU Firefox is using, or -1.0 if it is not running
[ffxmem] - the amout of memory Firefox is using, or -1.0 if it is not running
[safcpu] - the percentage CPU Safari is using, or -1.0 if it is not running
[safmem] - the amout of memory Safari is using, or -1.0 if it is not running
This is very early stage, and they are looking for good people and ideas on how t get good data across platforms (browsers and operating systems). I would love to see this.
Peter Nederlof just released version 3 of whatever:hover, his library that makes sure that :hover works just fine for the IE browsers out there.
The new version is faster, better documented, uses a CSS trick with expressions in IE to trigger the hover events in IE and now has Ajax support! (this means that new items added to the DOM after loading will also be affected by whatever:hover.
How does it work?
All browsers provide some way to look at a stylesheet's rules using javascript, and dynamically insert new rules. Normally, IE returns "unknown" for anything it does not support, for instance; a "div p:first-child" would change into "div p:unknown", and a "p a[href]" would be returned as "UNKNOWN" altogether. Fortunately IE recognizes :hover as something it's familiar with, and leaves it alone.
IE also supports so called behaviors; both predefined functionality like dynamic content loading or persistent data storage, as well as custom behaviors that you can build into an .htc or .hta file. These behaviors are linked to html nodes via css, and "enhance" the nodes that are selected by a rule's selector with the given behavior.
Combining the above, it should be possible to create a bahavior that searches the styles for rules IE doens't support, and trick affected elements into applying the associated styles some other way. The steps involved in this are something like:
Search all stylesheets for :hover rules IE doesn't support,
Insert a new rule IE does support, like one with class names,
and finally, set up script events for switching class names.
This way, :hover, :active and :focus can be supported, and as a developer you don't have to do anything except including the behavior. Everything else runs on full automatic.
Unlike versions 1 and 2, version 3 also supports dynamically added html (ajax). The difference is that 1 and 2 actively searched for affected elements onload of the page (so; only once), whereas 3 uses expressions to let nodes do a callback themselves. Read the commented version for more details on this.
Lloyd Hilalel and the Yahoo! BrowserPlus team have released a BrowserPlus SDK which allows you to easily create your own services:
We're extremely happy to announce the availability of the BrowserPlus SDK. This first SDK and the accompanying documentation gives you all the tools you'll need to start extending the web using BrowserPlus. Getting started is easy, you can hop over to our tutorial and write your first service in about 15 minutes.
In addition to the SDK, we've pushed a new platform version, 2.1.14, that fixes several bugs reported by all of you. We deeply appreciate your continued contributions and hope with the SDK and our ongoing process of open sourcing BrowserPlus we'll empower you to contribute even more to the project.
class MyGreatServiceInstance
def initialize(context)
end
def HelloWorld(transaction, args)
transaction.complete("Hello #{args['who']} from my great service!")
end
end
rubyCoreletDefinition = {
'class' => "MyGreatServiceInstance",
'name' => "MyGreatService",
'major_version' => 0,
'minor_version' => 0,
'micro_version' => 1,
'documentation' => 'A GREAT service.',
'functions' =>
[
{
'name' => 'HelloWorld',
'documentation' => "Say \"hello\" to the world",
'arguments' => [
{
'name' => 'who',
'type' => 'string',
'documentation' => 'who you want to say hello to',
'required' => true
}
]
}
]
}
There is also a new service released:
Welcome the new Zipper service to our collection! A big problem with some web apps today is being able to efficiently attach all file types. Zipper plays nicely with Uploader and lets you compress files or folders on the client before uploading them. This service should be considered alpha, and we look forward to your feedback and ideas on how to make this more useful. We've got lots of ideas of which way to take this service (lzma being first and foremost), but would love to hear your thoughts.
We desperately want users to upgrade to the latest and greatest. A prominent and respected Web citizen recently said "With Ajax we are developing to 1997 technology, and are restricted by IE 6." What if you didn't have that nagging feeling, and instead could use the platform that sits below the clients of modern browsers? You could do a hell of a lot more.
Some are arguing over how easy or hard it is to get safe (run some regedit really OK?) but scary it is. Other folks can't gloat though, as who know what the hackers will find next. But, for now, we may get a few switchers. Maybe the IT guys who made the call to write ActiveX components back in the day will finally get a kick up the backside and move over? The end users? Hmm, I wonder how many are paying any attention versus clicking on the big "Internet" button and doing their thing.
Snuck over this post about getting better discoverability into the browser from me personal blog
Greasemonkey and Fluid userscripts. AIR and the newTitanium apps. Browser add-ons. When you go to a website do you know if you are getting the best experience for you? You could search for script on userscripts, or Google for apps, but what if the developers of the sites had a way of pointing out that there were enhanced experiences for you?
This is where App Discover comes in. It is a Firefox add-on that notifies you of these very items. All the developer has to do is add a simple link tag to their page, and the add-on will find it for you.
For example, if Twitter added the following tag, you would be notified of TweetDeck:
That line would mean you would see this in the browser:
The type is a mime-type of course, and these are mapped into custom verbiage, but if you come up with something new... as long as the href is good, you should be golden.
I just added support for Appcelerator Titanium for example:
This is just a simple beginning of course. Where would we really want to go from here?
The current limitation is that it only really works well with one link tag (items get replaced)
I want to add preferences so the user can let the add-on know what they want to be alerted about (e.g. yes to Titanium apps and Greasemonkey scripts only!)
Be smart based on installation: E.g. if you don't have Fluid (and especially if not on a Mac), don't show it
Get social: "You have three friends who have installed TweetDeck". This requires the browser being smarter about your social graph, which I think is a natural progression.
It should be smarter and not bug you when you go back to the same page. That can be fixed via the AnnotationService.
That leads me to XUL. I tweeted how it can feel a little strange to look up XUL docs and see dates in the lower 2000s. You have this nagging feeling of "has something really not changed since them? Is there an new better way of doing this?" As @mfinkle pointed out, "XUL is stable."
The IE8 team let their partners know about a December "Partner Build" that contains the following changes since IE8b2:
Accessibility-ARIA
ARIA attribute names containing dashes, such as “aria-checked”, no longer have to be referenced by their camelCased equivalent (ariaChecked) in IE 7 Mode and Quirks Mode. As a consequence of this change, the camelCased syntax no longer exists for these attributes.
XDR now checks Access-Control-Allow-Origin header for specific URLs as well as wildcards.
Developer Tools
The Developer Tools now has a menu option to let the user choose the view source app. In IE7 the only choice was Notepad and in IE8 Beta 2, the built-in viewer was the only choice. Now users can choose Notepad, built-in viewer, or another application.
CSS
Syntactically valid filter declarations are applied in standards mode, even if unquoted Starting with IE8 Beta 1, the following filter declaration was not applied in standards mode:
For web applications supporting both IE7 and earlier as well as IE8 standards mode, this meant maintaining both declarations and possible a third for other browsers in the case of opacity.
Starting with IE8 Partner Build, the first declaration above will be applied in standards mode if and only if its syntax is valid. If it is not e.g. the final parenthesis is missing then the declaration will not be applied and our CSS parser fails per the standard.
CSS style sheet encoding detection complies with CSS 2.1 e.g. including @charset directive, charset attribute on link element etc.
Compatibility View List
Check box added in Tools->Compatibility View Settings to receive updates from Microsoft. At the moment, the functionality of this feature works but our list will not be activated until the next release of IE.
Filter Syntax Property
IE8 will accept the current filter syntax as well as the fully quoted syntax (“–ms” prefix) previously announced for IE8.
Links Bar
A new option allows users to put as many items on the Favorites bar as they want. The size of Links bar items can now be set to long (default), short (5 characters), or simply the favicon.
InPrivate Blocking
New InPrivate Blocking button on the status bar. This can be pressed to turn InPrivate Blocking on and off.
InPrivate Blocking now has a quick on/off entry in the Safety menu (or Ctrl-Shift-B).
The InPrivate Blocking on/off setting is now a session-specific option. InPrivate Blocking will be off by default each time users launch Internet Explorer.
InPrivate Blocking can now be turned on for all browsing sessions, not just InPrivate Browsing sessions.
UI Improvements to the InPrivate Blocking settings dialog.
New feature first-run dialog box.
InPrivate Subscriptions have been removed.
Add-ons are now disabled while in InPrivate Browsing.
Smart Address Bar
Increased number of typed addresses (up to 12 by default, up to 25 if History and Favorites are turned off).
Removed AutoComplete Suggestions.
Turned off Feeds by default. Feeds can be turned on through the AutoComplete Settings dialog in Tools->Internet Options->Content->AutoComplete Settings’.
That is the equation that Jeremy Keith shares with us on his article for this years 24ways. He is discussing IE6, which he sets to the variable of $web_designer_nemesis (variable used to equal NN4).
He looks at the sliding scale of support for the browser:
Block IE6 users from your site.
Develop with web standards and don’t spend any development time testing in IE6.
Use the Dean Edwards IE7 script to bootstrap CSS support in IE6.
Write an IE6 stylesheet to address layout issues.
Make your site look exactly the same in IE6 as in any other browser.
And, gives some weight behind what you may or may not want to do. We all keep running into the highs and lows of Web development. As we look to the amazing features that current gen browsers give us we think about apps we could build. Then we come back to reality as we think about getting these apps working on browsers that people use.
A smart man just told me:
The Ajax applications that we rave about now are running on 1997 technology. Take a look at what current browsers can do, and then you will get a glimpse of where we are going.
I want to see as many forces as possible trying their best to get IE 6 users to upgrade (again: to IE.latest is fine!). One way is to develop applications that have amazing functionality that they can't use unless they upgrade.
It actually now looks like Minefield (Firefox nightly) is getting 10 out of 11, and the other browsers are doing great too.
Jonas Sicking of Mozilla has a really nice comment that talks about what the engines are doing and some nuances. For example, if you have a CSS file and a JS file, do you block just in case the JS looks into CSS values (e.g. "in case there is a call to .offsetTop in the script"). How about looking ahead to see? That is the case. You can download away and try to do the right thing. document.write() is another beast that seems to do a lot of harm. Having the browser be smart about it ("they don't do that") will be good.
Back to John, he also discusses features that we can use as developers:
Prefetching
This is part of the HTML 5 specification and allows for pages to specify resources which should be opportunistically downloaded in case they should be used in the future (the common example of image rollovers could be used here).
There's a full page describing how to use them on the Mozilla developer wiki but it isn't that hard to get started. It's as simple as including a new link element in the top of your site:
And that resource will be downloaded preemptively.
Inline Images
The final case that the profiler tests for is the ability of a browser to support inline images using a data: URI. Data URIs give developers the ability to include the image data directly within the page itself. While this saves an extra HTTP request it's important to note that the resource will not be cached (at least not as external resource - it may be cached as part of the complete page). The use of this technique will vary on a case-by-case basis but having a browser support it is absolutely important.
The most exciting part of Adobe MAX last week was a service that was announced by Paul Gubbay at the "Sneaks" session that shows cool tech that Adobe folk are working on. His (very early stage) service is called Meer Meer and it is genuinely useful.
You can plugin a URL and the system will render that page on a server farm (many browsers, cross OS) and show you the results. It can visually layer these results so you can see the differences. It was awesome.
I pinged Paul and had a nice conversation with him about the project:
Can you explain what Meer Meer is, and where you got the inspiration?
Meer Meer is the code name for a new hosted service that allows Web Pros to view their content on a variety of different browsers and operating systems without requiring them to install anything other than the standard Flash Player. The inspiration is easy. We spend a lot of time with our customers and cross-browser compatibility consistently comes up as the #1 issue unprompted. It’s a real pain and we wanted to help solve it.
What browsers and OSes are supported? This means I don't have to kick up VMWare to test in IE 6 now right? ;)
IE6 is covered :) We haven’t finalized the complete set yet but we’re committed to supporting the top browsers for Windows and Mac. We expect that mix to change over time as new browsers/versions gain market share.
What are the various views and features?
We’ve really focused on how users tweak/debug their CSS today and engineered the service to fit into that workflow. One of the unique features for Meer Meer is that it can work directly with your local content if you are using Dreamweaver. This is a big benefit as users can tweak CSS and hit the refresh button to get an immediate representation of the page on their target browsers. No need to save, publish to a public location and then view. In addition, we’ve focused on several views (1-up, side by side and onion skin).
Onion skin is the most interesting as it overlays two browser shots over each other and provides the user with complete control over the transparency. This view typically gets the big oohs and aahs :)
Can you talk about the high level implementation? I assume you have a server farm on the back end and you are rendering and sending back images of the rendered image?
That’s correct. In addition we’re using a Flex application as the client. This makes the application feel very snappy and respond like a desktop application without the need to install anything. The team has also done some great work to establish a local connection with Dreamweaver to work with local content. When you make a change to your code and switch back to Meer Meer it knows you’ve made a change and prompts you to refresh. You can choose to refresh from within Dreamweaver and a panel will update and show you the status of the screenshot retrieval in real time.
In Dreamweaver CS4 you showed taking an Ajax app, clicking around to change state, freezing the page and then sending it to Meer Meer. Can you talk more about the freezing feature and other things that you can do?
I’m really proud to be associated with this release of DW CS4. We’ve definitely pushed the envelope. Our new Live View leverages the WebKit rendering engine to provide users with a true browser experience directly within the product. This means that you can see and interact with dynamic content such as Ajax UI widgets. Furthermore, we’ve included the ability to see the Live Code that the browser generates as you interact with the page. Users can freeze JavaScript to get the page into different states and then use the new Code Navigator to jump directly to the CSS that effects the element they select. This is an added bonus for Meer Meer because we can place the page into different states, such as selecting the second pane of an Accordion widget, and then view the page in that state within Meer Meer. Other browser compatibility services simply can’t do this.
Any final thoughts on Meer Meer or other Web Pro services coming from Adobe?
We’re really excited about the future of desktop + services at Adobe. Meer Meer is a great example of what we can accomplish when we take a holistic view to solving a user challenge. We’re also very interested in extending the capabilities of our users by providing them with turn-key hosted solutions that allow them to grow their business. Content maintenance follows very closely on the heels of browser compatibility as a top challenge that our users face today. Our new InContext Editing service that is now in free preview on Adobe labs allows Web Pros to provide content editing capabilities directly within the browser to their end user. No programming required.
We look forward to hearing feedback from the community on these services to help guide our future direction.
This is an exciting server from Adobe, and shows that focusing on the Flash issue isn't the entire story. They have a lot to offer the Open Web if we look to the right places and we can continue to fight for more too :) If we support projects like Meer Meer we can make our voice heard.
Of course, this is just the beginning. I would love to see an API to the service which would allow any developer tools to mashup nicely with the service. You can also imagine actively analyzing the code to not only point out the diff in the image, but the issue in the code. When we get there, we will be in a very good place indeed :)
There were some other cool things from MAX that showed up in Labs:
Alchemy: A research project that allows users to compile C and C++ code into ActionScript libraries (AVM2).
Austin Chau and I are here on the Yahoo campus for the Yahoo BrowserPlus release party. I'm going to blog the event as it happens here (Disclosure: I work for Google with the Open Web Advocacy and Gears teams).
First, Ernest Delgado, Canvas whiz here at Yahoo, sent me a cool demo showing a prototype he and Michael Johnston made of Yahoo Maps and Flickr integrating with Yahoo BrowserPlus using the native gyroscope on Macs. You just hit the side of the laptop, for example, in order to jump to the next Flickr picture, or tip your laptop to zoom around a Yahoo Map:
* Starts with some really nice demos of things you can create in the browser using YUI.
* Underlying technologies driving browsers are very complicated.
* About 7 knowledge areas needed for web development -- each is different than the standard, with bugs and specialized expert knowledge. You get about 672 different permutations of things needed for you to know and test on.
* YUI focused on "A-grade browser support".
* Good to target toolkits like YUI, since it helps you be future-compatible when new browsers appear like iPhone and Google Chrome
* Goal of YUI: Have a sophisticated widget like a rich text editor work cross-browser using just a snippet small snippet of code.
* Also want things to be automatically accessible.
* Progressive enhancement should be easy and possible, showing a cool demo of hierarchical menus still being readable on Lynx, a version of Firefox with no JavaScript, and then a full IE with CSS and JavaScript on.
* YUI is ala carte, file sizes are small, between 15 and 30K for any given component (including gziped)
* Deployed at Yahoo for three years, on every major property, 400 million users/browsers consuming YUI every month. In properties like Flickr and on the front page, well tested.
* YUI in lots of places: iGoogle, Wall Street Journal, Mozilla, LinkedIn, Southwest.com, Obama website, more
* ~1,000,000 external downloads
Now Lloyd Hilaiel is getting up to present on Yahoo BrowserPlus, the focus of today's event:
* The teams motivations: people get browsers -- browsers could be so much more -- plugins aren't working! Takes too long for new innovations to propagate (5-7 years)!
* Non-goals: no fixing web UI, no web outside the web (like AIR or Mozilla Prism), no improving JavaScript (that's the domain of YUI, JQuery, Dojo, etc.)
* YES to new web features with low overhead. Low overhead: low intellectual overhead, low overhead to
