I want your opinion on this question.
Is it that necessarily to close the <tr> and <td> tags?
Most web editor/design softwares prefer having these tags closed, I personally think it's more ergonomic to leave the tags open.
You can easily distinct the start and the end of a row if you properly write your code.
<table>
<tr><td class="login_cell">Login:
<td><input type="text" name="user_login" class="input" autocomplete="off">
<tr><td class="login_cell">Password:
<td><input type="password" name="user_pass" class="input">
<tr><td>Forgot password?
<input type="hidden" name="log" value="ok">
<td><input type="submit" name="btn_login" class="btn" value="Log in">
</table>
Pros:
less characters --> page loads faster
(the thing you said, which I don't think is a good reason)
Cons:
Hard to maintain
No valid XHTML
Might mess up CSS/JS
Not always allowed
Might not be rendered correctly by all browsers (Yeah, I'm talking to you, IE!)
Bad, bad style...
Summa summarum, I'd close the tags...
Always close HTML tags in HTML5! Whether it's a short tag (e.g., <img src="image.png alt="image" />) or a regular tag. (e.g., <div id="myDiv">Content</div>)
The rules are:
XHTML: You have to close all tags.
HTML: You only need to close the table tag.
My advice would be to always close the tags in a table. That makes it easier to keep track of everything, and a lot easier if you would choose to use XHTML instead of HTML.
Related
Can anyone explain shortly the different meanings of these inputs? 1st one, ended space + slash. 2nd one ended only slash, 3rd one ended no slash. Which is the new method or which is the correct method or are both for different purposes?
<input type="text" id="id" value="some" />
<input type="text" id="id" value="some"/>
<input type="text" id="id" value="some">
There are no differences if we speak about HTML5. It makes sense to close the tag only if you work with XHTML, otherwise it's not necessary. You can close tag or not. Both are acceptable in HTML. Space before the slash makes nothing except better reading opportunity.
I know if input tag no need close tag input like this
<input type="text" value="Save">
but i will continue some web app and i see so many input tag with close tag like this
<input type="text" value="Save"></input>
I want to know, does this have an effect on something?
I fear will have an effect on something in the future.
You can make the tag closed, which would combine conciseness of HTML and strictness of XHTML:
<input type="text" value="Save" />
For further discussion, please refer to HTML 5: Is it <br>, <br/>, or <br />? but please keep in mind that the top-rated response there is very old. XHTML correctness is more important now than it was in 2009. Also, the closed tag tells the reader not to attempt to look for the closing tag, which makes the code more readable in my opinion.
I've been a developer for a long time, however forms have always been my least favourite part, more specifically designing them!
I'd really like to know how you do you forms, and why. I've had a few discussions with fellow developers over <div> vs <p> on form fields. Which one would you stick with, and why?
An example of what I am talking about:
<form action="" method="post">
<p>
<label for="username">Username:</label>
<input type="text" name="username" id="username" />
</p>
<p>
<label for="submit"></label>
<input type="submit" name="submit" id="submit" value="Log In" />
</p>
</form>
VS
<form action="" method="post">
<div>
<label for="username">Username:</label>
<input type="text" name="username" id="username" />
</div>
<div>
<label for="submit"></label>
<input type="submit" name="submit" id="submit" value="Log In" />
</div>
</form>
When it comes to styling, it seems you can do pretty much the same with both, so is it just personal preference, or is there logic behind using one over the other?
Thanks for your time :)
UPDATE
I ended up following a nice article on HTML5 forms and have actually found it to allow MUCH better styling of forms. They are much more organised from a development perspective too. For anyone interested, it is located here: http://24ways.org/2009/have-a-field-day-with-html5-forms
HTML is all about semantics. There is no reason username or submit should be inside a paragraph (<p>) because it's not a paragraph.
So I would go using <div> instead. Ok, maybe <div> has no meaning at all. But it's better than <p>.
I prefer the <div> variant, because its semantics is closer on what you want to express and markup.
A <p> tag is for text paragraphs, whereas a <div> is a general block of any kind.
One option I'd like to suggest:
You could consider wrapping the input inside its label. That way you possibly can avoid additional elements. Also (if you don't need to support IE6) then this allows you to drop the for. And finally if the input is a check box or radio button, then it allows the user to click on the whole text instead of just the tiny control, just like in most operating systems:
<label>Username: <input type="text" name="username" /></label>
Also I'm not sure what the point of an empty label for the submit button is good for, except being lazy when writing the style sheet.
Just thought I'd throw my 2 cents in (assuming we all agree that semantic markup is the goal):
While one can argue that form elements themselves are not semantic, this doesn't mean that the context in which they appear is not as well. There is no "one true way" to markup all form controls.
If the control is actually appearing in a paragraph of text, that is fine - but that pretty much never happens.
If it is an ordered list of checkboxes for example, put them in an <ol> tag.
If order is not relevant, use a <ul> in that case.
If it is a label/text_input pair, one could argue that a <dl> element is appropriate
If it is a spreadsheet, use a <table> (Yes, tables can be appropriate! In fact, I've heard the (questionable) argument many times that form data is tabular)
By the way it is considered a description list in HTML5 to clear up confusion about meaning, and whether or not it's appropriate for things other than literal definition terms.
Almost no one will ever say a <p> is appropriate, but very few will argue that a <div> is inappropriate because there are no attached semantics.
Semantically, each label is bound to its control through the for attribute. There's no need to wrap the pair for semantic reasons, although you may wish to do so for styling reasons. So div is appropriate.
Similarly, grouping of controls has a dedicated element fieldset so there's no sense in using ul, ol or dl for that purpose, and using them is simply a form of listitis.
What about fieldsets ? - it is more logical for forms
And in fact you can style anything the way you want
Semantically I'd say divs make more sense simply because they have no semantic meaning and the only reason to use a block container like this is for layout purposes. That said, I use paragraphs, but completely out of habit. It's the only place I use paragraphs while not considering their semantic meaning.
So I've been reading a lot of "Designing with Web Standards" and really enjoying it. I'm a big CakePhp user, and as I look at the source for various form elements that Cake creates with its FormHelper, I see all sorts of extraneous
In the book, he promotes semantic HTML, and writing your markup as simple / generic as possible.
So my question is, am I better writing my own HTML in these situations? I really want to work in compliance with XHTML and CSS standards, and it seems I'd spend just as much time (if not more) cleaning up Cakes HTML, when I could just write my own
thoughts?
p.s. Here's an example in an out of the box form that CakePhp generates using the FormHelper
<form id="CompanyAddForm" method="post" action="/omni_cake/companies/add" accept-charset="utf-8"><div style="display:none;"><input type="hidden" name="_method" value="POST" /></div> <div class="input text required"><label for="CompanyName">Name</label><input name="data[Company][name]" type="text" maxlength="50" id="CompanyName" /></div> <div class="input text required"><label for="CompanyWebsite">Website</label><input name="data[Company][website]" type="text" maxlength="50" id="CompanyWebsite" /></div> <div class="input textarea"><label for="CompanyNotes">Notes</label><textarea name="data[Company][notes]" cols="30" rows="6" id="CompanyNotes" ></textarea></div> <div class="submit"><input type="submit" value="Submit" /></div></form>
EDIT: An in an indented form (indentation does not effect the standards compliance issue, but the above one-liner style is nearly impossible to read):
<form id="CompanyAddForm" method="post" action="/omni_cake/companies/add" accept-charset="utf-8">
<div style="display:none;">
<input type="hidden" name="_method" value="POST" />
</div>
<div class="input text required">
<label for="CompanyName">Name</label>
<input name="data[Company][name]" type="text" maxlength="50" id="CompanyName" />
</div>
<div class="input text required">
<label for="CompanyWebsite">Website</label>
<input name="data[Company][website]" type="text" maxlength="50" id="CompanyWebsite" />
</div>
<div class="input textarea">
<label for="CompanyNotes">Notes</label>
<textarea name="data[Company][notes]" cols="30" rows="6" id="CompanyNotes" ></textarea>
</div>
<div class="submit">
<input type="submit" value="Submit" />
</div>
</form>
In the above, there's those couple divs that seem unnecessary like the one that has inline CSS "display:none". I realized I can change classes and IDs of all the fields, but if I'm doing do that for each one, I might as well write the HTML myself...
My answers to your two questions are as follows:
Is CakePhp 'standards compliant' when
generating HTML, Forms, etc?
Yes.
In [Designing with Web Standards], he
promotes semantic HTML, and writing
your markup as simple / generic as
possible. So my question is, am I
better writing my own HTML in these
situations?
Sometimes you are better off, sometimes you're not. If your goal is to use minimal, semantic markup, you could be better off writing your own HTML most of the time. However, if your goal is to generate standards compliant HTML quickly, then allowing Cake to be what it's meant to be—a rapid development framework—is a good idea.
That said, you can tell Cake not to print some of its markup when you find it unnecessary. For example, you can suppress the div elements that wrap form inputs by using a value of false with this option: http://book.cakephp.org/view/1397/options-div
The markup output by Cake helpers is certainly standards compliant, as you can check at any time. What it could possibly be is simpler, but not much more so. The <div style="display:none;"> container with hidden input fields may be superfluous, but it's nicely grouping these fields and getting them out of the way. If you're using the SecurityComponent you'll find many more of these necessary hidden fields, which makes the wrapping <div> less superfluous. Apart from that, I have a hard time finding any really extraneous markup.
If you're not happy with the <div><label><input>[error]</div> structure, you can use the specialized $this->Form->label() etc. methods to produce only the input elements and wrap them in your own container elements. Just remember to include the $this->Form->error() as well somewhere.
I think the best way is to start prototyping your apps using basic $this->Form->input() groups of elements. Often these are perfectly serviceable in the final app as well. If during development you realize you need different markup than what Cake offers you, you can start transitioning to more custom markup. The one thing you should not do is write your own <input> elements, you should always use the FormHelper methods to produce those, since it's taking care of a lot of details that are a pain to reproduce properly by hand.
Apart from the FormHelper, I don't think there's anything to complain about in Cake's HTML markup, since you're writing most of the rest yourself.
According to the CakePHP book, the generated HTML is standards compliant.
You could override the default HTML output from the FormHelper methods by extending the Helper class.
More information here
Question already answered but maybe worth adding that this depends on which standards, and which version of CakePHP.
HTML5 form input types are not supported by the FormHelper in 1.2.x and 1.3.x, for example
echo $this->Form->input('User.email', array('type' => 'email'));
will output something like
<div class="input textarea">
<label for="UserEmail">Email</label>
<textarea id="UserEmail" name="data[User][email]"></textarea>
</div>
Apparently this will be fixed in 2.0.x.
Another edge case is if you have more than one form on the page with the same model you may end up with duplicate HTML identifiers.
For a standard "add item" form page it is desirable to have two submit buttons: an "OK" button and a "cancel" button, where the former POSTs the form to one URL, and the latter GETs some other URL.
This obviously means that two separate FORMs are needed, and, if laid out with tables, the markup would go as follows:
<form action="add.html" method="post">
<table>
<tr>
<td>Enter data:</td><td><input type="text" name="data"/></td>
</tr>
</table>
<input type="submit" value="OK"/>
</form>
<form action="index.html" method="get">
<input type="submit" value="Cancel"/>
</form>
However, this would result in the two buttons being placed below each other. It would be desirable to have them placed side by side. The following works:
<form action="add.html" method="post">
<table>
<tr>
<td>Enter data:</td><td><input type="text" name="data"/></td>
</tr>
<tr>
<td><input type="submit" value="OK"/></td>
</form>
<form action="index.html" method="get">
<td><input type="submit" value="Cancel"/></td>
</tr>
</table>
</form>
But although I've seen it used on commercial websites, I guess it's not quite legal HTML.
So thus:
1) Since the second methods works, are there any good reasons for not using it?
2) Are there any better solutions?
EDIT: This was a silly question. The second method is unnecessary. Solution: add to the first method a CSS rule of:
form
{
display: inline;
}
You broke my mind.
There are many and varied problems with what you have here, but I'll start by pointing out that Cancel/Reset are not considered good things generally.
I'll follow that by pointing out that you could use CSS to style the buttons side by side in your first example, and follow that by pointing out that a simple type="button" could have any arbitrary script attached to it to do your cancel navigation, and follow that by the fact a simple anchor tag would be even more straightforward.
And I'm not going to mention the table, because that'll just start some trouble.
Don't use a second form. Wrap both buttons in the same form, and do something like this with the cancel button:
<input type="button" text="Cancel"
onclick="document.location.href='index.html';return false;" />
1) When you create a page using "legal HTML," you can have an expectation that what works in today's browsers will work in tomorrow's browsers, or in some other user agents that you might not have checked the site in. But in the example you've given, the degree to which different browsers agree on how to "fix" the HTML for display is much less certain. It adds a level of predictability to the how the page will display when "valid HTML" is used. Plus, who knows how a user agent such as a screenreader would describe the code in question.
2) Is using a regular anchor tag an option?
<td><input type="submit" value="OK"/></td>
<td> or Cancel</td>
Or you could use CSS to move a second form and its submit button up into the first form, but the specifics of this might be tricky.
Add a row to your table
<tr>
<td><input type="button" value="Cancel" onClick="window.location='./index.html'"/></td>
<td><input type="submit" value="OK" name="submit"/></td>
<tr>