- From: Michel Fortin <michel.fortin@michelf.com>
- Date: Wed, 21 Jun 2006 15:54:30 -0400
Le 21 juin 2006 ? 13:29, Alexey Feldgendler a ?crit : > On Wed, 21 Jun 2006 21:48:25 +0700, Michel Fortin > <michel.fortin at michelf.com> wrote: > >> 1. Some "border-character" property, which would work mostly like >> CSS 3's border-image, but would put a stretchable character in the >> border. The browser would be in charge of stretching. "border- >> image" with SVG could be an adequate substitute for some >> characters, but I'm not sure it would be so great with braces or >> arrows. > > border-character isn't going to work. When scaled non- > proportionally, characters get ugly, with horizontal elements > getting thick. The { and } characters will suffer the most from > this. TeX applies custom logic to stretchy braces, and I think we > shouldn't try to make ANY character stretch automatically. Well, my idea was that the stretching logic would be character- and implementation- specific. A nice browser would stretch braces using its own elegant way, while an ugly browser could use linear stretching or no stretching at all. >> 4. In the same reasoning, it would be great if there was a way >> adjacent >> elements could share the same horizontal space, like <sup> >> and <sub> >> when they are next to each other: >> >> C<sup>1</sup><sub>2</sub> >> >> I'm thinking of something which I would call "inline-float" (for >> the lack of a better name), which would make two or more >> elements >> with that property collapse into the same horizontal space when >> they are following directly each other and are not overlapping >> vertically. > > 1. They would also need to be aligned either to left or right (to > accomodate prefixes to chemical symbols). The way I was thinking about it, you would have: "inline-float: left", "inline-float: right" and "inline-float: center" to align horizontally the element's box inside the collapsed area. > 2. This isn't going to work correctly when the subscripts and > superscripts are complex (e.g. fractions). In your proposal, > they'll fail to stack and will go one after another. What should > happen is that they should still be one above another, just > occupying more vertical space. You're right, that's a pretty valid criticism that I haven't thought about. But if I bring back my third point suggesting new values for "vertical-align" based on the preceding character's or element's height, we could arrange the meaning of such values as to make vertical overlap impossible. Michel Fortin michel.fortin at michelf.com http://www.michelf.com/
Received on Wednesday, 21 June 2006 12:54:30 UTC