Re: [whatwg] title/meta elements outside of head
On Thu, Jan 19, 2012 at 8:30 AM, Michael Day mike...@yeslogic.com wrote: What is the reason why title/meta elements are not always moved to the head, regardless of where they appear? They didn't need to be for compatibility, so we went with less magic. Also, being able to use meta and link as descendants of body is useful for Microdata and RDFa Lite without having to mint new void elements. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
Ilya Sherman isher...@chromium.org schrieb am Wed, 18 Jan 2012 21:30:08 -0800: I have gotten a bit of feedback […] https://plus.sandbox.google.com/114128403856330399812/posts/9dKsD7Mi7JU I am being redirected to an unrelated page promoting the immense benefits of having a Google profile. Is there a publicly available instance of the resource or is that discussion “limited” ? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
Hi, For what should not be auto completed, I think autocomplete=off is sufficient. As far as I understand, the issue comes when you want different fields to be auto completed and only related suggestions should be shown. With the approach mentioned in this proposal, we can easily differentiate fields. But problem is the never ending list of field type tokens. Even the list mentioned here looks a small subset. Is it not sufficient to have just generic types like name, address, contact, etc? I understand user would always like to see more specific auto complete suggestions but then it looks hard to standardize huge list of tokens like name, surname, cc-name, etc. and also it may not support internationalization properly. Have you considered just having autocompletetype attribute on form? autocompletetype=registration/private(banking, etc)/personal/login, etc. Having such attribute attribute on form also make it easy to control what kind of forms should be auto completed. For example, not many user would want their banking details like cc-name,cc-exp-year to be auto completed on a desktop browser. Probably only users with personal electronic devices(mobile/other) would like to have banking details auto completed. Regards Arun On Thu, Dec 15, 2011 at 1:17 PM, Ilya Sherman isher...@chromium.org wrote: Current autofill products rely on contextual clues to determine the type of data that should be filled into form elements. Examples of these contextual clues include the name of the input element, the text surrounding it, and placeholder text. We have discussed the shortcomings of these ad hoc approaches with developers of several autofill products, and all have been interested in a solution that would let website authors classify their form fields themselves. While current methods of field classification work in general, for many cases they are unreliable or ambiguous due to the many variations and conventions used by web developers when creating their forms: + Ambiguity: Fields named name can mean a variety of things, including given name, surname, full name, username, or others. Similar confusion can occur among other fields, such as email address and street address. + Internationalization: Recognizing field names and context clues for all the world’s languages is impractical, time-intensive, and error-prone (as good context clues in one language may mean something else in another language) + Unrelated Naming: Due to backend requirements (such as a framework that a developer is working within), developers may be constrained in what they can name their fields. As such, the name of a field may be unrelated from the data it contains. We believe that website authors have strong incentive to facilitate autofill on their forms to help convert users in purchase and registration flows. Additionally, this assists users by streamlining their experience. To that end we would like to propose adding an autocompletetype attribute [1] to the HTML5 specification, as a complement to the existing autocomplete attribute that would eliminate ambiguity from the process of determining input data types. We developed this initial draft proposal working together with developers or several autofill products, and are now looking forward to feedback and suggestions from the broader community. [1] http://wiki.whatwg.org/wiki/Autocompletetype Thanks, ~Ilya Sherman, Chromium Autofill Developer
Re: [whatwg] Decimal comma in numeric input
On Sat, 16 Jul 2011, Jukka K. Korpela wrote: 16.07.2011 00:01, Ian Hickson wrote: Much discussion on this topic happened when we started on this work in 2004 and 2005, I highly recommend perusing the archives around that time. Authors and implementors will need to be able to understand the topic without checking discussions archives, so the specs should say at least a little about the issue that the rules for user’s input may be quite different from the rules for the as stored and forwared. And users will be confused anyway, when user interfaces work oddly. Ok, done. On Thu, 14 Apr 2011, John Tamplin wrote: The entire web application, which includes both client and server-side code, must have the same idea about what locale the user is using. If the app provides a drop-down box or preference setting to choose a different locale, as most localized apps do, the web browser has to be using the same locale for any native locale processing it uses. Otherwise, you run a serious risk of having incorrect data -- if a user types 10,000 in a field when they think they are using a locale with a comma as the decimal separator, does the app receive that as 1 or 10.000? If the app is running in en-US because the user requested it or their system locale isn't supported by the app, and the browser sends 10.000 as the value because the system locale is de, then that is a problem. Indeed. To solve this, we need help from CSS. That's one of the reasons we createdoutput in HTML. This is about data representation and localization, not about optional stylistic suggestions, so CSS is a wrong way to deal with the issue. I disagree. It's entirely a presentational issue. It's almost the _definition_ of a presentational issue. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Decimal comma in numeric input
On Thu, Jan 19, 2012 at 3:38 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 14 Apr 2011, John Tamplin wrote: The entire web application, which includes both client and server-side code, must have the same idea about what locale the user is using. If the app provides a drop-down box or preference setting to choose a different locale, as most localized apps do, the web browser has to be using the same locale for any native locale processing it uses. Otherwise, you run a serious risk of having incorrect data -- if a user types 10,000 in a field when they think they are using a locale with a comma as the decimal separator, does the app receive that as 1 or 10.000? If the app is running in en-US because the user requested it or their system locale isn't supported by the app, and the browser sends 10.000 as the value because the system locale is de, then that is a problem. Indeed. To solve this, we need help from CSS. That's one of the reasons we createdoutput in HTML. This is about data representation and localization, not about optional stylistic suggestions, so CSS is a wrong way to deal with the issue. I disagree. It's entirely a presentational issue. It's almost the _definition_ of a presentational issue. I still disagree -- a user types 1,575 in a field. Is that interpreted as a value between 1 and 2 or between 1000 and 2000? Interpretation of the value entered by the user has nothing to do with CSS. -- John A. Tamplin Software Engineer (GWT), Google
Re: [whatwg] Decimal comma in numeric input
On 19.1.2012 21:51, John Tamplin wrote: On Thu, Jan 19, 2012 at 3:38 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 14 Apr 2011, John Tamplin wrote: Indeed. To solve this, we need help from CSS. That's one of the reasons we createdoutput in HTML. This is about data representation and localization, not about optional stylistic suggestions, so CSS is a wrong way to deal with the issue. I disagree. It's entirely a presentational issue. It's almost the _definition_ of a presentational issue. I still disagree -- a user types 1,575 in a field. Is that interpreted as a value between 1 and 2 or between 1000 and 2000? Interpretation of the value entered by the user has nothing to do with CSS. This should depend on selected locale, is coma thousands or decimal separator? Browser should follow such settings and display value accordingly, but value MUST be sent to server according to 1 set of rules, regardless of anything else (e.g. no thousands separator and full stop as decimal separator). No browser locale, no server locale... one set of rules. Consider JavaScript here... regardless of displayed value, you always get Number type out of it (not string like 15.123,55 but 15123.55) So it is just display here, but spec should explain the difference between display value and underlying data. Brona.
Re: [whatwg] Decimal comma in numeric input
On Jan 19, 2012, at 13:35 , Bronislav Klučka wrote: On 19.1.2012 21:51, John Tamplin wrote: On Thu, Jan 19, 2012 at 3:38 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 14 Apr 2011, John Tamplin wrote: Indeed. To solve this, we need help from CSS. That's one of the reasons we createdoutput in HTML. This is about data representation and localization, not about optional stylistic suggestions, so CSS is a wrong way to deal with the issue. I disagree. It's entirely a presentational issue. It's almost the _definition_ of a presentational issue. I still disagree -- a user types 1,575 in a field. Is that interpreted as a value between 1 and 2 or between 1000 and 2000? Interpretation of the value entered by the user has nothing to do with CSS. This should depend on selected locale, is coma thousands or decimal separator? Browser should follow such settings and display value accordingly, but value MUST be sent to server according to 1 set of rules, regardless of anything else (e.g. no thousands separator and full stop as decimal separator). No browser locale, no server locale... one set of rules. Consider JavaScript here... regardless of displayed value, you always get Number type out of it (not string like 15.123,55 but 15123.55) So it is just display here, but spec should explain the difference between display value and underlying data. Yes. What the user enters and sees on screen is a presentational/locale issue mediated by the browser etc. What an API returns, a form sends, etc., when it is a number in string format, should be fixed. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Decimal comma in numeric input
2012-01-20 1:19, David Singer wrote: What the user enters and sees on screen is a presentational/locale issue Which one? “Presentational” normally refers to things like layout design, colors, fonts, and borders. Locales are something different. The difference between “1.005” meaning one thousand and five vs. one and five thousandths is normally regarded as a locale difference, and nobody has suggested that that it should be handled in CSS when it is about document content. Why would things suddenly change when it comes to user interface? Besides, there is nothing in CSS as currently defined that even tries to address such issues. Yucca
