altering text with javascript

C

C Gillespie

Dear All,

Hopefully I have a simple problem. Basically, I just want to alter some text
with JS.

Here is some of my test code:

<snip>
<script type="text/javascript">
var tmp='a';

function myfunction(){
tmp='b';
}
</script>

<input type="button" onClick=javascript:myfunction() >
<script type="text/javascript">
document.write(tmp);
</script>
<snip>

So when variable tmp is updated, I want to change the 'document.write(tmp)'
to reflect this.

If there is a better of changing text, feel free to suggest it.

Many thanks

Colin
 
S

simina

I tried too but in a different manner...
Hope it helps:

<form>
<input type="text" name="myText" value="a">
<input type="button" name="myButton" onClick="return
myfunction(this.form);">
</form>

<script language="JavaScript1.2" type="text/javascript">
function myfunction(frm)
{
frm.myText.value = "b";
}
</script>

If you don't want the "a" to be in a text field, but just a text I
don't konw how to do it...
S.
 
D

Dr John Stockton

JRS: In article <[email protected]
et>, dated Fri, 24 Sep 2004 17:58:55, seen in
Robert said:
You need to access the document node structure to insert the text. Here
is an example of this, Robert:

That way will, I think, not work in as many browsers as the method in
our FAQ, 4.15.

There is no need to require getElementById ; see past posts here, and my
page js-other.htm , for generating it, briefly.
 
M

Michael Winter

I do not follow ever detail about the code in this section, but it seems
to use innerHTML which I understand isn't in W3C.

It's not, but a lot of browsers do support it.
I added the code to support documnent.all and did some general fix up.

Note: I'm not correcting you, just suggesting a different approach.

Here's the code I use for gEBI and d.all support (part of a larger
collection of code):

var domCore = (function() {
function isN(o) {return 'number' == typeof o;}
return ({
getElementById : document.getElementById ?
function(n) {return document.getElementById(n);}
: document.all ?
function(n) {
var e = document.all[n], i = e.length;
if(isN(i)) {while(i--) {if(e.id == n) return e;}}
else if(e.id == n) {return e;}
return null;
}
: function() {return null;}
});
})();

It tries to ensure that only one element is returned by the all
collection, and that that element was retrieved by its id, only.

You could then test whether innerHTML was supported with a typeof test:

var node = domCore.getElementById(label);
if(node) {
var child;
if('string' == typeof node.innerHTML) {
node.innerHTML = text.value;
} else if((child = node.firstChild)) {
child.data = text.value;
} else if(document.createTextNode && node.appendChild) {
node.appendChild(document.createTextNode(text.value));
}
}

Probably a better way than that, though.

[snip]

Mike
 
R

Robert

Note: I'm not correcting you, just suggesting a different approach.

Here's the code I use for gEBI and d.all support (part of a larger
collection of code):

var domCore = (function() {
function isN(o) {return 'number' == typeof o;}
return ({
getElementById : document.getElementById ?
function(n) {return document.getElementById(n);}
: document.all ?
function(n) {
var e = document.all[n], i = e.length;
if(isN(i)) {while(i--) {if(e.id == n) return e;}}
else if(e.id == n) {return e;}
return null;
}
: function() {return null;}
});
})();

It tries to ensure that only one element is returned by the all
collection, and that that element was retrieved by its id, only.


This will take some study. I realize that this is copied code. Any
advantages of nesting the code in the return statement. You did end
up rather deep in all of these )}.
You could then test whether innerHTML was supported with a typeof test:

var node = domCore.getElementById(label);
if(node) {
var child;
if('string' == typeof node.innerHTML) {
node.innerHTML = text.value;
} else if((child = node.firstChild)) {
child.data = text.value;
} else if(document.createTextNode && node.appendChild) {
node.appendChild(document.createTextNode(text.value));
}
}

Dr John Stockton wants to add a code path that doesn't require the use
of getElementById().

While I didn't think of useing innerHTML for this, I'd think that
using innerHTML would be slower than inserting the node directly.

I thought that side effects are questionable. I see an if statement
as a structure to test something so I do not expect things to change
inside of the if statement.

Robert
 
R

Richard Cornford

Robert said:
Michael Winter wrote:
Note: I'm not correcting you, just suggesting a different
approach.
Here's the code I use for gEBI and d.all support (part of
a larger collection of code):

var domCore = (function() {
function isN(o) {return 'number' == typeof o;}
return ({
getElementById : document.getElementById ?
function(n) {return document.getElementById(n);}
: document.all ?
function(n) {
var e = document.all[n], i = e.length;
^
Isn't it a bit premature to be assuming that the - document.all -
collection has returned something at this point? Any undefined (or null)
value will error at the reading of - e.length -. I suppose you could
assign a value to e with a logical OR expression where undefined or null
would result in a right hand side value that could be type converted
for - e.length - and - e.id -, returning undefined at that point. A
number or boolean literal should be practical as their object
representations lack both properties (which is not true of a string):-

var e = (document.all[id] || false);
- or:-
var e = (document.all[id] || 0);

- or an explicit object that has no - length - or - id - property:-

var e = (document.all[id] || {} );
if(isN(i)) {while(i--) {if(e.id == n) return e;}}
else if(e.id == n) {return e;}
return null;
}
: function() {return null;}
});
})();

It tries to ensure that only one element is returned by
the all collection, and that that element was retrieved
by its id, only.


This will take some study. I realize that this is copied
code. Any advantages of nesting the code in the return
statement.


Function expressions do not result in the creation of a corresponding
function object until they are evaluated. So while it would be possible
to define all of the possible assigned functions with inner function
declarations their appearance as expressions in the conditional
statement means that only the one function expression evaluated will
result in the creation of a function object (which is faster in
execution than creating 3 as would happen with separate inner function
declarations).
You did end up rather deep in all of these )}.

The resulting code looks convoluted but once you are used to seeing
function expressions, and assuming the code is indented to express
structure and parenthesised to highlight the precedence in expression
evaluation, it is not nearly as complex as it might at first appear.

Personally I might have been inclined to put a few more parentheses in.
Around the conditional expression and maybe its contained function
expressions. But you can go overboard with parentheses, and javascript
authors should be capable of recognising where an expression is implied
by its context in most situations anyway.

While a - typepf - test will indicate the existence of an innerHTML
property (of string type), it has been suggested that innerHTML might be
available as a read-only property on some less-dynamic browsers (I don't
recall whether specific examples have ever been cited). Hence the more
elaborate strategy in the notes for #4.15.
Dr John Stockton wants to add a code path that doesn't require
the use of getElementById().

But this code calls - domCore.getElementById -, a method of the object
set-up in the first example block of code. And that doesn't require -
document.getElementById -.
While I didn't think of useing innerHTML for this, I'd
think that using innerHTML would be slower than inserting
the node directly.

Using innerHTML makes most sense when attempting to change more than
just the text of one text Node (i.e. To insert a branch of a DOM tree,
especially when that branch is defined a string of HTML source code).
I thought that side effects are questionable. I see an
if statement as a structure to test something so I do
not expect things to change inside of the if statement.

Moving the assignment expression outside of the - if - statement means
having a second - if/else - inside the - else - clause of a first.
Whatever might be gained in attempting to clarify that one - if -
statement can be weighed against losing the clear one-of-three structure
in the containing code. Parenthesising the assignment expression within
the - if - expression should make it clear that the assignment precedes
the evaluation of the - if - expression, which is based on the result of
the assignment expression.

Richard.
 
R

Robert

Richard Cornford said:
You could then test whether innerHTML was supported with a typeof test:

var node = domCore.getElementById(label);
if(node) {
var child;
if('string' == typeof node.innerHTML) {
node.innerHTML = text.value;
} else if((child = node.firstChild)) {
child.data = text.value;
} else if(document.createTextNode && node.appendChild) {
node.appendChild(document.createTextNode(text.value));
}
}


Moving the assignment expression outside of the - if - statement means
having a second - if/else - inside the - else - clause of a first.
Whatever might be gained in attempting to clarify that one - if -
statement can be weighed against losing the clear one-of-three structure

You have to mentally insert the assignment statement and realize that
it isn't a conditional thing. My thought process is that I have to
push the if statement down in my thinking. Remember the assignment.
Then, I have to recall the if statement. You can see from my
formatting of the code. That I do not have to do this mental activity
because it is written on paper.

At least for me, I have to do the translation in my head. It is more
complicated for me to understand.
in the containing code. Parenthesising the assignment expression within
the - if - expression should make it clear that the assignment precedes
the evaluation of the - if - expression, which is based on the result of
the assignment expression.

I reformulated the logic here.

var node = domCore.getElementById(label);
if(node)
{
var child;
if('string' == typeof node.innerHTML)
{
node.innerHTML = text.value;
}
else
{
child = node.firstChild;
if(child)
{
child.data = text.value;
}
else if(document.createTextNode &&
node.appendChild)
{
node.appendChild(
document.createTextNode(text.value));
}
}
}



Shows clearly:

1) What goes with what
2) code parrallels the oder the machine will run the code. You do not
have to back scan in the if statment nor do mental push and pop
operations.
3) avoids the confusion over = and ==
4) Hilights the assignment statement because is valid for the rest of
the code block. It is valid outside the rest of the if statement. I
believe this reason alone is something you want to hilight. Don't try
to hide the assignment in the if statement where it is easier to miss
than if it had it's own line of code.

You can see from the format of the code that I like to understand one
simple
thing at a time then go onto the next thing.

In examples to folks who are not as familiar with program, I believe
it is best to code things in an easy to understand format and avoid
coding styles that many programs have noted as problematic. Look at
the code posted to this forum and note the problems with it.

Even though you may like using an assignment statement in an if
statement many programmer have found it troublesome. I assume this
must be getting at something. Best to avoid troublesome situations.

Thanks for you other comments.

You are a great asset to this forum.

Robert
 
R

Robert

I tried too but in a different manner...
Hope it helps:

<form>
<input type="text" name="myText" value="a">
<input type="button" name="myButton" onClick="return
myfunction(this.form);">
</form>

<script language="JavaScript1.2" type="text/javascript">

Language has been depreciated in favor of type.

<script type="text/javascript">

Best to leave out JavaScript1.2. Version 1.2 acted a little different
from the other versions of Javascript.
function myfunction(frm)
{
frm.myText.value = "b";
}
</script>

If you don't want the "a" to be in a text field, but just a text I
don't konw how to do it...
S.

This is valid:

<input type="text" name="myText" value="">

You should start a new thread if this is not what you are looking for.

I do not understand this comment:
but just a text

I assume you meant a blank text field.

You can hide the input field until you need it. Ask again if this is
what you wanted.


Robert
 
R

Richard Cornford

Robert said:
Richard Cornford wrote:

You have to mentally insert the assignment statement and
realize that it isn't a conditional thing.

Maybe it takes the realisation that the - if - statement evaluates an
expression and that only a small sub-set of expressions are 'conditional
things'. An assignment is just as much an expression as any other, and
has a well-defined result. Hence:- a = b = c = d = null; - ( or
parenthesised: - a = (b = (c = (d = null))); -)
My thought process is that I have to push the if statement
down in my thinking. Remember the assignment. Then, I have
to recall the if statement. You can see from my formatting
of the code. That I do not have to do this mental activity
because it is written on paper.

At least for me, I have to do the translation in my head.
It is more complicated for me to understand.

Humans vary considerably in the way they view, model and perceive the
world, and there is no doubt in my mind that that is a good thing (there
wouldn't be nearly as much invention if everyone's perceptions were
identical). Where you see this change as a clarification of the testing
logic I see it as an obscuring of the structure of the testing. Which
was originally a clear one choice of three and is now two nested choices
of two (the outcome is the same but my preference was for the former).

I reformulated the logic here.

var node = domCore.getElementById(label);
if(node)
{
var child;
if('string' == typeof node.innerHTML)
{
node.innerHTML = text.value;
}
else
{
child = node.firstChild;
if(child)
{
child.data = text.value;
}
else if(document.createTextNode &&
node.appendChild)
{
node.appendChild(
document.createTextNode(text.value));
}
}
}

Shows clearly:

1) What goes with what
2) code parrallels the oder the machine will run the code.
You do not have to back scan in the if statment nor do
mental push and pop operations.

While computer languages all exhibit operator precedence in one form or
another I don't think there are many programmers who learn (all of) the
precedence in any language they work with. Preferring instead to use the
appropriate placement of parentheses to make the desired sequence of
operations both certain and obvious.

I don't see the mental operations involved in comprehending a
parenthesised complex mathematical operation as significantly different
from that involved in comprehending a logical expression or if
expressions that contains assignment expressions (appropriately
parenthesised).
3) avoids the confusion over = and ==

There is no doubt that they are often confused, though mostly by those
unfamiliar with javascript (and the many other languages that use the
two). And JavaScript 1.2 confused matters even more by considering an
assignment directly within an - if - statement's expression as
comparison instead. And JSLINT will not put up with it, *unless* the
assignment is parenthesised (which also has JavaScript 1.2 treat it as
assignment).
4) Hilights the assignment statement because is valid for
the rest of the code block. It is valid outside the rest
of the if statement. I believe this reason alone is something
you want to hilight. Don't try to hide the assignment in the if
statement where it is easier to miss than if it had it's own
line of code.

While the results of the assignment do indeed stand for the remainder of
the execution following it the value assigned to - child - (the fact
that it has been assigned a value at all) is only of significance within
the one branch of the original code guarded by the - if - statement in
which the assignment happened. So it might be argued that placing the
assignment in the - if - expression more closely/directly associates it
with the code that may employ the result.
You can see from the format of the code that I like to
understand one simple thing at a time then go onto the
next thing.

Fair enough. But consider how some alternative structures might be
effected by this type of re-structuring. For example, suppose an
initial - if - branch was conditional on two assignments:-

var a, b;
if(
(a = getA()) &&
(b = getB())
){
// do something with a and b
}else{
//default action on failure
}

- once you re-structure it to get the assignments out of the - if -
expressions you get something like this:-

var b, a = getA();
if(a){
b = getB();
if(b){
// do something with a and b
}else{
// default action on failure
}
}else{
// default action on failure
}

- in which the - else - code has been doubled-up.

Make that three assignments and:-

var a, b, c;
if(
(a = getA()) &&
(b = getB()) &&
(c = getC())
){
// do something with a, b and c
}else{
// default action on failure
}

- becomes:-

var c, b, a = getA();
if(a){
b = getB();
if(b){
c = getC();
if(c){
// do something with a, b and c.
}else{
// default action on failure
}
}else{
// default action on failure
}
}else{
// default action on failure
}

- and it is looking like the - else - code is going to need passing off
to a parameterised function call to avoid the repetition (with the
consequence that what was previously directly visible code is moved
elsewhere, hardly a contribution to clarity).

And now if the - else - code itself branches, two branches become six.
That looks like escalating complexity to me.

There are alternative structures that could avoid repeating the - else -
code, such as flagging the success of the nested - if - blocks:-

var success = false, c, b, a = getA();
if(a){
b = getB();
if(b){
c = getC();
if(c){
success = true;
// do something with a and b
}
}
}
if(!success){
//default action on failure
}

- in which success cannot short-circuit the test for success and an
extra local variable has been added to the context.

However, returning from the function within the innermost - if -
branch:-

var c, b, a = getA();
if(a){
b = getB();
if(b){
c = getC()
if(c){
// do something with a, b and c
return; // avoid the default action by
// returning here.
}
}
}
// default action on failure (because the function did
// not return above)

- will short-circuit the default code and remove the necessity to test
for success/failure. But now the entire default action code is outside
any branching structure and someone missing the return statement might
waste time wondering why it is applied on each execution of the
function. Indeed there is quite a lot of debate about how and where
functions should return, centred around source code clarity, and the
above structure illustrates the case for claming that returning from
anywhere but the end of a function is less than clear.
In examples to folks who are not as familiar with program,
I believe it is best to code things in an easy to understand
format and avoid coding styles that many programs have noted
as problematic. Look at the code posted to this forum and
note the problems with it.

Even though you may like using an assignment statement in
an if statement many programmer have found it troublesome.
I assume this must be getting at something. Best to avoid
troublesome situations.

For a novice there probably are advantages in seeing code that is clear
on the level of individual expressions. Hopefully I have made a case for
suggesting that code written to be clear at that level might be
detracting form clarity and simplicity at a higher (structural) level.
In learning javascript there must come a point where the individual
expressions become second nature and interest moves on to the bigger
picture. It wouldn't be fair or reasonable to insist that all code
posted to the group catered for a lowest common denominator javascript
novice, and under those circumstances a lot of very interesting code
would never get the wider public exposure it deserves.

Richard.
 
M

Michael Winter

Michael Winter wrote:
[snip]
var e = document.all[n], i = e.length;
^
Isn't it a bit premature to be assuming that the - document.all -
collection has returned something at this point?

Oops.

This is a new version of old code. Whilst fiddling with the .all section,
I must have removed that test without realising.

[snip]
var e = (document.all[id] || {} );

I'd probably choose that.
if(isN(i)) {while(i--) {if(e.id == n) return e;}}
else if(e.id == n) {return e;}
return null;
}
: function() {return null;}
});
})();


function(n) {
/* I would use l (L) instead of m, but it won't
* show very distinctly in most news readers.
*/
var e = document.all[n] || {}, m = e.length;
if(isN(m)) {
for(var i = 0;i < m; ++i) {if(e.id == n) {return e;}}
} else if(e.id == n) {return e;}
return null;
}

would probably be better. This way the first, not the last, matching
element would be returned. A more expected result. Of course, nothing
should really be expected with two or more matches: null is just as
correct in the eyes of DOM Core. It's just not very useful.

[snip]

Mike
 
G

Grant Wagner

Richard said:
var a, b, c;
if(
(a = getA()) &&
(b = getB()) &&
(c = getC())
){
// do something with a, b and c
}else{
// default action on failure
}

- becomes:-

var c, b, a = getA();
if(a){
b = getB();
if(b){
c = getC();
if(c){
// do something with a, b and c.
}else{
// default action on failure
}
}else{
// default action on failure
}
}else{
// default action on failure
}

- and it is looking like the - else - code is going to need passing off
to a parameterised function call to avoid the repetition (with the
consequence that what was previously directly visible code is moved
elsewhere, hardly a contribution to clarity).

Or:

var c, b, a = getA();
if(a){
b = getB();
}
if (b) {
c = getC();
}
if (c) {
// do something with a, b and c.
} else {
// default action on failure
}

Which has the advantage that the tests can be re-ordered, or new tests
added, without significantly affecting the underlying logic.

It also has as an advantage that if there are many tests to be performed,
you do not end up with multiple levels of indentation.

Of course, your first code example already provides these advantages.

Still, I believe there are places where this modified gauntlet is a good
structure, although perhaps not in this particular example.

For the OP, a bit more on gauntlets here: <url:
http://mindprod.com/jgloss/gauntlet.html />
 
T

Thomas 'PointedEars' Lahn

Robert said:
2) There is no need for javascript: in an event handler. Javascript is
assumed in all event handler such as onclick.

No, it is not. In fact, it is only where the default scripting language
is J(ava)Script. However, the default scripting language should be defined
explicitely when using intrinsic event handler attributes:

<meta http-equiv="Content-Script-Type" content="text/javascript">

However, especially IE does not care about this declaration; instead,
it uses the scripting language of the last script element instead.
To workaround this bug, M$ has introduced the abuse of labels in event
handler attribute values to specify the scripting language. However,
this only works in IE and is a proprietary approach that should not
be pursued on the Web.
3) It is best to put quotes around the javascript code in an event
handler. onClick="myfunction();"

More, it is *required* as of SGML:

<http://www.w3.org/TR/REC-html32#sgml>
4) It is best to put in the trailing semi-colon ";".

It does not make a real difference whether the trailing semicolon
is included in the attribute value or not. In fact, the "overhead"
that is saved if the trailing semicolon is omitted is compensated
by the then-required built-it automatic semicolon insertion process
as specified in ECMAScript.


PointedEars
 
J

Jim Ley

No, it is not. In fact, it is only where the default scripting language
is J(ava)Script.

Which is in all user agents that assume a default.
<meta http-equiv="Content-Script-Type" content="text/javascript">

This bogus, and until the HTML WG respond to the comments against it,
it doesn't even have much weight of standard, it's certainly not an
http-equiv header.
To workaround this bug, M$ has introduced the abuse of labels in event
handler attribute values to specify the scripting language.

This predates the HTML WG's bogosity.
However,
this only works in IE and is a proprietary approach that should not
be pursued on the Web.

Agreed, but it's harmless, as is the meta-equiv of course, but that's
just bogus irrelevance.

Jim.
 
T

Thomas 'PointedEars' Lahn

Jim said:
Which is in all user agents that assume a default.

That is a bold statement. You have tested all user agents in questions, all
versions of them with all OSes on all platforms? If not, you should be
more careful with generalizations like "all".
This bogus,

It is not bogus.
and until the HTML WG respond to the comments against it,
it doesn't even have much weight of standard,

The exact opposite is true. It has much weight of a standard until there
is an official consensus among the HTML WG that it should be removed from
or altered in the HTML 4.01 Specification:

it's certainly not an http-equiv header.

(There is no "http-equiv" header.) It is true that "Content-Script-Type"
is not an HTTP/1.0 or HTTP/1.1 header, but that does not invalidate the
Recommendation. There is no "text/javascript" MIME media type registered
at IANA, for example, however it is recommended, in this group too, to use
it because there is not a widely supported alternative.
This predates the HTML WG's bogosity.

That does not matter here.
Agreed, but it's harmless,

It is not. A script engine that does not support labels will yield a syntax
script error here. Since the used script engine is an unknown factor on
the Web, it cannot be recommended to pursue that proprietary approach.
[...] but that's just bogus irrelevance.

(Script) Errors that can be avoided are never irrelevant.


PointedEars
 
J

Jim Ley

The exact opposite is true. It has much weight of a standard until there
is an official consensus among the HTML WG that it should be removed from
or altered in the HTML 4.01 Specification:

No, there is an open issue against it, the WG must respond to issues
in their specifications, they have not responded to this one in many
months, this means that there is clearly not consensus (if there was,
they'd've been able to respond to the issue instantly)
(There is no "http-equiv" header.) It is true that "Content-Script-Type"
is not an HTTP/1.0 or HTTP/1.1 header, but that does not invalidate the
Recommendation.

What Recommendation? It's a bogus header, that achieves nothing - the
HTML WG will not respond to comments despite being required to (and
yes there's a problem in W3 Process that doesn't put a time limit on
responses - I have an issue against that too, currently 11 months
old...)

The HTML WG did not have the required 1 implementation of the header
at the time of specification, it's bogus.
There is no "text/javascript" MIME media type registered
at IANA, for example, however it is recommended, in this group too, to use
it because there is not a widely supported alternative.

Because there's a good reason for this, there is no reason to include
the bogus header.
It is not. A script engine that does not support labels will yield a syntax
script error here.

So that would be a non ECMAScript conformant script engine, which are
the only things relevant to default intrinsic events, this is not a
problem.

Bogus, crap reccomendations are not things to promote, they lock in
poor choices, such as the meta header you're discussing, don't blindly
support bad decisions, especially ones with open issues against like
this.

Jim.
 
T

Thomas 'PointedEars' Lahn

Jim said:
The exact opposite is true. It has much weight of a standard until there
is an official consensus among the HTML WG that it should be removed from
or altered in the HTML 4.01 Specification:

[...] they have not responded to this one in many months, this means that
there is clearly not consensus [...]

Exactly, and because of that what the HTML 4.01 Specification says
is still kind of a standard. Thank you for proving me right.
What Recommendation?

The HTML 4.01 Recommendation and the section of it I am referring to the
whole time.
It's a bogus header, that achieves nothing -

Do you have *any* strong proof for that bold statement? If not, I suggest
you be still, for it could be perceived as a nonsensical statement if
repeated.
Because there's a good reason for this, there is no reason to include
the bogus header.

You are missing the point, i.e. that there are widely used features that
are not standardized or registered but work anyway because they are widely
supported as well.
It is not. A script engine that does not support labels will yield a
syntax script error here.

So that would be a non ECMAScript conformant script engine, [...]

Wrong. Labels (or, more precisely, labelled statements; in the
ECMAScript grammar: LabelledStatements) have been introduced in
ECMAScript 3. There have been two more editions prior without
that feature which compliant scripting languages and engines are
based upon. And there have been several JavaScript and JScript
language versions that did not provide the feature.


PointedEars
 
J

Jim Ley

Jim said:
and until the HTML WG respond to the comments against it,
it doesn't even have much weight of standard,

The exact opposite is true. It has much weight of a standard until there
is an official consensus among the HTML WG that it should be removed from
or altered in the HTML 4.01 Specification:

[...] they have not responded to this one in many months, this means that
there is clearly not consensus [...]

Exactly, and because of that what the HTML 4.01 Specification says
is still kind of a standard. Thank you for proving me right.

No, since if that was the case, responding to the issue would've been
trivial, and wouldn't've taken so long.
Do you have *any* strong proof for that bold statement?

Proof of what, that's bogus, I can't see what I could provide other
than the absence of the WG's explanation in response of the issues
against it, of that it achieves nothing, sure the fact that all but an
insignificant minority of pages don't have it and they all work in all
user agents.
You are missing the point, i.e. that there are widely used features that
are not standardized or registered but work anyway because they are widely
supported as well.

Yep, such as javascript being the default script language for
intrinsic events.
It's not what the W3C standard specifies. But seamonkey see, seamonkey do.

An interesting sig. Given that you're arguing for blinding following
a W3C standard when it has no benefit, and I'm saying, follow the
de-facto standard.

Jim.
 
T

Thomas 'PointedEars' Lahn

Jim said:
Jim said:
[...] Thomas 'PointedEars' Lahn [...] wrote:
and until the HTML WG respond to the comments against it,
it doesn't even have much weight of standard,
The exact opposite is true. It has much weight of a standard until
there is an official consensus among the HTML WG that it should be
removed from or altered in the HTML 4.01 Specification:
[...] they have not responded to this one in many months, this means
[that
there is clearly not consensus [...]
Exactly, and because of that what the HTML 4.01 Specification says
is still kind of a standard. Thank you for proving me right.

No, since if that was the case, responding to the issue would've been
trivial, and wouldn't've taken so long.

You are hedging. There is no official consensus among the WG and so the
last edition of the HTML 4.01 Specification is the only valid reference
on this topic.
Do you have *any* strong proof for that bold statement?

Proof of what, that's bogus, [...]

Yes, strong proof of that, exactly. That would include a long list of
positive UA tests, but then I don't expect you to ever provide it.
Yep, such as javascript being the default script language for
intrinsic events.

No, that depends on the UA.
An interesting sig. Given that you're arguing for blinding following
a W3C standard when it has no benefit,

1. I am not arguing for blinding following a W3C standard (better: a W3C
Recommendation). If you would have read my posting(s) thoroughly, you
would have known. For example, I disregard the Recommendation's section
that says "script" element's content should be commented out, for I know
that there is no (quasi-)standards compliant HTML UA out there that does
not support the "script" element (as I have proven prior.)

2. That this feature does not have a benefit remains to be proven.
Since you state that it does not have one, you are the one to prove it.
If you cannot prove it or you are not willing to do so, your statement
remains false, and: By repeating false statements (over and over again)
they do not become more true. [psf 4.18] Period.
and I'm saying, follow the de-facto standard.

Which I do in this case. The (HTML 4.01) Recommendation is
the de-facto standard; your unproved allegations are not.


PointedEars
 
J

Jim Ley

You are hedging. There is no official consensus among the WG and so the
last edition of the HTML 4.01 Specification is the only valid reference
on this topic.

No, that's the point of an issue against a specification - the
specification isn't clear, or is dubious in its nature etc. hence the
issue - The element is suspect until the issue is resolved. (like a
law that is being reviewed by a constitutional court, the law is
suspect)
Yes, strong proof of that, exactly. That would include a long list of
positive UA tests, but then I don't expect you to ever provide it.

Lots of UA tests wouldn't prove it, there'd always be another UA, so
that proof method wouldn't be acceptable to me.
No, that depends on the UA.

No it does not! Or prove it... (please don't actually bother...)

Jim.
 
R

Richard Cornford

Thomas said:
Jim said:
[...] Thomas 'PointedEars' Lahn [...] wrote:
It's a bogus header, that achieves nothing -
Do you have *any* strong proof for that bold statement?

Proof of what, that's bogus, [...]

Yes, strong proof of that, exactly. That would include a
long list of positive UA tests, but then I don't expect you
to ever provide it.

You have got your logic the wrong way around here. Evan an infinite list
of browsers that pay no heed to the bogus META element, or any
corresponding HTTP header, could not _prove_ that the header was bogus.
However, just one example of a browser that did take some significant
action in the presence of the META element (or HTTP header) that it
would not take in the absence of the same, would logically falsify the
assertion that the META/header is bogus. But realistically, the onus is
on you to find that one example. Otherwise the fact that nobody else has
ever cited such a browser (and in a community with quite a curiosity
about the diversity of web browsers) supports the theory that no such
browser exists.

2. That this feature does not have a benefit remains to be
proven. Since you state that it does not have one, you
are the one to prove it. If you cannot prove it or you
are not willing to do so, your statement remains false,
and: By repeating false statements (over and over again)
they do not become more true. [psf 4.18] Period.

It is not possible to prove anything logically. But any non-metaphysical
theory can be demonstrated to be false (disproved) if it is false. You
are the one asserting that the theory is false so the onus is on your to
present the evidence that disproves it.

Richard.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top