W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2012

[whatwg] Feedback on HTML elements

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 18 Oct 2012 19:33:01 +0000 (UTC)
To: whatwg@whatwg.org
Message-ID: <Pine.LNX.4.64.1210181913220.2478@ps20323.dreamhostps.com>
On Fri, 28 Sep 2012, Ian Yang wrote:
> On Fri, Sep 28, 2012 at 2:27 AM, Ian Hickson <ian@hixie.ch> wrote
> > 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.
> 
> When it comes to conveying semantics, many existing HTML elements' name 
> already have such an issue. So developers should at least have a basic 
> understanding of English. After all, it's not hard to learn a few more 
> English words. :-)

More people speak Chinese than English, and it's not too hard to learn a 
bit of Chinese, right? Maybe we should change HTML to use Chinese names 
instead. :-)

In practice, I would expect that most authors learn HTML in their native 
tongue, and treat the element names as opaque strings.


> The displaying of new elements like <c> or <info> could be fixed by 
> using javascript like how we have fixed the displaying of <header>, 
> <footer>, <article>, ...... etc in legacy browsers.

Indeed, for some elements we have done this (e.g. <mark>).


> > 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.
> 
> That structure is simple and elegant. Yet in some circumstances, that 
> might cause styling issues. For example, developers might want to float 
> the label text to right or slightly adjust its vertical aligning.

Indeed.


> > 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.
> 
> Yes, we could do absolute positioning for every <dt> and <dd>, but 
> that's troublesome. With the optional use of <li>, we only need to 
> position <li>s.

I mean it's something that we should make easy in CSS. That is, CSS should 
have a way to do this that doesn't require complicated positioning of each 
<dt> and <dd> or whatnot. For example, a way to imply a pseudo-element 
around a pattern of elements.

   ::pseudo(from: dt:first-child, dd + dt;
              to: dd:last-child, dt:matches(# + dd)) { }

...or some such.


> > 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.
> 
> Since the proposed use of <li> is optional, developers who want to use 
> it should include closing tags (</li>, </dt>, and </dd>). That solves 
> the issue.

I don't think that's solving the issue, I think that's asking authors to 
paper over the issue for us.


On Mon, 15 Oct 2012, Willabee Wombat wrote:
>
> Please see http://forums.whatwg.org/bb3/viewtopic.php?f=3&t=5081 for the 
> background of my request to have <acronym> added to the HTML5 spec.
> 
> Without getting into all of the discussions about what is an 
> abbreviation and what is an acronym, I would like to propose the 
> <acronym> element be added to the semantics of HTML5 with a clear 
> indication of its semantic use;
> 
> <acronym> the word is spoken.
> 
> <abbr> the abbreviation is spelt out, letter by letter.

This, unfortunately, doesn't cover the full range of abbreviations in 
English (let alone other languages).

Is "SQL" spoken or spelt out? Or "PNG"?

Is "XMLHttpRequest" spoken or spelt out?

Are "JPEG" or "MPEG" spoken or spelt out? How about "IPSEC"?

And that's not even looking at issues like translation (such as what Karl 
pointed out), or other complications in other languages.


> Nice and simple. Everyone should understand the semantics.

Unfortunately, language is anything but simple. :-)


>    - Screen readers can use it to say or spell out the word.

Screen readers have to solve this problem in the absence of markup anyway, 
since not everyone uses these elements. So they tend to use heuristics and 
dictionaries, which make this a non-problem.


>    - Designers can use these different elements to stylistically make the
>    semantics obvious to visual users.

The class attribute can be used to do this. This page on Wikipedia 
suggests that in practice there are many styles and it's not clear that 
two elements would make matters easier:

   http://en.wikipedia.org/wiki/Acronym_and_initialism


>    - There will be no need to add a class name to these elements for
>    presentation purposes.
>       - Thus making the HTML author and the designers job much easier.

Back when we had both elements, there were continuous debates about which 
element to use when. I don't think this was easier. :-)


>       - In addition, the overall page weight will be much lighter. Which is
>       very important as we go more and more into the mobile world with our web
>       site designs.

I think this is assuming that authors are going to want to style 
abbreviations in the first place, which is somewhat rare in practice.


On Mon, 15 Oct 2012, Nils Dagsson Moskopp wrote:
> 
> I just found <http://camendesign.com/code/using-abbr> where it is 
> suggested to use an abbr element without a title attribute to indicate 
> that the abbreviation “is unpronouncable as a word”.
> 
> <http://camendesign.com/abbr_redux> backtracks: “Do not use [abbr] on 
> initialisms that are spoken letter-by-letter”, “Only use abbr 
> without a title on initialisms that should be pronounced as written 
> rather than read out letter-by-letter”.
> 
> Is this acceptable?

The spec makes it pretty clear that <abbr> may, but need not, be used for 
any kind of abbreviation:

   http://www.whatwg.org/specs/web-apps/current-work/#the-abbr-element

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 18 October 2012 19:33:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:11 GMT