|
|
plugin output stylingThere often appear special 'pieces' within a rendered page that ewiki returns, because not everything in the returned html code belongs to the requested pages` content. For example the current pages` title needs its own css class, like does the block of action links ("EditThisPage, PageInfo+, ...") below every page, so it can be distinguished from the pages` text. Also note again the use of the '.wiki' selector within the following stylesheet guide and ewiki CSS class overview: .wiki h2.page.title { // all titles now have it, while many ... // of them include links as well } .wiki.view .action-links { // "EditThisPage, PageInfo+, ..." links ... // are inside such a block, like are two } // <hr>'s .wiki.info .chunked-result { // some generated pages (like the history ... // info/ ones) may need to split their } // results; this matches those links //-- the edit/ pages are separated into // following blocks: .wiki.edit .edit-box { ... } .wiki.edit .image-upload { ... } .wiki.edit .preview { ... } //-- info/ pages contain a history of page versions, each enclosed in // a <table class="version-info">, the <tr>s inside can be selected // separately: .wiki.info table.version-info { ... } .wiki.info .version-info .action-links { ... } .wiki.info .version-info .page-author { ... } .wiki.info .page-refs { ... } .wiki.info .page-flags { ... } The class naming across most of the extension plugins is not unified, so you may often need to look it up here - or inside of the plugins source code. This is at least necessary for calendar and navbar, which follow a very different naming scheme. .wiki .download-entry { ... } .wiki .download-form { ... } .wiki .upload-form { ... } .wiki .image-append { ... } -------------------------------------------------------------------- 5 --prev << "user style classes in pages" next >> "Explanations" You cannot modify the README file, but anyhow any ideas or suggestion should as usually get filed on BugReports, UserSuggestions or even better the README.Discussion. |