Broken links in WebIDL for constants

[michael-n-cooper]

When using respec magic to output WebIDL from special definition lists, it outputs lists of properties about an object, beginning with an index linked to a fuller definition. The expanded definition gets an ID that is concatenated from a few things, and the index link uses the same concatenation to form the in-page link. For most properties (attributes, properties, etc.) this works fine. But for constants, the index link is not concatenated properly and therefore is a broken link to the target.

For example, in https://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/indie-ui-events.html#UIFocusRequestEvent there are a lot of constants defined (UNKNOWN, NAV_FIRST, etc.). All those links in the list at the top are broken; a source inspection shows that the link target is not the same as the ID of the expanded definition of the constant below. However, the link for the attribute focusType, at the bottom of that link, does correctly link to its expanded definition. Therefore it appears to be only constants for which proper link creation is overlooked.

[marcoscaceres]

On Friday, July 26, 2013 at 8:48 PM, michael-n-cooper wrote:

When using respec magic to output WebIDL from special definition lists, it outputs lists of properties about an object, beginning with an index linked to a fuller definition. The expanded definition gets an ID that is concatenated from a few things, and the index link uses the same concatenation to form the in-page link. For most properties (attributes, properties, etc.) this works fine. But for constants, the index link is not concatenated properly and therefore is a broken link to the target.

A little off topic, but you should not be using constants in the way you are doing anyway. See the big red warning:
http://www.w3.org/TR/WebIDL/#idl-constants

For example, in https://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/indie-ui-events.html#UIFocusRequestEvent there are a lot of constants defined (UNKNOWN, NAV_FIRST, etc.). All those links in the list at the top are broken; a source inspection shows that the link target is not the same as the ID of the expanded definition of the constant below. However, the link for the attribute focusType, at the bottom of that link, does correctly link to its expanded definition. Therefore it appears to be only constants for which proper link creation is overlooked.

It's probably that because specs are not supposed to be using them that this hasn't come up :)

[darobin]

@michael-n-cooper I can't seem to reproduce the problem. Assuming that you're talking about the enum (rather than constants) I see links generated just fine, they work when clicked, they match the IDs, etc.

Note however that as @marcoscaceres points out, using numeric values like that isn't very friendly to developers and is broadly considered bad practice (see http://berjon.com/blog/2011/06/numerical-constants-must-die.html).

I'm closing for now, please reopen if you can point me to an issue I can reproduce.