Is CakePhp 'standards compliant' when generating HTML, Forms, etc? - html

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.

Related

Using HTML Validation Popups with jQuery Unobtrusive Validations

I have an ASP.NET MVC site that uses Data Annotations for validations and I'd like to get "free" client-side validations. Most simple ones work well and Foolproof helps me with more complex scenarios. All is good so far.
However, I'd like to tie into HTML5 validations with browser support. Specifically, I want to use the little popups for all of my client-side validation messages.
I've created a JSFiddle example here explaining what I want and am coming from: https://jsfiddle.net/4nftdufu/
The behavior I want to see is shown by the first form (Foo).
<form class="form-inline">
<div class="form-group">
<input type="text" class="form-control" id="inputFoo" placeholder="Type Foo Here" required>
</div>
<button type="submit" class="btn btn-primary">Submit Foo</button>
</form>
The second form (Bar) is essentially where I'm coming from. Note that I'm hooking into some Bootstrap validation behavior here (I found that CSS online somewhere in a blog post or some other SO question). Ultimately, this is not the behavior I want and I've not spent any time cleaning up this imperfect integration.
<form class="form-inline">
<div class="form-group">
<input class="form-control input-validation-error" data-val="true" data-val-required="Required" id="inputBar" name="inputBar" placeholder="Enter Bar here" type="text" value="" aria-required="true" aria-describedby="Bar-error" aria-invalid="true">
<p class="help-block"><span class="field-validation-valid" data-valmsg-for="inputBar" data-valmsg-replace="true"></span></p>
</div>
<button type="submit" class="btn btn-primary">Submit Bar</button>
</form>
How can I get my Data Annotations + jQuery Unobtrusive-driven validations to hook into these HTML popups for all validation messages when in a supported browser?
MVC's client side validation using the jquery.validate.js and jquery.validate.unobtrusive.js files and HTML-5 validation do not play well together. The jquery.validate.js file in fact adds the novalidate attribute to your <form> element to disable HTML-5 validation using the following code
// Add novalidate tag if HTML5.
this.attr( "novalidate", "novalidate" );
If you want your messages to look like the browsers callouts, then you can always use css to style the element generated by #Html.ValidationMessageFor(). When a form control is invalid, a class="field-validation-error" is added to the element which can be used for styling (adding color, borders, using the ::after pseudo selector to add arrows etc)

Angularjs HTML attribute code styling guidelines

This is somewhat opinion based, but I was wondering about good practices to styling HTML attributes in code when using Angularjs. As I am sure you know there is a problem of too long lines if there are no lines breaks in between attributes.
This is killing the readability:
<input spellcheck="false" type="text" name="some_name" id="some_name" ng-this ng-that long even-longer blablabla>
So I tend to do this:
<input
spellcheck="false"
type="text"
name="some_name"
id="some_name"
ng-this
ng-that>
Any official guidelines on this, or suggestions. Thou the second option is more readable too me, it's still bad in my opinion. Messes me up a bit on elements that have some content or other element in them.

HTML Forms - In your opinion, how should they be done and why? (<div> vs. <p>)

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.

CSS - Focus login fields just like twitter with only CSS?

I already posted a similar question and got a jQuery solution that works. Now I want to do it with only CSS/HTML. I saved twitter's homepage locally and deleted all the js scripts and noticed that the effect I'm trying to achieve is with CSS/HTML (when you click on the username/pass the values "Username"/"Password" stay there until you enter text).
I'm a newbie at these kind of new CSS/HTML effects and have spent the last couple of hours trying to replicate it with no success.
Here's the html of twitter's login form:
<form action="#" class="signin" method="post">
<fieldset class="textbox">
<div class="holding username">
<input type="text" id="username" value="" name="session[username_or_email]" title="Username or email" autocomplete="on">
<span class="holder">Username</span>
</div>
<div class="holding password">
<input type="password" id="password" value="" name="session[password]" title="Password">
<span class="holder">Password</span>
</div>
</fieldset>
<fieldset class="subchck">
<label class="remember">
<input type="checkbox" value="1" name="remember_me">
<span>Remember me</span>
</label>
<button type="submit" class="submit button">Sign in</button>
</fieldset>
I've looked over the site's CSS but it's 10,000 lines and very complicated. How should the CSS look like? Or could you point me out to a tutorial on how to achieve the same effect as this is driving me nuts?
Thank you very much,
Cris
Set the HTML autofocus attribute:
<input type="text" placeholder="Type here ..." autofocus="autofocus" />
You can target elements that are focused or blured like so:
input:focus {color:red;}
You now need to nest the CSS to hide the span called holder inside the input.
span.holder input:focus {visibility:hidden;}
I have not tried this, but it would be something like this.
To clarify, I have just pulled the JavaScript twitter use and the source for their home page and I can confirm that they are using the following JavaScript function for focus on the field
inp.focus()
The JavaScript is quite lengthy but it looks like after a quick read that they are using jQuery that is setting focus based on the class being username.
I just looked at the autofocus property suggested by another poster and this method has worked for me in my web app currently under development.
The code for this is
<input type="text" id="username" value="" name="session[username_or_email]" title="Username or email" autocomplete="on" autofocus>
Note, per the documentation at the W3C website, the autofocus property can only be used once on the page. I have put it into a form that is hidden and shown in an inline element using Fancybox.
The grayed out text in the input field can be done with the place-holder element, something I'm already using, add the following into your input element
placeholder="Username"
NOTE: Both placeholder and autofocus are HTML5 properties and may not be supported by all major browsers yet, this is why JavaScript is still being used by sites like twitter.
The styling is done based on CSS/CSS3 greatly, an excellent resource is W3Schools. I would recommend for what you're wanting to achieve start at the CSS3 section looking at borders.
Another resource that is excellent but hasn't been updated for about a month and a half sadly is doctype.tv. Nick has some fantastic advise regarding styling your website along with some great insight into design.
Judging by the bolded text in your question (when you click on the username/pass the values "Username"/"Password" stay there until you enter text), I'm guessing what you want is the placeholder attribute, which #phihag has in his example.
<input type="text" placeholder="This text will disappear" />
The placeholder attribute works without Javascript in browsers that support it. For older browsers, you'll need some Javascript, and this is probably what Twitter is doing in their code.
See the Wufoo page on the Placeholder Attribute for more details, including how to do a javascript fallback and what browsers it is currently supported in.
See also this demo which shows how to style the ":placeholder" and ":active" states (at least for webkit and mozilla).

What's the best semantic way to wrap a search area?

I'd like to take advantage of the improved semantics of html5. I'm creating a search area, and the search area should have a background and contain search related things, like autocomplete and search hints.
Is there some consensus around what type of element something like a search area should be wrapped in?
Should it be a NAV because searching is a method of navigation?
Should it be a SECTION because it's a discreet section of the page?
Should it be a DIV because the wrapping of search related elements has no clear semantics?
The markup is something like this:
<?whatElement?>
<input type="search" placeholder="Search for a name or ID..." required />
Search
</?whatElement?>
Thanks for your thoughts.
I am aware this question already has a chosen answer, but it ranked so high in my Google search for "semantic search form" that I feel the need to contribute what I believe to be a slightly better answer, semantically and from a standards standpoint.
<section role="search">
<form action="#" method="get">
<fieldset>
<legend>Search this website:</legend>
<label for="s">
<input type="search" name="s" id="s" placeholder="Search..." maxlength="200" />
</label>
<button type="submit" title="Search this website now">Submit</button>
</fieldset>
</form>
</section>
Of course, I made a series of assumptions and populated the HTML with some default values (action, get, the id and name of the input, etc) and with no classnames for the elements (which I always tend to use in favor of generic element names or, Heaven forbid, IDs) but you should adapt to your own needs.
For example, some additions on top of the excellent contributions above: the first child of any form should always be a <fieldset> tag and have a <legend> attached (visible or not - https://www.w3.org/TR/WCAG20-TECHS/H71.html ), and all <input> tags should have a connected <label> tag through the for and id properties (https://www.w3.org/TR/WCAG20-TECHS/H44.html - I find it easier to just wrap the input in the label so as not to forget connecting them). All call to action elements should have a title (for SEO and usability, to reinforce the action the user is about to make just before she makes it), etc.
The HTML5 specification says this about the section element:
Role must be either region, document,
application, contentinfo, main,
search, alert, dialog, alertdialog,
status, or log
so I would use that.
How about:
<form>
<input type="search" name="" value="" />
<input type="submit" value="Search" />
</form>
<section role="search">
The role attribute is an ARIA landmark:
A landmark region that contains a collection of items and objects that, as a whole, combine to create a search facility.