[Webkit-unassigned] [Bug 90789] Web Inspector: Add "CSS Named Flows" sidebar pane (experimental)

[bugzilla-daemon at webkit.org]

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





--- Comment #25 from Pavel Feldman <pfeldman at chromium.org>  2012-07-18 06:38:37 PST ---
(In reply to comment #24)
> (In reply to comment #23)
> > > Sorry, I meant to say "I think we should try NOT to add any more special-purpose panes." I'd suggest only using the sidebar for now.
> > 
> > I think the opposite. We are talking about the functionality that is very targeted (used by the small percentage of the users). Hence it should not be visible / on the screen at all times.
> 
> Right. My proposal was also not visible by default -- you'd have to drill down into a "-webkit-flow-from" or "-webkit-flow-into" style to see the info.
> 
> > - Sidebar is something that is always visible, it exposes functionality one needs on a daily basis. Styles, Metrics, fall here.
> 
> Since CSS regions are just styles, it seems logical to expose the information inside the Style pane, as in my mockup. Do you agree, or do you think that it should only be accessible from the context menu?

Ok, now that I see the mock, what you are saying makes more sense. I would not want to add anything heavy into the narrow sidebar. You screenshot is speculatively wide!

> 
> > - Temporary drawer views are sessional, invisible by default and can scale. They are opened using contextual actions. Advanced search results, revision history fall here. We can also expose custom drawers using extensions API. Eventually, we'll have a tabbed pane there and allow several views in drawer at a time (a-la Eclipse's views).
> 
> The problem with the drawers is that they take up a lot of screen real estate, which is especially bad in compact mode. Ideally, I think they should be mostly transient. If we try to restrict their use to cases where they are absolutely necessary, then hopefully most of the time the drawer won't need to be open.

I perceive this functionality as profiling. I.e. you are going to spend time exploring these flows and you need real estate there.

Another important point is that putting it into a drawer significantly reduces the integration surface and raises our chances to form this functionality as an extension.

> 
> Also, I think that the ability to view the _default_ document flow would be tremendously useful in debugging layouts. That's not an expert feature, so it should be easily discoverable. I think we should use the same UI for exploring both named flows and the default flow, hence my suggestion that we implement minimal support for named flows for now.

Unfortunately, I am not sure what default flow is and how one debugs it. Also not sure what the difference between the named flows and default one is.

I'd suggest that the patch contributor explains in greater detail the life of the flow debugging. Like what information user gets and what he/she can change live and how. But from the common sense standpoint, I'd suspect that implementing it in a rectangular view would be more flexible.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.