467,905 Members | 1,863 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,905 developers. It's quick & easy.

using setAttribute or set attribute directly

I am curious if there is a benefit to set attributes directly, in my
javascript, or to use setAttribute.

For example, I have this:
var input = document.createElementNS(xhtmlNS, 'input');
input.setAttribute('width', '20em');

I could have just called input.width='20em'

When is each better to use, or is there no difference between them?

Also, it is improper to use setAttribute in such a way:
input.setAttribute('onchange', mychangefunction)

Thank you for any help.

May 21 '06 #1
  • viewed: 39151
Share:
21 Replies
James Black wrote:
Also, it is improper to use setAttribute in such a way:
input.setAttribute('onchange', mychangefunction)

Have you tried it? I haven't.

Even if it does work, it would be obscure, just assign event handlers
directly.

--
Ian Collins.
May 21 '06 #2
James Black said the following on 5/20/2006 9:40 PM:
I am curious if there is a benefit to set attributes directly, in my
javascript, or to use setAttribute.
Yes, there is a benefit to setting the attribute directly. setAttribute
is known to be buggy in IE, so why bother with a buggy code?
For example, I have this:
var input = document.createElementNS(xhtmlNS, 'input');
input.setAttribute('width', '20em');

I could have just called input.width='20em'
And that is a better approach.
When is each better to use, or is there no difference between them?
The difference is buggy behavior in IE with some setAttribute calls.
Also, it is improper to use setAttribute in such a way:
input.setAttribute('onchange', mychangefunction)


No idea, never used it before. input.onchange = mychangefunction;

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 21 '06 #3
"James Black" <pl***********@gmail.com> writes:
I am curious if there is a benefit to set attributes directly, in my
javascript, or to use setAttribute.

For example, I have this:
var input = document.createElementNS(xhtmlNS, 'input');
input.setAttribute('width', '20em');

I could have just called input.width='20em'

When is each better to use, or is there no difference between them?
First of all, it's important to know what the difference is.

The former is a general DOM method. It works in all DOM documents to
set the attribute on the element.

The latter comes from the HTML DOM (and Style and Events DOMs), which
is an extension of the basic DOM. It only really applies to HTML/XHTML
documents.

One could then hope that using
node.attrName = "foo"
was equivalent to
node.setAttribute("attr-name", "foo")
(as suggested by
<URL:http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-642250288>),
but that is not the case in all browsers.
In IE, and possibly other browsers too, the DOM attribute represents
the original value, but isn't "live". To change the actual value
used by the renderer, you must assign to the property.
Also, it is improper to use setAttribute in such a way:
input.setAttribute('onchange', mychangefunction)


Yes. The value must be of type DOMString.
There isn't really a standardized connection between, e.g., the HTML
onclick attribute and a DOM attribute. The closest is
<URL:http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-registration-html40>
To follow standards, you should use the Events DOM methods
(addEventListener, etc) to handle event handlers.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
May 21 '06 #4

Lasse Reichstein Nielsen wrote:
The former is a general DOM method. It works in all DOM documents to
set the attribute on the element.

The latter comes from the HTML DOM (and Style and Events DOMs), which
is an extension of the basic DOM. It only really applies to HTML/XHTML
documents.
To embed mathml in my page I need to use xhtml, so that is why I am
exploring this area. :)
Yes. The value must be of type DOMString.
There isn't really a standardized connection between, e.g., the HTML
onclick attribute and a DOM attribute. The closest is
<URL:http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-registration-html40>
To follow standards, you should use the Events DOM methods
(addEventListener, etc) to handle event handlers.


Thank you for the response. I will go read more about the DOM2 Events
methods then.

I am playing around with some new (for me) technologies, so I can see
what may be useful for my university, and what it would take to make it
useful.

May 21 '06 #5
James Black wrote:
Lasse Reichstein Nielsen wrote:
The former is a general DOM method. It works in all DOM documents to
set the attribute on the element.

The latter comes from the HTML DOM (and Style and Events DOMs), which
is an extension of the basic DOM. It only really applies to HTML/XHTML
documents.


To embed mathml in my page I need to use xhtml, so that is why I am
exploring this area. :)


Probably it is also possible to include the content of a MathML document via
the `iframe' or the `object' element, in which case you would not need XHTML
1.1, as the included document resource has its own namespace. You would
need XML and MathML support, though.

<URL:http://www.w3.org/TR/MathML2/appendixa.html#parsing.usingdtdt>

And there are also server-side processors that can generate images from
MathML; those images cannot be scripted easily, though.
PointedEars
May 25 '06 #6
Thomas 'PointedEars' Lahn wrote:
James Black wrote:
To embed mathml in my page I need to use xhtml, so that is why I am
exploring this area. :)


Probably it is also possible to include the content of a MathML document
via the `iframe' or the `object' element, in which case you would not need
XHTML 1.1, as the included document resource has its own namespace. You
would need XML and MathML support, though.

<URL:http://www.w3.org/TR/MathML2/appendixa.html#parsing.usingdtdt>

And there are also server-side processors that can generate images from
MathML; those images cannot be scripted easily, though.


Compare:

<URL:http://pointedears.de/markup/xml/MathML-embedded>
(XHTML 1.1 plus MathML 2.0, application/xhtml+xml)

<URL:http://pointedears.de/markup/xml/MathML-included>
(HTML 4.01 Strict, text/html; MathML 2.0, application/xml)

Works for me (except of the MathML fonts) in Mozilla/5.0 (X11;
U; Linux i686; en-US; rv:1.8.0.3) Gecko/20060326 Firefox/1.5.0.3
(Debian-1.5.dfsg+1.5.0.3-2)
HTH

PointedEars
--
What one man can invent another can discover.
-- Sherlock Holmes in Sir Arthur Conan Doyle's
"The Adventure of the Dancing Men"
May 25 '06 #7
VK

James Black wrote:
To embed mathml in my page I need to use xhtml From /what/ source did you get this strange idea? Namespace usage for

HTML is well defined by producers and (lucky you :-) even by W3C. Just
on W3C they moved these docs a bit behind so that XHTML promotion would
jump up first. Yet if one knows for sure that it once existed and keeps
searching then it still can be found.

I'm using anonymous content extensively for different solutions, bot no
one paid me yet for a math: so had to adjust quickly an SVG block. The
"complexity" of the formula reflects my profound knowledge in math :-)

Side note: it appears that default installation Firefox 1.5 cannot
display MathML right away: on the first attempt I was asked to download
and install extra fonts from
<http://www.mozilla.org/projects/mathml/fonts/> (MIT Font Install
Package ~2Mb). After that all went smoothly. You may know it already,
but I thought necessary to mention.

You can serve this file as regular text/html and don't worry about
MathML uncapable browsers. - I would suggest only to change the default
text message :-)

Below the HTML you see the source for the math.xml file you have to
create.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<title>MathML</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<style type="text/css">
body {
font: 1em "Times New Roman", serif;
color: #000000;
background-color: #FFFFFF;
}
var {
display: -moz-inline-box;
display: inline-block;
margin: auto 0.2em;
padding: auto 0.2em;
font: 1em normal "Comic Sans MS", fantasy;
}
#eq01 {
-moz-binding: url(math.xml#eq01);
}
#eq02 {
-moz-binding: url(math.xml#eq02);
}
</style>
</head>
<body>
<p>Please tell what equation is solved correctly:</p>
<p>This one:
<var id="eq01">Your browser sucks</var>
or this one:
<var id="eq02">Your browser sucks</var>
</p>
</body>
</html>
// math.xml

<?xml version="1.0"?>
<bindings
xmlns="http://www.mozilla.org/xbl"
xmlns:html="http://www.w3.org/1999/xhtml">

<binding id="eq01">

<content>

<math xmlns="http://www.w3.org/1998/Math/MathML">
<mroot>
<mrow>
<mn>6</mn>
<mo>+</mo>
<mn>3</mn>
</mrow>
<mn>3</mn>
</mroot>
<mo>+</mo>
<mfrac>
<mn>9</mn>
<mn>3</mn>
</mfrac>
<mo>=</mo>
<mn>6</mn>
</math>

<html:span style="display:none"><children/></html:span>
</content>
</binding>
<binding id="eq02">

<content>

<math xmlns="http://www.w3.org/1998/Math/MathML">
<mroot>
<mrow>
<mn>6</mn>
<mo>+</mo>
<mn>3</mn>
</mrow>
<mn>3</mn>
</mroot>
<mo>+</mo>
<mfrac>
<mn>9</mn>
<mn>3</mn>
</mfrac>
<mo>=</mo>
<mn>9</mn>
</math>

<html:span style="display:none"><children/></html:span>
</content>
</binding>
</bindings>

May 25 '06 #8
VK wrote:
James Black wrote:
To embed mathml in my page I need to use xhtml From /what/ source did you get this strange idea?


The MathML Specification perhaps?
Namespace usage for HTML is well defined by producers and (lucky you :-)
even by W3C. Just on W3C they moved these docs a bit behind so that XHTML
promotion would jump up first. Yet if one knows for sure that it once
existed and keeps searching then it still can be found.
That is complete utter nonsense.
[...]
display: -moz-inline-box;
[...]
Not Valid CSS, and Gecko-proprietary.
// math.xml

<?xml version="1.0"?>
<bindings
xmlns="http://www.mozilla.org/xbl"
xmlns:html="http://www.w3.org/1999/xhtml">


You are confusing MathML and XBL.
PointedEars
--
When you have eliminated all which is impossible, then
whatever remains, however improbable, must be the truth.
-- Sherlock Holmes in Sir Arthur Conan Doyle's
"The Blanched Soldier"
May 25 '06 #9
VK

Thomas 'PointedEars' Lahn wrote:
The MathML Specification perhaps?
Noop, wrong call. MathML is /data/ in XML format. It has no means nor
business to specify to the transformation media in what environment it
must be used.
To diminish my evelness in the eyes of some possible readers :-):
mostly I'm using bindings (Gecko) and behaviors (IE) in client-side
XSLT transformers, so it all evolves in 100% pure XML environment -
until the final HTML output is sent to the HTML parser.
Namespace usage for HTML is well defined by producers and (lucky you :-)
even by W3C. That is complete utter nonsense.
You may for start google for "namespace
http://www.w3.org/TR/REC-html40" at w3.org
If you need more explanations, f'up2 ciwah

Overall I you want to stop it working, then just turn you computer off
and pretend you never saw it.
If you want a discussion of "why it must never work even if it works"
then it is better suited to <comp.infosystems.www.authoring.misc> or
something. But I cannot promise that I will follow for the latter
boring and useless "quote to death" discussion.
display: -moz-inline-box;

Not Valid CSS


Don't be boring
and Gecko-proprietary


Native MathML support is Gecko-proprietary so far - nothing I can do
about it. Lucky it is a highly rare matter in commercial solutions.
Behavior/binding twinpairs work everywhere including IE (well,
"everywhere on UA's I'm anyhow concerned to").
The only UA missing in my collection is Opera. They were working with
Mozilla all these years over the XBL standard, but at the last moment
(Opera 9 Beta) they decided to bet on their proprietary and buggy
"widgets". Yet they still have time to think it over before the final
release.

May 25 '06 #10
On 25/05/2006 22:09, VK wrote:

[snip]
Namespace usage for HTML is well defined by producers and (lucky
you :-) even by W3C.


That is complete utter nonsense.


You may for start google for "namespace
http://www.w3.org/TR/REC-html40" at w3.org


<http://www.google.co.uk/search?num=50&hl=en&safe=off&q=namespace+http%3A%2 F%2Fwww.w3.org%2FTR%2FREC-html40&btnG=Search&meta=>
Terms: namespace http://www.w3.org/TR/REC-html40
Hits: 1

That lone hit contains links to namespaces in XML.

<http://www.google.co.uk/search?num=50&hl=en&safe=off&q=namespace+site%3Aw3 .org+inurl%3AREC-html40&btnG=Search&meta=>
Terms: namespace site:w3.org inurl:REC-html40
Hits: 0

<http://www.google.co.uk/search?num=50&hl=en&safe=off&q=namespace+REC-html40+site%3Aw3.org&btnG=Search&meta=>
Terms: namespace REC-html40 site:w3.org
Hits: ~369

The first 100 results are all regarding applications of XML (I couldn't
be bothered to check the rest). Rather than wasting my time, or that of
anyone else, post a link to a normative reference that defines
namespaces in HTML.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
May 25 '06 #11
VK wrote:
Thomas 'PointedEars' Lahn wrote:
The MathML Specification perhaps?
Noop, wrong call. MathML is /data/ in XML format.


I suppose you need someone <Q>to connect the dots for you [again]</Q>,
<Q>so that your puny mind could comprehend. How boring.</Q>

A. MathML is a _markup language_; the Mathematical Markup Language, to be
precise. (Of course it is also data, as _everything_ regarding software
is data. One could also say that it is "in XML format"; however XML is
a markup language of its own. A MathML document is rather "in MathML
format". [What are you trying to accomplish by posting such tautologies
anyway?])

B. One needs namespace support to _embed_ MathML in a document written in
another markup language.

C. Namespace support is provided only by applications of XML (Extensible
Markup Language), as defined in the XML Namespaces Specification.
(If you had given this further thought, you would have recognized
that SGML applications are _not_ extensible and therefore do _not_
/need/ namespaces.)

D. XHTML and MathML are XML applications.

E. XHTML 1.1, which is the first module-based XHTML version, provides a
MathML module, implemented as a DTD incorporating both XHTML and MathML
language elements.

However, that does not mean you need to use XHTML when you want to use
MathML, and I have never said so. A MathML document can also be _included_
through an `iframe' or `object' element in an HTML document, as I have
shown.
[snipped VK fiction]
> Namespace usage for HTML is well defined by producers and (lucky
> you :-) even by W3C.

That is complete utter nonsense.


You may for start google for "namespace
http://www.w3.org/TR/REC-html40" at w3.org


But I will not. For I know, in contrast to you, that SGML applications,
like HTML, have no concept of namespaces (one reason why XHTML became
necessary). The code you have posted certainly is not Valid HTML, or
any other kind of Valid markup for that matter.
> display: -moz-inline-box;

Not Valid CSS


Don't be boring


It is not Valid CSS. It is unnecessary if you avoid XBL, which is
unnecessary here as well. And I have already posted an example here
that shows this.
PointedEars
May 25 '06 #12
VK

Michael Winter wrote:
http://www.google.co.uk/search?num=50&hl=en&safe=off&q=namespace+http%3A%2 F%2Fwww.w3.org%2FTR%2FREC-html40&btnG=Search&meta=>
Terms: namespace http://www.w3.org/TR/REC-html40
Hits: 1
Then change "namespace" to "HTML" or "xmlns", take the url
"http://www.w3.org/TR/REC-html40" into quotes, use explisit site search
site:w3.org

I'm sure that you are fully comfortable with the Web search technics.
Rather than wasting my time, or that of
anyone else, post a link to a normative reference that defines
namespaces in HTML.


I don't wast anyone time: I posted a working code made from another
code used on the daily basis by me and many others. Yet I have to waste
my time with the W3C crap, as I had to prove /to myself/ that my code
some kind of "spiritually non-working"... I don't know even how to
describe it... "destroys chakras' balance in my karma for future life"
.. Sorry for a moment irritation but I just /hate/ a la civah-civas
mental exercises.

<http://www.w3.org/TR/REC-xml-names/#defaulting>
That is one sample.
btw "http://www.w3.org/TR/REC-html40" opaque string is used for HTML
namespace in IE, but you almost never have to declare HTML namespace in
IE (still you can see that this string was chosen way ago by IE by W3C
specs, not out of evelness)
Gecko took "http://www.w3.org/1999/xhtml" for both HTML and XHTML.
(<q>The namespace name, to serve its intended purpose, should have the
characteristics of uniqueness and persistence. It is not a goal that it
be directly usable for retrieval of a schema (if any exists).</q>)

- Prove all of it!
- Sorry, time limit ;-) For the first position you can take Microsoft
VML Generator
and play with it. The rest can be found too.

<http://www.w3.org/TR/xhtml1/#normative>
An XML declaration is not required in all XML documents;
however XHTML document authors are strongly encouraged
to use XML declarations in all their documents.
Such a declaration is required when the character
encoding of the document is other than the default UTF-8 or UTF-16
and no encoding was determined by a higher-level protocol.

If one is willing to get away from XHTML and start working with
supported media, these two links is enough. If the task is to prove
everything wrong, then it's easy too - W3C has enough of quotes of any
sort and any kind.

Will it stop anonymous content from working properly on Gecko engines
or IE? Not at all, it will work the same way now and in the future.

May 26 '06 #13
VK wrote:
Michael Winter wrote:
http://www.google.co.uk/search?num=50&hl=en&safe=off&q=namespace+http%3A%2 F%2Fwww.w3.org%2FTR%2FREC-html40&btnG=Search&meta=>
Terms: namespace http://www.w3.org/TR/REC-html40
Hits: 1
Then change "namespace" to "HTML" or "xmlns", take the url
"http://www.w3.org/TR/REC-html40" into quotes, use explisit site search
site:w3.org

I'm sure that you are fully comfortable with the Web search technics.


You are such an incredibly dumb fool. If I do that, I get two results, none
that has to do with namespaces in HTML, because no such thing exists. BTW,
it is called "xmlns" for a reason ...
Rather than wasting my time, or that of
anyone else, post a link to a normative reference that defines
namespaces in HTML.


I don't wast anyone time: I posted a working code made from another
code used on the daily basis by me and many others. Yet I have to waste
my time with the W3C crap, as I had to prove /to myself/ that my code
some kind of "spiritually non-working"... I don't know even how to
describe it... "destroys chakras' balance in my karma for future life"
. Sorry for a moment irritation but I just /hate/ a la civah-civas
mental exercises.

<http://www.w3.org/TR/REC-xml-names/#defaulting>
That is one sample.


Namespaces in _XML_ (applications), you fool.
btw "http://www.w3.org/TR/REC-html40" opaque string is used for HTML
namespace in IE,
HTML, as an SGML application, does not have a concept of namespaces.
Your/Microsoft's fantasies do not count.
[more fiction]
Gecko took "http://www.w3.org/1999/xhtml" for both HTML and XHTML.
That is the namespace defined in the _XHTML_ 1.0 Specification, fool.
- Prove all of it!
You have proven nothing. No surprise here.
<http://www.w3.org/TR/xhtml1/#normative>


That is about _X_HTML, not HTML, fool.
PointedEars
--
When you have eliminated all which is impossible, then
whatever remains, however improbable, must be the truth.
-- Sherlock Holmes in Sir Arthur Conan Doyle's
"The Blanched Soldier"
May 26 '06 #14
On 26/05/2006 00:59, VK wrote:
Michael Winter wrote:
[Search] Terms: namespace http://www.w3.org/TR/REC-html40
Hits: 1
Then change "namespace" to "HTML"


Search for 'HTML' and the URL to the HTML 4.0 Recommendation? *sigh*
or "xmlns",
As that is the XML namespace attribute (prefix), would you care to
suggest how it could be applicable to namespaces in HTML? On second
thoughts, don't.
take the url "http://www.w3.org/TR/REC-html40" into quotes,
It won't return any more (useful) results than I already received.
use explisit site search site:w3.org
Already did that.
I'm sure that you are fully comfortable with the Web search technics.
Very.
Rather than wasting my time, or that of anyone else, post a link to
a normative reference that defines namespaces in HTML.


I don't wast anyone time:


You /consistently/ waste people's time, and this occasion is no
exception. By not fulfilling my very reasonable request, you have
prompted another round of posts, rather than permitting a conclusion to
reached (though I'm sure readers already know what the conclusion will be).

Surely if you /know/ that the W3C have specified the use of namespaces
in HTML, you can post a link to that document? Nobody needs to search
for anything.
I posted a working code made from another code used on the daily
basis by me and many others.
For some value of 'working'.

[snip]
Sorry for a moment irritation but I just /hate/ a la civah-civas
mental exercises.
You mean, you hate that everyone else knows what they're writing about,
but you don't? I can see how that might be frustrating, but it's not
half as frustrating as the effort it requires to make you realise that
you're wrong.
<http://www.w3.org/TR/REC-xml-names/#defaulting>
You're citing the "Namespaces in XML" Recommendation? You're joking, right?
That is one sample.


Referencing HTML 4.0 in an XML Recommendation doesn't mean that HTML
itself has namespaces. Are you really /that/ clueless?

I should imagine that the only reason why HTML itself is used is because
XHTML wasn't even a Working Draft at that point (though work had begun
on Voyager, as it was then known) and HTML would be a recognisable example.

[snip]

You have yet to make a worthwhile point. That isn't surprising, of
course, but it is irritating. Either reply with a link to a normative
reference (which will be easy if you're right), or don't bother to reply
at all.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
May 26 '06 #15
VK
Michael Winter wrote:
As that is the XML namespace attribute (prefix), would you care to
suggest how it could be applicable to namespaces in HTML? On second
thoughts, don't.


Because W3C on second thought said that "HTML namespace no", "XHTML
namespace yes"? You can find these quotes too - and plenty of.
As I stated already: if you made your mind that namespaces are /not
allowed/ to be used in HTML, no matter /can/ they be used or not, then
simply don't use them, what's the problem? Same with <iframe> in HTML
Strict - don't use it, no problem. Use only higher blessed ways. I
don't want to put anyone's soul in troubles by forcing to commit
actions treated as sins in her/his religion. :-) :-|

I just can humbly ask (pretending for a second to stay on /your proper/
point of view): why did you decide that the posted code is HTML and not
XHTML?

Because it is served as text/html? It is not a criterion for local
files, and it is allowed for XHTML1.0

Because it has extension .html ? It is not a criterion, from the server
you can serve it w/o extension at all.

Because it doesn't have a prolog? It is not a requirement for a valid
XML if encoding is default UTF-8 or specified on a higher level. So
guess what: my server sends not just Content-Type: text/html\n but more
proper Content-Type: text/html;charset=iso-8859-1\n

Because it is not a well-formed XML? It is. Just remove the redundant
meta (we don't need it as the encoding is set by the server) and change
the extension to .xml - now validate it.

Other words you want to pass a strict division line between two matters
where at least one of them (XHTML) is not strictly defined to the
common consensus. If you believe it is then post this definition at
ciwah - it conveniently did not have intensive "XHTML with text/html"
discussions recently, so everyone is full of fresh energy I think.

The regular HTML supports namespaces - this fact can be checked on
practice by everyone by using say document.createElementNS method, even
leaving bindings out. So the discussion can be only about "can I use
the supported feature or it is morally wrong". I really don't want to
push any further on that, as someone's moral issues is definitely not
my business.

Technically I can make one more attempt to "bring the desires in a
harmony with (self-)imposed moral rules" (in case if anyone is willing
to use the proposed solution but s/he is afraid of sleepless nights
because of bad feeling after that) :-

Both binding and behavior are XML-conformant data sources used to
generate layer out content for the document-requestor. They are not
inserted directly into document. They are being parsed by XML parser
and the /result content/ is added into the document. This way it is not
more "illegal" than <script> with content-type "text/javascript" used
to insert text/html content into page (over say document.write); or
XML+XSL combo resulting in an HTML 4.01 page.

If W3C docs do not help and the possibility of sleepless nights is
really a matter, one can look at this from the point of view above.
I posted a working code made from another code used on the daily
basis by me and many others.


For some value of 'working'.


It provides intended results on supported platforms and degrades
seamlessly to some predefined behavior for non-supported platforms,
where the degradation results do not prevent the document from
viewing/browsing. This result is not affected by script
enabled/disabled.
It is called "working" in its pure sense, w/o any "some value of",
"kind of" etc.
P.S. Keep in mind that in this very particular case the bottleneck is
not binding but MathML itself which is currently supported AFAIK by
Firefox only (Amaya out). On the regular run it covers IE5.5+,
Firefox1.0+, MozSuite, Camino1+, Netscape8+
Yet I readily accept the statement that it doesn't work for from 1 to
100 (and counting) not listed UA's Some of them I possibly never heard
about, but they all have in common that I do not care of any of them.
Still it always the question of particular demand and for some intranet
solution it may be required to have full MathML support for Safari 1.2
(that would be a challenge :-)
P.P.S. That my last and best attempt on the theoretical matter. I
accept bets 1:10 that in three years from now a mention of XHTML will
raise a question "and what is it?", so whoever is theoretically right
now - it has no big importance anyway. It can be you - so be you.
P.P.P.S. The future can have all kind of surpises, so I better drop the
bet to 1:5

May 26 '06 #16
VK

VK wrote:
Because it is not a well-formed XML? It is. Just remove the redundant
meta (we don't need it as the encoding is set by the server) and change
the extension to .xml - now validate it.


Before anyone jumped on this yet another side issue:

<strike>now validate it</strike>

<ins>now load it into XML parser</ins>

(well-formed !== valid)

May 26 '06 #17
VK wrote:
Michael Winter wrote:
As that is the XML namespace attribute (prefix), would you care to
suggest how it could be applicable to namespaces in HTML? On second
thoughts, don't.
Because W3C on second thought said that "HTML namespace no", "XHTML
namespace yes"?


They did not. Examples in a specification are _never_ normative. You are
obviously referring to an example in a specification, where the URL of the
first HTML 4 specification is used as a namespace for HTML. That does not
mean HTML 4 has namespaces; which is one reason why XHTML became necessary.
You can find these quotes too - and plenty of.
/You/ are to prove your currently unfounded assumptions, unless you want
to display the known logical fallacy of shifting the burden of proof, in
which case you had lost this argument (in case you have not already).
As I stated already: if you made your mind that namespaces are /not
allowed/ to be used in HTML, no matter /can/ they be used or not, then
simply don't use them, what's the problem?
The problem is you telling the opposite and trying to sell that nonsense
as the truth, misusing otherwise reliable resources by quoting them out
of context (and mixing what you managed to misunderstand from them with
your fantasy world).
Same with <iframe> in HTML Strict - don't use it, no problem.
You are comparing apples and oranges.
Use only higher blessed ways.
I don't want to put anyone's soul in troubles by forcing to commit
actions treated as sins in her/his religion. :-) :-|
I wished you would stop misusing religious notions in your argumentation,
unless it was about a truly religious matter.
I just can humbly ask (pretending for a second to stay on /your proper/
point of view): why did you decide that the posted code is HTML and not
XHTML?


What you have posted is neither of both, so there is no point in considering
an answer to this question.
PointedEars
May 26 '06 #18
On 26/05/2006 14:33, VK wrote:
Michael Winter wrote:
As that is the XML namespace attribute (prefix), would you care to
suggest how it could be applicable to namespaces in HTML? On second
thoughts, don't.
Because W3C on second thought said that "HTML namespace no", "XHTML
namespace yes"?


My question was rhetorical, yet I /knew/ you'd post some nonsense in
reply to it. That was, incidentally, why I asked you not to answer.
You can find these quotes too - and plenty of.
You've already stated that the W3C specified that HTML has namespaces,
yet when asked, you can provide no references. Now you're doing it again.

[snipped rambling]
I just can humbly ask (pretending for a second to stay on /your
proper/ point of view): why did you decide that the posted code is
HTML and not XHTML?
Aside from the example that you cited in the "Namespaces in XML"
Recommendation, I haven't made in-depth comments to any specific markup,
only the issue of namespaces. However, if you are referring to that
example, it's neither HTML nor XHTML, it's XML. If you're referring to
the markup you posted, /you/ stated that it was HTML.
Because it is served as text/html?
What is 'it'?
It is not a criterion for local files,
Local files aren't 'served' in the sense that is usually attached to HTML.
and it is allowed for XHTML1.0
It is questionable to consider markup that looks like XHTML to be XHTML
when served as text/html. None of the properties of XHTML hold in that
instance, and no user agent would consider such a document to be XML.
Moreover, I wouldn't say that serving XHTML as text/html is allowed, but
rather it is tolerated (and only because browsers don't implement HTML
as specified).

[snip]
The regular HTML supports namespaces
You have yet to prove that.
this fact can be checked on practice by everyone by using say
document.createElementNS method,


That is a method for XML documents you fool. Every namespace-aware
method includes the note, "HTML-only DOM implementations do not need to
implement this method." It should be obvious, even to you, why that is:
HTML does not have namespaces.

[snip]
I posted a working code made from another code used on the daily
basis by me and many others.


For some value of 'working'.


It provides intended results on supported platforms and degrades
seamlessly to some predefined behavior for non-supported platforms,


Your example would have people read "Your browser sucks", which isn't
even remotely close to graceful degradation.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
May 26 '06 #19
VK
VK wrote:
Because W3C on second thought said that "HTML namespace no", "XHTML
namespace yes"?
Michael Winter wrote:
My question was rhetorical, yet I /knew/ you'd post some nonsense in
reply to it.


So you /know/ the exact situation with namespaces in both HTML and
XHTML? You are the luckyest person then on the Web because even W3C and
the best W3C interpreters (like Hixie) are in troubles. There is a
difference between "no namespace" and "default namespace" and everyone
is completely lost these as W3C changed the rules several times. You
are welcome to shed some light on it at
<https://bugzilla.mozilla.org/show_bug.cgi?id=280692> followed from
<http://developer.mozilla.org/en/docs/DOM:document.createElement#Notes>

Maybe your clarifications will allow finally to make the MCD article
for createDocumentNS method (as currently it is as difficult as place
XHTML definition there - it will be re-edited or removed immediately by
the opposite camp).
It provides intended results on supported platforms and degrades
seamlessly to some predefined behavior for non-supported platforms,


Your example would have people read "Your browser sucks", which isn't
even remotely close to graceful degradation.


As it is a practical question, I answer it: that was a joke with
inclination to "Micro$oft", followed by smily and comment: <q>I would
suggest only to change the default
text message :-)</q>

On a real run it should be of course something more serious from the
text "MathML formula cannot be displayed" to say <img
src="mathmlgen.cgi?param=foo"> to insert server-side generated images
for MathML-unaware UA's.

May 27 '06 #20
VK

VK wrote:
for createDocumentNS method


for createElementNS method of course

May 27 '06 #21
On 27/05/2006 12:04, VK wrote:

[snip]
So you /know/ the exact situation with namespaces in both HTML and
XHTML?
What exactly do you think is so complicated about it? XHTML has
namespaces, and HTML doesn't. You are the only person confused by this.
You are the luckyest person then on the Web because even W3C and
the best W3C interpreters (like Hixie) are in troubles.
No they aren't.
There is a difference between "no namespace" and "default namespace"
and everyone is completely lost these as W3C changed the rules
several times.
If you are going to make assertions like that, back them up.

The most significant changes to the DOM Core description of XML
namespaces occurred whilst DOM Level 2 was still a Working Draft (so
hardly surprising). However, there are no contradictions, only better
definitions. The same goes for the XML Namespaces Recommendation. So, to
say that the W3C 'changed the rules several times' seems nothing more
than a lie (or at least a figment of your imagination).
You are welcome to shed some light on it at
<https://bugzilla.mozilla.org/show_bug.cgi?id=280692> followed from
<http://developer.mozilla.org/en/docs/DOM:document.createElement#Notes>


Why? Neither are confused. The development team know that they are
breaking the specification, they know how, and they know why. That
doesn't mean I agree (and neither does Ian Hickson, by the looks of it),
but they don't need any help understanding the issues.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
May 27 '06 #22

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by bdinmstig | last post: by
3 posts views Thread by timmy_dale12 | last post: by
4 posts views Thread by mitch | last post: by
11 posts views Thread by jesdynf | last post: by
2 posts views Thread by Aaron Gray | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.