Re: Last Call feedback on Date/Time controls

On 29/06/2011, at 5:15 AM, Adrian Bateman wrote:

> On Tuesday, June 28, 2011 8:21 PM, Jonas Sicking wrote:
>> On Tue, Jun 28, 2011 at 6:01 PM, Adrian Bateman <adrianba@microsoft.com>
>> wrote:
>>> 1. Control styling
>> As has already been mentioned, this is up to CSS. I suspect what needs
>> to happen here is for UAs to experiment with adding various pseudo
>> elements which can then be styled or hidden by the page. Which
>> elements make sense is hard to tell until we actually have UI to
>> style, which is why I think UAs experimenting is the way to go.
> 
> It sounds like we may have consensus on this being a CSS issue and my
> request was that, if so, we make a formal request that the CSS WG consider
> making this part of their scope when they recharter.
> 
> Experimentation is fine - I'm concerned about multiple incompatible shipping
> experiments, though. I hope we can come together to share our learning before
> we get too far into making web developers cope with different approaches.

Any stylistic customizations need an external declaration in keeping with the separation of roles, however this will be a complex introduction to css and is probably only able to be specified once the html implementations have settled.

However, there would seem to be a contention over the specification of this in css. As html is void of stylistic specification and in this case is deferred to UA as a product-level definition, how can it be included in a specification which only works over declared elements and attributes?

The problem with date\time picker controls is that they are rich interface elements treated by UAs with a system-level integration style, like filesystem integration. This doesn't make sense however, as date/time is not a system resource and can not be defined on this level.

For this to be included in css there would seem to either require the macro-decleration of rich elements or the composition of micro elements, of which only a macro declaration would seem to even be theoretically possible, ie:

input [type="date"] {
	date-style: long | medium | short;
}

or maybe:

input [type="date"] {
	picker: wheel | calendar;
}

...but this leaves a lot which can't be styled.

>>> 2. Date formatting
>>> a. Date formatting is another challenging issue 
>> I'm not quite understanding how this is different from 1. Is this for
>> when the full datepicker is not displayed and instead a text-field
>> sized control is displayed which shows the controls current value?
> 
> #1 is really about look and feel and #2 is about how the content is expressed.
> Are they closely related? Yes, probably. Would we solve them in the same way?
> I don't know so based on the feedback we heard we called them out separately.

The problem is encountered through there being 2 types of possible interaction from a single input field, either direct text entry and  parsing, or by date-picker. The picker would seem to be of lesser importance though as the real purpose of the new input types is for the ability to declare an intelligent element which has knowledge of the rules of what is and is not allowed and the ability to apply and retrieve valid values programatically or through form control.

What should be remembered though, is that traditionally the server controls output\formatting of date\time into string representation based on the locale of the request parameters. This may change for some use cases in future if raw values are sent, however even if a sound declarative approach is found for html there will always be cases of pre-formatted date\time being sent, which is after localization has already been applied.

The real problem with this, and getting onto more of this in a second, is that there starts to become an implementation-synchronization problem between client and server. The localizations, or more importantly, the algorithms for localization selection and precedence will require a degree of consistency across the client\server channel. When this scenario is encountered, the historical approach has been to defer default authority to the author, with the client providing the optional overrides for end-user desires. However, pre-formatted values escape this ability for client-level control as the DD/MM/YY vs MM/DD/YY inference debacle shows.

As an additional possibility to address formatting, might the pattern attribute provide additional scope for specification of custom formatting and (possibly) parsing? This would introduce an additional order of precedence over some aspects of the application of locale.


>>> b. Localisation 
>> Again, I'm not quite understanding how this is different from 3.
>> Unless it's for the display-only-current-value state described above.
> 
> Again, this one is similar; however it's not just about the language. For example,
> Some cultures use different calendars and there may be a desire to select which
> calendar is appropriate for a specific site.


The ability to declare the localization of elements with cascading impact is already present globally in html, and to my knowledge, there is nothing in the specification which says that UAs should be ignoring that. This would seem to require a no-change in specification but encouragement on implementation in order to have full universal declarative localization support.

There is probably an argument here in the shape of "the user should see what they can read", however this is an implied decision based on a relatively arbitrary setting of locale on a product or system level. The real mode of operation of the UA should be that the user has chosen to navigate to a localized resource and, unless specific translation has been requested (an override-preference, service, etc), that the user should see the resource that they have requested, as the author has declared they want that representation to be seen.

There is the complexity, however, of how to correctly determine the locale which should take precedence in what can amount to a locale-soup: elements, meta-tags, html, xml-lang, accept-language, content-language, product locale, system locale, etc, etc

It is this algorithm which is of importance, not whether the resulting locale should be respected or not.

> 
>>> 3. String localisation
>> Yes, this does indeed seem like a problem. I don't agree with Tab that
>> you generally want to simply use the locale of the browser. It always
>> looks pretty terrible to me when I'm browsing on a swedish website
>> that suddenly has a few random elements with english in them, or the
>> other way around. So I think that more often than not websites will
>> want to use the locale of the website.
> 
> Yes, that's one scenario we ran into.
> 
> We wanted to share the feedback we've heard from developers including some at
> Microsoft working on products such as Hotmail and Office Web Applications. We
> think that addressing these gaps in an interoperable way will be needed to
> achieve broad adoption of these HTML5 features.
> 

As stated, this already should be possible and only requires support on implementation. The following has many use-cases and should be completely possible for an author to declare:

<form lang="en">
	<input type="date"/>
	<input type="date" lang="en_AU"/>
	<input type="date" lang="en_UK"/>
	<input type="date" lang="en_US"/>
	<input type="date" lang="fr"/>
</form>

That these produce the same date\time is not of importance, it is the ability for an author to declare their intentions which is of importance, otherwise html is a lossy language incapable of self-description.

Thanks,
Cameron Jones

Received on Wednesday, 29 June 2011 14:45:14 UTC