Last Comment Bug 9458 - (inline-block) Implement inline-block in layout
(inline-block)
: Implement inline-block in layout
Status: RESOLVED FIXED
[A2][patch]
: css2, css3, dev-doc-complete, testcase
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: All All
: P1 major with 137 votes (vote)
: mozilla1.9alpha8
Assigned To: David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
: Hixie (not reading bugmail)
Mentors:
http://www.w3.org/TR/2004/CR-CSS21-20...
: 118711 204010 217675 298384 299276 302637 304681 327658 377003 421193 (view as bug list)
Depends on: 16515 reflow-refactor 337426 349477 367332 367504 369547 371249 373625 398144 398797 421397 427638 504092 505706
Blocks: 184155 219873 18217 61902 163504 361352 367247
  Show dependency treegraph
 
Reported: 1999-07-08 15:25 PDT by sujay
Modified: 2014-04-26 03:08 PDT (History)
127 users (show)
dbaron: blocking1.6b-
asa: blocking1.8b2-
mconnor: blocking‑aviary1.5-
pavlov: blocking1.9+
dbaron: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase for showing inline-block and moz-inline-block behaviour (1017 bytes, text/html)
2003-11-18 15:04 PST, Matthew Mastracci
no flags Details
Testcase for showing inline-block and moz-inline-block behaviour (1.42 KB, text/html)
2003-11-19 01:49 PST, Erik Arvidsson
no flags Details
"hack" to implement inline-block w/<button> (Mozilla-only) (1.79 KB, text/html)
2003-11-19 08:56 PST, Matthew Mastracci
no flags Details
Another test case that shows a possible hack using -moz-inline-box containing a block element (2.05 KB, text/html)
2003-11-19 12:13 PST, Erik Arvidsson
no flags Details
inline-block XBL hack (569 bytes, text/xml)
2003-11-19 12:58 PST, Matthew Mastracci
no flags Details
HTML that uses previous XBL hackery to fix inline-block (545 bytes, text/html)
2003-11-19 13:00 PST, Matthew Mastracci
no flags Details
test case (267 bytes, text/html)
2004-08-19 05:42 PDT, Anne (:annevk)
no flags Details
Javascript test for inline-block (1.31 KB, text/html)
2006-02-17 21:29 PST, compufly
no flags Details
patch v0.1 (12.56 KB, patch)
2006-12-11 14:53 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review
patch (work in progress) (28.51 KB, patch)
2006-12-12 16:26 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review
vertical alignment testcase (911 bytes, text/html; charset=UTF-8)
2006-12-20 16:42 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details
patch (work in progress) (21.88 KB, patch)
2007-01-18 19:43 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review
patch (work in progress) (23.63 KB, patch)
2007-01-18 23:15 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review
patch (40.23 KB, patch)
2007-01-19 14:06 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
bzbarsky: review+
bzbarsky: superreview+
Details | Diff | Review
testcase for inline-block width (202 bytes, text/html)
2007-10-25 05:43 PDT, Eugen Konkov
no flags Details

Description sujay 1999-07-08 15:25:30 PDT
using 7/8 build of apprunner

1) launch apprunner
2) launch editor
3) insert anchor

anchor icon doesn't get inserted.

all platforms
Comment 1 Charles Manske 1999-07-08 16:21:59 PDT
I've already tried all kinds of CSS tricks to do this and have discussed it
with Peter, so I think it's best to just hand the bug to him.
For background, here's most of our last exchange:
Charles Manske wrote:
I can't seem to morph the "A" tag into something visible by any of your
suggestions. Here's what I settled on for "proof of concept"  testing, even
though it's not inline (this is in mozilla/editor/ui/composer/skin/Editor.css):
  a[name][href=""] {
    display: list-item;
    list-style-image: url(chrome://editor/skin/images/ED_Left.gif);
    list-style-position: inside;
    line-height: 10px;
    min-width: 10px;
  }
  Peter Linss wrote:

    Firstly, to make it apply to only <A> tags with the name attribute use:
"a[name]" for your selector (if you want to exclude hrefs that also
    have names, use: "a[name][href=""]").

    Charles Manske wrote:

     In the editor, we want to show a named anchor as a small image. To explore
this, I tried the following CSS:
     a {
       display: inline;
       width: 10px;
       height: 10px;
       border: 1px solid blue;
     }
    Inlines have special rules about respecting width and height, in short,
height doesn't work (use line-height) instead. I'm not sure about if
    width will work when the element is empty, you might try 'min-width'.
     or:
     a {
       display: list-item;
       list-style-image: url(chrome://editor/skin/images/ED_Left.gif);
     }
    This probably should work You should add 'list-style-position: inside' to
keep the image from appearing outside the element's margin.
    But again, I'm not sure if empty list-items get bullets... Also, display:
list-item will create a block level frame, I presume you really want an
    inline
     or:
     a {
       display: table; // or inline-table;
       background-image: url(chrome://editor/skin/images/ED_Left.gif);
     }

    This will probably only work in "standard mode", in "quirk mode" tables
don't draw backgrounds (it gets shoved into the cell). I'm also not
    sure if inline-table is working, but that's what you really want.

    I think what you really want is a bit of CSS3 that hasn't been implemented
yet (but I think we're going to have to real soon).
    a[name][href=""] {
      display: inline-block;    /* the new feature */
      width: 10px;
      height: 10px;
      background-image: url(...);
      border: 1px solid blue;
    }
Comment 2 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 1999-07-21 13:40:59 PDT
One problem is that width doesn't apply to inline elements, so attempts to force
it will fail.  I see two solutions:

* wait for inline-block or inline-table
* use :before or :after and get joki to fix bug 5886 if you need it (i.e., check
in the fix attached to the bug)

And does [href=""] select elements without an href attribute?  I don't think it
should.

So I would think:

a[name]:before {
  content: url(....gif);
  border: 2px solid blue;
  }

a[name][href]:before {
  content: "";
  border: none;
  }

would be closer to what you want.  Also, since a elements with a name attribute
still enclose text, you probably want that text to still be visible, so I think
:before is a good choice.  (Note, however, that :before is really a first child,
not a previous sibling, so the style applied to the a applies to the :before.)
However, what if the document already has a :before pseudo-element for
anchors...?
Comment 3 Charles Manske 1999-07-21 17:54:59 PDT
I applied the patch for bug 5886. Using ":before" does indeed display an
image like we want. BUT it won't work because we don't allow selecting
generated content. The whole purpose of making the anchor visible is to allow
the user to click on it (thus selecting it) so they can delete it, copy
it, or bring up the property dialog for it.
Comment 4 Peter Linss 1999-07-28 14:18:59 PDT
inline-block is in the style system. Waiting for Nisheeth and/or Troy to hook it
up to layout.
Comment 5 Nisheeth Ranjan 1999-07-28 17:39:59 PDT
Accepting bug and setting target milestone to M9...
Comment 6 Nisheeth Ranjan 1999-08-10 15:03:59 PDT
Kipp has certain questions about the semantics of inline-block that he wants to
discuss with Peter once he gets back from the W3C CSS working group meeting.
We'll scope this out more for M10...
Comment 7 Nisheeth Ranjan 1999-08-27 23:08:59 PDT
Updating summary and setting milestone to M11.  I need to work on this when I
get back from vacation.
Comment 8 Hixie (not reading bugmail) 1999-09-05 14:23:59 PDT
[Adding a radar... Hmm, first time I've put in a {css3} radar...]
Comment 9 Matthew Tuck [:CodeMachine] 1999-09-05 17:58:59 PDT
Is it really a good idea to be implementing a draft standard?  How close is CSS3
to proposed standard status?
Comment 10 Charles Manske 1999-09-21 12:18:59 PDT
Adding Akkana to cc.
Comment 11 Akkana Peck 1999-09-21 12:21:59 PDT
The named anchor tag currently in the editor init page looks very bad on Linux
-- it draws on top of some of the text on that line and the next line.  Charley
says it doesn't do that on Windows, and that perhaps this has something to do
with the style not being fully implemented yet.  When working on this bug, it
might be useful to look at the named anchor in the editor init page on several
platforms and compare their presentations.
Comment 12 Peter Linss 1999-09-21 12:32:59 PDT
The style code is 100% cross platform, so the linux issue in not likely that.
Perhaps a font metrics issue?
Comment 13 Akkana Peck 1999-09-21 14:58:59 PDT
I've split the Linux rendering issue off into bug 14474.
Comment 14 Nisheeth Ranjan 1999-09-23 14:28:59 PDT
Charley, is this a beta blocker for you guys?  I'm moving it out to the M12
milestone for now...
Comment 15 Charles Manske 1999-09-23 14:51:59 PDT
We must solve the problem of displaying something for normally hidden elements
like Named Anchor, and there doesn't seem to be any other CSS way of doing that
*inline*, so I guess the answer is yes unless it is a lot of work.
Comment 16 Hixie (not reading bugmail) 1999-09-23 15:31:59 PDT
Having reread the comments above, I don't really see how inline-block _will_
help, actually. I think David's use of generated content is probably best; why
can we not select generated content?

Alternatively, use this:
   a[name] { padding-left: 20px; background: url(...gif) 5px 50% no-repeat; }
There are some issues with 'background-position' on inline elements, though.
(I will split them off into another bug.)
Comment 17 Charles Manske 1999-10-15 10:06:59 PDT
Adding dependency to 16515 -- selection of generated content in the editor.
If we can't solve that bug, then we may need the inline-block CSS attribute to
represent hidden elements in the editor.
Comment 18 Nisheeth Ranjan 1999-12-01 15:44:59 PST
Move non-PDT+ bugs to M13...
Comment 19 Nisheeth Ranjan 2000-01-14 11:13:59 PST
Moving non-blockers for beta to M15...
Comment 20 Nisheeth Ranjan 2000-03-28 16:34:39 PST
Just got word from charley that he is no longer blocked by this.  Moving off to 
M20.
Comment 21 Nisheeth Ranjan 2000-06-08 16:30:40 PDT
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration. 
Comment 22 Matthias Kerkhoff 2000-07-15 13:18:41 PDT
I also ran into this. The problem is, that without inline-block, it's impossible 
to generate an inline element that has a certain (specified) width. As Mozilla 
supports other CSS3 properties, the question if or if not supporting CSS3 seems 
to be answered in the meantime. 
From my opinion there are two possible workarounds which should allow setting a 
predefined width: inline-table (which does not work) or using a table and 
setting the col-widths to the desired values (it's such an ugly workaround ...). 
I would like to hear, if there are other solutions, which I may have missed.
Comment 23 Hixie (not reading bugmail) 2000-07-25 20:43:31 PDT
As per meeting with ChrisD today, taking QA.
Comment 24 Daniel Steinberger 2002-07-07 17:19:19 PDT
*** Bug 118711 has been marked as a duplicate of this bug. ***
Comment 25 Daniel Steinberger 2002-07-07 17:40:31 PDT
i've read (bug 3935, comment 108: ...I did disable 'inline-block' and
'inline-table'...) that we once had an implementation of this display style.
where there problems with that? if not, why was it removed?

IE (at least v6) does support 'display: inline-block' and i find it a very
elegant way for some design-ideas (though i wouldn't use it, unil it's supported
by some real browsers :-). i do know that this property is only in the cc3-wd,
so i've read it over and found that imho IE's implementation seems correct. and
i guess that it's not very hard to implement. 

i've also notived that there is a '-moz-inline-block' property that simply seems
to act like 'block' but does not honor the 'display-role: inline; display-model:
block-inside;' stuff.


the question is simply: are you going to wait till there is some css3-box-model
last call for comments or later, or is this just because of resource-shortage?
(last comment before: 2000-07-25)
Comment 26 Hixie (not reading bugmail) 2002-07-08 06:37:47 PDT
resource shortage.

What used to be display:inline-block; is not display:-moz-inline-block; so you
can determine for yourself how badly broken it is (very).
Comment 27 Erik Arvidsson 2002-09-02 06:06:58 PDT
CSS2.1 includes inline-block

inline-block is also needed for lots of form elements. These are today marked as
inline which is obviously incorrect since inline elements cannot have any width.

Increasing priority...
Comment 28 Hixie (not reading bugmail) 2002-09-10 11:54:09 PDT
Form elements are "replaced elements" and CSS 2.1 doesn't say what to do with them.
Comment 29 Samuel Sieb 2003-01-20 21:45:38 PST
Hixie, you wrote: "What used to be display:inline-block; is not
display:-moz-inline-block;", should "not" be "now"?

Reassigning to a better component.
Comment 30 Boris Zbarsky [:bz] (Out June 25-July 6) 2003-04-30 20:38:08 PDT
*** Bug 204010 has been marked as a duplicate of this bug. ***
Comment 31 Bryn Dyment 2003-06-29 16:35:31 PDT
Unless I misunderstand, inline-block allows you to nest block-level elements 
within, for example, a span.  The span continues to be displayed inline, but 
its contents are treated as a block-level "black box" that doesn't affect how 
the span is rendered (ie., you can imbed block-level constructs, such as UL).  
An example of a clean solution that would be very difficult without "inline-
block": http://www.bigtrouble.com/inline_block_1.htm (multiple columns, "shrink 
wrapped widths", centered horizontally).
Comment 32 Bryn Dyment 2003-06-29 16:36:47 PDT
(Sorry, try above link in IE6+, or Opera 7+)
Comment 33 Boris Zbarsky [:bz] (Out June 25-July 6) 2003-08-28 21:08:36 PDT
*** Bug 217675 has been marked as a duplicate of this bug. ***
Comment 34 Matthew Mastracci 2003-11-18 15:04:11 PST
Created attachment 135852 [details]
Testcase for showing inline-block and moz-inline-block behaviour

This test-case shows the inline-block (and -moz-inline-block) behaviour.  I
couldn't find a good test anywhere within Bugzilla, so I thought I'd place it
here for others to use.

BTW- any ideas on how to "fake" this behaviour using XBL?  I would imagine that
there's an element somewhere within Mozilla that affects layout like the <img>
tag, but can contain arbitrary HTML markup.
Comment 35 Erik Arvidsson 2003-11-19 01:49:26 PST
Created attachment 135898 [details]
Testcase for showing inline-block and moz-inline-block behaviour

Adding a <br> inside the inline blocks to make it clearer. Also made sure that
the document validates to HTML 4.01 Strict
Comment 36 Matthew Mastracci 2003-11-19 08:56:06 PST
Created attachment 135929 [details]
"hack" to implement inline-block w/<button> (Mozilla-only)

Thanks for the testcase update!  I've found a hacky (but virtually
indistiguishable) way to implement inline-block: use a <button>.  The <button>
tag is an arbitrary HTML container.  With the following CSS styles, the
"button"-esque nature of the element is removed, leaving an unstyled,
inline-block HTML element.  

Might there be a way to use the button rendering code to render <button> tags,
inline-blocks and inline-tables?  AFAIK, these should render with the same
layout rules.  Perhaps Hixie might know if this is a valid assumption.

button.E
{
	width: 100pt;
	border: 1px solid black;
	background: inherit;
	font: inherit;
	color: inherit;
	vertical-align: bottom;
}

See my new attachment for a demonstration of how this looks.  The only issue is
that the text within the <button> is unselectable.
Comment 37 Erik Arvidsson 2003-11-19 12:13:41 PST
Created attachment 135942 [details]
Another test case that shows a possible hack using -moz-inline-box containing a block element

I modified the test case again to use a hack that I found on the net. I already
lost the URI and it is not included in my Firebird history :'( The hack uses a
-moz-inline-box containing a block element. I guess this is basically what
button is doing.

Although one can achieve the desired layout using this technique it is really
not possible to use XBL to solve this problem. This really needs to be
supported natively in the layout engine.
Comment 38 Matthew Mastracci 2003-11-19 12:58:23 PST
Created attachment 135946 [details]
inline-block XBL hack
Comment 39 Matthew Mastracci 2003-11-19 13:00:23 PST
Created attachment 135947 [details]
HTML that uses previous XBL hackery to fix inline-block

Using previously mentioned -moz-inline-box w/ block XBL hack.  Uses the XBL
from the previous attachment.
Comment 40 Erik Arvidsson 2003-11-19 13:15:31 PST
Using XBL and doing workarounds might be fun but this will not solve the real
issues here:

1. Will not support DOM Level 2 CSS
2. Not compatible with CSS2


I think I've done enough spamming of this bug so I'll keep quite now.
Comment 41 Simon Fraser 2004-03-25 11:57:46 PST
It would be great if mozilla supported this. Opera does, Safari does, and hyatt
sez that WinIE does.
Comment 43 Doug Wright 2004-08-19 05:32:10 PDT
This is valid CSS that we don't support and IE of all things does. Please?
Comment 44 Anne (:annevk) 2004-08-19 05:42:07 PDT
Created attachment 156506 [details]
test case

Test case to show that only Opera has some native support for
'display:inline-block'.

Please don't spam this bug any futher with useless comments.
Comment 45 Doug Wright 2004-08-19 06:01:49 PDT
I was basing my remark about IE on the tests in comments #31 and #35, as well as
comment #25 - none of which anyone has repudiated. If these tests are wrong then
I apologise, if not I stand by my comment.
Comment 46 LPB 2004-10-26 20:09:58 PDT
It would be nice to have support for inline-block - not only to call Firefox a
standards-compliant browser (it does not comply with CSS2.1), but also because
using handfuls of table cells etc. to do formatting is getting old.
Comment 47 Alexander Presber 2004-10-27 03:15:07 PDT
Could somebody with enough knowledge about the core.layout part of the gecko engine point the rest 
of us to a document or something, that exlains the difficulty with implementing display:inline-block?

Aren't there already some elements that behave so similar (button, fieldset), that a proper 
implementation of display:inline-block seems achievable?
Comment 48 Andres C. Rodriguez 2004-11-17 23:18:33 PST
Please fix this bug, it's crucial for web apps and it works (almost) perfectly
in IE (no support in DIVs, yes support in SPAN and A).  If we want
Firefox/Mozilla to deliver on its promise this bug should not be allowed to be
alive for 5 years.
Comment 50 Justin 2004-12-20 09:12:03 PST
I think this bug needs to be changed from enchantment to normal. Firefox is
supposed to support CSS2.1 for starters. And this is also a CSS attribute that
would be very useful because it's implementation would reduce the need to use
hackish techniques such as using the float attribute to create tabbed interfaces
and other similar items.
Comment 51 Magnus Kristiansen 2005-03-01 15:20:56 PST
As much as I enjoy using this bug to knock haughty firefox fanatics down a few 
pegs, I would much rather be able to use inline-block while coding. How about 
a status report, if nothing else?
Comment 52 Ben Basson 2005-03-06 17:44:57 PST
Can anyone comment if this is fixable in the Firefox 1.1 timeframe? We have a
load of other new CSS features, and probably over two months for regression
checking. This is my only main gripe with Firefox/Mozilla's current level of CSS
support. The hackarounds necessary are up there with the solutions for some of
IE's hideous CSS problems.
Comment 53 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-03-06 18:01:36 PST
It's not (correctly, at least).
Comment 54 Justin 2005-03-06 21:58:13 PST
I know nothing of the layout engine, but I still think this should be an easy
fix. An image is similar to a block element, as in, it's not text. Yet images
are already in-line by default and behave according to the specs.
Is treating a block element really that much more different than an image? Is it
to do with size calculation?
Comment 55 Steve England [:stevee] 2005-04-11 11:05:58 PDT
Asa Dotzler <asa@mozilla.org> has denied Steve England
<steve.england@gmail.com>'s request for blocking1.8b2: Bug 9458: Implement
inline-block in layout. 9th April 2005. I guess re-requesting blocking isn't
going to achieve anything.
Comment 56 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-04-14 01:16:08 PDT
Note to self (on the off chance that I'll ever even see it in between all the
comments on this bug that don't belong here):

In addition to being careful about shrink wrapping (which is the main reason
this hasn't been done yet), we also need to be careful about getting z-ordering
right (NS_FRAME_PAINT_LAYER_* stuff).  See http://www.w3.org/TR/CSS21/zindex.html .
Comment 57 Peter van der Woude [:Peter6] 2005-06-21 13:15:46 PDT
*** Bug 298384 has been marked as a duplicate of this bug. ***
Comment 58 Elmar Ludwig 2005-06-30 12:00:32 PDT
*** Bug 299276 has been marked as a duplicate of this bug. ***
Comment 59 Mike Connor [:mconnor] 2005-07-11 11:10:21 PDT
see comment 53, not fixable in this timeframe, moving on
Comment 60 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-07-17 00:33:48 PDT
*** Bug 301072 has been marked as a duplicate of this bug. ***
Comment 61 José Jeria 2005-07-29 07:39:16 PDT
*** Bug 302637 has been marked as a duplicate of this bug. ***
Comment 62 Ric Hardacre 2005-08-09 06:39:20 PDT
just faked a tabulation class using the -moz-inline-box hack thus

span.tab
{
		display: -moz-inline-box;
		display: inline-block;
		width:	150px;
}

in html

<span class="tab">zeroth tab</span><spn class="tab">first tab</span><spn
class="tab">second tab</span>

works fine in opera,netscape,ie5,ie6 and firefox. though i havent attempted a 
pixel matching test, nor do i plan to. otherwise surely if there's a class that
emulates it already all you have to do is a string replace!?
Comment 63 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-08-09 09:13:34 PDT
-moz-inline-box is very different from inline-block.  -moz-inline-block is more
similar and less likely to cause problems in the future.
Comment 64 Justin 2005-08-09 11:23:58 PDT
If you do a pixel matching test, you will find that just using a width is not
possible. In terms of height, padding, wrapping etc. spans behave much
differently to blocks. I've already tried using spans with padding etc. to
simulate in-line blocks, but have always found problems in different browsers.
Comment 65 Ric Hardacre 2005-08-10 04:00:50 PDT
(In reply to comment #63)
> -moz-inline-box is very different from inline-block.  -moz-inline-block is more
> similar and less likely to cause problems in the future.

tried -block but it inserts a carriage return after it, ergo: not inline

Comment 66 Uri Bernstein (Google) 2005-08-15 10:25:41 PDT
*** Bug 304681 has been marked as a duplicate of this bug. ***
Comment 67 spagmoid 2005-12-02 04:48:32 PST
For god's sake, please fix this NOW!  This bug actually has fan sites.  Firefox is notorious as being the ONE BROWSER unable to perform this simple function.
http://www.bigtrouble.com/inline_block.htm
Comment 68 Arpad Borsos [:Swatinem] 2005-12-02 07:11:28 PST
Since this is the single most important RFE this should realy be checked in ASAP...
AFAIK this bug is dependent on the reflow changes dbaron is working on since more than a year, which is not quite ready, right?
But it sounds better to throw in a 80% finished patch and let a majority of people sqeeze out the last 20% of bugs generated by the patch instead of letting one single man complete this patch to 95% before checkin, which could take another year...
Anyone wants to give this bug a blocking1.9a1+ ?
just my 2 cents... and please dont burn me alive for moaning so much :D
Comment 69 Zibi Braniecki [:gandalf][:zibi] 2005-12-02 07:19:28 PST
(In reply to comment #68)
> Since this is the single most important RFE this should realy be checked in
> ASAP...

In Open Source communities, such demands sound rude. Please, consider never again writing them.

> Anyone wants to give this bug a blocking1.9a1+ ?

I doubt so. There is no patch nor any developer agreed to track the task. Dbaron said he don't know how long it'll take him, and if you think you can handle, go on, write down your proposal, with patches if possible.

> just my 2 cents...

If not, consider making a better use of your 2 cents, without rude demands and absolutely useless comments like those two above. This bug, like any other is not the place where people can share their frustrations and describe the reasons for why they so much want the bug to be fixed. Thank you for not replaing in this bug anymore if you don't have a patch proposal or other value to add. (my email is public if you want to discuss this comment)
Comment 70 Ryan VanderMeulen [:RyanVM] 2005-12-02 07:21:14 PST
Guys, keep the advocacy out of this thread. It's clearly on the developer's radar, so adding more "Fix this bug now!" posts to it just increases the signal to noise ratio and makes it harder to find useful information in the discussion (which is the point of Bugzilla). Take the advocacy to Mozillazine. I'm also going to request that you guys please read the Bugzilla etiquitte page.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

That being said, since the next official build coming off the current trunk is looking to be version 3.0, it seems to me that we've got time to get this fixed correctly on the trunk. I'm sure David will create the necessary patch as soon as he feels it's ready and fairly regression-free. Now can we please leave discussion in this thread to useful posts only?
Comment 71 Neil Deakin 2006-02-17 14:43:15 PST
*** Bug 327658 has been marked as a duplicate of this bug. ***
Comment 72 compufly 2006-02-17 21:29:07 PST
Created attachment 212291 [details]
Javascript test for inline-block
Comment 73 compufly 2006-02-17 21:33:55 PST
Comment on attachment 212291 [details]
Javascript test for inline-block

The prompt is supposed to show the content of "display" in Firefox
Working fine in MSIE 6 if you want a reference of what I'm trying to do...
Comment 74 compufly 2006-02-17 21:34:31 PST
Comment on attachment 212291 [details]
Javascript test for inline-block

The prompt is supposed to show the content of "display" in Firefox
Working fine in MSIE 6 if you want a reference of what I'm trying to do...
Comment 75 Gérard Talbot 2006-02-18 07:27:30 PST
> The prompt is supposed to show the content of "display" in Firefox
> Working fine in MSIE 6 if you want a reference of what I'm trying to do...

var divns6 = document.getElementsByTagName('tr');

getElementsByTagName: Returns a NodeList (...)
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-A6C9094

"The items in the NodeList are accessible via an integral index, starting from 0."
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-536297177

prompt(divns6[nObjet].style.display); 

Your testcase is not correct. Besides, this bugfile has a testcase and is about implementing inline-block.
Comment 76 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2006-12-11 14:50:46 PST
So one of my main concerns was shrink-wrapping, which is now fixed thanks to bug 300030.  Also, one of the frame construction issues I was worried about was filed as bug 337426 and is now fixed on the trunk.  I still need to look into comment 56.

With all this whining about how we absolutely must implement inline-block, I assume there's already a comprehensive test suite for it.  Could somebody point me to the URL so we don't have to spend a few days duplicating the effort that went into writing it?

A comprehensive test suite would cover:
 * dynamic changes to/from inline-block, to content inside of them, etc.
 * interaction with other properties (z-ordering)
 * putting various things inside of it
 * shrink-wrapping
 * any other conformance statements in CSS 2.1
and would generally be written as closely as possible to the CSS2.1 test suite authoring guidelines.

(And I really need the same for inline-table.)
Comment 77 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2006-12-11 14:53:43 PST
Created attachment 248305 [details] [diff] [review]
patch v0.1
Comment 78 Bruno Girin 2006-12-11 15:15:49 PST
(In reply to comment #76)
> With all this whining about how we absolutely must implement inline-block, I
> assume there's already a comprehensive test suite for it.  Could somebody point
> me to the URL so we don't have to spend a few days duplicating the effort that
> went into writing it?

Not quite a test suite but have a look at this article on alistapart: http://www.alistapart.com/articles/prettyaccessibleforms/ that gives you a good example of how it can be used and what it should do. Also, it comes with a piece of Javascript to tweak the DOM and fix the problem in Firefox so that may give you an idea of how to solve it.
Comment 79 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2006-12-11 15:23:10 PST
So I definitely don't need to add support for -moz-inline-table, since that was actually a parse error before; I just need to add support for inline-table, which is what the next version of the patch will have.

I'm not sure whether I want to keep support for -moz-inline-block in addition to inline-block; authors who are using -moz-inline-block should generally be using inline-block as well, for other browsers, and we're better off encouraging those who aren't doing so already to do so.  So my inclination is to drop support for -moz-inline-block when adding support for inline-block.  (Good practice when using -moz-inline-block has always been "display:-moz-inline-block;display:inline-block".)
Comment 80 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2006-12-12 15:06:56 PST
And it looks like nsIFrame::BuildDisplayListForChild should already handle the stacking context stuff correctly.
Comment 81 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2006-12-12 16:26:05 PST
Created attachment 248456 [details] [diff] [review]
patch (work in progress)

This is the current state of my patch and tests.  Note that 6 of the tests fail:
 * 9458-width-1a fails because the shrink-wrapping behavior is actually incorrect, since I added aAvailableWidth to nsIFrame::ComputeSize
 * the 5 9458-zorder-* tests fail because of a vertical positioning issue that I need to figure out

I haven't started testing inline-table yet, but it needs the 9458-* tests copied, plus perhaps some additional tests of anonymous box construction (although we already have one, from bug 360065.
Comment 82 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2006-12-20 16:42:20 PST
Created attachment 249318 [details]
vertical alignment testcase
Comment 83 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-01-18 19:43:59 PST
Created attachment 252006 [details] [diff] [review]
patch (work in progress)
Comment 84 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-01-18 23:15:38 PST
Created attachment 252022 [details] [diff] [review]
patch (work in progress)

This has the tests fixed.  There's still one actual failure, and that's in one of the width tests.  I think we change "available width" during inline reflow in ways that we shouldn't, at least not for anything other than inlines and text.
Comment 85 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-01-19 14:06:59 PST
Created attachment 252099 [details] [diff] [review]
patch

This fixes the test failure by making the availableWidth munging in nsLineLayout happen only for true inlines, and also adds more tests.
Comment 86 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-01-25 22:21:00 PST
It's worth noting that this bug also now depends on bug 163504 and bug 367247, because I've put related bug fixes to inline-block and inline-table in to those patches along with the uses.
Comment 87 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-01-26 23:30:41 PST
Comment on attachment 252099 [details] [diff] [review]
patch

>diff -r 5df1530b6fe3 layout/base/nsCSSFrameConstructor.cpp
>@@ -6378,6 +6387,7 @@ nsCSSFrameConstructor::ConstructFrameByD
>   // XXX Ignore tables for the time being
>   if (aDisplay->IsBlockLevel() &&
>       aDisplay->mDisplay != NS_STYLE_DISPLAY_TABLE &&
>+      aDisplay->mDisplay != NS_STYLE_DISPLAY_INLINE_TABLE &&
>       aDisplay->IsScrollableOverflow() &&
>       !propagatedScrollToViewport) {
> 

Maybe that condition could be a method on nsStyleDisplay or something? E.g. part of IsScrollableOverflow()?

Followup bug if you agree.

Also a followup bug for all the NS_STYLE_DISPLAY_TABLE stuff in MathML code?  I don't know what behavior rbs wants for inline-table and all.

Do we need to add NS_STYLE_DISPLAY_INLINE_TABLE in the condition in PageBreakBefore()?  Then again, inline-table is not a block-level element, but I don't see where we restrict page-break to those...

>diff -r 5df1530b6fe3 layout/generic/nsFrame.cpp

>@@ -3773,6 +3773,7 @@ nsFrame::IsFrameTreeTooDeep(const nsHTML
>   // Absolute positioning causes |display->mDisplay| to be set to block,
>   // if needed.
>   return display->mDisplay == NS_STYLE_DISPLAY_BLOCK || 
>+         display->mDisplay == NS_STYLE_DISPLAY_INLINE_BLOCK || 
>          display->mDisplay == NS_STYLE_DISPLAY_LIST_ITEM ||
>          display->mDisplay == NS_STYLE_DISPLAY_TABLE_CELL;

Huh.  The function name in that "@@ .... @@" line is such a lie!

Should the condition here basically be something like IsBlockInside()?

That said, nsBlockFrame overrides this function, so what are the cases when we'll hit this code with a non-nsBlockFrame that has NS_STYLE_DISPLAY_INLINE_BLOCK?

> nsLineLayout.cpp

While I was looking at this stuff, it occurs to me that nsLineLayout::TreatFrameAsBlock should probably be a method on nsStyleDisplay...

I assume we want to make generated content kids of inline-block inline for now (that's what this patch does)?

I didn't review the tests in detail.  Let me know if you want me to.

r+sr=bzbarsky
Comment 88 Bill Gianopoulos [:WG9s] 2007-01-27 04:27:56 PST
I have been building with thei patch included for a bit now and noticed that the code in nsLineLayout needs some changed due to bug 367442.

mCOmputedWidth stuff.
Comment 89 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-01-27 09:34:28 PST
I already have that fixed in my tree; it was too minor to bother commenting or including a new patch.
Comment 90 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-01-27 09:36:40 PST
(though probably worth warning me about, so thanks)
Comment 91 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-01-27 10:14:04 PST
(In reply to comment #87)
> Do we need to add NS_STYLE_DISPLAY_INLINE_TABLE in the condition in
> PageBreakBefore()?  Then again, inline-table is not a block-level element, but
> I don't see where we restrict page-break to those...

We really should restrict it to block-level elements; if we don't, that's a bug.

But I did notice while looking into this that I should fix IsSpecialFrameReframe as follows:

-    childIsBlock = display->IsBlockLevel() || IsTableRelated(display->mDisplay, PR_TRUE);
+    childIsBlock = display->IsBlockLevel();

since anonymous table objects force an inline-table when they're within an inline (as does inline-table itself, which is IsTableRelated).

> >diff -r 5df1530b6fe3 layout/generic/nsFrame.cpp
> 
> >@@ -3773,6 +3773,7 @@ nsFrame::IsFrameTreeTooDeep(const nsHTML
> >   // Absolute positioning causes |display->mDisplay| to be set to block,
> >   // if needed.
> >   return display->mDisplay == NS_STYLE_DISPLAY_BLOCK || 
> >+         display->mDisplay == NS_STYLE_DISPLAY_INLINE_BLOCK || 
> >          display->mDisplay == NS_STYLE_DISPLAY_LIST_ITEM ||
> >          display->mDisplay == NS_STYLE_DISPLAY_TABLE_CELL;
> 
> Huh.  The function name in that "@@ .... @@" line is such a lie!
> 
> Should the condition here basically be something like IsBlockInside()?

Yeah, I should fix that once I land IsBlockInside in the next patch...

> That said, nsBlockFrame overrides this function, so what are the cases when
> we'll hit this code with a non-nsBlockFrame that has
> NS_STYLE_DISPLAY_INLINE_BLOCK?

Probably pretty low.  I suppose it should perhaps even just return PR_FALSE so that we don't say that something that can't be a containing block is one.

> > nsLineLayout.cpp
> 
> While I was looking at this stuff, it occurs to me that
> nsLineLayout::TreatFrameAsBlock should probably be a method on
> nsStyleDisplay...

I'm not so sure, since it has only one caller and doesn't seem generally useful (it's a rather odd combination).

> I assume we want to make generated content kids of inline-block inline for now
> (that's what this patch does)?

Hrm.  No, actually.  12.1 of CSS2.1 doesn't have those restrictions anymore, so we should at least allow block inside inline-block.  I'll fix that (in nsRuleNode::ComputeDisplayData).

> I didn't review the tests in detail.  Let me know if you want me to.

No need.
Comment 92 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-01-27 10:26:32 PST
(In reply to comment #91)
> (In reply to comment #87)
> > Should the condition here basically be something like IsBlockInside()?
> 
> Yeah, I should fix that once I land IsBlockInside in the next patch...
> 
> > That said, nsBlockFrame overrides this function, so what are the cases when
> > we'll hit this code with a non-nsBlockFrame that has
> > NS_STYLE_DISPLAY_INLINE_BLOCK?
> 
> Probably pretty low.  I suppose it should perhaps even just return PR_FALSE so
> that we don't say that something that can't be a containing block is one.

In the patch to bug 367247 I decided to make it do the latter -- just return PR_FALSE, and add an IsContainingBlock to nsTableCellFrame.
Comment 93 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-01-27 11:56:47 PST
(In reply to comment #92)
> In the patch to bug 367247 I decided to make it do the latter -- just return
> PR_FALSE, and add an IsContainingBlock to nsTableCellFrame.

I had to back the nsFrame part of that out due to orange; probably need to add overrides on nsViewportFrame / nsHTMLFrame or something similar.
Comment 94 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-02-04 01:52:55 PST
> Yeah, I should fix that once I land IsBlockInside in the next patch...

Did this ever get a bug report?  And the MathML stuff?

Also, there's some code (or rather misleading comments) in ProcessInlineChildren() that we talked about going away:

12640     // recompute allKidsInline to take into account new child frames
12641     // XXX we DON'T do this yet because anonymous table children should

etc.
Comment 95 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-02-04 11:21:46 PST
Yeah, I haven't resolved this yet because I haven't had a chance to file all the necessary followup bugs.
Comment 96 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-02-23 15:57:18 PST
(In reply to comment #87)
> Followup bug if you agree.

Filed bug 371446.

> Also a followup bug for all the NS_STYLE_DISPLAY_TABLE stuff in MathML code?  I
> don't know what behavior rbs wants for inline-table and all.

Filed bug 371448.

> Do we need to add NS_STYLE_DISPLAY_INLINE_TABLE in the condition in
> PageBreakBefore()?  Then again, inline-table is not a block-level element, but
> I don't see where we restrict page-break to those...

Filed bug 371449.

> >@@ -3773,6 +3773,7 @@ nsFrame::IsFrameTreeTooDeep(const nsHTML
> >   // Absolute positioning causes |display->mDisplay| to be set to block,
> >   // if needed.
> >   return display->mDisplay == NS_STYLE_DISPLAY_BLOCK || 
> >+         display->mDisplay == NS_STYLE_DISPLAY_INLINE_BLOCK || 
> >          display->mDisplay == NS_STYLE_DISPLAY_LIST_ITEM ||
> >          display->mDisplay == NS_STYLE_DISPLAY_TABLE_CELL;
> 
> Huh.  The function name in that "@@ .... @@" line is such a lie!
> 
> Should the condition here basically be something like IsBlockInside()?

Filed bug 371450.

> That said, nsBlockFrame overrides this function, so what are the cases when
> we'll hit this code with a non-nsBlockFrame that has
> NS_STYLE_DISPLAY_INLINE_BLOCK?

Filed bug 371452.


Checked in to trunk on 2007-01-27.  Marking fixed.
Comment 97 philippe (part-time) 2007-04-10 05:14:45 PDT
*** Bug 377003 has been marked as a duplicate of this bug. ***
Comment 98 Eric Shepherd [:sheppy] 2007-09-25 09:41:26 PDT
This was documented a while ago.
Comment 99 Eugen Konkov 2007-10-25 05:43:46 PDT
Created attachment 286150 [details]
testcase for inline-block width
Comment 100 Eugen Konkov 2007-10-25 05:46:56 PDT
https://bugzilla.mozilla.org/show_bug.cgi?id=9458 MUST be reopened
Comment 101 Patrick Dark 2007-10-25 05:57:43 PDT
(In reply to comment #100)
> https://bugzilla.mozilla.org/show_bug.cgi?id=9458 MUST be reopened

Eugen, this bug is fixed in test builds of Firefox 3 (codenamed Gran Paradiso). Next time, you might want to test your attachment in the latest test release before disputing a “RESOLVED FIXED” status.

You might want to also use valid HTML in your attachments; your current attachment is invalid and triggers quirks mode.
Comment 102 Jonathan Watt [:jwatt] (Away Jun. 27 - Jul. 13) 2007-10-25 06:10:52 PDT
Eugen: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Comment 103 Eugen Konkov 2007-10-25 07:15:41 PDT
Jonathan. Will developers of FF leave FFv2.0 unfixed and apply only security patches to it?
Comment 104 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-10-25 07:25:17 PDT
Yes, the stable release is only getting security and stability patches.  It's not getting feature work (like this bug).
Comment 105 Smokey Ardisson (offline for a while; not following bugs - do not email) 2008-03-05 15:53:41 PST
*** Bug 421193 has been marked as a duplicate of this bug. ***
Comment 106 Jose Fandos 2008-03-13 13:41:24 PDT
Should it not be REOPENED, as it depends on two bugs still OPEN?
Comment 107 Tuukka Tolvanen (sp3000) 2008-03-13 14:33:43 PDT
No, bugs are not reopened for regressions.

Note You need to log in before you can comment on or make changes to this bug.