Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Thu, Jan 19, 2012 at 3:08 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: 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” ? Whoops, typo in the URL -- it should be [ https://plus.google.com/114128403856330399812/posts/9dKsD7Mi7JU ]. Thanks for pointing that out!
Re: [whatwg] Decimal comma in numeric input
On 20.1.2012 1:29, Jukka K. Korpela wrote: 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 I've joined this discussion to point out the difference between presentation and data behind it. But I agree, this has nothing to do with CSS, this should not be handled by CSS. I'd prefer lang attribute here: if not presented (directly on input element) then users OS locale should be used (or maybe some general browser settings), if presented, format defined by that locale should be used (the same process should apply to date inputs as well). Brona
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
Thanks for the detailed explanation! I also think that specifying a good list of common tokens is a good approach. Today itself I observed different behavior when I tried structured auto form fill on ebay.com registration form. Chrome auto completed it but the android browser didn't, because of the different approaches used to identify full-name fields. Having common way of differentiating fields makes it straightforward to implement it as well. Regards Arun On Fri, Jan 20, 2012 at 3:05 PM, Ilya Sherman isher...@chromium.org wrote: On Thu, Jan 19, 2012 at 7:01 AM, Arun Patole arun.pat...@motorola.comwrote: Hi, For what should not be auto completed, I think autocomplete=off is sufficient. I think you're referring to the paragraph beginning with In practice, this allows... in the proposal [1]. If so, note that this is not directly part of the proposed mechanics; rather, it's simply a practical on how to leverage those mechanics. [1] http://wiki.whatwg.org/wiki/Autocompletetype#4.10.7.2.13_The_autocompletetype_attribute As mentioned in that same paragraph, specifying something like autocompletetype=x-other would have different behavior from specifying autocomplete=off. To explain that, I'm going to have to detour for a bit and describe the difference between regular autocomplete and structured autofill. By regular autocomplete, I mean the baseline, cross-browser autocomplete feature that remembers verbatim what you've typed into a field based on the field's name, and nothing else. In contrast, by structured autofill I am referring to something more like Chrome or Safari's Autofill functionality, which enables filling of a complete address all at once. Now, using that terminology, there are some fields for which regular autocomplete is perfectly appropriate, whereas structured autofill is not. Namely, if you have a form field requesting a relatively unique type of data -- e.g. the user's alma mater -- it might be useful to specify autocompletetype=x-other to avoid false positives triggering in structured Autofill providers, while still enabling the regular autocomplete functionality that saves time if you ever find yourself filling out this selfsame form again. 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. Unfortunately, generic types of the sort you mention are not sufficiently descriptive to enable structured Autofill providers to fill the form without falling back upon heuristics. The primary goal of this proposal is to enable site authors to instruct such providers -- including, for example, Chrome, Safari, and the popular Firefox extension Autofill Forms [2] -- precisely how to fill common types of forms, especially registration and e-commerce forms. [2] https://addons.mozilla.org/en-US/firefox/addon/autofill-forms/ Your point that it is hard to standardize the list of tokens is well taken, and is also something that Tantek touched upon in his Google+ comment that I previously linked to. If we agree that specifying a list of common tokens is a good approach, there will no doubt be some bikeshedding about which tokens, exactly, should be included; and what they should be named. This discussion is welcome, though -- when the time comes -- it might be wise to fork it to a separate thread (perhaps in a different forum) so as to not distract from any broader concerns. However, I will mention now that there is precedent for defining such lists of tokens; and indeed, the list of tokens in the initial proposal is consolidated across the token types in ECML [3], vCard [4, 5], xNAL [6], and Google Map's geocoding APIs [7]; as well as the types filled by Chromium's and by Safari's Autofill features. [3] http://www.ietf.org/rfc/rfc3106 [4] http://en.wikipedia.org/wiki/VCard#Properties [5] http://msdn.microsoft.com/en-us/library/ms533032(v=vs.85).aspx [6] http://www.oasis-open.org/committees/ciq/download.shtml [7] http://code.google.com/apis/maps/documentation/geocoding/#Types Have you considered just having autocompletetype attribute on form? autocompletetype=registration/private(banking, etc)/personal/login, etc. Yes, we did consider this. However, as with the generic types you mention above, such a high-level labeling is not sufficiently descriptive to avoid the need for heuristics. Again, it is a premise of this proposal that
[whatwg] form.elementName does not return RadioNodeList
http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-form-nameditem says to return a live NodeList where as http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#dom-htmlformcontrolscollection-nameditem says to return a RadioNodeList This is inconsistent. Personally to me, returning a RadioNodeList on the form namedItem getter makes sense.
Re: [whatwg] Augmenting HTML parser to recognize new elements
On Wed, Jan 18, 2012 at 8:19 PM, Dimitri Glazkov dglaz...@chromium.org wrote: A typical example would be specifying an insertion point (that's content element) as child of a table: table content tr ... /tr /content /table Both shadow and template elements have similar use cases. This doesn't comply with the Degrade Gracefully design principle. Is this feature so important that it's reasonable to change table parsing (one of the annoying parts of the parsing algorithm) in a way that'd make the modified algorithm yield significantly different results than existing browsers? Have designs that don't require changes to table parsing been explored? What would be the sane way to document such changes to the HTML parser behavior? A change to the HTML spec proper *if* we decide that changes are a good idea. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
[whatwg] Localisation of form fields
Hello There are two recent threads on localisation of form fields, one on input type=date, the other on the Decimal comma in numeric input. Both are about the question whether the form field value should be displayed according to the element's language, or rather based on the user's preferred locale. This looks like a basically interesting question to me; I see use cases for both: Use case for using User's preferred locale: - The user is viewing a website in a foreign language, using his/her own computer. Use case for using the element's language: - The user is viewing a website in his/her own language, but using a computer in an internet café in a foreign country (where (s)he might not even be able to change the language settings of the browser). As some formats may be very different, both situations can lead to misunderstanding of the values displayed in the form, and thus wrong submissions. It was pointed out, that the comma may be a 1000 or a decimal separator. Or, dates are arranged differently, e.g. M/D/Y in English, but D.M.Y in German. This makes me think, if UAs could be encouraged to invent some kind of UI for per-session overriding the localisation settings of both UA and website content.
Re: [whatwg] Decimal comma in numeric input
On 20/01/2012, at 1:33 PM, Bronislav Klučka wrote: On 20.1.2012 1:29, Jukka K. Korpela wrote: 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 I've joined this discussion to point out the difference between presentation and data behind it. But I agree, this has nothing to do with CSS, this should not be handled by CSS. I'd prefer lang attribute here: if not presented (directly on input element) then users OS locale should be used (or maybe some general browser settings), if presented, format defined by that locale should be used (the same process should apply to date inputs as well). Brona The lang attribute is the structural declaration of the content's localization, be it prose or data values. There should be no difference in what the following mean: p lang=enThis is some english text/p input lang=en type=text value=This is some english input/ input lang=en type=date value=2012/ !-- An english date -- This methods allows for an element-by-element application of localization enabling multi-lingual pages to exist. Added to the hierarchical resolution of language tags and this enables effective declaration. Add the meta tags and http headers and you have a compete resolution algorithm. Only once all of these avenues have been exhausted does the resolution of content language enter an ambiguous state whereby a user's default preference should be used. Do not forget that the UA specifies a user's preference in the Accept-Language header. If a server is incapable of providing a localized representation then what is returned is the most relevant representation available and as a result the one that the user has requested to see. It is up to the server to define the representation of a resource based on all request information and it is the UA's responsibility to render *that* representation for the user. There is a usability case for the UA to translate the content automagically for the benefit of the user, but this is assuming that the user desires this feature and is not multilingual and just navigating to a foreign site. For them to have to adjust their locale settings each time they do this is a disaster. Automatic translation as an option is better as it could be applied for white\black-list configured languages and will take responsibility for translating the entire content (or potentially translate=yes elements) and not just form inputs. The method for how to handle data entry on inputs should be defined by the resolved language of the element per the algorithm. This is the only method which makes sense especially if you examine use cases for text entry as well as numerical or temporal data values. In this case the form author is defining which language of input they desire whereby dictionary and additional assistance can be given. By automatically applying a static application-level setting the user will always be given assistance in their own language which isn't very helpful in answering a question such as what is your favourite colour? for a different language. Even for non-native speakers with such auto-assistance even i might be able to enter a correct value in french or whatever other language was defined on the page\element. The notion that native periods or comma usage in data entry is too confusing to decipher fails to take into account they the user has already navigated to a foreign language page and is obviously already capable of interacting with it enough to decipher what the form they are entering data into means. Possibly the addition of a placeholder text would definitively communicate this to the user for these types. The case for CSS presentational specification of formatting is desirable in the case of date\time values which typically can take a large variety of formats and is distinct from their value. Unicode defines both enumerated FULL, LONG, MEDIUM, SHORT pre-configured settings and symbol format templates. Since these have no affect on the data values themselves the place seems to be CSS, however their interaction with data entry would in effect result in applying pattern restriction in order to retain parsing ability. For this reason i think this negates using CSS for this purpose in favour of possibly a format attribute or such. Thanks, Cameron Jones
Re: [whatwg] Localisation of form fields
On 20/01/2012, at 3:56 PM, Markus Ernst wrote: Hello There are two recent threads on localisation of form fields, one on input type=date, the other on the Decimal comma in numeric input. Both are about the question whether the form field value should be displayed according to the element's language, or rather based on the user's preferred locale. This looks like a basically interesting question to me; I see use cases for both: Use case for using User's preferred locale: - The user is viewing a website in a foreign language, using his/her own computer. Use case for using the element's language: - The user is viewing a website in his/her own language, but using a computer in an internet café in a foreign country (where (s)he might not even be able to change the language settings of the browser). As some formats may be very different, both situations can lead to misunderstanding of the values displayed in the form, and thus wrong submissions. It was pointed out, that the comma may be a 1000 or a decimal separator. Or, dates are arranged differently, e.g. M/D/Y in English, but D.M.Y in German. This makes me think, if UAs could be encouraged to invent some kind of UI for per-session overriding the localisation settings of both UA and website content. I think translation is the word here and accurately identifies the potentially inaccurate process taking place. Thanks, Cameron Jones
Re: [whatwg] Decimal comma in numeric input
Sorry, I didn't mean to argue that CSS should be involved, merely that the communication user to user-agent should be considered to use locle-dependent formats, and that the communication user-agent to server should be in a standard format. On Jan 19, 2012, at 16:29 , Jukka K. Korpela wrote: 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 David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Augmenting HTML parser to recognize new elements
On Fri, Jan 20, 2012 at 7:03 AM, Henri Sivonen hsivo...@iki.fi wrote: On Wed, Jan 18, 2012 at 8:19 PM, Dimitri Glazkov dglaz...@chromium.org wrote: A typical example would be specifying an insertion point (that's content element) as child of a table: table content tr ... /tr /content /table Both shadow and template elements have similar use cases. This doesn't comply with the Degrade Gracefully design principle. Is this feature so important that it's reasonable to change table parsing (one of the annoying parts of the parsing algorithm) in a way that'd make the modified algorithm yield significantly different results than existing browsers? This is a good question. It is not strictly necessary to change the parsing, since one could always construct the desired tree imperatively as a workaround. However, this does lead to unpleasant surprises for those attempting to use shadow DOM insertion points declaratively. There are use cases that will require dealing with tables and other tags that have special insertion modes. A while back, Boris had mentioned replacing tables with charts (http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases#Table-based_Charts). Should the developer decide to still include table data somewhere in the chart, they may wish to put something like this in their shadow DOM subtree: ... table content trtdNo data/td/tr /content /table ... Without parser modifications, they would need to build this structure using JS+DOM methods. Have designs that don't require changes to table parsing been explored? At one point, we considered using collapsed DOM ranges to represent insertion points. However, this sidesteps possibilities of declarative syntax and thus didn't seem viable. As the next step, I will gather some developer feedback on the degree of unpleasantness arising from parsing behavior, and document it to better understand possible opportunities for improvement. Sounds good? What would be the sane way to document such changes to the HTML parser behavior? A change to the HTML spec proper *if* we decide that changes are a good idea. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Decimal comma in numeric input
On 20.1.2012 18:52, Cameron Heavon-Jones wrote: The lang attribute is the structural declaration of the content's localization, be it prose or data values. There should be no difference in what the following mean: p lang=enThis is some english text/p input lang=en type=text value=This is some english input/ input lang=en type=date value=2012/ !-- An english date -- English date is misleading term here input lang=en type=datetime value=2010-11-19T15:48+01:00/ is a datetime, not English datetime, not Czech datetime (since time zone suggests CET), but a datetime, the difference is how it should be presented. But also in this case translation/language has no meaning here, because of the time zone in dates, East Coast Time presentation will be different than London time presentation, it can have the same structure (mm/dd/ [0-11]:[0-59] am/pm) but values should be different. And without lang attribute, this should follow users choice 11/19/2010 2:48 pm in London, 19.11.2010 15:48 in Prague and as such should be displayed according to localization Brona
Re: [whatwg] Localisation of form fields
Hello There are two recent threads on localisation of form fields, one on input type=date, the other on the Decimal comma in numeric input. Both are about the question whether the form field value should be displayed according to the element's language, or rather based on the user's preferred locale. This looks like a basically interesting question to me; I see use cases for both: Use case for using User's preferred locale: - The user is viewing a website in a foreign language, using his/her own computer. Use case for using the element's language: - The user is viewing a website in his/her own language, but using a computer in an internet café in a foreign country (where (s)he might not even be able to change the language settings of the browser). As some formats may be very different, both situations can lead to misunderstanding of the values displayed in the form, and thus wrong submissions. It was pointed out, that the comma may be a 1000 or a decimal separator. Or, dates are arranged differently, e.g. M/D/Y in English, but D.M.Y in German. This makes me think, if UAs could be encouraged to invent some kind of UI for per-session overriding the localisation settings of both UA and website content. I think translation is the word here and accurately identifies the potentially inaccurate process taking place. Thanks, Cameron Jones No, localization is, localization goes beyond simple translation Brona
Re: [whatwg] namespaces in html5
On Mon, 18 Jul 2011, David Karger wrote:
[...] the Exhibit data visualization framework
(http://simile-widgets.org/exhibit) [...]
The goal of Exhibit is to make it easy for non-programmers to embed
interactive data visualizations in their web pages.
HTML has a number of features intended for such things. The class
attribute, for example, could be used to flag a table as something that
should get a graph:
table class=graph-me.../table
Specific annotations for the graphing script can be included in data-*=
attributes; for example, this:
table class=graph-me data-graphs-type=xy
thead
th data-graphs-series-kind=x time-seriesDate/th
th data-graphs-series-kind=y logDate/th
...might be how you mark up the top of a table that's going to be drawn as
an X-Y plot with a time-based x axis and a logarithmic y axis.
You can use meta to include page-wide information. You can link to other
resources using link rel or a rel. You can embed raw data using
script type, for example, assuming the type was registered:
script type=text/graph-data
{ type: 'xy', x: 'time-series', y: 'log',
data: [...] }
/script
If the data structure is more like nested name-value lists than tabular,
you could use microdata to mark it up, with the script then using the
microdata DOM API to present the data.
In short, there are a huge number of ways to approach this.
We are also working on further options. The component work in the Web Apps
working group is developing mechanisms for encapsulating widget
definitions, so that your script could bind directly to the data in the
page. This same work will likely involve introducing author-extensible CSS
properties for styling purposes, as well.
Another approach would be to use the catchall html5 data- prefix for
attributes. We could certainly prefix all of our specialized attributes
with the data- prefix, which would turn those attributes valid for html.
This solution is unsatisfactory for two reasons. The first is that our
attributes are not data attributeswe are not using
microformat-oriented data attributes; rather, we are using attributes
that describe visualizations. data- seems a poor choice of prefix.
Treat the five characters data- as an opaque string. data-* attributes
are for use by scripts for any purposes that the script wants.
Personally I would recommend against putting presentational information in
the markup -- whether you use XML namespaces, data-* attributes, or
non-conforming attributes of your own invention. The right place for
styling information is CSS. On the long run, as mentioned above, I expect
we'll provide explicit hooks in CSS for authors to put custom style
information for this purpose (the equivalent of data-* attributes but for
properties). Unfortunately we're not there yet.
The second problem that concerns me is attribute collisions. If we use
an attribute like data-role=view, how long will it be before an
exhibit author runs into a situation where a different javascript
library is using the same data-role attribute for a different purpose,
which would make the two libraries incompatible with one another?
Just use the format data-exhibit-foo=.
I have no specific loyalty to namespaces, but I am really hopeful that
html5 will offer us a solution that reflects the issues I outlined
above, namely:
* allow extension of them html5 vocabulary with attributes Exhibit will
use to anchor visualizations,
* such that the resulting html will validate,
* without requiring rigid obedience to the challenging html polyglot
syntax, which is beyond the capabilities of our target novice web
authors
* and protecting us from a future in which collisions on choice of
attribute names make our library/vocabulary incompatible with others'
That's what data-library-name=value attributes are for. They exactly fit
the described requirements.
On Mon, 18 Jul 2011, Anne van Kesteren wrote:
You could use data-exhibit-* as the specification suggests. Potentially
including the ability for the web author to override the exhibit
constant.
Indeed. That's exactly what data-*= is for: passing data to a script
library.
On Mon, 18 Jul 2011, David Karger wrote:
Yes, we could, but it doesn't address the two objections I raised to data-
prefix:
1. it isn't actually a data attribute, so prefixing with data seems odd
(appearance; minor)
This is a non-issue. The attributes could be called carrot-*= or
socialism-*= or presentation-*=, what matters is what their definition
says, not what they are called. (Most users of HTML don't speak English as
their first language...)
2. there's no way to guarantee someone else won't use the same
data-exhibit prefix, causing incompatibilities (functionality; major)
This is, in practice, a trivial problem. It turns out that there are
relatively few libraries, and so the odds of two libraries picking the
same short string
Re: [whatwg] Placeholder visibility on focus
On Tue, 19 Jul 2011, TAMURA, Kent wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-placeholder-attribute �User agents should present this hint to the user, after having�stripped line breaks�from it, when the element's�value�is the empty string and the control is not focused (e.g. by displaying it inside a blank unfocused control). I'd like to propose to change this part so that we allow UAs to show placeholder text even if the control is focused. * This behavior might depend on platforms. The password field of Windows 7 logon screen shows placeholder text when the field is focused. * autofocus + placeholder is useless in the current specification. I have since changed it to and/or rather than just and. On Tue, 19 Jul 2011, Thomas Maas wrote: a placeholder is supposed to give a hint. It's not logical to hide the hint before you actually add content. As the act of adding content probably means you understood the hint, not the act of focussing. I left the option of having the hint even when there's a value since the value could come from the server (a default) rather than the user. In general this is a UA UI issue so I don't want to overconstrain this. If there's a use case for UIs that aren't allowed in the spec as it stands, I'm happy to loosen it further, let me know. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] namespaces in html5
On 01/20/2012 02:24 PM, Ian Hickson wrote:
Thanks for taking the time to look at this.
On Mon, 18 Jul 2011, David Karger wrote:
[...] the Exhibit data visualization framework
(http://simile-widgets.org/exhibit) [...]
The goal of Exhibit is to make it easy for non-programmers to embed
interactive data visualizations in their web pages.
HTML has a number of features intended for such things. The class
attribute, for example, could be used to flag a table as something that
should get a graph:
table class=graph-me.../table
Specific annotations for the graphing script can be included in data-*=
attributes; for example, this:
table class=graph-me data-graphs-type=xy
thead
th data-graphs-series-kind=x time-seriesDate/th
th data-graphs-series-kind=y logDate/th
...might be how you mark up the top of a table that's going to be drawn as
an X-Y plot with a time-based x axis and a logarithmic y axis.
yes, this is exactly how we do it, currently using an ex: prefix on the
attributes to make sure we don't collide with anything else
You can usemeta to include page-wide information. You can link to other
resources usinglink rel ora rel. You can embed raw data using
script type, for example, assuming the type was registered:
script type=text/graph-data
{ type: 'xy', x: 'time-series', y: 'log',
data: [...] }
/script
If the data structure is more like nested name-value lists than tabular,
you could use microdata to mark it up, with the script then using the
microdata DOM API to present the data.
again, this is in fact what we do (both link and embed methods). but
these aren't the parts that we are struggling to address properly via html5
In short, there are a huge number of ways to approach this.
We are also working on further options. The component work in the Web Apps
working group is developing mechanisms for encapsulating widget
definitions, so that your script could bind directly to the data in the
page. This same work will likely involve introducing author-extensible CSS
properties for styling purposes, as well.
Another approach would be to use the catchall html5 data- prefix for
attributes. We could certainly prefix all of our specialized attributes
with the data- prefix, which would turn those attributes valid for html.
This solution is unsatisfactory for two reasons. The first is that our
attributes are not data attributeswe are not using
microformat-oriented data attributes; rather, we are using attributes
that describe visualizations. data- seems a poor choice of prefix.
Treat the five characters data- as an opaque string. data-* attributes
are for use by scripts for any purposes that the script wants.
Perhaps this is hair-splitting, but I agree completely if we are talking
about a script running and, for example, binding temporary data to a
particular node.
However, in our use case, it is in a sense coincidence that our tags
are being examined by a script. The _purpose_ of our tags is to provide
the same kind of semantic structuring as img or author or navbar
tags: specifying that certain elements, such as a map or a facet, should
appear on the page. It is conceivable that there might be several
different scripts, and perhaps some native extensions, that are all able
to interpret these tags and do something useful with them on the page.
Personally I would recommend against putting presentational information in
the markup -- whether you use XML namespaces, data-* attributes, or
non-conforming attributes of your own invention. The right place for
styling information is CSS. On the long run, as mentioned above, I expect
we'll provide explicit hooks in CSS for authors to put custom style
information for this purpose (the equivalent of data-* attributes but for
properties). Unfortunately we're not there yet.
I don't think of map as presentational information, any more than I
think of img. I agree that certain _attributes_ of the map, such as
marker colors, should ultimately be put in css.
The second problem that concerns me is attribute collisions. If we use
an attribute like data-role=view, how long will it be before an
exhibit author runs into a situation where a different javascript
library is using the same data-role attribute for a different purpose,
which would make the two libraries incompatible with one another?
Just use the format data-exhibit-foo=.
Yes, and what happens when someone else decides that exhibit is a neat
name and they want to use it too? This is the biggest problem I see.
I'd be happy to use any technical solution, and find it worrisome that
instead the spec is relying on a good behavior solution.
I could hack it myself, by putting a namespace argument to the script
script src=script.js?namespace=exhibit that would tell the script to
look for tags prefixed with the given namespace. That way someone
encountering a collision could change the namespace. But it seems a
horrible hack to
Re: [whatwg] namespaces in html5
On Fri, 20 Jan 2012, David Karger wrote: However, in our use case, it is in a sense coincidence that our tags are being examined by a script. The _purpose_ of our tags is to provide the same kind of semantic structuring as img or author or navbar tags: specifying that certain elements, such as a map or a facet, should appear on the page. It is conceivable that there might be several different scripts, and perhaps some native extensions, that are all able to interpret these tags and do something useful with them on the page. Ah, ok. What you're doing then is simply creating a new language. Write a spec, and within your community that spec will define what is valid. Just use the format data-exhibit-foo=. Yes, and what happens when someone else decides that exhibit is a neat name and they want to use it too? This is the biggest problem I see. That's an academic problem. It doesn't happen often enough in practice to worry about. I agree that they technically solve the first three, although I'm skeptical that was the original intent (if the data- prefix just means anything we want to add outside the html spec then why not just allow any tag, without a prefix, which accomplishes the same thing?). Because then it would limit the space within which the language itself can be extended in the future. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Page displayed during/after download (meta refresh downloads)
On Sat, 23 Jul 2011, Kornel Lesi�~Dski wrote: There is a design (anti)pattern related to file downloads: instead of linking to a file directly, websites use Download links pointing to a page with meta refresh=5; url=actual URL to download (or equivalent javascript) and Thank you! text or further instructions how to use downloaded file (e.g. install an application). * it's hard or impossible to see or copy URL of the file (to download with another application, share URL, check if file type is correct by looking at the filename) * Right-click and Save As on Download now links is unreliable and sometimes results in HTML downloaded * Thank you! pages saved in browsing sessions cause files to be re-downloaded every time browser is restarted * Extra pages and meta refresh cause unnecessary delays. Your download will start in 5 seconds is very annoying when download itself takes couple of seconds. I wish this could be replaced with something that doesn't break download links. I agree. There are a number of existing ways that this could be addressed today, e.g. a rel= value that causes a link to automatically be downloaded (would require browser support), or script that detects when the user has clicked on a link for a download and replaces the page with the thanks page without interrupting the download (could be done today, but isn't as simple as a refresh). I think in terms of use-cases it can be expressed as: 1. Show users immediate and very clear feedback that the download is starting, even if browser's standard download UI is very subtle or appears only after the download server responds. 2. Allow website to show additional information about the download, while the download is taking place. e.g. Instructions what to do with the file after it is downloaded. List of mirrors to use in case download is slow or fails. List of related products to upsell. a download and UI improvements in browsers might partially cover use case #1, but I don't see an easy solution to #2, and partial improvement might not be enough to replace meta refresh download pages. And I'm afraid that meta refresh also fulfils another case: 3. Make it harder for others to link directly to the file, force them to link to a branded landing page. I think cases #1 and #2 could be satisfied with something like: a post-download-href=url of page to navigate to when download starts And to satisfy all three cases (without breaking links), it needs to be done at HTTP level, by adding HTTP header (or multipart response? or attribute to Content-Disposition?) that causes both file download to start and a page to be displayed at the same time. This could be done today using Link: headers and a rel value. I recommend approaching browser vendors about this. I don't think we need changes to the spec to handle this today. I'm not sure pages would adopt a solution, either. It might be worth approaching high-profile sites that do this and asking them whether they're interested in doing it in a different way. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] window.status and window.defaultStatus
On Mon, 25 Jul 2011, Bjartur Thorlacius wrote: Are JavaScript implementors willing to reimplement window.status? There are obvious security problems with drawing an author-provided string where a certain URI is expected, but could window.defaultStatus not set the name (_NET_WM_NAME or equivalent) of the script's window and window.status either override window.defaultStatus temporarily, or sent to the user, e.g. through Growl or as a Windows toast. The window name is already accessible to scripts (by modifying the text child of title through the DOM) so no new security concerns are introduced. The Growl binding might well be better by a new function, though. Historically, window.status support has been removed by browsers. In practice, many browsers no longer have status bars anyway. On Mon, 25 Jul 2011, James Graham wrote: If you want OS-level notifications you might be interested in [1] [1] http://dev.w3.org/2006/webapi/WebNotifications/ Indeed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Physical quantities: var or i?
On Tue, 26 Jul 2011, Jukka K. Korpela wrote: 25.07.2011 22:02, Ian Hickson wrote: So what markup should we use for E = mc�, given that by the applicable standards, E, M, and c should appear in italics and the other characters as normal (upright)? It sounds like you want to use these characters: U+1D438 MATHEMATICAL ITALIC CAPITAL E U+1D45A MATHEMATICAL ITALIC SMALL M U+1D450 MATHEMATICAL ITALIC SMALL C No, I don’t want to use them, since only about one person in a million would see the expression. There are several reasons to that, including the absence of those characters in fonts—the only commonly available font that contained a reasonable collection of Plane 1 characters was code2001, and it does not seem to be distributed by its author any more. Well, any new feature will take time to get adopted. We live in the future here. That it doesn't work yet isn't a valid argument against it. :-) Comparing this with how well iE/i = im/iic/i² works, I don't think anyone who understands the implications will give a second though to using such Plane 1 characters in HTML documents. If it works well, I think we're good. Problem solved. Alternatively, you can use MathML to mark up the equation. Or I could use LaTeX and get a presentation of acceptable quality. Or an image, as people still widely use. The question was about markup of physical quantities in HTML. Using other tools just to present a casual equation in running text would be disproportionate. MathML is merely one of several options available to HTML authors that I was enumerating. It is obviously not the only one. For more complicated cases, it may be the preferred option (e.g. if you have fractions, calculus, etc). For simpler cases, e.g. a single variable, it's obviously not simpler than just using var. Whether you want something in italics or not is more a matter for CSS than a matter for HTML. In many contexts, by long traditions and conventions, the use of italics is a matter of content, not casual presentation. Well, kinda. The content is variable, or planck constant, or pi; the presentation as a set of pixels representing an italics /i/ vs an audio sample that says eye vs a set of raised dots in Nemeth Braille is the presentational aspect. As such I think it's fair to say that the italics is a mapping of the var semantic to display presentation via CSS. Should we consider the var element as covering physical quantities too? After all, they can be regarded as variables in a broad sense, as symbols that denote different values in different situations. However, varc/var would be odd, wouldn't it, since the symbol denotes a universal constant of nature. You can look at it as being a variable whose value is a constant of nature. I've clarified the spec to indicate that this is fine. I don’t think you have clarified whether var is suitable for physical quantities, but I guess you meant to imply it—even though there is not a single example about markup for physical quantities. Given that the spec contains the exact example you gave (E=mc^2), and given that the definition explicitly includes an identifier representing a constant as one of the uses for the element, I have to disagree with your assessment. On the other hand, it seems that it doesn’t really matter. The var element has now been defined to have such a wide and vague meaning that it is pointless to use it. There is little reason to expect that any software will ever pay attention to var markup on any semantic basis. You seem to imply that there was reason to expect so before, which is certainly news to me! I would not really expect these elements to be used for anything other than styling hooks. So authors will use i if they think italics is semantically essential, and var won’t be used much. That seems to be the status quo. A programming language variable is something that is _not_ conventionally rendered in italics. Rather, they are usually (though for no really good reason) rendered in a monospace font, like any other expressions in computer languages. Indeed. And vectors are usually bold. So why should authors be told to use markup that by default (and always when CSS is off) results in programming language constructs to be italicized? Flagging “placeholders” with italics (as in “issue the command kbdrm ifilename/i/kbd to delete a file) is a widely used and understood style, but programming language variables are a completely different issue. Well it's entirely up to the authors, of course; if they would rather only use divs and spans then there's not much we can do to stop them. However, some authors like the ease of maintenance that comes from using elements as a general classification mechanism and classes to provide fine-grained control, and it is mostly for them that HTML provides a variety
Re: [whatwg] [Selectors4] case-insensitive attribute value matching (in XML)
On Tue, 26 Jul 2011, Christoph Päper wrote: Anne van Kesteren: I'm still trying to get HTML and browsers to change so that attribute values always match case-sensitively, irrespective of markup language. The current magic attribute list in HTML whose values needs to be matched ASCII case-insensitively is just ugly. Can’t that be changed to something like the following? When an attribute takes as a value – a single keyword or – a whitespace-separated list of keywords, where all valid keywords are defined in this spexcification, these keywords are ASCII case-insensitive. All other attribute values are case-sensitive. or just All element names, attribute names and attribute value keywords defined in this specification are ASCII case-insensitive. All other attribute values are case-sensitive. The spec changed recently in response to Anne's efforts here. If this is an area of interest, I encourage you to study the specification to see if the current requirements are satisfactory. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Fri, Jan 20, 2012 at 2:02 AM, Simon Pieters sim...@opera.com wrote: On Thu, 19 Jan 2012 06:30:08 +0100, Ilya Sherman isher...@chromium.org wrote: 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/**Autocompletetypehttp://wiki.whatwg.org/wiki/Autocompletetype Thanks, ~Ilya Sherman, Chromium Autofill Developer I have gotten a bit of feedback about this proposal via email/IRC/Google+; but this thread has been vewy vewy quiet. On Google+, Tantek Çelik expressed concern [1] that this proposal “appears to be a fait-accompli, that is, having already been implemented” in Chrome 15 under the experimental attribute x-autocompletetype. As I explained in my response to Tantek's post, this proposal is not intended as a fait-accompli; but rather is very much open to feedback and iteration. If you have any comments or suggestions, please send them along! We have no interest in indefinitely supporting this attribute prefixed with x-, and fully expect the proposal to evolve prior to (hopefully) acceptance into the HTML specification. [1] https://plus.sandbox.google.**com/114128403856330399812/** posts/9dKsD7Mi7JUhttps://plus.sandbox.google.com/114128403856330399812/posts/9dKsD7Mi7JU Maybe some of the supported keywords could be dropped (e.g. those that are not recommended to use). Since there's no legacy yet, we can reject bad keywords completely and only support the best practice keywords. Similarly, there's address-line1, address-line2 and address-line3 -- maybe they could be dropped and encourage authors to use a textarea for address? Dropping the discouraged keywords (e.g. phone-local-prefix) certainly seems reasonable to me, in the interest of keeping the predefined token set relatively small. On the other hand, these seven discouraged keywords were added to the initial proposal because a nontrivial number of existing forms currently structure their fields in this way. I'd love to get more people's insights into this tradeoff. I'll go ahead and fork off a thread specifically for discussion of the specific choice of tokens, so that this thread can remain focused on the more high-level details of the proposal. For the address lines, I don't think it's practical to encourage authors to use a textarea rather than separate fields. To the best of my knowledge, almost no website currently uses textareas for this purpose, so textareas are only a theoretical best practice -- users and developers both tend to expect the address lines to be separate fields. Moreover, transitioning from separate fields to a single textarea would require backend migrations (in the parsing code, the database, or both) in order to store the data entered in this new format. That would negate one of the key advantages of this proposal, i.e. the lack of need for backend migrations, relative to ECML. The extensibility story should
[whatwg] autocompletetype tokens (was: Proposal for autocompletetype Attribute in HTML5 Specification)
Forking off this thread to discuss and/or bikeshed about the specific list of field type tokens for the 'autocompletetype' attribute proposal [1]. If you have any comments or suggestions regarding this list, please add them here. [1] http://wiki.whatwg.org/index.php?title=Autocompletetype#Notes_on_tokens: One suggestion, brought up by Simon Pieters, is to remove the discouraged field types (e.g. 'phone-local-prefix'). As I mentioned on the other thread, the tradeoff with these is supporting existing websites vs. trimming the official list of tokens and encouraging best practices. Both lines of reasoning seem fairly sensible to me, and I'd love to get some insights from folks on which approach is more likely to work better for establishing a good specification.
Re: [whatwg] link.sizes and [PutForwards=value]
On Sat, 30 Jul 2011, Cameron McCormack wrote:
Jumping in the middle of this thread to pick up on one aspect...
On 28/07/11 6:15 PM, Ian Hickson wrote:
Are we really concerned about objects stringifying to [Object Foo]?
It seems that the usefulness of such stringification is far outweighed by
the usefulness of being able to treat the attribute as a string attribute
like any other reflecting attribute while also being able to use methods
on it. In fact, it is consistent with every DOMString attribute: they
don't stringify to [Object String], yet you can call methods on them.
What's the difference?
There is a disadvantage. In JS, doing a comparison between two objects,
regardless of whether they have custom stringification behaviour, will compare
based on object identity and not the string.
!DOCTYPE html
iframe id=x src=b.html/iframe
iframe id=y src=b.html/iframe
script
window.onload = function() {
var xw = document.getElementById(x).contentWindow;
var yw = document.getElementById(y).contentWindow;
alert([xw.location, yw.location,
xw.location == yw.location].join(\n));
};
/script
The two Location objects stringify to the same thing, but are not ==. I think
this can be confusing.
Can we overload equality for objects?
On Tue, 2 Aug 2011, Cameron McCormack wrote:
On 2/08/11 6:29 AM, Tab Atkins Jr. wrote:
It's a confusion shared by all objects, though:
var x = [1,2];
var y = [1,2];
alert([x,y,x==y).join(' ');
This alerts 1,2 1,2 false.
That is true, but I get the impression that some authors don't know that
the Location object is actually an object rather than a string.
I don't feel like [PutForwards] is a particularly obvious API design
pattern for authors, and I don't think we should be adding new uses of
it.
I think the benefits outweigh the disadvantages here. With most cases of
DOMSettableTokenList, it doesn't make sense to do a straight comparison
anyway -- a sizes= attribute with value 10x10 20x20 should be
considered equivalent to 20x20 10x10, even though they aren't equal.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] link.sizes and [PutForwards=value]
Cameron McCormack: The two Location objects stringify to the same thing, but are not ==. I think this can be confusing. Ian Hickson: Can we overload equality for objects? No, not within the confines of ECMAScript.
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, Jan 20, 2012 at 6:41 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 1 Aug 2011, Aryeh Gregor wrote: On Fri, Jul 29, 2011 at 7:24 PM, Ian Hickson i...@hixie.ch wrote: My overarching point, however, is that this is a UI issue, and not an authoring issue. The overarching counterpoint is that in-page UI *is* an authoring issue, because authors want to control exactly how their page looks and behaves. Browser/chrome UI issues shouldn't be standardized, but page UI issues absolutely should (at least in many cases). I disagree with this, at least in terms of a general guiding principle. I agree with Ian. I'm not sure how/why something like autocomplete should be treated different than select elements or alert dialogs. If you need a lot of control over the appearance or functionality, don't rely solely on native controls; enhance them with custom JS and CSS. I don't think it's reasonable for standards to try to address all appearance and functionality issues. The native implementations should work for everyone and be good enough for the majority. The rest is up to page, library, and framework authors.
Re: [whatwg] link.sizes and [PutForwards=value]
Cameron McCormack: The two Location objects stringify to the same thing, but are not ==. I think this can be confusing. Ian Hickson: Can we overload equality for objects? No, not within the confines of ECMAScript. I do agree here with Cameron. This could cause inconsistency issues, some object would be compared according to pointer like approach, some object would be compared according to toString()/valueOf() approach; some objects might represent the same data when stringified, yet be different ([object Object]). The fact, that programmer does not know that window.location is Location object, not string should be no excuse here. Setter of this object can accept string, that is fine, but getter should return always the same, not sometimes string, sometimes object... if xw.location == yw.location are the same based on string comparison, we would introduce type coercion to comparison with already the same type on both sides, heh?. And at last, what should var x = xw.location do? what is the type of x? String? it makes no sense at all. Object? fine, but then how come sometimes getter returns object (in assignments) and sometimes string (in comparison). ECMAScript defines no operator overloading, and we should not introduce one arbitrary because someone does not read spec, does not test, does not use browsers development tools, etc. Brona
