Wish list: Improved CSS text support, navi bar & show/hide

summary:

Ideas for: (1) More user friendlier CSS text support (2) A revised placement for the breadcrumb navigation bar (3) An option to show/hide text

Wish list: Improved CSS text support, navi bar & show/hide

madhu_sharma 1162205926|%e %b %Y, %H:%M %Z|agohover

I really love Wikidot. Here is a wish list of things I would like to see:

1) More user friendlier CSS support for text based elements.

Currently, CSS styles for text can be added to the themes. The disadvantage of this is that a site may have several themes (e.g. to create a different identity for each section), but these might all share the same text styles. This is problematic if the user decided to change a particular text style, as s/he would have to update the CSS code in each of the themes.

Applying CSS styles to text in the page is also time consuming and complicated, as it requires the use of span and div tags, which can be confusing.

I propose the following system, which compromises of a five step process:

1. The user creates a CSS style sheet. It can either be hand coded or generated with one of the many available WYSIWYG CSS editors.
2. The sheet is uploaded in the site manager.
3. A new drop down menu appears in the page editor menu. The drop down menu lists all the styles that have been uploaded in the site manager.
4. The user highlights some text and then selects a text style from the drop down menu. Wikidot automatically attaches the relevant style sheet to the page and applies the style to the text by inserting the correct span/div tags with the appropriate code to reference the CSS text style.
5. If the user decides to change the style, s/he can re-upload the revised style sheet. This will automatically update the use of the style across the entire site without having to change the code on the individual themes.

I think this would be even better than a WYSIWYG system for text editing for two reasons. Firstly, the system of creating styles and then applying with a drop down menu is very similar as to how text formatting works in Microsoft Word, which should be familiar to people. Secondly, a WYSIWYG text editing system will inevitably embed formatting information in the document, which is less efficient than using a CSS style.

2) Revised placement of breadcrumb navigation bar

The breadcrumb navigation bar currently appears under the title headline. I think this is disorientating, as after reading the title, the reader of a page expects to see the first line of the content. I think there should be the option to place the breadcrumb bar above the title headline.

3) Show/hide text

The ability to show/hide text would be especially handy for bi-lingual pages, as the reader of a page can choose to hide text that isn’t in their language.

To author of a page can use the [sh:] [/sh] tags to mark the language of specific text. (Sh stands for show/hide.) After the colon of the first tag, the editor names the language of the text.

For example, if a page is in both French and Klingon, the user would use the tags [sh:French] [/sh] to mark French text and [sh:Klingon] [/sh] to mark Klingon text.

Wikidot would then automatically create a menu to which would give the reader of a page the option to “show/hide French text” and “show/hide Klingon text”. The reader can click these links to make the appropriate text appear and disappear.

By default the menu would appear directly underneath the top navigation bar, but it can be placed anywhere by inserting the [sh-menu] tag.

The site manager can be used to define the languages that can be used with the [sh:][/sh] tages. This would allow the editor to mark out text by selecting the language from a drop down menu as opposed to having to manually type the tag each time.

Re: Wish list: CSS, navi bar & show/hide

Goon 1162594221|%e %b %Y, %H:%M %Z|agohover

I second that, but maybe we should wait until the demo of the never seen new WYSIWYG editor. :-)

1. Somthing like part1 i had in mind as i was writing this post. If there was a .class-name attribute on each element (or at least for the custom elements [[span .class-name]] and [[div .class-name]]) it would produce cleaner page code because one would not have to duplicate local style definition within the page . For some complicated reasons i need this for anchors too.
   
   
2. i think one could solve this problem with a module [[module breadcrumps depth="3"]]
   
   
3. for the language switch i suggest a clean multi-language support for later. But the idea to toggle the visibility of blocks within a page is great. Maybe one could implement something like the toc-action-bar for divs in general.

---

If you want to move the breadcrumps above the title, add the following css code to your theme:

#page-title {
 
position:relative;
top:0.5em;
}
 
#breadcrumps {
 
position:relative;
top: -3em;
 
}

it is assumed that the title has the default font-size: 200%.

last edited on 1162598655|%e %b %Y, %H:%M %Z|agohover by Goon + show more

Re: Wish list: CSS, navi bar & show/hide

michal frackowiak 1162808683|%e %b %Y, %H:%M %Z|agohover

I have been quite busy recently but I have read all your suggestions and indeed they are great.

• custom classes will be incorporated into the WYSIWYG, but a bit later. this is a good thing. so users will be able do define custom classes and choose them later when editing pages.
• ok, I will move the breadcrumbs. please do not move it using the CSS because this might mess up.
• multilang - this would be great but this is a niche thing a bit… this would also complicate things with the internal processing of requests quite seriously… but I have been thinking about this so it is very likely it will be available!

thank you again!

---

Michał Frąckowiak @ Wikidot Inc.
Visit my blog at michalfrackowiak.com

Re: Wish list: CSS, navi bar & show/hide

pieterh 1162831321|%e %b %Y, %H:%M %Z|agohover

For multilanguage sites… here is a model that I think would work (at least for the sites I've seen):

- the site should define the languages it works with (presumably chosing from a fixed list)
- there should be the notion of "default language" and "current language"
- by default, all pages are shown are in the default language
- the language code is optionally embedded at the start of the url "/lang-xx/pagename"
- when wikidot sees such a text in the url, it automatically uses 'xx' as the current language for buttons, messages
- the navigation elements can also be translated by the site builder, e.g. /lang-xx/nav:side
- when a lang-xx page is missing, the engine will show the default page, and an option 'translate into XX'

This would not require major changes to the engine, since languages are just subdirectories of pages.

For translation of wikidot elements, you may want a simple UI that lets people make/submit translations.

---

Blog - Writings - Devil's Wiki - OpenAMQ - iMatix

Re: Wish list: CSS, navi bar & show/hide

madhu_sharma 1162920238|%e %b %Y, %H:%M %Z|agohover

michal frackowiak, thanks for considering my ideas. It is most appreciated. ^_^

pieterh, the model you suggested is good. However, even with this model, I think it would also be useful to have the ability to show/hide languages on a single page for two reasons.

Firstly, it allows the user to quickly compare the language variations of text. This can be useful if the user wants to identify errors in the translation of a text.

Secondly, the show/hide function doesn't have to be restricted to just languages. The show/hide tags could be applied to any text. This would be useful if the user wants to hide certain aspects of the text. For example, on a long article, a user new to the subject matter of the article could hide any detailed information on a page to make the article shorter (provided the detailed information was marked with the appropriate tag). A user who is more experienced in the subject matter of the article could chose to show the detailed information.

^_^

Re: Wish list: CSS, navi bar & show/hide

pieterh 1162986743|%e %b %Y, %H:%M %Z|agohover

Comparing two languages for translation is obviously a useful function. I'm not sure that putting multiple languages onto one page is the model that would work for me. My immediate questions are: what if the page gets large, and the number of languages increases to five, ten, twenty?

To compare translations, I'd probably just open two browser windows and flip between them, especially since complex pages have their own layout.

---

Blog - Writings - Devil's Wiki - OpenAMQ - iMatix