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

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

Will there ever be a HTML tag to divide HTML documents?

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

Contents

  Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-03 23:40 -0700
    Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 00:14 -0700
      Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 00:22 -0700
        Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 00:25 -0700
          Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 00:35 -0700
            Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 00:49 -0700
              Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 00:57 -0700
                Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 00:57 -0700
                  Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 01:38 -0700
                    Re: Will there ever be a HTML tag to divide HTML documents? Martin Leese <please@see.Web.for.e-mail.INVALID> - 2019-06-04 15:14 -0600
                      Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 22:14 -0700
                        Re: Will there ever be a HTML tag to divide HTML documents? Martin Leese <please@see.Web.for.e-mail.INVALID> - 2019-06-05 13:32 -0600
                          Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-05 13:07 -0700
          Re: Will there ever be a HTML tag to divide HTML documents? John G Harris <niam@jghnorth.org.uk.invalid> - 2019-06-04 19:09 +0100
            Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 12:10 -0700
              Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 12:44 -0700
                Re: Will there ever be a HTML tag to divide HTML documents? Arno Welzel <usenet@arnowelzel.de> - 2019-06-05 14:19 +0200
                  Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-05 13:03 -0700
                    Re: Will there ever be a HTML tag to divide HTML documents? Arno Welzel <usenet@arnowelzel.de> - 2019-06-06 10:26 +0200
            Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 12:24 -0700
            Re: Will there ever be a HTML tag to divide HTML documents? dr.j.r.stockton@gmail.com - 2019-06-05 01:21 -0700
              Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-05 02:52 -0700
            Re: Will there ever be a HTML tag to divide HTML documents? dr.j.r.stockton@gmail.com - 2019-06-06 07:38 -0700
      Re: Will there ever be a HTML tag to divide HTML documents? Arno Welzel <usenet@arnowelzel.de> - 2019-06-05 14:15 +0200
    Re: Will there ever be a HTML tag to divide HTML documents? "R.Wieser" <address@not.available> - 2019-06-04 12:50 +0200
      Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 09:14 -0700
        Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 09:27 -0700
        Re: Will there ever be a HTML tag to divide HTML documents? "R.Wieser" <address@not.available> - 2019-06-04 18:52 +0200
          Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 12:35 -0700
    Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 12:51 -0700
    Re: Will there ever be a HTML tag to divide HTML documents? JJ <jj4public@vfemail.net> - 2019-06-05 10:33 +0700
      Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 22:28 -0700
        Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-04 23:22 -0700
          Re: Will there ever be a HTML tag to divide HTML documents? Arno Welzel <usenet@arnowelzel.de> - 2019-06-05 15:58 +0200
            Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-05 13:00 -0700
            Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-05 13:04 -0700
              Re: Will there ever be a HTML tag to divide HTML documents? Arno Welzel <usenet@arnowelzel.de> - 2019-06-06 10:29 +0200
      Re: Will there ever be a HTML tag to divide HTML documents? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-05 21:07 +0200
        Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-05 13:02 -0700
          Re: Will there ever be a HTML tag to divide HTML documents? Arno Welzel <usenet@arnowelzel.de> - 2019-06-06 10:30 +0200
            Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-06 01:46 -0700
            Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-06 01:57 -0700
              Re: Will there ever be a HTML tag to divide HTML documents? Arno Welzel <usenet@arnowelzel.de> - 2019-06-06 11:21 +0200
                Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-06 02:33 -0700
                  Re: Will there ever be a HTML tag to divide HTML documents? Arno Welzel <usenet@arnowelzel.de> - 2019-06-06 13:04 +0200
                    Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-06 09:28 -0700
                      Re: Will there ever be a HTML tag to divide HTML documents? Arno Welzel <usenet@arnowelzel.de> - 2019-06-09 14:39 +0200
                  Re: Will there ever be a HTML tag to divide HTML documents? John G Harris <niam@jghnorth.org.uk.invalid> - 2019-06-06 18:45 +0100
                    Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-06 12:32 -0700
                    Re: Will there ever be a HTML tag to divide HTML documents? dr.j.r.stockton@gmail.com - 2019-06-06 13:02 -0700
              Re: Will there ever be a HTML tag to divide HTML documents? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-06-06 02:24 -0700
                Re: Will there ever be a HTML tag to divide HTML documents? Arno Welzel <usenet@arnowelzel.de> - 2019-06-06 13:07 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#36781

On Tuesday, 4 June 2019 19:09:17 UTC+1, John G Harris  wrote:
> On Tue, 4 Jun 2019 00:25:42 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
>   <snip>
> >But i think this is what you get when you put datadriven people on the board to make a hypertext markup language, could you not at least **one single** context driven person used to deal with layouts?
> 
> Professional web designers don't need that. They solve the same
> problem by building complicated html documents in the web server,
> using jsp, asp, or php.

And Jonas could just write a lot of little files on his PC, and concatenate them using COPY (maybe in a .BAT file) before use.


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

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

#36782

Den onsdag 5 juni 2019 kl. 10:22:02 UTC+2 skrev dr.j.r...@gmail.com:
> On Tuesday, 4 June 2019 19:09:17 UTC+1, John G Harris  wrote:
> > On Tue, 4 Jun 2019 00:25:42 -0700 (PDT), Jonas Thörnvall
> > <jonas.thornvall@gmail.com> wrote:
> > 
> >   <snip>
> > >But i think this is what you get when you put datadriven people on the board to make a hypertext markup language, could you not at least **one single** context driven person used to deal with layouts?
> > 
> > Professional web designers don't need that. They solve the same
> > problem by building complicated html documents in the web server,
> > using jsp, asp, or php.
> 
> And Jonas could just write a lot of little files on his PC, and concatenate them using COPY (maybe in a .BAT file) before use.
> 
> 
> -- 
>   (c) John Stockton, near London, UK.  Using Google Groups.           |
>  Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

Well he could but he won't because it is 2019...

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

#36812

On Tuesday, 4 June 2019 19:09:17 UTC+1, John G Harris  wrote:


> Professional web designers don't need that. They solve the same
> problem by building complicated html documents in the web server,
> using jsp, asp, or php.


I see an alternative which might suit Jonas, if it works.

Handling files directly from the local filesystem without
using any form of server, I commonly read HTML pages into
an iframe element and access their content, as source or
as DOM tree, using JavaScript.

That only works in some browsers; the interpretation of
the 'same origin policy', or something else, prevents
access to the iframe content for local files.  Happily,
it works in Firefox.

It appears to me, ICBW, that, for all browsers, access
to the iframe contents works on same-origin files from
a server ; and that for all, it _should_ work on local
files in a filesystem. ICBW.

If it works in Jonas's circumstances, ISTM that he could
load his sections in turn into an iframe, attach the bodies
to an element created in the main page, and, when that has
been completed, attach that element to the body of the main
page.  And I seem to remember having had a page which
replaced its own body ... H'mmm ... I'll do a test ...

I have a local page which uses function eval on the content
of a textarea; it contains several words 'body' near the
textarea.  I insert the following line into the textarea -

document.body.innerHTML = document.body.innerHTML.replace(/body/gm, "CORPS")

- I press the "eval" button, and every 'body' is changed
to 'CORPS' - testing in Firefox and in AVG Secure Browser
(the content of the textarea vanishes). The script of the
page is within the body of the page, and does not contain
'body'.

That demonstrates a full body transplant.

Purists and pedants will probably dislike the suggested
scheme.


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

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

#36785

On 04.06.19 09:14, Jonas Thörnvall wrote:

[...]
> I mean for what i am thinking only local files in same folder
> necesary. It is a way to structure a textmass that becomes
> unreasonable large, and i simply refuse the use of <iframe> it is
> nonesense.
> 
> <sub text="pianoframe.html">Your document goes here</sub text>
> 
> Right now my main.html is 41 KB it is insane. And i will not go back
> add origin on every function call back and forth, it is ludicrous,
> that i have to state in which document i want to reach the function.

Server side includes exist. Content management system exist as well.

And I wouldn't call 41 KB of HTML "insane". I've seen much bigger
documents. For example
<https://arnowelzel.de/en/experiences-with-nextcloud> has about 43 KB
and I would not call this "insane" because of its size.


-- 
Arno Welzel
https://arnowelzel.de

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

#36764

Jonas,

> I can see many people ask for a way to just divide a
> text into subblocks, will it ever happen?

You mean like dividing a webpage up with frame sets 
(https://www.w3schools.com/tags/tag_frameset.asp) ?  Nah, probably won't 
ever happen :-)

Regards,
Rudy Wieser

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

#36765

Den tisdag 4 juni 2019 kl. 12:50:23 UTC+2 skrev R.Wieser:
> Jonas,
> 
> > I can see many people ask for a way to just divide a
> > text into subblocks, will it ever happen?
> 
> You mean like dividing a webpage up with frame sets 
> (https://www.w3schools.com/tags/tag_frameset.asp) ?  Nah, probably won't 
> ever happen :-)
> 
> Regards,
> Rudy Wieser

You do not read Rudy, that is your problem noone need to divide document into logical units when they start it is nonesense. What is needed is bread down a document into pieces.

And you probably missed that scripts are not available automaticly in the main document.

No what is needed is a sub tag "not an outer table" only a moron would come up with such an idea make a similar structure like frame that is not part of the HTML document.


The frame is a container, tables is a container, no one wants to put HTML into a  layout that may change over time what is needed it to divide the text into logical blocks, not necessarily to layout blocks "it could be" but it is not necessary.

A tag to fill a table ID or div ID is needed, a logical text unit i do not want to deal with changing the fram layout. The layout is in my HTML document, i just want to add something, but the fucking text start to get enourmus. Please fucking let me divide the text. You can build it together when the parts fetched from server.

It is avalable in PHP,

If you can't get such a simple thing like to divide a book into pages there is no help for anyone of you.  It deos not have to do with layout it is a simple way to not have to read a scroll.

You know the ones they had before the advent of books, the book is also pretty old you know so it can't be a mystery to you, so i think it is fucking time to let the HTML scroll go, and replace it with a book where you can find chapeters and pages.

No i do not need to know the parent page reading the fucking book not even the parent chapter. It is just pages "textblocks".

Fuck this nonsesense low IQ monkey buisness.

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

#36766

Den tisdag 4 juni 2019 kl. 18:14:42 UTC+2 skrev Jonas Thörnvall:
> Den tisdag 4 juni 2019 kl. 12:50:23 UTC+2 skrev R.Wieser:
> > Jonas,
> > 
> > > I can see many people ask for a way to just divide a
> > > text into subblocks, will it ever happen?
> > 
> > You mean like dividing a webpage up with frame sets 
> > (https://www.w3schools.com/tags/tag_frameset.asp) ?  Nah, probably won't 
> > ever happen :-)
> > 
> > Regards,
> > Rudy Wieser
> 
> You do not read Rudy, that is your problem noone need to divide document into logical units when they start it is nonesense. What is needed is bread down a document into pieces.
> 
> And you probably missed that scripts are not available automaticly in the main document.
> 
> No what is needed is a sub tag "not an outer table" only a moron would come up with such an idea make a similar structure like frame that is not part of the HTML document.
> 
> 
> The frame is a container, tables is a container, no one wants to put HTML into a  layout that may change over time what is needed it to divide the text into logical blocks, not necessarily to layout blocks "it could be" but it is not necessary.
> 
> A tag to fill a table ID or div ID is needed, a logical text unit i do not want to deal with changing the fram layout. The layout is in my HTML document, i just want to add something, but the fucking text start to get enourmus. Please fucking let me divide the text. You can build it together when the parts fetched from server.
> 
> It is avalable in PHP,
> 
> If you can't get such a simple thing like to divide a book into pages there is no help for anyone of you.  It deos not have to do with layout it is a simple way to not have to read a scroll.
> 
> You know the ones they had before the advent of books, the book is also pretty old you know so it can't be a mystery to you, so i think it is fucking time to let the HTML scroll go, and replace it with a book where you can find chapeters and pages.
> 
> No i do not need to know the parent page reading the fucking book not even the parent chapter. It is just pages "textblocks".
> 
> Fuck this nonsesense low IQ monkey buisness.

Well if you can't see the logic in what i say, think about it like this, an empty frameset is not dividing the text into logical textblocks, it is basicly a table element. Where you have to refer to variables "in other documents" that is why you have to pass a document argument.

This is not about separate documents this is about break down a text into blocks that you can overview easily "so we are in same document" built by subs. Of course you could put them into a format of a "div,table" the main document but you do not need to. You could split it by lines if you so wanted.... It is just a way to split a text into logical units, you could call it pages, chapters, subs, frambes, inners or what the fuck ever ****THE IMPORTANT THING IS TO LET THEM BE PART OF THE DOCUMENT*** so you can reach the function you have declarer without have to play hide and seek, do you know what i mean? I am not interested in fucking find the parent or sibling holding the function i want to reach. It is the same fucking document. End of story.

<sub text="my.html>Yeah fuck your text goes here, you can have it in a layout element as a table or div, but it can also just be a text split up, but most important the fucking sub is part of the document so i do not fucking have to ask my aunt if i can call the functions i wrote.</sub text>

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

#36767

Jonas,

> You do not read Rudy,

Really ?

Your problem : "Dealing with real big HTML blocks is frustrating in HTML"

My suggestion: Split it up in smaller parts using framesets.

> What is needed is bread down a document into pieces.

Which is *exactly* what the above will do.

> And you probably missed that scripts are not available automaticly in the 
> main document.

No, I did not mis that /at all/.   Why ? Because you did not mention it (in 
your initial post).    What do you expect me to be ?   A fucking mindreader 
or something ?

But yes, as your questions most all revolved around using JS what you said 
there crossed my mind.    Alas, I assumed you would be smart enough to throw 
a google at it and discover that "crossing the borders" when using a 
frameset is a helluva lot easier than doing the same with iframes (where it 
should not be allowed/possible)

But no.   Instead of taking the time to check a few things out you think 
currently already understand both JS and framesets well enough (I sincerely 
doubt that by the way) to know for sure that my suggestion is bogus.

Well, have it your way.   Good luck finding another solution.  Goodbye.

Regards,
Rudy Wieser

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

#36771

Den tisdag 4 juni 2019 kl. 18:52:55 UTC+2 skrev R.Wieser:
> Jonas,
> 
> > You do not read Rudy,
> 
> Really ?
> 
> Your problem : "Dealing with real big HTML blocks is frustrating in HTML"
> 
> My suggestion: Split it up in smaller parts using framesets.
> 
> > What is needed is bread down a document into pieces.
> 
> Which is *exactly* what the above will do.
> 
> > And you probably missed that scripts are not available automaticly in the 
> > main document.
> 
> No, I did not mis that /at all/.   Why ? Because you did not mention it (in 
> your initial post).    What do you expect me to be ?   A fucking mindreader 
> or something ?
> 
> But yes, as your questions most all revolved around using JS what you said 
> there crossed my mind.    Alas, I assumed you would be smart enough to throw 
> a google at it and discover that "crossing the borders" when using a 
> frameset is a helluva lot easier than doing the same with iframes (where it 
> should not be allowed/possible)
> 
> But no.   Instead of taking the time to check a few things out you think 
> currently already understand both JS and framesets well enough (I sincerely 
> doubt that by the way) to know for sure that my suggestion is bogus.
> 
> Well, have it your way.   Good luck finding another solution.  Goodbye.
> 
> Regards,
> Rudy Wieser

No Rudy, Frames are layout dependent and to reach elements between frame documents you have adress parent e t c. That is not what anyone ask aftr, they ask after something that simply split a document a Frame is a layout "that you fill with documents" do you see the difference. THose documents must be adressed to reach ID's within, or reach function within.

I ASK FOR HTML TO BE ABLE SPLIT A DOCUMENT BY YOUR CHOICE, YOU KNOW IN ARCHIVES ONE STORE THINGS IN DIFFERENT DRAWERS IT MEANS ONE EASILY CAN FIND A BLOCK. YOU COULD DO IT IN FRAMES, BUT THERE IS A LOGICAL OVERHEAD CREATED WHEN REACH ID's AND FUNCTIONS.

I am talking about splitting a chunk of text after my idea, for example i have things that use css, that simply do not fit the frame paradigm like a keyboard and drumpad hidden behind menues. I just want to split the fucking text, "it is one single document". SO ALL FUNCTIONS ID's SHOULD BE REACHABLE DEFAULT.

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

#36773

Den tisdag 4 juni 2019 kl. 08:40:42 UTC+2 skrev Jonas Thörnvall:
> Dealing with real big HTML blocks is frustrating in HTML, the only option you got is to split the document with iframe and innerHTML. And then you suddenly must hang on the origin "parent" to reach the functions you call, it add complexity when all you want to do is have neat textblocks included "frames".
> 
> I find it somehow unreasonable to add unnecessary complexity to reach local functions.
> 
> Is the HTML standard fix now, iframe was not the solution i was hoping for.It may be good for other purposes but for dividing a text into logical textblocks it is practically useless if you do not want to add overhead.
> 
> I can see many people ask for a way to just divide a text into subblocks, will it ever happen?

You see in the end i fucking rather invent my own tag inside a comment tag, and write an editor that split the HTML text over multiple tabs. Rather that then adhere to the idiot paradigm where documents in same page ***must*** adress eachother with document names and be put into frames, it is simply madness at best.

I refuse to bend over to idiocy. One day the book will be invented.

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

#36776

On Mon, 3 Jun 2019 23:40:31 -0700 (PDT), Jonas Thörnvall wrote: 
> Dealing with real big HTML blocks is frustrating in HTML, the only option
> you got is to split the document with iframe and innerHTML. And then you
> suddenly must hang on the origin "parent" to reach the functions you
> call, it add complexity when all you want to do is have neat textblocks
> included "frames". 
> 
> I find it somehow unreasonable to add unnecessary complexity to reach
> local functions. 
> 
> Is the HTML standard fix now, iframe was not the solution i was hoping
> for.It may be good for other purposes but for dividing a text into
> logical textblocks it is practically useless if you do not want to add
> overhead. 
> 
> I can see many people ask for a way to just divide a text into subblocks,
> will it ever happen?

Probably. Such feature is useful to provide newspaper styled page.

But considering that most of current HTML elements are just dumb passive
containers (where they can not change their contents without users'
intervention), I doubt it'll change soon. At least until they introduce
something like "smart HTML" - where HTML elements are more active in
general.

But I think before that happens, they'll need to provide support for better
text rendering so that text can nicely fill up non rectangular containers
without getting clipped.

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

#36778

Den onsdag 5 juni 2019 kl. 05:33:30 UTC+2 skrev JJ:
> On Mon, 3 Jun 2019 23:40:31 -0700 (PDT), Jonas Thörnvall wrote: 
> > Dealing with real big HTML blocks is frustrating in HTML, the only option
> > you got is to split the document with iframe and innerHTML. And then you
> > suddenly must hang on the origin "parent" to reach the functions you
> > call, it add complexity when all you want to do is have neat textblocks
> > included "frames". 
> > 
> > I find it somehow unreasonable to add unnecessary complexity to reach
> > local functions. 
> > 
> > Is the HTML standard fix now, iframe was not the solution i was hoping
> > for.It may be good for other purposes but for dividing a text into
> > logical textblocks it is practically useless if you do not want to add
> > overhead. 
> > 
> > I can see many people ask for a way to just divide a text into subblocks,
> > will it ever happen?
> 
> Probably. Such feature is useful to provide newspaper styled page.
> 
> But considering that most of current HTML elements are just dumb passive
> containers (where they can not change their contents without users'
> intervention), I doubt it'll change soon. At least until they introduce
> something like "smart HTML" - where HTML elements are more active in
> general.
> 
> But I think before that happens, they'll need to provide support for better
> text rendering so that text can nicely fill up non rectangular containers
> without getting clipped.

Well that is not what i ask for i ask for something dumb as a rock basicly a picture element that is a sequential part of a full HTML page. You know how books work page 1 page 2 page 3.....

A simple matter of divide a scroll into defined pages, but where "elements" id's and function's from main or "in parts" can be accessed without somekind of fucking scheme "it is ***ONE*** html doc" divided into textblock.

The idiot that came up with that HTML documents on same page are not of same ***origin*** but need to be adressed well... if being a clueless idiot was not hard enough.

Yes i understand that there must be cross domain features.
But they are not fucking needed when you want to split a textblock are they?

No one could come up with such an idiotic ideas in reallife, but in programming such idiocy just pass as it was the natural order of things.



 

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

#36779

Den onsdag 5 juni 2019 kl. 07:28:39 UTC+2 skrev Jonas Thörnvall:
> Den onsdag 5 juni 2019 kl. 05:33:30 UTC+2 skrev JJ:
> > On Mon, 3 Jun 2019 23:40:31 -0700 (PDT), Jonas Thörnvall wrote: 
> > > Dealing with real big HTML blocks is frustrating in HTML, the only option
> > > you got is to split the document with iframe and innerHTML. And then you
> > > suddenly must hang on the origin "parent" to reach the functions you
> > > call, it add complexity when all you want to do is have neat textblocks
> > > included "frames". 
> > > 
> > > I find it somehow unreasonable to add unnecessary complexity to reach
> > > local functions. 
> > > 
> > > Is the HTML standard fix now, iframe was not the solution i was hoping
> > > for.It may be good for other purposes but for dividing a text into
> > > logical textblocks it is practically useless if you do not want to add
> > > overhead. 
> > > 
> > > I can see many people ask for a way to just divide a text into subblocks,
> > > will it ever happen?
> > 
> > Probably. Such feature is useful to provide newspaper styled page.
> > 
> > But considering that most of current HTML elements are just dumb passive
> > containers (where they can not change their contents without users'
> > intervention), I doubt it'll change soon. At least until they introduce
> > something like "smart HTML" - where HTML elements are more active in
> > general.
> > 
> > But I think before that happens, they'll need to provide support for better
> > text rendering so that text can nicely fill up non rectangular containers
> > without getting clipped.
> 
> Well that is not what i ask for i ask for something dumb as a rock basicly a picture element that is a sequential part of a full HTML page. You know how books work page 1 page 2 page 3.....
> 
> A simple matter of divide a scroll into defined pages, but where "elements" id's and function's from main or "in parts" can be accessed without somekind of fucking scheme "it is ***ONE*** html doc" divided into textblock.
> 
> The idiot that came up with that HTML documents on same page are not of same ***origin*** but need to be adressed well... if being a clueless idiot was not hard enough.
> 
> Yes i understand that there must be cross domain features.
> But they are not fucking needed when you want to split a textblock are they?
> 
> No one could come up with such an idiotic ideas in reallife, but in programming such idiocy just pass as it was the natural order of things.

Just guessing here but, it seem to me that HTML requests will send files in some type of order, starting with the indexfile, and then rest text files, after that script files and last pictures.

So i guess the subs would go after the index file transmitted.

https://vanseodesign.com/web-design/browser-requests/

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

#36787

On 05.06.19 08:22, Jonas Thörnvall wrote:

[...]
> Just guessing here but, it seem to me that HTML requests will send
> files in some type of order, starting with the indexfile, and then
> rest text files, after that script files and last pictures.

There is no "HTML request"! It's all HTTP - and it does not matter, if
the requested resource is a HTML document or something else.

Try to understand at least the basics:

The browser will just send a HTTP (not HTML!) request and get a response
from the server. And if this response is a HTML document, the browser(!)
will parse the document and will request other resources which are
referred in the HTML document (e.g. scripts, style sheets, images).

And by the way: what does this all have to do with JavaScript?



-- 
Arno Welzel
https://arnowelzel.de

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

#36790

Den onsdag 5 juni 2019 kl. 15:58:13 UTC+2 skrev Arno Welzel:
> On 05.06.19 08:22, Jonas Thörnvall wrote:
> 
> [...]
> > Just guessing here but, it seem to me that HTML requests will send
> > files in some type of order, starting with the indexfile, and then
> > rest text files, after that script files and last pictures.
> 
> There is no "HTML request"! It's all HTTP - and it does not matter, if
> the requested resource is a HTML document or something else.
> 
> Try to understand at least the basics:
> 
> The browser will just send a HTTP (not HTML!) request and get a response
> from the server. And if this response is a HTML document, the browser(!)
> will parse the document and will request other resources which are
> referred in the HTML document (e.g. scripts, style sheets, images).
> 
> And by the way: what does this all have to do with JavaScript?
> 
> 
> 
> -- 
> Arno Welzel
> https://arnowelzel.de

Oh another anal prick who have learned a few words, i know protocol i want to look shiny. My god your a bunch of low IQ idiots.

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

#36793

Den onsdag 5 juni 2019 kl. 15:58:13 UTC+2 skrev Arno Welzel:
> On 05.06.19 08:22, Jonas Thörnvall wrote:
> 
> [...]
> > Just guessing here but, it seem to me that HTML requests will send
> > files in some type of order, starting with the indexfile, and then
> > rest text files, after that script files and last pictures.
> 
> There is no "HTML request"! It's all HTTP - and it does not matter, if
> the requested resource is a HTML document or something else.
> 
> Try to understand at least the basics:
> 
> The browser will just send a HTTP (not HTML!) request and get a response
> from the server. And if this response is a HTML document, the browser(!)
> will parse the document and will request other resources which are
> referred in the HTML document (e.g. scripts, style sheets, images).
> 
> And by the way: what does this all have to do with JavaScript?
> 
> 
> 
> -- 
> Arno Welzel
> https://arnowelzel.de

You are an idiot and you are tiresome....

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

#36798

On 05.06.19 22:04, Jonas Thörnvall wrote:

> Den onsdag 5 juni 2019 kl. 15:58:13 UTC+2 skrev Arno Welzel:
>> On 05.06.19 08:22, Jonas Thörnvall wrote:
>>
>> [...]
>>> Just guessing here but, it seem to me that HTML requests will send
>>> files in some type of order, starting with the indexfile, and then
>>> rest text files, after that script files and last pictures.
>>
>> There is no "HTML request"! It's all HTTP - and it does not matter, if
>> the requested resource is a HTML document or something else.
>>
>> Try to understand at least the basics:
>>
>> The browser will just send a HTTP (not HTML!) request and get a response
>> from the server. And if this response is a HTML document, the browser(!)
>> will parse the document and will request other resources which are
>> referred in the HTML document (e.g. scripts, style sheets, images).
>>
>> And by the way: what does this all have to do with JavaScript?
>>
>>
>>
>> -- 
>> Arno Welzel
>> https://arnowelzel.de
> 
> You are an idiot and you are tiresome....

At least I know what I do and I don't talk about bullshit...

<https://github.com/arnowelzel/>
<https://wordpress.org/plugins/lightbox-photoswipe/>
<https://wordpress.org/plugins/timed-content/>


-- 
Arno Welzel
https://arnowelzel.de

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

#36788

JJ wrote:

> On Mon, 3 Jun 2019 23:40:31 -0700 (PDT), Jonas Thörnvall wrote:
>> Dealing with real big HTML blocks is frustrating in HTML, the only option
>> you got is to split the document with iframe and innerHTML.

Nonsense.

>> And then you suddenly must hang on the origin "parent" to reach the
>> functions you call, it add complexity when all you want to do is have
>> neat textblocks included "frames".
>> 
>> I find it somehow unreasonable to add unnecessary complexity to reach
>> local functions.
>> 
>> Is the HTML standard fix now, iframe was not the solution i was hoping
>> for.It may be good for other purposes but for dividing a text into
>> logical textblocks it is practically useless if you do not want to add
>> overhead.
>> 
>> I can see many people ask for a way to just divide a text into subblocks,
>> will it ever happen?
> 
> Probably. Such feature is useful to provide newspaper styled page.
> 
> But considering that most of current HTML elements are just dumb passive
> containers (where they can not change their contents without users'
> intervention), I doubt it'll change soon. At least until they introduce
> something like "smart HTML" - where HTML elements are more active in
> general.
> 
> But I think before that happens, they'll need to provide support for
> better text rendering so that text can nicely fill up non rectangular
> containers without getting clipped.

Whatever the *perceived* problem, I am almost certain that it is only that, 
caused by ignorance (at best).  There are

  overflow: auto;

  columns: 2;

and

  border: 1px solid black;
  border-radius: 10px;
  padding: 5px;

and there are the Flexible Box (Flexbox) and Grid CSS layouts.

<https://developer.mozilla.org/en-US/docs/Web/CSS/overflow>
<https://developer.mozilla.org/en-US/docs/Web/CSS/columns>
<https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius>
<https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout>
<https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout>

Plain HTML and CSS are *off topic* here.
They are on topic in <news:comp.infosystems.www.authoring.html> and 
<news:comp.infosystems.www.authoring.stylesheets> instead.

See also the FAQ (sig).

X-Post & F’up2 .stylesheets

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#36791

Den onsdag 5 juni 2019 kl. 21:07:08 UTC+2 skrev Thomas 'PointedEars' Lahn:
> JJ wrote:
> 
> > On Mon, 3 Jun 2019 23:40:31 -0700 (PDT), Jonas Thörnvall wrote:
> >> Dealing with real big HTML blocks is frustrating in HTML, the only option
> >> you got is to split the document with iframe and innerHTML.
> 
> Nonsense.
> 
> >> And then you suddenly must hang on the origin "parent" to reach the
> >> functions you call, it add complexity when all you want to do is have
> >> neat textblocks included "frames".
> >> 
> >> I find it somehow unreasonable to add unnecessary complexity to reach
> >> local functions.
> >> 
> >> Is the HTML standard fix now, iframe was not the solution i was hoping
> >> for.It may be good for other purposes but for dividing a text into
> >> logical textblocks it is practically useless if you do not want to add
> >> overhead.
> >> 
> >> I can see many people ask for a way to just divide a text into subblocks,
> >> will it ever happen?
> > 
> > Probably. Such feature is useful to provide newspaper styled page.
> > 
> > But considering that most of current HTML elements are just dumb passive
> > containers (where they can not change their contents without users'
> > intervention), I doubt it'll change soon. At least until they introduce
> > something like "smart HTML" - where HTML elements are more active in
> > general.
> > 
> > But I think before that happens, they'll need to provide support for
> > better text rendering so that text can nicely fill up non rectangular
> > containers without getting clipped.
> 
> Whatever the *perceived* problem, I am almost certain that it is only that, 
> caused by ignorance (at best).  There are
> 
>   overflow: auto;
> 
>   columns: 2;
> 
> and
> 
>   border: 1px solid black;
>   border-radius: 10px;
>   padding: 5px;
> 
> and there are the Flexible Box (Flexbox) and Grid CSS layouts.
> 
> <https://developer.mozilla.org/en-US/docs/Web/CSS/overflow>
> <https://developer.mozilla.org/en-US/docs/Web/CSS/columns>
> <https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius>
> <https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout>
> <https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout>
> 
> Plain HTML and CSS are *off topic* here.
> They are on topic in <news:comp.infosystems.www.authoring.html> and 
> <news:comp.infosystems.www.authoring.stylesheets> instead.
> 
> See also the FAQ (sig).
> 
> X-Post & F’up2 .stylesheets
> 
> -- 
> PointedEars
> FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
> <https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
> Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

No waht the fuck i am quite happy with using notepad++ and when i want to look something up i use Atom.

No the tools are not the problem Thomas....

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

#36799

On 05.06.19 22:02, Jonas Thörnvall wrote:

[...]
> No the tools are not the problem Thomas....

Indeed - it's your attitude...


-- 
Arno Welzel
https://arnowelzel.de

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web