Sounds related to Programmable HTTP Caching and Serving (formerly titled
DataCache API):
http://dev.w3.org/2006/webapi/DataCache/
[[[ This document defines APIs for off-line serving of requests to
HTTP resources using static and dynamic responses. It extends
the function of
On Aug 12, 2010, at 3:29 PM, Ian Hickson wrote:
These quotas are often global, some kind of user setting, or are
per-origin. Application Caches are missing such a quota.
The entire Disk Space section of Web SQL Databases could equally apply
to Application Caches:
Should window.name be [Replaceable]?
There are a number of [Replaceable] [1] properties on the window
object. However, window.name is not marked as such [2]. Not being
marked as replaceable means that if authors use a global variable
named name it will be coerced into a string. For many this
On Jul 4, 2010, at 9:35 PM, Biju wrote:
On Mon, Jul 5, 2010 at 12:05 AM, Joseph Pecoraro pecor...@apple.com wrote:
- I didn't have access to IE to test. I'd appreciate
someone giving it a shot to see how they act.
On IE8 it is printing string,string,string
Thanks for checking! So
The section describing the pattern attribute does not explain that
it only applies to particular input types [1].
However, one of the tables showing which content attributes apply
to which input types shows the pattern attribute only applies to
particular input types. Namely text, search, url,
On Apr 20, 2010, at 6:16 AM, Mounir Lamouri wrote:
Actually, if you are looking for something more normative (the table is
non-normative), at the end of each input element states description, you
can found the list of attributes which apply/don't apply. AFAIK, the
attributes/methods never
?
There was a change around the time this email thread occurred that
clarified that the download process should be performed in the
background, but nothing about the events.
- Joseph Pecoraro
On Dec 17, 2009, at 4: 44PM, Ian Hickson wrote:
Another conforming sequence of events would be:
1. The parser's first parsing task begins.
2. As soon as the manifest= attribute is parsed, the application cache
download process begins. It queues a task to dispatch the 'checking'
event.
3.
it defers Offline events until the body element is reached (I did a
search and found nsGlobalWindow::FireOfflineStatusEvent). It looks like many of
Firefox's tests depend on this type of behavior.
Thanks,
Joseph Pecoraro
[1]: https://bugs.webkit.org/show_bug.cgi?id=29690
this sound like a worthwhile improvement?
Cheers,
Joseph Pecoraro
[1]: http://code.google.com/speed/articles/reflow.html
[2]: http://dev.opera.com/articles/view/efficient-javascript/?page=3
// Single reflow would be triggered at the end of batchUpdate
document.batchUpdate(function() {
...
});
As a UA developer, I'd not be all that happy implementing this,
since you can stay inside the batchUpdate more or less forever (e.g.
by putting up alerts or doing sync XHR).
In any
optimizations in the engine, could search the entire DOM tree.
Cheers,
Joseph Pecoraro
[1]: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018835.html
[2]: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011561.html
[3]: http://www.whatwg.org/specs/web-apps/current-work
On Sep 20, 2009, at 3:57 PM, Michael A. Puls II wrote:
I think it'd be cool to have to complement document.documentElement
and document.body.
On Sep 20, 2009, at 4: 00PM, Juriy Zaytsev wrote:
Surely better than abominable – `document.getElementsByTagName
('head')[0]` :)
I agree.
On Sep 20, 2009, at 4: 24PM, Juriy Zaytsev wrote:
Speaking of `document.head`, I think Mootools does exactly that.
Good thinking. I took a look at some JavaScript Libraries /
Frameworks. Here are some quick counts of how many times I could see
that they use the getElementsByTagName
On Sep 20, 2009, at 10: 29PM, Garrett Smith wrote:
On Sun, 20 Sep 2009 16:15:11 -0400, Joseph Pecoraro joepec...@gmail.com
Something like this almost always works:
var head = document.documentElement.firstChild
The documentElement.firstChild cannot be expected to be head. It could
On Jul 28, 2009, at 9: 21PM, Ian Hickson wrote:
Use Cases:
Any that apply to XHR accessing their response headers would
certainly
apply here. Some thoughts are accessing the Content-Type header or
Custom Headers and acting accordingly.
You can just include the data straight into the page,
I think we need an approach that doesn't involve in-flow links...
I'm just
not sure what the right solution is. Maybe alt-double-clicking
should show
a menu with two options, submit comment here or change section
status?
Alt-Double Click doesn't sound very discoverable. Even if I knew
interface with something like:
document.getAllResponseHeaders() and
document.getResponseHeader(header)
Cheers,
Joseph Pecoraro
[1] Example: http://bogojoker.com/x/xhr/headers.html
On Jul 13, 2009, at 3: 01PM, Aryeh Gregor wrote:
How about you have an extra HTTP header like X-Content-Hash? This
could provide a SHA256 hash (or something else that looks safe for
now, progressively upgradeable) of the content. The browser can keep
its cached copies of these files indexed by
Some quick feedback before I heed Ian's advice and try to formalize
things a little more.
As a browser vendor (or at least someone working for one, specifically
on script-loading), I would definitely be interested in something like
this. However there are some hard problems to be solved:
I
We could make Storage into an EventTarget and also fire events on
there,
sure. As Jeremy said, this is something that might best be done in the
next version; we're still trying to get the current features
implemented
in a stable and consistent fashion as it is.
Sounds great. Although
I would recommend approaching the browser vendors directly and
seeing if
they would be interested in implementing this idea, as discussed in
this
FAQ entry on introducing new features:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F
I see,
This doesn't break anything in the current spec. So it wouldn't
break
any existing implementations. I'm also guessing that the groundwork
for implementing a feature like this is already in place due to the
ubiquity of addEventListener.
To be frank, it seems like a lot of bloat though to
Jeremy Orlow: Is it too late? It seems as though Joseph's
suggestion could be in addition to what's already in the spec.
This doesn't break anything in the current spec. So it wouldn't break
any existing implementations. I'm also guessing that the groundwork
for implementing a feature
Seems like a reasonable idea. I don't know if it's been brought up
before. My guess is that Ian will say this should be re-examined
for HTML6, though.
Very cool. Let me know if I can help at all to push this idea forward.
- Joe
-June/020485.html
On Jun 17, 2009, at 1: 44PM, Joseph Pecoraro wrote:
The storage event [1] fires for both sessionStorage and
localStorage. To me, this means if you only want to interact with
localStorage you will have to manually ensure that it is the storage
area being modified
The storage event [1] fires for both sessionStorage and
localStorage. To me, this means if you only want to interact with
localStorage you will have to manually ensure that it is the storage
area being modified:
window.addEventListener('storage', function(e) {
if ( e.storageArea ===
Hey Guys,
This is my first time on the list, I searched the Archives but I
didn't see anything like this so I apologize if I missed any earlier
discussion on something like this.
A while back I came across this two paragraph blog post titled
Browsers Should Bundle JS Libraries:
Pros:
- Pre-Compiled: By bundling known JS Libraries with the browser,
the browser could store a more efficient representation of the
file. For instance pre-compiled into Bytecode or something else
browser specific.
I think something needs to be clarified wrt to compile times and the
The common JavaScript libraries should be identified using urn
scheme with
JavaScript namespace, as in
script src=urn:JavaScript:cool-acme-lib:1.0 /script
Chris
Chris, this was what I was originally thinking of when I read about
tag-uri's in the Atom Publishing Protocol (which I think are
Dion: The problem here is that isn't backwards compatible and thus
no-one will really be able to use it.
I thought the original idea was backwards compatible. Maybe not the
URN Schemes. If the original idea is not, could you point out the
issues?
Dion: You then also get into the how do
Chris Holland: But you're right, this is all a lot of end-user
intervention: it would
be a slightly, err, very painful process of installing a browser
plugin, which is currently very-much of a user opt-in process, and not
something very practical.
[...]. I'm just trying to find ways to
On Mon, Jun 15, 2009 at 1:09 PM, Joseph Pecoraro
joepec...@gmail.com wrote:
Dion: The problem here is that isn't backwards compatible and thus
no-one will really be able to use it.
I thought the original idea was backwards compatible. Maybe not the
URN Schemes. If the original idea
c) fun things would happen with a SHA collision! ;)
c) Hehe, I think I detect a hint of sarcasm. If there is a SHA1
collision then you'd probably make a lot of money!
C is a serious concern. SHA-1 collisions are now 2^51 -
http://eprint.iacr.org/2009/259.pdf
This time I didn't detect
In the event of a collision there would be huge issues - imagine
running
someone else's script in your application. Basically XSS - someone
could
take over your app, steal passwords, do bank transactions on your
behalf,
etc.
Collisions are made easier in plain text than in certs given that
35 matches
Mail list logo
