<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - Web Inspector: Style sidebar editing issues"
href="https://bugs.webkit.org/show_bug.cgi?id=145982#c4">Comment # 4</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - Web Inspector: Style sidebar editing issues"
href="https://bugs.webkit.org/show_bug.cgi?id=145982">bug 145982</a>
from <span class="vcard"><a class="email" href="mailto:timothy@apple.com" title="Timothy Hatcher <timothy@apple.com>"> <span class="fn">Timothy Hatcher</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=145982#c3">comment #3</a>)
<span class="quote">> 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!</span >
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!</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>