[whatwg] Mathematics in HTML5

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

Received on Wednesday, 21 June 2006 12:54:30 UTC