What doesn't make sense is that when I enter the URL into a browser, it goes to the top of the question's page
Not the case for myself. Using the answer-link in the question my browser ends up looking at the (selected) answer (by Nars).
- Chromium Version 83.0.4103.116 (Developer Build) built on Debian 10.4, running on Debian 10.0 (64-bit)
or is this just buggy behaviour on the server side?
Nothing to do with the server, everything to do with the client browser.
I'm going to deconstruct the whole thing because @justanotheruser cannot accept what I am saying.
The link url is deconstructed into it's URL scheme as follows:-
- https://ask.libreoffice.org/en/question/29139/can-the-new-start-screen-in-v42-be-reverted-to-that-in-v41/?answer=36673#post-id-36673
(the text of the question duplicated within the URL can be removed): - https://ask.libreoffice.org/en/question/29139/?answer=36673#post-id-36673
(also the answer-part): - https://ask.libreoffice.org/en/question/29139/#post-id-36673
(using php parse_url() on that gives): - ["scheme"]=>"https"
- ["host"]=>"ask.libreoffice.org"
- ["path"]=>"/en/question/29139/"
- ["fragment"]=>"post-id-36673"
When the URI in (3) is issued by a browser, it does the following:-
a) It determines the address of the host using DNS
b) It sends a HTTP GET request to the host composed from parts of the URI in (3)
c) The server will respond with a 301 Moved Permanently pointing to the original URI as in (1)
d) The browser repeats previous actions, now using (1)
e) The file-resource at the path arrives at the browser, possibly in a hundred little pieces, and not necessarily in order
f) The browser consults to see whether it (i) has the file-resource already in it's cache and, if so, (ii) whether that cache can be used
g) The file-resource (either new or as-cached) is shown on-screen; the top of the file is shown at the top of the screen (naturally, only when the browser has both received it & composed it for the screen)
h) When enough of the file-resource has been received as to reach the location of the fragment (and all points in between to the top of the file) then the view can be shifted down to the fragment.
And now, as long as your internet has not lost any vital bits of the file, you should be looking at Nars's answer. If not, then any problem lies with some combination of your machine / browser / internet-connection. If it can work without a problem for me (and it does) then potentially the same can be true for you.
Good question but I have no answer. Could you, please, change tag
commontometa? Use the edit link at end of title, not the one below the question. Thanks."So the link to the answer is no better than a link to the question."
Have you considered that, in order to understand an answer, it is often necessary to first understand the question? So, the question is sometimes a good place to start.
I could not confirm the "when I enter the URL into a browser, it goes to the top of the question's page". The
has an url of the kind:
It has an "answer" GET parameter pointing to which section should be highlighted, and also a fragment starting with
#that tells the browser where to scroll (both naturally referring to the same answer). I have confirmed that e.g. Google Chrome shows the accepted answer by @Nars at the top of the window when it opens the URL.@ajlittoz: I was in the process of changing tag
commontometa, but a question occurred to me. Hoping you can shed light. I can divine the reason formeta, but am I right in assuming thatcommonmeans it applies across all of the LibreOffice apps? What distinguishes these two tags?@ve3oat: I see your point. In general (not necessarily the example here), however, for a thread with many responses, it may be hard to focus a reader on the specific post of interest. So the link icon for each post should yield a URL that directs the browser to the specific post. Otherwise, the icon should not be there.
@Mike Kaganski: Interesting. The
#syntax should not be specific to a browser. I've used that notation decades ago. I just tried the URL in Microsoft Edge, and I still get positioned at the top of the page rather ...(more)As I said, # denotes "fragment" URL part that is of course in standard. So of course, it is not browser-specific.
Yes, thanks. I understood. My point is that it seems to be that the observed behaviour seems to be browser specific. It works for you on Chrome. It fails for me on Firefox and Edge. Until we get more information, the problem as I see it is that the browser-specific behaviour deviates from the expectation of browser-agnostic and proper positioning of the browser at the specified portion of that page.
@JustA.NotherUser: you understand right.
commonrelates to an issue "common" to all components when using LO, e.g. something with print orTools>Options, features which are shared, or also font rendering or window management.metais not "directly" related to LO usage; this is why questions about AskLO are tagged so, but you could also have questions about LO "philosophy", workflow , principles or roadmap. These questions do not involve matter-of-fact problems encountered during a precise usage (but may evoke potential problems).Sometimes the dividing line between
commonandmetamay be thin. But, in no case,commonhas the usual meaning of "problem-universally-met-by-all-users-in-daily-use". So analyse first your problem. It stems from a concrete issue with a component. When in doubt about the shared nature, choose to tag with the component name (writer,calc, etc.).