Ellipses too aggressive - truncating overflow early on lists, buttons, form elements #779

Closed
rogerbinns opened this Issue Jan 9, 2011 · 6 comments

Comments

Projects
None yet
6 participants
@rogerbinns

When long text is shortened using ellipses it shortens the string far too much. There is usually plenty more space, and given how narrow the screen is really hinders usability. I'll attach a screenshot showing this where almost a third of the available screen width got turned into white space.

@rogerbinns

This comment has been minimized.

Show comment
Hide comment
@rogerbinns

rogerbinns Jan 9, 2011

It looks like github doesn't allow ticket attachments. I've uploaded the screenshot as http://imgur.com/YEhCj

It is part of the demo site http://jquerymobile.com/test using Android 2.2 on a Tmobile G2. Several more characters will fit. This problem is especially bad when you have larger text such as headings.

It looks like github doesn't allow ticket attachments. I've uploaded the screenshot as http://imgur.com/YEhCj

It is part of the demo site http://jquerymobile.com/test using Android 2.2 on a Tmobile G2. Several more characters will fit. This problem is especially bad when you have larger text such as headings.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Jan 23, 2011

Contributor

I agree that on button, select menus, check, radios, etc. that we could trim down some of the left ad right padding to fit more characters.

On headers, we leave room for buttons on either side of the text to keep the styles and positioning logic simpler but we could look into refining this to take up more space if there aren't buttons up there.

Contributor

toddparker commented Jan 23, 2011

I agree that on button, select menus, check, radios, etc. that we could trim down some of the left ad right padding to fit more characters.

On headers, we leave room for buttons on either side of the text to keep the styles and positioning logic simpler but we could look into refining this to take up more space if there aren't buttons up there.

@rogerbinns

This comment has been minimized.

Show comment
Hide comment
@rogerbinns

rogerbinns Jan 23, 2011

Sorry for not being precise. In my case headers are an h3 element being used as described in "Collapsible content markup" in the doc. They are a name and the expanded content is more detail.

Sorry for not being precise. In my case headers are an h3 element being used as described in "Collapsible content markup" in the doc. They are a name and the expanded content is more detail.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Jan 24, 2011

Contributor

Understood. I just wanted to expand the scope of this ticket to cover the padding and truncation across all widgets in a consistent way. Collapsibles are another element that should be included in this because they are based on button markup and styes.

Contributor

toddparker commented Jan 24, 2011

Understood. I just wanted to expand the scope of this ticket to cover the padding and truncation across all widgets in a consistent way. Collapsibles are another element that should be included in this because they are based on button markup and styes.

@jannotti

This comment has been minimized.

Show comment
Hide comment
@jannotti

jannotti Apr 4, 2011

I think this happened because a.ui-link-inherit has padding, but it's inside .ui-btn-inner which has already padded to make room the icon.

jannotti commented Apr 4, 2011

I think this happened because a.ui-link-inherit has padding, but it's inside .ui-btn-inner which has already padded to make room the icon.

@jakeboone02

This comment has been minimized.

Show comment
Hide comment
@jakeboone02

jakeboone02 Jun 9, 2011

Contributor

This may be redundant based on what Todd said above about the scope of this ticket, but I wanted to make sure the case of a plain text, non-link list item is covered. These should have no extra padding whatsoever since there is no icon on the right. See here: http://jsbin.com/eqoho4. This is especially bad on inset lists.

Contributor

jakeboone02 commented Jun 9, 2011

This may be redundant based on what Todd said above about the scope of this ticket, but I wanted to make sure the case of a plain text, non-link list item is covered. These should have no extra padding whatsoever since there is no icon on the right. See here: http://jsbin.com/eqoho4. This is especially bad on inset lists.

@ghost ghost assigned scottjehl Jun 9, 2011

@ghost ghost assigned gseguin Jul 28, 2011

gseguin added a commit that referenced this issue Aug 12, 2011

Fix for issue #779
Added a ui-li-has-count class for listview items that contain a count bubble. Changed default padding-right to 25px adjusting it to 75px when count bubble is present.

@gseguin gseguin closed this Aug 12, 2011

gseguin added a commit that referenced this issue Aug 24, 2011

gseguin added a commit that referenced this issue Aug 24, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment