bronzemonkey
-
Posts
433 -
Joined
-
Last visited
Never
Everything posted by bronzemonkey
-
because those properties aren't supported on those tags in IE
-
[SOLVED] What is the latest method for rounding corners of CSS buttons
bronzemonkey replied to DataRater's topic in CSS Help
That's great if you're working on personal projects...but if you're building large websites for big clients then they couldn't give a shit about you having to stick an extra span in the html to get produce rounded corners. Ideally I wouldn't want to add "extra" markup just to create completely fluid/elastic rounded boxes...but that's why I wouldn't include them in my personal designs. Eventually css will allow those types of designs (complex "custom/rounded borders") to be realised without needed extra markup. Where I do leave IE6 out in the cold is :first-child. I just use expressions to get the job done and those visiting the site with IE6 and js disabled are just going to have a minor aesthetic difference in a few instances. -
The original clearfix did not use an empty div in the markup. The whole point of the clearfix was that it removed the need to use an empty div and provided increased reliability. The modified version of the clearfix goes even further by removing the need to even use an extra class in the markup. I personally add a few other styles to the clearfix solution to cover a few rendering differences in Opera. I would also strongly recommend that people do not use the IE6 and IE7 "hacks". Put that kind of stuff in conditional stylesheets. The IE7-targeting style isn't even technically required since {min-height:1px;} has no effect whatsoever on other browsers because the height of the element will be greater than 1px anyway. Much like {display:inline;} on a floated element has no effect on anything above IE6 (which is why some people leave it in their master stylesheet). But the concept is that you separate any IE-specific styles from each other and from the styles being served to standards compliant browsers. It is also worth understanding that the self-clearing of floats in IE is achieved by triggering the proprietary IE property of "hasLayout". It is not always the case that you will want to trigger "hasLayout" in IE on the same element that you are self-clearing in modern browsers...and equally, it will be the case that you will need to trigger "hasLayout" on some elements for IE but do nothing to the styles for modern browsers.
-
Just to come back to this. There is no technical problem with using an image within an anchor. Just set the image to {display:block;} and use {border:0;} to avoid the issues with the inline "margin" often found at the base of the image. There are many sites that use img tags for logos with no technical problem.
-
If you want to disable part of a form using valid (x)html you use: <input disabled="disabled" type="text" value="" /> Readonly is different to disabled.
-
When you turn images off, you're left with nothing there. This technique is discouraged in favour of using an empty span that is layered over the top of the text - the unsemantic markup is a small price to pay for increased accessibility: <h2><a href="#non">text<span></span></a></h2> h2 a {position:relative; display:block; width:200px; height:20px; overflow:hidden;} h2 a span {position:absolute; top:0; left:0; width:100%; height:100%: background:url(/images/h2-background.gif) no-repeat 0 0; cursor:pointer;}
-
I agree with FilmGod. Better to put the class on the list item that is the parent of the link...rather than the link. It means you can also style the list item if needed, which it often is. I also avoid using a class of "active" because there is already a css pseudo-class :active - a current page state is distinctly different from a link being active. <!-- html --> <ul id="nav"> <li><a href="#"></a></li> <li class="current"><a href="#"></a></li> <li><a href="#"></a></li> </ul> /* css */ #nav li.current a {} You can also use purely css to produce current-page styles (I wouldn't use this technique on a large site though). Just give the body a page-specific id and each list item of the nav an id (or class) <body id="home"> <ul id="nav"> <li id="navHome"><a href="#">Home</a></li> <li id="navAbout"><a href="#">About</a></li> <li id="navBlog"><a href="#">Blog</a></li> <li id="navContact"><a href="#">Contact</a></li> </ul> </body> /* css */ #nav li a {font-weight:normal; color:#000; background:#fff;} #home #navHome a, #about #navAbout a, #blog #navBlog a, #contact #navContact a {font-weight:bold; color:#fff; background:#000;}
-
IE 6 UL Dropdowns not dropping?! * other browsers fine?
bronzemonkey replied to scotchegg78's topic in CSS Help
Go back to where you ripped this menu from - www.cssplay.com - and look at the source html. -
the declarations must be in this order: :link :visited :hover (:focus) :active
-
get the firebug extension for firefox and you would have seen they are flash files. you need that tool.
-
It doesn't work in IE because it isn't supported. There is nothing wrong with using css that doesn't work in IE if it is just for minor decorative details - :after and :before are good examples and sometimes used to insert a middle dot between links or quotation marks around a quote. However, sounds like you need to use a background image rather than insert markup on hover.
-
You need to clear the floated elements within your container - http://www.positioniseverything.net/easyclearing.html. IE is actually not behaving in accordance with the css2.1 specs.
-
use {display:block; float:left;} on the anchors. read this site - http://css.maxdesign.com.au/
-
It is part of the css3 spec...but no browser supports it yet. They are still in css2.1-land.
-
Background-Image Buttons/Links with Large Offset
bronzemonkey replied to Edgewalker81's topic in CSS Help
Yeah there is a "better" way. Using text-indent to put the text off-screen means that is someone is visiting the site with images turned off, they cannot see any text! If you're prepared to introduce a non-semantic element then there is an image replacement technique that is completely accessible because it places the image over the text: <h2>Hello world<span></span></h2> h2 {position:relative; height:50px; width:200px; overflow:hidden;} h2 span {position:absolute; top:0; left:0; width:100%; height:100%; background:url() no-repeat 0 0;} The span element gets pulled over the containing element and given a background image. If you need to do this for a link, then make sure the anchor is displayed as a block and that {cursor:pointer;} is added to the span declarations. This technique is widely used and considered the most accessible. Has many advantages and the non-semantic element is not exactly a deal breaker. Depending on what browser support you require, you might also want to check out "Bob Image Replacement" - http://neal.venditto.org/articles/12/bir - when the website is back up. It uses z-index and relies on more semantic html. -
CSS Designer needed for big project (READ CAREFULLY)
bronzemonkey replied to cybershatter's topic in CSS Help
Isn't this the 3rd or 4th time you've posted this on the forum? Please don't post it a 5th. -
Can't really tell without seeing the complete code that you're using. But try adding {clear:left} to the element that you're floating left.
-
Yeah that's possible. Make sure your server has the appropriate charset set (utf-8 is a safe bet), that your html head element also uses the same charset, and that where ever you use a different language you include the lang attribute in the containing element. You can even specific the text direction should the language read right-to-left. /*server charset must be utf-8*/ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> </head> <body> <div id="blah" lang="en">Blah blah</div> <div id="blah" lang="he" dir="rtl">Blah blah</div> <!-- makes the text direction right-to-left --> <div id="blah" lang="fr">Blah blah</div> </body> </html>
-
There is no difference in css implementation in FF/Win and FF/Linux. Differences I come across are down to OS font-rendering or selection. It's not that I haven't "seen" a need for it, it is that there is no logical reason to do so. You don't even need to target IE7 because declaring a min-height has no consequence for modern browsers. Besides, I put all my IE code into IE specific stylesheets rather than use any form of selector hack. If you know how browsers behave and the concepts behind the browser-differences then there are often several ways to solve the same problem.
-
Download the "firebug" extension for Firefox and it will really help you with debuging. The "Inspect" tool will be very useful for you.
-
The h1 inside #main has a top-margin which is creating that whitespace. Either remove the top-margin from h1s inside #main (and use some top-padding on main) or use 1px of top-padding/border on #main to force the h1 margin not to spill out of #main.
-
Floats and positioning (two things that are heavily used in css-based layouts) seem to be the root of many people's difficulties. It is really worth anyone's time to read something like Eric Meyer's CSS Definitive Guide (the only css book I've ever read) to understand what is going on and how to make these things work for you. Can you post a code example? Is the image and text within the box? At the moment, it sounds more like FF is behaving correctly by allowing the floats to poke out the bottom of the box while the IE hasLayout property is causing non-standard behaviour by self-clearing a container. This is true, but I only experience differences between modern browsers and IE. Some of my colleagues show me differences that they have found between FF and Opera, or Safari and FF, but it is always down to a less than ideal solution to a layout. The differences exist but they can be avoided. The biggest differences, that I come across, are between different OS. Not because FF2 or FF3 on Windows/Mac/Linux have different interpretations of the specs, but because something like Ubuntu will often render fonts differently or use alternative fonts to Arial / Times / Georgia. So sometimes a bit of care is required to make sure things don't "break" in Ubuntu et al.
-
Legends cannot be styled consistently across browsers.
-
Really? I haven't come across any such problems. It's actually getting a container to self-clear. Floats are supposed to removed from the flow and "poke out" of their containers...it's an intended behaviour. But since we have to use floats to create columns, we have to find ways to get their containers to act as containers! It is not as flexible as variations on the clearfix theory. Using overflow will either produce scrollbars in certain situations or cut off content that exceeds the limits of the container. The FnE method can also produce "peekaboo" bugs in IE6 that seem to be completely unfixable. {clear:both;} does not work if you are trying to self-clear an element that contains floated elements. If I have this: /*css*/ #content {margin-bottom:1em; background:#000;} #col1, #col2 {float:left; height:500px;} #footer {clear:both} <!-- html --> <div id="content"> <div id="col1">blah blah</div> <div id="col2">blah blah</div> </div> <div id="footer"></div> Then both #col1 and #col2 will "poke out" of #content. The #content will only be 1px high and the background colour will not expand down the page and surround the two columns. The footer will render after the two columns but it will ignore the #content margin because that margin will be directly below the 1px high #content div (check it out in firebug) and have no effect on the position of the footer below the two columns. To get #content wrapping both columns so that its background extends downwards and its margin will produce a space between the columns and the footer, you need to "self-clear" the content div. Using <div class="clear"></div> is not only unsemantic but unreliable. The clearfix method was a solution to avoid unsemantic code and unreliable self-clearing. However, it can be improved so that you don't even need to add classes in the markup at all. Actually, it doesn't make your css invalid. It's just that I prefer to keep version-specific IE targetting in version-specific stylesheets. All my fixes for a particular version of IE go into their own conditional stylesheet - that way I don't have to mix standards/non-standard code and I don't have to worry about those "hacks" suddenly being read by other browsers in the future. If you were using the IE7 haslayout fix in your master stylesheet then it works just as well with *+html {min-height:1px;}. And because it is min-height, it doesn't matter if other browsers can read it.
-
Margin 12px for IE7 + Firefox, but need 6px for IE6?
bronzemonkey replied to scooter41's topic in CSS Help
IE6 has a "double margin bug". For example: #myelement1 {float:left; margin-left:10px;} #myelement2 {float:right; margin-right:10px;} Both examples will result in a doubling of the margin in IE6 because you've got a margin on the same side as the direction that the element is floated. It is easy to fix by adding {display:inline;} to your code for the element that is experiencing the problem. All other browsers will ignore the declaration because a floated element is always displayed as a block (even in IE6 when you use this declaration). However, it is probably best to put this into a conditional stylesheet targeting only IE6 in order to properly separate all the IE-specific pieces of code from the code that is purely standards orientated.