Re: [whatwg] Why do we have input type='month' and input type='week'?
On Wed, Jan 30, 2013 at 9:55 PM, Mounir Lamouri mou...@lamouri.fr wrote:
Regarding 'month', I mostly don't understand the use case. I can't find
any situation where I am asked to input a { month, year } information.
Credit cards.
This type would solve the use cases of people trying to find a week to
meet.
I think it was for tax forms, though I have not encountered one myself.
--
http://annevankesteren.nl/
Re: [whatwg] Why do we have input type='month' and input type='week'?
On Wed, 30 Jan 2013 20:55:29 -, Mounir Lamouri mou...@lamouri.fr
wrote:
Regarding 'month', I mostly don't understand the use case. I can't find
any situation where I am asked to input a { month, year } information.
Given that the element is pretty trivial to implement by authors (this
is basically two select or a select and a input type='number'),
Others have commented on use-cases for collecting month, eg credit card
expiries.
The use-case for an input type I imagine is that a browser can have a
select-like UI (Jan, Feb, March, April ...) which, in a French language
browser becomes Janvier, Fevrier, Mars, Avril .. (or even Vendémiaire
to Fructidor for FRC fans).
b
Re: [whatwg] Why do we have input type='month' and input type='week'?
2013-01-31 14:20, Bruce Lawson wrote: Others have commented on use-cases for collecting month, eg credit card expiries. I have seen forms that prompt for year in month to specify start of employment (apparently when the exact date is not interesting) or a month to use when searching for cheapest flights to somewhere, apparently assuming that the customer is flexible with dates. Or you could have a month selection in a calendar application, or budget application. There are several use cases. It might be argued that they are considerably less common than selecting a day, The main problem is different, and shared with other date and time fields: do authors really want each visitor to see whatever widget his browser is showing? In the ideal world, maybe. There is great potential in principle, since the widget could be selected, by the user or someone helping him, so that it meets the user’s personal needs and preferences. It could also be argued that in the long, it greatly improves usability if different sites and applications use methods based on such widgets, so that the user can routinely use them, instead of wondering why this widget does not work the way he would expect from past experience with similar widgets. But is this going to happen? Why would authors/designers/managers favor some “standard widgets”? The use-case for an input type I imagine is that a browser can have a select-like UI (Jan, Feb, March, April ...) which, in a French language browser becomes Janvier, Fevrier, Mars, Avril .. (or even Vendémiaire to Fructidor for FRC fans). Right. And this probably becomes a nuisance if you need to select December 1952, because the widgets have typically been designed so that you need to click on something to get one year forward or backward. The other problem is that in non-supporting browsers, or in browsers that implement input type=month in a very simple manner (textbox, user input is taken as such, just checked for correctness), the user needs to type e.g. 1952-12, which is fast and simple – as soon as you know what is expected from you. Yucca
Re: [whatwg] proposal: Add support for masking to canvas
On 30/01/13 6:28 PM, Ian Hickson wrote:
That's weird. heycam, can you elaborate on this? The addHitRegion() case
in particular never makes sense to be called without a dictionary
containing at least one member. Do we have to allow it?
This is to encourage (require, really) API design that allows the
dictionary object to be not specified at all. Remember that all
dictionary members can be not specified anyway.
Do you want addHitRegion() to throw just like addHitRegion({}) would
throw? That will happen if you already have wording to say that
addHitRegion({}) will throw.
[whatwg] IRC and WWW integration proposal
Hi, I would like to submit a proposal of integration of websites and webpages with IRC. == Summary == To have some universal, standard protocol to indicate that a webpage or website has an IRC channel or network associated with it. == Purpose == For anyone to write scripts which would check whether a website has an irc channel or network for it. Usecase 1: I search for python and see a link to their website in search results, and the search engine looks up both title and IRC info - so I see webpage title, and a link to its irc network or channel. Usecase 2: Browsers implement some interface to display IRC channel link or window when user visits a page. Advantages: - The websites will benefit from this and will not have to manually embed qwebirc or Mibbit instances into their webpages anymore[1], leaving the IRC client preference to the user (choose from locally installed clients, or a client provided by the website). - User would not have to skim a page of text to locate and click an irc:// link manually, as such links would be a part of browser interface (an IRC icon like RSS feed icon?). == Short desc == The IRC info should be inside of a page HEAD tag. It should include a link to an IRC network or an IRC channel with a note of whether it's for the entire website, or specific for this webpage. There could be two group of entries too, one for the website, and another one for this page. Related specs: -- IRC protocol [2] -- irc:// URL specs [3] -- meta, head, link tags specs (you really know where they are) == Basic syntax == There could be different ways to indicate this information in the HEAD tag; we should pick one of them and standartise it. Option #1 link rel=officialirc scope=site href=irc://server.tld/#channel (scope = site or scope = page) (multiple tags allowed) Option #2 meta name=irc scope=site content=irc://server.tld/#channel / (multiple tags allowed) Option #3 irc network=networkname server ssl=yes port=6697 hostname=foo/ server ssl=no port=6667 hostname=bar channel=baz1/ channel=baz2 /irc I'm more inclined to pick any one of the first two options (probably 1?). == Browser behaviour == When user clicks a part of browser interface referring to IRC, he's presented with - a list of network(s) and/or channel(s) the page advertises, and - a list of IRC clients to use. For this purpose, the metadata should include IRC webchat URL if the website wants to have one (self-hosted, or a service like Mibbit) in addition to the IRC clients user has installed on his machine. [1] http://wiki.mibbit.com/index.php/Widget [2] http://tools.ietf.org/html/rfc1459 [3] http://www.w3.org/Addressing/draft-mirashi-url-irc-01.txt Welcome any feedback and help shaping a standard if need be. Gryllida.
Re: [whatwg] IRC and WWW integration proposal
Gryllida gryll...@gmail.com schrieb am Fri, 1 Feb 2013 14:26:00 +1030: == Summary == To have some universal, standard protocol to indicate that a webpage or website has an IRC channel or network associated with it. Associated in what form? Which verb describles the relationship between the web page and the IRC channel? Also, I would call the link relation „chat“ or something, there are other protocols than IRC, e.g. XMPP. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] IRC and WWW integration proposal
On Fri, 1 Feb 2013 05:24:58 +0100 Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Gryllida gryll...@gmail.com schrieb am Fri, 1 Feb 2013 14:26:00 +1030: == Summary == To have some universal, standard protocol to indicate that a webpage or website has an IRC channel or network associated with it. Associated in what form? Which verb describles the relationship between the web page and the IRC channel? Also, I would call the link relation „chat“ or something, there are other protocols than IRC, e.g. XMPP. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net Probably associated as in 'have', that a page/site 'has' its channel somewhere. Acknowledge XMPP support in that, might need a 'protocol' attribute or just an xmpp:// URL? --Gryllida.
Re: [whatwg] IRC and WWW integration proposal
Gryllida gryll...@gmail.com schrieb am Fri, 1 Feb 2013 15:01:26 +1030: On Fri, 1 Feb 2013 05:24:58 +0100 Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Gryllida gryll...@gmail.com schrieb am Fri, 1 Feb 2013 14:26:00 +1030: == Summary == To have some universal, standard protocol to indicate that a webpage or website has an IRC channel or network associated with it. Associated in what form? Which verb describles the relationship between the web page and the IRC channel? Also, I would call the link relation „chat“ or something, there are other protocols than IRC, e.g. XMPP. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net Probably associated as in 'have', that a page/site 'has' its channel somewhere. Acknowledge XMPP support in that, might need a 'protocol' attribute or just an xmpp:// URL? “to have” as you use it .ust denotes a relationship exists (as in “I have a sister.”), but not which one. My fault, the question should have been “What noun describes the IRC channel in relation to the web page?”. For a feed, for example, this can be answered with „this is an alternate representation of the content“. A protocol attribute for link elements would be totally hilarious. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] IRC and WWW integration proposal
On Fri, 1 Feb 2013 05:55:11 +0100
Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote:
Gryllida gryll...@gmail.com schrieb am Fri, 1 Feb 2013 15:01:26 +1030:
On Fri, 1 Feb 2013 05:24:58 +0100
Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote:
Gryllida gryll...@gmail.com schrieb am Fri, 1 Feb 2013 14:26:00
+1030:
== Summary ==
To have some universal, standard protocol to indicate that a
webpage or website has an IRC channel or network associated with
it.
Associated in what form? Which verb describles the relationship
between the web page and the IRC channel? Also, I would call the
link relation „chat“ or something, there are other protocols than
IRC, e.g. XMPP. --
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net
Probably associated as in 'have', that a page/site 'has' its channel
somewhere. Acknowledge XMPP support in that, might need a 'protocol'
attribute or just an xmpp:// URL?
“to have” as you use it .ust denotes a relationship exists (as in “I
have a sister.”), but not which one. My fault, the question should have
been “What noun describes the IRC channel in relation to the web
page?”. For a feed, for example, this can be answered with „this is an
alternate representation of the content“.
A protocol attribute for link elements would be totally hilarious.
--
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net
It is rather common to have a channel for a website, not just one page.
There are some exceptions of sites which have subsites with a channel for each.
A {IRC, XMPP} channel is an official chat medium aiming to serve as an
official {support, development, contact} means.
For example,
https://developer.mozilla.org/en/Themes irc://irc.mozilla.org/themedev -
discussion of theme development for Mozilla platform
http://www.ubuntu.com/* irc://irc.ubuntu.com/ - official support channel for
the distro
the w3c network for individual sections of website - channels for development
collaboration and meetings
c
I think a protocol attribute might be redundant as it is a part of the URL.
It may be worth noting that every part of the note I originally sent is
possible to look up and you can try finding proper way to phrase things (I have
no experience in writing documentation of this sort).
--Gryllida.
Re: [whatwg] IRC and WWW integration proposal
A protocol attribute for link elements would be totally hilarious. Not if the device is a tablet, or a phone running a browser that supports it. Need support from a page/article or even a project? Hit a button, and if the protocol is implemented, you're in the IRC channel able to garnish that support instantly. Whether it's IRC. or XMPP the option being there wouldn't be harmful or detrimental in any way. http://www.snoonet.org/missions - Our goal is to bring live chat to subreddits that enable it, why should people have to 'Search' for a live chat on a page? Why should others that seek what my project is doing have to rely on an extension when a protocol is easy implementable (whether or not it's used is on the webdev) On Thu, Jan 31, 2013 at 10:55 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Gryllida gryll...@gmail.com schrieb am Fri, 1 Feb 2013 15:01:26 +1030: On Fri, 1 Feb 2013 05:24:58 +0100 Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Gryllida gryll...@gmail.com schrieb am Fri, 1 Feb 2013 14:26:00 +1030: == Summary == To have some universal, standard protocol to indicate that a webpage or website has an IRC channel or network associated with it. Associated in what form? Which verb describles the relationship between the web page and the IRC channel? Also, I would call the link relation „chat“ or something, there are other protocols than IRC, e.g. XMPP. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net Probably associated as in 'have', that a page/site 'has' its channel somewhere. Acknowledge XMPP support in that, might need a 'protocol' attribute or just an xmpp:// URL? “to have” as you use it .ust denotes a relationship exists (as in “I have a sister.”), but not which one. My fault, the question should have been “What noun describes the IRC channel in relation to the web page?”. For a feed, for example, this can be answered with „this is an alternate representation of the content“. A protocol attribute for link elements would be totally hilarious. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net -- Shane Allen (sh...@snoonet.org) - *Network Director*
