Michel Fortin wrote:
I know that. But special parsing rules, just as new CSS properties,
need changes to happen in the browser. If someone is going to improve
the browser, it'd be much better to improve the presentational layer
with a few reusable CSS rules than to add a collection of
Alexey Feldgendler wrote:
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
Juan R. Gonzalez-Alvarez wrote:
I assume that authors agree. Therefore, now is matter for developers, they
have the last word.
Basically there is nothing in proposal that could be difficult to implement,
morover on first stage XHTML with fallback style sheets can work without
any kind of
Michel Fortin wrote:
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:
Csup1/supsub2/sub
To avoid changes on CSS side in current proposal
this is
Michel Fortin wrote:
My proposal was fractions, and *only* fractions.
This rises question how to mark formulae produced by combining expressions with
fractions and indices. At least one element for this purpose would be
necessary. Even DocBook and TEI that does not have their own math markup,
Michel Fortin wrote:
Bugs will need to
be fixed with many CSS engines,
Withdrawing proposal does not mean that this bugs need not to be fixed.
They has to be fixed in any case.
and even then the current markup
proposal isn't something I'd call pretty even for simpler structures
Ian Hickson wrote:
There is nothing to read between my lines. I am being as honest and candid
as possible. There is no conspiracy here. I have given you the exact
reasoning I have used, I have suggested how you can move forward. I am
being quite sincere.
Very well. In this case please
Robert O'Callahan wrote:
From my point of view, a fraction element that can be implemented using
inline-block in the UA style sheet seems like a reasonable thing to support
in HTML5, since it's basically no effort and is a small increment over
existing sup etc.
Thus fractions work in MSIE,
Alexey Feldgendler wrote:
How should formula be used? There has been some discussion about it.
In case when everything is reduced to fractions and simple indices,
it can be optional. But having such an element is still important for those
who want to mark formulae explictly.
I've never said
Oistein E. Andersen wrote:
- labelled arrows [...]
'over' and 'under' elements can be used to put label above or below the
arrow (also it will not stretch arrow).
Do you mean that ISO-12083 labelled arrows are not supposed to stretch?
They are supposed to stretch, this is part of
Anne van Kesteren wrote:
Certainly. The question is how. There have been several proposals. My
recommendation to those who think it is possible to re-use CSS to get an
acceptable level of Math support would be to go through the Microformats
process to prove the case.
What is the
James Graham wrote:
You have to choose your battles and, personally, I
agree with the idea that, if the proponents of CSS-based maths want to
work in the structure of the WHATWG, they should demonstrate the
feasibility of their approach using a microformat. Given the constraints
under
Ian Hickson wrote:
Certainly. The question is how. There have been several proposals. My
recommendation to those who think it is possible to re-use CSS to get an
acceptable level of Math support would be to go through the Microformats
process to prove the case.
What is the difference
Michel Fortin wrote:
Yes, sub/sup will behave like HTML sub/sup with offsets being based
on font size like it is currently done in HTML implementations,
while llim/ulim and marker/submark will have offsets based on size
of their base (operator, fence, matrix etc.) not font size like
James Graham wrote:
So how does it fit in the scope of fundamental principles upon which
the WHAT working group intends to operate?
http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html
I don't see anything contradictory there
Web application technologies SHOULD BE BASED ON
Oistein E. Andersen wrote:
The proposal states that op should be used to mark resizable operators,
but this presumably does not mean that the size of such operators is
actually intended to change.
It is intended to be larger.
Yes, but the size is not intended to vary as a function of
Michel Fortin wrote:
Yes, sup/sub will work like in HTML. This behavior is not perfect
in case
of resizable operators, fences, matrices and vectors however in
this cases operator limits (llim/ulim) and fence markers (marker/
submark) provide necessary functionality.
That's what I
Anne van Kesteren wrote:
Web application technologies SHOULD BE BASED ON technologies
authors are familiar with,
including HTML, CSS, DOM, AND JAVASCRIPT
As it would work with that, it's not really a problem.
How it will work with CSS? New parsing rules at least does not improve
Since MathML does not fit into the WHATWG philosophy, I would
aknowledge information about your own solution to the problem of
mathematical markup on the web.
Oh please, cut the crap. Did you miss the message from Ian saying how
it could integrate?
If by integrate you mean
Oistein E. Andersen wrote:
As a first step, I have tried to transform the TeX code used on
Wikipedia (http://en.wikipedia.org/wiki/Help:Formula) into HTML5.
This raises some issues, see http://xn--istein-9xa.com/HTML5/WikiTeX.pdf for
all the details. I have tried to follow the current
Oistein E. Andersen wrote:
This issue [font selection] belong to presentational layer and has to be
addressed
on CSS side (there are no problems on XSL and/or DSSSL side as one can make
appropriate transformations).
I am not so sure about that.
In fact I am not sure either.
The
Oistein E. Andersen wrote:
each mark-up element must be kept as short as possible.
Some people argue that short element names being misleading and not
intuitive does not actually improve readability, some people like short
element
names as they are more convenient for authoring.
The
Michel Fortin wrote:
Well, now that I think of it, there will be some problems with any
pure CSS implementation (for current browsers at least, but maybe
with CSS3 too). Aligning fraction separators correctly with the base
line when num and den do not have the same height for instance: I
Ian Hickson wrote:
I am not at all convinced that it makes any sense to rely on CSS to render
mathematics. CSS simply doesn't have the expressive power to obtain
acceptably good mathematical typography, and adding features to CSS to
obtain this level of expressiveness would require a huge
Anne van Kesteren wrote:
but just putting
this in the specification as well and requiring UAs to support it by
default seems too much to ask, imho
Maybe, but taking into account that WHATWG does not want to establish several
levels
of compliance, what can we do?
I see at least three
Anne van Kesteren wrote:
I've already sort of proposed to add Ruby to HTML. Simple Ruby is
already supported by Internet Explorer in HTML (I think the XHTML
module was based on that implementation) and it makes sense to have it
for certain foreign (to me at least) use cases.
Alexey Feldgendler wrote:
Why have f at all? When I'm writing about varx/var, why should I
write fvarx/var/f? What would be the difference? I think a
formula element is only needed for what is called display equations --
they are rendered out of line, usually centered, and sometimes
Michel Fortin wrote:
Use integral and bounds for integrals.
integral
bounds
sub0/sub
sup100sup
/bounds
3varx/var dvarx/var
/integral
There are at least 30 different operators that would require similar markup,
following this line one
Dan Brickley wrote:
It would also be both considerate and sensible
(if anyone does want to undertake such a task) to talk to the
MathML folks first.
So far we are addressing problems that were invented and deployed by MathML
folks.
--
___
Surf
Oistein E. Andersen wrote:
As Henri Sivonen put it: «[I]t is futile to insist on semantics that
you can't pull out of LaTeX as it is normally authored.» I would
like to use a slightly different wording: It is futile to insist on
encoding anything that does not change the appearance of a
Alexey Feldgendler wrote:
What exactly is a formula?
If you ask this question from the point of view of browser developer or browser
itself,
then the answer is simple formula2 + 2 = 4/formula is formula, while
2 + 2 = 4 is plain text. If you ask it from the point of view of mathematician
or
Alexey Feldgendler wrote:
What exactly is a formula?
If you ask this question from the point of view of browser developer or
browser itself, then the answer is simple formula2 + 2 = 4/formula is
formula, while 2 + 2 = 4 is plain text. If you ask it from the point of
view of
James Graham wrote:
They have to use LaTeX to prepare documents
for publication,
it is the only language they know for typesetting
mathematics and, in general, the web is not their major target medium.
However, for current markup proposal, web is major target medium,
which means that if
James Graham wrote:
However,
elsewhere on this thread you have convinced me that a lot of CSS work is
needed
before it can display maths with any degree of complexity in a pleasant
manner
without requiring extensive, per-formula, adjustments to the style properties
that would produce
Michel Fortin wrote:
What Juan propose, about adding a limited number of elements to HTML
for maths, actually makes sense to me, especially if you can get not-
too-bad results with CSS. HTML is designed to be easy to learn and
write; if we had a markup like that for mathematics which
To summarize discussion on mathematics in HTML5, I would like to ask several
questions.
1) Which markup do you think fits better in the scope of HTML5?
a)
div
(X)HTML document may contain math formulae, like
formula
Hakon Wium Lie wrote:
I think you make a compelling case for adding math to HTML the simple
way. Personally, I'm open to adding it to HTML5. How much would it add
to the specification?
In ISO 12083 Electronic Manuscript Format description of mathematical markup
occupies about 7 pages, in our
Anne van Kesteren wrote:
So WHATWG doesn't really care about DTDs. (There are two people
involved with that though for validating.)
This is important issue, because requirement to keep DTD accurate imposes
certain
constraints on markup (for example DTD fails to catch errors like
a
James Graham wrote:
I remain sceptical about this. However, if there is a serious effort to
replace
MathML I believe the resulting language must fulfil the following
requirements:
1) Easy conversion from standard LaTeX2e.
There are plenty of different packages and low level presentational
James Graham wrote:
If LaTeX - HTML converters don't work no-one
will use the language and it will be a complete waste of effort.
Sorry but taking into account nature of LaTeX (many packages, low level TeX
commands),
it would be more appropriate to use stuff like PNG, SVG, PS, PDF as a output.
40 matches
Mail list logo
