In Mobile Me Calendar, New Event text displayed offset when it's first created. This is a regression from Ojan's recent textarea change (http://trac.webkit.org/changeset/43007 ) Steps to reproduce: 1. Login into MobileMe 2. Go to http://www.me.com/calendar/ 3. Double-click a day on the calendar to automatically create a new event 4. Notice the "New Event" text is offset from its banner. Without a reduction, it will be really difficult to know what is going on here since the Web Inspector shows that the misplaced text is inside a div that is inside many divs; there are no textareas in sight! There are likely textareas involved in the JavaScript that puts the text there though, because this is definitely a regression from Ojan's change. If we cannot find a way to fix this quickly, we may have to roll out the change until we can find a way to implement it without breaking MobileMe.
I should note if anyone if trying to reproduce: Make sure you are in the month view when you create the event. The bug does not happen in the week or day view.
Though I still do not have a reduction, I strongly suspect that MobileMe has built their layout around our exact metrics. That was bad of them, but it makes this change extremely scary; there could be a lot of sites that have done things like this.
I reverted the margin changes to restore our old behavior. That reduces the offset somewhat. However the padding changes are still causing issues. I really don't see how we can change padding metrics (like we apparently just did in 43007) without causing all sorts of huge compatibility issues with existing sites that have coded to our old metrics. We should probably just back out the padding changes for now as well.
I believe they had no choice but to build to our metrics, since we had some built-in intrinsic padding that could not be removed.
Actually looking into this more I think the textarea padding changes make sense. inputs essentially have 3px of border+padding on all sides. Before ojan's change, textareas had 4px on left/right and only 1px top/bottom. Now they're 3px all around just like inputs. So the change seems good to me. Really MobileMe should have put 0 padding in CSS on their secret textarea rather than coding to the default metrics of it. I think we just need to get the site to change.
So it looks like you rolled out part of Ojan's change in http://trac.webkit.org/changeset/43355, but you're agreeing that the post r43007 behavior was better than the current behavior? I suspect mobile me is one of very very few sites to build to Safari's metrics specifically. Dashboard would be another. I would suspect most sites to match IE/FF. But you guys are gonna be the experts here, not I.
Hyatt thinks that the remaining behavior that did not get rolled out is an improvement. We are looking into having this fixed on the MobileMe side. That being said, I am still nervous about the change because I disagree that MobileMe and Dashboard are the only WebKit clients likely to build sites around WebKit's metrics; we get compatibility bugs at totally random sites when we make changes like this all the time!
Moving this to Evangelism for now.
The bulk of r43007 was to change the interpretation of size/cols on inputs/textareas. This was inspired by our QA running into a number of top sites (by number of pageviews) that woud layout incorrectly in WebKit due to the widths of text controls not matching IE (e.g. an input that was too large would cause things to wrap and make a site look surprisingly broken). I'm pretty sure that, for text controls that have an explicit CSS width, the only differences in metrics from r43007 is the amount of padding on textareas and that the padding can be removed via CSS. If I understand correctly, the latter should enable MobileMe to not need to hard-code to webkit metrics. I don't know how to prove this, but I expect that, of sites that actually use size/cols instead of CSS width, there are considerably more sites that depend on IE metrics here than WebKit metrics. The CSS changes in r43007 were to match IE, but, as I told hyatt/mitz, I'm OK with r43355 as it makes form controls look better in general and the majority, if not all, of the compatibility win is from treating size/cols differently.
Created attachment 45922 [details] Improve text control intrinsic widths.
Comment on attachment 45922 [details] Improve text control intrinsic widths. Wrong bug.