Recent HTML & CSS Structure? What do you think?

Discussion in 'HTML & Website Design' started by rolodex, Mar 31, 2013.

  1. #1
    I have problem understanding Doctype and its usage, further reading required. So I just put the latest (HTML) for it.

    Can someone please download the file and see whether my practice is semantic or how can I improve on my code grammar.

    For the rest out there, you can use this freely as yours. It's my practice file.

    Thanks a bunch.
     

    Attached Files:

    rolodex, Mar 31, 2013 IP
  2. wiicker95

    wiicker95 Well-Known Member

    Messages:
    438
    Likes Received:
    37
    Best Answers:
    10
    Trophy Points:
    100
    #2
    It is really good that you decided to learn writing proper HTML. You have made a good number of mistakes, but it's good since you are in learning phase. I will point out all I could could find. I will only comment daftarstaff.html, it's pretty much the same errors repeated.

    HTML:

    L. 1: It is not really a mistake, but you should try to avoid the x1 tranny doctype. I'm not only saying this for fun, tranny at the top basically means your code is a transition from 20th century bad practices to 21th worse. As a matter of fact, you have 3x the formal errors with the strict doctype.

    L. 4-7: You have omitted an important META name keywords.

    L. 9: "Mobile" value for media LINK attribute doesn't exist. I suppose you wanted to write handheld, but it's pretty much screen with a low max-width.

    L. 18: It is not a good idea to make you logo an empty span. It should have probably looked something like this :
    <h1>
        <a href="#">
            JUTA
        </a>
    </h1>
    Code (markup):
    Mind you, there is no unempty tag left empty. You can give your h1 a background image in CSS (that cercle), and make JUTA - text. If you don't want it to be text, then put an empty span below JUTA, and give it a background image. In both cases, you'll have text replacement. I would personally go with the first solution for multiple reasons, it's your call though.

    L. 20: You don't have an h2 preceeding this h3, let alone an h1 englobing them all. It's h2's job, but ONLY if preceded by a valid h1.

    L. 21: No need to break any lines here.

    L. 22: All the fun starts here! Use ID to target forms, not names. That name is pretty much unnecessary there. Method value cannot be "POST". Either "get" or "post". You should also avoid inline onevents. Not to mention that the event "onSubmit" doesn't exist. It's "onsubmit", but that's one of the events you shouldn't even be using.

    L. 23: You have omitted a FIELDSET element. INPUT cannot be direct children of FORM.

    L. 24: This is LEGEND's job, not h4's.

    L. 26-68: When INPUT isn't LABEL's child, you give it an ID as well as FOR to your LABEL. "Naming" your input serves to no purpose, you use ID you gave them. Class="textinput" is redundant there.

    L. 28-70: Clearing your floats with an empty DIV is bad practice, clearing it 20 times in a single wrapper is 20 times worse practice. fieldset {overflow:hidden} is all what it would take, that is if you had any fieldset.

    L. 38: You've omitted two mantadory attributes, cols and rows. Type attribute doesn't exist.

    L. 58: Same issue, LEGEND, not H4. New LEGEND usually means new FIELDSET (it's the other way around), but not necessarily.

    L. 76: Semantically wise, this BR should have been an HR. If you don't want it to appear, give it a display:none in CSS.

    CSS:

    Don't format it your CSS inline, strip white spaces between properties and values. Let your markup dictate your stylesheet, not the other way around. Due to this you have a number of unneeded and redundant declarations. It lacks reset, font declaration in body. All your widths are fixed, font sizes are declared in px. Since you wanted to test your semantics, I won't be as rough on your CSS. But just so you know, it could be better.
     
    wiicker95, Mar 31, 2013 IP
  3. rolodex

    rolodex Well-Known Member

    Messages:
    364
    Likes Received:
    37
    Best Answers:
    5
    Trophy Points:
    175
    #3
    Which doctype should I use next time? <!DOCTYPE html>?
    Is it case-sensitive? How do I avoid inline onevents? I'm gonna read some more on HTML Forms and how to function and optimize it properly. INPUT cannot be a direct children of FORM? How's this?
    <form id="myform" action="test.php" method="post">
      <fieldset>
          <legend>User Info</legend>
          <label for="name">Name</label>
          <input type="text" name="name" />
      </fieldset>
    </form>
    HTML:
    Does fieldset{overflow:hidden} clears floats?
    Where should I put the events? And which event should I be using?
    HR. I've forgotten about that.

    Thanks wiicker95 for taking your time analyzing my humble little code. With your knowledge shared, my HTML grammar will be top-notch in the next document, and the rest of DP's readers, too.

    Now the grammar of CSS. I'm gonna have to read more on this. I know its bad, but I'll try to improve.
     
    rolodex, Mar 31, 2013 IP
  4. wiicker95

    wiicker95 Well-Known Member

    Messages:
    438
    Likes Received:
    37
    Best Answers:
    10
    Trophy Points:
    100
    #4
    Use XHTML 1 Strict or HTML 4 Strict.

    You would have to write your own scripting to handle to handle it.

    This is how you would want it to look like :

    <form
        id="myform"
        action="test.php"
        method="post"
    >
        <fieldset>
            <legend>
                User Info
            </legend>
            <label for="name">
                Name
            </label><input
                type="text"
                id="name" 
            />
        </fieldset>
    
    </form>
    HTML:
    It's almost identic to your version, but I stripped the names and put ID.

    Yes, overflow:hidden wraps floats, and a lot of amazing stuff besides that.
    I'll rewrite the whole thing later today.
     
    wiicker95, Mar 31, 2013 IP
  5. kk5st

    kk5st Prominent Member

    Messages:
    3,497
    Likes Received:
    376
    Best Answers:
    29
    Trophy Points:
    335
    #5
    and
    The name attribute's value is the variable name associated with the input value. The submission to the server is the name/value pair. Input values without a name attribute are not supposed to be sent. Name tokens may be repeated and, in fact, define the set of radio buttons. Id tokens otoh must be unique. E.g.
    <label for="m">
      <input type="radio"
        name="gender"
        id="m"
        value="man" />
      &nbsp; Male
    </label>
     
    <label for="f">
      <input type="radio"
        name="gender"
        id="f"
        value="woman" />
      &nbsp; Female
    </label>
    Code (markup):
    See §17.13.2 Successful controls, especially this:
    cheers,

    gary
     
    kk5st, Mar 31, 2013 IP
  6. rolodex

    rolodex Well-Known Member

    Messages:
    364
    Likes Received:
    37
    Best Answers:
    5
    Trophy Points:
    175
    #6
    Purpose of NAME is to serve the server. OK!
    Apparently I'm working on a form right now. I have corrected the HTML to discard all NAME.

    Now I have to revert, thanks to you kk5st.
     
    rolodex, Mar 31, 2013 IP
  7. kk5st

    kk5st Prominent Member

    Messages:
    3,497
    Likes Received:
    376
    Best Answers:
    29
    Trophy Points:
    335
    #7
    What a great way to put it.

    cheers,

    gary
     
    kk5st, Mar 31, 2013 IP
  8. wiicker95

    wiicker95 Well-Known Member

    Messages:
    438
    Likes Received:
    37
    Best Answers:
    10
    Trophy Points:
    100
    #8
    Well of course, but as I mentioned (I thought i did, but it appears I didn't), it has nothing to do about quality of his HTML. Control naming is pretty much mandatory, no doubt about that, but we aren't talking about form submission handling here. Thanks for stating that though, now that I read my post, I actually say that it's useless, which it isn't! That's not what I intended to say lol...
     
    wiicker95, Mar 31, 2013 IP
  9. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,999
    Best Answers:
    253
    Trophy Points:
    515
    #9
    Wiicker95 hit most of the good points -- but a few more things.

    You have your CSS in a subdirectory, which is making you up-tree link to the images. Images called by the CSS are better placed in a subdirectory of the stylesheet's location. This way you're linking "down tree" instead of up-tree. Usually makes it more portable, and opens the door to using multiple skins later on. Also, stylesheets aren't scripts -- so putting it in a 'scripts' directory doesn't make any sense.

    Avoid the named font sizes, their behavior can be unpredictable, and if you change the font size, EXPLICITLY re-declare the line-height. You can never trust the line-height once you've changed the font-size.

    Do NOT turn of underscores on anchors globally on your document -- not everyone can see color. Likewise you are usually better off targeting A and just A first -- then hitting the pseudostates -- and don't forget to feed :focus and :active the same values as :hover so people navigating via the keyboard aren't left out in the cold.

    Really Wiicker hit most of it on the head -- Lemme just summarize what I'm seeing from that archive file --

    HTML 5 lip service doctype so validation is pretty much meaningless

    Pointless "author" meta that nothing would actually use

    Description meta that doesn't describe what the page is about

    incomplete media stack (should be "screen,projection,tv" and not just "screen")

    There's no such thing as 'mobile', as Wiicker said that could be 'handheld' but I really wouldn't bother with that 'target' anymore, and instead rely on media queries. (that or add handheld to screen and then put a copy of the query layout in a handheld.css as a second layout trigger)

    Vague/presentational outer ID -- 'bigBox' really doesn't tell us what it IS.

    Empty span don't H1's job... also there's no reason to be putting a non-breaking space inside it if you have a valid doctype.

    Line-break doing padding's job.

    DIV around the perfectly good FORM tag for no good reason.

    H3 that makes no sense without H1 or H2 preceding it, and that appears to be a LEGEND's job.

    No fieldset on the form.

    No FOR attribute on the labels.

    I'd suggest somewhat more unique ID's on the form.

    onclick crap on the submit buttons for **** only knows what... really the form should submit to the SAME file, and that file (which would NOT be HTML) would then determine which button was clicked. Cute 'trick', a button of type="submit" will populate it's named index when you click it, otherwise it'll be empty/undefined.

    NOT that the second "button" shouldn't be a button, it should be an ANCHOR. Don't replace HTML functionality with some stupid scripting crap just because you want it to 'look' a certain way.

    pointless clearing DIV -- this isn't 2001. (most likely you're floating when you should be inline-block or working off margins)

    ... and what makes the footer content a paragraph? Is it a consistent thought of natural flow text? No, no it's isn't -- hence all the line-breaks inside it. Good rule of thumb, if it's short bits of text broken into multiple lines like an address, it's NOT a paragraph. Images are NOT paragraphs, sentence fragments are not paragraphs... There's a LOT of things that are text and are NOT paragraphs that people seem to slap the P tag around for no good reason.

    I'd also suggest a HR before the footer (hidden by the CSS) to indicate the change in topic, since that footer text/address is not a subsection of "System Login".

    Some better indenting wouldn't hurt either.
     
    deathshadow, Mar 31, 2013 IP