Open Bug 439430 Opened 15 years ago Updated 2 months ago
Text-shadow text remnants visible in this case, when selection should make those invisible
See testcase, you wouldn't expect the text-shadow text inside the selection to be visible, but it is, in this case. Compare it to the reference rendering, which is the correct rendering, afaik.
This is a problem with how text needs to be drawn, since each of those is a different text frame. I'm not sure how to fix this other than moving the shadow above the selection background.
fwiw, the shadow in the testcase is also visible in Opera and Safari
Ignore that last comment, I mistakenly viewed the testcase in firefox 3 with the text-shadow extension, which doesn't show the bug which I now see in 3.1a1pre
I think the behaviour is correct since in this case every letter is in a single textframe and each letter (including shadow) is painted above the letter on the left, even without the selection. Look for example at the red "e" that is overlapping the black "t". I suggest wontfixing this. The only way to fix this is either to stop inserted script elements from creating additional textframes or painting the shadow on top of the selection background.
I think that "selection area" should cover the text-shadow. This bug is very annoying, especially in PMA (phpMyAdmin): http://i43.tinypic.com/2rrqqmb.png
(In reply to Michał from comment #6) > I think that "selection area" should cover the text-shadow. > This bug is very annoying, especially in PMA (phpMyAdmin): > http://i43.tinypic.com/2rrqqmb.png We recently changed selection to paint behind shadows in bug 692752. This may be a case to change it back.
This may need to be standardized.
(In reply to Michael Ventnor from comment #7) > We recently changed selection to paint behind shadows in bug 692752. This > may be a case to change it back. I don't think so. That change made us more consistent with other browsers, as well as improving the user experience for typical uses. The main issue with the testcase in this bug, AIUI, is that each letter is painted (and shadowed) individually, so that the shadow of one character may overpaint a preceding character. That problem remains, regardless of which way we paint the shadows and selection. The PMA example from comment 6 is unrelated to the original issue here, and just illustrates a poor design choice, I think - it's not a good idea to use a light text-shadow behind text that the user may want to select, as some platforms automatically switch the foreground text color to white when selected; the result is that the shadow just makes the text look blurry. I see the same thing in the PMA site using Chrome. (Interestingly, with IE9 there's no text-shadow present; maybe the site is serving browser-specific CSS, and assumed shadows wouldn't look good there?) (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #8) > This may need to be standardized. Perhaps; though a prior question may be whether the visual representation of text selection is/should be standardized?
(In reply to Jonathan Kew (:jfkthame) from comment #9) > (Interestingly, with IE9 > there's no text-shadow present; maybe the site is serving browser-specific > CSS, and assumed shadows wouldn't look good there?) IE9 doesn't support text-shadow. > (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #8) > > This may need to be standardized. > > Perhaps; though a prior question may be whether the visual representation of > text selection is/should be standardized? If it affects interop, it should probably be standardized. Or at least some constraints should be standardized.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
You need to log in before you can comment on or make changes to this bug.