Re: [css-d] styling
> I just found another bug in Firefox 2.0.0.13 which I haven't seen listed
> anywhere else.
>
> If I style as follows: hr {color:red;} it does appear as red and
> displays correctly in most browsers.
> However, in Firefox it displays, but with an enormous amount of top and
> bottom padding.
> This also causes problems with floats, which tend to float upwards and
> partially cover the horizontal rule, leaving a large gap where the float sits.
>
> The good news is that it can be cured. :-)
>
> Just add margin:0; padding:0; to the hr style and all's well.
Your problem description is not conclusive so can you show this in a
link? You say "an enormous amount of top and bottom padding", but
later on you set also _margin_ = 0?
And what is "enormous" in pixels?
Manfred
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] styling
Alan, you did _not_ respond to the list and therefore I'll repeat your
message here:
On 05/04/2008, Alan K Baker <[EMAIL PROTECTED]> wrote:
>
>
> I didn't measure "enormous" but an estimate is over 20px, which is far more
> than a simple margin error.
>
> The code is very simple:
>
> CSS:
>
> hr {
> background-color:#dd; /* One browser needed this, I forget which one
> */
> color:#dd;
> /* Enter margin:0; padding 0: for Firefox */
> }
>
> #header {
> display:block;
> position:absolute 0 0 ;
> width:800px;
> height:160px;
> margin:0;
> padding:0;
> }
>
> #header h1 {
> font-family:"Times New Roman", Times, serif;
> font-size:90px;
> font-weight:normal;
> color:#dd;
> text-align:center;
> margin:0;
> padding-top:15px;
> }
>
> HTML
>
>
> Some header text
>
>
>
> Regards,
>
> Alan.
You wrote:
> hr {
> background-color:#dd; /* One browser needed this, I forget which one
> */
> color:#dd;
> /* Enter margin:0; padding 0: for Firefox */
> }
and earlier:
> > If I style as follows: hr {color:red;} it does appear as red and
> displays correctly in most browsers.
> > However, in Firefox it displays, but with an enormous amount of top and
> bottom padding.
Please note that color does not have any meaning if the element has no
content. This only leaves border-color and background-color to specify
any color for styling.
> I didn't measure "enormous" but an estimate is over 20px, which is far more
> than a simple margin error.
Sometimes you claim it to be a padding (right) and sometimes a margin
(false, as no color specification is applicable to the margin).
You wrote:
> > I just found another bug in Firefox 2.0.0.13 which I haven't seen listed
> anywhere else.
> > If I style as follows: hr {color:red;} it does appear as red and
and later:
> The code is very simple:
(for the code see above).
I'm sorry, yes the code you posted is very simple, but it does not
show any bug in Firefox 2.0.0.13. The only problem is, you forgot to
show us the rule from your stylesheet, which causes the padding ("is
over 20px") on the . As a guess, that rule might just look like
this:
html * {padding: 12px 0 12px 0;}
Manfred
> - Original Message -
> From: Manfred Staudinger
> To: Alan K Baker
> Cc: css-d
> Sent: Friday, April 04, 2008 7:13 PM
> Subject: Re: [css-d] styling
>
> > I just found another bug in Firefox 2.0.0.13 which I haven't seen listed
> anywhere else.
> >
> > If I style as follows: hr {color:red;} it does appear as red and
> displays correctly in most browsers.
> > However, in Firefox it displays, but with an enormous amount of top and
> bottom padding.
> > This also causes problems with floats, which tend to float upwards and
> partially cover the horizontal rule, leaving a large gap where the float
> sits.
> >
> > The good news is that it can be cured. :-)
> >
> > Just add margin:0; padding:0; to the hr style and all's well.
> Your problem description is not conclusive so can you show this in a
> link? You say "an enormous amount of top and bottom padding", but
> later on you set also _margin_ = 0?
> And what is "enormous" in pixels?
>
> Manfred
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] styling
Hi Alan,
> Without me looking up specifications, if color has no meaning, then how do
> you propose > to change the color of a horizontal rule? It is not a border,
> neither is it a background, so
> how else would you style its color property? To answer my own question,
> Mozilla
> obviously think it's a background element, but then you can't simply put
> printable
> characters on top of it, so they are breaking the rules.
If you take a look at the HTML 4.01 Strict DTD
http://www.w3.org/TR/html401/sgml/dtd.html
you will see that HR is a block-element (maybe you meant this when you
say "background element")! This answers also your question but in a
different way: looking up the specification is always helpful to learn
what the rules are.
> Not sure why you say that I am making false claims. If I appear to be
> claiming something > to be a padding and sometimes a margin, that is not my
> intention. I am well aware that
> 'margin' has no color property, why would it? It's a non-printable spacing
> property. The
> extra spacing that Firefox inserts is totally transparent, therefore I can't
> tell whether it's a > margin or padding in the true sense of the words. It's
> a 'lump' of transparency that's being > inserted, and it's only Firefox that
> does it. I call that a bug.
I didn't say you are "making false claims" but you use some basic
notion very freely. When it comes to differentiate between margin and
padding this should be simple: for example the padding takes the
background-color but the margin not. So if you have a block-level
element and you have specified a background-color then the transparent
space is the elements margin area, isn't it?
> I did not forget to show the rule from my stylesheet that causes padding.
> Firstly, if that was the case, it would happen in all browsers and secondly
> there is no
> such rule in my stylesheet. I did not show the code for 'body' because it is
> irrelevant in
> this case. There's nothing in it to cause errant spacing and there is no
> "html * etc" code > in my stylesheet.
O.k. Anyway, we now know it's the margin.
> FWIW I have included below, all that is above the 'hr' definition and there's
> nothing after
> it to affect it. The code can be tested exactly as it is below, by saving it
> as a set of styles > in an HTML document and a simple command inserted
> in the body below it. In
> Firefox only, it will space itself far more than a single line height from
> the top of the page.
>
> OK. Set up your own and try this in Firefox exactly as it is,
>
>
>
> body {
> background-color:#f4f9a8;
>
> font-family:"Times New Roman", Times, serif;
>
> font-size:12px;
> font-weight:normal;
> color:black;
> margin:0;
> padding:0;
> }
>
> hr {
> background-color:#dd;
> color:#dd;
> }
>
> #container {
> width:800px;
> height:auto;
> margin:0;
> padding:0;
> position:absolute;
> top:0;
> left:20px;
> }
>
>
>
>
>
The code you posted here looks almost the same in Firefox and IE 6.
Was this your
intention?
> In fact I believe that Mozilla are wrong. A is a printable line and is
> therefore a
> foreground element and should possess color.
Above I showed you that is defined as a block-level element in
the HTML 4.01 Strict DTD. As long as you don't backup the "foreground
element" with some evidence, I have to assume it's only your personal
opinion.
Manfred
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] IE table column width
Hi List,
Assume we have a table with these basic properties:
table {
border-collapse: collapse;
border: 1px solid #859EB5;
border-spacing: 0;
font-family: tahoma;
}
td {
border: 1px solid #859EB5;
font-size: 11px; text-align: right;
padding-top: 1px; padding-bottom: 1px;
padding-right: 0px; padding-left: 0px;
}
Note the last line: horizontal padding is set to 0. Assume further the
table has 8 columns which should have an alternating width of 60px and
90px respectively. We do this by assigning a class to the col:
and then define the column width with css:
table col { width: 90px; } /* take this as a default */
table col.num1 { width: 60px; }
table col.cur1 { width: 90px; color: black; background-color: #ffc;}
To take advantage of the fixed table layout we specify
table {
table-layout: fixed;
width: 609px; /* (60+90)*8 for col-width + (8+1) for borders */
}
The result is shown in Tab. 1 (http://test.rudolphina.org/col-width.html). The
display is the same for Firefox 2.0.0.13, Opera 9.25, IE 6 and IE 7.
But this changes if we specify a padding (Tab. 2) for the cells like
td { padding-right: 4px; padding-left: 0px; }
as IE 6 and IE 7 enlarge each column by 4px (in the absence of a colspan).
To get IE 6 and IE 7 to display the same as Firefox and Opera again (Tab. 3)
it is necessary to overwrite the specified col width by
table#t3 col { width: 86px; }
table#t3 col.num1 { width: 56px; }
table#t3 col.cur1 { width: 86px; }
Note: Other tests seem to indicate that this might not sufficient in cases
where colspans are present.
Questions:
1. Is IE 6, IE 7 in accordance with the specification?
2. How does it look in Safari, Firefox 3 and IE 8 ?
Regards,
Manfred
References:
http://www.w3.org/TR/CSS21/tables.html#columns
17.3 Columns
Table cells may belong to two contexts: rows and columns. However, in
the source document cells are descendants of rows, never of columns.
Nevertheless, some aspects of cells can be influenced by setting
properties on columns.
'width'
The 'width' property gives the minimum width for the column.
http://www.w3.org/TR/CSS21/tables.html#fixed-table-layout
17.5.2.1 Fixed table layout
With this (fast) algorithm, the horizontal layout of the table does
not depend on the contents of the cells; it only depends on the
table's width, the width of the columns, and borders or cell spacing.
In the fixed table layout algorithm, the width of each column is
determined as follows:
1. A column element with a value other than 'auto' for the 'width'
property sets the width for that column.
2. Otherwise, a cell in the first row with a value other than
'auto' for the 'width' property determines the width for that column.
If the cell spans more than one column, the width is divided over the
columns.
3. Any remaining columns equally divide the remaining horizontal
table space (minus borders or cell spacing).
The width of the table is then the greater of the value of the 'width'
property for the table element and the sum of the column widths (plus
cell spacing or borders). If the table is wider than the columns, the
extra space should be distributed over the columns.
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] styling
Reading through your responses I found it necessary to set up a small
test page to show the effect of specifying different properties for
color on the hr element.
http://test.rudolphina.org/hr.html
Because of the number of bugs, interpreting the results is a non-trivial task
certainly. Some examples:
a) IE 6 and IE 7 do show the background-color specified - but if the hr
has color specified also, you have to set color: none; to get it.
b) Firefox 2.0.0.13 ignores height completely.
c) Opera 9.25 does honor the border-color property if specified, but fails
to use the color property in its absence.
d) margin: 0; does what you would expect in Firefox 2.0.0.13 and Opera 9.25
but not for IE 6 and IE 7, where you have to specify margin: -7px 0;
Enjoy finding more bugs. For your reference ("Box model"):
http://www.w3.org/TR/CSS21/box.html#border-color-properties
I would also be interested to hear about Safari, Fx 3b and IE 8b.
Thanks,
Manfred
On 08/04/2008, Philippe Wittenbergh <[EMAIL PROTECTED]> wrote:
>
> On Apr 8, 2008, at 6:16 AM, Alan K Baker wrote:
> > Depending on the browser, there are different methods needed to
> > address the actual color of horizontal line in . My test results
> > are below:
> >
> > hr {
> > background-color:#d00; /* Firefox */ Implies that the 'line'
> > is entirely constructed of padding and transparent space is 'margin'.
> > color:#d00; /* IE 6 & 7 */ Implies that the
> > line is classed as text, the element cannot have padding because
> > background-color does nothing, and its transparent space is 'margin' .
> > border-color:#d00; /* Opera & Safari */Implies that the line is
> > classed as a border, the element cannot have padding because
> > background-color does nothing, and its transparent space is 'margin' .
> > margin:0;
> > padding:0;
> > }
> >
> > If one of these methods is the de-facto standard, then must be
> > classed as a special case, where some rules of block styling do not
> > apply, or at least one of the browsers is breaking the rules.
>
>
> And browsers have bugs...
>
> The colour you see on an is actually the border of the element.
> Now, in theory, the colour of the border is determined by the 'color'
> of an element, unless specified by the border-color property [1]. That
> works correctly for most elements in all browsers. The is a
> problem child, not because it is a special element, but due to browser
> bugs.
>
> * Opera 9.5b, Gecko 1.9 (Fx 3b5), IE 6+ all apply the colour specified
> by the color property for the element
> * WebKit (Safari 3.1), Opera 9.2x don't apply (inherit) the 'color'
> property correctly for the The author need to specify the border-
> color property (and border-style) [2].
> Applying the border-colour property also works correctly in Gecko 1.9,
> and Gecko 1.8 (Fx2); not sure about IE.
> * Gecko 1.8: the background-color property determines the colour of
> the , unless specified as 'border-color'.
>
> In all browsers, except IE 6 and 7, one can also use the background-
> color property (will fill the space between borders), padding ( i.e.
> makes the element taller), margin, width, height, ...
>
>
>
>
> [1]
>
> [2] for a thin (1px tall or similar), you should specify the
> border-style (as 'solid'), as the default style in mst browsers is
> inset.
>
>
> Philippe
> ---
> Philippe Wittenbergh
> http://l-c-n.com/
>
>
>
>
>
> __
>
> css-discuss [EMAIL PROTECTED]
> http://www.css-discuss.org/mailman/listinfo/css-d
> List wiki/FAQ -- http://css-discuss.incutio.com/
> List policies -- http://css-discuss.org/policies.html
> Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
>
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] styling
Hi Alan,
> Safari behaves in a similar way to Opera.
Which Safari and do you have a screen shot?
> you don't set border-style so I don't know where it inherits that
Philippe Wittenbergh has shown us (in this thread) the default settings
for Fx3, so you might want to look into it again.
> Firefox is even worse as it doesn't seem to know what fuchsia and aqua
> are so displays white with inset borders in shades of gray.
Of course Fx know these colors, but it does not want to apply any!
(to proof that I've updated http://test.rudolphina.org/hr.html )
> the only really useful browser consistent attribute that has is
> its ability to alter its width
It is not as bad as you see it now: if you apply a padding for non-IE and
reserve height for IE you will be able to use the background-color consistently.
Cheers,
Manfred
On 09/04/2008, Alan K Baker <[EMAIL PROTECTED]> wrote:
> Hi Manfred.
>
> Safari behaves in a similar way to Opera.
>
> In non-IE browsers, when a border is shown it appears to be in an inset
> style in two colors, but looking at your code, you don't set border-style so
> I don't know where it inherits that from.
> Firefox is even worse as it doesn't seem to know what fuchsia and aqua are
> so displays white with inset borders in shades of gray. The borders do take
> on the same hue family in lime!
>
> What a total nightmare and a minefield for the unwary.
>
> I must admit that if I'd specified the original that I used, I'd have
> made a 1px box with a background color and specified its length. ISTM that
> the only really useful browser consistent attribute that has is its
> ability to alter its width to suit its container. :-)
>
>
> Regards,
>
> Alan.
>
> www.theatreorgans.co.uk
> www.virtualtheatreorgans.com
> Admin: ConnArtistes, UKShopsmiths, 2nd Touch & A-P groups
> Shopsmith 520 + bits
> Flatulus Antiquitus
>
>
> - Original Message -
> From: Manfred Staudinger
>
> To: Philippe Wittenbergh
> Cc: CSS-D
> Sent: Tuesday, April 08, 2008 9:28 PM
> Subject: Re: [css-d] styling
>
>
>
> Reading through your responses I found it necessary to set up a small
> test page to show the effect of specifying different properties for
> color on the hr element.
>
> http://test.rudolphina.org/hr.html
>
> Because of the number of bugs, interpreting the results is a non-trivial
> task
> certainly. Some examples:
>
> a) IE 6 and IE 7 do show the background-color specified - but if the hr
> has color specified also, you have to set color: none; to get it.
> b) Firefox 2.0.0.13 ignores height completely.
> c) Opera 9.25 does honor the border-color property if specified, but fails
> to use the color property in its absence.
> d) margin: 0; does what you would expect in Firefox 2.0.0.13 and Opera 9.25
> but not for IE 6 and IE 7, where you have to specify margin: -7px 0;
>
> Enjoy finding more bugs. For your reference ("Box model"):
> http://www.w3.org/TR/CSS21/box.html#border-color-properties
> I would also be interested to hear about Safari, Fx 3b and IE 8b.
>
> Thanks,
>
> Manfred
>
> __
> css-discuss [EMAIL PROTECTED]
> http://www.css-discuss.org/mailman/listinfo/css-d
> List wiki/FAQ -- http://css-discuss.incutio.com/
> List policies -- http://css-discuss.org/policies.html
> Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
>
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] styling
On 09/04/2008, Philippe Wittenbergh <[EMAIL PROTECTED]> wrote: > > On Apr 9, 2008, at 5:28 AM, Manfred Staudinger wrote: > > > b) Firefox 2.0.0.13 ignores height completely. > > > Gecko (Firefox) does honour the height. But it uses the 'border-box' > model for . That means: padding and border-width are inside the > specified height. In the content-box model, the specified height (or > width) applies only to the content of the box (the way browsers apply > height (width) to any other block level element. > > For more on the difference between the two models, see > <http://www.w3.org/TR/css3-ui/#box-model> Thanks for the correction and the pointer! Manfred __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] IE table-layout bug? (Was: IE table column width)
I have posted this before, but could not find anything in the
meantime: IE6 and IE7
seem to add any horizontal padding for to the width for the element.
Test case:
http://test.rudolphina.org/col-width.html
Questions:
- Is IE 6, IE 7 in accordance with the specification or is it a bug?
- How does it look in Safari, Firefox 3 and IE 8 ?
Regards,
Manfred
On 06/04/2008, Manfred Staudinger <[EMAIL PROTECTED]> wrote:
> Assume we have a table with these basic properties:
> table {
>border-collapse: collapse;
>border: 1px solid #859EB5;
>border-spacing: 0;
>font-family: tahoma;
> }
> td {
>border: 1px solid #859EB5;
>font-size: 11px; text-align: right;
>padding-top: 1px; padding-bottom: 1px;
>padding-right: 0px; padding-left: 0px;
> }
> Note the last line: horizontal padding is set to 0. Assume further the
> table has 8 columns which should have an alternating width of 60px and
> 90px respectively. We do this by assigning a class to the col:
>
>
>
>
>
>
>
>
>
>
> and then define the column width with css:
> table col { width: 90px; } /* take this as a default */
> table col.num1 { width: 60px; }
> table col.cur1 { width: 90px; color: black; background-color: #ffc;}
>
> To take advantage of the fixed table layout we specify
> table {
>table-layout: fixed;
>width: 609px; /* (60+90)*8 for col-width + (8+1) for borders */
> }
>
> The result is shown in Tab. 1 (http://test.rudolphina.org/col-width.html).
> The
> display is the same for Firefox 2.0.0.13, Opera 9.25, IE 6 and IE 7.
>
> But this changes if we specify a padding (Tab. 2) for the cells like
> td { padding-right: 4px; padding-left: 0px; }
> as IE 6 and IE 7 enlarge each column by 4px (in the absence of a colspan).
>
> To get IE 6 and IE 7 to display the same as Firefox and Opera again (Tab. 3)
> it is necessary to overwrite the specified col width by
> table#t3 col { width: 86px; }
> table#t3 col.num1 { width: 56px; }
> table#t3 col.cur1 { width: 86px; }
> Note: Other tests seem to indicate that this might not sufficient in cases
> where colspans are present.
>
> Questions:
> 1. Is IE 6, IE 7 in accordance with the specification?
> 2. How does it look in Safari, Firefox 3 and IE 8 ?
>
> Regards,
>
> Manfred
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] How do you feed IE versions different css than w3c compliant browsers?
On 15/04/2008, John Griessen <[EMAIL PROTECTED]> wrote: > Manfred Staudinger wrote: > > > Hi John, > > > > If you want to select IE6 and IE7, but not IE8 nor IE5.5 or IE5.01 > > then you might use > > > > > > > > > > Thanks, > > very helpful. Looks like you just put this in line with your stds > compliant css > and the " css here" lines are fed to the version of IE you selected, right? Yes. Manfred __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] How do you feed IE versions different css than w3c compliant browsers?
On 15/04/2008, Bill Brown <[EMAIL PROTECTED]> wrote:
> You can use this syntax to target all NON-MSIE browsers:
>
> @import url("css/fix/non_msie.css");
>
Thats definitely an unnecessary hack. The correct (although
proprietary) syntax would be:
css here
Regards,
Manfred
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] How do you feed IE versions different css than w3c compliant browsers?
On 16/04/2008, Bill Brown <[EMAIL PROTECTED]> wrote: > I could not more *strongly* disagree with you, and I'm not sure why you are > calling my syntax "incorrect" or "unnecessary" either. If they both do the > same thing, mine not only appears (to me, at least) to be more elegant, but > is shorter and more understandable. By comparison: > > Mine: > > ... anything at all, including css here > > > and yours: > > > ... anything at all, including css here > > > It seems a little odd to call my (correct and occasionally necessary) > syntax "unnecessary" and "incorrect" and then send through a longer, more > complicated syntax to accomplish the same thing. > > Or am I totally missing something here? Yes, there is a documentation about this proprietary syntax (as David Laakso has pointed out) http://msdn2.microsoft.com/en-us/library/ms537512(VS.85).aspx and certainly your invention is not covered by it. It is not future proof too, as MS may come up with an IE which still recognizes "Downlevel-revealed Conditional Comments" as documented, but not your variant of it. Regards, Manfred __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] How do you feed IE versions different css than w3c compliant browsers?
On 16/04/2008, James Leslie <[EMAIL PROTECTED]> wrote: > Can anyone explain why you would want to target all non-IE browsers and > then all IE browsers? More realistic example: assume you want to use css 2.1 selectors (those which are supported even by IE7). This makes it necessary to hide the rules from IE6 and as a consequence you will end up with 2 very different stylsheets: one for IE6 and below and one for IE7 and Firefox etc. This could be done with css for Fx, Opera, Safari and IE 7 I'm not going to say thats beautiful or standards conform. But that is the documented proprietary selection mechanism called "conditional comments" for IE. Regards, Manfred __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] How do you feed IE versions different css than w3ccompliant browsers?
On 16/04/2008, James Leslie <[EMAIL PROTECTED]> wrote: > -Original Message- > > More realistic example: assume you want to use css 2.1 selectors (those > which are supported even by IE7). This makes it necessary to hide the > rules from IE6 and as a consequence you will end up with 2 very > different stylsheets: one for IE6 and below and one for IE7 and Firefox > etc. This could be done with > > > > css for Fx, Opera, Safari and IE 7 > > > > > > I'm not going to say thats beautiful or standards conform. But that is > the documented proprietary selection mechanism called "conditional > comments" for IE. > > > --- > > But in this example IE6 won't understand the CSS2.1 selectors and so > will ignore them or misinterpret it. In fact it will be impossible to make IE6 behave after fed with lots of advanced selectors. > Therefore we just add some extra commands in an IE6 > specific conditional comment so that IE6 displays the element in a > suitable way. Isn't that pretty much the principle of graceful degradation? > I personally use CC's on every site to deal with IE quirks, but wouldn't > dream of trying to hack a (MS proprietary)conditional comment to feed > stylesheets to other browsers. It seems very unsafe in terms of future > proofing to me. The CC is targeting _only_ IE and no other browser, of course. The first CC is only there to prevent IE's other than IE 7 from reading the css. For the "other browsers" there are simply 2 comments, one before and one after the
[css-d] Beyond CC's, targeting Mozilla, Safari and Opera
Hi list, Currently I'm thinking about a consistent and simple method for CSS to target not only IE's but also Mozilla, Safari and Opera, each of them separately and standards compliant. Up to now the CSS language actually available for developing web sites is limited by the weakest browser to be supported (IE 6, IE 7). Many great techniques have been generated and documented by web developers to overcome bugs and shortcomings. These constrains will not go away for years to come. But if we had a method to target the most advanced browsers, we would be able to _add_ something new to the (technically) minimalistic approach dictated by MS. Web sites would then look differently in different browsers while functionally still equivalent (a must, I suppose). What are your pros and cons? Regards, Manfred __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Beyond CC's, targeting Mozilla, Safari and Opera
Hi Zoe, > As others have already said, there are no real advantages to browser > detection and targeting. It is certainly true, that Firefox, Safari and Opera have shown very high quality so far. But as many more different and diverse web sites keep coming and make use of advanced CSS features I can imagine that we will see more bugs, shortcomings and implementation differences with advanced browsers. If you want to apply a hack, it will come very handy to limit the scope of it. I want to say, that any solution for my browser detection has to be full W3C standards compliant, independent of Javascript and also should expose CC's to IE's only. As I have seen strong emotions about CC's here, let me clarify my position on that. They are useful to limit IE hacks to IE by using them in the head of the html, but are very problematic if used in the body section. From the standards point of view CC's are even worse, because they allow constructs equivalent to standard html A terrible idea as you can see and I am glad _no_ other browser has adopted it! > However, your idea of giving more advanced browsers more advanced CSS > does have advantages. It's called progressive enhancement, and it's Thanks to your reminder I've read a lot about "progressive enhancement" and think the wording is better compared to "graceful degradation" which I know for some years now. It seems to come from Javascript and to imply multiple steps, which makes sense in CSS too. It has obviously become a buzz word and I found it used even for XSLT! Thanks (also to Philippe and Georg) for your response, Manfred On 18/04/2008, Zoe M. Gillenwater <[EMAIL PROTECTED]> wrote: > Manfred Staudinger wrote: > > Hi list, > > > > Currently I'm thinking about a consistent and simple method for CSS to > > target not only IE's but also Mozilla, Safari and Opera, each of them > > separately and standards compliant. > > > > Up to now the CSS language actually available for developing web sites > > is limited by the weakest browser to be supported (IE 6, IE 7). Many > > great techniques have been generated and documented by web developers > > to overcome bugs and shortcomings. > > > > These constrains will not go away for years to come. But if we had a > > method to target the most advanced browsers, we would be able to _add_ > > something new to the (technically) minimalistic approach dictated by > > MS. Web sites would then look differently in different browsers while > > functionally still equivalent (a must, I suppose). > > > > What are your pros and cons? > > > > > Hi Manfred, > > As others have already said, there are no real advantages to browser > detection and targeting. > > However, your idea of giving more advanced browsers more advanced CSS > does have advantages. It's called progressive enhancement, and it's > quite possible without browser detection. I suggest Googling > "progressive enhancement" for more on the general idea, and reading the > book Transcending CSS for in-depth teaching of how to design and develop > web sites with a progressive enhancement mindset. (The author states the > "transcending" way of designing goes beyond progressive enhancement, but > I think it's just mincing words -- same basic concept and techniques.) > > Best, > Zoe > > > -- > Zoe M. Gillenwater > Design Services Manager > UNC Highway Safety Research Center > http://www.hsrc.unc.edu > > > __ > css-discuss [EMAIL PROTECTED] > http://www.css-discuss.org/mailman/listinfo/css-d > List wiki/FAQ -- http://css-discuss.incutio.com/ > List policies -- http://css-discuss.org/policies.html > Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ > __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Beyond CC's, targeting Mozilla, Safari and Opera
On 19/04/2008, David Laakso <[EMAIL PROTECTED]> wrote: > Manfred Staudinger wrote: > > ***off-list*** > > You got a uri? Or just a mouth? > David, > You got a uri? I have not yet decided to publish it. To clarify the pros and cons I started this thread. > Or just a mouth? I don't understand what you mean, please clarify. Manfred Manfred __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Beyond CC's, targeting Mozilla, Safari and Opera
Hi all, I suppose my question was too general to get useful answers. This time its more concrete, you can try it: http://documenta.rudolphina.org/cond-css-demo.xml Any questions? Manfred __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Text Wrap around Floated Div
On 13/05/2008, Del Wegener <[EMAIL PROTECTED]> wrote: > It never occurred to me that it might not be legal to have a float inside an > ordered list. Why not? does not allow any child other than , so the problem is not the float. Hope this helps, Manfred __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Text Wrap around Floated Div
On 14/05/2008, Bobby Jack <[EMAIL PROTECTED]> wrote: > I think you're right here. Although David raised the > legality issue, a div within a list item is perfectly > valid (floated or not), and this equivalent of your > original does render as expected (as I understand it, > i.e. the same as the paragraph version) in Opera, > Firefox 3, and (presumably, based on your evidence and > my conjecture) IE 6/7. So it looks like a FF2 bug. The was not used within a list item but as a direct child of , which is invalid. The content model for in html 4.01 strict only alows (no FF2 bug here). Manfred __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] anchor doesn't receive focus in firefox 1.5
Hi list, This following can be demonstrated with (currently for _fx_only_) page http://free.pages.at/staudinger/Regest/Indices/Index.html The anchor E on the left side E will receive focus in firefox 1.0.4+ when anchor E from the top line E is clicked - but not in firefox 1.5. Is the change intentional? Is there anything I can do about? Regards, Manfred __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] anchor doesn't receive focus in firefox 1.5
I've submitted bug 321493 for this. https://bugzilla.mozilla.org/show_bug.cgi?id=321493 Manfred On 15/12/05, Manfred Staudinger <[EMAIL PROTECTED]> wrote: > Hi list, > > This following can be demonstrated with (currently for _fx_only_) page > http://free.pages.at/staudinger/Regest/Indices/Index.html > > The anchor E on the left side > E > will receive focus in firefox 1.0.4+ when anchor E from the top line > E > is clicked - but not in firefox 1.5. > > Is the change intentional? Is there anything I can do about? > > Regards, Manfred > __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] Check with Safari 1.3, 2.0 for UTF-8 chars
Can someone please check this page http://free.pages.at/staudinger/Regest/Regesten/A1603-11-29-02004.xml with Safari 1.3 and 2.0? I've seen a Problem UTF-8 characters (ä ö ü) not displaying correctly, but wanted to know if the problem is reproducible. Thanks in advance! Manfred __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] span not displayed by ie6
Hi list,
If you click "Anton Kupfer" on this page
http://free.pages.at/staudinger/Regest/Regesten/A1608-10-14-02382.xml
then after "Quellen:" Fx 1.5 displays
1604-04-10 1605-09-03 1608-10-14 1612-10-18
as three links and one span, but ie6 only displays three links,
1604-04-10 1605-09-03 1612-10-18
the span for 1608-10-14 is missing. In the stylesheet at
http://free.pages.at/staudinger/Regest/Regest_b.css
you will find
div.docindex span {display: none;}
div.docindex a {margin-right: 0px;}
and from embedded styles
div.docindex span.Z02382 { display: inline; }
div.docindex a.Z02382 { display: none; }
while for 1608-10-14 both a and span have a class="Z02382".
So it seems the second line from the embedded style
gets honoured, the first one not - strange. Any help would be
greatly appreciated.
Manfred
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] span not displayed by ie6
Ingo, http://free.pages.at/staudinger/Regest/Regesten/A1608-10-14-02382.html I've uploaded a sligthly different version of this page in html, where you can see the very same problem. Manfred On 02/03/06, Ingo Chao <[EMAIL PROTECTED]> wrote: > Manfred Staudinger wrote: > > If you click "Anton Kupfer" on this page > > http://free.pages.at/staudinger/Regest/Regesten/A1608-10-14-02382.xml > > then after "Quellen:" Fx 1.5 displays > > 1604-04-10 1605-09-03 1608-10-14 1612-10-18 > > as three links and one span, but ie6 only displays three links, > > 1604-04-10 1605-09-03 1612-10-18 > > the span for 1608-10-14 is missing. > > > Manfred, > > I cannot reproduce the problem on a static html page rebuild: > http://www.satzansatz.de/others/manfred.html > > I had to copy the markup from Fx "view selected source" and added the > styles you provided. > > Can you provide a static page that reproduces the problem? > > Ingo > > -- > http://www.satzansatz.de/css.html > __ > css-discuss [EMAIL PROTECTED] > http://www.css-discuss.org/mailman/listinfo/css-d > IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 > List wiki/FAQ -- http://css-discuss.incutio.com/ > Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ > __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] span not displayed by ie6
On 02/03/06, Ingo Chao <[EMAIL PROTECTED]> wrote:
> This is not a static page.
I've updated the page with a static initial content for the div in
question (also
changed the inline style="display: none" to style="display: block"). If you
click "Anton Kupfer" you get the dynamic content (and the problem appears):
http://free.pages.at/staudinger/Regest/Regesten/A1608-10-14-02382.html
>And there is physically no span inside A
> class=Z02382, according to IEDomExplorer.
>
>A class=Z02382
>A class=Z02675
Even when I eliminated all the css for the span elements, none of them
got copied.
> This is quite different from the Dom view I get from Firefox1.5 Dom
> Inspector when I open "AntonKupfer" :
>
>A class=Z02382
>SPAN class=Z02382
>A class=Z02675
>SPAN class=Z02675
You see here the a and span elements side by side, exactly reflecting the
source.
> Your Style
>div.docindex span.Z02382 { display: inline; }
> does not apply in IE without this span.
correct
> I may be wrong, but I think this problem is not within CSS. At least I
> cannot tell if there is a span inside or not in IE6.
Agreed. Problem seems to be that IE-JScript copies the a elements but
not the span elements. Thanks a lot for helping sorting out and clarifying this!
>Maybe someone who is experienced with Javascript could provide more
>help, sorry.
Any suggestion off-list?
> Since I started typing my first answer at the bottom, and you reply to
> me with top posting, but I refuse to switch, the next one should
> alternate and top post again. The beginning of the thread would be
> somewhere in the middle of the resulting post.
I'm confused here. If I look at the css-d thread, it appears to me we both
posted at the bottom?
Manfred
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
