- From: Masataka Yakura <myakura.web@gmail.com>
- Date: Tue, 24 Sep 2013 18:27:36 +0900
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: "Jukka K. Korpela" <jukka.k.korpela@kolumbus.fi>, public-html <public-html@w3.org>
- Message-ID: <CANJXhd17q_2r7w_KtNA7x3Ym6AsKpjp-jBe2oR_5YQdYEGtCeQ@mail.gmail.com>
Hi Silvia, On Mon, Sep 23, 2013 at 2:00 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>wrote: > On Mon, Sep 23, 2013 at 2:33 PM, Jukka K. Korpela > <jukka.k.korpela@kolumbus.fi> wrote: > > 2013-09-23 4:52, Silvia Pfeiffer wrote: > >> > >> FYI: being "at risk" has nothing to do with the usefulness of the > >> feature - the spec's concern is whether there is cross-UA support of > >> the feature. > > > > > > Which in turn depends on how useful the feature is seen by implementors, > > doesn't it? > > And on the amount of work needed for implementation, of course. > > > > > > > >> Such a feature can be a useful feature (I personally have > >> used such input types in my recent apps), but its standardisation may > >> need to be delayed to the next version of HTML if UAs don't have > >> uniform support of the feature. That's all. > > > > > > According to > > https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input > > the support status for type=date is the same as for type=datetime. So > there > > must be > > something else than the current implementation status that explains why > > type=date > > is not marked as being at risk and type=datetime is not. > > It's simply a matter of process. At the time that the spec went into > Last Call, implementations were behind, so the feature was put "at > risk". So that means at that time, there was (or were) impl for the 'date' type but not other date&time-related types, right? > Now it's supported, so if tests confirm uniform support, it's > not at risk any more. > > If the HTML5 spec goes back into Last Call, that list can be updated. > Understood. Thanks! -- Masataka Yakura <myakura.web@gmail.com>
Received on Tuesday, 24 September 2013 09:28:44 UTC