scrolling around a PHP page

This site is best viewed in a modern browser with JavaScript enabled.

PeterPan_321

Is it possible in PHP to force the html in the page to scroll to a specific position? I may have shot myself in the foot, taking a long page that had a javascript form at the bottom, and turning it into a PHP file.But now when I do my page validation, any errors I report forces a page load, and the page does not get re-positioned by the browser as HTML pages do. This didn't matter in a shorter form I did where the whole page was the form.

So if I place an html anchor tag down where the actual form starts, like <a name="form">, is there any way within my PHP code to make the browser jump to that position? I know I can jump to it by saying header( 'Location:' . "#form");, but of course that totally reloads the page, clearing my variables.

ginerjm

Without using ajax, any php activity causes a page reload. Your code has to be prepared to handle that by capturing the variable (naturally) and by sending those values back in the event of a needed reload.

Php doesn't control the layout of the page other than to output your html/css as you want it. If you are having a problem with a re-loaded (re-sent) page not looking right, check your css (which has to be re-sent along with the html).

Sup3rkirby

Just to make sure I understand your situation, you have a form (at the very bottom of the page) and upon validation (are you having the form actually submit to PHP for validation?) the page reloads and the user is at the top of this page, however the form (and any errors) are at the bottom of the page, thus creating a user experience issue.

To directly answer your first question, "no". PHP cannot scroll around on a page or preform any dynamic actions to a page. Once the page loads that's it, PHP is done and has nothing to do with what's going on (until you eventually load a PHP-based page on the server).

While you wouldn't be able to use PHP to actually scroll on the page, you could still have PHP print out something such as a simple line of javascript to jump to your form on the page. Though frankly I'd be against using javascript in a simple situation like this. Frankly my initial thought is to use an anchor on the page like you mentioned, but what confuses me is that you said

... but of course that totally reloads the page, clearing my variables.

I would almost imagine your page would be reloading itself regardless if PHP is involved to begin with. If you were using javascript validation the page of course wouldn't need to reload, but it also wouldn't end up at the top of the page either. So if you are using PHP to validate the page it's going to have to reload purely by design and so I can't see how it causes an issue. Since I haven't experienced this scenario I'll have to speculate, but perhaps you mean that when reloading the page with a hash anchor it clears the data that was entered into the form (versus remembering the form by default). Which I can only see being possible because the URL has technically changed (and as the browser controls form memory, it may clear forms if any part of the URL changes?). Anyway, if that's the case it may benefit you to actually store the form fields in the $_SESSION. This will allow you to populate the fields yourself on the page and also keep up with the form data in general (of course remember to never store certain types of data like credit cards this way!).

PeterPan_321

Solved it! If anyone has a similar problem, here's what to do. In my case it was a page with a mail form near the bottom, so when the form was POSTED, I wanted the updated page to scroll back to where the form was. So, down where the form part of the page is, I place an anchor tag...

next, in my PHP file, I now have a variable called formAnchor, set to empty...

$formAnchorPos = "";

Now if the form has been posted, this part of the PHP code that detects the POST (to process the form) will be activated, and there I'll set my variable to "form", like this...

if ($_SERVER["REQUEST_METHOD"] == "POST")
{
$formAnchorPos = "form";
// rest of form processing follows.

Finally, in the BODY tag (WHICH MUST APPEAR AFTER THE ABOVE PHP CODE, we add this...

Normally, before the form has been posted, the formAnchorPos variable is empty. So in that case, the re-position is just to "#", which is just the current page position anyway. But after the POST, the javascript will scroll to the position of the "#form" anchor. PRESTO!!!! :-)

Glad I found this! Because I can use this method to reposition the scroll position to other areas, or even do a re-direct!

Starting to LIKE PHP!!! :-)

deathshadow

Here's a better trick -- simpler and needs no JS.

Put the 'check' ID where you want it to scroll to. When the page reloads it will scroll to that point... sending a hash that doesn't have a matching name or ID does nothing, so no harm, no foul.

Oh, and don't use <a name="whatever"></a> anymore, this isn't 1997. An ID has the same functionality. Just place id="check" on whatever element you want it to scroll to in the PHP. (one of the big reasons to use ID's on a page for major subsections! #content, #mainMenu, #top... )

PeterPan_321

So can my form have two actions? Currently my form tag looks like this...

But anyway... atking out my javascript and adding the #check id to a nearby element, and then changing the form tag to look look this...

Doesn't work. Page does reload, but always to the top.

deathshadow

You don't need two actions, that's not what I'm saying.

<form
  method="post"
  action="<?= htmlspecialchars($_SERVER["PHP_SELF"]) ?>#check"
  id="contactform"

BTW, unless you are doing nyetscape 4 style javascript, there is little legitimate reason to have a NAME on your form... an ID on the other hand might at least be nice for targeting it with CSS.

I would probably also avoid using PHP_SELF, it's not entirely reliable and some people think there are security issues with it. Decent article on that here:
http://www.cyberscorpion.com/2012-03/why-php_self-should-be-avoided-when-creating-website-links/

Oh, and notice the shorthand <?= ?> it's the same as <?php echo ?> and as of PHP 5.4 is always enabled. It used to not be enabled because the "shorttag" <? would conflict with the doctype -- they made the parser smarter so <?= isn't mis-recognized by the parser.

Though really I prefer to echo ALL my markup than constantly open and close PHP tags -- I had my way <?php, <?, <?= and ?> would be stricken from PHP. It would be easier on the parser and more consistent with other languages. I say the same thing about all the other 'doc' methods too, like heredoc, nowdoc, etc... get rid of it. If making an interpreted language you pick one way of doing things, not twenty.

PeterPan_321

@deathshaddow...

Ah Yes! Thanks for that. And even better...

<form method="post" action="<?= htmlspecialchars($_SERVER["PHP_SELF"]) . $formAnchorPos ?>" id="contactform" >

where $formAnchorPos is initially defined as "#form", and later after a successful email is finally sent, and an email confirmaion message is displayed, change it to "top" (another anchor) or just an empty string, along with all my other vars. That way if some visitor is tempted to hit my submit button repeatedly, at least it takes them back to page top. away from the form.

PeterPan_321

YAY!!! I've got it. Here's my final form. Its an advertisement for my guitar lessons. If you scroll down you'll get to the form. I'm not doing a lot of validation this time... the user might want to send me a phone number instead of an email. But if there's no name or message given and you submit, it will show the errors. Or if you got it all right (feel free to send me an email... no big deal), text will display indicating the message was sent. in both cased, you'll notice the URL changed with an appended "#form", an anchor tag, to ensure the page loads to that point. And since that "#form" anchor is specified through a variable, another click on the SUBMIT button will cause the page to load at the top, away from the form, as if you started from scratch. That's just to avoid visitors that are tempted to hit the SUBMIT button multiple times.

http://pixyland.org/guitarLessons.php

Anyway, comments or reports stupid behavior on some browsers welcome. I have to go try it on my android tablet now. I don't have a smart phone yet.

Gravy

If I'm submitting to the same page I submitted the request from, I would simply leave the action empty. In this scenario the browser will submit to the current URL.

If I wanted to have it jump to a particular position on the page, I'd just add the # without and file.

So If I was submitting from "http://www.mysite.com/page.php", the destination URLs respectively would be:

http://www.mysite.com/page.php

http://www.mysite.com/page.php#wheretogo

deathshadow

Well, it might help if you had built the form properly -- and weren't using tables for layout... or deprecated attributes like ALIGN on DIV... BGCOLOR on TABLE... anchor with name on it for nothing... non-breaking spaces for christmas knows what reason... Comment placements that could trip rendering bugs (yes, I said COMMENTS, yes... it sounds crazy, did I mention it's an IE thing?)

That whole page is a laundry list of outdated 1990's style markup. Pretty much EVERY table on that page belongs in the trash, some semantic markup wouldn't hurt.

For example, where you have:

<div align="center" >

<a id="form"></a>

<div class = "strong">
</div>

<table bgcolor="#66ff66" border="1" width="90%" ><tr>
<td  bgcolor="#66ff66" style ="text-align:right;"  >

<p><span class="error">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;* required fields.</span></p>
<form id="contactform" method="post" action="/guitarLessons.php#form"> 
Name: <span class="error">* Name is required</span>&nbsp;
   <input type="text" name="name" value=""><br>
Email:&nbsp</span>&nbsp;
	<input type="text" name="email" value=""><br>
Where are you:&nbsp; <input type="text" name="location" value=""><br>
Phone:&nbsp;<input type="text" name="phone" value=""><br><br>
<div align="center"> ---- <span class="error">*</span> Message ---- <span class="error">Please fill in the message field</span><br>
<textarea name="comments" wrap="physical" cols="65" rows="10"  ></textarea>



<br><br>
<!-- forget this for now
File Attachment:&nbsp;<input type="file" name="file_attachment">
-->
</div>

<br> <input name="submit" type="submit" value="Submit">

</form> 




</td</tr></table> <!-- mail form table -->

That should probably JUST be:

<form 
	id="contactForm"
	method="post"
	action="/guitarLessons.php#contactForm"

<div class="error">* required fields.</div>

<fieldset>

	<label for="contactName">Name: <b>*</b></label>
	<input type="text" name="name" id="contactName" />
	<br />

	<label for="contactEmail">Email:</label>
	<input type="text" name="email" id="contactEmail" />
	<br />

	<label for="contactLocation">Where are you:</label>
	<input type="text" name="location" id="contactLocation" />
	<br />

	<label for="contactForm">Phone:</label>
	<input type="text" name="phone" id="contactForm" />
	<br />

	<label for="contactMessage">Message: <b>*</b></label>
	<textarea 
		name="comments"
		id="contactMessage"
		cols="65" rows="10"
	></textarea>
	<br />

</fieldset>

<div id="submitsAndHiddens">
	<input type="submit" class="submit" value="Submit">
</div>

</form>

EVERYTHING else you are doing there belonging in the CSS... without tables. From an accessibility standpoint user INPUT/SELECT/TEXTAREA belong in a fieldset, and should ALWAYS have LABEL tags, not text just slapped in there any old way. Likewise if you have to resort to non-breaking spaces you are doing something WRONG, and the same can be said of tables that only have one TD or aren't around actual tabular data.

Also, don't show that to a "designer" -- they'll see the comic sans and start ridiculing you for it. (Personally I never really got their objection to it, particularly with their now jonesing for even worse webfonts on everything).

Of course, it looks like you're working in Serif Webplus -- which is incapable of writing markup for you properly. Long term that's really going to tie your hands behind your back worse than FrontPage, Web Expression or Dreamweaver would. (and I don't advocate the use of any of those either). You REALLY should consider tossing that away too since it's saddled you with a H2 around non-heading content with no H1 preceding it, tables for layout...

Silly question -- just how old is this site?

PeterPan_321

deathshadow;1335987 wrote:
Well, it might help if you had built the form properly -- and weren't using tables for layout... or deprecated attributes like ALIGN on DIV... BGCOLOR on TABLE... anchor with name on it for nothing... non-breaking spaces for christmas knows what reason... Comment placements that could trip rendering bugs (yes, I said COMMENTS, yes... it sounds crazy, did I mention it's an IE thing?)

That whole page is a laundry list of outdated 1990's style markup. Pretty much EVERY table on that page belongs in the trash, some semantic markup wouldn't hurt.

<snip>

Silly question -- just how old is this site?

@deathshaddow

OK, well I will offer thanks, because I did ask for comments. But I will offer some of my own too. First, a few minor points, I'm not working in WebPlus. Webplus I d/ls and bought because it was $15, and would have asked for a refund had it been worth my time to bother for $15. (LOL). I don't like it one bit, and about the only "webplus" thing on that page was a background I had created and kept. Also, the file is only 1/2 week old. But if you mean the domain site itself, whose main area is actually http://peterpan.pixyland.org, that I first published in 2000, and in passing I'll say that it did win a webby in 2001.

But this brings me to an important philosophical point which probably could fill many threads. I wear many hats... electronic engineering, product design, software (started back with assembler on an ATARI!), musician, carpentry, modeling, costuming (hence the "hats" reference), and several other endeavors which all have something in common. That is, there is always a "newer" way of doing things. But newer is not always better, and since "newer" always requires time to learn and implement, there has to be a better argument for "newer" than the teasing that you might get for your choices. I DO appreciate the lessons and info you're offering me, but I don't buy the multiple arguments about changing things because the code style is dated.

There are many examples of things I do in web pages that in retrospect I could have done better. But by the same token there are many things I've endured critique about which I wouldn't change, because they start and end of the argument is that it is a newer methodology. The bottom line, at least IMHO, is content and accessibility.

For example, you suggested several coding shortcuts I could use unless I'm coding for an early NETSCAPE browser. I'd counter that as everyone's bandwidth has come a long way even in rural USA, and there's no reason to stop using conventions that make your page backward compatible to save a few bytes. And tables vs CSS? Yes i use both. But if my pages display properly on the browsers of today as well as 10 years back, or at least are usable 10 years back, that's not a BAD thing.

I do appreciate the power of CSS, and I like the way HTML 5 is going. But as long as I'm typically hand coding I'll likely always use a mixed bag of methods, both because its what I'm used to and because it works. And I have to elaborate on that last point. I've done things with Tables that you can do better in CSS, but fail to a point of being unbelievable on many versions of browsers that people still use. And with MS pretty much abandoning XP users with no direct upgrade path and hundreds of non backward compatible OS changes, there are going to be a lot of home users on IE 8, 7, and maybe even 6 for a long time. My point? Many is the time I'll cobble together a page using what I know to be the most up to date CSS methodology, only to find it doesn't work properly in several browsers. Tables are tied and true, and where there are bugs, I know most of them. I have no issue migrating more to divs with positioning controlled by CSS, but I do have a problem doing so just to avoid someone's teasing. judging by the many pages I've seen put out by modern CSS systems like Wordpress and Joomla that don't display right (even on some newer browsers), it tells me again that newer is not always better. The developers can blame the broswers all day, and some even resort to chiding the user to come into modern times and get a new browser.

I starts to border on arrogance after a while. I've also been criticized for using GIFs instead of PNGs, despite the fact that PNG transparencies don't work on all browsers, and can't do simple animations. I've even been criticized for still using HTML symbols like @quot; instead of the UTF equivalents. This despite the fact that some systems will render an annoying display where every apostrophe or quote is displayed as a sting of weird characters. So I continue to create pages that can be represented in 7-bit ASCII. And really... <br><br> means something is wrong? Everybody does that. They do because some browser will do the "right" thing and others won't, and its a simple way to ensure better layout in the majority of cases.

Again, if you think I'm opposed to learning new things you have me all wrong. Just this week I learned some PHP and turned out two working forms for two of my sites. So being new to PHP, my main reason for asking opinions was to find out if something didn't display right or failed to function correctly. So far, despite not using all the latest greatest formatting, they seem to look the way I'd like them too (on multiple new and old browsers), and most important WORK. (well i did have to tweak my <textarea> a little to look right on my android tablet, but that's about it).

Bottom line... content, layout, and functionality first. Not opposed to newer methods, just want to see better arguments for newer methods than to say my way is archaic. My guitar of choice is a my Gibson 1972 Les Paul. I bought it in 1972! many newer guitars have a lot of very cool new features, and many I I do like. But at least in the music world, what matters is what you play and the quality of your music and sound... not how old fashioned the electronics or style may be. See my point?

PeterPan_321

Gravy;1335985 wrote:
If I'm submitting to the same page I submitted the request from, I would simply leave the action empty. In this scenario the browser will submit to the current URL.

<form method="post" action="">

If I wanted to have it jump to a particular position on the page, I'd just add the # without and file.

<form method="post" action="#wheretogo">

So If I was submitting from "http://www.mysite.com/page.php", the destination URLs respectively would be:

http://www.mysite.com/page.php

http://www.mysite.com/page.php#wheretogo

the reason i did this...

action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]) . $formAnchorPos; ?>"

where "$formAnchorPos" might be "#wheretogo" or might be empty depending on the program activity, is because I'd read that there are security issues that were best dealt with referencing ($_SERVER["PHP_SELF"]), and then only after passing it through a function to remove the ind of suspicious characters that could be a hacker. I'm kind of new to PHP, so when I see warnings like that (and the example code works) I tend to go with it. So even if it works, are you saying its just as safe and effective to leave the action empty?

Gravy

PeterPan_321;1336067 wrote:
the reason i did this...

action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]) . $formAnchorPos; ?>"

where "$formAnchorPos" might be "#wheretogo" or might be empty depending on the program activity, is because I'd read that there are security issues that were best dealt with referencing ($_SERVER["PHP_SELF"]), and then only after passing it through a function to remove the ind of suspicious characters that could be a hacker. I'm kind of new to PHP, so when I see warnings like that (and the example code works) I tend to go with it. So even if it works, are you saying its just as safe and effective to leave the action empty?

Yes, it's safe and effective to leave it empty. I can't imagine and possible security risk by doing this. It just simply allows the browser to make the decision, which has always been to post to the source file.

I imagine the security risk the person was talking about was using "$_SERVER["PHP_SELF"]" without "htmlspecialchars()", which means they could put some of their own HTML, CSS or JS on the page. They probably never thought of just leaving the action blank and went the long way to solve a problem that never really existed.

Sadly the Internet is full of many people who think they are experts but often give bad advice. I would much rather leave it blank than add extra unneeded PHP code any day.

if the address never changes, hard coding the url is a simple option too action="this.php", however I'd just leave it blank.

deathshadow

I'm going to answer this out-of-order, because some stuff at the top, middle and bottom can be answered all at once.

PeterPan_321;1336061 wrote:
Not opposed to newer methods, just want to see better arguments for newer methods than to say my way is archaic.

I agree that newer isn't always better -- just look at the train wreck of "let's take a trip with Mr. Peabody" known as HTML 5. BUT...

It's a laugh some of this being called "newer" since what I'm advocating -- semantic markup, use of the proper tags for what they are for, and so forth are now over a decade and a half old! Much less that LABEL and FIELDSET were introduced with HTML 4, which is when FORM was added -- Which is to say early 1998...

That's not newer, that's following the rules of language; something a lot of people creating tutorials, books, videos and even professional educators never seemed to learn in the first place.

You want better arguments as to why... that's easy. ACTUALLY using the elements for means MORE than just "what it looks like on the screen in front of you" - not everyone has the same size screen, OS, device capabilities, screen sizes - or are even looking at your page with a screen! That's what semantic markup is about. Search engines don't give a flying purple fish what your page looks like -- screen readers, braille readers, printers, etc don't care. Then there's the new trend of responsive design - using semantic markup means easier hooks for doing things without 'throwing classes at everything'.

Bottom line on that - If you can't be bothered to use the rules of writing HTML when writing HTML, why are you using HTML?

At least though it's not as bad or risky in HMTL as it is in say PHP, where decade out of date practices can leave security holes the size of the USS IOWA.

PeterPan_321;1336061 wrote:
I starts to border on arrogance after a while.

You're probably getting that feeling from the fact that for people who do this stuff all the time, seeing the same mistakes over and over again year after year just gets really frustrating -- particularly when it's NOT the fault of people like you, but the people and sources you learned from who never did it right in the first place either. Frustration can make you say all sorts of crazy ****.

Naturally, being told "you're doing it all wrong, and been doing so for a decade and a half" can be equally frustrating.

Some of the things you mentioned being taken to task for ... are... well... I have a different perspective on.

PeterPan_321;1336061 wrote:
I've also been criticized for using GIFs instead of PNGs, despite the fact that PNG transparencies don't work on all browsers, and can't do simple animations.

The transparency thing is a lie... kind of.

Palette transparencies -- they type of transparency GIF does -- works JUST FINE in IE using PNG all the way back to IE 4 in 1996. PNG also compresses (with a good compressor, Photoshop isn't) smaller image files between 17 and 256 colors, so in terms of file size PNG usually wins out over GIF. PNG also wins in that it can do true-color images, and unlike JPEG is lossless.

Meaning the only thing left for GIF is images that can be done in 16 or less colors, or where you want an animation -- and webm is starting to put a real dent in GIF's since it's smaller, true-color, and has finer control over frame rate.

If you can do it with a GIF, you can do it with a PNG, all the way back to IE 4. ALPHA transparency, where you have multiple levels of translucency is the one that didn't work right until IE7.

PeterPan_321;1336061 wrote:
I've even been criticized for still using HTML symbols like @quot; instead of the UTF equivalents.

XML-tards love to pull that stunt, but news flash for them, HTML isn't XML, neither is XHTML 1.0 -- the named symbols are SAFER than UTF, because then it doesn't matter what encoding the document ends up.

Though I would probably never use &quote; (which is what I assume you meant) as I'd just put the quote in the markup -- not a fan of styled quotes or wasting time making entities of them... but for things like © or • -- RIGHT THERE WITH YOU!

PeterPan_321;1336061 wrote:
So I continue to create pages that can be represented in 7-bit ASCII.

As do I in most cases, so long as all you're working with is English, that's ALL you need.

Hell, officially by the spec the only valid characters in a CSS file is ASCII7... which makes the use of @charset kind of a head scratcher! :/

It's actually something I suggest to people starting out -- avoid stepping outside ASCII7 until you have a firm grasp of what character sets are, how they work, and what a pain in the backside they can be.

PeterPan_321;1336061 wrote:
And really... <br><br> means something is wrong? Everybody does that.

The only thing wrong with double-breaks is if the text is clearly grammatically a paragraph of flow text. Search engines, screen readers, etc, etc can leverage a paragraph tag to help deliver the content -- it's saying what the text IS, NOT what it looks like. Breaks are for splitting text inside a semantic element, and really provide no 'meaning' to the document structure.

REALLY bad with breaks though is just slapping a bunch of them back to back inside a page instead of using margins or padding... not so much for semantics, but from an efficiency and speed standpoint. Markup isn't cached, CSS in an external stylesheet is.

PeterPan_321;1336061 wrote:
They do because some browser will do the "right" thing and others won't, and its a simple way to ensure better layout in the majority of cases.

Except it isn't... because you actually have less control thanks to more markup; a bunch of breaks might look fine on one media target, but not another. It's why what things look like has never had any business in the markup no matter what HTML 3.2 became thanks to Microsoft and Netscape's repeated one-upmanship from when they both licensed from Mosaic and started piling on their own proprietary garbage.

PeterPan_321;1336061 wrote:
but I don't buy the multiple arguments about changing things because the code style is dated.

It's not just that it's dated, it's that it's WRONG and BEEN WRONG as long as people have been doing it.

Take that form -- you have clear labels, use a LABEL tag. That's what the HTML specification has said as long as there has been a FORM tag... WHY? So that user agents can leverage that relationship to make the page easier to use -- from clearly identifying that said text is the label for the INPUT in screen readers, to letting you click on the label to focus the element giving a larger target area for people using something other than a mouse (like a touch interface).

BY THE RULES none of the inline-level tags can be direct children of FORM, you need a DIV or FIELDSET -- and FIELDSET is preferred for that to identify that the inputs contained within are ones the user can interact with.

There is more to a website than what you happen to see on the screen in front of you.

You make the comparison to a '72 Gibson, when a more apt comparison would be a '69 Kay bought out of the Sears Christmas Catalogue in the kids section. (the guitar I had when I was five, before I moved over to woodwinds)

PeterPan_321;1336061 wrote:
I wear many hats... electronic engineering, product design, software (started back with assembler on an ATARI!), musician, carpentry, modeling, costuming (hence the "hats" reference), and several other endeavors which all have something in common. That is, there is always a "newer" way of doing things. But newer is not always better

Similar here, musician (Sax, Flute, EWI), custom bicycle builder, electronic design, carving, painting, writing -- and you're right, there is always something new to learn, the trick is to learn what's actually BETTER... more so, when things AREN'T new, they're just new to you.

PeterPan_321;1336061 wrote:
I have no issue migrating more to divs with positioning controlled by CSS, but I do have a problem doing so just to avoid someone's teasing.

Please don't think I'm teasing -- most of what I say I do in earnest; There are reasons for doing this and I outlined most of them above.

PeterPan_321;1336061 wrote:
judging by the many pages I've seen put out by modern CSS systems like Wordpress and Joomla that don't display right (even on some newer browsers), it tells me again that newer is not always better.

Well, get a load of this. I don't consider those to be 'newer' in terms of how they put things together; Turdpress in particular raises my ire as it is some of the most poorly coded garbage I've ever come across. Using those as examples of "modern CSS" is like using a 1984 Yugo GV or Reliant Robin as an example of automotive excellence.

PeterPan_321;1336061 wrote:
But at least in the music world, what matters is what you play and the quality of your music and sound... not how old fashioned the electronics or style may be. See my point?

Which is not exactly a great parallel, well, unless you only want your music to be heard live, without amplification, in a small venue that seats maybe 20... with everyone being deaf in one ear; as opposed to a stadium performance with an accompanying live album.

... and that's really the difference between using HTML properly and just vomiting it up any old way completely ignoring the structural rules of the language and what it's tags actually mean and are for!

PeterPan_321

deathshadow;1336089 wrote:
I'm going to answer this out-of-order, because some stuff at the top, middle and bottom can be answered all at once.

I appreciate your argument, but let me hasten to add something to my premise about newer not always being better. Maybe even better than my "guitar analogy", if a tree falls in the woods and no one hears it, does it make a sound". Well of course it does, but that starts the whole line of questioning about whether it matters, and if so to who (or whom... if your picky)

I will absolutely grant you that anything you learn to do the right way (and that assumes everyone agrees on the "right way") will make things much easier. But if the point of language is to "express" rather than "impress", so too is the point of a website to display and function well in the maximum number of cases. A coded page structure that works to the composers satisfaction in a sufficient number of cases is never "wrong", even if the code looked like HELL, in the same sense if it works well, "It doesn't matter" is a phrase aptly applied to both that code and the tree that fell somewhere in the Amazon rainforest today.

Don't get me wrong... I find VERY valuable your tips like using of "label" tags instead of plain text, because as you pointed out, some browsers can make use of those tags for association with the field. I never knew that, and in the future will go that route. But taking an argument like CSS positioning of DIVs being better than tables for layout? In all cases? I've found that it does have lots of advantages, for sure. But I'm also saying those advantages are often trumped by the way some browser and browser versions interpret CSS positioning differently. Can you make adjustments to accommodate all the browsers? Maybe. But if you have to do all that, never knowing if you're leaving an stone unturned somewhere, maybe in some cases a few old fashioned table structures can save you some time.

And TIME really is the important thing in the context of this discussion. In engineering, programing, model making, music composition... carpentry... or any endeavor the conscientious designer has a constant mental challenge balancing the meaning of the word "done". When is something done? When its perfect or when it works? When it works most of the time or all of the time? I would assert that in all cases, the 80/20 rule dominates. That is, you'll get 80% of what you need done with 20% effort, but that last 20% requires 80% more effort... effort and time. And I'd further argue that as project approaches "perfection", the time to reach that goal becomes infinity. And since there isn't infinite time, we have to balance. I will shoot for 99.9% in the code of an embedded processor in a product that is going to be a nightmare to recall and fix, if the customer finds bugs. But for a web form, where changes can be easily made anytime with a simple FTP transfer, I'll probably get that 80% mark 9well maybe 90%) and leave it at that.

This probably sounds like a lot of psycho babble, but I do hope you see my point. A website, for all its interesting methodologies, is almost never an end product. We post blogs to express our opinions, not spotlight our code structure. We create websites to advertise products and convey ideas, and seldom to advertise our coding skills. So for most of us... especially weekend warriors with dreams, the limited amount of time for each task combined with the daunting number of tasks often means we have to budget our time. In my case, at least for websites, that means that "functional"="done". There can always be "done better", and certainly I am always interested in learning to do things better. (I've been playing that guitar for 45 years and I'm STILL learning better playing techniques!). But time is a major limitation (at least for me). This is why I have no choice but to really consider carefully when 'wrong" might really mean "could be better" and in some cases "might not matter". There is no choice but to discern the difference. Time is precious! :-)

Bottom line, please don't hold it against me (or others in my shoes) when it seems I'm slow to change something that 'works". Its not that I'm not interested in potentially better alternatives. There are just so many other things demanding my time, and its invariably the next piece of added functionality that trumps things like the decision to use a table or a DIV :-).