On Mon, 24 Aug 2009, Philip Jägenstedt wrote:
As far as I can see there's no good reason why createImageData should
take a float as input rather than unsigned long. Having it as float
creates the odd situation where (0.1, 0.1) gives a 1x1 ImageData while
(10.1, 10.1) gives a 10x10 or 11x11
On Aug 29, 2009, at 00:47, David Bennett wrote:
There currently is no way to detect the system idle state in the
browser. This makes it difficult to deal with any sort of chat room
or instant messaging client inside the browser since the idle will
always be incorrect.
How could such a
On Mon, 31 Aug 2009 08:08:05 +0200, Ian Hickson i...@hixie.ch wrote:
On Mon, 24 Aug 2009, Philip Jägenstedt wrote:
As far as I can see there's no good reason why createImageData should
take a float as input rather than unsigned long. Having it as float
creates the odd situation where (0.1,
On Tue, 25 Aug 2009, Alex Vincent wrote:
I read this paragraph (from section 4.10.15.3) as self-contradicting:
The validationMessage attribute must return the empty string if the
element is not a candidate for constraint validation or if it is one
but it satisfies its constraints;
On Tue, 25 Aug 2009, Peter Kasting wrote:
[...] However, I'm not sure why elements which are barred from
constraint validation (fieldset, output) have a setCustomValidity()
method; perhaps so that authors could blindly iterate over all
form-associated elements and call this method?
Yes,
On Tue, 25 Aug 2009, Andrew Oakley wrote:
Ian Hickson wrote:
I'm not sure exactly what change you mean. The spec already has some of
Gecko's behaviour (in particular the special-casing of certain MIME types
to enable sniffing), are there other changes you think we should include?
On Aug 29, 2009, at 00:47, David Bennett wrote:
There currently is no way to detect the system idle state in the
browser.
Henri Sivonen wrote:
How could such a notification be abused? The first abuse use case I can
think of is throttling Web Workers-based botnet computation to be less
On Tue, 25 Aug 2009, Jens Alfke wrote:
I've just noticed an apparent self-contradiction in the Web Storage spec (24
August draft).
Section 4.3 states:
Data stored in local storage areas should be considered potentially
user-critical. It is expected that Web applications will use the
On Mon, 31 Aug 2009 11:08:16 +0200, Ian Hickson i...@hixie.ch wrote:
On Tue, 25 Aug 2009, Andrew Oakley wrote:
Ian Hickson wrote:
I'm not sure exactly what change you mean. The spec already has some
of
Gecko's behaviour (in particular the special-casing of certain MIME
types
to enable
On Mon, Aug 31, 2009 at 1:55 AM, Philip Jägenstedt phil...@opera.comwrote:
I get the impression this has all been discussed before.
It has.
Still, it seems unlikely that any browser will ever be able to switch to
anything but a 1:1 CSS pixel:device pixel ratio, as that would break all
Philip Jägenstedt wrote:
In any event, judging by existing implementations, the behavior of
createImageData(w, h) isn't as clear as it needs to be:
Firefox:
Just to be clear, the Firefox code for this predates the spec text.
I would assume so does Webkit's.
Once we're actually trying
Ian Hickson wrote:
On Tue, 25 Aug 2009, Andrew Oakley wrote:
So if we had a type attribute of application/x-shockwave-flash, and a
Content-Type header of image/png we would use the flash plugin.
Following the HTML5 spec we would use the image renderer.
Ah, yes, that's intentional (doing
On Sun, Aug 30, 2009 at 10:42 PM, Jonas Sickingjo...@sicking.cc wrote:
The difference between input type=text and textarea is mostly a
rendering one. One scrolls the text when it can't fit, the other
wraps.
input type=text also can't contain newlines.
Of course, another solution would be to
Ian Hickson wrote:
On Fri, 21 Aug 2009, Mike Wilson wrote:
I'm currently wrapping my head around the notion of
first script in the spec [1]. It's description is
a bit terse and the subject seems non-trivial, so
maybe the text could be fleshed out some?
Section 6.1.5 Groupings
Ian Hickson wrote:
Given that all frames in a
browsing context have to be on the same thread,
regardless of domain, then unless we put all the
browsing contexts on the same thread, we can't
guarantee that all frames from the same domain
across all browsing contexts will be on the same
Jonas Sicking wrote:
On Sat, Aug 29, 2009 at 10:06 PM, Ian Hicksoni...@hixie.ch wrote:
Upon further consideration I've renamed getStorageUpdates() to
yieldForStorageUpdates().
I really liked Darin's (?) suggestion of allowStorageUpdates as that
seems to exactly describe the intended use
(Grabbing from the end...)
On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson i...@hixie.ch wrote:
implementation experience before specifying it. But I really don't think
it is the direction we should be taking the platform in. Granted,
programmers today don't want to use threads -- but, well,
On Aug 31, 2009, at 3:11 AM, Ian Hickson wrote:
We can't treat cookies and persistent storage differently, because
otherwise we'll expose users to cookie resurrection attacks.
Maintaining
the user's expectations of privacy is critical.
The fact that local storage can be used as a type of
On Mon, Aug 31, 2009 at 11:12 AM, Jeremy Orlow jor...@chromium.org wrote:
Yes, this is pretty disconcerting since there's been OVERWHELMING support
for LocalStorage being treated as user-critical on this thread.
The spec says basically what you want except that it uses should. It
seems like
On Mon, Aug 31, 2009 at 11:18 AM, Peter Kasting pkast...@google.com wrote:
On Mon, Aug 31, 2009 at 11:12 AM, Jeremy Orlow jor...@chromium.orgwrote:
Yes, this is pretty disconcerting since there's been OVERWHELMING support
for LocalStorage being treated as user-critical on this thread.
The
On Aug 31, 2009, at 11:18 AM, Peter Kasting wrote:
The spec says basically what you want except that it uses should.
It seems like UAs and authors would both be satisfied with this; I
don't expect any UA vendor to wantonly discard local storage data.
By encouraging the UI to treat local
On Aug 31, 2009, at 11:35 AM, Peter Kasting wrote:
Again, the spec now says in 4.3: User agents should expire data
from the local storage areas only for security reasons or when
requested to do so by the user. The only stronger statement you
could get would be by changing this to a must.
Jens Alfke wrote:
Local storage is a significant change from the browser's current data
model, and I think that (no offense) browser developers are not used to
taking care of user-critical data for longer than the duration of a DOM
tree or POST request. It's a change in perspective. Coming as
On Mon, Aug 31, 2009 at 11:50 AM, Jens Alfke s...@google.com wrote:
On Aug 31, 2009, at 11:35 AM, Peter Kasting wrote:
Again, the spec now says in 4.3: User agents should expire data from the
local storage areas only for security reasons or when requested to do so by
the user. The only
On Mon, Aug 31, 2009 at 6:11 AM, Ian Hicksoni...@hixie.ch wrote:
We can't treat cookies and persistent storage differently, because
otherwise we'll expose users to cookie resurrection attacks. Maintaining
the user's expectations of privacy is critical.
By that reasoning we can't treat cookies
04.08.2009, в 16:47, Ian Hickson написал(а):
I've added support for redirects. While I was at it I also added
support
for authentication.
Reading the authentication part of the latest draft, I had several
comments:
9. If the client has any authentication information ... that would
On Aug 31, 2009, at 11:58 AM, Boris Zbarsky wrote:
It's controversial because, no offense, browser developers don't
trust the website author, nor should the users. At least to a first
approximation.
Over on another thread of this list we've already been talking about
the need to get
On Sat, Aug 29, 2009 at 5:40 PM, Ian Hicksoni...@hixie.ch wrote:
Furthermore, consider performance going forward. CPUs have pretty much
gotten as fast as they're getting -- all further progress is going to be
in making multithreaded applications that use as many CPUs as possible. We
should
Quoting Ian Hickson i...@hixie.ch:
On Tue, 25 Aug 2009, Jens Alfke wrote:
Potential result: I was having trouble logging into FooDocs.com,
so my friend
suggested I delete the cookies for that site. After that I could log in, but
now the document I was working on this morning has lost all
+1, I like this approach for its simplicity and familiarity.
As part of fleshing out, there are probably a few small but key additions
that would greatly increase effectiveness:
- update frequency (knowing the sample rate is crucial for even the most
trivial DSP operations such as filtering)
On Mon, Aug 31, 2009 at 2:01 PM, Jens Alfkes...@google.com wrote:
The fact that local storage can be used as a type of super-cookie doesn't
mean the two are the same thing. Yes, obviously if I give a website
permission to put 50MB of stuff on my disk, it can use 1k of that as a type
of cookie
On Mon, Aug 31, 2009 at 2:49 AM, Max Romantschuk m...@romantschuk.fi wrote:
On Aug 29, 2009, at 00:47, David Bennett wrote:
There currently is no way to detect the system idle state in the browser.
Henri Sivonen wrote:
How could such a notification be abused? The first abuse use case I
On Mon, Aug 31, 2009 at 6:08 PM, Aryeh Gregorsimetrical+...@gmail.com wrote:
On Mon, Aug 31, 2009 at 2:36 PM, Tab Atkins Jr.jackalm...@gmail.com wrote:
Outlawing persistent storage in HTML5 as a privacy mechanism does
*nothing* for privacy. There are numerous methods, Flash LocalStorage
in
On Mon, Aug 31, 2009 at 11:06 PM, Anne van Kesteren ann...@opera.comwrote:
Once we get huge screens and lots of processing power people can just blow
up the canvas grid and then scale it down with CSS. Works just as well and
makes the data more portable.
I think we can do better than that.
This would be a nice addition... seems like an event plus a read-only
property on the 'window' object could work.
window.idleState;
window.onidlestatechange = function(e) {...}
On Fri, Aug 28, 2009 at 3:40 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 28, 2009 at 2:47 PM, David
On Mon, Aug 31, 2009 at 5:30 PM, Drew Wilson atwil...@google.com wrote:
This would be my inclination as well. I'm not entirely convinced that
every web app should define their own idle timeout is such desirable
behavior that we should build our API around it by forcing every caller to
specify
36 matches
Mail list logo
