Re: [css-d] overflow: inheritance?
David McFarland wrote: I was just looking over the CSS 2.1 specs and see that some properties that aren't inherited accept a value of 'inherit' When the spec shows Inherited: No it simply means that the property is not inherited by default. It does not mean that the property can never be inherited. Granted, the spec language is unclear on this precise point, but it is easily inferred from the fact that the properties you point out, among others, explicitly take the inherit keyword as a valid value. For example, the overflow property accepts 'inherit' as a valid value. What exactly can this property inherit from? The spec defines this here: http://www.w3.org/TR/CSS21/cascade.html#value-def-inherit. To quote directly: Each property may also have a specified value of 'inherit', which means that, for a given element, the property takes the same computed value as the property for the element's parent. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- 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/
Re: [css-d] overflow: inheritance?
Re: inheritance: I meant to also note that IE/Win doesn't always adhere to the spec, and in particular does not support the 'inherit' keyword at all. Just a tiny little gotcha there. My understanding is that this is high on the CSS fix list for IE7, but that it is not yet implemented. So, sometimes I hit the send button a little too soon. -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- 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/
Re: [css-d] Contextual selector plus explicit class
James Eaton wrote:
What are the rules regarding contextual selectors used in combination with
explicit class declarations? I'm trying to use something like the
following, but a class set in the td element has no effect (in Firefox
and IE6):
.stats td {
padding: 2px;
}
.calign {
text-align: center;
}
/style
table class=stats
tr
thScore/th
td class=calign725/td
/tr
/table
The selector .stats td has specificity [1] of 0,0,1,1. The selector
.calign has specificity of 0,0,1,0. In other words, the first
selector is winning, and your second selector is not getting applied.
Try using .stats td.calign as your selector, instead. This has
specificity of 0,0,2,1 and should therefore solve your problem
(assuming I have understood the issue correctly).
1. http://www.w3.org/TR/CSS21/cascade.html#specificity
HTH,
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7b2 testing hub -- 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/
Re: [css-d] Confused re: validation
David Dorward wrote: Not so sure about that, as support by browsers is no good if designers are thrown off by being told it isn't valid. OTOH is it such a good idea to encourage the use of new features which aren't yet stable in the spec? My understanding of the state of the 2.1 spec is that it is stable with regard to new features: there won't be any. At worst, there will be a deletion or two of properties that are in any case unsupported. The W3C site itself defaults to CSS 2.1, as you can see on the CSS home page: http://www.w3.org/Style/CSS/. Note the menu links to versions 1, 2.1, and 3. There is no direct link to the 2.0 version. Although unofficial, it may even be that the Working Group intends to skip the CR phase and move 2.1 from its current Working Draft status to a Proposed Recommendation. See http://lists.w3.org/Archives/Public/www-style/2005Dec/0164.html. Although W3C procedures evidently prevent the Working Group from declaring 2.0 to have been superceded, as a practical matter, CSS 2.0 is no longer current. The 2.1 spec itself notes that it is intended to replace CSS2, and it is the more accurate picture of current browser support (i.e. the more commercially viable version). 2.1 would be by far the better version default, IMO, and if there are any bored developers out there, I would encourage them to offer up a patch to fix that. Meanwhile, it is probably OT for the list, except to note that the default is likely to give an unexpected result here and there. -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- 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/
Re: [css-d] List Replies
At 09:13 AM 3/8/2006, Michael Clayton wrote: (Clicking reply in Gmail defaults to the user's email address, and not [EMAIL PROTECTED] Anyone know a way to fix this? I accidently sent this to Angel directly.) Some e-mail clients can set up addressing based on headers other than Reply-To. I don't think Gmail's interface allows that. So the short answer is that you'll need to hit reply to all. Please see http://css-discuss.incutio.com/?page=CssDiscussListHeaders for more information as to why the list operates in this way. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- 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/
Re: [css-d] General font size inheritance question
Scott Haneda wrote: I have a table td that has a font size set to .8em, if I put a h1 inside the td, any font size I set to the h1 will be a percentage of the td's .8. Only if you set the size in ems or percentage. As I recall, IE sets its header default sizes in points, for example, so they wouldn't be affected by the .8em. You could use points, pixels, mm, or absolute keywords (among others) without worrying about inheritance. This kinda bugs me, is there some other approach to be able to use consistent font sizes I'm not sure I understand the problem. You can always reset the relative font sizes, if you are willing to do a little math. If you set the font size to .8em on the TD, for example, and you want to get a font size of, say, 1.25 times the original value, just set the value to 1.25/.8 = 1.5625em. (Presumably you can round that a little.) It is perfectly consistent. If you are planning to change the font size of an outer element, of course, you'll need to recalculate the value for the inner element, as well. I guess from that standpoint it isn't maintenance friendly. But if you are going more than a level or too deep, you probably need to rethink your design, anyway. Font-size should be set sparingly. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- 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/
Re: [css-d] Table widths not the same with image in td
At 04:21 PM 3/7/2006, Scott Haneda wrote: http://newgeo.com/web/css/wide.html Top table, has an image in it 728px wide, with a 3px border You have declared the table width at 728px and the contained image width at 728px in inline declarations. Because the image width is declared in the markup, the browser is treating it as an intrinsic width. The browser is therefore expanding the table beyond its declared width to accommodate the intrinsic content width plus the border. Declare the image width to be 722px, and it should line up. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- 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/
Re: [css-d] Keeping an indent with an image
At 08:17 AM 2/27/2006, John Lockerbie wrote:
Paragraphs on my site have an indent of 2em for the second and
subsequent paragraphs; the first para has no indent. I use
p + p {
text-indent: 2em;
}
to effect this.
Where there is an image at the beginning of a para I use
img + p {
text-indent: 2em;
}
to keep the indented para.
This works. However, if I have a link from that image, which would
begin with a href=http://etc., then there will be no indent.
How do I alter my code to keep the indent?
If I can't sort out an
additional rule such as a + img + p (which doesn't work) I'll have to
use the method you suggest.
a + img + p would select the paragraph in the following markup:
alink/a
img /
pparagraph/p
Your markup is like this:
aimg //a
pparagraph/p
Is a + p too plebeian? You'll have to make sure you are OK with code
order and the cascade, but that selector is the one you want. Do you
have instances of links at sibling level with your paragraphs when
the links do NOT contain images, and you also do not want to preserve
the indent? I.e.:
atext only link/a
pparagraph/p !-- no indent here? --
If you do, then you will be forced to use classes. There is no way
currently in CSS to do something to a parent (or the sibling of a
parent) based on the child.
HTH,
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7b2 testing hub -- 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/
Re: [css-d] Approaching Designing for Multiple Browsers and Versions
Christian Heilmann wrote: @import also helps you if you want to not give MSIE 5/Mac (a discontinued browser that is hard to test for) a stylesheet. MSIE 5/ Mac understands @import 'foo.css'; but fails to read @import foo.css; I know Christian is aware of this, but just for purposes of the archive, he wrote this exactly backwards. IE/Mac FAILS to read URLs enclosed by SINGLE quotes. It DOES read URLs enclosed with double-quotes or no quotes at all. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- 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/
Re: [css-d] display:inline List Items and whitespace bug
Jeremy Boggs wrote: I've tried searching for a solution to this with no luck. Has anyone discussed whitespace bugs in lists, where the list-items are set to display-inline? Here's the test page: http://clioweb.org/test/listtest.html The CSS is in the header. All three of these unordered lists have list items that are set to display:inline;. I'm getting spacing around the list-items in the first example on this page. Actually, this is correct behavior for inline elements. This is so that, for example, you can use a construction like this: These little things can be emreally/em strongVERY/strong frustrating if you don't know the reasons why they happen. Note that you really don't need or want to emphasize or strongly emphasize the space between the elements. Instead, it is treated as a normal, anonymous text node. That node really only becomes a problem when you convert what is normally a block element into one that is inline, and thus aren't expecting the result. Is there a cross-browser way to fix this in CSS, without resorting to changing the code, as I do in the second example on the page? I am aware of no reliable way to neutralize this behavior in CSS. Sorry, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- 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/
Re: [css-d] Centering a List Menu
At 12:47 AM 2/20/2006, Tyson Tate wrote: I'm trying to create a centered menu using a ul that looks like so: http://ohgoditburns.net/wp-content/uploads/2006/02/desired_menu.gif The links are regular and don't use image replacement. Can anyone suggest a list menu technique that allows for centering? You've already received one reply which suggests inlining your links. That method will work, but will cause only the actual link text to be clickable. To do this with block links, so the entire width and height of each link can be clicked, you can float your links and list items. Set the UL width to the sum of the combined LI widths (accounting for margins, padding and borders, as necessary), and then set the left and right margins on the UL to auto. Depending on how you set the units on everything, you may not be able to center *exactly* using this method, but with judicious tweaking you can get close enough so nobody will know the difference. (If you need to support IE/Win 5.5 and older, you need to set text-align: center; on the parent element of your list in order to get the proper centering. Don't forget the reset the text-align value for child elements that need a different value.) HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- 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/
Re: [css-d] li gap doesn't show up in Safari, Mac IE
Bruno Fassino wrote: I have a list of image links in a list with no white space between the li's in the HTML. In Win IE and Firefox a gap appears around the images. In Safari and Mac IE, it doesn't. The list is here (with the borders turned on): http://calreefs.dreamhosters.com/calendar/index.php?page=calendarmain Summarizing: remove display: inline and alter the margin on the img, and add display: block on the anchors. That's one way, of course, but it begs the question of why you are using images for text links in the first place. Why not use text for text? It simplifies most of your layout issues, and gives your users the opportunity to resize one of the most important elements on the page. Use text-transform: uppercase; font-family: Arial, sans-serif; color: white; and text-decoration: none; (this last on both li a and li a:hover). Given how the layout on your site works, you may also want to give the links a background color, so that the link text will contrast even if user resizing moves them off the dark blue header background. Alternatively, allow the header div to grow with text resizing. This way you can also avoid IE hacking. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- 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/
Re: [css-d] List styles
At 01:07 PM 2/15/2006, Skip Knox wrote: I have read the W3C specs on list style type, but I have need for more and was wondering if anyone has figured a way to kludge this. Our university policy manual has a few sections that go ridiculously deep in numbering -- six or seven levels. The list style types cover the first four levels but then it breaks down. In theory you could do this with generated content (that's what it is there for, primarily), but since some browsers don't do generated content, I would regard the numbering as essential information and just hardcode it into the HTML, setting the list-style-type to none. I don't know of any other practical way to do what you are asking. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- 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/
Re: [css-d] List styles
Skip Knox wrote:
In theory you could do this with generated content (that's what it is
there for, primarily),
I did not see in the specs where one could control the punctuation,
even on generated content.
It is in the spec, but the spec is hard to read sometimes. Note the
grouping under the content property. [1] Do you see the + after
the brackets? That means anything in the grouping can appear more
than once. So this set of statements:
ol {list-style-type: none;}
li:before {content: ( counter(section, lower-alpha) ) ;}
li { counter-increment: section;}
acting on this markup:
ol
lilist item one/li
lilist item two/li
lilist item three/li
/ol
Would get you this, in a compliant browser:
(a) list item one
(b) list item two
(c) list item three
I would regard the numbering as essential information and
just hardcode it into the HTML, setting the list-style-type to
none.
Trouble with that is that the text isn't indented properly. It's
going to come out underneath the numeral or letter, as it does with
list-style-position: inside -- which is not acceptable to the
custodians of the policy manual.
That is the purpose of a hanging indent. Read the spec section on
text-indent [2] and experiment with negative values. I generally
like the look of -1em, but you can use whatever value you like. Be
aware that the negative indent will move the (hardcoded) counter out
of the normal block box. You may have to tweak some margin/padding
values on the list and list items to make all browsers display the same.
Thanks for thinking about it, though.
You're welcome.
1. http://www.w3.org/TR/CSS21/generate.html#content
2. http://www.w3.org/TR/CSS21/text.html#indentation-prop
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7b2 testing hub -- 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/
Re: [css-d] z-index? content menu hiding behind header
David Laakso wrote: Leading (line-height) is expressed as a raw number. There is no unit of measure(px, em, %) used with it. The validator is just being a little over-zealous, and complaining about a parse error open string. line-height: 2; is correct. To make the *validator* happy, close the string, like so: line-height: 2.0; Note that a validator bug has been filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=2307, but there appear to be very few developer resources available to make fixes to this tool. If anyone out there is a bored developer, this might be one way to help the community. In any case, since we know that line-height: 2; is correct, I would argue that there is no need whatever to make the validator happy. It is a tool to help you, and you should feel free to ignore it whenever you are certain it is wrong. -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- 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/
Re: [css-d] Line-height in drop-down not adjustable
At 02:06 PM 2/6/2006, [EMAIL PROTECTED] wrote: I can't seem to alter the line height in the drop-down, which is too high in IE. I believe this is the white-space bug. IE will render the white spaces between list items. One good technique for defeating the bug is to put the white space inside the list item tags, like so: ullistuff/li limore stuff/li liand so on/li/ul Note that the line break is INSIDE the tags, so there is no white space BETWEEN the tags. That's generally the easiest way to do it, although there are other methods, as well. A second issue is that I've used the !important hack for display in IE, although I've paid attention today to the conditional comments suggestions. Can I jump in and out of these conditionals - as I might when intermixing PHP code with HTML- or is this used in some different manner? You can't put conditional comments directly into a stylesheet at all. Typically, they are used to serve up a link to an independent IE-only stylesheet, like this: head link rel=stylesheet type=text/css href=regularstyles.css / !--[if lte IE 6] link rel=stylesheet type=text/css href=ieonlystyles.css / ![endif]-- /head Note that the conditional comments do not appear inside a style block, but are used directly in the document head to serve a link to a stylesheet. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- 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/
Re: [css-d] Stop the cascade
At 11:25 AM 2/2/2006, Zoe M. Gillenwater wrote: Brian Ogden wrote: Is there a way to do this: div style=text-align:centerSome Content div id=this one must be nested in the one above style=text-align:none/div /div In other words how do I stop the cascade? You can't stop the cascade. But every property has a default value, and you can set a property back to its default value in the second div. In your case, use text-align: left;. Just to be clear, you can reset the property to the value of your choosing. If you know the default value, you can pick that one and explicitly reset the property. What you can't do, though, is reset the property to whatever it would have been otherwise. For example, suppose you have the following: body div style=color: red psome text/p /div /body The paragraph will inherit the red text color, so the words some text will ordinarily be red. You can explicitly reset this to some other value. However, there is no way in pure CSS to tell the paragraph text to be the same color as the body text, unless you explicitly know the color value of the body text. (In most UAs it will default to black.) There is no way to uninherit or zero out a property value. Once a property has a value, you need to explicitly override that value. I don't know if that makes a difference to you or not, but I wanted to note it since there are times when this can be an issue (especially when doing a redesign). HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- 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/
Re: [css-d] Problems with IE 7
At 03:07 PM 2/2/2006, Eric A. Meyer wrote: Thus the IE7 CSS support page on the wiki (the URL of which I added to the list footer appended to every message). Just a request to those making contributions to this wiki page (which I hope Microsoft will locate and find useful): Please be sure to document that you are testing IE7 *beta 2*. That way as Microsoft releases updated beta versions, we will have our bug reports properly catalogued by applicable version, and can delete any reports of issues they fix (or can update the entries if the fixes are only partial). Thanks, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- 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/
Re: [css-d] CSS validator confusion
Theresa Mesa wrote: Why, when I enter the URI for my website, http://mesadesignhouse.com , into the CSS validator, does it tell me that padding: doesn't exist for one of my rules (div#sidebar), but it doesn't point out all the other instances where I *do* use padding with impunity? It is warning you about padding:. Have you used something other than simple spaces or tabs for your whitespace before this property? It could be that the characters you used are unexpectedly being interpreted by the parser as part of the property name. And why does it give me all those warnings about colors and background colors when I'm using the divs as containers only, and colors are addressed elsewhere in the CSS code? It doesn't look elsewhere in the code. It is a simple machine check, and warns you if the code is valid but could present a problem. For example, one color warning you get is this one: You have no background-color with your color : div#nav a:link What if somebody out there who hates not knowing where the links are on the page (or who has trouble seeing in general) has set a light background for all links in a user stylesheet? Now this user may be able to tell these are links just by looking at them, but he may not be able to read them any more, since the contrast has been destroyed. It's up to you if you want to fix something like this. The validator just points it out in case you overlooked a possible problem. See the code validation page on the Wiki for more info. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Using display: inline; for navigation lists
cj wrote: from what i understand, one newbie to another, is that you can *either* float or display, but both don't happen at the same time (unless you consult with IE). if you float, it means that display is effectively ignored by standards-comliant browsers. Well, almost. When an element is floated, its display value is automatically set to block. That's almost the same thing, but not quite. floating means that the li no longer has a real height or width. Again, not quite. In modern browsers that follow the CSS2.1 spec, the float gets the width of the content (sometimes referred to as shrink-wrapping) up to 100% of the available space, at which point the content will wrap. The exception is IE5/Mac which slavishly follows the 2.0 spec and will default to 100% width. If you need to support IE5/Mac, you will need to supply a declared width. (Em-based widths often work well for this purpose.) The height is defined as the height of the content, subject to the wrapping rule I mentioned. displaying them inline keeps kind of their same basic characteristics, but they are no longer block and therefor don't take up 100% width. If they are links, inline display means they are not clickable over the entire width and height; only the text itself can be clicked. Floating links are clickable anywhere. On the downside, centering a menu based on floats requires extra markup. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Inconsistent unordered list
At 01:43 PM 1/25/2006, you wrote: Greetings: I am styling a two level unordered list with each item hyperlinked. The first level behaves as I have dictated by CSS. The second level ul does not. Does anyone have a solution? Thanks in advance. ul liitem1/li liitem1/li ul liitem1/li /ul /ul You need to get the markup correct. Although you have indented your inner UL as if it were a child of an outer list item, in fact the second UL is a direct child of the first UL. This is not valid HTML. Correct markup fragment would be: ul liitem1/li liitem2 ul liitem2a/li /ul /li !--This is where the outer list item closes-- /ul I'm guessing that will fix most if not all of your problems. If it is any consolation, this is an easy and quite common mistake. The validator is your friend. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Organizing CSS
At 05:37 AM 1/21/2006, Jesse Skinner wrote: Bill Moseley wrote: I just looking for a few tips on how to organize CSS files. Of course there's no one-right-way to do this, but here's what I would suggest. Have one master CSS file, say style.css, that every page references. Inside the style.css, put everything that is common across all brandings. You may even want to put the default branding in this file. Then, at the end of the file, put: @include green.css; You have just violated the CSS Specification, and compliant browsers are therefore free to ignore green.css. [1] Included CSS files must come at the beginning of a stylesheet, before any property/value declarations, not at the end. If you import *all* of your styles, as someone else suggested, then this method could work. However, if you have any direct declarations in the stylesheet, the import statement must precede them. 1. http://www.w3.org/TR/CSS21/syndata.html#at-rules HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Overflow problem in FF
Well Damn wrote: When the outer div is smaller than the larger div, i'd like it to hide the text -- not wrap. The code below works fine in IE, can anyone suggest what I'm doing wrong for firefox? div id=testdiv style=border:1px solid blue; width:200px; overflow:hidden div width=100% ul li A test div.A test div.A test div.A test div.A test div.A test div.A test div./li li A test div.A test div.A test div.A test div.A test div.A test div.A test div./li li A test div.A test div.A test div.A test div.A test div.A test div.A test div./li li A test div.A test div.A test div.A test div.A test div.A test div.A test div./li li A test div.A test div.A test div.A test div.A test div.A test div.A test div./li /ul /div /div That code looks the same to me in FF 1.5 and IE6, even if I write it so the inner div uses a style declaration instead of a width attribute. The inner div holds at the 198px content width and expands vertically to accommodate the wrapping list items. This is the behavior I would expect. If I make the inner div a width of 100em (instead of 100%) then the list items don't wrap and the content to the right is hidden. But this behavior, too, is identical in both browsers. What differences do you see? Perhaps you might post a complete page, in case something else is interfering. -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Changing Span in link on hover
Julian Voelcker wrote:
I have a span within a link to provide a block of colour which I want
to change the colour of when the mouse is hovered over the link, but am
getting muddled on the correct formatting of the css.
a href=#span class=redblocknbsp;/spannbsp;Link text/a
I would have thought this would work:
a:hover span.redblock{background-color:#AE0042;}
but is doesn't - any ideas?
This is an IE/Win bug. IE needs you to trigger some kind of action
on the anchor when you hover in order to recompute the properties of
the span. The good news is that the action on the anchor doesn't
actually have to make a difference. So, for example, assuming your
anchor already has a white background, the following should work just fine:
a:hover {background-color: white;} /*bugfix for IE-Win*/
a:hover span.redblock{background-color:#AE0042;}
This page gives you a detailed list of properties you can use to
trigger the redraw in IE/Win:
http://www.tanfa.co.uk/css/articles/pure-css-popups-bug.asp.
HTH,
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Question about the adjacent selector
cj wrote:
this is one example of css that looks like it's working in my own work:
.wrapper-div.solo,
.wrapper-div.multi {
border-top: 2px solid #4e94d5;
border-left: 2px solid #4e94d5;
}
In IE/Win, this will select either of these elements in the markup:
div class=wrapper-div solo/div
div class=wrapper-div multi/div
That's the good news. The bad news is that IE/Win will also
incorrectly select either of these elements in the markup:
div class=solo/div
div class=multi/div
In IE, a multi-class selector is over-inclusive, so in one sense the
selector is successful. You just aren't using .solo or .multi for
anything conflicting, or you have coincidentally over-ridden the bad effects.
HTH,
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] right and left justify
At 01:20 PM 1/13/2006, Vic Rauch wrote: I have a listing of seminars that are happening on 3 different days and would like to list these with the seminar time right justified, then the seminar title and description left justified just to the right of the seminar time: 9:00AM -- Seminar Title presented by Geo Green and his host of illustrations. Don't rule out a table, here. This is definitely table-appropriate data, and marking it up with a simple, semantic table should probably be preferred. If there is some reason why you cannot use a table, you could float each item to the left. The floated times would get text-align: right, and the floated descriptions would get text-align: left. Each floated time would also need clear: left applied. Apply widths, padding, and margins as needed. But do consider using a table. -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Question about the adjacent selector
Zoe M. Gillenwater wrote:
Does this accurately describe the div above:
about + home {color:black};
No. that would be
.about.home { color: black;}
Interesting. Do you know the name for this kind of styling? I'm going
to test it in various browsers right now.
I suppose it's just called multiple class styling. IE doesn't support
it fully. An easier way to get what you want:
.about, .home { color: black; }
Actually, that formulation could well break something you don't want
broken. Note that .about.home will break in IE/Win, which will apply
the rule to everything with the home class, completely ignoring the
about class. However, modern browsers will get it correct, and
only apply the rule to elements with both classes. Zoe's method will
apply the rule to any element with *either* class in all
browsers. That is probably not what you want.
FWIW, support for multiple class selectors is supposedly on the fix
list for IE7.
HTH,
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Specificity Problem
Philippe Wittenbergh wrote: On 10 Jan 2006, at 3:21 am, Adam Kuehn wrote: [1] http://www.littleandreid.com/mentaidyn/about ul class=mainnav lia href=/ id=menu_defaultspanHome/span/a/li lia href=about class=active id=menu_aboutspanAbout/span/a/li [--more links--] /ul But in this case, the CMS (textpattern) and the plugin used for generating the menu does the correct thing, by adding the class .active to the a. It is just a question of specificity to apply the class .mainnav li a:link is more specific than just .active Yes, except the presence of the ID could complicate things as the ID could trump any number of classes. I agree that if the CSS is constructed properly, your way should work, but the pre-existing ID makes it a bit tricky. The author would need to make certain that any CSS selectors which use that ID do not contain rules the author wants overridden by the .active class, or the CMS would need to be configured to swap out the ID (which could get fairly complicated). Good construction will make it easy, though, as the rest of your post suggests. -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Specificity Problem
At 01:11 AM 1/7/2006, Rahul Gonsalves wrote:
[1] http://www.littleandreid.com/mentaidyn/about
ul class=mainnav
lia href=/ id=menu_defaultspanHome/span/a/li
lia href=about class=active
id=menu_aboutspanAbout/span/a/li
[--more links--]
/ul
Now, I want to assign the class Active to have the different
background. What should I do? This changes from page to page,
dynamically, so I can't use the ID property.
Actually, you can. IDs can be used once PER PAGE. So long as you
use the ID only once on each page (which should be the case in this
situation, unless I am badly misunderstanding you),
Yup. :-)
But that's because I was unclear about _what_ I want to do. I want
the active link to be highlighted with a different colour from the other links.
So I assumed.
The active class is generated dynamically by the CMS. Therefore,
by just adding the .active class in my global CSS, each page now has
the active link highlighted.
Yes, but you had a specificity problem using just .active as your
selector, correct?
I can't see how I would use the ID class, unless I wrote a little
CSS header for each page, with the background for the currently
active ID specified. Not my idea of fun, even on the admittedly
small site, as above.
Uh, oh. Now we're in trouble. The phrase ID class doesn't really
make sense. Let me see if I can clarify with example code, again,
mostly so newbies checking the archives can follow along. Your HTML
(as noted above) had this:
lia href=about class=active
id=menu_aboutspanAbout/span/a/li
The class=active part is generated by your CMS, and you presumably
had something in your global CSS file that said something like this:
.active {background-color: foo;}
Your original problem was that this selector was not sufficiently
specific to override your other declarations for the anchor. I am
suggesting that your content management system should generate
something like this, instead:
lia href=about id=active
id=menu_aboutspanAbout/span/a/li
Note we have just changed the class=active to id=active. Your
global CSS file would then include something like this:
ul li a#active {background-color: foo;}
You should have only one active link per page, so this is legal in
CSS/HTML terms, and it makes your selector a whole level of
specificity higher. See
http://www.w3.org/TR/CSS21/cascade.html#specificity for more information.
There is at least one CMS system that doesn't like to generate
elements with ID attributes. However, that is a flaw with the CMS,
not with this use of an ID in this situation.
Perhaps that is more clear.
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Specificity Problem
At 02:11 PM 1/9/2006, CJ Larson wrote:
lia href=about id=active
id=menu_aboutspanAbout/span/a/li
Note we have just changed the class=active to id=active. Your
global CSS file would then include something like this:
ul li a#active {background-color: foo;}
One note about this: now he has two IDs instead of one ID and one
class.
Which is, of course, perfectly valid. There is nothing wrong with
attaching two IDs to a single element, so long as the attribute
values are unique within the document.
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Specificity Problem
At 02:56 PM 1/9/2006, Adam Kuehn wrote:
At 02:11 PM 1/9/2006, CJ Larson wrote:
lia href=about id=active
id=menu_aboutspanAbout/span/a/li
Note we have just changed the class=active to id=active. Your
global CSS file would then include something like this:
ul li a#active {background-color: foo;}
One note about this: now he has two IDs instead of one ID and one
class.
Which is, of course, perfectly valid. There is nothing wrong with
attaching two IDs to a single element, so long as the attribute
values are unique within the document.
Darn it. I hit send by mistake, before I verified this
claim. That is, of course, not correct. Only one ID per element is
allowed. I hate having to print retractions, but that's what I get
for doing this stuff while I'm busy with other things. Apologies, all.
The truth is, I didn't notice on the first run-through that the ID
was there. However, the CMS could still simply substitute one ID for
another, without affecting the general applicability of the
method. The CMS could either copy the existing information from the
original ID, or could substitute a class for the second ID. Yes, the
logic would be more complicated, but it could work.
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Specificity Problem
Rahul Gonsalves wrote: [1] http://www.littleandreid.com/mentaidyn/about ul class=mainnav lia href=/ id=menu_defaultspanHome/span/a/li lia href=about class=active id=menu_aboutspanAbout/span/a/li [--more links--] /ul Now, I want to assign the class Active to have the different background. What should I do? This changes from page to page, dynamically, so I can't use the ID property. Actually, you can. IDs can be used once PER PAGE. So long as you use the ID only once on each page (which should be the case in this situation, unless I am badly misunderstanding you), you'll be fine. I personally prefer to use the ID in this situation rather than !important as was suggested earlier, but that's really a matter of choice. Mostly, I just wanted to make it clear that IDs do work for dynamic assignments, so long as you use them carefully. It is a fairly common misconception that they don't, and it is worth noting the correction for users searching the archives. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Font-size keywords
Jonathan Carter wrote: I've noticed some people on this board always encourage the use of the font-size keywords (small, smaller, ect.) when setting a font-size in your stylesheet. I've personally never used these, but am interested to know their pros and cons. Can someone please help me understand when and why you would or wouldn't use these over ems or any other unit. Thanks. There is no easy answer to this best-practice question, and it is addressed rather thoroughly in our Wiki. You can head to the Wiki home page (listed in the footer of this and every list message) and scroll down to the Sizing Text sub-heading. I think you'll find most of what you need to know on those pages. Every method has its advocates and detractors. The ems w/ percent base is probably the most prevalent method currently, but that doesn't make it best for you. Read and decide for yourself. Good luck, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Box Model
Holly Bergevin wrote: (The MSDN page does not mention HTML4.01, the current W3C recommendation, but I have found that, for box model issues at least, as long as there is a complete doctype, IE6 will be in standards mode.) Well, the page you cite does say, Standards-compliant mode is also switched on when you specify a version of HTML that is not listed in the table, such as HTML 1.0 or HTML 3.22. Version 4.01 is not listed in the table, so therefore I would deduce that 4.01 always triggers standards-compliant mode, regardless of URL. I have not tested this deduction in practice, however, and would be interested to hear the results. Whatever the results of that test, however, it should not alter your conclusion, which I reproduce for emphasis: So, if you'll write /complete/ doctypes, of the type currently recommended by the W3C for HTML4.01 or XHTML1.0, and if [there is nothing - not even whitespace] preceding the doctype, then IE6 will render in standards-compliant mode. -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] css speed
kenny heaton wrote:
I've heard talk about how much faster css is at rendering pages than
table layouts, but I've never seen the proof (actual statistics). I
was wondering if anyone knew of a study on this.
I don't think a general study is possible, since the rendering time
depends largely on exactly what it is you are laying out and what
browser you are using to do so. A table can, for example, render
faster than a complex series of CSS floats. On the other hand, CSS
which relies on relative positioning and only a few layers
(absolute positioning or floats) is generally considerably faster
than a table for the same job. CSS generally (but not always) ends
up lighter weight in total than a table-based layout, and it has the
advantage that the CSS portion can be cached. This can lead to
significant savings under most real-world conditions. Try it yourself to see.
However, look carefully at any test that makes a general claim that
one is always faster than the other. It just isn't so.
My second questions is related to that, dose anyone know of any
resources on writing more optimised css. For example I was just
reading on this list in the talk comparing class to id and there was
mention there was performance difference between
element.class {}
and
.class {}
I'm the one who brought up this performance difference, and I was
careful to qualify that I only knew the facts for one browser (in
this case, Mozilla). A general attempt to optimize CSS may not even
be possible. Each browser vendor is free to optimize page display in
any way they can think of. Because of the specific way that Mozilla
has optimized selector matching, a class or ID without the element is
*slightly* faster to match than one that includes the element. That
may or may not be true with some other browser (and it might be
difficult to even discover in anything other than an open-source
implementation, unless you are willing to do brute-force technical
testing on thousands of combinations).
I think it is likely that optimizing CSS is probably not worth your
time. In addition to significant browser and platform differences,
network latency, page weight, and other overhead will most likely
completely overwhelm any effects from the CSS, which has been written
explicitly with progressive rendering (i.e. speed) in mind. There
are a few CSS3 properties that may have more significant effects, but
for now, if browsers support it, it is probably fast enough not to
make much difference.
Mind you, this is anecdotal and somewhat speculative. I know of no
formal testing on the subject that I would consider reliable.
HTH,
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] IE7 and Display Table
Gunlaug Sørtun wrote: No need to hide it from IE/win, as that browser doesn't understand 'display: table-cell' anyway. IE7 may though, since that property is part of the CSS-specs, and we may hope IE7 will make proper use of specs when it arrives. Is there any authoritative source that has commented yet about whether or not IE7 will support display: table*? Last time I checked the IE Blog, information on that subject was conspicuously absent. Anyone have any real information on this subject? (Please don't use this as an excuse to speculate; I can do that pretty well all by myself.) -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] class vs. id
Brian wrote:
Similarly, refer to elements with an ID by the ID alone: #m_home,
not a#m_home. There should only be ONE, so there's no need to
specify the element.
If you have a rule for
#container a {} and want new rules for #container #foo {} just give it
the rules - anything that requires overriding has to be explicitly set
in any case. What would be the difference between #container #foo {} and
#container a#foo {} if you want to override #container a {} rules?
There's no point in specifying a#foo.
There still can be a good reason to specify the element: human
readability. If it isn't otherwise obvious to someone maintaining
the site a year later (or to someone helping someone else on a list
like this one) that the unique #foo is actually a link, having a#foo
in the CSS can help in figuring out what the identified item is
supposed to be doing. My understanding is that specifying the
element does add fractionally to rendering time in at least one
browsing engine, but in my view that consideration is generally
outweighed by the ease-of-use for future development.
In any case, this particular issue is largely a matter of choice, and
either way is not clearly better than the other. Personally, I use
both methods from time to time, depending on the particular context.
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Notation
Carlton Gregory wrote: If I have a class defined for a table named tclass and that table has headers, rows, and columns, [c]an I refer to all rows in the above table in my CSS as .tclass tr That should work just fine. You would use a class on the row if you had some rows which you wanted to style differently from other rows in the same table. The way you chose will distinguish tclass tables from other tables which don't have the class, but will otherwise style all the rows within each tclass table in the same way. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] display: table-cell --- why?
Rolf Mortenson wrote: Okay... so I recently posted this test page with a different problem, but I wonder if this would have benefited from display: table-cell or it's brethren? http://www.monkeypuzzle.net/testfiles/html_test_gc3/test5.html Actually, this would have benefited most from an actual table. The CSS display:table-cell is meant to mimic the display properties of a table cell, but without actually having the table semantics at the markup level. So why would you do that? Table cells in traditional HTML have been granted some unique properties. They have the ability to vertically center content with relative ease, for example, something that can be difficult to accomplish using other display types. And they have the ability to expand based on the content of adjacent elements, something you would otherwise need a direct container to accomplish. And, as someone already mentioned in the thread, they have the ability to style arbitrary XML elements and make them behave as tables. But the key in using display: table-* is that you need table-like display properties without wanting to have table-like semantics for people/machines that don't get or use the styling information. In other words, there are times when those properties can be very handy, but it isn't that often. Most of the time, when you want to see a table, you want to actually have a table in the structure, too. And there is also the difficulty that while display: table-cell and its siblings could be useful in certain places in the real world, they actually aren't, simply because the vast majority of the population uses a browser that doesn't support those values. Maybe soon. -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Unable to fix p font size in specific class
M. Othman wrote: Generally speaking, positioning is a real problem in CSS, I think. I hear this kind of complaint a lot. This isn't really a fault of CSS, however, but is more a question of familiarity. We've seen table abuse for so long that we've become accustomed to it, and many developers aren't ready for some of the pitfalls of CSS. But those pitfalls can be overcome. A good way to learn is to take a site like ESPN (or maybe something a touch simpler that still breaks on resize) and re-work it yourself as an exercise. It is amazing how much and how quickly one can learn that way. Positioning in CSS is a problem in the sense that it is the steepest part of the CSS learning curve. But if you hang in there, you'll be able to do everything you could with tables, and more. Good luck, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Classes vs. ids
At 11:54 AM 11/29/2005, Mark Fredrickson wrote: Here's a general question about CSS that I've been able to quite figure out. If one has a DIV that will only appear once per page, which should one use: a class or an id? This is a FAQ, and as such it appears on the CSS-D Wiki. See http://css-discuss.incutio.com/?page=ClassesVsIds. It is worth your time to just browse the Wiki for awhile. For the situation you describe, either will work, but the ID is definitely more specific. See http://www.w3.org/TR/CSS21/cascade.html#specificity for the details on that subject. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] can't get images to float in IE5 Mac
Philippe Wittenbergh wrote: Actually, Adam is right, and wrong Something I realized after I went home last night. I was going from memory since I have a new job and my beloved Mac has been replaced by a PC, or else I would have tested it before I posted. Thanks for the correction, Philippe. -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] What´s wrong
Michael Wilson wrote:
.divBanner {
background: #DDD url(../theme_image/bannerbck.gif);
border-bottom: 1px solid gray;
padding: 0.2em;
}
In the above, adding the background color (#DDD) to 'background:' will
provide a default color for the element in the case images are
unavailable or undesired.
Just a quick note that the background color is ALWAYS applied, not
just when images are unavailable. This can matter if you are using a
partially transparent image as a background and don't want the
background color to apply if the image is loaded. At the moment,
there is no way in CSS to check for image loading before applying a
background color. This would have to be done through scripting.
This capability has been mentioned several times in connection with
CSS3, but (without checking) I don't think anything concrete has made
it into the draft specs, yet, and I'm certain nothing useful is
supported by actual browsers at this time.
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Inline styles vs. !important
Peter-Paul Koch wrote:
Consider this situation:
div#test {
text-decoration: none !important:
}
div id=test style=text-decoration: underline
Test DIV
/div
Mozilla, Explorer Mac and Opera obey the underline, Explorer Win and
Safari the none.
Who's right? Why?
Explorer Win and Safari are correct, in my view, but the issue is not
clear-cut. The 2.1 spec http://www.w3.org/TR/CSS21/ says in
section 6.4.1 that UA's should sort styles in the following order:
1. Media type and element match
2. Importance and origin in ascending order of importance (confusingly):
A. user agent style sheets
B. user normal style sheets
C. author normal style sheets
D. author important style sheets
E. user important style sheets
3. Specificity
4. Source order
In section 6.4.3, specificity for inline style attributes is
explicitly defined, and although they are given maximal importance,
the sort order for specificity as a whole comes after importance and
origin. Accordingly, I would say that !important declarations of any
specificity should outweigh style attributes. Moreover, this is a
desirable outcome, since it would give user !important style
declarations absolute priority over style attributes.
The spec could be more clearly worded, however. (Note, e.g., that
style attributes are never explicitly mentioned, nor is it absolutely
explicit that sort order means order in which declarations are to
be applied.) Further, the 2.0 version of the spec
http://www.w3.org/TR/REC-CSS2/cascade.html (which is technically
still the active Rec) is considerably more ambiguous. So, there is
probably some room for disagreement. Nevertheless, I think this
interpretation is the most defensible one from the text, and probably
the most desirable in actual practice.
Is that clear as mud?
-Adam Kuehn
Durham, NC
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] can't get images to float in IE5 Mac
At 01:43 PM 11/17/2005, David Agnew wrote: I'm probably missing something obvious, but... I'm simply trying to get one or more images to float to the right of some text. It works on Firefox and Safari (MacOS), and in Firefox and IE6 (Windows) - but I have no luck with Mac IE5. These pages illustrate the problem: http://www.vsi.cape.com/~dagnew/act/ http://www.vsi.cape.com/~dagnew/abt/beacon.php I'm using DTD XHTML 1.0 Transitional. The most pertinent CSS is: Actually, the most pertinent CSS you have is mixed in with the markup: img src=../img/soccergame.jpg width=400 alt= style=float: right; margin: 0 0 4px 4px / Note that there is no width on the float. Mac IE is the only browser that, by default, gives widthless floats 100% width, in slavish adherence to the mostly-superceded 2.0 version of the spec. That means there is no room for the image to be to the right of inline content. To make IE happy, you will need to declare a width on the float. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] ADMIN: Re: Too Funny, and (yes) really off topic...
Christian Heilmann wrote: But, on a quasi-related note, I have this thing about comments appearing on production... Comments, as far as HTML goes, should only be for developers. Language like F**king table isn't appropriate for the end user, and neither is the bytes used (wasted?) on transmitting it. To wrap up: http://www.kuro5hin.org/story/2004/2/15/71552/7795 And let's really have that be a wrap on this off-topic thread, please. Thanks, -Adam Kuehn CSS-D List Moderator __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] ADMIN: Re: MovieMadeProductions.com
Steve Tchorzewski wrote: Oh, sorry about that. That email was not intentionally sent to the mailing list. I must have CC'ed CSS-Discuss on accident while composing that e-mail. Apology accepted on behalf of the list. So chill out asshole. On the other hand, flaming of any kind is against the list policies, and may subject you to the unsubscribe button. I'm not inclined to do that for a first offense, but vulgarities are inappropriate in this venue. Anyone who has the slightest doubts about that should be re-reading the list policies at http://www.css-discuss.org/policies.html. Let's keep the posting civil, please. Thank you, -Adam Kuehn CSS-D List Moderator __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Use of non-standard font in declaration?
Tom Dell'Aringa wrote:
.SubMenu a { font: 11px Interstate-Regular, Verdana; color:
#947D37; text-decoration: none; }
I
don't remember this being what I'd consider a standard web font,
particularly across platforms. Can anyone advise on how widespread
Interstate-Regular is?
The best source for this sort of information that I know of is
CodeStyle http://www.codestyle.org/. As you can see,
Interstate-Regular doesn't make the radar for any platform. Having said that:
I'm particularly concerned because the x-width of Interstate-Regular
vs. Verdana is quite
different. (They also need to declare a generic font family, which I
will make sure they do.) My feeling is that this is not a good idea
I don't see how it isn't a good idea, just so long as you design with
some flexibility in mind - which you should probably do, anyway. The
thing is, even something as generic as Arial only shows at 95% on the
survey, so you can never be certain how your viewers will be seeing
your page. Allow flexibility in all dimensions and you will be much
safer. Here the designers have provided an obscure ideal font, a
reasonably generic specific fall-back, and you'll add the really
generic fall-back. That part is done completely correctly, even if
the named fonts are quite different. The trick is in making a
flexible layout that accommodates this way of doing business.
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] How to extend background-repeat:repeat-y to entire height of container?
Guy K. Haas wrote: Please give me a clue How can I make the left and right edge gradations in http://covinahigh68.com/classpageACxx.htm extend all the way to the end of the viewport? Mozilla, Safari, and Opera on Mac all show the gradations at the viewport edges since you applied Georg's fixes. However, there are a couple of other issues, which unfortunately I don't have time to sort out for you at the moment: The gradations don't appear at all in IE5 Mac. I don't have time to take a close look, but I'll bet you'll find something that can help you to fix that on Philippe's excellent IE5 Mac site here: http://www.l-c-n.com/IE5tests/. Safari (2.0.1) has an issue with the table, giving it only about half the width it gets in the other browsers. You have not specified the background color for your page (some of us don't use the default white). [Yes, the CSS is very untidy, but I wanted to get it working before getting it reorganized.] I would be careful with this approach. Order matters in CSS. I have found that if a site is not working as I expect, sometimes simply cleaning things up will fix the problem. On the other hand, if I clean up after things are working, occasionally something will break. As a general method of working, I find it is best to keep things ordered as I go along. HTH, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] background color/color declarations - why?
Pringle, Ron wrote: I'm trying to understand exactly why the W3C CSS validator now spits out errors for instances where you do not declare a color on a property with a background-color declaration, or vice versa. It doesn't. The validator spits out WARNINGS for that situation, not ERRORS. Those are very different beasts. This has come up a lot recently. Please search the archives and read the Wiki validation page. http://css-discuss.incutio.com/?page=CodeValidation Am I missing something here? I don't understand the point of the validator invalidating my css on these issues. I'm inclined to ignore these issues with the validator, but at some point I'm going to have to explain to my bosses exactly WHY the code doesn't validate and why that's ok. Just to reiterate, the code DOES validate, which should go a long way toward satisfying your bosses. -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Mac Problem (site causes browser crash)
Shane Porter wrote: Following a site check (thanks everyone), it transpires that the site: http://www.freshclickmedia.com/previews/endo/home.htm causes a browser crash on the Apple Mac (reported specifically on IE 5.2.3, but I'm now concerned about other mac browsers.) The CSS is at: http://www.freshclickmedia.com/previews/endo/css/endo.css (default stylesheet) First, don't worry about other Mac browsers. They work fine on your site, and Mac IE is known to be quite quirky by today's standards. Second, you have made extensive use of the inherit keyword. As you can read about here http://www.l-c-n.com/IE5tests/misc/#crash, Mac IE does not like that keyword. As an experiment, I simply searched for and commented out all instances of that keyword and your site worked just fine. I expect you are using all those inherits in order to placate validator warnings about color and background-color. If so, I would suggest simply ignoring the validator. You still have valid code, and all your backgrounds are working just fine at any zoom level that doesn't cause element overlap (which for me occurs at 300%). A warning means something could go wrong that can't be mechanically checked. If a human check shows everything is fine, the warnings can be safely ignored. If there is some other reason for having all those inherits in there, hopefully Phillipe's pages will suggest some useful workarounds. HTH, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Website Copying was (Hummmmmm :0))
Trevor Boult wrote: I had noticed the source code stuff but wanted to know how much does someone have to change a site before its become their property?, hence me asking the comparison. OK, time to put the moderator hat on. As fascinating as this topic may be, it is not germane to a CSS mailing list. Please send your responses to Trevor off-list, and feel free to continue your discussions there. There should be no more posts on this topic hitting the list. Thanks, -- -Adam Kuehn CSS-D List Moderator __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Can I make my link attributes differ by table?
James Crispino wrote:
I was wondering if I could set the link attributes separately for
links contained within a specific table.
Certainly. Give your specific table an ID attribute, and then just use:
#tableID a:link {color: myColor;}
#tableID a:visited {color: myOtherColor;}
If that doesn't work for some reason, post the URL to the forum and
we can take a closer look to see if something is interfering.
HTH,
--
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
RE: [css-d] Any complete resources for inline CSS?
At 11:27 AM +1000 10/19/05, Peter Williams wrote: From: css man Does anyone know of any tutorials, reference or other sites that focus on inline CSS? CSS isn't different when it is applied inline, in a style element, or in an external stylesheet. It isn't fundamentally different, but I can think of at least two common gotchas related to inline CSS: 1. Inline CSS is always of the highest specificity, applying in preference to anything in a style element or external style sheet. [1] 2. Because they are parts of the selector and are not style properties, pseudo-classes and pseudo-elements cannot be used in a style attribute. Thus you cannot apply, for example, :hover or :visited styles on an element (not even on an anchor) from within a style attribute, nor can you use generated content. Dynamic effects cannot be achieved through inline styling alone. Although it does have its uses, make sure you know why you want to use inline styles. As Peter suggests, placing the CSS inline does remove a good deal of the flexibility and ease of maintenance that makes CSS such a powerful and valuable tool. 1. http://www.w3.org/TR/CSS21/cascade.html#specificity Good luck, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
RE: [css-d] Line break issues
Yeah, but not every paragraph will have a br / at the end of it. Those are the cases where I need to do this. Margins are the way to go, here. Do you need this extra space at every occurrence of a paragraph, list, etc., or only on some of them? If on only some of them, you will need to apply a class or use some kind of contextual selector to single out the ones you want. The most practical solution will depend on your specific situation. If you can provide some more details (best: provide a URL), we could express more definite opinions as to the best method. -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
RE: [css-d] Line break issues
At 11:52 AM -0400 10/19/05, Chad Calhoun wrote: I can't add a margin to p because I only need it to apply on the first paragraph there (with the br //p). I can't add a bottom-margin to all br tags because it would create a margin in the middle of the paragraph and still would have inconsistencies. What you need is to style br:last-child, but this solution requires a CSS3-capable browser (Mozilla understands this selector). If you want to bring IE along for the ride, however, I'm afraid you are stuck with classes, search replace, or scripting, as others have suggested. Sorry there is no easy answer for this particular problem. -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Simple Question About Sign
htmlbody #color_me_green {
color: #00cc00;
}
I have never seen thesign used in a CSS style sheet. What does
it do?
I would suggest reading the selectors portion of the CSS spec
http://www.w3.org/TR/CSS21/selector.html. As you can see from that
chart, a is the child selector. So while div p means find any
paragraph nested, however deeply, in a div; divp means find only
those paragraphs that are *directly* nested in a div. As you can
see, this combinator can be used with any two elements.
IE/Win does not understand the child selector, so these days it is
mostly used as a hack to feed values to browsers other than IE/Win.
Hopefully, that will change when IE7 is released.
... Why not just use a dot in that code?:
html.body #color_me_green {
color: #00cc00;
}
No, that is a completely different can of worms. The . is the
class attribute selector. Your code would select any html element
with a class of body. Class selectors are very common and useful
creatures. You should study them. Indeed, as I mentioned, I would
read that entire section of the spec carefully. It is very important
to understanding how CSS works.
HTH,
--
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
ADMIN: Re: [css-d] scrollbars in div on MAC
Arlen Walker wrote: \IE for MAC is a AWFUL browser. And therefore is no longer being developed. Just a factual correction: IE/Mac is an awful browser because it is no longer being developed. And to issue a list correction: This thread is dead. Sorry, folks, I thought this one had died a peaceful death before I went home yesterday, so I let it slide. However, discussions of which browser is or is not awful and why or why not is just simply off-topic. Take your aesthetic debates off the list please. If you want to know what browsers you should be developing for, I suggest you take your inquiry to another forum (see http://css-discuss.incutio.com/?page=OffTopic for some possibilities). On the other hand, if you want to know how to make your site work with a given browser (without the value-judgement as to whether or not that's a good thing to do) then this is the place for you. Thanks, -- -Adam Kuehn CSS-D List Moderator __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] don't want image on last li link!
Bruce Gilbert wrote:
I have a uborganized list which are also hyperlinks. I am wanting an image
to appear to the right of the first two links, but not the third (or last).
ul.sitemap li a{
padding:0 1.5em 0 .5em;
background:url(/footer_dots.gif) right no-repeat;
}
ul.sitemap li.last a{
padding:0 1.5em 0 .5em;
}
The first declaration still applies to a link within the classed list
item, so your background image is still placed behind that link. You
can remove the repeated padding declaration, but you need to zero
the background, like so:
ul.sitemap li.last a {
background: none;
}
HTH,
--
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] First Post. Yay! Browser Discrepancy
http://www.northstar-emerg.com/main6.html
#1. the Internet Explorer rendition of the main menu has white lines
between the menu linksarg.
Hmm, it appears that the line is coming from the following bit of CSS:
/*** #navBar link styles ***/
/* hack to fix IE/Win's broken rendering of block-level anchors in lists */
#navBar li {border-bottom: 1px solid #EEE;}
I don't know what this hack is fixing, but it appears to be causing the
lines under each menu item. Removing should fix your problem.
You are correct Ronnow in IE the menu items have huge gaps
between them...ah well.
Which is exactly what the hack was fixing to begin with. This is IE
refusing to ignore white space between list items. Adding a
border-bottom is one of the more obscure fixes for the problem. You
can do the same thing by removing the white space between the list
items in the markup. A popular way to do this is to place the
carriage returns inside the li tags, like so:
div id=navBardiv id=sectionLinks
ul
lia href=#Home/a/li
lia href=#About Us/a/li
lia href=#Biographies/a/li
lia href=#Announcements/a/li
lia href=#Health News/a/li
lia href=#Contact Us/a/li
lia href=#Login/a/li
/ulbr /br /
/div/div
A little odd to read at first, but effective and completely avoids
the need for the underline.
BTW, I'd remove those br / tags, too. Use bottom margin or padding
to get the spacing you need.
HTH,
--
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
ADMIN: Re: [css-d] Say no to CSS hacks with branching techniques
Thierry Koblentz wrote: Clean code? I'll mention the pros and cons of this important issue when others will stop using the box model hack ;) I understand that this is humor, and I don't mind to sound like I'm against a little levity, but let's take the thread off-list now, please, and spare our servers the extra load. Michael summed up the thread arguments pretty well, and unless someone has some other practical application aspect that applies and has not yet been mentioned, everyone should probably be willing to leave it there. Thanks, -- -Adam Kuehn CSS-D List Moderator __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] conditional images
Sam Partington wrote:
I have a page with mutiple div class=article attributes. inside
each one of them I have another div with a image on it so it's
something like this
div class=article
div class=article-imageimg src=.../div
/div
div class=article
div class=article-imageimg src=.../div
/div
div class=article
div class=article-imageimg src=.../div
/div
*Note, this is not the complete markup, is just a simple testcase ...
Is it possible to write a css that AUTOMATICALLY only shows the image
on the first div ?
I just realised there was a typo in my last message. The CSS selector
should have read
div.article div.article-image img
{
display: none; /* or however you want to do the hiding */
}
div.article:first-child div.article-image img
{
display: inline; /* or however you want to do the showing */
}
note the : after article in the second selector
I'm not sure that your :first-child selector will work in the way you
intend in an arbitrary layout. The selector div.article:first-child
will select a div of class article which *is itself* the first child
of some other element (in this case, any other element). So if the
line of divs are in their own container with nothing else in front of
them, this method will work. But if there is any sibling-level
element in front of them, it won't. Also, since IE understands the
first selector but not the second, that browser will hide everything.
A better method might be to use something like this:
div.article img { display: inline; /*or no selector at all for this*/ }
div.article+div.article img {display: none; }
This will hide the images after the first, but only in browsers that
understand the adjacent sibling selector. In browsers that don't get
it, all the images will display. The caveat is that you cannot have
any sibling-level elements in between the classed divs (arbitrary
text nodes would be OK, but not actual elements). We don't know the
full layout, so this method may or may not be suitable for Grillo's
needs.
Having said all that, I agree with Sam that the best method (and
probably the only cross-browser method) involves scripting.
--
-Adam Kuehn
Biomedical Programs Accounting
406 Nanaline Duke
Box 3567, DUMC
Durham, NC 27710
919-681-8825 (voice)
919-684-8346 (fax)
[EMAIL PROTECTED]
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Browser and platform compatibility
Gunlaug Sørtun wrote (among other good bit of advice): For cross-browser compatibility year 2005: rewrite all 'font:' so font-sizes are defined in 'em' or '%', and line-heights are in 'em', '%' or 'unitless', as IE/win can't resize fonts defined in px-units. There are very few use cases that require line-heights with units (indeed, I can't even think of a single one). I would strongly recommend that you use unitless line-height values as a matter of course. Only if you are dead sure that you want the COMPUTED value of a line-height to inherit should you use a unit value. Using units on line-heights is a very common way to break a website. -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Validator Woes
BJ wrote:
I just this morning got caught by similar. How many of us have used this?
.clearA {
overflow: hidden;
clear:both;
height:0;
margin:0;
font-size: 1px;
line-height: 0;
}
It no longer validates and is probably used in every dang stylesheet
I've got out there . . .
Once I changed it to line-height: .01em; it validates.
Do you have any reason to believe that a line-height of 0 is invalid?
When in doubt, check the spec. [1] As you can see, the value of
line-height can be a length. [2] Length units are specifically
allowed to be zero, and the line-height definition explicitly states,
Negative values are illegal. (And therefore, by implication, zero
values are allowed.) Further, if you add any unit to your zero
value, suddenly the validator stops throwing a parse error
complaining about an empty string. And again checking the spec [2],
the length unit indicator is explicitly optional for zero values.
Clearly, therefore, the validator is broken in this respect. I filed
a bug report.
More generally, please remember that the validator is a tool. It
helps you to check your work, but it is a computer program and not an
adequate substitute for reasoned human judgment. If you find a place
where the spec and the validator disagree, the spec is correct. This
is doubly so when the properties flagged continue to work just as
they always have in actual browsers. Neither Mozilla, nor IE, nor
Opera, nor Safari are directly connected to the validator in any way.
So don't worry about every dang stylesheet you have out there. They
all still work just fine.
1. http://www.w3.org/TR/CSS21/visudet.html#propdef-line-height
2. http://www.w3.org/TR/CSS21/syndata.html#value-def-length
--
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Weird inheritance issue?
Jeff Chastain wrote:
div id=container
div class=crWrapper
div class=photoBlock
div class=crWrapper ... /div
/div
div class=photoBlock
div class=crWrapper ... /div
/div
/div
/div
#container .crWrapper { border: 1px solid #f00; }
.photoBlock .crWrapper { border: 1px solid #00f; }
When I do this, all three blocks still have a red border. The weird
thing is that if I change the 'class=photoBlock' to
'id=photoBlock' and update the styles accordingly, I have red and
blue blocks. Why does this not work for a class, but will work for
an id (which I can't use as there are multiple 'photoBlock's)?
The cascade is working perfectly. You can review the general rules
here http://www.w3.org/TR/CSS21/cascade.html#cascade, and more
specifically to your problem here:
http://www.w3.org/TR/CSS21/cascade.html#specificity. It should be
obvious once you read those that #container .crWrapper will always
apply in preference to .photoBlock .crWrapper. So just make the
second selector more specific by including the container as part of
that selector, too. I.e. use these:
#container .crWrapper {rule}
#container .photoBlock .crWrapper {rule}
Now the selector with .photoBlock will always apply, regardless of
cource order.
HTH,
--
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Warnings in CSS validation
Tanya Renne wrote: Can someone give me some insight around the warnings I get when validating css? How seriously should they be taken? Is the goal to have no errors and no warnings? What is the impact of different warnings? The goal is to have a good, working page. The validator is one tool you can use to help you accomplish that goal. Pleasing the validator should not be an end in itself. Having said that, an error means that you have some CSS that is incorrect according to the validation profile you used. There may be some good reasons for having errors (e.g. using some CSS3 features, even though validating against the CSS2 profile). A warning means that the CSS is valid according to the profile, but may present problems for one reason or another. You need to look at both warnings and errors and make sure that you understand what each one is and whether or not it will break your page. How seriously you take them depends entirely on what they are. The most common warning is not specifying color and background-color together. Most of the time, this is not a show-stopping problem; however, it can be, so you need to look at your particular page and make sure. More information is available on the Wiki: http://css-discuss.incutio.com/?page=CodeValidation. HTH, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Header Width
Thierry Koblentz wrote: I'm not sure if this is a safe solution; I wouldn't use float without an explicite width... It is safe for all CSS 2 browsers with the sole exception of IE5/Mac. That browser, and only that browser, requires the explicit width. The strict width requirement has been removed as of CSS 2.1, so no new browsers will require an explicit width for floated elements, either. If shrink-wrapping is the preferred behavior, I would suggest leaving out the width for most browsers, and feeding the explicit-width approximations to IE5/Mac only. (For filters to use for this purpose, see the Wiki.) -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Header Width
Thierry Koblentz wrote: ... and using width:auto for NN4 only. NN4 takes width:auto, but not no width at all I qualified my remarks to limit them to CSS 2 browsers. I would not put NN4 in that group. However, if version 4 browser support is needed for your particular project, them the explicit assignment of the auto value would certainly be a fine idea and in any case will not harm the display in newer browsers. -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
RE: [css-d] Header Width
CJ Larson wrote:
Wouldn't you be able to have { display: inline; clear: both; } instead
of floating them?
It is certainly possible to inline them, but floating can carry some
important advantages, particularly if you are floating links. In
that case, floating makes the items block display, which, in turn,
makes the entire block area clickable. Inline elements allow
clicking only on the text. There are other difference, as well.
Inline elements cannot have an explicit width or height and therefore
also cannot accept margins. Sometimes those are desirable features,
and sometimes it doesn't matter so much.
Incidentally, if they are not floated, the clear is irrelevant unless
there are preceding floats. The ability to clear can be another
advantage or disadvantage of floating, depending on the layout.
HTH,
--
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] setting initial height for a DIV: is it possible?
cappellano wrote: Is it possible to set an initial height for a DIV? I want to use height: auto for this DIV overflow, but as it contains a bg image, I need to start it with an especific height to show the image. Is it possible? It is certainly possible to set a minimum height. Just specify min-height: [length]. You can separately set the height to auto. This works in most modern browsers. Naturally, however, this does not work in IE/Win. However, IE will (incorrectly) expand a DIV to fit its contents, regardless of what you specify as the height. So, if you don't mind using hacks (see the Wiki), you can set the min-height, and then feed a height value only to IE/Win. That should make IE do what you want, too. Good luck, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Now possible: CSS Constants
At 6:08 PM -0400 8/31/05, Eric A. Meyer wrote: http://www.shauninman.com/plete/2005/08/css-constants (detailed explanation) http://www.shauninman.com/plete/2005/08/css-ssc-quickie (latest version) And in case anyone is wondering about CSS running being output via PHP, Mr. Inman is indeed smart enough to set and send correct caching headers with the files, so your server won't have to pre-process every CSS call but will update when you change the contents of the PHP files. Very slick. -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Question about the list - Public apology
Scott Glasgow wrote: Adam Kuehn wrote: Scott Glasgow wrote: If I hit Reply All, it does go to the list, but sends a separate copy to the sender (which can be annoying to the recipient, I would imagine). [...] This page was written for you: http://css-discuss.incutio.com/?page=CssDiscussListHeaders.[...] I do not have a problem with this decision by the list moderators. I do, however, wonder why this was not included in what seems to be the list guidelines (the very definite ground rules) or any other of the information which I assiduously read whule subscribing. Perhaps it should be. It is definitely a FAQ, and as such we have put it on the Wiki, a link to which appears in the footer of every list message. But since this does come up from time to time, perhaps it needs to be more prominent. Thank you for the suggestion. I am not a newbie to the Web, nor to online communications, having watched lines of text being spelled out letter by letter at 300 baud back in 1983 on a character-mode-only 9 inch amber monochrome screen. Dang, you've got me beat. My first home modem was 2400 baud, and I could get 1200 baud on the school modems. I remember having to use AT commands, too, and I thank the software gods that I no longer have to remember what a DIP switch is. Please do not patronize me. A simple reply (using Reply and not Reply All) would have sufficed. I don't need all should be right with the world (not accurate in any event because it depends upon concrete action by every individual member to avoid duplicate messages) or public service ( if it's so public, why not put it in the information presented to all subscribers during the process of subscription?). But here I do sincerely apologize. I intended neither to patronize, nor offend. I've been on lists that do Reply-To both ways, and it can be disconcerting that this parameter varies from list to list. I was making an attempt to be light-hearted about this sometimes-annoying problem, but clearly the effort failed. I am sorry. I did, however, present that post as a public service. As I mentioned, this comes up from time-to-time, and I felt that a post from a moderator which reviewed the subject (especially including the part about avoiding duplicates) would be a good thing. There is a sharp divide as to whether or not our Reply-To policy is desirable, and I wanted to make sure that those who feel inconvenienced by it were reminded of a way we have to minimize some of the perceived negative impact you mentioned in your original post. I value this list, a great deal. The information available here is both unique and inestimably valuable, and I do not wish to be administratively unsubscribed. You are in no danger of that, certainly. (I believe it has happened exactly one time in the entire history of this list, thanks to the very high quality of our list members.) We do value your contributions, and I hope you can forgive the rantings of an old web denizen which were in no way intended as an admonishment. I look forward to reading your posts. Sincerely, -- -Adam Kuehn CSS-D List Moderator __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] CSS Height Question
Yazmin Media wrote: http://tnri.yazminmedia.com/news When I remove the height on .container, the background then extends as needed on the News page, but on other pages where the content is short than the viewport, .container no longer extends to the bottom of the screen. Have you tried playing with min-height at all? In Gecko, at least, if you set html and body to height 100%, and then set .container to min-height: 100% (but no explicit height), you get what you are after. Of course, IE doesn't recognize min-height, so you'll have to try to feed it the values you want in some other way. I don't have IE to play with right now, but perhaps someone else knows a solution for that browser off the top of their head. Good luck, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
RE: [css-d] Hacks, to use them, or not
Al Lemieux wrote: I'm in total agreement with Haoshiro. Hacks are just that - hacks. Its like using a screwdriver to hammer in a nail. A lot of them didn't work for me either. May I suggest that this topic is covered sufficiently on the Wiki? Please see these pages: http://css-discuss.incutio.com/?page=ToHackOrNotToHack - discusses this exact topic of whether or not to hack at all http://css-discuss.incutio.com/?page=CssHack - links to detailed discussions of many hacks and their possible shortcomings http://css-discuss.incutio.com/?page=CategoryBrowserBug - links to various bug resource sites http://css-discuss.incutio.com/?page=GoodCSSHack - attempts to define whether or not a CSS hack is good http://css-discuss.incutio.com/?page=AvoidingHacks - suggests workaround methods that avoid true hacks Not to pick on Al at all. It's just that this topic has been known to reach Holy War status. I'd rather not see that on the list. Very messy. Thanks, -- -Adam Kuehn CSS-D List Moderator __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] proper syntax for background-repeat x and y?
Richard Grevers wrote: On 8/11/05, Bruce Gilbert [EMAIL PROTECTED] wrote: I have an image that I want tile both verticall and horizontally so I declare it in CSS as : background-image: url(/test/images/BG_tile.gif);background-repeat: repeat-y repeat-x; which works just fine, but CSS validator gives parse error and says too many values. Is this not the proper way to so this? background-repeat:repeat; (or you could just not decalre it, bvecause I've yet to see a browser where it isn't the default setting.) Which is good, because such a browser would be non-conformant. The spec requires the default value to be repeat. See http://www.w3.org/TR/CSS21/colors.html#background-properties. I also wanted to point to the spec because the original question was about proper syntax. The spec is the authoritative source for those sorts of questions, for those who don't want to wait for an answer on the list. -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Firefox DocType blues
Michiel van der Blonk wrote: http://test5.caribmedia.com/doctype.html When we look at it, the validator says the HTML and CSS are flawless, but the CSS is not applied to the page! The same page without a doctype does apply the CSS. http://test5.caribmedia.com/nodoctype.html What's wrong? Your server is sending your stylesheet as type text/plain. Mozilla will accept that when it is in quirks mode, but when it is in standards mode it will (correctly) only accept stylesheets that are sent as type text/css. If you control the server, you can set this yourself. Otherwise, you will need to explain the problem to the system administrator of the server you are using, and ask them to configure the server to send the correct MIME type when serving .css files. Unrelated to you problem, please do not cross-post to multiple lists. List administrators lose sleep when they see cross-posts. If you really need to post to more than one list, send a completely separate message to each. Thanks, -- -Adam Kuehn CSS-D List Moderator __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] IE/Mac is the bane of my existence
Jon Trelfa wrote: Is there an easy way to program for IE/Mac? Is there a definitive guide out there to show *exactly* what problems I'm going to have when I use CSS/XHTML and how to work around them? Do I *really* have to accomodate that browser (^-^)? You will find loads of information specific to IE/Mac on Philippe Wittenbergh's site here: http://www.l-c-n.com/IE5tests/. It isn't a guide, per se, but it clearly outlines most of the really bad pitfalls that plague this browser. Obviously, you need to make your own decisions on whether or not to support IE/Mac. As you know, it is a dead browser. As such, it is becoming much less common, even on Mac-centric websites. (My last log showed that IE5/Mac accounted for less than 20% of Mac users, and less than 2% overall traffic, on a site I maintain in a Mac-heavy subject area.) Depending on your specific site, IE/Mac may well not be worth the trouble. Good luck, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] How to get one tag to inherit the same style as another
J. Kang wrote: For example, if I haven't defined a style to the p tag but I want my h5 tag to have the same style as the p tag, is there an easy way of doing that within the stylesheet? No, I'm afraid the only way to do what you want is to explicitly set the styles on both. There may be a JavaScript way to read the default style on p and then apply them to the header. That's out of scope for this list, however. Good luck, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] targeting readonly form elements
Brian Cummiskey wrote: I'm looking to add a simple background color to some form fields. all of these fields happen to have the readonly=readonly attribute attached to them. Without classing each input box, is there a way with css that works in IE6 to target those inputs based on the readonly attribute? In IE with only CSS? No. As you noted, you can do it with CSS if you add classes, and you can also use Javascript. But as of now, IE does not accept attribute selectors. Sorry, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Site Collapses
Roger Roelofs wrote: I have built a site at http://www.theriverchurch.info with the css at http://www.theriverchurch.info/styles/pages.css If I view the site in a small screen size the middle column ends up below the content column. Is there anyway I can stop this please? #navigation + warpper = 98.7% + 10px. At small screen sizes this can be greater than 100% The same is true with main-content and sub-content. How about expressing padding for these elements in % also? Alternatively, you could give a containing element for each area a min-width, which would cause browser scroll bars instead of drop-down. IE/Win does not recognize min-width, however, so this solution won't work for that browser. Some people use a spacer div to get around that limitation, feeding IE/Win only a width for the spacer equal to the minimum you want. Your call as to whether or not that method offends your sensibilities. Some people really hate doing it that way, but it does work. -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Firefox: little bug with text-transform and ß
Klaus Hartl wrote: If you use text-transform: uppercase; on an element holding text which contains ß, that letter transforms to SS (correct), but than, under certain circumstances (has to be one word or the second of two), the last letter is missing. In testing on other Mac browsers (Opera 7.54, Safari 2.0, and IE 5.2), none of them display the cut-off bug, but none transmutes the ß character to SS, either. Damned if you do, damned if you don't, it seems. -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Visual Artifacts in IE6
At 2:37 PM -0500 8/4/05, Martin Tschofen wrote: When I scroll down to see the footer, IE puts the last few characters of the footer that ends with company name, inc. on the next line on the left side of the screen. Sometimes it's just c. other times it's inc.. Anybody have any idea what else to try? It sounds like the duplicate characters bug. [1] Are there comments in your style sheet? If so, remove them and the problem should go away. 1. http://positioniseverything.net/explorer/dup-characters.html As always, PIE is the main place to go when you are looking for an IE bug. Good luck, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Odd boxing with html form
Keith Sader wrote: I've got a strange layout issue with IE 6.0 and a form. When I layout a form ala Man in Blue: http://www.themaninblue.com/experiment/InForm/margin.htm, I get really strange box sizing. The red-outline shows that the box for the labelinput/ is huge. It's much larger than a plain old label element by itself i.e. w/o a nested input or select. Has anyone seen this problem before? Here's a snippet of the html: fieldset labelEquipment Category select name=categoryName onchange=processCatChange(this) option value=empty selected=selected- Any -/option option value=Aerial LiftsAerial Lifts /option /select /label ... labelManufacturer input type=text name=manufacturerName value=/label labelModelinput type=text name=modelName value=/label ... etc. /fieldset If that is an exact code snippet, your problem may be because you have not closed the input elements. The site you posted uses an XHTML DOCTYPE and is very particular about closing all of those elements, e.g.: input id=firstName1 name=firstName1 type=text value=First name / Note the trailing / before the closing angle-bracket. Try closing those on your own site and see what happens. A good way to catch this kind of error is to validate your code before posting. See http://css-discuss.incutio.com/?page=CodeValidation for more on that subject. Good luck, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] IE5/Mac hates my site
Mimi Huang wrote: The only major browser left to support is IE5/Mac. And it's not cooperating. I was wondering whether someone could offer some tips/ideas/code on getting the design working in IE5/Mac. I'm really hoping this won't have to result in a complete rewrite of the CSS, because I'm *so close*. Site: http://chuang01.web.wesleyan.edu/avalerio/mockup.html CSS: http://chuang01.web.wesleyan.edu/avalerio/ie6win.css Without looking in great detail, it is most likely that your problem has to do with your extensive use of absolute positioning. IE/Mac has a few problems with that positioning scheme. For your page, I would start reading here: http://l-c-n.com/IE5tests/right_pos/bottom.shtml. (Indeed, I would recommend perusing all of Philippe Wittenberg's excellent site for anyone planning to support IE/Mac.) Hopefully, that site will get you pointed in the right direction. -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Formatting ordered lists
Keith Bloom wrote: Is anyone in possession of an explanation on how to style an ordered list? I'm trying to set a large font size for the number and a small size for the copy in the list item with out using extra markup. You need to use extra markup, at least for a cross-browser solution. The list marker uses the same styling as the list item, but you need to make them different. The only way to do that is to add an enclosing element (such as a span) for the list item contents. Sorry about that, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Background Images in Mac OS X / IE 5.x
Tim Zappe wrote: I am currently designing a website that will not display the background images in Mac OS X / IE 5.x. I'm baffled and I don't know what to do. Can someone much smarter than me please give me a hand. Much appreciated. Here's the link: http://www.western.edu/webmaster/redesign/ I explicitly deny being smarter than you, but I do have some experience with IE/Mac, which does not like URLs enclosed in single quotes. Use no quotes or double quotes in your image URLs, and everything will work just fine. Nice site, BTW. -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Reverse Stacking Order
Justin Piper wrote: By default, siblings with the same z-index are stacked according to their position in the document tree, with elements obscuring the elements which came before them. Other than by explicitly defining the z-index for each element, is it possible to reverse this, so that earlier elements are drawn above later ones? Other than by defining the z-index? No, there's no other way that I'm aware of, unless it involves some sort of complex DOM manipulations outside the scope of CSS. The purpose of z-index is to change the stack order, so I think you'd have to go with that. I don't even see that what you are asking for is even in any of the CSS3 drafts, although the Presentation Levels module comes closest. Without decrement, though, you'd still need to explicitly define each layer. -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Reverse Stacking Order
Justin Piper wrote:
I don't even see that what you are asking for is even in any of the
CSS3 drafts, although the Presentation Levels module comes closest.
Without decrement, though, you'd still need to explicitly define
each layer.
But unless mis-interpreting the spec, I'm not
sure how it would help in this case, even if it supported decrement.
If my style sheet included something like this:
div { presentation-level: 10; }
span { presentation-level: decrement; }
:below-level { z-index: 0; }
:at-level { z-index: 1; }
Then the elements' presentation levels would be
010 div
009 spanPanel A/span
008 spanPanel B/span
007 spanPanel C/span
006 spanPanel D/span
005 spanPanel E/span
/div
Which seems like it would put Panel A on top and stack the rest in
document order.
It is hard to know exactly what that would do, given that the
Positioning module is not drafted, yet. If the z-index property
could accept the EPL as a value (which would seem like a reasonable
thing for it to do), then it would be doing exactly what you asked.
If z-index only accepts integers, as currently, then you'd probably
need to use JS (or some other behavioral language) to discover the
EPL and assign it as a z-index value.
In any case, since we're talking about stuff that isn't even drafted,
yet, let alone implemented, perhaps we should take this off-list.
--
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] ADMIN: Music Files and CSS
Rimantas Liubertas wrote: On 7/21/05, T Shorrock [EMAIL PROTECTED] wrote: What about musican's websites - should they, too, remain silent? Yes, they should. Would you feel the same about your TV if it played soundtrack from five channels at once? Perhaps I was not clear before: This thread is over. If you feel you need to comment further on whether or not music should be played on websites, feel free to discuss that amongst yourself - OFF THE LIST. The rest of us do not need to hear it. Don't make the list admins get nasty with the unsubscribe button. That is all, -- -Adam Kuehn CSS-D List Moderator __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Specificity question
Reese wrote:
I'm having trouble with a moderately extensive site which has
only a rudimentary implementation of CSS. This is the CSS coding
relevant to my question:
4.
5. a {
6. color: #99;
7. text-decoration: underline;
8. font: bold 10px Verdana, Arial, Helvetica, sans-serif;
9. }
I'm trying to give a specific link a different style, but this
code [does not work]:
16. #alt a:link {blah}
Your first selector a applies to all states of all links. However,
a:link only applies to unvisited links. So if you have followed
the link and have not cleared your browser history, the first
selector will apply even when the second does not.
even this code:
16. div#alt a:link {blah}
17. div#alt a:active {blah}
18. div#alt a:hover {blah}
19. div#alt a:visited {blah}
does not work
Assuming you have the correct ID in the HTML, this should work,
although your rule order may cause confusion on hover. The rules
should always appear in LVHA order (LoVe HAte, if you need a
mnemonic). The way you have the rules ordered, the visited rule,
being last, will supercede the hover rule, so your visited links will
not appear to change on hover.
You later wrote:
#order a:link a:visited a:hover a:active {
text-decoration: none;
font: 900 italic;
}
That doesn't select what you think it does. The correct syntax would be:
#order a:link, #order a:visited, #order a:hover, #order a:active {blah}
Note the order of the declarations is not relevant here, but the
commas are required. Note also that I reiterated the #order part of
the selector to keep the specificity the same throughout.
I would recommend that you check the list Wiki/FAQ (address at the
end of each list message) to find a good selector/shorthand tutorial.
I think a quick review of how selector syntax works might be helpful
for you.
--
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Vertical Text
Ian Skinner wrote: I'm pretty sure the answer is no, but I would like to confirm it. There is currently no well supported way to orient text vertically with CSS, correct? There is currently no way, well-supported or otherwise, to do this with CSS. I thought it was being added to CSS3, but, surprisingly, I cannot locate such a thing in a quick check of the draft specs. If it is there, and someone has the reference handy, please share it. Sorry, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Safari 2.0, inline !important
Tim Brown wrote: h4 style=background-image: url(something.jpg) !important; background-image: none;.../h4 ... browsers that don't understand !important (NN4) still show a transparent area, which they should, and browsers that do understand !important still show a background image on the h4, which they should, except Safari (I'm using version 2.0 ... not sure about other versions) - which should show an image - shows a transparent area. I've not encountered this before, and the spec is pretty vague about how to handle inline styles. However, I would intuitively expect the same behavior you do, and if the other implementations agree, then you should probably file this as a bug with Apple. I doubt they would want to be different in this area and they probably just didn't contemplate inline !important rules very carefully. Good luck, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Safari 2.0, inline !important
Tim Brown wrote: Which spec are you talking about? I want to start reading specs. Sorry, it has been cited here so often, I forgot to consider that a new poster may not know. I was referring to the most current CSS specification, CSS 2.1, available at http://www.w3.org/TR/CSS21/. The specific section addressing the issue you raised is here: http://www.w3.org/TR/CSS21/cascade.html#cascade. I know CSS (2) fairly well, and I'd like to start learning why some rules behave differently in different browsers. Well, now that is an entirely different issue. Browser-makers implement what they can, or what they want to, or what they think is needed the most, and the reasons for their choices are often pretty opaque. It is very difficult to divine WHY the browsers do what they do. A major topic of this list, however, is figuring out how to fix things that work differently across browsers. In other words, we generally address WHAT the browsers do, without trying to tackle the why. So if you hang around with us, you'll be pointed to literally dozens of resources that describe what breaks where and how to fix it, or whether or not a fix is even possible. A great place to start with this aspect is on the list Wiki, which you can find here: http://css-discuss.incutio.com/. HTH, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Div's Vs Classes
Christian Heilmann wrote:
this is off-topic though and better suited for the evolt list
moderatorIndeed, most of this discussion was very much off-topic.
Please confine crusades to the off-list community.
Thanks./moderator
To respond to the concerns of the original post, the one pitfall I
can see in developing CSS with only classes is the potential for
conflicting declarations. In general, if one is using IDs, it is
easy to write things like:
#content a.external {color: blue;}
p.first a {color: green;}
You know that the first rule will always apply because of the ID. If
the first rule uses a class instead of an ID, however, and the rules
still appear in that order, the second rule will override the first,
and your external link in the first paragraph will now be
misleadingly green.
So when using only classes, you will need to be very careful about
specificity and rule conflicts. It will be a much more dangerous
environment to work in, and will make later changes to the code more
difficult, as they will be more likely to conflict with existing
rules. However, careful development practices could make it work. I
do agree with Christian, though, that it would be good to get with
the developers and see if you can't designate a few structural IDs
that could be used for styling. If they agree, that will help you a
lot. If they don't, you are covered when a later, last-minute change
breaks the display.
Good luck,
--
-Adam Kuehn
CSS-D List Moderator
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Div's Vs Classes
Some idiot (namely, me) wrote:
#content a.external {color: blue;}
p.first a {color: green;}
If the first rule uses a class instead of an ID, however, and the
rules still appear in that order, the second rule will override the
first, and your external link in the first paragraph will now be
misleadingly green.
No, it won't in this case, because I constructed the example poorly.
Please just ignore the specific example. Just notice that unexpected
conflicts are easier to come by and my sometimes bite you when you
least expect it. Thus, you need to be more careful, and expect
things to break more when you make changes.
Thanks,
--
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Using background-position and background-repeat together
Ray Dickman wrote: When I set the background-repeat on the right-hand border to repeat-y, I can no longer seem to control the image's initial vertical position (i.e. it starts immediately at the top of the div rather than, say, 70px down). Is this a known issue/correct behaviour? And if so, is there a way round it that doesn't involve hacking in additional non-semantic divs? I believe this is the correct (or at least prevelant) behaviour. You cannot vertically position a background image that is repeated on the y-axis. Similarily, you can't horizontally position a background image that is repeated on x-axis. Yes, that's correct. Just remember that repeat-y means repeat in both the + and - directions. That is, the image repeats down, as you probably expect; but it also repeats up, which you probably aren't expecting. You can see the example in the spec shows exactly this behavior with a centered background image: http://www.w3.org/TR/CSS21/colors.html#background-properties . The only work-around I know to get that repeat in only one direction is to add in the non-semantic container element you are trying to avoid. There have been proposals to add a repeat directionality into CSS3, but I'm not sure if they have been added to the drafts at this point (or perhaps it is there already and I just don't understand the draft specs well enough to see it). -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] General cascade question
Thomas Livingston wrote:
div#stylea{foo}
p.styleb{foo}
div id=stylea
p class=stylebbar/p
/div
styleb was not being applied until I did this:
div#stylea p.styleb{foo}
why?
I admit I'm not entirely sure what you're asking. You may need to
get more specific in your question. Let's say you have this:
div#stylea{ font-weight: bold; color: blue; }
p.styleb{ color: red; background: yellow; }
The word bar will be bold, blue, and have a yellow background.
div#stylea is more specific than p.styleb. Accordingly, anywhere the
two conflict, #stylea will apply and override .styleb. Hence the
text is blue, not red. However, both selectors still apply to the
element, so where the rules do not conflict, each will be applied.
Hence the text is both bold, and has a yellow background.
If you add div#stylea p.styleb the same principles hold: Anywhere the
selectors conflict, this one is more specific, and will win.
Anywhere they differ, all will be applied.
So add to the above:
div#stylea p.styleb { color: black; font-size: 2em; }
Now the text will be black, but still bold, still with a yellow
background, and now it will also be twice as big.
Does that help?
--
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] using percentages, paragraph too small within tables
Felix Miata wrote: But then I noticed use of not font-size, but font, and I thought about this: All font-related properties are first reset to their initial values http://www.w3.org/TR/CSS21/fonts.html#font-shorthand. So where is the initial font-size value coming from to make the inherited value 70% instead of 100%? Aren't initial values supposed to come from the browser? Why is .content table creating the initial value for font-size for .content p here? You aren't quoting enough of the spec. The full quote is this: All font-related properties are first reset to their initial values, including those listed in the preceding paragraph [i.e 'font-style', 'font-variant', 'font-weight', 'font-size', 'line-height' and 'font-family']. Then, those properties that are given explicit values in the 'font' shorthand are set to those values. In other words, the percentage font-size value given in the rule is an explicit value (here, 70%) and so that *is* the value used. On the other hand, if no value appears in the shorthand rule, then initial value would be used. But since font-size is always required as part of the font shorthand, effectively the font-size value is never set to the initial value determined by the browser, unless that value (==medium) is set explicitly in the rule. Clear as mud? Admittedly, the spec could be written more elegantly on this point, but I think the meaning is clear: If you set a value explicitly, that's the value for that property; if you don't, you get the default. HTH, -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] using percentages, paragraph too small within tables
Felix Miata wrote:
And so my question seems to
remain unanswered by the mud above. Let me rephrase my question:
html body {font-size: 80%}
p.one {font-size: 80%}
p.two {font: 80% sans-serif; }
...
p class=oneFrom reading the CSS spec, I expect this to be 64% of
the browser default./p
p class=twoFrom reading the CSS spec, I expect this to be 80% of
the browser default./p
Class two should be the same size as class one, according to the
spec. Why should they be the same size? The spec describes an
algorithm that works like this:
1. When encountering the font shorthand, reset all font values to the
initial values, but don't yet compute results.
2. Read the specified values in the shorthand rule, and substitute
those explicit values for any that were reset in step 1.
3. Compute the results according to normal rules of inheritance.
My real question is the meaning of initial. If it doesn't refer to the
browser default, what is the purpose of the reset that the font property
provides? Of what use is its reset function?
It does refer to the browser default, but since font-size is required
in the shorthand, font-size is always explicitly set and the browser
default never applies. On the other hand, let's change your example
a bit:
html body {font-style: italic; }
p.one {font-style: oblique; }
p.two {font: 100% sans-serif; }
p class=oneThis paragraph will be in the default font face and oblique./p
p class=twoThis paragraph will be in the browser's sans-serif
font face, which is probably not the browser default, because that
(required) value was explicitly specified. However, this paragraph
will also be in normal style rather than italic or oblique, because
that value has been reset by the algorithm and was NOT explicitly
specified./p
Hopefully, that example makes it more clear. If not, I'm happy to
try again, but it would probably be better to take it off list until
I can come up with an answer that you agree makes sense! :-)
--
-Adam Kuehn
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] textline partly overlaps float (the mysteries of float)
Ingo Chao wrote: Hi, while I was zooming the text-size in FF, I saw that one line of text partly overlaps the red float. http://www.satzansatz.de/cssd/tmp/lineinfloat.html I have the feeling that the line box may not overlap the float. Or is floating meant as the upper left (0,0) corner of the line box to be floated? Only parts of the line box overlap. So, when FF and Safari agree with overlapping the float, is this a bug? Or is it expected behavior? And if so, why? What do you think? I think this is undefined in the spec. As you say, it is Rule 5 in the float spec [1] that controls how high the outer top of the left floated box is. If you remove the bottom margin from your floats (which confuses the issue visually), this means the top of the left float will be precisely 4.5em from the top of the containing block. You'll be able to see that in FF and Safari, the overlap is precisely one-half of a line in the flowed text paragraph at most text sizes (rounding prevents exact alignment in some cases, but you can still see the basic problem). So what is supposed to happen to that over-lapped line box? The only place I could find in the spec that described the behavior between floats and inline boxes [2] had this to say: ... Any content in the current line before a floated box is reflowed in the first available line on the other side of the float. In other words, if inline boxes are placed on the line before a left float is encountered that fits in the remaining line box space, the left float is placed on that line, aligned with the top of the line box, and then the inline boxes already on the line are moved accordingly to the right of the float (the right being the other side of the left float) and vice versa for rtl and right floats. This language is very unclear. To me, it contemplates that the tops of any floats will always correspond with the tops of any encountered line boxes, and simply doesn't address the case presented here in which the top of the float is between the tops of content line boxes. The left float in this instance cannot be placed on that line, aligned with the top of the line box because the vertical position of the float has already been determined in reference to a different line box (i.e. the line box generated by the right floats). Moving the float as this paragraph describes would cause the floated box to move too high. Ideally, of course, one would hope that the UA would determine that the entire inline box of the text does not fit, and would reflow that line of content so it does not overlap. However, nothing I can find in the spec actually requires that behavior, and I'm guessing the Gecko and Safari algorithms simplify by only calculating the top of each of the two boxes. Since the float top was below the inline box top, my speculation is that those browsers simply stop there and do not reflow that line. Can you leave your sample page up a for a little while? This seems like something to raise with the CSS WG, both for CSS 2.1 and the CSS3 box module, and with your permission, I'll submit your page to the WWW-Style mailing list. Meanwhile, Gecko and Safari are clearly not exhibiting optimum behavior, so submitting this to Bugzilla and Apple would also be appropriate, if you would like to do that. [1] http://www.w3.org/TR/CSS21/visuren.html#float-position [2] http://www.w3.org/TR/CSS21/visuren.html#floats -- -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
