[whatwg] small element should allow nested elements

2009-08-24 Thread Jeremy Keith

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

2009-08-24 Thread Chris Cressman
 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

2009-08-24 Thread Ian Hickson
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

2009-08-15 Thread Remy Sharp

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

2009-08-15 Thread Smylers
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

2009-08-15 Thread Remy Sharp

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

2009-08-14 Thread Ian Hickson
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

2009-08-09 Thread Bruce Lawson

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

2009-08-07 Thread Remy Sharp

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

2009-08-07 Thread Remy Sharp
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