• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

please critique my website

option5

n00b
Joined
Sep 5, 2006
Messages
11
Hey I was wondering if you guys could critique my website for me. I want to see what you guys thought of it and how I could improve it maybe. You might think its simple, but it's supposed to be.

http://www.indiansdigest.com

- I'm also having problems with the way it views in multiple browsers. I.E the layout, txt, etc gets thrown off. Kind of hard to explain really. (I like the way it views in Mozilla FireFox, but in Internet Explorer it looks different)

If you know what im talking about how can this be fixed?
 
"2x World Champions" looks awkward. "Two-Time World Champions" reads better. You might use "Two World Championships" to match "Five Pennants".

"Read your copyright" brings me to a page that's about your site, not about "your copyright'.

You say that "Any improper use of our website layout" is forbidden. What is proper use? I think you mean "any use". Other wording on this page is similarly marginal; "by any chance", for example.

The subheadings in the roster page are hard to notice.

The advertising info link is 404.

The "Media & Entertainment" link is 404. No reason for an ampersand in that link.

Your "Discuss this article" links dump me unceremoniously in the forum. It's not very friendly. If visitors were actually using this, they wouldn't all land in the same place.

You almost always use numbers where you should use words. "2 runs on 4 hits today" should be "two runs on four hits today".
 
thanks for your response... what you said made sense. Do you think anything could be changed with the layout to make it look better? Or do you have any ideas?
 
The layout looks fine; it's usable and not garrish. I like that the font size scales. It's great that you have few (none?) ads.

Really, I barely give a darn about layout. It's content that I'm after. I don't go to a website and say "ooh, pretty!" and drool on myself while I stare at teh prittay. I read it, and think about what I read, and want to respond and interact with others on the subject. Maybe others are different.
 
just out of curiosity which browser were you using to view the site? On Internet Explorer the "comments" and "discuss" link are not displaying in the right spot. It's showing it aligned on the left side whereas it should be on the right side of the page.

In FireFox it displays correctly but its in I.E where I cant figure out whats the problem,
 
IE 7 Beta 2. I'd have no idea what the "correct" spot is, since you didn't include a specification of the intended behaviour with your request for a critique.
 
mikeblas said:
IE 7 Beta 2. I'd have no idea what the "correct" spot is, since you didn't include a specification of the intended behaviour with your request for a critique.

The infamous mikeblas uses a beta version of a MS program; Ahhhh, apocolypse is coming!

To the point:
The coloring and simplicity and your backend way of displaying information is very well put together. With all of that coding practice ..... you should definately get a different logo for the website. Other than that it is right to the point, has nice news, etc.

Good job!
 
here is the template for the "news" shown on the main page:

-------


<tr>
<td width="570"> <div align="center"><font face="Verdana" size="1">
<table border="0" width="570" cellspacing="1" cellpadding="3">
<tr>

<td style="font-family: arial,verdana, tahoma;" bgcolor="e9e9e9" width="570"><b><font color="black"> <div><strong><font size="3">{title}</font></strong></div>
<div><font size="1"><font color="#000033"><i>Posted on {date} by {author}</i></font></div></font>
</td>
</tr>
<tr>
<td width="75%" style="font-family: arial,verdana, tahoma; font-size: 10pt; color: #000000; padding:3px; margin-top:3px; margin-bottom:5px; border-top:1px solid #D3D3D3;"> {short-story}</td>
</tr>
<tr>
<td width="100%">
<table border="0" style="border-top: 1px solid #d3d3d3; font:10px veranda; color:black" width="570" cellspacing="0">
<br></td>
<td width="168" ><div align=right><div style="font-family: arial,verdana, tahoma; font-size: 10pt;"><b>[full-link]Full Story[/full-link]</b> - [com-link]{comments-num} Comments[/com-link] - <a href="http://www.indiansdigest.com/forums"><b>Discuss this article</b></a>.</div>
<tr>
</div>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>




-----


Here is the code where it has the comments, and dicuss to be on the right side:


<td width="168" ><div align=right><div style="font-family: arial,verdana, tahoma; font-size: 10pt;"><b>[full-link]Full Story[/full-link]</b> - [com-link]{comments-num} Comments[/com-link] - <a href="http://www.indiansdigest.com/forums"><b>Discuss this article</b></a>.</div>


----

Whats making it perform differently??
 
Code:
<table border="0" style="border-top: 1px solid #d3d3d3; font:10px veranda; color:black" width="570" cellspacing="0">
<br></td>
<td width="168" ><div align=right><div style="font-family: arial,verdana, tahoma; font-size: 10pt;"><b>[full-link]Full Story[/full-link]</b> - [com-link]{comments-num} Comments[/com-link] - <a href="http://www.indiansdigest.com/forums"><b>Discuss this article</b></a>.</div>
<tr>
</div>
</td>
</tr>
</table>

the table begins, and then the table cell data ends. Huh?
Then the table data begins again, then a div begins, then another div begins.
Then a table row begins, then a div ends. Then table data ends.
Then the row ends.
Then the table ends. But that one div is still open.

That a browser can parse, with all its errors, and display anything remotely resembling what you intended seems quite impressive. Maybe you should start by fixing all the errors you can find.
 
As far as markup goes, you need to have a doctype on the first line of your source so browsers render in standards mode. Then, you can fix display problems between browsers. Test in at least IE, Firefox and Opera while you're developing. Do not develop the page while testing only in IE and then checking in other browsers after you're done. That will just cause you problems. Also, when it doubt, assume that Firefox and Opera are correct in what they display and assume IE is incorrect.

Anyway, it looks like this:
Code:
<!DOCTYPE html>

Then, if you want your markup to conform to a certain dtd, you need a doctype that specifies the version and dtd URI.

See http://www.opera.com/docs/specs/doctype/ for why and how doctype matters.

See http://www.w3.org/QA/2002/04/valid-dtd-list.html for the standard dtds you can use.

Judging by your current markup,

Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
        <title>title</title>
    </head>
    <body>

    </body>
</html>

would fit you best.

Then, as already pointed out, you can check your page to see if it conforms to that HTML 4.01 transitional dtd by going to http://validator.w3.org/ and checking the page.

Also, for good habits, make sure your tag names are all lower case. Make sure your attribute names are lowercase and make sure your attribute values are quoted.
 
Shadow,

so do I add this code before my <html> tag:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

or do I need to add more? You know more than me.
 
Everytime i declare a doctype all my CSS and DHTML and half my javascript support goes down the toilet ..... Also when using mutiple includes in SSI languages, how are you supposed to know the correct standards all the time?

Ive used a page before in quirks mode that displays fine in all browsers, then doctyped EVERY doctype I could find, and none of them worked correctly.
 
option5 said:
Shadow,

so do I add this code before my <html> tag:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

or do I need to add more? You know more than me.

Yes, you add it before the html tag. Make sure it's on the very first line of the source. You can check that by going the page in a browser, viewing source and checking to see if it's on the first line.
 
MadJuggla9 said:
Everytime i declare a doctype all my CSS and DHTML and half my javascript support goes down the toilet

That's most likely because you waited to declare the doctype after developing the page. What you see in standards mode is what your markup tells the browser to do. If it doesn't look right, your markup, css, js etc. are telling the brower the wrong thing. ( browser bugs aside.)

If quirks mode works for you, that's fine, but do note that quirks mode among browsers differs a lot more than standards mode.

If you start of with a proper doctype so that browsers render in standards mode, things will be fine and all you will have to do is work around browser bugs. With quirks mode, you let each browser work around bugs in their own, different way.

If you do not like developing for standards mode, you probably wouldn't like XHTML.
 
any reason why once I added that code it messed up the alignments a little.... i.e it made the table borders a little darker and make the news headline table different...


i temporarly took the code off...
 
option5 said:
any reason why once I added that code it messed up the alignments a little.... i.e it made the table borders a little darker and make the news headline table different....

Didn't catch your post. The forums are a little stingy on email notification.

Anyway, it happened because rendering switched to standards mode.

The change didn't mess up the alignment. It was already messed it. You just couldn't see that because your page was invoking quirks mode instead of standards mode.

I'm suggesting you keep the doctype and make things look right in standards mode, but ultimately, it's your choice and there's nothing wrong with that.
 
Shadow2531 said:
Didn't catch your post. The forums are a little stingy on email notification.

Anyway, it happened because rendering switched to standards mode.

The change didn't mess up the alignment. It was already messed it. You just couldn't see that because your page was invoking quirks mode instead of standards mode.

I'm suggesting you keep the doctype and make things look right in standards mode, but ultimately, it's your choice and there's nothing wrong with that.

Look at my post above. I do agree that standardization is best. But when you get into larger sites there's no way to doctype all kinds of includes and feeds from outside sources. I think a browser shoud be smart enough to render a webpage ... I mean ... that's its primary job. Perhaps the favorites and lovely add-ons should be put off until they can correctly render a page.

If you ever take a compiler theory class, youll note that you go by pattern matching with opt codes, offsets, jumps, etc (how function declarations differ from function implementations, how to know when a variable is being declared or if it exists by keeping a seperate paging scheme, this can get down into the architecture of memory controllers and addressing) ..... web programming is so simple compared to machine instrutions at low level that I just assume theres not enough put into web browsers; My personal opinion of course. Using regular expressions and pattern matching for web standards is like teaching retards compared to what a non-realtime compilers like gcc,masm, etc do
 
MadJuggla9 said:
I do agree that standardization is best. But when you get into larger sites there's no way to doctype all kinds of includes and feeds from outside sources.

Understood. Ultimately, you do what you need to make things work. Nothing wrong with that.
 
I'm using Firefox and I see the website without issue. I like it...simple, direct, informative.
 
MadJuggla9 said:
If you ever take a compiler theory class, youll note that you go by pattern matching with opt codes, offsets, jumps, etc (how function declarations differ from function implementations, how to know when a variable is being declared or if it exists by keeping a seperate paging scheme, this can get down into the architecture of memory controllers and addressing) .....
Where are you going to school, Mad?
 
mikeblas said:
Where are you going to school, Mad?

Im afraid to say .... why? I assume you are going to point out flaws or something lol. Won't be the first time you've corrected me ;)

I still think browsers should work harder to interpret code better anyhow.
 
MadJuggla9 said:
Im afraid to say .... why? I assume you are going to point out flaws or something lol. Won't be the first time you've corrected me ;)
Because what you said above is just a string of jargon that barely makes sense.

MadJuggla9 said:
I still think browsers should work harder to interpret code better anyhow.
It's impressive that any browser was able to do anything with option5's page. The tags weren't even nested correctly, many weren't closed, yet the page rendered was not unreasonable. I think they could be better at reporting errors. It seems strange that we need to go to that validation site in order to see what the browser already knows.
 
mikeblas said:
Because what you said above is just a string of jargon that barely makes sense.

It's impressive that any browser was able to do anything with option5's page. The tags weren't even nested correctly, many weren't closed, yet the page rendered was not unreasonable. I think they could be better at reporting errors. It seems strange that we need to go to that validation site in order to see what the browser already knows.


It does make sense if read correctly. Have you ever made a pseudo compiler or tokenized non script languages on tokens/lexemes? It's MUCH harder work than a browser must do by far as you probably know. The browser's interpretation is a majority of tokenizing tags. <a> and </a>: beginning and end. I understand theres more to it, but it's nowhere near comparable status to what compilers do.

I never looked at his code anyhow. Not ending tags is a lack of work on the programmer's end. The page rendered pretty well in quirks, nothing I noticed wrong anyways. Validation, as stated, is just not as worthy as it is revved up to be IMO.

It worked just fine anyhow until it was restricted to standards. Yes I know standards are good to follow, but it doesn't mean its the line of judgement as far as good/bad goes. I just see it as an additional plus. Again, my opinion.
 
MadJuggla9 said:
It does make sense if read correctly.
Or, not. There's no such thing as an "opt code"; you must mean op codes. Op codes have nothing to do with pattern matching. Pattern matching has nothing to do with offets (er, an offset from what to what, anyway?) or jumps. You've somehow tried to tie pattern matching to assembler or machine code. Your parenthetical is about tokenizing a language; that has nothing to do with "the architecture of memory controllers", or addressing.

MadJuggla9 said:
I understand theres more to it, but it's nowhere near comparable status to what compilers do.
The front-end of a classic compiler/interpreter is really just a tokenizer and a lexer. So, sure; there's more to it, but parsing is parsing. How much is "nowhere near"? It'll depend on the language.

MadJuggla9 said:
Not ending tags is a lack of work on the programmer's end.
Yep. But the implementation of the browser is responsible for inferring what should have been there, what needs to be rendered as a result, and what makes sense. It can't throw its hands up and quit when it encounters an error -- otherwise, people like you who think that validation isn't worthwhile, would end up being frustrated by browsers that pedantically anaylse your pages and fail to render them because of even small errors. Not to mention the grand problems option5's code had/has.
 
mikeblas said:
Yep. But the implementation of the browser is responsible for inferring what should have been there, what needs to be rendered as a result, and what makes sense. It can't throw its hands up and quit when it encounters an error.

It can and does if you use XHTML. ( xml with the xhtml namespace, served as application/xhtml+xml)

When IE finally gets on board with XHTML support, it will be practical for many more situations than it is now. I also have faith that even those that expect browsers to fix their broken code will jump on board in situations where XHTML wouldn't be a problem.

I may be in the minority, but I love it that ( when you use xhtml ), the page breaks when there's a markup/parse error. The way Opera does it is extra cool because you can choose to reparse it as text/html if there's an error.
 
Shadow2531 said:
It can and does if you use XHTML. ( xml with the xhtml namespace, served as application/xhtml+xml)
And it will for extreme cases of bad HTML, too. But the browser's rendering of its source is far more resilient than the analogous tools for any other computer langauge I can name.
 
mikeblas said:
Or, not. There's no such thing as an "opt code"; you must mean op codes. Op codes have nothing to do with pattern matching. Pattern matching has nothing to do with offets (er, an offset from what to what, anyway?) or jumps. You've somehow tried to tie pattern matching to assembler or machine code. Your parenthetical is about tokenizing a language; that has nothing to do with "the architecture of memory controllers", or addressing.

The front-end of a classic compiler/interpreter is really just a tokenizer and a lexer. So, sure; there's more to it, but parsing is parsing. How much is "nowhere near"? It'll depend on the language.

Yep. But the implementation of the browser is responsible for inferring what should have been there, what needs to be rendered as a result, and what makes sense. It can't throw its hands up and quit when it encounters an error -- otherwise, people like you who think that validation isn't worthwhile, would end up being frustrated by browsers that pedantically anaylse your pages and fail to render them because of even small errors. Not to mention the grand problems option5's code had/has.

This is getting too off-topic and you're taking parts of my phrases out of context. I was simply tying my story together from one part to another skipping MANY in-betweens, I'm not saying I'm using a transitive property to go from A to Z skipping steps B-Y, I filled in a few of the B-Y steps as reference but not as a fulfillment of reading a book over watching its movie. Of course my steps don't directly relate ... I know that.

The ONLY basic principle I am stressing here is that parsing HTML is easier than any non scripting languages. It doesnt matter what language it is ..... perhaps youd rather write a parser for COBOL and fortran as to HTML and CSS ...... I guess that could be an opinion on severity of difficulty, but 90% of web languages would be much easier to write a parser for and 90% would agree, hence why we agreed partially on how browsers could use a little more implementation for correctly parsing code unless its is a blatantly obvious that the code has no end tags, etc. A compiler would pick that up anyways.

So anyways, the site looks good. Yes it can use standardization, but don't kill yourself over it with such a large site and large amounts on included/fed data. DO, however, code it correctly and end your tags atleast. Take it one step at a time. Most prefer coding with a standard first, you never know what you run into though. Id personally do it last if I were worried my code could not be interpreted.

Call me a cheapskate, but if my code works in all browsers and I have nested things correctly and generated good code, who cares if I leave off unneccessary alt tags, table border tags, etc which should be interpreted as null if they are not there anyways.

Hope this discussion has exposed you to some of the other things out there and how tedious programming CAN be :)
 
MadJuggla9 said:
The ONLY basic principle I am stressing here is that parsing HTML is easier than any non scripting languages. It doesnt matter what language it is .....
I can't agree with that. Perhaps it's because I don't see how "opt codes" or memory controller architectures are involved. Or, perhaps it is because your generalization is far too wide: there are lots of non-scripting langauges which are very simple to parse, while HTML isn't as easy to parse as you think. Could also be that you're thinking about tokenization instead of parsing.
 
MadJuggla9 said:
Sorry, I just had to. You did it to me twice on my "opt codes"
Fixed! I hope that enables you to respond substantively.
 
Back
Top