Bug 21268 – CSS file line numbers should be displayed on styles pane

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector (Deprecated)

[Henry Jalonen]

This useful feature is present in Firebug and missing from WebKit inspector, which I'm really missing.

[Timothy Hatcher]

<rdar://problem/6116072>

[Timothy Hatcher]

*** Bug 21324 has been marked as a duplicate of this bug. ***

[Timothy Hatcher]

*** Bug 27362 has been marked as a duplicate of this bug. ***

[jasonevers]

I also would love this to be implemented. +5

[jasonevers]

Created attachment 43793 [details]
Example of CSS Line numbers implementation [screenshot]

[jasonevers]

Comment on attachment 43793 [details]
Example of CSS Line numbers implementation [screenshot]

http://img.skitch.com/20091124-rxtwi85rw2um1xiw88ft4be5r8.jpg

[Timothy Hatcher]

Out style is file:line.

So: imac.css:144

[jasonevers]

That format sounds spectacular.

[Joseph Pecoraro]

It seems this is a very common request. So I looked things over.
A few thoughts out loud:

  1. The Web Inspector currently gets all its style info
     through public DOM methods. As far as I know, everything
     is available, up to the filename (taken from the href)
     of the Stylesheet. Line numbers however aren't available.
     
     Would exposing them through the DOM, say in an IDL like
     CSSStyleRule be taboo? I'd like to know the process on
     creating non-standard, but public properties.

  2. Grammar Changes. Currently whitespace is breezed over:
  
      - css/tokenizer.flex has
      
>         [ \t\r\n\f]+            {yyTok = WHITESPACE; return yyTok;}

      - css/CSSGrammar.y has
  
>         %token WHITESPACE SGML_CD

      - css/CSSParser.cpp in CSSParser::lex(void* yylvalWithoutType)

>         switch (token()) {
>         case WHITESPACE:
>         case SGML_CD:
>         case INCLUDES:
>         case DASHMATCH:
>             break;
  
    If we were to quickly add this, we could just have a counter,
    and increment the counter in the lexer however many newlines
    we see in the WHITESPACE (and SGML_CD?) tokens. I have a
    feeling that would probably have an impact performance.
    (Reparsing a string that was already parsed into a token).
    
    An alternative would be breaking WHITESPACE up in the
    tokenizer/grammar. Counting newlines there, and ignoring
    other whitespace as usual. This would (hopefully) ensure the
    text is parsed just once, keeping the performance about
    the same.
    
    Assuming a developer were to try out these approaches, are
    there tools for testing the performance of the CSS parser?
    I noticed some recent work on the JavaScript grammar had
    some tooling for just testing parsing:
    https://bugs.webkit.org/show_bug.cgi?id=32722#c17

[Ron Domingue]

Line numbering provides an efficient way to identify adjustments and errors in CSS.

[Pavel Feldman]

Fixed as a part of 36414