Re: [whatwg] Input and spell check/keyboard settings
On 18 Jun 2015, at 13:07, Jonny Rein Eriksen jon...@opera.com wrote: On 18.06.2015 12:01, Florian Rivoal wrote: Would it make sense to add an 'auto' value to the lang attribute, explicitly instructing the UA to try and guess what language is being entered? Remembering what was used last time being a legitimate way to guess, but looking at what keyboard you're using, or at the content of what you're typing being others. UAs that don't know how to guess would be no worse off than today, but for those that do, you'd get the benefits that Jonny was talking about, plus any language dependent css being applied correctly... The mechanics of it aren't hard to polifyll, so maybe leaving it up to author provided js is good enough, but a js implementation would have access to less information to base its guess on. For instance, if you're using a typical mobile on-screen keyboard, it wouldn't know which language the keyboard is in, which provides a big clue as to what you're typing. This is another part of the problem. There is currently no way to set which keyboard you would like to use on iOS/Android if I understand correctly. We could maybe get a standardized API which could solve this. Having support in desktop browsers first for handling spell check better would probably help in achieving this though. If a text input field has lang=foo, and your system has a (virtual) keyboard for language foo, I would expect that keyboard to be the one presented to you. Same thing with IMEs (e.g. you have a US keyboard and a Japanese IME installed on your desktop computer, when focusing a text input field with lang=ja, I would expect the IME to be turned on). Not sure if any spec change is needed for that. - Florian
Re: [whatwg] Input and spell check/keyboard settings
Hello all: On language detection and allowing the device to serve your needs: lang and hreflang work well inside the data , but -- as far as I have tested it -- they do not interact with the OS language, neither the browser ( not to mention keyboards or peripherals) I guess it was Adobe, who has this _System.capanilities.language_ implementation, a ECMAScript variane, used in software for the web. Excellent, by the way. Would'nt it be nice to polyfill it ( this is, to adopt the class as a native object for devices/browsers) to implement it, not as an applet or plugin but as a standard for futures specs? Anyone here in this list from Adobe that would like to bring some light on the matter? Cheers --- Delfi Ramirez My digital signature [1] +34 633 589231 del...@segonquart.net [2] twitter: delfinramirez IRC: segonquart Skype: segonquart [3] http://segonquart.net [4] http://delfiramirez.info [5] On 2015-06-18 12:01, Florian Rivoal wrote: On 18 Jun 2015, at 10:58, cha...@yandex-team.ru wrote: - jonnyr@ 18.06.2015, 09:59, Jonny Rein Eriksen jon...@opera.com: A possible solution: If we had support for setting a standardized context attribute on the input element, the browser could keep a small database with configured settings per context. There is an attribute called lang that probably has what you want, if you set up the spellcheck etc to read it. The HTML code in a web page doesn't know what the context is, until you script up something to make that happen. At which point, you may as well change the lang attribute as anything else. Note that some systems auto-detect language being entered - for example both yandex.translate and MacOS do this for me, and I suspect that the future tends that way rather than trying to guess whether I should write to you in english or norwegian... Would it make sense to add an 'auto' value to the lang attribute, explicitly instructing the UA to try and guess what language is being entered? Remembering what was used last time being a legitimate way to guess, but looking at what keyboard you're using, or at the content of what you're typing being others. UAs that don't know how to guess would be no worse off than today, but for those that do, you'd get the benefits that Jonny was talking about, plus any language dependent css being applied correctly... The mechanics of it aren't hard to polifyll, so maybe leaving it up to author provided js is good enough, but a js implementation would have access to less information to base its guess on. For instance, if you're using a typical mobile on-screen keyboard, it wouldn't know which language the keyboard is in, which provides a big clue as to what you're typing. Also, good language detection isn't that trivial, so any random author would probably have a hard time pulling this off, but that's probably not a showstopper, since nothing's stopping them form using third party libraries or services to do the job. - Florian Links: -- [1] http://delfiramirez.info/public/dr_public_key.asc [2] mail:%20del...@segonquart.net [3] skype:segonquart [4] http://segonquart.net [5] http://delfiramirez.info
Re: [whatwg] Input and spell check/keyboard settings
On 18.06.2015 12:01, Florian Rivoal wrote: On 18 Jun 2015, at 10:58, cha...@yandex-team.ru wrote: - jonnyr@ 18.06.2015, 09:59, Jonny Rein Eriksen jon...@opera.com: A possible solution: If we had support for setting a standardized context attribute on the input element, the browser could keep a small database with configured settings per context. There is an attribute called lang that probably has what you want, if you set up the spellcheck etc to read it. The HTML code in a web page doesn't know what the context is, until you script up something to make that happen. At which point, you may as well change the lang attribute as anything else. Note that some systems auto-detect language being entered - for example both yandex.translate and MacOS do this for me, and I suspect that the future tends that way rather than trying to guess whether I should write to you in english or norwegian… So the browser could re-use lang and when the user either manually sets spell checker or the system automatically detects language being written it could set the lang attribute on a textarea element. And when the form is submitted it could be stored by the web server in the right context and served again with the form the next time I am writing in the same context (Ie. writing to the same friend in webmail or fb)? Or did I misunderstand this? Would it make sense to add an 'auto' value to the lang attribute, explicitly instructing the UA to try and guess what language is being entered? Remembering what was used last time being a legitimate way to guess, but looking at what keyboard you're using, or at the content of what you're typing being others. UAs that don't know how to guess would be no worse off than today, but for those that do, you'd get the benefits that Jonny was talking about, plus any language dependent css being applied correctly... The mechanics of it aren't hard to polifyll, so maybe leaving it up to author provided js is good enough, but a js implementation would have access to less information to base its guess on. For instance, if you're using a typical mobile on-screen keyboard, it wouldn't know which language the keyboard is in, which provides a big clue as to what you're typing. This is another part of the problem. There is currently no way to set which keyboard you would like to use on iOS/Android if I understand correctly. We could maybe get a standardized API which could solve this. Having support in desktop browsers first for handling spell check better would probably help in achieving this though. Also, good language detection isn't that trivial, so any random author would probably have a hard time pulling this off, but that's probably not a showstopper, since nothing's stopping them form using third party libraries or services to do the job. - Florian
Re: [whatwg] Icon mask and theme color
On Thu, Jun 18, 2015 at 7:19 PM, Edward O'Connor eocon...@apple.com wrote: On the other hand, link rel=mask-icon color=darkslategray seems like it should Just Work™. I guess we could add support for named colors to input type=color too. -- https://annevankesteren.nl/
Re: [whatwg] Input and spell check/keyboard settings
Hello All:Same solution than before. I knew there a library in the spec of Adobe and its scripting languages ( a derivative of ECMA/DOM) that implemented IME as well. Like a charm. For virtual kybrds , specially. As before, It would be nice that someone at Adobe Inc. could introduce us to this possible solution . Cheers --- Delfi Ramirez My digital signature [1] +34 633 589231 del...@segonquart.net [2] twitter: delfinramirez IRC: segonquart Skype: segonquart [3] http://segonquart.net [4] http://delfiramirez.info [5] On 2015-06-18 13:17, Florian Rivoal wrote: On 18 Jun 2015, at 13:07, Jonny Rein Eriksen jon...@opera.com wrote: On 18.06.2015 12:01, Florian Rivoal wrote: Would it make sense to add an 'auto' value to the lang attribute, explicitly instructing the UA to try and guess what language is being entered? Remembering what was used last time being a legitimate way to guess, but looking at what keyboard you're using, or at the content of what you're typing being others. UAs that don't know how to guess would be no worse off than today, but for those that do, you'd get the benefits that Jonny was talking about, plus any language dependent css being applied correctly... The mechanics of it aren't hard to polifyll, so maybe leaving it up to author provided js is good enough, but a js implementation would have access to less information to base its guess on. For instance, if you're using a typical mobile on-screen keyboard, it wouldn't know which language the keyboard is in, which provides a big clue as to what you're typing. This is another part of the problem. There is currently no way to set which keyboard you would like to use on iOS/Android if I understand correctly. We could maybe get a standardized API which could solve this. Having support in desktop browsers first for handling spell check better would probably help in achieving this though. If a text input field has lang=foo, and your system has a (virtual) keyboard for language foo, I would expect that keyboard to be the one presented to you. Same thing with IMEs (e.g. you have a US keyboard and a Japanese IME installed on your desktop computer, when focusing a text input field with lang=ja, I would expect the IME to be turned on). Not sure if any spec change is needed for that. - Florian Links: -- [1] http://delfiramirez.info/public/dr_public_key.asc [2] mail:%20del...@segonquart.net [3] skype:segonquart [4] http://segonquart.net [5] http://delfiramirez.info
Re: [whatwg] Icon mask and theme color
Hi, Kornel wrote: Safari[…] uses `theme-color` for foreground color of favicons of pinned tabs, but other browsers use `theme-color` for background colors. I replied: Well, meta name=theme-color is not specced as speficially a foreground or background color; it's a color that user agents may use in any number of ways to customize their UI when displaying a web page. Safari's use of theme-color for pinned tabs is consistent with its definition. [1] Kornel raised the FT's use of theme-color: Financial Times' theme color is salmon pink (#fff1e0), but FT's logo must use black letters. Maciej replied: I find this use case pretty compelling. There’s no reasonable set of processing steps that could get you salmon pink for use as a background, but black for use as a foreground. I think this is compelling evidence that it needs to be at least possible to specify a mask icon color relative to the theme color. Yeah, I agree. I wish we had a time machine to rename theme-color to theme-background-color! :) (A.2) Add an attribute to link specifically for use in specifying the color for that icon, e.g. link rel=mask-icon href=whatever.svg color=lightred. I like this option. I suspect it's better than specifying the color in the SVG file itself. Consider the top-level tabs of bbc.co.uk (News, Sport, Weather, etc.) They each have a different dominant theme color (red for news, yellow for sport, etc.) but you can easily imagine them wanting to share the same mask icon. Anne wrote: This seems reasonable to me too. Though perhaps color= should share parsing with input type=color? More restrictive, but does not allow transparency either, which CSS/canvas-like parsing would allow for. There are three options I can see for parsing the color: * rules for parsing simple colour values (like input type=color) * rules for parsing a legacy colour value (like body bgcolor) * parsed as a CSS color value (like in the canvas API) I generally don't like the idea of adding new features that use weird legacy parsing rules, so I'm inclined to agree that we should use the rules for parsing simple colour values. On the other hand, link rel=mask-icon color=darkslategray seems like it should Just Work™. IIRC we don't currently have any cases in HTML where attribute values get parsed as CSS colors do, so I'm reluctant to go that route here. Ted
[whatwg] support for named colors in input type=color (was Re: Icon mask and theme color)
Hi Anne, You wrote: On the other hand, link rel=mask-icon color=darkslategray seems like it should Just Work™. I guess we could add support for named colors to input type=color too. Offhand I think that's a good idea. Probably won't round-trip through typical color picker implementations, but that doesn't seem like much of a problem to me. What do others think?
Re: [whatwg] support for named colors in input type=color (was Re: Icon mask and theme color)
On 6/18/15, Edward O'Connor eocon...@apple.com wrote: Hi Anne, You wrote: On the other hand, link rel=mask-icon color=darkslategray seems like it should Just Work™. I guess we could add support for named colors to input type=color too. Offhand I think that's a good idea. Probably won't round-trip through typical color picker implementations, but that doesn't seem like much of a problem to me. What do others think? I think getAttribute(color) should return the value specified in the HTML source code and that color serialization, what you might get from the property should generally be consistent across APIs. Here is one: http://dev.w3.org/csswg/cssom/#serializing-css-values Seems weird specifying color in the HTML. Reminds me of bgColor. Should there be a way to specify the link's color in CSS? Like mask-image? -- Garrett @xkit ChordCycles.wordpress.com garretts.github.io personx.tumblr.com
Re: [whatwg] Icon mask and theme color
On Thu, Jun 18, 2015, at 19:19, Edward O'Connor wrote: Maciej replied: I find this use case pretty compelling. There’s no reasonable set of processing steps that could get you salmon pink for use as a background, but black for use as a foreground. I think this is compelling evidence that it needs to be at least possible to specify a mask icon color relative to the theme color. Yeah, I agree. I wish we had a time machine to rename theme-color to theme-background-color! :) Allow me to toot my own horn: https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jun/0144.html --tobie
Re: [whatwg] Input and spell check/keyboard settings
On 18 Jun 2015, at 10:58, cha...@yandex-team.ru wrote: - jonnyr@ 18.06.2015, 09:59, Jonny Rein Eriksen jon...@opera.com: A possible solution: If we had support for setting a standardized context attribute on the input element, the browser could keep a small database with configured settings per context. There is an attribute called lang that probably has what you want, if you set up the spellcheck etc to read it. The HTML code in a web page doesn't know what the context is, until you script up something to make that happen. At which point, you may as well change the lang attribute as anything else. Note that some systems auto-detect language being entered - for example both yandex.translate and MacOS do this for me, and I suspect that the future tends that way rather than trying to guess whether I should write to you in english or norwegian… Would it make sense to add an 'auto' value to the lang attribute, explicitly instructing the UA to try and guess what language is being entered? Remembering what was used last time being a legitimate way to guess, but looking at what keyboard you're using, or at the content of what you're typing being others. UAs that don't know how to guess would be no worse off than today, but for those that do, you'd get the benefits that Jonny was talking about, plus any language dependent css being applied correctly... The mechanics of it aren't hard to polifyll, so maybe leaving it up to author provided js is good enough, but a js implementation would have access to less information to base its guess on. For instance, if you're using a typical mobile on-screen keyboard, it wouldn't know which language the keyboard is in, which provides a big clue as to what you're typing. Also, good language detection isn't that trivial, so any random author would probably have a hard time pulling this off, but that's probably not a showstopper, since nothing's stopping them form using third party libraries or services to do the job. - Florian
[whatwg] Input and spell check/keyboard settings
The problem: When writing messages on Facebook, in web-mail, in discussion forums and so on, we often end up switching languages for the spell-checker in the desktop browser and on phones we switch which keyboard we use. Typically I will write in English in messages to my English friends and Norwegian to my Norwegian friends. But since spell-check and keyboard are always global settings in browsers we end up having to switch keyboard and spell-checker whenever we switch between who we are writing messages to. Of course this is only a problem if you communicate in multiple languages. A possible solution: If we had support for setting a standardized context attribute on the input element, the browser could keep a small database with configured settings per context. The idea being that this context attribute would be connected to each entity you were communicating with. In general I would have a default spell-checker/keyboard. Since I set it to English last time I talked to an English friend on Facebook and if Facebook supported this context ID the browser would remember this and auto-switch to English next time I started writing a message to him. We would need to define an attribute for the input field so that web sites could supply such a context ID. Looking at Textarea there are related settings: Id, Spell check and input mode are the most obvious, but nothing I can find that would solve this issue, IE. a context ID that could be set per user, or group of users you are writing to. Or did I miss something? My question then: Is this interesting for this group? Jonny Rein Eriksen Opera Software
Re: [whatwg] Input and spell check/keyboard settings
- jonnyr@ 18.06.2015, 09:59, Jonny Rein Eriksen jon...@opera.com: A possible solution: If we had support for setting a standardized context attribute on the input element, the browser could keep a small database with configured settings per context. There is an attribute called lang that probably has what you want, if you set up the spellcheck etc to read it. The HTML code in a web page doesn't know what the context is, until you script up something to make that happen. At which point, you may as well change the lang attribute as anything else. Note that some systems auto-detect language being entered - for example both yandex.translate and MacOS do this for me, and I suspect that the future tends that way rather than trying to guess whether I should write to you in english or norwegian… har det bra Chaals -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com
