SitePoint Sponsor

User Tag List

Results 1 to 25 of 25
  1. #1
    SitePoint Zealot
    Join Date
    May 2010
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    whats the correct way to layout 2row 2 column forms using css xhtml strict

    whats the correct way to layout forms using css xhtml strict , so you have 2 text areas on each line, and have control over the space between the lines. I used unordered lists as in my other post but unwanted space occured

  2. #2
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Uhm... do you have a picture of what you are trying to do, having trouble visualizing it.

    If I'm understanding the question, you SHOULDN'T need ANY extra elements like lists, tables, div, etc to do a form since you have labels and inputs. Your other thread left me with just one question about that list - WHY!!!!! There is NO reason to be wasting markup on a LIST there.

    You can:
    <label>My Element/label>
    <input />
    <br />

    Controlling space between them with line-height.

    You can:

    <label>
    <span>My Element/span>
    <input />
    <br />
    </label>

    setting label to display:block and pad the bottom, while fixing the width and floating the two inner tags.

    Though really I'd have to see what it is you are trying to accomplish for a layout on it to come up with the best markup to accomplish it with.

  3. #3
    SitePoint Zealot
    Join Date
    May 2010
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    all I want to do is layout this

    name_______________ company _________________

    phone_______________ email __________________

    without tables so they go next to each other and the control between thats not <br />'s . I'm fairly new to laying out with CSS and the recomended techniques, i'm an old tables and 1x1 dinosaur who's only recently made the jump to lightspeed !

  4. #4
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Ok, semantically they aren't two separate fieldsets (your example in the other thread had them as such) NOR are they lists... You just have some labels and inputs. They'd be ONE fieldset, but I'd use two SPAN to break them up for floating.

    Looking at your other example, I'd approach the markup for that something like this:

    Code:
    <form method="post" id="quickContact" action="basicvalidation.php" onsubmit="return checkForm();">
    	<fieldset>
    		<legend>Your Contact Info</legend>
    		
    		<span>
    		
    			<label for="name">Name:</label>
    			<input type="text"
    				name="name" 
    				id="name"
    				size="15"
    				maxlength="30"
    			/><br />
    			
    			<label for="company">Company:</label>
    			<input type="text"
    				name="company"
    				id="company"
    				size="15"
    				maxlength="50"
    			/><br />&nbsp;
    			
    		</span><span>
    		
    			<label for="phone">Phone:</label>
    			<input type="text"
    				name="phone"
    				id="phone"
    				size="15"
    				maxlength="30"
    			/><br />
    			
    			<label for="email">E-Mail:</label>
    			<input type="text"
    				name="email"
    				id="email"
    				size="15"
    				maxlength="50"
    			/><br />&nbsp;
    			
    		</span>
    		
    	</fieldset>
    	
    	<div>
    		<input type="image" src="images/quick_response_send.gif" value="send" alt="send" />
    	</div>
    	
    </form>
    You'll notice I didn't put the submit in a fieldset. To me a fieldset contains FIELDS - stuff the user fills out, so the input that submits the form doesn't belong there. It's also an easy way to provide a hook to style it with CSS if wanted without inheriting the properties of it's parent elements.

    Oh, and the non-breaking spaces are there because IE CORRECTLY collapses the bottom, while modern browsers do not...

    For the CSS, I'd probably be doing something like:

    Code:
    #quickContact fieldset {
    	overflow:hidden; /* wrap floats standards browsers */
    	height:1&#37;; /* trip haslayout, wrap floats IE */
    }
    
    #quickContact span {
    	float:left;
    	white-space:nowrap;
    }
    
    #quickContact label {
    	display:-moz-inline-block;
    	display:-moz-inline-box;
    	display:inline-block;
    	width:10em; /* you'll have to play with this value */
    }
    the inline-block behavior (or for IE the element already being inline-level) lets you set a even width, so you don't need to play with floats on your labels/inputs. The nowrap on the spans will prevent the labels/inputs from riding down, while the floats puts the two span next to each-other. I used span instead of DIV

    1) so that div's block behavior doesn't interfere when CSS isn't present.

    2) so that the div I use for hidden and submit inputs doesn't need a class on it.

    Note, the line-break before the close of each span MAY inject unwanted whitespace when CSS is applied. If so, apply a negative margin to the bottom each span equal to the current line-height, should clear that right up.

    The reason for it being one fieldset is it's all one type of data 'contact info' as the legend I added says. It's only if it's an entirely different type of information "reason for contact", "payment info", "shipping address" that it would warrant being a separate fieldset semantically.

    Also, get used to using label and legend - that's how you build a semantic proper accessible form. You do no/should not be throwing in lists, tables, or anything else.

    (See the nimrods abusing definition lists for an example of COMPLETELY wasted code... Hunting season is open on them.)

    -- edit --

    Oh, and styling fieldsets directly can be a bit unpredictable - much like legend. Common practice is to wrap an extra DIV around the fieldset with the class "fieldsetWrapper" to style instead. You WANT the fieldset accessibility on things that don't see the CSS, but you cannot trust it for styling cross-browser. Legend is similarly afflicted so you'll often see a span inside the legend (using the legend as it's CSS hook) and then absolute positioning it in relation to the fieldset and/or div.fieldsetWrapper.

    It's a pain in the ass, but it's the only solution that gives you predictable cross-browser styling AND semantics/accessibility.

  5. #5
    SitePoint Zealot
    Join Date
    May 2010
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    look at www.rbcreations.co.uk/index.php and see what I'm trying to do here.

  6. #6
    SitePoint Zealot
    Join Date
    May 2010
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    what if a client wants what I want , with graphics for the form text, instead of html, how would you do that?

  7. #7
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Ok, I can't even tell what that's supposed to look like - though I'm pretty sure structurally the "valid XHTML" should NOT be the h1, that 90&#37; of what you have applied as images on that page shouldn't be images or should be applied on a per element basis using image replacement....

    I mean you've got multiple H1's that don't even appear to be the starts of sections, lists on non-list elements, spans on what SHOULD be heading tags, nothing resembling actual content, a horde of div's for god only knows what... hordes of DIV and span around elements that I cannot fathom the reasoning behind...

    You are leaving me with more questions about just what it is you are even trying to do - as that is a DISASTER that I can't even figure out what elements are what... Though your use of spans, lists and h1's seems to have you similarly flummoxed.

    Though I CAN see at least one major oopsy that is probably screwing you in IE. You have the XML prolog at the start of the document. That throws IE into quirks-mode, doctype or no. CERTAINLY not helping your issues.

    Now if I could just make sense of what you are even trying to do.

  8. #8
    SitePoint Zealot
    Join Date
    May 2010
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    look , its not a site crytic I want , its not finished , I just working on the form and database etc. If you know what I'm trying to do you can say what you have just said, but you dont , so disaster it isnt. If you looked at the great pyramid of giza when it was being built you would think that was a disaster too. I did say I was learning. When you know what the end result is going to be , you can comment on weather somethings the way its meant to be or not. Look deathshadow, go and prove your a guru to someone else, your not helping me , your just bigging yourself up. Anyone else can help me please?

  9. #9
    SitePoint Zealot
    Join Date
    May 2010
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    just think if we were all as good as you deathshadow, you wouldnt have anyone to look down your nose at, so go easy on us lesser mortals.

  10. #10
    SitePoint Zealot
    Join Date
    May 2010
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    actually you have helped me, but in future, just leave the "YOU STUPID IDIOT" off the end of your sentences.

  11. #11
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    What I assume you are asking is how to replace the 'label' text with those 4 textual images (quick_response_BG.gif) which to me doesn't make a lot of sense - regarding UK Web Accessibility - but it would probably be easier if you used four separate images.

    I think that is what you are after?

  12. #12
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    I think you just misunderstood - and I didn't see the image UNDER your content that showed what you were trying to do. That one image (hidden behind the broken form) told me more than the finished page did.

    I THINK I'm still guessing wildly, but is THIS:

    http://www.cutcodedown.com/for_other.../template.html

    What you are trying to do? It's kind of funny, from all that excess markup you had I thought you were trying to do something much more complex than what you actually have. I'm still guessing as to the input sizes and placements... but for the most part that's what you are after ja?

    I threw out the background image since as xhtmlcoder said, that's a REALLY bad approach to handling things, and just kept the little 'phone' and placed it best I could.

    Side note - If you are just working on the form/database side, you should be working on the markup WITHOUT the styling. It's the best approach to get the semantic proper tags around the elements for the document structure FIRST, before you even think about appearance. proper semantic markup, THEN the layout in CSS, THEN the graphics.

    I'll write up a breakdown of the HTML and CSS for you to explain WHY it works, it's actually pretty simple.

  13. #13
    SitePoint Zealot
    Join Date
    May 2010
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    your form is exactly what I want, but , I dont want to use html text for the lables, I want graphics, I also want accessability and validation, thats what I'm trying to achieve, why ?, I just want more control over design and know clients will too, if posible. I would like to know why not if so. I'm just trying to offer a bit more in the way of bespoke style I supose.

    Thanks for this, I do appreciate it.

  14. #14
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Ok, to break down the HTML

    FORM#quickContact - Our primary hook, really given the style we don't NEED classes or ID's on any of our sub-elements if we take proper care. We don't need a div around it, we don't need a list inside it.

    FIELDSET Because you aren't playing with border or padding on it, we really don't need to play with the fieldset much.

    LEGEND Legend placement can be a royal pain, so most the time you are best off just slapping a span inside it to absolute position it. You can use padding to make room, or an element like a paragraph...

    P which you have perfectly good text to slap into a paragraph tag.

    LABEL Labels can be used to wrap their inputs, which works to our advantage because all we need to do is float these. I noticed in your image they are in the same order as your code, so all that extra wrapping and floating - completely unnecessary! LABEL will do our job!

    LABEL SPAN The span are there for padding or other styling hooks.

    LABEL INPUT - Just the input. Remember that LABEL's for statement should always be required, and point at the ID of the input it is for.

    LABEL BR - When CSS is disabled, make sure they all end up on one line apiece. When developing the markup first and foremost you should be thinking that CSS and presentation doesn't even exist, so what can you do to make it usable without all the eye candy.

    DIV - The nested DIV is just a hook to style the submit. I tend to use a DIV instead of a fieldset for these so it's easy to distinguish from the actual data fields. A submit is not a data field, so why would it be in a 'set' of fields.

    ... and that's really all there is to the markup.

    For the CSS, follow along here:
    http://www.cutcodedown.com/for_others/mrcoda/screen.css

    First I use a CSS reset - it's a good idea to use one given that cross browser all those tags don't tend to start out with the same values. There are larger ones, but they're a bit saggy around the midsection for my tastes... there are smaller ones, but they can cause problems with form elements (which would be REALLY bad here)... this is a nice middle-ground, I've never needed more or had success with less.

    body - NEVER set px fonts on body if it can be avoided, since that makes your &#37;/em elsewhere meaningless. Even if you are forced to use PX on the document by image interactions, constrained widths or unpredictable element behaviors, BODY should remain %. The background-color is just there to make the form elements borders clear.

    h1 - Just a placeholder.

    #quickContact - I dropped the width to 768px so that it's ACTUALLY 800 friendly (780 is not) - though I couldn't tell what you were aiming for off that original as your target. The Margin is just to center it, and the position:relative is to prevent the absolute positioned span inside the legend from going off to never-never land. I regrettably am forced to use PX metric fonts because of the MULTIPLE px metric containers and the image interaction... Which of course I load that little phone image as the background here. I also set the text-transform so you don't have to type it in all upper-case in the markup, which looks kind-of 'meh' when CSS isn't present.

    #quickContact fieldset - I set up some simple float wrapping and pad the left side to make certain our floats don't try to overlap that phone image.

    #quickContact legend span - uses absolute positioning to push that legend to where we want it.

    #quickContact p - the text-align is obvious, less obvious is that the entire P rides up UNDER the absolute positioned legend, hence the extra padding.

    #quickContact label - here's the neat part about floats - they STACK. So if you have a bunch of them the same size in order, they'll stack one atop each-other in nice neat columns. I pad the bottom just to push them apart a bit. Because our input and span will be display:inline and/or inline-block, the text-align:right will push them all over to the right edge of the label... Do our math right, and we get that 8px right 'padding' without actually stating it. This 'unstated' unused 'padding' (that isn't really padding) lets us avoid the 'perfect width' IE layout headaches where all of a sudden it will decide they need to be one column. (IE - boo!)

    #quickContact label span - Setting these to inline-block means we can declare a width on them in standards compliant browsers (in IE7/earlier you can ALWAYS declare a width even when you shouldn't be able to). This width pushes the text over to the left thanks to the text-align... (I'd be half tempted to just let them ride up against the inputs on the right, but it's your layout)

    #quickContact label input - Manually declaring a width on these clears up some oddball cross browser issues... Most still won't actually make them the same size, ESPECIALLY using the markup 'size' property - so we undersize these just a hair to account for that. The font size on inputs does NOT inherit from it's parent so we need to set that to match, and I turn off text-transform (which inherits in some but not all browsers) since the user will likely want to type upper and lower case.

    #quickContact div - just some padding to make it pretty and a text-align to position that submit. Wasn't actually certain where you wanted the submit, so I took a wild guess.

    Hope this helps.

  15. #15
    SitePoint Zealot
    Join Date
    May 2010
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    deathshadow, one minute I like you , one minute I think your an arsey mare, your not my misses are you? Thanks mate, your a bit of a star , you are.

  16. #16
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mrcoda View Post
    your form is exactly what I want, but , I dont want to use html text for the lables, I want graphics, I also want accessability and validation, thats what I'm trying to achieve, why ?, I just want more control over design and know clients will too, if posible. I would like to know why not if so. I'm just trying to offer a bit more in the way of bespoke style I supose.
    In general you will find most developers will take you to task for the mere NOTION of doing this on labels, fieldsets, etc... They'll tell you to suck it up and deal with the default fonts. It's why xhtmlcoder reacted as such, and why I had similar misgivings.

    For the most part I agree with this, but there are ways around the shortcomings... The best technique being "gilder-levin image replacement" - I write up a demo for you that does that on the labels, paragraph and legend.

    But first let's review the problems with using images:

    1) Images instead of text means search engines have nothing to look at - it's bad SEO.

    2) Screen readers aren't going to present it properly either.

    3) It's a waste of bandwidth. Blowing a 1 to 3k of images for single digit BYTES of text isn't all that great an idea.

    4) multiple images means more handshakes, slowing the page load and unnecessarily increasing server load thanks to the extra file requests.

    5) The text does NOT automatically enlarge for large font/120dpi users, win7 144dpi 'ten foot' media center users, or shrink for the handful of handhelds that obey screen but force 72dpi. (and yes, they are out there). That's bad accessibility. There's a REASON the WCAG says to use &#37;/em for all user content. It's also part of why fixed width layouts are a miserable /FAIL/ as well, but that's a subject for another time.

    6) It's a HELL of a lot harder to update later on.

    Now of those, only the last two cannot be 'fixed' by using gilder-levin style replacement... but since I resorted to PX metric fonts ANYWAYS which also don't obey the rules for #5, what's the big difference?

    Gimme a while, I'll toss together a version that uses a gilder-levin_esque method to put those images over the text.

    Another approach would be using something like sIFR to let you force-load the font or one of the new SVG approaches - but those too can be really bloated.

  17. #17
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mrcoda View Post
    deathshadow, one minute I like you , one minute I think your an arsey mare, your not my misses are you? Thanks mate, your a bit of a star , you are.
    WORSE, I'm a backwoods New England Yankee.

  18. #18
    SitePoint Zealot
    Join Date
    May 2010
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    In general you will find most developers will take you to task for the mere NOTION of doing this on labels, fieldsets, etc... They'll tell you to suck it up and deal with the default fonts. It's why xhtmlcoder reacted as such, and why I had similar misgivings.

    For the most part I agree with this, but there are ways around the shortcomings... The best technique being "gilder-levin image replacement" - I write up a demo for you that does that on the labels, paragraph and legend.

    But first let's review the problems with using images:

    1) Images instead of text means search engines have nothing to look at - it's bad SEO.

    2) Screen readers aren't going to present it properly either.

    3) It's a waste of bandwidth. Blowing a 1 to 3k of images for single digit BYTES of text isn't all that great an idea.

    4) multiple images means more handshakes, slowing the page load and unnecessarily increasing server load thanks to the extra file requests.

    5) The text does NOT automatically enlarge for large font/120dpi users, win7 144dpi 'ten foot' media center users, or shrink for the handful of handhelds that obey screen but force 72dpi. (and yes, they are out there). That's bad accessibility. There's a REASON the WCAG says to use &#37;/em for all user content. It's also part of why fixed width layouts are a miserable /FAIL/ as well, but that's a subject for another time.

    Now of those, only the last one cannot be 'fixed' by using gilder-levin style replacement... but since I resorted to PX metric fonts ANYWAYS which also don't obey the rules for #5, what's the big difference?

    Gimme a while, I'll toss together a version that uses a gilder-levin_esque method to put those images over the text.
    look , for a start you use sprites, so theres only one image, as I have on the rollovers at the top of my homepage, and then theres only one handshake, the text is in the 1x1 <span> and doesnt use hidden text and is clearly marked as image replacement text which google is OK with, and the text reader reads the text inside the span. I think were both learning here Death.

  19. #19
    SitePoint Zealot
    Join Date
    May 2010
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    totally correct code does mean less flare in style and more standard looking pages though doesnt it ?
    Digressing a bit now.

  20. #20
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Ok, here it is with image-replacement.

    http://www.cutcodedown.com/for_other.../template.html

    It uses this image, cutting out some unnecessary white-space to try and keep the filesizes under control.

    http://www.cutcodedown.com/for_other...ages/texts.png

    Using this one image means less handshakes than the method most people would use - which would have all of those as separate files. It's harder to update, but is a lot less strain on the server and loads faster.

    The major changes to the markup is the addition of classes to some of the parent wrapping elements so we can slide that background image around, and an empty BOLD tag for use as the image. Normally I would use a span, but we've already used those inside the form - so we need another tag if we don't want to end up adding even MORE classes. Thankfully empty elements are ignored so there is zero impact on semantics or SEO from their presence.

    In the CSS all of the immediate parents wrapping the bold tags need positioning. On the legend, it's already absolute positioned so it doesn't need anything extra, but on the P and the LABELS they all need position:relative added. Thankfully the ones that would need haslayout to fix positioning bugs already have it thanks to the various widths and heights declared.

    All the image sandbags share the same absolute positioning, height and background-image, so we can set those together. Likewise the legend and label ones share position values, so those too can be put together. We then set the widths on those two, and then the positioning and width on the one for the paragraph. Finally we just need to set the background-position off each parent class to slide that image around to show just the parts we want.

    It's a very powerful technique, and is fine for small uses on things like headers from time to time - I am NOT certain I would even TRY using this technique this much on a page.

    It's one of those "just because you CAN do something, doesn't mean it's a good idea" moments.

  21. #21
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mrcoda View Post
    look , for a start you use sprites, so theres only one image, as I have on the rollovers at the top of my homepage, and then theres only one handshake, the text is in the 1x1 <span> and doesnt use hidden text and is clearly marked as image replacement text which google is OK with, and the text reader reads the text inside the span. I think were both learning here Death.
    Actually, read what I said about gilder-levin - that's EXACTLY the solution I'm talking about since I apply "CSS sprites" to them. (I don't consider them true sprites, I prefer the term sliding backgrounds)

    I use image replacement and CSS sprites all the time - I just am not sure I'd be using it on form elements or 'all over the page'. I mean, where do you drawn the line? Next thing you know you'll be using it for actual flow paragraphs.

    As I said, Gilder-levin and CSS sprites addresses all except the last two issues. They don't auto-scale to the system metric, and it's a royal PITA to update.

    For me that's enough reason to restrict their use to a handful of headings and menus.

    I do have another technique that uses javascript to do a per letter overlapping replacement of the text using images - requires no plugins, SVG, VML or other tricks... but I'm not sure I'd ever try using it on a production website. Was more of an experiment to see if it could even be done.

    http://battletech.hopto.org/experime.../template.html

    Wrote that like three or four years ago. Was planning on using to for headings on one site in particular, but that project has been on the back-burner for the better part of two years since that would be for a volunteer project, not a paying one. Was actually going to use a simpler version since the font desired was mono-space mono-caps, so it doesn't need the complex kerning functionality.

  22. #22
    SitePoint Zealot
    Join Date
    May 2010
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    really what I am tryng to do is use more images to add bespoke design, I'm aware of all the downfalls of over use, but I design them very small in FS and just want to take away that standard feel , to give me the selling edge over my competitors. I really need to know the do's and dont's and get a standard way of building my sites. I'm trying to start as I mean to go on and adopt standards that carry through to the future. I try and follow w3c and xhtml strict and google advice. I learnt it all back in the day when anything and everything went and it was very adhoc , looks ok , run with it ! So now I feel there more web standards i'm trying to retrain myself in a pure way if you like. Thats ultimatly my goal, i've learnt so much I dont need, bits of this and that, this time I want to make sure I'm learning it from the ground up. Its there an exact standard way now a days ? You mentioned I should first semantically design the page, without style but I design in illustrator and then build it as its designed not the other way around. I know this is what big design agencies in london want you to do, they wont accept no's for answers when it comes to laying out a multi &#163;1000 deisgn. I supose you mean group the information first and then put the ribbons on the boxes ? HELP , i'm getting scared !!! Do I really know knothing , its feels like it again.

  23. #23
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Sorry for the multi-post multi-replies. Was so busy coding the answers I didn't read later posts.

    Quote Originally Posted by mrcoda View Post
    totally correct code does mean less flare in style and more standard looking pages though doesnt it ?
    You say that like it's a bad thing. In OS design there's something called 'interface guidelines' so that users will have a familiar and pleasant experience. For web development that's what the WCAG is for.

    There's lots of other stuff you can do to make it pretty besides playing around with the fonts. I'm NOT looking forward to CSS3 font support since it's going to mean more and more people bloating out pages with multiple font downloads, possibly even in faces that don't render well on screen or are even legible.

    Arial,helvetica,sans-serif might seem a bit plain, but at least everyone can actually READ IT. More than I can say for a LOT of the fonts people want. "Hey can you do it in Comic Sans?" --- and my response "Oy, can you go schtup yerself?"... Lord help us when people start trying to use script fonts - it's bad enough when people do it as images and you can't figure out what ANY of the button images actually say...

    I'm starting to get the NASTY feeling in the near future I'm going to be using Opera's user.css a LOT more on sites just to force "* { font-family:arial,helvetica,sans-serif !important; }"

    Back in the 90's I was working with print a good deal, and when I first started doing web work like a lot of people in "design" I was obsessed with things like glyphs and the 'perfect font' -- but then around 2003 or so I realized that on the low dot pitch of most screens fancy fonts just get in the way of getting the content to the user.

    ... and that's what websites are for. It's about when I started flipping my design process around 180 degrees to work with my current design order...

    You list SEO on said site as a feature - if you know SEO you know the rule: "Content is King" -- everything else is window dressing. So why would you draw a pretty picture and then try to shoe-horn the content into it? Doesn't make any sense.

    That's how I came up with my approach, I may have already mentioned it.

    Step 1: Write the content that's going on the page. At the very least put together place-holder content (menu items, headings and some lorem-ipsum) so you have something to apply markup to.

    Step 2: Mark up the content in semantic HTML saying what elements are, NOT how they are going to appear. Appearance should have NOTHING to do with the HTML - that's NOT HTML's job. This is the stage at which you get any back-end functionality server-side working - BEFORE you even worry about appearance.

    Step 3: Bend that markup to your will with CSS to make the layout, you may have to add a few simple image sandbags and extra DIV at this stage, but those should NOT be allowed to interfere with what it looks like when CSS is disabled or the tags already written.

    Step 4: ONLY after the above three are complete do you go into your paint program to make the graphics you are going to hang on the layout.

    Even if I was using the styled font as images (which here looks uglier than cleartypes rendering - but I've never been wild about how most image programs render fonts which is why I'll often HAND anti-alias them one pixel at a time) I wouldn't actually be trying to apply them to the layout until the final step...

    It's a bit different a way of handling designing a site, but the end results usually end up better for SEO, better for Accessibility, and generally aren't THAT plain since you can still do a heck of a lot.

    The approach also means it's more likely for users to like it - I am more impressed by pages that load quickly and get me to the information I'm after, and are clear and concise as to what things are, than I am 90% of the 'eye-candy' nonsense many people churn out and call websites. If nothing else, LOOK at the big successes! Google, Amazon, E-Bay, even FaceBook, mySpace and Slashdot - these aren't exactly stunning gems of graphical design. (or even well coded in most cases)... This is because the developers of those sites realize that people visit websites for the CONTENT, not the goofy graphics you hang on them.

    Which is a bitter pill for anyone with artistic leanings to swallow - I should know, it took Dan shoving it down my throat for two years to convert me...

    Not to drag this WAY off topic, but I figure if I outline my approach you can come away with a bit more useful a way of handling things.

    Like the form or even the page as a whole - whenever you add an element ask yourself "is this tag adding meaning" - span and DIV do not, empty tags do not - if they are there as presentational hooks, ask "do I need this tag or can I apply the styling to an existing element"... If you use a heading tag ask "is this a heading for a section of content" - if the answer is no, you shouldn't be using a heading tag on it.

    You'll see page after page where people are nested ten div deep - headings around non-heading elements or WORSE, spans, DIV or P with classes on them doing heading's job, resulting in pages where you'll see hundreds of K of code to deliver maybe 5k of content - that's not going to blow anyones skirt up.

    It's only as complex as you make it, and it is WAY to easy to make things more complex than it needs to be. MOST (but not all) of that can be blamed on the bloated half-assed presentational markup that came out of the browser wars. Now that CSS 2.1 is semi-deployable (there are still parts I won't even TRY to use on a production site)

  24. #24
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    oops, helps to FINISH a post...

    <snip>Now that CSS 2.1 is semi-deployable</snip> we can finally get back to having HTML do it's job of device neutral content saying what things are - and letting CSS do it's job of saying how they should appear. Separation of presentation from content - the cornerstone of modern markup and CSS techniques.

  25. #25
    SitePoint Zealot
    Join Date
    May 2010
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So , its write the content, on paper really first, you know the white thin stuff , that has the blue or black squiggly lines on it ! HAHA ! Then put it in a clear , well structured document, with relevant headings , .............. wait a minute , basically if my english skills are good enough , I can really forget all about web design and just become a writer, true statement surley. Obviously, not all web design skills, but this is what it really all about.
    I supose to sum up its , 1. usefullness 2. Relevance 3. speed , and forget graphics completly untill the end. I THANK YOU FOR THIS HELP BY THE WAY. its really clarifing what I have learnt, you are a Guru.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •