[whatwg] small element should allow nested elements

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'