style="position:relative" leaves an unwanted hole in original location

ycc Peon

Messages:: 99

Likes Received:: 0

Best Answers:: 0

Trophy Points:: 0

#1

Hello,

When I use style="position:relative" the content of the tag will move accordingly, but an empty hole will remain in the original location of the tag. This does not happen for "position:absolute". Maybe I haven't fully understood this, but to me it just seems to give problems.

Here is an example where I move a blue tag on top of a yellow so they can fade into eachother. An ugly empty hole remains where the blue tag was originally placed (to the right of the fading animation). How do I get rid of this empty space and put the text beside the animation?

http://web.telia.com/~u17103363/doc/pos_rel_ex.htm

In many applications I cannot use position:absolute since the material above is of varying size. (I also see now that my code in this example is redundant and that it is maybe enough to fade one of the tags.)

However, this problem has occurred to me on several occasions, I am no expert on this subject, I guess there is something simple that I have missed. Please help

I am on a trip and I may not be able to reply immediately, but I will definitely read all replies very carefully in due course. Thank you.

ycc, Jan 8, 2009 IP

crath Well-Known Member

Messages:: 661

Likes Received:: 33

Best Answers:: 0

Trophy Points:: 100

#2

<style>
#blockDiv001{
	float:left;
	width:100px;
	height:100px;
	background-color:#ffff00;
	border-style: solid;
	border-width: 1px;
	margin-right: 10px;
	border-color: #0000ff;
	layer-background-color:#660099;
	visibility:visible;
	text-align: center;
	padding:4px 0px 4px 0px;
	filter:alpha(opacity=100);
	-moz-opacity:1.0;opacity:1.0;
}

#blockDiv002{
	margin-right: 10px;
	float:left;
	position:absolute;
	left: 8px;
	width:100px;
	height:100px;
	background-color:#0000ff;
	border-style: solid;
	border-width: 1px;
	border-color: #0000ff;
	layer-background-color:#660099;
	visibility:visible;
	text-align: center;
	padding:4px 0px 4px 0px;
	filter:alpha(opacity=100);
	-moz-opacity:1.0;opacity:1.0;
}
</style>

<script type="text/javascript" src="http://web.telia.com/~u17103363/yngveCC/blendtrans.js"></script>
<script type="text/javascript">
// http://brainerror.net/scripts/javascript/blendtrans/

var counter = 0;

function interval(){
if (counter==0){
currentOpac('blockDiv001', 100,  1000);
currentOpac('blockDiv002',   0,  1000);
counter = 1;
} else {
currentOpac('blockDiv001',   0,  1000);
currentOpac('blockDiv002', 100,  1000);
counter = 0;
}

window.setTimeout("interval()", 3000);

}
</script>

<body onload=interval()>

<div id=blockDiv001>yellow</div>
<div id=blockDiv002><br>blue</div>
<script type="text/javascript">
for (i=0; i<500; i++){document.write("text ")}
</script>

</body>

Code (markup):

i cleaned up your css a little bit, and added a margin-right to pad the text off of the boxes, etc. tested using firefox

enjoy

crath, Jan 8, 2009 IP

ycc likes this.

drhowarddrfine Peon

Messages:: 5,428

Likes Received:: 95

Best Answers:: 7

Trophy Points:: 0

#3

ycc said: ↑

Hello,

When I use style="position:relative" the content of the tag will move accordingly, but an empty hole will remain in the original location of the tag.
Click to expand...

Yes it does and this is correct behavior.

drhowarddrfine, Jan 8, 2009 IP

Jaguarjace Guest

Messages:: 52

Likes Received:: 1

Best Answers:: 0

Trophy Points:: 0

#4

i edit the css and change the height of the tags to 95px and also made the position:absolute;:


<head>
<style>
#blockDiv001{float:left; width:100px; height:95px; background-color:#ffff00;
border-style: solid; border-width: 1px; border-color: #0000ff;
layer-background-color:#660099; visibility:visible; text-align: center;
padding:4px 0px 4px 0px;
filter:alpha(opacity=100);-moz-opacity:1.0;opacity:1.0;
}

#blockDiv002{float:left; width:100px; height:95px; background-color:#0000ff; position:absolute; top:14; left:9;
border-style: solid; border-width: 1px; border-color: #0000ff;
layer-background-color:#660099; visibility:visible; text-align: center;
padding:4px 0px 4px 0px;
filter:alpha(opacity=100);-moz-opacity:1.0;opacity:1.0;
}
</style>

<script type="text/javascript" src="http://web.telia.com/~u17103363/yngveCC/blendtrans.js"></script>
<script type="text/javascript">
// http://brainerror.net/scripts/javascript/blendtrans/

var counter = 0;

function interval(){
if (counter==0){
currentOpac('blockDiv001', 100,  1000);
currentOpac('blockDiv002',   0,  1000);
counter = 1;
} else {
currentOpac('blockDiv001',   0,  1000);
currentOpac('blockDiv002', 100,  1000);
counter = 0;
}

window.setTimeout("interval()", 3000);

}
</script>

</head>

<body onload=interval()>

<div id=blockDiv001>yellow</div>
<div id=blockDiv002><br>blue</div>
<script type="text/javascript">
for (i=0; i<500; i++){document.write("text ")}
</script>

</body>

Code (markup):

It looks good

Jaguarjace, Jan 8, 2009 IP

ycc Peon

Messages:: 99

Likes Received:: 0

Best Answers:: 0

Trophy Points:: 0

#5

Thank you everyone and in particular thank you crath for adding "position: absolute;"

I had hesitated to use "position: absolute;" since I thought it would set a position relative to the start of the web-page. But when I now put the two animation div-tags inside an outer (container) div-tag, the "position: absolute" seems to refer to the postition relative the conatiner-div-tag (and not the top/left of the page). I wasn't aware of that.

I have changed the code in the example above accordingly.

The problem is solved now, thanks.

ycc, Jan 8, 2009 IP

Stomme poes Peon

Messages:: 3,195

Likes Received:: 136

Best Answers:: 0

Trophy Points:: 0

#6

Ah, you should know what's going on! Esp if you are going to continue web design stuff.

As Doc said above, that "space left behind" is supposed to happen, but it's not a space. Here's what you did:

you had a block, and its position was static (the default for everyone). It took up x amount of space (all its width+padding, height, and any margins it had). It claimed all that room on the page for itself, meaning no other blocks could just come in and take its place.

When you said "position: relative", by the CSS specs you have created another box right on top of the original one (called a "generated box") and this new box had all the stuff you can "see" in that block. The original box is now invisible, but so far everything's ok because the new box is just sitting right on top of the old one.

When you start adding coordinates though, you move that visual, generated box. You AREN'T moving the Old Box, who's still staying right where you left it, still claiming that space for itself and still not letting anyone else slide into there
thus
the "space leftover".

The new box was sitting "on top of" the old box, and this is partially why you could move it anywhere-- it has a higher z-index by nature (another "layer" if you've heard DreamWeaver talk), and can slide right over other static divs. This is why relative positioning can be dangerous, because you don't expect that.

Re absolute positioning: The rule for that is as follows, because you were kinda half-right when you said what you thought would happen was that they'd be positioned in relation to the web page:

If some J. Random Box is given position: absolute, and no other boxes are "position: anything" (they're still static) then yes, it WILL be positioned from the top left corner of the body (the <body> tag).

But the specs say it should look to the top left corner (top right in a right-to-left page I think) of its nearest positioned ancestor and guess who counts as a positioned ancestor? Any parent, grandparent, whatever who has "position: anything" on it.

We use this technique ALL the time so you'll be glad to know this. You want some little icon absolutely positioned in relation to a box that also has a search bar in it. Let's say that box is a div.

<div id="searchbar">
search stuff
<img the icon>
</div>

if we just set that image to position: absolute it will look for a nearest positioned ancestor and if it doesn't find one, it'll use the body for reference. But if we do this:

#searchbar {
position: relative;
}
#serachbar img {
position: absolute;
right: 2px;
top: 5px;
}

now it's looking at the top and right of #searchbar, not the body.

#searchbar could have also been positioned absolutely-- that also counts as a "positioned ancestor" but the reason we don't normally use it for the containers is because we want the containers to stay "in" the document.

Remember I said there's a generated box sitting above the old box with position: relative? With position: absolute, the generated box is made but also the old box is removed. The other static boxes on the page no longer see it and it can no longer affect those other elements, nor does it see them.

Poorly written and not finished and I want pictures/diagrams but I have a page basically repeating what I've said here. I hope to make it a decent page some day, or rip off a better-written one from any of the many many sites out there repeating this. This is basic to CSS and very powerful for design on web pages so learn it inside and out. IE as usual has a few bugs regarding this so go learn them too.

Stomme poes, Jan 8, 2009 IP

kk5st and ycc like this.

ycc Peon

Messages:: 99

Likes Received:: 0

Best Answers:: 0

Trophy Points:: 0

#7

Stomme poes,

Thank you for the explanation. I think I understand that I must make a special declaration for e.g. img-tags within div-tags if I want the image to "follow" the div-tag relatively. Like you say, it is very useful to know.
#searchbar img {postition: absolute; left: 10px; ...
Code (markup):
The "left : 10px" will now be relative to the external searchbar-div-tag, wherever I move the external searchbar-div-tag. That is how I understand your explanation. The picture will now always follow inside the external searchbar-div-tag.

I hadn't yet read your reply when I continued working on my problem. I got the impression the browsers differ. I just put the fading images in a div-tag (but without using the method you described above). It seemed to work for MSIE but Firefox took the position:absolute as in relation to the body (and not the external div). (In Firefox 3.x pictures ended up left of where they were intended. They were put left of the left margin, at the absolute left of the page.)

I think I solved the problem by including the following in the div containing the images (and some text)::
	left: 48px;
	#left: 0px;
	_left: 0px;
/* 1. all browsers, 2. all MSIE browsers, 3. MSIE 6.0 and older  */
Code (markup):
I included this in the bottom example of:
http://web.telia.com/~u17103363/doc/pos_rel_ex.htm

But I agree your method is better. I will definitely try to include the method you recommend as soon as time permits. (I am on a trip and can only use internetcafes, many of which only use one browser and disallow installation of programs). As I understand I will not have to separate the code for different browsers using your approach.

(The actual page I am trying to make is an introduction to Ubuntu-Linux in Swedish. The animation occurs here:
http://web.telia.com/~u17103363/doc/Ubuntu_installation.htm#Bakgrund
I thnk it should be OK in MSIE, FF and Chrome now?
The very first fade-transition between pictures is still a little crazy, but hopefully people will not see it since they come to the top of the page first I will look into it when time permits.

Thanks for the explanation.

ycc

ycc, Jan 10, 2009 IP

drhowarddrfine Peon

Messages:: 5,428

Likes Received:: 95

Best Answers:: 7

Trophy Points:: 0

#8

Apparently you are using IE as your initial test browser. Never, ever do that. Always, always use a modern browser like Firefox or Safari or anything else but IE. IE is 11 years behind web standards and wrong in its implementation. Right now you are running both those pages in 'quirks mode' and IE won't attempt to behave like any other browser. Validate your html and css for those lists of errors.

drhowarddrfine, Jan 10, 2009 IP

ycc Peon

Messages:: 99

Likes Received:: 0

Best Answers:: 0

Trophy Points:: 0

#9

drhowarddrfine, thanks for your advice. Right now I am in an internetcafe that only uses MSIE - very poor - I agree. I must read up on Quirks mode. Neither do I know how to validate the code. I must definitely improve on this.

I tried implementing Stomme poes' suggestion. I did not use img-tags but I used div-tags. (I also want to include text.)

I thus put two div-tags (called #blockDiv007 and #blockDiv008) into a surrounding div-tag (called myContainer, corresponding to searchbar in Stomme poes' example.)

I may very well have misunderstood or coded wrongly. However, the top-coordinates of the div-tags (red/green) are not relative to the container (container is grey). I must give the red/green tags very high numbers (top: 800 px) in order for them to appear close to the grey myContainer tag.

I still don't understand how to put div-tags into another container div-tag and position them relatively the outer container tag.

The example is still here (bottom - example #3):
http://web.telia.com/~u17103363/doc/pos_rel_ex.htm

I apologize if the problem would be due to me coding wrongly.

Thanks for advice given (and advice to come )

ycc, Jan 11, 2009 IP

deathshadow Acclaimed Member

Messages:: 9,732

Likes Received:: 1,998

Best Answers:: 253

Trophy Points:: 515

#10

Just to clairfy what SP was saying, I have a method for explaining the behavior in question that while not really having much to do with the specification, is an explanation of how the box model actually works. It also explains a third as not yet mentioned technique for doing what's being discussed - negative margins.

When thinking of your elements on a page you are used to thinking of them being a single entity - basically a box. While this is the behavior under normal circumstances you really need to think of it as two separate boxes once you use position:relative or negative margins (or both!) - the 'flow box' and the 'render box'.

The flow box is used to determine how other elements on the page 'flow' around your item. Margins control the size of the flow box. In position:static; (the default) or position:relative; the flow box determines all interactions with other elements 'in flow'. If you turn on position:absolute; or position:fixed; the flow box 'goes away' and elements ignore the flow box outright.

The 'render' box determines where the element is going to be drawn on the sceen. The render box can in fact be expanded outside the flow box, or even be in a completely different location.

For example if you had an element:

display:block;
position:relative;
left:150px;
width:100px;

the 'flow box' - used to determine how elements wrap around it, remains in it's original position, but the content is rendered 50px to the left of it. This effect can actually be used to create a simple drop shadow thus:
<style type="text/css"></style>

<div class="dropshadow"><div class="content">
	Some test content
</div></div>
Code (markup):
Very simple example of using that behavior to an advantage.

As I mentioned, margins effect the flow box but not the render box.

display:block;
margin-left:150px;
width:100px;

This makes the 'flow box' 150px wider than the render box, though you have to remember your margin collapsing behavior on that.

If we can make the flow box bigger, can we make it smaller? Most certainly:

display:block;
margin-right:-50px;
width:100px;

That gives us a flow box 50px wide, but a render box that 'hangs over' the flow by 50px.

Bottom line - Thinking of it as two separate entities on the page can really help understand all the different ways you can manipulate an elements size and positioning.

A word of warning on position:relative - ALWAYS remember that a position:relative will always depth-sort over non-positioned elements.

-- in regards to your last post:

I think where you are getting confused is on the definition of "relative to what".

position:relative means "move the rendering relative to it's normal position on the page while leaving the flow alone", NOT "relative to it's container". What you are looking for is position:absolute, which positions it relative to whatever parent container last had a non-static (aka default) positioning... defaulting to BODY if no other element has positioning. You just need to remember that yanks said element out of 'flow' so other items on the page will NOT wrap around it. If you are looking to auto-wrap content around an element you move using position:absolute, you are pretty much **** out of luck - HTML/CSS doesn't work that way.

In your current demo there you are positioning absolute left:200px and top:800px because it's working off #body. If you want it to work off #myContainer, you need to set some form of positioning on #myContainer apart from the default 'static' behavior. Easiest solution? add position:relative to #myContainer. This tells the browsers the element is positioned, so elements inside it should use #myContainer for calculating top, bottom, left and right instead of BODY. That's the little element you are missing - you have to set a positioning other than static on an element to have elements inside it calculate position:absolute or position:fixed in relation to it.

Here's a simple demo showing the difference between having the wrapper set to position:relative and not setting it.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
	xmlns="http://www.w3.org/1999/xhtml"
	lang="en"
	xml:lang="en"
><head>

<meta
	http-equiv="Content-Type"
	content="text/html; charset=iso-8859-1"
/>

<title>
	position:relative example
</title>

<style type="text/css"></style>

</head><body>

<div class="test1">
	.test1
	<div>.test1 is not relative, this is positioned off BODY</div>
</div>

<div class="test2">
	.test2
	<div>.test2 is set to position:relative, this is positioned off of it.</div>
</div>

<p>
	The only difference between the above two elements markup is that the second one has position:relative on it. 
</p>
			
</body></html>
Code (markup):
Side note - you may want to start getting in the habit of condensing your CSS properties, double checking you aren't defining the same values twice, and I don't know what layer-background-color is (isn't that some goofy netscape 4 only value?), but it's certainly NOT a valid CSS declaration.

deathshadow, Jan 11, 2009 IP

ycc likes this.

ycc Peon

Messages:: 99

Likes Received:: 0

Best Answers:: 0

Trophy Points:: 0

#11

Thanks. I read through your post, deathshadow. It will take a little time to digest (due to me being a beginner with CSS), but I think it spots my problems. I included one further example in http://web.telia.com/~u17103363/doc/pos_rel_ex.htm - example #4, adding position:relative to the #myContainer (and called it myContainer002) like you suggested. This seems to get much closer to what I want, thanks.

This was something I wouldn't have expected. I had thought that adding position:relative to the #myContainer002 would relate to how #myContainer002 is positioned and not to how its content (the yellow/blue tags) is positioned.

I am a little busy today, but will come back in this thread later when I have tried to read up a little.

Thanks a lot deathshadow, I appreciate it.

ycc, Jan 11, 2009 IP

deathshadow Acclaimed Member

Messages:: 9,732

Likes Received:: 1,998

Best Answers:: 253

Trophy Points:: 515

#12

ycc said: ↑

This was something I wouldn't have expected. I had thought that adding position:relative to the #myContainer002 would relate to how #myContainer002 is positioned and not to how its content (the yellow/blue tags) is positioned.
Click to expand...

Threw me off at first as well a few years ago - took me a while to come up with a way to 'think about' the box model in my head. It does both - which is why it's a bit confusing. The terminology is also confusing because 'relative' is a relative term - as I said, the question becomes 'relative to what exactly'?

Note, position:absolute and position:fixed ALSO change how elements inside them are positioned, making absolute on child elements relative to the positioned parent. Basically you get that behavior the moment your wrapper is no longer position:static. Position:relative is just used the most because it preserves flow.

The box model LOOKS simple on the outside, until you get things like positioning, negative margins and other oddities involved - compounding the problems are things like IE5/earlier (or modern IE in 'quirks mode') having a broken/different box model alltogether.

You get confused on this subject or find it counterintuitive don't feel bad - it drives even the professionals nutters from time to time with the inconsistant nonsenscial behaviors we end up having to 'work around'.

deathshadow, Jan 11, 2009 IP

Stomme poes Peon

Messages:: 3,195

Likes Received:: 136

Best Answers:: 0

Trophy Points:: 0

#13

ycc:

when I read you saying this:
#searchbar img {postition: absolute; left: 10px; ...
Code (markup):
that's where I think you missed me. Crusty has said it again but the point is

The container (searchbar in the earlier example) needs to become a "positioned ancestor" (a box with "position: something" on it) and then its children/descendents can have position: absolute and their positioning will look to searchbar's top left (or right) corner as their reference.

Also, that earlier demo you posted with different values for IE... was because your document started with <style> tags and no doctype.

Hmmm, you can take a look at any of Crusty's pages for a look at how a proper page with a doctype etc look, or the link I posted earlier to my page. First character, first line of every HTML page you build (if it's static and not scripted with PHP or some stuff) starts with a doctype declaration.

This should make IE act like modern browsers most of the time (the rest of the time it's usually bugs).

Stomme poes, Jan 13, 2009 IP

ycc Peon

Messages:: 99

Likes Received:: 0

Best Answers:: 0

Trophy Points:: 0

#14

Thanks for explaining, guys. I appreciate it. Sorry for me only being able to reply irregularly. (Due to remporary back-pain not being able to sit too long in front of a computer and also being on a trip.) However, I definitely read all replies carefully. (And try to understand them to the best of my ability )

I think I can understand the difference between "flow-box" and "render-box". I think I also have reasonable clear that the margin-property enlarges the flow-box.

I put the dropshadow as example five in the example: http://web.telia.com/~u17103363/doc/pos_rel_ex.htm Very useful.

Setting the margin-property NEGATIVE was really a good suggestion. I hadn't thought of that. Since I sometimes think the flow-box is ""unnecessary"" I can get rid of it with negative margins. I tried that in example 6.

So, thanks for explaining it. To get a position ""relative"" to the parent container I should use position: absolute for the elements INSIDE the container and having the CONTAINER as position : relative.

deathshadow said: ↑

... position:relative means "move the rendering relative to it's normal position on the page while leaving the flow alone", NOT "relative to it's container". What you are looking for is position:absolute, which positions it relative to whatever parent container last had a non-static (aka default) positioning...
Click to expand...

Your example is here, thanks.
http://web.telia.com/~u17103363/doc/pos_rel_ex_02.htm

So I will try to remember it:

deathshadow said: ↑

... Note, position:absolute and position:fixed ALSO change how elements inside them are positioned, making absolute on child elements relative to the positioned parent. Basically you get that behavior the moment your wrapper is no longer position:static. Position:relative is just used the most because it preserves flow. ...
Click to expand...

Yes Stomme poes, that's where I missed you, but it has been a valuable lesson to me. Thanks all of you. You speak about "Crusty". Sorry I am new here, I don't know who it is. I found a member called "crusty" but I don't know how to find the pages by Crusty you refer to.

The page you refer to starts with:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"  "http://www.w3.org/TR/html4/strict.dtd">
Code (markup):
I must learn more about this. I do not yet understand how this declaration affects the page. Neither do I know anyghing about code-validation.

Thanks for a lot of valuable help

EDIT: I removed a part about changing the width of the dropshadow-example, I had got it wrong

ycc, Jan 18, 2009 IP

Stomme poes Peon

Messages:: 3,195

Likes Received:: 136

Best Answers:: 0

Trophy Points:: 0

#15

Yes Stomme poes, that's where I missed you, but it has been a valuable lesson to me. Thanks all of you. You speak about "Crusty". Sorry I am new here, I don't know who it is. I found a member called "crusty" but I don't know how to find the pages by Crusty you refer to.
Click to expand...

"Crusty" in this case was referring to Deathshadow. It's short for "Crusty Old Guys Who Know Stuff And Rant" : ) There are also some other crusties floating around here.

the link I was talking about was this one: http://web.telia.com/~u17103363/doc/pos_rel_ex.htm which does not start out line 1 character 1 with a doctype. Doctype comes before everything else in the document. Everything.

Why does it matter? In Ye Olden Days, nobody used Doctypes. Browsers still don't use them for anything. A Doctype is a declaration telling a parsing validator (like the HTML validator we use at W3C such as this one) what rules you were following when writing your document. This allows it to tell you where you made typos : )

However as "web standards" slowly crawled into the subconsciousness of the average code monkey, the browser vendors, namely M$, realised that new pages written to the standards needed to be treated correctly while old pages, presumably written in garbage instead of HTML, needed the old rendering rules. So generally most browsers do this (not just IE):

If there's no doctype, the page must have been written back in the heyday of Geocities with animated gifs and Nirvana was a really popular band, touring and everything.

If there's a doctype, then it must be a new page, written at least since the US invaded Afghanistan or something. So, browsers guess they should treat doctypped pages as "modern" while not "breaking" the old sh*t pages.

Every browser has a Standards and a not-standards mode (and some have a sub-sub standards mode) but in IE the differences are huge. IE in Quirks Mode will act like IE5.5 and below. That's like, more than 10 years old, right? In "standards mode" you'll still get problems because that's just IE being IE with all it's bugs and Haslayout and other bullshit but at least it gets the box model right (follows the rules set on things like widths vs padding etc).

Things in IE in Quirks Mode are often off-set or not centered compared to modern browsers in standards mode. So, why doctypes are important.

Of course, using it to test your document in a parsing validator is another good reason to have one. If you did <span>stuff</psan> by accident it will catch it for you.

Stomme poes, Jan 30, 2009 IP

ycc Peon

Messages:: 99

Likes Received:: 0

Best Answers:: 0

Trophy Points:: 0

#16

Thanks Stomme poes.

Very good to learn what the doctype-tag was doing and what Quirks mode is, among other things. I should have known that earlier.

Having been introduced to the codevalidator, I have started trying it out. If necessary I will come back with more questions, thanks.

It is off topic, but another problem for me is the Javascript debugging. I think there are Firefox plugins? On top of this I am presently forced to use an Internet-cafe that, unfortunately, only allows MSIE. When I mess up the Javascript I often only get the non-informative message "object expected on line ..." by MSIE. Is there a way to get more informative error-messages?

ycc, Feb 8, 2009 IP

deathshadow Acclaimed Member

Messages:: 9,732

Likes Received:: 1,998

Best Answers:: 253

Trophy Points:: 515

#17

ycc said: ↑

It is off topic, but another problem for me is the Javascript debugging. I think there are Firefox plugins? On top of this I am presently forced to use an Internet-cafe that, unfortunately, only allows MSIE. When I mess up the Javascript I often only get the non-informative message "object expected on line ..." by MSIE. Is there a way to get more informative error-messages?
Click to expand...

MSIE is effectively useless for javascript debugging - your only real option for proper script testing is a better browser like firefox or opera. (as much as I prefer opera, FF has a better javascript errror window built in)

When working at a intenet cafe you may find that portable applications can fill the gap in things they won't let you install. There's a 'portable version' of Firefox that will let you run it off a USB flash disk. If they let you read and write files to a USB flash drive, you should be able to run the following version of FF off of it.
http://portableapps.com/apps/internet/firefox_portable

Likewise there's a portable version of Opera:
http://www.opera-usb.com/operausben.htm

One of the keys to successfully writing websites is the ability to test multiple browsers - being stuck testing in just IE - or WORSE developing for just IE is just asking to /FAIL/ miserably. This is actually true of ANY attempts to 'write to one browser, hack for others' approach.

Too often 'round the various web design forums you'll see people asking "Why doesn't my page work in ____" and you find out they've written the entire site without ever testing in anything but one browser (usually IE or FF)... Sad fact is NONE of the browsers are 100% correct to standards and all have quirks that you can code something in one of them, and not have it work anywhere else. This is why writing a whole page then layering hack upon hack upon hack to make it work in ____ browser is pretty much a recipe for fail.

It is why my design approach is write the entire HTML without any concern for how it is going to appear, my markup, classnames and ID's all saying what things ARE, NOT what they are going to look like. I then work one section at a time top-down in the CSS testing each section and change I make in at least one of each of the major browser engines in circulation... You use the CSS to bend the semantic markup to your will, avoiding changes to the HTML as much as possible. For testing, that means Trident 6 and 7 (IE 6 & 7 respectively), Gecko 1.8 and 1.9 (FF 2 & 3), Presto (Opera 9.63), and Webkit (Safari and Chrome - I leave safari using the apple font renderer so I can see what it would do on a quack).

Such widespread testing usually avoids 99% of the cross browser troubles that plague the endless rubbish code vomited up and propogated on the web.

deathshadow, Feb 9, 2009 IP

ycc Peon

Messages:: 99

Likes Received:: 0

Best Answers:: 0

Trophy Points:: 0

#18

Deathshadow, thanks for informing me about the portable FF and Opera. Exactly what I needed. I hadn't thought about it. Could be used instantly at the Internetcafe!! Has already saved me a lot of time.

However, I haven't found out how to get errormessages. Maybe the Javascript error window is not included in the portable Firefox? Or I don't understand how to open it?

It seems to me like a very good advice to separate html and css. Page content separated from page rendering. I will try to think about that.

Taking small steps, trying to see what happens at each level. (I come to think of a quote going something like "good programmers write simple programs", could it come from Kernighan or Ritchie?)

Thanks a lot for useful advice in this thread.

ycc, Feb 17, 2009 IP

deathshadow Acclaimed Member

Messages:: 9,732

Likes Received:: 1,998

Best Answers:: 253

Trophy Points:: 515

#19

tools > error console

It will also show you all of your CSS and HTML errors. You can filter out warnings or errors, and/or clear the list.

deathshadow, Feb 18, 2009 IP

ycc Peon

Messages:: 99

Likes Received:: 0

Best Answers:: 0

Trophy Points:: 0

#20

Thanks deathshadow, a great tool. In the internecafe I am often forced to use Wordpad and can't see the linenumbers. The error console provides links to where the error is located, really useful for me.

ycc, Mar 12, 2009 IP

Log in or Sign up

Advertising (learn more)

style="position:relative" leaves an unwanted hole in original location

ycc Peon

crath Well-Known Member

drhowarddrfine Peon

Jaguarjace Guest

ycc Peon

Stomme poes Peon

ycc Peon

drhowarddrfine Peon

ycc Peon

deathshadow Acclaimed Member

ycc Peon

deathshadow Acclaimed Member

Stomme poes Peon

ycc Peon

Stomme poes Peon

ycc Peon

deathshadow Acclaimed Member

ycc Peon

deathshadow Acclaimed Member

ycc Peon

Log in or Sign up

Advertising (learn more)

style="position:relative" leaves an unwanted hole in original location

ycc Peon

crath Well-Known Member

drhowarddrfine Peon

Jaguarjace Guest

ycc Peon

Stomme poes Peon

ycc Peon

drhowarddrfine Peon

ycc Peon

deathshadow Acclaimed Member

ycc Peon

deathshadow Acclaimed Member

Stomme poes Peon

ycc Peon

Stomme poes Peon

ycc Peon

deathshadow Acclaimed Member

ycc Peon

deathshadow Acclaimed Member

ycc Peon

Useful Searches