Also valueOf.
Adam
On Mon, Sep 24, 2012 at 10:10 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Turns out, some things care about at least the .href and .toString of
Location objects for security-check purposes. So they need to be
unforgeable. But of course WebIDL doesn't provide a way to make
On 9/25/12 2:24 AM, Adam Barth wrote:
Also valueOf.
We'd just need to add that on the interface to make it work, right?
-Boris
On 25/09/2012 01:07 , Glenn Maynard wrote:
On Mon, Sep 24, 2012 at 12:30 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
I suggest just making it a map from String-[String]. You probably
want a little bit of magic - if the setter receives an array, replace
the current value with it; anything
On 25 sept. 2012, at 13:48, Robin Berjon wrote:
On 25/09/2012 01:07 , Glenn Maynard wrote:
And round-tripping using ; as the separator instead of . I mention this
because I've seen actual production code (more than once) that relied on
this. I have no idea how common it is though. I'm
On Tue, Sep 25, 2012 at 9:48 PM, Robin Berjon ro...@w3.org wrote:
On 25/09/2012 01:07 , Glenn Maynard wrote:
On Mon, Sep 24, 2012 at 12:30 PM, Tab Atkins Jr.
jackalm...@gmail.comwrote:
I suggest just making it a map from String-[String]. You probably
want a little bit of magic - if the
On Tue, Sep 25, 2012 at 6:18 AM, Ian Hickson i...@hixie.ch wrote:
Not necessarily, but that's certainly possible. Personally I would
recommend that we not change the definition of what is conforming from the
current RFC3986/RFC3987 rules, except to the extent that the character
encoding
On Mon, Sep 24, 2012 at 11:31 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/25/12 2:24 AM, Adam Barth wrote:
Also valueOf.
We'd just need to add that on the interface to make it work, right?
I'm not sure what needs to be done in spec-land to make valueOf work
correctly, but in
On 9/25/12 12:54 PM, Adam Barth wrote:
I'm not sure what needs to be done in spec-land to make valueOf work
correctly, but in implementation-land it needs the same unforgability
mitigations as toString.
Well, one thing that needs to happen is that its behavior needs to be
specced. Should it
On Tue, Sep 25, 2012 at 10:15 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/25/12 12:54 PM, Adam Barth wrote:
I'm not sure what needs to be done in spec-land to make valueOf work
correctly, but in implementation-land it needs the same unforgability
mitigations as toString.
Well, one thing
On Mon, Sep 24, 2012 at 9:18 PM, Ian Hickson i...@hixie.ch wrote:
This is Anne's spec, so I'll let him give more canonical answers, but:
On Mon, 24 Sep 2012, David Sheets wrote:
Your conforming WHATWG-URL syntax will have production rule alphabets
which are supersets of the alphabets in
On Tue, Sep 25, 2012 at 8:03 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Sep 25, 2012 at 6:18 AM, Ian Hickson i...@hixie.ch wrote:
Not necessarily, but that's certainly possible. Personally I would
recommend that we not change the definition of what is conforming from the
current
On Tue, 25 Sep 2012, David Sheets wrote:
Not necessarily, but that's certainly possible. Personally I would
recommend that we not change the definition of what is conforming from
the current RFC3986/RFC3987 rules, except to the extent that the
character encoding affects it (as per the
On Tue, Sep 25, 2012 at 8:20 PM, David Sheets kosmo...@gmail.com wrote:
On Tue, Sep 25, 2012 at 8:03 AM, Anne van Kesteren ann...@annevk.nl wrote:
FWIW, given that browsers happily do requests to servers with
characters in the URL that are invalid per the RFC (they are not URL
escaped) and
On Thu, 16 Aug 2012, David Geary wrote:
It looks like there is general agreement that CSS filters should be
added to Canvas. Now how do we make it happen?
On Thu, 16 Aug 2012, Rik Cabanier wrote:
File a bug on it: [...]
Actually no need to file a bug, just mentioning it in this mailing
On Tue, Sep 25, 2012 at 12:55 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 16 Aug 2012, David Geary wrote:
It looks like there is general agreement that CSS filters should be
added to Canvas. Now how do we make it happen?
On Thu, 16 Aug 2012, Rik Cabanier wrote:
File a bug on it:
On Mon, Sep 24, 2012 at 7:18 PM, David Sheets kosmo...@gmail.com wrote:
Always. The appropriate interface is (string * string?) list. Id est,
an association list of keys and nullable values (null is
key-without-value and empty string is empty-value). If you prefer to
not use a nullable value
On Tue, Sep 25, 2012 at 2:13 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Sep 24, 2012 at 7:18 PM, David Sheets kosmo...@gmail.com wrote:
Always. The appropriate interface is (string * string?) list. Id est,
an association list of keys and nullable values (null is
key-without-value and
On 26 sept. 2012, at 00:14, David Sheets wrote:
On Tue, Sep 25, 2012 at 2:13 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Sep 24, 2012 at 7:18 PM, David Sheets kosmo...@gmail.com wrote:
The right approach is probably to expose the results in an object-like form,
as Tab suggests, but to
On Tue, Sep 25, 2012 at 5:14 PM, David Sheets kosmo...@gmail.com wrote:
Looking up keys is easy in an association list. Filtering the list
retains ordering. Appending to the list is well-defined. Folding into
a dictionary is trivial and key merging can be defined according to
the author's URL
Boris Zbarsky:
So we have indications that making everything on this
interface unforgeable is sufficiently web-compatible.
OK. I propose then that we allow [Unforgeable] on the interface, which
means:
* attributes get own, non-configurable accessor properties (with setters
if they are not
On Tue, Sep 25, 2012 at 4:58 PM, Cameron McCormack c...@mcc.id.au wrote:
Boris Zbarsky:
So we have indications that making everything on this
interface unforgeable is sufficiently web-compatible.
OK. I propose then that we allow [Unforgeable] on the interface, which
means:
* attributes
On 9/25/12 7:58 PM, Cameron McCormack wrote:
OK. I propose then that we allow [Unforgeable] on the interface, which
means:
* attributes get own, non-configurable accessor properties (with setters
if they are not readonly attributes), and no property on the prototype
* operations get own,
Boris Zbarsky:
I can live with this, but why is this better than just allowing
[Unforgeable] on all operations and attributes and defining an object
valueOf(); /* returns self */ on Location?
If we really do want to make all Location interface members be
unforgeable, then moving the
On 9/25/12 6:53 PM, Glenn Maynard wrote:
(Of course, a separate method could exist to get access to the underlying
order, if and when real use cases turn up that actually need it, and it's
not unlikely that there are use cases--but so far they haven't been
raised.
The obvious use case is
On 9/25/12 9:28 PM, Cameron McCormack wrote:
Boris Zbarsky:
I can live with this, but why is this better than just allowing
[Unforgeable] on all operations and attributes and defining an object
valueOf(); /* returns self */ on Location?
If we really do want to make all Location interface
Boris Zbarsky:
I guess the question is whether we're more likely to need [Unforgeable]
on some other entire interface or whether were more likely to need
[Unforgeable] on a single member that's not a readonly attribute. Of
course we might never need either one...
I'm inclined to simplify now
On 9/25/12 9:48 PM, Cameron McCormack wrote:
Boris Zbarsky:
I guess the question is whether we're more likely to need [Unforgeable]
on some other entire interface or whether were more likely to need
[Unforgeable] on a single member that's not a readonly attribute. Of
course we might never need
On Tue, Sep 25, 2012 at 8:36 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/25/12 6:53 PM, Glenn Maynard wrote:
(Of course, a separate method could exist to get access to the underlying
order, if and when real use cases turn up that actually need it, and it's
not unlikely that there are use
On 9/25/12 10:13 PM, Glenn Maynard wrote:
The obvious use case is constructing a URI with a given query by
hand, right?
If you already have the a=1b=2 string, you can just assign it to
.search and not use the prepared-query-parameters interface at all.
I was thinking more like you
On Tue, Sep 25, 2012 at 9:27 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/25/12 10:13 PM, Glenn Maynard wrote:
The obvious use case is constructing a URI with a given query by
hand, right?
If you already have the a=1b=2 string, you can just assign it to
.search and not use the
On 9/25/12 10:36 PM, Glenn Maynard wrote:
You usually don't care about the resulting order in that case, right?
It's not uncommon for servers to depend on a particular order of
parameters in the query string and totally fail when the ordering is
different. Especially the sort of servers
On Tue, Sep 25, 2012 at 9:53 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/25/12 10:36 PM, Glenn Maynard wrote:
You usually don't care about the resulting order in that case, right?
It's not uncommon for servers to depend on a particular order of
parameters in the query string and totally
On 9/25/12 11:15 PM, Glenn Maynard wrote:
What this doesn't allow is creating things like a=1b=2a=3
Ah. That should be relatively unlikely (though forms with checkboxes in
them can in fact lead to query strings like that).
-Boris
On Tue, 25 Sep 2012, Glenn Maynard wrote:
What this doesn't allow is creating things like a=1b=2a=3. You can
create a=1a=2b=3 (url.query.a = [1,2]; url.query.b = 3), but
there's no way to split the keys (a, b, a). This is the limitation we
were really talking about. This seems unlikely
34 matches
Mail list logo
