[whatwg] small element should allow nested elements
Hixie wrote: 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. Fair enough. But in that case, I think perhaps the spec could do with a bit of rewording for the small element. The current wording: Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements. ...sounds like an *exact* fit for Remy's use case: So I'm making a list of disclaimers for my site: ol liYou must agree to this term/li liAnd this term too/li liAnd don't break this term/li liAnd don't forget the milk/li /ol pBy reading this, you're agreeing to xyz/p Does anyone have any ideas on a rewording of the definition of the small element to make it clear that it is only intended for certain instances but not others? Alternatively, does anyone else think the small element should be capable of wrapping inline and block elements? (raises hand) -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] small element should allow nested elements
Alternatively, does anyone else think the small element should be capable of wrapping inline and block elements? (raises hand) 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). Chris -- Chris Cressman http://chriscressman.com
Re: [whatwg] small element should allow nested elements
On Fri, 14 Aug 2009, Aryeh Gregor wrote: On Fri, Aug 14, 2009 at 5:09 AM, Ian Hicksoni...@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 smallTerms and conditions apply. For full details see the a href=http://www.bbc.co.uk/terms/;standard BBC Tamp;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
Re: [whatwg] small element should allow nested elements
On 14 Aug 2009, at 10:09, Ian Hickson 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. 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). 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/ Random blog post on the BBC (most, if not all pages are the same font size): http://www.bbc.co.uk/blogs/thereporters/robertpeston/2009/08/what_rbss_results_say_about_qe.html They're using CSS to visually create the small print effect on a large amount of text. From my understanding of the HTML 5 spec, the right semantics to use is the small element, but if they used it on their existing terms page, in the way that the spec current outlines it would bloat the page with the extra nested small element. Wrapping the entire block in small (or individual blocks) would be much more maintainable, and it would give the copy the right semantic meaning. Is that correct? 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). I'd be happy to go through those issues and see if I can run tests against the small element through each of the browser engines to see if the issues still apply to small element. Cheers, Remy Sharp Left Logic ___ I'm running a conference in Brighton on 20-Nov called: Full Frontal JavaScript Conference http://2009.full-frontal.org
Re: [whatwg] small element should allow nested elements
Remy Sharp writes: On 14 Aug 2009, at 10:09, Ian Hickson 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. For example, the BBC's ... 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. BBC Terms: http://www.bbc.co.uk/terms/ That's an entire page of legalese. The legalese is the point of the page. It doesn't need marking up in some way from the rest of the text on the page because there isn't any such text. This is because they want the text to appear as small print. CSS seems an entirely reasonable way of doing that. If a CSS-less user doesn't get the text delivered smaller no meaning is lost (since the user reading that page is aware that it's all small print). Ditto for a listen whose speaking browser uses the normal voice for it. Where small might be useful is another page which has a competition on it (in regular sized text) followed by: p smallTerms and conditions apply. For full details see the a href=http://www.bbc.co.uk/terms/;standard BBC Tamp;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. Smylers
Re: [whatwg] small element should allow nested elements
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. Remy Sharp On 15 Aug 2009, at 12:29, Smylers wrote: Where small might be useful is another page which has a competition on it (in regular sized text) followed by: p smallTerms and conditions apply. For full details see the a href=http://www.bbc.co.uk/terms/;standard BBC Tamp;Cs./ a./small /p
Re: [whatwg] small element should allow nested elements
On Fri, 7 Aug 2009, Remy Sharp wrote: The HTML 5 spec says: Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements. So I'm making a list of disclaimers for my site: ol liYou must agree to this term/li liAnd this term too/li liAnd don't break this term/li liAnd don't forget the milk/li /ol pBy reading this, you're agreeing to xyz/p To make this valid, and small print text, I need to individually wrap the inner HTML of each inline element (li and p elements). This is wasteful and very much like the situation that we had with the a element when we wanted the whole block to be clickable. 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. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] small element should allow nested elements
On Fri, 07 Aug 2009 14:19:23 +0100, Remy Sharp r...@leftlogic.com wrote: Hi, I know Bruce Lawson has mentioned that this has been brought up before, but I couldn't find it in the archives (searching small), so I'd like to bring it up again. I suggested it in the w3c list, not this one. Link: http://lists.w3.org/Archives/Public/public-html/2009Jan/0130.html ... When I wrap *everything* in the small element (as seen here: http://jsbin.com/okevo ) all the browsers I've tested it in renders the text as I would expect, but it doesn't validate against the HTML 5 parsing rules (as you'd expect). Here's the list of the compatible browsers (I could have done more browsers, but I think this test with 10 proves the support is solid): http://leftlogic.litmusapp.com/pub/a5fa8ed Previously we got on a bit of a navelgaze about what constitutes legalese/ disclaimers and whether any sites actually use it. But given that browsers currently allow small to go round block level elements, I agree with Remy that we should document the current state of browsers and allow the element to be both inline and block, like a, ins and del. bruce
[whatwg] small element should allow nested elements
Hi, I know Bruce Lawson has mentioned that this has been brought up before, but I couldn't find it in the archives (searching small), so I'd like to bring it up again. The HTML 5 spec says: Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-small-element So I'm making a list of disclaimers for my site: ol liYou must agree to this term/li liAnd this term too/li liAnd don't break this term/li liAnd don't forget the milk/li /ol pBy reading this, you're agreeing to xyz/p To make this valid, and small print text, I need to individually wrap the inner HTML of each inline element (li and p elements). This is wasteful and very much like the situation that we had with the a element when we wanted the whole block to be clickable. When I wrap *everything* in the small element (as seen here: http://jsbin.com/okevo ) all the browsers I've tested it in renders the text as I would expect, but it doesn't validate against the HTML 5 parsing rules (as you'd expect). If this element is truly for disclaimers, caveats and restrictions, and not stylistically making something small, then it will be typically used on blocks of content, be it a single line or multiple paragraphs. As such, it seems sensible to say that the small element can have nested block elements within it. Here's the list of the compatible browsers (I could have done more browsers, but I think this test with 10 proves the support is solid): http://leftlogic.litmusapp.com/pub/a5fa8ed smallAt time of writing, the last test is still being generated, but I've tested Firefox 3.5 manually and it passes/small ;-) Cheers, Remy Sharp Left Logic ___ I'm running a conference in Brighton on 20-Nov called: Full Frontal JavaScript Conference http://2009.full-frontal.org
Re: [whatwg] small element should allow nested elements
I should add, another argument for using small to wrap, is that without it, on a list element, the numerals in the list are larger than the the small print text - because the small element is on the inner HTML rather than the entire element (which does effect the numeric bullets too). Remy Sharp On 7 Aug 2009, at 14:19, Remy Sharp wrote: Hi, I know Bruce Lawson has mentioned that this has been brought up before, but I couldn't find it in the archives (searching small), so I'd like to bring it up again. The HTML 5 spec says: Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-small-element So I'm making a list of disclaimers for my site: ol liYou must agree to this term/li liAnd this term too/li liAnd don't break this term/li liAnd don't forget the milk/li /ol pBy reading this, you're agreeing to xyz/p To make this valid, and small print text, I need to individually wrap the inner HTML of each inline element (li and p elements). This is wasteful and very much like the situation that we had with the a element when we wanted the whole block to be clickable. When I wrap *everything* in the small element (as seen here: http://jsbin.com/okevo ) all the browsers I've tested it in renders the text as I would expect, but it doesn't validate against the HTML 5 parsing rules (as you'd expect). If this element is truly for disclaimers, caveats and restrictions, and not stylistically making something small, then it will be typically used on blocks of content, be it a single line or multiple paragraphs. As such, it seems sensible to say that the small element can have nested block elements within it. Here's the list of the compatible browsers (I could have done more browsers, but I think this test with 10 proves the support is solid): http://leftlogic.litmusapp.com/pub/a5fa8ed smallAt time of writing, the last test is still being generated, but I've tested Firefox 3.5 manually and it passes/small ;-) Cheers, Remy Sharp Left Logic ___ I'm running a conference in Brighton on 20-Nov called: Full Frontal JavaScript Conference http://2009.full-frontal.org