Re-learning HTML, CSS and so on, need some help

[Kaotik]

I started re-learning the stuff after years and years of nothing, and I now faced couple strange issues I can't seem to figure out.

(no need to comment on layout, colors etc, it's just for re-learning purposes, not design)

Files can be found here:
http://home.akku.tv/~akku38901/.temp/temp1/

Currently known issues:
- Text in Layer4 isn't showing up at all
- Custom scrollbars aren't working in IE8

the scrollbars themselves have been confirmed to work in IE8 too here: http://home.akku.tv/~akku38901/.temp/temp2/

 

[Rolf N]

Opera error console sez:

CSS - http://home.akku.tv/~akku38901/.temp/temp1/index1.html
DOM style property
Invalid value for property: width
Line 1:
  NaNpx
  -----^

So you dynamically generate CSS via JavaScript, huh?

 

[Kaotik]

JavaScript is used for the hide/show layer function which of course alters the CSS (changes the specific layers display:block; to display:none; or vice versa), but nothing else should be happening with it.
(excluding the flexcroll scrollbars but that shouldn't do anything to css)

Using Expression Web, so need to go and check if it has put something there that doesn't really belong there.

 

[Frank]

I got a bit (or rather a lot) fed up with html, css and the bad cross-browser compatibility, recently. So I started to do a site in only JavaScript. It only has a link to a sitemap in the body (for Google), and starts Onload and OnResize with: document.innerHtml = "";

The good: it actually works very well, and is truly cross-browser compatible, as long as you don't count the occasional, untraceable and unfixable IE 6 bug.

The bad: half the work is in getting Google to index it right and show the page as you want it shown.

In short: it's better than all the other ways I used in the past, but still sucks.


That's web in a nutshell, from a software developers POV.

 

[Dooby]

Just so you know, tables and divs don't play together that nicely. Remove the table and it will get a bit easier.

Another "hint" (though more like a "well duh!"): if you're using <br />'s that much, you're doing something wrong.

The other issues are just attributed to very wrong JS .


And Frank, OMG, so the very wrong way to do it ::dies::

 

[Kaotik]

Most of the <br />'s are there due copypastatext for the sake of making something appear on screen fast at this point
but thanks for the tip

 

[Frank]

And Frank, OMG, so the very wrong way to do it ::dies::

I know, that's what everyone says. People do it like they do because that's how it evolved and we all learned how to do it. With a reason. You need it all: php/ASP.NET, JavaScript, css AND html, to make it work as it should. And cross-browser testing is what we all do most of the time.

If it were easy, anyone could do it!

And if there was a simpler way, some huge company would have gotten it and made it vastly popular long before some unknown bloke would come up with it. Not that any major company has any vested interests in making things better, unless they can convince people to pay them lots of money for it.

That doesn't stop me from doing it the way I think works best anyway.

 

[Rolf N]

I got a bit (or rather a lot) fed up with html, css and the bad cross-browser compatibility, recently. So I started to do a site in only JavaScript. It only has a link to a sitemap in the body (for Google), and starts Onload and OnResize with: document.innerHtml = "";

The good: it actually works very well, and is truly cross-browser compatible, as long as you don't count the occasional, untraceable and unfixable IE 6 bug.

The bad: half the work is in getting Google to index it right and show the page as you want it shown.

In short: it's better than all the other ways I used in the past, but still sucks.


That's web in a nutshell, from a software developers POV.

That doesn't make a whole lot of sense to me. If you emit html code via Javascript document.write clauses, aren't you doing more work? You get HTML code out of it, but now you have to quote it, add JS concatenation for every line-break, and escape any contained quotes (and newlines, maybe). What benefit is there to offset this extra work?

Free (computed) pixel placement of elements? You can use the same JS logic on static HTML code by assigning to the element.style group of attributes. There's really no need to generate the whole document in JS if all you want to control are formatting attributes.

Methinks you gave up on CSS a little before the hump.

 

[Frank]

That doesn't make a whole lot of sense to me. If you emit html code via Javascript document.write clauses, aren't you doing more work? You get HTML code out of it, but now you have to quote it, add JS concatenation for every line-break, and escape any contained quotes (and newlines, maybe). What benefit is there to offset this extra work?

Free (computed) pixel placement of elements? You can use the same JS logic on static HTML code by assigning to the element.style group of attributes. There's really no need to generate the whole document in JS if all you want to control are formatting attributes.

Methinks you gave up on CSS a little before the hump.

No, I create objects and set their properties through code in the DOM. Just as you would in a Windows app.

And why would I use templates (html and CSS) if I can do the same by simply giving the properties the value I want?

If you want it dynamic, you either have to create a template for each and every possible combination of properties, or set them on demand. And the latter doesn't require tou to check and/or change another file whenever you want to do that.


The main problem with html and css is, that it looks different in every browser. If you only use "windows" (DIV's) and place them absolutely, it alwys looks the same. And you can animate them.

 

[Zaphod]

And why would I use templates (html and CSS)

Well, that's where you go wring in the first place. You shouldn't.

You should think of most XHTML tags as the semantic (object) structure of your document, their contents as your data, and CSS as the (visual) properties of said objects. In addition you have divs and spans to create block level and inline objects that have no semantic meaning. Then use the DOM to dynamically access and update the content, structure and properties of these objects.

 

[Frank]

Well, that's where you go wring in the first place. You shouldn't.

You should think of most XHTML tags as the semantic (object) structure of your document, their contents as your data, and CSS as the (visual) properties of said objects. In addition you have divs and spans to create block level and inline objects that have no semantic meaning. Then use the DOM to dynamically access and update the content, structure and properties of these objects.

If I do that last part, why would I bother with creating it in html and css up front in the first place?

Looking at W32 programs, everything is created dynamically by functions in the first place, and the same goes for the "html/css/script" interpreter in the browser that renders it.

I'm treating html and styles like a page description language you generate, like postscript.

 

[Zaphod]

I guess that depends on weather you're you're building a page or an application. I.e. if what you're delivering is information or a set experience. If it's the former you should care whether it degrades gracefully and at the basic level not make the message dependent on its presentation.

If it's more of a tool defined by its interactivity and designed to be working within a set of parameters (as defined by operating in any given browser) you might not care about such things as far as the front end goes since 'the page' then becomes all interface and no data.

Edit:

Spoiler

But then you should really move on to Ajax (or whatever), once more separating content from presentation.