The Infobar and pseudo-class support in the page inspector

22 views
Skip to first unread message

Kevin Dangoor

unread,
Oct 13, 2011, 2:42:15 PM10/13/11
to dev-apps-firefox
If you're using Nightly, you've possibly noticed that some of the developer
tools we've been working on have been landing. I'm really excited...
everyone involved has been doing great work and it's coming together well.

I wanted to open things up for feedback on a new feature page. For context,
using Nightly, if you right-click on a page element and select "Inspect
Element" from the context menu(*) you'll see everything on the page go dim
except for the element you're inspecting. Somewhere near the element you're
inspecting is the "infobar" which tells you the tag name, ID and classes
associated with the selected page element.

We want to add a bit of interactivity to the infobar for some very common
things that people want to do when they're working on page styling. The most
important part of this is being able to "lock in" pseudo-classes like
"hover" on the element, since for some pseudo-classes there's no other way
to inspect the styles.

With that preamble, the feature page is here:

https://wiki.mozilla.org/DevTools/Features/RichInfobar

and I'd be happy to hear any suggestions you have.

Kevin

--
Kevin Dangoor

work: http://mozilla.com/
email: kdan...@mozilla.com <k...@blazingthings.com>
blog: http://www.BlueSkyOnMars.com

B.J. Herbison

unread,
Oct 14, 2011, 6:12:27 AM10/14/11
to dev-apps-firefox
I've tried the tools several times, and they keep getting more useful. The style pop-up window that shows where each attribute comes from will be very helpful, but there are some annoyances.

First, whenever I click on a style sheet a new window is opened with the style sheet. I very quickly had three open windows showing the same style sheet. My desktop would be easier to manage if the you didn't open more than one copy of each sheet.

Also, it's hard to find the information in the style sheet. Saying "screen.css:37" is helpful, but give line numbers in the displayed file or highlight the line (or preferably both).

Kevin Dangoor

unread,
Oct 14, 2011, 9:38:30 AM10/14/11
to mozilla.dev....@googlegroups.com, dev-apps...@lists.mozilla.org
On Fri, Oct 14, 2011 at 6:12 AM, B.J. Herbison <bjher...@gmail.com> wrote:

> I've tried the tools several times, and they keep getting more useful. The
> style pop-up window that shows where each attribute comes from will be very
> helpful, but there are some annoyances.
>

The tools are definitely getting there, but there are a good number of
patches still to land.


> First, whenever I click on a style sheet a new window is opened with the
> style sheet. I very quickly had three open windows showing the same style
> sheet. My desktop would be easier to manage if the you didn't open more than
> one copy of each sheet.
>
> Also, it's hard to find the information in the style sheet. Saying
> "screen.css:37" is helpful, but give line numbers in the displayed file or
> highlight the line (or preferably both).
>


Where we're ultimately going with that is to open the Style Editor when you
click that link. It's all a question of timing, because the Style Editor
hasn't landed yet, so we certainly couldn't link over to it yet!

Eric Sh.

unread,
Oct 14, 2011, 11:04:13 AM10/14/11
to Kevin Dangoor, dev-apps...@lists.mozilla.org, mozilla.dev....@googlegroups.com
Some suggestions:
- If the window is maximized then put the style window on the firefox window
not next to it, because if i have a panel open(on Windows XP) that is
causing maximized windows to be smaller. What you are doing now is not
respecting my screen setup.

- In the HTML window it is very hard using the keyboard to move trough
elements. It feels more natural to me(on Windows XP) to left click to close
the sub-tree, right to open it, and up and down move to the next visible
element(just like in firebug).

- The idea of having a caption next to the inspected element is very cool,
but if I scroll down the page it should point to the direction that element
is(just like in a map).

- There should be a button of disabling the "lights out feature" and the
dashed border(or an ption to only show it upon hovering the item in the HTML
window), because let's face it in real development you care about how the
element looks with it's sorroundings and it's impossible to design or work
on a web design currently.

- In the console it would be nice to have a trace for errors or at least the
file and the line an error has occured at

Keep working on this, I really like the direction this is going and having
this directly in the browser gives it a lot more power than a normal addon.

Regards,

Paul Rouget

unread,
Oct 17, 2011, 7:39:54 AM10/17/11
to
On Oct 13, 8:42 pm, Kevin Dangoor <kdang...@mozilla.com> wrote:
> We want to add a bit of interactivity to the infobar for some very common
> things that people want to do when they're working on page styling. The most
> important part of this is being able to "lock in" pseudo-classes like
> "hover" on the element, since for some pseudo-classes there's no other way
> to inspect the styles.

From https://wiki.mozilla.org/DevTools/Features/RichInfobar

> * double-clicking the tag name or ID switches the label to a text box for editing.
> * classes and pseudo-classes can be toggled by clicking on them in the Infobar. If the user switches to another page element and then back after turning off a class, that class will be gone from the Infobar.

These 2 behaviors (click to edit and click to toggle) are not
consistent. I think people will try to double-click to edit the
classes.
The edition mechanism should be the same for ids, tag names and
classes.

> * Clicking the + displays a text field with placeholder text along the lines of :pseudo, #id, or .class.

Below or at the end of the infobar? Or should we replace the infobar?
What will contain this textbox? An exact copy of the infobar or an
empty textbox with placeholders?
What if we allow the user to edit this selector-like text?

> * If the user types :, it would the field would contain ":active, focus, hover, visited, ..." with all of the text but the ":" selected.
> * ":a", ":h", etc. should autocomplete to the supported pseudo-classes
> * if the user starts the field with anything but "#", "." or ":" the field should turn red (or otherwise show the error state)

Not consistent. With the click, you can edit tag name, id and classes,
but with the text, you can only edit classes and ids.
We could allow the user to edit a text like that:

div#foo.class1.class2:hover

Then, he would be able to delete classes, add pseudo classes, change
the tagname, the id, etc.
We just need to make sure the user doesn't delete the tag name, and
doesn't include any combinator
(spaces, >, +, …).

Once the user hit enter, we update the node and the infobar.

The only problem with this method is that you lose the original
content (if you remove a class, you wont be able to see is anymore,
because there will be nothing to greyed out).
But we could add a "reset" button, and I guess that with a good
autocompletion mechanism, it would be easy to come back to the
original classes.

> * if the user types "#" and the node has an ID, the existing ID should be placed in the field, preselected with the cursor after the #

-- Paul

Paul Rouget

unread,
Oct 17, 2011, 8:38:11 AM10/17/11
to Eric Sh., Kevin Dangoor, dev-apps...@lists.mozilla.org, mozilla.dev....@googlegroups.com
Thank you for the feedback. I open a couple of bugs:

Eric Sh. wrote:
> Some suggestions:
> - If the window is maximized then put the style window on the firefox window
> not next to it, because if i have a panel open(on Windows XP) that is
> causing maximized windows to be smaller. What you are doing now is not
> respecting my screen setup.

This tool will soon lie in a sidebar on the right of the content.

> - In the HTML window it is very hard using the keyboard to move trough
> elements. It feels more natural to me(on Windows XP) to left click to close
> the sub-tree, right to open it, and up and down move to the next visible
> element(just like in firebug).
>
> - The idea of having a caption next to the inspected element is very cool,
> but if I scroll down the page it should point to the direction that element
> is(just like in a map).

https://bugzilla.mozilla.org/show_bug.cgi?id=694954

> - There should be a button of disabling the "lights out feature" and the
> dashed border(or an ption to only show it upon hovering the item in the HTML
> window), because let's face it in real development you care about how the
> element looks with it's sorroundings and it's impossible to design or work
> on a web design currently.

https://bugzilla.mozilla.org/show_bug.cgi?id=694956

> - In the console it would be nice to have a trace for errors or at least the
> file and the line an error has occured at
>
> Keep working on this, I really like the direction this is going and having
> this directly in the browser gives it a lot more power than a normal addon.
>
> Regards,
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
-- Paul

Kevin Dangoor

unread,
Oct 18, 2011, 9:45:22 AM10/18/11
to Eric Sh., dev-apps...@lists.mozilla.org
On Fri, Oct 14, 2011 at 11:04 AM, Eric Sh. <shed...@gmail.com> wrote:

> - In the console it would be nice to have a trace for errors or at least
> the file and the line an error has occured at
>
>
Do you have a specific example of this? The web console should be listing
the file/line for errors (as long as it knows it).

We should definitely file a bug if it's not doing that in a reproducible
way.


> Keep working on this, I really like the direction this is going and having
> this directly in the browser gives it a lot more power than a normal addon.
>
>
Thanks!

Rob Campbell

unread,
Oct 18, 2011, 9:48:52 AM10/18/11
to Paul Rouget, dev-apps...@lists.mozilla.org

On 2011-10-17, at 07:39, Paul Rouget wrote:

> On Oct 13, 8:42 pm, Kevin Dangoor <kdang...@mozilla.com> wrote:
>> * double-clicking the tag name or ID switches the label to a text box for editing.
>> * classes and pseudo-classes can be toggled by clicking on them in the Infobar. If the user switches to another page element and then back after turning off a class, that class will be gone from the Infobar.
>
> These 2 behaviors (click to edit and click to toggle) are not
> consistent. I think people will try to double-click to edit the
> classes.
> The edition mechanism should be the same for ids, tag names and
> classes.

Not sure editing in the infobar makes sense, tbh. I think it may be adding too much capability to something provided for informational purposes.

~ rob

Paul Rouget

unread,
Oct 18, 2011, 10:09:26 AM10/18/11
to Rob Campbell, dev-apps...@lists.mozilla.org
Rob Campbell wrote:
>
> On 2011-10-17, at 07:39, Paul Rouget wrote:
>
> > On Oct 13, 8:42 pm, Kevin Dangoor <kdang...@mozilla.com> wrote:
> >> * double-clicking the tag name or ID switches the label to a text box for editing.
> >> * classes and pseudo-classes can be toggled by clicking on them in the Infobar. If the user switches to another page element and then back after turning off a class, that class will be gone from the Infobar.
> >
> > These 2 behaviors (click to edit and click to toggle) are not
> > consistent. I think people will try to double-click to edit the
> > classes.
> > The edition mechanism should be the same for ids, tag names and
> > classes.
>
> Not sure editing in the infobar makes sense, tbh. I think it may be adding too much capability to something provided for informational purposes.

I understand that. Where do think these features should be? In the Style Inspector?

-- Paul

Kevin Dangoor

unread,
Oct 18, 2011, 10:11:22 AM10/18/11
to Rob Campbell, dev-apps...@lists.mozilla.org, Paul Rouget
On Tue, Oct 18, 2011 at 9:48 AM, Rob Campbell <rcam...@mozilla.com> wrote:

>
> On 2011-10-17, at 07:39, Paul Rouget wrote:
>
> > On Oct 13, 8:42 pm, Kevin Dangoor <kdang...@mozilla.com> wrote:
> >> * double-clicking the tag name or ID switches the label to a text box
> for editing.
> >> * classes and pseudo-classes can be toggled by clicking on them in the
> Infobar. If the user switches to another page element and then back after
> turning off a class, that class will be gone from the Infobar.
> >
> > These 2 behaviors (click to edit and click to toggle) are not
> > consistent. I think people will try to double-click to edit the
> > classes.
> > The edition mechanism should be the same for ids, tag names and
> > classes.
>
> Not sure editing in the infobar makes sense, tbh. I think it may be adding
> too much capability to something provided for informational purposes.
>
>
The most important part to get into the tool is a convenient mechanism for
the user to lock in pseudo-classes like hover. I put all of this into one
feature page based on Stephen Horlander's suggestion of the UI here. We
could take a different approach to pseudo-classes and break that out into a
separate feature.

Being able to manipulate classes and the ID from the infobar would be a nice
convenience, as long as the UI is not cumbersome, obtrusive or unexpected.
We could instead (or in addition) get attribute editing into the HTML panel
or to provide a UI that allows quick attribute editing for the element from
the highlighter. We had at one point talked about having more than just the
infobar around the highlighted element.

Paul made some good points about consistency. And, actually, in tools like
the Style Inspector we'd like to go with a single click for editing rather
than a double click, which might make single click toggling seem
inconsistent across the tool set. It's worth considering further.

Rob Campbell

unread,
Oct 18, 2011, 10:25:47 AM10/18/11
to Kevin Dangoor, dev-apps...@lists.mozilla.org, Paul Rouget

On 2011-10-18, at 10:11, Kevin Dangoor wrote:
>
>> On Tue, Oct 18, 2011 at 9:48 AM, Rob Campbell <rcam...@mozilla.com> wrote:
>>
>> On 2011-10-17, at 07:39, Paul Rouget wrote:
>>
>> > On Oct 13, 8:42 pm, Kevin Dangoor <kdang...@mozilla.com> wrote:
>> >> * double-clicking the tag name or ID switches the label to a text box for editing.
>> >> * classes and pseudo-classes can be toggled by clicking on them in the Infobar. If the user switches to another page element and then back after turning off a class, that class will be gone from the Infobar.
>> >
>> > These 2 behaviors (click to edit and click to toggle) are not
>> > consistent. I think people will try to double-click to edit the
>> > classes.
>> > The edition mechanism should be the same for ids, tag names and
>> > classes.
>>
>> Not sure editing in the infobar makes sense, tbh. I think it may be adding too much capability to something provided for informational purposes.
>
> The most important part to get into the tool is a convenient mechanism for the user to lock in pseudo-classes like hover. I put all of this into one feature page based on Stephen Horlander's suggestion of the UI here. We could take a different approach to pseudo-classes and break that out into a separate feature.

yeah, I have no problem with toggle buttons on the infobar. A click to add :hover seems reasonable (and probably the only one we'll need on the infobar).

> Being able to manipulate classes and the ID from the infobar would be a nice convenience, as long as the UI is not cumbersome, obtrusive or unexpected. We could instead (or in addition) get attribute editing into the HTML panel or to provide a UI that allows quick attribute editing for the element from the highlighter. We had at one point talked about having more than just the infobar around the highlighted element.

Kind of a separate issue, and probably deserving a separate thread.

We've got *basic* attribute editing in the HTML panel now.

Dave and I were just talking about possibly creating a full-on attribute editor for the selected node that lives outside of the HTML panel. It could be accessed via a button on the toolbar and slide up a little box with the full list of attributes in a Source Editor. It'd be free-form and allow easy addition and removal of attributes for the selected node without adding cumbersome UI to the HTML panel.

> Paul made some good points about consistency. And, actually, in tools like the Style Inspector we'd like to go with a single click for editing rather than a double click, which might make single click toggling seem inconsistent across the tool set. It's worth considering further.

Yeah, agreed. Overloading too much behavior can get a little hinky, to use a technical term.

~ rob

Eric Sh.

unread,
Oct 18, 2011, 12:38:57 PM10/18/11
to Kevin Dangoor, dev-apps...@lists.mozilla.org
For example:
<html>
<body>
<script>
function error1(){
throw 'An exception';
}
</script>
<input type='button' value='Error 1' onclick="error1()" />
<input type='button' value='Error 2' onclick="aa();" />
</body>
</html>

If you click the button "Error 1" you will not see the line of the
exception, instead you will see "uncaught exception: An exception" - no
error line or script.

And if you click the "Error 2" button you will see a file and line for the
error but it will be the first line, meaning that it is completely not
helpful - this also happens in firebug so it could be a firefox problem.
But in a browser like Chrome I do get the line of the error.


And what about stack trace, are there any plans for that?

Regards,
Eric

On Tue, Oct 18, 2011 at 3:45 PM, Kevin Dangoor <kdan...@mozilla.com> wrote:

> On Fri, Oct 14, 2011 at 11:04 AM, Eric Sh. <shed...@gmail.com> wrote:
>
>> - In the console it would be nice to have a trace for errors or at least
>> the file and the line an error has occured at
>>
>>
> Do you have a specific example of this? The web console should be listing
> the file/line for errors (as long as it knows it).
>
> We should definitely file a bug if it's not doing that in a reproducible
> way.
>
>
>> Keep working on this, I really like the direction this is going and having
>> this directly in the browser gives it a lot more power than a normal addon.
>>
>>
> Thanks!

Kevin Dangoor

unread,
Oct 19, 2011, 12:24:13 PM10/19/11
to Rob Campbell, dev-apps...@lists.mozilla.org, Paul Rouget
(lots of snippage)

On Tue, Oct 18, 2011 at 10:25 AM, Rob Campbell <rcam...@mozilla.com>wrote:

> Kind of a separate issue, and probably deserving a separate thread.
>
>
[snip]

> Yeah, agreed. Overloading too much behavior can get a little hinky, to use
> a technical term.
>
>
Very good points. Dave suggested that we punt on pinning down the UX for
things like this until we're a bit closer to the implementation, which
sounds like a fine idea.

To that end, I've broken our discussion here up into two separate feature
pages:
https://wiki.mozilla.org/DevTools/Features/PseudoClassLock
https://wiki.mozilla.org/DevTools/Features/EasyAttributeEditing

with separate priorities and just the bare set of requirements. I added
references to the UI discussions for when we actually do get to
implementation time.

Let's come back to discussions about the UI for this a bit later. I'd be
happy to hear any feedback you have on the new pages.
Reply all
Reply to author
Forward
0 new messages