Open
Bug 178671
Opened 22 years ago
Updated 2 years ago
<wbr> should be implemented as a CSS rule or maybe XBL
Categories
(Core :: Layout: Text and Fonts, enhancement, P4)
Core
Layout: Text and Fonts
Tracking
()
NEW
Future
People
(Reporter: jesup, Unassigned)
References
Details
(Keywords: compat)
Attachments
(1 file)
|
(deleted),
patch
|
Details | Diff | Splinter Review |
<wbr> is only partly supported an in a somewhat on-useful way; it works only
outside <nobr>.
It could be implemented as a ZWSP character (zero-width space). This MAY be a
small problem on (some?) X11 machines, since my machine/font has a square with
ZWSP inside of it (though it does cause a break properly).
roc suggested either a CSS rule:
wbr:before { content:"​"; white-space:normal; }
Or implementing it in XBL if we want people to be able to style wbr:before.
BTW, chatzilla uses <wbr>
See also
http://www.htmlcodetutorial.com/linepar/_WBR.html
and
http://www.cs.tut.fi/~jkorpela/html/nobr.html#wbr
|
Reporter | |
Comment 1•22 years ago
|
||
Changing component
s/on-useful/un-useful/
Component: Layout: HTML Frames → Layout: Fonts and Text
Keywords: 4xp
|
||
Comment 2•22 years ago
|
||
This patch removes the layout code and adds the CSS rule. The CSS rule does
not work. I tried content: "\200B" as well, which is the zero-width space, but
if *normal* space does not break then zero-width space sure as hell isn't.
In other words, this patch does output the content (you can verify by putting
normal text in the content:) but does *not* break the line.
|
|
Reporter | |
Comment 3•22 years ago
|
||
How come you used " " instead of "​" (ZWSP)?
Yeah, sorry John, the CSS doesn't work. It's probably because the 'white-space'
property only applies to block elements, according to spec. (I can't see where
that is enforced in our code, though.)
I suggested this because timeless had tried it and said it worked, but I guess
he was mistaken.
Actually our current implementation of <wbr> is exactly equivalent to a ZWSP ---
it doesn't allow breaking inside a nowrap block, which it should. So we could
either replace our <wbr> code with an XBL binding introducing a ZWSP, or we
could fix <wbr> to really work. In the latter case the easiest way might be to
make the 'white-space' property applicable to inline elements, then our CSS rule
would work.
|
|
||
Comment 5•22 years ago
|
||
I would prefer that we be able to specify as many elements as possible using CSS
alone, yes ... it is really the point of having a CSS engine. But since this
requires actual new content, perhaps XBL is more *appropriate*.
Kinda sucks that white-space doesn't work on an inline element, but it doesn't
sound easy :) CC'ing kin anyway.
|
|
||
Comment 6•22 years ago
|
||
Giving it away to default owner. Not gonna get to it myself anytime in the near
or far future, I suspect.
Assignee: jkeiser → font
QA Contact: amar → ian
|
||
Comment 7•22 years ago
|
||
'white-space' should apply to all elements. That was an error in CSS2, fixed in
the CSS2.1 draft.
|
||
Updated•22 years ago
|
Priority: -- → P4
Target Milestone: --- → Future
|
||
Comment 8•22 years ago
|
||
Copying HTML containing a <wbr> to Notepad does not copy the <wbr>. Copying
HTML containing a ​ does copy the zero-width space. So implementing <wbr>
using :before would change content in an invisible way (once bug 12460 is
fixed). Changing content in an invisible way is usually nasty.
|
||
Comment 9•20 years ago
|
||
If this is going to be implemented using CSS, it should be like:
# wbr:before { content:"\200B"; white-space:normal; }
... I guess. (You can't use SGML character references inside CSS.)
Severity: normal → enhancement
Hardware: PC → All
|
||
Updated•15 years ago
|
Assignee: layout.fonts-and-text → nobody
QA Contact: ian → layout.fonts-and-text
|
|
||
Comment 10•13 years ago
|
||
The HTML standard now defines the <wbr> and <nobr> elements in terms of CSS. The definition in the spec does not address the issue raised here in comment 8. I'm open to changing the spec on this further based on feedback regarding whether this is a problem or not.
|
|
Reporter | |
Comment 11•3 years ago
|
||
Going through old bugs... Any thoughts on this? What's the current state?
Flags: needinfo?(dholbert)
|
||
Comment 12•3 years ago
|
||
Looks like we have https://searchfox.org/mozilla-central/source/layout/generic/WBRFrame.cpp , added in bug 584141 in 2019 (pretty recently).
It's linked up to the tag via SIMPLE_TAG_CREATE here:
https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/layout/base/nsCSSFrameConstructor.cpp#3415
I haven't paged in the history/spec/details on wbr (it's not a tag I frequently encounter), but given the relatively-recent work in bug 584141 , I'd be surprised if we need to do a lot of rethinking/reimplementing at this point?
Flags: needinfo?(dholbert)
|
|
||
Comment 13•3 years ago
|
||
In particular, it looks like:
- WBRFrame.cpp's (relatively-recent) implementation is quite minimal/trivial, which is great.
- If we wanted to define the element in "pure CSS", we'd probably still need a dedicated frame class like this, for its CSS to cause us to generate under the hood (to produce the right behavior/semantics).
So, I'm not sure there's anything in particular to be done here. If there are any issues with the current impl, it might be best to file new bugs for them at this point?
|
|
||
Comment 14•3 years ago
|
||
FWIW, according to HTML it needs to be implemented in terms of Edit: turns out this is a mess standards-wise: https://github.com/whatwg/html/issues/2291.display-outside (using the break-opportunity value).
|
|
||
Updated•3 years ago
|
See Also: → https://github.com/whatwg/html/issues/2291
|
|
Reporter | |
Comment 15•3 years ago
|
||
So it sounds like the title of this bug should change (re the whatwg thread, and XBL being dead), but it's still relevant
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•