Closed Bug 136158 Opened 23 years ago Closed 22 years ago

Default values in some dom object properties

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 65469

People

(Reporter: pabloa, Unassigned)

References

Details

Attachments

(1 file)

I send the HTML sample in this file
2.07 KB, text/html
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 BuildID: 2002031115 A few problems: - The default value of the some properties aren't initialized. So when you ask for its value, it returns empty string. - Another thing is that in e few case I can look for the current value of a property. - We need a method to reset to its default value a property. In a lot of script the people use '=""' because "" is a incompatible property (so the browser know that it means 'the default property value') or if this value is valid, no problem. :-) - If I assign to a DOM property a bad value, Mozilla doesn't show a runtme error. This is BAD for debug stuff. Reproducible: Always Steps to Reproduce: 1. Cut and paste this little sample and browse it. <html> <head> <title>Untitled Document</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <style type="text/css"> <!-- .mostrar { background-color: #FFCC33; display: block} .nomostrar { background-color: #FFCC33; display: none } --> </style> </head> <body bgcolor="#FFFFFF" text="#000000"> <p> <script language="JavaScript"> function visibleOnOff( enombre) { // This Line show the default value propert problem!! // In IE it return the default DOM value. // The property has a default value and I believe that THIS value must be returned alert( "default value problem :" + document.getElementById( enombre).style.visibility) // This does not return error... very difficult to debug document.getElementById( enombre).style.visibility = "foo value"; alert( "not easy debug :" + document.getElementById( enombre).style.visibility) // Which is the real value? document.getElementById( enombre).style.visibility = "visible"; document.getElementById( enombre).style.visibility = "foo value"; alert( "real Value :" + document.getElementById( enombre).style.visibility) // The '= ""' is used in a lot of script to reset the property to // the default value. This isn't the case in Mozilla. We need a // way to reset all the properties to their default values. document.getElementById( enombre).style.visibility = "hidden"; document.getElementById( enombre).style.visibility = ""; alert( "generic reset method :" + document.getElementById( enombre).style.visibility) if( document.getElementById( enombre).style.visibility == 'hidden' ) { document.getElementById( enombre).style.visibility='visible'; } else { document.getElementById( enombre).style.visibility='hidden'; } // document.getElementById( 'grupoMensajes').innerHTML='aAAAAAAAAAAAa'; alert( document.getElementById( 'grupoMensajes').innerHTML); } </script> </p> <p id="grupoMensajes">Ampliar Mensajes</p> <p><a href="javascript:visibleOnOff('m2')">Test</a><br> Contraer</p> <p>Primera L&iacute;nea</p> <p id="m2">Segunda L&iacute;nea</p> </body> </html> Actual Results: The property is in a not known value and it is difficult to debug. Expected Results: In the code are comments with the expected results.
Blocks: 55240
>- The default value of the some properties aren't initialized. So when you ask >for its value, it returns empty string. This is a known issue... you will find that default values are implemented for some properties (mainly the table element properties). We implemented not long ago a mechanism to return default values in the DOM, however we haven't had the time to assign default values to the properties yet. It's easy though, so if someone wants to step up, be my guest. CC'ing bz on the DOMStyle default values issue. >- Another thing is that in e few case I can look for the current value of a >property. I don't understand the problem here >- We need a method to reset to its default value a property. In a lot of script >the people use '=""' because "" is a incompatible property (so the browser know >that it means 'the default property value') or if this value is valid, no >problem. :-) Interesting idea. Is there any (upcoming) standard regarding this? Note that I think that style.visibility = "" works in Mozilla. At least it works for style.display >- If I assign to a DOM property a bad value, Mozilla doesn't show a runtme >error. This is BAD for debug stuff. Does the spec say anything about handling bogus values for properties? We do throw exceptions when the W3C says we should.
Status: UNCONFIRMED → NEW
Ever confirmed: true
> >- Another thing is that in e few case I can look for the current value of a > >property. > > > I don't understand the problem here Try this part of the attach: // Which is the real value? document.getElementById( enombre).style.visibility = "visible"; document.getElementById( enombre).style.visibility = "foo value"; alert( "real Value :" + document.getElementById( enombre).style.visibility) The alert message is empty, so the current value is undeterminated. > Interesting idea. Is there any (upcoming) standard regarding this? > Note that I think that > style.visibility = "" works in Mozilla. At least it works for style.display I don't know really, but 'the other browser' resolve it on this way. And it's a good way to default the property values. > >- If I assign to a DOM property a bad value, Mozilla doesn't show a runtme > >error. This is BAD for debug stuff. > > Does the spec say anything about handling bogus values for properties? We do > throw exceptions when the W3C says we should. Ok. But at last put a warning message in the javascript console. For example: Warning: Current value 'yyyy' of Property 'xxxxx' is invalid! Because the specs is not clear on this, I think that it's implementation details stuff and this accelerate A LOT the debugging. I don't have am excellent skill of C Programing, but if you say that "It's easy though, so if someone wants to step up, be my guest." maybe that I could look a bit. Where can I get it?
> // The property has a default value and I believe that THIS value must be > returned > alert( "default value problem :" + document.getElementById( > enombre).style.visibility) This should return the empty string in your testcase. document.getElementById(enombre).style is the CSSStyleDeclaration corresponding to the inline style on the element with id "enombre" (see http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-ElementCSSInlineStyle). Once you have the CSSStyleDeclaration, you get its .visibility property, which involves an implicit cast to the CSS2Properties interface (http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-CSS2Properties). As the spec says, getting .visibility is equivalent to calling getPropertyValue("visibility") on CSSStyleDeclaration. The definition of the getPropertyValue method says: Return Value DOMString Returns the value of the property if it has been explicitly set for this declaration block. Returns the empty string if the property has not been set. Since the visibility is not explicitly set in this declaration block (i.e. in the inline style) we return the empty string, as the spec demands. If IE does something different, it's a blatant spec violation. > // This does not return error... very difficult to debug > document.getElementById( enombre).style.visibility = "foo value"; Returning an error here would break forward-compatible parsing. For example, consider a CSS3 that is released that has "foo value" as a valid balue of visibility. Consider a script that uses said value. This script would automatically break in old browsers which give an error on that line, thus defeating much of the point of CSS. In short, there is no concept of a "parser error" in CSS, just a concept of "this is not defined in a specification yet and should be silently ignored". If you set visibility to "foo value" in a stylesheet, the CSS parser would not stop processing at that point. IMO the DOM should behave the same way. If you want an error, you can yourself add assertions about .visibility being equal to the value you just set and throw an exception if that is not the case. > // Which is the real value? > document.getElementById( enombre).style.visibility = "visible"; > document.getElementById( enombre).style.visibility = "foo value"; That would depend on the version of CSS supported by the browser and on whether "foo value" is a defined value of visibility in that version of CSS. > // The '= ""' is used in a lot of script to reset the property to > // the default value. This isn't the case in Mozilla. We need a > // way to reset all the properties to their default values. > document.getElementById( enombre).style.visibility = "hidden"; > document.getElementById( enombre).style.visibility = ""; This _does_ reset the value to its default -- unset. If you're interested in the _computed_ style of the element as opposed to what's currently in its inline style, then you want to use getComputedStyle, which _will_ have the "default" value of the property as you want (see the definition of the ViewCSS interface at http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-ViewCSS and of the DocumentView interface at http://www.w3.org/TR/2000/REC-DOM-Level-2-Views-20001113/views.html#Views-DocumentView). In short, the only place where our behavior is at all subject to modification from the DOM Style end of things is to add that warning to the JS console. This will require some arch work as the CSS parser is incapable of saying that it ignored a value at this point. All parse attempts return success. Anyone trying to fix this better make sure that it does not regress startup, new window, and pageload....
Mass-reassigning bugs.
Assignee: jst → dom_bugs
*** This bug has been marked as a duplicate of 65469 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: