Live data from Hacker News

Password protect a static HTML page

github.com

31–40 of 294 posts

Re: Password protect a static HTML page

#31
post #11
post #3

If you have to run javascript it is not a static page anymore. I've seen a lot of this particularly weird overloading of "static HTML" lately. Static HTML, or static webpage, is meant to describe the experience from the person who is trying to look at the page. It does not describe the experience of the dev. Using a dynamic script or application to generate a static html page that requires no JS execution is a static…

> If you have to run javascript it is not a static page anymore. I've seen a lot of this particularly weird overloading of "static HTML" lately. Static HTML, or static webpage, is meant to describe the experience from the person who is trying to look at the page. It does not describe the experience of the dev. I don't think this has been the common meaning of "static page" for at least 10 years. From Wikipedia [0]: >…

>A static web page (sometimes called a flat page or a stationary page) is a web page that is delivered to the user's web browser exactly as stored"

Right. "exactly as stored" It doesn't matter who or what wrote the HTML. I could do it by hand or maybe use a WYSIWYG editor to make it or maybe it's generated by a script. The point is that there's an html file sitting on disk and the server delivers it without modification and it's viewable in the browser as it. It's just the webserver sending the contents of the file.

Whereas this "Password protected a static HTML page" cannot be viewed in the browser without a "web application", the javascript, dynamically changing the file. It's pretty clear cut. So it fails the test of the very link you posted:

>in contrast to dynamic web pages which are generated by a web application

Re: Password protect a static HTML page

#32

Earlier quoted context omitted.

I think your definition of a static web page is different from the common one? In my head, a static page is something that's served verbatim, without some backend generating it or inserting things into a template. Wikipedia seems to agree with that view: https://en.wikipedia.org/wiki/Static_web_page

That's exactly what I said. It doesn't matter if I wrote the HTML by hand or I had a perl, or bash, or compiled c program make it. It's just an HTML file.

You can put client-side JavaScript fine in “just an HTML file”?

Re: Password protect a static HTML page

#33

Earlier quoted context omitted.

I think your definition of a static web page is different from the common one? In my head, a static page is something that's served verbatim, without some backend generating it or inserting things into a template. Wikipedia seems to agree with that view: https://en.wikipedia.org/wiki/Static_web_page

That's exactly what I said. It doesn't matter if I wrote the HTML by hand or I had a perl, or bash, or compiled c program make it. It's just an HTML file.

[deleted]

Re: Password protect a static HTML page

#34
post #11
post #3

If you have to run javascript it is not a static page anymore. I've seen a lot of this particularly weird overloading of "static HTML" lately. Static HTML, or static webpage, is meant to describe the experience from the person who is trying to look at the page. It does not describe the experience of the dev. Using a dynamic script or application to generate a static html page that requires no JS execution is a static…

> If you have to run javascript it is not a static page anymore. I've seen a lot of this particularly weird overloading of "static HTML" lately. Static HTML, or static webpage, is meant to describe the experience from the person who is trying to look at the page. It does not describe the experience of the dev. I don't think this has been the common meaning of "static page" for at least 10 years. From Wikipedia [0]: >…

The title says “static HTML page” not “static web page”.

JavaScript is not HTML.

Re: Password protect a static HTML page

#35
post #3

If you have to run javascript it is not a static page anymore. I've seen a lot of this particularly weird overloading of "static HTML" lately. Static HTML, or static webpage, is meant to describe the experience from the person who is trying to look at the page. It does not describe the experience of the dev. Using a dynamic script or application to generate a static html page that requires no JS execution is a static…

[deleted]

Re: Password protect a static HTML page

#36
post #11

Earlier quoted context omitted.

> If you have to run javascript it is not a static page anymore. I've seen a lot of this particularly weird overloading of "static HTML" lately. Static HTML, or static webpage, is meant to describe the experience from the person who is trying to look at the page. It does not describe the experience of the dev. I don't think this has been the common meaning of "static page" for at least 10 years. From Wikipedia [0]: >…

>A static web page (sometimes called a flat page or a stationary page) is a web page that is delivered to the user's web browser exactly as stored" Right. "exactly as stored" It doesn't matter who or what wrote the HTML. I could do it by hand or maybe use a WYSIWYG editor to make it or maybe it's generated by a script. The point is that there's an html file sitting on disk and the server delivers it without modificat…

[deleted]

Re: Password protect a static HTML page

#37
post #3

If you have to run javascript it is not a static page anymore. I've seen a lot of this particularly weird overloading of "static HTML" lately. Static HTML, or static webpage, is meant to describe the experience from the person who is trying to look at the page. It does not describe the experience of the dev. Using a dynamic script or application to generate a static html page that requires no JS execution is a static…

That is not correct. As long as the javascript is run on the client-side, it's a static page. Static simply means the files on the server are sent directly to the client. The client can then do whatever they want with the files.

The expression "dynamic" was trending a decade or two ago to vaguely refer to javascript+HTML5. It was never the opposite of "static" in this domain.

Re: Password protect a static HTML page

#38

Earlier quoted context omitted.

That's exactly what I said. It doesn't matter if I wrote the HTML by hand or I had a perl, or bash, or compiled c program make it. It's just an HTML file.

You're incorrect CSS and JavaScript and images are also static, it doesn't have to be just HTML If you have a perl or bash or c backend generating html in response to http requests it's not static

You're assuming this is a backend. It is not. Do you consider generating an HTML file in a WYSIWYG editor like, say, "Dreamweaver" that outputs an .html no longer static because it was made by a program? That's absurd.

Re: Password protect a static HTML page

#39
post #11

Earlier quoted context omitted.

> If you have to run javascript it is not a static page anymore. I've seen a lot of this particularly weird overloading of "static HTML" lately. Static HTML, or static webpage, is meant to describe the experience from the person who is trying to look at the page. It does not describe the experience of the dev. I don't think this has been the common meaning of "static page" for at least 10 years. From Wikipedia [0]: >…

>A static web page (sometimes called a flat page or a stationary page) is a web page that is delivered to the user's web browser exactly as stored" Right. "exactly as stored" It doesn't matter who or what wrote the HTML. I could do it by hand or maybe use a WYSIWYG editor to make it or maybe it's generated by a script. The point is that there's an html file sitting on disk and the server delivers it without modificat…

It's really not "clear cut." By the definition which you agree with, an HTML file containing JavaScript is served to the client without modification, and is viewable in any modern browser with a functioning JavaScript engine. The "web application" in reference is a server-sided application which controls and renders the content, as can be assumed based on context from the rest of that page. Namely:

> Any personalization or interactivity has to run client-side, which is restricting.

Post reply on HN