Adding and removing many style elements
in [JavaScript]
|
Prev: Cujo 1.4 review
Next: Obfuscated code
From: Thomas 'PointedEars' Lahn on 6 May 2010 11:41 Scott Sauyet wrote: > Sean Kinsey wrote: >> Set the height using css (hint 100%) and make sure that the parent >> containers do the same. No need to involve js at any step here. > > I tried that several times with no success. Perhaps I'm simply doing > it wrong. [...] Perhaps. The elements need to be positioned. Plain CSS is on-topic in ciwa.stylesheets. 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.)
From: Thomas 'PointedEars' Lahn on 6 May 2010 11:43 Scott Sauyet wrote: > Richard Cornford wrote: >> On May 6, 3:41 pm, Scott Sauyet wrote: >> <snip>> The problem is that they also print this page frequently. >>> With the fixed heights assigned to the elements' styles, >>> the printed version is cut short at that height. It's >>> easy enough in the print stylesheet to override the >>> relevant heights when they are assigned via a general >>> stylesheet, but not when the element itself has a height >>> assigned. >> >> 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). 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.)
From: Scott Sauyet on 6 May 2010 12:01 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. >> [...] >> 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. Am I imagining that? I was hoping that this button simply altered class names to switch which styles applied. 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. > Of course, the headers will not be fixed where a scrollable TBODY is not > supported either way; unless you use two tables, one for the headers and > one for the data, which would not be semantic. As a workaround, you can > repeat the headers when the TBODY is not scrollable; that is what I do. I've also played with adding a second table of headers via script that has "position:fixed", then hiding that one in the print stylesheet and hiding the normal one in the screen stylesheet. The trouble is the chrome that sits above the table. I don't have any real need to keep that there on scroll, but I would have to do so in a straightforward use of this technique. One possibility I really like is what Google's Living Stories does with a sidebar, namely to scroll it with the page until it meets the top of the viewport, then switch it to a fixed position as the rest of the page scrolls with it. I haven't looked at their implementation yet, but it might be the perfect UI for my users. An example of this is at http://livingstories.googlelabs.com/lsps/DCSchoolReform (The "Timeline of Important Events" sidebar is what I might want to emulate.) >> 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? 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. >> 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, and double-checking the ones that Sean and Richard suggested. But I really do want this table to mostly fill the viewport. >> 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. 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. Thanks for the response, -- Scott
From: Scott Sauyet on 6 May 2010 12:10 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. [1] http://www.w3.org/TR/CSS2/cascade.html#cascading-order -- Scott
From: Scott Sauyet on 6 May 2010 15:21
Scott Sauyet wrote: > I'm taking over the maintenance and enhancements of a small intranet > application. It has fewer than 50 users, all of whom usually use > Firefox for it. I would prefer that it also works in IE7/8, though. > Several pages have no significant content beyond a single large > table. On those pages, the users would like to have the headers > visible as they scroll the page. But they also want the standard > repeating header behavior when the page is printed. Ok, I managed to get a working solution, only to be told that, actually, the page they want printed should not have the scrolling headers! I love shifting requirements. :-) I reverted to my earlier solution for the page with the scrolling table body as they like that well and left the other one (which they will want to print) alone. But if anyone is curious, a technique something like the Google Living Stories [1] approach I discussed elsewhere in this thread is relatively simple to do and was working fine in my small test cases. 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 -- Scott |