2 replies [Last post]
skitelluride531
Offline
Regular
Last seen: 13 years 13 weeks ago
Joined: 2009-01-05
Posts: 17
Points: 0

I've just finished up the index of my home page. I'd love it if someone here would look over it. THANKS!

http://www.new.elite-css.com/

Stomme poes
Stomme poes's picture
Offline
Elder
Netherlands
Last seen: 10 years 48 weeks ago
Netherlands
Timezone: GMT+2
Joined: 2008-02-04
Posts: 1854
Points: 378

Well, are you

Well, are you ready?

Congrats on writing a valid page. Too many sites just don't.

Initial thought re design was, the images are beautiful.

The bad/comments:

When first loading your page (and I'm supposedly on DSL), the first of your three blocks at the top (the timeline) had the background showing up on time, however the other two loaded last, making reading difficult. I would suggest giving coloured backgrounds to make text readable until the image appears (also some people never dl the image at all!)... this would be a hair tricky since you don't want the bg colour to show when the image appears, but it can be done.

I also think that, as text is enlarged (not zoomed) that the text in that timeline should be able to overflow, and push the rest of the page down. I know often I'll overflow: hidden a box so that the content inside can't cover content further down, but it looks like you have room to go ahead and let the timeline push the form down.

The site nav: While you are actually making use of the wrapping div, I don't think you need it. The ul itself can hold all those declarations, and if you need sliding doors, the last li can hold the right rounded curve.

Javascript form validation is evil. Never let the client validate. The server should validate. In fact, does the page even work if the user has no JS? JS should enhance a working page, but should never be a crutch.

Inline styles are so appealing, because it's just this ONE place where you want this style, huh? Don't give in. Inline styles mean someone has to crawl into the HTML to make a style change. Crawling the HTML should be for CONTENT changes not style changes.

I'd take overflow: hidden off the div called form. Even on my screen the bladeren button (for file upload) is half-cut-off (FF3 on Gnome windowing system seems to enlarge form input areas for some reason... so assume other systems may do it too, and undfortunately the input type="file" is one of the elast stylable elements, so yes you're stuck with it, let it overflow).

Only when I shrink the text quite a bit can I see which radio button belongs to HTML/CSS and which to Wordpress. With radios, you want to find a way to keep the radio button (or the checkbox) always hugging its label. So, if the label wraps, make the button/box wrap as well. As it is, many people don't see the convention in having the button to the left of the label (so a bunch of options in a row, people still don't seem to know which button belongs to which input).

The good thing here is, you've linked your labels with their inputs explicitly, so the user has the option of clicking on the label text, and screen readers will be able to match inputs with their labels.

Putting extra content INSIDE a form is not a good idea. Forms should be mostly made up of form controls-- using some divs for grouping, columns, or label-input pair wrapping is ok, but h1, h2, p's, explanations, those should try to stay OUT of the form. You can fake them looking like they're IN the form by having a block wrapping the form and holding all the bg colours and border etc. I would take many of your wrapping divs OUT of that form, and ALL of the clearing divs. Clearing divs are no longer cool. They give people pre-diabetes (but not full-blown diabetes like br's do). Remember that screen readers in Forms Mode do not hear the non-form controls-- only legends, labels and inputs.

Tabindex: realise that tab index is NOT as good idea... you can use it, but only if you are really good. Why? It will steal the normal document flow from the user. You have them in your form, but guess what? They control the whole page. Someone may have to tab through your entire form before being able to get to your site menu. That's a pain. Unless you have a goofy source order that you can't change and MUST make sure the keyboarding user needs to tab in a direction different from normal flow, keep the tab indexes out. There are many sites out there cautioning against them for this reason.

	<label>
			<strong>Website Type:</strong>
			<br/><span class="subform">(Wordpress Coming Soon)</span>
		</label>

could be

	<label>
			<strong>Website Type: </strong>
			<span>(Wordpress Coming Soon)</span>
		</label>

with label strong OR label span being display: block... which will give you a new line stylewise. No styles, there will still be at least a space from your newline between elements and if not, you can stick a space after the :
Website Type: (Wordpress coming soon)

Be aware you may be locking users out with that dragbar thingie. You've obviously thought of keyboarders, because you've added a tabindex. What are keyboarders going to do with the slider? I can't slide it either. Maybe it runs on Javascript? You can maybe have a normal input where people can type a number, and those with scripts, load a script that converts the input (or maybe a select dropdown?) into the slider, and people typing in a number could still move the slider? That way, everyone can use the form, and people with JS and mice get a cool effect.

Multiple H1's aren't a great idea but they're not illegal. Which one do you think best heads that entire page?

rows="7" cols=""

Ok while this is legal it's kinda cheating (and makes a really skinny textarea with styles off). Put a number in cols and in CSS you can *generally* style it pretty good. I've noticed that the rows and cols vary wildly per browser but the CSS values work much better. I check in Konq because it's the browser who makes textareas the widest. IE and Opera seem to make them pretty small. Safari lets users resize to their hearts content. Bah!

I'm no big fan of the Yahoo resets, and here's a fout:

/* tables still need 'cellspacing="0"' in the markup */
table {
	border-collapse: collapse;
	border-spacing: 0;
}

No, tables don't need cellspacing in the markup. I think that's something Eric Meyer or whoever first thought was the case, or maybe it was true for much older browsers? But it's not true now.

	-moz-border-radius: 5px;
	-webkit-border-radius: 5px;

Even though it's not spec yet, go ahead and add the regular CSS3 border-radius too. Any browsers who attempt to implement the actual one (whenever it's out of draft, lawlz) might work esp if you don't have time to get to your CSS right away.

In any case, it's mostly good, impossible to read if images don't load (dial-uppers?) and doesn't text-enlarge very well (but has potential to scale well). Mostly I'd ditch the unhelpful tabindex and try to get those inline styles out. Take a look at your page with CSS on and images off. Try to use the page like someone without a mouse. Can you do everything you want to? Now, can your mom?

Since you're selling your ability to code, people are going to look at your source. Make it shine.

Good luck.

I'm no expert, but I fake one on teh Internets

skitelluride531
Offline
Regular
Last seen: 13 years 13 weeks ago
Joined: 2009-01-05
Posts: 17
Points: 0

Really appreciate you taking

Really appreciate you taking the effort to look this over for me! I am going to go through everything tomorrow and make some changes based on your suggestions!

THANKS!