Re: [css-d] non-English characters: omit accents when using text-transform:uppercase
Hmm. It works for me. Oh, but I have a nightly Firefox build, not the release build (which version is the latest ?). After a quick look though the MDC docs, it appears you'll have to wait for Firefox 15 to have it work correctly. Yes, it works with on the latest Firefox Nightly. Is this something we'll see in CSS3 or just a Mozilla thing? __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] non-English characters: omit accents when using text-transform:uppercase
How many blocks of Greek text is this needed for? Are the accented letters a different Unicode codepoint from the same letter unaccented or is it unaccented letter followed by the accent? If so, you can just use find/replace to do the conversion of the text in the HTML. I'm not sure I understand. All text is UTF-8. The HTML file is UTF-8 encoded and the meta charset is set to utf-8. Is this what you mean? One way that this may work is if you can duplicate the text in both lower and upper case and then just use span with class tags to mark each version. Use style=hide to not display the version you want. You mean display:none? __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] non-English characters: omit accents when using text-transform:uppercase
Le 23 juil. 2012 à 21:40, sweepslate a écrit : Is this something we'll see in CSS3 or just a Mozilla thing? CSS 2.1 ? [quote] The actual transformation in each case is written language dependent [/quote] http://www.w3.org/TR/CSS21/text.html#propdef-text-transform (who wrote that sentence… so hard to read) CSS 3 text is a little more verbose http://dev.w3.org/csswg/css3-text/#transforming Other browsers will have to update their implementation at one point. Philippe -- Philippe Wittenbergh http://l-c-n.com/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] Pixels vs. ems--what's the point?
How do pixels compare with ems on devices with high DPI/PPI? The reason I ask is that, years ago, I had a laptop that was set to 120 DPI instead of the then more common 96 DPI. Setting a font size of 12 points in the CSS displayed text at 20 pixels. But at 100% or 1em, Webkit and Mozilla browsers displayed text at 16 pixels, while IE and Opera displayed at 20 pixels. Not having even a mobile phone to test on, I am wondering how higher DPI/PPI affects relative font sizes? (Ems, Rems, percent.) -- Cordially, David __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Pixels vs. ems--what's the point?
On 2012/07/23 09:40 (GMT-0700) David Hucklesby composed: How do pixels compare with ems on devices with high DPI/PPI? Poorly, and without regard to DPI. Px disregards user preferences 100%, bearing no relationship to ems except in cases where px per em is known, such as on an intranet and the stylist has actual knowledge of the hardware and settings in use. Em bears correlation to users' preference settings, 1:1 at the root level, other values when sizing is nested and inheritance applies, but fully predictable. The reason I ask is that, years ago, I had a laptop that was set to 120 DPI instead of the then more common 96 DPI. Setting a font size of 12 points in the CSS displayed text at 20 pixels. That's because the default size in IE and some ancient other browsers was set in pt, which was affected by DPI. But at 100% or 1em, Webkit and Mozilla browsers displayed text at 16 pixels, while IE and Opera displayed at 20 pixels. WebKit's Gecko's defaults are specified in px, which are traditionally not affected by DPI, which in turn meant only if the browser default was changed would 1rem not equal 16px. In recent years that lack of impact on DPI has been altered, such that e.g. in Gecko, when the DPI reaches 192, a switch is thrown to make a CSS px consist of two device px instead of one (and in two dimensions, height and width, since we see nothing that has non-zero height but zero width). A 23 1920x1080 display has about 2,073,600 device px, and a density to the nearest integer of 96 DPI. Had that very same 23 display a DPI of 192, it would be 3840x2160 resolution, with 7,862,400 device px, 4 times as many! Compare that to the latest Macbook Pro, with 2880x1800 resolution on a 15.4 screen! http://www.tested.com/news/44741-apple-launches-new-retina-display-macbook-pro-with-2880x1800-display/ That's over 220 DPI! http://fm.no-ip.com/PC/dpi.xhtml Another development is that Gecko has matched the bad behavior of other browsers by hard coding a 3:4 relationship between pt and px. On todays's web a pt no longer stands a predictable chance of actually measuring a pt in size[1], except for some users of some ancient browsers, and for Konqueror[2] users. The Mozilla developers' rationalization for this is that too many poor web sites exist that depend on an assumed 3:4 ratio and break otherwise, and those powers that be decided better to have physical units bear no logical relationship to their namesakes than for all those poorly designed web sites to look as broken as they in fact are. The Mozilla marketers could stand no more of it looks OK in [IE,Chrome,Safari], why not in Firefox? increasing Chrome's market share at the expense of Firefox's. The consequence of these developments is that the predictability of actual legibility using px to size anything has become even worse than the poor it used to be. Not having even a mobile phone to test on, I am wondering how higher DPI/PPI affects relative font sizes? (Ems, Rems, percent.) Using px or any so-called physical unit is complicated because of the hard-coded 3/4 ratio and a CSS px to device px ratio that changes at integer multiples of 96. Plus, as always, most of the devices accessing the web are personal, which is to say personalizable, which in turn means you can't predict either the size of a px or the size of the UA default, much less what the relationship between them and/or legibility might be. OTOH, when you size based on a 1em root (1rem), and keep that for the majority of page text, you know there's a 1:1 relationship between the user's preferred size (however many px that happens to be) which is presumptively equal to both comfortable and legible, regardless the unknown number of users who ever personalize the OEM defaults on their personal computing devices. This is not something that DPI had, has, or will ever have any impact on. WRT images, sizing is complicated. Traditional bitmap images scale upward poorly, while required bandwidth to support large images suitable for high density displays imposes a heavy toll regardless whether the image is to be used in a context that can utilize all the px that are available. Regardless of a decision made for any given context whether to go larger or smaller in image size, keep in mind a small image rendered too small for eyes to embrace it all at its intrinsic size on a high DPI device isn't materially different in effect from that same image sized up in em so as to maintain a fixed relationship in the layout. In the former, it's just too small, while in the latter, it's fuzzy or otherwise just doesn't look right. Either way, what isn't there simply isn't there. Until vector based images or something else is widely available to replace bitmaps, if that ever happens at all, to support imagery at high DPI requires larger intrinsic image sizes than used to be considered normal. [1] Gecko actually has an out for those who
Re: [css-d] Pixels vs. ems--what's the point?
Felix, this is the reason I subscribe to the list. Thanks for such a comprehensive answer – there's loads here I didn't know. It's amazing how much bizarre standard practice comes from a perceived need for retroactive continuity with a minority of sites that make terrible mistakes. Break the future to avoid breaking the past! __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Help with CSS3 transitions?
On Fri, Jul 20, 2012 at 3:18 PM, David Hucklesby huckle...@gmail.comwrote: On 7/20/12 12:24 PM, Kyle Sessions wrote: Hi everyone, I was hoping someone could give me a hand with the CSS3 transition property. I've set up a very simple test page here: http://kage23.com/transition-**test.htmlhttp://kage23.com/transition-test.html When you first load the page, you should see a ul with four visible items, and a More link. There's also another ul with a few additional items, that is hidden when you first load the page (height: 0px; overflow: hidden;). When you click the More link, I'm using Javascript/YUI to add a class to the hidden ul, that gives it height: auto; instead of height: 0px;. I have applied the transition property [...] Transitions only work from one specific value to another. Auto won't work, as you discovered. Try deleting the height properties, and use max-height instead. Make sure the max-height on the .open state is big enough for any future number of list items in the submenu. I'd use ems for this. Thanks, David! I couldn't use max-height because in the actual production environment that this is intended for, there's no way to predict what the maximum number of additional items is. I did get it working, though. I put the additional items into a containing div, then I measured the height of the additional-items ul, and then used Javascript to adjust the height of the containing div, rather than the actual ul itself. Throw an overflow:hidden onto the containing div, and it's good to go. http://kage23.com/transition-test.html Best, Kyle -- Cordially, David __**__**__ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/**mailman/listinfo/css-dhttp://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.**com/http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/**policies.htmlhttp://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_**support_evolt/http://www.evolt.org/help_support_evolt/ -- Kyle G Sessions Berkeley Electronic Press ksessi...@bepress.com 510-665-1200 + 128 www.bepress.com bepress: the frontier of scholarly publishing since 1999 Check out IR success stories on the DC Telegraph at http://blog.digitalcommons.bepress.com __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Pixels vs. ems--what's the point?
So as a non-expert who wants to be sure my pages look a certain way, I'm best to stick with px rather than em? Bruce In a message dated 7/23/2012 2:17:56 P.M. Eastern Daylight Time, mrma...@earthlink.net writes: On 2012/07/23 09:40 (GMT-0700) David Hucklesby composed: How do pixels compare with ems on devices with high DPI/PPI? Poorly, and without regard to DPI. Px disregards user preferences 100%, bearing no relationship to ems except in cases where px per em is known, such as on an intranet and the stylist has actual knowledge of the hardware and settings in use. Em bears correlation to users' preference settings, 1:1 at the root level, other values when sizing is nested and inheritance applies, but fully predictable. The reason I ask is that, years ago, I had a laptop that was set to 120 DPI instead of the then more common 96 DPI. Setting a font size of 12 points in the CSS displayed text at 20 pixels. That's because the default size in IE and some ancient other browsers was set in pt, which was affected by DPI. But at 100% or 1em, Webkit and Mozilla browsers displayed text at 16 pixels, while IE and Opera displayed at 20 pixels. WebKit's Gecko's defaults are specified in px, which are traditionally not affected by DPI, which in turn meant only if the browser default was changed would 1rem not equal 16px. In recent years that lack of impact on DPI has been altered, such that e.g. in Gecko, when the DPI reaches 192, a switch is thrown to make a CSS px consist of two device px instead of one (and in two dimensions, height and width, since we see nothing that has non-zero height but zero width). A 23 1920x1080 display has about 2,073,600 device px, and a density to the nearest integer of 96 DPI. Had that very same 23 display a DPI of 192, it would be 3840x2160 resolution, with 7,862,400 device px, 4 times as many! Compare that to the latest Macbook Pro, with 2880x1800 resolution on a 15.4 screen! http://www.tested.com/news/44741-apple-launches-new-retina-display-macbook-p ro-with-2880x1800-display/ That's over 220 DPI! http://fm.no-ip.com/PC/dpi.xhtml Another development is that Gecko has matched the bad behavior of other browsers by hard coding a 3:4 relationship between pt and px. On todays's web a pt no longer stands a predictable chance of actually measuring a pt in size[1], except for some users of some ancient browsers, and for Konqueror[2] users. The Mozilla developers' rationalization for this is that too many poor web sites exist that depend on an assumed 3:4 ratio and break otherwise, and those powers that be decided better to have physical units bear no logical relationship to their namesakes than for all those poorly designed web sites to look as broken as they in fact are. The Mozilla marketers could stand no more of it looks OK in [IE,Chrome,Safari], why not in Firefox? increasing Chrome's market share at the expense of Firefox's. The consequence of these developments is that the predictability of actual legibility using px to size anything has become even worse than the poor it used to be. Not having even a mobile phone to test on, I am wondering how higher DPI/PPI affects relative font sizes? (Ems, Rems, percent.) Using px or any so-called physical unit is complicated because of the hard-coded 3/4 ratio and a CSS px to device px ratio that changes at integer multiples of 96. Plus, as always, most of the devices accessing the web are personal, which is to say personalizable, which in turn means you can't predict either the size of a px or the size of the UA default, much less what the relationship between them and/or legibility might be. OTOH, when you size based on a 1em root (1rem), and keep that for the majority of page text, you know there's a 1:1 relationship between the user's preferred size (however many px that happens to be) which is presumptively equal to both comfortable and legible, regardless the unknown number of users who ever personalize the OEM defaults on their personal computing devices. This is not something that DPI had, has, or will ever have any impact on. WRT images, sizing is complicated. Traditional bitmap images scale upward poorly, while required bandwidth to support large images suitable for high density displays imposes a heavy toll regardless whether the image is to be used in a context that can utilize all the px that are available. Regardless of a decision made for any given context whether to go larger or smaller in image size, keep in mind a small image rendered too small for eyes to embrace it all at its intrinsic size on a high DPI device isn't materially different in effect from that same image sized up in em so as to maintain a fixed relationship in the layout. In the former, it's just too small, while in the latter, it's fuzzy or otherwise just doesn't look right. Either
Re: [css-d] Pixels vs. ems--what's the point?
On 7/23/12 11:24 AM, Barney Carroll wrote: Felix, this is the reason I subscribe to the list. Thanks for such a comprehensive answer – there's loads here I didn't know. It's amazing how much bizarre standard practice comes from a perceived need for retroactive continuity with a minority of sites that make terrible mistakes. +lots This indeed precisely answers my question. Many thank, Felix. -- Cordially, David __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Help with CSS3 transitions?
On 7/23/12 11:25 AM, Kyle Sessions wrote: On Fri, Jul 20, 2012 at 3:18 PM, David Hucklesby huckle...@gmail.comwrote: On 7/20/12 12:24 PM, Kyle Sessions wrote: Hi everyone, I was hoping someone could give me a hand with the CSS3 transition property. I've set up a very simple test page here: http://kage23.com/transition-**test.htmlhttp://kage23.com/transition-test.html When you first load the page, you should see a ul with four visible items, and a More link. There's also another ul with a few additional items, that is hidden when you first load the page (height: 0px; overflow: hidden;). When you click the More link, I'm using Javascript/YUI to add a class to the hidden ul, that gives it height: auto; instead of height: 0px;. I have applied the transition property [...] Transitions only work from one specific value to another. Auto won't work, as you discovered. Try deleting the height properties, and use max-height instead. Make sure the max-height on the .open state is big enough for any future number of list items in the submenu. I'd use ems for this. Thanks, David! I couldn't use max-height because in the actual production environment that this is intended for, there's no way to predict what the maximum number of additional items is. I did get it working, though. I put the additional items into a containing div, then I measured the height of the additional-items ul, and then used Javascript to adjust the height of the containing div, rather than the actual ul itself. Throw an overflow:hidden onto the containing div, and it's good to go. http://kage23.com/transition-test.html Cool! But I hope you don't anticipate having more than a dozen sub-items, though. The bottom items might not be visible in that case. YMMV of course. -- Cordially, David __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Help with CSS3 transitions?
On Mon, Jul 23, 2012 at 1:02 PM, David Hucklesby huckle...@gmail.comwrote: On 7/23/12 11:25 AM, Kyle Sessions wrote: On Fri, Jul 20, 2012 at 3:18 PM, David Hucklesby huckle...@gmail.com wrote: On 7/20/12 12:24 PM, Kyle Sessions wrote: Hi everyone, I was hoping someone could give me a hand with the CSS3 transition property. I've set up a very simple test page here: http://kage23.com/transition-test.htmlhttp://kage23.com/transition-**test.html http://kage23.com/**transition-test.htmlhttp://kage23.com/transition-test.html When you first load the page, you should see a ul with four visible items, and a More link. There's also another ul with a few additional items, that is hidden when you first load the page (height: 0px; overflow: hidden;). When you click the More link, I'm using Javascript/YUI to add a class to the hidden ul, that gives it height: auto; instead of height: 0px;. I have applied the transition property [...] Transitions only work from one specific value to another. Auto won't work, as you discovered. Try deleting the height properties, and use max-height instead. Make sure the max-height on the .open state is big enough for any future number of list items in the submenu. I'd use ems for this. Thanks, David! I couldn't use max-height because in the actual production environment that this is intended for, there's no way to predict what the maximum number of additional items is. I did get it working, though. I put the additional items into a containing div, then I measured the height of the additional-items ul, and then used Javascript to adjust the height of the containing div, rather than the actual ul itself. Throw an overflow:hidden onto the containing div, and it's good to go. http://kage23.com/transition-**test.htmlhttp://kage23.com/transition-test.html Cool! But I hope you don't anticipate having more than a dozen sub-items, though. The bottom items might not be visible in that case. YMMV of course. -- Cordially, David Why would the bottom items not be visible? Unless I'm misunderstanding, I _think_ this solution should allow for any number of sub-items, since I'm measuring the height of the sub-items themselves, and toggling the height of the sub-item container between 0 and the actual measured height of the sub-items. In the actual production environment, there will certainly be more than a dozen sub-items in many cases. -- Kyle G Sessions Berkeley Electronic Press ksessi...@bepress.com 510-665-1200 + 128 www.bepress.com bepress: the frontier of scholarly publishing since 1999 Check out IR success stories on the DC Telegraph at http://blog.digitalcommons.bepress.com __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Pixels vs. ems--what's the point?
On 2012/07/23 14:42 (GMT-0400) bho...@aol.com composed: So as a non-expert who wants to be sure my pages look a certain way, I'm best to stick with px rather than em? Depends on your meaning of a certain way. If you mean you want pages designed for print hosted on the web, it's probably the easiest way, and why so many pages are like that. OTOH if you want pages that the vast majority users will be glad they reached and enjoy using no matter what device they use or what its DPI, px can't do it, because px disregards what users prefer. To use px sized pages, many users, high DPI or otherwise, must apply defensive apparatus like zoom or minimum text size in an attempt to offset the offense of completely disregarding preferences, assuming such is possible at all. It is often the case that such defenses are only partial compensation, leading to hidden and/or overlapping elements or portions thereof. The attachments to https://bugzilla.mozilla.org/show_bug.cgi?id=612755 show typical results of px-sized pages opened in a high DPI environment without any defenses applied. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Pixels vs. ems--what's the point?
On 7/23/12 11:42 AM, bho...@aol.com wrote: So as a non-expert who wants to be sure my pages look a certain way, I'm best to stick with px rather than em? Bruce In a message dated 7/23/2012 2:17:56 P.M. Eastern Daylight Time, mrma...@earthlink.net writes: On 2012/07/23 09:40 (GMT-0700) David Hucklesby composed: How do pixels compare with ems on devices with high DPI/PPI? Poorly, and without regard to DPI. [...] Umm, Bruce. I think you missed this part: The consequence of these developments is that the predictability of actual legibility using px to size anything has become even worse than the poor it used to be. -- Cordially, David __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] Place LinkedIn, Facebook likes side-by-side?
Please look at the bottom of www.eigen.com. How can I position the Facebook Like and LinkedIn Follow buttons side-by-side? The FB button utilizes some CSS for its positioning. Doing something similar for the LinkedIn Follow button didn't work (at least my implementation didn't.) Thanks __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Place LinkedIn, Facebook likes side-by-side?
Hmmm They are side by side. -- Registered Linux User: #480675 Registered Linux Machine: #408606 Linux since June 2005 On Mon, Jul 23, 2012 at 5:32 PM, Chris Morton salt.mor...@gmail.com wrote: Please look at the bottom of www.eigen.com. How can I position the Facebook Like and LinkedIn Follow buttons side-by-side? The FB button utilizes some CSS for its positioning. Doing something similar for the LinkedIn Follow button didn't work (at least my implementation didn't.) Thanks __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Place LinkedIn, Facebook likes side-by-side?
Also, the Facebook Like is in a relative position when adjusting browser width. The LinkedIn Follow button is absolute, which poses a related problem. On Mon, Jul 23, 2012 at 3:48 PM, Chris Morton salt.mor...@gmail.com wrote: Not when rendered in Chrome, they're not. On Mon, Jul 23, 2012 at 3:35 PM, Wade Smart wadesm...@gmail.com wrote: Hmmm They are side by side. -- Registered Linux User: #480675 Registered Linux Machine: #408606 Linux since June 2005 On Mon, Jul 23, 2012 at 5:32 PM, Chris Morton salt.mor...@gmail.com wrote: Please look at the bottom of www.eigen.com. How can I position the Facebook Like and LinkedIn Follow buttons side-by-side? The FB button utilizes some CSS for its positioning. Doing something similar for the LinkedIn Follow button didn't work (at least my implementation didn't.) Thanks __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
