Re: [whatwg] Load events fired during onload handlers
For what it's worth, I think the weirdness described in this thread is a good reason not to try to make DOMContentLoaded consistent with the load event for the sake of consistency. For one thing, the code that manages the weirdness of the load event lives in a different place compared to the code that fires DOMContentLoaded. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] register*Handler and Web Intents
On Thu, Jul 26, 2012 at 5:20 AM, Ian Hickson i...@hixie.ch wrote: Thus, I propose a parallel mechanism in the form of an empty element that goes in the head: intent action=edit intent action, e.g. open or edit, default share type=image/png MIME type filter, default omitted, required if scheme omitted scheme=mailto Scheme filter, default omitted, required if type omitted href= Handler URL, default (current page) title=Foo Handler user-visible name, required attribute disposition=HandlerDisposition values, default overlay This is a severe violation of the Degrade Gracefully design principle. Adopting your proposal would mean that pages that include the intent element in head would parse significantly differently in browsers that predate the HTML parsing algorithm or in browsers that implement it in its current form. I believe that having the intent element break the parser out of head in browsers that don't contain the parser differences you implicitly propose would cause a lot of grief to Web authors and would hinder the adoption of this feature. My concerns could be addressed in any of these three ways: 1) Rename intent to link 2) Rename intent to meta 3) Make intent have an end tag and make it placed in body rather than head I prefer solution #1. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] register*Handler and Web Intents
On Thu, 2 Aug 2012, Henri Sivonen wrote: This is a severe violation of the Degrade Gracefully design principle. Adopting your proposal would mean that pages that include the intent element in head would parse significantly differently in browsers that predate the HTML parsing algorithm or in browsers that implement it in its current form. I believe that having the intent element break the parser out of head in browsers that don't contain the parser differences you implicitly propose would cause a lot of grief to Web authors and would hinder the adoption of this feature. My concerns could be addressed in any of these three ways: 1) Rename intent to link 2) Rename intent to meta 3) Make intent have an end tag and make it placed in body rather than head I'm pretty sure the short-term pain of introducing a new head element would be far lower than the long-term pain of either of those three solutions. _Far_ lower. link and meta already have tons of overloaded behaviours, but none of them come close to matching the set of attributes intent would need. So we'd be overloading them with yet another mechanism, further increasing author confusion for those elements forever. Having intent have an end tag is really ugly, since the element has no contents. We'd be forever requiring that authors add this dummy end tag that doesn't do anything, yet if forgotten causes all kinds of trouble in the DOM. Authors would try putting things inside it, further confusing matters. But now consider the short-term cost of adding an element to the head. All it does is make a few elements in the head leak to the body. The page still works fine in legacy UAs (none of the elements only work in the head). The intent works fine in new browsers, isn't confusing, doesn't have any random vestigial end tags. The only difference is that in legacy UAs, some elements happen to be in the body instead of the head, but that's hardly a big hardship -- and it's easy to work around, you just put the intent elements last in the head, and then you can even use their position in the DOM as a way to detect support. I really am unconvinced that this is a lot of grief. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A mechanism to improve form autofill
On Mon, 23 Jul 2012, Ian Hickson wrote: So we could define the autocomplete= field's value as follows: [...] I've now specced this, with some minor changes. On Wed, 25 Jul 2012, David Holloway wrote: A contact address might be helpful for sites that are non-commercial in nature. Airlines and hotels often ask for contact information such as here: https://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/autofill/heuristics/input/10_register_hotels.com.html?revision=89396view=markup Or, optionally: subsection = up to one of: shipping or billing Where omitting the subsection covers the general case. I went with making shipping/billing optional. Anything other than work, home, and fax? Should it be work-fax and home-fax? mobile, pager? Added those. On Wed, 25 Jul 2012, Maciej Stachowiak wrote: For some of these fields, autocomplete= as a hint to autocompletion seems sufficient. However, I think some may logically be a distinct input type as well. Some of the information represented in the proposal below is also redundant with existing type values (so it needs to be specified either twice or in a conflicting way). I've added a section that details the difference between type=, inputmode=, and autocomplete=. Let me know if that doesn't answer your questions on this front. I think cc-number is worthy of a distinctive type value. Credit card numbers have a distinctive syntax. At the very least, they are numeric and should trigger a numeric keyboard on touch devices and restriction to digits. But they cannot be input type=number because it would be wrong to format and localize the number (with comma or dot separators for instance), and a spinner button is an obviously inappropriate treatment. A similar consideration applies to cc-csc. These should either be assigned distinctive types, or else we need to introduce a new input type for a string of digits that is not to be formatted as a number or treated as a spinner button (input type=digits or input type=numeric). I think it is essential to do that before widely deploying these autocomplete values, or else browsers will start using the autocomplete value to drive behavior of the control itself, which defeats the purpose of having a separate autocomplete attribute. As far as I can tell, this is just input type=text inputmode=numeric. cc-exp subtypes could be distinguished by input type for cases where they are not selects. Or alternately, it would be nice if there was a way to use input type=month in browsers that have support for it, and the traditional two selects or two text fields. Without script, that's hard. With script it's possible today. language, bday, bday-day, bday-month, bday-year, It's unfortunate that we don't have distinct input types for just a day, just a month, or just a year. Why? (What's wrong with type=number, select, and type=number respectively?) input type=url exists, doesn't seem necessary to also have an autocomplete value. As with the others, type=url just means the data type is URL, it doesn't mean the value is my home page. Let me know if you still disagree after having read the section I added to the spec and I'll reconsider. :-) Also, should this not be a contact field? Do people have different home pages based on whether they're at home or at work or on their cellphone? contact-type = home, work, cell, or fax contact-field = one of: email, tel, tel-country-code, tel-national, tel-area-code, tel-local, tel-local-prefix, tel-local-suffix, tel-extension, impp I would suggest dropping the contact field values email and tel and instead infer them from type. Please let me know if you still support this after reading the aforementioned section in the spec. (In particular, the spec talks explicitly about the tel case.) So instead of input type=tel autocomplete=work tel you would just say input type=tel autocomplete=work (and would not be able to say input type=text autocomplete=work tel, which would be an inferior user experience when tel is given special behavior, or input type=email autocomplete=work tel, which would be inconsistent). I'm a little wary about adding more magic here, these attributes are already pretty complicated. See the autocomplete section's algorithms and let me know if you still think we should do something along those lines. If it's something people are willing to implement, I wouldn't want to stand in the way; I agree that it has some good side-effects (like making it impossible to have certain combinations). I could also introduce some conformance requirements to make the bogus combinations non-conforming; currently I haven't made type=tel autocomplete=email non-conforming for instance. On Wed, 25 Jul 2012, Anne van Kesteren wrote: This
Re: [whatwg] register*Handler and Web Intents
On Wed, Jul 25, 2012 at 10:20 PM, Ian Hickson i...@hixie.ch wrote:
Having carefully studied the Mozilla Web Activities proposal, the Web
Intents draft, the register*Handler APIs, and to a lesser extent the
dispatch mechanisms in existing operating systems (desktop and mobile) and
the piles of advocacy on teh subject on the Web, I've tried to come up
with a concrete proposal for merging all of them into a coherent whole
that addresses the limited use cases that are of most interest.
Overall, this proposal mainly draws from the following sources:
- For the handling mechanimsm, it's basically directly based on the
Mozilla System Message Handler mechanism.
- For the dispatch mechanism, it is based mainly on the Web Intents
draft.
- For the registration mechanism, it's based on extending the
register*Handler APIs consistently.
However, I have attempted to simplify the proposal from its sources of
inspiration, where that seemed possibly without sacrificing key use cases.
The overall design is that there are URLs that can handle particular
messages, herein called intents (mostly because that's what Web developers
seem to have adopted as the term already).
These intents are indications that the user, or the system on behalf of
the user, wants the application to do something or other.
For example: please open this PDF, please share these four images,
please be aware that it is now the time you asked to be awoken at,
please allow the user to compose an e-mail to this address.
We want pages to be able to handle intents promptly upon being opened.
This puts certain constraints on the design that are explained in detail
in the Mozilla System Intents thread:
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.webapi/o8bkwx0EtmM
This leads therefore to the first part of the concrete proposal:
partial interface Window {
void setIntentHandler(DOMString action, IntentCallback callback);
set generally implies only one value for a given key - is this the case?
Or is this more like add—where I can add an arbitrary number of handlers
to for any given action.
boolean hasPendingIntent(DOMString action);
}
callback IntentCallback = void (Intent intent);
Is there any way this can be re-thought that avoids adding more API to the
global object? What about using Intent as the global namespace object and
hanging the Intent API there. The Intent object below would need to be
renamed—why not Intention, it works nicely in discussion/explanation as
well: Intent handlers receive an Intention object as the sole argument
when the UA asynchronously calls the handler...
When a page is loaded, it registers its intent handler callback using
setIntentHandler(), and as soon as that happens, the UA asynchronously
calls the handler.
The Intent object itself just needs to describe what the page is being
asked to do. For this, I borrowed freely from all the proposals mentioned
above, and ended up with:
interface Intent {
See Intention above...
readonly attribute DOMString action,
Inclusion of an action property supports the arbitrary number of
handlers case (as well as the single delegation handler case.
readonly attribute DOMString type,
What piece of information is this?
readonly attribute any data,
void success(any data, optional sequenceTransferable transfer);
void failure(DOMString message);
Where do I define success and failure?
}
This is basically the data that needs to be sent from the application that
wants to initiate an intent, too:
dictionary IntentSettings {
DOMString action,
DOMString type,
What piece of information is this?
any data, // structured-cloned
sequenceTransferable transfer,
};
So how do we start an intent? Well, for intent handlers that are just
registered to handle URLs being loaded using certain schemes or that have
certain MIME types, you just use a link:
a href=web+customscheme:foo.../a
a href=file.customtype.../a
But more interestingly, to start one programmatically you would use a
startIntent() method:
partial interface Window {
void startIntent(IntentSettings intent,
Again, I hope you consider not making this a method of the global object.
(proposal below)
optional AnyCallback success,
optional DOMStringCallback failure);
I'm guessing this where the previously questioned success and failure are
defined?
What is a DOMStringCallback
}
callback AnyCallback = void (any data);
callback DOMStringCallback = void (DOMString message);
The callbacks given in the method, if provided, are invoked asynchronously
in reaction to the handler calling success() or failure() on the Intent
object. We would just allow one success or failure message per Intent,
for sanity's sake.
All of my notes above summarized would look like this...
Intent is a property
