Compass +inline-block utility not working for IE7?
183 views
Skip to first unread message
Eric Meyer
Jul 21, 2009, 3:46:04 PM7/21/09
to Compass
The only way I've found to get inline-block styles in IE7 is to give
an element hasLayout and then declare it inline. The +inline-block
mixin does that, but then breaks for IE7 at the point where it sets
the display back to inline-block. Of course, without that it's broken
in other browsers. Am I missing something?
an element hasLayout and then declare it inline. The +inline-block
mixin does that, but then breaks for IE7 at the point where it sets
the display back to inline-block. Of course, without that it's broken
in other browsers. Am I missing something?
Chris Eppstein
Jul 21, 2009, 4:28:36 PM7/21/09
to compas...@googlegroups.com
I don't have any ie7 bugs in my usage of it, but perhaps our use cases differ. One important thing to note is that inline block only really works in IE on elements whose default styles are inline. If you're trying to get it to work on a div, you'll be sad -- change it to a span.
chris
Eric Meyer
Jul 21, 2009, 5:01:26 PM7/21/09
to Compass
That is the difference. It is possible to get IE7 to treat block
elements as inline-block by triggering hasLayout and then setting
display to inline. I'll have to think through how I might achieve that
in a mixin without breaking for other browsers. Might not work. Or
maybe I'll need an IE specific mixin to use as an override in
ie.sass...
Glad for thoughts if anyone has them.
-e
On Jul 21, 2:28 pm, Chris Eppstein <ch...@eppsteins.net> wrote:
> I don't have any ie7 bugs in my usage of it, but perhaps our use cases
> differ. One important thing to note is that inline block only really works
> in IE on elements whose default styles are inline. If you're trying to get
> it to work on a div, you'll be sad -- change it to a span.
> chris
>
elements as inline-block by triggering hasLayout and then setting
display to inline. I'll have to think through how I might achieve that
in a mixin without breaking for other browsers. Might not work. Or
maybe I'll need an IE specific mixin to use as an override in
ie.sass...
Glad for thoughts if anyone has them.
-e
On Jul 21, 2:28 pm, Chris Eppstein <ch...@eppsteins.net> wrote:
> I don't have any ie7 bugs in my usage of it, but perhaps our use cases
> differ. One important thing to note is that inline block only really works
> in IE on elements whose default styles are inline. If you're trying to get
> it to work on a div, you'll be sad -- change it to a span.
> chris
>
Chris Eppstein
Jul 21, 2009, 5:05:16 PM7/21/09
to compas...@googlegroups.com
Would love to have a more comprehensive solution if anyone has one... But glad to hear you're not blocked.
chris
Travis Tilley
Jul 21, 2009, 6:58:47 PM7/21/09
to Compass
I've actually had a patch to your inline-block mixin that I've just
been too lazy to submit so far. ^^;
My version is as follows:
// In IE6+7, setting display to inline-block simply has the effect of
// triggering IE's internal 'hasLayout' attribute for that element.
When used
// on an inline element, this results in normal inline-block behavior.
Block
// level elements with hasLayout do not behave like inline-block
elements. The
// solution to inline-block behavior in IE6+7 is to make something
display
// inline, and then trigger hasLayout (by setting zoom or what have
you).
// FF2 supports something similar to inline-block behavior via XUL
using the
// -moz-inline-box display setting. Setting -moz-box-orient to
vertical fixes
// an additional display issue with unknown width elements.
// inline-block is properly supported by webkit, FF3+, and IE8.
=inline-block
:display -moz-inline-box
:-moz-box-orient vertical
:display inline-block
:vertical-align middle
:#zoom 1
:#display inline
// fixes alignment against native input/button on IE6
:#vertical-align auto
been too lazy to submit so far. ^^;
My version is as follows:
// In IE6+7, setting display to inline-block simply has the effect of
// triggering IE's internal 'hasLayout' attribute for that element.
When used
// on an inline element, this results in normal inline-block behavior.
Block
// level elements with hasLayout do not behave like inline-block
elements. The
// solution to inline-block behavior in IE6+7 is to make something
display
// inline, and then trigger hasLayout (by setting zoom or what have
you).
// FF2 supports something similar to inline-block behavior via XUL
using the
// -moz-inline-box display setting. Setting -moz-box-orient to
vertical fixes
// an additional display issue with unknown width elements.
// inline-block is properly supported by webkit, FF3+, and IE8.
=inline-block
:display -moz-inline-box
:-moz-box-orient vertical
:display inline-block
:vertical-align middle
:#zoom 1
:#display inline
// fixes alignment against native input/button on IE6
:#vertical-align auto
Chris Eppstein
Jul 21, 2009, 7:21:27 PM7/21/09
to compas...@googlegroups.com
Frankly, I don't know much about this approach. I'm cool with taking a patch, but I don't have time to test this in the next few days. Would love to get some feedback from the list with +1s and what browsers you've tested against.
chris
Eric Meyer
Jul 23, 2009, 3:50:03 AM7/23/09
to Compass
I'm making an effort to sort my IE fixes out into their proper
conditional-comment-called ie.sass, which in this case is as easy as
adding "display:inline" as an IE-only override to your +inline-block
elements. That's a cleaner solution in my mind, and worth the extra
line to avoid hacks in my code.
That aside, the one above should do the trick nicely for people who
prefer the all-in-one approach and don't mind a few hacks. The FF2
proprietary comments are entirely worth a second look either way.
Thanks, Travis.
One question: Is the ":zoom 1" actually needed? Wouldn't this work
without it, seeing as ":display inline-block" should already trigger
hasLayout?
Cheers,
-e
On Jul 21, 5:21 pm, Chris Eppstein <ch...@eppsteins.net> wrote:
> Frankly, I don't know much about this approach. I'm cool with taking a
> patch, but I don't have time to test this in the next few days. Would love
> to get some feedback from the list with +1s and what browsers you've tested
> against.
> chris
>
conditional-comment-called ie.sass, which in this case is as easy as
adding "display:inline" as an IE-only override to your +inline-block
elements. That's a cleaner solution in my mind, and worth the extra
line to avoid hacks in my code.
That aside, the one above should do the trick nicely for people who
prefer the all-in-one approach and don't mind a few hacks. The FF2
proprietary comments are entirely worth a second look either way.
Thanks, Travis.
One question: Is the ":zoom 1" actually needed? Wouldn't this work
without it, seeing as ":display inline-block" should already trigger
hasLayout?
Cheers,
-e
On Jul 21, 5:21 pm, Chris Eppstein <ch...@eppsteins.net> wrote:
> Frankly, I don't know much about this approach. I'm cool with taking a
> patch, but I don't have time to test this in the next few days. Would love
> to get some feedback from the list with +1s and what browsers you've tested
> against.
> chris
>
Chris Eppstein
Jul 23, 2009, 4:04:20 AM7/23/09
to compas...@googlegroups.com
I'm all about maintainability, and I've seen what happens when you have two disconnected files that have to be kept in sync: bit rot.
I don't understand you're aversion to the css hacks if they allow you to keep your code well organized. Is it anything other than aesthetics?
I want to add a feature to sass that would allow you to add rules into an alternate css stylesheet from your main sass file. Then we don't have to have the false choice between hacks in our css and maintainability anymore. Until then, I prefer to keep things centralized into single mixins for the general user base, I would encourage you to do the same. Not everyone has the diligence to keep two files in sync (out of sight == out of mind).
chris
Eric Meyer
Jul 23, 2009, 4:15:09 PM7/23/09
to Compass
Chris,
My hesitance comes from the dangers of counting on a browser to fail
exactly the way you want it to. Hacks aren't reliable:
http://www.digital-web.com/articles/keep_css_simple/
But I might be (easily) convinced for the sake of Susy to make both
options available, and let the user decide. In fact, I'll start
working on the patch now.
I agree with you on the dangers of maintaining disconnected files. My
half-fix is to use IE styles as an override rather than separate
track, but it can still be a pain to maintain. I would love to see
your feature for alternate stylesheets in a single sass file. Is there
any way I can help make that happen?
Eric
On Jul 23, 2:04 am, Chris Eppstein <ch...@eppsteins.net> wrote:
> I'm all about maintainability, and I've seen what happens when you have two
> disconnected files that have to be kept in sync: bit rot.
>
> I don't understand you're aversion to the css hacks if they allow you to
> keep your code well organized. Is it anything other than aesthetics?
>
> I want to add a feature to sass that would allow you to add rules into an
> alternate css stylesheet from your main sass file. Then we don't have to
> have the false choice between hacks in our css and maintainability anymore.
> Until then, I prefer to keep things centralized into single mixins for the
> general user base, I would encourage you to do the same. Not everyone has
> the diligence to keep two files in sync (out of sight == out of mind).
>
> chris
>
My hesitance comes from the dangers of counting on a browser to fail
exactly the way you want it to. Hacks aren't reliable:
http://www.digital-web.com/articles/keep_css_simple/
But I might be (easily) convinced for the sake of Susy to make both
options available, and let the user decide. In fact, I'll start
working on the patch now.
I agree with you on the dangers of maintaining disconnected files. My
half-fix is to use IE styles as an override rather than separate
track, but it can still be a pain to maintain. I would love to see
your feature for alternate stylesheets in a single sass file. Is there
any way I can help make that happen?
Eric
On Jul 23, 2:04 am, Chris Eppstein <ch...@eppsteins.net> wrote:
> I'm all about maintainability, and I've seen what happens when you have two
> disconnected files that have to be kept in sync: bit rot.
>
> I don't understand you're aversion to the css hacks if they allow you to
> keep your code well organized. Is it anything other than aesthetics?
>
> I want to add a feature to sass that would allow you to add rules into an
> alternate css stylesheet from your main sass file. Then we don't have to
> have the false choice between hacks in our css and maintainability anymore.
> Until then, I prefer to keep things centralized into single mixins for the
> general user base, I would encourage you to do the same. Not everyone has
> the diligence to keep two files in sync (out of sight == out of mind).
>
> chris
>
Chris Eppstein
Jul 23, 2009, 4:43:15 PM7/23/09
to compas...@googlegroups.com, Compass
We need to make sure Nathan is ok with the feature. He's been hesitant
so far.
That said, any new sass feature wouldn't go into 2.2, and so that
makes them off limits for any of the core compass frameworks until
after compass 1.0 (unless 2.4 comes out before compass 1.0.)
If you provide multiple mixins for your framework, I guess the user
can decide to use hacks or not. At the end of the day, it's your
framework, and so it's your decision how to balance the ease of use
vs. flexibility vs. "future proof".
I would point out that one of the benefits of how compass encourages
distribution of code, makes the "future proof" argument carry less
weight, because if your abstractions are sound, a simple upgrade might
clear up the future issues.
Hunt & pecked on my iPhone... Sorry if it's brief!
so far.
That said, any new sass feature wouldn't go into 2.2, and so that
makes them off limits for any of the core compass frameworks until
after compass 1.0 (unless 2.4 comes out before compass 1.0.)
If you provide multiple mixins for your framework, I guess the user
can decide to use hacks or not. At the end of the day, it's your
framework, and so it's your decision how to balance the ease of use
vs. flexibility vs. "future proof".
I would point out that one of the benefits of how compass encourages
distribution of code, makes the "future proof" argument carry less
weight, because if your abstractions are sound, a simple upgrade might
clear up the future issues.
Hunt & pecked on my iPhone... Sorry if it's brief!
Eric Meyer
Jul 23, 2009, 7:37:29 PM7/23/09
to Compass
I stand convinced/corrected. I've now implemented Travis' solution
above (without the zoom attribute) and tested it in IE6 and IE7 with
positive results. This will be pushed into Susy 0.4.1 along with a few
other features this evening:
=inline-block
:display -moz-inline-box
:-moz-box-orient vertical
:display inline-block
:vertical-align middle
On Jul 23, 2:43 pm, Chris Eppstein <ch...@eppsteins.net> wrote:
> We need to make sure Nathan is ok with the feature. He's been hesitant
> so far.
>
> That said, any new sass feature wouldn't go into 2.2, and so that
> makes them off limits for any of the core compass frameworks until
> after compass 1.0 (unless 2.4 comes out before compass 1.0.)
>
> If you provide multiple mixins for your framework, I guess the user
> can decide to use hacks or not. At the end of the day, it's your
> framework, and so it's your decision how to balance the ease of use
> vs. flexibility vs. "future proof".
>
> I would point out that one of the benefits of how compass encourages
> distribution of code, makes the "future proof" argument carry less
> weight, because if your abstractions are sound, a simple upgrade might
> clear up the future issues.
>
> Hunt & pecked on my iPhone... Sorry if it's brief!
>
above (without the zoom attribute) and tested it in IE6 and IE7 with
positive results. This will be pushed into Susy 0.4.1 along with a few
other features this evening:
=inline-block
:display -moz-inline-box
:-moz-box-orient vertical
:display inline-block
:vertical-align middle
:#display inline
// fixes alignment against native input/button on IE6
:#vertical-align auto
-eric
// fixes alignment against native input/button on IE6
:#vertical-align auto
On Jul 23, 2:43 pm, Chris Eppstein <ch...@eppsteins.net> wrote:
> We need to make sure Nathan is ok with the feature. He's been hesitant
> so far.
>
> That said, any new sass feature wouldn't go into 2.2, and so that
> makes them off limits for any of the core compass frameworks until
> after compass 1.0 (unless 2.4 comes out before compass 1.0.)
>
> If you provide multiple mixins for your framework, I guess the user
> can decide to use hacks or not. At the end of the day, it's your
> framework, and so it's your decision how to balance the ease of use
> vs. flexibility vs. "future proof".
>
> I would point out that one of the benefits of how compass encourages
> distribution of code, makes the "future proof" argument carry less
> weight, because if your abstractions are sound, a simple upgrade might
> clear up the future issues.
>
> Hunt & pecked on my iPhone... Sorry if it's brief!
>
Chris Eppstein
Jul 24, 2009, 3:19:28 PM7/24/09
to Compass
If you make this into a patch for compass, I'll pull it into edge for
the next release.
Thanks,
Chris
the next release.
Thanks,
Chris
Reply all
Reply to author
Forward
0 new messages