Re: [whatwg] Proposal for a tab visibility API
Hi,
Maybe we can disallow the visibilitychange event to produce any dialogs
or anything else that could give focus?
window.onvisibilitychange = function(e) {
setTimeout(function() {
alert(Worked around!);
}, 0);
};
Or would browsers be able to track that the code was initially
triggered from visibilitychange? (including when programmatically
creating and dispatching another DOM events, instead of or in addition
to the setTimeout?)
You don't have to track where call was coming from:
1. you just don't let the alert take the focus in windows that are not
visible or
2. you don't show it up at all until the visibility of the window
changes back to visible.
--
frank hellenkamp | interface designer
solmsstraße 7 | 10961 berlin
+49.30.49 78 20 70 | tel
+49.176.32 13 88 89 | mbl
+49.3212.100 35 22 | fax
jo...@depagecms.net
http://depage.net | bureau
http://depagecms.net | content management
http://immerdasgleiche.de | read
http://everydayisexactlythesame.net | see
signature.asc
Description: OpenPGP digital signature
Re: [whatwg] Processing the zoom level - MS extensions to window.screen
On 12/14/2010 9:51 PM, Simon Fraser wrote:
On Dec 14, 2010, at 10:22 AM, Charles Pritchard wrote:
On 11/24/2010 1:12 AM, Robert O'Callahan wrote:
On Wed, Nov 24, 2010 at 9:09 PM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
On 11/21/2010 4:12 PM, Robert O'Callahan wrote:
On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard
ch...@jumis.com mailto:ch...@jumis.com wrote:
Rob: Mobile deployments using dpiPixelRatio (as has been
adopted by Moz and Webkit) and target-DpiDensity work well
on the mobile, they are not hooked to zoom on the desktop,
It is in Firefox.
I just tested in 4b7, and it's not changing dpiPixelRatio.
Try this:
style
div { display:none; }
@media screen and (min--moz-device-pixel-ratio: 1.5) {
.in { display:block; }
}
@media screen and (max--moz-device-pixel-ratio: 0.) {
.out { display:block; }
}
/style
div class=inZoomed in by a factor of at least 1.5/div
div class=outZoomed out by a factor of at least 1.5/div
Try zooming in a lot and zooming out a lot. It works for me.
I've started working to get this behavior supported in webkit.
Do you have a bugs.webkit.org http://bugs.webkit.org bug about this
issue? It may be better to get consensus about how the feature should
work before you spend a lot of time implementing it.
Simon
I brought it up to the webkit-dev mailing list, and was told that it
should remain on the WHATWG:
https://lists.webkit.org/pipermail/webkit-dev/2010-November/015146.html
As stated in the thread: Most of us follow the WHATWG closely and
generally prefer to discuss standardization issues such as this in that
forum to get a broader feedback base.
Here's a bug report, for this particular issue:
https://bugs.webkit.org/show_bug.cgi?id=51190
Mozilla has agreed that such behavior is correct and asserted that it
is implemented in FF4.
They do not update window.devicePixelRatio, only the CSS selector metric:
Mozilla's policy on exposing screen metrics to the scripting environment
is that it must happen through matchMedium.
At this point, I'm trying to get the CSS selector fixed via Chromium.
The broader concept of exposing CSS pixel ratios is filed as an a11y issue.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11328
If you have any ideas, let me know. I'm rather frustrated on the issue,
and have
certainly frustrated several list members in the process.
-Charles
Re: [whatwg] Bluetooth devices
On 2010-12-15 18:02, Aryeh Gregor wrote: On Tue, Dec 14, 2010 at 10:12 AM, Bjartur Thorlacius svartma...@gmail.com wrote: I still don't grasp how that could be useful. Please provide an example. So you've got a non-kb, mouse, headphone or camera device, say a permanent storage drive. No, not something so general-purpose. Say it's some type of device where the market is so small that standardization is infeasible -- maybe it's only useful in a particular specialty, and there are only one or two low-volume vendors. Or maybe it's some new type of device where the market is uncertain and nothing has been standardized yet. Given that there's no standard high-level way to interact with the device, it might be desirable to have *some* way to interact with it, necessarily generic and low-level. Probably along the lines of sending and receiving binary messages. At least that's the general idea I get. I can't give any specific examples, but I don't think mass-market stuff like permanent storage drives is what we're talking about here. (We already have filesystem APIs in the works anyway, right?) Of course, more specific real-world use-cases would be necessary before anyone would consider speccing something like this. Something that specific would be better implemented as a browser plugin that wrap OS API or a OS driver's API functionality, if it becomes popular then one or more browser developers would probably be interested in supporting it without the need for a browser plugin/wrapper, at which point one just need to follow the guidelines that Ian posts here quite frequently to get it standardized. -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
[whatwg] CSSElementMap - updates needed for out-of-document elements
The CSSElementMap object defined in http://www.whatwg.org/specs/web-apps/current-work/complete/dom.html#dom-document-csselementmap allows an author to map an element to an identifier that CSS can then use to refer to the element. However, it allows elements that are outside the DOM tree to be mapped, which creates a problem for CSS - CSS has no notion of elements outside the element-tree. We want to preserve this ability, so authors can, for example, generate canvas in script, map it to an identifier, and then refer to it with the element() function to provide an animated background for an element. While you can put any element in the map, only a subset of them make sense to expose to CSS while out of the DOM. Particularly, we want to only expose the img, video, and canvas elements, as they have an intrinsic notion of size that doesn't rely on layout information. So, amendments: 1. While any element can be in the CSSElementMap, only elements are either (a) in the DOM or (b) img, video, or canvas outside the DOM are exposed as CSS Element Reference Identifiers. 2. img, video, and canvas, while outside the DOM, expose the intrinsic width of their content as the size of their margin box. (The margin box of the element is used in the description for element() to figure out how large the generated image should be.) ~TJ
