This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13808 - Let users make whitespace visible
Summary: Let users make whitespace visible
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - HTML Editing APIs (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 enhancement
Target Milestone: ---
Deadline: 2015-07-30
Assignee: Aryeh Gregor
QA Contact: HTML Editing APIs spec bugbot
Depends on:
Reported: 2011-08-17 15:31 UTC by Aryeh Gregor
Modified: 2015-07-30 23:47 UTC (History)
4 users (show)

See Also:


Description Aryeh Gregor 2011-08-17 15:31:49 UTC
Suggested by Alfonso Martínez de Lizarrondo:
Related to CSS, one feature that people request and that from my POV should
be done with CSS is the ability to see the "formating blocks", that's easy
to do with most of the elements by using a little background image in the
stylesheet and some border, but Opera used to be the only one able to format
<br>, and that's what people are requesting, to see a glyph where a line
ends like they can do in MS-Word. But I'm not sure that this relates to the
Editing APIs doc.

This is not something that should actually be in the HTML Editing APIs spec -- it belongs in CSS.  Perhaps something like whitespace-visibility: { visible | invisible }, then maybe a pseudo-element like ::visible-whitespace that lets authors control the color of the glyphs.  This would be fairly nontrivial to define and implement, but it's worth thinking about as a feature for future versions.

Actually, this is at least as useful for plaintext editing as for rich-text editing.  It can be very useful for source code to be able to tell the difference between tabs and spaces, say.  On Windows I used to use Notepad++ for code editing, and it had a nice option where all whitespace would have a faint glyph on top of it: a centered dot for spaces, a little triangle or something for tab, and a paragraph symbol for line breaks.  So this would definitely be good to support for <textarea> too.  Of course, if white-space is not pre or pre-wrap, it doesn't make sense to mark spaces/tabs/source newlines specially, and you'd probably want to just mark <br>'s and the ends of blocks.
Comment 1 bjartur79 2011-08-17 16:14:30 UTC
Is rendering spaces using black (visible) glyphs instead of white (invisible) ones not a font matter, and thus belonging to the font-* namespace? It's more or less a question of using glyphs for whitespace, instead of leaving it blank. That's possible without any magic by simply using a font with such glyphs for whitespace characters.
Comment 2 Aryeh Gregor 2011-08-17 16:27:17 UTC
That's a good point, and it was my first thought too, but it's not that simple:

1) I assume at least tabs and newlines are handled exclusively by whatever is doing the text layout, not by the font.  Thus there'd be no way to do this for tabs or newlines by modifying the font, only regular spaces.

2) Authors often just have pages use the user's default font.  This is recommended practice for running text (as opposed to headings and such), so that the user can read in whatever fonts they're most used to.  The author can't modify the user's default fonts (or any system fonts) to replace particular glyphs.

3) A typical web author is not going to know how to modify fonts appropriately.

4) We'd want the option for the placeholder glyphs for whitespace to be a different color, specifically a lighter color.  Making·&#8203;every·&#8203;space·&#8203;a·&#8203;black·&#8203;dot·&#8203;would·&#8203;be·&#8203;very·&#8203;distracting, but a gray dot could be useful without being annoying.  (Notepad++ used a well-calculated shade of gray when I used it, so it was there when I wanted it but I didn't notice it otherwise.)

It's possible that (2) and/or (3) could be worked around with some kind of @font-face hackery, but I think the other problems still make this approach prohibitive in practice.
Comment 3 Ehsan Akhgari [:ehsan] 2011-08-17 16:30:31 UTC
(In reply to comment #2)
> 1) I assume at least tabs and newlines are handled exclusively by whatever is
> doing the text layout, not by the font.  Thus there'd be no way to do this for
> tabs or newlines by modifying the font, only regular spaces.

At least in Gecko, whitespace is collapsed in non-preformatted mode, but I'm not aware of any other special processing on whitespaces in layout.