I'm spending some time writing HTML and CSS, and am using the developer tools in Firefox 53. Specifically, the "HTML/DOM/CSS Inspector".
When you move the mouse over a chunk of HTML in the Inspector window, the corresponding rendered HTML element on the page is highlighted. Plus, there are some helpful grid lines and color overlays and whatnot also drawn over the page, all of which was a good decision on the part of the Mozilla developers. It shows how random divs and other elements might be overlapping, is great for showing where margins are collapsing, etc.
However, when I move the mouse off the HTML tree, all that useful highlighting and overlays vanish. Is there a way to get that highlighting/overlay to "stick"? For example, until I click on another HTML element, or reload the page, or... actively take some action other than simply moving my mouse?
Note that right-clicking the Inspector and selecting the ":hover" menu entry is most emphatically not what I'm looking for. I want to change the mouseover behavior of the Inspector, not that of the page.
(Now I'm going to pour another shot of whiskey and resume fighting with the Rules/Computed-versus-"browser styles" controls. Those were... not as well designed.)
The general highlighter can't be toggled to stay on the page, it only reacts on hovering the nodes.
Only some other highlighters are sticky, like the one for elements matching a specific CSS selector or the CSS grid highlighter, both located within the Rules side panel:
The CSS selector matching highlighter is currently (as of Firefox 53) the one that comes nearest to what you're looking for, though it's missing the grid lines.
Furthermore, there is already a request for adding a sticky element highlighter in Mozilla's bug tracker.
Related
What is the name of event when we start drawing the markup(circle, arrow, rectangle etc.) on the shape when in edit mode? And can we change the markup type in this event?
Problem is: When we are in edit mode and have selected specific shape and color to draw the markup, and in between if we select any markup, the drawing tool takes up that shape and color for the next markup to be drawn ignoring the markup type and color we selected earlier. Is this the normal behavior. Why does the drawing tool take up the configuration of the last selected markup and overrides the type we define through - new Autodesk.Viewing.Extensions.Markups.Core.EditModeCloud(markupExt);
Thanks!
That's an interesting question. I believe the current behavior of markups is as-designed because one would typically only select a markup if they wanted to move it around, scale it, etc. That's why in the current implementation, selecting a markup automatically enters its edit mode.
At the same time I understand your view where if I already activate a specific edit mode, it seems strange that that edit mode would change after simply selecting another markup.
Let me bring this up with the engineering team, and in the meantime, I'd suggest using the Autodesk.Viewing.Extensions.Markups.Core.EVENT_EDITMODE_CHANGED event to detect a change to the edit mode, and if needed, reset the mode to the one you want.
I'm fairly new to using Madcap Flare but have been using it without problems for a few months. Now suddenly the Style Class menu appears zoomed way out to many times its normal size, and it won't scroll or let me select a style. The steps to reproduce the problem:
Open an .htm topic in MadCap Flare 12.
In the XML Editor view, right-click on a P tag.
From the pop up menu, select Style Class > and wait.
After a few seconds, the style class menu pops up on the left but it's covering three-quarters of the screen from left to right, and covering the entire screen from top to bottom. The style items in the menu are so huge that only four of them are visible. I can't scroll through them nor select one.
Until recently the menu acted normally, popping up in a much smaller size and letting me scroll through it and select styles.
I haven't found any mention of this in my searches online.
Edit: Adding a few more pieces of info:
Resetting MadCap Flare layouts doesn't help.
This only happens on paragraph tags, I notice. If I right click on a li or h2 or any other kind, the style class menu acts normally.
The styles in the class menu come from a CSS file that might be corrupt or contain invalid syntax that Flare is parsing incorrectly.
Locate the CSS file (Default location within Flare: Content Explorer > Resources > Stylesheets > Styles.css).
Right-click the file and select Open with > NOTEPAD.EXE.
Copy the contents of the CSS file and validate it here: http://jigsaw.w3.org/css-validator/#validate_by_input
Fix the validation errors, then copy the results back into the CSS file and save you changes.
This seems to have been just a matter of the WYSIWIG popup styles menu expanding to display the one heading that the previous writer had set up to a large font size. In displaying the one heading style at 96 pt, Flare increases the height of all of the style menu entries to that height, which unfortunately makes the menu pretty much unusable.
The solution was just to use the other ways of accessing the styles, displaying the styles window for example which doesn't seem to have this problem, and avoiding using the popup styles feature.
I went through everything else, validating the CSS file and etc, before finding the solution or at least the workaround.
To be clear, this is not highlighting in the sense of finding an element from the DOM Inspector to the page, or vice versa. It's behavior I haven't seen before, but then I usually use Chrome.
I'm debugging a textarea that won't accept clicks, or allow selection, or basically gain focus in any way. I noticed that clicking on the textarea, in the page, caused several DOM nodes in the Inspector to highlight, and then fade away after a second. None of the nodes that highlighted were the textarea; they were parents of the textarea, including the body, but not necessarily all of the parents in between the textarea and the body. There was also a sibling of one of the parents highlighted, as well.
It's one of those things where Firefox is trying to tell me something, but I don't know what. I feel like the answer to my original problem is probably contained in this highlight, if only I knew what it meant.
In the attached screenshot, you can see the textarea highlighted in blue, being the selected element, and the rather grossly-colored highlights on a few other elements; this was right after I clicked on the textarea (in the page, like I was trying to enter some text in it; not in the inspector)
What does it mean?
When the nodes in the markup view (the thing in your screenshot) highlights, it means that these nodes have gone through mutations. These can be of the following manner:
Attribute value change on the node
Addition/Removal of child nodes
Now, what you are actually looking a way to hover the textbox and get the markup view to select your textbox, right ?
You can do that in two ways:
Hit the shortcut Ctrl + Shift + C. You will see an overlay on the page which follows your mouse. Head over to text box and click it.
Click the "Pick an element from the page" button on top left corner of the developer tools and the same node-selector will appear.
For more and deep information : visit the MDN page : https://developer.mozilla.org/en-US/docs/Tools/Page_Inspector
I'm trying to figure a lot of hover/mouseover related CSS/Javascript on a webpage.
To do so, I use Firefox+firebug inspectors.
The problem, is that whenever I move the mouse out of an element I'm inspecting, all the "hover reactions" are lost.
Is there a way, to fix the mouse position firefox sees so I can freely use the mouse withouth concern about weiter it actually hovers some elements or not?
Well, it is not fixing the mouse position, but when you right-click on an element in the Inspector in the regular Developer Tools, you're offered a :hover menu item (along some other things). Selecting that will put the element into permanent :hover state. That at least should cover the CSS-part of your question. I'm sure Firebug offers something similar.
For the JS-part, I'd just set a breakpoint somewhere.
Scroll bars are really boring. I've seen a few really inventive new user interfaces for updating these. I believe there are many better ways to spend 10px then with a solid color and static buttons. Here are two examples I've found:
http://www.youtube.com/watch?v=-PnXY4wjuH8
http://chikuyonok.ru/u/demo/infoscroller/
(credit for this link goes to this question uses HTML5 Canvas )
Do you have any other ideas to add to this list? How can we give a better idea of view-status in the document, without wasting so much real estate? How can we add more functionality to the notorious dead space on the right?
Firstly, one should be very careful about “updating” the scrollbar. The scrollbar is a great success story, a simple, elegant, powerful control that is critical for successful computer use and almost universally understood by users. Trying to improve the scrollbar is like trying to improve the ballpoint pen. It’s stayed the same for so long because there’s really not much more you can do. Being "boring" is not a good reason to improve it. Users don’t use an app or site because it has new and "cool" controls. They use an app or site because it lets them accomplish their tasks. To improve the scrollbar, consider how changes can improve task completion.
Good things the humble scrollbar has:
Capacity to scroll one pane-full.
Capacity to scroll one line (fine tuning).
The capacity to do each of the above repeatedly without moving the mouse (so a user reading some content only has to click occasionally after initially placing the mouse over the right spot).
Allows random access to anywhere in the pane by simple linear drag and drop.
Intuitively shows the relative position in the content (e.g., allowing the user to judge how close s/he is to the end).
Intuitively shows the relative size of content by the size of the slider relative to the track.
Supports intuitive keyboard activation via the cursor keys -good shortcuts, and good for accessibility.
Supports clickamatic (pressing down and holding the mouse button to scroll multiple lines or pane-fulls).
Very smooth real-time feedback on user actions.
All in a remarkable compact and unobtrusive control that doesn’t distract from the content (what the user is really interested in).
You don’t want to mess with any of that. In particular, the pop-up scrollbar you link to is probably a bad idea because it interferes with the capacity to scroll by a pane-full by clicking the track. That is perhaps the most common user action so it deserves the greatest number of pixels (i.e., the track).
On the other hand, building on existing scrollbar capability, like the Infoscroller you link to, is a something worth investigating further. For the original research on this concept, see:
McCrickard DS and Catrambone R (1999)
Beyond the scrollbar: An evolution and
evaluation of alternative navigation
techniques. Georgia Institute of
Technology Technical Report
GIT-GVU-97-19.
Obviously, what you show in the scrollbar track depends on your content. A thumbnail of the content won’t work well for a text table or list. For that, Greg Raiz has suggested indicating the values for the current sort order. If there’s not enough space, maybe tooltips or callouts can appear pointing to key places in the track to drag to. MS Word does something similar with this, showing a tooltip indicating the page and section of the current drag-to point.
Here’re some other ways we could build on the scrollbar:
More Buttons. I’ve seen suggestions to include both up and down buttons at the top and bottom so the user can transition between scrolling down and up without having to slew the entire height of the pane. Or you could have buttons to scroll immediately to the beginning and end of the content, handy for users who don’t know about Ctrl-Home and Ctrl-End, saving them from making a long drag of the slider. MS Word includes buttons to execute the last Find or Goto, among other possibilities.
Split bar. On the subject of MS Word, MS Word and Excel scrollbars include a split control to allow you to divide the window into two panes. That would be handy for a lot of other applications, such as browsers and large lists and tables.
Expert activation. If you don’t want to clutter the scrollbar with more buttons and controls, consider providing expert shortcuts via meta keys. Ctrl-clicking an arrow button could scroll the user to the beginning and end of the content. Ctrl-clicking the track could instantly scroll to the corresponding position in the content, particularly useful if you’ve implemented Infoscroller. Ctrl-clicking the slider could pop open a mini dialog or text box to enter a page number, list item identifier, or Find criteria to jump to.
Left side scrollbar. There is some research suggesting we should usually be putting vertical scrollbar on the left side, rather than the right (see Kellener E, Barnes GM, & Lingard R (2001), Effects of scroll bar orientation and item justification, Proceedings of the Human Factors and Ergonomics Society 45th Annual Meeting). Having the scrollbar position consistent with the content alignment means less average slew distances for faster scrollbar use. In the same vein, putting the scrollbar on the left in a browser would shorten the distance between the scrollbar and the Back button for faster navigation. However, the advent of the scrollwheel may have made this idea obsolete.
Great question. Please see RockScroll, which is now standard in Visual Studio 2013 Preview: http://www.hanselman.com/blog/IntroducingRockScroll.aspx
RockScroll in turn inspired MetalScroll:
which in turn inspired RockMargin.
Also, Jetbrains Resharper plug-in for Visual Studio puts a vertical affordance to the right of the scrollbar. The information is displayed as little horizontal bars of different colors. These bars indicate a piece of code that can be improved. Clicking on a bar scrolls the code page to bring the code in question into view:
Also, most file comparison software uses fancy scrollbars. See Scooter Software's Beyond Compare 3.0, which puts an "infoscroller"-like affordance separate from the scrollbar. The affordance on the left is draggable like a scrollbar. In addition, to reduce the need for horizontal scrolling, there is a bottom pane which puts the current line from the left pane on top and the current line from the right pane below. Moving the info-scroller allows the user to scroll both documents simultaneously, which makes "merging" changes between two versions of the same document MUCH easier. Please see:
WinMerge has a different, equally scrollable, left-pane that functions like a scrollbar and duplicates the existing scrollbars. http://winmerge.org/about/screenshots/filecmp.png
Finally, Google Chrome integrates search functionality (the "find bar") into the scroll bar.
And Greg Raiz came up with the ABC Scrollbar:
And Overlay Scrollbars which minimize the non-client area:
And a research, gaze-enhanced scrolling techniques.
I like the Google Wave scrollbar- it seems like they've reconciled scroll bars with Fitt's Law.