Re: Implementor feedback on new elements in HTML5

(Additional comments are personal feedback only.)

On Aug 31, 2009, at 10:14 PM, Jonas Sicking wrote:

> Great feedback Maciej,
> At mozilla we have yet to do a detailed review of the new elements, so
> I can't give as detailed feedback at the time. However it feels like I
> personally generally agree. Some comments and cases I didn't agree
> with below:
>> - <dialog> element
>>   This essentially gives the same behavior as <dl> but with  
>> appropriate
>> semantics for logs of conversations. It seems useful and easy to  
>> implement.
> Useful for what? I don't yet understand what anyone needs this  
> element for.

One example would be markup for a chat log. I'm personally not sure it  
adds a lot of value for this case, but I'm not sure if there is an  
existing good way to mark up logs of conversations, and it seems like  
a fairly common use case. I don't feel strongly about this, but it  
doesn't seem like implementing it would be a problem.

>> - New interactive controls: <meter>, <progress>
>>   These elements seem useful and a good idea. These controls are  
>> useful in
>> native UI and often get hand-rolled by JavaScript libraries. We  
>> would like
>> to expose a default native look, but with full author stylability  
>> for these.
> I think it's a very good point that these two elements need to be
> author stylable in order to become useful for authors. I suspect
> people in many cases won't use them until they can be styled. Would be
> great to see a proposal from apple on CSS properties for styling
> these.
> I am however yet unconvinced that <meter> will really be used enough
> to warrant inclusion in the spec and implementation in UAs. It has
> been pointed out to me that some platform toolkits does indeed include
> a similar feature, but I can't really think of many websites or
> applications where I've seen them used.
> Also, as someone not from Liberia, Burma or the United States, I find
> the name very confusing. I usually associate the term 'meter' with the
> unit of length. In fact, the first time I saw the element I thought it
> was more related to <time> than to <progress>, i.e. some way to mark
> up distances.

I think <progress> is much more generally useful. Apple's Mail uses  
the Cocoa/AppKit equivalent of the <meter> element in the search  
interface. This may give me a misleading impression of how generally  
useful it is to applications.

>> - new <input> element types
>>   These seem generally useful, and we already have some implemented  
>> to
>> various extents (search, range, email, url tel). The only concern  
>> is the
>> sheer number of date and time controls. 6 of the 13 new input types  
>> are for
>> dates or times. Are there real use cases for all 6? Do all 6  
>> exhaustively
>> cover the types of time and date input you may want to do in forms?
> We had a recent discussion about this one at mozilla. There was a lot
> of concern that even if we added date-pickers to the platform they
> wouldn't get used since authors wanted a consistent look with the rest
> of the page. So this might be similar to <progress> in that regard.
> I still think that some type of date/time-picker is important for
> accessibility, mobile devices, etc. However I think the styling
> problem is important. Unfortunately, unlike <progress>, I think
> there's a risk the problem can't be solved with CSS alone.

I agree that styleability is important in this case. Particularly so  
because many sites have been forced to build their own date pickers,  
and would want to continue to reflect the site branding. I wonder if  
Opera has experience to share here (I believe they have implemented  
all the date inputs). Is there author interest? Is the implementation  
stylable, or is the implementation conducive to adding styling?


Received on Tuesday, 1 September 2009 05:30:26 UTC