The future of XML related technologies in Mozilla

[SmauG-2]

After implementing xml:id/setIdAttr* and getting somewhat expected
critical comments about adding new bloat I started to wonder what are
the "new" XML technologies that should be or could be supported in Mozilla.




Currently implemented, not in wide use:

XPointer is in xmlextras, but is it used by anyone?

XML Events is used only by XForms, though some external project(s) use
it too. XML Events could be implemented as an extension, if XTF
supported extensions for attributes. (There is bug and patch for XTF
attributes). Installing yet another extension would be an annoyance for
users, but perhaps this situation could be worked out with better
extension dependencies handling.

xml:base is implemented, but does anyone really use it?

XLink is partially implemented and iirc used in SVG, and
there is a patch to fix some of its problems and reduce the
extra size overhead it currently adds to all xml element objects.

MathML shouldn't perhaps be mentioned here, but it is something which is
implemented but not used too often.




Possible new features:

xml:id. Bug and patch available. Opera supports this. Useful in DIY
languages (no need to use DTDs).

XInclude. Could this be more useful in application development than in
web pages. Something to complement XUL overlays?

SMIL (animation module). This is a big one, but for SVG animations and
perhaps for XUL UI animations too. There is or was a partial patch
somewhere.

XBL2 ;)

DOM Level 3: Core, Load&Save (these are already partially implemented)

What else... validation?...




So the questions I have is that although I'd like to reduce the binary
size, these all add some overhead or bloat - so in which cases that is
acceptable. What are the features we really need and why? Who/what is
the target audience/user for these technologies; web developers, xul
app developers, researchers, firefox UI, extension developers,
implementators of new XML based languages?

Can we somehow measure the need for a feature and say that it is ok to
implement it if the binary size increases only XXkB. Or that if code is
removed elsewhere, new features can be implemented.
(Performance regressions aren't ever acceptable, IMHO)




I think Mozilla's support for XML technologies should evolve and maybe
we shouldn't always think only web developers. HTML5 doesn't solve all
the problems ;)



br,


-Olli
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Boris Zbarsky]

smaug wrote:
> I started to wonder what are
> the "new" XML technologies that should be or could be supported in Mozilla.

What follows are my thoughts based on about 10 minutes of thinking; they're not
really policy or anything like that.

With that caveat, I think the goal of supporting whatever we support should be
to advance the Web (in the broad sense of equal/free/easy access to information
and ability to accomplish things via sharing of information).  Vague, but it
feels to me like that's what the point of the Mozilla Foundation is.

Now deciding what's going to help "advance the Web" is the hard part.  ;)  As I
see it, there are several classes of things we should consider supporting even
if they're not used much yet:

1)  Things that are useful for information interchange and have no reasonable
(e.g. usable by anyone) alternatives.  The idea here is that once there's a
critical mass of support for whatever it is, usage will increase.   MathML could
fall in here, though it's severely hampered by the fact that hand-writing it is
basically impossible and the professional mathematical community already has
TeX/LaTeX as an interchange medium.  Generating MathML from TeX is chancy at
best because the layout models are so different -- simple things map over OK,
but anything complicated doesn't really.

2)  Things that are as in #1 but have reasonable proprietary solutions.  In some
ways, SVG falls here (Flash being the proprietary solution).  The goal here
would again be to allow wider use of the technology.  Compared to items in class
1, there's more of a market pressure against whatever we'd do here, as well as
much more difficulty in standardizing something that's appropriate for the Web.

3)  Things that improve our application platform and allow both us to improve
our products and others to create innovative products based on XULRunner.

Some specific bits of XML technology that we want may have other bits of XML
technology as dependencies, of course.

Now of the things you list, as far as I can tell the situation is the following:

XPointer doesn't really fall in any of these cases, though the closest fit would
be class #3, maybe.  In fact, having seen the recent mail about XPointer in
response to queries about its compatibility with SVG, it seems that doing just
about anything with XPointer is "compliant", which raises the question of what
the point of it is.  As far as I can tell the point is to give XML language
authors a common syntax that they can use to mean different things, which is
pretty silly.

I don't know much about XML Events, so can't say anything about it.

xml:base I'm really not sure about.  Actually handling it properly (which we
don't, btw) is hard to do, especially if you want to do it fast.  It seems like
a nice idea, but over-engineered based on a use case that I'm not seeing people
use much right now (that of putting together various pieces of automatically
generated content from different sources into a single document).  This use case
_does_ seem like something that might be beneficial in the future.  This sort of
falls in classes #1 and #3.  Of course we'd need to actually make it work
correctly first.

XLink is pretty much like XPointer, but worse.  Careful reading of the XLink
spec indicates that pretty much anything you do with it is conformant; email
from the working group the few times they've deigned to respond to anyone
indicates that like XPointer the idea is to give XML language authors a syntax
for defining what a "link" is in their language and a way of expressing how it
behaves.  Absolutely not provisions are made for real-life authoring situations
(e.g. various combinations of the XLink attributes, or lack of them as the case
may be).  Combined with the fact that our XLink implementation is not really
compatible with what SVG wants out of XLink and the fact that the working group
routinely takes months to respond to simple clarification queries, I feel that
we should remove XLink support altogether.  Namespaces that wish to use it will
need namespace-specific knowledge anyway.

MathML I mostly addressed above.

xml:id might fall in class #3 above.  It really feels like a solution in search
of a problem to me, though...

I don't know enough about XInclude and SMIL to comment.

XBL2 is an absolute necessity for us in terms of security and class #3 above.
Whether what we implement is "XBL2" or "Mozilla XBL That's Designed Better" or
whatever, we need a replacement for the current XBL code...

DOM3 Core has some useful functionality that we have implemented.  It has a
number of things that are targeted at server-side XML processors that we don't
really need, except _possibly_ for class #3.  In my opinion, DOM3 Core should
have been split into at least 2, possibly 3 specifications (Core, XML Workflow,
and maybe some sort of browser spec).

DOM3 Load/Save is even more slanted towards server-side things than Core.  It's
not a very usable API -- it makes the edge cases hard and the common cases hard.
  We ideally need something that makes the common cases easy and the edge cases
possible.  Something more akin to our DOMParser and DOMSerializer, perhaps.

Validation is not something I can speak about usefully.

 > What are the features we really need and why?

Good question!  Worst thing is that the answer is likely not time-invariant.  ;)

> Who/what is the target audience/user for these technologies; web developers, xul
> app developers, researchers, firefox UI, extension developers,
> implementators of new XML based languages?

"Yes."  ;)

> Can we somehow measure the need for a feature and say that it is ok to
> implement it if the binary size increases only XXkB. Or that if code is
> removed elsewhere, new features can be implemented.
> (Performance regressions aren't ever acceptable, IMHO)

This would be interesting to try...  Right now we operate more on a "we've
decided we need this; let's just do it!" model.

I do suspect that as we add more features binary size growth is unavoidable.  I
also think that even performance regressions might be OK, depending on the
benefits and on how the regression compares with user hardware improvements.
But the benefits would have to be _huge_ here, imo....

> I think Mozilla's support for XML technologies should evolve and maybe
> we shouldn't always think only web developers. HTML5 doesn't solve all
> the problems ;)

Indeed.  I think the way to start is by identifying the problems we are looking
to solve, or the infrastructure we need to allow others to identify such
problems and solve them.

-Boris
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Ian Hickson]

On Fri, 27 Oct 2006, Boris Zbarsky wrote:
>
> DOM3 Load/Save is even more slanted towards server-side things than
> Core. It's not a very usable API -- it makes the edge cases hard and the
> common cases hard.  We ideally need something that makes the common
> cases easy and the edge cases possible.  Something more akin to our
> DOMParser and DOMSerializer, perhaps.

HTML5 has document.innerHTML, which allows you to serialise any document
and parse any string:

   var d = document.implementation.createDocument(null, null, null);
   d.innerHTML = "...XML...";

...or:

   var d = document.implementation.createDocument(null, null, null);
   d.open(); // switch document to HTML mode
   d.innerHTML = "...HTML...";

...or, for that matter:

   var d = document.implementation.createDocument(null, null, null);
   d.open();
   d.write("...HTML...");
   d.write("...HTML...");
   d.write("...HTML...");
   d.close();

...if you're getting the data one bit at a time. (There's no bit-by-bit
equivalent for XML in the current proposal.)

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Boris Zbarsky]

Ian Hickson wrote:
> HTML5 has document.innerHTML

Only for HTMLDocument.

>    var d = document.implementation.createDocument(null, null, null);

createDocument doesn't create an HTMLDocument, last I checked.

In addition to which, for serialization purposes this is all patently
insufficient without jumping through a _lot_ of hoops (one of the hoops
being that innerHTML doesn't serialize the node in question, so the only
way to do the equivalent of outerHTML is to import the subtree into a
brand-new HTMLDocument, etc).  Especially if, God forbid, you were to
want to serialize SVG or MathML or some such.

I also fully expect people to demand configurable serialization at some
point.  I think the default serializer should "do something sane" and
there should be a way to configure it...

One other note.  For purposes of parsing HTML, it's not even clear what
the right behavior for random fragments is (which is why the innerHTML
does some whack things and one reason why DOMParser doesn't handle
HTML).  It'd be good to figure this out.

-Boris
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Ian Hickson]

On Tue, 31 Oct 2006, Boris Zbarsky wrote:
>
> Ian Hickson wrote:
> > HTML5 has document.innerHTML
>
> Only for HTMLDocument.

In DOM5 HTML, every Document supports HTMLDocument.


> >    var d = document.implementation.createDocument(null, null, null);
>
> createDocument doesn't create an HTMLDocument, last I checked.

DOM5 HTML changes this.


> In addition to which, for serialization purposes this is all patently
> insufficient without jumping through a _lot_ of hoops (one of the hoops
> being that innerHTML doesn't serialize the node in question, so the only
> way to do the equivalent of outerHTML is to import the subtree into a
> brand-new HTMLDocument, etc).  Especially if, God forbid, you were to
> want to serialize SVG or MathML or some such.

Could you elaborate on this? I don't follow.


> I also fully expect people to demand configurable serialization at some
> point.

The answer "no" is probably good enough for now, though. Eventually, we
can add configuration attributes for the really desired options, but
frankly I don't see the point -- once an author has an XML string, he can
fix it to whatever he wants himself, e.g. on the server side.


> One other note.  For purposes of parsing HTML, it's not even clear what
> the right behavior for random fragments is (which is why the innerHTML
> does some whack things and one reason why DOMParser doesn't handle
> HTML).  It'd be good to figure this out.

HTML5 has this all documented now. Let me know if you spot any errors. I
know of a few that have been reported to the WHATWG list, and that I'll be
fixing in due course, but please report any you see.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Boris Zbarsky]

Ian Hickson wrote:
> In DOM5 HTML, every Document supports HTMLDocument.

"Good luck".  ;)

As in, I don't see that shipping in Gecko in the next 2 years... (not
going to happen in 1.9, almost certainly, and the next version is
probably 2 years away at least).

>> In addition to which, for serialization purposes this is all patently
>> insufficient without jumping through a _lot_ of hoops (one of the hoops
>> being that innerHTML doesn't serialize the node in question, so the only
>> way to do the equivalent of outerHTML is to import the subtree into a
>> brand-new HTMLDocument, etc).  Especially if, God forbid, you were to
>> want to serialize SVG or MathML or some such.
>
> Could you elaborate on this? I don't follow.

You can't use innerHTML on non-HTML nodes.  Assuming that you wanted the
part about SVG/MathML elaborated.  Or did you want something else?

>> I also fully expect people to demand configurable serialization at some
>> point.
>
> The answer "no" is probably good enough for now, though. Eventually, we
> can add configuration attributes for the really desired options

My point is that there's no good way to add such with the innerHTML
solution.  So it makes sense to have an easy-to-instantiate serializer
that such things could be added to later.

> but frankly I don't see the point -- once an author has an XML string, he can
> fix it to whatever he wants himself, e.g. on the server side.

You mean reparse it and reserialize it?  That's what it would come down
to...  Plus, why force a round trip to the server?  That's generally a
bad idea, imo.

> HTML5 has this all documented now. Let me know if you spot any errors. I
> know of a few that have been reported to the WHATWG list, and that I'll be
> fixing in due course, but please report any you see.

Given the size of the HTML5 spec and my time constraints, I personally
am not likely to get a chance to read the whole thing before I finish my
PhD work (so spring 2008).  If you want me to read particular small
self-contained parts, please link to them and I'll see what I can do.

Unless that was supposed to be the collective "you"?

-Boris
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Ian Hickson]

On Tue, 31 Oct 2006, Boris Zbarsky wrote:
> Ian Hickson wrote:
> > In DOM5 HTML, every Document supports HTMLDocument.
>
> "Good luck".  ;)
>
> As in, I don't see that shipping in Gecko in the next 2 years... (not
> going to happen in 1.9, almost certainly, and the next version is
> probably 2 years away at least).

I don't imagine the spec will be finished in 2 years either. But in any
case my impression was that the whole discussion was very much a long term
thing.

(In any case, that's not a prerequisite for doing this -- while we wait
for the Documents to be changed to the HTML5 way, if we ever do that, we
can still go ahead and put innerHTML on XMLDocument.)

> > > In addition to which, for serialization purposes this is all
> > > patently insufficient without jumping through a _lot_ of hoops (one
> > > of the hoops being that innerHTML doesn't serialize the node in
> > > question, so the only way to do the equivalent of outerHTML is to
> > > import the subtree into a brand-new HTMLDocument, etc).  Especially
> > > if, God forbid, you were to want to serialize SVG or MathML or some
> > > such.
> >
> > Could you elaborate on this? I don't follow.
>
> You can't use innerHTML on non-HTML nodes.  Assuming that you wanted the
> part about SVG/MathML elaborated.  Or did you want something else?

I don't understand why innerHTML wouldn't work on non-HTML nodes.

 
> > > I also fully expect people to demand configurable serialization at
> > > some point.
> >
> > The answer "no" is probably good enough for now, though. Eventually,
> > we can add configuration attributes for the really desired options
>
> My point is that there's no good way to add such with the innerHTML
> solution.

Sure, just throw some things into document.domConfig.


> > but frankly I don't see the point -- once an author has an XML string,
> > he can fix it to whatever he wants himself, e.g. on the server side.
>
> You mean reparse it and reserialize it?  That's what it would come down
> to... Plus, why force a round trip to the server?  That's generally a
> bad idea, imo.

I can't really comment, since I don't understand the use case in the first
place. I was assuming that the data would be sent to the server anyway.


> > HTML5 has this all documented now. Let me know if you spot any errors.
> > I know of a few that have been reported to the WHATWG list, and that
> > I'll be fixing in due course, but please report any you see.
>
> Given the size of the HTML5 spec and my time constraints, I personally
> am not likely to get a chance to read the whole thing before I finish my
> PhD work (so spring 2008).

That makes sense. In any case, HTML5 documents how innerHTML works on
documents and elements in HTML and XML (regardless of whether they are
HTML elements or not, in theory, though currently on elements it's on
HTMLElement, not Element, so I guess you can't get to it for other
namespaces yet), both for setting and getting. The parsing in particular
is defined in detail.

There are issues remaining for sure, but I don't see why the approach
wouldn't work on the long term.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Boris Zbarsky]

Ian Hickson wrote:
> I don't imagine the spec will be finished in 2 years either. But in any
> case my impression was that the whole discussion was very much a long term
> thing.

Hmm... I guess so, sure.

> (In any case, that's not a prerequisite for doing this -- while we wait
> for the Documents to be changed to the HTML5 way, if we ever do that, we
> can still go ahead and put innerHTML on XMLDocument.)

This I don't buy so much -- more below.

>> You can't use innerHTML on non-HTML nodes.  Assuming that you wanted the
>> part about SVG/MathML elaborated.  Or did you want something else?
>
> I don't understand why innerHTML wouldn't work on non-HTML nodes.

Maybe I'm naive, but it makes little sense to me to have an "innerHTML" property
on non-HTML nodes that does completely non-HTML things... Expedient, maybe, but
confusing in the long run.

> Sure, just throw some things into document.domConfig.

Which document?  The ownerDocument of the node being serialized?

> I can't really comment, since I don't understand the use case in the first
> place. I was assuming that the data would be sent to the server anyway.

The use case I'm thinking is communication between packages that a web app uses...

-Boris
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Ian Hickson]

On Tue, 31 Oct 2006, Boris Zbarsky wrote:

> > >
> > > You can't use innerHTML on non-HTML nodes.  Assuming that you wanted
> > > the part about SVG/MathML elaborated.  Or did you want something
> > > else?
> >
> > I don't understand why innerHTML wouldn't work on non-HTML nodes.
>
> Maybe I'm naive, but it makes little sense to me to have an "innerHTML"
> property on non-HTML nodes that does completely non-HTML things...
> Expedient, maybe, but confusing in the long run.

Well, the reason would be "it's there" in the case of elements, and
"consistency" in the case of documents. But the name isn't important to
me (and your opinion on it has been noted), the important thing is that it
makes document serialisation and parsing trivial.


> > Sure, just throw some things into document.domConfig.
>
> Which document?  The ownerDocument of the node being serialized?

Yeah.


> > I can't really comment, since I don't understand the use case in the
> > first place. I was assuming that the data would be sent to the server
> > anyway.
>
> The use case I'm thinking is communication between packages that a web
> app uses...

Why wouldn't they just pass the raw Document or Element around?

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Boris Zbarsky]

Ian Hickson wrote:
> Well, the reason would be "it's there" in the case of elements, and
> "consistency" in the case of documents. But the name isn't important to
> me (and your opinion on it has been noted), the important thing is that it
> makes document serialisation and parsing trivial.

I maintain that it still makes the simple use case of "serialize this node and
all its descendants" nontrivial.  Compare:

   var str = (new DOMSerializer()).serializeToString(node);

vs

   var doc = document.implemenentation.createDocument(null, null, null);
   var clone = doc.importNode(node);
   doc.appendChild(clone);
   var str = doc.innerHTML;

I agree that the equally simple use case of "serialize all descendants of this
node but not this node" is harder with DOMSerializer.  The question is which one
is more useful, I guess...

> Why wouldn't they just pass the raw Document or Element around?

Good question!  But they won't.  ;)  Imo, of course.

-Boris
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Ian Hickson]

On Wed, 1 Nov 2006, Boris Zbarsky wrote:

>
> Ian Hickson wrote:
> > Well, the reason would be "it's there" in the case of elements, and
> > "consistency" in the case of documents. But the name isn't important to me
> > (and your opinion on it has been noted), the important thing is that it
> > makes document serialisation and parsing trivial.
>
> I maintain that it still makes the simple use case of "serialize this node and
> all its descendants" nontrivial.  Compare:
>
>   var str = (new DOMSerializer()).serializeToString(node);
>
> vs
>
>   var doc = document.implemenentation.createDocument(null, null, null);
>   var clone = doc.importNode(node);
>   doc.appendChild(clone);
>   var str = doc.innerHTML;

No no, innerHTML would apply to everything, so the equivalent would be:

   var str = node.innerHTML;

(Currently the spec says it applies to HTMLElement only, but I'd be happy
to put it on Element if you think there's a use case for that.)


> > Why wouldn't they just pass the raw Document or Element around?
>
> Good question!  But they won't.  ;)  Imo, of course.

I'm still confused as to the use case.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Boris Zbarsky]

Ian Hickson wrote:
>> I maintain that it still makes the simple use case of "serialize this node and
>> all its descendants" nontrivial.  Compare:
...
>>   var str = (new DOMSerializer()).serializeToString(node);
...
> No no, innerHTML would apply to everything, so the equivalent would be:
>
>    var str = node.innerHTML;

OK, I sense a significant communications failure here.  Let's say we have:

   <div id="foo">Text</div>

and script as follows:

   var node = document.getElementById("foo");
   var str = (new DOMSerializer()).serializeToString(node);
   var str2 = node.innerHTML.

Then str is the string:  '<div id="foo">Text</div>'
while str2 is the string:  'Text'

To get the string in |str| using innerHTML, you would have to use the
code with importNode and company that I posted in my previous post.
This is why outerHTML exists, fwiw.

> (Currently the spec says it applies to HTMLElement only, but I'd be happy
> to put it on Element if you think there's a use case for that.)

There's absolutely a use case for that, imo.

-Boris
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Ian Hickson]

On Wed, 1 Nov 2006, Boris Zbarsky wrote:

>
> OK, I sense a significant communications failure here.  Let's say we
> have:
>
>   <div id="foo">Text</div>
>
> and script as follows:
>
>   var node = document.getElementById("foo");
>   var str = (new DOMSerializer()).serializeToString(node);
>   var str2 = node.innerHTML.
>
> Then str is the string:  '<div id="foo">Text</div>' while str2 is the
> string:  'Text'
>
> To get the string in |str| using innerHTML, you would have to use the
> code with importNode and company that I posted in my previous post. This
> is why outerHTML exists, fwiw.

Oh, I see what you're saying. I have no objection to introducing outerHTML
as well. Currently I haven't done so mostly because Mozilla doesn't
support it, so I assumed there wasn't strong demand for it.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Jonas Sicking]

Ian Hickson wrote:

> On Wed, 1 Nov 2006, Boris Zbarsky wrote:
>> OK, I sense a significant communications failure here.  Let's say we
>> have:
>>
>>   <div id="foo">Text</div>
>>
>> and script as follows:
>>
>>   var node = document.getElementById("foo");
>>   var str = (new DOMSerializer()).serializeToString(node);
>>   var str2 = node.innerHTML.
>>
>> Then str is the string:  '<div id="foo">Text</div>' while str2 is the
>> string:  'Text'
>>
>> To get the string in |str| using innerHTML, you would have to use the
>> code with importNode and company that I posted in my previous post. This
>> is why outerHTML exists, fwiw.
>
> Oh, I see what you're saying. I have no objection to introducing outerHTML
> as well. Currently I haven't done so mostly because Mozilla doesn't
> support it, so I assumed there wasn't strong demand for it.

The problem with outerHTML is that it makes sense to get, but is very
confusing to set. I.e setting outerHTML removes the current node from
the document so any additional operations on the node after that are
effectively no-ops. I.e. something like

node = document.getElementById("foo");
node.outerHTML = "<ol><li>hi</li></ol>";
node.setAttribute("start", 5);

won't do what many people would think it does. Of course, we could make
outerHTML readonly, but that'd be confusing because innerHTML is not,
and outerHTML is not in IE.

/ Jonas
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Boris Zbarsky]

Ian Hickson wrote:
> Oh, I see what you're saying. I have no objection to introducing outerHTML
> as well. Currently I haven't done so mostly because Mozilla doesn't
> support it, so I assumed there wasn't strong demand for it.

People who want that use DOMSerializer or ranges at the moment.

There's not much point to _setting_ outerHTML, but _getting_ it is another
matter, I think.

-Boris


_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml

[Lucky-3]

Jonas Sicking wrote:

> Ian Hickson wrote:
>> On Wed, 1 Nov 2006, Boris Zbarsky wrote:
>>> OK, I sense a significant communications failure here.  Let's say we
>>> have:
>>>
>>>   <div id="foo">Text</div>
>>>
>>> and script as follows:
>>>
>>>   var node = document.getElementById("foo");
>>>   var str = (new DOMSerializer()).serializeToString(node);
>>>   var str2 = node.innerHTML.
>>>
>>> Then str is the string:  '<div id="foo">Text</div>' while str2 is the
>>> string:  'Text'
>>>
>>> To get the string in |str| using innerHTML, you would have to use the
>>> code with importNode and company that I posted in my previous post.
>>> This is why outerHTML exists, fwiw.
>>
>> Oh, I see what you're saying. I have no objection to introducing
>> outerHTML as well. Currently I haven't done so mostly because Mozilla
>> doesn't support it, so I assumed there wasn't strong demand for it.
>
> The problem with outerHTML is that it makes sense to get, but is very
> confusing to set. I.e setting outerHTML removes the current node from
> the document so any additional operations on the node after that are
> effectively no-ops. I.e. something like
>
> node = document.getElementById("foo");
> node.outerHTML = "<ol><li>hi</li></ol>";
> node.setAttribute("start", 5);
>
> won't do what many people would think it does. Of course, we could make
> outerHTML readonly, but that'd be confusing because innerHTML is not,
> and outerHTML is not in IE.
>
> / Jonas

outerHTML is in IE?
<http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/outerhtml.asp>

and works are you are speaking, replaces the element with the newly
parsed fragment.

sorry to interrupt.
_______________________________________________
dev-tech-xml mailing list
dev-tech-xml@...
https://lists.mozilla.org/listinfo/dev-tech-xml