[Webkit-unassigned] [Bug 21268] CSS file line numbers should be displayed on styles pane

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=21268


Joseph Pecoraro <joepeck at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joepeck at webkit.org




--- Comment #9 from Joseph Pecoraro <joepeck at webkit.org>  2010-01-18 18:58:45 PST ---
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

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.