Looking at html, there is a bunch of built-in attributes on tags:
I am trying to work out what HTML "on spec" attributes are named.
Note: I am not looking for an opinion - I want to determine/breakdown exactly what the W3C opinion is. This is so I can recreate it this naming convention in React.
As a best-guess, I generally stick to the phrase:
The thing [is/has x]
And is/hasX becomes my prop.
However, I do not have a good grasp of the lingo of grammar, and it can be difficult for me to keep it consistent.
Lets consider two inputs, one html and one React.
This sounds right to me:
My input is hovered
<input checked selected active disabled />
<MyInput isHovered hasTooltip hasError />
But isHovering also sounds correct , but I suspect this doesn't have the correct (past) tense:
My input is hovering
<input activating checking />
<MyInput isHovering hasTooltip isErroring />
When things start to get confusing, I realise I'm in the bad habit of trying to side-step doing the grammatical-gymnastics
My input is...hover
<Myinput isHover hasError />
But the props of the component no longer seem consistent.
Plus its not what html does:
<input check />
Question What is the correct (verb?) tense of html attributes according to the spec (I've looked, and didn't find anything in the spec about tense/verbs)?
Note: is/has is added because props, unlike attributes are variables, and this prefix helps with code clarity
This question will probably get closed because it's a matter of opinion, but anyway:
I never saw the present progressive tense ('hovering', 'activating') being used anywhere.
In our project we have components with props in the past tense ('disabled', 'checked') which happens to conform with HTML. I'm in favor of this also because of brevity ('isDisabled' is lengthier, which could be ok if it adds to readability, but it doesn't).
Don't use an infinitive ('check') because it implies an action (so as a developer I might think it connects the component to some external control).
But above any other consideration - whatever you choose, be consistent.
Related
I usually saw html data-attribute(s) to add specific values/parameters to html element like Bootstrap that uses them to "link" buttons to modal dialog to be opened, etc.
<button type="button" class="close" data-dismiss="modal" aria-label="Close">
Now, I see that an almost famous CSS framework, Kube, in its new version extensively uses simple custom attribute such as in following:
<column cols="4">4</column>
<span class="label label-black" outline bold>Black</span>
Other in-action examples are visibile for example, here.
I did not know that was possible to use simple custom attributes so I tried to search some source about this, and I found only this old similar question in which are noted almost only (possible) compatiblity issues.
I'm surprised that a CSS framework like Kube could use a similar solution if browser support could be so "fragile"....
So my question are:
How good (=cross-compatible) is Kube's approach?
Can I safely replace my data-attribute with simple custom ones if for example I have to pass only true/false values?
This last question is better described by an example, so replace <span class="foo" data-boo='true'>Black</span> with <span class="foo" boo>Black</span>
Use data attributes. They are:
standard
won't make a validator report them as errors (it's hard to spot unintentional errors in a validation report when they are surrounded with a pile of errors that you've made intentionally)
won't conflict with attributes that might be added to the standard in the future
… and you don't have to give them values if you just want to check to see if they exist with a CSS attribute selector … but if you want that then you should probably just be using additional classes instead.
When using element directives I have seen Angular element directives used in two ways:
1. As block level components
The element is styled as display:block, is the component and its children are the component's children, so the element itself is the component.
Use of directive:
<example class="Example"></example>
The directive's html:
<header class="Example-header"></header>
<img class="Example-image">
<footer class="Example-footer"></footer>
2. As an inline wrapper of the component
The element is left as display:inline and effectively acts as an invisible wrapper for the component itself:
Use of directive:
<example></example>
The directive's html:
<div class="Example">
<header class="Example-header"></header>
<img class="Example-image">
<footer class="Example-footer"></footer>
</div>
Obviously each have advantages and disadvantages for example extra markup, loss of layout context due to inline element etc, but is one the correct way? or is this another of Angular's vagaries?
I'm surprised no one responded, but the idea behind creating custom directives is the ability to create reusable pieces of code that fulfill a specific bit of functionality on your site.
This functionality, however, doesn't care about the styles that you are going to use. You can of course conditionally change classes and styles from within Angular, but the core component when dealing with the framework is the data.
With that being said, there is no "correct way" as you bolded in your question. Develop the directive to fit your needs and style of your site.
First this is probably opinion based but i'd really like to share my point of view about this.
If you really follow angular way of doing directives none of theses are a correct way.
Directives are intended to add a behavior to an HTML element.
The less the directive add HTML the best it is as it allow you to have a better control on this element.
Lets take an exemple.
We have a data grid (let say ui-grid, it doesn't really matter)
<ui-grid ...>
...
</ui-grid>
I had a the idea to add some button to add or remove element in the grid.
I first came up with this
<ui-grid ...>
...
</ui-grid>
<button ng-click="addItem()">Add</button>
<button ng-click="removeItem()">Remove</button>
I'm really happy with this and that's ok, but finally i need to use theses buttons in some other views. I'll have to duplicate the HTML, duplicate the JS and adapt it to the collection.
The common mistake
That's obviously not a good idea.
Instead i will do a directive. Lets say "button-list" : it produce the same html and behavior.
<ui-grid ...>
...
</ui-grid>
<button-list></button-list>
That's pretty cool.
Now i have some need. On one view i need the add button to be blue, on an other one i don't need to have a remove button, and on a last one i want the button text to be "X" and "+" (That's was some request by a client in a true story).
I could make a big object with a list of option and etc... but this is really painful and you need to touch the directive each time you need to add a custom different little behavior.
The good way to go
Now lets just think again about what i wanted to do.
I want the button to interact with the grid... and that's pretty much all. This is how we should go building a custom directive.
We could then produce this directive this way :
<div grid-button-container collection="mycollection">
<ui-grid ...>
...
</ui-grid>
<button grid-add-item>Add</button>
<button grid-remove-item>Remove</button>
</div>
So what do we have here ? We have three different directives.
grid-button-container : Its responsibility is to hold the list for the sub-directives.
grid-add-item : It add a function on click that add an element to the collection of grid-button-container.
grid-remove-item : It add a function on click that remove an element to the collection of grid-button-container.
Both grid-add-item and grid-remove-item will be requiring the grid-button-container to be used.
I cannot describe all the implementation of this (it would take too long) but i think this is how directives should be used. Such as almost no angular build-in directives (ng-*) add HTML and just add a behavior i think all the directives should be build in this way.
Pro :
You have a full control about your HTML
Directives are tiny and trivial
This is really re-usable
Cons :
Can be harder and longer to implement.
To make a final point, the two way you're asking about are just different. No one is better than the other it will just depend on your own HTML organisation and it will depend on the directive use.
Hope it helped.
I've build a page with a form and for some reason my button for the form and my footer element is not showing up on the page.
I have added a link so you can check out my code. And I know its a HOT MESS! so if you can give me any tips on the css and html please feel free to let me know.
http://jsfiddle.net/jeramiewinchell/j6n0w1tj/
enter code here
Fair point in the edit. I said it was a mess without giving anything positive.
Here are some tips that could improve the HTML (with links for reference):
You should specify a doctype (e.g.: <!doctype html>) instead of having an empty <!DOCTYPE> tag.
http://www.w3.org/TR/html-markup/syntax.html#doctype-syntax
It would be nice to have a <html> wrapping everything, and a <head> wrapping the title and links. I'm not clear if it's technically valid not to have them (the W3C HTML validator will not validate a page without a <head> although it will validate without the <html>), but it's nice and it will help keep things organized.
The links should have a type indicating the mime type (in this case type="text/css").
http://www.w3schools.com/tags/tag_link.asp
Closing empty elements (e.g.: img, link, input) is not mandatory in HTML5, but it is in XHTML. Depending on the doctype that you choose, you should close them accordingly. Using /> at the end is valid for both HTML5 and XHTML, so you may want to consider it.
http://www.456bereastreet.com/archive/201005/void_empty_elements_and_self-closing_start_tags_in_html/
Don't nest <p> tags. Paragraphs are block elements that should contain only phrasing content (= not block/paragraph elements). How to fix it: replace <p class="site_section1"> with a <div class="site_section1">.
http://www.w3.org/TR/html5/grouping-content.html#the-p-element
Always close the block tags that you open. For example, you never close the <p class="site_section1"> (altough as I said in the previous point, you should making it a <div>... and then close it). The result in the browser may be unpredictable.
I mentioned in my comment above (sorry, I don't know the name in English), you should avoid crossed tags/nesting of tags. This is incorrect: <label>...<select></label>...</select>, it should be <label>...</label><select>...</select>.
Again, not mandatory but it could be nice to set a value attribute in the <option> tags. If you don't specify a value, the value sent will be the content inside between the <option> tags (that may be what you want in this case).
Don't forget all the code and to close the tags correctly! Things like this: <button type="submit">Save</buttons </div> can have disastrous results (although it looks more of a typo to me).
Don't close tags twice (e.g.: you have </body> twice)
And for the CSS (also with some links for reference):
Avoid unnecessary styling. E.g.: border-radius:0px is unnecessary because 0 is the default value for border-radius (unless you have defined some previous style and you want to overwrite it).
http://www.w3schools.com/cssref/css3_pr_border-radius.asp
Specifying units is required for values different than 0. E.g.: margin-left:15 is that 15 in px or em?
http://www.w3.org/TR/CSS21/syndata.html#length-units
The units are optional when the value is 0. Some people find it more readable and better because it is shorter; I personally like them. Your call, but always:
Be consistent: if you omit the units for a zero value, do it in all your definitions. It looks awkward to me to see a padding:0 (without units) next to a margin:0px. It will help you read and maintain the code later.
You could merge many styles together. For example: .zonelist23, .zonelist24, and .zonelist25 are the same, you could define one style only (e.g.: .zonelist_bml30) or set all of them together: .zonelist23, .zonelist24, .zonelist25 { ... }
Not mandatory, but nice: The font-family tag should have several names as a "fallback" system. That way, if the browser does not support the first font, it will go to the next and so on.
http://www.w3schools.com/css/css_font.asp
Just out of curiosity: did you meant to put in the stylesheet .header or is it header? I personally try to avoid classes/ids with the same name as a tag to keep the code easier to understand, but that's a personal choice. As far as I know there's nothing against naming a class like a tag.
One way of having fun and learning (you may now think that I have a strange way of having fun and learning):
Go to the W3C HTML Validator.
Click on the the "validate by direct input" tab.
Copy your code in the box.
Click on the "Validate" button.
View the first error, and read the comments (visit the links for reference).
Fix the code according to what you've read.
Click on the "Revalidate" button.
Repeat steps 5-7 until no errors are found.
(You can do the same with the CSS in the W3C CSS Validator)
Please see this fiddle : http://jsfiddle.net/j6n0w1tj/1/
I have corrected your code.
Kindly follow the steps mentioned by #monty82, who has given an excellent explanation on how to proceed with your code.
Wrong html:
<label>..<select></Label><option></option></select>
Correct html
<label>..</label><select><option></option></select>
Tags like <input>,<br> are self closing tags,close it like <input
type="radio"/> and <br/> not as </br>.
Please make sure whether your opening and closing tags match
Usually when i create some HTML template, i tend to prefix and class (or id) everything, This is my way of keeping the markup more readable, and also it makes styling a lot easier.
For example if create a template called MyTemplate, then i prefix all elements like this
<form id="mt-form-blue" class="mt-form">
<input class="mt-input-large" type="text" />
<input class="mt-input-small" type="text" />
</form>`
I've seen lots of HTML templates, where the creators make very little use of classes and ids.
My question is why? Does using many classes and ids, have an impact on the browser performance? Does it have any dangerous side effects?
CSS selector do impact performance, but how much it impact will depend on its complexity and what operators were used. Usually you won't notice such tnings, but there are plenty of researches for this matter on the web.
Regarding the use of selectors, listing only the basic three, the use of them depends on what is your intention, for example:
tag name selector - When you want apply style to every element of this type
class selector - when you want to reuse your style in more than one element
ID selector - when you want to apply your style to only one element per document
Of course, their use is not limited for the list above but I believe it contains the most common use cases.
I was recently corrected, and according to the HTML4 DTD, it is legitimate to use a fieldset outside of a form:
http://www.w3.org/TR/html401/sgml/dtd.html#block
Previously I had not known this, and wonder if anyone can think of a legitimate use case for doing so. I feel like using one to decorate would be frowned upon by most designers. So is there a legitimate use case, or can you link to a site where this has been found appropriate and used as such?
I used a field set to decorate sections when printing documents. For example an invoice might have a Bill To and a Ship To, and drawing the frame around them with the legend text embeded in the frame can look really slick.
I think its more than legit to use it for decoration. Its simple and elegant and with the use of tag its pretty nice.
Check w3schools example out
I don't think there is a legitimate case to semantically have a fieldset outside a form element, since a fieldset is a set of (input) fields - the clue's in the name! If you have input fields, you will likely always have a form, even if you're not posting back to the server.
I have occasionally used from a presentational aspect, because the fieldset+legend combo is impossible to replicate exactly in CSS, specifically, the broken line behind the legend.
It is acceptable to use all form field control outside of a form element, including fieldset.
This is appropriate wherever you have fields that only talk to JavaScript, instead of ever being submitted back as to the server side.
(This didn't originally used to work in Netscape 4, but that's hardly a concern this century...)
Well, using it to decorate can be frowned upon by designers AND be legitimate, so there is a legitimate use case.
A form is simply a container for the fields you wish to submit via post back. Most regular site pages may not even have one. That said, using a fieldset as a styling tag is legitimate and has nothing at all to do with whether a form tag exists or not.
You can use a fieldset to wrap multiple form controls that you need to disable together:
<fieldset disabled>
<input type="text" placeholder="disableable input" />
<button type="button">Some action that needs to be disabled</button>
<button type="button">Some other action</button>
</fieldset>