By: Almost Standards Mode or How to Fit a Square Peg into a Round Hole « Synthesize this…

Mon, 03 Jan 2011 04:17:58 +0000

[...] by creating Almost Standards Mode and has a lovely, detailed post about how the new mode came about here. And, this page has a great explanation of how and why to implement the different [...]

By: About the meta IE8 switching tag « The Universe Divided

About the meta IE8 switching tag « The Universe Divided — Thu, 11 Dec 2008 14:55:29 +0000

[...] had their say in it already. Now it’s my turn, d*** it! It was kind of weird to see Zeldman, Meyer and PPK all agree on something that seems it would have to be appalling to standardistas, in the [...]

By: Twenty Sided » Blog Archive » Catching up with Web Standards

Twenty Sided » Blog Archive » Catching up with Web Standards — Fri, 28 Mar 2008 16:00:29 +0000

[...] on the digital one. Eric Meyer has a beautiful example of a problem that has no right answer: You can either conform to the specs or you can make it work. In a perfect world these two actions would be identical, not mutually exclusive. This intrusion of [...]

By: Richard Rutter

Richard Rutter — Thu, 21 Feb 2008 14:15:52 +0000

a page will be able to tell [IE] at which stage of IE"s evolution it was developed, and should thus be treated

Thank you for putting it so succinctly. This is the crux of my argument too, and why I (reluctantly) agree with the default versioning behaviour proposed by MS.

By: ThePickards » Blog Archive » IE8 Meta

ThePickards » Blog Archive » IE8 Meta — Wed, 13 Feb 2008 00:58:58 +0000

[...] they were even interested in my opinion in the first place. Plus, having read what Roger and Eric have to say on it, as well as the 600+ comments on the IE blog entry, plus what Chris Wilson had to [...]

By: mynth

mynth — Tue, 12 Feb 2008 20:14:06 +0000

so in 2015 i will have in my head section something like this:

<br /> <head></p> <p>?</p> <p>if in ie9 i put “ie 8 compatible tag” it will be rendered with ie 8 engine, or ie 9 engine. </p> <p>Will ie11 have 20 engines for every version?</p> </article> <article> <h1>By: Austin Cheney</h1> <p>Austin Cheney — Fri, 08 Feb 2008 15:11:45 +0000</p> I agree with the direction IE8 is taking. The problem is that people are confusing standards for requirements. According to the <abbr title="World Wide Web Consortium">W3C</abbr> the standards are recommendations and not requirements. The <abbr title="World Wide Web Consortium">W3C</abbr> provides standards that are relegated to mere guidance while the browser vendors provide the requirements. This is not my desire to favor browser vendors, but the reality in which the internet exists. <strong>Identifying the problem - faulty reasoning</strong> The problem is confusion between those <abbr title="recommendations and requirements">"R"</abbr> words. If the standards are not requirements then the idealism for standards lust based arguments looses idealistic appeal. The rational result is to ensure the recommendations become requirements, or at least enforceable options. <strong>Identifying the solution - a migratory path for browser vendors</strong> Unfortunately the standards are written as doctypes and not schema, so validation of code is not capable of being enforced. Browser vendors are more capable of enforcing the standards that are otherwise unenforceable merely through field use. The solution to the noted problem is help browser vendors carry the torch of standards enforcement. Notice that I said <b><em>standards enforcement</em></b> and not <b><em>standards compliance</em></b>. In order to achieve this most desirable solution without immediate alienation of backwards conformance browser vendors must adhere to a three part plan: <b>1) - Abandon slackware:</b> Browser vendors must implement an optional standards mode that fails on non-compliant pages. This will allow designers to create future compatible content that is nothing less than well formed. In the case of IE8 the IE8 processing engine must be optional if it actually wishes to be strict to the standards. Internet users must be aware that IE8 is not requiring conformance to the standards of IE8, but it will. This allows content owners to get their assets up to par before they are exposed as flawed, archaic, or simply incompetent. This would also satisfy the requirement of point 3 - timely notice. <b>2) - Version control:</b> Browser vendors must implement a version control system to warn web content owners that the browser will significantly limit backwards compatibility in future versions. This will allow time necessary for content owners to conform to the standards before their pages begin to break. <b>3) - Timely notice:</b> Browser vendors must make public what a browser version will no longer support and what new features it will support 9-18 months in advance to allow the market to prepare for those changes. Without timely notice the previous two points are irrelevant. The point of timely notice is not to benefit designers or asset owners, but to protect the browser vendors. Browser vendors must view themselves as always legally liable and take steps accordingly to continually provide innovation while ending support for older versions that impair such innovation. <strong>Intended result - standards become requirements</strong> The goal is not to improve code. The goal is to make content asset owners aware that archaic content and markup methods will expire and that it is their liability to stay up to date. Without liability there are no requirements. <strong>The only alternative - abandoning <abbr title="hyper text markup language">HTML</abbr></strong> If standards are important they would be enforceable. If browser conformance to those standards were important then they would be given the liability of enforcement. If the mentioned steps are too much to ask for then HTML creation will never be standards conforming. Requirements are extreme in their strictness and lack of compromise or they are not requirements. If standards are not entirely followed then they are not standards. If the mentioned steps are not appetizing then simply abandon HTML. Create a new markup language that is more semantic and defined by schema so that validation is a requirement. </article> <article> <h1>By: Leszek Swirski</h1> <p>Leszek Swirski — Thu, 07 Feb 2008 02:34:31 +0000</p> <p>Brian Warshaw: You seem to be the first person to be speaking any sense.</p> <p>The whole point of this proposal is to “not break the web”, not to “not break the web after <strong>every</strong> broken page adds a meta tag to unbreak it”. Some pages are dead, some have idiot developers who refuse to accept that new browsers are out, some have idiot developers who don’t know that new browsers are out. Whatever the reason, saying that pages won’t be broken because you can unbreak them is very naive.</p> </article> <article> <h1>By: Ray McCord</h1> <p>Ray McCord — Sat, 02 Feb 2008 02:27:46 +0000</p> <p>@ JeffW in # 72</p> <p>CSS 2.1 is, in fact, a revision to bring the standards in line with the existing implementations. In doing so, it broke compatibility with a few implementations of CSS 2.0 and made some changes that were technically inferior to the original specification.</p> <p>It was recognized that standards are only so when relevant. Thus, web standards do adapt to our shared reality. The W3C had retired HTML and started touting XHTML as the way forward. The development of HTML 5 recognizes that not everyone in reality wants an XML-derived markup language as the basis for the web. The rigidity of the standards is not the problem.</p> <p>The problem is that the standards now agree with all other existing implementations, except IE. Standards compromised already. It is now the turn of IE to make the effort to come in line with the standards and other implementations.</p> <p>@ JeffW in #73</p> <p>The supply chain you state is incorrect. The browser “product” is not modified and redistributed by the Author of each site to the End User. That is just not how it works.</p> <p>The browser is between the Author and the End User. It is not a source producer. It’s middleware. The source producer is the Author.</p> <p>It’s important to note that, in terms of IE, if the Author is a third-party web developer or tool maker (whom is not partnered with Microsoft), they are not viewed as the customers of the browser maker. The browser maker’s customers are viewed as being the End User and Site Owner. Period.</p> <p>Even though we web developers provide the service which gives the browser its value to the end user and enables the site owner to extract value from the browser, we are rarely, if ever, given much consideration.</p> <p>From the IE point of view, the supply chain is like this:</p> <p>End User <– Browser Maker <– Site Owner <– Third Party (Web Developers and Tool Makers)</p> <p>That we have the power to demand change is through our expertise, but only when we realize and take the attitude that the site owner came to us because they *need* us — we are the experts in a legitimate profession that deserves respect. Only when we have the ability to sway the thinking of the site owner can our influence and demands be extended down the line to the browser maker.</p> </article> <article> <h1>By: JeffW</h1> <p>JeffW — Thu, 31 Jan 2008 22:47:38 +0000</p> <p>Richard Fink said:<br /> Second, if you view standards-based features as a product (which it is), the supplier chain looks like this:</p> <p>1) Browser makers<br /> 2) Authors (the people who create sites)<br /> 3) Users</p> <p>… don’t forget those who make the tools to help authors create sites… that’s another level, whether they be editors, syntax checkers, WYWI!WYG editors, or blog and CMS software that runs on the site itself… They have to adjust for changes too.</p> </article> <article> <h1>By: JeffW</h1> <p>JeffW — Thu, 31 Jan 2008 22:32:48 +0000</p> <p>I’m pretty strong for meeting the standards when possible, and when browsers implement them, but this brings to mind a quote I saw recently. </p> <p>I don’t have the exact quote handy, but it was to the effect that standards writers aren’t the top of the food chain, they’re at the bottom, and what they write has no meaning unless someone decides to use their implementation. (fwiw, I think it might have been by someone involved with the html v5 team)</p> <p>I’m a hardware design engineer, and we’ve long had to face the difference between documented standards and ‘accepted/implemented standards.’ Sometimes the documented isn’t ultimately the right way to go, either due to poor decisions made in that standard, or due to the need to match other not-quite-spec implementations. </p> <p>So, ultimately, while we usually want browser makers and others to meet the written standards as closely as possible, there may be times when that is the wrong choice. Perhaps the spec should be changed. Contrary to popular belief, they aren’t gospel written in stone and blessed by God. ;-)</p> <p>In this case you mention, I’d ask:</p> <p>… did anyone consider changing the html/css standards to better reflect a working and established reality? </p> <p>(instead of branching the implementations still further with more modes?)</p> <p>… and was there some reason that the way the spec changed the behavior from the accepted/established was wise or advantageous technically?</p> </article> <article> <h1>By: hoopskier</h1> <p>hoopskier — Thu, 31 Jan 2008 02:40:51 +0000</p> <p>“The truth, of course, was that we were actually fixing something, and every other browser got this wrong.”</p> <p>So at that time, *nobody* was following the CSS spec when it came to this scenario? Sounds to me like the spec was wrong, not the browsers… :)</p> </article> <article> <h1>By: michael paige</h1> <p>michael paige — Wed, 30 Jan 2008 19:01:13 +0000</p> <p>I don’t like this for a lot of reasons. Many of them already stated by others.</p> <p>But if there is no stopping this on the whole, I’d like to suggest it be a switch that could be placed inside a CSS file, and not in the HTML.</p> <p>I have sites that have a lot of template files/master pages, and these would all have to be updated, however CSS files are few, and there is usually a single master (or could be!) that could contain this switch.</p> <p>This would make testing/QA easier since I would only need to update one file to test an entire site. It could be as simple as:</p> <p>html { filter: XUACompatible.Microsoft.RenderMode( ie=’8′); }</p> <p>It would also give us a way to target previous/future browsers.</p> <p>I could have a ‘*rendermode.css*’ file with this in it, and simply import it into my global.</p> <p>In a different scenario developers could also do:</p> <p><br /> html { filter: XUACompatible.Microsoft.RenderMode( ie=’8′ ); }</p> <p><br /> html { filter: XUACompatible.Microsoft.RenderIEMode( ie=’edge’ ); }</p> <p>But like I said, I’m against having to put this in the HTML – this however would simply be an alternate. Right now there is only the META tag. I prefer having more options.</p> <p>The last thing I think this might prevent is mass proliferation. CSS files are not typically CMS/application templates, so this being built in by default is less of a possibility (it could still happen though, I’m sure). It could certainly be a code snippet, but only the developers who know what it is would use it.</p> </article> <article> <h1>By: The State of the Craft (HTML) | commadot.com</h1> <p>The State of the Craft (HTML) | commadot.com — Wed, 30 Jan 2008 02:32:32 +0000</p> <p>[...] just recently saw this posting by Eric Meyer on how browser makers and big companies interact and how browsers (and developers) are put in a bad situation. The short version is: Browser [...]</p> </article> <article> <h1>By: Ben Davies</h1> <p>Ben Davies — Tue, 29 Jan 2008 12:52:34 +0000</p> <p>Eric, I just wanted to say that this story has clearly illustrated the frustration so of the IEDev team to me. I can actually see the issue from their perspective at last, so thanks!</p> <p>However, I still don’t agree with thier proposal :)</p> </article> </main></body></html>

Comments on: Almost Target

By: Almost Standards Mode or How to Fit a Square Peg into a Round Hole « Synthesize this…

By: About the meta IE8 switching tag « The Universe Divided

By: Twenty Sided » Blog Archive » Catching up with Web Standards

By: Richard Rutter

By: ThePickards » Blog Archive » IE8 Meta

By: mynth