295938 - XMLHttpRequest DOM data doesn't style.

Status: RESOLVED INVALID

(Core :: DOM: CSS Object Model, defect)

Description

[Nigel McFarlane]

XML data retrieved with XMLHttpRequest and inserted into the DOM
of an HTML document as document fragments doesn't apply any inline styles.
Which this might possibly be correct, there's no seperate namespace
for the inserted content, so it's a non-intuitive effect. It's also
very confusing when examined with the DOM Inspector, which shows
style attributes in place that aren't styled.

See test case. Tested on Fx 1.0.4, probably OS=all and Platform=all
but I can't test that from here.

XMLHttpRequest doesn't seem to have one place where bugs can land.
Feel free to reallocate this.

- N.

Comment 1

[Nigel McFarlane]

Attachment: run this.

Comment 2

[Nigel McFarlane]

Attachment: test data

Comment 3

[Martijn Wargers (dead)]

Interesting bug, but I think this is invalid.
ResponseXML returns a document Node
http://www.whatwg.org/specs/web-apps/current-work/#scripted-http

It is not very clear to me how a document node should interact with appendChild,
but it seems like Mozilla is doing the same as for DocumentFragment:
"If it is a DocumentFragment object, the entire contents of the document
fragment are moved into the child list of this node"
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-184E7107

So now we're having the interesting situation that xml nodes are inserted inside
an html document (didn't know that was possible).

That xml document of yours doesn't have any namespace URI's, so every element in
there has null namespace URI.
Basically, that's why it is not working, those elements are not in the xhtml
namespace. If you would add  xmlns="http://www.w3.org/1999/xhtml", then you get
the desired effect.

Comment 4

[Nigel McFarlane]

Look at the test case again.

a) It doesn't insert the Document node; it inserts all the children of
   that node, which are at least Elements and possibly Document Fragments.

b) There's no XHTML here; it's a Tag Soup example. Feel free to create
   test cases/bugs for other combinations of Tag Soup/HTML/XHTML/XML.
   Perhaps some of them have xmlns issues as you describe, but this is
   the simplest case as a starting point.

I'm not saying this is good practice; I'm saying the way Mozilla works
is confusing for those who aren't standards mavens (and possibly for
those that are). There are no data islands in Mozilla; content inserted
into a target document should adopt the type of that document, at least
where namespace rules aren't available to broker a different outcome.

- N. 

Comment 5

[Hixie (not reading bugmail)]

> b) There's no XHTML here; it's a Tag Soup example.

Ah but that's the problem. There are two sources of nodes: Tag Soup nodes (HTML
nodes) which are known to be HTML, and XML nodes, which are in no namespace, and
therefore are not known to be HTML. When you merge the XML nodes into the
document with the HTML nodes they don't magically change type, so they are still
not HTML nodes.

(You could merge SVG or MathML nodes into the HTML document, and you wouldn't
want them to stop working, it's the same principle here.)

Since the "style" attribute and "p" elements and so forth in your XML file
aren't in any way marked up as being XHTML, they don't suddenly become magical
when they are inserted into another document.

You can fix this by putting |xmlns="http://www.w3.org/1999/xhtml"| on your <p>
elements.

Comment 6

[Nigel McFarlane]

Hmm. I clearly don't understand the protocol for ad-hoc intermingling
of HTML's pseudo-SGML and XHTML's XML, especially in the Tag Soup case.
More homework for me. Never heard of a standard for such a thing.
Any pointers?

Comment 7

[Hixie (not reading bugmail)]

Basically they're the same, because the mingling happens at the DOM level.

If the DOM is generated from XML, then the nodes get the magic from their
namespace. If the DOM is generated from HTML, then the nodes get their magic as
if they had an XHTML namespace (it's just assumed). Then once we have the nodes,
they keep their magic wherever they are put in the DOM.

There isn't a specific reference, it's just the DOM specs really, with the
various XML and HTML specs.

WHATWG's HTML5 spec will probably define this better in due course.

Comment 8

[Nigel McFarlane]

Ok, I've read everything, everywhere. "magic" is not well-defined
anywhere and for quirks mode, choosing HTML or XHTML magic is pretty
arbitrary, and a UA-specific issue.

My concern is that the quirks mode/namespaceless XML combo
is a common starting point for beginners, and beginners need
the tool to "just work" without complications.

I argue that the responseXML content, in the absence of
standards, and in the case of quirks mode, should be imported
into the quirks mode magic, whatever it is. That wouldn't
damage the standards support modes of Mozilla in any way.
It is also trivial post-processing of XML content; you can
turn XML into HTML a variety of ways, eg XSLT. So it is no
form of mis-treatment either.

Comment 9

[Hixie (not reading bugmail)]

The quirks mode is decided by the type of the document. XML documents never
trigger quirks mode. Thus, responseXML documents are never in quirks mode.

This all does "just work". Just put in the namespace and you're done.

Comment 10

[Nigel McFarlane]

I didn't say quirks mode should be triggered by XML. I said that
namespaceless XML brought into a quirks mode document (via DOM
operations only) should, for best effect, be converted to match the
quirks mode document.

It doesn't "just work" for beginners; namespaces are an
intermediate concept and therefore not available to beginners.

Comment 11

[Hixie (not reading bugmail)]

XMLHttpRequest is also an intermediate concept, then.

Comment 12

[Nigel McFarlane]

This bug is nothing but an argument now. If Ian ever desists,
I'll open a seperate bug with the same title and dup this one.
If Ian persuades everyone, we can wontfix here.

comment 11 attempts a technical analysis but this bug is
as much about education as anything:

XMLHttpRequest is a facility exposed to quirks mode where
beginner learners typically play, and should work as beginners expect
in that context. Also, beginners commonly choose what to learn based
on utility arguments, and XMLHttpRequest is a high-utility tool.
By comparison, namespaces are a low utility tool, from a beginner's
point of view. Complaints about namespaces are common. Even if you
argue that there are many easier features to learn first, the bottom
line is that when the time comes to learn XMLHttpRequest, an easy
learning path is a valuable thing.  The capability to learn
XMLHttpRequest without having to integrate namespace concepts at the
same time is of high practical value. It efficiently readies the
learner. That easy learning path should integrate with other
concepts the beginner has already internalised, like style=.

- N.

Comment 13

[Hixie (not reading bugmail)]

We do more of a favour to beginners by treating them like adults and educating
them to do the right thing straight away, than we do by coddling them and
pretending that what they are doing is correct.

Not putting on the namespace is an accessibility problem (when the content is
accessed directly, it cannot be recognised as XHTML). Putting on the namespace
is easy (no prefixes involved, which is what is really hard about namespaces).
Faking the namespace will result in problems when people are doing the right
thing (as it means there is no way to include content from _other_ namespaces
and have it work correctly).

Comment 14

[Nigel McFarlane]

If you're going to make an education argument, you'd better be
prepared to back it with an education theory. Classical education
styles, which emphasis rigour and high standards from the start,
are productive only for a small number of people who tend to
be talented or self-motivated anyway. The majority of people
require a more contextual and supportive learning experience
that has a different set of internal rules.

If you want to bring moral arguments to bear: "treat
people like adults", then the best argument is to apply
a theory of education that works, that helps, and that
is practical, not to task people with abstract rigour
that is a less accessible learning process. It is not
denigrating to give people tailored learning tools, it
is thoughtful, enlightened, assistive and rewarding.
The highly competant few can and do find their own way.

In any event, your argument has a massive hole. School
children are a class of learner that shouldn't be treated
like adults. They should be treated with respect, but as the
children or adolescents that their personal development
demands they be.

A second hole is assuming that somehow "upholding" people
in a more civilised state is better than achieving learning
outcomes. It's not. High performance learning using the right
tools yields more outcomes, which advances the person's own
experience and life efficiently, in a context meaningful to
them.

No one is saying that the standards agenda should be held
hostage to the needs of the unwashed majority, but quirks
mode is the right place for many people to start without
the counter-productive burden of classical rigour. That is
not to say that those people will never learn rigour,
merely that they need a different pathway than that which
you or I might prefer.

In quirks mode and namespaceless XML, there is no XHTML.
If people are "doing the right thing" then they won't be
in quirks mode in the first place; they'll be in HTML Strict
or entirely within XML where namespaces are defined. I can't see
any clash when quirks and strict regimes are typically seperate.
I didn't propose that an implementation do "faking"
either, that implies that something "real" lurks underneath.
I propose that namespaceless XML loaded into quirks mode
HTML be made into quirks mode HTML body and soul, or a
mechanism suficiently similar that style= can work.

- N.

Comment 15

[Hixie (not reading bugmail)]

I've no idea what you're talking about any more, sorry. However, from a
technical perspective, as I've pointed out twice so far, doing namespace-munging
would break potential use cases that are correctly written. That is bad. Since
doing this right is so easy, and since there are no major sites depending on
this bug (which is the criteria we use to decide whether to add a quirk), I do
not think we should increase the complexity of our codebase to handle this
authoring error.

Comment 16

[Nigel McFarlane]

I'm talking about a very big use case, and about a proper view of
the performance of Mozilla in terms of technology uptake. That is
entirely a technical argument, since the act of learning is a very
technically complex process. The whole ICT industry is driven daily
by learning; and learning is an important factor in technology
success and use. That bears directly on the success or otherwise
of Mozilla and the Web. It is entirely a technical matter whether
people successfully use Mozilla or not.

Features that robustly support technology education are critical
to technology popularity, especially in learning-intensive
environments like programming.

The lack of a broken web site is neither necessary nor sufficient
for quashing this bug. There are definite forward-looking
advantages to the web in general, and competitive advantages
to Mozilla specifically, in fixing this feature.
Advantages include:

- enlarged product respect in educational settings, where
  most technology people eminate from.
- lowered barriers to entry for those wishing to contribute
  something minor to Mozilla.
- tool support for core W3C goals: the web is for everyone.
- more pages that "just work", independent of quality factors.
- more competitive features against web-alternatives like Longhorn.

It's very clear that Mozilla and/or Firefox is a quality
web development tool; it makes perfect sense to add more assistive
features, especially where they don't impact standards-oriented
regimes.

You've still supplied no robust example that is affected by
this fix. Show us code.

If you find this cross-disciplinary type of argument complex
to unravel, then we all appreciate your attempts, but in the end
you may not be arguing from the right solid ground. Your arguments
here serve only to drive people from Mozilla and from the Web,
not towards it, because under your rule, they can't get their
beginner coding experiments to work, and therefore give up in
frustration. That is a bad outcome for them and for Mozilla.

Comment 17

[Boris Zbarsky [:bzbarsky]]

XMLHttpRequest fetches XML.  That's just a fact of life.  You're asking us to
parse this XML with a tag-soup parser.  This would break large number (most, I
suspect) of the XMLHttpRequest users out there, so it's not happening.

Sorry, but use of XMLHttpRequest means use of XML and hence understanding of how
XML works.  There's no shortcut there.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Admittedly I have not read through all comments here, so I might be restating
things that has already been said. But here goes anyway...

I don't really like Ians use of the word 'magic'. There is no magic involved
with parsing HTML to give it an XHTML namespace. When we parse HTML we create
html objects. These behave much like the xhtml objects created when we parse
XHTML. But they are not exactly the same. The HTML parser creats HTML, the XML
parser creates XML (which can include SVG, MathML and XHTML).

Once the node-tree is built the objects are, for better or worse, what they are.
If you have an xml-node in the null namespace with the name 'input', that node
does not have a .value property. And if you render it it doesn't display a form
control. Same goes for an xml <a> element. It does not render as a link and it
does not have a .click() function that can be called.

If these objects are moved into a HTML document, they do not change. They are
still plain xml objects. The <input> does not have a .value and the link does
not have a .click(). For the same reason these elements do not render as html
elements.

This is how things work today.

Even if we could (which we can't) it would IMHO be very confusing to go through
all the objects in a node-tree when inserted in a HTML document and add these
functions and properties to these objects. That would be magic.

We could in theory render these objects as HTML I guess. But IMHO it would be
very confusing to have objects that looked like HTML, but didn't act like them.