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] api for fullscreen()
While an element is fullscreen, the UA imposes CSS style position:fixed; left:0; top:0; right:0; bottom:0 on the element and aligns the viewport of its DOM window with the screen. Only the element and its children are rendered, as a single CSS stacking context. So this makes it a very element-focused API (as does the enterFullscreen() method on Element that you propose above). Another approach would be to leave it entirely up to the page author to style their page differently when in fullscreen, and not have the API force them to focus on one element. Then the API would probably be on the Window object, and the UA would simply transition the view to a fullscreen presentation. There could be a pseudo-class to the body, or a way to use media queries to allow the author can apply different styles for fullscreen. In this scenario the author is not forced to nest all their fullscreen content under one element, and can continue to show the rest of the page content (maybe dimmed out by a semi-transparent overlay div) in the background. Well, as an author, you can always choose to make the body element go fullscreen, wouldn't you? So you can have both: - use a single div with all it's content - use a video element - or use the body, so that the whole page goes fullscreen. And if there is a pseudo-class on this element, you can always style the content accordingly. Best regards, Frank Hellenkamp -- frank hellenkamp | interface designer solmsstraße 7 | 10961 berlin +49.30.49 78 20 70 | tel +49.173.70 55 781 | mbl +49.3212.100 35 22 | fax jo...@depagecms.net http://www.depagecms.net http://immerdasgleiche.de http://everydayisexactlythesame.net/ signature.asc Description: OpenPGP digital signature
Re: [whatwg] Annotating structured data that HTML has no semantics for
Ian Hickson wrote: I agree entirely. I actually tried to find a workable solution to address this but unfortunately the only general solutions I could come up with that would allow this were selector-based, and in practice authors are still having trouble understanding how to use Selectors even with CSS. There's also the problem with separating the data from the rules that say how to interpret the data, which would likely lead to more problems than the typos one would get from repeating the itemprop=s. I am sorry, but I cannot agree on this one. At least simple selectors are well understood and a well established technique on the web. There is widespread use for it in CSS (so it is very simple to test, if your selector works for the correct set of elements). And the fact that jquery is *so* successful is based on jquery's capability to work with selectors in such an easy way – not the other way around. And with a selector-based aproach it is far easier to add metadata-information to existing content, than with the metadata-proposal. So for authors it would be much easier, I think. It would work like a dezentralized microformats-approach (btw. it would be easy to map the existing microformats to such a css-based metadata-format), with the benefit that you can simply map your own classes and ids to global ones like foaf, dc or hcard. And you could easily use such profiles from other pages, e.g.: Someone could markup the songs on his page in a way last.fm does and then simply use a copy of their meta-data profile (basically in the same way we use microformats now). The only real problem I see is the unfortunate fact, that it is harder for browser-implementors to write a good copy paste code which preserves all metadata from one source to another. Best regards Frank -- frank hellenkamp | interface designer solmsstraße 7 | 10961 berlin +49.30.49 78 20 70 | tel +49.173.70 55 781 | mbl +49.3212.100 35 22 | fax jo...@depagecms.net http://www.depagecms.net http://immerdasgleiche.de http://everydayisexactlythesame.net/ signature.asc Description: OpenPGP digital signature
Re: [whatwg] Proposal for cross domain security framework
1. Browser downloads a script from server A. 2. Script tries to connect to server B. 3. Browser looks up server B's IP-address. 4. Browser performs a reverse lookup of server B's IP-address and gets a host name for the server. 5. Browser looks up a special TXT record in the DNS record for Server B, which states each of the IP addresses/host names that can hosts scripts allowed to connect. DNS records are cached multiple places (including at the local computer), so a DDOS attack attempting to take down DNS servers probably not succeed. DNS-Server-Information is often not accessible for many hosts/shared hosts. Adobe has some of the same Problems with the Adobe-Flash-Player. They use a crossdomain.xml-file to provide policy-informations. In the Flash Player 9,0,115,0 they introduced something like meta-policies: http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security_04.html Probably worth a read, when we discuss this topic... best regards, frank hellenkamp -- frank hellenkamp | interface designer hasenheide 53 | 10967 berlin +49.30.49 78 20 70 | tel +49.173.70 55 781 | mbl +49.1805.4002.243 912 | fax [EMAIL PROTECTED] | mail http://depagecms.net strnr 14/339/61587 signature.asc Description: OpenPGP digital signature
Re: [whatwg] Proposal for a link attribute to replace a href
I agree that this is an unconvincing example, but consider instead banner ads that are created from a bunch of HTML markup rather than a single image; they generally want the entire banner rectangle to be clickable but make use of tables and all sorts of other strange things. I also think, that the banner is not a convincing example. But I step over different kinds of teaser (news- and article-teasers) during my work, that are made out of images, text and headlines. Now, you have to do this (without javascript): div class=teaser a href=link.htmlimg src=image.png/a h3a href=link.htmlnewsteaser/a/h3 pa href=link.htmlText/a/p pa href=link.htmlText/a/p /div If you are good, you also set the a-elements to display: block so that the whole area is clickable, not only the text. It would be *much* more simple/useful to have something like this: div class=teaser href=link.html img src=image.png h3newsteaser/h3 pText/p pText/p /div Or this: a href=link.html div class=teaser img src=image.png h3newsteaser/h3 pText/p pText/p /div /a By the way: It would be more accessible with the mouse in this case, because the clicking-area is much bigger (without css-tricks). best regards frank -- frank hellenkamp | interface designer hasenheide 53 | 10967 berlin +49.30.49 78 20 70 | tel +49.173.70 55 781 | mbl +49.1805.4002.243 912 | fax [EMAIL PROTECTED] | mail http://depagecms.net strnr 14/339/61587
Re: [whatwg] Proposal for a link attribute to replace a href
As an alternative, you can put a clickable empty transparency over the teaser. Is that what you meant by CSS tricks? Chris If you don't know the width and height of the element (because the text may have a differnet height for different teaser) you can't put a clic#kable rectangle over it - the content have to be inside to let the element grow with the content. best regards frank -- frank hellenkamp | interface designer hasenheide 53 | 10967 berlin +49.30.49 78 20 70 | tel +49.173.70 55 781 | mbl +49.1805.4002.243 912 | fax [EMAIL PROTECTED] | mail http://depagecms.net strnr 14/339/61587
Re: [whatwg] Proposal for a link attribute to replace a href
The anchor customarily encompasses just the key phrase, not the whole text. The problem here is that the advertisements are not cooperative; they aggressively try to get in the reader's way. In your example, it would be more consistent to wrap the header text only. As an alternative, you can put a clickable empty transparency over the teaser. Is that what you meant by CSS tricks? Chris The thing is: You want to have it most intuitive for the user: You have a portal page for a newspaper for example. Every article has a teaser with an image, a headline and text. As a user, I don't want to search for a link text (like more..., which is really bad, or some small key phrase), i just want to click somewhere on the teaser (on the image or the text) to get the article I want to read. As a content producer, I have to honor that. It is good to have big clickable buttons, especially on present and upcoming mobile devices (like the iphone for example). In the best case the whole rectangle of the teaser is clickable. At the moment you need some javascript or an a-tag with display: block for it, to get this behavior (see example in my last mail). best regards frank -- frank hellenkamp | interface designer hasenheide 53 | 10967 berlin +49.30.49 78 20 70 | tel +49.173.70 55 781 | mbl +49.1805.4002.243 912 | fax [EMAIL PROTECTED] | mail http://depagecms.net strnr 14/339/61587
