Hi All,

On Mon, Jan 4, 2010 at 11:00 PM, Shaun McCance <[email protected]> wrote:

> Hi folks,
>
> In Mallard, every element unambiguously takes either block or
> inline content.  In other words, you can't do something like
> put a paragraph inside a paragraph.  This was an intentional
> design decision from the start, and it considerably simplifies
> a lot of processing.
>
> One side effect of this is that, in order to allow different
> block elements in list items, we have to enforce that list
> items always take block content.  So we have to do this:
>
> <list>
>  <item><p>One</p></item>
>  <item><p>Two</p></item>
>  <item><p>Three</p></item>
> </list>
>
> The same applies for table cells.
>
> We've discussed ways of dealing with this little annoyance
> in the past.  One suggestion was to introduce a different
> list item marker that takes inline content instead.  This
> would work, but I'm very cautious about adding elements.
>
> So I had an idea.  What if we just allowed block elements
> to stand on their own, without an item element?
>
> <list>
>  <p>One</p>
>  <p>Two</p>
>  <p>Three</p>
> </list>
>
> Any block element that's directly inside a list would be
> interpreted as if it were wrapped in an item element.  Of
> course, you would still be able to use the item element
> if you need to wrap multiple blocks elements in one list
> item.  You could even mix and match in a single list.
>
> <list>
>  <p>One</p>
>  <p>Two</p>
>  <item>
>    <p>Three</p>
>    <p>i.e. 3</p>
>  </item>
> </list>
>
> The same would apply for item elements in a steps list,
> but not for item elements in terms lists or tree lists.
> (The processing model for those would make it stupidly
> difficult to deal with.)  And we could possibly do the
> same thing for table cells, though I'd need to look more
> thoroughly into how much that complicates things.
>
> For basic lists and steps lists, though, processing this
> is actually very simple in any tools I'm familiar with.
> I don't think it would significantly complicate anything
> on the code side.  And it saves everybody a lot of typing.
>
> My question is, does it make sense to you as writers?
> It certainly seems much easier once you understand it,
> but does it boggle you at first glance?  I want to make
> things as simple as possible, but sometimes too simple
> can just be confusing.
>
> Thoughts?
>
>
Initially, looking at something like this seemed pretty cumbersome to me:

<list>
 <item><p>One</p></item>
 <item><p>Two</p></item>
 <item><p>Three</p></item>
</list>

In practice, though, it hasn't been much of a hindrance to me.  Once I knew
that this is how I set up a list, it has been easy to remember, and easy
enough to use.  I normally just copy and paste from one list to another as a
starting point anyway.

You reference lists here, but steps are done in the same way.  If you made
this particular change, would <step> (or other such syntax elements) also be
affected?

Part of me thinks, "Will this cause problems with xslt processing or other
stuff that we might be considering yet?" but other part thinks that if
Mallard's goal is to make authoring simpler (more simple?) . . .  such a
change would be good.

Jim
_______________________________________________
gnome-doc-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-doc-list

Reply via email to