search

firebug / firebug

Web Development Evolved - The Firebug you have known and loved
http://getfirebug.com/
1.35k stars 343 forks source link

Show pseudo-elements in HTML #5914

Open fbugissues opened 9 years ago

fbugissues commented 9 years ago

Originally reported on Google Code with ID 5785

Chrome cross reference: http://code.google.com/p/chromium/issues/detail?id=123343

Sample: http://johnjbarton.github.com/webdev-examples/InspectHoverBefore/InspectHoverBefore.html

How implemented in Opera: http://chromium.googlecode.com/issues/attachment?aid=1233430009000&name=pseudo.PNG&token=925_aRO-CyKkB404fyE4l7IZbrg%3A1344111817004&inline=1

Reported by sroussey on 2012-08-04 23:18:04

fbugissues commented 9 years ago

Reported by sroussey on 2012-08-04 23:19:23

fbugissues commented 9 years ago 
Did you intentionally set yourself as owner?

Sebastian

Reported by sebastianzartner on 2012-08-05 01:26:08

fbugissues commented 9 years ago 
Yeah, for part, at least. I have part of it going, but the CSS rules ought to get moved
around a bit, now that there is an element to select to see them. I'll push the branch
so you can play with it. It will be called html-pseudo.

Reported by sroussey on 2012-08-05 07:25:41

fbugissues commented 9 years ago 
":first-letter" and ":first-line" should probably go inside, not before with "::before",
but I haven't gotten that far yet.

Reported by sroussey on 2012-08-05 07:32:11

fbugissues commented 9 years ago 
Locking the :hover state on the <h2> tag of John's test case doesn't seem to work for
me... :-/ Do you see the same? Though I do not see any bug in the code.

Sebastian

Reported by sebastianzartner on 2012-08-09 21:52:51

fbugissues commented 9 years ago 
Sorry, forget about that. I missed that it's the <div> that needs to be hovered, not
the <h2>.

The pseudo-elements are not displayed yet when the tree is already expanded before.

> ":first-letter" and ":first-line" should probably go inside, not before with 
> "::before", but I haven't gotten that far yet.
Agree.

Sebastian

Reported by sebastianzartner on 2012-08-09 22:06:57

fbugissues commented 9 years ago 
Further reading the spec [1] I saw that all the pseudo-elements including ::before and
::after should actually be placed inside an element:

"The ':before' and ':after' pseudo-elements can be used to insert generated content
before or after an element's content."

I created a better test case for this covering all pseudo-elements and the things mentioned
here.

Sebastian

[1] http://www.w3.org/TR/2011/REC-CSS2-20110607/selector.html#before-and-after

Reported by sebastianzartner on 2012-08-09 22:55:53

fbugissues commented 9 years ago 
And even one more thing:

Clicking the pseudo-elements should show the matching styles inside the Styles side
panel like Dragonfly does.
This could be put into a separate issue, though.

Sebastian

Reported by sebastianzartner on 2012-08-09 22:58:34

fbugissues commented 9 years ago 
Yeah, I think you are right... all should go inside as they inherit. It will be weird
though. What about <br> which has no closing tag, and doesn't normally have anything
inside it? I guess we will get used to it.

I'm not sure of a way to make things effecient for handling things like a parent :hover.
May need platform support to get this right. Not sure yet.

And yes, making the style panels work should be a different issue.

This might be a better reference: http://www.w3.org/TR/css3-content/#pseudo-elements

Reported by sroussey on 2012-08-10 00:05:15

fbugissues commented 9 years ago

Reported by sebastianzartner on 2012-08-10 05:17:41

fbugissues commented 9 years ago 
> What about <br> which has no closing tag, and doesn't normally have anything inside

> it? I guess we will get used to it.
I assume <br> is very seldomly styled, even less with pseudo-elements. But anyway,
if somebody does it, it must be displayed appropriately.
I am wondering, though, if we shouldn't add an option to toggle the display of pseudo-elements.

> I'm not sure of a way to make things effecient for handling things like a parent

> :hover. May need platform support to get this right. Not sure yet.
If so, please create a Bugzilla issue for that, post the backlink here and add the
label "platform", so it's clear that it depends on the user agent to support this.

> And yes, making the style panels work should be a different issue.
Here it is: issue 5927.

> And yes, making the style panels work should be a different issue.
Ah, right. I just had a look at the CSS3 and CSS4 selectors spec, which reference to
the CSS 2.1 spec.

Sebastian

Reported by sebastianzartner on 2012-08-10 05:21:02

fbugissues commented 9 years ago 
> I am wondering, though, if we shouldn't add an option to toggle the display of pseudo-elements.

I was thinking the same thing. It will definitely be a slower code path. Internally,
we can just switch dom walkers and refresh. I do this already with the chromebug dom
walker to have a look around xul stuff from time to time.

Reported by sroussey on 2012-08-10 16:01:45

fbugissues commented 9 years ago 
+1 - please implement this proposal! It's awesome!

(just make sure that <::before> and <::after> get place *inside* their parent element
- like seen in the first screenshot above)

Reported by mar.orlygsson on 2013-05-18 00:19:59

fbugissues commented 9 years ago 
Regarding Sebastian's suggestion to hide them behind a toggle-option:

Pseudo-elements may seem like a rare curiosity still, but going forward I see them
being used more and more - both for icons and for advanced styling that has traditionally
been handled by layers of superfluous <div>-wrappers.

My bet is that most, if not all, web developers would prefer to have them visible by
default.

Reported by mar.orlygsson on 2013-05-18 00:26:33

fbugissues commented 9 years ago

Reported by sebastianzartner on 2013-05-18 06:47:53

fbugissues commented 9 years ago 
To only show pseudo-elements, which actually relate to specific elements, we need help
by Mozilla.[1]

@Steven: If you still have the patch from comment 3, please create a branch for it
called "issue5914", so it's not lost.

Sebastian

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=874227

Reported by sebastianzartner on 2013-07-17 22:43:04

fbugissues commented 9 years ago 
Yeah, I still have it. I'll take a look at it again and then transfer it over.

Reported by sroussey on 2013-07-18 13:57:25

fbugissues commented 9 years ago 
> Yeah, I still have it. I'll take a look at it again and then transfer it over.
Steven, I'm still waiting for you to attach your patch. :-)

Sebastian

Reported by sebastianzartner on 2013-09-08 19:48:40

fbugissues commented 9 years ago 
Is this feature on the roadmap? Chrome has implemented this recently

Reported by dpashk on 2014-01-21 21:52:31

fbugissues commented 9 years ago 
It's not on our roadmap[1] at the moment, though it's marked with high priority. So
we'll probably put it on the roadmap for the release after the upcoming major version.
Because Steven didn't answer anymore, I assume he's not gonna work on this. So dpashk,
feel free to provide a patch for this, if you want to help us.

Sebastian

[1] https://getfirebug.com/wiki/index.php/Firebug_Roadmap

Reported by sebastianzartner on 2014-01-22 06:51:46