www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - OK to change anchor names in the language specification?

reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
Many sections on dlang.org have anchor names, allowing for direct 
linking to a particular section. Some examples include:

http://dlang.org/function#interpretation
http://dlang.org/arrays#static-arrays
http://dlang.org/template#alias-template
http://dlang.org/template#function-templates
http://dlang.org/statement#foreach_with_ranges
http://dlang.org/expression#Expression

As pointed out by Kenji in this pull request[1], this is a mess 
of hyphen vs underscore, singular vs plural and lowercase vs 
PascalCase. These names are manually specified in the DDoc 
document, not automatically generated.

The aforementioned pull request[1] would make these anchors 
public, by making the section headers links to themselves.

The question is - do we unify their formatting before making them 
public? This would break existing links, but these links were 
nigh unobtainable in the first place.

If we do change the format, which style do we use? Do we use 
different styles for different kinds of sections, or just one 
throughout? Here is some data to help make a decision[2]. Sorry 
if the quality of the data is poor.

[1] https://github.com/D-Programming-Language/dlang.org/pull/497
[2] http://pastebin.com/Z6S3z6cC
Feb 15 2014
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Saturday, 15 February 2014 at 10:47:14 UTC, Jakob Ovrum wrote:
 The question is - do we unify their formatting before making 
 them public? This would break existing links, but these links 
 were nigh unobtainable in the first place.

Google occasionally displays links to anchors in its search results. For example, search for "dlang blockstatement". I think the best way around this is to allow creating "legacy" hidden anchors, in addition to visible ones.
Feb 15 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 15.02.2014 17:26, schrieb Vladimir Panteleev:
 On Saturday, 15 February 2014 at 10:47:14 UTC, Jakob Ovrum wrote:
 The question is - do we unify their formatting before making them
 public? This would break existing links, but these links were nigh
 unobtainable in the first place.

Google occasionally displays links to anchors in its search results. For example, search for "dlang blockstatement". I think the best way around this is to allow creating "legacy" hidden anchors, in addition to visible ones.

If you have control over the web server, HTTP 301 redirects could be used instead. -- Paulo
Feb 15 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/15/2014 2:47 AM, Jakob Ovrum wrote:
 Many sections on dlang.org have anchor names, allowing for direct linking to a
 particular section. Some examples include:

 http://dlang.org/function#interpretation
 http://dlang.org/arrays#static-arrays
 http://dlang.org/template#alias-template
 http://dlang.org/template#function-templates
 http://dlang.org/statement#foreach_with_ranges
 http://dlang.org/expression#Expression

 As pointed out by Kenji in this pull request[1], this is a mess of hyphen vs
 underscore, singular vs plural and lowercase vs PascalCase.

I think the anchor name should match the section text.
Feb 15 2014
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Saturday, 15 February 2014 at 21:59:15 UTC, Paulo Pinto wrote:
 Am 15.02.2014 17:26, schrieb Vladimir Panteleev:
 I think the best way around this is to allow creating "legacy" 
 hidden
 anchors, in addition to visible ones.

If you have control over the web server, HTTP 301 redirects could be used instead.

The web server never sees anchors in URLs, so that would be impossible.
Feb 15 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Saturday, 15 February 2014 at 22:27:35 UTC, Vladimir Panteleev 
wrote:
 On Saturday, 15 February 2014 at 21:59:15 UTC, Paulo Pinto 
 wrote:
 Am 15.02.2014 17:26, schrieb Vladimir Panteleev:
 I think the best way around this is to allow creating 
 "legacy" hidden
 anchors, in addition to visible ones.

If you have control over the web server, HTTP 301 redirects could be used instead.

The web server never sees anchors in URLs, so that would be impossible.

I think it might be very possible, unless I'm missing something[0]? [0] http://httpd.apache.org/docs/2.2/rewrite/flags.html#flag_ne
Feb 15 2014
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sunday, 16 February 2014 at 01:16:22 UTC, Rikki Cattermole 
wrote:
 On Saturday, 15 February 2014 at 22:27:35 UTC, Vladimir 
 Panteleev wrote:
 The web server never sees anchors in URLs, so that would be 
 impossible.

I think it might be very possible, unless I'm missing something[0]? [0] http://httpd.apache.org/docs/2.2/rewrite/flags.html#flag_ne

That example redirects *to* an anchor. Since the anchor part of an URL is never sent to the server, the server has no way to act upon it. It is only possible using JavaScript.
Feb 15 2014
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sunday, 16 February 2014 at 01:29:12 UTC, Vladimir Panteleev 
wrote:
 On Sunday, 16 February 2014 at 01:16:22 UTC, Rikki Cattermole 
 wrote:
 On Saturday, 15 February 2014 at 22:27:35 UTC, Vladimir 
 Panteleev wrote:
 The web server never sees anchors in URLs, so that would be 
 impossible.

I think it might be very possible, unless I'm missing something[0]? [0] http://httpd.apache.org/docs/2.2/rewrite/flags.html#flag_ne

That example redirects *to* an anchor. Since the anchor part of an URL is never sent to the server, the server has no way to act upon it. It is only possible using JavaScript.

Quoting RFC 3986:
 As such, the fragment identifier is not used in the 
 scheme-specific processing of a URI; instead, the fragment 
 identifier is separated from the rest of the URI prior to a 
 dereference, and thus the identifying information within the 
 fragment itself is dereferenced solely by the user agent, 
 regardless of the URI scheme. Although this separate handling 
 is often perceived to be a loss of information, particularly 
 for accurate redirection of references as resources move over 
 time, it also serves to prevent information providers from 
 denying reference authors the right to refer to information 
 within a resource selectively.

Feb 15 2014
prev sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Saturday, 15 February 2014 at 10:47:14 UTC, Jakob Ovrum wrote:
 The question is - do we unify their formatting before making 
 them public? This would break existing links, but these links 
 were nigh unobtainable in the first place.

It think it is ok to break anchors, Google will fix itself and the page will still load for others, it just won't be as friendly.
Feb 15 2014