A site I came across uses input type="private" for its password Form field. However, I searched online and it seems that "private" is not one of the defined types (https://www.w3schools.com/html/html_form_input_types.asp)? What does it do and where can I search for more details on this?
As you said, private is not one of the HTML input types. (MDN reference)
Even semantically, the input type 'private' does not make any sense. Input element with unknow type is rendered as text type by default. So here private is just some gibberish for the render.
I guess the site you came across might be doing for any specific use-case - CSS selector like input[type="private"] or with JavaScript - which is not the way to do. As this not standard, it should not be used.
type=private simply isn't one of the default values that the browser would recognize.
However, you're free to give it any type you want, you could give it a type="peanutbutter".
Doesn't matter, cause what matters is: now you can call that input type with jquery or something by doing input[type=peanutbutter] to select all inputfields with that specific type using javascript, jquery or css.
My guess is that type=private doesn't exist, but it's simply something used by that company to manipulate the inputfields.
Related
To set string #Input() properties of the component, we can use two type of syntax:
<my-component caption="Hello there" type="primary" someThing="text value"></my-component>
OR:
<my-component [caption]="'Hello there'" [type]="'primary'" [someThing]="'text value'"></my-component>
I'm fully aware of the differences between those two types of bindings. The question is: If I have bunch of string #Input() properties that I want to set statically, can I use simple attribute binding syntax (first example) than more "meaty" property binding syntax (second example)?
What is the recommendation, and why? I.e. what are the trade-offs and is it preferable to use property-binding always, even for setting static string inputs?
Here are the few drawbacks I can think of:
Attribute bindings are actually applied as HTML attributes, and e.g.
user can see/alter them via browser's dev tools easily. Property
bindings are not part of the markup.
Attribute bindings might collide
with actual HTML attribute names (unless you prefix them with data-
which defeats the whole purpose of simplicity). Actual example that
already bit me is title attribute.
There is no intellisense in markup for attribute bindings with Angular Language Service.
But the major advantage is the simplicity. In the example above, you would agree that the first form is more elegant. In my projects it seems that big number of properties are constant (one-time-set) string properties, and the syntax makes actual difference in readability.
So... Is it a bad practice to use attribute-binding syntax for custom (non-HTML) string properties? (Given the fact that I'm aware/ok with above listed few limitations)
These are a couple of things I like to add:
Attributes are just plain static fields.
There is a fine line when attributes become properties.
Simplicity is not the goal here, modularity and reuse-ability is.
Property binding give you more control in your component and you can use a component in any like any data-driven or static scenario.
One component build right with property binding can be used in 20 different projects.
But if you got no such requirement then you can use attributes. They are fine.
I will not say which one is better, both have their use cases but overall property bindings are lot more powerful and flexible.
And last thing I like to mention for all readers:
In front-end development any one can modify the code. We use
validations just to provide a smooth user experience. Other than that
any one can get the code or alter HTML if they want to, that's why we
use server side validations. Angular pipe line is complex but
hack-able. A user can wrap a JSON object and send it to server
bypassing all our validations. So for all readers who are new front-end
devs, we don't bother too much about security, we try our best to give
a good user experience.
I have a doubt about good practices writing HTML with Javascript.
I've came up with an idea (probably not the first, but couldn't find a clear reference about that) to mark some elements as candidates to load some data when it's available (after some user interaction). Let me exemplify:
Suppose I have a request that returns the following:
GET /animals/dog
{
name: "Gutemberg",
race: "doberman",
age: "2y"
}
The code I wrote binds fields in the response to elements that are candidates to load such value.
For example: With the request above, I could use the following tags:
<input name="dog-name-field" data-load-dog-name type="text"/>
<input name="dog-age-hid" data-load-dog-age type="hidden"/>
Each tag would receive the property value because it's marked as a candidate to do so - dog-name-field will have a value of "Gutemberg" when everything executes . That will happen everytime the request is reloaded. For now, I just get the data type I've searched ("dog"), concat it with the property "name/age" to form the attribute data-load-type-property and set a value to everyone that has such attribute.
I have a feeling that attributes are not meant to be used just like that, but I'm not aware of any real downsides to that. As I could not find it for the lack of a clear name to this approach, I'd like some guidance.
Is there a name for such technique? Is it a bad practice? If so, why?
PS:
To comply with SO good practices, I'd like the answers to be reference-guided and not based solely on opinion whenever possible. If no reference is provided, please, let us have a solid, well described example.
I have a feeling that attributes are not meant to be used just like that
Let's see what custom data attributes are meant to be used for:
Custom data attributes are intended to store custom data private to
the page or application, for which there are no more appropriate
attributes or elements. These attributes are not intended for use by
software that is independent of the site that uses the attributes.
(from w3.org)
So whether using data-attributes is "appropriate" in your case depends on your needs: if the DOM API doesn't provide better attributes to do that then it's appropriate.
If your need is just to select some element to change the textContent then you have two more appropriate/simpler options:
1) Using the id attribute if your elements are going to be unique in the document
The id global attribute defines a unique identifier (ID) which must be
unique in the whole document. Its purpose is to identify the element
when linking (using a fragment identifier), scripting, or styling
(with CSS).
(from id on MDN)
2) Using the class attribute if your elements are going to be used in multiple instances in the document
The class global attribute is a space-separated list of the classes of
the element. Classes allows CSS and Javascript to select and access
specific elements via the class selectors or functions like the DOM
method document.getElementsByClassName.
(from class on MDN)
As #Supr says in his answer, what you are doing is a very simple implementation of data-binding. data-binding can involve a lot more complexity than what you are doing at the moment; for example you may want to:
keep in sync your UI with a Javascript object which represent your business model instead of directly injecting data coming from an Ajax call,
update other attributes (value, style) and not only innerHTML or textContent,
have your business model updated in reaction to changes on the UI (two way data binding)
To implement all these features, simple id and class selectors are not sufficient, and this is why frameworks which implement data-binding, like KnockoutJS or AngularJS, use the more flexible data-* attributes instead (AngularJS is actually using its own ng-* attributes, but allows to use the alternative data-ng-* syntax for using HTML validation tools).
Data attributes allow to describe much more complex bindings:
<input data-bind="visible: editing, value: name, hasFocus: editing" />
Check KnockoutJS documentation for the meaning of the above code, it is not relevant to this example but just imagine describing that with classes or ids, it wouldn't be very convenient.
TL;DR
If you don't plan to implement more complex features you might want to use class and id instead.
This is called binding. Sometimes data binding and sometimes template binding.
Various frameworks provide mechanisms for this, though the syntax varies.
AngularJS example:
<input ng-model="dog.name" />
Knockout example:
<input data-bind="textInput: dog.name" />
React example:
<input value={this.state.dog.name} />
These are all quite popular frameworks/libraries, so I think it's safe to say it is not considered bad practice. The main difference from your approach is that they use the value of the attribute to specify the reference into the model (i.e. the "dog.name" part of your attributes), while you are putting the reference in the attribute name. In practice this is mostly a matter of style. Separating the reference from the "marker" (i.e. "data-load") is perhaps a bit more readable.
I am looking for a way to replace the content of the src attribute for an iframe with a dummy variant containing the original src value (but will not actually fetch anything). I am loading the html code via Ajax so I can change the src-attribute before the code is injected into the DOM - so I don't need help with that part. What I would appreciate feedback on is what to put in the src attribute. There is a related post here discussing what can go in the src attribute, but in contrast to this post, I want to store data (namely the original src value) so that I can extract it later. It seems the alternatives are:
src="javascript:/*http://originalsrcvalue.com*/"
src="about:blank/*http://originalsrcvalue.com*/"
src="#http://originalsrcvalue.com"
I am leaning towards the last variant using bookmarks. I'm looking for feedback on potential problems or cross-browser issues that might arise or suggestions for alternative solutions.
Edit: One way of addressing the problem is to use custom attributes - and this is probably what I'll end up using in this specific case. However, I would also like feedback on ways to store data in src-tags in the fashion showed above.
You could store the actual URL to a data-your-data-name attribute and fetch it with Javascript when you need it, by doing element.getAttribute('data-your-data-name') or if you don't care much about IE users, by element.dataset.yourDataName
References:
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Using_data_attributes
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/dataset
I am building a multilingual website and I was wondering how is set the default value of a submit button?
Is it something browser specific or does it rely on the system language or both?
ie : I'm just asking if I've to set a specific value according to the language of the page or if it will be done automatically?
I've been unable to find anything about that in the w3c specs.
Thanks!
The HTML 4.01 specification is rather vague about this, but the HTML5 CR is more explicit. It says, in the description of <input type=submit>: “If the element has a value attribute, the button's label must be the value of that attribute; otherwise, it must be an implementation-defined string that means "Submit" or some such.” This does not specify that the string should be language-dependent in any sense, but in practice it usually depends on the language of the browser.
The conclusion that you should always set the value attribute, to make sure it is in the language of the page and, moreover, that it is informative. Quite often, a generic name that means “submit” is too abstract.
On the technical side, the value of a submit button is undefined if there is no value attribute. This means that the getAttribute() method yields null and the value property of the element node is the empty string. However, on form submission, browsers in practice act as if the value were the string that they use as button label.
If a value is missing, the browser will place it there (in the language that the browser is in).
So assuming you don't know the language of the browser, it's best to just set the value attribute yourself.
Also, it's more consistent to have a translation for every text used in the website (which includes buttons).
I've faced two strange attributes of an html tag . They are "data-url" and "data-key".
What are they and how can they be used?
For some reasons i can't show the exact example of the HTML file I've found them in, but here are some examples from the web with such tags:
data-key
data-key
data-url
PS: I've tried to Google, but no useful results were found.
When Should I Use the Data Attribute?
Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements.
This time the data attribute is used to indicate the bubble value of the notification bubble.
Profile
This time is used to show the text for the tooltip.
This is the link
When Shouldn’t I Use the Data Attribute?
We shouldn’t use data attributes for anything which already has an already established or more appropriate attribute. For example it would be inappropriate to use:
<span data-time="20:00">8pm<span>
when we could use the already defined datetime attribute within a time element like below:
<time datetime="20:00">8pm</time>
Using Data Attributes With CSS (Attribute selectors)
[data-role="page"] {
/* Styles */
}
Using Data Attributes With jQuery (.attr())
Google
$('.button').click(function(e) {
e.preventDefault();
thisdata = $(this).attr('data-info');
console.log(thisdata);
});
Examples and info from here
Those are called HTML5 Custom Data attributes.
Custom data attributes are intended to store custom data private to
the page or application, for which there are no more appropriate
attributes or elements. These attributes are not intended for use by
software that is independent of the site that uses the attributes.
Every HTML element may have any number of custom data attributes
specified, with any value.
The reason why you can't find it in Google is because those attribute are custom attributes generated by user for their own usage.
From seeing your code it seems:
The person who has written this code, wants to store some additional
information with the elements. Not sure he may handle this in
Javascript too.
What you should do is to check the Javascript code completely,
whether he is handling those data attributes or if possible check
with him.
Since you code is using jQuery library, check for .data()
method. After a complete code review, if you find it has no use,
then feel free to remove.
data-* attributes are for adding arbitrary data to an element for use solely by the code (usually client side JavaScript) running on the site hosting the HTML.
In order to tell what the three examples you give are for, we would have to reverse engineer the code that comes with them (unless they are documented on the sites) since they don't have standard meanings.
A new feature being introduced in HTML 5 is the addition of custom data attributes. Simply, the specification for custom data attributes states that any attribute that starts with “data-” will be treated as a storage area for private data (private in the sense that the end user can’t see it – it doesn’t affect layout or presentation). This allows you to write valid HTML markup (passing an HTML 5 validator) while, simultaneously, embedding data within your page. A quick example:
<li class="user" data-name="John Resig" data-city="Boston"
data-lang="js" data-food="Bacon">
<b>John says:</b> <span>Hello, how are you?</span>
</li>