Something changed in the last 48 hours -- I'm sure I went through the install UI either yesterday or the day before and it was fine.
Today I went through the D8 UI install (standard install profile, English, PostgreSQL) and when it got to the "configure site" stage, it looked like this:
All of the fields are hanging over into the blue section of the page. Not very pretty.
If it matters, I'm running Firefox version 18.0 (Yes, I know it's old, need to update, etc.).
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | ie-password-confirm.png | 122.28 KB | sun |
| #17 | Screenshot 2014-04-08 19.11.04.jpg | 293.39 KB | lewisnyman |
| #13 | 2014-03-30 13.28.48.jpg | 1.7 MB | lewisnyman |
| #12 | 2195781-install-formatting-11.patch | 382 bytes | lewisnyman |
| #11 | 2014-03-30 13.19.36.jpg | 1.78 MB | lewisnyman |
Comments
Comment #1
larowlanCertain There Was An Issue To Remove #size From Form fields
Comment #2
longwaveReverting #2002336: Introduce a CSS class to hide borders of fieldset elements fixes this.
Comment #3
longwaveAnd the later comments in that issue suggest it was known to be broken at commit time, but #2193271: Remove default #size attribute from core should fix this.
Comment #4
longwaveClosed #2197187: Install output error as duplicate
Comment #5
sunYes, #2193271: Remove default #size attribute from core has a working solution for this (much deeper) CSS problem space.
Comment #6
anksy commentedComment #7
jhodgdonIt sounds like maybe we should postpone this issue until #2193271: Remove default #size attribute from core is addressed and then revisit to make sure this issue is fixed.
Comment #8
webchickThat issue is taking forever, and in the meantime this is totally embarrassing.
Comment #9
lewisnymanComment #10
lewisnymanThis is such a weird problem. So the textfields have
max-width: 100%but fieldsets have the equivalent ofmin-width: content-width. Details hereThis fix needs testing in IE9+, which I am unable to on my local. Anyone with a Browserstack account can use simplytest.me to do this.
Comment #11
lewisnymanIt's ok, I got someone here to test it. It does break IE, so we need to wrap some of the CSS in something Firefox specific, which is recommend in the stackoverflow answer.
Comment #12
lewisnymanComment #13
lewisnymanIt works in IE9!
Comment #14
corbacho commentedI could replicate the bug in Firefox 28.0 , and I could verify that patch still applies and fixes the issue.
In IE9 and IE10 is working ok
It's a Gecko-engine issue, so I think it's good to address the issue with that small fix suggested.
And it's self-documented, the CSS rule has the -moz prefix
Comment #15
sunSince this is a temporary fix, not sure whether the added CSS shouldn't have a comment (@todo + @see) that says to remove this when the other issue is resolved?
Comment #16
lewisnyman@sun let's double check that this is a temporary fix. What if we modify the form to add a #size attribute. Does it still break?
Comment #17
lewisnymanYeah turns out you can still break it, we shouldn't allow forms to break pages like this.
Comment #18
sunYes, that's the nature of the
'size'attribute. It's a beast. That's why need to do #2193271: Remove default #size attribute from core + discourage its usage.FWIW, grabbed from #13: The password confirm label is misplaced:
Comment #19
webchickComment #20
corbacho commentedThe password confirm label thing is unrelated to this.
It is misplaced because JavaScript does not execute in IE9, so the "password strength widget" is broken. See #2235425: domready bug breaks Drupal behaviors
But when JS works, everything looks fine in IE9 and IE10. Screenshot http://monosnap.com/image/Nv1IhusxW0iXJis6fTwLRWViO4s6nq
Comment #22
webchickOk, great. Let's get this in then so the next alpha doesn't have a black eye. We can handle whatever else needs to happen in follow-ups.
Committed and pushed to 8.x. Thanks