| Summary: | Web Inspector: Styles: replace a multiline text editor with a "spreadsheet" model | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Chris Chiera <chris> | ||||||
| Component: | Web Inspector | Assignee: | Nikita Vasilyev <nvasilyev> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | bfulgham, graouts, hi, inspector-bugzilla-changes, jonowells, macbookrepairuae, nvasilyev, webkit-bug-importer | ||||||
| Priority: | P2 | Keywords: | InRadar | ||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | Mac | ||||||||
| OS: | OS X 10.10 | ||||||||
| Bug Depends on: | 146878, 147360, 174741, 174838, 175343 | ||||||||
| Bug Blocks: | 174334, 170779, 174329, 174338 | ||||||||
| Attachments: |
|
||||||||
|
Description
Chris Chiera
2015-06-15 12:49:27 PDT
Think of the style rule editing as a mini text editor, not a spreadsheet. To add a new property, press return and insert a newline and start typing. The new Rule button is for adding a whole new rule, not a property. You can increment/decrement numbers with the option-arrow keys. Arrow keys are taken by the standard text editing navigation. Thank you for your response. Guess I'm still finding the logic hard to understand on Safari's implementation compared to Chromes. When selecting a rule, the highlighting the whole word would seem better than adding the cursor since users (I think) far more often than not will be replacing the whole word rather than making a spelling change (in regards to words not numbers that is). Do you believe that not to be the case? Thank for your the tip on using the option keys however also believe Chrome's approach to be better. You mention arrows (with option is for scrolling up/down the page. In Chrome you can scroll up/down a page with arrows to, however when editing a number in the inspector at that time, the up/down will change the values which makes sense since at the exact moment in time you choose a to edit a number in the inspect you are well editing that number and not trying to up and down the page. But also maybe there is some use case that I'm missing that would make that not so? While I probably sound like a broken record, the tab/enter implemention in Chrome seems to make far more sense as well. In both Chrome and safari you can tab from the rule name to the rule value, but in Chrome clicking tab again allows you then to go straight to creating a new rule and so on. Where is in chrome you have to go back and forth between tabs and returns. The tab logic seems to make the most sense like if I were filling out a form in Chrome (or Safari) after I fill out the first to forms inputs on one line to get to the next line of inputs I wouldn't have to click enter/return, I'd simply be able to keep clicking tab to get to the next tabs no matter that they are on a separate line. In regards to new rule, I may have not described the issue and/or using wrong terminology. So in Chrome to I select something in the HTML and then click the top right + to add a style to that. The plus if you hold down also lets you choose which style sheet to add the rule to. In Safari, I have to scroll down past the pseudo styles to find the large new rule button to do the same. Would be great if it were always at the top, and if an option to add the rule to particular stylesheets from the document like in Chrome. Chrome allows you to also add an inline style by clicking the style part at the top which can come in handy sometimes which I don't think is possible on Safari (unless you manually edit the html in the html side of the inspector). I don't know if Chrome is doing best, just it seems better than Safari in that regard. But hopefully there is room for improvement in Safari in regards to adding styles. Hope this all comes off as helpful and not stubborn. I love love the look and feel (and better memory/tab management/battery life savings of Safari. Though currently Chrome while less pretty offers a superior experience for power users. A lot of these little items can make or break it for developers and know once the inspector is up to par with chromes that devs would start using it more as their primary browser and then share that recommendation with their non technical friends and family. Though just my opinion and understand if Apple has their own private reasons in regards to the above compared to chrome's implementation. Or maybe Apple devs have unique use cases that make them prefer safari's implementations that I'm not aware of but figured I'd give it a go, before switching back to chrome at least for development. Safari ROCKS for browsing! (In reply to comment #3) > Thank you for your response. > > Guess I'm still finding the logic hard to understand on Safari's > implementation compared to Chromes. > > When selecting a rule, the highlighting the whole word would seem better > than adding the cursor since users (I think) far more often than not will be > replacing the whole word rather than making a spelling change (in regards to > words not numbers that is). Do you believe that not to be the case? > > Thank for your the tip on using the option keys however also believe > Chrome's approach to be better. You mention arrows (with option is for > scrolling up/down the page. In Chrome you can scroll up/down a page with > arrows to, however when editing a number in the inspector at that time, the > up/down will change the values which makes sense since at the exact moment > in time you choose a to edit a number in the inspect you are well editing > that number and not trying to up and down the page. But also maybe there is > some use case that I'm missing that would make that not so? > > While I probably sound like a broken record, the tab/enter implemention in > Chrome seems to make far more sense as well. In both Chrome and safari you > can tab from the rule name to the rule value, but in Chrome clicking tab > again allows you then to go straight to creating a new rule and so on. Where > is in chrome you have to go back and forth between tabs and returns. The tab > logic seems to make the most sense like if I were filling out a form in > Chrome (or Safari) after I fill out the first to forms inputs on one line to > get to the next line of inputs I wouldn't have to click enter/return, I'd > simply be able to keep clicking tab to get to the next tabs no matter that > they are on a separate line. > > In regards to new rule, I may have not described the issue and/or using > wrong terminology. So in Chrome to I select something in the HTML and then > click the top right + to add a style to that. The plus if you hold down also > lets you choose which style sheet to add the rule to. In Safari, I have to > scroll down past the pseudo styles to find the large new rule button to do > the same. Would be great if it were always at the top, and if an option to > add the rule to particular stylesheets from the document like in Chrome. > Chrome allows you to also add an inline style by clicking the style part at > the top which can come in handy sometimes which I don't think is possible on > Safari (unless you manually edit the html in the html side of the > inspector). I don't know if Chrome is doing best, just it seems better than > Safari in that regard. But hopefully there is room for improvement in Safari > in regards to adding styles. > > Hope this all comes off as helpful and not stubborn. I love love the look > and feel (and better memory/tab management/battery life savings of Safari. > Though currently Chrome while less pretty offers a superior experience for > power users. A lot of these little items can make or break it for developers > and know once the inspector is up to par with chromes that devs would start > using it more as their primary browser and then share that recommendation > with their non technical friends and family. Though just my opinion and > understand if Apple has their own private reasons in regards to the above > compared to chrome's implementation. Or maybe Apple devs have unique use > cases that make them prefer safari's implementations that I'm not aware of > but figured I'd give it a go, before switching back to chrome at least for > development. Safari ROCKS for browsing! Please try the latest WebKit nightly. We have fixed many of these issues since you filed this bug. If you have any other requests / bugs that have not been addressed yet, please file a bug per issues so it is easier to track and fix. Thanks for the detailed feedback! Will do. Thanks for all your hard work! Looks like the nightly builds currently don't work with 10.11 beta 3. Will try installing again later or maybe they will work with beta 4. Created attachment 257522 [details]
Mockup
Created attachment 257523 [details]
Comparison
While Webkit still isn't available on 10.11 so can't test on my own computer, tested on another person's computer who still has 10.10 installed to see the improvements to Webkit mentioned here. At quick glance I see all the irrelevant :before:after and other styles have been moved to the bottom of the list like Chrome now, which is great. However, at quick glance all of the space issues still appear to exist. I'm attaching a screenshot comparison of the Chrome Web Inspector vs the Safari web inspector set to the exact same height to show how Safari shows very little actual data and a lot of UI compared to Chrome which shows very little UI and a lot of actual styles. Once again, Safari's implementation looks much sexier and looks great for screenshots or looking at, just not very helpful for actual dev work compared to Chrome especially on a Laptop where space is so limited. So ways to improve: 1. Like in Safari's main tab view at the top, the tab bar in the dev panel should disappear if only one tab is open. Perhaps have the "+" next to the search box in the main dev bar. 2. Combine Node, Styles, Layers bar with the Computed Rules Metrics bar. May for instance it would show, "Styles: Computed Rules Metrics" and an arrow next to Styles so in a dropdown you could choose Node or Layers and when you change to one of those the links to right change accordingly. 3. Shorten elements.style section. I think you can remove "No properties - click to edit" since it will be evident there are no properties if there are no properties showing. You could move click to edit to be right aligned, but I think it's also self evident since this is aimed at devs rather than consumers who would need explicit instructions. 4. Reduce Remove Rule. This is probably the biggest space hog other than the double tab bars. It takes up an enormous amount of unnecessary space. Chrome simply has a "+" that takes up no extra vertical space and think you could put the plus in the element.style place on the right like Chrome. 5. Media Queries. I actually like Safari's visual version of these. The only space saving suggestion would be to reduce the top padding to match the bottom padding of that media bar. 6. Styles Padding. In chrome the padding space above/below the styles such as .bs-docs... is a few pixels less which saves a good deal of space in the long run. While the roomier Safari looks nice, I think less padding would be more useful though is a little tougher because Safari has icons which take more vertical space. While I personally don't think the icons are necessary, if left, you could have the top of the icons lined up with the top of the adjacent text (so move the icons down a few pixels. 7. One place where Safari wins space wise is Safari doesn't show the closing } which saves space. Great! 8. For Active, Focus, Hover, Visited, there is a lot of extra top/bottom padding. That bar should be the same height as the computed, rules, metrics bar right above it. While it's great it hides as you scroll it still would be better with a consistent smaller height. 9. Finally the Filter Styles is taller in Safari than Chrome. This is one place where Chrome's version may be just a tad too small. I'd recommend less than Safari but more than Chrome and removing the inner border of the filter styles search box. Perhaps if a person is on desktop and increases the height of the dev tools to a substantial size, the dev tools could default to a roomier option like it currently is but imagine more than not will be designing on a laptop with the dev window relatively small so they can see the actual content above. I've attached a quick 1 minute mockup called modified showing all the extra space you could save. One last follow up. Forgot to reduce the padding slightly above and below the rules in the mockup. Also for the + button next to the search box, would probably be better to just be an + rather than an + in a button like the x in the opposite side that bar for consistency and balance. Devin is making some changes to tighten things up in bug 147360 and bug 146878. Thanks for the suggestions. We are doing some of these, but not everything is somethings we agree with. We want to maintain nice spacing, visual alignment of bars, and system consistency that Chrome does not care about. Most developers will not have one tab, so optimizing that case won't impact many developers. And we have a toolbar that Chrome does not have. Comparing style sidebar content, not UI above, we are closer now with Devin's pending changes. "Spreadsheet" CSS editing model is a very common request. Let's make this bug just about that. We can continue our discussion about vertical spacing in Bug 145985 - Web Inspector: Styles Top Options Use Too Much Vertical Real Estate. (In reply to Chris Chiera from comment #9) > 2. Combine Node, Styles, Layers bar with the Computed Rules Metrics bar. May > for instance it would show, "Styles: Computed Rules Metrics" and an arrow > next to Styles so in a dropdown you could choose Node or Layers and when you > change to one of those the links to right change accordingly. Let's continue in Bug 174229 - Web Inspector: Styles: make "Computed" a top-level tab. |