Fuzzy highlighting? about code.pyret.org

[jpolitz]

(This is on horizon, not on CPO proper)

[blerner]

It's this: d220a2d#diff-5828ef0df6fd1cbf728e4103df9b1affR69. Turning off that one rule fixes the fuzziness, but also makes the lines appear separately highlighted. Problem is every single token is its own <span> with its own box shadow, and they overlap. This might be a partial solution: http://blog.dudak.me/2014/css-shadows-under-adjacent-elements/, but because CM sets a z-index on every row, this will only fix side-to-side overlap, not top-to-bottom overlap.

[jpolitz]

Also, changing the box-shadow to border: 1px solid hsl(220, 100%, 95%) seems to fill in the extra space between lines, if that's the goal.

[jpolitz]

The other issue I see is that it looks like there's supposed to be a box around fun and end, but no amount of z-index muckery makes it show up. Is this a feature-in-progress?

[blerner]

Using a full border works, but it mucks with the horizontal spacing. Using only border-top and border-bottom, though, works better. I think the partial boxes around fun and end are actually deliberate -- they're a top-left marker and a bottom-right marker, so they shouldn't be full boxes. Those look good to me.

[jswrenn]

Definitely a feature in progress. I needed to distinguish the block matching highlight from the error highlights. The fuzziness, as you guys figured out, was an attempt at dealing with the spaces between lines (although the fuzziness doesn't interact with text nearly as much on my machine; your screenshot looks awful).

I like the box-shadow edge-fuzziness as a distinguishing feature, but not if it wreaks havoc on the visibility of the code. border-bottom: 2px hsl(220, 100%, 95%); seems to work for me; can you guys confirm it doesn't much with spacing for you?

The pseudo-element solution to box-shadow overlapping adjacent siblings is a bit tricky to get right. I'll revisit it soon, but for now I suggest we just use border to fill the gaps.

[jpolitz]

1px of border bottom works in Chromium (OSX) for me. Do you need the 2px?

Thanks for pointing out border-bottom; just using border like I suggested clearly adds wacky spacing.

[blerner]

You should use both top and bottom, so that the first and last lines are symmetric. You should probably use 0.1em instead of ###px, so it scales when we resize fonts.

[blerner]

And you should use whatever border width is equal to the line spacing that CM uses. (Joe's probably getting it to work with 1px because two of them just touch, and having larger borders is ok because of CSS border collapsing.)

[jpolitz]

The partial boxes confused me because they appear to curve around the keyword, making it look like an incomplete rounded box (to my eye).

Doing it without a border-radius (so square edges) fixes this visual glitch for me.

[blerner]

You can add a border radius only to one corner, so that should help too...

[jpolitz]

Ah, good point. So border-top-left-radius and border-bottom-right-radius for the start and end, respectively.

[jswrenn]

@blerner changes fix the issue of code being obscured by the fuzziness but still succeeds in being visually distinct from highlights.

[jpolitz]

This looks awesome.