We’re in a really exciting time for front-end web development. Our modern browsers are excellent in terms of their standard support for CSS, and new features are becoming usable far more rapidly than I can ever remember.
对于前端Web开发，我们正处在一个非常激动人心的时期。 我们的现代浏览器在对CSS的标准支持方面非常出色，而且新功能的使用速度比我所记得的要快得多。
This situation is exactly what we asked for in the early days of the Web Standards movement. That browsers support standard features according to the spec, so that developers could build their site using a single browser and be confident that it would then work in the other browsers. Vendor prefixes aside (and I personally believe they are a sane solution to the problem of implementing early stage CSS) that is where we are now. I do most development in Firefox on my Linux desktop and it just works in the other modern browsers and platforms that I test in. Even something that might be considered complex – such as a large-scale responsive design – works pretty consistently across not only desktop browsers but mobile ones too.
这正是我们在Web标准运动初期所要求的。 该浏览器根据规范支持标准功能，因此开发人员可以使用单个浏览器来构建其站点，并确信该站点随后可以在其他浏览器中运行。 除了供应商前缀（我们个人认为，这是解决实现早期CSS问题的理智解决方案），这就是我们现在所处的位置。 我在Linux桌面上使用Firefox进行大多数开发，并且只在我测试过的其他现代浏览器和平台中工作。即使是可能被认为很复杂的内容（例如大规模响应式设计），也不仅在桌面上都可以一致地工作浏览器，但移动浏览器也是如此。
However, despite us entering a seemingly golden age of browser consistency, what I am seeing is an increasing reliance on a whole slew of polyfills, CSS frameworks and boilerplate starting points. I am concerned that these things are being promoted as something everyone should include from the outset, rather than being a toolkit you draw on to deal with problems once they have arisen.
但是，尽管我们进入了浏览器一致性看似黄金时代，但我看到的是越来越多的人依赖于大量的polyfill， CSS框架和样板起点。 我担心这些事情从一开始就被推广为每个人都应该包括的东西，而不是成为问题一旦发生就可以依靠的工具包。
这是我的“ HTML5样板” (Here is my “HTML5 boilerplate”)
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title></title>
</head>
<body>
</body>
</html>
That’s it. For at the start of a project I don’t necessarily know what problems I am going to encounter and how I might deal with them. Adding a bunch of polyfill JavaScript at the start doesn’t help. Firstly, I might not need it, however if I have been developing with it there from the start how do I know if there is a better way to do things that negate the requirement for it? Secondly, it might actually cause me a problem – is that issue I am seeing a browser bug, or a problem with the polyfill? Thirdly, if I am adding a lot of JavaScript right from the start I am very likely to end up with bits of my layout needlessly requiring JavaScript to work.
而已。 因为在项目开始时，我不一定知道我将遇到什么问题以及如何处理它们。 在开始时添加一堆polyfill JavaScript并没有帮助。 首先，我可能不需要它，但是，如果我从一开始就一直在使用它进行开发，我如何知道是否有更好的方法来做事来否定它的要求？ 其次，这实际上可能会引起我一个问题–是我看到浏览器错误还是该polyfill有问题？ 第三，如果我从一开始就添加了很多JavaScript，那么很有可能最终会不必要地需要我JavaScript来工作。
Take the Greenbelt website I wrote about last week. I was working alongside the designer when developing the site, I didn’t know at the start exactly how we would solve many of the problems inherent in such a large, responsive site. So I developed the site for modern browsers, working in Firefox, with a mobile first approach. The only thought I put in for older browsers during the entire front-end development was to make a note of any CSS3 Selectors that I knew were unsupported in IE8 and below. Once we had the site developed and snagged in modern browsers on desktop and mobile, I moved on to look at IE8, 7 and 6.
以我上周撰写的Greenbelt网站为例。 在开发网站时，我与设计师一起工作，一开始我并不确切知道如何解决如此庞大的响应式网站固有的许多问题。 因此，我以移动优先的方式开发了适用于Firefox的现代浏览器的网站。 在整个前端开发过程中，我对较旧的浏览器的唯一想法是记下我知道在IE8及以下版本中不受支持的所有CSS3选择器。 一旦我们开发了该网站并将其嵌入台式机和移动设备上的现代浏览器中，我便着眼于IE8、7和6。
问题1：IE8及以下版本不支持媒体查询 (Problem 1: IE8 and below have no support for media queries)
At first view, IE8 was showing the mobile version of the site as it did not load in the other stylesheets. Here I could choose to use respond.js to enable support for media queries (but create a reliance on JavaScript) or include a stylesheet for IE8 that fixed the width. I chose the latter option. I also used this stylesheet to fix up a few small CSS issues that I spotted in IE8.
乍一看，IE8展示了该网站的移动版本，因为它没有在其他样式表中加载。 在这里，我可以选择使用response.js启用对媒体查询的支持（但创建对JavaScript的依赖）或包括用于IE8的样式表，以固定宽度。 我选择了后者。 我还使用此样式表修复了在IE8中发现的一些小CSS问题。
问题2：IE8及以下版本不支持某些CSS3选择器 (Problem 2: IE8 and below had no support for certain CSS3 selectors)
Some of my layout looked a bit wonky due to my use of CSS3 selectors. I do love my CSS3 selectors. I knew this would be an issue and again I had a choice. I could use a polyfill such as Selectivizr or I could polyfill them myself with jQuery. As we were already using jQuery on the site and I knew exactly which selectors were an issue I chose to just add a function into our global UI file to polyfill these myself. If the site had been littered with these issues then I might have chosen to just use Selectivizr – again, by waiting until I could see the problem I was in the best place to make a decision.
由于使用了CSS3选择器，因此我的某些布局看起来有些奇怪。 我喜欢我CSS3选择器。 我知道这将是一个问题，我再次有了选择。 我可以使用Selectivizr之类的polyfill，也可以使用jQuery自己对其进行polyfill。 由于我们已经在该站点上使用jQuery，并且我确切知道哪个选择器是一个问题，因此我选择将一个函数添加到全局UI文件中以自己填充这些选择器。 如果站点上充斥着这些问题，那么我可能选择只使用Selectivizr –再次等待直到看到问题，我才是做出决定的最佳位置。
问题3：IE6和7 ...... 你在做什么？ (Problem 3: IE6 and 7 … what are you doing?)
With the IE8 stylesheet loaded for IE8 and below, the layout actually held up reasonably well in older Internet Explorer browsers. There were of course the usual crazy layout issues which were mainly solved by getting the element concerned to have layout, and a few rounding issues. However I was surprised at how well the layout worked considering that everything bar a few items was still sized using percentages – my IE8 and below stylesheet having fixed the width of the main container.
在为IE8及以下版本加载IE8样式表的情况下，该布局实际上在较旧的Internet Explorer浏览器中保持得很好。 当然，还有一些常见的疯狂布局问题，主要是通过使相关元素具有布局来解决的，以及一些舍入问题。 但是，考虑到所有项目（除少数项目外）都仍使用百分比来设置大小，我对布局的效果感到惊讶，因为我的IE8和以下样式表固定了主容器的宽度。
This large and complex site, which had been over 4 months in development, was tidied up in old browsers in around 1 day of work, mainly by way of CSS added via our old friend the conditional comment.
这个庞大而复杂的网站经过4个多月的开发，在大约1天的工作时间内就通过旧浏览器进行了整理，主要是通过我们的老朋友添加有条件注释的CSS的方式。
不要解决您没有的问题 (Don’t solve problems that you don’t have)
Build for modern browsers. Test your work in those and make sure the experience for an up to date browsers is as you want it. Then look at the problems you have, alongside your policy in terms of what you are delivering to older browsers, and see what you need to fix those issues.
为现代浏览器构建。 在其中测试您的工作，并确保最新浏览器的体验如您所愿。 然后，根据向旧版浏览器提供的内容，查看政策方面的问题，并查看解决这些问题所需的条件。
There is some amazing work out there in terms of polyfills, frameworks and libraries. However you don’t have to use them, and in many cases won’t need to use them. So make sure every bit of code added to your project is there for a reason you can explain, not just because it is part of some standard toolkit or boilerplate.
在polyfill，框架和库方面，有一些惊人的工作。 但是，您不必使用它们，并且在许多情况下不需要使用它们。 因此，请确保存在添加到项目中的所有代码都是出于可以解释的原因，而不仅仅是因为它是某些标准工具箱或样板文件的一部分。
If you are an experienced developer be very careful about suggesting that a whole slew of things are required as a solid base for any given project. Depending on the sort of projects you work on, it may well be that you do need all of this stuff and make use of it well. However, it’s a confusing world of options out there to the beginner and learning the basics of HTML and CSS development for modern browsers, then solving the issues that come up, is still the best grounding for any new developer.
如果您是一位经验丰富的开发人员，请非常谨慎地建议将所有东西作为任何给定项目的坚实基础。 根据您从事的项目的种类，很可能您确实需要所有这些东西并充分利用它。 但是，对于初学者来说，这是一个令人困惑的选择世界，并且学习现代浏览器的HTML和CSS开发基础知识，然后解决随之而来的问题，对于任何新开发人员来说仍然是最好的基础。
翻译自: https://rachelandrew.co.uk/archives/2012/03/21/stop-solving-problems-you-dont-yet-have/
9684
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
