8 replies [Last post]
Tyssen
Tyssen's picture
Offline
Moderator
Brisbane
Last seen: 7 years 7 weeks ago
Brisbane
Timezone: GMT+10
Joined: 2004-05-01
Posts: 8201
Points: 1386

Just a very slight problem in IE with a design I'm working on (it's OK in FF & Opera). If you have a look at www.pure-grit.com/index2.php, you'll see a very thin dark line showing just below the top nav links in IE. Anyone know why this might be?
CSS file

How to get help
Post a link. If you can't post a link, jsFiddle it.
My blog | My older articles | CSS Reference

thepineapplehead
thepineapplehead's picture
Offline
Guru
Last seen: 9 weeks 4 days ago
Timezone: GMT+1
Joined: 2004-06-30
Posts: 9674
Points: 810

Very thin line in IE

Remove this:

<?xml version='1.0' encoding='iso-8859-1' ?>

It thows IE into Quirks Mode, which makes it display using all kinds of weird engines.

If the problem still persists, I'm out of ideas Laughing out loud

Verschwindende wrote:
  • CSS doesn't make pies

Tisnew
Tisnew's picture
Offline
Enthusiast
MissOuri
Last seen: 16 years 26 weeks ago
MissOuri
Timezone: GMT-6
Joined: 2005-06-04
Posts: 200
Points: 0

Very thin line in IE

I'm guessing here and this could be way off, but if you split the logo image's

<a href="/"><img id="logo" src="images/logo.jpg" alt="GRiT"></a>

">a" to the next line, then does the black line go away?

What about the last menu item's ">a"?

Like this

http//beta-154104.server1.dotnetsandbox.net/Default2.aspx

Granted, this is an ugly fix, but there's a fellow that proved a better one on the www recently - I just can't find it at the moment.

A crust eaten in peace is better than a banquet partaken in anxiety --- Aesop

Tisnew
Tisnew's picture
Offline
Enthusiast
MissOuri
Last seen: 16 years 26 weeks ago
MissOuri
Timezone: GMT-6
Joined: 2005-06-04
Posts: 200
Points: 0

Very thin line in IE

Thank you for the opportunity to view your site. I enjoyed the cave wall and your artistic-descent into the darkness below...very much reminding me of Mammoth Cave in Kentucky and Carlsbad in New Mexico. A wonderful presentation!

Meanwhile, "Pixel" the Pixie Fairie
http//beta-154104.server1.dotnetsandbox.net/Pixel%20Dust.aspx
discovered a tiny pixel issue in your cave. Just a little too much Logo pixel dust that she magically fixed for you )

http//beta-154104.server1.dotnetsandbox.net/CaveCheck.aspx

Keep up the good work!

A crust eaten in peace is better than a banquet partaken in anxiety --- Aesop

Tyssen
Tyssen's picture
Offline
Moderator
Brisbane
Last seen: 7 years 7 weeks ago
Brisbane
Timezone: GMT+10
Joined: 2004-05-01
Posts: 8201
Points: 1386

Very thin line in IE

Tisnew wrote:
Thank you for the opportunity to view your site. I enjoyed the cave wall and your artistic-descent into the darkness below...very much reminding me of Mammoth Cave in Kentucky and Carlsbad in New Mexico. A wonderful presentation!

Not sure if you're being sarcastic or not :? but thanks for taking the time to delve into the problem a bit deeper and come up with the solution (although I'm not sure why I really needed to see the pixel fairie).
By the way, that site is hosted with Canaca and there's been no real problems to speak of as yet.

How to get help
Post a link. If you can't post a link, jsFiddle it.
My blog | My older articles | CSS Reference

Tisnew
Tisnew's picture
Offline
Enthusiast
MissOuri
Last seen: 16 years 26 weeks ago
MissOuri
Timezone: GMT-6
Joined: 2005-06-04
Posts: 200
Points: 0

Very thin line in IE

I was vexed by your thin line. And wanted to figure-out what caused it. In the process of examining this problem, I learned that the server delivers all the files to the client that it needs (e.g., images, .js script, .css file(Drunk, and, in this case something new - a .php file) and files them in a "temporary internet folder". Meaning that all the files are readily accessible to the guy at the client.

I also learned that, despite the fact that sometimes though the .css file may be in compressed format when it's filed at the client, if you CTL-Copy the compressed .css file and CTL-Paste it into an IDE (in my case, Visual Studio 2005 Beta), then the .css internal text is transformed into readable text in the IDE. It appears the compression is undone by the CTL-Paste function.

I also learned that if you View-Source (even if it's denoted as .PHP) that it really doesn't matter. You can still CTL-Copy that and CTL-Paste it into your IDE. And compile it and it displays locally as a web page.

There were a bunch of other things I learned in attempting to re-create your index2.php page. It took alot of head-scratching work to put this together and to, ultimately, figure-out this solution.

I am quite proud of my first-ever original web-page creation without cloning someone else's code. It's just a little fun in a generally-screwed-up world. My grandchildren liked it and that's all that really matters.

A crust eaten in peace is better than a banquet partaken in anxiety --- Aesop

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 6 years 46 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

Very thin line in IE

Tisnew wrote:
I was vexed by your thin line. And wanted to figure-out what caused it. In the process of examining this problem, I learned that the server delivers all the files to the client that it needs (e.g., images, .js script, .css file(Drunk, and, in this case something new - a .php file) and files them in a "temporary internet folder". Meaning that all the files are readily accessible to the guy at the client.

Congratulations you have discovered the server/clients biggest secret "the Cache" Actually how on earth did you imagine the system of requesting web files could ever work ? The Temp Internet folder is only used if your running IE, FF uses it's own Cache.
"something new- a .php file" have you really not come across php scripting before :? the file that the client receives is still html the php extension instructs the server to pass the file to the php engine for processing of any php instructions within and then generates a normal html page based on those instructions which is received by the client.

Tisnew wrote:

I also learned that, despite the fact that sometimes though the .css file may be in compressed format when it's filed at the client, if you CTL-Copy the compressed .css file and CTL-Paste it into an IDE (in my case, Visual Studio 2005 Beta), then the .css internal text is transformed into readable text in the IDE. It appears the compression is undone by the CTL-Paste function.


Files may be compressed for transmission but I don't think they remain that way at the client end if you open any .css file you may find on your drive you'll just find a normal text file that will open in the simplest editor such as notepad. Regardless the easiest way of obtaining a CSS file is to enter the path to the file in the browser url bar, in IE that will open the file in a notepad window, FF has many more useful tools for this sort of thing.

tisnew wrote:

I also learned that if you View-Source (even if it's denoted as .PHP) that it really doesn't matter. You can still CTL-Copy that and CTL-Paste it into your IDE. And compile it and it displays locally as a web page.


As mentioned above if your viewing a files source then it's in a format that the browser renders i.e html the extension makes no difference to the file contents and is only to instruct the server to pre-process the file before fulfilling the client get request. and you do not "Compile a html file if you cut and paste the view source of the browser viewport and save it as a new file then naturally it is possible to render it off line, img paths and links being the only problem, again all you need do is save the source in notepad for this to work.

tisnew wrote:

There were a bunch of other things I learned in attempting to re-create your index2.php page. It took alot of head-scratching work to put this together and to, ultimately, figure-out this solution.


And that solution would be ?

Tisnew one of the fundamental principles of forums such as these is that they are a learning resource for many ( have a look at the number of times posts are viewed)
When someone posts a question in an open forum they do so with the knowledge that others may also benefit from the discussions and proposed solutions.
There is problem with using personal web space to present solutions in that it is not guaranteed to be permanently available you may delete pages, move server etc. the "solution" then becomes broken and the thread ceases to be of any use to anyone else reading through, it is for this reason that certain forums actually forbid this type of solution providing, linking to personal web sites, and indeed any resource that isn't considered a primary reference and well known.

If you feel compelled to work this way please ensure that your CSS skills are up to the job, lest we lead astray less knowledgeable beginners and also provide a textual explanation of your solution in the thread as well, in order that the thread remains useful to others in the event the link becomes broken.

I would also personally hesitate to recreate someones work on my personal site even though they had provided a public link to the work in progress, some would not take kindly to it, and could well ask that you remove it (as has happened in the past ) and again were left with a meaningless thread.

Lastly could I ask that when you post that you be slightly less cryptic and obtuse, it's very confusing for some of us simple souls we need things direct and to the point Smile

Hugo.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Tisnew
Tisnew's picture
Offline
Enthusiast
MissOuri
Last seen: 16 years 26 weeks ago
MissOuri
Timezone: GMT-6
Joined: 2005-06-04
Posts: 200
Points: 0

Very thin line in IE

Thanks, Hugo. Alot of what you've said makes sense. For example, offering a solution in the form of a website could have temporal problems. This is good advice. There appear to be some unwritten rules about forums and such. This might be a cultural divide as I don't cotton to rules much. Nonetheless, I do appreciate that you took your valuable time to counsel.

The problem, in this case, was the logo image (upper-right) at 125 pixels high. The other deliverables to its left accounted for 124 pixels in height. The browser display, then, resulted in one extra pixel to be shown as a thin black line across the delivered page.

My solution was to specify a height of 124px for the logo image. Some alternative solutions would be to resize the logo image offline as 124px or restyle-redefine via the .css the material to its left as 125px.

At least for the moment, I don't see an alternative to copying a site's material to figure-out what's going-on with it though. Granted, the copy need not be published for public consumption. Just the solution in clearly-written short-form.

There is an 'old' adage. You've probably heard it, "Code does not lie". In this example, both a guru and I were guessing as to the problem and solution. But by copying the material into a test site, and experimenting with scenarios, the "code" told the real story.

Yes, some .css files are filed-down at the client in compressed-format.

When asked about this on a csscreator site-check thread, a fellow suggested it might be Dreamweaver output that caused the compressed version(Drunk to arrive this way. Frankly, I don't know.

But the point is, it doesn't matter. As you can CTL-Copy even compressed files and they will CTL-Paste as un-compressed text in your Development Screen (IDE). Attached, please find an example of a compressed .css as it was displayed by Notepad. As noted earlier, csscreator .css files arrive in non-compressed readable-text format. However, not all deliveries appear this way.

I'm not sure I follow about the "easiest way of obtaining a CSS file is to enter the path to the file in the browser url".

The path to the .css doesn't appear to be available in most page-source(Drunk.

In other words, I'm not clear on how to obtain a .css path derived solely from a page source.

This reference in page source "<style type="text/css" media="screen">@import "grit.css";</style>" doesn't help.

One must know that in Internet Explorer, the temporary internet folder has the .css (and other files) you seek. This can be found by selecting Tools, Internet Options, Temporary Internet files Settings, View Files button.

In Mosaic Firefox, a different path is not so obviously available; so far at least, not clearly through selecting drill-down buttons within Firefox as I've examined help and a multitude of button selections. But, fortunately, the path was provided in an earlier post in the Canacas thread. The Firefox product appears alot less intuitive, or "user-friendly", in terms of how to get things done.

There are a great many things to learn. And none of us has all the answers. But I do enjoy the generally cooperative spirit on this forum. There are issues particularly germane to styles that are interesting. And, hopefully, newbies (like me) not knowing some unwritten rules will not get in the way so much as to not make significant progress in general. Thanks for your patience and good counsel.

A crust eaten in peace is better than a banquet partaken in anxiety --- Aesop

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 6 years 46 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

Very thin line in IE

(At risk of taking this thread Off topic and with apologies to Op)

Tisnew wrote:
Yes, some .css files are filed-down at the client in compressed-format.
When asked about this on a csscreator site-check thread, a fellow suggested it might be Dreamweaver output that caused the compressed version(Drunk to arrive this way. Frankly, I don't know.


It is possible to configure Apache servers to deliver Gzip compressed data and the client is informed that 'Content encoding' is in effect; the client request header has to inform the server that it is capable of receiving files that are so compressed, but once received I would have thought that they are decompressed, but may be wrong and may stay compressed until the browser needs to read them.

Tisnew wrote:
The path to the .css doesn't appear to be available in most page-source(Drunk.
In other words, I'm not clear on how to obtain a .css path derived solely from a page source.
This reference in page source "<style type="text/css" media="screen">@import "grit.css";</style>" doesn't help.


Well that style link tells me that the CSS file lives in the same directory as the page you are viewing which if that is the index file of the top level document root would be http://somesite.com/grit.css
if it was written as say "../grit.css" I would know that it resided one level up from the current page directory, it's usually possible to work out the path to the file.

Tisnew wrote:
One must know that in Internet Explorer, the temporary internet folder has the .css (and other files) you seek. This can be found by selecting Tools, Internet Options, Temporary Internet files Settings, View Files button.


One does indeed know that, only too well, what you may not be aware of is the lengths MS go to preserve the cache.
Try this go to the temp option you quote and run empty temp files now do you think that you have cleared the cache ? think again you haven't. If you know how to work at the dos prompt or better still how to clean boot to dos and how to use switches then run through a few directories using the command line, 'cd' to temp internet files and do 'dir /a /s to allow hidden and system files to be listed and you should see a file called 'index.dat' this holds all your htpp browser requests and other browsing history, ok delete it, fine; not so, there are up to around eight or so of these files all with near identical data most of them are kept in directories that you wouldn't know existed and are kept hidden from all view in windows and are very hard to 'cd' to if you don't know what they are called these files are never deleted under normal operation and it's not possible to delete them from within windows.

tisnew wrote:
In Mosaic Firefox, a different path is not so obviously available; so far at least, not clearly through selecting drill-down buttons within Firefox as I've examined help and a multitude of button selections. But, fortunately, the path was provided in an earlier post in the Canacas thread. The Firefox product appears alot less intuitive, or "user-friendly", in terms of how to get things done.


It may seem that way but it isn't really, what it is is highly configurable to an extent that just isn't possible in IE nor would MS want you to able to.
This is the joy of FF and this style of product development. Spend some time with it it's worth getting to understand and will teach you a lot that IE can't possibly do , oh and if you delete the cache in FF( which isn't difficult to find , and remember that it has to work with the windows configuration to a certain extent) it is gone for good no little secret files lying around.

Not knowing supposedly unwritten rules should not hamper your participation or enjoyment of this forum too much but it's always worth ensuring that one understands general forum etiquette which is not always written as such but has to be gleamed through example so to speak.
Unlike my example here of encouraging and leading a thread away from its original topic 'Highjacking a thread' and as a Mod that's bad practise on my part Smile

Hugo.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me