Web standards are rather clear about having or not having a new line on a rendered web page.

Using the Movie tutorial # 1 as an example, the following code generates, as expected,
each text box on a new line:

            <p>
                <label for="Title">Title:</label>
                <%= Html.TextBox("Title") %>
                <%= Html.ValidationMessage("Title", "*") %>
            </p>
            <p>
                <label for="Director">Director:</label>
                <%= Html.TextBox("Director") %>
                <%= Html.ValidationMessage("Director", "*") %>
            </p>
            <p>
                <label for="DateReleased">DateReleased:</label>
                <%= Html.TextBox("DateReleased") %>
                <%= Html.ValidationMessage("DateReleased", "*") %>
            </p>

Contrary to web standards, the version below, without the extra <p>
and </p> tags still takes multiple lines when all of the textboxes
should be rendered on the same line.

            <p>
                <label for="Title">Title:</label>
                <%= Html.TextBox("Title") %>
                <%= Html.ValidationMessage("Title", "*") %>
                <label for="Director">Director:</label>
                <%= Html.TextBox("Director") %>
                <%= Html.ValidationMessage("Director", "*") %>
                <label for="DateReleased">DateReleased:</label>
                <%= Html.TextBox("DateReleased") %>
                <%= Html.ValidationMessage("DateReleased", "*") %>
            </p>

I've looked at the overloads for Html.TextBox and I can not see
how to force these to a single line ~~ AFAIK, HTML has no
"don't <br />" tag.

How do I keep my textboxes on a single line so that my non-trivial forms
are not many miles long?

Example, from http://www.w3schools.com/html/html_forms.asp:

<form>
First name:
<input type="text" name="firstname" />
<br />
Last name:
<input type="text" name="lastname" />
</form>

Note the break to force a new line.

g.

The problem is that the default stylesheet ~/Contents/Site.css defines labels inside Fieldsets to display as block

fieldset label
{
    display: block;
}

forcing the label to a new line.  Try changing it to inline or inline-block and set width;

label is per default a non-block element, and only block elements can have a set size.

The typical trick is this:

label
{
    display: block;
    float: left;
    width: 80px;
}

This will render the text-block at a specific width, and cause all the input to be in the format of

Username: [input field]

And web standards is quite clear about it doesn't matter. The only standard requirement is you do not use inline elements in <form>, but encapsule it in block elements, and paragraphs are splendid for doing that.

Semantics however, point that having a label on the same line is good layout, and I agree with that.

gerrylowry:

Web standards are rather clear about having or not having a new line on a rendered web page.

 Gerry, I couldn't find that anywhere. Care to link it?

I saw plenty (as DeathArt said) about what parents inline elements can have and such, but to my knowledge you would typically wrap your form elements inside a block element that's allowed to have them (e.g. a FieldSet, whcih is what it's intended for semantically).

Paul [paul.vencill] asked to which standards I am referring.

              http://www.w3.org/TR/html401/struct/text.html

9.3 Lines and Paragraphs
9.3.2 Controlling line breaks

A line break is defined to be a carriage return (&#x000D;), a line feed (&#x000A;), or a carriage return/line feed pair.
All line breaks constitute white space.

http://www.w3.org/TR/html401/appendix/notes.html#notes-line-breaks
B.3.1 Line breaks

SGML (see [ISO8879], section 7.6.1) specifies that a line break
immediately following a start tag must be ignored, as must a line break
immediately before an end tag. This applies to all HTML elements without exception.

http://www.w3.org/TR/html401/struct/text.html#whitespace
9.1 White space

The document character set includes a wide variety of white space characters. Many of these are typographic elements used in some applications to produce particular visual spacing effects. In HTML, only the following characters are defined as white space characters:

• ASCII space (&#x0020;)
• ASCII tab (&#x0009;)
• ASCII form feed (&#x000C;)
• Zero-width space (&#x200B;)

Line breaks are also white space characters.

Regards,
Gerry (Lowry)

Please, never set widths or any other dimensions in pixels. It ruins accessibility, as a pixel varies wildly in size.

Ok, but none of that applies to what you're talking about.  Those standards are talking about how the browser should read your HTML, not how your HTML should be written. 

Further, the reponse marked as "answered" is talking about how to use CSS styles to turn things that default as inline into things that render as blocks, but that neither talks to the standards you're quoting here, nor the XHTML requirement to have only block elements as children of the Form.

Not to be persnickity, I'm just confused.

Hello Paul, let me see if I can help you with your confusion,
although this may be a case of the confused leading the confused.

(a) I did not mark TheDeathArt as answer (although I would have); 
    probably the work of a moderator.

(b) The preceding post, matthewD, I just marked also as an answer
     because matthewD's post was sufficient to point me in the correct direction.

(c) My form design will be traditional, where H is heading and T is text:
          HHHH     HHHHHHHHHHHH            HHH
          TTTTT     TTTTTTTTTTTTTTTTTTT        TT     et cetera

Please note:  since 1995, most of my HTML has been hand coded
or generated by programs that I wrote entirely.

So, although css is involved, it's the fundamental standards that
have been violated here.  Please let me explain.

When a developer uses a tool to generate HTML, the developer
has a reasonable and basic expectation that she/he will get from
that tool the same underlying (X)HTML that she/he would have coded
by hand; i.e., there should be no surprises.

When the developer looks at the code and removes extra <p>
and </p> tags, the developer has a reasonable expectation for
the textboxes to come together on a single line.

Now, I'm going to be constructively critical here:
if a code generation wizard is going to generate a form for the developer,
then it has to explicitly give the developer an option and present
that option to the developer in an informative way, something like this:

   [   ]   check to stack all form elements vertically.
  (Note:  stacking is achieved through css using fieldset and display: block)

Remember, not every developer is as advanced as someone like yourself
who has begun his fourth year as a member of the forums.asp.net community.

Paul, I hope that ends your confusion regarding this thread.
If not let me now.  To summarize, it seemed to me that the
wonky behaviour of my text boxes was because of something
going on with the way the page was being generated.  That's
why I wrote that ? Html.TextBox appears to break web standards.

Next time, I'll look at the css first.  Nevertheless, although the affect
has been achieved via css, with respect to the fundamental standards,
I'd declare them as having been broken.  There's an old saying,
a camel is a horse designed by a committee.  Personally,
I strongly believe that correct behaviour within a fieldset must respect
the removal of the  extra <p> and </p> tags as if css were not involved.

Regards,
Gerry (Lowry)

Ok, I think my confusion was that between the several posts, there's conflating of issues, none of which has to do (imo) with a violation of web standards per se; though I'll whole heartedly agree that it might violate common conventions and developer expectations. 

The issue of whether it adds newlines (\n) to the rendered HTML output is separate from whether it adds line breaks (<br />) is separate from what the css block style (display:block or display:inline).  the fact that all discussions were jumbled together and seemingly accepted as answers for each other is what was confusing me.

I dunno, I was probably splitting hairs, but when I see "appears to break web standards" I have a whole different perception of what you mean than if you say, "texboxes have wonky behavior". 

The complaint is really about the default CSS in the project template.

One could argue every aspect of that CSS "violates" expectations. For example, I expect web pages to have a white background, but the default template sets a blue background. Making such arguments is kind of silly, though. Nothing fundamental in the application platform is broken or violates either the letter or the spirit of the standards. If you are unhappy with the CSS default, the recourse is to change the CSS file.

Hello Brad,

I hope you will not mind me challenging you on this. 

I agree that web pages normally do have a white background.
However, I think it's fair to say that most developers who
see a blue background somewhere will automatically
be aware that somewhere there's a colour code at work
(even if they've never heard of css).

Please note also that I never said that the platform per se was broken.

What I am saying, and it's fair, is that unless I have somehow been forewarned,
then deleting extra <p> and </p> tags should behave as expected.

Again, it all comes back to documentation.  Remember, in computer years,
I'm ancient ~~ back in my day (I can say that because I'll be 62 this month)
we produced documentation before we wrote code, and then, in a disciplined
way, we modified the documentation when to do so was an appropriate
action to take.  A developer from the present might aptly name this
way of the ancients as agile documentation*.  Many times I have said
that the ASP.NET MVC team should have had the benefit of a documentation
specialist working with them from day one.  That's not a criticism of the team,
it is a criticism of the management for not committing what I consider to be
a fundamental human resource to the project.

Regards,
Gerry (Lowry)

* even now, as I write each xUnit test (I thank James Newkirk and yourself for xUnit.net),
  I document my xUnit tests and my production code with XML Documentation
  from within the Visual Studio editor.

Sorry, Gerry, I normally agree with you, but on this one it's hard to be sympathetic to your point. 

Now that I finally understand your complaint, I have to say there' *no* onus on the MVC team to document this; it's not something in their framework at all, it's just a CSS rule that they added to a sample template.  It's not forced on you via compiled code like certain output in ASP.net WebForms was; it's just a CSS style that is very common to set however the particular web designer wants to.

And it's certainly *nothing* to do with today's standards or even expectations.  You might've had certain preconceptions and expectations going in, but I don't think that's a prevailing expectation or standard on the web today.  One of the advantages of this MVC framework (and others like Rails and Cake) over the previous generation of web frameworks is that it does a good job of putting the logic where it belongs.  Structure in the View; style in the CSS, app flow in the controllers, etc.  It's one of the things that many of us who were developing under WebForms really complained about, was how much core functionality and controls we had to kind of throw away if we wanted CSS-friendly markup. 

Paul

Hi Paul, no need for you to apologize ~~ that's human nature.
If you and I agreed 100% of the time, we'd probably be clones.

For now, we'll have to agree to disagree, if that's okay with you.

It comes down to management style.  If I were managing the MVC team,
they would have had a documentation specialist as an essential team member
and I would have required them to document a number of things from day one.

With this particular concern, because I've been about user friendliness since
before the term "user friendliness" was coined, you'd have seen in the wizard
essential discovery information.  Remember, lots of developers will come to
ASP.NET MVC from a background where they may never once have even
heard about the existence, let alone the awesome power of css.

gerry

If this were a shrink-wrap software product they were charging for, I'd be more inclined to agree.  As it is, this project is (despite being from Microsoft), essentially a foray into open source, agile development, which implies a certain level of self-discovery and community contribution to the documentation.  The podcasts by Phil Haack, the MVC Tips from Walther and Conery, those are all documentation, and frankly many developers today (CSS-wizards or no) find them a more useful form of documentation than the more formal type that was common in prior years.