Almost targeting

Original author: Eric Meyer
  • Transfer
Let me tell you a story that happened in 2002. (The exact date is forgotten, but this year is exactly.) Like many other stories, it is a long one, but, unlike some stories, it is true.

While the developers of Netscape were preparing a new release of Mozilla, the browser from which we "removed" the Navigator, we in the Technology Evangelism / Developer Support (TEDS) group checked it on popular and partner sites. On some of them, the layout was spreading. In one case, very seriously.

Quickly enough it became clear that the problem is in the sliced ​​pictures, which are put into the table. For some reason, gaps appeared between these images on some sites. After digging around, we found a reason - the Gekko engine changed the mechanism for working with strings to a more compatible with the CSS specification. Now the pictures were always “sitting” on the baseline (unless otherwise indicated) and the bottom of the line (the one for the lower remote font elements - approx. Per.) Was always present.

This was new to the world of browsers because all browsers acted like all browsers always did - they reduced the table cell to the size of the picture if there was nothing besides it. The only problem is that this behavior was incorrect. Having corrected CSS implementation errors, Gecko “broke” the layout of such sites. That is, he broke it in standard mode. In non-standard (quirks) Gekko behaved in the old way and performed focus with decreasing cells.

We contacted the developers of one of the problem sites, a well-known social network at that time (like that), and explained the situation. We already knew that they could not change doctype to go into non-standard mode, because that would break other things for them. We could not offer them a simple CSS fix of the form td img {vertical-align: bottom;}, because they had all the layout they had on the table and so we would shift all the pictures, not just the cut ones. All we could offer was an explanation of the situation, a recommendation to set all the sliced ​​images a CSS class that “clings” the images, and assurance that this will not affect other browsers.

Their answer: “No. It's your problem. All browsers do everything right, and we are not going to bother with our templates and add classes just because you broke something. ”The

truth was that we even repaired it at all - all other browsers behaved wrong. But this truth did not solve our problem. It turned out that we were faced with a choice: to roll back our CSS engine improvements or break this site and all the similar ones, which were then quite a lot. Neither one nor the other did not cause joy. And they said that without a solution to the problem - whether it is an update of the site or the browser - the product will not work. That was the case.

Let me summarize the existing situation. We:

1. Improved browser standards support.

2. Found that it spoils the layout on certain sites.

3. Their developers flatly refused to change anything on their side.

4. We had to solve the problem.

It was impossible to roll back the improvement - this affected the display of the text and affected a bunch of other things. We could not convince the developers of the site, no matter how much we explained to them, that this is part of the development of web standards and more correct browser behavior. We have two roads before us, and we could not go along any of them.

And we found the third option: “almost standard” mode, in addition to the usual standard and non-standard. Yes, that’s why the “almost standard” mode exists. If I remember the discussion correctly, for the most part I am guilty of its existence; so forgive me all those who were forced to deal with the "almost standard" mode in non-Heck browser.

We made it so that the "almost standard" mode was used to doctype the problem site - it was XHTML DOCTYPE, I must say. Along the way, we released a special DTD for IBM. They used it to validate their site, where there was a lot of all HTML invalid, and they also had the described problem. So the third display mode appeared. And all because some sites were incorrectly arranged and refused to change in order to comply with our improvements. We did this so as not to spoil a small (but popular) part of the web and at the same time improve standards support.

(By the way, this same case caused the article “ Images, Tables, and Mysterious Gaps “ to appear .)

Now, take this situation a few orders of magnitude larger — you'll get an idea of ​​what people from IE have to deal with. Exactly what we had in Netscape: on the one hand, our own past mistakes, on the other, the refusal of sites to meet our desire to better maintain standards.

Someone said that Microsoft is in a unique position that can allow it to “stand at the head”, to promote among its customers improved standards and adjustments to old sites. All right. But what if the partner multimillionaire corporation refuses to make adjustments and demands, in accordance with the long contract and its clauses about serious penalties, to make sure that the new version of IE does not break (understand "break" as you want) their corporate intranet or commercial web site. One such case is a sufficient obstacle.

All our publications on DevEdge, active assistance to sites in updating their code, CSS and JS for working with Gecko (so that nothing breaks in other browsers) and assistance in the process of improving standards support in Gecko could not help us overcome this obstacle. I had to go around.

Looking back, I can assume that this experience subconsciously influenced my agreement with the offer of browser targeting, because in a sense, this is exactly what we did with Mozilla in similar conditions. We just did it in a more implicit and unreliable way, tying everything to a specific doctype instead of some kind of reliable anchor. If we could offer that site (and all the like) a simple way to ask "draw as Mozilla 0.9" (or whatever) at the top of the page or in the server headers - they could agree.

But what if we proposed, and they would refuse and again put us before the choice to roll back the improvements or fix the browser - would we all configure it to one specific version of Mozilla instead of the last and best? My inner idealist wants to think not. The inner pragmatist nods, yes. What else could we do in these circumstances? To release a browser that would break the site, which is among the ten most popular, in the hope that they will put up with what has already been released? Knowing that this is a noticeable way, and sometimes very seriously ruin the web surfing process for our users? Not. We would release the product without CSS improvements, or we would use the default poor targeting. We didn’t have version targeting then, but we did the same thing, just hung everything up for doctype.

Short-term solution to a short-term problem? Yes. But if we hadn’t done this, how long would the poor support of the standards by Netscape / Mozilla continue, waiting for the day when this improvement can be returned without breaking a bunch of sites in front of numerous users? Maybe years. That's why we applied a weak similarity of version targeting in order to be able to improve support for standards faster. And that was more than five years ago.

So, maybe I sympathize more strongly with the difficulties of IE and the solution they proposed, because I myself went through a similar one. Not to such an extent, but the dilemma seemed no less depressing, despite the difference in scale. This should be taken into account when evaluating what I said and will say on this topic.

Also popular now: