On 04/15/2011 02:57 PM, Tyrin Avery wrote: > So you think that something supported by the schema and by every known > desktop publishing system is not desirable? Hmmmm ;) > Let me explain why I think it is. Lists generally do not stand on their own, > they are related to some introductory text that explains the point of the > list, i.e. they are part of a paragraph. Even if the text is just an > introductory statement saying "Here's a list of x:". If you insert the ul or > ol outside of the paragraph you get extra space between the introductory > statement(s) and the list, so it doesn't look right.
I wouldn't do that in my own documents, but if it works for you, why not. > Aside from which, shouldn't you be able to split text into multiple li > elements? Check any publishing system you like - they let you do this. It's > standard functionality. > So I'd encourage you to reconsider. Sure. In the macro below, please replace: parameter="ancestorOrSelf[implicitElement] p" by: parameter="ancestorOrSelf[implicitElement] li p" (You may want to add before p other elements similar to li, that is, sli, step, substep, etc.) After using this enhanced macro for a little while, it would be nice if you could tell us if you have seen any drawback. > Ask other users what they'd like to see.. I think you'll find they'd also > like to be able to create multiple li elements. For now, it's always possible to press Ctrl-Enter to create multiple list items. > I do appreciate the direction on changing the macro. I'm going to see what I > can do. > > Tyrin > > > -----Original Message----- > From: Hussein Shafie [mailto:[email protected]] > Sent: Friday, April 15, 2011 5:01 AM > To: Tyrin Avery > Cc: [email protected] > Subject: Re: [XXE] next item after li is ul > > Tyrin Avery wrote: >> I use the DITA add on. If I'm in a list and I press enter in the middle of >> an li, it doesn't just create another li, it creates a new ul/li. This is >> not desirable. > > Sure. What you report *would* clearly be a bug. However I didn't manage > to reproduce it by using XXE ``normally''. > > When I press Enter in the middle of an li, it does nothing at all. > > Excerpts of XXE_install_dir/addon/config/topic.xxe: > --- > <binding> > <keyPressed code="ENTER" /> > <command name="dita.splitOrInsertNewLine" /> > </binding> > > <command name="dita.splitOrInsertNewLine"> > <macro> > <choice> > <command name="insertControlChar" parameter="\n" /> > > <sequence> > <command name="selectNode" > parameter="ancestorOrSelf[implicitElement] p" /> > <command name="split" /> > </sequence> > </choice> > </macro> > </command> > --- > > The above binding basically means that Enter splits the p ancestor of > the element containing the caret. > > The ill behavior you describe may be explained if you tend to insert ul > elements *inside* p elements (because you tend to use "Edit|Insert" > instead of using "Edit|Insert After"). > > Inserting ul elements inside p elements is a very bad idea[*] and should > not be allowed by the DITA DTD or schema. We didn't design our DITA > topic configuration with this feature in mind[**], therefore we do not > intend to fix the ill behavior you describe. > > > > --- > [*] This simply does not make sense: a paragraph should not contain > lists or tables, otherwise why call it a paragraph? Please use a section > without a title if you want the equivalent of a division. > > [**] For example, the "Add ul" button found in the DITA topic toolbar > would never insert the ul inside a p, even if this is valid. It inserts > the ul after the p. > > > >> Is there any way I can edit the .imp or .css files to allow me to have it >> create another li instead. >> > > The ill behavior you describe is not related to .imp or .css files, it > is related to the above binding. > > If you really want to insert ul elements inside p elements, then you'll > have to change the above dita.splitOrInsertNewLine macro by making it > slightly smarter. > This e-mail message and all attachments transmitted with it may contain > privileged and/or confidential information intended solely for the use of the > addressee(s). If the reader of this message is not the intended recipient, > you are hereby notified that any reading, dissemination, distribution, > copying, forwarding or other use of this message or its attachments is > strictly prohibited. If you have received this message in error, please > notify the sender immediately and delete this message, all attachments and > all copies and backups thereof. > > > -- > XMLmind XML Editor Support List > [email protected] > http://www.xmlmind.com/mailman/listinfo/xmleditor-support > > -- XMLmind XML Editor Support List [email protected] http://www.xmlmind.com/mailman/listinfo/xmleditor-support
