13808 2011-08-17 15:31:49 +0000 Let users make whitespace visible 2015-07-30 23:47:07 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - HTML Editing APIs unspecified PC Linux NEW P2 enhancement --- 1 ayg ayg bjartur79 ehsan mike public-webapps 2015-07-30 sideshowbarker+html-editing-api oldest_to_newest 55308 0 ayg 2011-08-17 15:31:49 +0000 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. """ http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-August/032941.html 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. 55315 1 bjartur79 2011-08-17 16:14:30 +0000 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. 55317 2 ayg 2011-08-17 16:27:17 +0000 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·every·space·a·black·dot·would·be·very·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. 55318 3 ehsan 2011-08-17 16:30:31 +0000 (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.