Fixed top row in a table
in [CSS]
|
Prev: Float elements break block elemens - why?
Next: paypal wholesale all brand(UGGBOOTS,SHOES,CLOTHES,HANDBAG,WATCH,JEANS,JERSEY,T-SHIRT,SHIRTS,HOODY,EYEGLASS,CAP,SHAWL,WALLT) and so on
From: Thomas 'PointedEars' Lahn on 4 Mar 2010 12:35 Jonathan N. Little wrote: > Thomas 'PointedEars' Lahn wrote: >> Jonathan N. Little wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> Thomas 'PointedEars' Lahn wrote: >>>>> The following tweak is recommended: >>>>> >>>>> <!--[if IE 7]> >>>>> <style type="text/css"> >>>>> /* IE 7: Support for scrollable tbody is buggy */ >>>>> >>>>> table>tbody.static { >>>> >>>> table.static>tbody { >>>> >>>> in this example. I have it differently in the ES Matrix because I >>>> want the user to be able to toggle scrollability if sufficient script >>>> support is present, and I mostly keep the style for the THEAD. >>> >>> IMO the proprietary conditional comments is a bad idea. Defeats the >>> purpose of separating markup from stylesheets and JavaScript with >>> external files. Change you style and you now editing /n/ pages instead >>> of *one* stylesheet. MS takes another stab at making a 2.1 compliant >>> browser and ditto to updating those /n/ pages with a new fork in the >>> comments. No thanks. Play the graceful degrade for *inferior* >>> browsers... >> >> What are you babbling about? The Conditional Comments are the only >> means to handle *this* quirk of *this* MSHTML version reliably. > > Okay let's try it again. > > If you have a website with 50 pages. On those 50 pages you have a link > to an external stylesheet. And if you have done you markup with > foresight and efficiency then to change the styling of all 50 pages of > the site would require a change to only *one* document--the stylesheet. (A stylesheet is not a document.) Relevant tweaks can be put into external stylesheet resources as well, of course. It has been done before: <!--[if IE 7]> <link rel="stylesheet" href="ie7.css" type="text/css"> <![endif]--> I did not do it in the ES Support Matrix because a single rule for in a single HTML document does not justify another stylesheet resource. Since there is going to be a DOM Support Matrix using much the same style, I will probably move it to an external stylesheet as indicated above. > Also, the stylesheet is optional and your site should be still > accessible if a bit less "pretty" without. If a browser does not support > a CSS property it should degrade "gracefully". That principle is still met here. > Now, add the MS's Conditional Comments to "fix" your pages. Conditional > Comments are added to the HTML document and not the stylesheet, so style > changes could result in 50 page edits. But that is unlikely as rules applying to 50 documents would be moved to a stylesheet resource to begin with. > Yes, you could use the comments to load a "fix_lousy_ie.css" stylesheet > to help mitigate the problem. No, I would load (and have been loading) a fix_lousy_ie7.css stylesheet to help mitigate the problem (although named differently), where the resource name would indicate its purpose and field of application, as usual. > However IE slow and painful progress towards supporting CSS v2.1 has not > always been linear. I found one IE7 specific peekaboo bug not present in > versions before or after. So that bug of that particular version would only be addressed when the Conditional Comment is parsed by the parser of that version. Your problem being? > And although the W3 is as slow as MS, version > 2.1 is not the endpoint. CSS will continue to evolve so with MS's > propensity to progress like a tired two-year-old being dragged through > the grocery store, how many forks would be needed to your Conditional > Comments? None. Each new version would get its own fixing stylesheet as version- specific issues are identified, or if quirks would be detected to exist among several versions, stylesheets that are included if and only if the version range fits. If a new version would not require the fix, it would not include it, automatically. Your problem being? > Again resulting in 50 page edits! That assumes incorrectly that all markup documents would use all features of all CSS versions. Historically there have been zero edits to address issues corresponding with an event as you describe. Because the problem is _not_ that a new CSS level introduces problems with display in older versions of MSHTML but that features already specified in lower CSS levels introduce problems with newer versions of MSHTML when they start supporting that level. But if necessary so, that would be only either one edit of the relevant stylesheet file, or two edits on stylesheet files and one search-and replace operation over only the relevant markup files; several edits no doubt, but requiring as little effort. Certainly it would require less effort than the proposed alternatives. > So in *my option* because of complexity Conditional Comments can add to > the maintenance of a website, my conclusion is that Conditional Comments > is a bad idea. I am afraid your _opinion_ (typo there) is based on flawed reasoning, which in turn is based on a misconception about how Conditional Comments work, what they would allow, and what their proposed alternatives would allow. PointedEars
From: Nick Theodorakis on 4 Mar 2010 13:24 On Mar 3, 9:33 pm, "Jonathan N. Little" <lws4...(a)gmail.com> wrote: [...] > > Well a simple Gecko only css solution is to set a fixed height and > overflow properties on the TBODY element. I was messing around with applying overflow to <tbody> once, and wondering why it only worked on Gecko. I wasn't surprised to see it fail on IE, but it was curious to me that it didn't work on other browsers (Opera, Chrome, or Safari), either. I found this page: <http://www.gtalbot.org/BrowserBugsSection/MSIE6Bugs/ MSIE6BugTbodyOverflowAuto.html> which claims: "This bug turns out to be INVALID. From the beginning, I assumed that overflow could apply to table-row-group objects (like <tbody>) but the overflow property, as defined by CSS 2.1 specification, section 11.1.1, does not apply to table-row-group objects." The CSS2.1 reference states: "'overflow' .... Applies to: non-replaced block-level elements, table cells, and inline- block elements " Is this an accurate observation that the overflow property does not apply to <tbody>? That would be a shame, because it would be a great way to visually display long <tbody>s, but perhaps this explains the poor support for it. OTOH, the CSS checker at w3.org doesn't complain about it. Any thoughts? Nick -- Nick Theodorakis nick_theodorakis(a)hotmail.com contact form: http://theodorakis.net/contact.html
From: BootNic on 4 Mar 2010 13:34 On Thu, 04 Mar 2010 17:56:58 +0100 Thomas 'PointedEars' Lahn <PointedEars(a)web.de> wrote: > BootNic wrote: > >> Thomas 'PointedEars' Lahn <PointedEars(a)web.de> wrote: >>> Jonathan N. Little wrote: >>>> IMO the proprietary conditional comments is a bad idea. Defeats >>>> the purpose of separating markup from stylesheets and JavaScript >>>> with external files. Change you style and you now editing /n/ >>>> pages instead of *one* stylesheet. MS takes another stab at >>>> making a 2.1 compliant browser and ditto to updating those /n/ >>>> pages with a new fork in the comments. No thanks. Play the >>>> graceful degrade for *inferior* browsers... >>> >>> What are you babbling about? The Conditional Comments are the only >>> means to handle *this* quirk of *this* MSHTML version reliably. >> >> Interesting! Well I suppose it may be a perspective issue. >> >> :root table.static tbody {â¦} > > By comparison, CSS hacks like this are definitely going to do > something unintended once the corresponding selector is supported by > an implementation, regardless whether the feature declared with it is > going to be supported. They completely fail to address the issue. CSS hack? What makes this a CSS hack? An example of "something unintended" would be appreciated. There is no "They", there is one rule. This rule totally address this issue, "*this* quirk of *this* MSHTML version". It makes no since to trigger an issue then fix it when it can simply be avoided. -- BootNic Thu Mar 4, 2010 01:34 pm When I was younger, I could remember anything, whether it had happened or not. *Mark Twain* â 130 days remaining
From: David Stone on 4 Mar 2010 13:38 In article <doraymeRidThis-877371.04323405032010(a)news.albasani.net>, dorayme <doraymeRidThis(a)optusnet.com.au> wrote: > In article > <no.email-B3842E.09373204032010(a)news1.chem.utoronto.ca>, > David Stone <no.email(a)domain.invalid> wrote: > > > In article <doraymeRidThis-371DE6.13531504032010(a)news.albasani.net>, > > dorayme <doraymeRidThis(a)optusnet.com.au> wrote: > > > > > In article <4b8f138a$0$22130$742ec2ed(a)news.sonic.net>, > > > "S.T." <anon(a)anon.com> wrote: > > > > > > > I have a table with a substantial number of rows and need to keep the > > > > top row fixed/static (so that row is always visible when scrolling). > > > > Googling gives some answers but they *all* seem rather complicated -- > > > > most utilizing javascript -- apparently to make the technique work in > > > > IE. > > > > > > > > In this case I don't care whether it works on IE or not -- is there a > > > > simpler CSS/HTML method that will work for the latest version of > > > > Firefox, and if so any hints on what to look for like some > > > > -moz-whatever: rule I'm not aware of? > > > > > > > > Thanks > > > > > > You could look at something like: > > > > > > <http://www.imaputz.com/cssStuff/bigFourVersion.html> > > > > > > Works in a variety of Mac browsers. Not sure about Windows. > > > > dorayme, > > > > I thought you had posted something before that would > > do the job? The bookmark I _thought_ referred to the example > > was http://dorayme.890m.com/alt/pseudoFrames.html, but this > > no longer appears to be valid. Do you still have your > > pseudoFrames.html somewhere? (Chances are it's not what I > > thought it was but, if I bookmarked it, there must have been > > a good reason!) > > I recall that not being about tables... That "free server" went > downhill when I forgot to operate on it for a while ... but the > page seems to be at > > <http://dorayme.netweaver.com.au/alt/pseudoFrames.html> Ah, that was what I was thinking of. As you said, not about tables, but it was something I wanted to remember! > > and perhaps renamed from > > <http://dorayme.netweaver.com.au/alt/positionFixed.html> > > which latter has siblings: > > <http://dorayme.netweaver.com.au/alt/positionFixed2.html> > <http://dorayme.netweaver.com.au/alt/positionFixed3.html> Could that last one be modified to keep the footer in view at all times also? > ( > Wonder why OP or the two guys engaged in the pissing competition > in this thread don't instead talk about the link I gave before > <http://www.imaputz.com/cssStuff/bigFourVersion.html> Who knows? Looks good to me, although the hacks to accommodate IE in the CSS make me a little bit wary. Maybe they didn't like all the absolute px sizing? > Doesn't > anyone want to talk to me any more? Is it too many jokes, too > many Jewish jokes? To misquote the Coffee Crisp commercial "They don't know from jokes!" > Did I mention that I invented a joke the other day? It came in > blinding insight when I was making breakfast: > > "Last night I held a party that was so wild, I called the police > myself" > ) Hate to say this, but I've seen that joke before. Must be one of those "meme" things... (Hmm, isn't that a bit like a mumu?)
From: Thomas 'PointedEars' Lahn on 4 Mar 2010 15:13
BootNic wrote: > Thomas 'PointedEars' Lahn <PointedEars(a)web.de> wrote: >> BootNic wrote: >>> Thomas 'PointedEars' Lahn <PointedEars(a)web.de> wrote: >>>> Jonathan N. Little wrote: >>>>> IMO the proprietary conditional comments is a bad idea. Defeats >>>>> the purpose of separating markup from stylesheets and JavaScript >>>>> with external files. Change you style and you now editing /n/ >>>>> pages instead of *one* stylesheet. MS takes another stab at >>>>> making a 2.1 compliant browser and ditto to updating those /n/ >>>>> pages with a new fork in the comments. No thanks. Play the >>>>> graceful degrade for *inferior* browsers... >>>> >>>> What are you babbling about? The Conditional Comments are the only >>>> means to handle *this* quirk of *this* MSHTML version reliably. >>> >>> Interesting! Well I suppose it may be a perspective issue. >>> >>> :root table.static tbody {…} >> >> By comparison, CSS hacks like this are definitely going to do >> something unintended once the corresponding selector is supported by >> an implementation, regardless whether the feature declared with it is >> going to be supported. They completely fail to address the issue. > > CSS hack? What makes this a CSS hack? A syntax element of CSS (CSS 3 Selectors PR, to be precise) is used to prevent a rule from being applied to one or more elements in user agents that do not support that syntax element. > An example of "something unintended" would be appreciated. You are the one to use this selector as a counter-argument, you provide that example. Suffice it for me to say that if a user agent supports this selector, the property declarations of it are supposed to be applied. However, *again*, the property declarations have nothing to do with the support of the selector, those are *seperate* issues. And that is the very problem with this approach, that is what makes it evidentially (sic!) error-prone. > There is no "They", there is one rule. This rule totally address this > issue, "*this* quirk of *this* MSHTML version". Most certainly it doesn't. This rule is either ignored by the MSHTML version is intended for and all previous versions, or it is supported by the MSHTML version it is intended for and all newer versions. By contrast to Conditional Comments, it does _not_ and can _not_ target only _one_ specific version. > It makes no since to trigger an issue then fix it when it can simply be > avoided. Parse error. PointedEars |