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

Re: Proposed amends to <small> element

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 12 Feb 2009 01:42:31 +0000 (UTC)
To: Bruce Lawson <brucel@opera.com>
Cc: Ben Millard <cerbera@projectcerbera.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, HTML WG <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0902120130560.28232@hixie.dreamhostps.com>

On Tue, 20 Jan 2009, Bruce Lawson wrote:
> On Sat, 17 Jan 2009 19:36:31 -0000, Ian Hickson <ian@hixie.ch> wrote:
> > 
> > On Sat, 17 Jan 2009, Bruce Lawson wrote:
> > > 
> > > I suggest that <small> be allowed to surround block level elements, 
> > > because a list of caveats, or two paragraphs, may legitimately be 
> > > legalese and worthy of the <small> tag.
> > 
> > This doesn't seem intrinsically bad, but the problem is that doing 
> > this makes the requirements in the spec really complicated. We've 
> > already gone down this road with <a>, and it makes determining what is 
> > a paragraph and what isn't an exercise in subtlty. Unless there are 
> > really compelling reasons to allow elements to do double-duty, as 
> > there are with <a>, I'd really rather not make the content models even 
> > more complicated.
> It seems to me that this favours convenience for browser manufacturers 
> and spec writers (of whom there are comparatively few) over the 
> ease-of-use for web authors (of whom there are significantly more) and 
> for whom authoring simplicity and easy-to-learn is a factor in adoption 
> of a technology or an element.

To some extent, yes, but in practice doing things that are likely to cause 
implementation bugs in low-priority areas like this end up hurting authors 
far more than implementors and spec authors (who can just ignore it).

For example, look at the mess that <object> has become. It's been mostly a 
pain to authors, because it was designed in a way that introduced a lot of 
implementator baggage.

> I'd still suggest rewording the spec to clarify
> - that legal restrictions are "caveats", not "disadvantages" (I think we 
> should avoid loaded terminology)

I looked up "caveats" on anseers.com and the first definition was:

# Warnings, often written to a potential buyer, to be careful; often 
# offered as a way for the seller or broker to minimize liability for what 
# otherwise might be a deceptive trade practice.

...which seems far more loaded that "disadvantages". In general though I 
think it's pretty safe to say that the small print is disadvantages; after 
all, most people would not hide the advantages in the small print.

> - that the small element surrounds caveats that are related to the main 
> content but which are not, in themselves, the main content (so it's not 
> used to surround all text on a page dedicated to legalese)

Isn't this covered by the current definition already? In what sense is the 
main content on a page dedicated to legalese "small print"?

> - the difference between "other side comments" that are marked up using 
> the small element, and side content that is in the aside element, 
> without arbitrary and undefined distinctions of "short" passages vs long 
> passages.

I've added an example to try to clarify this.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 12 February 2009 01:43:06 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:42 UTC