Re: [whatwg] Elements feedback

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. :-)

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.


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

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.


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


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

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.

With regard to compatibility issue, we could always use javascript to fix
that. It's like how we have fixed <header>, <footer>, <article>, ...... etc.


Kind Regards,
Ian Yang

Received on Friday, 28 September 2012 03:48:37 UTC