Default them password mask character

[r0m4n]

When using the default themes from the Themeroller, one would think the themes would be completely compliant when using the default configurations.

I have run into an issue where I am using default themes generated with Themeroller, the themes display squares for the password fields.

I have only really witnessed this on Firefox v13.0

In this jsfiddle, I am using the Redmond theme (out of the box: ​http://code.jquery.com/ui/1.8.21/themes/redmond/jquery-ui.css)

​http://jsfiddle.net/xKx48/

I found someone with a similar issue but no solution was really brought about (other than the conversation of declared fonts not containing these password symbols).

​http://stackoverflow.com/questions/6714086/weird-password-mask-when-using-jqueryui-dialog

I realize this really isn't a bug with the Themeroller itself, more of the specific configured default theme created but as a theme that is included in some releases of the jQuery package and referenced to in many places, shouldn't they all default themes be completely compliant across all claimed browsers/system configurations?

[rdworth]

This is an issue with your specific platform matching a font in the Redmond theme's font stack (Lucida Grande, Lucida Sans, Arial, sans-serif) that it feels is a match or a close match, but as you point out, that font on that platform doesn't have that password symbol. The workaround is something like:

 .ui-widget input { font-family: sans-serif; }

Put that css after you include the theme.

(I'm sorry I can't fully test as I can't reproduce. My system matches a font that has that symbol, even with Firefox v13.0)

shouldn't they all default themes be completely compliant across all claimed browsers/system configurations?

There's almost no telling what fonts will and won't be installed on a given system. It's a lot bigger question than just "Mac" or "Windows" or "Linux". The font stacks in jQuery UI rely on relatively common font families, and have proven fall-backs to dependable across-the-board stand-ins, such as Arial and sans-serif (a whole class of families).

We need more information about which platform configurations present this issue and due to which font family matching incorrectly, in order to consider taking any corrective action.

[trac-o-bot]

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!