Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
HasLayout
23 views
Skip to first unread message
j
Nov 10, 2012, 9:42:27 PM11/10/12
to
I've been using these "hacks" to trigger haslayout so that a container
with floats will have height:
overflow:hidden;
zoom:1;
Although this still works well for me, I wonder what is the current way
of dealing with this issue.
I've stopped using some of the old IE hacks, like those for inline-block
and png transparency but I see that IE6 still has significant market
share:
http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0
Sheesh, what's it take to bury that dog?
with floats will have height:
overflow:hidden;
zoom:1;
Although this still works well for me, I wonder what is the current way
of dealing with this issue.
I've stopped using some of the old IE hacks, like those for inline-block
and png transparency but I see that IE6 still has significant market
share:
http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0
Sheesh, what's it take to bury that dog?
BootNic
Nov 11, 2012, 12:37:38 AM11/11/12
to
In article <k7n3ak$cl9$1...@news.albasani.net>, j <mun...@att.net> wrote:
> I've been using these "hacks" to trigger haslayout so that a container
> with floats will have height:
> overflow:hidden; zoom:1;
older versions of IE only needed zoom:1.
> I've been using these "hacks" to trigger haslayout so that a container
> with floats will have height:
> overflow:hidden; zoom:1;
Since IE 8, only overflow:hidden; just like any other ua.
> Although this still works well for me, I wonder what is the current
> way of dealing with this issue.
going to spend/pay at least 25% more to develop for ua's 6 - 11 years old.
It's wrong enough that IE 8 will soon be 3 years old.
> I've stopped using some of the old IE hacks, like those for
> inline-block and png transparency but I see that IE6 still has
> significant market share:
> http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0
Even then, statistics may not be dependable.
[url] http://www.w3schools.com/browsers/browsers_explorer.asp [/url]
> Sheesh, what's it take to bury that dog?
--
BootNic Sun Nov 11, 2012 12:37 am
"There is a wicked pretense that one has been informed. But no such thing has
truly occurred! A mere slogan, an empty litany. No arguments are heard, no
evidence is weighed. It isn't news at all, only a source of amusement for
idlers."
*Gibson-Sterling, The Difference Engine*
dorayme
Nov 11, 2012, 3:08:48 AM11/11/12
to
> I've been using these "hacks" to trigger haslayout so that a container
> with floats will have height:
>
> overflow:hidden;
etc...
> with floats will have height:
>
> overflow:hidden;
overflow: hidden is not actually a hack. It is an effect of a kosher,
mensch of a thing, a block formatting context. There is some stuff on
this at
http://netweaver.com.au/floatHouse/page8.php
and there is some stuff on IE6 on the next page.
I agree with bootnic, don't worry about IE6 too much now.
--
dorayme
Cezary Tomczyk
Nov 11, 2012, 4:19:10 AM11/11/12
to
W dniu 2012-11-11 09:08, dorayme pisze:
There is nothing wrong with overflow:hidden; but in some situation could
bring us a headache. Scenario:
<div class="mysection">
<h1>Test</h1>
<p>some text</p>
<ul>
<li>list</li>
</ul>
</div>
.mysection{
position:relative;
height:10em;
}
.mysection h1,
.mysection p{
float:left;
}
.mysection ul{
position:absolute;
right:0;
top:-2em;
}
UL will be cut by overflow. That's why I personally prefer solution
described here: http://nicolasgallagher.com/micro-clearfix-hack/
--
Cezary Tomczyk
http://www.ctomczyk.pl/
bring us a headache. Scenario:
<div class="mysection">
<h1>Test</h1>
<p>some text</p>
<ul>
<li>list</li>
</ul>
</div>
.mysection{
position:relative;
height:10em;
}
.mysection h1,
.mysection p{
float:left;
}
.mysection ul{
position:absolute;
right:0;
top:-2em;
}
UL will be cut by overflow. That's why I personally prefer solution
described here: http://nicolasgallagher.com/micro-clearfix-hack/
--
Cezary Tomczyk
http://www.ctomczyk.pl/
Thomas 'PointedEars' Lahn
Nov 11, 2012, 2:57:41 PM11/11/12
to
BootNic wrote:
> In article <k7n3ak$cl9$1...@news.albasani.net>, j <mun...@att.net> wrote:
>> I've stopped using some of the old IE hacks, like those for
>> inline-block and png transparency but I see that IE6 still has
>> significant market share:
>
>> http://www.netmarketshare.com/browser-market
> In article <k7n3ak$cl9$1...@news.albasani.net>, j <mun...@att.net> wrote:
>> I've stopped using some of the old IE hacks, like those for
>> inline-block and png transparency but I see that IE6 still has
>> significant market share:
>
>> http://www.netmarketshare.com/browser-market
>> share.aspx?qprid=2&qpcustomd=0
>
> The only statistics that should matter at all, would be specific to a
> site.
No, for you cannot estimate what you have not measured. Tying website
>
> The only statistics that should matter at all, would be specific to a
> site.
development to previous site statistics is a major mistake because, for
example, if you have tailored your website so that it only works with
Internet Explorer, and you keep on doing that because of your site
statistics (however flawed they might be), you will find your decision
confirmed because you have not improved the site. A self-fulfilling
prophecy.
> Even then, statistics may not be dependable.
snapshots.
> [url] http://www.w3schools.com/browsers/browsers_explorer.asp [/url]
I would not trust w3schools farther than /dev/null, into which I regularly
have to throw its "advice" and "Web documentation". Keep in mind that
w3schools has nothing to do with the W3C (and it shows).
For a more complete picture then, see <http://gs.statcounter.com/>. This
and netmarketshare are among the most cited sources when it comes to Web
statistics, and the best documented that I have found so far. That is not
to say that they are fully reliable, but they give better approximations
than others.
F'up2 ciwam
PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14
dorayme
Nov 11, 2012, 4:09:47 PM11/11/12
to
In article <k7nqic$thd$1...@speranza.aioe.org>,
your above a demo of a UL cut by overflow:?
--
dorayme
Cezary Tomczyk <cezary....@gmail.com> wrote:
> There is nothing wrong with overflow:hidden; but in some situation could
> bring us a headache. Scenario:
>
> <div class="mysection">
> <h1>Test</h1>
> <p>some text</p>
> <ul>
> <li>list</li>
> </ul>
> </div>
>
> .mysection{
> position:relative;
> height:10em;
> }
> .mysection h1,
> .mysection p{
> float:left;
> }
> .mysection ul{
> position:absolute;
> right:0;
> top:-2em;
> }
>
> UL will be cut by overflow.
Perhaps you might explain for the benefit of those interested. How is
> There is nothing wrong with overflow:hidden; but in some situation could
> bring us a headache. Scenario:
>
> <div class="mysection">
> <h1>Test</h1>
> <p>some text</p>
> <ul>
> <li>list</li>
> </ul>
> </div>
>
> .mysection{
> position:relative;
> height:10em;
> }
> .mysection h1,
> .mysection p{
> float:left;
> }
> .mysection ul{
> position:absolute;
> right:0;
> top:-2em;
> }
>
> UL will be cut by overflow.
your above a demo of a UL cut by overflow:?
--
dorayme
Cezary Tomczyk
Nov 11, 2012, 4:34:57 PM11/11/12
to
W dniu 2012-11-11 22:09, dorayme pisze:
For example:
--------------------------
Header
|
--------------------------
Content | Sidebar
|
--------------------------
Assuming that Content and Sidebar is inside one one big <div> and I want
to move the Sidebar slightly higher then I can use:
.sidebar{
position:relative;
top: -1em;
}
If parent <div> will be have rule overflow:hidden; then Sidebar will be cut.
--------------------------
Header
|
--------------------------
Content | Sidebar
|
--------------------------
Assuming that Content and Sidebar is inside one one big <div> and I want
to move the Sidebar slightly higher then I can use:
.sidebar{
position:relative;
top: -1em;
}
If parent <div> will be have rule overflow:hidden; then Sidebar will be cut.
dorayme
Nov 11, 2012, 5:52:51 PM11/11/12
to
In article <k7p5m1$e4m$1...@speranza.aioe.org>,
The sidebar is already a bit hidden *without* overflow on the wrap.
But let's suppose your mysection has content before it or has a
top-margin to clear it from the top of the viewport. The sidebar's top
is deliberately positioned to be out out of the containing
"mysection". What would motivate anyone to put overflow on your
example there anyway?
One of the reasons to use overflow: hidden is to make a border or a
background of a containing element enclose its floated children.
--
dorayme
But let's suppose your mysection has content before it or has a
top-margin to clear it from the top of the viewport. The sidebar's top
is deliberately positioned to be out out of the containing
"mysection". What would motivate anyone to put overflow on your
example there anyway?
One of the reasons to use overflow: hidden is to make a border or a
background of a containing element enclose its floated children.
--
dorayme
Cezary Tomczyk
Nov 11, 2012, 6:13:10 PM11/11/12
to
W dniu 2012-11-11 23:52, dorayme pisze:
No, it's not. Why sidebar must be hidden by default?
> But let's suppose your mysection has content before it or has a
> top-margin to clear it from the top of the viewport. The sidebar's top
> is deliberately positioned to be out out of the containing
> "mysection". What would motivate anyone to put overflow on your
> example there anyway?
Overflow can be used on wrapper to clear floats, right? Then whatever
reason is for moving by top:-1em; overflow then cut sidebar.
If sidebar is on the very top of viewport then moving sidebar by
top:-1em; doesn't make sense.
> One of the reasons to use overflow: hidden is to make a border or a
> background of a containing element enclose its floated children.
Yes, one of the reasons.
> But let's suppose your mysection has content before it or has a
> top-margin to clear it from the top of the viewport. The sidebar's top
> is deliberately positioned to be out out of the containing
> "mysection". What would motivate anyone to put overflow on your
> example there anyway?
reason is for moving by top:-1em; overflow then cut sidebar.
If sidebar is on the very top of viewport then moving sidebar by
top:-1em; doesn't make sense.
> One of the reasons to use overflow: hidden is to make a border or a
> background of a containing element enclose its floated children.
dorayme
Nov 11, 2012, 6:48:45 PM11/11/12
to
In article <k7pbeb$4tu$1...@speranza.aioe.org>,
does not seem to me even slightly tempting to put overflow: hidden on
your markup. What would tempt or drive someone to want to? What would
their motivations be? That it cuts off the particular element in your
markup is true. But so what?
--
dorayme
Cezary Tomczyk <cezary....@gmail.com> wrote:
>
> Overflow can be used on wrapper to clear floats, right? Then whatever
> reason is for moving by top:-1em; overflow then cut sidebar.
>
I was just hoping to get you to explain with a realistic example. It
>
> Overflow can be used on wrapper to clear floats, right? Then whatever
> reason is for moving by top:-1em; overflow then cut sidebar.
>
does not seem to me even slightly tempting to put overflow: hidden on
your markup. What would tempt or drive someone to want to? What would
their motivations be? That it cuts off the particular element in your
markup is true. But so what?
--
dorayme
Cezary Tomczyk
Nov 11, 2012, 7:11:07 PM11/11/12
to
W dniu 2012-11-12 00:48, dorayme pisze:
version):
ul
li a href="url">Link1</a /li
li a href="url">Link1</a /li
/ul
(sorry about html, but NNTP provider do not allow html tags)
ul{ overflow: hidden; }
li { float:left; }
li a{ display:inline-block; }
And if you want to move <a> on :hover status slightly up, let's say
0.25em, then you can do this by (one of the solution):
ul li a:focus,
ul li a:hover{
position:realtive;
top:-0.25em;
}
Now, <a> on :hover status will be cut.
Is this realistic?
This is just an example. There could be many more situation. I can not
count every of them. Just wanted to point that clearing floats using
overflow:hidden; could be risky due to problems I described before.
> I was just hoping to get you to explain with a realistic example. It
> does not seem to me even slightly tempting to put overflow: hidden on
> your markup. What would tempt or drive someone to want to? What would
> their motivations be? That it cuts off the particular element in your
> markup is true. But so what?
Let say we have a menu based on un(ordered) list (example, very simple
> does not seem to me even slightly tempting to put overflow: hidden on
> your markup. What would tempt or drive someone to want to? What would
> their motivations be? That it cuts off the particular element in your
> markup is true. But so what?
version):
ul
li a href="url">Link1</a /li
li a href="url">Link1</a /li
/ul
(sorry about html, but NNTP provider do not allow html tags)
ul{ overflow: hidden; }
li { float:left; }
li a{ display:inline-block; }
And if you want to move <a> on :hover status slightly up, let's say
0.25em, then you can do this by (one of the solution):
ul li a:focus,
ul li a:hover{
position:realtive;
top:-0.25em;
}
Now, <a> on :hover status will be cut.
Is this realistic?
This is just an example. There could be many more situation. I can not
count every of them. Just wanted to point that clearing floats using
overflow:hidden; could be risky due to problems I described before.
EX_OWM
Nov 12, 2012, 3:09:29 PM11/12/12
to
dorayme
Nov 12, 2012, 4:55:39 PM11/12/12
to
In article <k7per0$bes$5...@speranza.aioe.org>,
> ul{ overflow: hidden; }
> li { float:left; }
> li a{ display:inline-block; }
>
> And if you want to move <a> on :hover status slightly up, let's say
> 0.25em, then you can do this by (one of the solution):
>
> ul li a:focus,
> ul li a:hover{
> position:realtive;
> top:-0.25em;
> }
>
> Now, <a> on :hover status will be cut.
>
> Is this realistic?
>
Well, I am getting the technical point, fine.
If the motivation (*still* missing from your example) was to make a
border on the UL drop to enclose the menu items, that would be a
motivation.
If an author wanted to play jiggly jiggly with links for the modern
man on the Clapham bus, and if he did not want to make a little
padding at the top of the UL, (the most natural thing to do in your
example), then yes, overflow would cut it off if you :hovered a bit
more than .25em (at .25em, on Safari, I am not seeing actual cut off,
rather I am seeing and hearing the poor hovered link bang it's head
against an included border and scream in pain. <g>)
> This is just an example. There could be many more situation. I can not
> count every of them. Just wanted to point that clearing floats using
> overflow:hidden; could be risky due to problems I described before.
Your technical point is noted. The risk is dependent on rather special
contexts which, I am getting the feeling now, are rare.
--
dorayme
Cezary Tomczyk <cezary....@gmail.com> wrote:
> W dniu 2012-11-12 00:48, dorayme pisze:
> > I was just hoping to get you to explain with a realistic example. It
> > does not seem to me even slightly tempting to put overflow: hidden on
> > your markup. What would tempt or drive someone to want to? What would
> > their motivations be? That it cuts off the particular element in your
> > markup is true. But so what?
>
> Let say we have a menu based on un(ordered) list (example, very simple
> version):
>
> ul
> li a href="url">Link1</a /li
> li a href="url">Link1</a /li
> /ul
>
> (sorry about html, but NNTP provider do not allow html tags)
>
That's OK. I know what you mean.
> W dniu 2012-11-12 00:48, dorayme pisze:
> > I was just hoping to get you to explain with a realistic example. It
> > does not seem to me even slightly tempting to put overflow: hidden on
> > your markup. What would tempt or drive someone to want to? What would
> > their motivations be? That it cuts off the particular element in your
> > markup is true. But so what?
>
> Let say we have a menu based on un(ordered) list (example, very simple
> version):
>
> ul
> li a href="url">Link1</a /li
> li a href="url">Link1</a /li
> /ul
>
> (sorry about html, but NNTP provider do not allow html tags)
>
> ul{ overflow: hidden; }
> li { float:left; }
> li a{ display:inline-block; }
>
> And if you want to move <a> on :hover status slightly up, let's say
> 0.25em, then you can do this by (one of the solution):
>
> ul li a:focus,
> ul li a:hover{
> position:realtive;
> top:-0.25em;
> }
>
> Now, <a> on :hover status will be cut.
>
> Is this realistic?
>
If the motivation (*still* missing from your example) was to make a
border on the UL drop to enclose the menu items, that would be a
motivation.
If an author wanted to play jiggly jiggly with links for the modern
man on the Clapham bus, and if he did not want to make a little
padding at the top of the UL, (the most natural thing to do in your
example), then yes, overflow would cut it off if you :hovered a bit
more than .25em (at .25em, on Safari, I am not seeing actual cut off,
rather I am seeing and hearing the poor hovered link bang it's head
against an included border and scream in pain. <g>)
> This is just an example. There could be many more situation. I can not
> count every of them. Just wanted to point that clearing floats using
> overflow:hidden; could be risky due to problems I described before.
contexts which, I am getting the feeling now, are rare.
--
dorayme
j
Nov 14, 2012, 11:28:42 AM11/14/12
to
On 11/11/2012 12:37 AM, BootNic wrote:> In article
would be poor HTML5 support.
Otherwise I write and format in Chrome. When I later look in IE8,IE9, FF
and Safari it looks very similar, but I have been at this for a while.
As much as I despise jquery, I'm using mediaelement.js to "standardize"
the audio and video tags and add basic functionality.
I see having to accommodate (HTML5 media limitations) in IE8 and IE9 for
a very long time.
Jeff
<k7n3ak$cl9$1...@news.albasani.net>, j <mun...@att.net> wrote:
>
>> I've been using these "hacks" to trigger haslayout so that a container
>> with floats will have height:
>
>> overflow:hidden; zoom:1;
>
> older versions of IE only needed zoom:1.
>
> Since IE 8, only overflow:hidden; just like any other ua.
>
>> Although this still works well for me, I wonder what is the current
>> way of dealing with this issue.
>
> Stop developing, testing, debugging for IE older then IE 8.
Seriously, who is
> going to spend/pay at least 25% more to develop for ua's 6 - 11 years
old.
I don't have any problems with IE8 that I don't also have with IE9, that
>
>> I've been using these "hacks" to trigger haslayout so that a container
>> with floats will have height:
>
>> overflow:hidden; zoom:1;
>
> older versions of IE only needed zoom:1.
>
> Since IE 8, only overflow:hidden; just like any other ua.
>
>> Although this still works well for me, I wonder what is the current
>> way of dealing with this issue.
>
> Stop developing, testing, debugging for IE older then IE 8.
Seriously, who is
> going to spend/pay at least 25% more to develop for ua's 6 - 11 years
old.
would be poor HTML5 support.
Otherwise I write and format in Chrome. When I later look in IE8,IE9, FF
and Safari it looks very similar, but I have been at this for a while.
As much as I despise jquery, I'm using mediaelement.js to "standardize"
the audio and video tags and add basic functionality.
I see having to accommodate (HTML5 media limitations) in IE8 and IE9 for
a very long time.
Jeff
Cezary Tomczyk
Nov 14, 2012, 4:25:51 PM11/14/12
to
W dniu 2012-11-12 22:55, dorayme pisze:
> If the motivation (*still* missing from your example) was to make a
> border on the UL drop to enclose the menu items, that would be a
> motivation.
>
> If an author wanted to play jiggly jiggly with links for the modern
> man on the Clapham bus, and if he did not want to make a little
> padding at the top of the UL, (the most natural thing to do in your
> example), then yes, overflow would cut it off if you :hovered a bit
> more than .25em (at .25em, on Safari, I am not seeing actual cut off,
> rather I am seeing and hearing the poor hovered link bang it's head
> against an included border and scream in pain. <g>)
Summary: just wanted to show some of example. Developers has a thousands
of solutions. Using overflow:hidden; sometimes could bring unexpected
results. That's why I think that mostly trick with :before and :after is
better.
>> This is just an example. There could be many more situation. I can not
>> count every of them. Just wanted to point that clearing floats using
>> overflow:hidden; could be risky due to problems I described before.
>
> Your technical point is noted. The risk is dependent on rather special
> contexts which, I am getting the feeling now, are rare.
Absolutely I agree.
> In article <k7per0$bes$5...@speranza.aioe.org>,
> Cezary Tomczyk <cezary....@gmail.com> wrote:
>> Is this realistic?
>>
>
> Well, I am getting the technical point, fine.
Thank you.
> Cezary Tomczyk <cezary....@gmail.com> wrote:
>> Is this realistic?
>>
>
> Well, I am getting the technical point, fine.
> If the motivation (*still* missing from your example) was to make a
> border on the UL drop to enclose the menu items, that would be a
> motivation.
>
> If an author wanted to play jiggly jiggly with links for the modern
> man on the Clapham bus, and if he did not want to make a little
> padding at the top of the UL, (the most natural thing to do in your
> example), then yes, overflow would cut it off if you :hovered a bit
> more than .25em (at .25em, on Safari, I am not seeing actual cut off,
> rather I am seeing and hearing the poor hovered link bang it's head
> against an included border and scream in pain. <g>)
of solutions. Using overflow:hidden; sometimes could bring unexpected
results. That's why I think that mostly trick with :before and :after is
better.
>> This is just an example. There could be many more situation. I can not
>> count every of them. Just wanted to point that clearing floats using
>> overflow:hidden; could be risky due to problems I described before.
>
> Your technical point is noted. The risk is dependent on rather special
> contexts which, I am getting the feeling now, are rare.
Mason Barge
Nov 15, 2012, 11:06:31 AM11/15/12
to
user anyway.
Thomas 'PointedEars' Lahn
Nov 15, 2012, 11:32:07 AM11/15/12
to
Mason Barge wrote:
> On Sat, 10 Nov 2012 21:42:27 -0500, j <mun...@att.net> wrote:
>> I've stopped using some of the old IE hacks, like those for inline-block
>> and png transparency but I see that IE6 still has significant market
>> share:
>>
>> http://www.netmarketshare.com/browser-market
> On Sat, 10 Nov 2012 21:42:27 -0500, j <mun...@att.net> wrote:
>> I've stopped using some of the old IE hacks, like those for inline-block
>> and png transparency but I see that IE6 still has significant market
>> share:
>>
>> http://www.netmarketshare.com/browser-market
>> share.aspx?qprid=2&qpcustomd=0
>>
>> Sheesh, what's it take to bury that dog?
>
> Anyone who is clueless enough to be using IE6 is not going to be my target
> user anyway.
Would that include the more than 1'347'350'000 Chinese (2011 figure) who are
>>
>> Sheesh, what's it take to bury that dog?
>
> Anyone who is clueless enough to be using IE6 is not going to be my target
> user anyway.
forced to do this in order to circumvent goverment censorship?
And all the people employed in companies who really do not have a choice?
You have no clue what you are talking about.
F'up2 ciwas
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
Dr J R Stockton
Nov 16, 2012, 3:10:27 PM11/16/12
to
In comp.infosystems.www.authoring.stylesheets message <5240908.AtD2l3LYW
C...@PointedEars.de>, Thu, 15 Nov 2012 17:32:07, Thomas 'PointedEars' Lahn
<Point...@web.de> posted:
>Mason Barge wrote:
>
>> On Sat, 10 Nov 2012 21:42:27 -0500, j <mun...@att.net> wrote:
>>> I've stopped using some of the old IE hacks, like those for inline-block
>>> and png transparency but I see that IE6 still has significant market
>>> share:
>>>
>>> http://www.netmarketshare.com/browser-market
>>> share.aspx?qprid=2&qpcustomd=0
>>>
>>> Sheesh, what's it take to bury that dog?
>>
>> Anyone who is clueless enough to be using IE6 is not going to be my target
>> user anyway.
>
>Would that include the more than 1'347'350'000 Chinese (2011 figure) who are
>forced to do this in order to circumvent goverment censorship?
You are as usual being silly. Americans, unless missionaries or
political activists, do not care about foreigners - including you.
--
(c) John Stockton, nr London UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.
C...@PointedEars.de>, Thu, 15 Nov 2012 17:32:07, Thomas 'PointedEars' Lahn
<Point...@web.de> posted:
>Mason Barge wrote:
>
>> On Sat, 10 Nov 2012 21:42:27 -0500, j <mun...@att.net> wrote:
>>> I've stopped using some of the old IE hacks, like those for inline-block
>>> and png transparency but I see that IE6 still has significant market
>>> share:
>>>
>>> http://www.netmarketshare.com/browser-market
>>> share.aspx?qprid=2&qpcustomd=0
>>>
>>> Sheesh, what's it take to bury that dog?
>>
>> Anyone who is clueless enough to be using IE6 is not going to be my target
>> user anyway.
>
>Would that include the more than 1'347'350'000 Chinese (2011 figure) who are
>forced to do this in order to circumvent goverment censorship?
political activists, do not care about foreigners - including you.
--
(c) John Stockton, nr London UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.
Ed Mullen
Nov 16, 2012, 7:11:30 PM11/16/12
to
Dr J R Stockton wrote:
> In comp.infosystems.www.authoring.stylesheets message <5240908.AtD2l3LYW
> C...@PointedEars.de>, Thu, 15 Nov 2012 17:32:07, Thomas 'PointedEars' Lahn
> <Point...@web.de> posted:
>
>> Mason Barge wrote:
>>
>>> On Sat, 10 Nov 2012 21:42:27 -0500, j <mun...@att.net> wrote:
>>>> I've stopped using some of the old IE hacks, like those for inline-block
>>>> and png transparency but I see that IE6 still has significant market
>>>> share:
>>>>
>>>> http://www.netmarketshare.com/browser-market
>>>> share.aspx?qprid=2&qpcustomd=0
>>>>
>>>> Sheesh, what's it take to bury that dog?
>>>
>>> Anyone who is clueless enough to be using IE6 is not going to be my target
>>> user anyway.
>>
>> Would that include the more than 1'347'350'000 Chinese (2011 figure) who are
>> forced to do this in order to circumvent goverment censorship?
>
> You are as usual being silly. Americans, unless missionaries or
> political activists, do not care about foreigners - including you.
>
>
Err, excuse me, but I married a "foreigner." Methinks thou art painting
> In comp.infosystems.www.authoring.stylesheets message <5240908.AtD2l3LYW
> C...@PointedEars.de>, Thu, 15 Nov 2012 17:32:07, Thomas 'PointedEars' Lahn
> <Point...@web.de> posted:
>
>> Mason Barge wrote:
>>
>>> On Sat, 10 Nov 2012 21:42:27 -0500, j <mun...@att.net> wrote:
>>>> I've stopped using some of the old IE hacks, like those for inline-block
>>>> and png transparency but I see that IE6 still has significant market
>>>> share:
>>>>
>>>> http://www.netmarketshare.com/browser-market
>>>> share.aspx?qprid=2&qpcustomd=0
>>>>
>>>> Sheesh, what's it take to bury that dog?
>>>
>>> Anyone who is clueless enough to be using IE6 is not going to be my target
>>> user anyway.
>>
>> Would that include the more than 1'347'350'000 Chinese (2011 figure) who are
>> forced to do this in order to circumvent goverment censorship?
>
> You are as usual being silly. Americans, unless missionaries or
> political activists, do not care about foreigners - including you.
>
>
with a wide and errant brush.
--
Ed Mullen
http://edmullen.net/
You ... ewe ... yew? No wonder this English is so to learn!
tlvp
Nov 17, 2012, 1:36:20 AM11/17/12
to
On Fri, 16 Nov 2012 19:11:30 -0500, Ed Mullen wrote:
> You ... ewe ... yew? No wonder this English is so to learn!
And don't forget [H]'ugh, U-, Yoo, and Yu :-) . Cheers, -- tlvp
> You ... ewe ... yew? No wonder this English is so to learn!
--
Avant de repondre, jeter la poubelle, SVP.
EX_OWM
Nov 17, 2012, 2:35:44 PM11/17/12
to
j wrote:
> On 11/11/2012 12:37 AM, BootNic wrote:> In article
> <k7n3ak$cl9$1...@news.albasani.net>, j <mun...@att.net> wrote:
>>
>>> I've been using these "hacks" to trigger haslayout so that a
>>> container with floats will have height:
>>
>>> overflow:hidden; zoom:1;
>>
>> older versions of IE only needed zoom:1.
>>
>> Since IE 8, only overflow:hidden; just like any other ua.
>>
>>> Although this still works well for me, I wonder what is the current
>>> way of dealing with this issue.
>>
>> Stop developing, testing, debugging for IE older then IE 8.
> Seriously, who is
>> going to spend/pay at least 25% more to develop for ua's 6 - 11
>> years old.
>
> I don't have any problems with IE8 that I don't also have with IE9,
> that would be poor HTML5 support.
>
> Otherwise I write and format in Chrome. When I later look in IE8,IE9,
> FF and Safari it looks very similar, but I have been at this for a
> while.
> As much as I despise jquery,
Why do you despise it?
> On 11/11/2012 12:37 AM, BootNic wrote:> In article
> <k7n3ak$cl9$1...@news.albasani.net>, j <mun...@att.net> wrote:
>>
>>> I've been using these "hacks" to trigger haslayout so that a
>>> container with floats will have height:
>>
>>> overflow:hidden; zoom:1;
>>
>> older versions of IE only needed zoom:1.
>>
>> Since IE 8, only overflow:hidden; just like any other ua.
>>
>>> Although this still works well for me, I wonder what is the current
>>> way of dealing with this issue.
>>
>> Stop developing, testing, debugging for IE older then IE 8.
> Seriously, who is
>> going to spend/pay at least 25% more to develop for ua's 6 - 11
>> years old.
>
> I don't have any problems with IE8 that I don't also have with IE9,
> that would be poor HTML5 support.
>
> Otherwise I write and format in Chrome. When I later look in IE8,IE9,
> FF and Safari it looks very similar, but I have been at this for a
> while.
> As much as I despise jquery,
Mason Barge
Nov 17, 2012, 2:42:30 PM11/17/12
to
On Thu, 15 Nov 2012 17:32:07 +0100, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:
>Mason Barge wrote:
>
>> On Sat, 10 Nov 2012 21:42:27 -0500, j <mun...@att.net> wrote:
>>> I've stopped using some of the old IE hacks, like those for inline-block
>>> and png transparency but I see that IE6 still has significant market
>>> share:
>>>
>>> http://www.netmarketshare.com/browser-market
>>> share.aspx?qprid=2&qpcustomd=0
>>>
>>> Sheesh, what's it take to bury that dog?
>>
>> Anyone who is clueless enough to be using IE6 is not going to be my target
>> user anyway.
>
>Would that include the more than 1'347'350'000 Chinese (2011 figure) who are
>forced to do this in order to circumvent goverment censorship?
Er, yes.
<Point...@web.de> wrote:
>Mason Barge wrote:
>
>> On Sat, 10 Nov 2012 21:42:27 -0500, j <mun...@att.net> wrote:
>>> I've stopped using some of the old IE hacks, like those for inline-block
>>> and png transparency but I see that IE6 still has significant market
>>> share:
>>>
>>> http://www.netmarketshare.com/browser-market
>>> share.aspx?qprid=2&qpcustomd=0
>>>
>>> Sheesh, what's it take to bury that dog?
>>
>> Anyone who is clueless enough to be using IE6 is not going to be my target
>> user anyway.
>
>Would that include the more than 1'347'350'000 Chinese (2011 figure) who are
>forced to do this in order to circumvent goverment censorship?
>And all the people employed in companies who really do not have a choice?
>You have no clue what you are talking about.
Jonathan N. Little
Nov 17, 2012, 2:47:41 PM11/17/12
to
EX_OWM wrote:
implement a simple slideshow that could easily be done in 25-50 lines of
role-your-own JavaScript.
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
> j wrote:
>> As much as I despise jquery,
>
> Why do you despise it?
>
>
Because it is often adds 500+KB of bloated, not always stable, code to
>> As much as I despise jquery,
>
> Why do you despise it?
>
>
implement a simple slideshow that could easily be done in 25-50 lines of
role-your-own JavaScript.
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
EX_OWM
Nov 18, 2012, 2:34:50 PM11/18/12
to
Jonathan N. Little wrote:
> EX_OWM wrote:
>> j wrote:
>
>>> As much as I despise jquery,
>>
>> Why do you despise it?
>>
>>
>
> Because it is often adds 500+KB of bloated, not always stable, code to
> implement a simple slideshow that could easily be done in 25-50 lines
> of role-your-own JavaScript.
That's crap code by the developer, the fact that (s)he is using jQuery is
> EX_OWM wrote:
>> j wrote:
>
>>> As much as I despise jquery,
>>
>> Why do you despise it?
>>
>>
>
> Because it is often adds 500+KB of bloated, not always stable, code to
> implement a simple slideshow that could easily be done in 25-50 lines
> of role-your-own JavaScript.
incidental, they would probably have written code every bit as bad using raw
JavaScript.
Jonathan N. Little
Nov 18, 2012, 2:50:28 PM11/18/12
to
alt.comp.lang.javascript. You should get a "warm" response.
EX_OWM
Nov 21, 2012, 2:27:43 AM11/21/12
to
Jonathan N. Little wrote:
> EX_OWM wrote:
>> Jonathan N. Little wrote:
>>> EX_OWM wrote:
>>>> j wrote:
>>>
>>>>> As much as I despise jquery,
>>>>
>>>> Why do you despise it?
>>>>
>>>>
>>>
>>> Because it is often adds 500+KB of bloated, not always stable, code
>>> to implement a simple slideshow that could easily be done in 25-50
>>> lines of role-your-own JavaScript.
>>
>> That's crap code by the developer, the fact that (s)he is using
>> jQuery is incidental, they would probably have written code every
>> bit as bad using raw JavaScript.
>>
>>
>
> Really? Why not discuss the virtues of JQuery over at
> alt.comp.lang.javascript. You should get a "warm" response.
I've never had occasion to wander in those parts but I suspect that my
> EX_OWM wrote:
>> Jonathan N. Little wrote:
>>> EX_OWM wrote:
>>>> j wrote:
>>>
>>>>> As much as I despise jquery,
>>>>
>>>> Why do you despise it?
>>>>
>>>>
>>>
>>> Because it is often adds 500+KB of bloated, not always stable, code
>>> to implement a simple slideshow that could easily be done in 25-50
>>> lines of role-your-own JavaScript.
>>
>> That's crap code by the developer, the fact that (s)he is using
>> jQuery is incidental, they would probably have written code every
>> bit as bad using raw JavaScript.
>>
>>
>
> Really? Why not discuss the virtues of JQuery over at
> alt.comp.lang.javascript. You should get a "warm" response.
reception would be something akin to the reception people used to get here
when they suggested using anything other than basic text editors for
developing websites ;)
Thomas 'PointedEars' Lahn
Nov 21, 2012, 5:52:33 AM11/21/12
to
alt.comp.lang.javascript except in archives. The international newsgroup
where ECMAScript implementations like JavaScript are on-topic that is alive
is comp.lang.javascript. Everything else that has been said about jQuery
(and the newsgroup) is correct, though, and that is good so.
F'up2 ciwas
PointedEars
--
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Ben C
Nov 27, 2012, 12:19:27 PM11/27/12
to
On 2012-11-14, Cezary Tomczyk <cezary....@gmail.com> wrote:
[...]
else (which it's true you hardly ever do).
Actually there have been one or two times when I wanted the side-effects
of overflow: hidden on floats but not the actual effect. I just put in
an empty div in with clear set on it.
IIRC the original :after "clearfix" thing worked as follows:
1. IE (6 probably) grew to fit the floats in anyway
2. More correct browsers wouldn't have, but did when they added the
clearing element in the :after
3. IE completely failed to parse the :after so was blissfully ignorant
of the whole thing, which was fine, because it had accidentally done
the right thing anyway.
This meant that for a long time the only use of :after you ever saw on
the real web was for doing "clearfixing".
[...]
> Summary: just wanted to show some of example. Developers has a
> thousands of solutions. Using overflow:hidden; sometimes could bring
> unexpected results. That's why I think that mostly trick with :before
> and :after is better.
Except for when you wanted to use :before and :after for something
> thousands of solutions. Using overflow:hidden; sometimes could bring
> unexpected results. That's why I think that mostly trick with :before
> and :after is better.
else (which it's true you hardly ever do).
Actually there have been one or two times when I wanted the side-effects
of overflow: hidden on floats but not the actual effect. I just put in
an empty div in with clear set on it.
IIRC the original :after "clearfix" thing worked as follows:
1. IE (6 probably) grew to fit the floats in anyway
2. More correct browsers wouldn't have, but did when they added the
clearing element in the :after
3. IE completely failed to parse the :after so was blissfully ignorant
of the whole thing, which was fine, because it had accidentally done
the right thing anyway.
This meant that for a long time the only use of :after you ever saw on
the real web was for doing "clearfixing".
j
Nov 28, 2012, 9:15:01 AM11/28/12
to
On 11/15/2012 11:06 AM, Mason Barge wrote:> On Sat, 10 Nov 2012 21:42:27
Well you may be more of a snob than some of my clients. If you are
providing a public service, then you care about every moron. The same if
you are selling.
I don't care if the site is beautiful or has flaws in an antique UA,
people in old browsers are used to oddities, but it should function.
Note also, the interesting point by Thomas.
providing a public service, then you care about every moron. The same if
you are selling.
I don't care if the site is beautiful or has flaws in an antique UA,
people in old browsers are used to oddities, but it should function.
Note also, the interesting point by Thomas.
Cezary Tomczyk
Nov 28, 2012, 5:25:37 PM11/28/12
to
W dniu 2012-11-27 18:19, Ben C pisze:
As I said: methods for clearing floats is "hundreds". The only one thing
is that some of them may create some unexpected results. We need to be
very carefully and test our selected methods. Nothing more.
is that some of them may create some unexpected results. We need to be
very carefully and test our selected methods. Nothing more.
0 new messages