- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 25 Aug 2009 00:08:58 +0000 (UTC)
On Fri, 14 Aug 2009, Aryeh Gregor wrote:
> On Fri, Aug 14, 2009 at 5:09 AM, Ian Hickson<ian at hixie.ch> wrote:
> > I wouldn't bother wrapping any of the above as small print. If you're
> > structuring this enough that you have numbered lists and paragraphs
> > and everything, then it's either not small print, or it shouldn't be.
>
> To the contrary: the more text there is, the more you want to make it
> small print. That's the point of small print. :) Even very brief
> legalese can often run to more than a paragraph. Even if it's not so
> useful for <small> or (say) <em>, it would make a lot of sense for
> various other elements that are currently only inline. For instance:
>
> <strong>: A particularly important section of a document. For instance,
> it's common in EULAs for one or two sections (like disclaimer of
> warranty) to be entirely uppercase, often running to multiple
> paragraphs. It would be semantically correct to wrap the entire section
> in <strong>.
>
> <i>: A run of text in a novel that's meant to be set off in mood from
> the surrounding text. For instance, a multiparagraph flashback
> sequence.
>
> <cite>: The name of a postmodern work of art whose author chose to name
> it something 7,000 words long. (Okay, I'm kidding.)
>
> I've run into more than one case where I wanted to wrap inline elements
> around blocks and couldn't. If this could be implemented in a
> reverse-compatible way, that would be awesome.
We have done this with <a>, and the problems it introduces are
substantial. I'm very reluctant to extend this to more elements.
> > Allowing elements to wrap both inlines and blocks is a huge can of
> > worms which has caused all kinds of problems for <ins>, <del>, and
> > <a>. I really don't want to start adding more elements to this list of
> > complexity.
>
> I certainly realize that -- you can't even say what their CSS display
> property should be set to, at least not in a way that CSS currently
> supports. But once everyone has to support this behavior for those
> three elements, is there any reason not to extend the same behavior to
> other elements? Is there a significant marginal cost for allowing use
> as both inline and block for new elements once we've already paid the
> overhead of allowing it at all?
Yes, I think so. You can special-case a few elements in an editor's UI,
for example, without extending the complexity to the entire app.
On Sat, 15 Aug 2009, Remy Sharp wrote:
>
> As Aryeh said, my experience has been the inverse, this is small print.
> I've got the terms and conditions for a competition, which is small
> print for the whole thing. Currently I'm manually wrapping every
> sentence in a small tag (as per my example).
Just don't use <small> at all, and just make the font size smaller in CSS.
> For example, the BBC's web site is using the 62.5% rule, then by default
> pages are shown in 1.2em. The exception being their terms pages, which
> overrides the font size to 1em in a terms.css style sheet. This is
> because they want the text to appear as small print.
>
> BBC Terms:
> http://www.bbc.co.uk/terms/
That page is a great example of where _not_ to use <small> -- the text on
there is the main content of the page, it's not a throw-away side comment.
I've added text to this effect.
> > Allowing elements to wrap both inlines and blocks is a huge can of
> > worms which has caused all kinds of problems for <ins>, <del>, and
> > <a>. I really don't want to start adding more elements to this list of
> > complexity.
>
> Is there any record of these issues. I know of 1 rendering issue that
> Firefox has with nesting the section element inside the a element (but
> I'm sure you're referring to previously solved issues).
The issues are things like:
* It makes it possible to have phrasing-level elements span paragraphs:
Fred stood up. <i> How are you?
<p> Are you ok? </i> He sat down again.
* It makes it very difficult to have intuitive UI in WYSIWYG editors.
* It leads to confusing parsing behaviour, e.g. there are nested
paragraphs here, which is not allowed, and is highly unobvious:
<p> This is uncontroversial text.
<ins> <p> This is new text. </ins>
<del> <p> This is deleted text. </del>
On Sat, 15 Aug 2009, Smylers wrote:
>
> Where <small> might be useful is another page which has a competition on
> it (in regular sized text) followed by:
>
> <p>
> <small>Terms and conditions apply. For full details see the
> <a href="http://www.bbc.co.uk/terms/">standard BBC T&Cs.</a>.</small>
> </p>
>
> In that case the short amount of 'small print' is distinguished from the
> surrounding text. Visual users can see it as such; a speaking browser
> could read it out faster.
Right.
On Sat, 15 Aug 2009, Remy Sharp wrote:
>
> Here's the actual example I'm working with:
>
> http://2009.full-frontal.org/ticket-draw (at the bottom of the page)
>
> You can see that I've had to wrap each inner li element, and also that
> the li bullet sizes don't match that of the text.
>
> It seems logical to me to wrap the entire ol element in the small tag.
I agree that this is more borderline. However, you've given this its own
section, so I wouldn't bother with <small> at all.
On Mon, 24 Aug 2009, Jeremy Keith wrote:
>
> Fair enough. But in that case, I think perhaps the spec could do with a
> bit of rewording for the <small> element.
I've tried rewording it.
On Mon, 24 Aug 2009, Chris Cressman wrote:
>
> I agree that allowing <small> to wrap inlines and blocks addresses
> Remy's use case directly and would allow authors to create other useful
> patterns for small print. Personally, I would like to see this change in
> the spec. I admit though, I am ignorant of the issues this has caused
> for the other elements Ian mentioned.
>
> I see that the content model of <address> has been redefined in HTML 5
> to allow block elements. I'd like to see a similar change for <small>,
> but I ultimately defer to Ian to weigh the benefits against the cost in
> added complexity.
>
> I think changing the content model of <small> is more appropriate than
> changing its description. If the content model does not change, the
> description should not change either (since the description and content
> model work together to explain the appropriate use of the element).
If <small> was a block-level element in HTML4, then I think we'd just make
it a flow-level element here and give up on inline throw-away comments.
But as it is, it's the other way around. I don't think we want one element
to do both, though, and I don't think this use case is important enough to
bother with if we can't just leverage existing elements.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 24 August 2009 17:08:58 UTC