[html5] Lists, form controls, and section headings

[Ian Hickson]

(I'm replying to e-mail sent to the WHATWG lists in the past year in 
sort-of-related piles. Sorry if this seems a bit incoherent.)

On Mon, 31 Mar 2014, Brian Tremblay wrote:
>
> It would be nice to link <ol> elements such that the numbering would be 
> connected. Then you could place list items in different sections, or put 
> non-list things in between them, and have the browser determine the 
> correct number for each item.

I've filed a bug for this:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=27185

...but really it depends on browser vendor interest. <ol> hasn't exactly 
been a high priority for browser vendors.


On Thu, 6 Mar 2014, Not Telling wrote (about the selection API on input 
controls):
>
> The select API should be available as a character array or set of 
> indexes selected, and the programmer should be able to interpret what 
> that means.

Suppose the input type=email control is a widget that accepts hand-drawn 
diagrams of the user's contacts' faces. Not a very practical widget, but 
certainly within what is allowed by the spec, and a useful extreme 
example. The user selects a rectangle of the picture. What should the 
selection API return?


> web apps where you want to override/change the right-click context menu, 
> but still have the option to "copy" within it. How would you know what 
> to copy?

Just let the browser expose copy/paste.


> A web-based email client, selecting a username from a list of users you 
> are sending to in the "to" field gives you more details about that 
> person.

There's no way to do that with type=email currently. Unfortunately, since 
<input type=email multiple> has not been implemented especially well by 
browser vendors so far, I would imagine most sites that are interested in 
doing things to that level of detail would just implement their own 
type=email widget from scratch.


> Highlighting an area of the input that fails validation on form 
> submission.

Why wouldn't you just let the browser do this?


> web-based find next using regex searching I agree that you could run 
> into troubles where you don't know whether or not the user is selecting 
> an image within a paragraph could cause issues, but for the input 
> element of type text or textarea, the select API should definately be 
> available.

Consider the crazy widget above. The value of the control is 
"ian at hixie.ch,help at whatwg.org", and you use the select API to select the 
range "ch,help". What should get rendered?

Browsers have built-in search mechanisms, why not rely on that?


On Thu, 15 May 2014, Micky Hulse wrote:
> On Thu, May 15, 2014 at 2:16 PM, Andrew J Roazen <Andrew.Roazen at nau.edu> wrote:
> >
> > Let's compromise. <section data-headerstart="3"> could inform a 
> > syndicator that outside the flow of the containing document, <h3> is 
> > functionally the top-level header, <h4> is <h2>, etc. This puts 
> > metadata where it belongs, and leaves authoring the rest of the 
> > document without problems.
> 
> Interesting idea. I think I get it.
> 
> If I understand correctly, it kinda (maybe just a little bit) reminds me 
> of how I handle the styling of headings using CSS class names (in an 
> HTML5 <section>/<h1>,<h2>, etc. context):
> 
> <h1 class="h6">This is an H1 that's styled like an H6</h1>
> 
> The style for that would read (for example):
> 
> h6, .h6 { font-size: 115%; line-height: 1.2; }
> 
> Details here:
> 
> "Why use .h1 instead of actual h1?" 
> <http://stackoverflow.com/a/19166926/922323>
> 
> Though, I may have to update that answer to note some of the points 
> we've discussed here.

Per the HTML spec, you can already start at whatever level you want. The 
heading levels within a <section> are relative.

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