[Webkit-unassigned] [Bug 145982] Web Inspector: Style sidebar editing issues

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=145982

--- Comment #4 from Timothy Hatcher <timothy at apple.com> ---
(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!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150711/77a772a7/attachment.html>