We Keep Coding

How can a custom attribute of a component be accessed? (Angular 5)

I've got a component called phrase, which is used like this:
<phrase *ngFor="let phrase of phraseList.phrases" [attachedPhrase]="phrase"></phrase>
Let's say now, I get one of these phrase components using jQuery. How do I access attachedPhrase?

[attachedPhrase] is not an attribute but property binding. It is supposed to be available only inside Angular application.
Although it's possible to access it as ng-reflect-* attribute, this can be recommended only for debugging purposes (this is the reason why these attributes are available in debugging mode only).
Considering that phrase is a string and attachedPhrase should be available both as component input and DOM attribute, it should be changed to attribute binding:
<phrase *ngFor="let phrase of phraseList.phrases" attachedPhrase="{{ phrase }}"></phrase>
Since attributes are case insensitive, it will be compiled to
<phrase attachedphrase="..."></phrase>
Property and attribute bindings can be interchangeable, but only if the expression is expected to be interpolated to a string.
Whenever possible, it's always preferable to not rely on DOM selectors and provide $(...) with actual reference to DOM element (nativeElement property of ViewChild or ElementRef element reference).

You can try: [attr.attachedPhrase]="'phase'".
Detailed info you can check out this site about Angular 5 directive.

HTML: Can always the same identifier be used for name and id attributes?

Basically the "name" attribute is used in server-side programming (name/value pairs are sent in requests) and the "id" attribute is used in client-side programming (i.e. Javascript and CSS).
But both fulfill essentially the same function - provide a unique identification of an element. And to complicate things not too much, it is useful if a thing has only one identifier.
Therefore the question(s) - for tags that need both "id" and "name":
Is there any reason to choose different identifiers for the name and id attributes? Are there any use-cases for which different identifiers are required? Are there any differences in syntax? (for example you can use "myarray[123]" for the name attribute and PHP will understand that correctly and create an array, can that also be used in a similar manner for id-attributes in Javascript or CSS - and if not, is that a syntax-error or is it simply a valid identifier with brackets in it?) Are both case-sensitive?

Is there any reason to choose different identifiers for the name and id attributes?
Yes. IDs must be unique, names don't have to be. Names must be the same for members of a radio group, so they can't all have the same id—well, they can in practice but accessing the elements by ID will be problematic. And if you don't access them by ID, why have it?
Are there any use-cases for which different identifiers are required?
Yes, radio buttons. Only one can have an id that is the same as its name. But otherwise, there are few restrictions, such as than never give form controls the name or id of a method or property of the form itself, like "submit", as it will mask the same–named property of the form.
Also, names "_charset_" and "isindex" are special.
Are there any differences in syntax? (for example you can use "myarray[123]" for the name attribute and PHP will understand that correctly and create an array, can that also be used in a similar manner for id-attributes in Javascript or CSS - and if not, is that a syntax-error or is it simply a valid identifier with brackets in it?)
Yes. The rules for name and id attribute values are similar but an ID must not contain spaces (and some values for name are special, see above). There were more restrictions on id attributes in HTML4 (e.g. ids couldn't start with a number), but in practice they weren't implemented in browsers.
Some characters that are valid in names and ids must be quoted to use as CSS selectors, e.g. for:
<div id="d[]">
the CSS selector is:
#d\[\]
and for use with the Selectors API:
#d\\[\\]
(e.g. document.querySelector('#d\\[\\]').
Are both case-sensitive?
Yes.

To answer the question in the title: Yes, whenever the syntax of an element allows a name attribute, its value may be identical with the id attribute value. This follows from the declarations of the name attribute: its value is any string, and the only constraint imposed relates to the a element; and for it, the requirement is that the name attribute value must not match the id attribute value of another element (but must match the id attribute value of the same element if present).
To address the assumptions in the question: The name attribute in form field elements is indeed primarily for server-side processing; but various other elements may have a name attribute, for different uses. The id attribute is helpful in client-side programming, but it also has the effect of creating a destination anchor so that the element can be referred to by a link in the same document or another document. There is technically no tag that “needs” both id and name, or even one of them; whether they are used depends on practical purposes. The name attribute is not required to be unique, and it is not meant to provide unique identification. You can, for example, have an arbitrary amount of input elements with the same name attribute.
The syntax of id has traditionally been restricted in HTML specifications, but browsers have been much more permissive, and HTML5 PR imposes no other restrictions than the following: the value must not be empty (i.e. it must contain at least one character), it must not contain space characters, and it must be unique within the document (i.e. no two elements can have the same id attribute value).
The syntax of name has always been free. Apart from the special rules for the a element, the only restriction is that the value must not be empty.
Both id and name attribute values are case-sensitive. The special rules for the a element impose restrictions involving case-insensitivity, for legacy reasons.
There are many possible reasons why you might want to make id and name different for an element. For example, when interfacing to an existing server-side script that requires very long and complicated names for the fields, you have to use them in name attributes, but you are free to choose your id attributes.
The choices made when writing id and name attribute values have their consequences, but they depend on the contexts where the values are used. For example, if an id attribute value starts with a digit, it cannot be directly used in a CSS selector due to CSS syntax (but must be escaped). Similarly, the ways you can use the values in JavaScript depend on the syntax you have used, but you can always refer to them some way.

name attribute usually doesn't need to be unique. A given HTML document may have several forms, and each of them might have elements having names identical to names in the other forms.
If you're using PHP, saying:
<form>
<input type="text" name="foo[]" />
<input type="text" name="foo[]" />
</form>
would cause, PHP to read this name as array and all entries will contained within it. Names could possibly be used as attributes for non-form elements, however, they're most frequently used only within form.
id attribute on the other hand, needs to be able to uniquely identify a given DOM element within the document. You're not forced to use it this way. Browser doesn't blow up if you use same id on two different elements. But if you have two elements with same id, the last one you add prevails over the previous ones. So,
document.getElementById( 'foo' )
// or
$( '#foo' )
will return just one element of several.
id can be used to identify any element within the document and is not constrained to be within a form

Can a DOM element have an attribute whose value is an arbitrary object (not a string)?

I'd like to do something like this:
var elem = document.createElement("input");
elem.setAttribute("my-attribute", myObject);
document.getElementById("parent").appendChild(elem);
Later I will need to fetch myObject when performing some actions on this (and similar) element(s).
Note: I need this as an attribute (and not, for example, as a member of the element object, as in elem.myAttribute = myObject), as for some elements the value is a string which is hard-coded into the HTML of the page. What I need is the ability to set this attribute programmatically for other elements, and to use values which are not always plain strings.
I tried this and it worked in my browser (Firefox 14), but I need to know if this works cross-browser, and also if I'll be able to fetch the values of such attributes using jQuery if I decide to use jQuery in my page later on.

No - attributes by definition store string values. The obvious approach is to store the object as a property but you say that's not suitable.
Either:
1) Use jQuery's data API (since it does not literally log the data on the element, so you can store whatever you want, not only strings)
2) Stringify the object and append that to the element as an HTML5 data attribute.
var elem = document.querySelector('p'),
obj = {foo: 'bar'};
elem.setAttribute('data-myObj', JSON.stringify(obj));
/* ...then, later... */
var data = JSON.parse(elem.getAttribute('data-myObj'));
Note, though, that, because we're dealing with JSON, you will not be able to store methods as part of this object. They will be stripped out by JSON.stringify().
Finally, using attributes means you'll muddy your HTML since they show up in any HTML dumps (unlike properties) but this is purely a cosmetic weakness.

You can use the data attribute in jquery to do this (http://api.jquery.com/data/)
You can use html 5 data attributes:
http://ejohn.org/blog/html-5-data-attributes/
And these can be retrieved using the jquery data api.
These will have to be stringifed however
"As of jQuery 1.4.3 HTML 5 data- attributes will be automatically pulled in to jQuery's data object"

Unique identifier for HTML elements

Besides the ID, if you say you want a unique identifier for an HTML element (let’s say a div).
I browsed the DOM for something (like a number or string) that was unique for each element; but the DOM was big and I failed to find that on the Internet.
Is there a property (in the DOM obviously) that is unique only to that element? (Other than the ID and also you don't specify it, but it comes when the DOM is constructed.)

Depending on the objective, here are two suggestions.
Unless you actually need to express the id as some kind of string, you can save the normal DOM reference.
If you do need to express it as a string for some reason, then you'll need to assign a unique id yourself.
var getId = (function () {
var incrementingId = 0;
return function(element) {
if (!element.id) {
element.id = "id_" + incrementingId++;
// Possibly add a check if this ID really is unique
}
return element.id;
};
}());

The only other identifier I can think of is the XPath of the element in the document.
For instance, the title link inside the heading of this very page has an XPath of
/html/body/div[3]/div[2]/div/h1/a
But like Pekka already said, it depends on what you want to do. And I don’t think you can get the XPath easily from the DOM in JavaScript, despite XPath being available nowadays in JavaScript engines.

Internet Explorer has a property, "uniqueID", for every element. The problem is that the other browsers don't support it.

You can use a library or roll your own to create a unique identifier. jQuery has .data():
Store arbitrary data associated with the matched elements or return
the value at the named data store for the first element in the set of
matched elements.

I just encountered the same situation, and while I was looking into some DOM elements in the Chrome developer tools inspector, I noticed that they all seem to have a property like jQuery11230892710877873282 assigned with a unique number.
Obviously the number after 'jQuery' is different every time you load the page. My guess is that jQuery is generating this internally every time it tries to access or manipulate any DOM element.
I played a little bit with it, and it looks like elements that are never accessed/manipulated by jQuery may not have this property, but the moment you do something like $(elem), the property will be there. So, since we're using both jQuery and Lodash, I devised the following function to return a unique ID regardless of whether the element actually has a DOM id attribute.
_.reduce(
$(elem),
function(result, value, key) {
if(_.startsWith(key, 'jQuery'))
return value;
},
0)

There is the name attribute that can be addressed by document.getElementByName.
I don't think other unique identifiers exist - even though you could simulate one by setting a property (like title) to a unique value, and then query for that. But that is kludgy.

Javascript appendChild name property

So I'm trying to add attributes to a radio button input, specifically the name attribute in Javascript. I'm appending children to a main object and when I use Object.setAttribute("name", value); and subsequently check the innerHTML of the appended input, it does not even contain a name property at all!
I'm guessing I'm missing something simple or there is a way around it but I've been wrestling with this problem for quite a while with no success. I tried accessing the property directly using Object.name = value and Object.nodeName = value (that one was a random try).
Is there some sort of problem in which IE6's javascript rendering engine does not recognize setAttribute("name", value)? Is there a way around it?

Here's a workaround for dealing with IE:
http://javascript.about.com/library/bliebug2.htm
http://www.thunderguy.com/semicolon/2005/05/23/setting-the-name-attribute-in-internet-explorer/
Essentially, the method used is to create the elements on the fly instead of modifying existing elements.

In IE, you cannot add a name attribute on dynamically created objects.
I suggest using id if unique, or a class if not.