Adding and removing many style elements
in [JavaScript]
|
Prev: Cujo 1.4 review
Next: Obfuscated code
From: Thomas 'PointedEars' Lahn on 6 May 2010 19:59 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. You referred to CSS 2.1, but it was specified so in CSS 2, too. Apparently I have overlooked/misunderstood that part of the section all the time. Thank you. > It's not all clear to me how this is supposed to interact with ECMAScript > DOM implementations. Interact? PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: David Mark on 6 May 2010 20:43 Thomas 'PointedEars' Lahn 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. > > You referred to CSS 2.1, but it was specified so in CSS 2, too. Apparently > I have overlooked/misunderstood that part of the section all the time. > Thank you. > I had my suspicions but confess to never bothering to look it up. It just seemed crazy to me that such a strategy would not work (regardless of what the specs said about it). That and the fact that at least a hundred different browsers had worked fine with it over the years seemed to confirm at least an ad hoc standard. Glad it's a "real" one after all! :) I just used it again in the last hour. It seems the perfect (and perhaps intended) way to override scripted style changes (usually visibility or display) in print media.
From: Scott Sauyet on 7 May 2010 08:40 David Mark wrote: > Scott Sauyet wrote: >> 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. I was clearly doing something else wrong. I haven't tried to get a minimal test case as the requirements have changed on this and I went with an entirely different solution. Somehow or another, though, even "!important" print rules didn't seem to override the scripted ones. We'll see if I find time to figure out why, because I know I've used them before too. Since well before I was heavily involved with JS, I've been a strong advocate for CSS, and I believe I know pretty well what to expect. I'm still not sure why it didn't work in this case, but I'm willing to bet it's a stupid error on my part. > 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. That's what the spec says and what I believe generally works. Damn, I'm going to have to create that test case anyway! :-( Thanks for the responses, -- Scott
From: Scott Sauyet on 7 May 2010 09:42 Thomas 'PointedEars' Lahn wrote: > 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. Feel free to un-ask the question yourself, but I personally still find it an interesting idea to research. >>> ISTM you can lose the wrapper-DIV, see <http://PointedEars.de/es-matrix>. >> [ ... ] >> 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. For me, in FF3.6.3, the TBODY is scrolling properly, and if I call scroller.toggleScroll(true); from the console it toggles as expected, but the button is not visible. In other recent browsers I've tested the TBODY does not scroll. And if I try making that call from IE8's console it returns true, but also reports some error and does not change the scroll behavior. >> [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. Maybe not, but it was the effect I was interested in and not the implementation. I can't see any likely accessibility problems with it, but it is Google, so who knows? >>>> 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? I don't resize the table below a certain size. > What if client-side DOM scripting is unavailable or insufficiently > supported? Then the size of the table will not be adjusted. It will still be visible. But that's simply out of habit. The system I'm taking over gets all it's data through AJAX calls and displays it through DOM manipulation. The page will not function at all with JavaScript disabled. I disagree with this design, and will argue for change, but that's pretty low down my list of things that need to be changed. >> 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. Maybe not, but I think anything that would do this with straight CSS would involve a significant change in page markup. It might be doable, but it doesn't seem straightforward. All this might be a case, though, of my knowing that nothing will work without client scripting enabled and hence viewing such script as an all-purpose hammer. I'll think about it some more. >>>> 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? Yes, if I can do so without entirely reworking the pages. >> 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. That's easy to do if there is no fixed-size header. I'm not so sure how to do it as it stands. But that's off-topic in cljs. In any case, thank you very much for the advice. -- Scott
From: Thomas 'PointedEars' Lahn on 7 May 2010 17:22
Scott Sauyet wrote: > Thomas 'PointedEars' Lahn wrote: >> Scott Sauyet wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> ISTM you can lose the wrapper-DIV, see >>>> <http://PointedEars.de/es-matrix>. >>> [ ... ] >>> 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. > > For me, in FF3.6.3, the TBODY is scrolling properly, and if I call > > scroller.toggleScroll(true); > > from the console it toggles as expected, but the button is not > visible. Confirmed. It works locally, though, so probably there is a remote library version mismatch (I am currently updating those manually, while the Matrix files get updated automatically via SVN commit). I'll look into it. > In other recent browsers I've tested the TBODY does not > scroll. Works as designed, I suppose. > And if I try making that call from IE8's console it returns true, but > also reports some error and does not change the scroll behavior. No error message in Wine IE 6. Before I need to switch to Windows: With cleaned cache, what exactly is the error reported, please? >>> 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. > > Maybe not, but I think anything that would do this with straight CSS > would involve a significant change in page markup. It might be > doable, but it doesn't seem straightforward. I am 96% sure that the markup does not need significant change, if at all. >>> 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. > > That's easy to do if there is no fixed-size header. I don't see why that would be relevant. > I'm not so sure how to do it as it stands. But that's off-topic in cljs. ACK > In any case, thank you very much for the advice. You are welcome. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk> |