On Sat, 17 Jun 2006, James Graham wrote:
>
> That's a really particular use case which is hardly representative of
> the web as a whole. As sad as it is, 99.9% of authors have no use for
> maths (otherwise all these problems would have been solved long ago).
> Maths is certainly less of a core f
On Sat, 17 Jun 2006, White Lynx wrote:
>
> "Basic Web application features SHOULD BE IMPLEMENTABLE using behaviors,
> scripting, and style sheets IN IE6 TODAY"
Given that has been implemented in IE6, I have no worries that an
HTML-based Math markup language based on MathML (and creating a Math
On Mon, 12 Jun 2006 [EMAIL PROTECTED] wrote:
> >
> > WHATWG doesn't have a position on this -- different contributors have
> > different opinions, and no clear consensus is being reached as far as
> > I can tell.
>
> It has been taken one! The draft of the specification recommends the
> usage o
Stefan Gössner wrote:
Anne van Kesteren wrote:
"The core features of an XML vocabulary should require the use of
elements
from ONLY ONE NAMESPACE."
Is math really a core feature?
Yes, absolutely .. the upcoming microlearning / nanolearning units
inevitably need math.
That's a really p
Anne van Kesteren wrote:
"The core features of an XML vocabulary should require the use of
elements
from ONLY ONE NAMESPACE."
Is math really a core feature?
Yes, absolutely .. the upcoming microlearning / nanolearning units
inevitably need math.
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 imp
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
Oistein E. Andersen wrote:
> >>The proposal states that 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 f
Le 17 juin 2006 à 7:01, White Lynx a écrit :
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.
On 16 Jun 2006, at 2:27PM, White Lynx wrote:
>Oistein E. Andersen wrote:
>>The proposal states that 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 si
Quoting White Lynx <[EMAIL PROTECTED]>:
"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.
"Basic Web application features SHOULD BE IMPLEMENTABLE using b
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 B
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
13 matches
Mail list logo
