RGB Classic Games Forum

It's definately leaner, but it still has a lot of non-semantic and nonsensical markup... and it's still an accessibility train wreck with the fixed metric fonts.

Headings for example: H2, H3 and possibly H4 respectively... each indicating the start of a subsection. That's heading tag's job -- EVEN if you were doing bold on those you aren't emphasizing them, so even <b> would be more appropriate than strong.

You also appear to be using paragraphs in the typographical/HTML 3.2 style, instead of the HTML 4/newer style. Pretty much every P inside the updates box is wrong/pointless/shouldn't be there. "There are no paragraphs there!"

I'd HIGHLY suggest getting in the habit of using <p> with </p> -- it's not just the XHTML style, it's the preferred method for making it clear you are dealing with a BLOCK LEVEL container. <p> are block level containers meant to wrap... paragraphs -- and while the HTML spec lets you sleazy by omitting the closing tag, it's NOT good practice.

But then, I'm a pascal guy -- I like to see where something is closed.

I'm still seeing some absolutely disastrously bad code on that menu... Those are NOT fieldsets since they aren't in a form nor do they contain INPUT, SELECT, LABEL, BUTTON or TEXTAREA, and those most certainly are not LEGENDS describing the purpose of the inputs inside a form. No FORM? No FIELDSET! Likewise those are LISTS of choices, so they should ALL be lists... Semantic markup, say what things are; a flat run of anchors (inline-level container) means that "Interviews Tutorials Webshrines Licenses" is treated as a single coherent thought like a sentence -- they are separate links going to different places. "Submit a game Make a donation Store" doesn't make much sense as a sentence, does it?

You've also STILL got stuff that has no business in the markup in the markup... Pretty much EVERY style="" attribute in the markup is stuff that has no business... in the markup... ESPECIALLY if said element has a perfectly good ID on it.

Like this: Interesting use of BIG, but a number by itself isn't sufficient to recieve that type of emphasis, I'd probably use a span for that... the style attrribute on the img should be done in the external CSS via "#logo img", as should the background-image.... and I'm not sure I would be treating those as DIV since that's a heading on the page, and as such just might be the h1... in which case it doesn't even need an ID... or the image inlined in the markup.

Again: Makes more sense with the images added via CSS. the dual nested span is done so that you can put an extra copy of the background in for graceful degradation when images are disabled without killing the animation.

Though given the size, I'd seriously look at killing the animation -- it's cute, but frankly it gets in the way of doing better markup. (and that menu method you're using HATES it!)

But I will say, at least when I have to dive for the zoom from the absurdly undersized/useless fonts, the layout doesn't seem to break anymore when I hit the legible 150%.

deathshadow wrote:You've also STILL got stuff that has no business in the markup in the markup... Pretty much EVERY style="" attribute in the markup is stuff that has no business... in the markup... ESPECIALLY if said element has a perfectly good ID on it.

Like this:

Code: Select all

<A href="index.html"><IMG src="title.png" style="margin-top: 23px;" alt="RGB Classic Games"></A>

I missed that one, thank you.

Okay, I've converted the site to ems. This has been a very entertaining day.

I already knew the following:

Pixels are an absolute measurement, short for "picture elements", which are the smallest addressable components of any image, and define the resolution of any display.

PTs are a measurement system used to define the size of fonts in every word processor and operating system since the invention of computer fonts.

EMs are a unit of measure relative to the width of the letter m, and ENs are relative to the width of the letter n (used for such things as the width of an n-dash or m-dash). Since EMs are a relative measurement, the width of the m needs to be defined by some absolute measurement in order for them to have any meaning.

Here's what I've learned from reading the link that you gave me:

Internet Explorer does not scale fonts that are defined in PX or PT when a user changes the text size options, even though there is absolutely no reason why a font defined in pixels or points couldn't be scaled by x%. Because Microsoft was too stupid or too lazy to do this, everyone in the world is now forced to use EMs for font sizes to ensure accessibility.

It gets worse.

Since EMs are a relative measurement system, the "absolute" that we define EMs against is %. % of what? What is 100% in this system? 100% of the size of a mouse's ear? 100% the size of Bill Gates' dick?

Apparently 100% is defined arbitrarily by the creators of each browser. Are you fucking kidding me? So instead of doing something logical like defining fonts using a standardized, absolute measurement, we have to use a relative measurement system that is defined by an "absolute" that is not absolute, leaving the text size of our web pages to the whim of each browser's creators.

It gets worse.

Not only is 100% defined differently from browser to browser, but every % is different from browser to browser. This is mathematically impossible. By definition, something that is 50% should be half as large as 100%, but apparently (as demonstrated by side-by-side comparison screenshots) a 1.0em font defined against a base of 50%, 75%, 90%, 100%, etc., will appear in very different sizes across the browser spectrum. So, instead of defining the base font as something logical like 100%, it turns out that the closest overlap between rendering sizes across browsers is 76%, so we all have to play it safe by defining the base font as 76% and then make our fonts relative to that in terms of EMs.

Instead of putting up with this bullshit, why doesn't Microsoft just fix their fucking browser and let the world use PT for font sizes, like we do in Word and EVERY OTHER APPLICATION THAT LETS YOU CHOOSE YOUR FONT???

DOSGuy wrote:Not only is 100% defined differently from browser to browser, but every % is different from browser to browser. This is mathematically impossible. By definition, something that is 50% should be half as large as 100%, but apparently (as demonstrated by side-by-side comparison screenshots) a 1.0em font defined against a base of 50%, 75%, 90%, 100%, etc., will appear in very different sizes across the browser spectrum. So, instead of defining the base font as something logical like 100%, it turns out that the closest overlap between rendering sizes across browsers is 76%, so we all have to play it safe by defining the base font as 76% and then make our fonts relative to that in terms of EMs.

Well, that certainly makes each and every browsing experience unique

DOSGuy wrote:It gets worse.

What you are calling worse accessibility folks call BETTER... but I think you're missing the point.

DOSGuy wrote:Not only is 100% defined differently from browser to browser, but every % is different from browser to browser.

EXACTLY, that's the POINT of HTML, to present content in a device neutral way so the user agent (aka browser) can customize the content to the needs of the user... be it a 800x480 netbook through to a 2560x1440 17" macbook, from a teletype to 80 column text mode lynx.

DOSGuy wrote:This is mathematically impossible. By definition, something that is 50% should be half as large as 100%, but apparently (as demonstrated by side-by-side comparison screenshots) a 1.0em font defined against a base of 50%, 75%, 90%, 100%, etc., will appear in very different sizes across the browser spectrum.

I think you missed how it works... it's multiplicative - if you put 85% inside 90% inside 120%, you're going to get 91.8% as the output; that's the POINT of CSS inheritance and the "cascading" part of "cascading style sheets"

DOSGuy wrote:Instead of putting up with this bullshit, why doesn't Microsoft just fix their fucking browser and let the world use PT for font sizes, like we do in Word and EVERY OTHER APPLICATION THAT LETS YOU CHOOSE YOUR FONT???

I think you're blaming Microsoft for doing it PROPERLY. (It is in fact Nyetscape/gecko legacy that screw it up)... px shouldn't be resized unless you're going to resize ALL px based elements on a page -- that's the POINT of declaring px. PT obeys the system metric, but it too should NOT be resized unless the system metric changes (this is why most people say PT should be reserved for PRINT). %/EM based off the page default is the only one that should resized by all factors... That's what it's FOR.

I think you're really misunderstanding it. The ENTIRE point of using %/EM is to give the user what they want WITHOUT diving for the zoom BECAUSE it automatically adjusts or can be set to the user preference across the ENTIRE OS. -- it's BECAUSE PX doesn't rescale that you shouldn't use it. That it auto resizes is the POINT... and in fact IE is the only browser to handle it PROPERLY in those screenshots. Gecko and Webkit both by default ignore the OS system metric on %/EM, which is wrong... and Webkit even ignores it on PT. (as does opera 11 now apparently).

Question: Have you ever switched Windows to large fonts/120dpi? (Or as they call it in Win7, medium fonts since large is now 144dpi and XL is 172). 99.9% of applications obey it, the ones that don't usually falling into the category of "cross platform floss" like Chrome/FF, java crapplets written using "swing" (which is part of why I don't like Java crapplets), or reliance on poorly written toolkits (like VST).

I've been running that setting in Windows since it was called 8514 on windows 3.0; always running one resolution higher than everybody else... now with LCD's coming through at absurd resolutions for their size, it's a great choice to not have to sit there with my head plastered 6" from the display... when it works. Thankfully, most REAL websites support it properly... Google, Amazon, Ebay, etc...

It's really not that hard to figure out... I like to set 85% on body and leave that unmodified for the majority of my content... I then set big headings to 140% (which ends up 140% of 85%), medium headings to 120%... (of that original 85%)... See how they inherit? That's also the point -- it's relative to what it's wrapped in, so it's easier to work with. You don't have to remember "my normal text is 10pt and I want this at 14pt" you can go "I want this 40% larger than the default"... without having to think an exact number.

I've put a lot of work into implementing your advice, and I'd just like to know how I'm doing.

You keep bringing up the menus, so I want to address that. To be clear, I have never liked the appearance of the site. I'm perfectly willing to change it, but right now I'm just trying to learn to be a better web developer, so I'm focusing on improving the code that makes the site look and behave the way that it does now. I can get to improving the appearance of the site when I have a clear plan for how I'd like to change things, but that just isn't my focus right now.

So, things that I've done:

I've removed almost all of the inline CSS code and put it in a very clean external stylesheet. The file sizes of the HTML pages, the PHP script pages and the external stylesheet have all decreased significantly. The site loads faster as a result. I have also implemented your request for EM-based font sizing, and converted the menu system to lists for the sake of accessibility and semantic markup. I added submit buttons next to the search boxes for the sake of people who don't have an Enter button. (I am intentionally abusing the fieldset tag because I like the look of the result, and I feel that there ought to be some flexibility to use tags in ways other than they were designed to be used in the name of innovation and thinking outside of the box, but let's not have that debate again right now.)

What I'd like to focus on for now is whether or not I have correctly understood and implemented the changes you requested, and what remains to be done.

You've made a lot of progress, but there are still a lot of niggling little issued plaguing the codebase.

I'm trying to figure out where/what/why you'd go with 76% as the font size... the default on 96dpi systems is 16px, so 75% would give you an even 12px on the majority of systems, and the resize would be the same cross-system too for the most part... so not sure where you got that extra 1% from... Also, 12px 96dpi and 15px 120dpi is a wee bit on the small size for most users; honestly, I didn't even think you'd made the conversion to %/em because everything is still so bloody small! I would HIGHLY suggest 85% which gives you 14px on the majority of systems, 10px for 75dpi and 17px for large font/120dpi users...

It's generally accepted that 12px is bare minimum font size and the ideal is 14px for 96dpi users... and that's 15/17 for large font/120dpi users.

Your CSS has a number of issues that I feel need covering.

font: 76% Arial, Helvetica;

Without at least one of default weight or style, some browsers will ignore that entire font declaration. You CANNOT trust the default line-height cross-browser so if you change font-size you should ALWAYS re-declare your line-height, and you forgot to include a generic fallback family, meaning some users (*nix typically) are going to get a SERIF font since that's usually the default. Combine this with what I said above about the default size, and the ideal declaration there should be:

font:normal 85%/140% arial,helvetica,sans-serif;

Then you have:

background-image: url("images/background.png");

IF you are using a background-image I suggest setting a background color that is close to the image, that way images off users still get an attractive layout. It actually ends up less code since you can then use the condensed "background" property. I'd also point out that in CSS you do NOT have to put quotes around url values unless there are spaces in there.

So...

background:#DEF url(images/bodyBackground.png);

Notice I would also give it a more verbose name. Background is a bit vague since there are multiple backgrounds on the page -- using a more verbose name may involve a whopping four extra characters, but it makes it clear as day what's going on to the next poor shlub to maintain the codebase. (or even yourself a year from now)

You also set the margin - I HIGHLY suggest adding a reset to the CSS. The one I advocate goes thus:
Browsers do not set margins, paddings or borders in a consistent manner because the HTML specification doesn't actually say what the default appearance SHOULD be. The spec sucks in that regard since there's lots of "may", "would", "could"... and very little "should" or god forbid "must"... and when the specification is vague, it seems every browser maker goes out of their way to do things different.

The above reset is just under a quarter k, making it larger than some, smaller than most... the uber small "universal reset" of "* { padding:0; margin:0; }" is problematic since it pretty well shtups form elements -- on the other side of the coin you have fat bloated train wrecks like "reset reloaded"; or as I like to call it "you give resets a bad name". That's not a reset, that's a framework. The point of a reset is to make all browsers start out with the same values on stuff -- not to do half your layout.

Ok, moving on...
If you say A, you don't need to restate the psuedostates. By default psuedostates inherit from their parent. I also highly advise AGAINST setting :visited to the same as :link unless it's inside a menu -- that's turning off an accessibility aid! The same goes for the underlines. Not everyone can see color and turning off underlines on links isn't just bad practice, it's rotten accessibility unless you're styling them otherwise like on a menu.
I'm not sure why you are giving just gecko/presto/webkit keyboard users a different style from hover... or why you omitted IE users (:focus)... Really those states should be taking the SAME values.
If you use the reset, that's done for you.

So that section I'd have like this:
Next up we have something bizarre -- not even sure what you're trying to accomplish other than pushing the menu down 9px from the top in Opera (since O doesn't allow fonts to go below 9px by default), 1px down from the top in most browsers, and clear off the screen in older IE flavors.
I'm assuming you are trying to hide them -- setting 0pt does not work for hiding an element, that's what display:none or visibility:hidden is for... If you are worried about screen readers not seeing it, that's when position:absolute; left:-999em; is a better answer.

I usually use display:none for screen, display:block in my handheld.css since for many screen reader users those links are more hindrance than help.
Those are not headings, why are you using heading tags? Also, as mentioned set the line-height again... it's why they don't line up cross-browser at all.
Not inside a form, no inputs, selects or textarea's (aka fields) inside them -- why are you using fieldsets? If you are choosing a tag based on it's default appearance, you're choosing the wrong tags.
Explains the strangely shape-shifting layout and float drop... Just set the width -- your content area is float dropping here at some widths, so the float technique you are trying to build #sidebar and #content with are broken.
Presentational CSS -- defeats one of the reasons to even use CSS in the first place! Aka, getting presentation out of the markup. Say in the markup WHY they are receiving that color, not what color they are receiving.

In the markup, you've got a ridiculously overstuffed keywords meta with little relevance to the page content. Pretty much guaranteed google will ignore it, and I'm willing to bet most

You read up on the keywords meta on sites like WSO, and you'll learn they should be relevant to the content on the page, you should only have eight or nine of them, and it's best to keep the entire thing under 128 bytes. You have NONE of that. You've got at least twice as many characters as the "ignore" cutoff, most of those words are not on the page, and you've got 31 of them -- basically three and a half times as many as should be in there.

Again, you're still using paragraphs HTML 3.2 style -- while that's VALID, it also means you are not using them properly according to HTML 4. They are a block level container, and as such should be wrapping their content... they are NOT supposed to be used as standalone tags anymore.

... and across the page you still are using P, BR and STRONG -- especially STRONG -- to do numbered heading tags job. They are headings, mark them up as headings. You also strong an entire paragraph which from a SEO standpoint is likely to get that para slapped down and ignored -- strong just the key phrases, not three sentences in a row!

These too:
<H2><A href="companylist.html">By Company</A></H2>
<H2><A href="search.html#legal">By Legal Status</A></H2>
<H2><A href="search.html#video">By Video Mode</A></H2>
<H2><A href="search.html#year">By Year Released</A></H2>
<H2><A href="misc/source.html">Games with source code</A></H2>
<H2><A href="misc/cheats.html">Games with cheat codes</A></H2>

raise some questions -- headings that aren't followed by a lower order heading and/or content aren't headings.

<H2>By Game Title</H2>
<INPUT type="text" name="Title" size="12"><INPUT type="submit" value="Search">

That shouldn't be a heading, that's a label... likewise none of those anchors are fields, so using:
<LEGEND>Game Search</LEGEND>

May not be appropriate either.

It wasn't just the menu I was referring to on the legends, fieldsets and headings... Though yes, it's the greatest offender.

Though if you're not happy with the appearance as you mentioned, it may indeed be time for a retread. You've got great content -- now it's just a matter of presenting it in an accessible manner... preferably not as HTML 3.2 in HTML 4's clothing.

deathshadow wrote:I would HIGHLY suggest 85% which gives you 14px on the majority of systems, 10px for 75dpi and 17px for large font/120dpi users...

85% just looked ridiculously large on my monitors. 80% seems reasonable (and larger than many sites I visit).

deathshadow wrote:You also set the margin - I HIGHLY suggest adding a reset to the CSS. The one I advocate goes thus:

Code: Select all

/* null margins and padding to give good cross-browser baseline */
html,body,address,blockquote,div,
form,fieldset,caption,
h1,h2,h3,h4,h5,h6,
hr,ul,li,ol,ul,
table,tr,td,th,p,img {
	margin:0;
	padding:0;
}

img,fieldset {
	border:none;
}

Why do you have to do it for every single element type? Shouldn't they inherit the margin from html and/or body?

deathshadow wrote:The same goes for the underlines. Not everyone can see color and turning off underlines on links isn't just bad practice, it's rotten accessibility unless you're styling them otherwise like on a menu.

Almost every major website I go to has stopped underlining links, instead using blue text that adds an underline upon hover. Off the top of my head, this is how Wikipedia and CBC do it. CNN uses a variation where the text simply turns red during hover (no underline under any circumstances). I certainly understand the argument that underlines are an accessibility feature for the visually impaired, so why have the world's largest websites stopped using them?

deathshadow wrote:I'm not sure why you are giving just gecko/presto/webkit keyboard users a different style from hover... or why you omitted IE users (:focus)... Really those states should be taking the SAME values.

Looks the same in IE 6-9 as it does in other browsers. I've never heard of the :focus attribute, but I haven't found a browser that seems to need it.

deathshadow wrote:Next up we have something bizarre -- not even sure what you're trying to accomplish other than pushing the menu down 9px from the top in Opera (since O doesn't allow fonts to go below 9px by default), 1px down from the top in most browsers, and clear off the screen in older IE flavors.

Code: Select all

#navskip
{
 color: #E6EFFF;
 font-size: 0pt;
}

I'm assuming you are trying to hide them -- setting 0pt does not work for hiding an element, that's what display:none or visibility:hidden is for... If you are worried about screen readers not seeing it, that's when position:absolute; left:-999em; is a better answer.

I usually use display:none for screen, display:block in my handheld.css since for many screen reader users those links are more hindrance than help.

That's the link to skip directly to the content, so that the visually impaired don't have to hear the menu on every page, as suggested by the W3C. I didn't realize that it wasn't hidden in Opera. I can't stand that browser; I try each new version for about 5 minutes before uninstalling it and hoping that there won't be a next version.

deathshadow wrote:

Code: Select all

#menu h1
{
 font-size: 1.2em;
 margin: 0;
}

#menu h2 { font-size: 1.2em; }

Those are not headings, why are you using heading tags?

The menu has a hierarchy. All menus on Government of Canada intranet sites use headings to allow screen readers to determine their hierarchy. That's how we do it at work!

deathshadow wrote:

Code: Select all

#menu fieldset { float: left; padding: 0; margin: 4px; }

Not inside a form, no inputs, selects or textarea's (aka fields) inside them -- why are you using fieldsets? If you are choosing a tag based on it's default appearance, you're choosing the wrong tags.

It seems like it would be about 10 times as much work to achieve the same effect with the right tags, so screw using the right tags.

deathshadow wrote:

Code: Select all

#sidebar
{
 max-width: 220px;
 float: left;
 margin: 32px 20px 0 10px;
}

Explains the strangely shape-shifting layout and float drop... Just set the width -- your content area is float dropping here at some widths, so the float technique you are trying to build #sidebar and #content with are broken.

That was because the Spanish and French menus are wider than the English menu. I didn't want the English menu taking up more space than it needed to, so max-width seemed like the solution.

deathshadow wrote:

Code: Select all

.ACE78C { background: #c8ffc8 url('images/ACE78C.gif'); }
.B0D8FF { background: #e6efff url('images/B0D8FF.gif'); }
.FFA0A0 { background: #ffc0c0 url('images/FFA0A0.png'); }
.FFFF78 { background: #ffff90 url('images/FFFF78.gif'); }

Presentational CSS -- defeats one of the reasons to even use CSS in the first place! Aka, getting presentation out of the markup. Say in the markup WHY they are receiving that color, not what color they are receiving.

That's never going to change. I use those codes in the database to determine the legal status of games. Changing them now would require changing every instance of them in the database, then rewriting half of the functions in the site's PHP source code to use the new names. I'm not going to rewrite a dozen functions in order to change some class names -- which don't impact the appearance or behavior of the site in any way -- in order to comply with a philosophical concept of how classes should be named.

DOSGuy wrote:85% just looked ridiculously large on my monitors. 80% seems reasonable (and larger than many sites I visit).

Odd indeed, since that's typically the norm for many websites.... though there does seem to be a lot of love for what I find (and the WCAG calls) uselessly small fonts lately. I mean, if you find 14px large on a normal display... you must still be running 640x350 or something... But then I pity anyone who tries to view a website with 12px fonts on a 1920x1080 21.5" iMac... Zoomland here we come; too bad safari sucks donkey at zooming.

DOSGuy wrote:Why do you have to do it for every single element type? Shouldn't they inherit the margin from html and/or body?

No, because they aren't set to :inherit by the spec, in fact the default values for all tags are NOT inherited or even defined by the specification... and that's not for every tag, that is for the tags that do not start out the same, and omits tags that don't recieve styling the same way cross browser (like say INPUT, which you can completely shtup just by setting padding on)

Take UL and OL, which receives left padding in IE, left margin in FF, left padding on the LI in webkit... Which means if you try to manually change that indent for the bullets, none of them will take that formatting the same way... How did it end up that way? Simple, the HTML specification doesn't say that lists need to be indented -- or even have bullets by default for that matter. Again, kind-of the point of HTML to say what things are, NOT what they look like... If you are choosing tags because of their default appearance, you are probably choosing the wrong tags and COMPLETELY MISSED THE POINT of HTML!

DOSGuy wrote:Almost every major website I go to has stopped underlining links, instead using blue text that adds an underline upon hover. Off the top of my head, this is how Wikipedia and CBC do it. CNN uses a variation where the text simply turns red during hover (no underline under any circumstances). I certainly understand the argument that underlines are an accessibility feature for the visually impaired, so why have the world's largest websites stopped using them?

Because they are big enough that they no longer care about accessibility, and could right now crap into a cone and call it ice cream, and people would yum it up?

Though I have no clue what CBC is... google... if you mean CBC.CA, that accessibiltiy train wreck of garbage is NOT something I'd hold up as an example of a good website.

DOSGuy wrote:Looks the same in IE 6-9 as it does in other browsers. I've never heard of the :focus attribute, but I haven't found a browser that seems to need it.

You don't use the keyboard to navigate, do you?

DOSGuy wrote:That's the link to skip directly to the content, so that the visually impaired don't have to hear the menu on every page, as suggested by the W3C.

Uhm, the way you are doing it screen readers will STILL read it out -- that's display:none's job if you don't want them to read it. It's appearing as 1px tall in FF/Chrome/Saffy, font-size height in IE (since no element can be shorter than font-size) and 9px in Opera since it' doesn't allow fonts to be smaller than that.

DOSGuy wrote:I didn't realize that it wasn't hidden in Opera. I can't stand that browser; I try each new version for about 5 minutes before uninstalling it and hoping that there won't be a next version.

Funny since it's my favorite, since it has everything I want in a browser actually built in, lets me move tabs over into portrait mode, and lets me customize things much more than any other browser -- a far cry better than the buggy unstable disaster area known as Firefox, or the trip in the wayback machine to IE 3's UI that webkit based browsers are. (I love the webkit renderer -- were that we had a browser with a modern UI to go with it)

DOSGuy wrote:The menu has a hierarchy. All menus on Government of Canada intranet sites use headings to allow screen readers to determine their hierarchy. That's how we do it at work!

Wow, so ignore what the tag is even FOR, flush accessibility down the toilet, and then use screen readers as an excuse. What nimrod pulled that bit of fiction out of their backside? If there's no content below them you don't use headings -- saying that's done for screen readers is the DUMBEST thing I've ever heard for that, as yes -- you should use headings for screen readers, to label content and to navigate the content -- NOT to navigate off page, that's what anchors are for. Navigating a page built that way with a screen reader like JAWS would be painful at best, nonsensical at worst.

I tell ya, explains why most government websites are totally useless garbage and the number one target of accessibility complaints.

DOSGuy wrote:It seems like it would be about 10 times as much work to achieve the same effect with the right tags, so screw using the right tags.

Negative margin, inline-block for the collapse, done... though if you are letting the appearance dictate the use of semantic tags around things they don't mean, you're doing it wrong.

DOSGuy wrote:That's never going to change. I use those codes in the database to determine the legal status of games. Changing them now would require changing every instance of them in the database, then rewriting half of the functions in the site's PHP source code to use the new names. I'm not going to rewrite a dozen functions in order to change some class names -- which don't impact the appearance or behavior of the site in any way -- in order to comply with a philosophical concept of how classes should be named.

You stored the value of "shareware","freeware",etc as the COLOR CODE? So the values in the database are gibberish?!? WOW. Storing appearance... in the database... WOW. The mind boggles. Me, I like to store meaningful values in my databases like what things actually ARE.

That's not just a "matter of philosophy" -- it's a matter of making the site easy to maintain, easy to develop, and easy for the next poor shlub that comes along to work on the codebase to have ANY idea what the devil is going on.

Starting to remember why I retired from Web Development -- I was getting a little too pissed off with the people sleazing out pages any old way and ignoring the basic structural rules of HTML... making more work for themselves and the code for sites more complex than need be all because they couldn't pull their heads out of 1998's backside. You might as well just go out and vomit up a site in Frontpage at that point.

Or Adobe's "Frontpage in Drag" -- Dreamweaver.

deathshadow wrote:

DOSGuy wrote:That's never going to change. I use those codes in the database to determine the legal status of games. Changing them now would require changing every instance of them in the database, then rewriting half of the functions in the site's PHP source code to use the new names. I'm not going to rewrite a dozen functions in order to change some class names -- which don't impact the appearance or behavior of the site in any way -- in order to comply with a philosophical concept of how classes should be named.

You stored the value of "shareware","freeware",etc as the COLOR CODE? So the values in the database are gibberish?!? WOW. Storing appearance... in the database... WOW. The mind boggles. Me, I like to store meaningful values in my databases like what things actually ARE.

That's not just a "matter of philosophy" -- it's a matter of making the site easy to maintain, easy to develop, and easy for the next poor shlub that comes along to work on the codebase to have ANY idea what the devil is going on.

There's nothing mysterious about why I did that. It used to be that games didn't have their own pages; the genre pages listed each game that belonged to that genre alphabetically (like dosgames.com. <shudder>). I decided to color code the background of each game review: blue for shareware, green for freeware, red for public domain. Remembering that I'm self-taught, I didn't know CSS when I created the site. The server-side code that generated the page from the database added code for each review that looked like bgcolor="{$db_result['bgcolor']}". Later, when I taught myself CSS, I swapped bgcolor for style="background-color: {$db_result['bgcolor']}". Then, when I finally learned about classes, I swapped background-color for class="{$db_result['bgcolor']}". By that time, I had been storing the legal status in the database as a color for years. Had I known about CSS classes when I started the site in 2005, I would have chosen a descriptive class name, but storing colors in the database made absolute sense when my intention was to set the background color with a bgcolor or CSS background-color statement.


I think we're miscommunicating about navskip. There's a link at the top of the page that lets you skip the navigation menu and go straight to the content. I want screen readers to read the link out, and I want it to be invisible to the human eye. Chrome, Firefox, and IE 6-9 don't display the link on any computer I've checked it with, though I haven't checked with Opera. I seriously can't stand that browser. Opera's GUI fell out of the ugly tree and hit every code branch on the way down.

Actual email I just received:

I just found your site. Awesome. I loved most of these games over the years, and you're doing fine work.

However, while browsing, I noticed most of your links (i.e. amazon, etc.) all redirect the current page, instead of opening a new window/tab, etc.

This makes it difficult to navigate, as I would prefer to stay on the game-page to read, and be able to check out the purchase info in a tab or another browser window, without having to click the "Back" button 3-6 times to get back to your page.

Just some food for thought.

Thanks for your hard work keeping this site going!

RH

See?

I hope this doesn't mean you're going to spoil the site by having popups all over the place for the sake of one visitor who doesn't know how to open links using the middle mouse button...

Until this thread started, every link on the site that led to another site opened in a new tab/window. (That should be the default behavior of all browsers: it only makes sense that people don't want to leave the website that they're on when they click on a link.) In 6 years of doing it that way, I never got a complaint about it.

Well I don't often complain about it because normally nobody listens! Admittedly it's not so annoying since it became possible to force new windows into tabs instead. But you could argue it's a shortcoming of browser design. At the moment, if a link opens in the same page you (the website visitor) can choose whether you want to open it in a new tab/window or not, depending on what button you click. But if the website designer forces the link to open in a new tab/window, you no longer have that choice - it opens in a new window/tab whether you like it or not. So for me, losing that choice is what annoys me.

This is why I prefer it when links open on the same page - it's the only option that lets visitors choose their preferred option. But I guess the best solution would be to allow the web site designer to provide a hint about whether the page should open in a new window or not, and let the browser decide (based on user preferences) whether to honour that hint, or override it. Then everyone would be happy

I've rewritten the database and site code to get rid of the color codes.