WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
189048
You have to click *into* the Resources panel after clicking elements, to edit
https://bugs.webkit.org/show_bug.cgi?id=189048
Summary
You have to click *into* the Resources panel after clicking elements, to edit
Jay George
Reported
2018-08-28 08:25:40 PDT
If click a rule on the elements panel Web Inspector does not allow me to dive straight into editing the stylesheet. I first have to click into the Resources panel before I can start typing. I'm unsure whether this is a designed decision or a bug. If it is a designed decision, it's frustrating because I need to first move my mouse to the place in the window where I want to edit, then click — doing this 100s of times a day is not great for RSI. It would be great if either a) I could type straight away after selecting an element, or b) I could use a keyboard shortcut to start editing the stylesheet.
Attachments
Screencast to show poor keyboard accessibility workflow
(12.24 MB, video/mp4)
2018-09-14 21:04 PDT
,
Jay George
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Joseph Pecoraro
Comment 1
2018-09-11 11:40:17 PDT
The Style Rule sections in the Element Tab's sidebar should be editable. You just need to double click to modify or add properties like a spreadsheet. This is a recent change away from a text-editor approach to a spreadsheet-like approach that users appeared to be more familiar with. When you do want a full editor experience, you can jump to the stylesheet, but it shouldn't be necessary. Does this satisfy your concern, or is there a specific scenario I'm missing? Adding a keyboard shortcut would be difficult (if there are many rules that may be coming from many different stylesheets), but we should certainly improve keyboard accessibility in these circumstances (elements tab and its detail sidebar).
Jay George
Comment 2
2018-09-11 11:59:37 PDT
The scenario you're missing is where a web designer such as myself would want to directly edit the stylesheet. I suspect people that edit CSS every day would also like this as an option. While authoring CSS it is more desirable to see a sheet of rules and directly manipulate them; just as it is more desirable for a programmer to use a text editor vs. using a WYSIWYG editor. I'm not sure what the resistance is to be honest, Webkit's behaviour is the odd one out here amongst all the DevTools, and it's not a great usability experience. I think the preferred route would be that the stylesheet is immediately in focus once a rule is selected.
Devin Rousso
Comment 3
2018-09-11 15:51:14 PDT
(In reply to Jay George from
comment #0
)
> If click a rule on the elements panel Web Inspector does not allow me to > dive straight into editing the stylesheet. I first have to click into the > Resources panel before I can start typing. > I'm unsure whether this is a designed decision or a bug.
I'm entirely not sure what your talking about here. The CSS sidebar allows in-place editing of rule selectors and properties, and if you do want to edit it in the stylesheet (via the Resources tab), there is a link right next to the selector that will take you there. Could you describe what it is that you are doing where it isn't working as you'd expect? Most (if not all) browsers function in the same way.
Jay George
Comment 4
2018-09-14 21:04:05 PDT
Created
attachment 349850
[details]
Screencast to show poor keyboard accessibility workflow
Jay George
Comment 5
2018-09-14 21:10:33 PDT
My problem, shown in the screencast, is that once you click the link next to the rule in the elements tab, you then further need to click inside the Resources tab to edit anything. This is in contrast to other DevTools where the cursor is already focussed on the rule in question and you can start typing immediately.
Devin Rousso
Comment 6
2018-10-16 23:26:04 PDT
I think this will be fixed by <
https://webkit.org/b/190643
>.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug