Re: [whatwg] Orientation fixing for mobile devices
OH never mind found the spec for it https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html. On Wed, Dec 18, 2013 at 3:29 PM, Tingan Ho tinga...@gmail.com wrote: It would be great if there was some kind of orientation fixing for the mobile web. Developers might develop portrait or landscape only web apps. And today there is noway to accomplish this. I think an attribute to the html tag would fit well *For landscape only:* html orientation=landscape *For portrait only:* html orientation=portrait -- Sincerely, Tingan Ho -- Sincerely, Tingan Ho tin...@p1.cn
Re: [whatwg] Comments on dialog
On Wed, Dec 18, 2013 at 5:14 AM, Ian Hickson i...@hixie.ch wrote: My conclusion is that it's a tough call, but the current API is probably the least bad compromise (there's a resounding endorsement, eh?). I'm not the final decider on this, though; that would be the browser vendors. I believe Blink is currently getting an implementation of this; if you can convince whoever is writing that code to use a different API, then I'll change the spec accordingly. Well, that's me. But I plan to just follow the spec, and I think you've just convinced me it's the least bad compromise. Thanks for your consideration.
Re: [whatwg] Proposal: downsample while decoding image blobs in createImageBitmap()
Yes. Especially on these devices, JPEG decoding is undue latency. Also, Rik's suggestion makes an ImageBitmap just a thin wrapper around a Blob, with decoding performed every time we do a drawImage call. That's bad for performance in many cases. David's proposal lets the author be a little bit more explicit and the UA doesn't have to guess what to do. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Re: [whatwg] Comments on dialog
On Tue, Dec 17, 2013 at 3:14 PM, Ian Hickson i...@hixie.ch wrote: I've added a rule to the spec that says that viewports have to be pannable so you can see all of a dialog, but I don't know how feasible that really is. I could see implementations using shadow divs to satisfy this It might be beneficial to even codify kind of element as ::modal, representing a modal layer acting as an ancestor for both the ::backdrop and dialog. 3. When the modal dialog's height changes, either due to CSS or content changes, the vertical position of the dialog should change (unless the height exceeds the viewport height). That's an interesting idea, but I'm not convinced it's the right answer. Having the dialog move up and down when stuff is added at the bottom would be quite weird. You can always implement this manually from script. To go back to hacky and rather difficult-to-maintain JS techniques for something so simple seems antithetical to the intention of dialog to me. Modern modal implementations don't require that. My point isn't that we shouldn't offer the feature because it is already possible. My point is that this feature is actively bad. I'm saying I don't think it's good UI for the dialog position to change when it increases in height. It looks like Blink's implementation will recenter the modal when show/showModal are called.
Re: [whatwg] Add input Switch Type
On Tue, Nov 19, 2013 at 6:29 AM, Elliott Sprehn espr...@chromium.orgwrote: On Tue, Nov 19, 2013 at 1:37 AM, Jonas Sicking jo...@sicking.cc wrote: Realistically speaking, I don't think this will help much at all. Few websites like using the default styling for form controls anyway and so people would be just as unhappy with the default switch rendering as they are with the default checkbox rendering. The real fix is to allow styling formcontrols. It's one of the most requested features from web developers, yet no one has taken the time to research what it would take to do it. I'm quite sure that if someone comes up with a comprehensive and well researched proposal, that browsers would jump on it. And the fact that we now have shadow DOM defined should help a whole lot. +1, a switch is just a styled checkbox. We don't need more input types or attributes, we just need to standardize how to style type=checkbox. - E A switch is definitely NOT simply a styled checkbox. As I mentioned earlier, you can slide/drag a switch to change its value. Also, a switch typically animates, whereas a checkbox is essentially a more static interaction. A switch is often used to indicator more than true/false (which should ultimately be represented). Regardless of what one's opinion might be on the similarity to checkboxes, input types in HTML are not subject to the same semantics as other kinds of elements. Half of them are purely presentational or pave cowpaths. Switches on the Web are currently janky, inconsistent and difficult to implement. That is essentially the exact same reason that type=week or type=color have value. Before formal implementations, they had been implemented for a very long time with type=text and mountains of dubious code. Considering that every major UI toolkit now includes switches discretely from checkboxes, it makes a great deal of sense to include them in the Web Platform. It does not make sense to exclude switches simply because we can abuse checkboxes to create something weakly approximate to a switch.
Re: [whatwg] Comments on dialog
On Wed, 18 Dec 2013, Brian Blakely wrote: On Tue, Dec 17, 2013 at 3:14 PM, Ian Hickson i...@hixie.ch wrote: I've added a rule to the spec that says that viewports have to be pannable so you can see all of a dialog, but I don't know how feasible that really is. I could see implementations using shadow divs to satisfy this It might be beneficial to even codify kind of element as ::modal, representing a modal layer acting as an ancestor for both the ::backdrop and dialog. Not really sure how this would work. Can you elaborate? 3. When the modal dialog's height changes, either due to CSS or content changes, the vertical position of the dialog should change (unless the height exceeds the viewport height). That's an interesting idea, but I'm not convinced it's the right answer. Having the dialog move up and down when stuff is added at the bottom would be quite weird. You can always implement this manually from script. To go back to hacky and rather difficult-to-maintain JS techniques for something so simple seems antithetical to the intention of dialog to me. Modern modal implementations don't require that. My point isn't that we shouldn't offer the feature because it is already possible. My point is that this feature is actively bad. I'm saying I don't think it's good UI for the dialog position to change when it increases in height. It looks like Blink's implementation will recenter the modal when show/showModal are called. That's per spec, yes. The suggestion above was regarding when the dialog changes size while it's already visible, I believe. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Comments on dialog
On Wed, Dec 18, 2013 at 2:13 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 18 Dec 2013, Brian Blakely wrote: On Tue, Dec 17, 2013 at 3:14 PM, Ian Hickson i...@hixie.ch wrote: I've added a rule to the spec that says that viewports have to be pannable so you can see all of a dialog, but I don't know how feasible that really is. I could see implementations using shadow divs to satisfy this It might be beneficial to even codify kind of element as ::modal, representing a modal layer acting as an ancestor for both the ::backdrop and dialog. Not really sure how this would work. Can you elaborate? This is what the shadow DOM would look like for modal dialogs: ::modal - ::backdrop - dialog ::modal is dialog's ancestor, and is available when showModal is called. This allows authors to set CSS overflow to whichever value suits their use-case, and for user agents to establish overflow: auto as the default, making the dialog inherently pannable when it exceeds the viewport. 3. When the modal dialog's height changes, either due to CSS or content changes, the vertical position of the dialog should change (unless the height exceeds the viewport height). That's an interesting idea, but I'm not convinced it's the right answer. Having the dialog move up and down when stuff is added at the bottom would be quite weird. You can always implement this manually from script. To go back to hacky and rather difficult-to-maintain JS techniques for something so simple seems antithetical to the intention of dialog to me. Modern modal implementations don't require that. My point isn't that we shouldn't offer the feature because it is already possible. My point is that this feature is actively bad. I'm saying I don't think it's good UI for the dialog position to change when it increases in height. It looks like Blink's implementation will recenter the modal when show/showModal are called. That's per spec, yes. The suggestion above was regarding when the dialog changes size while it's already visible, I believe. You're correct. I was pointing out that there is already a means of recentering, albeit indirectly. I could see this being abused by clever hackers, with dialog.close() and dialog.showModal() being called in rapid succession, simply for the purpose of recentering.
Re: [whatwg] Media sink device selection on audio/video
On Tue, 17 Dec 2013, Ami Fischman wrote: Recently https://www.w3.org/Bugs/Public/show_bug.cgi?id=23263 Navigator acquired the ability to enumerate media output devices (in addition to input devices): http://dev.w3.org/2011/webrtc/editor/getusermedia.html#enumerating-devices What's the privacy story for this API? It would be nice to allow media elements to direct their output to such an output device. The primary use-case is to allow app UI/script to select which audio output device should play the audio track of a video or audio tag (wired speakers, bluetooth headset, etc.). Seems reasonable. Is any other browser vendor interested in implementing something to address this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
