Not bad, but it could be better. Remember that people are going to be judging the quality of your services based on your site, and that at least some of the work that might come your way will be coming from designers/developers who either don't have the time for a particular job or can't work within the client's (usually unrealistic) budget. That means that you need something that is more than surface pretty; it needs to be beautiful to the core.
The first thing to do is to get out of the XHTML habit. The xhtml 1.x transitional doctype didn't really solve any problems; it just made the markup syntax needlessly complex by requiring a closing solidus on unary (non-container) tags, and you still had to leave a space before the solidus or the browsers of the day would reject the markup as invalid. And you needed to include the silly DTD URI and namespace, neither of which were used by the browser for anything except a standards/quirks mode flag (no user agents actually fetched the DTD). Make friends with the new HTML doctype...
HTML Code:
<!DOCTYPE html>
... and forget that anybody ever suggested <hr /> or <br /> in the first place. XHTML was a poorly-reasoned answer to a problem that it never actually solved (it actually introduced more problems than it solved, since as an XML dialect it doesn't enforce sibling element ordering) and it has been dead-ended. The only possible excuse for using it is if you're designing/developing for IE6 in a closed corporate environment (and pity those who are stuck doing that).
I noticed that your links are all absolute, in this format:
HTML Code:
<a href="http://batorudesign.elementfx.com/imagine.php?nume_fisier=first_point.jpg" title="First Point">
Don't do that for internal links, ever. Use server-relative URLs for internal links, and protocol-relative URLs for external ones. Server-relative links begin with a solidus:
HTML Code:
<a href="/imagine.php?nume_fisier=first_point.jpg" title="First Point">
The browser will fill in the http://barotudesign.elementfx.com part automatically. Doing things that way means that you don't need to change the URLs when you change domains, and that if you have multiple domains (an add-on or parked domain in addition to your elementfx.com subdomain), the user is never surprised by a sudden trip to a web site they hadn't meant to visit. They don't notice that it's the same site -- if they head to, say, batorudesign.com and are redirected to batorudesign.elementfx.com, they're going to assume that you've been hacked and they've been hijacked. Similarly, you should never force a protocol on your users. It doesn't make a lot of difference here on Free Hosting, since there is no option to use HTTPS/SSL, but if you ever move hosting or design for someone else who has the SSL option, forcing a protocol can cause some users to bounce due to privacy concerns (if they're using HTTPS and you force them to HTTP), or may prevent them from accessing your site (if their company, hotspot or ISP blocks HTTPS requests and you try to force them in that direction). Resources linked externally will also cause the "mixture of secure and unsecure content" warning, and may prevent the browser from opening the page. A protocol-relative URL begins with two solidi:
HTML Code:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js"></script>
In this case, the browser will fill in either http: or https:, depending on what the user was already using.
In your meta tags, you've put the content attribute before the name, which makes it hard to read and modify. People notice things like that, and anything you do that makes it look like your code will be difficult to maintain is a red flag. The same goes for your indentation/white space and seemingly-random line spacing -- clean that up. White space may be (mostly) irrelevant to the browser, but keep in mind that
... programs must be written for people to read, and only incidentally for machines to execute.
Structure and Interpretation of Computer Programs, Preface to the First Edition
What people see when they view the source matters, particularly if you are building a portfolio so that you can eventually make a living at this, either as a paid freelancer or if you're looking to be hired by a design/development/consulting company. A sloppy page source like building a really nice looking car that gives people nightmares when they lift the hood/bonnet -- it doesn't matter what the paint job looks like, they're not going to buy it.
Oh, and do try to get out of the habit of doing this:
HTML Code:
<p>
This is the paragraph content.
</p>
A line break is supposed to be interpreted as significant white space, equivalent to ASCII character 32. User agents that get it right should put a space at the beginning and end of the paragraph; that none of them do at the moment (and many used to) is just a temporary lucky break for people who have developed XML habits in an SGML world, or who think all "computery" stuff should behave like C. (In XML, you wind up with an extra empty text node, which can make DOM traversal hard. And the tab or spaces you've used to indent should also count as significant white space, collapsed to a single space.) The proper markup is this:
HTML Code:
<p>This is the paragraph content.</p>
Sorry that this has turned into a full-scale review, but your work is mostly good, and avoiding just a few pitfalls will greatly increase the probability that you'll get work in the future.
4Likes
LinkBack URL
About LinkBacks
Reply With Quote
Originally Posted by min_d_jee75
