Responsive skin based on Foundation

Last modified by Thomas Mortagne on 2022/02/25 09:25


The objective of this project is to create a new XWiki skin for mobiles, tablets and desktops, based on the responsive foundation framework (







The idea of the present project is to create a skin for XWiki that is responsive to the sundry screen sizes used to access XWiki. Responsive Design is an emerging technique in web design that utilizes percentages and css3's media queries in order to scale the content depending on the size of the screen/viewport. These techniques allows the webpage to be viewed as optimally as possible in different screen scenarios. Though originally proposed to begin with the Foundation framework, it was later deemed to be more appropriate to work without the framework in order to remove dependency and give a more flexible and tailored solution. 

Timeline & Milestones

WeekDays        Description 
 121 May - 25 May        Design explorations: holistic view (UI wireframe)
 2[28 May - 1 JuneDesign explorations: common widgets/extensions (UI wireframe) (It seemed to be more useful to develop this after the hollistic design has been explored and implemented to be tailored to the final design) MILESTONE 1 -- Clear concept of what is to be coded/written 
 34 June - 8 June Raw Semantics that work cross platform
 411 June - 15 June Desktop implementation (holistic) (css & js) [opera, chrome, safari, ie]
 518 June - 22 June Desktop implementation (holistic) (css & js) [opera, chrome, safari, ie] (this weeks specifically watered down browser (eg. ie7, ie6?). begin perfecting fluidity of the responsive design (holistic) until tablet size/mobile size/device specific changes (eg. dropdown for mobile)
 625 June - 29 June perfecting fluidity of the responsive design (holistic) until tablet size/mobile size/device specific changes (eg. dropdown for mobile). clean up codes & optimize.  MILESTONE 2 -- Codes are written and ready to be implemented into XWiki  []
 7-82 July - 13 Julyimplementing into xwiki MILESTONE 3 -- Codes are implemented, and usable 
 9-1016 July - 27 JulyChoose priority of features to be worked on to be made responsive. Begin working on features that should be made responsive
 1123 July - 3 AugContinue working on features   MILESTONE 4 -- Chosen features are working and responsive
126 Aug- 10 Aug  Clean up code/optimize/bug fixes etc. 
 20 AugMILESTONE 5 -- Create distributable version


Milestone Description Link 
 1Clear concept of what is to be coded/written
 2Codes are written and ready to be implemented into XWiki 
 3Codes are implemented, and usablesource: 
 4Chosen features are working and responsive  search suggest, livetables, blog, color themes, print styling, ie compatibility
 5Distributable version created;


Time Description
 May 5 First design exploration. Not used since it was too close to colibri and offered no unique benefits beside resposive []
 May 12 Second design exploration. Not used. Still, to close too colibri. Mostly aesthetic revision rather than functional ones. []
 May 17 Third design exploration. Not used. Too much interactivity. Getting closer to the final design, as it introduces the main content area and hiding/consolidating parts of XWiki []
 May 23 Fourth design explorartion. Beginning of the final design style. With the help of the community, I went back to wire-framing completely and created the basis of the final design. With input and advices of current design trends, the skin was seperated into three parts--the breadcrumb (for location), a prominent content area, and the sidebar (holding everything else--eg. navigation/docextras) []
 Jun 10 A more visual and clearer illustration of the final design project []
 Jun 20 The codes to make the design work and feasible is for the most part coded and working. Prior to this, there were issues in implementing some of the features of the skin--mostly the sidebar. There is really no writings on how to implement a responsive sidebar. Sites like google/facebook etc. had their own different implementation--which was for the most part tailored to the way their sites work and used different techniques that does not necesarrily fit the bill for the present project. But after researching all the different methods, it worked out in the end, and I believe the sidebar is implemented as planned with little compromise.  []
 Jun 27 The codes are optimized cross browser/screensize/devices/capability (eg. js). []
 Jul 7 The codes are largely implemented and usable.  Still missing features to be implemented (eg. history in the sidebar has some bugs that prevents the doc from showing if turned on). It was a learning curve to learn how to skin for xwiki because of its enormous complexity and features. But after I got the hang of it, it went a little faster. I think there is still some issues with codes that could be simplified/cleaned up/standardized--which I hope to do in the future. []
 Jul 10 Implemented livetables. discovered bug with attachments resulting in missing buttons during edit? working on fix
Jul 13 Implemented history, improved livetables, fix attachments/other bugs. Created live instance:
 Jul 19 xwikimessage styling, better tablet support, mobile fix, livetable fix (tested on nex7, lg g2x, lumia710)
 Jul 20-24 Search bar fix, implemented ajax history and other comments from Jerome Velociter
 Jul 25-26 ajax search bar 
 aug 1-2 administrator styling, modal box styling, search suggeset fix
 aug 4 better sidebar degrade, panel wizard
 aug 5  blog styling, wysiwyg styling
 aug 7 xwiki color theme compatible, better responsiveness, fix sidebar issue when non existing doc, clean up js
 aug 8 improved sccrollbar, profile view, dl styling, content width, and removed "swipe hint"
 aug 10-11 added print styling and sidebar fixes. added some translation improvements
 Aug 16 CSS to xwiki standard, minor fixes, documentation (below)
 Aug 17 sidebar fix without js (better respond/compatibility in general)
 Aug 18 Test again on safari, opera, firefox (js/nojs) begin ie fixes
 Aug 20 ie 7,8,9 fixed, sidebar-handler changed to improve usability (only show relevant button)



First and foremost this skin is meant to be a responsive skin for xwiki. There are several reasons however behind this specific design.

  • The first is to unify xwiki by putting all sections in the same area. These two sections are the page content and the extras.

    • The page content is made front and center by using a different and stronger colored background highlighted by a bold thick border. Everything else is secondary to the page content. The breadcrumb is placed above this page content because not only is it a horizontal element, but it also provides context to what is below it (just like the tabs and address bar above it. 
    • The second main area, the sidebar combines everything else. Whether it is a tool that manipulates the main area, a way to view the main area, or additional info to the main areas, it is all in the sidebar. This allows the user to hopefully understand everything better since if they are only wanting to view, everything is right there, and if they want to do anything else, it's all in the same place.
  • The sidebar also follows a common trend in upcoming designs and ui interface. Many apps today utilize a hidden sidebar that appears when the user wants to see it by swiping or clicking a button. Eg. Facebook, youtube etc. mobile apps. Windows 8 also does this in which all the main area control is available by activating a sidebar on the right side of the screen.

    • The sidebar is always visible in a wide screen because there is a limit to how wide a text should be before it becomes inefficient. At the same time, because the screen real estate is not limited, and sidebar functions will be often used, there is no need to hide the sidebar.
    • However, when the screen width is reduced, the sidebar gets tucked away as, in small screen size, viewing mode is the primary importance.
  • The sidebar allows the viewer to view content and additional info simultaneously. For example, a viewer can view both a comment, and the content to which it is referring to at the same time.
  • One of the reasons the color and design cues are flat is in order to contrast the other xwiki default skin, giving them more option in their xwiki's style.


The stylesheet is divided into two section. Style.css & xwiki.css. Style.css is responsible for the basic function of the skin-mostly the sidebar and the dropdown UIs. Xwiki.css extends style.css and is called in the first line of style.css in order to make it look nicer (eg. Font properties, borders, padding, margin, backgrounds etc.) If you are wanting to make your own design, go ahead and remove this line.


  • #main-area - the content area (breadcrumb + page contents)
  • #xo-content - the page contents (the area with the thick solid border-top)
  • #sidebar - the sidebar area (navigation control, docextras, pageactions)
  • #sidebar-handle - the sidebar's handle that contains the link to accessing the menu or the content section (needed if no touch input is available))
  • <header> - xwiki title, search function and the #viewer [global.vm]
  • #viewer - user, login/log out, language

Responsive Design

The responsiveness comes from two parts: css3 media queries & jquery (endpage.vm). The latter only adds functionality and is not needed for the skin to be responsive. These improvements include

  • Resizable sidebar (If the user is wanting to see more docextras than the content
  • Creating a native drop down in small screen to make use of mobile UI's drop down screen for clarity
  • Make the sidebar content fixed so that the user can view whatever sidebar section they would like at whatever section the page content is at.


All mediaqueries are applied only on screen

If the screen width is between 1024px and 600px

It applies the same css as if the screen is below 600px IF the user can touch the screen (.touch through modernizr.js). This is to try and encapsulate many high resolution tablets that are still relatively small in physical screen size. The check whether the screen has touch is through modernizr.js which applies ".touch" property to the body if the screen has touch. Mediaquery at the moment does not support this check by itself. The use of JS here is ok, because if it is a tablet with high resolution, then JS is enabled.  (Note: Modernizr.js is also used to detect whether browser is rgba capable and thus allow the opacity based background)

If the screen width is <850px

  • The vertical menu in the admin is made full width, and the content of the admin placed below that.
  • The .xwikitabbar is transformed into a 2 column list

If the screen width is <600px

  • All .mobile is made display: block
  • #sidebar is made 100% width
  • #sidebar-handle is created and rotated
  • #change is made static so that the user can scroll through the sidebar normally
  • The breadcrumbs and viewer is given a black background and full width since horizontal space is lacking
  • .gadget-title is given an indicator as to whether it is toggled or not
  • Box-shadow is removed since it no longer fits the visual language
  • The admin profile is made so that its main content is made full width while its control is hinted and visible upon hover/touch.

    • This is because colibri utilizes a .js that defines the profile menu's sidebar to be a certain height such that the content can not be placed below the menu or else there will be a giant blank white psace

If the screen width is <300px

The .xwikitabbar is made into single column



The core responsiveness of the skin is based of resizeControl(). This resize control is called upon

  • Dom:loaded
  • Window resize

There are two pathways that resizeControl will execute. If the window width > 600px and it is not a touch screen, resizeControl will

  • Make the sidebar resizable and resize the skin accordingly
  • Put the header (global.vm) on the sidebar
  • Make the sidebar position: fixed with a scrolling area
  • Make the navigation control display based on scroll position of #change.

If not, it will

  • Make both the main aread and sidebar 95%
  • Move the sidebar off the screen
  • Make sidebar position: static
  • Create the drop down menu to replace links in order to improve usability (createDrop())
  • Make the sidebar handle that allows the user to access the menu/sidebar if they are not on a touchscreen
  • Allows user to minimize gadgets in order to increase viewing space


This functions creates the dropdown menu to improve usability in small screen by creating a native dropdown function. It is based off It's called by resizeControl() if the window width is less than <600px


Refer to the searchsuggest section of this doc.


Based in sidebar.vm and called by startpage.vm, the sidebar includes

  • Leftpanels.vm
  • Rightpanels.vm
  • Editpanels.vm
  • Editmenu.vm
  • Docextra.vm

Sidebar.vm's structure:

    1. Setting up which docextras to be called
    2. Displaying the control icons which has the notification number
    3. Displaying the control link
    4. Displaying #change which is the scrollable part of the sidebar that contains the data

      • Note: the editpanels.vm is only called if the current $xcontext.action ==edit and the editor != inline

Dom structure:

<section id=" NAME OF SECTION -wrapper">

            <h2>NAME OF SECTION</h2>

            <div id=" NAME OF SECTION "> (where the anchor from the sidebar-control-[icons/links] to

                  <h3 class="sub-menu">SUBSECTION</h3>



Special case:

This can be used if the user is wanting a white background to make that specific section stick out. It is used within  <div id=" NAME OF SECTION ">

      <div id="information">     


Doc Extra: History

The history section of the sidebar is unique. It is shown by clicking a link in the history section, which calls a modal box. This is because the history section is a mostly horizontal element and thus requires a width unavailable in the sidebar.

Checking the docextra.vm (which is called by sidebar.vm), we can see a specifically defined history section. This is called if the docextra name is History, else it will call a generic do.


<a id="${docextra.get(0)}link" href="$doc.getURL('view', "viewer=${docextra.get(1)}")"> [...] </a>

Creates the link that goes to the history page if js is not available


The <script> that follows that creates the function that allows for the modal box.

  • The first part allows the user to leave the modal box by clicking outside the history area (in the black lower opacity section), if the user presses esc, and if the user clicks the "close" button.
  • The second replaces the aforementioned link with a link to #History (Note: #History represents the fact that the historyinline.vm is called. #history represents the history section of the sidebar) and calls historyinline.vm and makes it visible by toggling "#historycontent-wrapper-helper". It replaces the #History link such that if the user c&p the page or refreshes the page, it will again pull the history modal.
  • The final part of the script calls the history modal if #History is present in the link.


Checking the historyinline.vm we can see that there is a <script> at the end of the file. This allows the history section to respond just like a livetable would. It uses its own since it does not use a livetable macro and it would not be efficient to always pull the script if a livetable or the history is not present. The way this script works will be covered in another section.

JS improvements:

"$j("#change").scroll(function(){" in endpage.vm, called within resizeControl() identifies the current section the #change is in so that the #sidebar-control-links can display the header of the appropriate one. It works by checking the current top position (how much of the div is above the current viewable area) of #change is less than or equal to the top of the section. If it is, then we are in that section, in which case we add an active-control, to bring it to the top of sidebar-control-links. active-control gives it a position: absolute thus allowing the other nav links to rearrange it self while allowing the current active-control to go above the <ul> containing the rest of the links, into the small window that is visible to the viewer without a mouseover. (Note: this visible area is where "<h2 style="visibility: hidden">x</h2>" in sidebar.vm is. This is a placeholder for where the active-control is placed).


The way livetables are made to respond is through a slightly modified version of filament tables (

The modification is very little, but it prevents the display of all columns. If the user is viewing the history modal while in document index, the originally script would display a toggle for all columns in both the document index and the history table. However, by using "hdrCols" instead of "$( "thead th" )" on line 165 of historyinline.vm, the script only displays the toggle for each specific tables.

Search Suggest

In order to make the searchsuggest result responsive, the fixed property can not be used. Style.css removes this property. However, because position: fixed is used in colibri, it is irrelevant where the result is injected in the DOM, and thus is added to the bottom. Because position: fixed is removed, the search suggest must be placed somewhere visible on the page (above #xo-content). "$j('.globalsearch').keyup( " in the jquery in endpage.vm moves the searchsuggest results appropriately.

JS Usage

  • respond.min = allows media queries for non ie compatible browser
  • jquery = bread and butter of sidebar, live tables, and other core features
  • jquery ui = resizable sidebar
  • modernizr = detect rgba and js for color and js improvements

Test Platform

  • Chrome
  • Firefox
  • Opera
  • Safari
  • IE 7,8,9


  • LG g2x (android phone)
  • Nexus7 (android tablet)
  • Nokia 710 (WP)
  • Blackberry Curve (bb)

Get Connected