Re: [whatwg] Add input Switch Type
+1 from the web author perspective. would be nice if this wasn't so Hackish and if the look was more consistent. I do agree that this could be achieved (maybe more backwards compatibly) with an switch attribute on the ```checkbox``` input type. Twitter:@alonisser https://twitter.com/alonisser LinkedIn Profile http://www.linkedin.com/in/alonisser Facebook https://www.facebook.com/alonisser *Tech blog:*4p-tech.co.il/blog *Personal Blog:*degeladom.wordpress.com Tel:972-54-6734469 On Sat, Sep 21, 2013 at 9:06 PM, whatwg-requ...@lists.whatwg.org wrote: Send whatwg mailing list submissions to whatwg@lists.whatwg.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org or, via email, send a message with subject or body 'help' to whatwg-requ...@lists.whatwg.org You can reach the person managing the list at whatwg-ow...@lists.whatwg.org When replying, please edit your Subject line so it is more specific than Re: Contents of whatwg digest... When replying to digest messages, please please PLEASE update the subject line so it isn't the digest subject line. Today's Topics: 1. Re: Canvas - Somewhat inconsistent rules in the spec for drawImage (Robert O'Callahan) 2. Add input Switch Type (Brian Blakely) 3. Re: Add input Switch Type (Tab Atkins Jr.) 4. Re: Add input Switch Type (Brian M. Blakely) -- Forwarded message -- From: Robert O'Callahan rob...@ocallahan.org To: Justin Novosad ju...@google.com Cc: Simon Sarris simon.sar...@gmail.com, WHATWG List wha...@whatwg.org Date: Sat, 21 Sep 2013 10:13:43 +1200 Subject: Re: [whatwg] Canvas - Somewhat inconsistent rules in the spec for drawImage On Sat, Sep 21, 2013 at 6:40 AM, Justin Novosad ju...@google.com wrote: If we do anything, it should be the latter (draw nothing) to avoid breaking existing apps. I agree. I commented on this a while ago, and I still think it's simpler and more robust for drawing a zero-size anything to just draw nothing. 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 * * -- Forwarded message -- From: Brian Blakely anewpage.me...@gmail.com To: whatwg@lists.whatwg.org whatwg@lists.whatwg.org Cc: Date: Fri, 20 Sep 2013 18:36:53 -0400 Subject: [whatwg] Add input Switch Type iPhone OS introduced the switch control (http://i.imgur.com/TA79fo2.png) in 2007. Since then, there have been many attempts to recreate this on the Web Platform by hacking existing control types and using a lot of meaningless markup, to varying degrees of success. The proposal is to add a switch input type. When it is active, the UA should render a switch control. It looks like this: input type=switch on / The on attribute indicates whether the switch is in its on or off state. There is no off attribute, as switches are off by default. The values corresponding to each state are true and false, respectively. List of OSs that implement switch controls (likely incomplete): - Windows 8 - OS X - iOS - Android - Blackberry OS - Windows Phone The major advantage here, as with all controls in HTML, is that the behavior and default appearance of the control is guaranteed to be consistent for a user across the Web, and likely match their host OS as well. This is sure to be a very attractive and convenient solution for authors. -- Forwarded message -- From: Tab Atkins Jr. jackalm...@gmail.com To: Brian Blakely anewpage.me...@gmail.com Cc: whatwg@lists.whatwg.org whatwg@lists.whatwg.org Date: Fri, 20 Sep 2013 15:44:55 -0700 Subject: Re: [whatwg] Add input Switch Type On Fri, Sep 20, 2013 at 3:36 PM, Brian Blakely anewpage.me...@gmail.com wrote: iPhone OS introduced the switch control ( http://i.imgur.com/TA79fo2.png) in 2007. Since then, there have been many attempts to recreate this on the Web Platform by hacking existing control types and using a lot of meaningless markup, to varying degrees of success. The proposal is to add a switch input type. When it is active, the UA should render a switch control. It looks like this: input type=switch on / The on attribute indicates whether the switch is in its on or off state. There is no off attribute, as switches are off by default. The values corresponding to each state are true and false, respectively. List of OSs that implement switch controls (likely incomplete): - Windows 8 - OS X - iOS - Android - Blackberry OS - Windows Phone The major advantage here, as with all controls in HTML, is that the behavior
Re: [whatwg] suggestions for the Notifications API (http://notifications.spec.whatwg.org/)
With less sarcasm: I think this can and will be horribly abused not sure why and how this could be abused but since this can be achieved otherwise (checking if denied and if isn't denied show the please press here to enable notifications logic) doesn't look too important. cheers אלון ניסר a...@noal.org.il 054-6734469 On Fri, May 3, 2013 at 7:49 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: alonn alonis...@gmail.com schrieb am Fri, 3 May 2013 18:50:36 +0300: 1. Having a way to check for the current permission without initiating a new Notification object first. something like webkit has (I'm not sure it's not deprecated) window.webkitNotification.checkPermission() I saw this isn't in the api, and I think having this would be a great Scenario: “You need to enable notifications to view this web site.” With less sarcasm: I think this can and will be horribly abused. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] suggestions for the Notifications API (http://notifications.spec.whatwg.org/)
On Fri, May 3, 2013 at 7:49 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 3, 2013 at 4:48 PM, alonn alonis...@gmail.com wrote: 1. Having a way to check for the current permission without initiating a new Notification object first. something like webkit has (I'm not sure it's not deprecated) window.webkitNotification.checkPermission() I saw this isn't in the api, and I think having this would be a great That would be Notification.permission. You can request using Notification.requestPermission(callback). Actually not, permission exists only on the notification instance . I was thinking a class method like requestPermission 2.having a collection to iterate over notification instances (from my page only). We might get this at some point. See the recent notifications threads. 3.having to set the title only when initiating the Notification object, instead in the dictionary NotificationOptions Iooks inconsistent to me. my instinctive attempt was to set the title together with the rest of the notification options. but that won't work. I think it belongs there (or at least, also there) Only title is required, basically. It's similar to how new Event() behaves. I think a more suitable example would be Geolocation api ( http://dev.w3.org/geo/api/spec-source.html#get-current-position) another api that calls functionality outside the browser window. where all the options are passed in the options dictionary the title could default to empty string or title like the rest of the options. and after looking in the geolocation api again I think maybe having a callback function as a third optional argument to the notification constructor, instead of attaching an 'onshow' events -- http://annevankesteren.nl/
[whatwg] suggestions for the Notifications API (http://notifications.spec.whatwg.org/)
I played a little bit with the Notification API and I have a couple of suggestions (I tried the chrome implementation with Mozille hacks jsFiddle http://jsfiddle.net/robnyman/TuJHx/) for improvement (at least in my view) or a more consistent API as web developer: 1. Having a way to check for the current permission without initiating a new Notification object first. something like webkit has (I'm not sure it's not deprecated) window.webkitNotification.checkPermission() I saw this isn't in the api, and I think having this would be a great *Real life usecase example:*I would like to show different content or apply different logic for someone who didn't explicitly granted permission, but didn't deny it either, without having to show the confirmation dialog first and frighten them away. 2.having a collection to iterate over notification instances (from my page only). 3.having to set the title only when initiating the Notification object, instead in the dictionary NotificationOptions Iooks inconsistent to me. my instinctive attempt was to set the title together with the rest of the notification options. but that won't work. I think it belongs there (or at least, also there) I would also like to say that this can be a really useful api, and you're doing a great work with it! thanks everyone for the great job!
[whatwg] suggestions for the Notifications API (http://notifications.spec.whatwg.org/)
I played a little bit with the Notification API and I have a couple of suggestions (I tried the chrome implementation with Mozille hacks jsFiddle http://jsfiddle.net/robnyman/TuJHx/) for improvement (at least in my view) or a more consistent API as web developer: 1. Having a way to check for the current permission without initiating a new Notification object first. something like webkit has (I'm not sure it's not deprecated) window.webkitNotification.checkPermission() I saw this isn't in the api, and I think having this would be a great *Real life usecase example:*I would like to show different content or apply different logic for someone who didn't explicitly granted permission, but didn't deny it either, without having to show the confirmation dialog first and frighten them away. 2.having a collection to iterate over notification instances (from my page only). 3.having to set the title only when initiating the Notification object, instead in the dictionary NotificationOptions Iooks inconsistent to me. my instinctive attempt was to set the title together with the rest of the notification options. but that won't work. I think it belongs there (or at least, also there) I would also like to say that this can be a really useful api, and you're doing a great work with it! thanks everyone for the great job!
