Bug 1610992 Comment 5 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Thanks for taking a look! But no, it's not quite that simple.  `inline-flex` would kind of work, but it's fragile, because it means the links (now both inline-level) could end up side-by-side if they're skinny enough to fit. We'd be *depending* on the precise text content being a particular minimum width, in order to produce the expected layout.  (And in certain locales/languages/fonts, that may or may not be true.)

Here's a screenshot showing that -- I've used devtools to switch to `inline-flex` and I've shortened the text of the first link, swapping in [SNIP] for the second half of the sentence.

If you switch to `inline-flex` **and** add a `<br>` between the links, that'd avoid this potential issue, I think.  Or you could leave its `display` value as it currently stands and just give it a `width` as noted previously here, or do any of several other things.
Thanks for taking a look! But no, it's not quite that simple.  `inline-flex` would kind of work, but it's fragile, because it means the links (now both inline-level) could end up side-by-side if they're skinny enough to fit. We'd be *depending* on the precise text content being a particular minimum width, in order to produce the expected layout.  (And in certain locales/languages/fonts, it may or may not satisfy that minimum width.)

Here's a screenshot showing that -- I've used devtools to switch to `inline-flex` and I've shortened the text of the first link, swapping in [SNIP] for the second half of the sentence.

If you switch to `inline-flex` **and** add a `<br>` between the links, that'd avoid this potential issue, I think.  Or you could leave its `display` value as it currently stands and just give it a `width` as noted previously here, or do any of several other things.
Thanks for taking a look! But no, it's not quite that simple.  `inline-flex` would kind of work, but it's fragile, because it means the links (now both inline-level) could end up side-by-side if they're skinny enough to fit. We'd be *depending* on the precise text content being a particular minimum width, in order to produce the expected layout.  (And in certain locales/languages/fonts, it may or may not satisfy that minimum width.)

Here's a screenshot showing that possible broken-layout -- I've simply used devtools to switch the first `a` to have to `display:inline-flex` and I've shortened the text of the first link, swapping in [SNIP] for the second half of the sentence.  As you can see, the links then end up side-by-side instead of one above the other.

If you switch to `inline-flex` **and** add a `<br>` between the links, that'd avoid this potential issue, I think.  Or you could leave its `display` value as it currently stands and just give it a `width` as noted previously here, or do any of several other things.
Thanks for taking a look! But no, it's not quite that simple.  `inline-flex` would kind of work, but it's fragile, because it means the links (now both inline-level) could end up side-by-side if they're skinny enough to fit. We'd be *depending* on the precise text content being a particular minimum width, in order to produce the expected layout.  (And in certain locales/languages/fonts, it may or may not satisfy that minimum width.)

Here's a screenshot showing that possible broken-layout -- I've simply used devtools to switch the first `a` to have to `display:inline-flex` and I've shortened the text of the first link, swapping in [SNIP] for the second half of the sentence.  As you can see, the links then end up side-by-side instead of one above the other.

If you switch to `inline-flex` **and** add a br between the links, that'd avoid this potential issue, I think.  Or you could leave its `display` value as it currently stands and just give it a `width` as noted previously here, or do any of several other things.
Thanks for taking a look! But no, it's not quite that simple.  `inline-flex` would kind of work, but it's fragile, because it means the links (now both inline-level) could end up side-by-side if they're skinny enough to fit. We'd be *depending* on the precise text content being a particular minimum width, in order to produce the expected layout.  (And in certain locales/languages/fonts, it may or may not satisfy that minimum width.)

Here's a screenshot showing that possible broken-layout -- I've simply used devtools to switch the first `a` to have to `display:inline-flex` and I've shortened the text of the first link, swapping in [SNIP] for the second half of the sentence.  As you can see, the links then end up side-by-side instead of one above the other.

If you switch to `inline-flex` **and** add a `<br>` between the links, that'd avoid this potential issue, I think.  Or you could leave its `display` value as it currently stands and just give it a `width` as noted previously here, or do any of several other things.
Thanks for taking a look! But no, it's not quite that simple.  `inline-flex` would kind of work, but it's fragile, because it means the links (now both inline-level) could end up side-by-side if they're skinny enough to fit. We'd be *depending* on the precise text content being a particular minimum width, in order to produce the expected layout.  (And in certain locales/languages/fonts, it may or may not satisfy that minimum width.)

Here's a screenshot showing that possible broken-layout -- I've simply used devtools to switch the first `a` to have to `display:inline-flex` and I've shortened the text of the first link, swapping in [SNIP] for the second half of the sentence.  As you can see, the links then end up side-by-side instead of one above the other.

If you switch to `inline-flex` **and** add a `br` between the links, that'd avoid this potential issue, I think.  Or you could leave its `display` value as it currently stands and just give it a `width` as noted previously here, or do any of several other things.

Back to Bug 1610992 Comment 5