Attributes starting with -moz
Steven Roussey
http://math.chapman.edu/~jipsen/mathml/asciimathandmathmlsvg.xhtml
Now inspect the mathml elements. They show attributes that start with -
moz. This example -moz-math-font-style is in several elements.
In my version of firebug I have it work with svg and mathml quite a
bit better, and this attribute thing is the only problem I have left.
Writing <mi -moz-math-font-style="italic">a</mi> in source code is not
well formed. My current solution is to hide it, though if a user edits
the whole element, then it does indeed lose its italics. Not quite
sure what to do here.
Are there other attributes that that start with -moz?
-s
gNeandr
Steven Roussey
Yes, I've seen that. But why would this css come up as ATTRIBUTES of
the element?
-s
Boris Zbarsky
> Have a look here:
> https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions
Totally unrelated to Steven's question.
-Boris
Boris Zbarsky
> In my version of firebug I have it work with svg and mathml quite a
> bit better, and this attribute thing is the only problem I have left.
> Writing<mi -moz-math-font-style="italic">a</mi> in source code is not
> well formed.
How about we just rename the attribute to mozMathFontStyle (probably
more expedient than changing the MathML code to not mess with the DOM).
> My current solution is to hide it, though if a user edits
> the whole element, then it does indeed lose its italics.
That's odd. I'd expect this to not break even with the attribute as-is.
What and how is the user editing, exactly? What API calls does
Firebug make in the process?
> Not quite sure what to do here.
File a bug to rename the attributes in question? ;) cc me.
> Are there other attributes that that start with -moz?
http://mxr.mozilla.org/mozilla-central/source/layout/mathml/mathml.css
has some attribute selectors for such, yes.
-Boris
Steven Roussey
> On 11/8/09 11:32 PM, Steven Roussey wrote:
>
> > In my version of firebug I have it work with svg and mathml quite a
> > bit better, and this attribute thing is the only problem I have left.
> > Writing<mi -moz-math-font-style="italic">a</mi> in source code is not
> > well formed.
>
> How about we just rename the attribute to mozMathFontStyle (probably
> more expedient than changing the MathML code to not mess with the DOM).
Anything would be better. :)
Using style="-moz-math-font-style:italic" would be ideal.
> > My current solution is to hide it, though if a user edits
> > the whole element, then it does indeed lose its italics.
>
> That's odd. I'd expect this to not break even with the attribute as-is.
> What and how is the user editing, exactly? What API calls does
> Firebug make in the process?
createConextualFragment. I don't think DOMParser would be any better,
as <mi -moz-math-font-style="italic">a</mi> is clearly non-conforming.
<mi mozMathFontStyle ="italic">a</mi> is though.
> > Not quite sure what to do here.
>
> File a bug to rename the attributes in question? ;) cc me.
Should I file two? One to change the names, and one to move the CSS
stuff to style? I think MathML may find more use in the HTML5 era, but
as that is some time away, a stopgap measure would be nice. Thus two
bugs?
> > Are there other attributes that that start with -moz?
>
> http://mxr.mozilla.org/mozilla-central/source/layout/mathml/mathml.css
> has some attribute selectors for such, yes.
But this in only MathML that does this, and nothing else?
-s
Boris Zbarsky
> Using style="-moz-math-font-style:italic" would be ideal.
If you have the time to make that work, good luck. I suspect that it
woudn't do at all what needs to be done here, and would be a huge pain
to make work.
>> What and how is the user editing, exactly? What API calls does
>> Firebug make in the process?
>
> createConextualFragment. I don't think DOMParser would be any better,
> as<mi -moz-math-font-style="italic">a</mi> is clearly non-conforming.
> <mi mozMathFontStyle ="italic">a</mi> is though.
You mean what you do is you serialize the element to a string, the user
edits the string, then you reparse the string and replace the old
element with the new one in the DOM?
Would it work to setAttribute the -moz-* stuff after you reparse?
> Should I file two? One to change the names, and one to move the CSS
> stuff to style?
The latter isn't viable. This isn't CSS stuff, so much...
There may well be an existing but to not munge the DOM here; if not, it
might be worth filing one.
> But this in only MathML that does this, and nothing else?
Can't guarantee that, sorry. Any extension could decide to set such
attributes for its own purposes, for example, if it directly calls into
nsIContent APIs. Or you can end up with them by importing nodes from an
HTML document into an XML one (which would allow web script to create
such nodes too), etc.
-Boris
Boris Zbarsky
> Would it work to setAttribute the -moz-* stuff after you reparse?
To answer myself: no.
> There may well be an existing but to not munge the DOM here; if not, it
> might be worth filing one.
s/but/bug/
-Boris
Steven Roussey
> > as<mi -moz-math-font-style="italic">a</mi> is clearly non-conforming.
> > <mi mozMathFontStyle ="italic">a</mi> is though.
>
> You mean what you do is you serialize the element to a string, the user
> edits the string, then you reparse the string and replace the old
> element with the new one in the DOM?
Correct.
> Would it work to setAttribute the -moz-* stuff after you reparse?
No, neither before nor after.
> Can't guarantee that, sorry. Any extension could decide to set such
> attributes for its own purposes, for example, if it directly calls into
> nsIContent APIs. Or you can end up with them by importing nodes from an
> HTML document into an XML one (which would allow web script to create
> such nodes too), etc.
OK, so perhaps I should let the user see it, but make it uneditable
(I'm just not sure how it was set in the first case). And if they edit
the source, strip it out since we can't reparse it. I suppose I can
use a regexp to detect non-conforming attribute names for a more
general case. Thanks for the heads-up.
-s
Boris Zbarsky
>> You mean what you do is you serialize the element to a string, the user
>> edits the string, then you reparse the string and replace the old
>> element with the new one in the DOM?
>
> Correct.
That's generally a lossy operation, in the face of DOM mutations. In
particular, DOM API calls can produce DOM data structures that a parser
cannot produce (and in the case of HTML vice versa, actually). If you
edit such a data structure with your setup, you will lose data from it.
Not sure there's a good solution for that, though reparsing the node
> OK, so perhaps I should let the user see it, but make it uneditable
> (I'm just not sure how it was set in the first case).
Ah, interesting. You can't setAttribute such an attribute in HTML
either. That means you have fewer worries about it; in particular
outside of MathML you probably won't run into it (and we should just fix
MathML).
It was set in the MathML case by using the internal SetAttr API that
doesn't do certain validity checks on its arguments.
-Boris
Steven Roussey
> particular, DOM API calls can produce DOM data structures that a parser
> cannot produce (and in the case of HTML vice versa, actually). If you
> edit such a data structure with your setup, you will lose data from it.
Yes, very lossy actually. JS variables attached to nodes, event
listeners, etc. all get lost. It would be better if there was a
function to conform a current node structure to a new one based on a
HTML string, altering and moving nodes, and only adding/deleting if
really necessary.
Certainly if the node structure doesn't change, and only attributes
and text nodes do, then we could create a new fragment and copy the
differences, instead of wholesale replacement of one node tree with
another. That could be augmented with adding nodes and deleting nodes,
and eventually with detecting moving of nodes. Sounds like a lot of
work to make it more correct for the user. Cost/benefit and all.
> Not sure there's a good solution for that, though reparsing the node
...? Sounds like you got cut off there.
> > OK, so perhaps I should let the user see it, but make it uneditable
> > (I'm just not sure how it was set in the first case).
>
> Ah, interesting. You can't setAttribute such an attribute in HTML
> either. That means you have fewer worries about it; in particular
> outside of MathML you probably won't run into it (and we should just fix
> MathML).
OK, I'll stick with just checking for attributes that start with -moz-
math. More self documenting that way.
Steven Roussey
> File a bug to rename the attributes in question? ;) cc me.
Related bugs I found in buzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=69409
https://bugzilla.mozilla.org/show_bug.cgi?id=527201
https://bugzilla.mozilla.org/show_bug.cgi?id=475518
I added you to the cc list for the last one.
Boris Zbarsky
>> Not sure there's a good solution for that, though reparsing the node
>
Actually, no idea where "reparsing the node" came from. Should have
just been a period after "though".
-Boris
Henri Sivonen
Boris Zbarsky <bzba...@mit.edu> wrote:
> How about we just rename the attribute to mozMathFontStyle (probably
> more expedient than changing the MathML code to not mess with the DOM).
It seems to me the right fix is to make the nodes hold the relevant data
in a form other than attributes.
However, if the attributes are renamed for expediency and in a way that
makes the serializer(s?) output the attributes, it would be good to
avoid upper-case letters in the attributes in case they ever find their
way into the HTML5 parser.
Using the pre-existing _moz naming convention seems safer to me than
putting upper-case letters in the names.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Steven Roussey
> in a form other than attributes.
>
> However, if the attributes are renamed for expediency and in a way that
> makes the serializer(s?) output the attributes, it would be good to
> avoid upper-case letters in the attributes in case they ever find their
> way into the HTML5 parser.
>
> Using the pre-existing _moz naming convention seems safer to me than
> putting upper-case letters in the names.
Indeed, that is what this patch does:
https://bug475518.bugzilla.mozilla.org/attachment.cgi?id=411215