homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Subscribe to WebmasterWorld

Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderators: DrDoc

CSS Forum

hasLayout - Microsoft's own CSS logic?
One year on, an overview of sorts

 2:49 pm on Jul 19, 2005 (gmt 0)

A year ago DrDoc proposed an interesting theory [webmasterworld.com], and asked:
"Is it true that IE has all these bugs (more seem to pop up every day), or are they all simply variations on the same theme? Maybe there's simply just one or two bugs, not tens or hundreds

What came out of that discussion led us to Microsoft's site and their proprietary hasLayout property [msdn.microsoft.com] and it seemed pretty conclusive at the end of that thread that, yes, whatever this property actually is, it is indeed the cause of 99% of the more common IE rendering bugs/errors (disappearing, shifting elements).

But what is hasLayout
Well a year later, that is still the question I would likely clearly answered!
There is now finally some interesting discussions starting to appear out there. So I would like to summarize bits I've collected in my own research and some bits from the little that's been written so far and would welcome additional thoughts and ideas.

With IE's new release coming up it could become important to know this property, they could e.g. base any "new improved" CSS support on modifying this property somehow, which could mean we need to understand it order to support backwards compatibility or even learn how it works/causes effects so we can fix the next set of problems, who knows. The first time we spoke about this, a year ago, I said: ".. haslayout and zoom.. I think they will be one of those never to be forgotten things.." I haven't forgotten ;)

From Microsoft's own site

hasLayout Property:
Retrieves a value that indicates whether the object has layout.

the hasLayout property is Boolean
it receives one of the following values.
false :
Default. Object does not have layout.
true : Object has layout

Unsubstantiated Note though see example below ***: this property is set to False by default, and once it is set to true, either by element type* or a specific CSS property**, it cannot be "reset" to false

**CSS property values which set hasLayout to true

  • display :: inline-block
  • height :: any value
  • float :: left or right
  • position :: absolute
  • width :: any value
  • writing-mode :: tb-rl
  • zoom :: any value

Note: zoom [msdn.microsoft.com] is a microsoft properietary property so will not validate, but it can be useful as a debug tool and can be used to help IE5.5+ if validation is not an issue. See this thread [webmasterworld.com] for some more on zoom.

*Elements which have hasLayout set to true by default

Here there is some differing lists (even on MS's own site!)

Microsoft list the following elements as always having layout on the page regarding hasLayout:

  • <body>
  • <img>
  • <input>
  • <table>
  • <td>

but in the course of travels around their site I find there are more:

  • <iframe>
  • <hr>
  • <marquee>

Dean Edwards also comments on another blog and in difference to what Microsoft says:
"Incidentally, an element immediately acquires "layout" when you set the contentEditable property. Even if you set it to false."

Whereas Microsoft says:
Setting the contentEditable [msdn.microsoft.com] property to true will cause an element to have layout

Now I don't know who's right having not tested that one, but I'll leave it in as an instance of why it's so hard to reliably document this whole layout thing ;)

What does hasLayout actually mean?
The terminology is slightly confusing perhaps, usually when we (CSS'ers) are speaking about layout we are talking about a whole page! But what this property actually does is determine (to the IE rendering Engine) whether a singular element is having or has layout. Then it detects a layout element as one deemed to have layout by default or that it is so because it gained it the setting of one of the CSS property values above.

OK, so why does that affect our CSS displays so much?
The way the CSS displays (or the visual formatting model) has been "tacked" onto IE's aging rendering engine and they had to make it fit ;) ~ (OT: worrying thought time: could it now be, with the impending IE7 beta release, that they're only going to do more of the same?)

The hasLayout property was only introduced in IE5.5, before that IE classified some CSS properties as "layout properties" [msdn.microsoft.com], they still do actually but, these properties are not the same thing as properties which set hasLayout to true

Previously in IE4 most every element was deemed to have layout, with the exception being inline elements in their simplest form, i.e. not absolutely positoned and not given a width or height (remember you used to be able to dimension inline elements, only IE6 CSS enhancements [msdn.microsoft.com] correctly stopped that behaviour introducing display: inline-block as the alternative.)

These simple non-laid out elements were then the ones which would not support IE's own layout properties (specifically, margin, padding and border), which I presume is where the original term came from.
reference table [msdn.microsoft.com]

Moving forward to IE5.5.. and from their page: The MSHTML Editing Platform in Internet Explorer 5.5 [msdn.microsoft.com]

Every control, iframe, image, marquee, horizontal line, and table has its own layout. Internally, having layout means that an element is responsible for drawing its own content. In future versions, it may be possible to have non-rectangular layout elements, but in Internet Explorer 5.5, having layout basically means an element is rectangular. If a layout element has contents, the layout of its contents is determined by its bounding rectangle. (You can actually cause any element to have layout simply by specifying a width or height on it, positioning it, or making it contentEditable.)

Note: My Bold.

So if I read that right:
"Having Layout basically means an element is rectangular" and that rectangle is "responsible for drawing it's own content" and the "layout of its contents is determined by it's bounding rectangle".

If so that suggests the paradox that is "auto-enclosing" behaviour. Where those rectangles will stretch to contain their content even incorrectly e.g. floats and veryveryverylongwordsandlinks?

Is it also conceivable that this is why they can't implement min-width and max-width

Also if then an internal element does not have layout which parent element takes responsibility for the rendering/drawing of content? Again I would suggest that this has not been clarified to the rendering engine which is why we then have:
disappearing content, where no parent element takes responsibility
shifting content: there's a struggle as to who takes responsibility and repainting errors occur especially after a background change on hover?

display: inline-block [w3.org]
Is an interesting property, and one which I think has again being used by IE because it suited their purpose. You'll remeber that this is one of the properties that sets haslayout to true.

In the IE6 CSS enhancements [msdn.microsoft.com] we are informed:
Width and Height of Inline Elements

Inline elements such as <span>, <b>, and <i> do not support width or height properties. If you want to set the width or height property of an inline element with standards-compliant mode switched on, you must set the display property of the element to inline-block.

This is just them tidying up the violation that inline elements cannot accept a width or height, but in return they are offering limited support of a CSS2.1 property (or are they)

According to the Definition of display: inline-block; [w3.org] this property should apply to all elements.

This value causes an element to generate a block box, which itself is flowed as a single inline box, similar to a replaced element. The inside of an inline-block is formatted as a block box, and the element itself is formatted as an inline replaced element.

When you try to use inline-block on a block level element in IE it doesn't appear to work, but I quite by accident found a way it could [webmasterworld.com]. Now I think that the solution is no more than using the hasLayout property against IE!

*** The solution involves two lines of code:

div {display: inline-block; width: 400px; background: #fcc;}
div {display: inline;}

the first rule on it's own will not make 2 x divs sit side by side like it should, it will give the divs the required width and color, but it does not reflow them inline like it should.

adding the second line of code makes it work, although at first glance then the second rule's display property should overrule the first by order of the cascade and therefore according to specs we shouldn't be able to set height or width.

However back to:
Note that this property is set to False by default, and once it is set to true, either by element type* or a specific CSS property**, it cannot be "reset" to false

That's what I think is happening, the first rule sets the hasLayout property to true, and even though the second one should reset it, it can't!

So I wonder how many other little anomalies we could workaround with CSS, if we ever get to grips with this.. lol then of course IE7 could change all this anyways, who knows

Absolutely none ;) except It seems clear that this "property" is the cause of a lot of IE's rendering difficulties and possibly that by continually trying to hack their own property in an attempt to make it fit they are causing even more paradoxes and it's likely not only us CSS'ers that will suffer.

There is likely still a lot to this little documented gem. hasLayout may never be fully understood, but for now I'm glad I'm aware of it and would welcome any further thoughts and information. just remember no personal site links please!


[update]: Microsoft on hasLayout [msdn.microsoft.com] ~ their own explanation[/url]

[edited by: SuzyUK at 7:52 am (utc) on Oct. 18, 2005]



 3:52 pm on Jul 19, 2005 (gmt 0)

Fascinating post, Suzy! I'm aware of some of the hacks such as using
_height:1%; (underscore hack) to trigger hasLayout, but do you think that those hacks (as well as the inline-block one) could be compromised with the upcoming IE7? It could lead to the breakage of some current designs.

I get the impression that understanding the implications of hasLayout is critical to understanding IE behaviour.


 5:05 pm on Jul 19, 2005 (gmt 0)

Thanks encyclo.. the subject has fascinated me for a while

>>the Hacks that are used to trigger hasLayout
I'm just not sure what will happen, there are loads of "what-ifs" out there but I'm still reading!

The underscore hack, and * html hacks could theoretically be compromised quite easily if they fix stylesheet parsing.

No matter which hack you use at present the solution (hasLayout trigger) of setting a small height, even 0 does actually, on the element is what needs watching.
Although hopefully it could continue to be used inside a version specific conditional comment, for backwards compatibility. I presume IE will have to continue to support CC's because they're theirs anyway.

But the worry is what happens if somehow IE actually manage to fix the "auto enclosing/stretching" behavior of height and width, but not the other rendering issues, this would mean we then have to find another way to trigger layout. (note: when I say fix, that's very tongue-in-cheek..) So I'm just very aware that the "dimensioning" solution itself may very well break, leaving us to find another method of fixing some of the usual display errors.

I hope designs will not "break", but I just can't see how they can properly fix their CSS support by hacking this property, maybe they're not going to do this, maybe they're planning something radically different (geez they may even introduce a new proprietary property!) which really might then include breaking designs.

I was wondering however if rather than waiting to see it might be safer to remove any existing layout hacks into a specific conditional comment in readiness?

I get the impression that understanding the implications of hasLayout is critical to understanding IE behaviour.

I agree, not that I want to become entrenched in IE's inner workings ;) but it's looking increasingly like this property has been the sole cause of thousands of CSS developer's headaches. So I'd say it is crucial to at least be aware of it so we can understand that it may have more implications.

btw: just to clarify.. I'm not advocating the use of display: inline-block; as a hack/trigger, indeed I haven't tested anything with it yet to see if it actually works on anything other than itself ;) I was just randomly connecting things..



 5:27 pm on Jul 19, 2005 (gmt 0)

Good post Suzy. I know this sounds crazy, but say IE7 fixes the way past versions of IE render CSS (I'm not holding my breath on that one). If we were using statements like...

<!--[if lt IE 7]>
<link rel="stylesheet" type="text/css" href="css/winIE.css" />

...wouldn't that avoid some of the design breaks? I guess that's only assuming that IE7 would fix everything. Yikes!

More likely than not MS would only fix enough things forcing us to go back and explain to our past clients why their site looks like a pile of cow patties.

I'm packing my suitcase and turning my phone off now...


 6:04 pm on Jul 19, 2005 (gmt 0)


"WaSP to Collaborate with Microsoft to Promote Web Standards"

[edited by: SuzyUK at 6:25 pm (utc) on July 19, 2005]


 6:58 pm on Jul 19, 2005 (gmt 0)

Suzy - have you read On Having Layout [satzansatz.de] by Ingo Chao on this subject that Dean Edwards recently linked to? It's still WIP but definitely provokes a lot of ideas.

[edited by: SuzyUK at 4:31 pm (utc) on April 9, 2007]
[edit reason] link updated [/edit]


 6:12 am on Jul 20, 2005 (gmt 0)

@Robin, yes thanks I have,

It's the first document I've read that is close to an attempt at tackling this subject and although it reaches no conclusions (bit like myself ;)), like you said it is still a Work in Progress so I am following it with interest.

@nigassma, LOL, but I hope it won't be that bad

btw.. did some more testing of the display: inline-block; "trigger", and can report it does indeed work on all the usual suspects
(I think if it ever needs come into use, which hopefully won't be the case, I'll call it the
Tripswitch Hack! ~ hehe)

You just need to declare display: inline-block; in the rule of the element that is affected (same place as where existing height hacks are now). Then make another, seperate, rule setting the display back to what it should be, either block or inline..



 8:51 am on Jul 20, 2005 (gmt 0)

Great post! I think Microsoft's intention with hasLayout was to provide sections of a page that would run independently, with a view to providing future web apps. But I'm just going by what I've read, and also some guess work. What I find bad is how Microsoft themselves must know exactly how their browser works
*, and could explain everything for us, but of course they won't. So everyone is trying to figure out how it works, often banging our heads against a brick wall. Thank God for people like Dean Edwards who have discovered so much about IE.

*Or do they? Perhaps the original programmers have moved on, leaving newer ones in the dark, unable to fix the code.


 1:14 pm on Jul 20, 2005 (gmt 0)

All the ins and outs of this are way beyond me, but I'm still following this with great interest. I remember from the thread a year ago (which I also followed) that triggering hasLayout seems to fix the vast majority of IE's bugs. However, there are two things that I've never quite understood:

A: How to trigger hasLayout effectively, and,
B: Does hasLayout need to be triggered for each problem element, or just once for the entire page?

The underscore hack, and * html hacks could theoretically be compromised quite easily if they fix stylesheet parsing.

That really scares me. If the bugs we use to fix other bugs are eliminated, but the bugs we've been using them to fix remain, what then? Hopefully you're on to a solution here, and if so, it couldn't come at a better time! ;)


 2:25 pm on Jul 20, 2005 (gmt 0)

Amazing post, Suzy. You've been writing about hasLayout for awhile now, but this is by far the most lucid and comprehensive of your threads on it. Zoe Gillenwater recently wrote: "IE's quirks can sometimes be figured out, but at other times must be accepted as mystery and hacked away through experimentation." While probably true, I think you're getting us one step closer to understanding hasLayout in IE.

I'm also glad to see that hasLayout is starting to get a little more noise. Between you, DrDoc and Big John at PIE, the fact that hasLayout is responsible for 95% of IE's display bugs has been known for awhile, but unlike lots of other important CSS facts, it's not really in the mainstream consciousness yet. Perhaps with interest peaking, MS will be more inclined to quit adding onto their broken engine and rebuild it without this confusing, proprietary mess.



 3:39 pm on Jul 20, 2005 (gmt 0)

Great post. If only M$ documented what they have done, at least we would know what their "standard" is. Instead we have to guess.

Seems clear to me that they don't exactly know how it works themselves.


 5:21 pm on Jul 20, 2005 (gmt 0)

If the bugs we use to fix other bugs are eliminated, but the bugs we've been using them to fix remain, what then?

This is the biggest problem brought about by IE7: Microsoft said for years that IE6 was the end of the line until Longhorn, so developers felt confident that their hacks would last the test of time. With IE7's release rapidly approaching, it is becomng urgent to get back to all those CSS designs which have been stable for a few years (I've got several untouched since 2002) and refactor the CSS.

My tactic on CSS-P sites is to check the stats and abandon IE5.x support completely unless absolutely required. So far, I've not seen the need. That means I can clear out all the box model hacks and such and concentrate on just IE6. After that, I've been moving all the IE6-specific code to a separate stylesheet brought in with a conditional comment. Once IE7 is out, I will add a separate stylesheet for that if necessary, otherwise it'll get the full CSS treatment currently sent to Gecko/Opera/KHTML.

However, this sucks on several levels: firstly, the idea of CSS and forward compatibility has proved to be rather illusory (perhaps due to inexperience?). Secondly, the idea of "one stylesheet for all" is now illusory too - we're back to the bad old days when we were writing different code for NN4/IE4. IE conditional comments function perfectly for what we want, but the whole idea was to avoid the need for such browser-specific code as user agents converged to a standards-based uniformity.


 6:26 pm on Jul 20, 2005 (gmt 0)

lol, there's probably a lot of truth in that g1smd!

I am getting the, feeling as with everything, MS (e.g., Word, Excel..) they've tried to use the ~ "you don't know anything so we need to help you do it better than you could" ~ attitude

hasLayout being their browsers (albeit hidden) "paperclip assistant" ;) And in order to implement the "paperclip" they had to dumb the whole process down. Leaving us only square blocks to work with. And square blocks that can't interact (floats?) at that!

Hester, that's a great summary and I like the thinking. I've been reading, and am starting to agree with something along these lines. The theory is that as soon as you give an element layout it becomes a "window" (like an application window as you mentioned) which is then capable of being completely responsible for it's own content, while creating a boundary around it keeping it seperate from everything else. If so this could explain where it falls down for us in that this doesn't work well in CSS with interactive elements, like floats and/or overflowing content as we've found out.

Why we have to use it however is because an element without layout frequently can't handle it's content very well in the last 3 x major releases and we can't not try to support them all.

(or can we.. shh - OT: Naughty thought time:)
<!--[if IE]>
<style type="text/css" media="screen">
* {display: none;}


A: How to trigger hasLayout effectively

1. Add a width or height to affected element :: this is the easiest way but sometimes not an option if percentage padding, borders etc being used, also if used it might involve further hacks for the Box Model!

2. Hack in a small height - 0 or 0.1% :: It will need to be in an IE/Win Only Hack or conditional , then IE will auto stretch (extend to fit) :: this is the favoured method at the minute - and can also be put in an IE Conditional Comment if you're worried about the parse error hacks.. But this method just might fall down if they somehow fix the "extend to fit" behaviour of elements - it may well be unlikely that they will fix this alone as this "extend to fit" behaviour is thought to be a byproduct of haslayout (Nice catch22 huh!)

3. Use {zoom: 1;} a Microsoft proprietary property - on the affected element :: no hacks required, but this only works in IE5.5+ so will be an issue for those who need to support IE5 also it will not validate unless hidden in an IE Conditional - I see this being a useful one in the near future if required as support for IE5 must surely be on the decline and conditional comments, because of the sheer amout of seperate IE CSS required , must be getting on to being the preferred method over hacks now?

4. Set the element to {position: absolute;} :: not even going to give that the time of day ;)

5. Or a new one I just found which also works (see msg#7) - set a tripswitch for IE :: no hacks required, will validate, but again doesn't work in IE5, so support is decider. Also they may well fix this as I only think I know why it works and because I can't reproduce the tripswitch behaviour with any other of the hasLayout properties so it could be a simple parse error!

all of the above will trigger hasLayout effectively at the minute, which one you use would come down to your choice or the job spec e.g. whether Valid CSS is required

B: Does hasLayout need to be triggered for each problem element, or just once for the entire page

It should just be applied to the affected element. You can apply it to the whole page, but this is not recommended (except I recommend it for debugging) as it would only be safe if you are not working with any internal floats (including floated or aligned images), it invokes the broken (IE5.5) float model and nothing will wrap where it's supposed to.. sheesh

Narrowing the affected element is sometimes the "crux" it's sometimes not the one you think it is, but it's parent/grandparent instead.. however I think (still in testing) that I have found a common denominator in all the bugs, which may or may not help.

Now has that made it clearer than Mud, or just murkier :)

Perhaps with interest peaking, MS will be more inclined to quit adding onto their broken engine and rebuild it without this confusing, proprietary mess.

If only I thought that were true, I personally think that IE7 is just a PR Exercise, stop gap if you like and that things may well get worse before they get better while they make a half-hearted attempt to sweet talk the masses, before they finally get it closer to right with "Longhorn (or whatever it's called now) - but I do hope I'm wrong!


[edited by: SuzyUK at 4:12 pm (utc) on Mar. 17, 2006]


 6:43 pm on Jul 20, 2005 (gmt 0)

I hope this isn't a preview of what is to come, but I was playing around with a beta ver of Longhorn and so far it looks like XP with a new skin. Very clunky. Anyway, the funniest part about the whole thing was that I opened up IE(6) and low and behold, it worked. Only for about 15seconds. Halfway through the load of msn.com's main page it crash and burned and asked me if I wanted to send an error report to Microsoft. After a quick laugh, I did it again. Still made me laugh. It never got old, until Longhorn itself crashed. Since then I haven't been back. The whole thing is wayyyyyyy buggy.


 9:33 pm on Jul 20, 2005 (gmt 0)

***** News, interested in further reading? google "having layout" - the Ingo Chao (and notable collaborators) article has been comprehensively updated today and although still general in it's conclusions, it is the best explanation there is so far.

Interestingly they reckon hasLayout effects all the main elements of the visual formatting model to some extent:

  • Clearing floats and the extend to fit
  • Elements next to floats
  • Lists
  • Tables
  • Relatively positioned elements
  • Absolutely positioned elements: Containing block, what containing block?
  • Filter
  • Re-flow of rendered elements
  • Background origin
  • Margin collapsing
  • Block-level links

Just about everything really!

>> common denominator
As my little head sees it: Look at the affected element and think of it as the child, does it know how much room it has to grow without having to do any sort of abstract calculation (e.g. px, percentage, em or default for that matter margin, borders or padding ~ this includes the default margin/padding applied to lists for example), is there anything in it's parentage that will tell it exactly what size to be? (forget doing any sums here as soon as you have to do that's were IE will fall)

If not it's very likely that's what triggered a "layout" bug: then as to where to apply the cure, I've tested some of PIE's bugs in the last few days and find that it's usually better to apply layout to the parent (disclaimer: PIE demos used instead of tinkering with any real world examples), as that gives them responsibilty, but sometimes the grandparent will do if that's less invasive, and then again sometimes it's better that the child takes responsibility for itself..

.. this is where the grey area of choice comes in as to which will work better for your pages.

The cure is the same, the logic, apparently, is non-existant! (Is this starting to sound like CSS Social Work?)

They also state in conclusion:
In conclusion, we see a lot of behavior ignoring the W3C CSS specs. Was the contenteditable and the filter worth all that specification violation?

Not sure I understand that reasoning as I'm following another site where they're testing contenteditable just now and they're having related problems..

ackkk. (encyclo you're right this sucks!) ~ time for bed says zebedeee



 12:18 am on Jul 23, 2005 (gmt 0)

I have been frustrated for years trying to fathom the IE backend thought processes. Thanks, once again, SuzyUK for a nice tidy explanation. hasLayout is certainly in the running for least mentioned/documented/understood Microsoft process.

My conclusion is that MSFT, being a software application company, always wanted an (interactive) application that browses. If not the only such application then the preferred one. Simple document request and display just wouldn't do.

The w3c works on consensus and consensus takes time. The w3c is open and open is level. Rather than wait and start even with everyone else IE jumped out first and fast. It is possible that they thought it would also allow them to set the rules by implemention. Also Microsoft applications are expected to be proprietary and that required their own DOM. Whatever, IE 4.0 implemented their Dynamic HTML (DHTML) Document Object Model rather than wait on the w3c Document Object Model (DOM).

If the w3c had caved, Opera not set a quality example, and Mozilla not been created this discussion would be moot. IE's way would be the only way. But. And so we have recommended standard behaviours and two (plus) browsers that largely meet them.

Attempts at reconciliating DHTML and DOM are, I think, behind hasLayout appearing in 5.5. IE 6 "standards mode" meant further changes to hasLayout. And that IE hoped would be enough. It hasn't been and isn't and the market is slipping away.

The big questions are:
* can IE truly reconcile the two DOMs?
* do they want reconciliation?
* if not, what will they do?

So far all I expect are improved security and tabbed browsing. I have heard nothing to expect DOM changes. It is very difficult to render the same exterior from differing skeletons. Sadly - from a designers perspective. Happily - from that of IE's competitors.


 4:34 am on Jul 28, 2005 (gmt 0)

>can IE truly reconcile the two DOMs?
Highly doubtful. I've worked on complex programs (optimizing compilers are probably comparable to rendering engines in complexity, with people who (I believe) had a clue as to what they were doing, and cared to document it. I think I know what Microsoft would be like if they had any such people, and that is not what they look like. I have never seen any evidence that anyone at Microsoft actually knew what the programs were doing--the most they can ever tell you is wherein your program using a MS DLL differs from the one sample test case that the in-house developers managed to make work; but if they document stuff, they'd feel customer pressure to fix it when it doesn't work (and, of course, odium when they didn't.) But now they face nothing like that, because nobody on earth can prove their garbage is supposed to act any other way than it does.

>do they want reconciliation?
No, absolutely not. What does it gain them to encourage people to use a standard? (Even reputable market-leaders don't encourage standards.) Better, far better for THEM, to utilize their monopoly on browsers-shipped-with-new-computers to ensure standards-conforming websites won't work for most of the lower-quartile of internet users -- thus forcing people to code to the moving target (shambling mound) that is IE.

>if not, what will they do?
Nothing. Patch security symptoms without raising a finger to touch the REAL technical problem (ActiveX and supervisor mode) or the REAL social problem (too many "reputable" companies demand that people go through wierd internet processes to run simple programs, so people get used to saying "OK" to any insane request, because Microsoft et al make so many of them.)

Global Options:
 top home search open messages active posts  

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About
© Webmaster World 1996-2014 all rights reserved