[whatwg] Mathematics in HTML5

[Michel Fortin]

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/