Re: Implementor feedback on new elements in HTML5

On Mon, 31 Aug 2009, Maciej Stachowiak wrote:
> 
> - Elements requiring changes to <legend> parsing: <figure>, <details>
>   These elements seem quite useful, but they will be unusable on the public
> Web until all browsers are updated to change how they parse <legend> and the
> new versions are widely adopted. Pretty much all current browsers do something
> idiosyncratic when parsing a <legend> element outside of a <fieldset>, which
> makes it impossible to make <figure> or <details> degrade gracefully via
> script or style. We are hesitant to implement elements that authors would feel
> they are unable to use, or to lead authors astray, so we are hesitant to
> implement the new elements until either the <legend> parsing issue is widely
> fixed or HTML5 uses some element other than <legend> for the caption on these
> elements. We will consider fixing our parsing of <legend> outside <fieldset>
> soon, so that we're not the blocker. But it seems like it would be easier to
> change the elements that carry the label/caption.

These elements aren't especially critical, so if people would feel like it 
was less of an issue to just not include them in this version, but to 
still fix the parsing of <legend>, and then to introduce them a few yeards 
down the road, once the parsing is fixed, then I'm fine with doing that -- 
it would have the exact same effect on authors, though, so it seems like 
a bit of a dance for no benefit.


> - <mark>
>   The basic idea for this element seems good, but the suggested UI for
> exposing it does not seem to entirely match the use cases, and may not be
> practical to deploy. Having tick marks in the scrollbar for every <mark>, and
> UI to cycle between them, seems too heavyweight for some of the suggested
> uses. We are interested in implementing the basics of <mark> soon, but
> probably not the requirements.

I've removed the bit about the scrollbar.


> - <time>
>   It seems useful for use cases like Microformats to have a clean, unambiguous
> way to represent a specific time. It seems odd that there are ways to get Date
> objects to represent the date, time and time zone separately, but no way to
> get a Date representing the combination of date/time/timezone. Wouldn't the
> latter be a common use case, and doesn't the JavaScript Date object give
> sufficient APIs to unpack a Date into its components as needed?

Ok, changed it to a single API.


> - 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. The
> only odd requirement is the use of inline text content in the elements to
> represent the state of the control. Specifying inline textContent may be a
> clever way to pass the initial state, but it seems very clunk as an interface
> for dynamically updating the state of the progress bar. Using the max and
> value IDL attributes of <progress> seems like it would be much easier for
> authors, and it seems like a problem that these only reflect the markup
> attributes and not the full state of the control (if the state is currently
> defined by text content). Likewise for the 6 attributes on <meter>. Assembling
> up to 6 numbers into a textContent string, which then does not cause the
> convenient DOM attributes to update, seems very clinky.

<meter> doesn't support 6 numbers in the textContent, only two, like 
<progress>.


> - 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?

This was studied in some depth a few years ago, yes.


> Two further points came up in the discussion here:
>     (a) Is it problematic to implement these without a lot of specialized UI,
> for cases such as "email" or "tel"?

Not as far as I can tell, no. I guess we'll see.


> - <menu>
>   The list form of a menu seems straightforward enough, it is good to have a
> list type specifically for popup menus. The toolbar form does not seem fully
> baked. First, it seems weird to think of a toolbar as a kind of menu. Second,
> the rendering is too inflexible and underspecified for the real Web content
> authoring use cases for toolbars. And finally, an important point of toolbars
> in many applications is that they can embed custom controls in a flexible
> layout that also includes some standard buttons, but <menu type="toolbar">
> does not seem flexible enough to handle this. The context menu form does seem
> genuinely useful. But it also seems like a lot of complexity for the somewhat
> marginal case of overriding the context menu. It seems like about a dozen
> different elements are allowed, all with different processing requirements.
> This seems like overkill for the use case of a context menu. It doesn't even
> make much semantic sense for a context menu to contain a button. Overall, it
> doesn't seem like the cases of menu list, toolbar and context menu really
> share enough behavior or appropriate content model to make them use the same
> element.
> 
> Overall, there was a lot of sentiment that Web developers need better built-in
> support for toolbars, context menus, and list-based hover menus. However, we
> were not comfortable with the complexity or the limitations of the design.
> 
> We're looking into whether we can propose some improvements in the near
> future.

The space is very constrained, given the desire for backwards 
compatibility, graceful degradation, and future compatibility with 
features like command="" (where one element can be disabled to affect 
all instances of that command, whether on toolbars, menus, or whatnot).

I'm certainly open to ideas for making <menu>'s toolbars more flexible. I 
disagree that there is much difference between a toolbark and a menu, 
though, and I'm not convinced that custom controls are a critical use 
case for the first version of the feature.

I'd rather not change this much at this stage. This feature has been 
pretty stable in the spec for several years now, after going through 
several phases of review along with a dramatic simplification of the model 
a few years ago.


> - <command>
>   It's unclear if this element is worth having without the use cases for
> toolbars or menus, and it also has 0 implementations so far and seems like it
> might not be fully baked.

It's pretty important going forward for doing things like having a single 
element that defines a command and then that element being referenced in 
many parts of the UI, so that an app doesn't have to go through and change 
the disabled state of each one (e.g.).


On Tue, 1 Sep 2009, Tab Atkins Jr. wrote:
> 
> We had a big discussion about these yesterday on #whatwg while 
> explaining the semantics of these elements to someone new. Surprisingly, 
> we all seemed to agree on a few salient points:
> 
> 1. <footer> is simply horribly named.  I like the semantics 
> (essentially, article metainfo), and would in practice often mark up 
> what <footer> represents with a classed div.  I think it's probably 
> common enough to fall on the "new element" side of the cut-off. However, 
> the name is just a no-go.  It will *constantly* be confusing from both 
> ends - tons of people will see "footer" and think "stuff I put at the 
> end of the section" (a perfect parallel to <header>) and violate the 
> content model with "fat footers" and such, while from the other side 
> people will put their article metainfo at the top of the article (just 
> below the heading is common) and feel reluctant to use <footer> since 
> it's at the top.
> 
> My suggestion is to move the current semantics of <footer> into an 
> element without a confusingly structural name - I suggest <info> or 
> <articleinfo>.  Though something with "meta" in the name feels right, 
> most peopleThen make <footer> into a genuinely structural element 
> identical to <header>, with the only difference between them being where 
> in the section they generally appear.  Yes, this feels wasteful to have 
> two identical elements differing only by their placement, but if we're 
> trying to capture common classnames here, the data is clear - .header 
> and .footer are *extremely* common.

"footer" is the most common semantic class name, so I think we should keep 
the name.

However, I have changed the content model of <footer>, to reduce at least 
one of the problems you describe.


> 2. <aside> is similarly badly named.  The name itself and the
> description of it as "sidebar" content apparently leads almost
> everyone astray into thinking it's for the ubiquitous website sidebar.

It is.


> An informal survey showed that at least 3 people in that chat (me
> included) immediately tried to misuse <aside> in *precisely* this way
> when we first heard of it, and when I discussed the issue with another
> friend mid-chat his response was roughly "what's confusing about them?
> footer is for site footer and aside is for side panels".

That is a correct interpretation.


> [meter and progress]
> 
> Possible idea: if some of the attributes were missing, thus requiring 
> the algorithm for extracting numbers from a string to be run, could the 
> textContent then be dynamically updated whenever the IDL attributes are 
> changed?  The basic idea is that if you're setting up a correspondence 
> between the attributes and the textContent, they should achieve a 
> complete coupling.

I considered doing that, but there's no point -- the textContent is only 
useful for legacy UAs, which don't do this.


On Tue, 1 Sep 2009, Tab Atkins Jr. wrote:
> 
> That's not sufficient; it only addresses the problem from *one* side - 
> authors using <footer> where they shouldn't.  It doesn't solve the 
> problem at the other side, where you have data that would very obviously 
> be marked up with <footer> if it was at the end of the article, but 
> instead it's being put at the beginning below the heading.  I would 
> personally be very reluctant to use <footer> near the top of an element.

Don't be. There's even an example in the spec for this.

Having said that, I don't think it's a big deal if people use some other 
element than <footer> for information in the header. They can use 
<header>, that's fine too.


> You either need a new element, or you need to declare that the current 
> <footer> semantics aren't actually valuable enough to capture.  What you 
> can't do is merely widen <footer>'s semantics, because that leaves it 
> still very asymmetrical with regards to <header>.

Actually the new content model is the same as <header>'s.


> This too doesn't feel right.  If <aside> is being used for a sidebar, 
> I'm not sure I feel right about using it for a pullquote that stretches 
> across my whole content column (differentiated from the surrounding 
> content by a border and a different font to make it clear it's not meant 
> to be read sequentially with the preceding and following text). It's no 
> longer on the side.

HTML isn't about the presentation. You're focusing too much on the 
styles here. You can take any random element and style it any which way 
you like; the idea is just to give you something to hook onto that can 
have a good accessibility in media that don't know about your styles.



> If the intent of the structural elements was to capture common class 
> names to make it easier and more obvious to author documents, then 
> <aside> is a failure if applied to both sidebars and 
> pullquotes/tangents/subtext/etc. (for the same reason that <footer> is a 
> failure if used for both "stuff that goes at the bottom of the section" 
> and "info about this article").  I don't believe that authors use the 
> same classes for both of these.  I'll end up still classing my <aside> 
> so I can tell apart the two cases, since they may both be direct 
> children of the article.

That seems reasonable. If you use many types of sidebars, and you can't 
distinguish them based on where they are in the markup, then use classes. 
That's what classes are for.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 4 September 2009 08:41:06 UTC