No subject

19:57 <dhyatt> mkwst: yeah i know about that code
19:57 <dhyatt> mkwst: so in order to make form controls look nice and not butt up against each other we have this feature called intrinsic margins.
19:58 <dhyatt> the basic idea is that - if we can detect it won't screw up the layout of the web page - we will add in intrinsic margins to provide a nice separation between adjacent controls the classic example years ago was google's home page with its two buttons that were right next to each other which on mac especially looked terrible since you never want aqua controls right up against one another (looks bad on windows too, just less bad).
19:59 <mkwst> dhyatt: ok. so it's not just the focus ring, but layout in general.
19:59 <dhyatt> so the basic idea is that if the author doesn't know the iwdth/height of the control (e.g., he didn't specify it explicitly) then it's safe to add in some margins but if the author said "i want this control to be 100px wide" then adding in margins is iffy since you could disrupt the author's intended page layout so that's the motivation behind sometimes turning intrinsic margins off.
20:00 <esprehn_> mkwst: form controls of full of these lies. We also tell you it has a 2 pixel beveled border and a grey background
20:00 <mkwst> esprehn_: lovely. :)
20:00 <esprehn_> getComputedStyle(input) is not super useful unless you styled it yourself
20:00 <dhyatt> the intrinsic margin feature is really nice
20:01 <dhyatt> like if you turn it off you would notice pretty fast on web pages. especially on mac.
20:01 <esprehn_> dhyatt: does Gecko do this?
20:01 <dhyatt> no this is something i invented
20:01 <dhyatt> i don't think any other browser does it
20:01 <esprehn_> seems like it would cause wrapping of controls that are inside in app toolbars. maybe that's what I've seen before.
20:01 <dhyatt> it shouldn't
20:01 <dhyatt> i mean, the margin is only added in if the control size is unspecified, so the control size was already going to vary across browsers and platforms. if the author specifies the control size, then the margins turn off 
20:03 <dhyatt> i don't recall ever seeing a bug where the intrinsic margins were to blame for disrupted page layout
20:04 <dhyatt> but if those bugs do exist, i would be willing to revisit
20:04 <esprehn_> nah, this behavior is sensible, it's just not documented
20:04 <dhyatt> but in the absence of those bugs, i'd recommend leaving the feature in, since controls with no gaps at all between them look really icky
20:04 <dhyatt> and it happens way too much
20:04 <mkwst> Right, but that bit is surprising for authors. I don't think it breaks anything in a big way, but jQuery has seen bugs filed.
20:04 <esprehn_> we could fix this with -webkit-input-spacing: auto or something
20:04 <mkwst> I don't think removing the margins is a good idea.
20:05 <esprehn_> then you'd see it in the inspector and could google search for what that was
20:05 <dhyatt> esprehn_: it needs to be margins though. if the author specifies an explicit margin, it needs to take precedence
20:05 <mkwst> But the current behavior is surprising.
20:05 <dhyatt> i mean, it's not lying. it's genuinely telling you the margin is there, right? what's surprising is that it changed.
20:06 <mkwst> That's what I mean.
20:06 <dhyatt> i mean, we could do something like not get rid of intrinsic margins if height/width are set dynamically
20:06 <dhyatt> but that seems iffy to me
20:06 <mkwst> Hrm. I agree. :/

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.