W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2006

[whatwg] Mathematics in HTML5

From: Alexey Feldgendler <alexey@feldgendler.ru>
Date: Thu, 22 Jun 2006 00:29:00 +0700
Message-ID: <op.tbiaumlz1h6og4@localhost>
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.

> 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).

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.

Alexey Feldgendler <alexey at feldgendler.ru>
[ICQ: 115226275] http://feldgendler.livejournal.com
Received on Wednesday, 21 June 2006 10:29:00 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:47 UTC