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: dorayme on 4 Mar 2010 16:23 In article <no.email-CE9093.13384204032010(a)news1.chem.utoronto.ca>, David Stone <no.email(a)domain.invalid> wrote: .... > > > 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? > I guess. Try on the footer: position: fixed; bottom: 0;left: 0; right: 0; and then maybe give the main a 1em bottom-margin > > "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. Who used my joke, when! <g> I would like an opportunity to argue before a judge that someone can pinch things from the future. I want my day in court on this matter! -- dorayme
From: Thomas 'PointedEars' Lahn on 4 Mar 2010 16:29 Nick Theodorakis wrote: > "Jonathan N. Little" 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>? I do not think so, because the author is apparently falsely assuming exclusive definitions. For a counter-example, though, sections 9.2.1 and 17.2 of CSS 2.1 CR make it clear that a "table" element is considered a special block-level element. ,-<http://www.w3.org/TR/2009/CR-CSS2-20090908> | | 9.2.1 Block-level elements and block boxes | | Block-level elements are those elements of the source document that are | formatted visually as blocks (e.g., paragraphs). Several values of the | 'display' property make an element block-level: 'block', 'list-item', and | 'run-in' (part of the time; see run-in boxes), and 'table'. | [...] | 17.2 The CSS table model | | [...] | table (In HTML: TABLE) | Specifies that an element defines a block-level table: it is a | rectangular block that participates in a block formatting context. There is no such definitive statement about the "element class" of "table-row-group" elements: | table-row-group (In HTML: TBODY) | Specifies that an element groups one or more rows. But the definition for block-level is inclusive with regard to the actual `display' property value, not exclusive. IMHO, the TBODY element, while being considered a table-row-group element (let it be noted, though, that a CSS Specification cannot define default HTML rendering), can reasonably be considered a non-replaced block-level element as well. If not by default, then by explicitly setting its `display' property value to one of that in the inclusion list (which as for `block' does not appear to have any negative effect to this feature in Gecko 1.9.1.8 [Iceweasel 3.5.8], where the default `display' property value is `table-row-group' indeed). I would rather CSS 2.1 would make a clearer statement about this, but then again it is not a REC yet. All that said, the pertinent Specification to check for would be CSS Level *3* because that is what Gecko claims to and appears to implement. Incidentally, the current CSS Level 3 Box Model WD extends the definition of block-level element/box accordingly:¹ ,-<http://www.w3.org/TR/2007/WD-css3-box-20070809/#block-level> | | A block-level box is a box that has a used value for 'display' of | 'block', 'list-item', 'table', 'table-*' (i.e., all table boxes) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | or <template>. This definition is then applied to specification of the `overflow-*' properties (which are more often used to provide this appearance) and the `overflow' property: ,-<http://www.w3.org/TR/2007/WD-css3-box-20070809/#overflow> | | Name: overflow-x, overflow-y | Value: visible | hidden | scroll | auto | no-display | | no-content | Initial: visible | Applies to: non-replaced block-level elements and non-replaced | 'inline-block' elements | Inherited: no | Percentages: N/A | Media: visual | Computed value: as specified, except 'visible', see text | | Name: overflow | Value: [ visible | hidden | scroll | auto | no-display | | no-content ]{1,2} | Initial: see individual properties | Applies to: non-replaced block-level elements and non-replaced | 'inline-block' elements | Inherited: no | Percentages: N/A | Media: visual | Computed value: as specified, except 'visible', see text ¹ History knows I avoid referring to Working Drafts for specified reasons, but since Gecko claims to implement CSS 3 features, and actually does so as described there in several instances, it would appear that I do not have a choice here. > 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. Perhaps. Only definitive statements from non-supporting vendors could clarify this. However, I find it more likely that they focus on other issues in their CSS implementations first. > OTOH, the CSS checker at w3.org doesn't complain about it. I do not think the W3C CSS _Validator_ checks for semantic errors. PointedEars P.S.: Your signature delimiter is borken.
From: S.T. on 4 Mar 2010 16:49 Thanks for the suggestions everyone. I ended up shifting gears in the layout a little and went for a fixed left column rather than top row, using the technique described at: http://stackoverflow.com/questions/1312236/how-do-i-create-an-html-table-with-fixed-frozen-left-column-and-scrollable-body Thanks again for the replies. Learned some things.
From: BootNic on 4 Mar 2010 17:13 On Thu, 04 Mar 2010 21:13:57 +0100 Thomas 'PointedEars' Lahn <PointedEars(a)web.de> wrote: > 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. Backwards thinking that is. It is used to apply not deny. >> 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. If this line of thinking is followed, no one would use any css3 at all. >> 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. If anything was targeted, it would be UAs that support :root. >> It makes no since to trigger an issue then fix it when it can >> simply be avoided. > > Parse error. The point is what? What is a UA to do when it cannot parse a selector? -- BootNic Thu Mar 4, 2010 05:13 pm There is no such thing as an underestimate of average intelligence. *Henry Adams* â 130 days remaining
From: Thomas 'PointedEars' Lahn on 4 Mar 2010 18:03
BootNic wrote: > Thomas 'PointedEars' Lahn <PointedEars(a)web.de> wrote: >> BootNic wrote: >>> Thomas 'PointedEars' Lahn <PointedEars(a)web.de> wrote: >>>> BootNic wrote: >>>>> Thomas 'PointedEars' Lahn <PointedEars(a)web.de> wrote: >>>>>> [...] 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. > > Backwards thinking that is. It is used to apply not deny. It was a reasonable assumption given that you used to to provide an argument against Conditional Comments and did not provide any property declarations, let alone explanations. >>> 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. > > If this line of thinking is followed, no one would use any css3 at all. Your logic is flawed. >>> 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. > > If anything was targeted, it would be UAs that support :root. Not necessarily. >>> It makes no since to trigger an issue then fix it when it can >>> simply be avoided. >> Parse error. > > The point is what? What is a UA to do when it cannot parse a selector? The point is that your statement does not make sense. PointedEars |