[wp-hackers] Tag cloud semantics

Otto otto at ottodestruct.com
Thu Jan 24 19:49:57 GMT 2008

On Jan 23, 2008 3:37 PM, Andy Skelton <skeltoac at gmail.com> wrote:
> This is the most interesting idea I've seen here, but I still don't
> see any problems with using explicit sizes.

Because then you're limiting it to *explicit sizes*. What if I don't
want to use sizes?
What if I want to use colors?
What if I want to use underlining or emphasis?
What if I want to use absolute position on the page?

By limiting the "cloud" to size, you're limiting it to what you think
a cloud should be. Also, you're putting actual styling information
into the content itself, instead of semantic information which can
have styling applied to it.

> I do not like the idea of a finite number of size classes for tag
> clouds. The wrong assumption is that classes are a better semantic
> representation than rational numbers for the infinite-and-bounded
> range of values expressed by a tag cloud. When you reduce that range
> to a finite set of values, you must force different values into group
> together and thereby lose information. It is beyond lossy; it is
> destructive.

There is a physical limit no matter how you look at it. Your use of an
unbounded set has a limitation as well, that being the limitation of
the floating point value. You also have destructive rounding problems
as well. This is all in addition to an inability to adjust the display
of your cloud without hacking the core code or ceasing to use that
core code entirely.

> To answer the OP's question, explicit sizes have the following benefits:
> * There are an infinite number of possible sizes because any rational
> number (e.g. 3.14159) will work.

Okay now you're just being silly. Do you seriously think that your
display is even capable of rendering a font size all the way down to
the 5th decimal place? Or that your browser is capable of calculating
it? Frankly, I'd be shocked if the browser rendered even one decimal
place and didn't just trunc the numbr to the int value anyway.

> * Rational numbers do not need to be defined in a stylesheet.

That's not a benefit, it's a downside. Again, I like the idea of using
color instead of size.

> * Rational numbers are compact and easy to understand.

I'll give you this one. But an theme defined set of tagcloud-X classes
is easy to understand too.

> * It is easy to give the user control over the size ranges: upper and
> lower bounds are familiar font sizes.

Let's say you used tagcloud-X classes. You don't need a lower limit,
just use 1 for X. The upper limit can be defined by the call to the
tagcloud creation function, but it can default to some useful value,
like 10 or so. This puts not only the rounding level within the
control of the theme creator, but the display parameters as well. Your
method gives neither to the theme creator, all they can do is specify
size bounds.

> There are also some interesting things you can do to manipulate the
> data in rational number format that you cannot do with nested
> big/small tags or pre-defined classes: you can write code to change
> the way the browser represents the data.
> For example (not that I've seen it done, but feel free to try it)
> there can be a javascript function written to allow the viewer to sort
> the terms according to any value associated with each term, such as
> its font size. In this way, you can convert a cloud into an ordered
> list. I have seen tables that can be sorted by different columns; why
> not the ability to switch the cloud's size basis to different values
> (post count, comment count, view count, etc.) or to convert between
> clouds and tables? This would not be so straight-forward without
> rational numbers.

I don't follow you. Sure, your font-size is adjustable via javascript,
but so is any form of CSS you like. The class values are well
available and easy to manipulate via javascript. Also, your idea
*requires* javascript to manipulate the display. Ours just requires
CSS to manipulate it, javascript would only be required to manipulate
it on the client side.

> So I hope we leave it the way it is.

The way it is is not only awful, it's non-semantic and completely
against the whole point of separation of the style from the content.


More information about the wp-hackers mailing list