| Home | Forums | Reviews | Guides | Newsgroups | Register | Search |
 |
| Thread Tools |
|
Guest
Posts: n/a
|
Determining default style properties
I know that one can use JS to determine various properties of the DOM. E.g., suppose one has: <p id='qwe' style="color:green">filler</p> then something= document.getElementById("qwe").style.color returns 'green'. But if one has <style> .setcolor {color  ink} </style><p id='qwe' class='setcolor'>filler</p> something= document.getElementById("qwe").style.color gets an empty string rather that the set color of 'pink'. Similarly, one does not get any information about the browser's default setting or any other setting given indirectly. I have tried going up a level with document.getElementById("qwe").parentNode.style.co lor but that does not help. Nor does using document.getElementById("qwe")getAttribute("style" ) do any better in FireFox and in IE it just returns [object] Surely that information must be there for the browser use it. Is it accessible in any practical way? One could, of course, set everything at the topmost level of <body> but that would override the user's default settings which is most undesirable (and rude). TIA |
|
|
|
|||
|
|
| |
|
Guest
Posts: n/a
|
On Jan 19, 10:28*am, Dr_KralNOS...@nyc.rr.com wrote:
> Determining default style properties > > But if one has > * <style> *.setcolor {color ink} *</style>> * <p id='qwe' class='setcolor'>filler</p> > something= document.getElementById("qwe").style.color > gets an empty string rather that the set color of 'pink'. As happens so often in browser scripting, there are competing ways of doing this. The W3C-defined method is getComputedStyle specified here: http://www.w3.org/TR/DOM-Level-2-Sty...tComputedStyle and explained better here: https://developer.mozilla.org/en/DOM...tComputedStyle Internet Explorer has the property currentStyle which is documented here: http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx There are plenty of examples (of varying degrees of correctness and efficiency!) online describing how you might combine these two into your own function. -- Scott |
|
|
|
|
|||
|
|
| |
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
On Jan 19, 11:07 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
> On Jan 19, 10:28 am, Dr_KralNOS...@nyc.rr.com wrote: > > > Determining default style properties > > > But if one has > > <style> .setcolor {color ink} </style>> > <p id='qwe' class='setcolor'>filler</p> > > something= document.getElementById("qwe").style.color > > gets an empty string rather that the set color of 'pink'. > > As happens so often in browser scripting, there are competing ways of > doing this. The W3C-defined method is > > getComputedStyle > > specified here: > > http://www.w3.org/TR/DOM-Level-2-Sty...view-getComput... > > and explained better here: > > https://developer.mozilla.org/en/DOM...tComputedStyle > > Internet Explorer has the property > > currentStyle > > which is documented here: > > http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx > > There are plenty of examples (of varying degrees of correctness and > efficiency!) online describing how you might combine these two into > your own function. > More like there are ten tons of bad examples. Where's one good article (or example?) It's non-trivial to write a solid getComputedStyle wrapper, even when limited to dealing with a handful of styles (and apps should be designed with that in mind). So if your design dictates a comprehensive cross-browser getComputedStyle wrapper, change the design as it's a hard way to go. |
|
|
|
|
|||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
On Jan 20, 10:08 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
> On Jan 20, 7:50 am, David Mark <dmark.cins...@gmail.com> wrote: > > > On Jan 19, 11:07 am, Scott Sauyet <scott.sau...@gmail.com> wrote: > >> On Jan 19, 10:28 am, Dr_KralNOS...@nyc.rr.com wrote: > >>> Determining default style properties > > >> getComputedStyle > >> currentStyle > > >> There are plenty of examples (of varying degrees of correctness and > >> efficiency!) online describing how you might combine these two into > >> your own function. > > > More like there are ten tons of bad examples. Where's one good > > article (or example?) It's non-trivial to write a solid > > getComputedStyle wrapper, even when limited to dealing with a handful > > of styles (and apps should be designed with that in mind). > > This is true. If anything, it's an understatement. Agreed. > > A few things you will probably have to keep in mind: > > - "opacity" is expressed in some places as a decimal, others as a > percentage, and it is handled very differently in IE than in most > other browsers. Yes, and among older non-IE browsers. But this is not specific to computing styles (just inherent to style in general). > > - "float" will require special handling (search for "cssFloat" and > "styleFloat"). Yes. > > - inheritable properties may require you to walk up the DOM to > find them defined. Right, among other calculations (some impossible) that would be required convert a "cascaded" style to proper computed value. It's one of those things that is half-assed in the "standard" libraries. Some make no distinction between them at all (and no comments or documentation to indicate the shortcomings). > > - You have to decide how to handle children of elements with > "display: none" that themselves have some other display value. There's nothing to decide. See the CSS specs.  > > - You'll have to deal with the difference in name formats between > JS and CSS: "backgroundColor" vs "background-color". Perhaps. It makes for a friendlier interface for beginners used to reading CSS, but not JS. I've never bothered with it at all. > > And that is probably just the tip of the iceberg. Pretty much. The computing of styles to compensate for IE's shortcomings is a major can of worms. That's why it is best to identify what you need out of a wrapper like this before you design it. If, for example, left and top will always be in pixels, you know you can get left and top reliably in cross-browser fashion (for browsers that support getComputedStyle or IE). Set the inline styles to pixel-based values and you can support the browsers that predate getComputedStyle. Context and simplicity are everything with this stuff, which is why outlandish, complex, half-assed error-prone nightmare scripts (that must be swapped out in their entirety every six months) are the opposite of a good idea. Yes, there are a lot of people out there who have yet to have this epiphany. It's coming.  > > > So if your design dictates a comprehensive cross-browser > > getComputedStyle wrapper, change the design as it's a hard way to go. > > If on the other hand, you have only a limited number of properties you > need to support, it may not be too bad. > Exactly. |
|
|
|
|
|||
|
Guest
Posts: n/a
|
On Jan 20, 10:25*am, David Mark <dmark.cins...@gmail.com> wrote:
> On Jan 20, 10:08 am, Scott Sauyet <scott.sau...@gmail.com> wrote: >> [ ... much agreement deleted ... ] >> * * - You have to decide how to handle children of elements with >> "display: none" that themselves have some other display value. > > There's nothing to decide. *See the CSS specs. * I don't think the CSS specs can determine how getComputedStyle or the OP's own wrapper should behave. Each time I've written such a wrapper, I've reported "none" for <p style="display:none"><a id="myLink">something</a> more</p> ... var myLink = document.getElementById("myLink"); alert(myGetComputedStyleWrapper(myLink, "display")); even though the underlying functions might report "inline". This has been useful behavior for my own applications. That's what I meant by deciding how to handle it. -- Scott |
|
|
|
|
|||
|
Guest
Posts: n/a
|
On Jan 20, 11:35 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
> On Jan 20, 10:25 am, David Mark <dmark.cins...@gmail.com> wrote: > > > On Jan 20, 10:08 am, Scott Sauyet <scott.sau...@gmail.com> wrote: > >> [ ... much agreement deleted ... ] > >> - You have to decide how to handle children of elements with > >> "display: none" that themselves have some other display value. > > > There's nothing to decide. See the CSS specs. > > I don't think the CSS specs can determine how getComputedStyle or the > OP's own wrapper should behave. Not the wrapper, but the inheritance rules are clearly defined in the specs. But you would have to move up to the DOM specs to get the specific recommendations for getComputedStyle. > > Each time I've written such a wrapper, I've reported "none" for > > <p style="display:none"><a id="myLink">something</a> more</p> > ... > var myLink = document.getElementById("myLink"); > alert(myGetComputedStyleWrapper(myLink, "display")); > > even though the underlying functions might report "inline". The computed style is "none." That's in the specs. IE wouldreport "inline" as it doesn't compute styles. > This has > been useful behavior for my own applications. That's what I meant by > deciding how to handle it. > Sure, you could decide to not worry about descendants of elements with display:none style. That's certainly do-able for most (if not all) designs. |
|
|
|
|
|||
|
Guest
Posts: n/a
|
On Jan 20, 11:49*am, David Mark <dmark.cins...@gmail.com> wrote:
> On Jan 20, 11:35 am, Scott Sauyet <scott.sau...@gmail.com> wrote: >> Each time I've written such a wrapper, I've reported "none" for >> >> * * <p style="display:none"><a id="myLink">something</a> more</p> >> * * ... >> * * var myLink = document.getElementById("myLink"); >> * * alert(myGetComputedStyleWrapper(myLink, "display")); >> >> even though the underlying functions might report "inline". > > The computed style is "none." *That's in the specs. * I don't think so. There are slightly mixed signals http://www.w3.org/TR/1998/REC-CSS2/v...ropdef-display display { inherited: no } So children don't inherit "display: none" from their parents. However the same section says display: block ============== | This value causes an element to not appear in the formatting | structure (i.e., in visual media the element generates no boxes and | has no effect on layout). Descendant elements do not generate any | boxes either; the element and its content are removed from the | formatting structure entirely. This behavior cannot be overridden by | setting the 'display' property on the descendants. And this is why I like to report them as "display: none", it's not technically accurate, but it's generally more practical. > IE would report "inline" as it doesn't compute styles. So does every other browser I've tested. Not that I've gone to great lengths to test this, mind. -- Scott |
|
|
|
|
|||
|
Guest
Posts: n/a
|
On Jan 20, 12:20 pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
> On Jan 20, 11:49 am, David Mark <dmark.cins...@gmail.com> wrote: > > > On Jan 20, 11:35 am, Scott Sauyet <scott.sau...@gmail.com> wrote: > >> Each time I've written such a wrapper, I've reported "none" for > > >> <p style="display:none"><a id="myLink">something</a> more</p> > >> ... > >> var myLink = document.getElementById("myLink"); > >> alert(myGetComputedStyleWrapper(myLink, "display")); > > >> even though the underlying functions might report "inline". > > > The computed style is "none." That's in the specs. > > I don't think so. There are slightly mixed signals > > http://www.w3.org/TR/1998/REC-CSS2/v...ropdef-display > > display { inherited: no } > > So children don't inherit "display: none" from their parents. That's correct. But when you _compute_ the display style, you have to take the ancestors into account. > However > the same section says > > display: block > ============== > | This value causes an element to not appear in the formatting > | structure (i.e., in visual media the element generates no boxes and > | has no effect on layout). Descendant elements do not generate any > | boxes either; the element and its content are removed from the > | formatting structure entirely. This behavior cannot be overridden > by > | setting the 'display' property on the descendants. > > And this is why I like to report them as "display: none", it's not > technically accurate, but it's generally more practical. It is accurate if the computed display style is what you are after. > > > IE would report "inline" as it doesn't compute styles. > > So does every other browser I've tested. Not that I've gone to great > lengths to test this, mind. > What browsers (aside from IE) have you tested that reported "inline" for the anchor? |
|
|
|
|
|||
|
|
| |
|
| Thread Tools | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Determining Host Default Route Based Upon IP Address | Brian Mac | Ruby | 0 | 04-01-2008 07:02 PM |
| Determining the Default Printer | David C. Barber | ASP .Net | 5 | 11-25-2007 11:04 AM |
| Determining an operating system's default browser | John McMonagle | Python | 11 | 02-12-2006 10:10 PM |
| Making Custom Control Properties Visible in Visual Studio's Properties Palette | Nathan Sokalski | ASP .Net | 0 | 10-17-2005 02:05 AM |
| Need help with Style conversion from Style object to Style key/value collection. | Ken Varn | ASP .Net Building Controls | 0 | 04-26-2004 07:06 PM |
