Re: Implementor feedback on new elements in HTML5

On 1 Sep 2009, at 06:29, Maciej Stachowiak wrote:

>
> (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.

I believe the IRC logs of #whatwg and #htmlwg at http://krijnhoetmer.nl/irc-logs/ 
  are marked up with <li>'s. Using <dl> inside <dialog> rather than  
<ul> or <ol> makes it harder to mark up joins, quits and nick changes.  
(It also requires more styling to match the common format of chat on  
IRC, but maybe we're talking about chat logs from Adium and the like?)

>
>>
>>> - 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?
>
> Regards,
> Maciej
>
>
>

--
Stephen Stewart

Received on Tuesday, 1 September 2009 11:12:53 UTC