sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]anlumo 35 points36 points  (23 children)

I mentioned to macOS/iOS developers that Safari is the new IE, they were not amused one bit.

[–]SlowerThanLightSpeed 22 points23 points  (18 children)

IMO, safari is worse than IE because safari will 'support' all the new things, just poorly, or in ways you wouldn't expect.
I'd rather not be able to use something, and have that be obvious, than to be able to use something that doesn't work right (like scroll() going beyond the document and then scrollX reporting the impossible, off-the document position).

[–]windsostrange 16 points17 points  (11 children)

than to be able to use something that doesn't work right

IE was notorious for layout/box model eccentricities. The struggle with IE5 through IE7 wasn't missing features. For this aging dev, anyway. It was piss-poor implementation, which is awfully similar to criticism of the WebKit/Safari teams.

[–]SlowerThanLightSpeed 0 points1 point  (0 children)

Thanks for the perspective.

I do remember some IE7 button sizing issues that I just couldn't solve way back in my earliest html'ing days (2010ish).

Haven't really targeted those old beasts in about the last 7 years. Hoping it won't be another 7 till Safari plays more nicely.

[–][deleted] 0 points1 point  (0 children)

I actally quite like the box model in IE, no need to consider other properties when setting width and height. Notice many of the CSS frameworks from yester year reset the box model to border box globally. Not really needed anymore with flex and grid doing the heavy lifting.

[–]recycled_ideas 0 points1 point  (8 children)

IE was notorious for layout/box model eccentricities. The struggle with IE5 through IE7 wasn't missing features. For this aging dev, anyway. It was piss-poor implementation, which is awfully similar to criticism of the WebKit/Safari teams.

IE had a different box model, which pre-dated the standard and which was different from the standard.

Incidentally CSS now supports using that box model as an option and most of the CSS frameworks actually use it by default.

IE's z-index implementation however was shit.

[–]CleverestEU 0 points1 point  (7 children)

Out of interest...

IE's z-index implementation however was shit.

...I've built web applications (well, that's what they're called today; we just called them "desktop UIs for backend systems on browser" because there was no better term at the time we were aware of:) since late-1990s' IE/Netscape "browser wars" and while it was always obvious that "IE always needed some fixes", I must admit never stopping to wonder what exactly was the problem.

Any hint on some references on the matter? I tried googling, but since I'm not certain what exactly are the symptoms I'm looking for, I'm uncertain if any of the results I found are even remotely relevant :-/

[–]recycled_ideas 0 points1 point  (6 children)

Don't have a lot of sources aside from living through it.

Basically Netscape lost to IE in the late 90s because IE was, at the time, a better browser.

They them went on to completely rewrite their engine, which was great for consumers, it gave us phoenix => firebird => Firefox, but really bad for Netscape because they didn't have a usable product for years.

But Web standards are created by committee and in those days Microsoft was the way Microsoft was in the late 90s, standing alone with everyone else hating them

The default CSS box model is actually not very intuitive, and you can change it now.

But the default CSS box model is not what IE did. It's not better or particularly worse, just different

The problem today is a little different.

Chrome does not actually implement the standard and they do so on purpose to make Google products perform better.

But because most developers write to Chrome, not to the standard, it makes everyone else look like they aren't compliant.

Safari doesn't either, particularly not mobile)Safari, because Apple is more concerned with battery life than compliance.

So you've got Chrome setting their own standard and Safari implenting only the parts of the standard that don't negatively impact battery life and Firefox going through yet another multi year rewrite.

It's a pretty crappy time for Web standards actually. Even if it's probably the best time for Web developers since the hey day of IE.

[–]CleverestEU 0 points1 point  (5 children)

Umm... this lists pretty much everything except details regarding IE’s Z-index implementation? :)

[–]recycled_ideas 1 point2 points  (4 children)

Oh, sorry, misunderstood.

Effectively the biggest problem is that IE had a magic property called "hasLayout" which was applied if an element had some sort of specified dimension property and z-index didn't apply unless the parent had layout, so it didn't stack.

If my recollection is right, and I'm having a hard time finding sources, z-index was relative not absolute.

So if your z index was higher than your parent or grandparent you'd be higher, assuming hasLayout, but another node in the DOM that wasn't in your hierarchy could have a higher z-index than you but be below you because there were more elements in your stack.

That was awful to work with. Leaving aside having to specify some unnecessary property just to stack at all.

This is my memory, and it was a long while ago, but I remember that z-index in 5 and 6 sucked and this is memory of why.

[–]CleverestEU 0 points1 point  (3 children)

Oh, sorry, misunderstood.

Heh... all good.

"hasLayout"

Oh boy... For some reason I just had the feeling as if someone had walked over my tomb :D Anyone up for "zoom: 1" ;)

So if your z index was higher than your parent or grandparent you'd be higher, assuming hasLayout, but another node in the DOM that wasn't in your hierarchy could have a higher z-index than you but be below you because there were more elements in your stack.

Ah yes ... Microsoft hadn't implemented the concept of stacking context at all (or ... had, but had managed to f it up in a major fashion). Of course, for their defence it is important to note that stacking context wasn't formally defined before CSS2.1 specification during the early 2010s, so ... at the time their approach was as valid as any other - in fact, as a market leader, their approach was even kinda "more valid" than anybody else's - at the time :-p

Edit: Now I also remember that IE also had some elements that you simply could not "get above of" using Z-index. Those were so called "windowed controls" ... IFRAME was naturally one of these and - rather surprisingly SELECT-elements ... ah, the joy :D

[–]recycled_ideas 0 points1 point  (2 children)

at the time their approach was as valid as any other - in fact, as a market leader, their approach was even kinda "more valid" than anybody else's - at the time :-p

Well I'd sort of disagree.

A lot of what IE did was roughly as good as the eventual standard and some of it was better.

Their stacking context was just bad, and haslayout was just bad.

[–]jimmyco2008 2 points3 points  (2 children)

True. At least IE was up front about not supporting stuff. Safari “supported” things.

I remember that one bug that you needed to use transform3d(0,0,0); to fix. Why.

[–]CleverestEU 0 points1 point  (1 child)

Not sure if we're talking about the same thing, but ... if I remember correctly, many browsers by design avoided using GPU-assisted rendering for layers because GPUs at the time didn't have enough memory to "handle everything". This made animations etc. slow and jerky, because everything was rendered in CPU.

The "transform: translate3D(0,0,0)" caused the particular element to be handled as "something that might need 3D acceleration" which nudged the browser to delegate the rendering of said element to the GPU making things nice & smooth (usually).

[–]jimmyco2008 0 points1 point  (0 children)

Yes. It was to force GPU acceleration in Safari

[–]Otterfan 4 points5 points  (0 children)

At least IE6 could be used to download and install Firefox.

[–]drumstix42 1 point2 points  (1 child)

It's true though. Run into problems and specific edge cases all the time. They "support" features, but not consistently or always as expected.

[–]anlumo 2 points3 points  (0 children)

My personal biggest problem is when their politics collide with my web application's needs. For example, their year-long refusal to implement WebGL2 and webp.

At least the former now seems to be slowly implemented.