On Fri, Jun 17, 2011 at 2:45 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/17/11 1:39 AM, Roland Steiner wrote:
Having another scoped stylesheet under an element further up.
Why does that matter for the way rules in _this_ sheet are treated?
On Fri, Jun 17, 2011 at 4:10 PM, Roland Steiner rolandstei...@google.comwrote:
On Fri, Jun 17, 2011 at 2:45 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/17/11 1:39 AM, Roland Steiner wrote:
Having another scoped stylesheet under an element further up.
Why does that matter for the way
On Fri, Jun 17, 2011 at 4:33 AM, Ojan Vafai o...@chromium.org wrote:
On Thu, Jun 16, 2011 at 12:09 PM, Ryosuke Niwa rn...@webkit.org wrote:
Yes, I think all selection modified by user should be normalized by
default.
I'm talking more about programmatically set selection. I think we'll
On Thu, Jun 16, 2011 at 12:33 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, Jun 16, 2011 at 12:09 PM, Ryosuke Niwa rn...@webkit.org wrote:
Yes, I think all selection modified by user should be normalized by
default.
I'm talking more about programmatically set selection. I think we'll
Sean, thanks for the suggestion. I have the following comments (my first
comment on here, please instruct me if I get the style wrong):
Why? The server can first try comparing the submitted password to the
stored hash, then if that fails, hash the submitted password and compare
that to
On 2011-06-17 09:36, Roland Steiner wrote:
On Fri, Jun 17, 2011 at 4:10 PM, Roland Steinerrolandstei...@google.comwrote:
http://dev.w3.org/2006/webapi/selectors-api2/#the-scope-pseudo-class says:
The :scopehttp://dev.w3.org/2006/webapi/selectors-api2/#scope
pseudo-class *must* match any
Hi Mat,
The simple solution to your problem is: The server SHOULD still hash the
password it receives, before storing it in the database (i.e., the client
would send a hashed password, and the server would hash the hash). Ideally,
all servers should be doing this, with per-user salts. However,
On Fri, 27 May 2011 21:11:59 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
It looks like Gecko, Presto, and Webkit all support on* event attributes
on all DOM elements, not just HTMLElement.
IE9 seems to only support them on HTMLElement.
I would propose that these be supported on all Elements
Thanks Sean,
The server SHOULD still hash the password it receives, before storing it in
the database (i.e., the client would send a hashed password, and the server
would hash the hash)
I agree, but if the server-side hashing should be implemented regardless of
whether the client-side
On 6/17/11 8:49 AM, Anne van Kesteren wrote:
On Fri, 27 May 2011 21:11:59 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
It looks like Gecko, Presto, and Webkit all support on* event
attributes on all DOM elements, not just HTMLElement.
IE9 seems to only support them on HTMLElement.
I would
On 6/17/11 12:57 PM, Boris Zbarsky wrote:
On 6/17/11 8:49 AM, Anne van Kesteren wrote:
On Fri, 27 May 2011 21:11:59 +0200, Boris Zbarsky bzbar...@mit.edu
wrote:
It looks like Gecko, Presto, and Webkit all support on* event
attributes on all DOM elements, not just HTMLElement.
IE9 seems to
On 6/17/11 1:40 PM, Aryeh Gregor wrote:
At a minimum, for instance, we could guarantee that a selection's
boundary point is always in a Text or Element node that descends from
a Document. That would be a big simplification by itself. Does
anyone object to that?
At first blush, that seems
On Wed, Jun 15, 2011 at 8:42 PM, Ian Hickson i...@hixie.ch wrote:
Google Chrome 10 seems to fire popstate even if I open totally new page.
Firefox 4 seems to fire event only on going back/forward
How are you determining if Firefox fires the event? Are you sure you're
not just checking after
On Fri, 17 Jun 2011, Boris Zbarsky wrote:
On 6/17/11 12:57 PM, Boris Zbarsky wrote:
On 6/17/11 8:49 AM, Anne van Kesteren wrote:
On Fri, 27 May 2011 21:11:59 +0200, Boris Zbarsky bzbar...@mit.edu
wrote:
It looks like Gecko, Presto, and Webkit all support on* event
attributes on
On Fri, 17 Jun 2011, Mihai Parparita wrote:
On Wed, Jun 15, 2011 at 8:42 PM, Ian Hickson i...@hixie.ch wrote:
Google Chrome 10 seems to fire popstate even if I open totally new
page. Firefox 4 seems to fire event only on going back/forward
How are you determining if Firefox fires the
On Thu, Jun 16, 2011 at 5:39 PM, Daniel Cheng dch...@chromium.org wrote:
A variation of this idea has been proposed in the past but was largely seen
as undesirable--see
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026254.html. In
general, I feel like the same objections are
Since I've somehow managed to send from the wrong address again for
the third time in 48 hours, here's yet another resent mail, probably
to be followed by a fourth when I respond to Boris' response and Gmail
auto-selects my non-list address again for the from address instead of
my list address:
Thank you for your input. I had forgotten about the input type=image
fields.
Yes, as these issues have been brought up, I've also imagined additional
disadvantages as well. For documentation purposes, here are some additional
items to consider if this topic comes up again:
1. I'm not clear how
On Wed, 1 Jun 2011, ilya goberman wrote:
Can EventSource be enhanced to support cross-domain requests via
Access-Control-Allow-Origin header, just like it is already done for
XHR? See
http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests.
Done.
On Wed, 1 Jun 2011, Jonas
On Thu, 16 Jun 2011 19:32:42 +0100, Dimitri Glazkov
dglaz...@chromium.org wrote:
What if we do this:
1) By default, style scoped implies that all selectors in this
stylesheet are prefixed with :scope.
2) Unless the :scope is already in the selector.
That feels magical and a bit backwards
2011/6/17 Ian Hickson i...@hixie.ch:
On Fri, 17 Jun 2011, Mihai Parparita wrote:
On Wed, Jun 15, 2011 at 8:42 PM, Ian Hickson i...@hixie.ch wrote:
Google Chrome 10 seems to fire popstate even if I open totally new
page. Firefox 4 seems to fire event only on going back/forward
How are you
On Fri, Jun 17, 2011 at 12:57 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 1 Jun 2011, ilya goberman wrote:
Can EventSource be enhanced to support cross-domain requests via
Access-Control-Allow-Origin header, just like it is already done for
XHR? See
On Fri, 17 Jun 2011, Jonas Sicking wrote:
2011/6/17 Ian Hickson i...@hixie.ch:
On Fri, 17 Jun 2011, Mihai Parparita wrote:
On Wed, Jun 15, 2011 at 8:42 PM, Ian Hickson i...@hixie.ch wrote:
Google Chrome 10 seems to fire popstate even if I open totally new
page. Firefox 4 seems to fire
On Fri, 17 Jun 2011, Jonas Sicking wrote:
On Wed, 1 Jun 2011, Jonas Sicking wrote:
We should probably consider adding the ability to specify if you want
the request to happen with or without credentials (and default to the
safe option which is without credentials).
Why?
For the
On Fri, Jun 17, 2011 at 5:31 PM, ilya goberman gober...@msn.com wrote:
I do not really understand what specify the request to happen with
credentials really mean. Can someone explain or point to an example?
My opinion is that it should be the same for the XHR and EventSource and
should also be
25 matches
Mail list logo
