Hello.
I can’t avoid shrink-wrap on an element with position: fixed. I tried out zoom: 1 but it did not help.
↑ please open an image and watch the bottom bar (yellow one).
thanks in advance!
Maybe try setting a width, such as 100%;
Sorry but it won’t work. Did you try it out?
Can you be more specific? I’m seeing different layouts and broken scripts here in all four major browsers – “shrink-wrap” not being a term used by web developers to describe anything and without saying what elements you are referring to… any answers would amount to wild/blind guesses in the dark.
Though, being I HATE lightbox scripts – not sure how much help I’d be in the first place… though yours appears to fail to finish ever even loading to start functioning here. Being a fat bloated pile of jquery bull this of course is hardly shocking.
Hey dude, I’ve construed your reply to be impolite. So I could ask also impolitely: ‘what the hell are you talking about?’. But I won’t, though I did (only this example, please).
The question was not about people’s love/hatred for a lightbox. I DON’T care. Of course the script was tested in Firefox (newer versions), Chrome (Chromium), IE8 and IE7. And it works without any errors nor warnings. I have not tested yet all browsers I want, but it is only a matter of time. Now it’s time for IE7.
But get down to the nitty-gritty. Please have a look at this screen shot:
http://wstaw.org/m/2011/07/24/rlb.png
The orange bar should expand to the right edge of the lightbox. It won’t in IE7.
I’m sorry for not being specific for the first time. 
We don’t call DS60 “Old Crusty” around here for nothing, he generally has the bedside manner of a rabid badger 
But I don’t think he said anything in his last post that was busting on you personally. I’m with him, I didn’t understand the term “shrink wrap” until I saw more of the discussion. I don’t agree with him about jQuery – I think it has a lot to offer (especially since unlike him, I am JS-deficient and need crutches) – but he was being abusive to the framework.
There are a lot of non-jQ lightboxes out there. I’ve even seen some that are CSS-only, though as you can imaging they’re pretty bare-bones. Here’s one I personally like: Nivo Slider It is almost bug-free (by my standards, not DS’s!), works very well cross-browser, even in IE6, and is pretty straightforward in its implementation.
Sorry I have no answers for you re your lightbox’s dysfunction in IE7. I’m not the one to ask. If you don’t get a satisfactory response in this thread, you may consider asking it in the JS forum.
Do you have some test code we could try?
The script seems to be setting a width on one of the inner P, and it’s shrinking to that width… thing is, the parent DIV is not (or shouldn’t be) position fixed, only the one above it is… so it shouldn’t be shrinking in the first place.
The markup produced by the script is needlessly convoluted and the CSS isn’t much better – I’d probably either live with it or go find another script. I don’t think you’re going to get a magic bullet fix for this one.
You could try:
#ui-lightbox-header { width:100% !important; } – but really the script is setting most of the values, so you are likely going to need to rip the script apart.
Oh, and don’t take my comments personally – I’m very frank about what I see wrong – slapping the rose coloured glasses on your head to lead you down the garden path to sing kumbaya around a drum circle is NOT how one gets help. You’ve got problems – I tell you what I think of the problems.
Problems like the layout being broken/different in four different browsers here.
Do you have some test code we could try?
here you go: a live mocup → http://ryrych.pl/null/header_ie7.html
The script seems to be setting a width on one of the inner P, and it’s shrinking to that width… thing is, the parent DIV is not (or shouldn’t be) position fixed, only the one above it is… so it shouldn’t be shrinking in the first place.
I use position fixed to center the lightbox in the viewport – instead of position absolute and silly calculation.
The markup produced by the script is needlessly convoluted and the CSS isn’t much better – I’d probably either live with it or go find another script. I don’t think you’re going to get a magic bullet fix for this one.
Actually I’m not going to go for another script because this lightbox is my own project. Just for fun and to improve my skills. 
Setting aside your aversion to jQuery, I bet you know that jQuery UI needs some stupid classes and ids.*
Problems like the layout being broken/different in four different browsers here.
Could you please elaborate? What problems do you have? What browsers have you tested in? It is really important to me since I want to make this widget public.*
Actually, that’s part of WHY I have an aversion to it.
Opera the page never finishes loading and I have to hit “stop” before I can use any of the scripting. ALL versions of IE have the element placement you’re complaining about, not just IE7 (6, 8 and 9 are doing it too), in FF it almost works, but it’s off-center by about 60px, and Safari/Chrome are placing it so that the center of the image is in the upper left corner of the screen.
OK. Opera has not been tested yet.
IE9 has not been tested thoroughly. It’s interesting what you are saying since I was testing in IE8 (XP) and roughly in Win7 and I did not see this behaviour. Could you please attach screen shots? I will be grateful.
in FF it almost works, but it’s off-center by about 60px
I tested this in Fx4 & 5 and it was OK. Strange.
and Safari/Chrome are placing it so that the center of the image is in the upper left corner of the screen.
I have to repeat myself. Chrome (Chromium) was tested and it was OK, too.
Does anyone have similar issues? Any help will be appreciated.
Off Topic:
Jason, your invitation to the next drum circle is in the mail. We’ll all sit around with our bongos, chanting to the Great Goddess Isis and engaging in ecstatic lamentations. Afterwards it’s corn dogs, brownies, and Zarex. Poes is invited also.
OK, I’ve figured it myself. Now it works also in IE7.
Black Max: sorry, but I don’t understand your OT. 
That was directed at me, not you.
your code still leaves me asking questions – like what it needs all those class and id’s for. The only ones I think need ID’s should be the outer div, the content div, the one you’re plugging TITLE into, and the page counter… and ALL those should need are the ID’s… the rest should get single classes. Since title doesn’t appear to be a paragraph, and the page counter most certainly isn’t, P is COMPLETELY the wrong tag… In general you’ve made this a dozen times tougher on yourself both in terms of HTML, CSS and scripting.
… and with that XML prologue forcing IE into quirks mode, that REALLY can’t be helping matters
I should sit down some time and write my own lightbox implementation – trying to do it in a manner that doesn’t piss me off like most lightbox’s do… Of course to make it work in a manner that doesn’t piss me off, it would have to pretty much work how Opera opens a image normally so…
Thanks for your suggestions. I must admit that I*have to improve my xhtml/css knowledge. I still have some gaps in it.
I am self-taught and learning on my own. One always makes mistakes. I know that there are much better than I*am, so I’m open to new ideas.
This is not the right thread, but could I get some help on Sitepoint forums about correct use of my structure – just what you are saying about?
Well, let’s apply it to this thread by going through your most recent example.
You start with:
<?xml version=“1.0” encoding=“UTF-8”?>
That’s what people call the “XML Prologue” (a technically inaccurate term). Having it before the doctype is required to be ‘proper’ XML, but it makes IE go into “quirks mode” – which means you have the IE5 style broken box model, jscript often behaves differently than expected. Lose that entirely, it’s as a rule of thumb a bad idea to put that on a page.
In your HTML, you have this:
<div class="ui-widget ui-widget-content ui-corner-all" id="ui-lightbox">
<div class="ui-widget-content" id="ui-lightbox-content" style="width: 426px; height: 328px;"></div>
<div style="display: block;" class="ui-widget-header ui-corner-all" id="ui-lightbox-header">
<p id="ui-lightbox-header-wrapper" style="width: 394px;">
<span id="ui-lightbox-header-title">foo bar baz</span>
</p>
<p id="ui-lightbox-header-counter">1 / 6</p>
<a href="#" id="ui-lightbox-header-close">
<span class="ui-icon ui-icon-closethick">close</span>
</a>
</div>
</div>
The only reason to give something a class is when it is styled differnnt from it’s siblings. that STREAM of “classes for nothing” on the div border on being presentational markup – especially when you have a fixed ID to which all that presentation can be applied. there is NO reason to have all those classes.
The div after also has a class for nothing with a perfectly good ID on it…
DIV’s are INHERENTLY display:block, there is no reason to change it’s display state in the markup – if that’s inherited from the scripting I can understand it being there – but really that should be a class swap on the parent, not something targeting the element directly.
The first paragraph may be surrounding text I’d consider treating as a P… but really you can’t predict what people will plug into “title” so paragraph could imply a semantic meaning that isn’t there. Semantic markup isn’t just about slapping P around everything willy-nilly.
The next paragraph though just isn’t a paragraph of content – PERIOD. I’d axe that right quick. The anchor seems to have all sorts of stuff attached to it for … well, I can’t figure out why. The nested span is even more of a mystery since it all seems to be for a scripting only close button. Since this scripting should fall flat on it’s ass with CSS turned off anyways, I’m wondering why it’s even an anchor with text inside it.
<div id="lightBox">
<div id="lightBoxContent"></div>
<div id="lightBoxInfo">
foo bar baz<br />
1 / 6
<span></span>
</div>
</div>
Would probably be overkill for markup – and given that you should be building it in your scripting using the DOM (you appear to be using jquery’s innerHTML equivalent) and adding it via the DOM, some of those ID’s might not even be necessary. Pad and relpo #lightBoxInfo, apo the span and throw your scripting hooks on it for ‘close’.
Thank you very much for your deep insight. But let me explain some questions so that we could come to a compromise, OK?
Some classes are used by jQuery UI theming ‘API’. Please have a look at: UI/Theming/API - jQuery JavaScript Library
In order to get consistency across jQuery UI widgets I used them. Apart from jQuery’s I use my own IDs: ‘ui-lightbox’, ‘ui-lightbox-content’, ‘ui-lightbox-header-wrapper’, ‘ui-lightbox-header-title’, ‘ui-lightbox-header-counter’ and ‘ui-lightbox-header-close’.
This especially may be an overkill for you:
<a href="#" id="ui-lightbox-header-close">
<span class="ui-icon ui-icon-closethick">close</span>
</a>
but this is how jQuery makes buttons in its widgets.
<p id="ui-lightbox-header-wrapper" style="width: 394px;">
<span id="ui-lightbox-header-title">foo bar baz</span>
</p>
<p id="ui-lightbox-header-counter">1 / 6</p>
I use two Ps because I’m operating on them internally. Because of yesterday’s changes I can shorten the first P and throw away the SPAN.
And sorry about the XML prologue. I must have overlooked it since normally I don’t use it.*
I really appreciate your help and time! Looking forward to your reply.*
Which is all why jquery is a giant steaming pile of useless bloat I would NEVER use in building a website. It’s not bad enough that it’s a fat bloated library of nonsense that ends up blowing hundreds of K to do tens of K’s job – it also takes a giant dump on the HTML.
If you need that many style and scripting hooks – for something that should automatically make the hooks when they’re generated (that’s what building via the dom instead of innerHTML is for) there is something disastrously wrong with the entire methodology.
ESPECIALLY if that DHTML (let’s call it what it is) is non-semantic markup using twice as many containers as necessary.
I mean, unless you’re building something like google docs, 296k of javascript in four files probably isn’t the answer! That is, by itself, just the scripting, AFTER compression twice my target size for an entire page (HTML+CSS+IMAGES+SCRIPTS)… before compression it’s two and a half times the upper limit I’d ever allow unless it was literally something along the lines of google maps or google docs… For “let’s open up a image link”?!? OUCH! And for what, some goofy animation that just gets in the way of the user actually viewing the image at full size?!?
Actually the whole structure is generated and injected into DOM. I don’t follow your aversion to jQuery but it is your right to a different opinion.*