Closed Bug 688878 Opened 13 years ago Closed 13 years ago

"Friends", "Photos", "Map" and "Likes" improperly use ellipses in new Facebook Timeline view

Categories

(Tech Evangelism Graveyard :: English US, defect)

Product:
Tech Evangelism Graveyard
Component:
English US
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox7+, firefox8-)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox7 + ---
firefox8 - ---

People

(Reporter: beltzner, Unassigned)

References

Details

(Keywords: top50, Whiteboard: [qa+]) 

Only tested on latest nightly so far ...

STR:

1. Enable new Facebook Timeline View (see: http://techcrunch.com/2011/09/22/how-to-enable-facebook-timeline/ )
2. View it

Expected: The words beneath the friends, photos, maps and likes to be displayed
Actual: the first two letters are clipped, replaced by ellipses

Screenshot: http://i.imgur.com/fFCtM.png

I tried to dig into the stylesheets; when viewing the page in Chrome, the span is set to text-overflow: clip ... Firebug didn't show any text-overflow rule when viewing in Firefox, but that might be because Firebug doesn't know about text-overflow?

Since the new Facebook timeline is about to go live to the world, I figured I'd flip tracking-firefox7 on this one just in case as it's a topsite.
This seems...less than ideal, good catch!
Filed this upstream at Facebook.
<3
Removing:

left: -19px;

from .fbTimelineNavigationWrapper .uiIconText fixes it for me.
tracking-firefox7: ? → +
tracking-firefox8: --- → ?
> .fbTimelineNavigationWrapper .uiIconText

Is this an issue with "text-overflow: ellipses"? 
If so, this should block bug 312156.
And probably move to "Tech Evangelism"?
Hello. I'm the UI Engineering lead for Timeline. An immediate fix for this has not been discovered short of removing the text-overflow declaration, which we are not prepared to do. I'm not considering this a hi-pri task as I feel it is a bug with Firefox and not our implementation. See the W3C specification of text-overflow below. I hope that this issue can be resolved before our launch to public users in the next 2-4 weeks.

"When only one <ellipsis> value is set by 'text-overflow-ellipsis', it determines the overflow visual hint at the /end/ of the element box."

http://www.w3.org/TR/2003/CR-css3-text-20030514/#text-overflow-ellipsis
That's a very out-of-date spec.  Since then, it's been improved to produce better results for bidi (which was disastrous in the early implementations).  The most current spec is at http://dev.w3.org/csswg/css3-ui/#text-overflow ; Mats (cc:ed already) would know more about the details.
Ah, the W3C TR page strikes again.

The current draft dbaron links to says:

  If there is one value, it applies to both the left and right line edges. If there are
  two values, the first value applies to the right edge, and the second value applies to
  the left edge. 

So our behavior is in fact correct.  Using "text-overflow: clip ellipsis" will do the right thing, of course, as far as I can tell.  So something like this to work around the buggy unprefixed WebKit implementations:

  text-overflow: ellipsis;  /* For old buggy but unprefixed impls */
  text-overflow: clip ellipsis;
Assignee: nobody → english-us
Blocks: 312156
Component: Style System (CSS) → English US
Product: Core → Tech Evangelism
QA Contact: style-system → english-us
Version: Trunk → unspecified
Though note that when there are two values we apply the first one to the _left_ edge.  Mats, is that expected or a bug?
(In reply to Stefan Parker from comment #6)
> Hello. I'm the UI Engineering lead for Timeline. An immediate fix for this
> has not been discovered short of removing the text-overflow declaration,
> which we are not prepared to do. I'm not considering this a hi-pri task as I
> feel it is a bug with Firefox and not our implementation. See the W3C
> specification of text-overflow below. I hope that this issue can be resolved
> before our launch to public users in the next 2-4 weeks.
> 
> "When only one <ellipsis> value is set by 'text-overflow-ellipsis', it
> determines the overflow visual hint at the /end/ of the element box."
> 
> http://www.w3.org/TR/2003/CR-css3-text-20030514/#text-overflow-ellipsis

I identified a stopgap fix in comment 4 and comment 8 should show that it isn't a Firefox bug...(though the jury is still out on comment 9)
I assume for RTL languages these values then apply to the opposite ends as well?
Stefan, that's an interesting question.  ;)  Our behavior when "direction: rtl" is specified on the block is sort of weird, and for Hebrew text in a "direction: ltr" block we seem to do the same thing as for English text, and its what comment 9 says.  But again, Mats should know more.
One additional note: we seem to only support the two-value syntax starting with current nightlies; it's not in Aurora or Beta, so won't ship until December.  See bug 677582; it's a new addition to the spec.
(In reply to Boris Zbarsky (:bz) from comment #8)
>   text-overflow: clip ellipsis;

The two-value syntax will be introduced in Firefox 9 (bug 677582), so that
workaround does not work for Firefox 7 and 8.

(In reply to Boris Zbarsky (:bz) from comment #9)
> Though note that when there are two values we apply the first one to the
> _left_ edge.  Mats, is that expected or a bug?

Yes, the first value applies to the left edge for both ltr and rtl blocks.
We discussed with the spec author whether it should be logical start/end
but we chose left/right since the property is visual rather than logical.

(In reply to Christian Legnitto [:LegNeato] from comment #4)
> Removing:
> 
> left: -19px;
> 
> from .fbTimelineNavigationWrapper .uiIconText fixes it for me.

Based on that I'm guessing it's a relative positioned inline that overflows
the left side of the block with text-overflow:ellipsis.
If so, the behavior is intentional.  I would need a testcase to say for sure.
(In reply to Mats Palmgren [:mats] from comment #14)
> (In reply to Christian Legnitto [:LegNeato] from comment #4)
> > Removing:
> > 
> > left: -19px;
> > 
> > from .fbTimelineNavigationWrapper .uiIconText fixes it for me.
> 
> Based on that I'm guessing it's a relative positioned inline that overflows
> the left side of the block with text-overflow:ellipsis.
> If so, the behavior is intentional.  I would need a testcase to say for sure.

Right, but what I am saying is I removed that line in the CSS and it displayed correctly w/o affecting the rest of the page. FB needs a workaround until bug 677582 lands I would imagine.
> Yes, the first value applies to the left edge for both ltr and rtl blocks.

Right, but the draft text curently says that the first value applies to the _right_ edge of the block.  Just a typo in the draft?
(In reply to Boris Zbarsky (:bz) from comment #16)
> Right, but the draft text curently says that the first value applies to the
> _right_ edge of the block.  Just a typo in the draft?

Yeah, that's a typo in the text-overflow draft.
Whiteboard: [qa+]
(In reply to Stefan Parker from comment #6)
> Hello. I'm the UI Engineering lead for Timeline. An immediate fix for this
> has not been discovered short of removing the text-overflow declaration,
> which we are not prepared to do. I'm not considering this a hi-pri task as I
> feel it is a bug with Firefox and not our implementation. See the W3C
> specification of text-overflow below. I hope that this issue can be resolved
> before our launch to public users in the next 2-4 weeks.

Firefox 7 is just about to ship --- without a fix for this bug, of course. So we definitely can't push out an update with a fix within 2-4 weeks.

Since our behavior is correct per the latest spec, could you please consider a workaround?
To clarify, your behavior is /incorrect/ per the latest spec since we have no way to disable left-side overflow. We have found a fix though and will push it out with our weekly push tomorrow.

Also, because I know it's sometimes difficult to interpret attitude over comments when you've never actually met the person, I feel I should mention that I'm not trying to be snotty or anything. I love what you guys are doing, just didn't think it was Facebook's bug.
(In reply to Stefan Parker from comment #19)
> To clarify, your behavior is /incorrect/ per the latest spec since we have
> no way to disable left-side overflow.

Hmm, that's true. Sorry.

> We have found a fix though and will
> push it out with our weekly push tomorrow.

Thanks!

> Also, because I know it's sometimes difficult to interpret attitude over
> comments when you've never actually met the person, I feel I should mention
> that I'm not trying to be snotty or anything. I love what you guys are
> doing, just didn't think it was Facebook's bug.

Yeah, no problem.
> We have found a fix though and will push it out with our weekly push tomorrow.
Fine, thanks. I assume there is no need for a relnote then.

> To clarify, your behavior is /incorrect/ per the latest spec 
Sure. To claify: There is no bug (not in Firefox and not in Facebook).
This is an incompatibility of browser implementations, originating back in the days of Browser Wars when Microsoft invented this without specification (IIRC).
Blessedly these days are gone (mostly).
Keywords: relnote
(In reply to Mats Palmgren [:mats] from comment #17)
> (In reply to Boris Zbarsky (:bz) from comment #16)
> > Right, but the draft text curently says that the first value applies to the
> > _right_ edge of the block.  Just a typo in the draft?
> 
> Yeah, that's a typo in the text-overflow draft.

Not a typo.

It is correct that when there are two values:
1st value: applies to right edge
2nd value: applies to left edge

This is deliberate for a couple of reasons:
1. When specifying one value, common existing (interoperable) text-overflow implementation/use/expectation is that it applies to the right edge. Thus having the second *optional* value apply to the left edge is more backward syntax/expectation compatible.
2. In multi-valued CSS properties (e.g. margin, padding, border), Right precedes Left (TRBL) and thus this is consistent.
(In reply to j.j. from comment #21)
> > We have found a fix though and will push it out with our weekly push tomorrow.
> Fine, thanks. I assume there is no need for a relnote then.

Deleted from relnotes.
(In reply to Tantek Çelik from comment #22)
> This is deliberate for a couple of reasons:
> 1. When specifying one value, common existing (interoperable) text-overflow
> implementation/use/expectation is that it applies to the right edge. Thus
> having the second *optional* value apply to the left edge is more backward
> syntax/expectation compatible.

I don't think this makes sense given that a single value applies to both edges.

> 2. In multi-valued CSS properties (e.g. margin, padding, border), Right
> precedes Left (TRBL) and thus this is consistent.

I don't think this makes sense either, since that pattern has been used only for 4 sides.  Things that involve x and y positions put x first.
(In reply to Boris Zbarsky (:bz) from comment #8)
> Ah, the W3C TR page strikes again.

Indeed. Aside, please +1 this: http://www.w3.org/wiki/TPAC2011/SessionIdeas#The_W3C_Publication_Process_is_broken:_lets_fix_it.21

> The current draft dbaron links to says:
> 
>   If there is one value, it applies to both the left and right line edges.
> If there are
>   two values, the first value applies to the right edge, and the second
> value applies to
>   the left edge. 
> 
> So our behavior is in fact correct.  Using "text-overflow: clip ellipsis"
> will do the right thing, of course, as far as I can tell.

I can't see any interpretation where our (FF) rendering in fFCtM.png is "correct".

Since there's nothing being scrolled (overflow etc.) of those elements, ellipsing should be on the right edge first if necessary. Since there is no ellipsing (not even clipping of a few pixels) happening on the right edge, there should not be *any* ellipsing occuring on the left edge. That *only* happens when you scroll ellipsed content on the right edge into view, thus pushing left edge content off the edge of the content box. Per:

http://dev.w3.org/csswg/css3-ui/#ellipsis-interaction-with-scrolling-inte
(In reply to David Baron [:dbaron] from comment #24)
> (In reply to Tantek Çelik from comment #22)
> > This is deliberate for a couple of reasons:
> > 1. When specifying one value, common existing (interoperable) text-overflow
> > implementation/use/expectation is that it applies to the right edge. Thus
> > having the second *optional* value apply to the left edge is more backward
> > syntax/expectation compatible.
> 
> I don't think this makes sense given that a single value applies to both
> edges.

It does make sense because the right edge gets ellipsed first per the section on overflow and scrolling, and thus the existing/interoperable "1 value" use case / expectation is that that first value is the one that will take effect first, and do so on the right edge.

> > 2. In multi-valued CSS properties (e.g. margin, padding, border), Right
> > precedes Left (TRBL) and thus this is consistent.
> 
> I don't think this makes sense either, since that pattern has been used only
> for 4 sides.

It's at least *a* pattern. Though yes, applicability is mild, not strong from TRBL to just RL.


>  Things that involve x and y positions put x first.

x and y is/are orthogonal (no pun intended) to -x and +x - thus the analogy does not apply.

Alternative existing patterns welcome.
> there should not be *any* ellipsing occuring on the left edge.

Why not?  The text is overflowing off the left edge, but not off the right edge!  If it's overflowing off the left edge, you get an overflow marker there.  This is completely independent of the scrolling thing; scrolling is _one_ way to get overflow off the left edge, but not the only one.
It's true that the first value is the optional one, and this is unusual, but I suspect the confusion from the order in the style sheet being opposite that on the page outweighs the consistency argument: I'd expect the first value in the declaration to be the first one on the line.

As for /TR holding a draft copy from 2004--Tantek, you haven't requested a push to /TR since 2004. We should fix that, too. :)
(In reply to Boris Zbarsky (:bz) from comment #27)
> > there should not be *any* ellipsing occuring on the left edge.
> 
> Why not?  The text is overflowing off the left edge

How? Maybe I'm missing something obvious but there is no left overflow in the comparative rendering in that PNG.
(In reply to fantasai from comment #28)
> As for /TR holding a draft copy from 2004--Tantek, you haven't requested a
> push to /TR since 2004. We should fix that, too. :)

Current CSS3-UI editor's draft is not LC-worthy, and I don't want to send it back to "plain" public WD as that will invite all sorts of non-LC related comments from people getting the incorrect impression that that a non-LC-WD means it's open to all kinds of random suggestions for additions/changes.

So yeah - go vote to fix the process and the ridiculous/counter-productive draft labels in the current W3C process.

http://www.w3.org/wiki/TPAC2011/SessionIdeas#The_W3C_Publication_Process_is_broken:_lets_fix_it.21
> How?

Because it's in a span that's positioned 19px left.  Now the text may then be scooted to the right (e.g. by a left-padding on the span), but there is still left overflow.
(In reply to Stefan Parker from comment #19)
> To clarify, your behavior is /incorrect/ per the latest spec since we have
> no way to disable left-side overflow.

Well, a browser can't implement future specs.
At the time the text-overflow code in Firefox 7 was added the spec did not
have the two-value syntax.  Some early patches in bug 312156 actually did
implement it but we decided to remove that for the first implementation
(Fx7) because the CSS WG needed to discuss the proposed syntax before it
could be added to the draft.  So, Firefox 7 is in fact correct per the spec
version at the time the code was written.
(In reply to Tantek Çelik from comment #22)
> It is correct that when there are two values:
> 1st value: applies to right edge
> 2nd value: applies to left edge

Here's what I proposed for the two-value syntax:
<quote origin="05/23/2011 email from me to tantek. CC: fantasai,roc,dbaron">
Regarding text-overflow:<left> <right>.  Since the spec calls for
overflow markers on both sides, it seems reasonable to give the author
control over each side separately.  Given that the clipping is visual
rather than logical, I think it makes sense that the two-value form
should also be visual left/right rather than logical start/end.
Either way is fine with me though.
</quote>

It was discussed by the WG (without objections or changes AFAICT):
http://lists.w3.org/Archives/Public/www-style/2011Jun/0329.html
>  fantasai: So the proposal is to let it take two strings (left and right)
>            in addition to one string (both).
...
>   RESOLVED: Add the two-value syntax to text-overflow in css3-ui,
>             marked at-risk

The proposed syntax was always text-overflow: <left-value> <right-value>
from the time it was first suggested (2011-05-08 bug 312156 comment 156)
in all bug comments and private emails to this date.  There are numerous
testcases using the proposed syntax and Firefox test builds implementing
it in bug 312156.  No-one has said anything about the order until now.

So, I'm quite surprised that it ended up in the spec with the values in
opposite order compared to what was proposed.
(In reply to Mats Palmgren [:mats] from comment #33)
> So, I'm quite surprised that it ended up in the spec with the values in
> opposite order compared to what was proposed.

Mats, in your emails it was not clear that you were proposing a specific order so I chose the order in the spec for better authorability/ease-of-use when switching from one value to two (having the second be the "optional" value).

However at this point, that's not relevant (how we got here).

From the above it appears that you, dbaron, and possibly fantasai (assuming she intended her minuting of "let it take two strings (left and right)" to imply order) have consensus of how the order should work, presumably also in the best interest of authors. Thus on this matter of design opinion I will defer to your consensus.
Tech Evangelism bug fixed per comment 19.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
---------------------------------[ Triage Comment ]---------------------------------

We don't need to track this for Firefox 8 as Facebook fixed it on their end.
tracking-firefox8: ? → -
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.