[whatwg] Thoughts on recent WhatWG blog post
Simetrical+w3c at gmail.com
Tue Feb 8 15:39:32 PST 2011
On Mon, Feb 7, 2011 at 6:15 PM, Adam van den Hoven <adam at littlefyr.com> wrote:
> But that is exactly what has happened, or perhaps some existing pollution is
> simply being codified.
atob() and btoa() were first implemented years ago, I guess by
Netscape, and are supported in all major browsers except IE. So they
were already in the global namespace (except if you only care about
> You could collect them into a single global object, and that was something I
> though about, as well. But I think that this is a more generally applicable
> believe this is a code smell. Having a consistent way to do this sort of
> thing would improve the lives of a lot of code developers and create some
> consistency between what is happening on the server side as well.
other than adding <script> to the DOM, but I don't think it needs the
namespace/module-style functionality that's part of your proposal.
Your proposal seems to be trying to do several different things at
once, not all of which look necessary.
To make a good proposal, you need to first clearly identify all the
problems you see with the status quo, in the form of use-cases -- "I
want to do X but can't", where X is something of self-evident utility.
Only once you've clearly identified the problems is it useful to talk
about solutions. Mixing the problem statement together with your
solution makes it harder for everyone else to consider alternative
solutions to your problems.
> cached between page requests should be a benefit.
What does "compiled" mean here? Browsers these days do compile
with your proposal, they could cache it without your proposal too.
How does your proposal benefit caching compared to the status quo?
case, I don't see how it's relevant to browser-level features, since
browsers don't know about minification.
> Inserting a script element is great, so long as you're writing code that
> only gets run in a browser.
What non-browser agent are you thinking about here?
> The number of well behaved libraries is very limited and generally they
> don't work well together.
Jonas says this is being worked on elsewhere at the language level, so
no need to consider it here further.
> Its quite simple. If you have a page that contains user contributed content,
> you spend lots of time trying to prevent people from injecting bad code. For
> example, if you were to bypass the filters (which unfortunately does happen
> from time to time) you could redefine jQuery.ajax to send a copy to where
You could also steal the user's cookies and send them off to your evil
site without using jQuery at all. How does access to jQuery
exacerbate the attack? Once you can run JS, you don't need libraries
to carry out typical attacks. Put another way, why would an attacker
even bother trying to use the libraries you've loaded instead of just
running whatever code they like directly?
More information about the whatwg