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.
Related
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 have no clue why the placeholder is not showing up in the textarea:
<textarea id="message" tabindex="4" cols="39" name="message" rows="7"
placeholder="Your Message"></textarea>
<input id="sendto" name="sendto" type="hidden"
value="benjamin#example.com" />
I dont know if this will be helpful, but:
http://www.w3.org/html/wg/drafts/html/master/semantics.html#attr-textarea-placeholder
http://www.w3.org/html/wg/drafts/html/master/semantics.html#attr-input-placeholder
Here is the documentatcion from W3C and information that placeholder is valid for both: textarea, and input.
In that case if Your browser does not show it and everything is done as it should (html5 doctype, and good html structure of whole file), then it is nothing to worry about. Maybe this is some kind of bug, or temporary problem, or something else.
IMPORTANT! Remember to add label to each input or textarea (as stated in documentary file), and then placeholder is kind of additional convenience.
try this
https://developer.mozilla.org/en-US/docs/Web/CSS/::placeholder
and
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea
cool tutorials for anyone facing placeholder issues, but if your input is created from codes and not HTML use aria placeholder
link : https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-placeholder
I'm building a html5 form. To validate it at first I use html5 validate mechanisms (patterns, required, etc...), and then PHP server side validation. I'm writting it as a library, so I can't predict all possible cases.
For example, I've got email input:
<input type="email" name="mail" placeholder="you#domain.com" />
Now I'm checking with php if the domain: domain.com exists (* - see footnote).
If no, PHP render the form once more but should display error near the input that has validation mistakes.
HOW TO DO THAT SEMANTICALY? What html element is good for it?
I will give some wrong examples to ilustrate my problem (I will write only important fragments of code) :
<label for="mail">Email:</label>
<input type="email" name="mail" id="mail" /> - given mail does not exist
Error without of html5 element. This is what I found to be most popular on websites, and most hopeless (stupid - no offense :) ) solution...
<label for="mail">Email (given mail does not exist):</label>
<input type="email" name="mail" id="mail" />
Is the error realy a label fragment? Or label is label, and error is not a fragment of label. In that case labels can be diferent (according to a given mail). Is this semantic?
<label for="mail">Email</label>
<input type="email" name="mail" id="mail" />
<span class="error">Given mail does not exist</span>
No idea solution. Span can be used here, but this is another no better idea solution.
Another ideas:
<details> - this isn't a detail...
<aside> - this isn't aside, this is important!
<mark>, <strong>, <emph> - with a given class?
Thanks for Your time and ideas. I know that even complicated error handling can be done using html5 validation methods, but there should be an object that is the best for showing such things in html5 semantic (for example for blind people - imagine the screen reader application, form filling by such a person by voice, and the first stupid solution usage. The screen reader should read whole page to hear just one error...)
Best regards
PS. If someone think, that there are better problems on earth (:D), yes of course there are. But we are those, who try to make the web more clean and available. And we really should take care about such details.
(*) which is not that easy in html5 You must use ajax, with php function, and override default Error handling mechanisms with Your own texts, and much much more...).
In order for an error message to be announced by assistive technology, it has to be associated with the field. When a screen reader arrives on a form, it triggers what's known as "forms mode" and at that point it will only read out that which is associated with the fields themselves.
<label for="mail">Email</label>
<input type="email" name="mail" id="mail" aria-describedby="email_error" />
<span class="error" id="email_error">Given mail does not exist</span>
In the above example, the use of aria-describedby allows you to create an explicit reference between the field and the error, which will ensure it is announced by screen readers.
semantics are debatable; that said, the "stupid, no offense" example is the most semantic approach, except its better practice to wrap the message in a span element.
don't let that semantically lacking span fool you: this approach is for addressing accessibility support.
semantics are being used properly here, as this markup is displaying the correct information, its just not an audience that most people realize exists.
Read more about this technique here: Simple inline error message pattern
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.