> In fact, display: inline-block is already supported by Mozilla if you use the > vendor prefix: display: -moz-inline-block
>From my little experience with -moz-inline-block I've found it to be buggy at best, mostly because the reflow algorithm's employed by gecko needed to be changed at a fundamental level to support that kind of behaviour. In fact, MDC <http://developer.mozilla.org/en/docs/ Mozilla_CSS_Extensions#display> even admits this: >Mozilla also accepts -moz-* values for certain CSS2 and CSS2.1 values of the >display property that it does not yet support correctly (or at all): > * -moz-inline-block And as I said, firefox 3 has a huge improvement to their reflow which will allow for non-buggy inline-block. > I just made the experience that scripting on top of an invalid DOM causes > more problems than trying to be compliant I know the troubles of invalid DOM, and in this instance I agree that there should be no reason to add a fieldset into a hyperlink element (beyond that "it works"), but there are instances where an "invalid" DOM has real practical advantages. The two I can think of right now are nested forms and style tags inside noscript tags. The first allows for a full form to be posted en masse through the parent form but also allows posting of the child forms to independent urls which handle the smaller forms more directly (and save time and bandwidth by not posting unnecessary form fields). (Nested forms are also necessary if working in ASP.NET and avoiding the postback system for one reason or another). The second is a simple and elegant way of hiding things you wanted to be shown for javascript behaviour, or vice versa. Anyways, enough standards ranting. -blair On Aug 14, 9:18 am, Klaus Hartl <[EMAIL PROTECTED]> wrote: > Blair Mitchelmore wrote: > > If inline-block worked cross-browser, we wouldn't have the floating > > hell we have today. inline-block is not supported by firefox, and > > won't be until firefox 3 is released. > > > And I'm not defending non-standard html (even though sometimes, the > > standards are overly restrictive for no real reason) but I was trying > > to duplicate an already existing behaviour and the only way to do it > > was with non-standard html. But my real point was that javascript > > generated html has no real incentive to be valid as it never gets > > tested by validators and it works. > > > -blair > > I just made the experience that scripting on top of an invalid DOM > causes more problems than trying to be compliant, no matter how the HTML > is generated. > > If it's compliant you'll have at least some reliability otherwise not at > all. > > I also just wanted to improve what you provided instead of rambling > about it. I apologize. > > In fact, display: inline-block is already supported by Mozilla if you > use the vendor prefix: display: -moz-inline-block > > A script could use that like: > > $(...).css({ display: 'inline-block', display: '-moz-inline-block' }) > > Browsers other than Mozilla should ignore the second unknown value and > apply the first declaration, whereas Mozilla will apply the second one. > > --Klaus
