W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: what is dt?

From: Smylers <Smylers@stripey.com>
Date: Thu, 17 Sep 2009 16:39:55 +0100
To: Shelley Powers <shelleyp@burningbird.net>, public-html@w3.org
Message-ID: <20090917153955.GV4359@stripey.com>
Shelley Powers writes:

> The rejection of the idea, because of how browsers currently implement
> the DOM for HTML4 puzzles me, since we're changing the DOM for HTML5,
> anyway.

Hi Shelley.  Often HTML5 changes don't change the dom -- even brand new
elements may not involve dom changes, if they happen to be how existing
browsers behave with unknown elements.

But the issue isn't just with the dom; it's also with how existing
elements are rendered.

> I am less concerned about issues related to browser companies having
> to change their code, than I am introducing levels of new confusion
> with HTML5. This specification should have, as its primary audience,
> the larger of the groups who are directly impacted by its contents,
> which would be the web developers/designers.

The problems with redefining existing behaviour aren't that browser
developers would need to make changes (they need to make plenty of
changes for HTML5 anyway!); they are problems for authors.  There are
two sorts of limitations:

* Not breaking existing pages:  Unfortunately there are existing pages
  which expect certain behaviour, such as what happens to a <caption>
  even if it's in a really stupid place in the source.  Changing this
  behaviour in HTML5 will break how such pages render.  Which will make
  users avoid HTML5 browsers, cos they break pages.  Which will prevent
  authors from ever being able to use any of the new HTML5 features.
  (See also XHTML2.)

  This is a permanent problem, in that such behaviour can never be
  changed.

* Being able to create new pages using the HTML5 elements:  Even when
  HTML5 browsers are released many users will still be on older
  browsers.  Authors are familiar with the idea of having to support
  legacy browsers.  So any new HTML5 element or meaning has to have
  reasonable behaviour in existing browsers, else can't be used until
  everybody has upgraded.

  Things like default padding on <dd> (in places where an HTML5 browser
  would not add it) are not particularly a problem, because an author
  can use CSS to remove unwanted the padding in legacy browsers.

  In contrast the odd way in which <legend> is currently treated cannot
  be overridden by authors with CSS or JavaScript.

  This is a temporary problem; HTML5 browsers could start treating
  <legend> differently, then once all users have upgraded authors can
  start to use it -- something which is likely to take a decade or so.

> The needs of the browser makers should be secondary.

Indeed.  The needs of browser makers do not come into this.

> I would rather a new element be defined, clean of past semantics, and
> used consistently

Everybody would prefer a well-named element which can be used now.
Unfortunately that doesn't seem to be possible, so we either have to put
up with a badly named element or wait a long time to be able to use it.

Obviously different people can legitimately find one of those worse than
t'other -- this is a judgement call rather than a matter of being
'right' or 'wrong', and whatever happens there are clearly going to be
some people unhappy, who can (legitimately) point to the downside of
that option.  (We know this because Ian has committed each in turn to
the spec, and been slated both ways round.)

Shelley Powers writes:

> Simon Pieters wrote:
> 
> > On Thu, 17 Sep 2009 15:02:42 +0200, Shelley Powers
> > <shelleyp@burningbird.net> wrote:
> >
> > > Actually, label has been found to be acceptable for use with
> > > Figure.
> >
> > I don't think <label> is acceptable, because it interacts with form
> > controls and is generally allowed anywhere. What if you want a form
> > control in the figure caption? What if you want a <label> as the
> > figure content? It wouldn't work if <label> was used as the figure
> > caption.
> >
> > Also, <label> is rendered as an inline element in legacy browsers,
> > but a figure caption should be block level.
> >
> > <dt> does not have these problems.
> 
> Interestingly enough, there's an existing bug about dt/dl because of how
> they are physically implemented by legacy browsers[1].
>
> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7629

That bug isn't to do with how <dd> is implemented in legacy browsers;
it's that HTML5's own rendering section needs updating to be in sync
with recent changes.

Smylers
Received on Thursday, 17 September 2009 15:40:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:08 UTC