Dom style attribute

[Soledad Vel]

Hi All,

i write this code:

var sliderwidth=100;
var sliderheight = 100;
var div1 = document.createElement('div');
div1.setAttribute('id','d5');
div1.setAttribute('style',
'background-color:yellow;position:relative;width:'+sliderwidth+'px;heigh
t:'+sliderheight+'px;overflow:hidden;');
var txt3 = document.createTextNode('Some text content for my div
with yellow background');
div1.appendChild(txt3);
document.body.appendChild(div1);

can anybody tell me why the Internet Explorer browser (for windows) does
not apply the style attribute?

Thanks.

 

[VK]

i write this code:

var sliderwidth=100;
var sliderheight = 100;
var div1 = document.createElement('div');
div1.setAttribute('id','d5');
div1.setAttribute('style',
'background-color:yellow;position:relative;width:'+sliderwidth+'px;heigh
t:'+sliderheight+'px;overflow:hidden;');
var txt3 = document.createTextNode('Some text content for my div
with yellow background');
div1.appendChild(txt3);
document.body.appendChild(div1);

can anybody tell me why the Internet Explorer browser (for windows) does
not apply the style attribute?

Because you did not ask him to do so. All you asked is to set attribute
value of "style" node to string "background-color:......" and it did it
as asked. See my explanations about DOM Tree vs. DOM Interface in the
recent thread "Can see property in NS" in this newsgroup. As you seem
want to script DOM Interface and not just setting string value in the
DOM Tree, then do what you /want/:

<script type="text/javascript">
function init() {
var sliderwidth = 100;
var sliderheight = 100;
var div1 = document.createElement('DIV');
div1.id = 'd5';
with (div1.style) {
backgroundColor = 'yellow';
position = 'relative';
width = sliderwidth+'px';
height = sliderheight+'px';
overflow = 'hidden';
}
var txt3 = document.createTextNode('Some text content for my div');
div1.appendChild(txt3);
document.body.appendChild(div1);
}

window.onload = init;
</script>

 

[RobG]

Because you did not ask him to do so.

The attribute was set, the browser *should* respond.

<URL:http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-F68F082>

IE does not respond because its setAttribute method is broken for some
attributes.

If your explanation is correct (and it isn't), how come I can set the
'rows' attribute of a textarea and see it change in the document?

var ta = document.createElement('textarea');
ta.setAttribute('rows','100');
document.body.appendChild(ta);

As is often stated, IE's setAttribute method is unreliable, it works in
some cases but not others and therefore setAttribute in general should
be avoided if suitable other methods exist to set attributes.


[...]

with (div1.style) {

The use of 'with' can make maintenance more difficult, its use here
doesn't seem to make life significantly easier than:

var ds = div1.style;

backgroundColor = 'yellow';

ds.backgroundColor = 'yellow';
...

[...]

 

[VK]

The attribute was set, the browser *should* respond.

It does "respond" - it changes the corresponding text node value for
the attribute. The common mistake is to think that UA is /obligated/ to
parse the value and update graphics context accordingly. As the DOM
specs state right the opposite, the only source of this allusion as I
see it is in the "convenience AID" in Gecko.

<quote cite="http://www.w3.org">
setAttribute(String)
Adds a new attribute. If an attribute with that name is already present
in the element, its value is changed to be that of the value parameter.
This value is a simple string; it is not parsed as it is being set. So
any markup (such as syntax to be recognized as an entity reference) is
treated as literal text, and needs to be appropriately escaped by the
implementation when it is written out.

IE does not respond because its setAttribute method is broken for some
attributes.

No, it doesn't respond because it is the chosen AID (Anti-Idiot
Defence) behavior.

If your explanation is correct (and it isn't), how come I can set the
'rows' attribute of a textarea and see it change in the document?

In the same way why "!@#$%" as background-color will be aqua and
"!ffffff" will be black. Out of the scope of specifications you can
have only one requirement to an UA: try do not crash with loosing your
data. IE doesn'r do the latter in neither case so in both cases it's
fine (so is Firefox).

 

[Richard Cornford]

It does "respond" - it changes the corresponding text node value for
the attribute. The common mistake is to think that UA is /obligated/ to
parse the value and update graphics context accordingly. As the DOM
specs state right the opposite, the only source of this allusion as I
see it is in the "convenience AID" in Gecko.

<quote cite="http://www.w3.org">
setAttribute(String)
Adds a new attribute. If an attribute with that name is already present
in the element, its value is changed to be that of the value parameter.
This value is a simple string; it is not parsed as it is being set. So
any markup (such as syntax to be recognized as an entity reference) is
treated as literal text, and needs to be appropriately escaped by the
implementation when it is written out.


No, it doesn't respond because it is the chosen AID (Anti-Idiot
Defence) behavior.


In the same way why "!@#$%" as background-color will be aqua and
"!ffffff" will be black. Out of the scope of specifications you can
have only one requirement to an UA: try do not crash with loosing your
data. IE doesn'r do the latter in neither case so in both cases it's
fine (so is Firefox).

 

[Richard Cornford]

It does "respond" - it changes the corresponding text
node value for the attribute.
The common mistake is to think that UA is /obligated/
to parse the value and update graphics context accordingly.
As the DOM specs state right the opposite,

No they don't. If anything they imply that assigning values to the
attribute should modify some (most) of the properties of the interfaces
defined in the HTML DOM.

the only source of this allusion as I
see it is in the "convenience AID" in Gecko.

You were never very good at seeing anything, especially where it
involves the interpretation of English combined with reasoned thought.

<quote cite="http://www.w3.org">
setAttribute(String)
Adds a new attribute. If an attribute with that name is already
present in the element, its value is changed to be that of the value
parameter. ...

</quote>

In the HTML DOM specification many of the interface property definitions
take the form of this example, the - id - property of the HTMLElement
interface:-

<quote
cite="http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html"id of type DOMString
The element's identifier. See the id attribute definition
in HTML 4.01.
</quote>

- where the - id - property is defined in terms of the HTML attribute
definition. Implying that it gets its value from the attribute in the
HTML mark-up (or the default for that attribute in the case of
attributes that have an implied default value).

However, the - src - property of the HTMLIFrameElement interface is
defined as:-

<quote
cite="http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html"src of type DOMString
A URI [IETF RFC 2396] designating the initial frame contents.
See the src attribute definition in HTML 4.01.
</quote>

-in which the value is qualified with the word "initial". If it was not
intended that changes to the HTML attribute values would update the
pertinent interface properties then there would have been no need for
such qualification, as the value of - src - must then be the initial
URI.

The fact that some interface properties defined in reference to HTML
attributes are qualified and the majority are not implies that the
intention was that modifying the value of the HTML attribute would
directly influence the values of the pertinent unqualified interface
properties.

This impression is reinforced by:-

<quote
cite="http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html"The attributes are exposed as properties for compatibility with DOM
Level 0. This usage is deprecated because it can not be generalized to
all possible attribute names for XML. We recommend the use of generic
methods on the core Element interface for setting, getting and removing
attributes.
</quote>

If the HTML DOM specification recommends using attribute getting,
setting and removing methods rather then the exposed properties then it
must be their intention that acting upon attributes in this way have all
the effects of manipulating the DOM through the exposed properties.

Which is why we are stuck with using the exposed properties directly as
the only reasonably cross-browser alternative.

No, it doesn't respond because it is the chosen AID
(Anti-Idiot Defence) behavior.

<snip>

You don't know what you are talking about, again.

Richard.