Since bug 1291638, we have new colors for the box-model regions in the highlighter. I'd like us to investigate ways to make sure these colors are always visible, independent of which background colors they are shown against. Here are a few demos. For each of them, use the element picker in the inspector, and move your mouse over the element in the page: - https://dl.dropboxusercontent.com/u/714210/box-model-tests/content.html A page with a background color that is similar to the box-model "content" region, containing a single element with no padding, border or margin. => When the element is highlighted, the guides are drawn around it so you see it, but it looks like the content region is transparent. - https://dl.dropboxusercontent.com/u/714210/box-model-tests/padding.html A page with a background color that is similar to the box-model "padding" region, containing a single element with some padding only. => When the element is highlighted, you see the content region clearly, but the padding is invisible. It's like there was no padding. - https://dl.dropboxusercontent.com/u/714210/box-model-tests/border.html A page with a background color that is similar to the box-model "border" region, containing a single element with border, no padding, no margin. => When the element is highlighted, again you see the content region, but it looks like there is no border. - https://dl.dropboxusercontent.com/u/714210/box-model-tests/margin.html A page with a background color that is similar to the box-model "margin" region, containing a single element with some margin only. => When the element is highlighted, again you see the content region, but the margin is not visible. To be clear, this happened also before bug 1291638, so is not new. But, the new color we have for the "content" region is very light, and a lot of websites have their background white or very light too. Therefore, I think there are more chances now than before that the content region isn't visible. We have the guides however, so that helps.
In fact, before bug 1291638, our box-model colors were so ... ugly, er, contrasted, that you had very little chance that they would not show up against the majority of websites out there. Now our colors are much nicer, but also a lot more subtle and light, and have therefore higher chances of blending in sites background colors.
One idea is to use blend modes to make sure the region colors always stand out.
Matteo has another proposal that he will describe here.
Inspector bug triage (filter on CLIMBING SHOES).
Assignee: nobody → pbrosset
Priority: -- → P1
Taking the bug as discussed in triage.
Assignee: pbrosset → zer0
With blend modes, we have a major issue: the inspector's colors will totally change depends by the color we're going to blend with, so we won't have a consistent palette. To me, that is not something we want to deal with. My suggestion is using a simple opacity for such color, in this way we're sure that they will be always recognizable. Google Chrome does that, using an opacity of 55%, that would probably works for us too. Also, opacity is one of the css properties that can perform really fast compare to others, where I'm not totally sure about blend modes. Helen, what do you think? I'm going to attach a screenshot of what Google Chrome has.
Flags: needinfo?(zer0) → needinfo?(hholmes)
I think it would help if you explained what you meant in more details. The highlighter is already semi-transparent today iirc.
I agree this is a P1, and I also can't give this the attention it deserves before what's currently in Nightly merges this week. Patrick and/or Mateo and/or Gabe, can we make sure the current color implementation doesn't ride the train? It needs more time to bake/another design cycle, I think. I know this has implications for the box model. Patrick, here are my thoughts: If we ship a box model that doesn't match the highlighter, there is the possibility that the relationship we build between the highlighter and the box model will get lost. This is a reason not to ship the new colors until we can land a version that matches. However, as you mentioned earlier this week, we could potentially uplift the new colors (relatively small uplift, unlikely it would cause breaking changes) within the next weeks once we've ironed this issue out. That way work that has been done this release on the box model can still land without causing any potential color-related regressions. Does this sound like a good plan?
Matteo and I talked about this on IRC and agreed that Matteo would look into this now. He thinks that we might be able to find more contrasting colors that work in the majority of cases. So the plan is: Matteo works on this and as soon as we have something we uplift to Aurora (since the merge is this coming Monday). We'll talk about it again at the inspector triage meeting today.
Matteo, I have backed out Bug 1291638 which changed the color theme of box-model view as promised. I am not quite sure if that bug should be reopened or left closed. I will leave that up to you. I assume this will take over Bug 1291638 and actually make it invalid, but we should mark it as appropriate.
Any progress on this Matteo?
Sorry for the delay. I was trying to use some approaches I did in the past with multiple elements, but it's working more in a grayscale environment. So, I still thinking that what I said in comment 6 is the most viable way.
Forgot to mention: I've a darker palette I'm going to work with Helen and see if it can fit our needs.
As discussed during the inspector meeting, I'm unassign myself since we won't work on this until the new designer(s) will be on board.
Assignee: zer0 → nobody
ni Victoria to make sure this is on the radar
Thanks - adding this to the DevTools UX queue. A few weeks ago I worked on softened colors for the box model that still keep the general color palette (attached). Could be a good solution for now until there's more time to look into more advanced highlighting approaches like blending.
You need to log in before you can comment on or make changes to this bug.