Types of child - elements, text. Getting children, count, basic navigation through them.
Link back to parent
Common properties - class, classList, id, direct attributes, get/set/remove any attribute, data attributes, style
Originally created by @bendtherules on GitHub (Oct 28, 2020).
Original GitHub issue: https://github.com/bendtherules/UiQuestions/issues/4
Originally assigned to: @bendtherules on GitHub.
Include topics like -
1. How to identify by tagname?
2. Types of child - elements, text. Getting children, count, basic navigation through them.
3. Link back to parent
4. Common properties - class, classList, id, direct attributes, get/set/remove any attribute, data attributes, style
@bendtherules.
Before you start writing the docs for the same, it would be good to collate the sections and sub-sections here for the same. What you say ? For instance, we have 2 main sections in DOM Manipulation and 8 sub-sections spread across both.
<!-- gh-comment-id:718094063 -->
@lakbychance commented on GitHub (Oct 28, 2020):
@bendtherules.
Before you start writing the docs for the same, it would be good to collate the sections and sub-sections here for the same. What you say ? For instance, we have 2 main sections in DOM Manipulation and 8 sub-sections spread across both.
Yes, that would be good. I added the section topics above. Can figure out the exact names.
What else should we add here?
This page is mostly about element attribute and properties of any element dom object - useful for filtering, traversal, checking, etc. It follows from our last page where we wrote how to create the basic structure.
<!-- gh-comment-id:718096172 -->
@bendtherules commented on GitHub (Oct 28, 2020):
Yes, that would be good. I added the section topics above. Can figure out the exact names.
What else should we add here?
This page is mostly about element attribute and properties of any element dom object - useful for filtering, traversal, checking, etc. It follows from our last page where we wrote how to create the basic structure.
Need to get some clarifications on the same too :-
How to identify by tagname?
Is this about the selector types ? Like "#id", ".class" , "[attribute=blabla]", "html_tag" ?
Types of child - elements, text. Getting children, count, basic navigation through them.
HTML element and text node, children vs childnodes, firstChild,lastChild,firstChildElement,lastChildElement.
Navigation would be iterating through them I believe ?.
Link back to parent
Couldn't understand this one ?
Common properties - class, classList, id, direct attributes, get/set/remove any attribute, data attributes, style
Do we clear out the attribute vs DOM property stuff here ? Or just show usage of few attributes and few DOM properties as per interview perspective ?
<!-- gh-comment-id:718102730 -->
@lakbychance commented on GitHub (Oct 28, 2020):
Need to get some clarifications on the same too :-
> How to identify by tagname?
Is this about the selector types ? Like "#id", ".class" , "[attribute=blabla]", "html_tag" ?
> Types of child - elements, text. Getting children, count, basic navigation through them.
HTML element and text node, children vs childnodes, firstChild,lastChild,firstChildElement,lastChildElement.
Navigation would be iterating through them I believe ?.
> Link back to parent
Couldn't understand this one ?
> Common properties - class, classList, id, direct attributes, get/set/remove any attribute, data attributes, style
Do we clear out the attribute vs DOM property stuff here ? Or just show usage of few attributes and few DOM properties as per interview perspective ?
Yes, i think I'll add bit more details. It sounded clear in my head 😅.
How to identify by tagname? - ele.tagName property gives "div"
Yes, what you said.
ele.parent property (traverse to parent)
Hmm, maybe not everything. But i think keeping properties and common
attributes together makes sense - because attributes are available as
property on dom object.
Maybe the common ones here - atleast class, id, data and then a generic
one. (style not so important)
Need to get some clarifications on the same too :-
How to identify by tagname?
Is this about the selector types ? Like "#id", ".class" ,
"[attribute=blabla]", "html_tag" ?
Types of child - elements, text. Getting children, count, basic navigation
through them.
HTML element and text node, children vs childnodes,
firstChild,lastChild,firstChildElement,lastChildElement.
Navigation would be iterating through them I believe ?.
Link back to parent
Couldn't understand this one ?
Common properties - class, classList, id, direct attributes,
get/set/remove any attribute, data attributes, style
Do we clear out the attribute vs DOM property stuff here ? Or just show
usage of few attributes and few DOM properties as per interview perspective
?
<!-- gh-comment-id:718108511 -->
@bendtherules commented on GitHub (Oct 28, 2020):
Yes, i think I'll add bit more details. It sounded clear in my head 😅.
1. How to identify by tagname? - ele.tagName property gives "div"
2. Yes, what you said.
3. ele.parent property (traverse to parent)
4. Hmm, maybe not everything. But i think keeping properties and common
attributes together makes sense - because attributes are available as
property on dom object.
Maybe the common ones here - atleast class, id, data and then a generic
one. (style not so important)
On Wed, 28 Oct, 2020, 11:18 pm Lakshya Thakur, <notifications@github.com>
wrote:
> Need to get some clarifications on the same too :-
>
> How to identify by tagname?
>
> Is this about the selector types ? Like "#id", ".class" ,
> "[attribute=blabla]", "html_tag" ?
>
> Types of child - elements, text. Getting children, count, basic navigation
> through them.
>
> HTML element and text node, children vs childnodes,
> firstChild,lastChild,firstChildElement,lastChildElement.
> Navigation would be iterating through them I believe ?.
>
> Link back to parent
>
> Couldn't understand this one ?
>
> Common properties - class, classList, id, direct attributes,
> get/set/remove any attribute, data attributes, style
>
> Do we clear out the attribute vs DOM property stuff here ? Or just show
> usage of few attributes and few DOM properties as per interview perspective
> ?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/bendtherules/UiQuestions/issues/4#issuecomment-718102730>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAXVDXT66O2PBSRJMCSBCCTSNBKN3ANCNFSM4TCRAHNQ>
> .
>
Adding you as a collaborator.
We can keep the process like this for both of us - create issue, PR for any new page/major change, approve to merge.
Small typos and fixes can be done directly on main.
<!-- gh-comment-id:718760748 -->
@bendtherules commented on GitHub (Oct 29, 2020):
Adding you as a collaborator.
We can keep the process like this for both of us - create issue, PR for any new page/major change, approve to merge.
Small typos and fixes can be done directly on main.
☝️ How is this note looking? Too big? The information seems important for the following content and why they are important, but idk.
<!-- gh-comment-id:719586561 -->
@bendtherules commented on GitHub (Oct 30, 2020):
https://4-element-properties--uiquestions.netlify.app/docs/element-properties/#children
☝️ How is this note looking? Too big? The information seems important for the following content and why they are important, but idk.
TBH, I have actually thinking about the 30 mins before interview thing and also took some feedback from one of my friends. Based on that , we are still making things concise for a person to refer but since we are also trying to clarify stuff like you did above, I think it's more like a revision days tool (not the interview day tool). Plus most of the stuff we might discuss here will allow person to know DOM api's and stuff to build small apps asked during frontend interviews.
If it's meant to be truly 30 mins before interview then those would be mostly like so:-
Question What is blabla stuff (Very specific yet recurring question asked in a frontend interview) ?
Answer This is blabla stuff.
I feel ours is concise docs which is great but not "30 mins" tool.
Let me know your thoughts on this. I feel it's important to clear this out.
<!-- gh-comment-id:719603515 -->
@lakbychance commented on GitHub (Oct 30, 2020):
I think it's a necessary distinction to know.
TBH, I have actually thinking about the 30 mins before interview thing and also took some feedback from one of my friends. Based on that , we are still making things concise for a person to refer but since we are also trying to clarify stuff like you did above, I think it's more like a revision days tool (not the interview day tool). Plus most of the stuff we might discuss here will allow person to know DOM api's and stuff to build small apps asked during frontend interviews.
If it's meant to be truly 30 mins before interview then those would be mostly like so:-
> Question What is blabla stuff (Very specific yet recurring question asked in a frontend interview) ?
> Answer This is blabla stuff.
I feel ours is concise docs which is great but not "30 mins" tool.
Let me know your thoughts on this. I feel it's important to clear this out.
"30 mins" thing is more of a tagline for conciseness - you can't lookup everything in that time, but if you know what you want - you can quickly find and read it. It's just like saying we won't waste your time - the topics are curated from what is needed in a typical task. (we can clarify this in readme, i guess - but good to know for the editors.)
Like I added all that details because sometimes i got stuck when during interview - childNodes started returning empty text nodes - which were a pain to deal with.
<!-- gh-comment-id:719607299 -->
@bendtherules commented on GitHub (Oct 30, 2020):
Yeah, what you said makes sense.
"30 mins" thing is more of a tagline for conciseness - you can't lookup everything in that time, but if you know what you want - you can quickly find and read it. It's just like saying we won't waste your time - the topics are curated from what is needed in a typical task. (we can clarify this in readme, i guess - but good to know for the editors.)
Like I added all that details because sometimes i got stuck when during interview - `childNodes` started returning empty text nodes - which were a pain to deal with.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @bendtherules on GitHub (Oct 28, 2020).
Original GitHub issue: https://github.com/bendtherules/UiQuestions/issues/4
Originally assigned to: @bendtherules on GitHub.
Include topics like -
@lakbychance commented on GitHub (Oct 28, 2020):
@bendtherules.
Before you start writing the docs for the same, it would be good to collate the sections and sub-sections here for the same. What you say ? For instance, we have 2 main sections in DOM Manipulation and 8 sub-sections spread across both.
@bendtherules commented on GitHub (Oct 28, 2020):
Yes, that would be good. I added the section topics above. Can figure out the exact names.
What else should we add here?
This page is mostly about element attribute and properties of any element dom object - useful for filtering, traversal, checking, etc. It follows from our last page where we wrote how to create the basic structure.
@lakbychance commented on GitHub (Oct 28, 2020):
Need to get some clarifications on the same too :-
Is this about the selector types ? Like "#id", ".class" , "[attribute=blabla]", "html_tag" ?
HTML element and text node, children vs childnodes, firstChild,lastChild,firstChildElement,lastChildElement.
Navigation would be iterating through them I believe ?.
Couldn't understand this one ?
Do we clear out the attribute vs DOM property stuff here ? Or just show usage of few attributes and few DOM properties as per interview perspective ?
@bendtherules commented on GitHub (Oct 28, 2020):
Yes, i think I'll add bit more details. It sounded clear in my head 😅.
How to identify by tagname? - ele.tagName property gives "div"
Yes, what you said.
ele.parent property (traverse to parent)
Hmm, maybe not everything. But i think keeping properties and common
attributes together makes sense - because attributes are available as
property on dom object.
Maybe the common ones here - atleast class, id, data and then a generic
one. (style not so important)
On Wed, 28 Oct, 2020, 11:18 pm Lakshya Thakur, notifications@github.com
wrote:
@bendtherules commented on GitHub (Oct 29, 2020):
Adding you as a collaborator.
We can keep the process like this for both of us - create issue, PR for any new page/major change, approve to merge.
Small typos and fixes can be done directly on main.
@lakbychance commented on GitHub (Oct 29, 2020):
@bendtherules Awesome ✌️.
@bendtherules commented on GitHub (Oct 30, 2020):
https://4-element-properties--uiquestions.netlify.app/docs/element-properties/#children
☝️ How is this note looking? Too big? The information seems important for the following content and why they are important, but idk.
@lakbychance commented on GitHub (Oct 30, 2020):
I think it's a necessary distinction to know.
TBH, I have actually thinking about the 30 mins before interview thing and also took some feedback from one of my friends. Based on that , we are still making things concise for a person to refer but since we are also trying to clarify stuff like you did above, I think it's more like a revision days tool (not the interview day tool). Plus most of the stuff we might discuss here will allow person to know DOM api's and stuff to build small apps asked during frontend interviews.
If it's meant to be truly 30 mins before interview then those would be mostly like so:-
I feel ours is concise docs which is great but not "30 mins" tool.
Let me know your thoughts on this. I feel it's important to clear this out.
@bendtherules commented on GitHub (Oct 30, 2020):
Yeah, what you said makes sense.
"30 mins" thing is more of a tagline for conciseness - you can't lookup everything in that time, but if you know what you want - you can quickly find and read it. It's just like saying we won't waste your time - the topics are curated from what is needed in a typical task. (we can clarify this in readme, i guess - but good to know for the editors.)
Like I added all that details because sometimes i got stuck when during interview -
childNodesstarted returning empty text nodes - which were a pain to deal with.