Instead of doing an each loop on a JSON file containing a list of SQL statments and passing them one at a time, is it possible with Safari client side storage to simply wrap the data in "BEGIN TRANSACTION" / "COMMIT TRANSACTION" and pass that to the database system in a single call? Looping 1,000+ statements takes too much time.
Currently iterating one transaction at a time:
$j.getJSON("update1.json",
function(data){
$j.each(data, function(i,item){
testDB.transaction(
function (transaction) {
transaction.executeSql(data[i], [], nullDataHandler, errorHandler);
}
);
});
});
Trying to figure out how to make just one call:
$j.getJSON("update1.json",
function(data){
testDB.transaction(
function (transaction) {
transaction.executeSql(data, [], nullDataHandler, errorHandler);
}
);
});
Has anybody tried this yet and succeeded?
I was asked today by a senior developer which doctype I'd use if I was going to write something (personal / non-commercial) for the open web.
I responded, <!doctype html>, to which I was greeted with a look of shock, horror and surprise and then asked to explain myself.
To my mind, it's a good candidate because current browsers (IE, FF, Opera, Safari) will look at it and switch the content into standards mode - even though they don't implement HTML5. If I want to actually take advantage of HTML5 elements, I can use some javascript to create a reference to those tags not recognised by, say, IE (e.g. document.createElement('article');) and then work with them as if they were native parts of the DOM.
Was this really such a bad answer? What would you have answered and why?
I planned to post this way earlier but travel, jetlag, and a general feel that the entry was not quite finished got in the way. It seems to slow process on posting other things though so here it is.
I was somewhat disappointed by the lack of fights. The W3C did their part by providing us with popcorn and nachos, but none of the discussions about accessibility, distributed extensibility, extensions to host objects that cannot be implemented by ECMAScript directly, a language specification for HTML, et cetera went beyond polite discourse. Boring!
It is pretty clear we are reaching the end of the process. The specification no longer has major holes and the remaining issues are around differences of perspective on how certain issues need to be tackled. Of course, if at one point we decide to go the other way on one of these the outcome may be disruptive, but it does not seem all that likely.
The HTML WG did run again in unconference-style and the only thing I think we should here is gauge the level of interest in certain topics before giving them a one or half an hour slot. If there is just one person talking all the time it is not that interesting and we might as well have read an email outlining his position at some other point.
I need to be able to run HTML forms offline. I mean they have to work without direct connection to the web server.
In an application I wrote over 5 years ago I did it by implementing a custom protocol handler - when a user initiated form submit the resulting HTTP request was recorded locally. At later time when a connection to the server becomes available a synchronization program loops through collected requests and submits them to the server collects the responses and again saves them locally for later use.
That was then. Now another customer approached me with a very similar request. What technology do you guys think I should use today?
Support for HTML5 is very limited just yet. Google gears? Or should I go back and continue using the protocol handler and custom synchronizer?
I'd like to know if there is a way to dynamically modify/access the data contained in html images just as if they were an html5 canvas element. With canvas, you can in javascript access the raw pixel data with getImageData() and putImageData(), but I have thus far been not able to figure out how to do this with images.
This morning the Mozilla community released Firefox 3.6 Beta 4, making it available for free download and issuing an update for all Firefox 3.6 beta users. This update contains over 100 fixes from the last Firefox 3.6 beta, containing many improvements for web developers, Add-on developers, and users. Almost 70% of the thousands of Firefox Add-ons have now been upgraded by their authors to be compatible with Firefox 3.6 Beta. If your favorite Add-on isn’t yet compatible, you can also download and install the Add-on Compatibility Reporter – your favorite Add-on author will appreciate it!
The Mozilla community appreciates your feedback and assistance in testing this preview of the next version of Firefox. Your beta software will update itself periodically, and eventually will be updated to the final release itself.
The Beta of Firefox 3.6 / Gecko 1.9.2 introduces several new features for users to evaluate:
Web developers and Add-on developers should read more detail about the many new features in Firefox 3.6 for developers on the Mozilla Developer Center. For the full list of changes since the alpha release of Firefox 3.6 see this list (it’s big).
Please use the following links to download Firefox 3.6 Beta, or visit the beta download page:
As always, the Mozilla community would appreciate hearing about any feedback you have about this release, or any bugs you may find.
Last weekend, Slashdot linked to an article that observed that Netscape had removed the RSS 0.91 DTD. Netscape quickly restored the resource on a temporary basis. I hope this episode has a silver lining and helps in making people realize that DTDs don’t belong on the Web.
My initial thought was “Wow people are actually using XML parsers with RSS” and next “but don’t have to good sense to disable the processing of external entities”. It has been interesting to observe how different people react to story. I think Netscape’s position that they want to get rid of the burden is actually quite reasonable, although the initial removal was obviously due to the New Netscape being ignorant about the activities of the Old Netscape.
There’s a lot of HTML and XHTML sample code out there that contains a doctype that points to a DTD on www.w3.org. The illusion that this somehow “works” is based on browsers not actually retrieving the referenced DTDs. This is why www.w3.org doesn’t melt down under a massive ongoing distributed denial of service attack. This is also why the Web keeps working when there is a power outage at MIT and www.w3.org is temporarily unreachable. (Update: www.w3.org is under a massive DDoS attack all the time—but not from browsers. Interestingly, the questions raised by the W3C Systeam don’t include “Should we admit that DTDs are a bad idea and we should get rid of them?” Update: Microsoft issues updates for various versions of MSXML to avoid parsing failure due to www.w3.org banning the IP address of the host running MSXML.)
The RSS 0.91 DTD incident shows how bad an idea the remote DTD becomes when it is for real and not just an illusion maintained to keep the appearances. First, there’s a single point of failure. When the DTD became unavailable, apps around the world stopped working. Not good. Second, the RSS 0.91 DTD is retrieved over 4 million times per day. That’s nuts. Burdening a single third party like that for something as useless as a DTD makes no sense.
Although I now have a bit of a “told you so” feeling, when I was younger, I too thought that loading external entities is a problem that needs to be solved. I have gotten over it, though. The right way to fix the use of DTDs on the Web is not to use them on the producer side and not to resolve them on the consumer side.
If you are a spec writer for an XML vocabulary, please don’t specify a DTD for the vocabulary. Please suggest that implementations run their XML parsers with external entity resolution disabled. Please note, however, that banning the doctype like SOAP does (or otherwise subsetting XML) is improper in terms of spec layering.
If you are an implementor of a Web-facing XML-consuming app, please configure your XML parser not to perform DTD-based validation and not to resolve external entities. If, for legacy reasons, you must process some well-known DTDs, please make your entity resolver retrieve those DTDs from a local catalog. (For the internal subset, be sure to have protection against the Billion Laughs attack in place.)
If you publish XML files on the Web, please don’t include a
doctype. (This point is specifically not about text/html
content.)
Unfortunately, writing about this requires pre-emptively refuting all the usual misconceptions, so here goes:
The document won’t be “valid” in the sense of the term defined in XML 1.0, but this does not matter. Validity in the sense defined in XML 1.0 is dubious and overrated.
DTDs aren’t a particularly powerful validation formalism. Moreover, having the document declare its own grammar is worthless as far as the ability of a consumer to trust the document adhering to particular rules is concerned. RELAX NG validation takes two distinct inputs—the document and the schema—and the document cannot override the schema. In the RSS 0.91 case, the Feed Validator (that uses custom Python code instead of any schema formalism) does a much better job at checking the feed syntax than DTD-based validation would.
There’s not-so-great spec writing out there. You can try what happens if you don’t comply. ☺
For text/html content, yes,
but this isn’t about HTML. For documents served using an XML
content type, no.
Using the doctype as an indicator of the type of the document (what kind of document it is) is utterly bogus. Please don’t let the unfortunate name “doctype” or the HTML 4.01 spec fool you.
If a consuming application can handle multiple XML vocabularies, the right way to dispatch document to different handlers is to check the namespace of the root element. For vocabularies that aren’t in a namespace, the right way to dispatch is to look at the MIME type. Vocabularies that aren’t in a namespace and don’t have a vocabulary-specific MIME type are badly behaved and you have to dispatch on the root element name.
Yeah, unfortunately. Fortunately, WML 2.0 is not really that relevant to the Web. Opera and WebKit-based browsers are doing a good job obsoleting the concept of the “Mobile Web” and making WML a legacy footnote.
Ad hoc subsetting is wrong. Having different spec profiles is also bad in general, but the XML spec itself effectively defines three processing profiles:
Not performing DTD-based validation, not retrieving external entities.
Not performing DTD-based validation, retrieving external entities to perform infoset augmentation and entity reference expansion.
Performing DTD-based validation, retrieving external entities to perform infoset augmentation and entity reference expansion.
The whole point of having profiles is to allow apps to choose a suitable one. The creators of the XML spec made profile #1 for browsers. It would be crazy for Web-facing apps not to take the opportunity to avoid the DTD cruft when given the chance. In fact, the whole concept of well-formedness is there to support DTDlessness!
It is a done deal. Many people are just still in denial. Character entities (other than the 5 predefined ones) became unsafe for the Web when the XML 1.0 spec made them an optional feature (profile #1 above). On the Web, you can’t count on optional features (which is why it is a bad idea for Web-oriented specs to have optional features).
The situation is unfortunate, but this really is an input method problem between you and your editor. Fixing it in the wire format is the wrong place. However, if I had a chance go back in time and change XML 1.0, I’d define all the XHTML and MathML entities as predefined. But it is too late, because much of the value of XML is in interoperable off-the-shelf parsers and changing XML would break the interop (which is why XML 1.1 is such a bad idea). So you just need to figure out a better input method and use straight UTF-8.
I am aware of that. What Gecko does is dirty, should be fixed and definitely should not be encouraged.
You establish it by mutating the infoset reported by the XML processor based on some criteria related to element and attribute names and namespaces. An “xml:id processor” does this. A conceptually analogous “XHTML id processor” could be defined. (XHTML5 implies such a processing component.) Both can be implemented as SAX filters.
Ha ha. We’re out of frequent questions.
Trying to get my head around the new semantic elements in HTML5.
Does a <section> belong inside an <article> or is it the other way around? Does it even matter?
I'm looking at structuring a wordpress blog something like this:
Is this reasonable, or am I missing something?
Can the HTML 5 Canvas element be implemented in Flash to provide support for that element in older browsers?
« previous week | index | next week »
Firefox 3.0.16 / Firefox 3.5.6
Firefox 3.0.17 / Firefox 3.5.7
Firefox 3.6 Beta
Firefox 3.6 RC
See more Firefox 3.6 related blocker queries, or learn about the new status and blocker flags
(Progress reports every weekend on Planet Firefox)
Summmary
Activity
More
| feature | review date | who | interested |
|---|---|---|---|
| Windows TSF integration (1.9.2) | unscheduled | Jim Chen, roc | |
| DNS Prefetching | unscheduled | Patrick McManus | Jesse, bz, reed(?), ctalbert |
| New system metrics (and media queries) | unscheduled | ? | dbaron |
Session Cookie Policies
When working with the DOM .nodeName property there are two hard-and-fast rules that most people abide by:
<html> will result in a .nodeName === "HTML" (see the HTML 5 draft).<data> will result in a .nodeName === "data", <DATA> will result in a .nodeName === "DATA".Knowing these rules can be useful because it allows you to optimize your code. If you know that you're in an HTML document you can avoid having to upper/lowercase your .nodeName checks and you can just always assume that you're dealing with a .nodeName that's uppercase. This results in faster selectors for Internet Explorer and other minor optimizations.
However recently I've been running across two cases that've been especially problematic and have bucked the trend.
The first is for browsers that support the adoptNode/importNode DOM methods. These methods allow you to move (or clone) a node from one DOM document to another. In this way you can move an XML node from an XML document and insert it into an HTML document. Normally this shouldn't matter much but, as it turns out, the original .nodeName case sensitivity is preserved from the original XML-ness of the node.
Thus if you have a lowercase XML element (<data>) and you use adoptNode or importNode to bring it into your HTML document the result will be .nodeName === "data" -- which completely bucks the trend for "all HTML element's node names are always uppercase." I consider this to be a bug, considering that the DOM element is now in an HTML document, not in an XML document, and should behave as such.
The second bit of weirdness comes from people attempting to use the new elements from HTML 5 in browsers that don't support it. Most browsers behave perfectly well when using some of the new HTML 5 elements (in that they don't freak out and support some level of styling). For Internet Explorer you must use the HTML 5 Shim technique - this will give unknown HTML 5 elements the ability to be styled and hold contents (such as a <section> element).
However there is an additional gotcha: When Internet Explorer encounters an element that it doesn't recognize it leaves the .nodeName in its original case. Thus if you have a <section> element in your HTML page the result will be .nodeName === "section" -- which directly contradicts the normal case sensitivity of the .nodeName property in HTML documents.
To try and understand all of this I made a bunch of test cases using a number of doctypes and document styles.
The important part of the test page is quite simple:
and the test cases are as follows:
HTML
Accesses the HTML elements that were originally included the page (should be case insensitive).
HTML createElement
Creates new DOM elements using the same document as the page in which it was shipped (should be case insensitive).
innerHTML
Attempts to inject the elements using .innerHTML (should be case insensitive).
For the remaining tests I grab a simple XML document:
like so:
xhr.open("GET", "test.xml", false);
xhr.send(null);
var xml = xhr.responseXML;
XML
Test the elements in the XML document directly (should be case sensitive).
XML createElement
Same as the HTML createElement but done using the XML document (should be case sensitive).
HTML via importNode
This clones the nodes from the XML document, using importNode, and places them into the HTML document (should be case sensitive).
var nodes = xml.documentElement.childNodes, node;
for ( var i = 0; i < nodes.length; i++ ) {
node = document.importNode( nodes[i], false );
test.appendChild( node );
}
return test.childNodes;
});
HTML via adoptNode
This moves the nodes from the XML document, using adoptNode, and places them into the HTML document (should be case sensitive).
var nodes = xml.documentElement.childNodes, node;
while ( nodes.length ) {
node = document.adoptNode( nodes[0] );
test.appendChild( node );
}
return test.childNodes;
});
I ran the following tests in IE 6, IE 7, IE 8, Firefox 3.5, Safari 4.0.3, Chrome 3.0.195, and Opera 10.10. Additionally I tested against .tagName in addition to .nodeName and found no discernible difference (you can run your own .tagName tests by appending a ?tagName to any test URL like so.)
Note: The HTML 5, XHTML (served as HTML), and no-doctype pages all behaved identically to each other in every browser - thus I'm just going to not display the XHTML (as HTML) and no-doctype results as there wouldn't be anything interesting to show.
Firefox, Safari, and Chrome all yielded the same results here: Bringing in elements from an external document maintains the case sensitive nature of the .nodeName property - which is unexpected.
| <div> | <DIV> | <section> | <SECTION> | |
|---|---|---|---|---|
| HTML | DIV | DIV | SECTION | SECTION |
| HTML createElement | DIV | DIV | SECTION | SECTION |
| innerHTML | DIV | DIV | SECTION | SECTION |
| XML | div | DIV | section | SECTION |
| XML createElement | div | DIV | section | SECTION |
| HTML via importNode | div | DIV | section | SECTION |
| HTML via adoptNode | div | DIV | section | SECTION |
Internet Explorer fails in a different manner. To start, Internet Explorer doesn't support importNode or adoptNode so those particular tests simply don't run. However we can confirm that the case sensitivity of the unknown HTML 5 element is maintained in HTML, even though it shouldn't be.
| <div> | <DIV> | <section> | <SECTION> | |
|---|---|---|---|---|
| HTML | DIV | DIV | section | SECTION |
| HTML createElement | DIV | DIV | section | SECTION |
| innerHTML | DIV | DIV | section | SECTION |
| XML | div | DIV | section | SECTION |
| XML createElement | div | DIV | section | SECTION |
| HTML via importNode | Error: Object doesn't support this property or method | |||
| HTML via adoptNode | Error: Object doesn't support this property or method | |||
Opera ups the ante one further: Since it attempts to simultaneous follow web standards, and implement Internet Explorer's weird quirks, it both fails the importNode/adoptNode and the HTML 5 unknown element cases.
| <div> | <DIV> | <section> | <SECTION> | |
|---|---|---|---|---|
| HTML | DIV | DIV | section | SECTION |
| HTML createElement | DIV | DIV | section | SECTION |
| innerHTML | DIV | DIV | section | SECTION |
| XML | div | DIV | section | SECTION |
| XML createElement | div | DIV | section | SECTION |
| HTML via importNode | div | DIV | section | SECTION |
| HTML via adoptNode | div | DIV | section | SECTION |
XHTML (served with correct mimetype)
Nearly every browser that supported showing this page (Firefox, Safari, Opera, Chrome) displayed the same, expected, results:
| <div> | <DIV> | <section> | <SECTION> | |
|---|---|---|---|---|
| HTML | div | DIV | section | SECTION |
| HTML createElement | div | DIV | section | SECTION |
| innerHTML | div | DIV | section | SECTION |
| XML | div | DIV | section | SECTION |
| XML createElement | div | DIV | section | SECTION |
| HTML via importNode | div | DIV | section | SECTION |
| HTML via adoptNode | div | DIV | section | SECTION |
An XHTML page served properly is just an XML document - thus the case of elements is sensitive (as to be expected).
... except in Opera. Opera apparently will treat div elements case insensitively, when injected using .innerHTML, even if it's being served within an XHTML document.
| <div> | <DIV> | <section> | <SECTION> | |
|---|---|---|---|---|
| HTML | div | DIV | section | SECTION |
| HTML createElement | div | DIV | section | SECTION |
| innerHTML | DIV | DIV | section | SECTION |
| XML | div | DIV | section | SECTION |
| XML createElement | div | DIV | section | SECTION |
| HTML via importNode | div | DIV | section | SECTION |
| HTML via adoptNode | div | DIV | section | SECTION |
Based upon some suggestions in the comments I've run some additional tests. Namely I tested the loading of an XML document that has the correct XHTML namespace attached to it (specifically I used the same XHTML test page that I used for the other tests, just appending a .xml extension instead of .xhtml). The results are rather interesting - and promising, at least. (Note: Internet Explorer continues to fail as it doesn't have an adoptNode/importNode method.)
Firefox continues to fail the importing of XML nodes, even when they're coming from an XML document:
| <div> | <DIV> | <section> | <SECTION> | |
|---|---|---|---|---|
| HTML | DIV | DIV | SECTION | SECTION |
| HTML createElement | DIV | DIV | SECTION | SECTION |
| innerHTML | DIV | DIV | SECTION | SECTION |
| XML | div | DIV | section | SECTION |
| XML createElement | div | DIV | section | SECTION |
| HTML via importNode | div | DIV | section | SECTION |
| HTML via adoptNode | div | DIV | section | SECTION |
| XML (XHTML) | div | DIV | section | SECTION |
| XHTML via importNode | div | DIV | section | SECTION |
As does Opera:
| <div> | <DIV> | <section> | <SECTION> | |
|---|---|---|---|---|
| HTML | DIV | DIV | section | SECTION |
| HTML createElement | DIV | DIV | section | SECTION |
| innerHTML | DIV | DIV | section | SECTION |
| XML | div | DIV | section | SECTION |
| XML createElement | div | DIV | section | SECTION |
| HTML via importNode | div | DIV | section | SECTION |
| HTML via adoptNode | div | DIV | section | SECTION |
| XML (XHTML) | div | DIV | section | SECTION |
| XHTML via importNode | div | DIV | section | SECTION |
BUT both Safari and Chrome PASS on the importing of XHTML nodes, coming from an XML document:
| <div> | <DIV> | <section> | <SECTION> | |
|---|---|---|---|---|
| HTML | DIV | DIV | SECTION | SECTION |
| HTML createElement | DIV | DIV | SECTION | SECTION |
| innerHTML | DIV | DIV | SECTION | SECTION |
| XML | div | DIV | section | SECTION |
| XML createElement | div | DIV | section | SECTION |
| HTML via importNode | div | DIV | section | SECTION |
| HTML via adoptNode | div | DIV | section | SECTION |
| XML (XHTML) | div | DIV | section | SECTION |
| XHTML via importNode | DIV | DIV | SECTION | SECTION |
This, in particular, is great news. It means that, at least, one browser understands the concept of loading in external (X)HTML into an HTML document and having it continue to work. It's unfortunate that it doesn't work in all browsers, though.
What can we learn from all of this? Unfortunately it appears as if we can't really trust our "trusted" rules about .nodeName case sensitivity for HTML documents. XML documents are completely safe and work as expected. XHTML (served with the correct mimetype) documents are nearly safe, save for the one bizarre Opera bug.
How will this change the code that we write? In short we can no longer trust the case insensitive nature of HTML documents - we need to assume that BOTH HTML and XML documents will be serving their content in a case sensitive nature - especially as more people start to adopt HTML 5 elements in their pages and expect some level of support in older browsers. This means that a number of selectors and DOM methods will take a performance hit as we can no longer take a case insensitive shortcut in our codebases.
There are a few outstanding jQuery tickets that are the result of these issues cropping up and now that I know the reasoning behind why they're happening I can now strip out all the case-insensitive performance improvements from the codebase - which is really quite unfortunate but at least it'll behave more consistently. I continue to stand by thesis from my earlier talk about the DOM: The DOM is a mess and every DOM method and property is broken in some way, in some browser.
I'm sure Wave doesn't poll the server every millisecond to find out if the other user has typed something... so how can I see what the other person is typing as they type? And without hogging the bandwidth.
Just in time for Thanksgiving is another SVG Web release. The SVG Web project's tradition is to name SVG Web releases after monsters from D&D just to increase the geek factor, so in that spirit their release name this time is "Gelatinous Cube":
The Gelatinous Cube is a truly horrifying creature:
A gelatinous cube looks like a transparent ooze of mindless, gelatinous matter in the shape of a cube. It slides through dungeon corridors, absorbing everything in its path, digesting everything organic and secreting non-digestible matter in its wake. Contact with its exterior can result in a paralyzing electric shock, after which the cube will proceed to slowly digest its stunned and helpless prey.
Fun times.
Highlights of this release:
Read more about the new release.
Learn more about SVG Web:
About SVG Web and SVG:
SVG Web is a JavaScript library which provides SVG support on many browsers, including Internet Explorer, Firefox, and Safari. Using the library plus native SVG support you can instantly target close to 100% of the existing installed web base. SVG itself stands for Scalable Vector Graphics, an open standard that is part of the HTML 5 family of technologies for interactive, search-engine friendly web vector graphics.
I'm playing around with html client side storage and wanted to know if there are any facilities for introspection of the database - is there an equivalent of sqlite ".tables" or ".schema" ?
Also, I'm not seeing my tables show up in AppData\Local\Apple Computer\Safari\LocalStorage . Is there another place tables are stored?
(Googler hat off)
I just spent an hour in Starbucks. (My kid is down the street at a Chinese class.) In the past hour, I’ve checked my email, read news, caught up on the HTML5 mailing lists and IRC chatter, paid two bills, balanced my checkbook, and written this post. Without leaving my browser.
So yeah, Google Chrome OS is gonna be a hit.
Bummer about the whole “only runs apps signed by a private key that Google won’t be sharing with anyone” thing. I’m not thrilled about the prospect of working for a DRM company. Google was in the DRM business once before; it ended with giving everyone their money back, twice. And does anyone honestly believe the first Chrome OS machine won’t be jailbroken within a week? Update: I’m getting conflicting reports about whether retail (non-developer) Chrome OS hardware will include a way to run unverified software. I’m locking this discussion thread until I can confirm this important detail.
On the other hand, computer maintenance sucks gargantuan donkey balls, and normal people don’t care about root. If you accost a random person on the street and ask them if they need root on their operating system to install another browser, and they’ll have three questions for you: 1. What’s root? 2. What’s an operating system? 3. What’s a browser?
Still… if I had root on a Linux netbook, the first thing I’d do is install Chromium and then spend 99% of my time in the browser. So I have to think that Chrome OS is a step in the right direction.
This is an open thread, but I won’t answer any questions on behalf of Google.
Stuart Langridge introduces us to some of the up-and-coming features we're getting with current and future browsers, a nice complement to Robert Nyman's talk, which covered the advanced features of "mainstream" (IE6-compatible) Javascript. After introducing the features that are there today, he also talks about how we can deal with the browser many of us are still having to support.
Here are some of the things we can look forward to. (Having been part of the large crowd who charged the pub across the road at lunch, I was a bit late getting back, so I missed one or two of these.)
It takes a mental shift to start taking advantage of features like this. "Certain browsers" *cough* don't yet provide these conveniences, but you can take advantage of them straight away. Or another example is the base2 library - use it now and you'll be ready for the time when it's present in all browsers.
As our Javascript apps get increasingly bigger and more complex, we need to borrow principles, patterns, and techniques from "real programming". Getters and setters are the kind of thing we'll need more of. More generally, we'll need to be in the mindset that we're building APIs to components, which others might use; not just an individual making a one-off web app. Stuart shows a couple of techniques for getters and setters: (a) manually defined; (b) using
We can now do global storage - globalStorage works similarly to cookies. "Like cookies turned up to 11".
He notes that like XHR, Microsoft did it a long time ago with userdata.
There is also the possibility of SQL and a consistent database API, somewhat supported today but not yet standardised.
Only in Opera right now.
You can use these features now if you're in a single-browser environment that supports them: app for one mobile; Air app; intranet app (where you've amazingly got Firefox exlcusively on your intranet); HTA. This isn't the sinful act of coding to weird proprietary APIs; it's coding to browsers that happen to support the technologies of tomorrow, today.
The libraries help us get to the future today, as long as they can support APIs compatibly across all the browsers. But it's all a little difficult when the market leader doesn't play ball. Hopefully, Dean Edwards will continue working on Base2 to plug the gaps, but we still have the problem. Around a year ago, it felt like the anti-IE6 might be at a tipping point, but that's died down a bit, and it's not clear how much longer we'll be held back.
What can you do then with IE6? If a number of major websites really held back and stopped supporting IE6, Stuart reckons corporations would upgrade. Imagine what would happen if Google stopped working on IE6...immediate upgrades. Show of hands indicates perhaps 20% of the audience would agree to mass dropping IE6 on their public sites. In Q&A, Stuart later clarifies he's not really proposing an IE6 shutdown switch, more like a helpful suggestion to upgrade.
Silverlight and Flash. Proprietary, not open. If everyone started using Flash, the future is Adobe's future. Let's make it our future instead - we're building the open web. A call to arms for showing strength in numbers.
</event>