Le 21 juin 2006 à 13:29, Alexey Feldgendler a écrit :
On Wed, 21 Jun 2006 21:48:25 +0700, Michel Fortin
<[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
http://www.michelf.com/
