A substitue of break but with CSS for a span next to field in form

Hi,

I’m designing a contact form. I’d like to know, what you’d suggest here so I don’t use a break but instead something in the CSS. My tutor says that br is style, so an equivalent should be found in the CSS not in the HTML that’s for the structure. I think that’s debatable, as h1, p, etc are also formatting style.

The span in empty because it’s the space for hints and red inline errors.


<label for="name">First Name <em>*</em></label>
                <input id="name" required>
                <span id = "namehint" class="hint"></span><br>


Here’s the demo: http://codepen.io/CarolinaSawney/pen/lIHBy

You are right pal, there is no need for the “br” element to set the form like that. Just remove it and then replace “130px” for a percentaje in the width property for the labels. And the same for inputs, selects and textareas.

Take into account also paddings and margins.

By the way, “br” elements are not style, but structural elements, the same as “h1”, “p”, etc.

(http://www.sitepoint.com/web-foundations/structural-elements/)

Hola,

It’s the span that I need to grab, where the inline red errors go. If take out the text that’s there as a hint, the surname label and input area go up, on the right, next to the first. At the moment break is preventing that.

I updated the demo to show that. If you delete the content of the span element next to the name. See what happens.

Without changing any CSS, you can put each row in a <div> and each row will be a distinct block.


<h1>Contact Form</h1>
<!-- Turn HTML5 validation off to test Javascript data validation -->
<form id="contactform" action="#" method="post" novalidate>
    <p><i>Please complete the form. Mandatory fields are marked with a </i><em>*</em></p>
    <!-- Patient's name -->
    <fieldset>
        <legend>Patient's Name</legend>
        <div>
            <label for="name">First Name <em>*</em></label>
            <input id="name" required>
            <span id = "nameHint" class="errorMessage">This is where the error messages go</span>
        </div>
        <div>
            <label for="surname">Last Name <em>*</em></label>
            <input id="surname" required>
            <p><span id = "surnameHint" class="errorMessage"></span></p>
        </div>
        <div>
            <label for="title">Title <em>*</em></label>
            <select id="title"  required>
                <option value="">Please select</option>
                <option value="mr">Mr.</option>
                <option value="ms">Ms.</option>
                <option value="mrs">Mrs.</option>
                <option value="miss">Miss.</option>
                <option value="master">Master.</option>
            </select>
            <span id = "titleHint" class="errorMessage"></span>
        </div>
    </fieldset>
    <!-- Contact details -->
    <fieldset>
        <legend>Contact Details</legend>  
        <div>
            <label for="telephone">Telephone</label>
            <input id="telephone">
            <span id = "telephoneHing" class="errorMessage"></span>
        </div>
        <div>
            <label for="email">Email <em>*</em></label>
            <input id="email" type="email" required>
            <span id = "emailHint" class="errorMessage"></span>
        </div>
    </fieldset>
    <!-- Health Number -->
    <fieldset>
        <legend>Health Information</legend>
        <div>
            <label for="health-number">Health Authority Number <em>*</em></label>
            <input id="health-number" type="alphanumeric" min="0" max="120" step="0.1" required>
            <span id = "healthNumberHint" class="hint"></span>
        </div>
    </fieldset>
    <p><input type="submit" value="Submit" id=submit></p>
</form>

I see. Haven’t considered the error message.

Anyway, the solution still works.

Please change the fixed width for a percentage-based one in labels, inputs and textareas.

Then modify the nameHint selector, changing its position property to relative, adding margin and padding and any other properties and values you think fit.

I have modified your styling and works perfectly without the “br” elements or any other one, including even a background for the error message.

Please, test the code below:


body {
  font-family: Georgia, serif;
  max-width: 800px;
  padding: 10px 30px;
  background: #DFDFCE; 
  color: #353530;  
}

h1 {
  margin-bottom: 0px;
  color: #F8584A;
  font-size: 28px;
  font-weight: normal;
  line-height: 1.2;
  color: #EE3A43;
  margin: 5px 0px 2px;
  font-weight: normal; 

}

p {
  margin-top: 0px;
}

fieldset {
  margin-bottom: 20px;
  padding: 10px;
}

legend {
  padding: 0px 3px;
  font-weight: bold;
  font-variant: small-caps;
  font-family: Arial,Helvetica,sans-serif;
  color: #353530;
  margin-bottom: 0.5em;
  font-variant: small-caps;
  font-size: 18px;
  line-height: 30px;
  font-weight: normal;
  margin-top: 0px;
}

label {
  width: 30%;
  display: inline-block;
  vertical-align: top;
  margin: 6px;
}  

em {
  font-weight: bold;
  font-style: normal;
  color: #f00;
}

input:focus {
  background: #eaeaea;
}

input, textarea {
  width: 40%;
  margin-right: 27px; 
  border: 1px solid #F2F2EB;
}

textarea {
  height: 60px;
}

select {
  width: 200px;
}

input[type=checkbox] {
  width: 10px;
}

input[type=submit] {
  width: 150px;
  padding: 10px;
  background: none repeat scroll 0% 0% #CBA53E;
  border: 1px solid #CBA53E;
  color: #FFF;
}

input:required:invalid {
  background-color: white;
}


.error{
  color: red;
  font-size: 15px; 
  display: inline-block; 
}

span#nameHint.errorMessage {
    position: relative;
  color: white;
  width: 90%;
  display: inline-block; 
  padding: 10px 5px 10px 15px;
  margin: 5px 20px 15px 5px;
  background: red;
 }

Yes, it also works, but it requires the addition of a number of selectors in the form. New html elements just for the sake of styling. I think it is a mistake. The fewer elements in the html code, the better; and any aspect related to styling of layout for the css rules outside the document.

More opinions on the subject would be much appreciated.

Fact. The <div>s have no styles attached. They are 100% structural block containers and bulletproof across all devices.

Absolutely! :slight_smile:
I tend to place more value in cross-device compatibility than in minimalist code. If both can be achieved, that’s great; but if not, I opt for compatibility. Just so ya know where my heart lies. :slight_smile:

Hi ronpat.

It is not a question of minimalism. Althought the selectors have no styles, you are adding new html code just for styling the form, and not for including some new functional elements.

I also had cross-device compatibility in mind, and there is no need for such selectors to get a fully compatible and customizable form. You can set a responsive, fully functional, cross browser compatible form without the “br” elements or additional one just by css.

It is not a question of minimalism. Althought the selectors have no styles, you are adding new html code just for styling the form, and not for including some new functional elements.

Try Ron’s html without css and then try yours and see which one looks better.:slight_smile:

When dealing with structural semantics its always good to turn css off and see how the page looks. A well structured semantically correct page will often look correct even without css applied. After all screen readers may run your form together because they see no structure between one element and the next.

Of course making pages display well with CSS off is a bit over the top but it is a good design tip just to check the structure works on its own. In the end its a trade off between structure, semantics, simplicity and functionality so there never really is one right answer.

I tend to avoid though running inline elements into block elements (although I seem to be the only one who objects to this) as things like this grate on me.


 <label for="surname">Last Name <em>*</em></label>
 <input id="surname" required>
 [B]<p>[/B]<span id = "surnameHint" class="errorMessage"></span>[B]</p>[/B]

It is perfectly valid to do the above and indeed in some cases you have no option but whereever you can its nicer to avoid that structure. The reason is that you are running an inline element into a block element which is akin to html like this:


<div>Hello <p>I am some more text</p></div>

The text “Hello” is in limbo because it doesn’t really have a structured container and should also be inside its own block element like the p element.

In your example you could simply set the span to display:block to avoid this issue and keep the semantics correct. As I said I am only one of the few who moan about things like that so feel free to ignore me :slight_smile:

Using breaks is often frowned on but funnily enough form elements are where they are perfect and semantically correct.

e.g.
label : input : break

The above will often save the use of using a parent div and closing div inside a fieldset. Remember though that when you don’t use a fieldset it is invalid to have inline elements as direct children of a form in some doctypes.

It’s the same reason that breaks are semantically correct when used in addresses, poetry and song lyrics etc

Your are correct in all you say, but consider that Prorsum is looking for a css-based substitute to the “br” elements.

In other case, If we finally choose to use some structural element, why not leaving the “br” and adding some more to handle the span?, which - like you well said - are semantically correct.


<br />
<span id = "nameHint" class="errorMessage">This is where the error messages go</span>
<br />

Yes the break is fine in that sequence and I often use “label : input : break” on simple forms to avoid the need for a div. :slight_smile:

However I often find that where error messages, hints and tips are also being supplied then it pays to have a div enclose the label and input rules so that you can just pin a dynamic class to the parent div to show your error message and highlight the form elements etc quite easily.

It’s not really a big deal but sometimes I find that just cutting corners for the sake of it often leaves you vulnerable to changes at a later date. I still agree that minimum code should always be the goal but as I work on more and more sites I come across situations where for example descendant selectors were fine at the time but as the site has progressed the html has changed and the css is now wide of the mark and if I’d used a simple class to start with the problems would have been avoided.

In the end it’s a choice you make based on the task in hand so I can’t say one approach is actually right or wrong.:wink:

Thanks for the reply Paul.

In any case, and after having a siesta, I have reconsidered the issue and become aware that there would be a problem in adding the “br” elements before and after the span when there is no error at all, for we would have two unnecessary line breaks.

So, either you generate these elements dinamically (generally by adding them to the language file) or put the span into a div or turn to a css-based solution.