Add a div element?

Hi Shaun,

On Fri, 2011-06-10 at 12:15 -0400, Shaun McCance wrote:
> I'm toying around with an extension to do expanders for blocks
> and sections. You can make formal blocks and sections collapsible,
> but you can also just have a stand-alone expander, like so:
> 
> <ui:expander expanded="no">
>   <title>The title is always shown</title>
>   <p>But this is only shown when expanded</p>
> </ui:expander>
> 
> The problem is that the fallback behavior for tools that don't
> support the extension is a bit weird. It will treat the content
> as normal block content, which is right, but it will encounter
> that extra title element, which isn't generally valid as block
> content.
> 
> So I'm thinking of adding a generic div element. It would have
> an optional leading title, so could be used as a no-semantics
> way to do a formal block or a floating title. You could also
> use it without a title for grouping. That's potentially useful
> for stuff like conditional processing.
> 
> Then the fallback behavior for unknown block content could be
> changed to something like "if the unknown block element has a
> leading title element, treat it as if the containing element
> were a div". 

Can you give an example of a use case for the standalone expander when a
section wouldn't be appropriate? I'm worried by the potential for abuse
here (expanders are cool, people always overuse cool things).

The use case I have firmly in mind for expandable sections is where you
have a topic that has a choice of several detailed actions which the
user must select from, but for which clicking through to a separate
topic would break the reader's flow. For example, a topic on connecting
to the internet: there are several non-trivial sets of instructions
depending on whether the user connects via wireless, Ethernet, 3G... but
they're still the same topic.

At the moment, I think I would prefer any expandable elements to be
quite "heavy" (large structural elements like sections which need a
significant amount of content to look sensible). That way, people won't
use expanders for trivial/short things, like single paragraphs or even
options within a <steps> <item>!

Expanders will be used as a sort of conditional processing tool (relying
on user input), like in the example I gave above. These aren't
necessarily good for users, especially if the hidden information is very
brief - hiding too much information behind expanders will slow down scan
reading and could encourage bad habits (like super-long topics).
Requiring someone to expand an element "just in case" there is useful
information in there is also bad practice, because it effectively makes
expansion compulsory for the user. Only elements where the situation in
which the hidden information is useful is *clear* should be expandable
(e.g. it's clear that someone with 3G will expand the "3G" section and
not "Wireless").

Thanks,

Phil