Opened 14 years ago
Closed 10 years ago
#5254 closed bug (wontfix)
Input, button and anchor buttons aren't consistent in IE7
Reported by: | misterdai | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 1.11.0 |
Component: | ui.button | Version: | 1.8rc3 |
Keywords: | button styling | Cc: | |
Blocked by: | Blocking: |
Description
In IE7 the input/button/anchor versions of a UI button are too varied when it comes to height and positioning. Please see the attached image.
Attachments (1)
Change History (17)
Changed 14 years ago by
Attachment: | button.png added |
---|
comment:1 Changed 14 years ago by
Priority: | minor → critical |
---|
comment:2 Changed 14 years ago by
Summary: | Input, button and anchor buttons aren't consistent → Input, button and anchor buttons aren't consistent in IE7 |
---|
comment:3 Changed 14 years ago by
comment:4 Changed 14 years ago by
From FJ on http://blog.jqueryui.com/2010/03/jquery-ui-18/#comment-1269
I tested the buttons on IE6,7,8 and 9 preview:
comment:5 Changed 13 years ago by
Priority: | critical → major |
---|
comment:6 follow-up: 7 Changed 12 years ago by
comment:7 Changed 12 years ago by
Replying to davidmurdoch:
As noted in git, I don't think this fix is necessary. I'm also not sure why this was ever marked as a critical bug? :) The differences between these buttons are negligible, and are noticeable only when they sit right next to each other -- is that a realistic use case? If the problem is how the buttons appear on the demo page, let's use a more realistic example on the demo page instead of incorporating a slew of hacks into the CSS for an edge case.
comment:8 Changed 12 years ago by
I agree that this is not a fix that is needed. I am currently using the buttons within a modal where we have a "cancel" and "confirm" button that sit next to each other and they work well.
comment:9 follow-up: 11 Changed 12 years ago by
One way to fix this inconsistency with no CSS hacks would be to override the original element with a new one. That way, no matter what element is declared, it will produce the same HTML. The new element can be added immediately after the original, and the original can be hidden. On removal, just remove the created element and show the original.
comment:10 Changed 12 years ago by
I do think a fix is needed but I am not sure there is one. These buttons do not work consistantly in IE 7. I have run into several examples of the behavior being posted here and I would be happy to provide more examples of goofy IE7 behavior if anyone thinks it would help. The biggest most glaring example being the jQuery UI documentation/demo page for the buttons that does not work properly when using IE7. View it in any other browser, everything snaps into its correct position.
comment:11 Changed 12 years ago by
Replying to straussm:
One way to fix this inconsistency with no CSS hacks would be to override the original element with a new one. That way, no matter what element is declared, it will produce the same HTML. The new element can be added immediately after the original, and the original can be hidden. On removal, just remove the created element and show the original.
This is an interesting idea because I have seen differences in the way that IE 7 treats a div with the button() call on it and a button with the button() call on it. I have different results based on how its being used but in at least one case, things work better calling button() on a div tag than a button tag.
comment:12 Changed 12 years ago by
I'm clearly in a case where I need Cancel / Delete buttons close to each other. This is ugly, whatever the browser. This is not to me a strange use case (please, have a look at Google Mail buttons layout for example) and should be fixed.
comment:13 Changed 12 years ago by
I'm still of the opinion that this needs to be fixed or a different approach taken. The idea of replacing / overlaying a div structured button is an interesting one, but I'm unsure about the accessibility issues that might be at play. If we definitely need to retain the input / button / a element, is it possible to involve an additional element to make standardisation across browsers easier?
Do any other styles in jQueryUI require additional effort for certain browsers?
comment:14 Changed 12 years ago by
Milestone: | 1.9 → 1.next |
---|---|
Status: | new → open |
We'll address this as part of the rewrite, following the jQuery Mobile approach, which avoids styling all these elements consistently and instead just wraps the native element in a generic, styled element.
comment:15 Changed 11 years ago by
Milestone: | 1.next → 1.11.0 |
---|
comment:16 Changed 10 years ago by
Resolution: | → wontfix |
---|---|
Status: | open → closed |
We're no longer landing bug fixes for IE7 and will fully drop support soon.
Example of varied button appearances.