trigger hasLayout without a dimension

the "Tripswitch" filter explained

[SuzyUK]

Talk about your past coming back to haunt you :o

It came to my attention recently that an IE hack I'd dubbed the "Tripswitch" when I noticed the behaviour back in 2005 has been picked up, despite my hopes at that time that it would not be necessary as IE7 would work properly ;)

[original thread] [webmasterworld.com]

(I think if it ever needs come into use, which hopefully won't be the case, I'll call it the Tripswitch Hack! ~ hehe)

There are many ways ways to trigger hasLayout and everyone has their favourite, however I've always advocated that any hack or filter be obvious! it can be really hard to remember everything you did at a point in time or why, and even harder for the next person who might be working on your sheet

This tripswitch filter is so tidy it can go in a main stylesheet and its presence is so subtle it would likely be hard to detect that it is even a filter, and while I don't think the tripswitch itself should cause any problem going forward (IE8 is reportedly going to be hasLayout free), Yes.. yes, I know it go in a conditional and if you're already using conditionals you're being responsible by making all filters obvious IMHO :).. but there are those who still like to keep everything in one sheet whenever possible and I still see filters in use where "it's just there because, it was that way when I got the template/code/stylesheet"

As part of my personal "responsible hack management" ethos I would hate to see this "tripswitch" go in a stylesheet without some kind of explanation about it and then beside it in the code.

the filter:

example HTML: where the <a> might need layout
<ul>
<li><a href="#">link which needs layout</a></li>
</ul>

CSS:
a {display: inline-block;}
a {display: inline;}

or

a {display: inline-block;}
a {display: block;}

Explanation

• The display rules must be given over two separate rule sets
  
• The display can be reset to whatever it should be, either inline or block (<a> is inline by default but often set to block in list element for rollovers)

Every browser including IE will read the second rule for its actual display property zas per the rules of the Cascade, which is why I assume IE8 will have no problem with this filter either. BUT IE7 and below will trigger hasLayout=true with the first rule and will not use the second one to reset it to false. This is expected behaviour, as Microsoft tell us that hasLayout cannot be reset to false once triggered to true.

• while the bit about resetting is true this little filter will not work if the two rules appear in the same ruleset
  
• the filter does not work with any other of the hasLayout triggering properties, only

  display

  - as far I've tested anyway, but ymmv

So I can imagine in a few years that *if* this filter appeared in a main stylesheet somebody relatively new to CSS might wonder.. "why just not set the display properly in the first place" and subsequently remove the 'inline-block' and put the block or inline back in the master rule.. prompting the "my site just broke in IE6/7 and I don't know what I did" headache

So while I'm not advocating use of one particular filter over another, *if* you do want the simplicity of one sheet, and use this one.. please comment it to make it known it is a filter!

something like below, it's how it got it's name:

a {display: inline-block;} /* hasLayout TRIPswitch */
a {display: block;} /* display tripSWITCH */

-Suzy

[ergophobe]

Just to wrap my head around this one, this is because I can't add a height:100%; to an inline element, or am I not really getting the significance of this?

Or do you worry about how setting a percentage height might get interpreted, whereas this has no amibguity ever?

The vaguaries of CSS make my head spin.It's as if Postscript markup worked differently in every printer.

[SuzyUK]

ergo, it's not CSS that's the problem here ;) it's IE pure and simple hehe

Just to wrap my head around this one, this is because I can't add a height:100%; to an inline element, or am I not really getting the significance of this?

no it's not necessarily because you can't set a height, an inline element cannot accept a height according to the specs, but the height itself should still trigger the hasLayout=true for IE - but perhaps you just might not want to use height trips - and yes, there may be a slight possibility, even down to future changes by someone to the styles that a percentage height would actually have something to inherit from.. if the inline was made into a block or the height is being used on a block it's a slim chance but still..

.. and I've actually since found some tests that show the

height: 1%;

is not always stable in some cases, so will test those cases with this tripswitch and see if that might have a bearing over which one to choose or if it's just something else to be aware of

but anyway like I said people have their favourites and you can set a percentage height on an inline element for the purposes of layout only - but comment it as hack too!

Or do you worry about how setting a percentage height might get interpreted, whereas this has no amibguity ever?

Yep, that's about it for me anyways

[ergophobe]

>>something to inherit from
Good point. Got it.

>>it's not CSS that's the problem here

Yes and no. It's a sign of how immature the web is by comparison to print. Sure, perhaps it's not the CSS spec that's problematic, but from my perspective the vaguaries of implementation can be hair-tearing at times. Granted, even a professional page layout tool like InDesign can be a lot to learn and counter-intuitive, but send it to a PostScript printer and check it and you can be pretty much guaranteed that it will be right on every PostScript printer. And, perhaps more importantly, I have no need when I do a print book, to know what's in the PostScript spec or, for that matter, that there even is one.

[SuzyUK]

yes I get you, I'm just so used to it by now I forget what it's like just trying to get basics to work :o

>>don't even need to know there's a spec
yes wouldn't that be fab, but in defence of CSS it's taken conscientious CSS developers and good browsers to even get the spec written to a standard. The last remaining battle to standardise is with IE and that's looking a bit better going forward - perhaps in few more years we can stop referring to this scenario at all ;)

I can confirm that there is instability with using a percentage height in some RARE cases, so perhaps another reason to look for a more informed choice?

The hasLayout Hack Management page [onhavinglayout.fwpf-webdesign.de] shows the various methods which can be used - if you go down the bottom table, "syntax", - at the top of the left column, under the "commented backslash method" there's a link to the test page showing the test cases.

Bruno's test is run using

height: 0;

and

height: 1%

for the comparison and obviously

height: 0;

is no use for IE7, so

zoom: 1;

used for it..

I ran the same test using

height:100%

and the tripswitch and can confirm the TS worked fine (like height: 0 and zoom in original test) and that

height: 100%

acted the same as

height: 1%

(it failed), so that for me would rule out the height hack unless forced to still support IE5.

.. just another thing to be aware of perhaps, again it's an unlikely scenario but negative margins are not that unheard of these days.

-Suzy

edit reason: my spelling is not getting any better

[edited by: SuzyUK at 8:40 pm (utc) on Feb. 27, 2008]

[ergophobe]

Got it. Thanks.