Re: [WSG] The weirdest IE bug I've ever encountered.
Then perhaps you would care to explain why this document: http://zenpsycho.com/quirkstest2.htm activates standards mode, when the table you've linked to suggests that it should be in quirks mode? Table clearly shows, that this page should activate standards mode. It is the last line, „unrecognized doctype“. I would conclude that the page you've linked to does not reflect reality. What would you conclude? I conclude, that HTML (No Version Present) means doctype like this: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML//EN and !DOCTYPE html falls under unrecognized !DOCTYPE (and is actually the only reason why html5 has doctype at all: because unrecognized doctype triggers standards compatible mode in IE), hence the table is accurate. Test with the versionless doctype I gave above and see. Regards, Rimantas -- http://rimantas.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] The weirdest IE bug I've ever encountered.
I have a stripped down example of it here. The bug only occurs in IE 7, and possibly ie6, and it occurs in IE8 running in compatibility mode. I cannot be sure whether it happens in IE8 in IE8 mode or not. (MS have made the compatibility mode interface so bloody complex I can't figure out whether I'm in it or not at any given time). The example is here: http://zenpsycho.com/iebug.htm On that page, you will see an italic letter v on the left hand side of the screen, and a view cart link on the right hand side which is NOT clickable, but which should be clickable. The ingredients of this bug appear to be: * a left floated element followed by * an italic styled element nested directly inside a p tag, which are both preceded by * a menu with links that are floated to the right Combine these things together, and the right hand side of the screen becomes unclickable. (you can have a huge column of links on the right hand side, and they're all useless). What really bothers me about this one, is that the spell is mysteriously broken (the bug goes away) if you change this: Pspanv /span/P to this: Pspanv /spannbsp;/P Just what on earth is going on here? *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] The weirdest IE bug I've ever encountered.
I took a look at your source code - there are a whole bunch of issues beginning with oddities in your HTML - things like: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd; HTML lang=en xml:lang=en xmlns=http://www.w3.org/1999/xhtml; Your saying the DocType is HTML 4.01 Transitional, but then you're linking to the XHTML namespace - that's probably confusing IE right from the get go. Using Transitional DocTypes also pisses IE off. ul Weird spacees in your tags? That's begging for IE weirdness. Try starting with perfect HTML that's of the Strict DocType whether it's HTML or XHTML. Joseph R. B. Taylor /Designer / Developer/ -- Sites by Joe, LLC /Clean, Simple and Elegant Web Design/ Phone: (609) 335-3076 Web: http://sitesbyjoe.com Email: j...@sitesbyjoe.com On 6/3/09 9:14 PM, Breton Slivka wrote: I have a stripped down example of it here. The bug only occurs in IE 7, and possibly ie6, and it occurs in IE8 running in compatibility mode. I cannot be sure whether it happens in IE8 in IE8 mode or not. (MS have made the compatibility mode interface so bloody complex I can't figure out whether I'm in it or not at any given time). The example is here: http://zenpsycho.com/iebug.htm On that page, you will see an italic letter v on the left hand side of the screen, and a view cart link on the right hand side which is NOT clickable, but which should be clickable. The ingredients of this bug appear to be: * a left floated element followed by * an italic styled element nested directly inside a p tag, which are both preceded by * a menu with links that are floated to the right Combine these things together, and the right hand side of the screen becomes unclickable. (you can have a huge column of links on the right hand side, and they're all useless). What really bothers me about this one, is that the spell is mysteriously broken (the bug goes away) if you change this: Pspanv/span/P to this: Pspanv/spannbsp;/P Just what on earth is going on here? *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] The weirdest IE bug I've ever encountered.
Joe is right, you got alot of tags unclosed and you're switch from HTML to XHTML style tags. Pick one, and use the validator! You'll see a pretty much bug free site in no time. _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Joseph Taylor Sent: 04 June 2009 02:38 To: wsg@webstandardsgroup.org Subject: Re: [WSG] The weirdest IE bug I've ever encountered. I took a look at your source code - there are a whole bunch of issues beginning with oddities in your HTML - things like: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd; http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd HTML lang=en xml:lang=en xmlns=http://www.w3.org/1999/xhtml; http://www.w3.org/1999/xhtml Your saying the DocType is HTML 4.01 Transitional, but then you're linking to the XHTML namespace - that's probably confusing IE right from the get go. Using Transitional DocTypes also pisses IE off. ul Weird spacees in your tags? That's begging for IE weirdness. Try starting with perfect HTML that's of the Strict DocType whether it's HTML or XHTML. Joseph R. B. Taylor Designer / Developer -- Sites by Joe, LLC Clean, Simple and Elegant Web Design Phone: (609) 335-3076 Web: http://sitesbyjoe.com Email: j...@sitesbyjoe.com On 6/3/09 9:14 PM, Breton Slivka wrote: I have a stripped down example of it here. The bug only occurs in IE 7, and possibly ie6, and it occurs in IE8 running in compatibility mode. I cannot be sure whether it happens in IE8 in IE8 mode or not. (MS have made the compatibility mode interface so bloody complex I can't figure out whether I'm in it or not at any given time). The example is here: http://zenpsycho.com/iebug.htm On that page, you will see an italic letter v on the left hand side of the screen, and a view cart link on the right hand side which is NOT clickable, but which should be clickable. The ingredients of this bug appear to be: * a left floated element followed by * an italic styled element nested directly inside a p tag, which are both preceded by * a menu with links that are floated to the right Combine these things together, and the right hand side of the screen becomes unclickable. (you can have a huge column of links on the right hand side, and they're all useless). What really bothers me about this one, is that the spell is mysteriously broken (the bug goes away) if you change this: Pspanv /span/P to this: Pspanv /spannbsp;/P Just what on earth is going on here? *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.52/2152 - Release Date: 06/03/09 05:53:00 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] The weirdest IE bug I've ever encountered.
Actually he won't see a bug free site at all. Correcting the doctype and other issues makes no difference. The bug does not occur in Internet Explorer 6. Something like this has been reported previously but the only references I can find are not directly applicable to this situation. http://foorider.blogspot.com/2007/09/css-ie7-float-italic-background.html http://www.positioniseverything.net/explorer/italicbug-ie.html Steve _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Essential eBiz Solutions Sent: 04 June 2009 02:57 To: wsg@webstandardsgroup.org Subject: RE: [WSG] The weirdest IE bug I've ever encountered. Joe is right, you got alot of tags unclosed and you're switch from HTML to XHTML style tags. Pick one, and use the validator! You'll see a pretty much bug free site in no time. _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Joseph Taylor Sent: 04 June 2009 02:38 To: wsg@webstandardsgroup.org Subject: Re: [WSG] The weirdest IE bug I've ever encountered. I took a look at your source code - there are a whole bunch of issues beginning with oddities in your HTML - things like: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd; http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd HTML lang=en xml:lang=en xmlns=http://www.w3.org/1999/xhtml; http://www.w3.org/1999/xhtml Your saying the DocType is HTML 4.01 Transitional, but then you're linking to the XHTML namespace - that's probably confusing IE right from the get go. Using Transitional DocTypes also pisses IE off. ul Weird spacees in your tags? That's begging for IE weirdness. Try starting with perfect HTML that's of the Strict DocType whether it's HTML or XHTML. Joseph R. B. Taylor Designer / Developer -- Sites by Joe, LLC Clean, Simple and Elegant Web Design Phone: (609) 335-3076 Web: http://sitesbyjoe.com Email: j...@sitesbyjoe.com On 6/3/09 9:14 PM, Breton Slivka wrote: I have a stripped down example of it here. The bug only occurs in IE 7, and possibly ie6, and it occurs in IE8 running in compatibility mode. I cannot be sure whether it happens in IE8 in IE8 mode or not. (MS have made the compatibility mode interface so bloody complex I can't figure out whether I'm in it or not at any given time). The example is here: http://zenpsycho.com/iebug.htm On that page, you will see an italic letter v on the left hand side of the screen, and a view cart link on the right hand side which is NOT clickable, but which should be clickable. The ingredients of this bug appear to be: * a left floated element followed by * an italic styled element nested directly inside a p tag, which are both preceded by * a menu with links that are floated to the right Combine these things together, and the right hand side of the screen becomes unclickable. (you can have a huge column of links on the right hand side, and they're all useless). What really bothers me about this one, is that the spell is mysteriously broken (the bug goes away) if you change this: Pspanv /span/P to this: Pspanv /spannbsp;/P Just what on earth is going on here? *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.52/2152 - Release Date: 06/03/09 05:53:00 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] The weirdest IE bug I've ever encountered.
On Thu, Jun 4, 2009 at 11:38 AM, Joseph Taylor j...@sitesbyjoe.com wrote: I took a look at your source code - there are a whole bunch of issues beginning with oddities in your HTML - things like: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd; HTML lang=en xml:lang=en xmlns=http://www.w3.org/1999/xhtml; Your saying the DocType is HTML 4.01 Transitional, but then you're linking to the XHTML namespace - that's probably confusing IE right from the get go. Using Transitional DocTypes also pisses IE off. ul Weird spacees in your tags? That's begging for IE weirdness. Try starting with perfect HTML that's of the Strict DocType whether it's HTML or XHTML. I'm pretty sure the well observed and documented behavior of IE is that WHICH doctype makes absolutely not a lick of difference at all. The only thing it looks for is the string !doctype at the beginning of the document, which decides whether it goes into quirksmode or not. But to such objections, I've cleaned up the example. It now validates on the w3c validator, has no spare spaces in the wrong places, doesn't disagree with itself about what sort of document it is, and still exhibits the bug, about as I predicted it would. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] The weirdest IE bug I've ever encountered.
On that page, you will see an italic letter v on the left hand side of the screen, and a view cart link on the right hand side which is NOT clickable, but which should be clickable. The issue does not seem to be related to standards. I cleaned up the code and the problem persists. The cause is that the right floated View Cart link does not get pushed below the paragraph. The paragraph has a width of 100% so it ends up covering the link which is why it is not clickable. To see it more clearly, I put a version of your page with different colored borders around each block at: http://neighborwebmaster.com/tests/iebug.html If you open it in IE8 and switch between IE7 compatibility mode and back, you will see the view cart link moving up and down. Best regards, Kepler Gelotte Neighbor Webmaster, Inc. 156 Normandy Dr., Piscataway, NJ 08854 www.neighborwebmaster.com phone/fax: (732) 302-0904 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] The weirdest IE bug I've ever encountered.
I see I have still not conviced you of the weirdness of this bug. I've updated my version to have a 1px border, and more items in the list, which are NOT covered by the P element. None of them are clickable, disconfirming your conclusions. On Thu, Jun 4, 2009 at 12:53 PM, Kepler Gelotte kep...@neighborwebmaster.com wrote: On that page, you will see an italic letter v on the left hand side of the screen, and a view cart link on the right hand side which is NOT clickable, but which should be clickable. The issue does not seem to be related to standards. I cleaned up the code and the problem persists. The cause is that the right floated View Cart link does not get pushed below the paragraph. The paragraph has a width of 100% so it ends up covering the link which is why it is not clickable. To see it more clearly, I put a version of your page with different colored borders around each block at: http://neighborwebmaster.com/tests/iebug.html If you open it in IE8 and switch between IE7 compatibility mode and back, you will see the view cart link moving up and down. Best regards, Kepler Gelotte Neighbor Webmaster, Inc. 156 Normandy Dr., Piscataway, NJ 08854 www.neighborwebmaster.com phone/fax: (732) 302-0904 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] The weirdest IE bug I've ever encountered.
Try adding borders to all block level elements (ie. p, div etc).
Firebug does this for you in Firefox, but you'll need to do it manually
for IE. To make it much more obvious, set a background color too (eg. p,
div {background-color: #00f;} ). If there are unclickable links then
chances are something is covering them.
Breton Slivka wrote:
I see I have still not conviced you of the weirdness of this bug. I've
updated my version to have a 1px border, and more items in the list,
which are NOT covered by the P element. None of them are clickable,
disconfirming your conclusions.
On Thu, Jun 4, 2009 at 12:53 PM, Kepler Gelotte
kep...@neighborwebmaster.com wrote:
On that page, you will see an italic letter v on the left hand side of
the screen, and a view cart link on the right hand side which is NOT
clickable, but which should be clickable.
The issue does not seem to be related to standards. I cleaned up the code
and the problem persists. The cause is that the right floated View Cart
link does not get pushed below the paragraph. The paragraph has a width of
100% so it ends up covering the link which is why it is not clickable.
To see it more clearly, I put a version of your page with different colored
borders around each block at: http://neighborwebmaster.com/tests/iebug.html
If you open it in IE8 and switch between IE7 compatibility mode and back,
you will see the view cart link moving up and down.
Best regards,
Kepler Gelotte
Neighbor Webmaster, Inc.
156 Normandy Dr., Piscataway, NJ 08854
www.neighborwebmaster.com
phone/fax: (732) 302-0904
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
--
*Rob Turner*
Company Leader
www. f l e x a d a t a .com http://flexadata.com
*+1 415 448 7652*
*+61 7 3040 1337*
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***begin:vcard
fn:Rob Turner
n:Turner;Rob
org:Flexa Pty Ltd
email;internet:r...@flexadata.com
title:Company Leader
tel;work:+61 7 3040 1337
tel;cell:+61 4 0115 9060
x-mozilla-html:TRUE
url:http://flexadata.com
version:2.1
end:vcard
Re: [WSG] The weirdest IE bug I've ever encountered.
Sorry, I misread your message, looks like this is not the problem.
Please disregard.
Robert Turner wrote:
Try adding borders to all block level elements (ie. p, div etc).
Firebug does this for you in Firefox, but you'll need to do it
manually for IE. To make it much more obvious, set a background color
too (eg. p, div {background-color: #00f;} ). If there are unclickable
links then chances are something is covering them.
Breton Slivka wrote:
I see I have still not conviced you of the weirdness of this bug. I've
updated my version to have a 1px border, and more items in the list,
which are NOT covered by the P element. None of them are clickable,
disconfirming your conclusions.
On Thu, Jun 4, 2009 at 12:53 PM, Kepler Gelotte
kep...@neighborwebmaster.com wrote:
On that page, you will see an italic letter v on the left hand side of
the screen, and a view cart link on the right hand side which is NOT
clickable, but which should be clickable.
The issue does not seem to be related to standards. I cleaned up the code
and the problem persists. The cause is that the right floated View Cart
link does not get pushed below the paragraph. The paragraph has a width of
100% so it ends up covering the link which is why it is not clickable.
To see it more clearly, I put a version of your page with different colored
borders around each block at: http://neighborwebmaster.com/tests/iebug.html
If you open it in IE8 and switch between IE7 compatibility mode and back,
you will see the view cart link moving up and down.
Best regards,
Kepler Gelotte
Neighbor Webmaster, Inc.
156 Normandy Dr., Piscataway, NJ 08854
www.neighborwebmaster.com
phone/fax: (732) 302-0904
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
--
*Rob Turner*
Company Leader
www. f l e x a d a t a .com http://flexadata.com
*+1 415 448 7652*
*+61 7 3040 1337*
--
*Rob Turner*
Company Leader
www. f l e x a d a t a .com http://flexadata.com
*+1 415 448 7652*
*+61 7 3040 1337*
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***begin:vcard
fn:Rob Turner
n:Turner;Rob
org:Flexa Pty Ltd
email;internet:r...@flexadata.com
title:Company Leader
tel;work:+61 7 3040 1337
tel;cell:+61 4 0115 9060
x-mozilla-html:TRUE
url:http://flexadata.com
version:2.1
end:vcard
Re: [WSG] The weirdest IE bug I've ever encountered.
Dropping the DOCTYPE declaration appears to fix it... Breton Slivka wrote: I see I have still not conviced you of the weirdness of this bug. I've updated my version to have a 1px border, and more items in the list, which are NOT covered by the P element. None of them are clickable, disconfirming your conclusions. On Thu, Jun 4, 2009 at 12:53 PM, Kepler Gelotte kep...@neighborwebmaster.com wrote: On that page, you will see an italic letter v on the left hand side of the screen, and a view cart link on the right hand side which is NOT clickable, but which should be clickable. The issue does not seem to be related to standards. I cleaned up the code and the problem persists. The cause is that the right floated View Cart link does not get pushed below the paragraph. The paragraph has a width of 100% so it ends up covering the link which is why it is not clickable. To see it more clearly, I put a version of your page with different colored borders around each block at: http://neighborwebmaster.com/tests/iebug.html If you open it in IE8 and switch between IE7 compatibility mode and back, you will see the view cart link moving up and down. Best regards, Kepler Gelotte Neighbor Webmaster, Inc. 156 Normandy Dr., Piscataway, NJ 08854 www.neighborwebmaster.com phone/fax: (732) 302-0904 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- *Rob Turner* Company Leader www. f l e x a d a t a .com http://flexadata.com *+1 415 448 7652* *+61 7 3040 1337* *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***begin:vcard fn:Rob Turner n:Turner;Rob org:Flexa Pty Ltd email;internet:r...@flexadata.com title:Company Leader tel;work:+61 7 3040 1337 tel;cell:+61 4 0115 9060 x-mozilla-html:TRUE url:http://flexadata.com version:2.1 end:vcard
Re: [WSG] The weirdest IE bug I've ever encountered.
I'm pretty sure the well observed and documented behavior of IE is that WHICH doctype makes absolutely not a lick of difference at all. This is not correct. The only thing it looks for is the string !doctype at the beginning of the document, which decides whether it goes into quirksmode or not. Rendering mode does depend on the doctype: http://msdn.microsoft.com/en-us/library/bb250395.aspx#cssenhancements_topic2 ... Regards, Rimantas -- http://rimantas.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] The weirdest IE bug I've ever encountered.
Then perhaps you would care to explain why this document: http://zenpsycho.com/quirkstest2.htm activates standards mode, when the table you've linked to suggests that it should be in quirks mode? for comparison, here's a typical html 4.0 strict doctype: http://zenpsycho.com/quirkstest1.htm I would conclude that the page you've linked to does not reflect reality. What would you conclude? On Thu, Jun 4, 2009 at 1:51 PM, Rimantas Liubertas riman...@gmail.com wrote: I'm pretty sure the well observed and documented behavior of IE is that WHICH doctype makes absolutely not a lick of difference at all. This is not correct. The only thing it looks for is the string !doctype at the beginning of the document, which decides whether it goes into quirksmode or not. Rendering mode does depend on the doctype: http://msdn.microsoft.com/en-us/library/bb250395.aspx#cssenhancements_topic2 ... Regards, Rimantas -- http://rimantas.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] The weirdest IE bug I've ever encountered.
I see I have still not conviced you of the weirdness of this bug. I've updated my version to have a 1px border, and more items in the list, which are NOT covered by the P element. None of them are clickable, disconfirming your conclusions. Actually, I was agreeing with you that it is a bug. I still think I am correct. The paragraph is still on top of the ul even if it is not covering all the list elements. I created another version where all I did was add a clear:both to the paragraph and now all links are clickable. You can see it here: http://neighborwebmaster.com/tests/iefix.html Best regards, Kepler Gelotte Neighbor Webmaster, Inc. 156 Normandy Dr., Piscataway, NJ 08854 www.neighborwebmaster.com phone/fax: (732) 302-0904 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***BEGIN:VCARD VERSION:2.1 N:Gelotte;Kepler;;Mr. FN:Kepler Gelotte (kep...@neighborwebmaster.com) ORG:Neighbor Webmaster TITLE:Web Designer TEL;WORK;VOICE:(732) 302-0904 TEL;WORK;FAX:(732) 302-0904 ADR;WORK:;;156 Normandy Dr;Piscataway;NJ;08854;United States of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:156 Normandy Dr=0D=0APiscataway, NJ 08854=0D=0AUnited States of America URL;WORK:http://www.neighborwebmaster.com EMAIL;PREF;INTERNET:kep...@neighborwebmaster.com REV:20070415T052107Z END:VCARD
Re: [WSG] The weirdest IE bug I've ever encountered.
So you think that there's an invisible part to the paragraph that is not outlined by the border? Kind of makes the border 1px approach to development kind of useless in IE in the face of behavior like this, don't you think? But I still don't think this idea quite matches up. In the broken version, try clicking on the ul using the IE developer tools element select. You end up selecting not the P tag, which you've hypothesised is covering the UL. Instead you end up selecting the body tag. On Thu, Jun 4, 2009 at 2:28 PM, Kepler Gelotte kep...@neighborwebmaster.com wrote: I see I have still not conviced you of the weirdness of this bug. I've updated my version to have a 1px border, and more items in the list, which are NOT covered by the P element. None of them are clickable, disconfirming your conclusions. Actually, I was agreeing with you that it is a bug. I still think I am correct. The paragraph is still on top of the ul even if it is not covering all the list elements. I created another version where all I did was add a clear:both to the paragraph and now all links are clickable. You can see it here: http://neighborwebmaster.com/tests/iefix.html Best regards, Kepler Gelotte Neighbor Webmaster, Inc. 156 Normandy Dr., Piscataway, NJ 08854 www.neighborwebmaster.com phone/fax: (732) 302-0904 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] The weirdest IE bug I've ever encountered.
To counter my point and support yours though, setting a width on the P tag also makes the elements clickable. Which does seem to suggest that the P tag extends vertically down further than its border suggests it does. On Thu, Jun 4, 2009 at 2:39 PM, Breton Slivka z...@zenpsycho.com wrote: So you think that there's an invisible part to the paragraph that is not outlined by the border? Kind of makes the border 1px approach to development kind of useless in IE in the face of behavior like this, don't you think? But I still don't think this idea quite matches up. In the broken version, try clicking on the ul using the IE developer tools element select. You end up selecting not the P tag, which you've hypothesised is covering the UL. Instead you end up selecting the body tag. On Thu, Jun 4, 2009 at 2:28 PM, Kepler Gelotte kep...@neighborwebmaster.com wrote: I see I have still not conviced you of the weirdness of this bug. I've updated my version to have a 1px border, and more items in the list, which are NOT covered by the P element. None of them are clickable, disconfirming your conclusions. Actually, I was agreeing with you that it is a bug. I still think I am correct. The paragraph is still on top of the ul even if it is not covering all the list elements. I created another version where all I did was add a clear:both to the paragraph and now all links are clickable. You can see it here: http://neighborwebmaster.com/tests/iefix.html Best regards, Kepler Gelotte Neighbor Webmaster, Inc. 156 Normandy Dr., Piscataway, NJ 08854 www.neighborwebmaster.com phone/fax: (732) 302-0904 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] another update - ie bug - content disappears on hover
The Guillotine is an interesting approach. I tried the clearing divs, but
that didn't solve the problem. I wish I could set up a generic example, but
it would take me too long to do the entire page. I'll see if I can duplicate
the issue with just the highlighted section.
Here's an update. When I put height:1% on the hovers, the problem
disappears, however, now the content is disappearing when the mouse is
clicked. I tried putting (a:active {height:1%}) and/or (a {height:1%}) with
no effect.
If I solve this, do I get to name a new hack/bug after myself? I've been
wanting to see the 7mary4 hack hit the airwaves for at least the last few
days.
Ted
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Ingo Chao
Sent: Friday, April 29, 2005 10:18 AM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] ie bug - content disappears on hover
Drake, Ted C. schrieb:
When you mouse over some of these divs, the content disappears and the
background color appears. It's like you are erasing it in blocks.
http://positioniseverything.net/explorer/guillotine.html
In case it is not the guillotine, you could provide an URL to a
simplified test case.
Ingo
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] another update - ie bug - content disappears on hover
Drake, Ted C. schrieb:
... I wish I could set up a generic example, but
it would take me too long to do the entire page. I'll see if I can duplicate
the issue with just the highlighted section.
That would be a good approach.
Here's an update. When I put height:1% on the hovers, the problem
disappears, however, now the content is disappearing when the mouse is
clicked. I tried putting (a:active {height:1%}) and/or (a {height:1%}) with
no effect.
As mentioned before, we can't analyze it without an URL to a test case.
IE does reflow the container and its childs on a :hover-transition with
any change of the background. I have written that somewhere.
If I solve this, do I get to name a new hack/bug after myself?
When someone describes a bug, he usually does try to summarize the
problem in a few words or some kind of abstraction like The Guillotine
which fits in a h1. But I think there is nothing wrong with Drake's
Bug in principle. For some reasons, I personally wouldn't prefer this
naming, but probably Chaos Bug would describe the named situation in
IE6 correctly for sure.
The hack might get the name of the author/describer of the original, but
by convention others do name it. But in this case, the hack was
developed some years ago: for a better understanding (since I've read
someone refers to the holy hack the other day), see Ten Questions for
John Gallant:
The well-known Holly hack was invented by this same Holly Bergevin. She
prefers to stay out of the spotlight, so I had to insist we call it the
Holly hack, over her objections I might add. Unknown to us, Doug
Bowman had also come up with the idea, but as he had not yet published
it I was able to affix Holly's name to the hack. Anyway, it sounds so
much better than The IE-improper-box-enlarging-to-trigger-layout hack.
(cited from http://webstandardsgroup.org/features/john-gallant.cfm a
good read about the bughunting process, or, the art of bughunting.)
I think when you have developed that height:1% hack too, it's a great
piece of work. But: when you don't bring it to paper, your bug
description will be lost like the timemachine, fuel-less car and p. mobile.
One important thing is to try your best (shame on me) to make it clear
to understand under which circumstances the bug appears, so you'll have
to sit down, read the relevant sources, and compile a nice demo after
some testing.
Ingo
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
RE: [WSG] another update - ie bug - content disappears on hover
Hi Ingo,
Thank you for the help so far. I have been trying more theories. The Holly
hack for the guillotine or peekaboo bug, which seemed to be the closest, are
not helping.
I've been able to create a generic version of the site and placed it on my
personal server: http://tdrake.net/generic-test.html
On the right side, you will see a section with an expandable menu. This has
the most predictable problems. If you hover over the + signs, the background
will turn dark blue. If you click on a link, it will turn blue. Some of the
divs in the right section will sometimes turn blue as well.
Thanks
Ted
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Ingo Chao
Sent: Friday, April 29, 2005 12:20 PM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] another update - ie bug - content disappears on hover
Drake, Ted C. schrieb:
... I wish I could set up a generic example, but
it would take me too long to do the entire page. I'll see if I can
duplicate
the issue with just the highlighted section.
That would be a good approach.
Here's an update. When I put height:1% on the hovers, the problem
disappears, however, now the content is disappearing when the mouse is
clicked. I tried putting (a:active {height:1%}) and/or (a {height:1%})
with
no effect.
As mentioned before, we can't analyze it without an URL to a test case.
IE does reflow the container and its childs on a :hover-transition with
any change of the background. I have written that somewhere.
If I solve this, do I get to name a new hack/bug after myself?
When someone describes a bug, he usually does try to summarize the
problem in a few words or some kind of abstraction like The Guillotine
which fits in a h1. But I think there is nothing wrong with Drake's
Bug in principle. For some reasons, I personally wouldn't prefer this
naming, but probably Chaos Bug would describe the named situation in
IE6 correctly for sure.
The hack might get the name of the author/describer of the original, but
by convention others do name it. But in this case, the hack was
developed some years ago: for a better understanding (since I've read
someone refers to the holy hack the other day), see Ten Questions for
John Gallant:
The well-known Holly hack was invented by this same Holly Bergevin. She
prefers to stay out of the spotlight, so I had to insist we call it the
Holly hack, over her objections I might add. Unknown to us, Doug
Bowman had also come up with the idea, but as he had not yet published
it I was able to affix Holly's name to the hack. Anyway, it sounds so
much better than The IE-improper-box-enlarging-to-trigger-layout hack.
(cited from http://webstandardsgroup.org/features/john-gallant.cfm a
good read about the bughunting process, or, the art of bughunting.)
I think when you have developed that height:1% hack too, it's a great
piece of work. But: when you don't bring it to paper, your bug
description will be lost like the timemachine, fuel-less car and p. mobile.
One important thing is to try your best (shame on me) to make it clear
to understand under which circumstances the bug appears, so you'll have
to sit down, read the relevant sources, and compile a nice demo after
some testing.
Ingo
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
RE: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes?
newbie questions... What is the advantage of the fact that IDs must be unique on a page? I am aware of the circumstance that if you need to repeat an ID, set is as a class, but have still not figured out the advantage of an ID. ¤ devendra ¤ In addition to everything else, as id replaces name, id becomes a means to navigate to parts of a document using the anchor element: a id=main/a. drew ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes?
On Thu, 10 Feb 2005 06:40:49 -0500, Trusz, Andrew [EMAIL PROTECTED] wrote: newbie questions... What is the advantage of the fact that IDs must be unique on a page? 1. getElementById() works. 2. Validation. If you use div id=maincontent, validator will complain when you have two or more such divs (typical copypaste accident :) Additionally IDs have higher priority than class in CSS, so it's easier to make local styles for element with an ID than with a class. -- regards, Kornel Lesiski ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes?
You can address elements from the DOM (Document Object Model) directly via JavaScript. Cheers, Mike Pepper Accessible Web Developer Internet SEO and Marketing Analyst [EMAIL PROTECTED] http://www.visidigm.com Administrator Guild of Accessible Web Designers [EMAIL PROTECTED] http://www.gawds.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Trusz, Andrew Sent: 10 February 2005 11:41 To: 'wsg@webstandardsgroup.org' Subject: RE: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes? newbie questions... What is the advantage of the fact that IDs must be unique on a page? I am aware of the circumstance that if you need to repeat an ID, set is as a class, but have still not figured out the advantage of an ID. ¤ devendra ¤ In addition to everything else, as id replaces name, id becomes a means to navigate to parts of a document using the anchor element: a id=main/a. drew ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 07/02/05 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes?
-Original Message- From: [EMAIL PROTECTED] On Behalf Of Kornel Lesinski Sent: Thursday, February 10, 2005 7:09 AM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes? newbie questions... What is the advantage of the fact that IDs must be unique on a page? 1. getElementById() works. 2. Validation. If you use div id=maincontent, validator will complain when you have two or more such divs (typical copypaste accident :) Additionally IDs have higher priority than class in CSS, so it's easier to make local styles for element with an ID than with a class. -- regards, Kornel Lesiski * While true all those points had already been mentioned and weren't the point in any case. The point was that you can create links to parts of documents using id: www.mysite.com/mypage.html?id=#myidea drew ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Not and IE bug?!?
Thanks Peter, I'll check it out! On 9-Feb-05, at 5:12 PM, Peter Asquith wrote: Hi Peter Peter Flaschner wrote: Well, the clearing didn't do it. At least not as I understand it. If you're following the lead of the page you mentioned, you will find removing the overflow: hidden; line from the style sheet should solve your problem. By setting the height to zero and then hiding the overflow you're effectively removing the clearer block from the page layout. Setting visibility to hidden, on the other hand, allows the block to take its specified position and size but not be rendered by the browser. I.e. it still takes up the space it would have. I note, too, that your example page contains multiple elements sharing the same ID. IDs must be unique for a given page. Cheers Peter -- Peter Asquith http://www.wasabicube.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Not and IE bug?!?
Well, the clearing didn't do it. At least not as I understand it. Here's a bit more info: ... bunch of stuff... home_bg home float:left/home home-right float:right /home-right footerclear:both/footer /home_bg In ie, home_bg sticks out a couple of pixels below the footer, but not in safari/moz. I've tried applying the :after trick from p.i.e., as well as adding a div class=clearing before and after the footer. To make things a bit more confusing, the exact code as listed above works perfectly here: http://www.digroup.ca/newsite/about_us Can anyone see what I'm missing? Thanks, Peter On 8-Feb-05, at 8:06 PM, Peter Flaschner wrote: Aha. Thanks. Clearing ought to do the trick. Peter On 8-Feb-05, at 7:30 PM, Peter Asquith wrote: Hi Peter [EMAIL PROTECTED] wrote: just-about-to-go-live site, and have run up against something I've never seen before. The problem has to do with a disappearing background image in Safari/Mozilla. It shows in IE, and I can make it show in Safari/Moz if I change the structure around, which causes new problem A little more information about your CSS would be useful. This is pure speculation but could it be that the home and home-right are floating blocks that are collapsing the home-bg block? When you introduce the footer block into the body of the home-bg you're giving it some height again. Maybe you need to clear the floats after the home-right block. Cheers Peter -- Peter Asquith http://www.wasabicube.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Not and IE bug?!?
Hi Peter Peter Flaschner wrote: Well, the clearing didn't do it. At least not as I understand it. If you're following the lead of the page you mentioned, you will find removing the overflow: hidden; line from the style sheet should solve your problem. By setting the height to zero and then hiding the overflow you're effectively removing the clearer block from the page layout. Setting visibility to hidden, on the other hand, allows the block to take its specified position and size but not be rendered by the browser. I.e. it still takes up the space it would have. I note, too, that your example page contains multiple elements sharing the same ID. IDs must be unique for a given page. Cheers Peter -- Peter Asquith http://www.wasabicube.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes?
I thought I should pick up on the comment by Peter and ask one of my many newbie questions... What is the advantage of the fact that IDs must be unique on a page? I am aware of the circumstance that if you need to repeat an ID, set is as a class, but have still not figured out the advantage of an ID. Apologies if this question is not appropriate for this list and should be directed more to a CSS-specific list. ¤ devendra ¤ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Asquith Sent: Wednesday, February 09, 2005 3:12 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Not and IE bug?!? Hi Peter Peter Flaschner wrote: Well, the clearing didn't do it. At least not as I understand it. If you're following the lead of the page you mentioned, you will find removing the overflow: hidden; line from the style sheet should solve your problem. By setting the height to zero and then hiding the overflow you're effectively removing the clearer block from the page layout. Setting visibility to hidden, on the other hand, allows the block to take its specified position and size but not be rendered by the browser. I.e. it still takes up the space it would have. I note, too, that your example page contains multiple elements sharing the same ID. IDs must be unique for a given page. Cheers Peter -- Peter Asquith http://www.wasabicube.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes?
The main advantage of using an ID is simply that it uniquely identifies the element. So your CSS or DOM scripting can target it alone. -- Iain Gardiner http://www.firelightning.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Devendra Shrikhande Sent: 09 February 2005 22:27 To: wsg@webstandardsgroup.org Subject: RE: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes? I thought I should pick up on the comment by Peter and ask one of my many newbie questions... What is the advantage of the fact that IDs must be unique on a page? I am aware of the circumstance that if you need to repeat an ID, set is as a class, but have still not figured out the advantage of an ID. Apologies if this question is not appropriate for this list and should be directed more to a CSS-specific list. ¤ devendra ¤ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Asquith Sent: Wednesday, February 09, 2005 3:12 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Not and IE bug?!? Hi Peter Peter Flaschner wrote: Well, the clearing didn't do it. At least not as I understand it. If you're following the lead of the page you mentioned, you will find removing the overflow: hidden; line from the style sheet should solve your problem. By setting the height to zero and then hiding the overflow you're effectively removing the clearer block from the page layout. Setting visibility to hidden, on the other hand, allows the block to take its specified position and size but not be rendered by the browser. I.e. it still takes up the space it would have. I note, too, that your example page contains multiple elements sharing the same ID. IDs must be unique for a given page. Cheers Peter -- Peter Asquith http://www.wasabicube.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes?
Hi Devendra
Devendra Shrikhande wrote:
What is the advantage of the fact that IDs must be unique on a page? I am aware of the circumstance that if you need to repeat an ID, set is as a class, but have still not figured out the advantage of an ID.
This is an important topic. At first glance, it would seem that there is
little need for an id attribute - why not use classes everywhere?
However, there's a semantic difference between ids and classes, which is
this: it's basically the difference between individuals and groups.
An id identifies a specific individual element of the document markup
and allows CSS to be written that addresses that element specifically.
In addition, you can reference the id in DOM (Document Object Model)
scripting to access an element using the getElementById() function.
A class, on the other hand can apply to many elements, not necessarily
of the same type - you could have a class called warning that is
applied to h1, p, li and so on to emphasize a warning condition,
for instance. Another example (which is pertinent to the thread that you
came in on) is where you want a class to clear floats. It may be that
you need to apply that class on more than one occasion in a particularly
fluid layout. By creating a clearer class you can apply it to any
appropriate block element in order to clear the preceding floats.
Another thing to bear in mind is that ids have higher precedence than
classes in determining what style is applied to a given element. This
means that
#myid {
color: blue;
}
.warning {
color: red;
}
will colour the element
p id=myid class=warningHello!/p
in blue (despite the fact that the .warning directive appears later in
the CSS cascade).
(To ensure that it's red you would need to add
#myid.warning {
color: red;
}
to your stylesheet).
If you carefully lay out your document, with ids for all the main
display blocks, you can set global class styles and then override them
on a block-by-block basis via the blocks' ids. So, for instance it might
be appropriate to display elements with the warning class differently
in a main content block as opposed a summary block.
Eric Meyer covers this topic well on pages 36-38 of his Cascading
Stylesheets The Definitive Guide 2nd Edition.
Having said all that, be wary of overusing ids and classes. By using CSS
selectors carefully, a lot of unnecessary classitis can be avoided.
Hope that helps
Peter
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes?
I thought I should pick up on the comment by Peter and ask one of my many newbie questions... What is the advantage of the fact that IDs must be unique on a page? I am aware of the circumstance that if you need to repeat an ID, set is as a class, but have still not figured out the advantage of an ID. If you used absolute positioning, or a background image of the company branding, or a structure only appropriate for the main navigation, or some other set of styles that should only be rendered if they are unique on the, then it is useful to have IDs instead of classes. In today's browsers, put multiple IDs on a page and the page is ok, if maybe unusually styled. But future browsers are likely to be more strict and may display a big fat parse error message for such a page. That's a good thing -- it'll help you identify when you accidentally gave two id=nav styles to teh same page. It will be problematic, however, when you combine templates, CMSs, and webservices-sourced XML all in one document. This is where we are rescued by namespaces and the increasingly common habit of giving IDs unique prefixes based on the author. -- Ben Curtis : webwright bivia : a personal web studio http://www.bivia.com v: (818) 507-6613 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] Not and IE bug?!?
Hiya, Long-time lurker, first time poster. I'm debugging a just-about-to-go-live site, and have run up against something I've never seen before. The problem has to do with a disappearing background image in Safari/Mozilla. It shows in IE, and I can make it show in Safari/Moz if I change the structure around, which causes new problem in ie... The structure goes like this: ...a bunch of other stuff... home-bg home title/title /home home-right /home-right /home-bg footer/footer With this setup, the home-bg is visible in ie, but not safari/moz. If I do this: ...a bunch of other stuff... home-bg home title/title /home home-right /home-right footer/footer /home-bg - note this is now below the footer home-bg is visible in all browsers, but sticks down a couple pixels below the footer in ie. The page validates (except for some soon-to-come flash-satay cooking), as does the css. I'm stumped. Anyone? ps. I know there are other accessibility issues with the site, which will be addressed once I get the home page working. Thanks, Peter Flaschner Flashlight Design www.flashlightdesign.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Not and IE bug?!?
You need to clear your floats. Check this: http://www.positioniseverything.net/easyclearing.html (technique discovered by WSG member Tony Aslett ;) Andrew. -- http://leftjustified.net/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Not and IE bug?!?
Aha. Thanks. Clearing ought to do the trick. Peter On 8-Feb-05, at 7:30 PM, Peter Asquith wrote: Hi Peter [EMAIL PROTECTED] wrote: just-about-to-go-live site, and have run up against something I've never seen before. The problem has to do with a disappearing background image in Safari/Mozilla. It shows in IE, and I can make it show in Safari/Moz if I change the structure around, which causes new problem A little more information about your CSS would be useful. This is pure speculation but could it be that the home and home-right are floating blocks that are collapsing the home-bg block? When you introduce the footer block into the body of the home-bg you're giving it some height again. Maybe you need to clear the floats after the home-right block. Cheers Peter -- Peter Asquith http://www.wasabicube.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
