The tag page index seems incorrect in one place #132

New Issue

davmo · 2023-06-22T18:43:45Z

davmo commented

2023-06-22 18:43:45 +00:00

The multi-column index on this page lists initial letters of blocks of tags.

Clicking on the letter 'k' does not move to the corresponding 'k' tags. Instead, it moves to the middle of the 'c' block.

I have seen this before; it has something to do with Unicode characters being used as anchors. I can investigate unless someone else wants to.

The multi-column index on this page lists initial letters of blocks of tags. Clicking on the letter 'k' does not move to the corresponding 'k' tags. Instead, it moves to the middle of the 'c' block. I have seen this before; it has something to do with Unicode characters being used as anchors. I can investigate unless someone else wants to.

davmo commented

2023-08-07 17:31:43 +00:00

As I have been working on #152 to make all tags into links to the tag page I have noticed a few things:

The anchors on the tag page are all lower case (which is good)
If the original tag is multi-word the spaces are part of the anchor (seems to work OK, but feels like a bit of a problem waiting to happen)
Some tags contain Unicode characters, and therefore, so do the anchors, and that can cause problems.

Suggestions:

Any code that needs to look up a tag must convert the anchor to lower case
Maybe in the anchors we should replace spaces with underscores
We should use some kind of Unicode conversion when generating anchors (HTML entity?)

As I have been working on #152 to make all tags into links to the tag page I have noticed a few things: 1. The anchors on the tag page are all lower case (which is good) 1. If the original tag is multi-word the spaces are part of the anchor (seems to work OK, but feels like a bit of a problem waiting to happen) 1. Some tags contain Unicode characters, and therefore, so do the anchors, and that can cause problems. Suggestions: 1. Any code that needs to look up a tag must convert the anchor to lower case 1. Maybe in the anchors we should replace spaces with underscores 1. We should use some kind of Unicode conversion when generating anchors (HTML entity?)

rho_n commented

2024-09-15 13:53:49 +00:00

According to the HTML spec, the ID attribute should not contain any ASCII white-space characters

I agree, when generating the ID the tags white-space should become an underscore to meet the spec.

According to the HTML spec, the ID attribute should not contain any ASCII white-space characters * https://html.spec.whatwg.org/multipage/dom.html#global-attributes:the-id-attribute-2 * https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/id#syntax I agree, when generating the ID the tags white-space should become an underscore to meet the spec.

rho_n commented

2024-09-15 14:04:17 +00:00

Other than no ASCII white-space characters, an ID attribute can be any other Unicode character. The Mozilla documentation does say if you want the ID to be used as a CSS selector, then it must be a valid CSS identifier.

https://developer.mozilla.org/en-US/docs/Web/CSS/ident

From what I read, a Unicode character is a valid as part of a CSS identifier, but you can also use escape sequences.

Other than no ASCII white-space characters, an ID attribute can be any other Unicode character. The Mozilla documentation does say if you want the ID to be used as a CSS selector, then it must be a valid CSS identifier. * https://developer.mozilla.org/en-US/docs/Web/CSS/ident From what I read, a Unicode character is a valid as part of a CSS identifier, but you can also use escape sequences.

rho_n commented

2024-09-15 15:58:39 +00:00

I'm not sure what is going on yet, but it seems like any tags that start with K are being dropped, and that instead of the actual tags being included in the html, it is the name of variables used in the code: count and urls.

I am looking into the issue.

I'm not sure what is going on yet, but it seems like any tags that start with K are being dropped, and that instead of the actual tags being included in the html, it is the name of variables used in the code: count and urls. I am looking into the issue.

rho_n commented

2024-09-16 03:05:33 +00:00

I have determined that the tag with the value of 'keys' is causing the issue. keys is a reserved word in the context of hashes. I haven't figured out how to use the value keys as a key. The following is the context in which it causes an issue:

        IF all_tags.${first_char}.exists(tag);
            all_tags.${first_char}.${tag}.count = all_tags.${first_char}.${tag}.count + 1;
            all_tags.${first_char}.${tag}.urls.push(ep_id);
        ELSE;
            all_tags.${first_char}.${tag}.count = 1;
            uniq_tag_count = uniq_tag_count + 1;
            all_tags.${first_char}.${tag}.urls = [ep_id];
        END;

Instead of interpreting ${tag} as the string "keys" it interprets it as the command/method keys (which returns a list of keys)

I have determined that the tag with the value of 'keys' is causing the issue. keys is a reserved word in the context of hashes. I haven't figured out how to use the value keys as a key. The following is the context in which it causes an issue: ``` IF all_tags.${first_char}.exists(tag); all_tags.${first_char}.${tag}.count = all_tags.${first_char}.${tag}.count + 1; all_tags.${first_char}.${tag}.urls.push(ep_id); ELSE; all_tags.${first_char}.${tag}.count = 1; uniq_tag_count = uniq_tag_count + 1; all_tags.${first_char}.${tag}.urls = [ep_id]; END; ``` Instead of interpreting ${tag} as the string "keys" it interprets it as the command/method keys (which returns a list of keys)

rho_n commented

2024-09-28 16:54:03 +00:00

PR205 fixes the issues and is merged into main.

[PR205 fixes the issues](https://repo.anhonesthost.net/HPR/hpr_generator/pulls/205) and is [merged into main](https://repo.anhonesthost.net/HPR/hpr_generator/commit/73dd71f2f0bf9f6e772b656c00acfd11f0e6ed6c).

rho_n closed this issue

2024-09-28 16:54:03 +00:00

Sign in to join this conversation.