[whatwg] Elements feedback

On Sun, 15 Jul 2012, Aurelio De Rosa wrote:
> 
> I'm writing this email because I want to discuss about where to have the 
> author's data inside an <article>. According to specification, the 
> header
> 
># The header element represents a group of introductory or navigational 
># aids.
> 
> while the footer
> 
># A footer typically contains information about its section such as who 
># wrote it, links to related documents, copyright data, and the like.
> 
> So the specs assert that the author's data have to stay into the 
> <footer>.

The first statement you quote is normative (the word "represents" is a 
functional word in the HTML spec). The second statement you quote is not, 
it's just descriptive. The equivalent statement for <footer> is:

># The footer element represents a footer for its nearest ancestor 
># sectioning content or sectioning root element.

The "author's data" can fit equally well into a header ("introductory 
aids") or a footer.


> Althought the specs say:
> 
># Footers don’t necessarily have to appear at the end of a section, 
># though they usually do.
> 
> this would carry to a situation where a lot of blogs have to change the 
> intuitive and natural structure header-article-footer into a more 
> counterintuitive one and that is header-footer-article.

You could also do:

   <article>
    <header> ... </header>
    <footer> ... </footer>
    ...article...
    <footer> ... </footer>
   </article>


On Mon, 16 Jul 2012, Ian Yang wrote:
> 
> Thanks. That use looks fine, yet I'm a bit confused now. What's the 
> difference between *using definition list (<dl>)* and *using ordered 
> list ( <ol>) with <dfn> inside of it*? And how could we determine when 
> to use which?

They're more or less equivalent. Using <ol> highlights the importance of 
the order of the entries, using <dl> highlights the importance of the 
structure being pairs of names and values.

In data structure terms, <ul> and <ol> represent lists, whereas <dl> 
represents groups of tuples. But in practice a group of tuples can be 
represents as a structured list, a numbered list can be represented as a 
group of tuples where each tuple has a unique number, etc. Similarly, you 
can make <table>s that are functionally equivalent to <dl>s, and often an 
<ol> can be expressed as just a paragraph with comma-separated items.

There's often more than one way to do things in HTML.


> > It's something we could add, but it's not clear that there's a 
> > compelling need for it. What is the use case for knowing that a <dl>'s 
> > contents can be arbitrarily reordered?
> 
> Well, I'm not sure if "user agent can't randomly reorder its contents" 
> equals to "the order of its content is important". If it does, some use 
> cases of <dl> such as FAQ may became incorrect as the order of contents 
> of FAQ is usually unimportant.

The order of contents in <dl> isn't defined to be important, it's just 
that the order can't be arbitrarily changed by the user agent because it 
_might_ be important; unlike a <ul>, where (in theory, at least) the order 
could be arbitrarily changed.

(Google will sometimes take a page that is mainly a list and use that 
knowledge in generating the page's snippet in search results. It would be 
reasonable to say that Google could reorder items in a <ul> list, but not 
those in an <ol> or <dl> list, when doing this.)


On Mon, 16 Jul 2012, Ian Yang wrote:
> 
> But your opinion does remind me of the <small> element. That element is 
> a perfect example of introducing and using an element simply for its 
> rendering. Unlike <ul> and <ol>, it's not meaningfully named at all. 
> Honestly, I'm not a huge fan of recycling a deprecated element. If we 
> need an element for side comments, we could introduce <comment> or <c>. 
> If we need an element for document info, we could introduce <info>. That 
> would make HTML elements more meaningfully named.

The names are opaque -- most people who write HTML don't speak English as 
their first language, if at all, so we can't really rely on the element 
names to convey the semantics.

We couldn't use <comment>, some browsers default to hiding <comment> 
elements.

We could introduce <c> or <info>, but <small> has the advantage that it 
already renders in an appropriate way in legacy user agents.


On Thu, 19 Jul 2012, Ian Yang wrote:
> 
> Let's consider <form> we used often. When coding a form, none of us make it
> like the following one because that's obviously very ugly and, most
> importantly, it hurts our eyes!
> 
> <form method="post" action="/">
>     <label for="name">Name</label>
>     <input id="name" type="text">
>     <label for="email">Email</label>
>     <input id="email" type="email">
>     <label for="site">Website</label>
>     <input id="site" type="url">
>     <label for="phone">Phone</label>
>     <input id="phone" type="tel">
>     <input id="male" type="radio">
>     <label for="male">Male</label>
>     <input id="female" type="radio">
>     <label for="female">Female</label>
>     <label for="msg">Message</label>
>     <textarea id="msg"></textarea>
> </form>
> 
> Instead, we use <div> (some people use <p>) to group sub elements to 
> make them more organized, and we also get the side benefit of having 
> more elements for styling:
> 
> <form method="post" action="/">
>     <div>
>         <label for="name">Name</label>
>         <input id="name" type="text">
>     </div>
>     <div>
>         <label for="email">Email</label>
>         <input id="email" type="email">
>     </div>
>     <div>
>         <label for="site">Website</label>
>         <input id="site" type="url">
>     </div>
>     <div>
>         <label for="phone">Phone</label>
>         <input id="phone" type="tel">
>     </div>
>     <div>
>         <input id="male" type="radio">
>         <label for="male">Male</label>
>     </div>
>     <div>
>         <input id="female" type="radio">
>         <label for="female">Female</label>
>     </div>
>     <div>
>         <label for="msg">Message</label>
>         <textarea id="msg"></textarea>
>     </div>
> </form>

Personally I'd recommend using structures like:

   <p><label>Phone <input name=phone type=tel></label></p>

...for each line, but the effect, and semantics, are the same.


> Like above examples, the following <dl> is not well organized, and it's
> also a pain to read it:
> 
> <dl>
>     <dt>Lorem Ipsum</dt>
>     <dd>Sit amet, consectetur adipiscing elit.</dd>
>     <dt>Aliquam Viverra</dt>
>     <dd>Fringilla nulla nunc enim nibh, commodo sed cursus in.</dd>
>     <dt>Pretium Et Nibh</dt>
>     <dd>Quisque porttitor mauris ut velit tincidunt ut hendrerit erat
> mollis.</dd>
>     <dd>A dui condimentum suscipit. Quisque tortor nulla.</dd>
>     <dt>Tempus Et Augue</dt>
>     <dd>Vivamus ipsum massa, tristique tempus lobortis a.</dd>
>     <dt>Vivamus Semper Convallis</dt>
>     <dt>Cras Eget Eros</dt>
>     <dd>Pellentesque. Vestibulum volutpat mollis placerat.</dd>
>     <dd>Maecenas eu tempus ut, imperdiet eu tortor.</dd>
>     <dt>Pellentesque</dt>
>     <dd>Lobortis consequat ipsum id pulvinar.</dd>
>     <dt>Nibh Purus</dt>
>     <dd>Adipiscing sit amet ultrices quis, consequat eu dolor.</dd>
> </dl>

Just put a blank line before each <dt>:

   <dl>
     <dt>Lorem Ipsum</dt>
     <dd>Sit amet, consectetur adipiscing elit.</dd>

     <dt>Aliquam Viverra</dt>
     <dd>Fringilla nulla nunc enim nibh, commodo sed cursus in.</dd>

     <dt>Pretium Et Nibh</dt>
     <dd>Quisque porttitor mauris ut velit tincidunt ut hendrerit erat mollis.</dd>
     <dd>A dui condimentum suscipit. Quisque tortor nulla.</dd>
     ...


> If developers could, *optionally*, use <li> to wrap each group, the code 
> would be more organized:
> 
> <dl>
>     <li>
>         <dt>Lorem Ipsum</dt>
>         <dd>Sit amet, consectetur adipiscing elit.</dd>
>     </li>
>     <li>
>         <dt>Aliquam Viverra</dt>
>         <dd>Fringilla nulla nunc enim nibh, commodo sed cursus in.</dd>
>     </li>
>     <li>
>         <dt>Pretium Et Nibh</dt>
>         <dd>Quisque porttitor mauris ut velit tincidunt ut hendrerit erat
> mollis.</dd>
>         <dd>A dui condimentum suscipit. Quisque tortor nulla.</dd>
>     </li>
>     [...]

I don't think that's more organised, it's just more verbose. :-)


> And usually "life cycle" type contents are presented as circles. Without 
> <li>(s), it will be hard to style them.

This is something we should fix in CSS.


> Since the *optional *use of <li> in <dl> could solve many problems, may 
> we have <li> being valid in <dl>?

On Thu, 19 Jul 2012, Alex Bishop wrote:
> 
> Probably not, as it has similar drawbacks as the proposed <di> element:
> 
> http://wiki.whatwg.org/wiki/FAQ#HTML_should_group_.3Cdt.3Es_and_.3Cdd.3Es_together_in_.3Cdi.3Es.21

Indeed.


On Fri, 20 Jul 2012, Ian Yang wrote:
> 
> <li> in <dl> is rendered without problems in IE6+, FF3.6+, Chrome, and 
> Safari. Only in Opera that definition term and the bullet aren't at the 
> same line.

One big problem with <li> in <dt>/<dd> (beyond it not really being 
necessary) is that it doesn't parse well. </dt>, </dd>, and </li> are 
optional, but when you use these elements together and omit those tags, 
markup like this:

  <dl>
    <li>
     <dt>...
     <dd>...
    <li>
     <dt>...
     <dd>...

...turns into DOMs like this:

  <dl>
    <li>
     <dt>...
     <dd>...
      <li>
       <dt>...
       <dd>...


> Furthermore, browsers need to be compliant with the standards, not the 
> standers need to be compliant with browsers. If the latter were true, we 
> wouldn't have had so many new HTML5 elements to use.

We need to be compatible with the browsers. Adding new features is 
something we have to do very carefully to avoid not breaking the browsers.


On Fri, 20 Jul 2012, Sean Hogan wrote:
> 
> - The benefit of <di> or <li> is not just styling

If there are use cases unrelated to styling, please do bring them up. It's 
not clear what they would be. The semantics are unambiguous, so we don't 
need a container for semantic reasons, and the markup is easier to read 
with a blank line between pairs than with a new element. I'm not aware of 
any other argument for this feature.


> - There's no indication that a CSS solution will be developed anyway

There's no indication than an HTML solution will be developed either. So 
given that both are in the same state, and that the CSS solution would be 
more appropriate here and would solve more problems, why not propose a CSS 
solution rather than an HTML one? :-)


On Tue, 31 Jul 2012, Leif Halvard Silli wrote:
> 
> Which makes me wonder: Why is not value="<number>" allowed for <li> 
> inside <ul>? E.g. I might want to add accidental numbers to the 
> list-items while at the same time also wanting to say that the page does 
> not change meaning whichever way you order the items?

I think that would just confuse an already confusing issue.


> I also wonder: Would it not make sense to advice, when uncertain about 
> whether order is significant, advice authors to pick <ol> over <ul>? For 
> instance the sub-items of our homework items: Since the order of the 
> sub-items often risks becoming significant, it seems smart to pick <ol> 
> and not <ul> - even if <ul> sometimes could work too.

The spec already seems to be pretty clear about the meanings of these 
elements. I hesitate to proffer additional advice lest authors follow that 
rather than actually looking at the definitions.


On Fri, 31 Aug 2012, Leo Willner wrote:
>
> If tour is just needed for panos we could do a <pano>-tag, for that we 
> need the distorted 360°-pano-image and do a rendering of it in the 
> browser into a 360°-pano.

It's not clear to me that this use case is anywhere near common enough to 
warrant dedicated support in browsers. It's already reasonably easy to 
create panoramas either using large images clipped by overflow:scroll 
elements, or using canvas. People doing more complicated things like 
panning around inside multiple panoramas will probably want to use WebGL 
to make more immersive applications. Unless those become really popular, I 
don't think there's a need for dedicated support.


On Sat, 1 Sep 2012, Jesús Ruiz García wrote:
> 
> I do not know if my proposal should go in getUserMedia() specifications, 
> It's something that you know better than I, but I would like to take 
> into account some details:
> - canvas support or any technology that could be drawn on the screen.
> - navigation by gestures or voice.
> - scanning capability of the human body: to store clothes and other more
> specialized sites in these issues.

I don't really follow.


> Before leaving, how could I add this proposal to the wiki?. I guess I 
> have to register, because I see the possibility to Login. Anyway, I 
> usually go by the IRC channel, so we can talk in #whatwg channel.

You are welcome to put proposals on the wiki; if you don't have an 
account, ask on #whatwg.


On Sun, 2 Sep 2012, Charles McCathie Nevile wrote:
> 
> As far as I can tell, those asking for [an element for "main content"] 
> do not believe we do have all the other elements, [like header, footer, 
> etc] and/or are not convinced they for a sufficient proportion of cases 
> they are going to be used as designed.

If an author isn't going to use the elements like <aside>, then there's no 
reason to believe they'll use <maincontent> either.

As far as I can tell, all content that isn't main content fits into one of 
the existing elements, so I don't see the problem if the author _is_ going 
to use them.


> To turn the question around, if it is more convenient for authors to 
> identify the main content, and not think about the classification of 
> other parts, should we offer that facility as part of the platform? Or 
> does it make sense to say that only the exhaustive identification of all 
> supplementary content is an appropriate way to mark up a page anyway?

"Exhaustive" makes it sounds like it would be exhausting to do it, but I 
don't think that's true. All these other sections are going to be wrapped 
anyway, by a <div> if nothing else, and it is trivial to change those 
<div>s into the appropriate <header>, <footer>, or <aside> elements.

Given that, I don't see how it could be more convenient to wrap the 
contents and... do what with the rest? I don't know. You'd still have to 
wrap it, presumably.


> > > The read question for me is: What is the problem of having the 
> > > content at the same level of <header> and <footer> (for example 
> > > inside an <article>)?
> > > 
> > > Can't we treat everything inside an article which is not in <header> 
> > > or <footer> is the real "content"?
> > 
> > That's the intent of the spec, right.
> 
> In that case I think the spec is wrong. I suspect that real content will 
> fail to match this intent in a significant proportion of cases. I also 
> suspect that allowing authors to identify the "main" content would 
> significantly alleviate the problems caused...

Do you have any examples where it wouldn't work?


> > If you just want to group some elements together without giving them 
> > any special meaning, that's what <div> is for.
> 
> But that fails to answer the question. It seems obvious that what 
> advocates of a content element want to do is group some elements 
> together and give that group a special meaning. I believe that is why 
> div="main", div="content" and the like are a common paradigm 
> (anecdotally - I have not done an analysis of any large database).

I think they're more likely there for styling reasons, for which <div> is 
perfectly suited.


> > On Fri, 29 Jun 2012, Steve Faulkner wrote:
> > > 
> > > ARIA fills the gap in HTML with role="main" 
> > > http://www.w3.org/TR/wai-aria/roles#main
> > 
> > This role is unnecessary in HTML documents, since browsers can skip 
> > the non-main content. That's the whole point of elements like <nav>.
> 
> Again, that presupposes that all the non-main content is identified.

What non-main content are you suggesting would not be identified?


> > > I agree that an explicit element would be nice, but the powers that 
> > > be have rejected the idea.
> > 
> > It's not clear what the idea is, so it's hard to say that it has been 
> > rejected. :-)
> 
> This makes no sense. You have very clearly rejected the idea of an 
> element to group the main content, and I am not sure how that is 
> unclear.

Well, all solutions without problems are de-facto not in the spec, but 
that doesn't mean they have been rejected, because to be rejected they 
have to be considered and evaluated, and to be evaluated they have to be 
considered in the context of a problem, and without a problem that can't 
be done. So no, I stand by my statement: without a problem, the solution 
isn't rejected, it's just not considered.


On Thu, 13 Sep 2012, Kevin Deamandel wrote:
> 
> I recently started checking the specs and i can't help but notice the 
> weird formation of the tags in this section [...] can anybody tell me if 
> this is known/on purpous

On Thu, 13 Sep 2012, Tim Leverett wrote:
>
> I assume you're referring to tags written as:
> 
> <Html
>  ><Head
>    ><Title
> 
> The reason for this is to prevent undesired whitespace in markup, while 
> preserving indentation. Whitespace in HTML is preserved between tags, 
> but it is not preserved within.

On Thu, 13 Sep 2012, Jukka K. Korpela wrote:
> 
> My guess is that it's an accidental result of some software used to 
> maintain the document. It's not incorrect, just odd, because it deviates 
> from the coding style used otherwise, both in the use of spaces between 
> tag close (>) and in casing (capitalized tag names).

On Thu, 13 Sep 2012, Tab Atkins Jr. wrote:
> 
> No, it's intentional.  Hixie purposely varied his style across examples, 
> to show that certain variances in the syntax were allowed and perfectly 
> fine.

On Thu, 13 Sep 2012, Jukka K. Korpela wrote:
> 
> Oh, I see. It's somewhat questionable if you ask me. Varying the syntax 
> _within a document_ is something different from the liberty of choosing 
> one's style.

Each example is a different document.


> But I guess the reader is assumed to treat the examples as quotations 
> that reflect different styles (and style is consistent within each 
> example).

Right.


> Still, I wouldn't do that. I don't think authors really need to be 
> reminded of the possibility of writing <Section> instead of the most 
> common way, <section>, and the next common one, <SECTION>.

Given the number of people who see the spec only doing things one way and 
then argue with each other that that is the Only Right Way to do things, I 
wish I could agree with you, but I cannot.


> People who have some special reason for writing, say,
>
> <sEcTIon
> 
> claSs
> 
> =                              foo
> 
> >
> 
> should probably check the syntax definition details if in doubt, and 
> just go ahead (maybe using a validator) if not.

Well, you'll notice I haven't used such esoteric styles. :-)

The styles used in the spec are all styles that I have come across in the 
wild, including the one people quote above.


On Thu, 13 Sep 2012, Scott González wrote:
>
> I personally find that having such an uncommon syntax is actually 
> distracting.

On Thu, 13 Sep 2012, Kevin Deamandel wrote:
>
> I second this Scott

On Fri, 14 Sep 2012, Silvia Pfeiffer wrote:
> 
> Might be worth a note in this instance to stop people from wondering?

Done.


On Fri, 14 Sep 2012, Hugh Guiney wrote:
> On Fri, Sep 14, 2012 at 9:51 PM, Ian Hickson <ian@hixie.ch> wrote:
> >> Also, as I pointed out in the original post, consumers already use 
> >> rel=tag intending for it to apply only to portions of a page.
> >
> > Consumers or producers? What matters here is not changing _consumer_ 
> > behaviour, so that we don't break pages written with the assumption 
> > that they work as they do now.
> 
> Ah, yeah, misunderstood "consumer" as a synonym for "author". Your 
> reasoning does makes more sense to me now.
> 
> But, I would still say that if existing consumer behavior is to apply 
> tags to the entire document, then that is simply a limitation of 
> producers not being able to explicitly say that certain tags only apply 
> to portions of the page... which is actually an open issue on the 
> Microformats Wiki for rel-tag[1], something that the HTML spec could 
> potentially solve, and which <article> seems well-suited to solve.

The problem is that if we change this, we are also changing how all 
existing documents get processed.


> How badly would this actually break existing parsers? Could it really be 
> worse than multiple <address>es? Or <style scoped>?

<style scoped> was carefully designed to not affect legcy content, and to 
be usable with legacy user agents. Not sure what you mean regarding 
<address>.


> And again, it isn't evident to me that pages *are* written with the 
> assumption that robots work this way, as evidenced by WordPress's 
> assignment of tags on a post-by-post basis[2], marked up with 
> rel=tag[3], posts themselves being marked up with <article>, and 
> multiple <article>s being displayed at once in the post listing views. 
> As WordPress is currently the most popular blogging platform on the 
> Internet[4], it represents significant existing usage of the attribute.

What we've found with other things in HTML is that people used them 
incorrectly, thinking they were using them correctly, but actually relied 
on the processing they were having despite it not being what htey 
intended. (For example, authors would give namespaces that were bogus, 
thinking they were making their pages XML-compatible, whereas in fact if 
they were processed as XML their pages would fall apart, since they were 
in fact relying on the processing of their content as HTML for it to work.)

This is why I am very skeptical about changing the semantics like this.

Now if you convince consumers of this link type that they should honour 
<article> after all, and it turns out this improves compatibility with the 
Web rather than breaking it, then that would be a reason to fix the spec.


On Mon, 24 Sep 2012, Karl Dubost wrote:
> 
> On cite attributes, I'm using urn:isbn:
> 
> <blockquote cite="urn:isbn:2-7073-1038-7">
>    <p>J'aime la liberté. J'aime être responsable 
>       de mes actes. J'aime comprendre ce que je 
>       fais… Et, cependant, je donne mon accord 
>       à ce marché bizarre.</p>
> </blockquote>
>
> Which I can use and parse with an extension in Opera [1] which convert 
> it into a link to the Open Library. In the future I could give 
> accessibilities to different services, and the user could choose its own 
> reference system.

On Mon, 24 Sep 2012, Jukka K. Korpela wrote:
> 
> This is all very cool in its own way, and could be useful when used with 
> discipline within a discipline. But for a long time, such cool ideas 
> will not be supported in most browsing situations. Yet, authors who know 
> the cool idea will apply it and will fail to "duplicate" any credits in 
> the normal visible content. This means that to most users, a quotation 
> will appear without any credits or source information.
> 
> It also means that the only immediately available source information for 
> a quotation will be an ISBN in URL format. So, for example, working 
> offline, you won't see even the title and the author. Would the 
> quotation even satisfy the legal requirements for quotations?
> 
> If the credits are additionally given in visible content, there *there* 
> is the place to do cool things with ISBNs. The credits, when they 
> include the ISBN in addition to author, title, etc., could have the ISBN 
> part turned to an element like <a href="urn:isbn:2-7073-1038-7">ISBN 
> 2-7073-1038-7</a>. (This would still suffer from lack of compatibility 
> with older user agents, creating non-working links on them, so maybe 
> some new markup - which would simply be ignored by old user agents - 
> would be better.)
> 
> The point, however, is that the cite attribute in <blockquote> is broken 
> by design and should not be implemented in any new ways (or old).

I will deal with cite="" via:

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

(Probably removing it.)

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