[uf-discuss] a very early draft proposal hTagcloud

[Scott Reynen]

On Sep 20, 2006, at 8:19 AM, John Allsopp wrote:

> It's very clever, without any doubt. It is however very divergent  
> from almost all current developer practice (which of course does  
> not remotely make it incorrect, but possibly harder to get  
> adoption), and in the case of deeply nested ems (even if we weights  
> to 5 levels we get thigns like this <em><em><em><em><em><a  
> href="...">tag</em></em></em></em></em>) perhaps even more so. I  
> also consider this in more detail in the article so won't.
> On the other hand, as tagclouds are most likely to software  
> generated, this really might not be such an issue.

I don't really think that's a big deal.  We've pushed correct, though  
uncommon, use of HTML tags before, e.g. <address>, the class  
attribute, and, well, most of microformats.  This seems to be no  
different.  It's part of the microformat process to look to existing  
HTML semantics first.  All of the alternatives to nesting <em> seem  
to be only duplicating the semantics of <em>.  I still like Tantek's  
approach.  The most significant concern seems to be that the default  
visuals without CSS are far from ideal, which seems to be a concern  
very similar to those raised with <address>.  We addressed that by  
allowing alternatives while still preferring the basic HTML tag.  How  
about something like this:

Preferred: <em>, <em><em>, <em><em><em>, <em><em><em><em>
Alternate: <small class="em">, <em><em>, <strong class="em"><em><em>,  
<big class="em"><strong class="em"><em><em>

For parsers, either <em> or a class of "em" would increase the  
emphasis given to the surrounded tag.

Peace,
Scott