simpler example of the padding bug

On Fri, 12 May 2006 01:29:17 +0800 ironcorona <iron.corona (AT) gmail (DOT) com> wrote:

Personally I think; if it works it works. I'm not trying to convert
anyone over to anything here and I tend to stay out of the debate. I
prefer not to use tables for layout simply because I find them confusing
after a certain level of complexity. My brother, on the other hand, who
is a professional programmer (but not web designer) uses tables to
layout all his pages. It doesn't really bother me. I think the point
is you have to make the page viewable to the most people under many,
varying conditions.

I'm a programmer (academically since 1972, professionally since 1979).
Maybe there's something about the way some programmers think that make
tables "obvious" to us. You can see in some of my older pages that I
have made heavy use of tables, including programs generating them in C,
PHP, and Pike.

For instance, it's a good idea to see if things look good in a
text-browser (lynx on linux). Probably no one will be viewing it on one
but screen readers use similar technology to parse the pages. The point
there is; do you think people with certain disabilities should be
facilitated? I'm not pushing a point here, they're just questions I
think you have to ask yourself as a web designer.

I personally like to use CSS because I think the pages look more elegant
and clean. That's just me.

It depends on what you (as viewer) want out of the page, and what you (as
author) want to put in the page. If I'm making a page to document some
program I wrote, I do things quite different than if I'm making a page to
sell the services of some business client.

[snip]

FWIW, I have managed to get _all_ of my family, and several non-techie
friends, to switch to Firefox. All that have switched like it and will
be staying with it. Of the friends that did not switch, half of them
already were using Firefox.

As regards my family, me too. As regards my friends. Not so much.
They're too used to clicking the big blue E on the desktop. AND the

Move the big blue E to a subfolder. Name it "cesspool".

fact that many of them are still mainly using the Internet in University
or their office where they can't download and install anything. Many

They should be calling tech support every day they see a page that will not
show up correctly even though correctly designed and validates strict.

people simply can't convert over. In fact, my dad uses FF for all his
browsing at home but still has to switch over to IE for his
online-banking because the bank will only support IE. I've actually

He needs to be calling the bank and speaking to someone with responsibility.
The thing to do is ask when talking to someone if they have responsibility.
If not, tell that person that they are calling to speak to someone with
responsibility.

heard this from many people. Banks, in particular, tend to have old,
stable systems, and can't really afford to change over.

Quite a number of banks have been broken into. I don't call that stable.

If you want to see Microsoft Internet Explorer continue to be used (such
as because you hold stock in MSFT) then you should urge Microsoft to make
their software work with standards better, including W3C web standards and
OpenDocument standards (at least for import and export). Trying to urge
people to design for IE is not the right way. Urging them to find some
reasonable middle ground appropriate for their particular audience is fine.

Don't get me wrong. I think that IE is an awful product that should
never have been released. I'm even having a look at the beta version of
the new IE7, which *still* doesn't conform. Reading the MSIE blog;
they've said that when it ships that it still won't be ready to conform.
I wonder why the hell they're bothering to release the product if it's
still broken.

They think it does conform ... to the defacto standards they are pushing.

The simple fact is that too many people use IE and since MS have that
market share there is no conceivable reason for them to rewrite all the
broken code, in the near future. It sucks but we have to live with it.

Every reason you see that someone still has to use IE is a reason you and
I both need to be trying harder to get them to change. If someone has to
use IE _only_ for the bank, they might eventually realize their bank is
the issue.

Ironically, I'm considering a move from my current bank because its branch
location is inconvenient for me. I opened an account there when it was
convenient. While I don't do any banking online, and specifically have my
account marked as disabled for internet access, your stories have convinced
me I need to ask some new questions when looking for a new bank (there are
about 6 I've identified so far with reasonably convenient locations that
could be my choice, including 2 of them with local main headquarters). So
one of the questions I will ask is "Which web browsers are supported by
your online banking web site, and your other web services?". Or maybe "Is
your online banking web site compliant with current web standards?".

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

On Fri, 12 May 2006 03:08:37 +0800 ironcorona <iron.corona (AT) gmail (DOT) com> wrote:

phil-news-nospam (AT) ipal (DOT) net wrote:
Here is a simpler (no drop shadows) example of the padding bug I see:

http://phil.ipal.org/usenet/ciwas/20...buttons-1.html

So far I find nothing in the CSS2 document that says I should get this
kind of inconsistent result.

Okay, I've solved your problem.

First though, a bit of a markup problem:

You have the table <div>s wrapped in <p> tags. <p> can only contain
inline elements

http://www.w3.org/TR/html4/struct/text.html#edef-P

This has nothing to do with the padding error.


If you take away the cell's padding then you have specified that the
button's content and the cell's content are *exactly* the same size
(100%). It seems that borders on the left cannot overlap so the cell
pushes the content 1px over to the right. This 1px overlap seems to
continue even after there is padding added to the cell.

I assume this is with padding:0 but is this with border:0 or border:1px?

Now add the 2px padding to the cell.

Since you have defined the cell and the button to be the same size
(because you have defined the button as being width:100% when you add
3px padding-left to the button; the cell must also add 3px of width to
compensate (because they're the same size remember).

Right. So the cell is 3px larger, horizontally. This should, and does,
happen with 3px added to left only, or 3px added to right only, or 1px on
the left with 2px on the right, or 2px on the left with 1px on the right.

Experiment: Add 3px of padding-left to the button. What you see is that
the button moves out 6px. Now look where the button border is
*relative* to the cell border: Before the padding-left was added there
was no gap between the button border and the cell border. When you add
the 3px padding-left the button border-right ends up 2px to the right of
the cell border-right (exactly where you'd expect *relatively*). So 1px

No, I would _expect_ the button border-right to be just left of the cell
border-right, with no gap between, whether button padding-left is 0 or 3px.

right means the borders would overlap. 2px right means the button
border is 1px to the right of the cell border. And finally 3px right
brings the border to 2px to the right of the cell. So it's in the
correct position relative to the cell but the compensation that the cell
creates because the button and the cell are the *same* size makes the
doubling.

The compensation should be the same. The cell content box (the inner
edge of the border when the cell has padding:0) should get wider by 3px.
The button content box will stay the same width. But the inner edge of
the button border should be 3px wider, of which the first 3px of that
is the padding area.

Here's my ASCII ART illustration:

With both cell and button having padding:0 and border:1px we would see
the borders right together with no gap between:

+--<this is the cell border>---------------------+

+--<this is the button border>-----------------+|
|This is the outermost pixels of button content||
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX||
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX||
+----------------------------------------------+|
+------------------------------------------------+

The content widthe is 46, so the button border is 48 and the cell border
is 50 wide.

Adding button{padding-left:3px} we SHOULD (IMHO) have the following with
dots for the padding area:

+-----<this is the cell border>---------------------+

+-----<this is the button border>-----------------+|
|...This is the outermost pixels of button content||
|...XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ||
|...XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ||
+-------------------------------------------------+|
+---------------------------------------------------+

The content area has moved to the right by 3px and the cell is enlarged
to compensate. Now the button border is 51 wide and the cell border is
53 wide.

But what Firefox 1.5.0.3 gives is MORE than that:

+-----<this is the cell border>---------------------+

+-----<this is the button border>--------------------+
|...This is the outermost pixels of button content???|
|...XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ???|
|...XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ???|
+----------------------------------------------------+
+---------------------------------------------------+

This is all the same as what I would expect EXCEPT that the extra space
exists within the confines of the button border. I just don't know if
it is content or padding. It is colored with the background-color, but
both content and padding would have that, so this is not indicative.
I filled the unknown part with question marks. The button border is 54
wide and the cell broder is 53 wide.

So tell me what YOU think is what that area with the question marks is.
Is it false padding? Is it content growing by 3px to 49?

I _suspect_ that the layout phase (calculating where everything is to be
rendered) is working correctly, but that the rendering phase (making the
appropriate calls to do graphical drawing) is working with dimensions
that are not the same as used in layout. It is _drawing_ the button as
if there was padding-left:3px _and_ padding-right:3px (thought that may
not be the mechanism of how that happens). I also believe it is NOT a
case of accidentally picking up a number from the padding-left variable
when it should pick up a number from the padding-right variable, because
doing all of this with padding-right:3px instead still gives the same
effect of widening the button more than widening the cell. That leaves
the content shifted left as in:

+-----<this is the cell border>---------------------+

+-----<this is the button border>--------------------+
|This is the outermost pixels of button content...???|
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX... ???|
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX... ???|
+----------------------------------------------------+
+---------------------------------------------------+

Or maybe:

+-----<this is the cell border>---------------------+

+-----<this is the button border>--------------------+
|This is the outermost pixels of button content???...|
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX??? ...|
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX??? ...|
+----------------------------------------------------+
+---------------------------------------------------+

I don't know whether the excess width is something added to the content
or to the padding. But that's probably moot. I just don't want to show
that I'm assuming one or the other of those.

What I think button{padding-right:3px} should do is:

+-----<this is the cell border>---------------------+

+-----<this is the button border>-----------------+|
|This is the outermost pixels of button content...||
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX... ||
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX... ||
+-------------------------------------------------+|
+---------------------------------------------------+

The same restrictions don't seem to hold on the top and bottom borders
which is why you didn't see any padding problem on the vertical axis.

I don't see any "restrictions" that should increase the space inside the
button border by more than 3px when adding button{padding-left:3px}.

Whatever explanation you might give as to why I should get what I did get
should explain what that extra area with the question marks is.

This is why it seems to work when you take out the width:100%;

Seems?

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

Neredbojias wrote:

Sure, no argument here. But if "suddenly" a significant percentage of
websites were unreadable in IE, the ratio would change.

I see your point now. Agreed!

--
Brian O'Connor (ironcorona)

phil-news-nospam (AT) ipal (DOT) net wrote:

On Fri, 12 May 2006 03:08:37 +0800 ironcorona <iron.corona (AT) gmail (DOT) com> wrote:
| phil-news-nospam (AT) ipal (DOT) net wrote:
|> Here is a simpler (no drop shadows) example of the padding bug I see:
|
|> http://phil.ipal.org/usenet/ciwas/20...buttons-1.html
|
|> So far I find nothing in the CSS2 document that says I should get this
|> kind of inconsistent result.
|
| Okay, I've solved your problem.
|
| First though, a bit of a markup problem:
|
| You have the table <div>s wrapped in <p> tags. <p> can only contain
| inline elements
|
| http://www.w3.org/TR/html4/struct/text.html#edef-P
|
| This has nothing to do with the padding error.
|
|
| If you take away the cell's padding then you have specified that the
| button's content and the cell's content are *exactly* the same size
| (100%). It seems that borders on the left cannot overlap so the cell
| pushes the content 1px over to the right. This 1px overlap seems to
| continue even after there is padding added to the cell.

I assume this is with padding:0 but is this with border:0 or border:1px?

This was with border:1px;. The only thing changed at this point is
setting the padding to 0px.

| Now add the 2px padding to the cell.
|
| Since you have defined the cell and the button to be the same size
| (because you have defined the button as being width:100% when you add
| 3px padding-left to the button; the cell must also add 3px of width to
| compensate (because they're the same size remember).

Right. So the cell is 3px larger, horizontally. This should, and does,
happen with 3px added to left only, or 3px added to right only, or 1px on
the left with 2px on the right, or 2px on the left with 1px on the right.


| Experiment: Add 3px of padding-left to the button. What you see is that
| the button moves out 6px. Now look where the button border is
| *relative* to the cell border: Before the padding-left was added there
| was no gap between the button border and the cell border. When you add
| the 3px padding-left the button border-right ends up 2px to the right of
| the cell border-right (exactly where you'd expect *relatively*). So 1px

No, I would _expect_ the button border-right to be just left of the cell
border-right, with no gap between, whether button padding-left is 0 or 3px.

But that would imply that the button is inside the cell. But they're
the same size (horizontally). So it can't be inside.

| right means the borders would overlap. 2px right means the button
| border is 1px to the right of the cell border. And finally 3px right
| brings the border to 2px to the right of the cell. So it's in the
| correct position relative to the cell but the compensation that the cell
| creates because the button and the cell are the *same* size makes the
| doubling.

The compensation should be the same. The cell content box (the inner
edge of the border when the cell has padding:0) should get wider by 3px.
The button content box will stay the same width. But the inner edge of
the button border should be 3px wider, of which the first 3px of that
is the padding area.

Here's my ASCII ART illustration:

With both cell and button having padding:0 and border:1px we would see
the borders right together with no gap between:

+--<this is the cell border>---------------------+
|+--<this is the button border>-----------------+|
||This is the outermost pixels of button content||
||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX||
||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX||
|+----------------------------------------------+|
+------------------------------------------------+

The content widthe is 46, so the button border is 48 and the cell border
is 50 wide.

But you've told the browser that they're THE SAME SIZE. (width:100%.
So in your above example the content area of the cell is 48px in width.
But you've said they're the same size so that makes the content area
of the button 48px.

The border is the problem. Borders on the left don't overlap. If you
take off the border all together (and change the background colour of
the cell, just so you can see it) you'll see there's no problem.

All of your drawn examples are flawed because they assume that the
button is inside the cell.

I _suspect_ that the layout phase (calculating where everything is to be
rendered) is working correctly, but that the rendering phase (making the
appropriate calls to do graphical drawing) is working with dimensions
that are not the same as used in layout. It is _drawing_ the button as
if there was padding-left:3px _and_ padding-right:3px

No it's not.

| The same restrictions don't seem to hold on the top and bottom borders
| which is why you didn't see any padding problem on the vertical axis.

I don't see any "restrictions" that should increase the space inside the
button border by more than 3px when adding button{padding-left:3px}.

Because they're the same size as each other. So you get 3px padding in
the button. You get 3px bigger in the cell (because they're the same
size) and then you get the 3px more on the button to put it in the
correct relative position position.

| This is why it seems to work when you take out the width:100%;

Seems?

Bad wording choice. This is why it WORKS when you take out the width:100%;

--
Brian O'Connor (ironcorona)

Neredbojias wrote:

To further the education of mankind, ironcorona <iron.corona (AT) gmail (DOT) com
vouchsafed:

I meant that from the perspective of "if you want the greatest amount
of people *possible* to view your site then you just have to live
with it".
I don't mean that anyone is forcing you to do what Bill says.
I mean hell; if you really want to you can programme and distribute
your own browsers that only read your own, brand-new markup language.
It just wouldn't make people want to view your web pages.

That would be taking a valid concept to an invalid extreme.

That's true but what you're saying is IE will go away if we all close
our eyes and hope it does.

--
Brian O'Connor (ironcorona)

On Fri, 12 May 2006 11:14:40 +0800 ironcorona <iron.corona (AT) gmail (DOT) com> wrote:

phil-news-nospam (AT) ipal (DOT) net wrote:
On Fri, 12 May 2006 03:08:37 +0800 ironcorona <iron.corona (AT) gmail (DOT) com> wrote:
| phil-news-nospam (AT) ipal (DOT) net wrote:
|> Here is a simpler (no drop shadows) example of the padding bug I see:
|
|> http://phil.ipal.org/usenet/ciwas/20...buttons-1.html
|
|> So far I find nothing in the CSS2 document that says I should get this
|> kind of inconsistent result.
|
| Okay, I've solved your problem.
|
| First though, a bit of a markup problem:
|
| You have the table <div>s wrapped in <p> tags. <p> can only contain
| inline elements
|
| http://www.w3.org/TR/html4/struct/text.html#edef-P
|
| This has nothing to do with the padding error.
|
|
| If you take away the cell's padding then you have specified that the
| button's content and the cell's content are *exactly* the same size
| (100%). It seems that borders on the left cannot overlap so the cell
| pushes the content 1px over to the right. This 1px overlap seems to
| continue even after there is padding added to the cell.

I assume this is with padding:0 but is this with border:0 or border:1px?

This was with border:1px;. The only thing changed at this point is
setting the padding to 0px.


| Now add the 2px padding to the cell.
|
| Since you have defined the cell and the button to be the same size
| (because you have defined the button as being width:100% when you add
| 3px padding-left to the button; the cell must also add 3px of width to
| compensate (because they're the same size remember).

Right. So the cell is 3px larger, horizontally. This should, and does,
happen with 3px added to left only, or 3px added to right only, or 1px on
the left with 2px on the right, or 2px on the left with 1px on the right.


| Experiment: Add 3px of padding-left to the button. What you see is that
| the button moves out 6px. Now look where the button border is
| *relative* to the cell border: Before the padding-left was added there
| was no gap between the button border and the cell border. When you add
| the 3px padding-left the button border-right ends up 2px to the right of
| the cell border-right (exactly where you'd expect *relatively*). So 1px

No, I would _expect_ the button border-right to be just left of the cell
border-right, with no gap between, whether button padding-left is 0 or 3px.

But that would imply that the button is inside the cell. But they're
the same size (horizontally). So it can't be inside.

Not they are not the same size. The button is inside the cell.

| right means the borders would overlap. 2px right means the button
| border is 1px to the right of the cell border. And finally 3px right
| brings the border to 2px to the right of the cell. So it's in the
| correct position relative to the cell but the compensation that the cell
| creates because the button and the cell are the *same* size makes the
| doubling.

The compensation should be the same. The cell content box (the inner
edge of the border when the cell has padding:0) should get wider by 3px.
The button content box will stay the same width. But the inner edge of
the button border should be 3px wider, of which the first 3px of that
is the padding area.

Here's my ASCII ART illustration:

With both cell and button having padding:0 and border:1px we would see
the borders right together with no gap between:

+--<this is the cell border>---------------------+
|+--<this is the button border>-----------------+|
||This is the outermost pixels of button content||
||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX||
||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX||
|+----------------------------------------------+|
+------------------------------------------------+

The content widthe is 46, so the button border is 48 and the cell border
is 50 wide.

But you've told the browser that they're THE SAME SIZE. (width:100%.

They were not the same size. Nor would I expect them to be. Firefox
did as I expected, not as you are explaining.

So in your above example the content area of the cell is 48px in width.
But you've said they're the same size so that makes the content area
of the button 48px.

No. The available space for the button is inside the cell just as it
describes in 10.3.3 of CSS2.

The border is the problem. Borders on the left don't overlap. If you
take off the border all together (and change the background colour of
the cell, just so you can see it) you'll see there's no problem.

All of your drawn examples are flawed because they assume that the
button is inside the cell.

That's because the button _is_ inside the cell. They exactly and correctly
represent my expectation. AND ... they also represent how Firefox really
did calculate the layout.

I _suspect_ that the layout phase (calculating where everything is to be
rendered) is working correctly, but that the rendering phase (making the
appropriate calls to do graphical drawing) is working with dimensions
that are not the same as used in layout. It is _drawing_ the button as
if there was padding-left:3px _and_ padding-right:3px

No it's not.

It really is. That is _exactly_ the display I get from Firefox. Every
position location figured by layout is _exactly_ where I expect it to
be. The _only_ difference between what Firefox displays and what I think
it should display is the extend of the button being drawn ... it _exactly_
3px further to the right than I think it should be, which makes it exactly
6px wider than w/o the padding-left:6px.

| The same restrictions don't seem to hold on the top and bottom borders
| which is why you didn't see any padding problem on the vertical axis.

I don't see any "restrictions" that should increase the space inside the
button border by more than 3px when adding button{padding-left:3px}.

Because they're the same size as each other. So you get 3px padding in
the button. You get 3px bigger in the cell (because they're the same
size) and then you get the 3px more on the button to put it in the
correct relative position position.

The button is wider by a total of 6 px. The _border_ of the button is not
changed in position. The _content_ of the button moves to the right by
_only_ 3px (as I expect it to for padding-left:3px). The right side of
the button border _should_ (also) move to the right by 3px but instead,
it moves to the right by 6px.

Bad wording choice. This is why it WORKS when you take out the width:100%;

Without width:100% an entirely different path of calculations is performed
in the code. That's why I'm studying the code for width:100%.

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

phil-news-nospam (AT) ipal (DOT) net wrote:

That's because the button _is_ inside the cell. They exactly and correctly
represent my expectation. AND ... they also represent how Firefox really
did calculate the layout.

No, it's not. How could it be. You have told the browser that the
button is to be 100% of the cell. To pick an arbitrary figure this
means that if the width of the cell is 50px then the width of the button
MUST be 50px. What is 100% of 50px? 50px, of course.

50px CAN NOT fit inside 50px.

--
Brian O'Connor (ironcorona)

On Fri, 12 May 2006 02:18:02 -0400 Neredbojias <http://www.neredbojias.com/fliam.php?cat=alt.html> wrote:

To further the education of mankind, ironcorona <iron.corona (AT) gmail (DOT) com
vouchsafed:

I mean hell; if you really want to you can programme and distribute
your own browsers that only read your own, brand-new markup language.
It just wouldn't make people want to view your web pages.

That would be taking a valid concept to an invalid extreme.

That's true but what you're saying is IE will go away if we all close
our eyes and hope it does.

No, I was implying that even mighty MS has to respect trends. IE could not
have lasted forever as an inferior browser/whatchamacallit. The point is
moot, anyway, since there is an IE7 in the offing.

Which is letting them maintain an "arm's distance" from web standards.

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

On Fri, 12 May 2006 16:21:12 +0800 ironcorona <iron.corona (AT) gmail (DOT) com> wrote:

phil-news-nospam (AT) ipal (DOT) net wrote:

That's because the button _is_ inside the cell. They exactly and correctly
represent my expectation. AND ... they also represent how Firefox really
did calculate the layout.

No, it's not. How could it be. You have told the browser that the
button is to be 100% of the cell. To pick an arbitrary figure this
means that if the width of the cell is 50px then the width of the button
MUST be 50px. What is 100% of 50px? 50px, of course.

50px CAN NOT fit inside 50px.

I interpret the standard a different way that you seem to. And Firefox
did do the layout as I expected. It just did one aspect of drawing in a
different way.

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

On Fri, 12 May 2006 20:49:58 -0400 Neredbojias <http://www.neredbojias.com/fliam.php?cat=alt.html> wrote:

To further the education of mankind, phil-news-nospam (AT) ipal (DOT) net
vouchsafed:

|> That's true but what you're saying is IE will go away if we all
|> close our eyes and hope it does.
|
| No, I was implying that even mighty MS has to respect trends. IE
| could not have lasted forever as an inferior browser/whatchamacallit.
| The point is moot, anyway, since there is an IE7 in the offing.

Which is letting them maintain an "arm's distance" from web standards.

Maybe, maybe not. While precedence has taught us to be cynical, who
knows?, IEx just might turn into a "model citizen". If Microsoft has any
real brains, it will...

Reports from beta testers indicate disappointment. Apparently they do
not even fully comply with CSS2, which has been out how many years?

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------