Re: [whatwg] Media queries, viewport dimensions, srcset and picture
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 (in addition to src, or instead of it? I am not sure). Then you could do stuff like this: picture source media=(orientation:landscape) srcset=long.jpg 1x, long2.jpg 2x source media=(orientation:portrait) srcset=tall.jpg 1x, tall2.jpg 2x img src=fallback.jpg / /picture Yesterday I made a similar proposal in an other thread: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/036143.html Yes, indeed, this seems to be exactly the same proposal. Sorry for not noticing you had already made it. I'd like to suggest that @srcset in this form would also be suitable for the img element, to address the optimization use case (without art direction) without the verbosity of picture. Sure, sorry for not being very clear about that. In my mind, @srcset would apply to both img and source. If you need media queries (to detecte portrait vs landscape, the viewport size, color depth...), you go with: picture source media=... srcset=... source media=... srcset=... source media=... srcset=... img src=... picture But if you don't need media queries, and only want images that adapt to the resolution and bandwidth, you do this one: img src=... srcset=... - Florian
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
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 a device is not a guarantee of suitability of an image at a given physical size. This solution seems to take the art-directed aspect out of the equation. Just because there's enough resolution on the device does not mean that the image itself is suitable at the size the device is outputting the image. Without some form of other qualifier you end up in a situation where an iPhone 4 with it's retina display will load an image intended for a device twice as big. Now, unless you've got perfect eyesight that image will be displayed at the correct resolution, but *half the size* on an iPhone 4. That's going to be a problem for some users, especially older users. There needs to maintain an art-directed aspect, and it doesn't seem possible for a device to have the required intelligence to know which image is appropriate based solely on the device's pixel density and a collection of images at given dimensions. Maybe I am misunderstanding you, but if I am not, my proposal addresses this need. You'd write it something like this: picture source srcset=normal.jpg 1x, highres.jpg 2x source media=(max-width:768px) srcset=ipad.jpg 1x, ipad3.jpg 2x source media=(max-width:320px) srcset=iphone.jpg 1x, iphone4.jpg 2x img src=normal.jpg /picture You would use the media attribute of the source element to create arbitrarily complex media queries for your art-directed decisions, and use the srcset on the same element to provide various resolutions. - Florian
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
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 for src vs srcset with a single source and no density qualifier, but yes, one of them should be available. - Florian
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
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 through all picture elements throughout the site to adjust them to fit the new design. This is to my mind a major problem which stops any such solution from being a general-purpose solution. I'd be ok for one-off special uses, but I can't write website's that I know to be future un-friendly - that's just storing up problems for the future. -Matt [re-posted to the group, I'd hit reply and not reply-all, sorry!]
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
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 re-design a site an author is going to have to trawl through allpicture elements throughout the site to adjust them to fit the new design. This is to my mind a major problem which stops any such solution from being a general-purpose solution. I'd be ok for one-off special uses, but I can't write website's that I know to be future un-friendly - that's just storing up problems for the future. This is true only for the art-direction use case, as MQs are removed from the optimization use case. Unless a new proposal comes up that solves this issue, too, I think this is something we can live with, for two reasons: - The art direction use case is somehow at the edge between content and design. Serving a cropped version of an image is actually dealing with content, even if it is about the design situation. - New designs usually require other image dimensions, meaning that images have to be recreated anyway. In my practice I have seen several redesigns of websites; none of them was restricted to CSS, in all cases, the whole websites were rebuilt, or at least the content was entirely reviewed. (My experience is very much focused on corporate situations, so this may be different in other fields such as academic.)
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
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 oldpicture and srcset, this means that when it's time to re-design a site an author is going to have to trawl through allpicture elements throughout the site to adjust them to fit the new design. This is to my mind a major problem which stops any such solution from being a general-purpose solution. I'd be ok for one-off special uses, but I can't write website's that I know to be future un-friendly - that's just storing up problems for the future. This is true only for the art-direction use case, as MQs are removed from the optimization use case. Yep, I can see that's the case :) Unless a new proposal comes up that solves this issue, too, I think this is something we can live with, for two reasons: - The art direction use case is somehow at the edge between content and design. Serving a cropped version of an image is actually dealing with content, even if it is about the design situation. 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 viewport we are actually hooking into the design itself rather than being able to automate things based on how much room is there for this image?. However it's cut, future maintenance is going to be a problem. - New designs usually require other image dimensions, meaning that images have to be recreated anyway. That's true, but the problem isn't so much that as it is that there will be different breakpoints. It's unlikely we'd be working with the same breakpoints, so the one's in the mark-up are all wrong. Leading to incorrect image selection. It's not trivial to revisit all mark-up to correct this. In my practice I have seen several redesigns of websites; none of them was restricted to CSS, in all cases, the whole websites were rebuilt, or at least the content was entirely reviewed. This always happens at the agency where I work too, but we also tend to keep an awful lot of the existing content even if we re-shuffle the organisation. There's a lot of existing content that will be re-used in new designs, and as before: while it's easy to change overall template aspects like div structure, it's an entirely different matter to go editing detailed *parts* of content like embedded images. (My experience is very much focused on corporate situations, so this may be different in other fields such as academic.) We do academic, corporate, personal, all sorts. We almost always end up keeping content (but it's nice on the occasions where we dont!)
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
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 viewport we are actually hooking into the design itself rather than being able to automate things based on how much room is there for this image?. However it's cut, future maintenance is going to be a problem. - New designs usually require other image dimensions, meaning that images have to be recreated anyway. That's true, but the problem isn't so much that as it is that there will be different breakpoints. It's unlikely we'd be working with the same breakpoints, so the one's in the mark-up are all wrong. Leading to incorrect image selection. It's not trivial to revisit all mark-up to correct this. Once CSS variables are available, would it be possible to reference them from the @media attribute? Given a variable breakpoint1 is defined in the CSS file: source media=(min-width:var(breakpoint1)) srcset=tall.jpg 1x, tall2.jpg 2x
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
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 than the space into which an image is sitting. Because we can only sense the viewport we are actually hooking into the design itself rather than being able to automate things based on how much room is there for this image?. However it's cut, future maintenance is going to be a problem. - New designs usually require other image dimensions, meaning that images have to be recreated anyway. That's true, but the problem isn't so much that as it is that there will be different breakpoints. It's unlikely we'd be working with the same breakpoints, so the one's in the mark-up are all wrong. Leading to incorrect image selection. It's not trivial to revisit all mark-up to correct this. Once CSS variables are available, would it be possible to reference them from the @media attribute? Given a variable breakpoint1 is defined in the CSS file: source media=(min-width:var(breakpoint1)) srcset=tall.jpg 1x, tall2.jpg 2x CSS variables as proposed can't work like that, as they rely on the cascade. - Florian
[whatwg] proposal for a location.domain property
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 that a page is from a
given domain. For example, if a script that might run on *.example.com,
*.example.co.uk etc can do
if(location.domain.indexOf('example.'==0) to check whether it runs on an
*.example.* site (and not get a false positive match on
example.exmple.com).
2) Checking what the shortest possible string for document.domain is.
3) Set cookies for all servers in a domain easily from JS without specific
string operations on the hostname
Thoughts?
--
Hallvord R. M. Steen
Core tester, Opera Software
Re: [whatwg] proposal for a location.domain property
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
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 that a page is from a given
domain. For example, if a script that might run on *.example.com,
*.example.co.uk etc can do
if(location.domain.indexOf('example.'==0) to check whether it runs on an
*.example.* site (and not get a false positive match on example.exmple.com).
2) Checking what the shortest possible string for document.domain is.
3) Set cookies for all servers in a domain easily from JS without specific
string operations on the hostname
Thoughts?
--
Hallvord R. M. Steen
Core tester, Opera Software
Re: [whatwg] proposal for a location.domain property
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 to
become an attractive nuisance that pulls developers in the wrong direction.
- Maciej
On May 24, 2012, at 10:56 AM, Adam Barth w...@adambarth.com wrote:
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
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 that a page is from a given
domain. For example, if a script that might run on *.example.com,
*.example.co.uk etc can do
if(location.domain.indexOf('example.'==0) to check whether it runs on an
*.example.* site (and not get a false positive match on example.exmple.com).
2) Checking what the shortest possible string for document.domain is.
3) Set cookies for all servers in a domain easily from JS without specific
string operations on the hostname
Thoughts?
--
Hallvord R. M. Steen
Core tester, Opera Software
Re: [whatwg] proposal for a location.domain property
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 domain-based limits because otherwise limits are easily worked around using subdomains. At least that's the way we try to do it in Gecko. Looking at our (Mozilla's) internal uses of getBaseDomain(), it's used for: * cookies * various site identity UI bits (e.g. highlighting the TLD+1 in the URL bar, the thing to show as the site identifier in various prompts, and so forth) * something about deciding whether to send CSP error reports * third-party determination (mostly cookies again, I suspect) * document.domain setting * Clearing per-site plugin data (see cookies) * localStorage quota enforcement * Something with caps on number of concurrent DOM workers * The URL bar autosuggest implementation I agree that it's not entirely clear how much of this is relevant to the web at large. Web apps that need this functionality (e.g. the browser in B2G) _can_ always import the eTLD list, if forced to -Boris
Re: [whatwg] register*Handler and Web Intents
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. open or edit, default share type=image/png MIME type filter [1], default */* scheme=mailto Scheme filter [1] [2], default omitted href= Handler URL [2], default title=Foo Handler user-visible name, required attribute disposition= replace, new, or overlay, default overlay /intent [1] Only one of type= and scheme= is allowed. [2] scheme= is only allowed if href= contains %s. The API could be something like: void registerIntentHandler(DOMString action, DOMString type, DOMString url, DOMString title, DOMString disposition); DOMString isIntentHandlerRegistered(DOMString action, DOMString type, DOMString url); void unregisterIntentHandler(DOMString action, DOMString type, DOMString url); The disposition of registerContentHandler() and registerProtocolHandler() would always be replace. The /url/ argument of registerProtocolHandler() would not be allowed to contain %s. Here's a slightly altered suggestion. There'd be three imperative registration APIs and three permissible intent tag configurations: For web intents services: intent action=a type=t href=u ... (that is, both action and type required, scheme disallowed) void registerIntentHandler(a, t, u, ...); // and unregister for protocol handler services: intent scheme=s href=u ... (scheme required, action and type disallowed) void registerProtocolHandler(s, u, ...); // and unregister for content handler services: intent type=t href=u ... (type required, action and scheme disallowed) void registerContentHandler(t, u, ...); // and unregister intent tags without these permissible permutations of scheme|action|type attributes must be ignored. Some more concordance moves to make them more like different aspects of the same feature: * In registerContentHandler, t can be a space-separated list of MIME types for registerContentHandler. * Let's think through why we'd need to limit the dispositions of the case of RPH/RCH to disposition=replace. Can't we achieve backwards compatibility by specifying that those cases default to disposition=replace? This would make it straightforward to get a nice style of navigational interaction with web intents -- RPH-style invocations can be handled by any of the disposition transitions. (i.e. a mailto handler that did all it's work in an overlay, which is frequently very desirable). * Add a couple more legal permutations: adding 'action=view' to the RPH/RCH registration intent tags would mean that the payload gets delivered using web intents instead of through %s-substitution. The RPH/RCH APIs wouldn't expose this. (This is very useful for offline.) These aren't large modifications, and in general just increase forward compatibility by making it more clear how to get more functionality out of RPH/RCH by using declarative registration, and blending those cases into the intents-based implementation. -Greg
[whatwg] Detecting eventListeners
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 way to determine if an element has an eventListener attached to it, created via addEventListener. There is a sure way to remove an event (via removeEventListener), but we want to enter some code path if and only if an element has an event registered, without altering its eventListener. This is currently not possible. Many discussions about this topic has been raised in the past. This Stackoverflow answer has a good summary: http://stackoverflow.com/questions/7810534/have-any-browsers-implemented-the-dom3-eventlistenerlist 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? We are also happy to hear workarounds, if anyone has previously encountered this issue and found a way. Cheers, Xav
Re: [whatwg] Detecting eventListeners
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, 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 custom event libraries such as jQuery's. As far as we can tell, there is no way to determine if an element has an eventListener attached to it, created via addEventListener. There is a sure way to remove an event (via removeEventListener), but we want to enter some code path if and only if an element has an event registered, without altering its eventListener. This is currently not possible. Many discussions about this topic has been raised in the past. This Stackoverflow answer has a good summary: http://stackoverflow.com/questions/7810534/have-any-browsers-implemented-the-dom3-eventlistenerlist 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? We are also happy to hear workarounds, if anyone has previously encountered this issue and found a way. Cheers, Xav
Re: [whatwg] Detecting eventListeners
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 event listener exists, not to remove it. However, you could use some prototyping tricks to make this work (hint: overload Node.prototype.addEventListener) We could add 1000 lines of code that overrides every single addEventListener on any arbitrary HTMLNode. That's a great solution. Tongue-in-cheekly yours, Xav On Fri, May 25, 2012 at 10:34 AM, 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 custom event libraries such as jQuery's. As far as we can tell, there is no way to determine if an element has an eventListener attached to it, created via addEventListener. There is a sure way to remove an event (via removeEventListener), but we want to enter some code path if and only if an element has an event registered, without altering its eventListener. This is currently not possible. Many discussions about this topic has been raised in the past. This Stackoverflow answer has a good summary: http://stackoverflow.com/questions/7810534/have-any-browsers-implemented-the-dom3-eventlistenerlist 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? We are also happy to hear workarounds, if anyone has previously encountered this issue and found a way. Cheers, Xav
Re: [whatwg] Detecting eventListeners
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 this easily. That's not what I'm asking. I'm asking to check if an event listener exists, not to remove it. But once the door is open, there is no way to close it. However, you could use some prototyping tricks to make this work (hint: overload Node.prototype.addEventListener) We could add 1000 lines of code that overrides every single addEventListener on any arbitrary HTMLNode. That's a great solution. Please save the dramatics, it would hardly take 1000 lines of code to accomplish this. I suspect there is likely a simpler alternative solution to your problem - that doesn't involve new spec features. Rick Tongue-in-cheekly yours, Xav On Fri, May 25, 2012 at 10:34 AM, 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 custom event libraries such as jQuery's. As far as we can tell, there is no way to determine if an element has an eventListener attached to it, created via addEventListener. There is a sure way to remove an event (via removeEventListener), but we want to enter some code path if and only if an element has an event registered, without altering its eventListener. This is currently not possible. Many discussions about this topic has been raised in the past. This Stackoverflow answer has a good summary: http://stackoverflow.com/questions/7810534/have-any-browsers-implemented-the-dom3-eventlistenerlist 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? We are also happy to hear workarounds, if anyone has previously encountered this issue and found a way. Cheers, Xav
Re: [whatwg] Detecting eventListeners
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
Re: [whatwg] Detecting eventListeners
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 save the dramatics, it would hardly take 1000 lines of code to accomplish this. I suspect there is likely a simpler alternative solution to your problem - that doesn't involve new spec features. I hope so too. I will add however that override an injection on the top of the page isn't a robust solution, because we want to run our scripts on any arbitrary internal sites. Cheers, Xav
Re: [whatwg] Detecting eventListeners
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 on page submission, event triggers, and form input. A very common use-case is to record a mouse click on a DOM element which may fire an event on the page. We want to capture clicks that actually triggered an event, does a HTTP request, and so on, but not meaningless clicks on an empty region. That said, there is no way of surely determining if a click is meaningful. We check if the DOM element clicked on is a button, a link (has href), has onclick attribute set, and so on. However, this will fail on sites that binds 'click' via 'addEventListener' on a strange element, like a span or a em tag. We are developing this script for user training and customer tutorials -- a playback script that moves the mouse, types in forms, interacts with the webpage -- which so far is almost complete. Feel free to ask any questions. I'm the main developer on this project. Cheers, Xav
Re: [whatwg] Detecting eventListeners
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 custom event libraries such as jQuery's. As far as we can tell, there is no way to determine if an element has an eventListener attached to it, created via addEventListener. There is a sure way to remove an event (via removeEventListener), but we want to enter some code path if and only if an element has an event registered, without altering its eventListener. This is currently not possible. Many discussions about this topic has been raised in the past. This Stackoverflow answer has a good summary: http://stackoverflow.com/questions/7810534/have-any-browsers-implemented-the-dom3-eventlistenerlist 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? We are also happy to hear workarounds, if anyone has previously encountered this issue and found a way. Cheers, Xav
Re: [whatwg] Detecting eventListeners
)-@impact) u On May 24, 2012 6:35 PM, Xavier Ho cont...@xavierho.com wrote:
Re: [whatwg] Detecting eventListeners
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 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);
is guaranteed to have no side-effects and to do nothing at all. Making
event listeners enumerable would remove that property.
I'm not personally concerned about that invariant, and I've wanted this in
the past myself (though honestly I don't recall off-hand what for).
On Thu, May 24, 2012 at 9:33 PM, Jason Edward 今井 Parrott
parrott.ja...@gmail.com wrote:
Personally, I wouldn't want some random library listening and
possibly forcibly removing my event listeners.
Some bad script could do this easily.
You always have to trust other scripts running in the same context. It
doesn't make sense to limit APIs by pretending that you don't.
On Thu, May 24, 2012 at 10:00 PM, Xavier Ho cont...@xavierho.com wrote:
The door's already open. You simply have to iterate through all the
nodes, and call removeEventListener with all possible events.
Actually, you can't, since you can't remove an event without a reference to
the callback to pass to removeEventListener.
On Thu, May 24, 2012 at 10:07 PM, Xavier Ho cont...@xavierho.com wrote:
A very common use-case is to record a mouse click on a DOM element which
may fire an event on the page. We want to capture clicks that actually
triggered an event, does a HTTP request, and so on, but not meaningless
clicks on an empty region.
That said, there is no way of surely determining if a click is meaningful.
We check if the DOM element clicked on is a button, a link (has href), has
onclick attribute set, and so on. However, this will fail on sites that
binds 'click' via 'addEventListener' on a strange element, like a span or
a em tag.
This will also fail if the event handler is up the node tree. That's very
common with the event delegation pattern, where a capturing event listener
for is registered for a container object (even on the document). You have
no way of knowing whether it'll actually do anything for any particular
element. I don't think this is a realistic use case.
On Thu, May 24, 2012 at 10:25 PM, Mani manips2...@gmail.com wrote:
)-@impact) u
(Alcohol?)
--
Glenn Maynard
Re: [whatwg] Detecting eventListeners
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);
is guaranteed to have no side-effects and to do nothing at all. Making
event listeners enumerable would remove that property.
Interesting. Thanks for sharing it. I can't think of a good reason why
this guarantee is useful, though.
I'm not personally concerned about that invariant, and I've wanted this in
the past myself (though honestly I don't recall off-hand what for).
Good to hear.
On Thu, May 24, 2012 at 9:33 PM, Jason Edward 今井 Parrott
parrott.ja...@gmail.com wrote:
On Thu, May 24, 2012 at 10:00 PM, Xavier Ho cont...@xavierho.com wrote:
The door's already open. You simply have to iterate through all the
nodes, and call removeEventListener with all possible events.
Actually, you can't, since you can't remove an event without a reference
to the callback to pass to removeEventListener.
Strange. I'm under the impression that simply calling
element.removeEventListener('click')
works, but that might have been my misunderstanding. I'll have to
experiment a little to make sure my understanding is correct.
On Thu, May 24, 2012 at 10:07 PM, Xavier Ho cont...@xavierho.com wrote:
A very common use-case is to record a mouse click on a DOM element which
may fire an event on the page. We want to capture clicks that actually
triggered an event, does a HTTP request, and so on, but not meaningless
clicks on an empty region.
That said, there is no way of surely determining if a click is meaningful.
We check if the DOM element clicked on is a button, a link (has href),
has
onclick attribute set, and so on. However, this will fail on sites that
binds 'click' via 'addEventListener' on a strange element, like a span
or
a em tag.
This will also fail if the event handler is up the node tree. That's very
common with the event delegation pattern, where a capturing event listener
for is registered for a container object (even on the document). You have
no way of knowing whether it'll actually do anything for any particular
element. I don't think this is a realistic use case.
We already handle this for a number of libraries like jQuery. This is
easily solved by traversing towards the root node and look for patterns
that match the library version. Having read-access to eventListeners on
elements would have made it much easier, though!
Cheers,
Xav
Re: [whatwg] Detecting eventListeners
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
Re: [whatwg] Detecting eventListeners
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 passed to addEventListener to remove the listener. I stand corrected. Cheers, Xav
Re: [whatwg] Detecting eventListeners
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 EventTarget {
boolean hasEventListener(DOMString type);
};
On Thu, May 24, 2012 at 10:07 PM, Xavier Ho cont...@xavierho.com wrote:
A very common use-case is to record a mouse click on a DOM element which
may fire an event on the page. We want to capture clicks that actually
triggered an event, does a HTTP request, and so on, but not meaningless
clicks on an empty region.
That said, there is no way of surely determining if a click is
meaningful.
We check if the DOM element clicked on is a button, a link (has href),
has
onclick attribute set, and so on. However, this will fail on sites that
binds 'click' via 'addEventListener' on a strange element, like a span
or
a em tag.
This will also fail if the event handler is up the node tree. That's very
common with the event delegation pattern, where a capturing event listener
for is registered for a container object (even on the document). You have
no way of knowing whether it'll actually do anything for any particular
element. I don't think this is a realistic use case.
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 never heard by script in the page can trigger dispatch of an
event that is heard by script. For example, a click event that bubbles
to a label element generates a synthetic click event on whatever the
label points to. It is possible for a page to have no event listeners
that see the first click, but have event listeners that see the second. I
think you really need to let the browser run event dispatch for all events
here.
- Kyle
Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry
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 the number of dropped files is
very huge.
This feels like the wrong optimization. It's making this API more
cumbersome for all users, for an unlikely case: selecting tons of
individual files that can't be stat()'d quickly. Usually, files that are
being dropped have been accessed recently (by the windowing system, when
the user selected the files), so they're almost always going to be in
cache. I think in practice, delay indefinitely is an exaggeration.
I wasn't fully convinced by the idea of making
dataTransferItem.getAsEntry() synchronous, but per recent File with
modification discussion on public-webapps it looks like we're likely
shifting the timing when to grab the file metadata to the timing of File
object creation, and it sounds like it'll match with what you're proposing
here.
That is:
- The UA grab file metadata along with file path when a file is dragged and
dispatches a drag event.
- When DataTransferItem.files, getAsFile or getAsEntry are called, the UA
instantiate a snapshot File object using the captured metadata, or
instantiate a FileEntry or DirectoryEntry based on the type information in
the metadata.
We (Chrome) are not yet ready to grab file metadata at file drag timing but
until then we can probably make a synchronous query just to get the
file/directory type information when getAsEntry() is called (and therefore
it won't affect any other APIs).
If we keep it asynchronous the Web page could have more control over which
to instantiate when, e.g. it could only show the` first few items upon drop
and then keep loading more items asynchronously only when necessary.
That's what DirectoryEntry is for. Adding yet another asynchronous API
layer on *top* of Entry to allow dropping lots of individual files feels
like an overcomplication, especially when most of the time, even doing that
with thousands of files would still be very fast.
It also makes it a lot harder to push file work to workers. This:
elem.ondrop = function(e) {
worker.postMessage({entries: e.dataTransfer.entries})
}
becomes something like this:
elem.ondrop = function(e) {
var items = e.dataTransfer.items;
var nextEntry = 0;
var entries = [];
var gotEntry = function(ent) {
if(ent != null)
entries.push(ent);
if(nextEntry == items.length) {
worker.postMessage({entries: entries});
return;
}
e.dataTransfer[nextEntry].getAsEntry(gotEntry);
++nextEntry;
}
gotEntry(null);
}
The point of using workers here would be to avoid all this (with sync
APIs)...
On Mon, Apr 9, 2012 at 12:21 PM, Eric U er...@google.com wrote:
It might make more sense to store a URL or other locator for the file,
to make it clear that you're storing a reference, not the data itself.
I suppose that storing an Entry could be like storing a capability
[permission to access the file], but that's for the other discussion.
That's how I've always viewed Entry (and File): its existence in your
context is what gives you access to the file it represents. URLs can't do
that.
--
Glenn Maynard
Re: [whatwg] Detecting eventListeners
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 never heard by script in the page can trigger dispatch of an event that is heard by script. For example, a click event that bubbles to a label element generates a synthetic click event on whatever the label points to. It is possible for a page to have no event listeners that see the first click, but have event listeners that see the second. I think you really need to let the browser run event dispatch for all events here. I was going to begin this reply by saying Yes, we also covered label and the 'for' property, but that doesn't seem to contribute to the conversation, heh. Still valid points, though. We've done a lot of work looking at all the possible ways of events firing and covered most of them. If this project was for a particular website, we would have done what many people do -- inject our own version of addEventListener and watch it go -- but it is not the case. All of our pages are sandboxes in an iframe and loaded that way, and we sometimes do not have control over what can be in the page -- i.e. sites we own but not directly developed by our team. Something like a hasEventListener(DOMElement elem) will help us a lot with what we've done, and we can check for delegates by looking at parent nodes, siblings, as well as synthetic events. They are well-documented. Cheers, Xav
