W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2008

[whatwg] Deprecating <small>, <b> ?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 14 Nov 2008 10:23:44 -0600
Message-ID: <dd0fbad0811140823qdc8ebaeyb055a3983cfbe6d4@mail.gmail.com>
On Fri, Nov 14, 2008 at 9:38 AM, Pentasis <pentasis at lavabit.com> wrote:

> Of course not.  You're not intended to.  What you *do* get, though, is that
> this is a word which is *intentionally* stylistically offset from the rest
> of the text.  This conveys semantic meaning to a human - it means that the
> word is special or being used in a particular context.  <b> and <i> don't
> communicate *much*, but they communicate *something*.  One could, of course,
> also use a <span> to mark up and style the text, thus communicating the same
> intent to a person reading the styled text, but to a machine the <span>
> means literally nothing, while <b> and <i> have the possibility to
> communicate *something*.
>
> In addition, the fact that these elements traditionally have a particular
> preferred rendering means something.  A dumb terminal which doesn't
> understand CSS won't give any indication to the user that a <span> exists at
> all, while <b> and <i> have a chance of providing fallback rendering that
> still accomplishes what they were designed to do.  A decent chunk of html5
> concerns itself with providing fallbacks and graceful degradation (or
> progressive enhancement, whichever way you want to look at it).  Having some
> *nearly* semantic-free elements which have a meaningful fallback can be
> useful.
>
> Of course, it may certainly be more useful to you if you provide a class on
> the <i> as well.
>
> ~TJ
>
>
>
> First: Computers are binary instruments. conveying *something* is not very
> logical seen from a computers point of view. It is not usefull to *me* to
> provide a class to the <i> or any other element, it is usefull to the
> computer, as humans may indeed come to some sort of conclusion based on
> style or strangely used semantics, computers cannot, they (still) need a
> more literal means of semantics.


If we wish to communicate that level of semantics, yes.  It may not be
useful to us.  If you *really* need some metadata/semantics, @class probably
can't convey it with enough granularity.  Check out the big discussion from
a few months ago about ccRel and RDFa.


> Second: Suppose I want to collect all copyright notices from 1000 websites
> (don't ask me why, I just want to), how am I to do this when they are marked
> up in <small>s? I will definatly end up with a lot of text that has nothing
> to do with copyrights (and probably miss a lot of copyright notices as they
> are marked up differently) Whereas If they were maked up in (for example)
> <span class="copyright"> I could retrieve it all based on the class-name.
>

That would be a wonderful perfect world.  I'd like the copyright date as
well, so I can retrieve only things copyrighted in the last ten years.
Assuming that metadata will exist is a fool's errand.  The fact is that if
you are searching for copyright notices, the most efficient way is likely to
just search for the string "copyright" and the (c) symbol.  That'll net you
copyright notices with a high accuracy, and some training on real data can
yield further rules to improve the data-mining accuracy.

While we're hoping for copyright notices to be marked up as <span
class="copyright">, though, why not wish for <small class="copyright">?  If
you're going to be providing metadata, it works the same.  Is it that you
believe people won't provide a special class for copyrights if the <small>
tag already gives them the preferred display?  Do you believe that everyone
will automatically use class="copyright" to mark up their copyright
notices?  What if they use class="copyright-notice"?  Or class="license"?
Or any of a million other distinct possibilities that would destroy any
naive attempt to datamine based on a particular class name?

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081114/9f044baf/attachment.htm>
Received on Friday, 14 November 2008 08:23:44 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:07 UTC