On Wed, 23 May 2012 21:48:39 +0200, Markus Ernst derer...@gmx.ch wrote:
Am 23.05.2012 17:21 schrieb Florian Rivoal:
Here's what I think we should do:
1) simplyfy srcset to only accept the *x qualifier
2) add support for srcset as an attribute of the source sub-element of
the picture element
On Wed, 23 May 2012 20:56:29 +0200, Matthew Wilcox
m...@matthewwilcox.com wrote:
I think this is a good step forward, however nless I am
mis-understanding something (entirely possible given how much has been
going on over this recently) there are problems still...
Resolution of an image and
On Wed, 23 May 2012 21:18:25 +0200, Scott Jehl sc...@scottjehl.com wrote:
With this proposal, could src be used on a source element if you don't
need the features srcset provides?
Or maybe, would that just be equivalent to srcset with a single source
listed?
I have no strong preference
Excellent, sorry I was not clear on that; this is looking good!
I would like to re-iterate that this solution is another which puts
design properties into mark-up directly, and just like old picture
and srcset, this means that when it's time to re-design a site an
author is going to have to trawl
Am 24.05.2012 10:27 schrieb Matthew Wilcox:
Excellent, sorry I was not clear on that; this is looking good!
I would like to re-iterate that this solution is another which puts
design properties into mark-up directly, and just like oldpicture
and srcset, this means that when it's time to
On 24 May 2012 09:45, Markus Ernst derer...@gmx.ch wrote:
Am 24.05.2012 10:27 schrieb Matthew Wilcox:
Excellent, sorry I was not clear on that; this is looking good!
I would like to re-iterate that this solution is another which puts
design properties into mark-up directly, and just like
Am 24.05.2012 11:13 schrieb Matthew Wilcox:
I agree, the problem is that... it's still a problem. It's not always
a cropped version, it's sometimes a different image entirely - but we
can only sense the viewport rather than the space into which an image
is sitting. Because we can only sense the
On Thu, 24 May 2012 11:35:35 +0200, Markus Ernst derer...@gmx.ch wrote:
Am 24.05.2012 11:13 schrieb Matthew Wilcox:
I agree, the problem is that... it's still a problem. It's not always
a cropped version, it's sometimes a different image entirely - but we
can only sense the viewport rather
Many browser engines use lists of top-level domains to be able to
determine what a server's base domain is. For some use cases it would be
interesting to have this information available to scripts. I list some use
cases I can think of below:
1) Determining in a simple and fool-proof manner
IMHO, we should be moving away from using the public suffix list in
the platform rather than adding more APIs that interact with it.
Adam
On Thu, May 24, 2012 at 8:35 AM, Hallvord R. M. Steen
hallv...@opera.com wrote:
Many browser engines use lists of top-level domains to be able to determine
I agree. Even though there are still legacy features like cookies and
document.domain that use domain-based security, most of the Web platform uses
origin-based security, and that has proved to be a sounder model. While I
acknowledge the use cases for exposing location.domain, it's also likely
On 5/24/12 5:02 PM, Maciej Stachowiak wrote:
I agree. Even though there are still legacy features like cookies and
document.domain that use domain-based security, most of the Web platform uses
origin-based security
For security, yes.
But for, say, resource limits, one wants to use
On Fri, Apr 20, 2012 at 10:35 AM, Greg Billock gbill...@google.com wrote:
Ian,
My suggestion then would be to add an element similar to what you suggest,
as well as an API similar to the existing one.
The element could be something like:
intent
action=edit intent action, e.g.
Hello,
We're working on a project that requires detection of registered event
listeners. Our targets are old-style onclick attribute bindings, events
registered via addEventListener (and the IE equivalent), and other custom
event libraries such as jQuery's.
As far as we can tell, there is no
Personally, I wouldn't want some random library listening and
possibly forcibly removing my event listeners.
Some bad script could do this easily.
However, you could use some prototyping tricks to make this work (hint:
overload Node.prototype.addEventListener)
On Fri, May 25, 2012 at 10:34 AM,
Hello Jason,
On 25 May 2012 12:33, Jason Edward 今井 Parrott parrott.ja...@gmail.comwrote:
Personally, I wouldn't want some random library listening and
possibly forcibly removing my event listeners.
Some bad script could do this easily.
That's not what I'm asking. I'm asking to check if an
On Thursday, May 24, 2012 at 10:45 PM, Xavier Ho wrote:
Hello Jason,
On 25 May 2012 12:33, Jason Edward 今井 Parrott parrott.ja...@gmail.comwrote:
Personally, I wouldn't want some random library listening and
possibly forcibly removing my event listeners.
Some bad script could do
On Thu, May 24, 2012 at 6:34 PM, Xavier Ho cont...@xavierho.com wrote:
Hello,
We're working on a project that requires detection of registered event
listeners.
I'll bite. Why do you care if an EventTarget has registered event
listeners or not?
- Kyle
Hello Rick,
Apologies, Jason.
On 25 May 2012 12:54, Rick Waldron waldron.r...@gmail.com wrote:
But once the door is open, there is no way to close it.
The door's already open. You simply have to iterate through all the
nodes, and call removeEventListener with all possible events.
Please
Hello Kyle,
On 25 May 2012 12:56, Kyle Huey m...@kylehuey.com wrote:
I'll bite. Why do you care if an EventTarget has registered event
listeners or not?
We're working on an internal script that does something similar to Selenium
IDE plugin on Firefox, which records user interactions based
París eh
On May 24, 2012 6:35 PM, Xavier Ho cont...@xavierho.com wrote:
Hello,
We're working on a project that requires detection of registered event
listeners. Our targets are old-style onclick attribute bindings, events
registered via addEventListener (and the IE equivalent), and other
)-@impact) u
On May 24, 2012 6:35 PM, Xavier Ho cont...@xavierho.com wrote:
On Thu, May 24, 2012 at 8:34 PM, Xavier Ho cont...@xavierho.com wrote:
As far as the author could tell, this feature was never implemented due to
a lack of a use-case. We have a use-case. Could someone share some
thoughts on this?
The basic argument against it is that attaching an event
Hello Glenn,
On 25 May 2012 13:27, Glenn Maynard gl...@zewt.org wrote:
The basic argument against it is that attaching an event listener that
doesn't do anything is currently guaranteed to be a complete no-op in all
cases. That is,
element.addEventListener(anything, function() { }, false);
On 5/24/12 11:00 PM, Xavier Ho wrote:
The door's already open. You simply have to iterate through all the
nodes, and call removeEventListener with all possible events.
No. removeEventListener needs the actual object that was passed to
addEventListener to remove the listener.
-Boris
On 25 May 2012 13:19, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/24/12 11:00 PM, Xavier Ho wrote:
The door's already open. You simply have to iterate through all the
nodes, and call removeEventListener with all possible events.
No. removeEventListener needs the actual object that was
On Thu, May 24, 2012 at 8:27 PM, Glenn Maynard gl...@zewt.org wrote:
Making event listeners enumerable would remove that property.
As I read it, he is not asking to enumerate event listeners. Simply to
know if there are any for the event in question. Something like
partial interface
Apologies for my late response.
On Tue, Apr 10, 2012 at 7:33 AM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Apr 9, 2012 at 3:35 AM, Kinuko Yasuda kin...@chromium.org wrote:
I don't think we should do this. The change would be invasive and could
delay firing a drop event indefinitely if
Hello Kyle,
On 25 May 2012 13:38, Kyle Huey m...@kylehuey.com wrote:
Yes, you would need to check the entire event dispatch chain for
listeners. At that point it may be easier just to fire the event and let
the browser figure it out. It's also possible that event dispatch of an
event that
29 matches
Mail list logo
