6 posts tagged “css”

Actually its not fixed yet. What i mean to say is:

1. My entire system is a single page layout and hence the logical way of designing this is to layout my elements with position: fixed, i.e. fixed to the points on the screen and not the containing element (position: absolute).
2. Actually *hehe* I set them to be position: absolute at first, but thats only because positioning them relative to the containing element gives the same effect as positioning relative to the screen.
3. Alright, so turns out that IE7 behaves wierd when I use position: absolute (I can no longer remember why or how), so I changed them to position: fixed.
4. But hohoho IE6 doesnt support position: fixed. So I had to change them to position: absolute. This is where the fun begins: In setting position:absolute, you cant set all four top, left, right, and bottom corner offsets. Only a pair (e.g. top, left) is allowed and then you have to set height and width.
5. So now for IE6, I have to hack my way to make them display correctly with a combination of unmentionable paddings, margins, and my most poweful tool: position: relative (which can offset from top, left, right and bottom -- but its presence affects sibling elements unlike position: absolute  or position: fixed)

I think Im about 80% done. But I cant really say. Im not even sure if I can emulate the proper layout with such restrictions. Why cant everyone just ugrade their browsers. Its free you know?

Arrggh... Ive spent the past four hours fixing my standards-compliant layout to fit to IE6's needs. And from this ridiculous layout:

All I have now is just:

In other words, the top part is done. Im fixing the CSS by setting display: none to all major containers and then work my way down the DOM tree; slowly fixing each <div> one at a time.

Onwards!

So Im trying to make my system (that works perfectly in Firefox and is almost perfect in Safari) to work for Internet Explorer (7 first and then Im going to tackle version 6).

And im facing with this wierd shrinking problem. I have some divs that are positioned absolute and restricted only by a top, left, right, bottom and min-width CSS properties. The thing is, sometimes, e.g. when I change the display/visibility property of some other div, the other divs decide to shrink to min-width. Huh???

So Im preparing my arsenal of books to refer to. The internet hasnt been very helpful cuz I probably cant really pinpoint the exact problem. I tried isolating just an absolute div and another that I hide/show and the problem is not reproduced.

Alright, one from my arsenal of CSS resources should have the answer:

I hope.

1. Web Development: Best Practises
2. Internet & Web: Web Content
3. Dynamic HTML and XML: The XMLHttpRequest Object
4. Safari Developer FAQ
   
5. CSS Suport in Safari
6. Safari JavaScript Reference
7. Introduction to Web Kit DOM Programming Topics
   

Some other resources:

1. Using Web Standards in your web pages - MDC
2. W3C DOM
3. Eric-Meyer CSS Links

So while I was happy as a bird using my Firebug and Web Developer toolbar add-on for debugging my system (read: Javascript bugs and errors), working with IE has no such luxuries. The closest thing to Web Developer toolbar for IE is the IE Developer toolbar. But then again, I personally feel that its not as powerful as Web Developer toolbar. But this is just half the story. There is no Firebug equivalent for IE! Well, there is Firebug Lite that has to be integrated into the source in the server (or use UserScripts via IE7Pro). But its not as powerful as the real Firebug. e.g. when theres an error in a script, normally I will use Firebug to open up exactly where the error occured and then use the watch list to debug some states (variable values, etc). With Firebug Lite, however, it just tells me that the error occured on Line 158. So I have to basically go through every single javascript that i have, insert a blank line at the top and refresh my browser until the error line changes (which would indicate that the recently changed file is the one in mention). I may not know how to use Firebug Lite and may be there is a way around this. But I cant seem to figure out how. Anyway, its more convenient in Firebug even if there is actually a way. The default error message from IE is just as non-descriptive. It just tells me the line number where the error occured.

I visited an MSDN blog (i think) and there are several suggestions to debug JavaScript in IE. One is by using Microsoft Script Editor (unfortunately I dont have Microsoft Office XP so I don't have this utility). Another is Microsoft Script Debugger (which I read is not very powerful). The last is the overkill of using Microsoft Visual Studios to debug (in which its actually debugging iexplorer.exe and some javascript errors detected in IE are not handed over to Ms Visual Studios for some reason -- its as if only the critical errors are passed over?).

Anyway, so Im going to debug using Firebug Lite along with the help of MSDN JScript documentation until I can find a better one. At least it has a console that I hope to be able to use to watch variables (the hard way by typing javascript like commands instead of variable names like in Firebug).

Update: I ended up using Ms Visual Studios after all for the run-time errors. As for the normal errors, I had to do a cat *.js > everything.js so that I know which line the error originated from. IE is a pain.

Update 2: I am subscribed to Apple's web dev mailing list and I read this related post about tools for web-dev in FF, IE and Safari. So here's the list: (Note that this is an ongoing discussion in the list)

> FF
> JavaScript Debugger : Venkman (Awesome), Firebug (OK)
> CSS and HTML Inspector: Firebug (The best)
> HTTP Request Inspector: Live HTTP Headers(Great), Firebug(Great)
> Profiler: Firebug (The best) Venkman (Good)
> DOM Inspector: Yes (Awesome)
>
> IE
> JavaScript Debugger: Visual Studio (The best)
> CSS and HTML Inspector: IE Developer Toolbar (OK)
> HTTP Request Inspector: HTTP Watch (The best)
> Profiler: none;
> DOM Inspector: none;
>
> Safari
> JavaScript Debugger: Drosera (Under development)
> CSS and HTML Inspector: none;
> HTTP Request Inspector: none;
> Profiler: none;
> DOM Inspector: Yes (Awesome)

So Im back from my trip to the server-side and landed myself back to client-side problems. The problem with mockups is that things appear to run much faster than they really do once you hook up a proper backend. Things run especially slower for me since my system involves scraping of web pages.

One major slow-down in my system is in how I handled text overflow. There were many interesting solutions on the web but I came up with my own computationally intensive solution. Here is the rough algorithm:

1. Draw the text unwrapped and allowed to overflow by wrapping it in a left-floated div.
2. Compare the widths of the div with its container (the td in my case) and decide whether or not to apply a "..." style (achieved by using a "..." background image and right padding the text so that it ends before the "..." background starts.)
   

While this is an interesting solution, there are two problems:

1. Its computationaly intensive because of the overhead: it has to introduce an intermediary div tag to compare widths (this is the only way I could think of to decide if the text was overflowing).
2. When users resize the screen after the final render, the "..." doesn't update. Of course, we can make a call to the function on every screen resize, but thats just suicide.

Microsoft's implementation actually has a direct CSS solution for the above problem actually. The 'ellipsis' value for text-overflow. Mozilla on the other hand (and other browsers I think) have no such convenience.

I was satisfied with my solution at the time since I was only handling mock data. Now, its a different story. So I have come up with a CSS-based solution which hopefully works much better. I thought about this a few months ago but didnt really have time to implement it given the time frame for completing my thesis. Anyway, here's what I remember of the solution:

1. The problem is how to use CSS to automatically detect:
1. that there is overflow
2. that the layout has resized and the "..." needs to shift
2. For problem #1, we can try to push the "..." out of view whenever there is no overflow. Likewise, when there is overflow, the "..." is in view.
3. Problem #2 can be solved by the above if we have a continous solution rather than a boolean (overflow or otherwise) solution.
4. My solution involves using 3 levels of z-index:
1. Bottom layer (furthest from viewer) holds the text
2. Middle layer holds the "..." image
3. Top layer holds a curtain for the "...",  i.e. its a solid coloured div (same colour of background-color of text)
5. We float both the top and bottom layer to the left so that as the text gets longer, the top layer gets pushed further to the right. e.g. <div class="floatleft" id="text">text</div><div class="floatleft" id="curtain"></div>
   
6. We float the middle layer to the right.
7. When the text is not overflowing, the curtain div is occluding the "..." layer. But when the text overflows, the text div will push the curtain div past the position of the "..." div and hence it is no longer occluded. But on the other hand, the text is occluded since the "..." layer is on top of the text layer.
   
8. The margin of error for this solution is just the width of the "...", i.e. if the curtain is only pushed by so little that only half of the "..." is revealed. But this could be compensated by offsetting the curtain from the text by half the width of the "..." image.
   

Maybe Ill implement this soon and see if it works. Cheers.