[css-d] Nested 100% min-height
G'day list, The problem I'm having currently is with nested 100% min-heights; I'm looking to wrap a fluid layout with drop shadows, which seems easy enough, but I'm far more used to dealing with fixed-width layouts (and the tricks and hacks that I can use there). I've reduced the problem to a simple test case here: http://kit.iqmultimedia.com.au/testcases/100percentheight/standards.html To see the issue I'm having, resize your window so that the window gets a vertical scrollbar; notice the shadows get cropped off. For an example of what I'm trying to achieve, check out the tables version: http://kit.iqmultimedia.com.au/testcases/100percentheight/tables.html This site will be deployed on an intranet with an IE7+ deployment environment (whoo!), so I'm happy with translucent PNGs etc. Being an intranet, I'm now just trying to justify spending any more time on the standards way given how quickly I knocked up the tables version. Please note: I have the need to whack a sticky footer in there too afterwards, but I don't anticipate that'll cause any issues. Thanks for any help you can provide (even just a consensus that the tables version is the lesser evil would be great). Cheers, Kit Grose iQmultimedia __ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] IE6 - display: none bug (with testcase)
G'day all, I've run into a bug that's (of course) only affecting IE6, but I'm interested to see if anyone else has a better fix for me. You can see the bug in action at http://www.iqmultimedia.com.au/kit/displaynonebug.html The test is a fixed-width container (with overflow:hidden) with four child elements (all set to float: left) of fixed width. One item is set to display: none. Despite IE not leaving any gap where that item is in the markup (between the two vertical grey columns), it determines that it cannot fit the green box into the remaining space. The bottom test shows the same markup but with 'display: none' replaced with 'width: 0'. The basic concept is that IE miscalculates the width of floated items with display: none set. If I set the width of the item to zero (with an overflow: hidden addition), the three items fit in the space perfectly in all tested browsers (IE6, Safari 3.1, Firefox 2+3, Opera 9). I'm using Javascript to set the display properties programmatically based on certain conditions in my real usage scenario. I can use the workaround, but it's much less clean. A quick Google shows others with the issue; none with this specific workaround, and no obvious alternative workaround. If someone knows of one, please, please let me know! Cheers, Kit Grose Frontend Web Developer iQmultimedia [EMAIL PROTECTED] iqmultimedia.com.au __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] space in horizontal nav
Matt, If the issue is only showing up in IE, try removing all the whitespace between the list items in the markup. - Kit __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] IE 6/Win Text line width expanding container
I thought so too initially, but I can't explain why it would affect that first line (ending in 'torn to shreds'). I'm prepared to leave it at overflow:hidden, rather than lay out a test case, since the client is already getting mate's rates. Thanks for your help, Kit __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] IE 6/Win Text line width expanding container
Hi, I've got an issue that's very frustrating at the moment and I'd like to know if anyone has encountered it and fixed it before: http://www.iqmultimedia.com.au/kit/iebug.gif Lines of text are wrapping based on the true line width, but leaving a trailing space after each line that pushes out the container width (rather than wrapping earlier). I've fixed the issue currently with overflow: hidden, but I'd really rather have the overflow be visible. The text is being input via CMS so it's not static and can't be customised by a designer before it's put on the web. I'm beginning to think it's going to require absolute positioning and I'd really rather not go there with this layout Any thoughts would be appreciated, Kit Grose [EMAIL PROTECTED] __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Help with converting table layout to standards
Well, I've fixed my problem for the most part. I simply used the trick where absolutely positioned elements have more than one vertical property set (which doesn't work in IE, but we're operating on a Firefox/Safari only assumption). So we've set the top to 2em, the bottom to 0, the left to 0 and left the right as auto, with the width defined as 200px, and now I get all the niceties of the design. It's a hack, but it works exactly to spec. Hope it helps someone else at some point, Kit __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] Help with converting table layout to standards
G'day all, I'm trying to build an extensible interface refresh for the backend of a product we sell. The interface I'm trying to build might be thought of as 'full screen'; with a sort of frames layout feel. There's a primary nav bar across the top of the screen, a secondary nav bar down the left of the screen (which ideally would occupy the full height of the window minus the height of the nav bar and have overflow: auto), a heading bar with some action buttons, a large content pane and a set of action buttons. To give you an idea, I've mocked it up in tables so you can see where I'm heading, and the start of a standards design, but I've become bogged down: Tables version: http://www.iqmultimedia.com.au/kit/slogger/tables.html Standards version: http://www.iqmultimedia.com.au/kit/slogger/standards.html The tables one doesn't work properly in anything except FF, but I don't really mind because I'm not likely to use a design with tables for layout. The issues I have are the following: - Can anyone think of a way to impose a scrollbar on the left-hand 'Stuff goes here!' secondary nav when it expands beyond the window bounds? - How can I allow the developers to create between 0 and 2 each of neutral, destructive and constructive buttons while keeping them all in line and tidy? Buttons are likely to get icons too if deemed feasible. I'm in a rather unique situation where the product is going to require Firefox (in order to fall under the support requirements for the application), so I have a lot more freedom when it comes to nice selectors etc. in CSS. Any help you can provide would be appreciated (I'm in a situation where I have to explain to my boss why I shouldn't just use the tables layout and get a moveon with the development). Cheers, Kit Grose __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Odd Safari display problem...
On 18/10/2007, at 10:18 AM, David Laakso wrote: Matt wrote: Check out the navigation and RSS link on the top right part of this page: http://www.scienceprogress.org/ Everything lines up fine in Firefox and IE-Win, but in Safari, the RSS icon drops below the navigation stuff and floats to the left... Any idea why? Mac OS X 10.4.10 Hmm. I see no difference in relative rendering among Safari/3.0.3, Mac/Opera/9.23, and Mac/Firefox/2.0.0.7. Safari 2.0.4 on OS X v10.4.10 here, and the RSS icon stays on the line with the other links in the navigation for me.__ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Is this possible?
Simply put: yes it is. Set the pale yellow as the background image of the body (create a 1px- high sliver of yellow and position it with background: #fff url(../ images/myyellowsliver.gif) 140px 0 repeat-y; assuming you want 140px of white sidebar to the left (it's a guess)) Make a DIV for the primary nav (with an unordered list for the nav itself), a div for the testimonial customer names, and a DIV for the content (give that last one a unique ID). Float all three DIVs left and give them the appropriate width. How you want to implement the logo is up to you (I'd be inclined to use a positioned h1 tag with an image tag for the text inside it so I could put it first in the source order), but for pragmatism's sake, you could put it into the third DIV, right above an image tag (for the photo), and two more floated DIVs (to form the columns of content). You could change the text in the third DIV using Javascript quite easily (but remember to provide fall-back links for non JS users). Hope that helps, Kit__ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Pure CSS drop-down menus aren't *good*
G'day Rafael, On 15/10/2007, at 2:01 PM, Rafael wrote: > I think this is yet another religious topic. Accessibility on > most JS menus (actually all I've seen so far) is inexistent, some > of them are so poorly done than they even throw an error on this or > that browser and the whole menu stops working. If you ask Joe Clark > about his opinion... maybe he would trash both of them :) I think in the authentic meaning of the word 'Accessibility', well- produced JS menus far outshine CSS-only ones, if only for point 2 of my previous email (introducing delays before collapsing submenus). As for handling errors and browser support, of course that's all down to implementation (any good JS is totally unobtrusive and so only users with support get the advantages of the Javascript). > Personally, I think CSS menus are better (or "less bad") than > JS menus. In both cases you must know what you're doing and have > accessibility on mind (and hoy many of us do really do this?). If > you ask me, a combination of both is the best solution, which means > a lot more work than current / typical implementations --and the > client's can't see a reason to spend on that, and the guy doing the > front-end has a lot of things to think on before spending some > "extra time" on the "minor details". I like to think I keep accessibility on the mind throughout every phase of a frontend design job. I do testing in text browsers, and in upwards of 10 desktop browsers (including the big four; IE 6, IE 7, Firefox 2 and Safari 2). When you say "a combination of both", that's exactly the behaviour I'm talking about when I say 'Javascript menus'. I don't believe in pure Javascript implementations of anything. It must be loaded unobtrusively as a supplement (rather than replacement) of CSS-based menus. As a full-time 'frontend guy', navigation is around about number 3 on my list of priorities when putting together a website; I think part of calling ourselves professionals is treating every part of each job as worth our time. Plus drop-downs tend to feature in around 90% of the designs our Art Director puts together, so getting it right once helps us with subsequent jobs. > I myself should be redoing part of a menu I'm planning on > using, but is for a personal site so the time I have spent on it > is... a message I sent to this list (and that Georg kindly > replied), that's all. Oh, well... real life again. In case you're > curious, the link I sent was > http://dev.rsalazar.name/css.d/menu.html > By the way, the best solution for the accessibility issue I asked > help for seems to be a re-implementation of the CSS "behavioral" > part combined with a little JS to make things look better (ironic? > yes, it is). I like the way that's looking, but it shows off exactly what problems pure CSS menus always (necessarily) show: say you expect another level of navigation to drop down, or you're just not particularly good with a mouse. You go to Groupo D, Groupo D.2, Enlace D.2.a and slide your mouse off the bottom (just a pixel) and instantly all progress is lost and you have to start from the top-level again. This is more important still when you have many items in each menu level (since there is more cognitive thought required to decide a menu item). > Here are some opinions, if you mind... > > Kit Grose wrote: >> G'day Jay, >> >> I've heard the request for pure CSS drop-down menus quite a lot, and >> rarely see people getting told what they should about how *bad* they >> are. >> > Can you say better things on JS menus? Aren't basically the > same things? No! Javascript adds some more desktop-level comforts to the way things work (like menu hide-delays). >> CSS is designed as a method for styling visible items and laying them >> out relative to one-another. Drop-down menus are behavioural, and >> thus should be taken care of with Javascript (not Java; there's a >> huge difference, worth noting). Of course, accessibility means >> keeping in place a series of fall-backs which allow non-JS enabled >> users to view the list. >> > So would CSS fall-backs to do exactly the same. Yes, but they're fall-backs. Just as the fall-back for no CSS is a simple nested unordered list, we have to draw the line somewhere. We lose some usability, but it still works. > It's hard (for me, at least) to agree on using JS solely on the > fact that their behavioral and, therefore, should be done with JS. > It's kind of the same as saying that changing the colors is a > be
[css-d] Pure CSS drop-down menus aren't *good*
G'day Jay, I've heard the request for pure CSS drop-down menus quite a lot, and rarely see people getting told what they should about how *bad* they are. CSS is designed as a method for styling visible items and laying them out relative to one-another. Drop-down menus are behavioural, and thus should be taken care of with Javascript (not Java; there's a huge difference, worth noting). Of course, accessibility means keeping in place a series of fall-backs which allow non-JS enabled users to view the list. There are some massive accessibility gains that Javascript drop-downs provide: • You can animate opening and closing lists (not just eye-candy; it makes it very clear to the user when there is a change on the screen) • You can provide a suitable pause before the list collapses (your users are not necessarily skilled with a mouse or keyboard. They may have difficulty operating a mouse and I can tell you from experience that they have real difficulty changing movement from horizontal (along your list headings) to vertical (down your first level list items) to horizontal (across the list item to the sublist) to vertical again (down the sublist items) without accidentally moving the mouse out of the bounds of the list item. Javascript menus introduce a delay before actions are cancelled so that a slight movement of the cursor outside the bounds of a list item is not penalised against) • You can get identical behaviour in all the major browsers (all the CSS-only drop-down menus rely on CSS hackery to work properly in IE. Every sensible browser can handle the ul>li selector; the basis of a simple, standards-based CSS solution, but IE doesn't. CSS hackery is no better for you as someone who doesn't understand JS but does understand CSS than JS hackery; CSS hacks commonly *don't make sense*. They're backward thinking and complex to write). Please, for your users' sake: use a Javascript drop down menu (but make sure it's one that is fully accessible, and that reverts to a pure-CSS menu when JS is not available). I use TwinHelix Designs' excellent FreeStyle Menus (http://www.twinhelix.com/dhtml/fsmenu/) personally, but it's donationware for commercial use. Cheers, Kit __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Navlist Problems
Richard; you've also left the browser's automatic left padding on the
list and list items.
To fix, it's simply:
#navlist,
#navlist li {
padding-left: 0; /* or some other suitable amount */
}
Cheers,
Kit Grose
iQmultimedia
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] How do you show Selected Page in the navigation?
Hi Craig,
The easiest way to select the current page in navigation is to give
each list item a unique ID, and to give the body tag the class of the
section you're on:
...
Contact Us
Site Map
...
...
Then define a stylesheet rule as such:
.sitemap #sitemap,
.contactus #contactus {
/* Selected list item */
}
Hope that helps!
- Kit
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
