Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #38158 > unrolled thread

HTML dom "document parent, child notation"

Back to article view | Back to comp.lang.javascript

Contents

  HTML dom "document parent, child notation" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-01-27 23:18 -0800
    Re: HTML dom "document parent, child notation" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-01-27 23:22 -0800
      Re: HTML dom "document parent, child notation" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-01-27 23:47 -0800
        Re: HTML dom "document parent, child notation" dr.j.r.stockton@gmail.com - 2020-01-28 01:37 -0800
          Re: HTML dom "document parent, child notation" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-01-28 01:59 -0800
      Re: HTML dom "document parent, child notation" JJ <jj4public@vfemail.net> - 2020-01-28 18:43 +0700
        Re: HTML dom "document parent, child notation" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-01-28 03:52 -0800
          Re: HTML dom "document parent, child notation" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-01-28 03:59 -0800
            Re: HTML dom "document parent, child notation" JJ <jj4public@vfemail.net> - 2020-01-29 20:07 +0700
              Re: HTML dom "document parent, child notation" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-02-05 08:02 -0800
                Re: HTML dom "document parent, child notation" "R.Wieser" <address@not.available> - 2020-02-06 12:50 +0100
              Re: HTML dom "document parent, child notation" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-02-05 08:05 -0800
              Re: HTML dom "document parent, child notation" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-02-05 08:06 -0800
    Re: HTML dom "document parent, child notation" "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2020-01-28 05:17 -0800
      Re: HTML dom "document parent, child notation" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-01-28 17:54 -0800
    Re: HTML dom "document parent, child notation" Arno Welzel <usenet@arnowelzel.de> - 2020-01-28 15:25 +0100

#38158 — HTML dom "document parent, child notation"

What is the justification for using the parent child notation between documents that is loaded from same source, for example iframes?

What is the idea behind it, why is it there?

[toc] | [next] | [standalone]

#38159

Den tisdag 28 januari 2020 kl. 08:18:34 UTC+1 skrev Jonas Thörnvall:
> What is the justification for using the parent child notation between documents that is loaded from same source, for example iframes?
> 
> What is the idea behind it, why is it there?

Is it because element ID's could have same ID?
There is something that bugs me about the whole thing.
It seems unnecessary, it is just a bunch of connected text and everything in it have ID, the iframe have it all the elements have it, so why would i need to specify a document source, for my variables, functions and elements.

[toc] | [prev] | [next] | [standalone]

#38160

Den tisdag 28 januari 2020 kl. 08:22:42 UTC+1 skrev Jonas Thörnvall:
> Den tisdag 28 januari 2020 kl. 08:18:34 UTC+1 skrev Jonas Thörnvall:
> > What is the justification for using the parent child notation between documents that is loaded from same source, for example iframes?
> > 
> > What is the idea behind it, why is it there?
> 
> Is it because element ID's could have same ID?
> There is something that bugs me about the whole thing.
> It seems unnecessary, it is just a bunch of connected text and everything in it have ID, the iframe have it all the elements have it, so why would i need to specify a document source, for my variables, functions and elements.

One should not add complexity where ther is no need for it...

[toc] | [prev] | [next] | [standalone]

#38161

On Tuesday, 28 January 2020 07:47:18 UTC, Jonas Thörnvall  wrote:

> One should not add complexity where ther is no need for it...

That is why you should post the text of your articles in your preferred flavour of Scandiwegian in addition to posting in your inaccurate version of English.

Some of us may be able to read Scandiwegian; I have a neighbour who can do so.  And Google Translate will at least provide a second opinion on what you are actually trying to say.


-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#38162

Den tisdag 28 januari 2020 kl. 10:37:18 UTC+1 skrev dr.j.r...@gmail.com:
> On Tuesday, 28 January 2020 07:47:18 UTC, Jonas Thörnvall  wrote:
> 
> > One should not add complexity where ther is no need for it...
> 
> That is why you should post the text of your articles in your preferred flavour of Scandiwegian in addition to posting in your inaccurate version of English.
> 
> Some of us may be able to read Scandiwegian; I have a neighbour who can do so.  And Google Translate will at least provide a second opinion on what you are actually trying to say.
> 
> 
> -- 
>   (c) John Stockton, near London, UK.  Using Google Groups.           |
>  Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

Well train your brain fill in the blanks, unfortunately there is no easy way to fill in the blanks for blatant mistakes like hieroglyphic encodings and over declared monkey syntax "it just is there".

[toc] | [prev] | [next] | [standalone]

#38164

On Mon, 27 Jan 2020 23:22:36 -0800 (PST), Jonas Thörnvall wrote:
> Den tisdag 28 januari 2020 kl. 08:18:34 UTC+1 skrev Jonas Thörnvall:
>> What is the justification for using the parent child notation between
>> documents that is loaded from same source, for example iframes?
>> 
>> What is the idea behind it, why is it there?

Because DOM nodes are connected hierarchically. Elements are extensions of
nodes, and attributes are just "properties" of an element - meaning that
they may not be present in a document.

> Is it because element ID's could have same ID?
> There is something that bugs me about the whole thing.
> It seems unnecessary, it is just a bunch of connected text and everything
> in it have ID, the iframe have it all the elements have it, so why would
> i need to specify a document source, for my variables, functions and
> elements.

JavaScript are scoped. DOM nodes are not.

[toc] | [prev] | [next] | [standalone]

#38165

Den tisdag 28 januari 2020 kl. 12:43:23 UTC+1 skrev JJ:
> On Mon, 27 Jan 2020 23:22:36 -0800 (PST), Jonas Thörnvall wrote:
> > Den tisdag 28 januari 2020 kl. 08:18:34 UTC+1 skrev Jonas Thörnvall:
> >> What is the justification for using the parent child notation between
> >> documents that is loaded from same source, for example iframes?
> >> 
> >> What is the idea behind it, why is it there?
> 
> Because DOM nodes are connected hierarchically. Elements are extensions of
> nodes, and attributes are just "properties" of an element - meaning that
> they may not be present in a document.
> 
> > Is it because element ID's could have same ID?
> > There is something that bugs me about the whole thing.
> > It seems unnecessary, it is just a bunch of connected text and everything
> > in it have ID, the iframe have it all the elements have it, so why would
> > i need to specify a document source, for my variables, functions and
> > elements.
> 
> JavaScript are scoped. DOM nodes are not.

Yeah that is the question why are they connected hiearchly, they are just text masses. I can understand the problem when you take in external sources but why do a developer have to deal with that "unneccesary hierarchy", the hierarchy only needed when linking other sources.

Still to this day one have do eeal with this idiocy, you never see a newspaper have need for such a hierarchy, it is just information with ID dynamic or not really does not matter. 

My point is the hierarchy is totally pointless "at least for a single developer", maybe it is fear of ID clashes different people doing different pages. I am not sure why the hierarchy is there?

[toc] | [prev] | [next] | [standalone]

#38166

Den tisdag 28 januari 2020 kl. 12:52:21 UTC+1 skrev Jonas Thörnvall:
> Den tisdag 28 januari 2020 kl. 12:43:23 UTC+1 skrev JJ:
> > On Mon, 27 Jan 2020 23:22:36 -0800 (PST), Jonas Thörnvall wrote:
> > > Den tisdag 28 januari 2020 kl. 08:18:34 UTC+1 skrev Jonas Thörnvall:
> > >> What is the justification for using the parent child notation between
> > >> documents that is loaded from same source, for example iframes?
> > >> 
> > >> What is the idea behind it, why is it there?
> > 
> > Because DOM nodes are connected hierarchically. Elements are extensions of
> > nodes, and attributes are just "properties" of an element - meaning that
> > they may not be present in a document.
> > 
> > > Is it because element ID's could have same ID?
> > > There is something that bugs me about the whole thing.
> > > It seems unnecessary, it is just a bunch of connected text and everything
> > > in it have ID, the iframe have it all the elements have it, so why would
> > > i need to specify a document source, for my variables, functions and
> > > elements.
> > 
> > JavaScript are scoped. DOM nodes are not.
> 
> Yeah that is the question why are they connected hiearchly, they are just text masses. I can understand the problem when you take in external sources but why do a developer have to deal with that "unneccesary hierarchy", the hierarchy only needed when linking other sources.
> 
> Still to this day one have do eeal with this idiocy, you never see a newspaper have need for such a hierarchy, it is just information with ID dynamic or not really does not matter. 
> 
> My point is the hierarchy is totally pointless "at least for a single developer", maybe it is fear of ID clashes different people doing different pages. I am not sure why the hierarchy is there?

Well maybe something with searchengines and metainformation, but it seem pointless since iframes do not need any.

[toc] | [prev] | [next] | [standalone]

#38185

On Tue, 28 Jan 2020 03:59:43 -0800 (PST), Jonas Thörnvall wrote: 
> Den tisdag 28 januari 2020 kl. 12:52:21 UTC+1 skrev Jonas Thörnvall:
>> 
>> Yeah that is the question why are they connected hiearchly, they are
>> just text masses. I can understand the problem when you take in external
>> sources but why do a developer have to deal with that "unneccesary
>> hierarchy", the hierarchy only needed when linking other sources. 
>> 
>> Still to this day one have do eeal with this idiocy, you never see a
>> newspaper have need for such a hierarchy, it is just information with ID
>> dynamic or not really does not matter. 
>> 
>> My point is the hierarchy is totally pointless "at least for a single
>> developer", maybe it is fear of ID clashes different people doing
>> different pages. I am not sure why the hierarchy is there?
> 
> Well maybe something with searchengines and metainformation, but it seem
> pointless since iframes do not need any.

You only see the surface.

Considering that an element can be within other element, there has to be an
information describing who contains what. Otherwise, elements can't be
within other element.

We're not living in a flat Earth, you know...

[toc] | [prev] | [next] | [standalone]

#38188

Den onsdag 29 januari 2020 kl. 14:07:14 UTC+1 skrev JJ:
> On Tue, 28 Jan 2020 03:59:43 -0800 (PST), Jonas Thörnvall wrote: 
> > Den tisdag 28 januari 2020 kl. 12:52:21 UTC+1 skrev Jonas Thörnvall:
> >> 
> >> Yeah that is the question why are they connected hiearchly, they are
> >> just text masses. I can understand the problem when you take in external
> >> sources but why do a developer have to deal with that "unneccesary
> >> hierarchy", the hierarchy only needed when linking other sources. 
> >> 
> >> Still to this day one have do eeal with this idiocy, you never see a
> >> newspaper have need for such a hierarchy, it is just information with ID
> >> dynamic or not really does not matter. 
> >> 
> >> My point is the hierarchy is totally pointless "at least for a single
> >> developer", maybe it is fear of ID clashes different people doing
> >> different pages. I am not sure why the hierarchy is there?
> > 
> > Well maybe something with searchengines and metainformation, but it seem
> > pointless since iframes do not need any.
> 
> You only see the surface.
> 
> Considering that an element can be within other element, there has to be an
> information describing who contains what. Otherwise, elements can't be
> within other element.
> 
> We're not living in a flat Earth, you know...

Well JJ i think the link whatever it is a pretty good indication about that. But as i say there is no need it could all be same document but broken up. The tag link whatever is just a tool for the server and browser, that the information is part of the same.

[toc] | [prev] | [next] | [standalone]

#38191

Jonas,

> But as i say there is no need it could all be same document but broken up.

What do you expect from us ?   Noone here seems to agree with you.  Worse, 
noone here has the power to change anything about it even if they would 
agree with you, realise that and just use what is offered to them.

But, if you think that your way is that much better, why don't you put your 
money where your mouth is and try to describe a run-of-the-mill webpage with 
it ?

After you've done that you can write a "compiler" (of sorts) to convert that 
into what the current webbrowsers understand, and both you and the rest of 
the world will be happy.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#38189

Den onsdag 29 januari 2020 kl. 14:07:14 UTC+1 skrev JJ:
> On Tue, 28 Jan 2020 03:59:43 -0800 (PST), Jonas Thörnvall wrote: 
> > Den tisdag 28 januari 2020 kl. 12:52:21 UTC+1 skrev Jonas Thörnvall:
> >> 
> >> Yeah that is the question why are they connected hiearchly, they are
> >> just text masses. I can understand the problem when you take in external
> >> sources but why do a developer have to deal with that "unneccesary
> >> hierarchy", the hierarchy only needed when linking other sources. 
> >> 
> >> Still to this day one have do eeal with this idiocy, you never see a
> >> newspaper have need for such a hierarchy, it is just information with ID
> >> dynamic or not really does not matter. 
> >> 
> >> My point is the hierarchy is totally pointless "at least for a single
> >> developer", maybe it is fear of ID clashes different people doing
> >> different pages. I am not sure why the hierarchy is there?
> > 
> > Well maybe something with searchengines and metainformation, but it seem
> > pointless since iframes do not need any.
> 
> You only see the surface.
> 
> Considering that an element can be within other element, there has to be an
> information describing who contains what. Otherwise, elements can't be
> within other element.
> 
> We're not living in a flat Earth, you know...

No apparently we are living on the pumpkin head earth where you can see southern cross from Gran Canaria LoL

[toc] | [prev] | [next] | [standalone]

#38190

Den onsdag 29 januari 2020 kl. 14:07:14 UTC+1 skrev JJ:
> On Tue, 28 Jan 2020 03:59:43 -0800 (PST), Jonas Thörnvall wrote: 
> > Den tisdag 28 januari 2020 kl. 12:52:21 UTC+1 skrev Jonas Thörnvall:
> >> 
> >> Yeah that is the question why are they connected hiearchly, they are
> >> just text masses. I can understand the problem when you take in external
> >> sources but why do a developer have to deal with that "unneccesary
> >> hierarchy", the hierarchy only needed when linking other sources. 
> >> 
> >> Still to this day one have do eeal with this idiocy, you never see a
> >> newspaper have need for such a hierarchy, it is just information with ID
> >> dynamic or not really does not matter. 
> >> 
> >> My point is the hierarchy is totally pointless "at least for a single
> >> developer", maybe it is fear of ID clashes different people doing
> >> different pages. I am not sure why the hierarchy is there?
> > 
> > Well maybe something with searchengines and metainformation, but it seem
> > pointless since iframes do not need any.
> 
> You only see the surface.
> 
> Considering that an element can be within other element, there has to be an
> information describing who contains what. Otherwise, elements can't be
> within other element.
> 
> We're not living in a flat Earth, you know...

Ever heard the phrase knowledgable but not that bright JJ LoL

[toc] | [prev] | [next] | [standalone]

#38169

On Tuesday, January 28, 2020 at 1:18:34 AM UTC-6, Jonas Thörnvall wrote:
> What is the justification for using the parent child notation between documents that is loaded from same source, for example iframes?
> 
> What is the idea behind it, why is it there?

If you're in the same domain (loaded from the same source), you should probably not be using an iframe in the first place. Seems like most of your problems are self inflicted.

[toc] | [prev] | [next] | [standalone]

#38177

Den tisdag 28 januari 2020 kl. 14:18:00 UTC+1 skrev Michael Haufe (TNO):
> On Tuesday, January 28, 2020 at 1:18:34 AM UTC-6, Jonas Thörnvall wrote:
> > What is the justification for using the parent child notation between documents that is loaded from same source, for example iframes?
> > 
> > What is the idea behind it, why is it there?
> 
> If you're in the same domain (loaded from the same source), you should probably not be using an iframe in the first place. Seems like most of your problems are self inflicted.

No i think i asked at leat some 10th of times in this forum how you break up a HTML document into files of logical code pieces.

You know that thing any intelligent desktop publishing program will let you do....

And i beleive most of the answers i got, was to use <iframe>, how can one create a framework for a publishing program where splitting it into subsections "articles/logical content" is not allowed?

It witness about pure madness. Well a desktop publishing program where the framework is totally broken that is what it is.

I mean it is so easy to see what is wrong and need to be done.
There is a framework to put articles in it is called tables. And if you want your content not locked in grid you place it in a div with cordinate position and size.

How fucking hard could it be, locally i could code up a better desktop publishing mockup in a week or two? "Using HTML and Javascript"

[toc] | [prev] | [next] | [standalone]

#38171

On 28.01.20 08:18, Jonas Thörnvall wrote:

> What is the justification for using the parent child notation between
> documents that is loaded from same source, for example iframes?

Example?

> What is the idea behind it, why is it there?

Because there can be elements which are parents of other elements.

For example:

<ol id="mylist">
  <li>...</li>
  <li>...</li>
  <li>
    <ul>
      <li>...</li>
      <li>...</li>
    </ul>
  </li>
</ol>

So <li> is a child of <ol> but there are also <li> elements which are
children of <ul>.

if you want to define a style for those <li> elements which children of
<ul> but not <ol>, you can define this as following:

ul > li {
}

Or you need a rule which styles only elements which are inside an <ul>
element which is a child of <li> inside <ol>:

ol > li > ul > li {
}

And you can also style all elements which are children of <ol> with tge
ID "mylist", no matter if "direct" children or just somewhere inside the
hierarchy:

ol#mylist li {
}

More about this:

<https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Selectors>



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web