Archive for the 'Web' Category

Previous Page Next Page
December 1st, 2010
11:26 am
List of useful Bookmarklets

Posted under HTML
Tags , , ,

This page here contains a number of useful commonly used bookmarklets.

Just drag them and drop them on your favourites bar to make them easily accessible.

My favourites are the following browser window resizing bookmarklets – useful for web development testing.

Note – These Bookmarklets use the JavaScript Window.resizeTo() method which is not supported in Opera and Chrome.
Also, IE8 only supports these when a single tab is open. Use F12 in IE to do this if you have multiple tabs open.
Firefox has the best overall support for them as they will still work with multiple tabs open.

Resize to 240×320 (pocketPC)

Resize to 544×372 (webTV)

Resize to 640×480

Resize to 800×600

Resize to 1024×768

Resize to 1280×1024

No Comments »

November 23rd, 2010
11:38 am
Using floats to place a border around a control group/toolbar

Posted under CSS
Tags , , , , , , ,

I originally used display:inline-block, line-height and vertical-align:middle to do this as detailed here, but the results were inconsistent across browsers.

Using floats is a much better solution for a number of reasons – details are as follows:- 

  • The controls are floated left inside a div which is itself floated left. As the div is floating, it auto resizes to fit around the content, and so scales to fit unknown control sizes.
  • The controls are all set to have fixed top and bottom margins (4px in the example), and the leftmost and rightmost also have similar left and right margins respectively.
  • The floated div is set to have the desired border and background etc. – in my case, I use Primefaces/jQuery UI theme style classes to apply theme look and feel.
  • The floated div is then placed inside another outer div, which may be of fixed dimensions. This allows the control group to adjust in size, but to be located inside a fixed area on a page.
  • If the outer div is of fixed size and non floating, the floating inside it is invisible to the rest of the document, so it is not necessary for example to clear the float.
  • If desired, the outer div can be set to overflow:auto to allow scroll bars if the size of the inner floating div exceeds the space allocated for it on the page.
  • If the area surrounding the control group is also floating, the outer div can also be set to float with no size specified, so the concept works well in both floating and fixed size situations.
  • display:inline-block and vertical-align:middle are not used with this method.

 This mechanism has the following characteristics:-

  • The control group bordering works nicely and consistently with the Primefaces/jQuery theme styling, as rather than trying to centre the controls in a fixed border, instead we vary the border size and keep the margin between the controls and the border constant.
  • The approach makes use of the laws of Gestalt Psychology – the eye notices even small imperfections in the alignment of the controls and their relationship to the border because they are close and obviously grouped/related.
  • Conversely the position of the entire bordered control group within its surroundings (the outer div) will typically not be so critical – it will likely be in a larger area of white space between it and adjacent items,  and so its position and size within that space matters less than the control / border relationship.

A caveat to all this is that it is still not perfect – the simple example below does not perform quite as well in terms of cross browser alignment as the Primefaces/jQuery UI version, as the Primefaces themes apply their own styling as well which changes the situation. This could of course be improved by adjusting the margins individually for different controls in the group to get the best overall cross browser alignment. One very important goal I am trying to acheive is to avoid browser specific CSS. The Primefaces/jQuery UI CSS does in general have browser specific tweaks which will help it in certain situations.

Overall though this approach performs significantly better than the previous method using vertical-align:middle etc. and has the advantage of being fully floating/dynamically sizing if required. An example of this approach follows :-

<!DOCTYPE html>
<html>
<head>
 <style type=”text/css”>
  .ss-outerdiv {
   height: 40px;
   width: 200px;
   background-color: orange;
  } 
  .ss-controlgroup {
   float: left;
   background-color: green;
   border: 1px solid black;
  }
  .ss-select, .ss-leftbutton, .ss-rightbutton {
   margin-top: 4px;
   margin-bottom: 4px;
   float: left;
  }
  .ss-select {
   width: 120px;
     font-family: Arial,Verdana,sans-serif;
     font-size: 11px;    
   margin-left: 4px;
   margin-right: 4px;
  }
  .ss-leftbutton, .ss-rightbutton {
   height: 20px;
   width: 30px;
  }
  .ss-leftbutton  {margin-right: 2px;}
  .ss-rightbutton {margin-right: 4px;}
 </style>
</head>
<body>
<div class=”ss-outerdiv”>
 <div class=”ss-controlgroup”>
  <select class=”ss-select”>
  <option value=”Test”>Test Value</option>
  </select>
  <button class=”ss-leftbutton ss-button”></button>
  <button class=”ss-rightbutton ss-button”></button>
 </div>
</div>
</body>
</html>

No Comments »

November 11th, 2010
12:59 pm
Scrollable containers in Primefaces

Posted under CSS
Tags , , ,

Some Primefaces containers appear to support scrolling, but this is not universally supported. Layout panels support it, but ordinary panels appear not to.

Fortunately, with IE7 and above, scrolling on a <div> (JSF panelGroup with layout=”block”) works reliably and consistently across modern browsers, so scrolling can just be added within e.g. within a CSS class rule as follows:-

.ss-scroll {
   overflow:auto;
}

or:-

.ss-scroll {
   overflow: scroll;
}

Using overflow:auto will only add the scrollbars if they are needed, i.e. if content is clipped. Using overflow: scroll will add them all the time so you will get redundant scrollbars when the content does not clip.

Note that for Primefaces, to make a scrolling panel for example, the attribute needs to be added to a containing div inside the panel, and not the panel itself, otherwise the panel header will scroll out of view when the contents scroll which is undesirable.

The w3schools documentation on overflow will be found here.

No Comments »

November 11th, 2010
11:35 am
Fonts reduce in size when Primefaces table moved inside a panel

Posted under CSS
Tags , , , ,

Update 22/09/2011

The following selector (as documented below) did not work when used for a particular table. CSS ignored the rule presumably for reasons of specificity:-

.ss-nested-widget, .ss-nested-widget .ui-datatable {
     font-size: 100% !important;
}

However, the following selector did work (and was also modified to include a dialog as well as a table). This has the advantage of not relying on having ss-nested-widget as a class on the table in order to work.
This has now been adopted as standard as the solution for this issue :-

.ss-nested-widget,
.ui-widget .ui-datatable,
.ui-widget .ui-dialog { 
     font-size:100% !important;   
}

Original Post

This issue is due to font size inheritance.

My default font for all Primefaces components was specified globally as follows:-

.ui-widget {

font-size: 75% !important;

}

The reason for this is that in general it is considered more flexible to go for percentage sizes as these can then be scaled automatically when viewed on smaller devices.

Unfortunately, it appears that when for example a table is nested inside a panel, the font size appears to be 75% of 75% as the rule is inherited and applied twice, as 75% is a relative measurement, The table ends up rendered as a 9px font which is too small. The situation is further complicated by the fact that in the Primefaces skinning, there is a mixture of fonts specified in ems, percentages and pixel sizes, which means that not everything is specified in relative sizing anyway.

There are 2 solutions to the issue, both are straightforward, 1/ is the simplest although arguably not the best due to absolute sizing:-

1/ Change the global ui-widget rule above to use a fixed font size (12px works as a replacement for the above 75%)

.ui-widget {

font-size: 12px !important;

}

2/ Keep the  75%  for ui-widget and introduce a new rule to specify a 100% size for nested elements:-

.ss-nested-widget {

font-size:100% !important;

}

This rule needs to be introduced inside the panel. If it is placed on the panel itself, which is the parent element, then the font size just ‘goes large’ to 100%, i.e. larger than the desired default font. To obtain the correct behaviour, the sub-elements inside the panel must be tagged with the style class. It is possible to tag an enclosing <div> just inside the panel, so that the sub-elements inherit it. However, whilst this worked for input selectors and buttons in the panel, tables refused to play ball, and the following rule was needed to ensure that a table in the panel inherited the correct size:-

.ss-nested-widget, .ss-nested-widget .ui-datatable {

font-size: 100% !important;

}

The same kind of trick can be used to target other nested elements which do not inherit the correct size.

An alternative method would be just to add the class to sub-elements individually where required.

No Comments »

September 26th, 2010
11:28 am
Choosing a DOCTYPE for maximum browser compatibility and standards mode

Posted under HTML
Tags , , , , , , ,

This follows on from my previous post which highlighted an example of a valid DOCTYPE which still threw IE into Quirks mode.

The DOCTYPE issue has been something of a minefield – there are a number of different declarations and they are relatively complex, some have browser compatibility issues, and then of course different ones are needed for XHTML/facelets use.

It seems the holy grail of simplifying all of this is just to stick to the remarkably simple and highly compatible HTML5 DOCTYPE:-

<!DOCTYPE html>

  • This has the following highly desirable characteristics:-
  • It triggers standards mode for all known modern browsers
  • It is backwards compatible
  • It works with HTML pages and facelets/XHTML

See these posts here, here and here for more discussion on this.

It really does seem to solve all the DOCTYPE pain – I think I’ve died and gone to heaven!

No Comments »

September 18th, 2010
11:08 am
Using display:inline-block and vertical-align in CSS

Posted under CSS
Tags , , , , , ,

Update 23/11/2010

Having experimented with this extensively on different browsers, I have found inconsistent results across browsers when trying to vertically centre a group of controls in a bordered div which closely surrounds them. If you need just a few pixels between the controls and the border, vertical centering does not work in a consistent browser independent manner. For larger centring, e.g. for centring a paragraph of text in a large div, the differences may not be noticeable, but at small scale they definitely are. For placing a close border around a group of related controls, my preferred method is now to use floats as detailed here. Note that the fact that floats are used does not force the rest of the document to use floats or to have non fixed sizing – the floats can be invisible to the outside due to a second outer non floated fixed size div. Also, the floated version works better when the contained controls are of variable or unknown size.

Original post

I originally used this here in order to centre the text on a Primefaces button, the usage of inline-block was incorrect.

What it does not do is allow you for example to centre a <span> element vertically and/or horizontally in a parent div!

What it does do is to allow setting of the alignment of an inline element relative to adjacent inline elements on a line (not relative to the parent container). It will therefore work within a <td> but not within a <div>

There appear to be a lot of fuzzy and partly incorrect articles on the net about this, and it was hard to find clear definitions. even the W3schools site does not greatly help, and does not appear to list for each element whether it is an inline or block element by default, which seems quite an omission.

In the end I found some helpful posts on it here and here which cleared it up for me, and explained why my simple example of a <span> in a <div> would not centre vertically with inline-block and vertical-align:middle!

Note regarding the use of vertical-align, a typical gotcha on this is if you have a horizontal group of buttons/combos and attempt to use top/bottom margins to try to centre them vertically, you may wonder why you do not get the expected behaviour as the margins do not appear to be properly honoured. This is a classic case for using display:inline-block and vertical-align:middle on all the controls.
Primefaces note:- the Primefaces commandButton components are set to  display:inline-block by Primefaces, using the internal jQuery ui-button class.

No Comments »

June 9th, 2010
5:06 pm
Centre text and other items e.g. on a Primefaces command button

Posted under HTML
Tags , , , , ,

Update

This post originally used display:inline-block and vertical-align:middle thinking mistakenly that these were part of the fix for the problem.
See here for a more complete understanding of it.
The modified CSS below works fine just by removing the padding and setting the font.

Taking the Primefaces commandButton as an example, the label is embedded in a span:-

<button attr1=value attr2=value…>
<span>Submit</span
</button>

The button has many attributes which are not relevant to this discussion.
However, as the span is an inline element, it does not have a top/bottom margin, width or height and using text-align:center; in css has no effect.

The default Primefaces button has fixed padding for the label, which works fine by default but which is a pain when you change the size of either the button or the text.

The following rules remove the padding and set the desired font correctly to centre the text for the Primefaces commnadButton:-

.ss-textbutton {
height:20px;
width:52px;
}
.ss-textbutton > .ui-button-text {
font-size:90%;
font-weight: bold;
padding:0px;
}

This CSS is activated when the class ss-textbutton is passed to the styleClass attribute of the commandButton tag.
This example declares a 52 x 20 button. It then targets the <span> within the button using ss-textbutton > ui-button-text, as the <span> in the commandButton has the ui-button-text class. It does the following to the <span>:-

  • sets a font size and weight
  • removes all the padding, so that the centring works correctly

In this example, I have deliberately not changed all buttons globally. The Primefaces documentation explains how to use the classes  ui-button, ui-button-text and ui-button-text-only to skin all buttons globally if this is desired.

This now allows us to resize our button, change the font size and the text, and still have the label nicely centred. We don’t have to mess around with tweaking the padding and other attributes in every case, which is a whole lot simpler and more modular.

No Comments »

January 8th, 2010
9:19 am
Quirks mode & DOCTYPE switching issues with IE

Posted under HTML
Tags , , , ,

The perceived wisdom is that adding a valid DOCTYPE switches a browser from quirks mode into standards mode, but the truth is that it depends on the DOCTYPE and the browser, and also can depend on how the browser validates the page against that DOCTYPE – the browser can potentially change its mind part way through parsing a page.

I was coding an html page which had the following DOCTYPE (which was auto generated by Topstyle 4), and which still threw IE8 into quirks mode :-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

The following DOCTYPE corrected the problem and put IE8 into standards mode :-

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
 "http://www.w3.org/TR/html4/loose.dtd">

When using Facelets which is xhtml based, as detailed in this post here re ICEfaces, the actual DOCTYPE outputted by ICEfaces is as follows – this also works well when using standards mode with xhtml/facelets :-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

I found the following sites useful when looking for information on this:-

Note re the last link – a Bookmarklet is a link containing javascript which performs some action directly in the current page. I linked to the site article as a courtesy, and the site contains a number of other useful Bookmarklets. The actual bookmarklet (link) which will display the browser mode is here. Just copy and paste the link into your address bar.

No Comments »

January 7th, 2010
7:28 pm
Styling tables with CSS

Posted under CSS
Tags , , ,

Rather than use the border keyword in HTML, it is better to style tables in CSS as this localises all the styling in the style sheet and promotes automatic re-use across different tables.

This page from Somacon is an easy-to-use ‘what if’ tool for tweaking all the properties for tables and instantly seeing the effect.

The w3schools reference page for tables may be found here.

This page also from w3schools describes the use of the border-collapse property, which causes the border-spacing and empty-cells properties to be ignored, and for all borders to be collapsed to a single border. This is very useful when you want complete control yourself and to prevent some of these other properties getting in the way, for example when you want a minimal flat solid border.

Note that as is often the case, incorrect HTML can give rise to strange behaviour. For example if you mistakenly set colspan to greater than the number of columns (as I did when I subsequently deleted a column after creating a table and forgot to reduce colspan) you may get a partial double border effect on the right hand side.

Here is an example page with a table illustrating these points, together with all its CSS and HTML.

No Comments »

January 7th, 2010
5:45 pm
Using Fonts in CSS

Posted under CSS
Tags , ,

The following articles are helpful re correct choice of font, and how to size and use the various units correctly.
Issues such as providing sensible fallbacks in the font list to cater for different browsers are covered, together with the use of the various absolute and relative sizing units, and how fonts are inherited

http://www.w3schools.com/css/css_websafe_fonts.asp

http://www.w3schools.com/css/css_font.asp

Gernally accepted advice is as follows :-

  1. Define a default family in CSS for the body tag, consisting of a suitable fallback stack. Use a sans serif for screen use as it is more readable
  2. Define a default size using percent in the body tag, then use ems after that for relative sizing. This gets around some browser quirks with IE, and allows resizing by the user for all browser types.
  3. The default will be inherited throughout the document. However I have found issues when tweaking local CSS files during testing – sometimes old values ‘stick’ perhaps due to caching effects.
  4. There is an issue apparently with some older browsers that tables do not inherit a default body font. Therefore, the default should be specified for body, table as in the example below.
  5. Note that not all fonts in the stack (such as the basic fallback sans-serif) are necessarily scalable, so size changes may not appear to work if an inferior fallback font is picked up.

The following is an example stack in css :-

body, table {
    font-family: Arial, Helvetica, sans-serif;
    font-size: 100%;
    color: #000000;
}

No Comments »

Previous Page Next Page