We have an application which uses Bootstrap badges to display pertinent field based information in a search result display. We were looking at it and it just doesn’t seem to stand out as we had expected.
Adding the following simple CSS makes all the difference. The extra contrast between the white space and the gray background just needed a “pop”
.badge {
border: 1px solid lightgray;
border-radius: 5px;
}
This is a really simple observation, but relevant to the side project I have started to work on for my wife (more to come later)
If we create a simple Bootstrap button
<button type="button" class="btn btn-default">Single toggle</button>
It looks something like this in firebug
Looking at the .btn style on the right we can see border-radius: 4px
Messing with this value can create a much more rounded button – if that is your desire
This is border-radius: 20px – Cool 🙂
When building a mobile interface with bootstrap, one design option is to use placeholders to signify the field label.
This approach has many critics who questions the page accessibility, the fact that when you click into the field and start typing you lose the context, and so on. It is however an approach which is frequently used. In this article I wanted to show how I made the PSC contest submission form go from “Labels” to “placeholders” using media queries.
Labels
Looking at the form normally we see labels and fields
If we have Labels and placeholders together at the same time, the effect is not really all that pleasing to the eye
As the screen size is reduced the bootstrap styling kicks in around the Galaxy Note 4 size
But when we get to the phone size screen the labels are removed and the the placeholders are made visible.
If you go the https://contest.psclistens.com site you can play with it yourself by resizing the page
How does that work then?
The labels are easy – they are hidden with a media query
@media screen and (max-width: 460px), screen and (max-device-width: 460px){
label:not(.projectSponsor) {
display: none !important;
}
}
The placeholders are not so easy though. The first problem is that the “placeholder” attribute does not have a CSS value to “display:none”. The second is that they are as yet not governed by a non-vendor prefixed style. Although you cannot hide the placeholders you can color them.
The code below is a media query which basically says that when the screen is above 768 pixels then the placeholders get a style color of white. I had to !important then to get it to override bootstrap properly. When the screen gets smaller the white override is lost and the bootstrap grey is seen.
@media (min-width: 768px) {
.form-control::-moz-placeholder {
color: white !important;
opacity: 1;
}
.form-control::-moz-placeholder {
color: white !important;
opacity: 1;
}
*::-moz-placeholder {
color: white !important;
}
.::-webkit-input-placeholder {
color: white !important;
opacity: 1;
}
::-webkit-input-placeholder {
color: white !important;
opacity: 1;
}
*::-webkit-input-placeholder {
color: white !important;
}
}
So the labels are hidden at 460 but the placeholder is displayed at 768 – so yes if you watch carefully as the screen is reduced you will see a screen size between the iPad and the phone where both are visible. This was done for effect so that you can see it happen.
Conclusion
Without going into the merits of whether or not this is an appropriate design method for displaying information to users, this served as a nice example of what is possible. This was all done within the context of an XPage.
Check it out – https://contest.psclistens.com
In this article I will demonstrate a method for hiding columns using CSS and making an XPages view Panel pseudo-responsive.
What is Responsive Design?
Introduction
XPages view panels out of the box are not “responsive”, in that they make no attempt to, and do not work well on a mobile device.
One solution demonstrated by Stewart Curry is to hide columns as the width of the browser decreases. Hiding the least significant, down to the most when the view space is smallest. This makes sense because you would not want to display 9 columns worth of data on a mobile device anyway.
Using the following CSS I was easily able to make an XPages view panel “work” at different resolutions by reducing the number of displayed columns. (IE9 and above http://caniuse.com/#search=nth-child)
<style>
.xspDataTable {width: 75%}
@media only screen and (max-width: 1000px) {
.xspDataTable tr td:nth-child(2), .xspDataTable tr th:nth-child(2) { display:none; visibility:hidden; }
}
@media only screen and (max-width: 768px) {
.xspDataTable tr td:nth-child(3), .xspDataTable tr th:nth-child(3) { display:none; visibility:hidden; }
}
@media only screen and (max-width: 480px) {
.xspDataTable tr td:nth-child(1), .xspDataTable tr th:nth-child(1) { display:none; visibility:hidden; }
}
</style>
How does it work?
The CSS media queries (IE9 and above) determine the CSS displayed depending on the width of the page (1000px, 768px and 480px in this case). At each stage I remove one column until I am left with just the detail as you can see below.
At > 768px
At > 480px
and below 480px
Conclusion
This is not the only “method” for trying to achieve responsiveness out of tables, but definitely my favorite 🙂
I learned this recently when trying to load a conditional stylesheet into an XPage. IE9 worked but IE11 failed on me and I couldn’t see why. It was only a small change so I ended up putting it in the main stylesheet as a media query.
Apparently IE10 and above does not understand conditional HTML code like this
<!--[if IE]>
This content is ignored in IE10 and other browsers.
In older versions of IE it renders as part of the page.
<![endif]-->
http://msdn.microsoft.com/en-us/library/ie/hh801214(v=vs.85).aspx
So to load a style conditionally in IE11 you can do it like this
@media screen and (-ms-high-contrast: active), (-ms-high-contrast: none) {
Add your IE10+ specific styles here
}
thanks to http://www.adaodesign.com/css-styles-for-ie10-and-ie11-only
I am currently working on a customer application which is oneuiv2.1 themed and I wanted to create a simple jQuery Mobile site. the dojo css was really messing up the styling and just for interest I wanted to see if I could programmatically remove the dojo css from the page client side
The application has the property checked to use runtime optimized JavaScript and CSS. This combines all the dojo css files nicely into one link.
Using a jQuery selector I can get a handle on that <LINK> as follows
$('link[href*="dojo.css"]') //select all LINK objects where the href contains dojo.css
Once I have that I can just remove the element from the DOM like this
$('link[href*="dojo.css"]').remove()
Unfortunately I cannot show you what this does my customer’s site to make it look all pretty and jQueryMobile like, but I can show you how it blows up a oneui site and you can take it from me this fixed my problem.
Just add the above code in a *SCRIPT* tag within your XPage and it will remove the dojo style before it is rendered to the end user – thus they will never know.
http://xpages.info/xpageshome.nsf/Demos.xsp
Before
After
Caveat
Yeah I realize this means the CSS file(s) are downloaded and then removed and I am sure there are more elegant ways to handle the issue server-side.
This was an exercise in learning that jQuery can be used to remove entire CSS DOM objects 🙂
This weekend I had one of those “oh DUH” moments which I have been struggling with for quite some time. How can I better structure my jQuery selectors and make the code more maintainable? I came across this excellent article – Decoupling your HTML CSS and JavaScript and it all came into focus.
The problem
Using JavaScript selectors (dojo or jQuery) in XPages can be a problem because of the id naming scheme used by the JSP generator “id=”view:_id1:_id2:link5” and how this falls over in a selector. So an alternate to not having to mess with is attributes is to use class selectors $(‘.class’) which is actually much simpler and less troubling to get your head around.
When you are using class selectors for a DOM element which already has a class then awesome I don’t have to add any more classes. Using this bootstrap example there are multiple classes I can get a hold of to manipulate the dialog contents.
<div class="modal fade myModal" id="myModal" tabindex="-1" role="dialog" aria-labelledby="myModalLabel" aria-hidden="true">
<div class="modal-dialog">
<div class="modal-content">
<div class="modal-header">
<button type="button" class="close modal-maxmin" aria-hidden="true">
<i class="icon-external-link"> </i>
</button>
<button type="button" data-dismiss="modal" class="close" aria-hidden="true">
<i class="icon-remove"> </i>
</button>
<h4 class="modal-title">modal-title</h4>
</div>
<div class="modal-body">
modal-body : HERE GOES THE MESSAGE
</div>
<div class="modal-footer">
<div class="btn-group">
<button type="button" class="btn btn-default modal-cancel" data-dismiss="modal">CANCEL</button>
<button type="button" class="btn btn-primary modal-ok">OK</button>
</div>
</div>
</div><!-- /.modal-content -->
</div><!-- /.modal-dialog -->
</div><!-- /.modal -->
To add something to the body of the dialog I would do something like this
$(".modal-body").html('Hi Marky')
The other problem
This example is very “coupled” code whereby my JavaScript selector is coupled to the real class file used by the HTML code. In reality what it means is that if I have to change the classname for some reason (hmm an example – oh I don’t know – going from Bootstrap2 to Bootstrap3 for example) then my JavaScript breaks down. While tightly coupled code is easy to follow, easy to create initially, it can be an absolute nightmare in the long run.
The epiphany moment
As I am reading Philip Walton’s article I am struck by the “oh well no duh” moment when he talks about using js-* as a naming convention for classes which only exist for JavaScript selection.
js-*. That way, when a developer sees such a class in the HTML source, she’ll know exactly where to look to discover its purpose.Well no duh – brilliant idea!
In all senses this makes perfect sense:
The new code
A very simple change to the modal-body but this then decouples my code form the bootstrap code – allowing me to make changes to the bootstrap classes int he future without breaking my JavaScript
<div class="modal fade myModal" id="myModal" tabindex="-1" role="dialog" aria-labelledby="myModalLabel" aria-hidden="true">
<div class="modal-dialog">
<div class="modal-content">
<div class="modal-header">
<button type="button" class="close modal-maxmin" aria-hidden="true">
<i class="icon-external-link"> </i>
</button>
<button type="button" data-dismiss="modal" class="close" aria-hidden="true">
<i class="icon-remove"> </i>
</button>
<h4 class="modal-title">modal-title</h4>
</div>
<div class="modal-body js-modal-body"> <!-- js-modal-body change here -->
modal-body : HERE GOES THE MESSAGE
</div>
<div class="modal-footer">
<div class="btn-group">
<button type="button" class="btn btn-default modal-cancel" data-dismiss="modal">CANCEL</button>
<button type="button" class="btn btn-primary modal-ok">OK</button>
</div>
</div>
</div><!-- /.modal-content -->
</div><!-- /.modal-dialog -->
</div><!-- /.modal -->
To add something to the body of the dialog I would now select the js-* class not the modal-body itself
$(".js-modal-body").html('Hi Marky')
Comment
One of the things I love about my career is that it is an “always learning” experience for me. There are times like this where you think to yourself that is an awesome idea and you are very happy to learn it – and at the same time feel so stupid that you didn’t think of it yourself before 🙂
In this article I will describe how to implement and use the Avgrund modal dialog which uses CSS transitions to give the effect of depth between the dialog and the page.
It is hard to believe that it has been two months since the last jQuery in XPages article – and for that I apologize. My current project requires most of my time to be away from the XPages DDE and as such the opportunity to find new and exciting plugins is decreased. But I came across this one today and figured I would take the time to write it up.
Demonstration
The XPages integration of avgrund.js is demonstrated here
Download
The demonstration database can be downloaded from the link above or from here
Introduction
Avgrund is a very simple 2k jQuery plugin which uses a CSS transition to shrink the visible page while displaying a modal dialog to the user. This gives the perception of depth between the page and dialog and a neat visual transition between the two. The plugin also uses IE alpha filters to fail back for IE<10 browsers which do not have CSS transition support (nice touch).
How does it work
We add the jQuery library and the avgrund.js library file to the database by adding them to the Web-Contents folder accessible via the package explorer. (Window–>Show Eclipse Views–>Package Explorer) and drag and drop the two libraries from your computer into the “js” folder.
We add the libraries to our XPages like this in the source panel – the avgrund.js also comes with two sample CSS files for the demonstration.
<script type="text/javascript" src="/xomino/jQinX.nsf/jquery-1.7.1.min.js"></script> <link rel="stylesheet" href="avgrund/style/style.css"></link> <link rel="stylesheet" href="avgrund/style/avgrund.css"></link> <script src="avgrund/js/jquery.avgrund.js"></script>
The plugin itself is very simple to instantiate and use, and the properties are self explanatory and well explained in the demo file:
$('element').avgrund({
width: 380, // max is 640px
height: 280, // max is 350px
showClose: false, // switch to 'true' for enabling close button
showCloseText: '', // type your text for close button
holderClass: '', // lets you name custom class for popin holder..
overlayClass: '', // ..and overlay block
enableStackAnimation: false, // another animation type
onBlurContainer: '', // enables blur filter for specified block
template: 'Your content goes here..'
});
The CSS transition is contained within the avgrund.css file and amongst other things scales the page to 0.9 of it’s size when active. A blur effect is also applied for greater visual effect.
body.avgrund-active {
-webkit-transform: scale(0.9);
-moz-transform: scale(0.9);
-ms-transform: scale(0.9);
-o-transform: scale(0.9);
transform: scale(0.9);
/* overflow: hidden; TIP: disables scrolling for long documents */
}
.avgrund-active .avgrund-blur {
-webkit-filter: blur(1px);
-moz-filter: blur(1px);
-ms-filter: blur(1px);
-o-filter: blur(1px);
filter: blur(1px);
}
In this case the element in question is the Show button.
Demonstration
The XPages integration of avgrund.js is demonstrated here
In this article I will show how your ExtLib Application Layout Control action buttons (OneUI) can remain on the page at all times with a simple CSS Trick.
The following was created using the Extension Library Application Layout control – with OneUI v2.1 using the silver theme.
Introduction
OneUI is a great, simple layout for a nice clean application layout without too much worry about CSS and other complicated design things. There are some nice examples on the OpenNTF site about using the OneUI layout. The http://xpages.info/XPagesHome.nsf/Home.xsp website uses the same layout and you can see for yourself how the top bars scroll out of the screen as you move down the page.
The buttons in the PlaceBar stay put as the page scrolls down – as the page gets larger this becomes more of a pain for the user to have to scroll back to the top to get to the Save button.
The desired effect
My requirement in modernizing my current R5 web based application was to keep the look and feel as close to the original frameset as possible. The buttons were in the top frame and therefore visible on the page at all times. Without wanting to revert back 15 years and use frames in the XPage I had to come up with a way to keep the buttons on the page at all times.
The initial look
The initial buttons look like this in the placebar – nothing spectacular to see here
Using what else – FireBug
So I had to figure out first of all what the CSS was for the buttons and then if I could change them. Looking at the HTML in FireBug you can see that the buttons are in a DIV with two classes: .lotusPlaceBar and .lotusBtnContainer
Fixing the position
Fixing the position of the buttons is as simple as using “position: fixed” and then they stay in that place on the screen. I added some other styling to pad it a little, and move at away from the side of the screen like this
This is achieved by adding the following style to the XPage
.lotusPlaceBar .lotusBtnContainer {
background: url("/xsp/.ibmxspres/dojoroot-1.6.1/dijit/themes/claro/images/titlebar.png") repeat scroll 0 0 #EEEEEE;
border: 1px solid #CCCCCC;
float: right;
padding-bottom: 0.3em;
padding-right: 0.3em;
padding-top: 0.3em;
position: fixed;
right: 20px;
z-index: 99999;
}
There we have it – fixed buttons on the page
As you can see from the picture below – the buttons stay in exactly the same place on the screen as the user scrolls down the page
All the way to the bottom of the screen
Xomino 