- From: Tantek Çelik <tantek@cs.stanford.edu>
- Date: Fri, 06 Sep 2002 01:47:50 -0700
- To: Ian Hickson <ian@hixie.ch>
- CC: "L. David Baron" <dbaron@fas.harvard.edu>, Bert Bos <bert@w3.org>, "www-style@w3.org" <www-style@w3.org>
On 9/6/02 12:49 AM, "Ian Hickson" <ian@hixie.ch> wrote: > > On Fri, 6 Sep 2002, Tantek Çelik wrote: >> >> If you want to style generated content, I strongly recommend you come up >> with a proper solution that does not depend on formatting instruction >> character code hackery. > > You can call it "hackery" if you like, but that doesn't stop the fact that > it is useful, used, simple, and implemented. kind of like document.all? 1/2 ;-) and for that matter, is it actually implemented interoperably by two or more implementations? including interactions with the 'white-space' property? >> "line feed character" is exactly the problem. It is a character based >> formatting instruction, which is antiquated, and its presence in a CSS >> specification (for that matter, a W3C specification) is very bad >> anachronism. Like I said, even the Unicode folks have been getting >> rid of all the characters which are simply formatting instructions. > > Calling a line feed character "antiquated" or "anachronistic" is > ridiculous. Look around you. Every file on the net has line feeds. This > e-mail has line feeds. There is nothing wrong with line feeds. line feeds are used for formatting in plain text / ASCII files. line feeds are effectively IGNORED in HTML (with the exception of <pre> elements) and XML files. line feeds being reintroduced in CSS, outside the treatment of <pre>-like content with white-space:pre, is thus a step backwards. You're right there is nothing wrong with using line feeds in plain text files or email etc. In fact, it is totally appropriate and necessary. However, in HTML files it is not necessary, and neither should it be in CSS. > The Unicode > folk may have been trying to get rid of formatting characters (I am not > privy to their meetings or minutes), but they have been _adding_ line > break characters (U+2028 anyone?). Feel free to do some googling on the subject, or reading up on i18n archives. > Yes, we could go one step further and allow for arbitrary styling of > arbitrary new elements in CSS (indeed, David recently suggested we might > want to do just that). But that doesn't make \A any less valuable. > > The simple tasks should be easy to do. I agree with this design principle. > This is an example of that. Using an escaped character inside a specific property on a little implemented pseudo-element in order to achieve an effect is NOT simple. Again, comparing: br { line-break-after:always } and br:after {content: "\A"; white-space: pre} I think it is pretty obvious which is simpler, both for the author, and the implementer. Nevermind which one is more readable, more self-describing, etc. etc. And I don't consider creating block formatting contexts (which is essentially what you are trying to do in your examples) inside generated content to be a simple task. Tantek
Received on Friday, 6 September 2002 04:37:56 UTC