On Tue, 25 Aug 2009 02:19:55 +0200, TAMURA, Kent tk...@chromium.org wrote:
I'd like stricter rule for it. e.g.
dot-atom-text @ 1*(ALPHA / DIGIT) 1*(. 1*(ALPHA / DIGIT))
That does not work with IDNs.
--
Anne van Kesteren
http://annevankesteren.nl/
On Tue, 25 Aug 2009 00:29:06 +0200, Ian Hickson i...@hixie.ch wrote:
On Mon, 24 Aug 2009, Philip Jägenstedt wrote:
I've found two related things that are a bit problematic. First, because
itemprops are only associated with ancestor item elements or via the
subject attribute, it's always
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; otherwise, it must return a suitably
localized message
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?
Boris Zbarsky wrote (near the top of this thread):
Hi Oliver,
I agree as I'm unsure what else *could* be safely exposed
before the drop event -- realistically anything beyond the
types seems risky: ignoring the obvious risks of exposing
actual content, exposing any form of URI may lead to
unintended information leaking (you have to assume
On Tue, Aug 25, 2009 at 2:59 AM, Anne van Kesterenann...@opera.com wrote:
On Tue, 25 Aug 2009 02:19:55 +0200, TAMURA, Kent tk...@chromium.org wrote:
I'd like stricter rule for it. e.g.
dot-atom-text @ 1*(ALPHA / DIGIT) 1*(. 1*(ALPHA / DIGIT))
That does not work with IDNs.
Nor does the
On Tue, 25 Aug 2009 15:19:42 +0200, Aryeh Gregor
simetrical+...@gmail.com wrote:
Nor does the current spec, but it only restricts what the UA actually
submits, not what it accepts from the user.
Ah, that makes sense.
The spec suggests that
UAs convert IDNs to punycode for submission, which
On Tue, Aug 25, 2009 at 3:05 AM, Anne van Kesterenann...@opera.com wrote:
Also, maxlength cannot be enforced as client-side validation requirement due
to compatibility issues.
Hmm, I hadn't thought of that. You're right, that would provide
somewhat inconsistent behavior. On the other hand,
On Tue, Aug 25, 2009 at 3:05 AM, Anne van Kesterenann...@opera.com
wrote:
Also, maxlength cannot be enforced as client-side validation
requirement due to compatibility issues.
Hmm, I hadn't thought of that. You're right, that would provide
somewhat inconsistent behavior. On the other hand,
On Tue, Aug 25, 2009 at 12:05 AM, Anne van Kesteren ann...@opera.comwrote:
Also, maxlength cannot be enforced as client-side validation requirement
due to compatibility issues.
I don't grasp what you're saying here. Are you saying that maxlength or
ValidityState.tooLong() cannot be
On Tue, 25 Aug 2009 18:57:59 +0200, Peter Kasting pkast...@google.com
wrote:
On Tue, Aug 25, 2009 at 12:05 AM, Anne van Kesteren
ann...@opera.comwrote:
Also, maxlength cannot be enforced as client-side validation requirement
due to compatibility issues.
I don't grasp what you're saying
On Tue, Aug 25, 2009 at 12:50 AM, Alex Vincent ajvinc...@gmail.com wrote:
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; otherwise, it must return a suitably
localized
to associate items with its
parent item, just like for itemprop.
IMHO, this syntax is more copy-paste robust, favors the common cases
over the complex cases and makes the model more intuitive to those who
understand XML and/or DOM.
http://krijnhoetmer.nl/irc-logs/whatwg/20090825#l-469
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.orgwrote:
On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow
On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow jor...@chromium.org wrote:
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.orgwrote:
On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan
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
local storage areas for storing user-written
On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
It is important that all local state be treated as a cache. User
agents need to be free to garbage collect any local state. If they
can't then attackers (or the merely lazy) will be able to fill up
the user's disk. We can't expect web sites
On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson beid...@apple.com wrote:
On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
It is important that all local state be treated as a cache. User agents
need to be free to garbage collect any local state. If they can't then
attackers (or the merely lazy)
It is important that all local state be treated as a cache. User agents need
to be free to garbage collect any local state. If they can't then attackers
(or the merely lazy) will be able to fill up the user's disk. We can't
expect web sites or users to do the chore of taking out the garbage.
At 0:49 +1200 23/08/09, Robert O'Callahan wrote:
On Mon, Aug 17, 2009 at 8:04 PM, Max Romantschuk
mailto:m...@romantschuk.fim...@romantschuk.fi wrote:
Silvia Pfeiffer wrote:
Precision is influenced more strongly by the temporal
resolution of the decoding pipeline rather than the polling
On Aug 25, 2009, at 2:16 PM, Jeremy Orlow wrote:
On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson beid...@apple.com
wrote:
On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
It is important that all local state be treated as a cache. User
agents need to be free to garbage collect any local
On Tue, Aug 25, 2009 at 2:16 PM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson beid...@apple.com wrote:
On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
It is important that all local state be treated as a cache. User agents
need to be free to garbage
On Tue, Aug 25, 2009 at 2:40 PM, Brady Eidson beid...@apple.com wrote:
On Aug 25, 2009, at 2:16 PM, Jeremy Orlow wrote:
On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson beid...@apple.com wrote:
On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
It is important that all local state be treated as
Interesting comments. Linus and Jeremy appear to be coming at this
from a pure cloud perspective, where any important or persistent
data is kept on a remote server and the browser, so local storage can
be treated as merely a cache. That's definitely a valid position, but
from my
On Aug 25, 2009, at 3:09 PM, Jens Alfke wrote:
Interesting comments. Linus and Jeremy appear to be coming at this
from a pure cloud perspective, where any important or persistent
data is kept on a remote server and the browser, so local storage
can be treated as merely a cache. That's
The statement in section 4.3 doesn't appear to specify any behavior... its
just an informational statement.
The statement in section 6.1 suggests to prohibit the development of a UI
that mentions local storage as a distinct repository seperate from cookies.
This doesn't belong in the spec imho.
On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman a...@google.com wrote:
On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlowjor...@chromium.org wrote:
Ok, well I guess we should go ahead and have this discussion now. :-)
Does
anyone outside of Apple and Google have an opinion on the matter (since
On Tue, Aug 25, 2009 at 3:51 PM, Jeremy Orlowjor...@chromium.org wrote:
I still don't understand what use local storage has outside of 'cloud
storage'. Even in the extensions use case (which I think is out of scope
for this spec), there's no reason you can't sync user preferences and such
to
On Aug 25, 2009, at 3:31 PM, Michael Nordman wrote:
The statement in section 4.3 doesn't appear to specify any
behavior... its just an informational statement.
The statement in section 6.1 suggests to prohibit the development of
a UI that mentions local storage as a distinct repository
On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlowjor...@chromium.org wrote:
Ok, well I guess we should go ahead and have this discussion now. :-) Does
anyone outside of Apple and Google have an opinion on the matter (since I
think it's pretty clear where we both stand).
FWIW, I tend to agree
On Aug 25, 2009, at 3:51 PM, Jeremy Orlow wrote:
On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman a...@google.com wrote:
On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlowjor...@chromium.org
wrote:
Extensions are an example of an application that is less cloud-based.
It would be unfortunate and
Drew Wilson wrote:
Currently, SharedWorkers accept both a url parameter and a name
parameter - the purpose is to let pages run multiple SharedWorkers using
the same script resource without having to load separate resources from
the server.
Per section 4.8.3 of the SharedWorkers spec, if
On Tue, Aug 25, 2009 at 4:18 PM, Brady Eidson beid...@apple.com wrote:
On Aug 25, 2009, at 3:51 PM, Jeremy Orlow wrote:
On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman a...@google.com wrote:
On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlowjor...@chromium.org wrote:
Extensions are an example
On Tue, Aug 25, 2009 at 5:44 PM, Jeremy Orlowjor...@chromium.org wrote:
Ok, well I guess we should go ahead and have this discussion now. :-) Does
anyone outside of Apple and Google have an opinion on the matter (since I
think it's pretty clear where we both stand).
FWIW, I initially thought
On Tue, Aug 25, 2009 at 7:24 PM, Ian Hicksoni...@hixie.ch wrote:
Drew Wilson wrote:
Per section 4.8.3 of the SharedWorkers spec,
if a page loads a shared worker with a url and
name, it is illegal for any other page under the
same origin to load a worker with the same name
The idea here is
Hi,
I am trying to use the specification of Dates and times given in section
2.4.5.
I was surprised to find that there is a specification of a valid month
string, but not of a valid year string or a valid day string. Is that an
oversight?
Regards,
Silvia.
Hi all,
It's been a while. :)
Looking through the spec I see the following DOM properties:
* formNoValidate
* novalidate
* willValidate
novalidate sticks out like a sore thumb. Can we change it to
noValidate. It's only mentioned in the IDL so maybe it's a typo.
-dean
On Sun, 16 Aug 2009, Mike Wilson wrote:
Ian Hickson wrote:
On Wed, 5 Aug 2009, Nathan Hammond wrote:
I should have stated this one with a goal: the ability to ensure
that the popstate event always fires with a full understanding of
the (app/page) state when navigating through
On Tue, Aug 25, 2009 at 7:56 PM, Dean Edwards dean.edwa...@gmail.comwrote:
Looking through the spec I see the following DOM properties:
* formNoValidate
* novalidate
* willValidate
novalidate sticks out like a sore thumb. Can we change it to
noValidate. It's only mentioned in the IDL so
On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow jor...@chromium.org wrote:
To me, getStorageUpdates seems to imply that updates have already happened
and we're working with an old version of the data. I think many developers
will be quite shocked that getStorageUpdates _enables_ others to
On Tue, Aug 25, 2009 at 10:28 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow jor...@chromium.orgwrote:
To me, getStorageUpdates seems to imply that updates have already happened
and we're working with an old version of the data. I think many
41 matches
Mail list logo
