Bug 76428 – Each style rule should have its own ID

• Component: WebKit Website
• Status: RESOLVED FIXED

[Kent Tamura]

I sometimes want to introduce one style rule to another WebKit developer. Now we have to introduce like:
  "The third item of the Indentation section in http://www.webkit.org/coding/coding-style.html"

If we introduced id attributes like

<li id="indentation-namespace" title="#indentation-namespace">The contents of an outermost <code>namespace</code> block (and any nested namespaces with the same scope)

, we would be able to introduce it by a URI reference like http://www.webkit.org/coding/coding-style.html#indentation-namespace

[Kent Tamura]

Created attachment 123256 [details]
Patch

[David Levin]

How do I get a link to a rule?

I kind of want some sort of href so I can click it and it will update the address bar with the correct link for that rule. Does that make sense?

[Kent Tamura]

Created attachment 123258 [details]
Patch 2

Make LI clickable

[Kent Tamura]

(In reply to comment #2)
> How do I get a link to a rule?
> 
> I kind of want some sort of href so I can click it and it will update the address bar with the correct link for that rule. Does that make sense?

I examined such idea, but I thought enclosing each of <li> with <a href=></a> looked bad.
WIth the latest patch, a LI element has title="#id" and is clickable to jump to #id.

[David Levin]

Comment on attachment 123258 [details]
Patch 2

View in context: https://bugs.webkit.org/attachment.cgi?id=123258&action=review

> Websites/webkit.org/coding/coding-style.html:233
> +<li id="linebreaking-multiple-satements">Each statement should get its own line.

s/satements/statements/

> Websites/webkit.org/coding/coding-style.html:249
> +<li id="linebreaking-elese-braces">An <code>else</code> statement should go on the same line as a preceding close brace if one is present,

s/elese/else/

> Websites/webkit.org/coding/coding-style.html:1104
> +    listItems[i].setAttribute('title', '#' + listItems[i].id);

May I get a hand as well so I can quick tell what is clickable? (I don't think that is there just b/c you are listening for the click event.)

listItems[i].style.cursor = ' pointer';

> Websites/webkit.org/coding/coding-style.html:1107
> +    });

Perhaps it should check for duplicate ids as well?

Something like this:

var idsUsed = new Object();
for ...

  if (idsUsed[listItems[i].id])
     alert("The id " + listItems[i].id + " is used more than once in this document.");
  idsUsed[listItems[i].id] = 1;

[Kent Tamura]

Created attachment 123266 [details]
Patch for landing

[Kent Tamura]

Comment on attachment 123258 [details]
Patch 2

View in context: https://bugs.webkit.org/attachment.cgi?id=123258&action=review

Thanks.  I followed your comments.

>> Websites/webkit.org/coding/coding-style.html:1104
>> +    listItems[i].setAttribute('title', '#' + listItems[i].id);
> 
> May I get a hand as well so I can quick tell what is clickable? (I don't think that is there just b/c you are listening for the click event.)
> 
> listItems[i].style.cursor = ' pointer';

Adding :hover style might be helpful too.

[Kent Tamura]

Committed r105494: <http://trac.webkit.org/changeset/105494>

This change made it extremely hard to use double- or triple-clicking to select anything on the Coding Style Guidelines webpage, and to click to clear the selection. In OS X, it also made WebKit almost always show a tool tip over the page, obscuring the content. I don’t see how any of the changes here that detracted from the page’s usability have to do with the statement “each style rule should have its own ID”.

[Kent Tamura]

(In reply to comment #9)
> This change made it extremely hard to use double- or triple-clicking to select anything on the Coding Style Guidelines webpage, and to click to clear the selection. In OS X, it also made WebKit almost always show a tool tip over the page, obscuring the content. I don’t see how any of the changes here that detracted from the page’s usability have to do with the statement “each style rule should have its own ID”.

Thank you for the comment.  Let's improve it in Bug 78470.