Avatar

About opening of links in new tabs or browser windows (Features)

by Auge ⌂, Monday, October 19, 2020, 11:05 (1247 days ago)

Hello

After the question of ChristianForum about opening links from the entries in new tabs or windows I played around with the code. IMHO it would be absolutely no problem to change from XHTML strict to XHTML transitional (because of using (X)HTML transitional noone is enforced to write bad code). Beside from a more leger interpretation of changes in theme reworks this change would make it possible to provide the (over the years) several times requested opening of links in other tabs or windows that depends on the target attribute (which is forbidden in (X)HTML strict).

I built a similar function like described in my reply to ChristianForum with the enhancement of a setting to enable and disable the function. So far so good.

A problem that I spotted instaneously (but needed 20 minutes to find the cause) is the entries cache in the database. The cache entry gets (re)written when creating or editing an entry but not in every case when changing a setting (or introducing and testing a setting [1]). There is a checkbox for reinitialising the cache at the end of the (basic) settings form but it's not available in the enhanced settings form.

There are different solutions for this problem, I can think of.

1. Enforce the reinitialisation of the cache after every change on the settings page(s).

This would be not so nice in a forum with many entries. The cache would have to be rebuilt even the changed setting(s) do not need that. Many users would see a unnecessary low performance in the first hours or days (depending on the traffic in the forum) after every settings change.

2. Put the checkbox for reinitialisation of the entries cache also on the page of the enhanced settings.

[edit]

- Putting the settings that needs a entry cache reinitialisation into the (basic) settings form.

(no numerisation to prevent the need of renumeration of the list)

Putting the relevant settings to the basic (main) settings would IMHO be questionable. Putting one setting there would be reasonable, puttin another setting to this form, would be dubious.

[/edit]

That would give the control over this function to the forum operators and administrators. If they know, when to use the function, the impact on the forum performance would be low as possible. On the other hand, if they don't know when to use, we would possibly see unnecessary bug reports [2].

3. Introduce an extension for handling caching issues.

That would need a fine granulated management of settings that requires a cache reinitialisation. Not only that, we would need to touch it every time we want to introduce a new setting with that dependency. An exception would be an automatism, a switch we have to set once per setting. The switch would have to be part of the settings table in the database.

4. Request the forum operator to reinitialise the entries cache.

Also here we would need a management, when to request the initialisation. But why should we annoy the forum operator/administrator when we would have a management solution and would be able to implement the automatism? But: In the case of introducing my implementation (as a single case) and possibly backporting it to the 2.4.x branch the request would be not a problem.

Solutions 1 and 2 are easy to implement but have disadvantages in their reliability. I (for myself) would prefer the third solution but as everyone knows the development of the forum has more or less stopped or at least is very slow. Number 4 would be a quick fix for a single case but no general solution.

Does anyone has additional ideas, thought, (counter)-arguments or solution approaches? Micha, Alex, Alfie, anyone else?

Tschö, Auge

[1]: During the tests of my changes I have to edit my testing entry to see the outcome of my changes. That's no problem, since I meanwhile know the reason for the not instantaneously applied changes.
[2]: To be fair, that's already possible now.

--
Trenne niemals Müll, denn er hat nur eine Silbe!

About opening of links in new tabs or browser windows

by shian, Tuesday, October 20, 2020, 08:29 (1246 days ago) @ Auge

Does anyone has additional ideas, thought, (counter)-arguments or solution approaches? Micha, Alex, Alfie, anyone else?

The term "de facto standard" was already used in the PC world few decades ago.
For example, in the DOS era we had to use a formal code-page for each language, in reality - the code page that we used was the "de facto standard" code page, regardless of the "formal" rules.

Why "de facto standard" is used instead of formal ("canonical") standard?
The answer is simple, the PC world is extremely wide and evolving incredibly fast, therefore software and hardware vendors cannot stick to canonical rules (unless they want to go bankrupt).

The same is true about (X)HTML script: most browsers are following the "de facto standard" instead of the canonical standard, since the canonical standard is a "moving target" and practically impossible to follow.

In short:
My family is partially German so I assume that you will not like this solution... :-), but it is a known fact that "de facto standard" overrides "canonical standard" in the PC world.

So my solution is to simply use the de facto standard, which means:
do not change anything! Most or all browsers are using the de facto standard and will gladly open a link on the specified target attribute also in XHTML 1.0 Strict.
Just add a BBCode to open a link with target="_blank".

Again, the de facto standards never change, while canonical standards are changing all the time.

Try the following 'test.html' on various browsers:

 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" dir="ltr">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>About opening of links in new tabs or browser windows - my little forum</title>
<meta name="description" content="yet another little forum" />
</head>
 
<body>
 
<div>
<h3>Open a link in a new tab in XHTML 1.0 Strict:</h3>
<a href="https://www.rapideuphoria311.com/" target="_blank">rapideuphoria311.com</a>
<br /><br /><br />
<b>Tested on the following browsers:</b>
<ul>
<li>Opera Version:71.0.3770.271 (64-bit)</li>
<li>Google Chrome Version 86.0.4240.75 (Official Build) (64-bit)</li>
<li>Firefox Browser 81.0.2 (64-bit)</li>
</ul>
</div>
 
</body>
</html>
 
 
Avatar

About opening of links in new tabs or browser windows

by Micha ⌂, Tuesday, October 20, 2020, 09:33 (1246 days ago) @ shian

Hi,

your code is invalid and that's the point. Of course, browsers may have a "tolerance" level and will "support" the deprecated attribute. Changing from strict to transitional solves this problem, the resulting code is valid.

It's like car driving: If there is a 30km/h limit, you can also drive 50km/h. Your car will "support" this "feature". The question ist: Why don't you use the highway to drive faster - in a legal manner?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

About opening of links in new tabs or browser windows

by shian, Tuesday, October 20, 2020, 11:02 (1246 days ago) @ Micha

your code is invalid and that's the point. Of course, browsers may have a "tolerance" level and will "support" the deprecated attribute. Changing from strict to transitional solves this problem, the resulting code is valid.

It's like car driving: If there is a 30km/h limit, you can also drive 50km/h. Your car will "support" this "feature". The question ist: Why don't you use the highway to drive faster - in a legal manner?

My code is invalid only according to canonical/arbitrary rule and that's the point.

Browsers are supporting a de facto standard not out of "tolerance" but out of principle which is called common law.

According to the common law principle which browsers adopted rightfully - my code is 100% legal and 100% valid.

Avatar

About opening of links in new tabs or browser windows

by Alfie ⌂, Vienna, Austria, Tuesday, October 20, 2020, 14:06 (1246 days ago) @ shian

Hi shian,

your code is invalid and that's the point. Of course, browsers may have a "tolerance" level and will "support" the deprecated attribute. Changing from strict to transitional solves this problem, the resulting code is valid. […]


My code is invalid only according to canonical/arbitrary rule and that's the point.

Nope, it isn’t. Of course, you are free to modify the scripts in your installation.

If all of your users aren’t handicapped (requiring a Braille-line of even a screen reader), fine. Opening links in a new window is extremely confusing in such installations. Hence, in the standard installation of mlf we will not change to doc-type.

--
Cheers,
Alfie (Helmut Schütz)
BEBA-Forum (v1.8β)

About opening of links in new tabs or browser windows

by shian, Tuesday, October 20, 2020, 14:22 (1246 days ago) @ Alfie

My code is invalid only according to canonical/arbitrary rule and that's the point.


Nope, it isn’t.

Hi Alfie,

"Nope, it isn’t" - is a statement, not an evidence.

The fact that major browsers are supporting the principle of Common Law is an evidence - not a statement.

Happy to meet you,
shian

Avatar

About opening of links in new tabs or browser windows

by Alfie ⌂, Vienna, Austria, Tuesday, October 20, 2020, 14:42 (1246 days ago) @ shian

Hi shian,

My code is invalid only according to canonical/arbitrary rule and that's the point.


Nope, it isn’t.


"Nope, it isn’t" - is a statement, not an evidence.

https://validator.w3.org/check tells me about your test.html:

Line 13, Column 52: there is no attribute "target"

…ef="https://www.rapideuphoria311.com/" target="_blank">rapideuphoria311.com</a>

You have used the attribute named above in your document, but the document type you are using does not support that attribute for this element. This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Transitional" document type to get the "target" attribute), […].

This error may also result if the element itself is not supported in the document type you are using, as an undefined element will have no supported attributes; in this case, see the element-undefined error message for further information.

How to fix: check the spelling and case of the element and attribute, (Remember XHTML is all lower-case) and/or check that they are both allowed in the chosen document type, […]

The fact that major browsers are supporting the principle of Common Law is an evidence - not a statement.

What you wrote before about a “moving target” is true for browser’s interpretations [sic] of the standard of the W3C. The latter is much more consistent and stable.

Only dead fish go with the current.    Scuba divers’ proverb

Anyone who conducts an argument by appealing to authority
is not using his intelligence; he is just using his memory.    Leonardo da Vinci

--
Cheers,
Alfie (Helmut Schütz)
BEBA-Forum (v1.8β)

Avatar

About opening of links in new tabs or browser windows

by Micha ⌂, Tuesday, October 20, 2020, 09:22 (1246 days ago) @ Auge

Hello,

Does anyone has additional ideas, thought, (counter)-arguments or solution approaches? Micha, Alex, Alfie, anyone else?

I don't like this feature. There are a lot of arguments against opening a new tab/window, since several years. For that reason, I don't understand the intention behind this feature. I don't see any benefit in opening a new tab/window.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

About opening of links in new tabs or browser windows

by shian, Tuesday, October 20, 2020, 11:19 (1246 days ago) @ Micha

I don't like this feature. There are a lot of arguments against opening a new tab/window, since several years. For that reason, I don't understand the intention behind this feature. I don't see any benefit in opening a new tab/window.

The ridiculous arguments against opening a new tab/window are mainly related to pop-up malware... and of course the extreme vulnerability of the Windows operating system (which only getting worse by the day IMHO).

There are huge benefits for opening a new tab/window for lots of users. I personally open links in my little forum always with the right mouse button in a new tab. always.

But then again - I don't use Windows, and my browser is "enough intelligent" to disallow pop-up windows... so where is the argument? I simply open a link that I fully trust in a new tab - while staying in the forum at the same time.

Avatar

About opening of links in new tabs or browser windows

by Auge ⌂, Tuesday, October 20, 2020, 12:50 (1246 days ago) @ Micha

Hello

Does anyone has additional ideas, thought, (counter)-arguments or solution approaches? Micha, Alex, Alfie, anyone else?


I don't like this feature.

I do. And the every when and then up-popping threads with questions about target tells me, I am not alone. ;-)

There are a lot of arguments against opening a new tab/window, since several years. For that reason, I don't understand the intention behind this feature. I don't see any benefit in opening a new tab/window.

I do open most of the links in forums and on any other sites in new tabs. So the attribute target is a little tiny help, even I know, how to open a link in a new tab without the attribute ([middle click] or [CTRL]+[left click]).

Other users of other forums seem to miss this functionality too. To make it simple and to prevent the need of own changes in case of a software update (in this case two functions and the main.tpl of the default theme) my idea was to make it part of the core and to make it a switchable setting (default value: off/NULL)).

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

About opening of links in new tabs or browser windows

by shian, Tuesday, October 20, 2020, 13:43 (1246 days ago) @ Auge

... my idea was to make it part of the core and to make it a switchable setting (default value: off/NULL)).

Without ignoring Micha's opinions (minimalism, simplicity and tidy code are probably the most important feature...), a switchable setting is great! The first thing I'd do is to turn the switch ON.

Opening links in a new tab saves a bit of bandwidth/expenses, and an extremely practical behavior for lots of users. (I'm not sure about Smartphone users... but Smartphones should be outlaw due to safety issues first and foremost).

Avatar

About opening of links in new tabs or browser windows

by Micha ⌂, Tuesday, October 20, 2020, 16:21 (1246 days ago) @ Auge

Hello,

I do. And the every when and then up-popping threads with questions about target tells me, I am not alone. ;-)

You are not alone, of course, but you don't count the users that supports the non-target links. This is a biased presentation and you know it.

I do open most of the links in forums and on any other sites in new tabs.

Of course, I do it the same way like you. Currently, one has the choice to open a link in a new tab or to leave the side by clicking the link. So, the different is, that I make the decision and not the software.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

About opening of links in new tabs or browser windows

by Auge ⌂, Wednesday, October 21, 2020, 10:54 (1245 days ago) @ Micha

Hello,

Currently, one has the choice to open a link in a new tab or to leave the side by clicking the link. So, the different is, that I make the decision and not the software.

I thought about your argument and think, it's valid. On the other side there is obvoiusly a demand for several people to be able to open links in other windows, tabs or – to mention the case of ChristianForum – by breaking out of a frame/iframe.

Because of that I changed my intention to a two step solution.

1. Make the forum wide setting a named setting (as you proposed in the PR-discussion) _parent or _top. This would make it possible to provide a dedicated name of a frame/window or the keywords that are relevant for frame handling. Default value would be NULL, keywords (_blank and _self) would get ignored.
2. Add a user setting that activates the value _blank (the other possible keywords makes IMHO no sense in this context).

This would make it possible to handle the forum in a frameset (case 1) and to offer the opening of links in other tabs or windows only for the interested audience (case 2). But – and that's a big but – I have no clue how to inject the user setting into the relevant functions. Injecting the forum settings is easy, add global $settings; and you are done. But user settings are optional because not every visitor is a logged in user and therefore I can't use global for it. On the other hand I don't know how to add the user setting to the parameter list of the relevant functions. These functions get called only in the functions html_format and signature_format where the bbcode class gets configured for these special cases.

It would be possible to make the setting an optional paremeter for html_format and signature_format and provide it inside these functions for the calls of do_bbcode_url (Next question is how to commit it to these functions?). But this solution looks not really nearly elegant.

Does my thoughts lead to anywhere?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

About opening of links in new tabs or browser windows

by Micha ⌂, Wednesday, October 21, 2020, 17:11 (1245 days ago) @ Auge

Hi,

Because of that I changed my intention to a two step solution.

1. Make the forum wide setting a named setting (as you proposed in the PR-discussion) _parent or _top. This would make it possible to provide a dedicated name of a frame/window or the keywords that are relevant for frame handling. Default value would be NULL, keywords (_blank and _self) would get ignored.
2. Add a user setting that activates the value _blank (the other possible keywords makes IMHO no sense in this context).

I don't understand your intention because I don't understand these two cases. Create a variable target_frame. If target_frame == NULL or empty, the target attribute is not necessary and should omitted. In any other case, add the target attribute and use the value defined by target_frame. All cases are considered. There is no need to exclude values nor to define a second variable - please, keep it simple!

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

About opening of links in new tabs or browser windows

by Auge ⌂, Wednesday, October 21, 2020, 20:12 (1245 days ago) @ Micha

Hello

I don't understand your intention because I don't understand these two cases.

It was you who reminded me to respect the decision of users to open links in the same or in other windows. So this should be a user setting. On the other hand a forum operator/admin should be able to i.e. break out of a frameset. So there would be a need for a forum setting.

A forum operator should be able to provide a dedicated name of a frame but he shouldn't be able to dictate the users of his/her forum to open links in new windows/tabs, what would end in forbidding the value _blank. The user, who wants to open links in new windows/tabs, wants nothing else. So the user should be able to use another value. Additionally IMHO most of the users will not be able to set a proper name, they want to activate or disable the function. This would be best done with a boolean setting.

So I end with two settings in mind. The one for the forum and the other one for the users own settings.

Create a variable target_frame. … There is no need to exclude values nor to define a second variable - please, keep it simple!

I would, if I could. IMHO your proposal breaks your own rule to let the user decide how to handle the problem. If your proposed setting is a forum setting, you take the decision away from the user. If this is a user setting, the proper naming would IMHO overburden many interested users. This is against my intention. Because of that I let my idea die.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

About opening of links in new tabs or browser windows

by Micha ⌂, Wednesday, October 21, 2020, 21:00 (1245 days ago) @ Auge

Hello,

It was you who reminded me to respect the decision of users to open links in the same or in other windows. So this should be a user setting. On the other hand a forum operator/admin should be able to i.e. break out of a frameset. So there would be a need for a forum setting.

Ahh, yes, I understand your intention now; and, yes, this would be a great idea! I was wrong because I didn't understand that your proposal includes a global and user-defined variable (instead of two global ones). So, I'm very sorry.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

About opening of links in new tabs or browser windows

by Auge ⌂, Thursday, October 22, 2020, 07:29 (1244 days ago) @ Micha

Hello

I'm very sorry.

There's no need for a sorry. As stated in the PR I wll open a new one. Bofore doing that I need the answer to the underlying question how to inject the optional user setting.

Quoting one of my previous postings.

I have no clue how to inject the user setting into the relevant functions. Injecting the forum settings is easy, add global $settings; and you are done. But user settings are optional because not every visitor is a logged in user and therefore I can't use global for it. On the other hand I don't know how to add the user setting to the parameter list of the relevant functions. These functions get called only in the functions html_format and signature_format where the bbcode class gets configured for these special cases.

It would be possible to make the setting an optional paremeter for html_format and signature_format and provide it inside these functions for the calls of do_bbcode_url (Next question is how to commit it to these functions?). But this solution looks not really nearly elegant.

Addition to my thoughts: I stated the user setting to be optional and therefore not to be able to import it with global. A possibility would be to initialise this user setting as a pseudo setting in the main code so that it would exist in every single case. That way I can import it for sure with global. But also this solution looks not really nearly elegant. :-/

Beside from that I would have to check if the user informations and settings are stored under the same or different variable names in different scripts.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

About opening of links in new tabs or browser windows

by Micha ⌂, Thursday, October 22, 2020, 07:46 (1244 days ago) @ Auge

Hello,

I believe, it is impossible to change the code via a PHP function (html_format and signature_format). I think, we need a JavaScript solution. The reason is the caching option of the forum. It will be impossible to overwrite the global-forum settings by the user-defined one once the link is hard-coded.

What do you think about adding the variable to a script like the js_defaults?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

About opening of links in new tabs or browser windows

by Auge ⌂, Thursday, October 22, 2020, 08:25 (1244 days ago) @ Micha

Hello,

I believe, it is impossible to change the code via a PHP function (html_format and signature_format). I think, we need a JavaScript solution. The reason is the caching option of the forum. It will be impossible to overwrite the global-forum settings by the user-defined one once the link is hard-coded.

Yes, you are right. Three days ago I wrote about the pitfalls of entry caching and afterwards I do ignore my own findings. *tss tss tss*

What do you think about adding the variable to a script like the js_defaults?

Will this file get generated for each request (potentially different for each visitor/user)? If yes, then this is the way to go.

Good spot.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

About opening of links in new tabs or browser windows

by Micha ⌂, Thursday, October 22, 2020, 18:21 (1244 days ago) @ Auge

Hello,

Yes, this file is generated by the corresponding php file js_defaults.inc.php. Depending on the user type (user, mode, admin), the content is changed.

Ah, I see.

I believe, we can create a similar file that contains the user-defined values (if exist).

I looked into the generated file of this forum, where I am an administrator. I see the sections lang, settings and preload. Why not add a new section user_settings (or another meaningful name) instead adding a new file? Only registered users will be able to use this functionality. All of them get a JS-file delivered with content, aligned to the user type. So this would be IMHO a proper place.

Tschö, Auge

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

About opening of links in new tabs or browser windows

by Micha ⌂, Friday, October 23, 2020, 18:30 (1243 days ago) @ Micha

Hello,


Why not add a new section user_settings (or another meaningful name) instead adding a new file?

Yes, we can also extend the existing file by a new section and adding an option like:

user_settings['open_links_in_new_window'] = 'EXTERNAL';  // EXTERNAL, ALL, NON

Should we also extend the main.js, too, or is it better to create a new script e.g. entry.js. If we use a new file, we can save resources by adding something like:

{if $mode=='entry' || $mode=='thread'}
<script src="{$FORUM_ADDRESS}/js/entry.min.js" type="text/javascript" charset="utf-8"></script>
{/if}

A further problem is HTML structure. Whereas each entry provides a header and a body class in thread mode, such elements are not presented in the single entry view. Is it possible to add such classes, too? It would be helpful to restrict the scope of modifying the target-attribute.

My test script looks like that:

var user_settings = new Array();
user_settings["open_links_in_new_window"] = "EXTERNAL";  // EXTERNAL, ALL, NON
 
function Entry(el) {
 if (!el) 
  return;
 
 this.setLinkTarget = function() {
  if (user_settings["open_links_in_new_window"].toUpperCase() == "EXTERNAL" || 
   user_settings["open_links_in_new_window"].toUpperCase() == "ALL") {
   var entryBodies = el.getElementsByClassName("body");
   for (var i=0; i<entryBodies.length; i++) {
    var links = entryBodies[i].getElementsByTagName("a");
    for (var j=0; j<links.length; j++) {
     // skip internal links
     if (user_settings["open_links_in_new_window"].toUpperCase() == "EXTERNAL" && links[j].href.includes(window.document.location.origin))
      continue;
     links[j].target = "_blank";
    }
   }
  }
 };
};
 
function Entries(cEl) {
 if (!cEl) 
  return;
 console.log(user_settings);
 var pEls = cEl.getElementsByClassName("posting");
 pEls = pEls.length > 0 ? pEls : cEl.getElementsByClassName("thread-posting");
 pEls = (typeof pEls == "object" || typeof pEls == "function") && typeof pEls.length == "number"?pEls:[pEls];
 for (var i=0; i<pEls.length; i++) {
  var entry = new Entry(pEls[i]);
  entry.setLinkTarget(); 
 }
};
 
window.ready.push(function() {
 if (typeof user_settings == "object") 
  new Entries( document.getElementById("content") );
});


/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

About opening of links in new tabs or browser windows

by Auge ⌂, Saturday, October 24, 2020, 20:56 (1242 days ago) @ Micha

Hello,

Why not add a new section user_settings (or another meaningful name) instead adding a new file?


Yes, we can also extend the existing file by a new section and adding an option like:

user_settings['open_links_in_new_window'] = 'EXTERNAL';  // EXTERNAL, ALL, NON

This would need a non boolean setting (your proposal contains three states). Otherwise it looks like it's pointing into the right direction.

Should we also extend the main.js, too, or is it better to create a new script e.g. entry.js. If we use a new file, we can save resources by adding something like:

{if $mode=='entry' || $mode=='thread'}
<script src="{$FORUM_ADDRESS}/js/entry.min.js" type="text/javascript" charset="utf-8"></script>
{/if}

Every way begins with a first step. But creating a new script file for only this one function looks a bit to much for me. Do we have further functions that are only tied to the entry views that we can transfer to this new script or would we trench the existing code on to many places with this idea?

A further problem is HTML structure. Whereas each entry provides a header and a body class in thread mode, such elements are not presented in the single entry view. Is it possible to add such classes, too? It would be helpful to restrict the scope of modifying the target-attribute.

Of course sir, that's possible and it's IMHO important regard to a meaningful document structure.

In my theme every entry in every view is an article, has a header for the metadata of the entry, a div for the content of the entry and a footer for the tag list and the entry dependent function links. Even we are still on XHTML 1 in the default theme, we should at least provide a similar structure in all of the views.

My test script looks like that:

I did only a skim read (querlesen) but it looks o.k. to me in a first sight. I will implement the code in a new PR.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

About opening of links in new tabs or browser windows

by Micha ⌂, Saturday, October 24, 2020, 21:27 (1242 days ago) @ Auge

Hello,

This would need a non boolean setting (your proposal contains three states). Otherwise it looks like it's pointing into the right direction.

In most cases, I open internal and external links in a new tab, e.g., for reading the documentation and writing the answer. shian states that he always open links in a new tab. Always includes internal links of the forum, or not? So, I was not sure about the right decision and leave it open (the user should define her/his best way).

Every way begins with a first step. But creating a new script file for only this one function looks a bit to much for me.

I don't see a problem to add the code to the main.(min.)js. It was just a question on the topic of generating readable code.

Do we have further functions that are only tied to the entry views

No, I don't think so.

I agree, at this point and due to the small pieces of code, we should add the code to the main.js.

Of course sir, that's possible and it's IMHO important regard to a meaningful document structure.

Perfect. In this case, the access to the posting links is quite easy and avoids the distinction of cases (single vs. list view).

I did only a skim read (querlesen) but it looks o.k.

I will provide a further version, if the resulting HTML structure was adapted and the user-defined option are available in js_defaults.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

About opening of links in new tabs or browser windows

by Auge ⌂, Monday, October 26, 2020, 08:32 (1240 days ago) @ Micha

Hello

I don't see a problem to add the code to the main.(min.)js. It was just a question on the topic of generating readable code.

O.k. let's make it so. :ok:

One further question about the issue of readable code. The main.min.js has only half the size of the main.js (25 versus 50 kB). The relation of sizes of posting.min.js and posting.js is similar. admin.min.js actually has only a third of the size of admin.js. On one hand I'm fine with the reduction of traffic but on the other hand the minification makes maintaining the sources harder than necessary.

As you can see in several of my code contributions, I often use readable but long variable- and function-names. That inflates the file sizes of the script but – this is at least my hope – enhances the understandability of the code.

And now the question.

Isn't it time to tidy up the code from compatibility … errr … legacy code for long dead browsers so we could minify the JS-code without minifying it?

add classes from the threaded views also to the single entry view


Of course sir, that's possible and it's IMHO important regard to a meaningful document structure.

Perfect. In this case, the access to the posting links is quite easy and avoids the distinction of cases (single vs. list view).

I will open a dedicated PR for the HTML code adaption today.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

About opening of links in new tabs or browser windows

by Micha ⌂, Monday, October 26, 2020, 09:31 (1240 days ago) @ Auge

Hello,

One further question about the issue of readable code. The main.min.js has only half the size of the main.js (25 versus 50 kB)....

We can omit to compress the sources for CSS and JS files. I believe, 50 kb is not a traffic problem (today) and these files are (usually) cached by the browser.

Isn't it time to tidy up the code from compatibility … errr … legacy code for long dead browsers so we could minify the JS-code without minifying it?

Most of the file size comes from comments and not from the code itself. To reduce the size, it is more reasonable to remove such comments than to look for some dead codes. Moreover, I'm not up-to-date which browser supports a function and which one not. For some functions, e.g.,

/**
 * Liefert eine Liste mit Elementen, die die
 * selbe CSS-Klasse haben
 *
 * @param class_name
 * @return node_list
 */
if(typeof document.getElementsByClassName != 'function') {  
 document.getElementsByClassName = function (class_name) {
 var all_obj,ret_obj=new Array(),j=0,teststr;
 if(this.all)
  all_obj=this.all;
 else if(this.getElementsByTagName && !this.all)
  all_obj=this.getElementsByTagName("*");
 var len=all_obj.length;
 for(var i=0;i<len;i++) {
  if(all_obj[i].className.indexOf(class_name)!=-1) {
   teststr=","+all_obj[i].className.split(" ").join(",")+",";
   if(teststr.indexOf(","+class_name+",")!=-1) {
    ret_obj[j]=all_obj[i];
    j++;
   }
  } 
 }
 return ret_obj;
 };
}


I can check the availability of these functions, cf. getElementsByClassName. For this example: all modern browsers support this function and the code can reduced. Which version is your preferred version that we should support?

I will open a dedicated PR for the HTML code adaption today.

Perfect.

Do you also create a PR for the user_settings and the corresponding changes in PHP/MySQL?

regards
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

About opening of links in new tabs or browser windows

by Auge ⌂, Monday, October 26, 2020, 11:19 (1240 days ago) @ Micha

Hello,

One further question about the issue of readable code. The main.min.js has only half the size of the main.js (25 versus 50 kB)....


We can omit to compress the sources for CSS and JS files. I believe, 50 kb is not a traffic problem (today) and these files are (usually) cached by the browser.

The file size of 50kB/25kB/4.5kB (to name also the other script files) does not seem to cause much traffic but for users with a data limit (i.e. per month) every bit counts. The second argument (browser cache) fits IMHO much better.

Isn't it time to tidy up the code from compatibility … errr … legacy code for long dead browsers so we could minify the JS-code without minifying it?


Most of the file size comes from comments and not from the code itself.

I thought, indentation and line breaks (that got removed in the minified code) and also the variable names (that got shortened (often to a single char)) would save more file size. But I havn't counted and compared.

To reduce the size, it is more reasonable to remove such comments than to look for some dead codes. Moreover, I'm not up-to-date which browser supports a function and which one not.

Code that you call "dead code" is the target of my consideration. The forum code (especially the JS-code) keeps compatibility to (for example) IE down to 5.anything (afaik).

[getElementsByClassName] … For this example: all modern browsers support this function and the code can reduced.

This is a good example. You rebuilt the functionallity for browsers with no support for getElementsByClassName (as shown in your code example). CanIUse? tells us, that this method works beginning with IE9 and FF3. Other browsers seem to had support from the beginning, so there's no problem with them.

Now to the latest versions with no support. FF2 is dead, so it's no problem at all. IE8 is the latest IE-version that was released for Windwos XP. Anyone who use Windows XP with an internet connection nowadays is stupid, foolish and a gambler in relation to system security and has the alternative to use other browsers that are not so stone-age (same argument is valid for the OS). Additionally Windows XP is outdated and gets no support since more than six years. So we should not cosider to support ist.

Which version is your preferred version that we should support?

I propose to remove the support for IE of version lower than 9 in our JS-scripts. All other browsers get updates very often so we can assume that all browsers (beside from IE) are more or less up-to-date. On the other hand we should keep the comments, especially if we do not minify the code. In this case we will have only the one script file (for every use case) and the comments enhances the understandability of the code.

Therefore we should also translate the comments to English language (many comments are in german language).

I will open a dedicated PR for the HTML code adaption today.

Perfect.

Do you also create a PR for the user_settings and the corresponding changes in PHP/MySQL?

Yes I will.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

About opening of links in new tabs or browser windows

by Micha ⌂, Monday, October 26, 2020, 17:11 (1240 days ago) @ Auge

Hello,

Which version is your preferred version that we should support?


I propose to remove the support for IE of version lower than 9 in our JS-scripts. All other browsers get updates very often so we can assume that all browsers (beside from IE) are more or less up-to-date. On the other hand we should keep the comments, especially if we do not minify the code. In this case we will have only the one script file (for every use case) and the comments enhances the understandability of the code.

I overworked the script files but I didn't check every modified function by every browser. So, please report problems if occur.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

About opening of links in new tabs or browser windows

by Auge ⌂, Monday, October 26, 2020, 16:25 (1240 days ago) @ Micha

Hello

I will open a dedicated PR for the HTML code adaption today.

Perfect.

First PR: 542, HTML-structure

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

About opening of links in new tabs or browser windows

by Micha ⌂, Monday, October 26, 2020, 21:30 (1240 days ago) @ Auge

Hi,

First PR: 542, HTML-structure

Okay, I add the corresponding JS part. Please note, I hard coded the user preferences to illustrate the working procedure. This code should not merged until this hard coded part is removed.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

About opening of links in new tabs or browser windows

by Auge ⌂, Monday, October 26, 2020, 22:20 (1239 days ago) @ Micha

Hello

Okay, I add the corresponding JS part. Please note, I hard coded the user preferences to illustrate the working procedure. This code should not merged until this hard coded part is removed.

I saw the PR :ok: and its state (draft).

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Forum error - wrong author?!

by Micha ⌂, Friday, October 23, 2020, 18:37 (1243 days ago) @ Micha

Hello,

Tschö, Auge

Why don't you are the posting author?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Auge error - wrong author!

by Auge ⌂, Friday, October 23, 2020, 22:49 (1242 days ago) @ Micha

Hello,

Tschö, Auge


Why don't you are the posting author?

Ahem, because I didn't write an answer but edited your posting.

I am sorry.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Auge error - wrong author!

by Micha ⌂, Saturday, October 24, 2020, 09:14 (1242 days ago) @ Auge

Hello,

Ahem, because ...

*lol*, okay, back to topic.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Please stop this effectless discussion

by Auge ⌂, Wednesday, October 21, 2020, 09:04 (1245 days ago) @ Auge

Hello

Please stop the discussion about following or ignoring the rules of HTML. It will have absolutely no outcome.

If and when we introduce the target functionality, we will (no ifs and buts) change from XHTML strict to transitional. This is the one and only tidy solution.

Yes, the browsers are fault-tolerant and execute/render the target attribute even with the strict HTML dialect. So we wouldn't break the forum for no one. But no, this is no solution, independent if a purported common law exists or not. There is the tidy solution with changing the HTML dialect to transitional and we will follow this way (if and when).

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Please stop this effectless discussion

by shian, Wednesday, October 21, 2020, 09:42 (1245 days ago) @ Auge

Please stop the discussion about following or ignoring the rules of HTML. It will have absolutely no outcome.

I'm not discussing anything with anybody - I've just implemented what I needed in my own forum, using your instructions, and my own experience.

What I was asking you is: if possible, to get detailed instructions for implementing the LTR-RTL BBcode manually. YES - YES, NO - NO.

btw, I'm only trying to give feedback and help others. If this is also "out of rule" then just delete my membership.

Thank you, shian.

Avatar

Please stop this effectless discussion

by Auge ⌂, Wednesday, October 21, 2020, 09:53 (1245 days ago) @ shian

Hello

btw, I'm only trying to give feedback and help others. If this is also "out of rule" then just delete my membership.

I hope, you can distinguish between an interdiction and a plea.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

About opening of links in new tabs or browser windows

by Micha ⌂, Sunday, November 22, 2020, 10:23 (1213 days ago) @ Auge

Hej Auge,

what is the state of solving this issue? I modified the JS part and stopped working because I need the PHP part - the user option. Are we agree that you implement the PHP part or do you wait for me? ;-)

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

About opening of links in new tabs or browser windows

by Auge ⌂, Thursday, December 03, 2020, 07:58 (1202 days ago) @ Micha

Hello Micha

what is the state of solving this issue? I modified the JS part and stopped working because I need the PHP part - the user option. Are we agree that you implement the PHP part or do you wait for me? ;-)

Sorry, that I didn't answer for so long. Yes, I will implement the PHP-part and afterwards you are on the run with the JS.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

RSS Feed of thread