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

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.

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.

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

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.

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

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.

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.

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.