...because I just don't have the motivation to do my urgent work right now :)
Well, that's not entirely true -- one of my thoughts does partially relate to work and a major project I'm working on there.
Tagging of JavascriptA problem I currently see with javascript in [X]HTML is that the page author can't specify what the javascript is doing to or providing to the page. I posted recently about the growing importance of securing trust of sites by making "contracts" both with the browser and site visitors, and also ways to improve inclusion of javascript in pages -- I see these two things going hand-in-hand to provide a way for a page author to say why he chose to include some javascript library in a page, and what it's doing. While most end-users won't directly need this information, having it available to them would be a big plus for trust. The key advantage for this is for power users, specifically people using tools like NoScript on Firefox, who want to know if they should turn off some script or not from some host.
For example, frequently I as a NoScript user have no idea what some page is using a script for, let alone what that script's host does. Sure, some hosts are notable for their services *cough* doubleclick.net *cough* so I know if I can or cannot trust them and their scripts. But there are a lot of sites and scripts that I don't know, and relying on a site name/URL as an indicator of whether to trust a script isn't the way to go -- I as a user should be able to see some information about what the script is intended to do, what you as a site author are using it for (e.g. rich interactions, site tracking, ad delivery), and then if I trust the site which serves that script (e.g. maybe I don't trust Yahoo's widgets because they crash my browser or slow me down, but do trust Google's).
The HTML spec doesn't allow much in the way of metadata for the SCRIPT tag, which I think is a shame. It can sit in the HEAD or the BODY of a page, but you can't give it any of the core attributes that you can give to so many other tags, particularly the BODY-enclosed tags. I think using the core TITLE attribute would be useful here, but alas it's not available to us for SCRIPT.
The other option might be to use LINK in the HEAD with a REL attribute of "script" and a TITLE for the intent of that script. While technically REL="script" isn't a standard REL value, I think one could use it as-is without incurring validation problems, and a more industrious type could create a profile that defines this REL value properly for use.
So what about using both tags as a sort of microformat or idiom for enriching the page? That is:
- use LINK in the HEAD with attributes:
- REL="script"
- TITLE=the script's statement of intent on the page
- HREF=the same URL for the SCRIPT tag in the BODY
- use SCRIPT as usual
That way we could provide some extra info that an "intelligent" tool could use.
Are there any other ideas and solutions out there which suit this particular concern? Quickly doing a search in google didn't reveal similar concerns or other solutions, but maybe I wasn't using the magic keywords.
An erlang Web BrowserWith the recent interest in web browsers trying to solidify their user experience and security, there's been much talk about having browsers display pages in tabs with their own processes. Google Chrome is doing this, and I think Firefox and IE are looking into it as well (I don't know what Safari does off-hand). The main advantage to an end user is that if a site does something that causes problems in the browser, that site won't affect any other pages/sites loaded in the browser adversely, or the browser itself. There's also a secondary, non-obvious benefit for security, where each page/site process is effectively sandboxed in its own process and can't touch other sites/pages or their info.
Typically browsers have been written in
ye olde standarde imperative languages like C, C++, and Objective-C, which in and of themselves don't handle process and thread management well natively. Often they rely explicitly on some reference to the underlying operating system or system layer for their process management, and this can introduce all sorts of issues and concerns to the program. Because of these complications, it's not hard to see why a lot of browsers -- already fairly complex applications -- haven't tried or accomplished much in the way of multi-processes for multi-site usage.
Enter erlang: a functional programming language developed by Sony-Ericsson for telephony systems. One of erlang's key values is easy and readily accessible concurrent and multi-process management. With this in mind, it raises the question: why hasn't someone tried to write a multi-process, multi-site web browser in erlang? Seems intuitively to be a good idea, and probably not too-too hard to do since erlang also has HTML and XML libraries available to it already, as well as graphical front-end libraries.
In addition, supposedly an erlang-based web server called Yaws outperforms Apache in both allowable load and speed of serving up pages -- so there seems to be precedent to building web systems with erlang with visibly improved performance.
Googling for an erlang web browser turned up nothing -- there's an opening for any adventurous and experienced soul to make one :)