Re: [whatwg] URI scheme whitelisting and the case of cryptocurrencies
Dnia 2015-03-07, sob o godzinie 15:45 -0800, Michael A. Peters pisze: Another thing to consider, most crypto-currencies use the same Qt client codebase - so it is easy for a web site to specify a price in one crypto-currency but use the URI scheme for a different one, and some users may not realize the wrong client launched until it is too late and can't be undone. e.g. `Please donate 3 QRK - that's all I ask' but 3 bitcoins are sent before the user realize it was bitcoin-qt that the link launched. There is also an example of multiple currency wallets, like Coinomi Android wallet or previously mentioned Coinkite. An user may launch a QR scanner inside his multi-wallet and scan a code which is said to represent 3 blackcoins, but instead will resolve to 3 bitcoins. Or the site may say it is requesting a payment of 35254.432424452 blackcoins, but instead 352534.432424452 blackcoins will be presented on QR code. Those are issues which can’t be fixed by HTML5 specification and in my opinion it is the client which should ensure that the user really knows what he’s doing. If the client feels scared by externally given URIs, it may choose not to register itself as a protocol handler or, for example, strip the “amount” part and require the user to enter currency symbol as an additional confirmation.
Re: [whatwg] Standardizing autocapitalize
On Tue, 10 Mar 2015, at 22:44, Jonas Sicking wrote: On Tue, Mar 10, 2015 at 3:05 PM, Mounir Lamouri mou...@lamouri.fr wrote: On Tue, 10 Mar 2015, at 21:44, Jonas Sicking wrote: I think I'd prefer to define on and off as defined values unless there is very little usage of them. We can certainly mark them as deprecated, but unless their usage is negligible, it seems better to document their behavior than to try to change all existing content not to use it. Especially since it'll also make the .autocapitalize JS property behave less surprising on/off is used. off is defined. The Non-conforming note means that the attribute reflection will behave like this: ```js input.autocapitalize = 'off'; input.autocapitalize === 'none'; // true ``` Right. My point is that this is unnecessarily confusing. Just like input.autocapitalize = 'on'; input.autocapitalize === 'sentences'; // true is unnecessarily confusing. How is that different from ```js input.type = 'foo'; input.type === 'text'; // true ``` Unless we expect that doing |input.autocapitalize = 'on'| is common use case. Which I think isn't. Just like leaving mention of on out of documentation and specs would be confusing for authors that are looking at other people's code and learning from it (which is one of the great powers of the web platform). The specification should definitely mention on in a non-normative section. The same way it should mention off as an allowed but deprecated value. I will have to double-check that but I wonder if the IDL attribute isn't always returning undefined on Safari iOS. At least, I wasn't able to use it last time I checked. Would that solve your concerns? -- Mounir
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On 2015-03-10 09:29, Anne van Kesteren wrote: On Tue, Mar 10, 2015 at 12:01 AM, Seth Fowler s...@mozilla.com wrote: I wanted to get the opinion of this list on how image-orientation and the img element’s naturalWidth and naturalHeight properties should interact. I thought there was some agreement that image-orientation ought to be a markup feature as it affects the semantics of the image (or perhaps investigate whether rotating automatically is feasible): https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 Just my opinion, but I believe rotation of a image should be stored in the image itself. With JPG this is possible. Not sure about PNG or WebP or SVG though. Now if a image space in a webpage (as reserved by css or width height in a image tag) is say 4:3 but the image has info about rotation so it ends up 3:4 instead then the ideal is for the browser to with that 3:4 rotated image within the reserved 4:3 space. The closest analogy I can think of are black bars on movies, although in this case it would be the background behind the image showing through maybe. If attributes or CSS override the orientation of an image I'd consider that an image effect instead. -- Roger Hågensen, Freelancer
[whatwg] Standardizing autocapitalize
(bcc: public-webapps@) Hi, I would like to standardize the Apple's proprietary autocapitalize attribute. This attribute is widely used and it would probably benefit the platform to have a broader support for it. The implementation cost should be fairly low while it can be very beneficial for the user experience with the keyboard on Mobile. I wrote a small proposal document based on Apple's document and live tests on latest Safari mobile: https://github.com/mounirlamouri/html-autocapitalize/blob/master/proposal.md I would be really interested to hear from other vendors, particularly if they would be interested to implement it. In addition, if Apple has some feedback about the proposal, it would be very valuable. Thanks, -- Mounir
Re: [whatwg] Standardizing autocapitalize
Hi Mounir, I would like to standardize the Apple's proprietary autocapitalize attribute. This attribute is widely used and it would probably benefit the platform to have a broader support for it. The implementation cost should be fairly low while it can be very beneficial for the user experience with the keyboard on Mobile. Cool. We proposed it here back in 2011, though it didn't end up getting adopted. https://www.w3.org/Bugs/Public/show_bug.cgi?id=12409 It might be worth reading the old discussion around this topic. In addition, if Apple has some feedback about the proposal, it would be very valuable. I'll take a look and get back to you. Thanks, Ted
Re: [whatwg] Standardizing autocapitalize
On Tue, 10 Mar 2015, at 20:56, Edward O'Connor wrote: Hi Mounir, I would like to standardize the Apple's proprietary autocapitalize attribute. This attribute is widely used and it would probably benefit the platform to have a broader support for it. The implementation cost should be fairly low while it can be very beneficial for the user experience with the keyboard on Mobile. Cool. We proposed it here back in 2011, though it didn't end up getting adopted. https://www.w3.org/Bugs/Public/show_bug.cgi?id=12409 It might be worth reading the old discussion around this topic. It seems that the main reason why it was killed is because it was considered that inputmode superseded autocapitalize. Unfortunately, in the wild, this is not the case and we (Google) have data about the usage of the attribute (cf Hixie's comment 1). I believe it is high enough to consider standardizing. In addition, if Apple has some feedback about the proposal, it would be very valuable. I'll take a look and get back to you. Thanks :) On Tue, 10 Mar 2015, at 21:44, Jonas Sicking wrote: I think I'd prefer to define on and off as defined values unless there is very little usage of them. We can certainly mark them as deprecated, but unless their usage is negligible, it seems better to document their behavior than to try to change all existing content not to use it. Especially since it'll also make the .autocapitalize JS property behave less surprising on/off is used. off is defined. The Non-conforming note means that the attribute reflection will behave like this: ```js input.autocapitalize = 'off'; input.autocapitalize === 'none'; // true ``` The same way you would have: ```js input.autocapitalize = 'NoNe'; input.autocapitalize === 'none'; // true ``` Basically, off should behave as none which is what Safari iOS is doing AFAIK. Regarding on, as pointed by Ted in the linked bug, it behaves like sentences (for states text and search). sentences is also the default value for those. This is the value that would be used if you were to type foobar or whatever. The fact that on is used a lot (or not) isn't really relevant here. To quote Ted In reality, if the attribute is present then only off is checked and all other values are assumed to be on. (He is mentioning the deprecated API.) HTH, -- Mounir
Re: [whatwg] Standardizing autocapitalize
On Tue, Mar 10, 2015 at 1:29 PM, Mounir Lamouri mou...@lamouri.fr wrote: (bcc: public-webapps@) Hi, I would like to standardize the Apple's proprietary autocapitalize attribute. This attribute is widely used and it would probably benefit the platform to have a broader support for it. The implementation cost should be fairly low while it can be very beneficial for the user experience with the keyboard on Mobile. I wrote a small proposal document based on Apple's document and live tests on latest Safari mobile: https://github.com/mounirlamouri/html-autocapitalize/blob/master/proposal.md I would be really interested to hear from other vendors, particularly if they would be interested to implement it. In addition, if Apple has some feedback about the proposal, it would be very valuable. I think I'd prefer to define on and off as defined values unless there is very little usage of them. We can certainly mark them as deprecated, but unless their usage is negligible, it seems better to document their behavior than to try to change all existing content not to use it. Especially since it'll also make the .autocapitalize JS property behave less surprising on/off is used. / Jonas
Re: [whatwg] Standardizing autocapitalize
On Tue, Mar 10, 2015 at 3:05 PM, Mounir Lamouri mou...@lamouri.fr wrote: On Tue, 10 Mar 2015, at 21:44, Jonas Sicking wrote: I think I'd prefer to define on and off as defined values unless there is very little usage of them. We can certainly mark them as deprecated, but unless their usage is negligible, it seems better to document their behavior than to try to change all existing content not to use it. Especially since it'll also make the .autocapitalize JS property behave less surprising on/off is used. off is defined. The Non-conforming note means that the attribute reflection will behave like this: ```js input.autocapitalize = 'off'; input.autocapitalize === 'none'; // true ``` Right. My point is that this is unnecessarily confusing. Just like input.autocapitalize = 'on'; input.autocapitalize === 'sentences'; // true is unnecessarily confusing. Just like leaving mention of on out of documentation and specs would be confusing for authors that are looking at other people's code and learning from it (which is one of the great powers of the web platform). / Jonas
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On Tue, Mar 10, 2015 at 12:01 AM, Seth Fowler s...@mozilla.com wrote: I wanted to get the opinion of this list on how image-orientation and the img element’s naturalWidth and naturalHeight properties should interact. I thought there was some agreement that image-orientation ought to be a markup feature as it affects the semantics of the image (or perhaps investigate whether rotating automatically is feasible): https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 -- https://annevankesteren.nl/
