Re: [whatwg] Notifications: reviving Notification objects
On 31/03/13 15:33, Anne van Kesteren wrote: There are a couple of scenarios http://notifications.spec.whatwg.org/ does not address at the moment. A) User navigates to chat site. Chat site creates a notification from a chat with P while the user does something else. User closes chat site and then navigates to chat site at a later point. I guess a better example would be that the website is unloaded on memory pressure but the tab is kept. Otherwise, an explicit user action could be considered as enough to remove all currently opened notifications. 1) Tie the document's address of when a Notification is created to the Notification object to address B) and C). Maybe at some point allow sites to define a URL to open. What if I have to instance of the same website open? what if those two instances have different contexts like not logged in with the same user? 2) Define a method on Navigator, getNotifications(), that returns a Future which is resolved with an array of Notification objects. Once the Future is resolved, a task is queued to fire a click event on the appropriate Notification object in case of B) and C). This magic behaviour with the click event is a bit weird. Does that mean that the UA shouldn't do anything with the notification? What if the website never calls getNotifications()? We could expect the UA to close the notification by default when the website is re-opened but if it has to wait for a possible .getNotifications() call, what should be done? Timing out seems a bit racy. -- Mounir
Re: [whatwg] Allowing authors to obtain a vertical input type=range
On 29/03/13 17:27, Ian Hickson wrote: On Tue, 26 Mar 2013, Jonathan Watt wrote: The result of the discussion here: http://www.w3.org/mid/514a17d4.3070...@jwatt.org is that I've changed Firefox Nightly's handling of input type=range to allow it to render as a vertical slider if it has an orient=vertical attribute on it. There was only one reply to my email to www-style, but the author suggested using an attribute which I'd also concluded was the best thing to do. I'd like to propose that this attribute be added to the HTML5 specification. It seems like a very medium-specific attribute. Why wouldn't this be a CSS issue? That's the layer of the Web platform where we put presentationa-specific things. I'm not a big fan of adding presentation-specific things to the markup but I do not see another solution here. If we set the orientation in CSS, we can't select elements based on their orientation because the properties associated with the rule might change their orientation, thus ending in an infinite loop. After talking with Boris Zbarsky and David Baron, they said that could be prevented by hacks to actually not go in such loop but they were not very happy about it. For progress and meter, Mozilla decided to set the orientation based on a CSS property and not allow users to select elements based on their orientation. It seems like developers would like to select elements based on their orientation and in that case, using the markup to set the orientation seems to be the only solution. But in this particular case, why do we need authors to explicitly say anything about the direction? Why can't you just be vertical if you're tall, and horizontal if you're wide? I don't understand why anyone would ever want a tall horizontal slider. The fact that Webkit, Trident and Gecko are not doing that on purpose should be a good sign that this is not a good idea. Even jQuery changed its behaviour. You can easily imagine a square element that wants to be represented horizontal or vertical or a wide element that wants a vertical representation (the wideness coming from labels on tickmarks for example). There is an example in this old email from Sylvain Galineau: http://lists.w3.org/Archives/Public/www-style/2011Apr/0386.html -- Mounir
Re: [whatwg] A question about portrait-secondary of screen orientation
On 08/02/13 17:53, Chundong Wang wrote: Hello - Got a question of screen orientation on portrait/landscape. Let's say we have a device doesn't support portrait-secondary, by spechttp://www.w3.org/TR/screen-orientation/ we should remove it from allow list which is fine. However if web developer specified portrait instead of portrait-primary for lockOrientation(), which I suppose is a common case, we'll have to expand it to portrait-primary, portrait-secondary according spec. In this case the lockOrientation() would fail because orientations isn't a supported orientation set. I don't think it'll satisfy the original purpose of portrait. IMHO, we should explain this more detailed. We could either, 1. Only expand portrait(or landscape) into allowed orientations, or; 2. Filter out disallowed orientations from orientation sequence and lock the screen with that list. Thank you for your feedback, it is quite interesting. I went with the first solution you proposed. The only down-side with that solution is that lockOrientation(portrait) would no longer be exactly like lockOrientation([portrait-primary, portrait-secondary]) but I guess this is better for developers who don't care which portrait orientation are allowed exactly. I am assuming that someone using the explicit form might want to know if that failed and wouldn't prefer a half-working lock without notification. You can view the updated document here : https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html By the way, this specification is being worked on in the WebApps WG so posting in the webapps mailing-list would have been better ;) Cheers, -- Mounir
Re: [whatwg] Allowing authors to obtain a vertical input type=range
On Fri, Mar 29, 2013 at 1:28 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 26 Mar 2013, Scott González wrote: No, auto is not useful in practice. We had this in jQuery UI and removed it four years ago because it was a bad idea. Why is it a bad idea? Because it's one of those features that sneaks up on you when you least expect it. We had several complaints from users about this behavior. If auto orientation is added, we'd also need to define whether the orientation is calculated just on insertion or if it updates with layout changes.
[whatwg] iframe srcdoc definition not compatible with existing user-agent user interfaces
The way iframe srcdoc is defined, the document URI does not in any way encode the document contents. Unfortunately, that breaks user-agent and extension features like open frame in new window, show only this frame, open frame in new tab, etc. I just tried this in the two UAs I have that implement such features, and Chrome simply doesn't have such options in its default UI, while in Safari those context menu options are in fact just completely broken. This seems fairly undesirable. Is there a reason we don't want a URI which _will_ encode the source in some way so as to avoid breaking basic UI like this? -Boris
Re: [whatwg] iframe srcdoc definition not compatible with existing user-agent user interfaces
On Thu, Apr 4, 2013 at 2:12 PM, Boris Zbarsky bzbar...@mit.edu wrote: The way iframe srcdoc is defined, the document URI does not in any way encode the document contents. Unfortunately, that breaks user-agent and extension features like open frame in new window, show only this frame, open frame in new tab, etc. I just tried this in the two UAs I have that implement such features, and Chrome simply doesn't have such options in its default UI, while in Safari those context menu options are in fact just completely broken. This seems fairly undesirable. Is there a reason we don't want a URI which _will_ encode the source in some way so as to avoid breaking basic UI like this? Are you asking to switch back to data urls instead of srcdoc, or are you asking for a way to generate an equivalent data url from the contents? The former was addressed during the design of srcdoc - the escaping requirements of data urls are non-trivial, and given that this is supposed to be an easy security measure, any difficulty in escaping means people will fail and get security escapes. If it's the latter, I think that makes sense. ~TJ
