If you could tell me how long it takes to load for you, and your connection speed, it would help alot.
Also, any errors that you may encounter, please report them here. Thanks._________________Principal Software Architect
Rambling Indie Games, LLC

Also, HTML 4 should die a quick, horrible death; the Intertubes have moved on since 1999; we have the easier to parse (for man or for machine!) XHTML 1.1 these days.

Also, on your services page? Why are you putting all of those links in individual unordered lists? You should either go without lists altogether, or merge all of those links into a single unordered list._________________"...LeoDraco is a pompus git..." -- Mandrake

Also, HTML 4 should die a quick, horrible death; the Intertubes have moved on since 1999; we have the easier to parse (for man or for machine!) XHTML 1.1 these days.

Also, on your services page? Why are you putting all of those links in individual unordered lists? You should either go without lists altogether, or merge all of those links into a single unordered list.

Thanks, I missed that..on several pages..damn. I'll fix them before I upload the next update.
As for the XHTML.....thats out of my league right now. I'm working towards it, but currently I cannot get any xhtml documents to display on my local testing/dev sever setup. :\ Perhaps at a later date I'll do yet another rewrite of the site....*shudders*

The links look better seperated, so I used an unordered list for each link...but now that I think of it, perhaps a single list with <br /> in each <li> pair would work the same? Any suggestions?_________________Principal Software Architect
Rambling Indie Games, LLC

Nothing wrong with using HTML 4. It's still the accepted HTML standard and is in FAR more use than xhtml.

DevX, using a header inside of a paragraph is bad form and will break compliance. Just remove the P tags around it and that part will comply to the standard._________________If you play a Microsoft CD backwards you can hear demonic voices. The scary part is that if you play it forwards it installs Windows. - wallace

The links look better seperated, so I used an unordered list for each link...but now that I think of it, perhaps a single list with <br> in each <li> pair would work the same? Any suggestions?

No, no they don't. But if you really want some separation between the links, use CSS to affect the layout; that's what it is there for, after all. For instance, you could set the margin-bottom property of all link items to something like 0.5 em.

Seriously: XHTML is not that difficult to write; in fact, it's mostly easier to write than older versions of HTML.

And nodtveidt: you're attitude towards HTML 4 is exactly why we still have the leper hanging around._________________"...LeoDraco is a pompus git..." -- Mandrake

Uh, yeah, so I've never posted on this board before, but as someone who's been coding websites since 1997, this thread sparked my interest.

I attempted to make my most recent project XHTML compliant, and the result was a horrible mess of code that was ultimately not able to achieve the effects that I wanted to achieve. The problem in my case being that you can not use XHTML to stretch a div to have a mininum height that is the user's screen height and be scalable. The workarounds I were finding via google searches were messy, and ultimately XHTML was more trouble than it was worth.

I was also incensed by some of the obnoxiously pointless rules that were included, such as changing noframes = 1, which makes perfect sense to me into noframes = "noframes". Or how about having to type <br /> instead of <br>. What?? Does this stuff actually make the page load faster? Even if I was on dialup, I'd don't think it'd matter much.

No, HTML4 and tabled layout is still the most efficient way to make a webpage. XHTML may be slightly faster, but HTML4 has the advantage of not being stupid. I think that's why it's still in popular use.

but HTML4 has the advantage of being stupid. I think that's why it's still in popular use.

Fixed that for you.

The point is not about making the page load faster; XHTML does, indeed, add a lot of boilerplate to the rendered page, which can, obviously, increase the amount of data which needs to be downloaded. What it does bring to the table, however, is the sense of a well-formed document: these are easier for the browser to render (the browser has to do less work to guess at what the web-page author intended), and are easier to author.

HTML 4 has no sense of what it means to be well-formed; as a result, it is entirely too easy to create shit pages.

Seriously, if we wanted to be stuck with web pages which were designed in the 90s, we might as well still use IE 4 or Netscape 4.

As a minor point: self-closing tags do no need a space before the slash; only stupid browsers still require that particular idiocy._________________"...LeoDraco is a pompus git..." -- Mandrake

Noticed a small bug with the site counter... It adds every page you visit... You can fix this with a simple PHP Session... Checking to see if the IP visiting the page is the same as the Session varible...

Peace---MU

BTW--- The site looks VERY NICE!!!_________________Most people would succeed in small things if they were not troubled with such great ambitions.

- When I'm programming a game, it's a necessary evil that I have to break up my program into hundreds of little pieces, and that sometimes I have to have 10 or 20 different code files open simultaneously, particulary when I'm debugging. Certain programs like TextPad and others alleviate this a bit, by putting them all into the same window, but it's still annoying. One of the things I like about a webpage is that most of the time, you can just focus on one window. The last thing I want to separate my page's formatting from its body. This either creates an abysmally long document (if I put everything at the top) or an abysmally messy document (if I modify every tag individually).

- a lot of the tag attributes that were removed from strict are much more easily accomplished with HTML4 and there's no good reason why HTML4 shouldn't be able to such things -- things like set the width and height of an element. Especially when, in the case of height, XHMTL is malformed and can't impliment that effect correct (I'm refering to my problem making a div fill 100% of the height of the window).

- the whole concepts of "strict" and "transitional" in and of themselves. I honestly don't know why anyone would choose transitional. At least, my approach towards life in general is that if a standard exists, you should follow it. For myself, I would feel no better having a "sort of" compliant XHTML website than "sort of" following the law and "sort of" not going on a killing spree (and, just for absolute clarity, those are things I would, of course, never do). The fact that w3 feels they need to offer a transitional option made me wonder in the first place, "well, what's wrong with strict?" If using strict makes you a perfectly compliant admin, why give the other option?

BTW, I hesitated to post, and almost deleted my post because when I discuss these sort of things I'm told I tend to come off as arrogant and single-minded. So yeah, if XHTML really is great, I'd really like to know why, because I'd certainly reconsider using it... if you can convince me not to hate it.

Noticed a small bug with the site counter... It adds every page you visit... You can fix this with a simple PHP Session... Checking to see if the IP visiting the page is the same as the Session varible...

Peace---MU

BTW--- The site looks VERY NICE!!!

Yeah, I've been wanting to fix that damned thing for some time, but never got around to it. Perhaps during the next update.

I'm currently in the middle of making a "simple" space shooter game with Allegro...so far its coming along without any trouble.
I have joystick support (bought a new USB gamepad today..so I wanted to add support for it to my game...and I did!) and right now I'm going over the code again to make it more reusable, and encapsulating alot of things into classes.

- When I'm programming a game, it's a necessary evil that I have to break up my program into hundreds of little pieces,

I would not call that a "necessary evil"; modularity is a wonderful thing in programming languages. Code is broken up to facilitate, amongst other ideals, the writability of the code: dumping code in the middle of a few thousand line file, and having to refer to other bits of code within that same file is a maintenance nightmare.

Code modularity allows for opportunities to reuse common code and to abstract boilerplate. Whether these opportunities are realized is not really important here: the point is, by introducing separation of concerns, you can be reasonably sure that dependencies within your code work properly. This should result in less time spent debugging.

Quote:

and that sometimes I have to have 10 or 20 different code files open simultaneously, particulary when I'm debugging.

As you say (in the next quote), various text editors help facilitate this type of thing. While I have yet to use it, TextMate seems to strike a good balance for managing multiple open files at once. That said, the necessity of keeping 20 different code files open at once seems mildly suspicious to me; not to denigrate your abilities, but such a situation may very well be indicative of a need to refactor your code.

Quote:

Certain programs like TextPad and others alleviate this a bit, by putting them all into the same window, but it's still annoying.

I'm honestly not sure I could program efficiently in any editor that did not have a multi-document interface of some sort; I personally like tabbed interfaces, and the editors I typically use support it. Granted, the two principle editors I use (gedit in Linux, and VS in Windows) have shitty tab-switching keyboard shortcuts, but that really says nothing about the concept. Many editors also support multiple views of the same document; this could help with, for example, having to edit a particular method while looking at some other method a few hundred lines away.

Quote:

One of the things I like about a webpage is that most of the time, you can just focus on one window.

I have written sites before where something like that was done; the result was not pretty. Even granting that the sites were written in a WTF language, and that my approach was really stupid, the result was an entire webpage in a single file which was entirely too difficult to navigate to find whatever information I needed. Modularity of the site design would have sped development up, significantly.

Quote:

The last thing I want to separate my page's formatting from its body.

That's actually probably the first thing you want to do; while I cannot speak for all web languages, I know of at least four or five that support some sort of MVC abstraction. The best I have found is Rails.

As for the actual formatting of the HTML document, it is also a good idea to separate the layout of the document from its formatting; this usually allows the formatting information to be reused for other pages on a given site, or for multiple formats to be usable for the same layout. Properly written stylesheets should also reduce document size (in the sense that HTML style elements and inline style information need not be replicated all over the place; obviously, the browser still needs to download the stylesheet), rather than increase it.

Quote:

This either creates an abysmally long document (if I put everything at the top) or an abysmally messy document (if I modify every tag individually).

As mentioned at the end of the last comment, this is what separate stylesheets are for: you dump all of the style declarations into a separate .css file, which you can then include in a single line. If you use javascript, the same thing applies: you could dump the entire script at the top of the document, dump it where it is used, or do the sensible thing and dump it in a separate file. (This latter is only really necessary if you like to keep clean markup, or you include the linked files in multiple separate documents.)

Quote:

- a lot of the tag attributes that were removed from strict are much more easily accomplished with HTML4 and there's no good reason why HTML4 shouldn't be able to such things -- things like set the width and height of an element. Especially when, in the case of height, XHMTL is malformed and can't impliment that effect correct (I'm refering to my problem making a div fill 100% of the height of the window).

As mentioned above, most of that should be set by stylesheets; layout should be separate from formatting.

Quote:

- the whole concepts of "strict" and "transitional" in and of themselves. I honestly don't know why anyone would choose transitional. At least, my approach towards life in general is that if a standard exists, you should follow it. For myself, I would feel no better having a "sort of" compliant XHTML website than "sort of" following the law and "sort of" not going on a killing spree (and, just for absolute clarity, those are things I would, of course, never do). The fact that w3 feels they need to offer a transitional option made me wonder in the first place, "well, what's wrong with strict?" If using strict makes you a perfectly compliant admin, why give the other option?

Sure, it does not make much sense for small projects that are started from scratch; however, for larger projects that need to be slowly moved from older versions of HTML to whatever is latest, some allowance for deprecated structures has to be allowed. Usually, if something is deprecated, it is not removed immediately: doing so can cause a lot of difficulties. Deprecation usually has a period during which deprecated features can be culled out.

Also, you may want to take a closer look at the HTML 4.01 spec: it has the same three separations that the XHTML 1.0 spec does. What does that say about the HTML 4.01 Strict?

Quote:

BTW, I hesitated to post, and almost deleted my post because when I discuss these sort of things I'm told I tend to come off as arrogant and single-minded. So yeah, if XHTML really is great, I'd really like to know why, because I'd certainly reconsider using it... if you can convince me not to hate it.

Somewhat contrary to the posts I have made above: everyone is entitled to their opinions; according to the Wikipedia article on XHTML, some people besides yourself do not care for it. I personally find that it makes more sense to me: I think it is more consistent than the HTML 4 specification. In any case, unless something crazy happens at the W3C, I doubt there will be future versions of non-XML HTML; W3C seems happy with the XHTML language._________________"...LeoDraco is a pompus git..." -- Mandrake

I attempted to make my most recent project XHTML compliant, and the result was a horrible mess of code

To be fair, XHTML really is one of those things which is much easier to comply to from the ground-up, rather than converting existing HTML. But as you've run into, the real world isn't perfect like that.

Iki wrote:

he problem in my case being that you can not use XHTML to stretch a div to have a mininum height that is the user's screen height and be scalable.

What's a screen? If I'm printing stuff out, do I go with the paper height, the document height, or the document height rounded up to the nearest page? I'll come back to this "height" thing a bit later.

Iki wrote:

I was also incensed by some of the obnoxiously pointless rules that were included, such as changing noframes = 1, which makes perfect sense to me into noframes = "noframes". Or how about having to type <br> instead of <br>.

No, HTML4 and tabled layout is still the most efficient way to make a webpage.

I've been making pages almost as long as you have (mind you, not in a professional context, but as a hobbyist), but I find that since I've left tables behind for layout, my underlying code has been easier to read and modify. Maybe you enjoy the whole <table><thead><tr><td></td><td></td></tr></thead><tbody><tr>... thing, but it's not for me. I can't indent that without it traveling across the screen, or putting it on the one line, which is just as bad.

Iki wrote:

(anti-modularity stuff)

I dunno. I tried the monolithic model for a university project once. It was so hueg that I had to completely rebuild it modularly to be able to even handle growing development. I learned my lesson. You'll learn it too in time.

But for small stuff, a single module is fine, because the overhead of managing multiple modules doesn't pay off at those sizes.

Iki wrote:

a lot of the tag attributes that were removed from strict are much more easily accomplished with HTML4 and there's no good reason why HTML4 shouldn't be able to such things

Can you come up with an example or two? Again, I'll get to the height thing in a moment, but CSS has managed everything I've thrown at it so far, and even done many things which plain HTML can't, such as repositioning elements and :hover styles for increased useability.

Iki wrote:

the whole concepts of "strict" and "transitional" in and of themselves.

Again, legacy. I agree, this nonsense wouldn't exist, were it not for the fact that HTML existed beforehand.

Iki wrote:

(I'm refering to my problem making a div fill 100% of the height of the window).

And now for the height thing. I used to think that way as well. But then I realised something: if you want to force a design into a page, it's no longer a document. You're looking at web design from a DTP perspective, and if you're going to do that, why not work with something like Flash instead? A lot of websites go this route because they understand that may not be suitable for their ends, given their target audience (which would mostly have some form of Flash installed.)

There's a reason why height is only allowed to be absolute: in some contexts, the concept of "height" doesn't make sense, or is ambiguous. When you make a web page, you are building a document, something which is designed to convey information. Precise control is for desktop publishing and PDFs.

You don't come off as arrogant so much as resigning to F.U.D. HTML is like an old friend. It has its quirks, but it gets the job done. Suddenly, you're waylaid by XHTML, the younger sibling which has done nothing but make your job harder. From that, it's easy to understand why you don't like XHTML.

One of XHTML's design goals is to simplify document structure. Writing an effective HTML renderer is hard. Accommodating for the quirks is beyond the ability of most mobile/embedded devices. IE's Trident engine is barely able to scrape by, and is a design mess. The devs on that couldn't make it standards compliant if they wanted to, and they genuinely do want to. And most of us were around in the days of the IE vs. Netscape rendering inconsistencies.

By going with XHTML, we can finally put those days behind us. Document formats are for building documents, which can be viewed on multiple viewing devices.

Improving XHTML is going to be difficult when people try it, don't like it, and sign it off as "teh evil".

With HTML, I always had the niggling feeling that I didn't know quite what effect what I was typing would have. I'd have to keep a version of my page in a browser, make the change, refresh, and hope it came out alright. With XHTML, I don't get that feeling anymore.