Re: [css-d] HTML email question
Am 17.10.2013 14:40 schrieb Hahnel, Fred (DET-MRM): Good morning all, I am writing a HTML responsive email template. Are you aware of the fact that e-mail clients are currently not reliably able to render modern HTML and CSS correctly at all? Outlook versions 2007 and 2010 e.g. use the rendering engine of MS Word. If you want your HTML mail to look somehow as you expect there, you will have to do table layouts as we did in the 90es. Some browser based clients do not apply styles you put in a style element, so you will have to use inline styles, which makes media queries unuseable even if they would be supported in some e-mail clients. I personnally try to stay away from HTML e-mail jobs, as they are always a pain. If you really need to do it: - Keep it basic - Use a paid preview service that shows you the results of your code in a broad variety of e-mail clients HTH Markus __ 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] Bad web font display in Chrome and Opera?
Thanks everybody for your hints and suggestions. I apologize for the delay in answering; I had no time to care about my personal site for the last few weeks. Am 19.09.2013 22:31 schrieb Jukka K. Korpela: Generally, font rendering is a rather complicated issue and depends on operating system, browser, display device, and other things. I think you should focus on one font at a time, in a simple setup, and experiment with different font sizes. I have seen Google fonts that mysteriously look very bad in some size but essentially better in a size 1px larger or smaller. This is bad news for those who favor the principle let the user decide, since this normally means that the browser's default size will be used. On the other hand, checking with typical default size of 12pt should then deal with most problem of this type. The font sizes are all relative to 1em; copytext is 1em. So I changed all percentages, margins, line-heights etc to values that compute to integer numbers in the Computed section of Firebug, with the standard setting of 1em=16px. Like this, the computed font sizes are now 16px, 18px, 22px and 28px. At first, this had no influence on the font rendering at all. Oddly enough, when I try to use the Font Information 1.0 add-on (which normally works excellently) in Firefox on your page, I get basically blank font names (names consisting of . and a box), in addition to the varying Google font names. So I suspect that there might be something wrong with the font files of the copy text - at least a broken name table. I did not find this add-on, it may have been made unavailable since your message. Am 20.09.2013 02:03 schrieb Philippe Wittenbergh: use the FontSquirel tool to generated a WOFF file, and use that as the first choice, rather than use the .ttf file you have listed first now. Am 19.09.2013 23:45 schrieb Karl DeSaulniers: It's been my experience that you should always load the .ttf before the .woff in the css declaration because chrome and Firefox like the .ttf better Interesting how experiences differ. I tried both orders, they did not differ, at least on my computer. But then I downloaded the font files again from FontSquirrel (originally I had them from the DaltonMaag website), and re-generated the webfonts (actually I had originally generated them with FontSquirrel, too). This did dramatically enhance the rendering! So it looks like either there are different versions of Aller available from DaltonMaag and FontSquirrel, that render differently when converted to webfonts, or I made a mistake the first time I generated the webfonts. Am 20.09.2013 00:01 schrieb Barney Carroll: On a tangent, I've found that Chrome (and now Opera — they use the same rendering engine) on Windows don't hint fonts as well as other browsers. You can sometimes get round this by specifying `-webkit- text-stroke: .25px` (your mileage may vary — play with the exact sub-pixel value to see what does and doesn't work). The gotcha is that this may make the font look worse in Safari OSX. Worth a shot… Nice one - I had not known about -webkit-text-stroke. Anyway, now the rendering is fixed, this property makes it rather worse than better. So now the copy text is fixed, I am fine, thank you all again. Maybe some day I will take the time to download all the title fonts and generate proper webfonts, too. __ 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] Bad web font display in Chrome and Opera?
Hello list In my new website http://www.markusernst.ch I use web fonts. Now I found that the appearance of these fonts is good in Firefox and IE, but quite poor in Chrome and Opera (on Windows 7). They are actually high quality fonts, the main text font is Dalton Maag's Aller, the alternative headline fonts are Google web fonts. I also checked the page with scripts disabled, which does not change the appearance of the fonts. Is it possible that Google's browser does handle Google's fonts poorly? (Actually, until know I was thinking that the fonts are displayed by the operating system rather than the browser applications.) Or do I have some mistake in my code? Thanks for any hints! Markus __ 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] Firefox the new pixel density ??
Am 09.07.2013 03:20 schrieb Janet Lynn Ford: Firefox now returns what 'should be' the CSS delivered to a tablet in portrait view. Am 09.07.2013 16:08 schrieb Greg Gamble: Are these issue from setting the zoom with text-only option being checked? I see site layout being busted when zoom is set to text-only, but not when its unchecked. Have you tried defining MQs in em instead of px? I usually do this, by dividing the target px size by 16 to get the em value. This addresses the problem described by Greg, as increasing the text zoom level will affect the MQ. Anyway I am not sure how this will interact with the new FF behaviour. It does not solve the image scaling, but it could make sure FF uses the appropriate styles for the text size actually displayed. __ 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] responsive design
Am 17.06.2013 16:44 schrieb Olivia A:
But for the web page layout by default, (with no media query applied) ,
when i resize down the pages a propos.php and enregistrement.php; the
two containers (below the long picture ) which are floated elements don't
float as it should, but instead there is one container falling down
underneath the other one.This only occur when i resize down the browser.
At the moment I look at your example pages, the 2nd container is below
the 1st one even without resizing (Firefox 21.0 on Windows 7). And this
is actually the expected behaviour, as the total width of them is more
than 100%. You have widths of 49% + 2% + 49% = 100%, plus 10px padding
on both containers, which makes totally 40px padding horizontally. So
both containers have a total width of 100% + 40px.
I made the same mistake when I started with web design. I was used to
the InDesign-/QuarkXPress box model which has the padding inside the
total width. In CSS, the padding is added to the total width.
You could add a css rule as follows, to change the box model:
.container1, .container2 {
box-sizing: border-box;
}
Anyway I believe to have read that browser support for border-box is not
quite perfect (IE8 seems to have problems). I'd personnally change the
padding to %, so you can sum up to exactly 100%, such as:
.container1, .container2 {
width:45%;
padding:2%;
}
.container1 {
margin-right:2%;
}
HTH
Markus
__
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] Best practices in only targeting only Styles needed for a page in an external style sheet?
Am 10.05.2013 14:56 schrieb Philippe Wittenbergh: Le 10 mai 2013 à 02:46, Nancy Johnson njohnso...@gmail.com a écrit : I have a question in the best practices for style sheet use and targeting only the styles needed for a specific page. @import? Less.js? mulitple stylesheets? As Cristian, I also use link. @import was cool to exclude Netscape 4.x in the old days; nowadays it does not seem to be the recommended way anymore (I am not familiar with the reasons, though). 2/ if you have many style rules only used by page C (the size of the main stylesheet grows by a _significant_ amount), it might make sense to dump them all in one separate stylesheet that is only called by page C. Eventually. As a rule of thumb, I personnally do the following distinction: - If I expect that not all users visit a page using the specific styles, I rather link them only from the pages that actually use them. - OTOH, If the styles are used by many or important pages, I usually link them from all pages, or include them in the main stylesheet, so they are kind of preloaded at the moment when they get used. HTH Markus __ 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] Question regarding the use of section
Am 18.04.2013 16:39 schrieb Nancy Johnson: When I first went live with a website a few months ago, the following code validated and now it doesn't. Why? section role=main Strange enough: the specs at WHATWG allow main as a value of @role in the section element: http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#wai-aria http://developers.whatwg.org/content-models.html#wai-aria Role must be either alert, alertdialog, application, contentinfo, dialog, document, log, main, marquee, region, search, or status __ 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] substitute font for Myriad Pro
Am 22.03.2013 18:33 schrieb Alnisa Allgood:
- font-family: Myriad Pro, Gill Sans, Gill Sans MT, Calibri,
sans-serif;
- font-family: MyriadProLightCondensed, Gill Sans, Lucida Grande,
DejaVu Sans Condensed, Arial, sans-serif;
On Fri, Mar 22, 2013 at 11:24 AM, David Laakso laakso.davi...@gmail.comwrote:
{font-family: 'MyriadPro', Lucida Grande, Lucida Sans
Unicode, 'Helvetica Neue', Helvetica, Arial, sans-serif} ???
Resp. Gill Sans, Gill Sans MT and Helvetica Neue: Are those delivered as
system fonts with any OS? Otherwise, I would recommend not to use them.
For websites, I'd only use fonts that are either widely supported system
fonts or delivered via @font-face.
Graphic designers and other people who work in the media business, such
as myself, often have old PostScript Type 1 versions of typefaces like
Helvetica Neue and Gill Sans installed. They are ok for print, but have
awful screen appearances. Thus, a website using those fonts may look bad
on my computer.
__
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] Select adjacent, but separately nested elements?
Am 15.03.2013 00:17 schrieb Philippe Wittenbergh: Le 15 mars 2013 à 07:38, Markus Ernst derer...@gmx.ch a écrit : I wonder how people use the adjacent selector with HTML5 elements that need to be nested, as legacy browsers do not recognize the new elements, such as: article div class=article ... /div /article footer div class=footer ... /div /footer The selector article + footer will probably not work in legacy browsers, while .article + .footer does not match the elements. If the html5shiv.js is used (or the Modernizr/Foundation/Bootstrap equivalent), then the article and footer elements are recognised in old IE (IE 9). They then can be used for styling purposes. Losers are old Gecko browsers (Firefox 2) and very old Safari (v1 only, I think). Not many of those around, me thinks. To your original question, given the structure of your documents as provided, nope, you can't select your nav based on the (non-)existing section(s). Perhaps use JS to add a class to the nav if and only if the sections don't exist (or only if they exist). The use that class to add or remove that border. Should be quite easy with Jquery, I think. Merci Philippe - yes I will do it with jQuery then. Best regards Markus __ 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] Select adjacent, but separately nested elements?
Hello
I have a structure of nested elements somehow like:
article
div
section
table
...
/table
/section
section
pThis second section is not always present!!/p
/section
/div
/article
nav
div
ul id=navi1
...
/ul
...
/div
/nav
And the CSS:
table {
border-top: 3px dotted green;
border-bottom: 3px dotted green;
}
#navi1 {
border-top:3px dotted green;
}
Now, I would like to remove the border on #navi1, when there is no
content between the table and #navi1. The following do not work:
table + #navi1 {
border-top:none;
}
article div section table + nav div #navi1 {
border-top:none;
}
Is there a possibility to select adjacent elements, if they are nested
separately? (I know about applying classes and such, but I'd like a
solution where I don't need to know at coding time whether there is
content after the table or not.)
Thanks for a hint!
Markus
__
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] Select adjacent, but separately nested elements?
Am 14.03.2013 14:25 schrieb Tom Livingston:
Can you apply the border to the second section instead of the nav?
Thank you for this idea. With the sample code I provided, this would do
it indeed. Anyway as the content is CMS driven, I have no control on the
number of sections above the navigation.
I wonder how people use the adjacent selector with HTML5 elements that
need to be nested, as legacy browsers do not recognize the new elements,
such as:
article
div class=article
...
/div
/article
footer
div class=footer
...
/div
/footer
The selector article + footer will probably not work in legacy
browsers, while .article + .footer does not match the elements.
On Thu, Mar 14, 2013 at 7:26 AM, Markus Ernst derer...@gmx.ch wrote:
Hello
I have a structure of nested elements somehow like:
article
div
section
table
...
/table
/section
section
pThis second section is not always present!!/p
/section
/div
/article
nav
div
ul id=navi1
...
/ul
...
/div
/nav
And the CSS:
table {
border-top: 3px dotted green;
border-bottom: 3px dotted green;
}
#navi1 {
border-top:3px dotted green;
}
Now, I would like to remove the border on #navi1, when there is no
content between the table and #navi1. The following do not work:
table + #navi1 {
border-top:none;
}
article div section table + nav div #navi1 {
border-top:none;
}
Is there a possibility to select adjacent elements, if they are nested
separately? (I know about applying classes and such, but I'd like a
solution where I don't need to know at coding time whether there is
content after the table or not.)
Thanks for a hint!
Markus
__
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/
__
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] Viewport vs. device dimensions
Am 09.03.2013 07:20 schrieb Philippe Wittenbergh: Le 9 mars 2013 à 00:49, Markus Ernst derer...@gmx.ch a écrit : In the www-style list, there is a discussion going on about handling media queries on rotatable devices. Some is about width/height/aspect radio vs. device-width/device-height/device-aspect-ratio. Are you talking about this thread: http://lists.w3.org/Archives/Public/www-style/2013Mar/thread.html#msg165 Yes indeed. Is there any useful thing about knowing device-* values? I understand how to use media queries to adapt the layout to the viewport width, but what useful thing can I do with knowing the device width, if it may differ from the viewport width? For generic html pages (things that are viewed inside a browser window), I don't think device-* MQ are very useful. However, html content can also be viewed inside a 'web view', inside apps, where device-* MQ can prove more useful: think the difference between the iPhone 4 and the iPhone 5 (basically same device-width but different device-height and -aspect-ratio). A designer may want to serve different spacing in order to make optimal use of the available height. I see. Though I do not fully understand, as I read the viewport definition the way that any kind of viewing area containing continuous media is called a viewport - thus the 'web view' inside apps should actually be a viewport, too: http://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#viewport __ 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] Viewport vs. device dimensions
Hello In the www-style list, there is a discussion going on about handling media queries on rotatable devices. Some is about width/height/aspect radio vs. device-width/device-height/device-aspect-ratio. Is there any useful thing about knowing device-* values? I understand how to use media queries to adapt the layout to the viewport width, but what useful thing can I do with knowing the device width, if it may differ from the viewport width? Just something that puzzles me... Best regards Markus __ 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] responsive not being responsive with images
Am 18.01.2013 16:25 schrieb Al Sparber:
On 1/18/2013 10:05 AM, Rob Emenecker wrote:
Okay. Errors resolved. Still the same issues with the display on some
mobile
devices. :-S
http://hairydogdigital.com
To ensure nothing is overriding your rules, add this to your page and test:
img {
height: auto !important;
width: auto !important;
max-width: 100% !important;
}
I tried in Firebug:
img {
width:100%;
max-width:477px;
}
This would actually shrink the image. Anyway, hardcoding the image width
does not seem to be very elegant, and the fact that Al's declaration
does not work in Firefox does not seem to make sense to me.
__
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] IE9: No (vertical) scroll bar
Am 22.12.2012 10:48 schrieb Tim Dawson: My page at the link below shows a vertical scrollbar in Fx17, Safari and Chrome, but not in IE9 (I've tried it on three computers in case there were a faulty installation). You could try to wrap the scrollbox table into a div, and apply overflow=scroll to the wrapper div rather than the table itself. (I have not tested it.) But you have more problems than that. If the browser viewport ist smaller than your table, there is no horizontal scrollbar, thus there is no way to see the whole page. Also, if you increase font size, the header table gets larger, while the width of the content table remains the same, but the columns at the right side disappear (tested with Firefox 14). Tables with fixed headers have always been a problem in HTML/CSS. I have seen solutions using jQuery and such, but I haven't come across a really satisfying one. Though, the last time I searched for it was about 2 years ago, there may have been some progress since then. Google for fixed header table. aside I actually don't understand how such a common task as a scrolling table with a fixed header can remain unsupported for decades of HTML/CSS development. Anyway I did not follow possible discussions on this topic. /aside __ 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] Background Image Not Showing in IE7/IE8
Am 15.11.2012 15:27 schrieb Elli Vizcaino:
Here is my conditional comment in case you were wondering:
!--[if lt IE 9]
link rel=stylesheet type=text/css href=?php bloginfo('template_directory');
?/css/ie.css /
![endif]--
At the page that you link to, I see this:
!--[if lt IE 9]
link rel=stylesheet type=text/css
href=http://www.e7flux.com/wp-content/themes/e7flux?1352988876; /
![endif]--
Are sure you have actually posted the link to the page you have the
problem with?
__
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] Background Image Not Showing in IE7/IE8
Am 15.11.2012 16:14 schrieb Elli Vizcaino:
- Original Message -
From: HMW Sales sa...@hallmarcwebsites.com
To: css-d@lists.css-discuss.org
Cc:
Sent: Thursday, November 15, 2012 9:56 AM
Subject: Re: [css-d] Background Image Not Showing in IE7/IE8
On 11/15/2012 9:43 AM, Markus Ernst wrote:
Am 15.11.2012 15:27 schrieb Elli Vizcaino:
Here is my conditional comment in case you were wondering:
!--[if lt IE 9]
link rel=stylesheet type=text/css
href=?php bloginfo('template_directory');
?/css/ie.css /
![endif]--
At the page that you link to, I see this:
!--[if lt IE 9]
link rel=stylesheet type=text/css
href=http://www.e7flux.com/wp-content/themes/e7flux?1352988876; /
![endif]--
Are sure you have actually posted the link to the page you have the problem
with?
Try using absolute path for the background image
Tried that too and did it again just now. Maybe I'm having a cache problem? Ok
tried something else. I deleted the ie.css file from server and in my header
file within the conditional comments I am calling a stylesheet named
iestyles.css which actually doesn't exist on the server and nothing has
changed. Do you think it's a cache problem or maybe it's my conditional comment?
It looks like IE is not finding or not interpreting the stylesheet at
all. To control this, you can do some very obvious change in the IE
stylesheet, such as body {background:yellow} - then you see very well if
the browser gets the stylesheet or not.
I am not quite familiar with the impacts of the media attribute. But I
noticed that in the link element for your main stylesheet you have
media=projection, screen. Maybe you try to add that in the link for
the ie stylesheet, too, or remove it at all.
(Anyway, the stylesheet you provided a link to does not seem to exist:
http://www.e7flux.com/wp-content/themes/e7flux/css/ie.css)
HTH
Markus
__
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] way to style list item number?
Am 30.10.2012 17:36 schrieb Angela French:
Is there a way (excluding using images for bullets) to style the bullet when it is a number
or a letter? I'm trying to apply css to some footnotes I'm building. The notes themselves
appear in a list at the bottom of my page where each list number (an ol)
corresponds to the footnote number. I'd like to try to make the number stand out and
actually even wrap it in an a tag if possible to link it back to the footnote
reference in the above text.
You can't do this in a way that works in today's browsers. You will have
to put the link on the footnote text instead of the list marker (number
or letter). To have different colors, just style the a element then:
HTML:
lia href=#myanchorFootnote Text/a/li
CSS:
li {
color:red; // styles the list element including marker
}
li a {
color:blue; // styles the linked text
}
If you don't want to link the text, do the same with a span instead of
the a.
__
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] Change the color of list markers
Hello
Trying to change the color of list markers, I came across the ::marker
pseudo element. Anyway, the following code does not seem to have an
effect in any browser I have access to:
li::marker {
color:#364065;
}
I have not found anything on browser support for this pseudo element. Is
this the right way to go for the future?
(I am looking for a CSS-only solution - I know I could wrap the contents
of the li in a span and apply a different color to this one, but I
can't change the markup. I also don't like to use a list-style-image
because it does not scale with the text.)
Thanks for your comments!
Best regards
Markus
__
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] Floating boxes with variable heights
Am 28.07.2012 13:58 schrieb Georg: On 28.07.2012 13:29, Markus Ernst wrote: http://www.rapid.ch/de/rapid-einachsgeraete/prospekte.html The headings here match the width of 3 image elements plus borders and the 2 margins between them. With space characters added to the margins, the width cannot be caluclated reliably anymore. Maybe you know a workaround for this, too? Sort of - in a round-about way. The auto added space is approx .5em either side of an inline-block, so by subtracting 1em from margin at front-side (often means negative front-margin) and offsetting the blocks (position: relative) to line up 1em further in - where they should show up, you can achieve pretty pixel-accurate margin calculations. Test and tweak subtracted value and offset till line-up is as stable as can be, and use backside margins to create wanted space. In most cases I simply set margins in em, .5em less that I want the blocks spaced. But since em is not always the right unit to make sure all blocks line up as intended in a more pixel controlled design, the round-about is how I do it while waiting for the calc() property to be supported across browser-land. Thank you Georg! I now added the desired visible gap in px as via padding, and set a right margin of -0.25em (as you suggested somewhere else in this thread). This works as intended in most modern browsers (including page or text zoom), with some minor differences in some zoom factors in some browsers. __ 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] @font-face: Buggy implementations in Firefox and Opera?
Am 04.05.2012 01:23 schrieb Philippe Wittenbergh:
Le May 4, 2012 à 12:26 AM, Markus Ernst a écrit :
I used web fonts from Fonts.com for the first time, in a website that is both
in German and Russian. As Fonts.com serves not only bold and italic variants,
but also the latin-1 and cyrillic language options with different family names,
I had to write my own @font-face declarations, that basically look like the
following:
/* Condensed Latin */
@font-face {
font-family:HelveticaNeue-Cn;
font-weight:normal;
src:[latin-1 font files];
}
/* Condensed Cyrillic */
@font-face {
font-family:HelveticaNeue-Cn;
font-weight:normal;
unicode-range: U+400-4ff;
src:[cyrillic font files];
}
The complete stylesheet is at http://www.memorynight.ch/css_js/fontfacelokal.css
Now this works well except in Firefox and Opera, as can be seen if you look at
the ä, ö and ü characters in this page:
http://www.memorynight.ch/de/spiel/charity.html
- Firefox shows these characters in the fallback font of the stylesheet (Arial)
- Opera shows these characters and the rest of the word in the browser default
font.
The characters affected are the only ones not present in the cyrillic font files. Thus I
assume that FF and Opera do not correctly interpret the unicode-range property, but
rather override the first declaration. Opera then does not seem to be able to
correctly apply the fallback font to single characters.
Does somebody know a workaround for this issue? Or am I even wrong, and
somebody can point me to a mistake in my stylesheet?
Gecko and Presto (Firefox and Opera) don't support unicode-range (yet). Thus
they don't find the correct characters in the Latin font, and fall back to the
next font specified (Gecko) or look for anything on the user machine that might
have those characters (Opera, quite poop).
One way around (I think, not tested but that is more or less what Typekit does)
/* Condensed Latin */
@font-face {
font-family:HelveticaNeue-Cn;
...
}
/* Condensed Cyrillic */
@font-face {
font-family:HelveticaNeue-Cn2; /* --- different name */
...
}
E { font-family: HelveticaNeue-Cn, HelveticaNeue-Cn2, 'fallback font'; }
Philippe, thanks very much for this helpful answer! (It took me 3 months
to respond because this special project was actually finished and the
german umlauts working in Firefox and Opera looked at as a nice-to-have
only.)
It turned out that your suggestion works great in Firefox, and totally
breaks in Opera at the russian pages. I was able to fix that by changing
the order in the font-family property:
E { font-family: HelveticaNeue-Cn2, HelveticaNeue-Cn, 'fallback font'; }
Like this, Opera does the same as in my original approach, which is not
worse at least. I hope they will fix that soon in Opera - quite poop
looks like a rather friendly qualification of this behaviour to me...
__
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] Floating boxes with variable heights
Am 27.07.2012 01:43 schrieb Georg: On 27.07.2012 00:46, Georg wrote: On 27.07.2012 00:18, Boray ERIS wrote: Is this a joke? Nope. It's CSS! ...an if you don't bother to test this old float-alternative at your end, here are a few examples. http://www.gunlaug.com/contents/test/test-floating-boxes.html http://www.gunlaug.com/contents/test/test-floating-boxes-c.html http://www.gunlaug.com/contents/test/test-floating-boxes-r.html Thank you very much Georg, this is great news! I don't think correcting for IE7 and even IE6 is a great deal, giving them some extra CSS via conditionnal comments. Now there is one thing that I noticed: With inline-block, a space character remains between the elements and is added to the margins. This can be a problem in case you try to calculate the total width of a number of the floated elements, as I did in my real case (inline-block not yet applied, as this is publicly online): http://www.rapid.ch/de/rapid-einachsgeraete/prospekte.html The headings here match the width of 3 image elements plus borders and the 2 margins between them. With space characters added to the margins, the width cannot be caluclated reliably anymore. Maybe you know a workaround for this, too? Thanks for your help! Markus __ 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] Floating boxes with variable heights
Hi Something that I asked myself for years already: If you have some floating boxes, you may want them to fill the available width and then continue at a next row. Now, if these boxes do not have a fixed height, this will result in rows that do not start at the left edge, as this example illustrates: http://www.markusernst.ch/stuff_for_the_world/test-floating-boxes.html Vary the window width to see how new rows are started according to the heights of the boxes in the upper row. The only CSS way I have been able to work around this so far (without scripting) is defining a fixed box height, which is not a good solution for multiple reasons. I would like the boxes to be rendered as if they were wrapped in table rows, each row having the height necessary for the tallest box in the row. But of course I cannot actually wrap them (or use table-* styles), because the number of boxes per row varies with the width of the viewport. Is there a good solution for this problem? Thanks for your comments! Markus __ 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] border-radius and image corners
Am 25.07.2012 14:43 schrieb John: The code below produces a round-corner in the lower left, but an image I place inside it doesn't have its lower left corner rounded..why is that? Besides the solution approaches already discussed, the why is because rounded corners of a container do not clip the contents of the container. I personnally think that this is not a good approach, and that it would make common use cases easier to handle if the rounded corners of a container would clip the contents, be it text or an image. If the author does not wish the clipping, appropriate padding is needed anyway. I do not see any use cases for not clipping the contents. But for any reason the people who specify CSS seem to think differently; I admit that I have not searched the archives of the CSS WG for discussions on this topic. __ 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] CSS Tables and colspan
Am 14.06.2012 03:33 schrieb Philippe Wittenbergh: Why don't you keep it as an html table, and then change the display value of table, tbody, tr, td, etc to 'block' within a media query ? Merci Philippe! I was not aware of the fact that HTML table elements can also be turned into block elements via CSS. __ 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] CSS Tables and colspan
Hello
I am not sure if this message has got through the technical problems, so
I take the liberty to send it again - I apologize for the case it worked
and just nobody had an answer.
I have a form, which I put in a layout table:
table
tr
td colspan=2h2First section of the form:/h2/td
tr
tr
tdlabelMylabel/label/td
tdinput type=text/td
/tr
... (more label/input pairs)
tr
td colspan=2h2Other section, quite long title/h2/td
/tr
tr
tdlabelOtherlabel/label/td
tdinput type=text/td
/tr
... (more label/input pairs)
/table
In order to make it responsive, I changed it to divs, and applied CSS
display:table-* declarations.
div
div
div class=colspanh2First section of the form:/h2/div
div
div
divlabelMylabel/label/div
divinput type=text/div
/div
... (more label/input pairs)
div
div class=colspanh2Other section, quite long title/h2/div
/div
div
divlabelOtherlabel/label/div
divinput type=text/div
/div
... (more label/input pairs)
/div
div { display:table }
div div { display:table-row }
div div div { display:table-cell }
It works well, except that I can't get the elements with the section
titles to span two rows - so the left column with the labels gets forced
to the maximum width of the titles.
I tried something like:
div div div.colspan { display:block }
Which did not seem to change anything.
The only solution that comes to my mind is to separate the table into 2,
and take the titles out of it. This means I will have to apply fixed
widths to the left column's elements. Is there something better?
Thanks for your comments!
Markus
__
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] CSS Tables and colspan
Hello
First, thanks to the css-d makers for your efforts to get this great
list back online!
To my question. I have a form, which I put in a layout table:
table
tr
td colspan=2h2First section of the form:/h2/td
tr
tr
tdlabelMylabel/label/td
tdinput type=text/td
/tr
... (more label/input pairs)
tr
td colspan=2h2Other section, quite long title/h2/td
/tr
tr
tdlabelOtherlabel/label/td
tdinput type=text/td
/tr
... (more label/input pairs)
/table
In order to make it responsive, I changed it to divs, and applied CSS
display:table-* declarations.
div
div
div class=colspanh2First section of the form:/h2/div
div
div
divlabelMylabel/label/div
divinput type=text/div
/div
... (more label/input pairs)
div
div class=colspanh2Other section, quite long title/h2/div
/div
div
divlabelOtherlabel/label/div
divinput type=text/div
/div
... (more label/input pairs)
/div
div { display:table }
div div { display:table-row }
div div div { display:table-cell }
It works well, except that I can't get the elements with the section
titles to span two rows - so the left column with the labels gets forced
to the maximum width of the titles.
I tried something like:
div div div.colspan { display:block }
Which did not seem to change anything.
The only solution that comes to my mind is to separate the table into 2,
and take the titles out of it. This means I will have to apply fixed
widths to the left column's elements. Is there something better?
Thanks for your comments!
Markus
__
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] media type not working with iphone -- and Android, either!
Am 06.06.2012 05:48 schrieb Rosie Williams:
My first responsive design is at http://forkinthecode.bloople.net (index page
only). I have made the responsive styles work in browsers but when I test it
using my iPhone, it displays all of the content so it isn't picking up the
styles for @media screen and (max-width:480px). I've tried a few different
things but not sure what the problem is.
I was just writing a similar post to this list when I saw yours. I have
the same problem with my Android phone; I tried both the Android browser
and Opera Mobile. The page in development is here:
http://hansbrun.ch.sabon.ch-meta.net/
It is not fully mobile-optimized, but some things are rearranged for
browser windows smaller than 801px width. I set the styles for the
smaller browsers as defaults, and added the changes for bigger displays
at the end of seite.css and home.css, in @media blocks:
@media (min-width:801px) {
/* Styles for bigger displays go here */
}
That works well if you change the window width on a desktop PC, but
mobile browsers insist in applying the styles for big displays.
I hope there is an easy answer for both of us!
Thanks, Markus
__
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] media type not working with iphone -- and Android, either!
Am 06.06.2012 10:23 schrieb Philippe Wittenbergh:
Le Jun 6, 2012 à 4:59 PM, Markus Ernst a écrit :
I was just writing a similar post to this list when I saw yours. I have the
same problem with my Android phone; I tried both the Android browser and Opera
Mobile. The page in development is here:
http://hansbrun.ch.sabon.ch-meta.net/
It is not fully mobile-optimized, but some things are rearranged for browser
windows smaller than 801px width. I set the styles for the smaller browsers as
defaults, and added the changes for bigger displays at the end of seite.css and
home.css, in @media blocks:
@media (min-width:801px) {
/* Styles for bigger displays go here */
}
That works well if you change the window width on a desktop PC, but mobile
browsers insist in applying the styles for big displays.
That doesn't surprise me.
In the absence of ameta name=viewport content=width=device-width
(you don't specify it, the viewport width of e.g iOS / MobileSafari is 980px.
That is large enough for your media query to kick in.
Add that viewport meta and your media query will start working.
Rosie has the same problem, I think.
Merci beaucoup Philippe, that's cool, I had missed meta viewport! In my
case, meta name=viewport content=width=700px turned out to work as
I expected it to work.
Is there any risk that desktop browsers interpret this meta tag, too, or
is it restricted to mobile devices?
Best regards
Markus
__
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] -webkit-tap-highlight-color
Am 30.05.2012 01:19 schrieb Christian Ziebarth: I recently worked on a project where for the iPad I altered the -webkit-tap-highlight-color value to a value that would match the color scheme of the site (http://www.brianleatart.com). I then told the project manager what I did thinking she would think it was neat and leave it at that but she followed up with, That's great! Now can you also change the font color when the link is tapped? After extensive searching I have been unable to find out how to do so. Any ideas? Without knowing about -webkit-tap-* properties or even having an iPad - would specifying a font color for a:focus and a:active do the trick? __ 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] display:block in Outlook 2007 2010
Am 21.05.2012 22:22 schrieb Jeff Reid: On Mon, May 21, 2012 at 12:34 PM, J Mijunk...@live.com wrote: Hey All, Does anyone know how to make the display:block attribute work in Outlook 2007 2010 for images? I used inline-style sheets and it doesn't work. This may help you some: http://www.campaignmonitor.com/css/ That's a real cool resource! If you have a look at the Outlook 2007/2010 column, you will notice that the display property is not supported. For whatever reason, Microsoft decided to use the rendering engine of MS Word in Outlook 2007 and 2010 (before, Outlook and Outlook Express used the rendering engine of Internet Explorer). Nobody outside MS can understand this decision, which makes HTML E-Mail quite unuseable in these programs. (Now that they catched up with standards rendering in IE, they might fear to lose their first place in giving us headaches...) If you want to write separate styles for Outlook rendering, you can enclose them in a conditionnal comment (found @ Wikipedia): !--[if gte mso 12] style type=text/css [Outlook 2007/2010 styles go here] /style ![endif]-- __ 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] @font-face: Buggy implementations in Firefox and Opera?
Hello
I used web fonts from Fonts.com for the first time, in a website that is
both in German and Russian. As Fonts.com serves not only bold and italic
variants, but also the latin-1 and cyrillic language options with
different family names, I had to write my own @font-face declarations,
that basically look like the following:
/* Condensed Latin */
@font-face {
font-family:HelveticaNeue-Cn;
font-weight:normal;
src:[latin-1 font files];
}
/* Condensed Cyrillic */
@font-face {
font-family:HelveticaNeue-Cn;
font-weight:normal;
unicode-range: U+400-4ff;
src:[cyrillic font files];
}
The complete stylesheet is at
http://www.memorynight.ch/css_js/fontfacelokal.css
Now this works well except in Firefox and Opera, as can be seen if you
look at the ä, ö and ü characters in this page:
http://www.memorynight.ch/de/spiel/charity.html
- Firefox shows these characters in the fallback font of the stylesheet
(Arial)
- Opera shows these characters and the rest of the word in the browser
default font.
The characters affected are the only ones not present in the cyrillic
font files. Thus I assume that FF and Opera do not correctly interpret
the unicode-range property, but rather override the first declaration.
Opera then does not seem to be able to correctly apply the fallback
font to single characters.
Does somebody know a workaround for this issue? Or am I even wrong, and
somebody can point me to a mistake in my stylesheet?
Thank you for your comments!
Markus
__
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] @font-face question
Am 03.05.2012 17:24 schrieb Tom Livingston:
On Thu, May 3, 2012 at 10:54 AM, Philippe Wittenberghe...@l-c-n.com wrote:
On May 3, 2012, at 10:56 PM, Tom Livingston wrote:
If I'm using RobotoBold - custom font - in my stack on anh2 for
example, I have to spec font-weight: normal; as well because otherwise
it double-bolds the font. But if the user sees a fallback font of
Helvetica or Arial, they won't get it in a bold weight. Is there
anything that can be done about this that I'm not seeing? Can only the
fall backs be bold?
I'm not sure I understand. Care to put an example ?
@fontface {
font-family: RobotoBold;
src: url(RobotoBold.woff);
font-weight: bold;
}
h2 { font-family: RobotoBold, Helvetica, Comic Sans; font-weight: bold; }
with that there should not be any artificial bolding. Browser will (should)
treat that font as being a bold face.
Philippe
--
Philippe Wittenbergh
http://l-c-n.com/
One other thing. After thinking about this, WHY doesnt this still
double-bold the custom font? Just a function of @font-face?
It should not double-bold if your code is ok... can you provide a link
to your page?
__
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] @font-face: Buggy implementations in Firefox and Opera?
Am 03.05.2012 17:33 schrieb Tom Livingston: Does the font include all the characters? Was is a minimum subset? Maybe that's it? Just guessing... No, the characters in question are part of the character set specified in the first @font-face declaration. They also appear correctly in Internet Explorer, Safari and Chrome. __ 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] trouble with my IE 9 64-bit v
Am 12.04.2012 17:28 schrieb David Laakso: On Thu, Apr 12, 2012 at 12:25 AM, Greg Wilkerjer...@well.com wrote: -Original Message- From: On Behalf Of David Laakso Sent: Wednesday, April 11, 2012 6:19 PM Subject: Re: [css-d] trouble with my IE 9 64-bit v On Wed, Apr 11, 2012 at 8:53 PM, Greg Wilkerjer...@well.com wrote: Hello CSS List, I am getting a blank white page when I load this on my version of IE9: http://ceert.org/ceert-affiliation.php Add this in the head of the document: meta http-equiv=X-UA-Compatible content=IE=edge Best, David Laakso [Greg Wilker] Now I am getting a plain black screen. (I remember experiencing this with BugDigger. I uninstalled it from my IE) - greg As of this writing your page appears the same in IE/9 as it does in Opera, Safari, Firefox, and Chrome on this end. In my IE9 on Win7 / 64-bit the error appears. Try the IE developer tools, you can switch on and off CSS declarations. The error seems to disappear if you disable the html, body block in your main CSS. I assume you can safely remove this block - at first sight, I can't see a difference whether it is there or not. HTH Markus __ 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] How to make a div fill the height of an iframe
Am 30.03.2012 05:50 schrieb Luis Cabral: I am re-posting my question below, I hope it displays properly this time. Hello, I have the following scenario: - An iframe that has fixed width and height and is absolutely positioned in the middle of the screen (simulating a modal pop up window) - The document inside that iframe contains 2 divs, both 100% width. The top one is variable height, and the bottom one should occupy the space left inside the iframe. If required, scrollbars should display in the bottom div, but not in the iframe itself. I made a diagram to try to make it clearer: +-iframe (fixed width and height) | no scrollbars should display on the iframe |+-div1 ||variable height || || || || |+- |+-div2 ||height should occupy the ||remaining space in the div, scrollbars should show ||inside the div if required if its contents ||are bigger than the available space |+-- +-- Note that this slightly different from the usual requirement, which is to dynamically resize the iframe accordingly to its contents. Is this possible to be done with just CSS? (assume the most recent browsers will be used i.e. Chrome, IE8+ etc) I am afraid this can't be done with CSS - somebody correct me if I am wrong. Unlike width, adjusting height is quite a hassle in CSS. I assume that your options are about the following: 1. Waive the fixed 1st div and make the whole iframed document scrollable. 2. Fix the height of the 1st div, so you know the height of the 2nd one. 3. Is it necessary to use an iframe? (It might be useful to provide a link to your actual case for such questions.) If not, it might be easier to go without, then you can just give the 2nd div a fixed height. 4. Use jQuery to calculate the heights of the divs. You might get help on that way in a Javascript or jQuery forum. HTH Markus __ 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] extra blank rows in table to fill window.
Am 09.03.2012 09:12 schrieb Ghodmode: http://www.ghodmode.com/testing/dthorp/zstripes/v3 That's very cool! I have no IE10 to test, though. I also like the ellipsis thing. If you remove the 10% from the first-child of the rows, the effect is even more impressing, when some longer words are introduced or the font size is increased in the browser. __ 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] extra blank rows in table to fill window.
Am 08.03.2012 06:22 schrieb David Thorp:
Hi all,
Another question on my current project...
Again, first, here's the code:
http://www.davidthorp.name/testingstuff/browser-tables-2.html
http://www.davidthorp.name/testingstuff/css/browser-tables-2.css
Also look at this image for reference:
http://www.davidthorp.name/testingstuff/FinderWindow.png
So here's the thing. That Finder list shows alternating table rows
(white/light blue) regardless of if there's any data in the row. Empty table
rows fill the window height if the window is larger than the number of rows
holding data. I want the same effect in the list part of my page.
Note that the container for the list is set to overflow, so a (vertical) scrollbar
appears if the window is too small (vertically) for all the rows with data to appear.
But any solution we come up with for displaying the empty rows when the
window is taller than the data needs to ensure no scroll bar appears then.
I've thought of a couple of ways I might accomplish this.
1. put another table behind the data one, with the same settings but no data in
it. This could be a very large number of rows. Trouble is the presence or
existence of the scroll bar is defined by the overflow setting of the container
object, and since both tables (the one with data and the one with empty rows)
are in the same containing object I can't win. I'm trying to get my head
around the idea that maybe I can somehow have two container objects with
different overflow settings, but that's starting to do my head in and I'd like
to see if there are any other common/recognised methods of achieving this.
This is going to be very hard. I'd rather try to use jQuery to add rows
to the table until the bottom is reached (which is off topic in this
list; maybe you could find help on this approach in a javascript or
jQuery forum).
2. I could create a small jpeg that looks like two blank rows of the same table
and set it to repeat. But then if I decide to change the row height of the
table rows for the data list, then I have to put in a different image, and
that'll just get messy.
Maybe you could experiment with background-size:
http://www.w3.org/TR/2012/WD-css3-background-20120214/#the-background-size
As I understand it, something like this should theoretically go in the
direction you want:
.list {
background-image: url(background.png);
background-size: auto 2.4em;
}
td {
height: 1.2em;
vertical-align:middle;
}
Anyway I haven't tested this, and I have no idea about the actual
browser support of background-size. And any background-image related
solution has of course the downside that it will break if there are
entries with multiple lines in the table.
__
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] :: makeready ::
Am 06.03.2012 01:31 schrieb David Laakso: First pass: desktop, laptop, tablet, mobile [signature link].. Your constructive comments and suggestions are always appreciated. I like it. 2 points that came to my mind: - I personnally would prefer to have the main navigation on every page, so I can navigate e.g. from Portfolio to Resources without a detour over Home. - I like the idea to make images smaller on narrow screens. Anyway, specially for your web design examples, it might be cool to find a way to make downscaled images clickable to show them full-size. Maybe something like this could be done via jQuery; I doubt that it can be done with CSS only. So this suggestion may be off-topic in this list. Best Regards Markus __ 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] Finding fallback fonts (for Calibri)
On 5 March 2012 11:01, Jukka K. Korpelajkorp...@cs.tut.fi wrote: I tried to play a bit with font-size-adjust, too, but it's apparently still a Firefox-only feature and might not even be suitable for this. Any value seems to either make Arial too small or Calibri too big. If the same value for font-size-adjust leads to different visual experiences for different fonts, I assume that either the calculation of the aspect ratio is not good enough, or there is some fundamental problem with the concept of aspect ratio. Let's hope this will be improved until font-size-adjust will be a standard. FWIW, your discussion inspired me to a suggestion on font-size-adjust in www-style: http://lists.w3.org/Archives/Public/www-style/2012Mar/0085.html __ 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] Need help with space between nav bar and content
Am 27.02.2012 06:25 schrieb Theresa Jennings: Here's a sample of the interior pages (the home page is handled a little differently): http://mdh-test.com/HealthySkin/Healthy_Skin_Story.shtml Style sheets, so you don't have to look for them: mdh-test.com/HealthySkin/main.css mdh-test.com/HealthySkin/ddsmoothmenu.css In Safari and Chrome (Win and OSX), the white #box juts up against the bottom of the text of the navigation. There should be a 1px space between the bottom of the nav bar and the top of the white box, like there is on the home page. It does it perfectly in all the other browsers. If I add extra margin pixels in the CSS to make the white box go down in Safari and Chrome, then it goes down a bunch in FF. Bleccch. On the home page, there is no #box rule. I have validated the html (woot!), and the css validates except for a few things having to do with the smoothmenu and the webkit hacks. I've been futzing with the original code. Can you help me, please? I imagine I'm going to need to hack the CSS a little. Without having had a deep look at your code, I'd suggest trying to un-hack first. You state that Safari and Chrome behave differently from other browsers, and you talk about Webkit hacks. Safari and Chrome use the Webkit engine. Thus, removing the Webkit hacks might make these browsers behave like the others. (Of course, if I am right, you will have to find other solutions for the things you try to do with the Webkit hacks; I don't know what they are for.) __ 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] Big IE8 problem: broken layout
Am 15.02.2012 22:21 schrieb Rory Bernstein: Hello All, I am working on a site that has a big IE8 layout problem. Here is the working prototype: http://donaldstark.ehclients.com/ You seem to have some nesting problems in your HTML code: http://validator.w3.org/check?uri=http%3A%2F%2Fdonaldstark.ehclients.com%2Fcharset=%28detect+automatically%29doctype=Inlinegroup=0 Try to fix these - maybe this fixes rendering in IE8, too. __ 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] Rounded corners do not apply to child elements
Hello!
I encountered that rounded corners do not seem to apply to child elements:
.roundCorners {
width:500px;
height:200px;
margin:1em auto;
background:yellow;
-moz-border-radius:15px;
-webkit-border-radius:15px;
border-radius:15px;
}
.roundCorners div {
width:200px;
height:200px;
float:right;
background:red;
}
div class=roundCorners
divHello/div
/div
In this example, the right corners of the red child element are not
rounded in recent versions of Firefox, Opera, Chrome, and IE9.
Is this the expected behavior? I did not find anything on the behavior
of child elements in the spec:
http://www.w3.org/TR/2011/CR-css3-background-20110215/#the-border-radius
I can't imagine that all current implementations are buggy, but from an
author's POV this behavior does not seem useful to me. If I apply
rounded corners to a container element, I would not want to re-apply
them to every child that might be placed in a corner. Is there a decent
solution to this? Or do you think I should raise this in the www-style list?
Thanks for your comments!
Markus
__
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] Rounded corners do not apply to child elements
Am 09.02.2012 11:05 schrieb Jukka K. Korpela: 2012-02-09 11:54, Markus Ernst wrote: I encountered that rounded corners do not seem to apply to child elements: Right. Is this the expected behavior? I did not find anything on the behavior of child elements in the spec: http://www.w3.org/TR/2011/CR-css3-background-20110215/#the-border-radius It is the expected behavior. Inherited: no means that setting border-radius on an element affects that element's border only. You would need to set it explicitly on any element for which it is desired. Thanks a lot for your quick answer. There seems to be a special case of inheritation here to me. If a property is inherited, it would mean that child elements get the same property, which is not desired in the case of rounded corners (as any border). In my example, the container element makes a box, which contains the inner element: div class=roundCorners divHello/div /div Now, if there is a border applied to the container element, the inner element is not expected to inherit the border, but it is expected to be placed inside the border, rather than covering it. In the case of rounded corners, I would accordingly expect the inner element to be rounded at the edges of the outer element, rather than covering the rounded corners (and even covering a possible border of the container element at the corners). Do you think it would make sense to raise this in www-style? __ 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] Rounded corners do not apply to child elements
Am 09.02.2012 11:38 schrieb Desi Matlock: Do you think it would make sense to raise this in www-style? Definitely not, what if you want another div inside that is only a few pixels smaller, with another set of similar rounded corners? Would you want to force that div to occur within a forced padding caused by a rounded corner on an outside div? I don't understand this - rounded corners do not seem to cause a padding, they just seem to affect the rendering of background and image contents, as far as I encountered it until now. __ 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] Flexible inside inside a wide div
Am 01.02.2012 13:04 schrieb Chris Blake: I have a 1920 wide div containing an image slide show. Inside that div are the controls. At the moment they sit in a 940px wide container, but i want the 'previous' and 'next' buttons to float either side of the browser. Fixed does this but I don't want them to stick when the page scrolls. Making the inside absolute and width 100% would just stretch it to the width of the outer div. Same with float left/right. If I understand you correctly, I would suggest trying: - drop the inside container - apply position:absolute to the control elements position:absolute does the same as position:fixed, exept that the element is scrolled with the rest of the page. HTH Markus __ 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] TwoQuestions: min/max-width, change layout with width
Am 24.01.2012 10:07 schrieb Felix Miata: On 2012/01/23 10:35 (GMT+0800) Ghodmode composed: 960px is a good max width... for most site visitors. ...where most is as little as 50% + 1 of today's visitors. Is there statistical evidence for any of these two statements? OTOH, the em unit bears a predictable relationship to both legibility and usability, and thus is the better way to determine how wide is wide enough. This is an old discussion. In a perfect world, the em unit would undoubtedly be the only reasonable choice. But in today's reality, some crucial parts of designs, such as image and border dimensions, do only work well if defined in pixels. (Look at a GIF logo scaled to an em size.) To have some kind of reliable relationship between the dimensions of a web page and its elements is a very common wish of website designers and their clients. Another downside of em is the fact that it is relative to the font size of the current element, and thus not reliably constant throughout a page. Once rem will be broadly implemented, it will be the unit of choice. Screen densities are rising and will continue to rise. Sure - which will also result in better renderings of images and borders with relative widths. And furthermore, the awareness of graphic designers (who usually are the ones who demand fixed page widths from us) for the differences between screen and print designs will rise. I am confident that in, let's say, 10 years the circumstances for using rem as the unit of choice will be dramatically better than today. __ 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] I Have a Really Big 'm'
Am 25.01.2012 11:04 schrieb Ghodmode: I think we're going around in circles. This matches my impression. It shows that an em is as wide as it is tall, but it's not the size of the letter 'm'. As described in the spec, the em unit is defined as the font size. em is maybe not the best of all possible names for it. In typography, this value is called a mutton (if I found the right translation for German Geviert). But the latin capital M is considered to be about that width, if designed traditionnally with serifs. Some people also talk about M height when they mean the capital height of a typeface. This may increase the confusion. __ 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] iframe troubles
Am 14.12.2011 02:05 schrieb Philippe Wittenbergh: On Dec 14, 2011, at 2:37 AM, Deighan, John wrote: For some reason, when I try to create a position:fixed iframe element, it gets an arbitrary height instead of filling to the bottom of the viewport as I think it should. A sample HTML page is below. The only change I've made from the version I'm using for testing is that I removed many lines like pThis is paragraph N/p to shorten this message. You can simply duplicate the existing line to create more content. In fact, I should explain the content since being inside an iframe element, it won't display anyway. The point is that to test whether I had the CSS top, bottom, etc. properties correct, I took the file below and simply changediframe todiv and/iframe to/div. When I do that, the div fills the screen, whereas when it was an iframe, it got an arbitrary (and small) height instead. Of course, when it's a div, it displays the content in the code below, whereas when it's an iframe, it uses the 'src' attribute to fetch content (you can use any arbitrary HTML file as content when it's an iframe). So, the exact same file, but with only changing one element between a div and an iframe, results in a drastically different layout. Can anyone explain this? iframe is an inline replaced element (a bit likeimg); as such, the rules for computing the height and the positioning coordinates are slightly different than for block level elements such asdiv.iframe has an intrinsic height (by default 150px). Yes, but unlike images, iframes do not adapt to the size of the content, if no size is specified. IMO, from a developer's POV the iframe spec is actually a hassle. Iframes would be much more useful if they could behave like block elements. I had some conversation on this in the WHATWG mailing list, where I was told that this would be a security issue. I am afraid the OP's task is not possible without scripting (determine the viewport height, and then calculate the Iframe height). __ 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] question on space at bottom of page
Am 21.07.2011 15:44 schrieb Alan Gresley:
Out of curiously, can you please tell me what the following CSS is for.
/* To prevent jumping */
html {
min-height: 100%;
margin-bottom: 1px;
}
I have seen this before as a recommendation how to force a scrollbar, in
order to prevent centered contents from moving 8 pixels horizontally
when navigating between pages with and without scrollbars.
__
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] OT: Protecting pictures
Am 26.04.2011 06:19 schrieb Chetan Crasta: How do you guys protect your images on the web? I normally don't bother trying to protect images because all the methods can be circumvented. But if a client insists on it, I use this technique: I overlay an absolutely positioned, transparent, div over the image. Right clicking on the image is then not possible. As usual, IE7 and IE8 behave differently. In these browsers, a transparent div is ignored when right clicking. The workaround for this is to give the div a background color and then set the opacity to 0 to make it transparent. A similar technique is to use a transparent gif to overlay instead of a transparent div. The effect is then not to make downloading via right-click impossible, but rather to confuse the user, as after having right-clicked and downloaded the image file, there is no actual image inside it. __ 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] Automatic resizing of textareas and contenteditable elements
Hello
Some days ago I encountered that Firefox 4 and Google Chrome implement
the resize property:
http://www.w3.org/TR/css3-ui/#resizing
They default the textarea element to resize:both, which is IMO a nice
usability boost. Now there are websites such as Facebook that use
scripting to dynamically adapt the height of textareas to the amount of
text contained, which works more or less well.
It would be nice to tell textareas and contenteditable elements to grow
with their contents. Maybe this could be achieved with no spec change, like:
textarea, *[contenteditable] {
height:auto;
min-height:5em;
}
Is something like that possible with CSS3? If not, do you think the
above approach is sensible and should be suggested to browser vendors,
or would this rather be a case to propose a new property such as
autoresize to the CSS Working Group?
Thanks for some opinions.
__
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] Rule of Thumb For Naming Classes/IDs?
Am 31.03.2011 13:12 schrieb Barney Carroll: But even from that angle, can this be considered good practice? Isn't it contrary to the specification's intentions in forbidding digit-led identifiers using the standard methods? Would you genuinely suggest this advice to the OP, or is this purely an exercise in exploiting spec loopholes? I could imagine a hypothetic Web application that generates class names from any other information, which may start with a digit. Thus class names may not even be known at coding time. In that case, escaping all digits might be a valuable alternative. A simpler question, that has still yet to be answered, is why digit-led class or id identifiers are banned in the first place. Alan, Phil — any ideas? Interesting question I was wondering about since I learnt CSS. __ 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] Web Pages Shift
Am 30.03.2011 09:25 schrieb PL:
Bob,
I am indebted to you for this bit of information! Thank you. It solved
the problem so easily that I am amazed. I had never heard of this, but
googled it to see what it was.
I dropped some code onto the bottom of my css sheet without really
understanding where to put it or format it, but it doesn't seem to
matter, it works.
html, body { height: 100%; margin: 0 0 1px; padding: 0; }
But I will do a bit of research to discover what this is all about.
It is not too complicated:
- When there is a scrollbar, it takes about 16px width, so it reduces
the width of the viewport (the inner dimensions of the browser window).
Thus, a page which is centered will move about 8px to the left compared
to a page with no scrollbar.
- The CSS rules you provide give the page a height of 100% of the
viewport, + a margin of 1px, which makes a total height of 1px more than
the viewport height. Like that you force a scrollbar even if there would
be none necessary.
__
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] Scrollable table body again
Am 29.03.2011 14:18 schrieb HallMarc Websites: Seem to be missing a link to your instance. Sure: http://www.wisental-horgen.ch/angebot/suche.php (I am aware of the fact that the page does not validate. The errors are the target attribute, which is re-allowed in HTML5, and the br / outputted by PHPs nl2br() function instead of br - thus nothing that affects table rendering.) __ 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] Scrollable table body again
Am 29.03.2011 15:11 schrieb Barney Carroll:
The problem is that jQuery dynamically introduces styles properties
per-element and attaches them via the object's style attribute. You
could over-ride this with !important print rules though.
Cool! I was not aware of the fact that !important is powerful enough to
override style attributes.
If you don't already have a print-only stylesheet, add it like so:
link rel=stylesheet media=print href=…/
I personnally prefer an @media print block in the stylesheet document,
as it has better support in legacy IEs.
This CSS should nullify the jQuery effects (allowing the table to
assume its necessary height):
.tablescroll_wrapper {
height: auto !important;
overflow: visible !important;
}
.tablescroll_body {
width: auto !important;
}
Thank you very much, this is what I was looking for! It makes the print
output not perfect (as the scroller script separates the table header
from the body, thus column widths differ, and the header is not repeated
at pages 2 and following), but absolutely usable for those who press
CTRL-P instead of clicking the link to the separate print version of the
page.
Am 29.03.2011 16:42 schrieb HallMarc Websites:
Ok first for IE 9 the jquery 1.5 is not working. They are aware of
this bug and the fix for now is to roll back to 1.4.4 for the scroller
to work in IE 9.
Thank you for this advice which for sure saved me quite some debugging
and researching time!
__
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] Scrollable table body again
Am 28.03.2011 23:43 schrieb Markus Ernst: I had to implement a table with a scrollable body and a fixed header for a client. [...] Has there been any movement on this topic since then? While it might be difficult from an implementation POV - from an authoring POV it would look consistent to me, that overflow:scroll should work on a tbody element without further hacking as it works on a div element. After I got great help to my actual problem, I would be interested in some opinions or clarifications about applying overflow:scroll to a tbody element. Currently there does not seem to be any good browser support for it - I tested this testcase: http://www.markusernst.ch/stuff_for_the_world/table-scroll-test.html IE 8, Opera 11 and Chrome 10 do nothing, which is better than Firefox 3.6 which displays a very buggy table with an unnecessary horizontal scrollbar and strangely behaving cell borders. I don't understand everything in the spec, but assume that table-* elements are looked at as replaced elements, so that the overflow property does not apply. But actually scrollable tables are asked for in the real world. There is no way to realize them via scripting or CSS without drawbacks. I can't see fundamental implementation barriers (as long as there is only one fixed header, either at the top or at the left resp. right side). Are there any clinical reasons for not allowing scrollable tables? Or has this just been forgotten in the speccing process so far? __ 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] Scrollable table body again
Hello I had to implement a table with a scrollable body and a fixed header for a client. While searching for solutions I found an approach that seems to work ok, but requires fixed column widths: http://www.imaputz.com/cssStuff/bigFourVersion.html Another one, discussed in this list, allows flexible column widths, but is rather hackish and does not seem to even work in IE 8 and Google Chrome: http://archivist.incutio.com/viewlist/css-discuss/72333 Has there been any movement on this topic since then? While it might be difficult from an implementation POV - from an authoring POV it would look consistent to me, that overflow:scroll should work on a tbody element without further hacking as it works on a div element. I ended up using a jQuery solution, with the downside that the table is not printable anymore. Of course I can add a printable version of the page, but I'd prefer a single page that works both on screen and print. So if somebody knows a better solution, I'd be glad to get pointed there. Thanks Markus __ 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/
