WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
36421
Web Inspector: Allow viewing styles of pseudo-elements
https://bugs.webkit.org/show_bug.cgi?id=36421
Summary
Web Inspector: Allow viewing styles of pseudo-elements
Aryeh Gregor
Reported
2010-03-20 18:57:49 PDT
E.g., data:text/html,<!doctype html><input placeholder=Placeholder> The placeholder is light gray. Web Inspector doesn't seem to be able to tell me about the existence or styles of the ::-webkit-placeholder to inform me why this is so. Also can be annoying when people use :before and :after. JoePeck in #whatwg suggested I file a bug.
Attachments
[IMAGE] Screenshot while running with patch.
(94.00 KB, image/png)
2010-03-21 07:27 PDT
,
Pavel Feldman
no flags
Details
[PATCH] Wip patch.
(4.29 KB, patch)
2010-03-21 07:40 PDT
,
Pavel Feldman
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Timothy Hatcher
Comment 1
2010-03-20 20:23:33 PDT
I'm pretty sure this is a dupe, but I can't find it…
Pavel Feldman
Comment 2
2010-03-21 07:27:28 PDT
Created
attachment 51245
[details]
[IMAGE] Screenshot while running with patch.
Pavel Feldman
Comment 3
2010-03-21 07:40:25 PDT
Created
attachment 51246
[details]
[PATCH] Wip patch. I can't land it just like this since all pseudo styles are considered as matching styles by the front-end and start overriding each other visually (using strike-through rendering). I need to somehow pass the fact that the rule is matched using pseudo style to the caller.
Joseph Pecoraro
Comment 4
2010-03-21 09:39:55 PDT
getMatchedCSSRules no longer calling getMatchedCSSRules is confusing.
Pavel Feldman
Comment 5
2010-03-21 11:45:30 PDT
(In reply to
comment #4
)
> getMatchedCSSRules no longer calling getMatchedCSSRules is confusing.
It is still returning matched rules, isn't it? Btw, window is likely to lose corresponding method soonish. The thing that concerns me more is the following usecase: Given the CSS fragment: .bar, .bar::after { content: "After bar"; color: red; } .bar { color:blue; } When element with class bar is selected, "color:red" belonging to the first rule should be marked as overriden, but it still applies to the after element. We have three options here: 1) Strike through color:red. As a result ::after element is still red and that is a bit confusing. 2) Do not strike through color:red. This is nice wrt after element, but .bar gets two 'active' values for color in two different rules. Less confusing, still formally incorrect. 3) Form a pseudo-element section and put all pseudo-element-related rules there. Formally correct, but introduces more clutter in the ui. I am leaning towards (3) + render pseudo-element separator similarly to the inherited styles today. Thoughts, comments?
Joseph Pecoraro
Comment 6
2010-03-21 15:53:07 PDT
> I am leaning towards (3) + render pseudo-element separator similarly to the > inherited styles today. Thoughts, comments?
I just played with inherited styles, and its a little clumsy. For instance inspecting this page I get a seperator that reads: "Inherited from body.bugs-webkit-org bz_bug bz_status_ASSIGNED bz_component_Web_Inspector bz_bug_36421". It took me a second to realize that everything beneath the separator was inherited. I guess comments about the UI should go in a different bug. I agree with you. I would like to see "Inherited" and "Psuedo" sections, that could easily be shown / hidden. I don't think a lot of information needs to be in the separator. And the separator should be more useful, its a big readonly non-clickable object in the sidebar!
Pavel Feldman
Comment 7
2010-03-28 05:11:11 PDT
Fixes landed under separate bugs.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug