Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Sun, Jan 22, 2012 at 1:50 AM, Mounir Lamouri mou...@lamouri.fr wrote: On 12/15/2011 10:17 PM, Ilya Sherman wrote: 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 Looking at the list of types you are proposing, I was wondering if we couldn't solve this another way. We could create two new input types: 'contact' (or person, or anything better) and 'address'. 'address' could even be part of 'contact' given that is a contact information. There is currently some work being done to access contact information [1] [2]. Currently, the way we handle names and addresses is probably suboptimal and websites have to re-invent a lot of things. A simple field that would ask the user to give those information might be way better for both authors and users. For example, on a mobile phone, I would be able to pick up one of my contact address to send him a gift instead of typing it. I believe that doing that would have the side effect to solve the autocompletion issue but would do much more. Other input types like 'email' and 'tel' should be able to solve the phone, fax and email autocompletetypes I believe. Authors should stop using multiple fields for telephone and use input type='tel' instead. Then, UA could always present the same autocomplete list when type=email or type=tel is used if they believe it's better. Extending the existing input 'type' attribute is an interesting idea, thanks for raising it. Looking through the existing input type values, it seems they are primarily chosen so as to enable user agents to render and format the input data in type-appropriate ways. However, the existing types do not try to nail down the field's exact data type beyond the needs of this use case -- for example, input type='tel' currently covers both phone and fax fields. In contrast, for many autocomplete/autofill agents, the distinction between phone and fax fields is important. One possibility -- also suggested by Kornel Lesiński on a separate thread -- would be to simply permit all of the attribute values from the 'autocompletetype' proposal as values for the 'type' attribute. This avoids introducing a new attribute, but co-opts the 'type' attribute. My guess is that people would object to co-opting the 'type' attribute in this way, but perhaps I am wrong... Another possibility, closer to your first suggestion, is to add one or two new input types, along the lines of 'contact', 'person', and/or 'address'. I've given this a fair bit of thought, and I'm just not sure how to make the details work out more smoothly than with the current autocompletetype proposal. Here are my two main hesitations: (1) The website's developer still needs to specify what data, specifically, is required. For example, consider an input type=contact field. The phone number might not be necessary, in which case most users would probably prefer not to share their phone numbers. Or, consider an input type=address field for a billing address. It might be sufficient for the developer to simply ask for the country and postal code information; and, again, the user might not be willing to share further information needlessly. So, these broad input types still need additional markup -- seemingly quite similar to the markup proposed for the autocompletetype attribute's values -- to more precisely specify what data is requested. Moreover, some Autofill agents work better if they can distinguish a shipping address from a billing address; again, specifying this distinction would require additional markup. (2) As a consequence, this proposal requires additional UI from user agents, and hence breaks backward compatibility. While it's definitely handy to be able to select a contact from one's phone's address book and fill the entire form in one go, a user should also be able to fill such fields by hand. This requires the user agent to somehow make clear to the user exactly what data is requested, and what format to fill it in (again, some data can be optional; and some can be required). This seemingly requires new UI, e.g. to render a single input type=address as a list of the required address fields. Existing user agents would lack such UI, which means that site developers could not use these new input types for the vast majority of users running older user agents. Had you already considered these issues, and perhaps had some solutions for them in mind? Also, I do not understand why we have credit cards types. Is anyone willing to have his
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Sun, Jan 22, 2012 at 11:57 PM, Simon Pieters sim...@opera.com wrote: On Sat, 21 Jan 2012 00:28:25 +0100, Ilya Sherman isher...@chromium.org wrote: The extensibility story should maybe use the wiki registration style like link rel keywords. Sorry, I'm not quite following what you mean by this. http://www.whatwg.org/specs/**web-apps/current-work/** multipage/links.html#concept-**rel-extensionshttp://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#concept-rel-extensions http://www.whatwg.org/specs/**web-apps/current-work/** multipage/semantics.html#**concept-meta-extensionshttp://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#concept-meta-extensions Ah, I see. That seems like a good idea -- added an Extensibility section with this suggestion to the wiki. Thanks :)
Re: [whatwg] autocompletetype vs autocomplete, type attributes
(Note that the main thread for this discussion is here: [ http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-January/034429.html].) On Wed, Jan 25, 2012 at 12:03 PM, Kornel Lesiński kor...@geekhood.netwrote: Google's annoucement of autocompletetype type[1] uses type=text field for e-mail input, which doesn't seem right given that HTML has input type=email already. Yes, this was a poor choice of example, sorry. Imagine that the example was address line 1 instead :) Should input type=text autocompletetype=email behave just like input type=email? Similar ambiguity exists for input type=text autocompletetype=phone-full and input type=tel. IMO, the autocompletetype attribute should have no effect on the rendering/formatting of the form field, whereas the type attribute should. So, user agents might validate the format of data entered into an input type=email field, but should not try to perform similar validation for an input type=text autocompletetype=email field. input type=tel is actually a little more subtle, in that it is ambiguous between what type of phone number is expected: a regular phone number, a fax number, etc.? Why not fold autocompletetype types into the existing type attribute (or autocomplete attribute)? Type could be redefined as space-separated list, so input type=cc-full-name name-full section-billing could work just like autocompletetype. It would be backwards compatible with HTML5 types and fall back to text for new types or lists. I've commented on this suggestion in the other thread (Proposal for autocompletetype Attribute in HTML5 Specification, linked to above). Briefly, I think the type attribute is designed to describe slightly broader types, just detailed enough to enable user agents to properly render or format or validate form fields and their data. The autocompletetype attribute, on the other hand, tries to achieve a higher level of precision. I anticipate that merging these two use cases into a single attribute is undesirable, but I'd love to hear from those more deeply familiar with the design decisions behind the type attribute. Having all of type, autocomplete and autocompletetype looks quite messy. One small saving grace here: Since autocomplete defaults to on, it should be rare to need to specify both autocomplete and autocompletetype. [1] http://googlewebmastercentral.**blogspot.com/2012/01/making-** form-filling-faster-easier-**and.htmlhttp://googlewebmastercentral.blogspot.com/2012/01/making-form-filling-faster-easier-and.html -- regards, Kornel Lesiński
Re: [whatwg] add html-attribute for responsive images
Am 25.01.2012 16:39 schrieb Matthew Wilcox: It's also worth noting another use case for this being in mark-up and not just server-negotiated rescaling of a single image: Imagine a profile photo on an About page. At large sizes you want to use a full body shot, at smaller sizes you need to retain what's important but no longer clear at small scales: a recognisable face - so you substiture a head and shoulders shot. That's a strong use case where the semantic meaning of the content is the same but requires a different resource to be properly conveyed at differing scales. This use case shows some kind of consistency issue: The printed version of a page might match a different media query, and thus use a different image. If the images have different contents, this can result in a confusing user experience. In order to work around this, UAs might want to keep the first image loaded, when the content is used for a different type of media, such as print or PDF output. (That could also be the case for changes of window size.) There was some more discussion on this type of use case: Am 25.01.2012 14:42 schrieb David Goss: On Tue, 24 Jan 2012 23:26, Ian Hickson wrote: What's the use case for doing it for images inimg elements? Typically img elements are for content images, where you don't usually want to adapt anything. On Tue, 30 Aug 2011, Karl Dubost wrote: And as I explained elsewhere it is not a question of high/low-resolution only, but about interaction contexts. Different images for different surface sizes. Desktop: Show a full photo of Anne van Kesteren riding on a plane 1024*250 px Tablet: Show the photo a closer shot of the plane (cowboy frame) 400*150 px Mobile: Show a portrait of Anne with his leather pilot helmet 100x100 px I don't understand the use case. For something like a user profile icon surely it would be rather bad UI to use a different icon on different devices. I presume you don't mean a profile icon though, since 1024x250 is a bit excessive for an icon these days, and I'm not aware of any site that lets users pick different icons for different size contexts. The use case is that you want to serve the same image (same content) to all users, but you want to serve it in different resolutions depending on their context to avoid wasting bandwidth and killing performance (especially on mobile devices where performance is key - you don't want to download a 1000px-wide image when you're scaling it down to 320px wide to display it). Karl's example is on dangerous ground, IMO. The different sizes of the image could be slightly cropped/zoomed as appropriate, but should still clearly represent the same thing - in other words, the same alt text should correctly describe all of them.
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On 12/15/2011 10:17 PM, Ilya Sherman wrote: To that end we would like to propose adding an autocompletetype attribute [1] to the HTML5 specification, This name is very verbose. Isn't there something shorter — for example fieldtype — that we could use instead?
Re: [whatwg] Feedback on Meta referrer
On 1/26/12 9:12 AM, Adam Barth wrote: Should the speculative parser have knowledge ofmeta name=referrer? That's not what's currently specified. Like many other browser features, this feature lets web sites detect that the browser is speculatively prefetching resources. If that's a big issue, it's something we can try to address. It seems like a bigger problem is that if speculative prefetches don't know about this meta then they will leak the referrer, which is something the site did NOT want to happen. So it seems like either this meta needs to disable prefetch altogether or be taken into account when prefetching. Either way, the prefetch code needs to know about it. I'm not sure all implementations have the speculative parser understandbase. For example, WebKit's preload scanner does not appear to understand thebase element: http://trac.webkit.org/browser/trunk/Source/WebCore/html/parser/HTMLPreloadScanner.cpp That's not as big a deal, because it will just mean you prefetch the wrong thing and have to do a second fetch. (That said, I think we may have had bug reports about the prefetch not understanding base; Henri would know for sure). -Boris
Re: [whatwg] Feedback on Meta referrer
On Thu, Jan 26, 2012 at 1:35 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/26/12 9:12 AM, Adam Barth wrote: Should the speculative parser have knowledge ofmeta name=referrer? That's not what's currently specified. Like many other browser features, this feature lets web sites detect that the browser is speculatively prefetching resources. If that's a big issue, it's something we can try to address. It seems like a bigger problem is that if speculative prefetches don't know about this meta then they will leak the referrer, which is something the site did NOT want to happen. So it seems like either this meta needs to disable prefetch altogether or be taken into account when prefetching. Either way, the prefetch code needs to know about it. I've added a TODO to http://wiki.whatwg.org/wiki/Meta_referrer to add this requirement. I'm slightly unsure how to specify it because the preload scanner isn't part of the spec's machinery, but we'll figure out a way. I'm not sure all implementations have the speculative parser understandbase. For example, WebKit's preload scanner does not appear to understand thebase element: http://trac.webkit.org/browser/trunk/Source/WebCore/html/parser/HTMLPreloadScanner.cpp That's not as big a deal, because it will just mean you prefetch the wrong thing and have to do a second fetch. (That said, I think we may have had bug reports about the prefetch not understanding base; Henri would know for sure). Makes sense. Thanks, Adam
Re: [whatwg] Feedback on Meta referrer
Le 26/01/2012 10:35, Boris Zbarsky a écrit : On 1/26/12 9:12 AM, Adam Barth wrote: Should the speculative parser have knowledge ofmeta name=referrer? That's not what's currently specified. Like many other browser features, this feature lets web sites detect that the browser is speculatively prefetching resources. If that's a big issue, it's something we can try to address. It seems like a bigger problem is that if speculative prefetches don't know about this meta then they will leak the referrer, which is something the site did NOT want to happen. A radically different approach that websites could take to express not wanting the referrer to be sent on requests for a given page would be sending a specific HTTP header in the response. This way, the user agent would know what the intention is before having to read any meta header and could do the prefetches without sending the referrer. David
Re: [whatwg] Feedback on Meta referrer
On Thu, Jan 26, 2012 at 1:46 AM, David Bruant bruan...@gmail.com wrote: Le 26/01/2012 10:35, Boris Zbarsky a écrit : On 1/26/12 9:12 AM, Adam Barth wrote: Should the speculative parser have knowledge ofmeta name=referrer? That's not what's currently specified. Like many other browser features, this feature lets web sites detect that the browser is speculatively prefetching resources. If that's a big issue, it's something we can try to address. It seems like a bigger problem is that if speculative prefetches don't know about this meta then they will leak the referrer, which is something the site did NOT want to happen. A radically different approach that websites could take to express not wanting the referrer to be sent on requests for a given page would be sending a specific HTTP header in the response. This way, the user agent would know what the intention is before having to read any meta header and could do the prefetches without sending the referrer. Indeed. I plan to propose this as a directive for CSP 1.1. Adam
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Fri, Jan 20, 2012 at 6:28 PM, Ilya Sherman isher...@chromium.org wrote: 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. I don't see how requiring forms to lump the address together is going to help -- if the database stores the fields separately, other APIs that the backend needs to give the address to (such as shipping carriers, address cleanup/geocoding, etc) expects separate fields then all you are doing is pushing the parsing of the address off to the backend rather than letting the user see it. Also, I think a properly localized (ie, fields dependent on the country given) address form is much more likely to get the correct data from the user than just asking them to enter a blob of text. One question -- how does this fit with, say, a select element for country that shows localized country names? Can it be autocompleted as well? If so, does it match on the localized names, the value (which might be an ISO 2 or 3-digit code, or something unique to the app), or what? -- John A. Tamplin Software Engineer (GWT), Google
Re: [whatwg] add html-attribute for responsive images
On 26 January 2012 09:21, Markus Ernst derer...@gmx.ch wrote: Am 25.01.2012 16:39 schrieb Matthew Wilcox: It's also worth noting another use case for this being in mark-up and not just server-negotiated rescaling of a single image: Imagine a profile photo on an About page. At large sizes you want to use a full body shot, at smaller sizes you need to retain what's important but no longer clear at small scales: a recognisable face - so you substiture a head and shoulders shot. That's a strong use case where the semantic meaning of the content is the same but requires a different resource to be properly conveyed at differing scales. This use case shows some kind of consistency issue: The printed version of a page might match a different media query, and thus use a different image. If the images have different contents, this can result in a confusing user experience. In order to work around this, UAs might want to keep the first image loaded, when the content is used for a different type of media, such as print or PDF output. (That could also be the case for changes of window size.) I think Matthew has it about right with the about page example. I think as long as the user can recognise that it's the same image (albeit cropped/zoomed in some way to adapt to the media) then we're okay.
Re: [whatwg] Detached elements and delaying the load event
On 01/25/12 23:06, Ian Hickson wrote: On Tue, 6 Sep 2011, Andrew Oakley wrote: I'm going to use the img element as an example here, but the same thing applies to other elements such as iframe, video, audio. I'm going to assume that the user agent obtains the images immediately, given that seems to be what most browsers do. If an img element is created and given a src attribute (but not necessarily attached to the tree) then, according to HTML5, we need to update the image data and therefore delay the load event. I guess this means we should lock the image element in a similar fashion to XMLHttpRequest objects, otherwise the image could be garbage collected before it has been loaded and therefore block the load event indefinitely. Firefox, Opera, Chrome and Safari do seem to implement this behaviour, IE does not. I would prefer not to implement this and just say detached elements do not delay the load event, but I'm not sure if that will always work. Can we please get a clarification in HTML5, either to say that these detached objects must not be garbage collected while they are delaying the load event, or to say that they do not delay the load event. Done for img. OK, so we don't GC the img while it is loading. video and audio already had requirements to this effect. OK, that looks similar. iframe outside a document doesn't initiate a load, so it's case is different. I'm not sure it is - we can create an iframe in the document then remove it before it loads. Most browsers seem to give up on loading the contents of the iframe if you do this (IE continues to delay the load event until it has loaded the iframe). As far as I can tell HTML5 says that you shouldn't do anything when an iframe is removed from a document (and therefore the frame should continue to load and delay the load event, assuming it isn't GC'd). I think we should be consistent here - if we continue to delay the load events for img, video and audio after they have been removed from the tree then the same should be true for iframe. -- Andrew Oakley
Re: [whatwg] autocompletetype vs autocomplete, type attributes
On Thu, 26 Jan 2012 08:38:41 -, Ilya Sherman isher...@chromium.org wrote: IMO, the autocompletetype attribute should have no effect on the rendering/formatting of the form field, whereas the type attribute should. So, user agents might validate the format of data entered into an input type=email field, but should not try to perform similar validation for an input type=text autocompletetype=email field. Orthogonality of validation and autofill sounds nice, but is it useful in practice? The only use case I can think of for a field autocompleted like an e-mail field, but not validated like an e-mail field would be login form with a username field that accepts either username or e-mail. However, login forms are better served by login-specific autofill that is in current browsers (saving opaque login field and password field together), since you don't want to enter arbitrary e-mail address from your addressbook, but a specific e-mail/login and a matching password at the same time. Are there any other cases where you'd like field that is autocompleted, but doesn't otherwise behave like the autocompleted type? But even if single-mixed-login-field autocomplete was desired, then perhaps a mixed type would work too: input type=username email It could be defined to mean that either of the two types is accepted, and autocomplete works for both. Also orthogonal type and autocompletetype allows nonsense combinations like input type=number autocompletetype=email, while a precise type attribute would ensure that rendering and autocomplete always make sense together. input type=tel is actually a little more subtle, in that it is ambiguous between what type of phone number is expected: a regular phone number, a fax number, etc.? Which is why I've suggested extending type attribute to take a token list: input type=tel fax (my expected rendering for this field would be [ are you serious? fax in the 21st century!? ] ;) Briefly, I think the type attribute is designed to describe slightly broader types, just detailed enough to enable user agents to properly render or format or validate form fields and their data. The autocompletetype attribute, on the other hand, tries to achieve a higher level of precision. I anticipate that merging these two use cases into a single attribute is undesirable, but I'd love to hear from those more deeply familiar with the design decisions behind the type attribute. In the thread you've pointed to I saw suggestion to make registration of new types open for anybody, and that could cause difficulty introducing new kids of validation/UI under names formerly used only for autocomplete. How about merging autocompletetype with autocomplete then? It looks sensible to me: input autocomplete=off input autocomplete=email In case of form autocomplete=offinput autocomplete=email/form I'd expect autocomplete=email to override form's off value. Having all of type, autocomplete and autocompletetype looks quite messy. One small saving grace here: Since autocomplete defaults to on, it should be rare to need to specify both autocomplete and autocompletetype. I can't imagine usefulness of this: input autocomplete=off autocompletetype=email and if that case is left out, then I don't see a reason to keep both attributes. I really like the idea of more specific autocomplete types and use of list of tokens for this, but the proposed attribute in its current form is overlapping/conflicting with existing attributes, and even the name 'autocompletetype' itself gives me an impression of a forced extension, rather than integral part of the language. -- regards, Kornel Lesiński
Re: [whatwg] Requests for new elements for comments
On Wed, 25 Jan 2012 22:26:31 -, Ian Hickson i...@hixie.ch wrote: Actually, they are remarkably similar. I think it's anachronistic to consider that the utterances of the site owner are in some way distinct from the utterances of the site readers. While I do agree with you (for a change), identifying authors of articles is undeniably useful. First-posters in a thread or syndication may be styled differently from other posters, articles by authors of outer articles may be emphasized in some way, articles by certain authors may be omit, etc. I find no algorithm for identifying authors of articles in the spec. Should the value of the first href attribute in a footer be assumed to identify the author? That seems bound to break, early and often. -- -,Bjartur
Re: [whatwg] Requests for new elements for comments
What's wrong with using a class on the article to identify the author stylistically? It's already identified semantically by having their name in the article itself, right (presumably in a footer too)? On 26 January 2012 13:57, Bjartur Thorlacius svartma...@gmail.com wrote: On Wed, 25 Jan 2012 22:26:31 -, Ian Hickson i...@hixie.ch wrote: Actually, they are remarkably similar. I think it's anachronistic to consider that the utterances of the site owner are in some way distinct from the utterances of the site readers. While I do agree with you (for a change), identifying authors of articles is undeniably useful. First-posters in a thread or syndication may be styled differently from other posters, articles by authors of outer articles may be emphasized in some way, articles by certain authors may be omit, etc. I find no algorithm for identifying authors of articles in the spec. Should the value of the first href attribute in a footer be assumed to identify the author? That seems bound to break, early and often. -- -,Bjartur
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Thu, Jan 26, 2012 at 12:15 AM, Ilya Sherman isher...@chromium.orgwrote: Extending the existing input 'type' attribute is an interesting idea, thanks for raising it. Looking through the existing input type values, it seems they are primarily chosen so as to enable user agents to render and format the input data in type-appropriate ways. However, the existing types do not try to nail down the field's exact data type beyond the needs of this use case -- for example, input type='tel' currently covers both phone and fax fields. In contrast, for many autocomplete/autofill agents, the distinction between phone and fax fields is important. I think of the distinction here as follows: Imagine the various values forms might want. For example, first name, last name, home address, work address, home phone, mobile phone, fax. Now classify these by kind. (For an object-oriented programmer like me, this would be enumerate the different classes/types required to hold the above values.) You might come up with name, address, phone number. All phone numbers share some set of properties, such as consisting of digits, as do all names, all addresses, etc. The distinction between what kind of a value something is and what precise instance of that kind it is is a valuable distinction. As you noted already, the former can be used to do structural validation or provide helpful UI for entry without needing to understand the latter. I see type versus autocompletetype in this same way. type allows the UA to understand the structure of a form value while autocompletetype allows it to understand which particular values might commonly go there. Certainly we could eliminate the former and just use the latter, but there is a major downside. Imagine my UA has support for all the above example specific types I gave. Now a web author wants to write a form with a new value, e.g. maiden name or pager number. It would be wrong to use any of the above autocompletetype values, since this field doesn't mean any of those things. But that means I can't get the UA to do validation or UI assistance for me either. We could try to solve this by allowing our unified type attribute to take on the union of all type and autocompletetype values. But this is confusing. When I can have type phone number or home phone number, which do I use? It's not necessarily clear to a web author what the practical ramifications of this choice are. Therefore, I think leaving these fields separate makes sense even if sometimes one could imply the type from the autocompletetype. PK
Re: [whatwg] Requests for new elements for comments
Þann fim 26.jan 2012 14:48, skrifaði Matthew Wilcox: What's wrong with using a class on the article to identify the author stylistically? It's already identified semantically by having their name in the article itself, right (presumably in a footer too)? As in article class=asdf lolcats author-bjar...@spam.la? Because then the class would contain content. That would depend on a stylesheet containing the identifier of every poster on every page. Generating such stylesheets from content already marked up in a page in a nonstandard fashion seems hackish at best, and harmful to usability at worst. The situation only gets worse when you consider the different stylistic needs of various media. I might want the whole footer rendered to the relatively large desktop screen of mine, but omit everything but authors' name or identity on my handheld screen. Address, for example, should be hidden behind a menu button and the authors name displayed tersely. The best solution I can think of is stating normatively that hCard footers describe authors of the respected article or document. hCard does not, AFAIK, provide means to state URIs of authors, but indirect identification using email addresses should suffice. !DOCTYPE html titleExample of Semantically Marking up Authors of Documents/title article h1An Article Written by Bjartur/h1 pThis article was written to demonstrate how authorship might be marked up. I sure hope it's valid!/p footer class=hcard a class=fn email href=mailto:bjar...@spam.la;Bjartur Thorlacius/a /footer /article
Re: [whatwg] Requests for new elements for comments
Obviously this is not right - perhaps I'm not understanding your use case? Why would you want to specify an author as an attribute on the element? What is wrong with: article class=by-post-author pContent/p footer p class=authorWritten by: Person/p /footer /article Any time you do this the information will have been pulled through a CMS, so it's trivial to have a class appended to the article. When would you want this as pure HTML that's not been parsed by some form of CMS? On 26 January 2012 21:43, Matthew Wilcox elven...@gmail.com wrote: On 26 Jan 2012, at 20:47, Bjartur Thorlacius wrote: Þann fim 26.jan 2012 14:48, skrifaði Matthew Wilcox: What's wrong with using a class on the article to identify the author stylistically? It's already identified semantically by having their name in the article itself, right (presumably in a footer too)? As in article class=asdf lolcats author-bjar...@spam.la? Because then the class would contain content. Obviously this is not right - perhaps I'm not understanding your use case? Why would you want to specify an author as an attribute on the element? What is wrong with: article class=by-post-author pContent/p footer p class=authorWritten by: Person/p /footer /article Any time you do this the information will have been pulled through a CMS, so it's trivial to have a class appended to the article. When would you want this as pure HTML that's not been parsed by some form of CMS? That would depend on a stylesheet containing the identifier of every poster on every page. Generating such stylesheets from content already marked up in a page in a nonstandard fashion seems hackish at best, and harmful to usability at worst. The situation only gets worse when you consider the different stylistic needs of various media. I might want the whole footer rendered to the relatively large desktop screen of mine, but omit everything but authors' name or identity on my handheld screen. Address, for example, should be hidden behind a menu button and the authors name displayed tersely. The best solution I can think of is stating normatively that hCard footers describe authors of the respected article or document. hCard does not, AFAIK, provide means to state URIs of authors, but indirect identification using email addresses should suffice. !DOCTYPE html titleExample of Semantically Marking up Authors of Documents/title article h1An Article Written by Bjartur/h1 pThis article was written to demonstrate how authorship might be marked up. I sure hope it's valid!/p footer class=hcard a class=fn email href=mailto:bjar...@spam.la;Bjartur Thorlacius/a /footer /article
Re: [whatwg] Autofocus readonly Input Elements
On Fri, 23 Sep 2011, Ojan Vafai wrote: On Fri, Sep 23, 2011 at 11:49 AM, Ian Hickson i...@hixie.ch wrote: If they're focusable at all, I don't see why they wouldn't be autofocusable. Is there a use case for special-casing read-only ones? Right. The question is whether read-only/disabled/hidden inputs should be focusable. I don't personally see pros and cons in either direction, but I wanted to make sure there was agreement here before changing WebKit's behavior. The intent is to match the behaviour of the native platform GUI, which generally speaking means readonly controls are focusable, and disabled and hidden ones are not. There's nothing special about autofocus= here. It's just like calling focus() on the element. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] beforepopstate event?
On Sun, 25 Sep 2011, Thomas Broyer wrote: Is there really no equivalent to the beforeunload event for the History API? Has it been discussed? or is this an oversight? Does the pagehide event do what you mean? -- 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 Thu, Jan 26, 2012 at 1:29 AM, James Graham jgra...@opera.com wrote: On 12/15/2011 10:17 PM, Ilya Sherman wrote: To that end we would like to propose adding an autocompletetype attribute [1] to the HTML5 specification, This name is very verbose. Isn't there something shorter — for example fieldtype — that we could use instead? Or perhaps we could simply extend the autocomplete attribute with these new semantics (see my most recent message to this thread).
Re: [whatwg] Question: rel=help
On Thu, 29 Sep 2011, Schalk Neethling wrote: Question, would an element with rel=help and a title=Help text make sense and be valid as a JavaScript hook for tooltips? Does not match the usage as described by the WHAT-WG (http://developers.whatwg.org/links.html#link-type-help) exactly, but close enough? On Thu, 29 Sep 2011, Anne van Kesteren wrote: If there is no actual hyperlink, using a link relation does not make sense. Indeed. On Thu, 29 Sep 2011, Schalk Neethling wrote: I heard some mention of using the data-* attributes so, something like: a href= data-tooltip=Some help text/a or input type=text data-tooltip=Some help text / Would you agree that this is the better option? If what you want is a tooltip, then the title= attribute is probably your best bet. No need for any scripting. -- 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
One question -- how does this fit with, say, a select element for country that shows localized country names? Can it be autocompleted as well? If so, does it match on the localized names, the value (which might be an ISO 2 or 3-digit code, or something unique to the app), or what? I would expect that this varies across autofill agents. For Chrome, we handle this case pretty well by leveraging the ICU library [ http://site.icu-project.org/ ].
Re: [whatwg] autocompletetype vs autocomplete, type attributes
On Thu, Jan 26, 2012 at 5:03 AM, Kornel Lesiński kor...@geekhood.netwrote: On Thu, 26 Jan 2012 08:38:41 -, Ilya Sherman isher...@chromium.org wrote: IMO, the autocompletetype attribute should have no effect on the rendering/formatting of the form field, whereas the type attribute should. So, user agents might validate the format of data entered into an input type=email field, but should not try to perform similar validation for an input type=text autocompletetype=email field. Orthogonality of validation and autofill sounds nice, but is it useful in practice? The only use case I can think of for a field autocompleted like an e-mail field, but not validated like an e-mail field would be login form with a username field that accepts either username or e-mail. However, login forms are better served by login-specific autofill that is in current browsers (saving opaque login field and password field together), since you don't want to enter arbitrary e-mail address from your addressbook, but a specific e-mail/login and a matching password at the same time. Are there any other cases where you'd like field that is autocompleted, but doesn't otherwise behave like the autocompleted type? My comment was really meant in direct response to your question of Should input type=text autocompletetype=email behave just like input type=email? Assuming type and autocompletetype remain separate attributes, I would not expect the value of the autocompletetype attribute to have any implications on rendering, formatting, or validation of the corresponding field and its data -- so the two snippets of HTML you provided should behave slightly differently. But even if single-mixed-login-field autocomplete was desired, then perhaps a mixed type would work too: input type=username email It could be defined to mean that either of the two types is accepted, and autocomplete works for both. Also orthogonal type and autocompletetype allows nonsense combinations like input type=number autocompletetype=email, while a precise type attribute would ensure that rendering and autocomplete always make sense together. A space-separated type attribute likewise allows a nonsense combination like input type=number email. We considered creating a stricter hierarchy of types that would disallow such nonsense. However, (a) developers could type the nonsense anyway, so we'd still have to specify the error recovery mechanism; and (b) enforcing a hierarchy makes the extensibility story much trickier. input type=tel is actually a little more subtle, in that it is ambiguous between what type of phone number is expected: a regular phone number, a fax number, etc.? Which is why I've suggested extending type attribute to take a token list: input type=tel fax Ah, I had thought you were suggesting that simply input type=fax should be valid, and should behave just as input type=tel does, except with more fine-grained type information. My concern with input type=tel fax is that the user agent now has to parse the type attribute in two different ways: (i) For formatting and validation, the user agent should parse tel as the relevant token; but (ii) for autofill, the user agent should parse fax as the relevant token (and fall back to tel if fax is not understood). This gets really complex to describe and implement. For example, how should input type=fax tel be parsed? What should happen if the markup simply says input type=fax? What about input type=tel x-3D-fax fax and the various permutations of those tokens? (my expected rendering for this field would be [ are you serious? fax in the 21st century!? ] ;) I rather agree :) (A lot of websites do still have fax fields, though...) Briefly, I think the type attribute is designed to describe slightly broader types, just detailed enough to enable user agents to properly render or format or validate form fields and their data. The autocompletetype attribute, on the other hand, tries to achieve a higher level of precision. I anticipate that merging these two use cases into a single attribute is undesirable, but I'd love to hear from those more deeply familiar with the design decisions behind the type attribute. In the thread you've pointed to I saw suggestion to make registration of new types open for anybody, and that could cause difficulty introducing new kids of validation/UI under names formerly used only for autocomplete. How about merging autocompletetype with autocomplete then? It looks sensible to me: input autocomplete=off input autocomplete=email In case of form autocomplete=offinput autocomplete=email/form I'd expect autocomplete=email to override form's off value. I actually like this idea a lot. We had previously chosen not to extend the autocomplete attribute because we were worried about backward compatibility. In particular, we were worried that existing user agents might interpret input type=text
Re: [whatwg] Drag and drop: bugged implementation of setting drag feedback with setDragImage?
On Thu, 29 Sep 2011, Rafa�~B Mi�~Becki wrote: I've a question regarding setDragImage. I've implemented dragstart event handler in the following way: event.setDragImage(this, 0, 0); this.style.background = 'yellow'; What do I expect: 1) Origin element to have yellow background 2) Drag feedback element (the one under cursor) to have original background Are my expectations correct? Sort of. The spec doesn't say that the drag image needs to exactly match the element, so technically browsers are allowed to set the bitmap to what the element will look like at some time in the future... But yeah, in principle, what you describe is correct. Because Webkit and Gecko implementation doesn't match it. In their cases both elements have modified background. It seems that both engines delay setting drag image until the end of event handler. On Fri, 30 Sep 2011, Daniel Cheng wrote: The reason it works that way is inside the dragstart handler, when you call setDragImage, we merely retain a reference to the element you passed in. We don't actually create the drag image until after dragstart processing is finished. Makes sense. Seems more useful to support what Rafal is trying to do, though, so I haven't currently changed the spec for this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] autocompletetype vs autocomplete, type attributes
On Thu, 26 Jan 2012 22:59:49 -, Ilya Sherman isher...@chromium.org wrote: Ah, I had thought you were suggesting that simply input type=fax should be valid, and should behave just as input type=tel does, except with more fine-grained type information. My concern with input type=tel fax is that the user agent now has to parse the type attribute in two different ways: (i) For formatting and validation, the user agent should parse tel as the relevant token; but (ii) for autofill, the user agent should parse fax as the relevant token (and fall back to tel if fax is not understood). This gets really complex to describe and implement. For example, how should input type=fax tel be parsed? What should happen if the markup simply says input type=fax? What about input type=tel x-3D-fax fax and the various permutations of those tokens? You have a good point. If UA is supposed to choose first type it understands, then tel fax wouldn't work as a fax field, but fax tel would. That's a nasty gotcha, so a selection algorithm should be more sophisticated than that. input autocomplete=off input autocomplete=email In case of form autocomplete=offinput autocomplete=email/form I'd expect autocomplete=email to override form's off value. I actually like this idea a lot. We had previously chosen not to extend the autocomplete attribute because we were worried about backward compatibility. In particular, we were worried that existing user agents might interpret input type=text autocomplete=bogus -- and hence also input type=text autocomplete=email -- to be equivalent to input type=text autocomplete=off. However, I just checked with IE, Chrome, Firefox, Safari, and Opera -- all simply ignore autocomplete=bogus. So, we seem to be ok in terms of backward compatibility -- hooray! If I don't see any objections over the next few days, I'll go ahead and update the proposal to extend the autocomplete attribute rather than introducing the additional autocompletetype attribute. That's great! If I may bikeshed a bit more: since HTML5 uses tel, then autocomplete[type] should use word tel too (instead of phone) — just to be consistent and use same name for the same thing. Order of words in cc-full-name is inconsistent with name-full. hCard uses given-name and family-name, while current autocomplete proposal has same given-name, but uses surname. It would be nice to rename autocomplete types for consistency with hCard where possible (unless they're consistent already with something else I don't know :) -- regards, Kornel Lesiński
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On Tue, 4 Oct 2011, Julien Chaffraix wrote: following WebKit's attempt at implementing the behavior of |sheet| and |disabled| per HTML5 / CSSOM [1], we have found that the specs [2] [3] either under-specify the behavior or do not match what browsers are doing. The spec has changed a bit since your e-mail; can you check again and see if the improvements are sufficient? * Opera and FF always have an associated stylesheet if |link.rel| matches a stylesheet and |href| is set. * They both fill link.sheet with default values even if the stylesheet was / ends up in error. This is per the spec now. * However, FF loads the stylesheet synchronously whereas Opera does it asynchronously from a JS perspective This is required per the spec: a pending link rel=stylesheet load does block certain scripts from executing. See: http://www.whatwg.org/specs/web-apps/current-work/#has-a-style-sheet-that-is-blocking-scripts * Some websites (4chan.org for examples) assumes that the |sheet| is always available and that |disabled| will work properly regardless of when it is called. This is now per spec as far as I can tell. See: http://www.whatwg.org/specs/web-apps/current-work/#styling On Wed, 5 Oct 2011, Henri Sivonen wrote: On Tue, Oct 4, 2011 at 9:54 PM, Boris Zbarsky bzbar...@mit.edu wrote: What Firefox does do is block execution of script tags (but not timeouts, callbacks, etc!) if there are pending non-altenate parser-inserted stylesheet loads. This is necessary to make sure that scripts getting layout properties see the effect of those stylesheets. A side-effect is that a script coming after a link will never see the link in an unloaded state... unless there's a network error for the link or whatever. One exception: If an inline script comes from document.write(), it doesn't block on pending sheets. It runs right away. If it blocked on pending sheets, the point at which document.write() returns would depend on network performance, which I think would be worse than having document.written inline scripts that poke at styles fail depending on network performance. Note that this is not conforming. The spec does not currently define any such behaviour. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Cut and paste (and related) events' futures
This is my first post to the mailing list, so please forgive me if the following is inappropriate for the list and let me know where I should direct this instead (h...@whatwg.org? http://h...@whatwg.org/?). In all the last-released versions of the major browsers (except Opera), there's support for cut-and-paste events like onpaste on input type=text... and textarea elements. Is there any plan to put these events into the standard? Isn't that a basic tenent of WHATWG--if the real-world vendor implementations are in consensus yet don't reflect the standard, change (or add to) the standard to reflect the de facto market standard, so long as any modifications are backwards compatible? Thanks, all! Chris
Re: [whatwg] Cut and paste (and related) events' futures
Hi Chris, On Thu, 26 Jan 2012 20:27:41 -0600, Chris O'Brien accou...@prettycode.org wrote: In all the last-released versions of the major browsers (except Opera), there's support for cut-and-paste events like onpaste on input type=text... and textarea elements. Is there any plan to put these events into the standard? Isn't that a basic tenent of WHATWG--if the real-world vendor implementations are in consensus yet don't reflect the standard, change (or add to) the standard to reflect the de facto market standard, so long as any modifications are backwards compatible? You're probably looking for this: http://dev.w3.org/2006/webapi/clipops/clipops.html. A search for clipboard data API in the archives might bring up some interesting discussion as well. Cheers, -- Mike Taylor Opera Software
[whatwg] Localization on script level and non form field
Hello,
we are currently discussing localization in form fields, but that may
result in some unfortunate behavior if implemented alone, because data
will be displayed in localized representation in form fields but not in
HTML - server can translate text, but not localize data, since it has no
idea about local settings (language is not enough) and when data are
inserted into HTML on UA side using scripting, the problem is the same.
Suggestion
1/ output element
output element should follow similar logic for presentation as form fields
there is an example of output usage
http://dev.w3.org/html5/spec/the-output-element.html#the-output-element
form onsubmit=return false oninput=o.value = a.valueAsNumber +
b.valueAsNumber
input name=a type=number step=any +
input name=b type=number step=any =
output name=o/output
/form
but imagine full stop as thousands separator, comma as decimal ,
inserting 12.135,5 + 4.125,6 would result in 16261.1 (Number is fine,
presentation confusing)
so output element should follow presentation form of the forms as well
2/ FormatSettings object
[Constructor(),
Constructor(DOMString locale),
Constructor(FormatSettings locale),
]
interface FormatSettings {
attribute DOMString CurrencyString;
attribute Number CurrencyFormat;
attribute Number CurrencyDecimals;
attribute DOMString ThousandSeparator;
attribute DOMString DecimalSeparator;
attribute DOMString DateSeparator;
attribute DOMString TimeSeparator;
attribute DOMString ShortDateFormat;
attribute DOMString LongDateFormat;
attribute DOMString TimeAMString;
attribute DOMString TimePMString;
attribute DOMString ShortTimeFormat;
attribute DOMString LongTimeFormat;
attribute Array ShortMonthNames;
attribute Array LongMonthNames;
attribute Array ShortDayNames;
attribute Array LongDayNames;
attribute bool DaylightSavingTime;
attribute Number TimeZoneOffset;
DOMString format (String input, Array data)
Number CurrencyAsNumber (DOMString value)
Number StringAsNumber (DOMString value)
Date StringAsDate (DOMString value)
[and probably set of constants representing different types of error
regarding formatting and data sanitation]
}
Window and similar objects (WorkerGlobalScope, etc.) should provide
access to instance of FormatSettings object (e.g. window.formatSettings)
prefilled with actual local settings, all properties should be settable
to change default behavior. And such object should be constructable by
script to be used in formatting functions if some nonstandard formatting
should be required.
examples:
var x = new FormatSettings();
should fill the properties with current (underlying) locale
var x = new FormatSettings('sk_SK');
accept language parameter and should fill the properties with locales
according to Slovak language
var x = new FormatSettings();
alert(x.DecimalSeparator);
on Czech OS should show comma,
x.DecimalSeparator = '.';
alert(x.DecimalSeparator);
on Czech OS should show full stop
var y = new FormatSettings(x);
should create new format settings wit properties set up according to
constructor parameter
x.DecimalSeparator = ',.';
should throw an exception
This should allow easy localization on client side based on users locale
and switching locales on application level
all attributes should be settable (with certain sanitations)
* CurrencyString: currency sign/abbreviation ($, €, Kč), any string
no sanitation
* CurrencyFormat: enum(0, 1, 2, 3)
this property defines where the currency sign is (before, after) and
whether is separated by space or not (0 = $1, 1 = 1$, 2 = $ 1, 3 = 1 $)
sanitation required on settings
* CurrencyDecimals: not negative integer number of decimals in currency
sanitation required on settings
* ThousandSeparator: char(1); DecimalSeparator: char(1)
clear meaning of those
sanitation required on settings
* DateSeparator: char(1); TimeSeparator: char(1)
characters separating parts of date (year, month, day) and time (hour,
minutes, seconds)
separation on milliseconds should be ruled by DecimalSeparator
sanitation required on settings
* ShortDateFormat: string; LongDateFormat: string;
substitution format defining how dates should be displayed
something like
http://php.net/manual/en/function.date.php
http://www.freepascal.org/docs-html/rtl/sysutils/formatchars.html
could not care less about the replacement letters at this point :)
sanitation required on settings
* ShortTimeFormat: string; LongTimeFormat: string;
see date formats above
* TimeAMString: string; TimePMString: string;
am/pm localizations
no sanitation
* ShortMonthNames: array; LongMonthNames: array
array[0..11] of strings representing month names; 0 = January
sanitation required on settings
* LongDayNames: array; ShortDayNames: array
array[0..6] of strings representing day names; 0 = Sunday (not happy
about it but corresponding to Date.prototype.getDay)
sanitation required on settings
* DaylightSavingTime: bool
whether DST does
Re: [whatwg] Localization on script level and non form field
Form control presentations and ECMA Globalization API should be synchronized. We might need HTMLInputElement::numberFormat to set/get a Globalization.NumberFormat object. http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts -- TAMURA Kent Software Engineer, Google
