How Flash Can Integrate With The Open Web
[Big giant usual disclaimer: These are my own thoughts and opinions and not those of my employer]
Dion just put up a great post on how Adobe can join the Open Web by open sourcing Flash. I agree with him, and just wanted to add to the conversation a bit.
I've actually been turning this idea around in my head as well. It might surprise you since I'm an Open Web Advocate, but I like Flash. I've always tried to be non-ideological in my work. Flash has done good things and created a great deal of innovation. Adobe (and Macromedia before it) has always been good about evolving Flash forward, including making ActionScript more like JavaScript, embracing markup language development, open sourcing Flex, and more. I'd like to see Flash continue to evolve into being a core part of the Open Web. This would be good for Flash and good for the Open Web.
As Dion points out open sourcing Flash is one big part of making this happen, but another huge aspect would be to have Flash and Flex integrate better into the web stack and be less of a 'black box' on the screen.
Here are some suggested ways to make Flash & Flex more a part of the Open Web -- these are just suggestions. The important point is to integrate Flash and Flex more deeply into how the Open Web works:
Directly push Flex and ActionScript to the browser and Embrace View Source
Right now Flex and Flash work by compiling everything you do down into a small, binary SWF file. This has some obvious advantages, mainly that it allows the Flash player to be simpler and not have a full interpreter in it (for example, ActionScript doesn't support eval because there's no way to dynamically execute script at runtime). Back when bandwidth was more constrained it also had the advantage of smaller file sizes and less latency when fetching multiple files.
These were good reasons for their time. However, things have changed. We now have much higher broadband penetration, and the Flash player doesn't have as strong size constraints (though I do agree you want to make sure the size stays small in general -- I've always liked the size constraint Adobe has around their player versus Sun with the Java VM).
At this point, Flash should start working like the web itself: Flex should be pushed right down to the browser and rendered there, with the ActionScript fetched just like SCRIPT tags. In addition, View Source should be on automatically and hooked into the browser's View Source. If I browse to an MXML page and do View Source, I'll see the MXML Flex markup for it. I could also then see the mx:Script tags and view their source as well.
Why this is good:
Flash should implement the HTML 5 History interface and should deeply integrate with the browser's bookmarking and history. I know there were some earlier efforts to have Flash have bookmarking machinery, but its buggy, no one uses it, and it doesn't work very well.
Don't Be Afraid of the Browser
AIR is really cool when you want to build desktop applications using web technologies. However, the browser doesn't need to be routed around as if it were a source of damage, which is what AIR essentially does. Personally I'd rather see Flash deeply embrace the browser itself and expand what can be done there, similar to Gears -- I want the web to grow into the desktop, not have the desktop grow into the web. Flash developers generally see the strengths of the browser as weaknesses, when they shouldn't:
Hyperlinks Are Your Friend
Hyperlinks are essential to the web, navigation, and searching -- it's the Hypertext in HyperText Markup Language (HTML) after all. Flash should embrace linking into the resources that are internally present (such as targeting particular parts of an MXML document). I'm not saying XLink is the way to do this, but perhaps one could mix in an attribute onto an MXML element (or the equivalent of a div and span in some inline text in an MXML element) that makes the element a targetable anchor. Or even better, just automatically make everything targetable:
http://example.com/my_flex_app.mxml#find(Some Text)
The line above would simply find the first occurrence of 'Some Text'. If there are multiple occurrences you can simply choose which one, starting at 1 rather than 0; for example, to target the second occurrence of 'Some Text', you would do the following:
http://example.com/my_flex_app.mxml#find(Some Text)[2]
This is good for search engines, for SEO, and for users. Again, this is just like View Source -- make things linkable by default.
Embrace REST and Readable Remoting Protocols
The Flash remoting protocols are interesting and a nifty piece of engineering. You've got AMF which is essentially a binary RPC protocol, and then you have things like RTMP which lie above this and which can efficiently intermix multiple streams of multimedia to ensure that no channel get's 'starved' if you are doing multiple collaboration or mixing streams together -- nice work. Again, however, this is a case where local efficiency is the enemy of broad adoption. Binary protocols make sense in some cases, but its much better to sacrifice the efficiency of binary protocols for the integration possibilities of textual protocols.
Flash should embrace REST (and if it must have RPC, just do XML-RPC) and layer higher-level protocols above these as HTTP-based protocols. Yes, you're going to sacrifice some efficiency, but it's just much easier for someone to throw up a PHP or Rails based backend that can setup things through REST, spit out some XML-RPC, or do multimedia through something like Jabber.
Embrace SVG
Yes, I know you are creating your own vector-graphics markup language, and I know you just published a long editorial on why SVG wasn't perfect for your needs. I hear what you're saying, but reading through the list it seems like minor errata rather than really good reasons. It seems more like the developer really wanted to make their own thing -- I understand that, it's always more fun to roll your own thing.
SVG's not perfect -- standards never are (and neither was TCP/IP or SMTP versus the competition, BTW). But SVG is actually pretty damn good, and the baseline of support has gotten strong the last year across Firefox, Safari, Chrome and Opera. In the next two years I think we'll start to see SVG emerge as a real tool in most web developers toolkits -- Flash should embrace this. Go ahead and add what you need to it (innovation is okay), but support the core standard itself. It's going to be a little different than the other MXML it's mixed in with, one of the issues you raise, but global systems like the web tend to sacrifice some internal consistency in support of evolvability.
Bonus point: Support the Canvas tag as well, including Web fonts (TrueType, not EOT).
Integrate with HTML and CSS
Yes, HTML has been sitting on its butt for awhile, but things like HTML 5 are starting to make things exciting again, and the work Safari and Firefox have been doing around CSS Effects are really powerful (and really easy for developers to use).
This can be a two-way integration. MXML has some cool ideas around layout, for example, that would be nice to push into HTML, while it would be pretty nifty to start being able to mix HTML and MXML together in some way and styling MXML using CSS. This might also include having one of the open source browsers integrate MXML and aspects of Flash into the layout engine itself. More thought needs to happen around the best way for these particular technologies to integrate.
Make Friends with HTML 5 Video
It would be pretty cool to simply open source and patent-unencumber the FLV format into HTML 5 as the default codec for the HTML 5 Video tag. I might be dreaming (and a bit off about FLV -- I don't know it's technical details deeply), but it never hurts to dream...
Support Both Documents and Applications
The web is good at documents (and with the addition of Ajax relatively okay at applications), while Flash is okay with applications, and not good at documents. The interesting thing about the web is it's actually a spectrum:
Documents <------- Hybrids -------> Applications
What we really need is a technology that can easily adapt along this continuum, creating documents, hybrids like Facebook and MySpace, all the web to full-blown appliations like Gmail and Buzzword, perhaps merging the best ideas of Flash and the HTML web stack. Mark this one as a research area.
Start Working with the W3C and IETF (and/or the Open Web Foundation)
Yeah, I know, working with standards bodies can be a pain. However, it would be pretty cool to have alot of the work happening in Flash flowing into the W3C and IETF (which I know has been happening around Adobe's ActionScript work, but not other aspects). If you want a lighter weight process, you should check out the Open Web Foundation's way of working, which is based on things like OpenID, OAuth, etc. which are a bit more pragmatic than the standards bodies we have today.
Conclusion
At the end of the day Adobe is a tools company, a really damn good tools company actually. Doing the above should allow Adobe to continue creating powerful tools that help authors and content creators while expanding the size of the market they can target.
The above list was just a suggestion to kick things off. The real focus is on having Flash integrate into the web stack better itself (and evolving both Flash and the web stack themselves into the future).
How do you see this happening?
Dion just put up a great post on how Adobe can join the Open Web by open sourcing Flash. I agree with him, and just wanted to add to the conversation a bit.
I've actually been turning this idea around in my head as well. It might surprise you since I'm an Open Web Advocate, but I like Flash. I've always tried to be non-ideological in my work. Flash has done good things and created a great deal of innovation. Adobe (and Macromedia before it) has always been good about evolving Flash forward, including making ActionScript more like JavaScript, embracing markup language development, open sourcing Flex, and more. I'd like to see Flash continue to evolve into being a core part of the Open Web. This would be good for Flash and good for the Open Web.
As Dion points out open sourcing Flash is one big part of making this happen, but another huge aspect would be to have Flash and Flex integrate better into the web stack and be less of a 'black box' on the screen.
Here are some suggested ways to make Flash & Flex more a part of the Open Web -- these are just suggestions. The important point is to integrate Flash and Flex more deeply into how the Open Web works:
- Cross-Platform Standards
- No Vendor Lock-in
- Anyone Can Innovate
- Powerful, Universal Clients
- Open Source Implementations
- Mashable, Searchable, and Integrated
Directly push Flex and ActionScript to the browser and Embrace View Source
Right now Flex and Flash work by compiling everything you do down into a small, binary SWF file. This has some obvious advantages, mainly that it allows the Flash player to be simpler and not have a full interpreter in it (for example, ActionScript doesn't support eval because there's no way to dynamically execute script at runtime). Back when bandwidth was more constrained it also had the advantage of smaller file sizes and less latency when fetching multiple files.
These were good reasons for their time. However, things have changed. We now have much higher broadband penetration, and the Flash player doesn't have as strong size constraints (though I do agree you want to make sure the size stays small in general -- I've always liked the size constraint Adobe has around their player versus Sun with the Java VM).
At this point, Flash should start working like the web itself: Flex should be pushed right down to the browser and rendered there, with the ActionScript fetched just like SCRIPT tags. In addition, View Source should be on automatically and hooked into the browser's View Source. If I browse to an MXML page and do View Source, I'll see the MXML Flex markup for it. I could also then see the mx:Script tags and view their source as well.
Why this is good:
- View Source is a good thing. It's helped to propel the growth of the web itself (and the Ajax community which has benefited hugely from it's existence). It's similar to how YouTube and Flickr made the default option for sharing be public and experienced massive growth -- this made things grow faster versus Snapfish, for example, which made everything private by default. If someone wants to keep their source private they can obfuscate their source just like we do today with JavaScript. View Source should always be on (you can't turn it off) -- just obfuscate your source if you don't want it.
- No compile phase -- the dev experience would become similar to working with HTML and JavaScript today.
- Over time, human readable textual formats have won -- SMTP, HTML, etc. Binary formats are better on paper (and are better in practice many times), but the simplicity of working with textual formats when creating software is just so much easier and is generally worth the efficiency tradeoff. Imagine simple PHP scripts that can just generate MXML, for example -- much easier than trying to emit a binary SWF file from PHP.
Flash should implement the HTML 5 History interface and should deeply integrate with the browser's bookmarking and history. I know there were some earlier efforts to have Flash have bookmarking machinery, but its buggy, no one uses it, and it doesn't work very well.
Don't Be Afraid of the Browser
AIR is really cool when you want to build desktop applications using web technologies. However, the browser doesn't need to be routed around as if it were a source of damage, which is what AIR essentially does. Personally I'd rather see Flash deeply embrace the browser itself and expand what can be done there, similar to Gears -- I want the web to grow into the desktop, not have the desktop grow into the web. Flash developers generally see the strengths of the browser as weaknesses, when they shouldn't:
- The browsers chrome is your friend -- I know you want to get rid of the URL bar and the back and forward buttons for your application, but users depend on this consistent UI. Users spend far more time navigating across many sites than your particular application -- UI consistency in the browser is a good thing. AIR jettisons the browser and loses this -- Flash should expand what web applications can do within the browser itself instead.
- Sandboxing is good - the fact that web applications have limited trust is a feature, not a bug. AIR throws away the sandbox, making it hard for users to effortlessly experiment and try new web sites. Instead, Flash should adopt what Gears and HTML 5 are trying to do, which is to expand the sandbox in a safe and consistent way.
- Users don't want to download applications, they just want to visit URLs - In AIR I have to download an application. Instead, users would rather visit web sites (though having a nice icon on your desktop is a good thing, similar to the Gears Desktop Shortcuts). I'd love if Flash allowed me to drop shortcuts on my desktop to web apps that live at URLs (and which might have cached code locally for performance like the Gears LocalServer, though this would be transparent to the user). However, again, the growth of the web has shown that the ease of simply navigating to URLs (and the safety because of the sandbox) drives huge growth.
Hyperlinks Are Your Friend
Hyperlinks are essential to the web, navigation, and searching -- it's the Hypertext in HyperText Markup Language (HTML) after all. Flash should embrace linking into the resources that are internally present (such as targeting particular parts of an MXML document). I'm not saying XLink is the way to do this, but perhaps one could mix in an attribute onto an MXML element (or the equivalent of a div and span in some inline text in an MXML element) that makes the element a targetable anchor. Or even better, just automatically make everything targetable:
http://example.com/my_flex_app.mxml#find(Some Text)
The line above would simply find the first occurrence of 'Some Text'. If there are multiple occurrences you can simply choose which one, starting at 1 rather than 0; for example, to target the second occurrence of 'Some Text', you would do the following:
http://example.com/my_flex_app.mxml#find(Some Text)[2]
This is good for search engines, for SEO, and for users. Again, this is just like View Source -- make things linkable by default.
Embrace REST and Readable Remoting Protocols
The Flash remoting protocols are interesting and a nifty piece of engineering. You've got AMF which is essentially a binary RPC protocol, and then you have things like RTMP which lie above this and which can efficiently intermix multiple streams of multimedia to ensure that no channel get's 'starved' if you are doing multiple collaboration or mixing streams together -- nice work. Again, however, this is a case where local efficiency is the enemy of broad adoption. Binary protocols make sense in some cases, but its much better to sacrifice the efficiency of binary protocols for the integration possibilities of textual protocols.
Flash should embrace REST (and if it must have RPC, just do XML-RPC) and layer higher-level protocols above these as HTTP-based protocols. Yes, you're going to sacrifice some efficiency, but it's just much easier for someone to throw up a PHP or Rails based backend that can setup things through REST, spit out some XML-RPC, or do multimedia through something like Jabber.
Embrace SVG
Yes, I know you are creating your own vector-graphics markup language, and I know you just published a long editorial on why SVG wasn't perfect for your needs. I hear what you're saying, but reading through the list it seems like minor errata rather than really good reasons. It seems more like the developer really wanted to make their own thing -- I understand that, it's always more fun to roll your own thing.
SVG's not perfect -- standards never are (and neither was TCP/IP or SMTP versus the competition, BTW). But SVG is actually pretty damn good, and the baseline of support has gotten strong the last year across Firefox, Safari, Chrome and Opera. In the next two years I think we'll start to see SVG emerge as a real tool in most web developers toolkits -- Flash should embrace this. Go ahead and add what you need to it (innovation is okay), but support the core standard itself. It's going to be a little different than the other MXML it's mixed in with, one of the issues you raise, but global systems like the web tend to sacrifice some internal consistency in support of evolvability.
Bonus point: Support the Canvas tag as well, including Web fonts (TrueType, not EOT).
Integrate with HTML and CSS
Yes, HTML has been sitting on its butt for awhile, but things like HTML 5 are starting to make things exciting again, and the work Safari and Firefox have been doing around CSS Effects are really powerful (and really easy for developers to use).
This can be a two-way integration. MXML has some cool ideas around layout, for example, that would be nice to push into HTML, while it would be pretty nifty to start being able to mix HTML and MXML together in some way and styling MXML using CSS. This might also include having one of the open source browsers integrate MXML and aspects of Flash into the layout engine itself. More thought needs to happen around the best way for these particular technologies to integrate.
Make Friends with HTML 5 Video
It would be pretty cool to simply open source and patent-unencumber the FLV format into HTML 5 as the default codec for the HTML 5 Video tag. I might be dreaming (and a bit off about FLV -- I don't know it's technical details deeply), but it never hurts to dream...
Support Both Documents and Applications
The web is good at documents (and with the addition of Ajax relatively okay at applications), while Flash is okay with applications, and not good at documents. The interesting thing about the web is it's actually a spectrum:
Documents <------- Hybrids -------> Applications
What we really need is a technology that can easily adapt along this continuum, creating documents, hybrids like Facebook and MySpace, all the web to full-blown appliations like Gmail and Buzzword, perhaps merging the best ideas of Flash and the HTML web stack. Mark this one as a research area.
Start Working with the W3C and IETF (and/or the Open Web Foundation)
Yeah, I know, working with standards bodies can be a pain. However, it would be pretty cool to have alot of the work happening in Flash flowing into the W3C and IETF (which I know has been happening around Adobe's ActionScript work, but not other aspects). If you want a lighter weight process, you should check out the Open Web Foundation's way of working, which is based on things like OpenID, OAuth, etc. which are a bit more pragmatic than the standards bodies we have today.
Conclusion
At the end of the day Adobe is a tools company, a really damn good tools company actually. Doing the above should allow Adobe to continue creating powerful tools that help authors and content creators while expanding the size of the market they can target.
The above list was just a suggestion to kick things off. The real focus is on having Flash integrate into the web stack better itself (and evolving both Flash and the web stack themselves into the future).
How do you see this happening?
Comments
Flash 9 Update 3 and above support H.264, an ISO standard. H.264 still carries a license fee, which led China to create AVS for free choice.
Multimedia is just one of the spaces where the threat of torpedo patents has stifled innovation.
http://www.whatwg.org/specs/web-apps/current-work/#video-and-audio-codecs-for-video-elements
Theora is not based on VP6. It is based on VP3 (http://en.wikipedia.org/wiki/Theora). VP6 is not free and unlicensed uses of it are actively litigated (http://en.wikipedia.org/wiki/VP6).
Adobe Flash Player does not support any royalty-free video codecs and it does not support any reasonably-compressed royalty-free audio codecs (it supports ADPCM and raw, but they have little or no compression). This is a major roadblock for open implementations of Flash.
Flash Player supports HE-AAC v2, MP3, AAC, Speech, ADPCM, and raw for audio. All but ADPCM and raw are patent-encumbered. Flash Player supports Sorenson Spark, On2 VP6, and H.264 for video. All of these are patent-encumbered. Sources:
http://www.adobe.com/products/hdvideo/supported_technologies/
http://www.adobe.com/products/hdvideo/supported_technologies/continued_support.html
Not only are all the useful formats supported by Flash Player patent-encumbered, but Adobe can't make any of them royalty-free because they don't own any of them. We need support for new formats in Flash if we are to have a freely-redistributable open source version of Flash. Unfortunately, all the big companies complain of possible submarine patents with the popular free codecs (Vorbis, Theora, and Dirac). Hopefully the use of Dirac and Vorbis by the BBC (who are driving the development of Dirac) will change this.
I just found out that Flash 10 supports Speex for low bitrate voice (record and playback), a free codec which is under the Xiph umbrella. See http://www.speex.org/
I think previously they used NellyMoser Asoa codec for these purposes: http://en.wikipedia.org/wiki/Nellymoser_Asao_Codec
Another small step towards openness.
Flash's display model is hierarchical, and it already supports styling with CSS, so maybe all we need to do is get adobe to provide the display model via a DOM api and to allow styling that DOM via in-page CSS. The timeline is a big question mark here, because you need a different DOM for every frame, but I think this is a surmountable obstacle.
Making things linkable by default doesn't happen for the same reason it doesn't happen for ajax apps. Nobody really has a good idea for how to go about it.
Over time Adobe has been become more and more open source friendly, contributing to open source projects and opening up their own products. However, these decisions have always been good business decisions and open sourcing Flash right now is a really bad business decision.
I agree too about the DOM; I forgot to mention that. They should just provide the standard DOM, plus the new querySelector type interfaces that JQuery and Dojo have.
In terms of making things linkable by default, I thought the very simple scheme I provided should help; 99% of the time you want to link to some text (like a section of a document), and the scheme I provided does that with very little implementation overhead and a spec that can be described in about two paragraphs.
As far as linking goes, while I could conceivably see a toolkit implementing such a scheme generically, there isn't any one I know that actually does it. I'm going to cut adobe some slack here, because from my perspective flash is not actually any worse at deep linking than your typical dojo or extjs app.
Long time reader, first time poster :-) For a long time (since a little before Flex 2) I wondered the same thing-wouldn't it be great if you could mix HTML and MXML and just use AS the same way you use JS (by using script tags). What I consider a bright future for application development on the web was killed the day Harmony was ratified. This all but abolished the idea of ever getting an AS like language to run outside of Flash. I don't have any intention of getting into a 'static vs. dynamic' language war, but I've been working with JS since it was LiveScript and let me just say I think it leaves something to be desired as far as enterprise level application development goes. ECMAScript 4 would have been nice.
I also think some of your criticism's of Flash are somewhat misguided when you say that it doesn't integrate well with history,linking, searches, mashups, etc. This is all pretty much the case despite attempts by Adobe to overcome these issues. However, this is not really the fault of Flash, but more the fault of conflicting paradigms of what the web should be: for applications or for documents.
Most of the above afflicts your run of the mill AJAX enabled Web 2.0 application as well. Instead of trying to make applications into documents, which they clearly aren't-maybe people should get used to the idea that many popular concepts were designed around the idea of the web as a collection of documents(which it was invented as) and not for applications. Applications as the vast majority of users think of them will never fit the 'mashable' 'linkable' web that we have today and attempts to do so are like trying to put a round peg into a square hole. We need to recognize that applications require a different way of thinking and not try to force them into a document-based paradigm.
Its also difficult for me to envision text based protocols replacing binary in all instances. There are still times when transmission bloat does matter(even in this supposed age of broadband everywhere). Perhaps one day this will be a reality, but I don't think we're quite there yet.
Lastly, I agree completely with the idea that 'View Source' was probably critical in the popularization of the web(that and the simplicity of HTML). But while making a feature like this built into the Flash player by default might have a similar effect on the Flash ecosphere, I truly don't think this is what many content-authors want. Right now Adobe provides a way for this feature as an option, but if they made it mandatory I'm sure they would be blasted by their current customer base. If the ability to turn off view source was available now for HTML/JS pages to content authors, I'm all but certain it would be taken advantage of by many, many people (not everyone, but likely a sizable percentage).
In a open source flash world, it would be interesting to see the development of both ActonScript and Javascript.
Also those who think MXML could be translated by either the browser or by the Flash Player at run time don't understand how Flex and MXML works. A single MXML file is compiled by the Java based Flex compiler into many ActionScript files, which are then compiled into a SWF. If you are interested in seeing these ActionScript files, you can set a flag to see all the code that Flex generates.
However, my point is having that process running in the Flash Player or the browser would be painfully slow even for small Flex applications. Large Flex applications can take many minutes to compile, which would doom the technology on the client.
Also the article complains about Flash embracing REST, when some of the main Flex examples use REST:
http://www.adobe.com/devnet/flex/samples/restaurant/
Not to mention, the Zend framework for PHP is working on intergrating AMF into their framework, so PHP developers will be able to very easily the format. It would be great if things went the other way and browsers began to incorporate AMF (which is now an open standard so any browser could use it if they wanted) so that JavaScript could take advantage of the efficiency of the protocol.
As for making friends with HTML5 video tag, Mike Chambers from Adobe already put together a proof of concept using the video tag with and FLV file:
http://www.mikechambers.com/blog/2008/05/27/poc-implementing-html-5-video-element-using-javascript-and-flash/
As for documents, Adobe really improved the text engine in Flash Player 10. Flash developers and designers now have a lot more control over the way the text is formated and looks that far exceeds HTML in the browser. It was recently announced that the New York Times was working on an AIR application that would display articles in the exact same look, format and font as their real newspaper. The demos they have shown really looks incredible and we are likely going to see more of this as Flash Player 10 gets a higher installation base.
I'm also aware of how the MXML process currently works today, with the Java based compiler that turns into ActionScript files that produce a final SWF final. I disagree that the performance would be bad to have MXML directly rendered -- in fact, HTML, CSS, SVG, etc. all currently render at runtime. Perhaps the render-on-demand model of the web is broken, but I don't believe it is and don't see why MXML can't be done in this way. Also, the compilation process is probably doing many optimizations, compiling it down into a simpler form that the Flash plugin can deal with. Rendering MXML at runtime would not necessarily slow, and I'm definently not arguing for that. Performance is extremely important, and I definently don't want Flash to become like Java, with a slow startup time. What I'm arguing for should be made to be fast -- MXML can definently be made to be fast at runtime.
In terms of REST, yes, it can be layered on, but Adobe made a choice when they chose the binary-based AMF protocol as their foundation and layered everything else over it. The work around getting AMF working in PHP is very cool, but again it reminds me of Samba: binary protocols are a pain in the butt, and aren't easy to work with from a library level.
Around Flash 10 and text reflowing, that's good to hear. Back in the day when I first heard about the Apollo project (what became AIR), I thought what they were trying to produce would be something that had the text reflowing abilities of PDF coupled with the animation abilities of Flash.
In terms of video codecs, yes, those are a big problem and can't currently be open sourced due to all the patent issues. I'd be okay with having everything else open source and in an open community, with a commitment to H.264 as the video codec. The video portion could be a binary drop-in component by necessity because of the patent situation.
* Use the Full DOM
The DOM tree when working with MXML should be the DOM standard, including the new HTML 5 querySelector and querySelectorAll syntax that JQuery pioneered.