Almost targeting
Let me tell you a story that happened in 2002. (The exact date is forgotten, but this year is the same.) Like many other stories - it is long, but, unlike some stories, it is true.
While the Netscape developers were preparing a new release of Mozilla, a browser from which we “selected” Navigator, we in the Technology Evangelism / Developer Support (TEDS) group checked it on popular and partner sites. On some of them the layout has spread. In one case - very seriously.
It quickly became clear that the problem is in the cut pictures wrapped in a table. For some reason, gaps appeared on some sites between these pictures. Having rummaged, they found the reason - the Gekko engine changed the mechanism of 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 outgoing elements of the font - note) was always present.
')
It was a novelty for the world of browsers, because all browsers did what all browsers always did — reduced the table cell to the size of the picture, if nothing else was there. The only problem is that this behavior was incorrect. Having fixed the errors of the implementation of the CSS Gekko "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 social network well known at the time (something like that), and explained the situation. We already knew that they could not change the doctype to go into a non-standard mode, because it would break other things for them. We couldn’t offer them a simple CSS fix like td img {vertical-align: bottom;} either, because they had a table layout and so we would shift all the pictures, not just the cut ones. All that we could offer was an explanation of the situation, a recommendation to set the cut CSS image class “pressing” the images, and assurances that other browsers would not be affected.
Their response: “No. It's your problem. All browsers are doing 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 the other browsers behaved incorrectly. But this truth did not solve our problem. It turned out that we were faced with a choice: roll back our improvements to the CSS engine, or break this site and all others like it, which were then quite a lot. Neither caused any joy. And they said that without a solution to the problem — whether to update the site or the browser — the product will not work. So it was.
Let me summarize the situation. We:
1. Improved standards support in the browser.
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 - it affected the display of the text and touched 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 in front of us, and we could not go on any of them.
And we found the third option: “almost standard” mode , in addition to the usual standard and non- standard mode . Yes, that is why the “almost standard” mode exists. If I remember the discussion correctly, I am largely guilty of its existence; so forgive me all those who were forced to deal with the “almost standard” mode in non-geckovic browsers.
We made it so that the “almost standard” mode was applied to the doctype of the problem site - it was XHTML DOCTYPE, I should note. Along the way, we released a special DTD for IBM. They used it to validate their site, where there were a lot of HTML-invalid ones, and they also had a described problem. So there was a third display mode. And all because some sites were incorrectly arranged and refused to change to fit our improvements. We did so in order 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 appearance of the article “ Images, Tables, and Mysterious Gaps “.)
Now, increase this situation by several orders of magnitude - you get an idea of ​​what people from IE have to deal with. Exactly as we had in Netscape: on the one hand, our own past mistakes, on the other - the failure of sites to meet our desire to better maintain standards.
Someone said that Microsoft is in a unique position, which can allow it to “take the lead”, to promote among its customers improved standards and adjustments to old sites. That's right. But what if a multi-billionaire partner corporation refuses to make adjustments and requires, in accordance with a long contract and its clauses about serious penalties, make sure that the new version of IE does not break (understand, “break” as you like) their corporate intranet or commercial web site? site. One such case is a sufficient obstacle.
All our publications on DevEdge, active assistance to sites in updates of their code, CSS and JS for working with Gekko (so that nothing is broken in other browsers) and assistance in the process of improving Gekko standards support 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 browser targeting proposal, because in a certain 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 reliable anchor. If we could offer that site (and all the like) a simple way to ask for “draw as Mozilla 0.9” (or whatever else) at the top of the page or in the server headers - they could agree.
And what if we offered, and they would refuse and again would have confronted us with the choice to roll back the improvements or fix the browser - would we all set up for a specific version of Mozilla instead of the last and best? My inner idealist wants to think no. The inner pragmatist nods that yes. And what else could we do in these circumstances? To release a browser that would break the site, which is among the top ten, in the hope that they will accept the fact that they have already been released? Knowing that this is a noticeable way, and sometimes very seriously spoil the process of web surfing for our users? Not. We would have released a product with no improvements on the part of CSS, or we would use the default targeting as bad. We didn’t have version targeting at the time, but we did the same thing, we just hung it up on the doctype.
A short-term solution to a short-term problem? Yes. But if we hadn’t done this, how long would the bad support of Netscape / Mozilla’s standards continue in anticipation of the day when it will be possible to return this improvement without breaking a bunch of sites before numerous users? Perhaps years. That is why we applied a weak similarity to version targeting in order to be able to improve standards support more quickly. And it was more than five years ago.
So, maybe I am more sympathetic to the difficulties of IE and the solution proposed by them, because I myself have gone through this. Not so much, but the dilemma seemed no less depressing, despite the difference in scale. This should be taken into account, assessing what I said and will say on this topic.
While the Netscape developers were preparing a new release of Mozilla, a browser from which we “selected” Navigator, we in the Technology Evangelism / Developer Support (TEDS) group checked it on popular and partner sites. On some of them the layout has spread. In one case - very seriously.
It quickly became clear that the problem is in the cut pictures wrapped in a table. For some reason, gaps appeared on some sites between these pictures. Having rummaged, they found the reason - the Gekko engine changed the mechanism of 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 outgoing elements of the font - note) was always present.
')
It was a novelty for the world of browsers, because all browsers did what all browsers always did — reduced the table cell to the size of the picture, if nothing else was there. The only problem is that this behavior was incorrect. Having fixed the errors of the implementation of the CSS Gekko "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 social network well known at the time (something like that), and explained the situation. We already knew that they could not change the doctype to go into a non-standard mode, because it would break other things for them. We couldn’t offer them a simple CSS fix like td img {vertical-align: bottom;} either, because they had a table layout and so we would shift all the pictures, not just the cut ones. All that we could offer was an explanation of the situation, a recommendation to set the cut CSS image class “pressing” the images, and assurances that other browsers would not be affected.
Their response: “No. It's your problem. All browsers are doing 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 the other browsers behaved incorrectly. But this truth did not solve our problem. It turned out that we were faced with a choice: roll back our improvements to the CSS engine, or break this site and all others like it, which were then quite a lot. Neither caused any joy. And they said that without a solution to the problem — whether to update the site or the browser — the product will not work. So it was.
Let me summarize the situation. We:
1. Improved standards support in the browser.
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 - it affected the display of the text and touched 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 in front of us, and we could not go on any of them.
And we found the third option: “almost standard” mode , in addition to the usual standard and non- standard mode . Yes, that is why the “almost standard” mode exists. If I remember the discussion correctly, I am largely guilty of its existence; so forgive me all those who were forced to deal with the “almost standard” mode in non-geckovic browsers.
We made it so that the “almost standard” mode was applied to the doctype of the problem site - it was XHTML DOCTYPE, I should note. Along the way, we released a special DTD for IBM. They used it to validate their site, where there were a lot of HTML-invalid ones, and they also had a described problem. So there was a third display mode. And all because some sites were incorrectly arranged and refused to change to fit our improvements. We did so in order 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 appearance of the article “ Images, Tables, and Mysterious Gaps “.)
Now, increase this situation by several orders of magnitude - you get an idea of ​​what people from IE have to deal with. Exactly as we had in Netscape: on the one hand, our own past mistakes, on the other - the failure of sites to meet our desire to better maintain standards.
Someone said that Microsoft is in a unique position, which can allow it to “take the lead”, to promote among its customers improved standards and adjustments to old sites. That's right. But what if a multi-billionaire partner corporation refuses to make adjustments and requires, in accordance with a long contract and its clauses about serious penalties, make sure that the new version of IE does not break (understand, “break” as you like) their corporate intranet or commercial web site? site. One such case is a sufficient obstacle.
All our publications on DevEdge, active assistance to sites in updates of their code, CSS and JS for working with Gekko (so that nothing is broken in other browsers) and assistance in the process of improving Gekko standards support 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 browser targeting proposal, because in a certain 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 reliable anchor. If we could offer that site (and all the like) a simple way to ask for “draw as Mozilla 0.9” (or whatever else) at the top of the page or in the server headers - they could agree.
And what if we offered, and they would refuse and again would have confronted us with the choice to roll back the improvements or fix the browser - would we all set up for a specific version of Mozilla instead of the last and best? My inner idealist wants to think no. The inner pragmatist nods that yes. And what else could we do in these circumstances? To release a browser that would break the site, which is among the top ten, in the hope that they will accept the fact that they have already been released? Knowing that this is a noticeable way, and sometimes very seriously spoil the process of web surfing for our users? Not. We would have released a product with no improvements on the part of CSS, or we would use the default targeting as bad. We didn’t have version targeting at the time, but we did the same thing, we just hung it up on the doctype.
A short-term solution to a short-term problem? Yes. But if we hadn’t done this, how long would the bad support of Netscape / Mozilla’s standards continue in anticipation of the day when it will be possible to return this improvement without breaking a bunch of sites before numerous users? Perhaps years. That is why we applied a weak similarity to version targeting in order to be able to improve standards support more quickly. And it was more than five years ago.
So, maybe I am more sympathetic to the difficulties of IE and the solution proposed by them, because I myself have gone through this. Not so much, but the dilemma seemed no less depressing, despite the difference in scale. This should be taken into account, assessing what I said and will say on this topic.
Source: https://habr.com/ru/post/31382/
All Articles