Adding and removing many style elements
in [JavaScript]
|
Prev: Cujo 1.4 review
Next: Obfuscated code
From: Sean Kinsey on 6 May 2010 15:57 On May 6, 9:21 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > Scott Sauyet wrote: .... > Here's some pseudo-code: > > // CSS > fixed {position: fixed, top: 0} > > // JS to run when page is loaded > (function() { > var > table = // getEBI("myTable"), > top = // get top offset of table > thead = // get thead of table > thead.style.left = // get left offset of table; > setInterval(function() { > if (getScrollHeight() >= top) { > addClass(thead, "fixed"); > } else { > removeClass(thead, "fixed"); > } > }, 50); > }()); > > Thanks, everyone for your contributions! > > [1]http://livingstories.googlelabs.com/lsps/DCSchoolReform > Ouch! Using an interval to change the class? Maybe you should try the resize event instead? What if the addClass adds without checking if the class is already added? I'm guessing that might cause some browser to redraw on each interval..
From: Scott Sauyet on 6 May 2010 16:24 Sean Kinsey wrote: > On May 6, 9:21 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > >> // CSS> > fixed {position: fixed, top: 0} > >> // JS to run when page is loaded >> (function() { >> var >> table = // getEBI("myTable"), >> top = // get top offset of table >> thead = // get thead of table >> thead.style.left = // get left offset of table; >> setInterval(function() { >> if (getScrollHeight() >= top) { >> addClass(thead, "fixed"); >> } else { >> removeClass(thead, "fixed"); >> } >> }, 50); >> }()); > > Ouch! Using an interval to change the class? Maybe you should try the > resize event instead? No, I probably induced some confusion here by discussing multiple different solutions to this problem. This one has nothing to do with re-sizes. This solution essentially works by changing the CSS on the THEAD to "position:fixed, top:0" when the top of the table is scrolled out of view and to default behavior when it's scrolled back in. I'm doing it in a polling interval because I don't know of an event to capture for the scroll of the body. There might be one for Firefox, but I hadn't checked yet since by the time I had this working, I found out about the requirements change. > What if the addClass adds without checking if the class is already > added? I'm guessing that might cause some browser to redraw on each > interval.. The function addClass() works appropriately. It's not added if it's already there. But since we're talking about scrolling, there is already a redraw going on; that doesn't worry me. Do you know if there is a scroll event I can listen to? -- Scott
From: David Mark on 6 May 2010 17:11 Scott Sauyet wrote: > Thomas 'PointedEars' Lahn wrote: >> Scott Sauyet wrote: >>> Richard Cornford wrote: >>>> Although styles applied directly to an element have the highest >>>> specificity, and so override nearly everything else, you could >>>> try using CSS's - !important - rule modifier in the print style >>>> sheet. That has worked for me in similar situations. >>> I'm wondering if I simply didn't do this to everything that needed to >>> be done. I did try this, as that was the first thing to come to >>> mind. I'll go back and check it again. >> That approach is wrong, it is not supposed to work (reliably). > > Why is that? According to the CSS2 Spec [1], importance and origin > are of higher priority than than specificity. It's not all clear to > me how this is supposed to interact with ECMAScript DOM > implementations. > The !important trick, as described by Richard, works. I've used it for many years and though I don't know for sure if the original specs are in agreement, I've never encountered a browser that wasn't. If the specs say it won't work, they are long since irrelevant in the matter (i.e. an ad hoc standard trumps them now). Knowing your history is sometimes as (or more) important than knowing the specs. In short, if you hide something with inline style that you want to print, add an !important rule to your (static) print style sheet that un-hides it. No extra script needed.
From: David Mark on 6 May 2010 17:33 David Mark wrote: > Scott Sauyet wrote: >> Thomas 'PointedEars' Lahn wrote: >>> Scott Sauyet wrote: >>>> Richard Cornford wrote: >>>>> Although styles applied directly to an element have the highest >>>>> specificity, and so override nearly everything else, you could >>>>> try using CSS's - !important - rule modifier in the print style >>>>> sheet. That has worked for me in similar situations. >>>> I'm wondering if I simply didn't do this to everything that needed to >>>> be done. I did try this, as that was the first thing to come to >>>> mind. I'll go back and check it again. >>> That approach is wrong, it is not supposed to work (reliably). >> Why is that? According to the CSS2 Spec [1], importance and origin >> are of higher priority than than specificity. It's not all clear to >> me how this is supposed to interact with ECMAScript DOM >> implementations. >> > > The !important trick, as described by Richard, works. I've used it for > many years and though I don't know for sure if the original specs are in > agreement, I've never encountered a browser that wasn't. If the specs > say it won't work, they are long since irrelevant in the matter (i.e. an > ad hoc standard trumps them now). Knowing your history is sometimes as > (or more) important than knowing the specs. > And I should add, it would be really stupid (not to mention inconvenient as hell) if this did _not_ work (and the browser developers clearly know this).
From: Thomas 'PointedEars' Lahn on 6 May 2010 19:24
Scott Sauyet wrote: > Thomas 'PointedEars' Lahn wrote: >> Scott Sauyet wrote: >>> Does anyone have experience with adding and removing a large number of >>> style elements? >> Mu. > > No, really, even if this technique turns out to be unnecessary to > fixing my problem, I'm curious as to whether others have done this, > and if so what obstacles there are to it. "Mu" is the correct answer here. It is unnecessary (and unwise) to "add and remove a large number of style elements" (client-side, programmatically); not only with regard to your problem. >>> [...] >>> For a small intranet app (no more than a few dozen users, targeting >>> Firefox, but would like to have it work in IE7/8 as well) that I'm >>> starting to modify, one requirement is that the main tables that are >>> the only substantial content on several pages need to keep the headers >>> visible when the user scrolls. I've done this several times with no >>> issues by wrapping the table in some fixed-height div with overflow >>> hidden and then making the TBODY have overflow-x hidden, overflow-y >>> auto, and with a height somewhat smaller than the wrapper div. >> ISTM you can lose the wrapper-DIV, see <http://PointedEars.de/es-matrix>. > > Perhaps. But it was already there and being used for other purposes, > so I wasn't worried. > > That's one of the places I looked right away. I seem to remember that > you until recently had a button to toggle whether the table scrolled > or the body did. You remember correctly. > Am I imagining that? No, given the same user agent it should still be there. However, in contrast to previous revisions it remains hidden (display: none) when and while activating it would not have an effect. > I was hoping that this button simply altered class names to switch which > styles applied. It does add/remove/modify the `class' attribute of the TBODY element with ID `scroller'. See printScrollButton() in table.js for details. > If that worked, I assumed I could simply put one in my print-only > stylesheet and the other one on screen media. But I don't see that button > any more. I didn't chase it down further. Either you did not use a user agent that supports sizeable TBODYs (which includes Firefox/Iceweasel 3.6.3) or something is wrong with my feature- testing that. > [Google's Living Stories] An example of this is at > > http://livingstories.googlelabs.com/lsps/DCSchoolReform Perhaps I am looking into this later, but I really do not expect too much of client-side Google applications at this point with regard to code quality and accessibility. >>> Since this is the only substantive content on the page, I also run a >>> script on re-size to adjust the height of the TBODY and the wrapper DIV. >> That does not sound like an idea being thought through. > > Can you explain why? I'll ask two good questions by contrast to yours: What if the window is too small? What if client-side DOM scripting is unavailable or insufficiently supported? > As I said, outside the logo and similar chrome, this table is the only > content on the page. The table starts as a fixed height table, but it > re-sizes to mostly fill the page on start-up and when the viewport is > re-sized. You don't need scripting for that, then. >>> So what I'm thinking of doing on re-size is to simply replace or >>> overwrite a STYLE element that determines the heights of those >>> elements. >> You do not need to do this. > > Perhaps not. I'm trying other techniques, [...] Like the straightforward one, CSS? > and double-checking the ones that Sean and Richard suggested. But I > really do want this table to mostly fill the viewport. ISTM CSS can readily provide this. >>> I know the techniques to do this, but I'm wondering if this >>> is asking for trouble. >> >> An interface to do that (implemented as document.styleSheets) already >> exists, so ... > > ... I'm not asking for trouble? > > I know the document.styleSheets interface (or "interfaces" given how > differently it's implemented in MSIE) and I might use it or might see > if this could be done with simple DOM manipulations. But at this > point, I think this will only happen if other techniques fail. I have no idea what you are talking about here. You want to modify a property in a stylesheet. Use document.styleSheets to do that, then, that is what it is there for. > Still I'm curious as to how viable a technique it might be. If I have > some time when I get this project done, I'd be curious to really dig > into it. No, you wouldn't. PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.) |