Wrapping Page in HTML Form...

**DoubleDee** · May 21, 2012 22:29

Is there any law that says I cannot wrap the larger part of a web page INSIDE an HTML Form??

I am building a page where Users can check their Messages, and currently I just have my Inbox - which is an HTML Table - inside my Form. Doing so allows me to have Submit Buttons and to use the $_POST array in PHP.

Everything is working fine, except that now I would like to add a side bar with the following links: Inbox, Sent, Deleted, etc. (Basically I'm trying to mimic how my Yahoo Mail account looks.)

This side bar - with the above mentioned links - will likely have some "Form-like" properties (e.g. containing a "Check Mail" and "Create PM" buttons), so it would make sense to include it in my existing Form. (Unless I create a second Form, but that seems inefficient.)

So, is what I am describing legit?!

Sincerely,

Debbie

**oddz** · May 21, 2012 22:40

Why do you consider the actions of checking mail and creating a pm a form action? Those would both suffice as standard anchor element considering they navigate to another page? If the only reason your using form elements rather than anchors is to achieve design goals than your wrong from a idealistic view point.

**DoubleDee** · May 23, 2012 11:45

Originally Posted by oddz

Why do you consider the actions of checking mail and creating a pm a form action?

Who said anything about Mail? This is entirely with Private Messages.

Those would both suffice as standard anchor element considering they navigate to another page? If the only reason your using form elements rather than anchors is to achieve design goals than your wrong from a idealistic view point.

Huh?

Having a hyperlink won't allow someone to "Create a PM" or click on a "Go" button that deletes PM's or a series of other actions...

Yes, going from the "Inbox View" to the "Sent View" can be done using hyperlinks back to the same page, but performing actions like "Creating a New PM", "Deleting PM's", "Flagging PM's" cannot be done with hyperlinks.

So my question was, "Is it a sin to wrap all of my Command Buttons on the Page in one Form so I can use them as one working unit?"

Follow me?

Debbie

**oddz** · May 23, 2012 18:05

Originally Posted by DoubleDee

Follow me?

Not really…

Anything that can be done with a button can be achieved with a hyperlink. At least in terms of single actions.

Originally Posted by DoubleDee

Who said anything about Mail? This is entirely with Private Messages.

Same concept within the confines of an application.

**deathshadow60** · May 24, 2012 01:56

Originally Posted by DoubleDee

Having a hyperlink won't allow someone to "Create a PM" or click on a "Go" button that deletes PM's or a series of other actions...

Uhm... you've lost me... why not?!? That's what GET is for; just don't trust get for auth -- that's what sessions and cookies are for.

Though if you want to send data back and forth that has no business being sent as POST or GET, then sure...

that's the real laugh of it

<a href="index.php?action=createPM&to=someUser">PM this user</a>

is really no more or less secure than

<form method="post" action="index.php">
<fieldset>
<input type="hidden" name="to" value="someUser" />
<input type="submit" name="createPM" value="PM this user" />
<fieldset>
</form>

Since authentication that the user should even be allowed to do that shouldn't even be in the markup.

**Stomme poes** · May 24, 2012 14:51

Originally Posted by Debbie

Is there any law that says I cannot wrap the larger part of a web page INSIDE an HTML Form??

This is minor in terms of your users but I'll say it: screen readers with a Forms Mode will ignore everything that's not a form control while inside the form. If you put a whole page inside a form, it's all non-form stuff (except the buttons you want).
Users can switch out of Forms Mode, of course, but also semantically, is the whole page a form? And I'd rather multiple dedicated forms on a single page than multiple actions within a single form myself.

ASP had this nasty, nasty, nasty horrid habit of wrapping whole HTML pages in forms.

<body>
<form runat="server" blah blah>
rest of web page...

later they want a contact form cause it's the contact page...
<form> contact stuff...
</form>

...
</form>
</body>
</html>

That sucked since you can't (and shouldn't) nest forms, and at least older Opera would actually puke on it (8? 9?). Not saying you would nest your forms but, it's what we used to see a lot. Actually I still see it. Anything ASP.net without the newer... what's it called? Razor? Something that generates HTML that's actually... HTML. But not everyone has updated... Funda.nl still uses an awful form. It doesn't have the runat=server thing, but it used to. They're in the process of updating.

**DoubleDee** · May 26, 2012 09:33

Originally Posted by deathshadow60

Uhm... you've lost me... why not?!? That's what GET is for; just don't trust get for auth -- that's what sessions and cookies are for.

Because I am taking the approach of having several "Submit" buttons - each with different names - that determine which actions my PHP takes.

PHP Code:


        if ($_POST['submit']=="Create PM"){

            // Do Create PM stuff...

        }



        if ($_POST['submit']=="Delete PM"){

            // Do Delete PM stuff...

        }



        if ($_POST['submit']=="Go"){

            // Do Go stuff...

        }

Us ing that approach, I have One Form, Several Command Buttons, and I run everything through my Form, which makes sense to me since everything on the page - in this case my "Message Center" - relates to the Form...

And the benefit is I can use the "out-of-the-box" Command Buttons if I don't want to have to tinker with Image Buttons or Background Buttons or JavaScript (which I always avoid).

Debbie

**oddz** · May 26, 2012 10:46

Originally Posted by DoubleDee

And the benefit is I can use the "out-of-the-box" Command Buttons if I don't want to have to tinker with Image Buttons or Background Buttons or JavaScript (which I always avoid).

So it is a visual design decision.First step to the dark side…

Not my site so I could really care less but the way your doing things is not ideal.

**deathshadow60** · May 26, 2012 14:40

While multi-submits are handy in many cases -- it doesn't sound like you actually HAVE a form or formData.... though without seeing the actual page I'm guessing a bit on that; it sounds like you're wrapping a non-form in a form.

**DoubleDee** · May 29, 2012 20:09

Originally Posted by deathshadow60

While multi-submits are handy in many cases -- it doesn't sound like you actually HAVE a form or formData.... though without seeing the actual page I'm guessing a bit on that; it sounds like you're wrapping a non-form in a form.

No, it is definitely a Form because I am using Check-Boxes to select Private Message, am using a Drop-Down to select Actions to take, and I have at least one true "Submit" button while he other one is admittedly a glorified hyperlink...

See a screen-shot of my completed Inbox...

Inbox.png

Debbie

**Stomme poes** · May 30, 2012 00:00

Hi Debbie, I see one form and one link.

The form is the "what does the user want to do with messages in their inbox/sentbox/draftsbox/etc." That's a single form with multiple checkboxes, with the message/subject name as the labels... looks good.

Create PM is, in most other places, a link called "send new mail" or similar. On the left you have "folders" which are really links to navigate to other groups of mails, and "Create PM" is another link which takes users to a different "form". To me, and on most web-based mail applications (you're taking on a lot, if this is to imitate a webmail-like system!), these are simple links because the user is *always* brought to the same blank send-mail template.

You said though that you wanted a script to be involved there when users hit Create PM as well as bringing them to a new page. Why? But assuming you do need this, I would still have that button be a separate form, so your image would be a single web page, with two forms and folder links.

<form action="somescript.php" method="get" id="createpm">
<fieldset>
<legend>Compose a new message</legend>
<input type="submit" value="Create PM">
</fieldset>
</form>
(or, input type="image"... your button looks *really* Appley :)

The fieldset can have border: 0 and the legend can be position: absolute; left: -999em; to hide it.

It is indeed totally legal to have a form that just has a submit button, though I believe most places with such buttons still don't use a form... instead their backend has a unique URL and just does special stuff based on that URL. See, the user isn't sending any special information with that button: everyone hitting it should be getting the same result, yes?

Is there any way the form on the right (dealing with messages in the inbox) would affect the result when the user clicks "Create PM"? That's the *only* way I can imagine that both would have to be in a single form.

**DoubleDee** · May 30, 2012 09:39

Stomme Poes,

As usual, an insightful response!! :tub:

Originally Posted by Stomme poes

Hi Debbie, I see one form and one link.

The form is the "what does the user want to do with messages in their inbox/sentbox/draftsbox/etc." That's a single form with multiple checkboxes, with the message/subject name as the labels...

Okay.

looks good.

Thanks!

Create PM is, in most other places, a link called "send new mail" or similar. On the left you have "folders" which are really links to navigate to other groups of mails, and "Create PM" is another link which takes users to a different "form". To me, and on most web-based mail applications, these are simple links because the user is *always* brought to the same blank send-mail template.

Yes, everyone is taken to the same page which is "send_pm.php"

(you're taking on a lot, if this is to imitate a webmail-like system!)

Yes, it was quite a challenge, but I have it done and working, and it behaves as well as my Yahoo e-mail (and I did it all with PHP and *no* JavaScript!!)

You said though that you wanted a script to be involved there when users hit Create PM as well as bringing them to a new page. Why? But assuming you do need this, I would still have that button be a separate form, so your image would be a single web page, with two forms and folder links.

<form action="somescript.php" method="get" id="createpm">
<fieldset>
<legend>Compose a new message</legend>
<input type="submit" value="Create PM">
</fieldset>
</form>

I thought I was passing something in the Query String like this...

Code:

/account/send_pm.php?user=DoubleDee

...but I ended up using a $_SESSION variable on the back-end to pass over the Username so the "To:" field gets auto-populated.

(or, input type="image"... your button looks *really* Appley

And that is what this all really comes down to...

For this particular page, I like the simple, stream-lined, metallic-looking buttons that HTML gives me "out-of-the-box" when I use a Form.

Since I don't have or know how to use Photoshop, GIMP, etc. I have a handicap when it comes to simple things like creating and working with Buttons.

By including my "Send PM" button in my larger Form, I got a "free button" thrown in!

It is indeed totally legal to have a form that just has a submit button, though I believe most places with such buttons still don't use a form... instead their backend has a unique URL and just does special stuff based on that URL. See, the user isn't sending any special information with that button: everyone hitting it should be getting the same result, yes?

Correct.

Is there any way the form on the right (dealing with messages in the inbox) would affect the result when the user clicks "Create PM"? That's the *only* way I can imagine that both would have to be in a single form.

No, same experience for everyone.

To sum things up...

- You have valid points above, but like I said, for now I like/need the built-in Metallic Button my Form gives me...

- After my site is up and running and I've had some time to "walk away" from everything, I will need to re-evaluate the look and feel or my Buttons, and come up with a better, more unified approach.

- If I could ever fine time to learn some basic Gimp and Inkscape, that would open a whole new world to me as well?!

- I think for now I'll leave thngs as they are, since they work, they look great, and I don't feel like I have made any "Mortal Sins" here, just maybe a slight "Venial Sin"!

Sincerely,

Debbie

**Stomme poes** · May 31, 2012 05:04

Originally Posted by Debbie

...but I ended up using a $_SESSION variable on the back-end to pass over the Username

That sounds like a better road, rather than relying on the client state to set this.

Originally Posted by Debbie

And that is what this all really comes down to...

For this particular page, I like the simple, stream-lined, metallic-looking buttons that HTML gives me "out-of-the-box" when I use a Form.

Originally Posted by Debbie

- You have valid points above, but like I said, for now I like/need the built-in Metallic Button my Form gives me...

So far as I know, only Apple's OS will make that button look that way. Windows, Linux, and various phone OSes will make it look their own way. I guess one of the advantages of using an image (or a bunch of CSS3... I think you could entirely do that button in CSS3) is it will look that way cross-OS. Generally we do this cautiously since there's good reason the OS has control over how form controls look, but... this is an obvious button, so meh.

Since Crusty doesn't like <p>s for text fragments, I'll use a div (because I'm assuming everyone else on that page is a block and you wouldn't want a loose <a> sitting around):

<div><a href="/account/send_pm.php" class="macinbutton">Create PM</a></div>

.macinbutton {
display: inline-block;
padding: 4px 8px;
color: #000;
font: bold 1em/1.2em 'yourfontname', sans-serif;
text-align: center;
text-decoration: none;
background: #fff url(images/gradientbg.png) 0 100% repeat-x;
background-image: -webkit-linear-gradient(top,#ececec, #fff);
background-image: -moz-linear-gradient(top,#ececec, #fff);
background-image: -ms-linear-gradient(top,#ececec, #fff);
background-image: -o-linear-gradient(top,#ececec, #fff);
background-image: linear-gradient(top,#ececec, #fff);
box-shadow: 1px 0 3px inset #fff;
border: 1px solid #000;
border-radius: 25%;
}
I'm not sure on that box-shadow bit, and all of this is out of my head and not tested, but something like this (and of course a hover/focus state)

The background statement is still using a regular gradient as a backup to the CSS3 gradient, which you'd need to make in the GIMP or whatever, but if you didn't have that you could leave it out and just set background-color: #fff;

**deathshadow60** · May 31, 2012 07:39

@Mallory -- I'd not waste the extra tag since there's probably already a perfectly good block level container around it -- and I've never had sibling between inline and block be an issue -- no div, no P, it's fine as a anchor.

I'd suggest avoiding linear-gradients, they take too long and make scrolling painful; instead I'd use "background-size:1px 100%;" with a gradient image of sufficient height to cover the gradient spectrum (which $EC to $FF is $12, or 18 decimal, so 1x18). Funny you did all the variations of linear-gradient, but forgot to -moz and -webkit box-shadow and border-radius

(I know latest of gecko and webkit don't need it, but a lot of sub-versions of said engines aren't up to snuff and still in use).

... and your background-position is redundant/broken. If you're doing repeat-x only, a 100% top means your fallback image would never show up, it's pushed off the bottom of the element. I suspect you meant to say 0% or "top" since you've got #FFF, the end of the gradient, as the bgcolor -- either that or you have the values in your linear-gradients backwards since you're fading dark to light.

Though I'd consider using multiple box-shadows instead of gradients.

Code:

  background:#EEE;
  box-shadow:
    inset 0 0.25em 0.5em #FFF,
    inset 0 -0.25em 0.5em #DDD;

Or something to that effect. BTW, I believe it's incorrect to state "inset" in the middle like you have it -- that or I've just never seen anyone do that.

**Stomme poes** · May 31, 2012 12:28

Originally Posted by crusty

instead I'd use "background-size:1px 100%;" with a gradient image

Actually I would have just had a plain old image, but I have the GIMP to make those in. So I have both image idea and CSS gradients to show both (and if gradients were used then an image may be a wanted fallback), but actually I'm assuming Debbie won't have an image at all. Background-size is another good idea.

And yeah box-shadow all the way around might work better too... I haven't played much with it.

Originally Posted by Crusty

... and your background-position is redundant/broken. If you're doing repeat-x only, a 100% top means your fallback image would never show up, it's pushed off the bottom of the element.

Assuming the background image is a white-to-grey gradient, and the button background is white, I would absolutely have that image tile left-to-right from the bottom (and with repeat-x I can set top/bottom, but not side-to-side... but since I'm using numbers rather than names, I have the 0 in there).

This way, the button can grow in height and the gradient image will stick to the bottom. If the gradient is going to be allowed to stick to the top, then it has to be made backwards (white-to-grey vertical gradient but now with the button's background set to that same grey, so when button grows the grey rather than the white grows).

Since I feel the white is a better contrast I went with the more-white setup.

Originally Posted by Crusty

I suspect you meant to say 0% or "top" since you've got #FFF, the end of the gradient

No... as I re-read what I wrote, I have the CSS gradients backwards... I should have
(top, #fff, #ececec) on all of those. Wupps. Thanks for catching that.

Originally Posted by Crusty

Or something to that effect. BTW, I believe it's incorrect to state "inset" in the middle like you have it -- that or I've just never seen anyone do that.

It might be... I remember last time I saw it, it wasn't the first thing mentioned, or the last; but I stopped using it because last time I did, a Chrome bug made inset + rounded corners a disaster. This bug HAS been fixed, I checked (and it was only Chrome/Skia, not other webkit...) but hadn't had a need for inset since then.

Originally Posted by crusty

Funny you did all the variations of linear-gradient, but forgot to -moz and -webkit box-shadow and border-radius

I no longer have browsers to test those on, because all my versions support border-radius and I thought box-shadow without prefixes, while the gradients were still derp.

I didn't check or test any of that code; I wrote it while slurping coffee and petting the whiney cat and talking to a friend on the phone. I'll mention I'm not one of those females who can multi-task. The fact that most of it isn't riddled with m0aR errors is pure grace of Cthulhu.

User Tag List

Thread: Wrapping Page in HTML Form...

Thread Tools

Display

Wrapping Page in HTML Form...

Bookmarks

Bookmarks

Posting Permissions