普朗特迈耶稀疏波_埃里克·迈耶的访谈

普朗特迈耶稀疏波

I've always wanted to interview Eric Meyer. His early CSS books are a big reason this blog exists today and the reason why I'm a web developer. Eric gave me some time to hit the history of CSS, CSS' problems today, and the future of CSS.

我一直想采访埃里克·梅耶(Eric Meyer)。 他早期CSS书籍是今天该博客存在的重要原因，也是我成为Web开发人员的原因。 Eric给了我一些时间来介绍CSS的历史，当今CSS的问题以及CSS的未来。

您早期CSS书籍有助于推动我对前端技术的热爱。 您爱上并驱使您撰写CSS的原因是什么？ (Your early CSS books were instrumental in pushing my love for front end technologies. What was it about CSS that you fell in love with and drove you to write about it?)

At first blush, it was the simplicity of it as compared to the table-and-spacer hacks that were so widespread at the time — this was mid-1996. CSS just felt right — the conceptual model made sense, the syntax was straightforward. It seemed like anyone who could learn HTML could learn CSS and have so much more power at their command.

乍一看，与当时非常流行的表和间隔黑客相比，这是它的简单性-那是在1996年中期。 CSS感觉很不错–概念模型很有意义，语法很简单。 似乎任何可以学习HTML的人都可以学习CSS，并且在其命令下拥有更多的功能。

From there, I think it was mostly the sheer joy of crawling through a new system, pulling it apart, figuring out how it worked, and documenting what worked and what didn't. I don't know exactly why those kinds of things excite me, but they do.

从那儿开始，我认为这主要是纯粹的乐趣，它是通过一个新系统进行爬网，将其拆开，弄清楚它是如何工作的以及记录什么有效以及什么无效。 我不知道这些事情为什么使我兴奋，但它们确实使我兴奋。

CSS面临的早期斗争有哪些？ 您可以分享任何旧故事吗？ (What were some of the early struggles that faced CSS? Any old stories you can share?)

The biggest struggle by far was interoperability. Early implementations were rushed, partial, and often deeply flawed. One of the first major projects that got me noticed was publishing CSS support charts for early browsers. It's always fun to see some of my early design decisions in charts that have come along later — classifying support for each feature as Yes/No/Partial/Buggy, color-coding each ratings' table cell as green/white/yellow/red, and so on. It was rare in those days to have a feature's row be all green, meaning it had cross-browser support without known bugs or limitations.

迄今为止，最大的挑战是互操作性。 早期的实施很仓促，不完整，而且常常存在严重缺陷。 引起我注意的第一个主要项目之一是发布早期浏览器CSS支持图表。 在以后出现的图表中看到我的一些早期设计决策总是很有趣–将对每个功能的支持分类为是/否/部分/越野车，将每个评分的表格单元格颜色编码为绿色/白色/黄色/红色，等等。 在那个日子里，很少有一个功能行全是绿色的，这意味着它具有跨浏览器的支持而没有已知的错误或限制。

So, if you wanted to do anything interesting with CSS, you had to write separate style sheets for each major browser. This was back when the only known hack was that Netscape ignored @import(), so you would write CSS for Netscape, then write styles for IE that overrode some of the Netscape styles while adding some IE-centric styles, and then import that style sheet.

因此，如果您想对CSS做任何有趣的事情，则必须为每个主要的浏览器编写单独的样式表。 当唯一的已知技巧是Netscape忽略@import() ，这又回到了过去，因此您将为Netscape编写CSS，然后为IE编写样式，以覆盖某些Netscape样式，同时添加一些以IE为中心的样式，然后导入该样式。片。

We were approaching a complete deadlock at the turn of the millennium: basic box model layout was totally different thanks to the whole width/height problem, where IE didn't implement the CSS box model, whereas Netscape and Opera did, so you could set a width and some padding and get elements of completely different sizes in different browsers. Neither side was willing to change their handling of the box model, and it threatened to strangle CSS to death. DOCTYPE switching let IE implement the specification box model in its standards mode while still using its incorrect, if more intuitive, box model in quirks mode. Netscape was able to use DOCTYPE switching to bury some of its embarrassing bugs in quirks mode as well.

千年之交，我们正在接近完全的僵局：由于整个宽度/高度问题，基本的盒子模型布局完全不同，其中IE没有实现CSS盒子模型，而Netscape和Opera却实现了，因此您可以设置宽度和一些填充，并在不同的浏览器中获得完全不同大小的元素。 双方都不愿意改变对盒子模型的处理，并威胁将CSS扼杀。 DOCTYPE切换使IE可以在其标准模式下实现规范框模型，同时仍在怪癖模式下使用其错误的(如果更直观的话)框模型。 Netscape也能够使用DOCTYPE开关将其一些令人尴尬的错误也以怪癖的方式掩埋。

I often say that DOCTYPE switching saved CSS, and it's no exaggeration. Without it or something like it, we'd be struggling through the ramp-up phase of a new presentation language right about now.

我经常说DOCTYPE切换保存了CSS，这并不夸张。 没有它或类似的东西，我们现在将在新的演示语言的升级阶段中苦苦挣扎。

您认为今天的开发人员所面临的与CSS相关的头几个问题是什么？ (What would you qualify as the top few CSS-related problems facing developers today?)

Layout is A-number-one, and has been for so long now. Flexbox and grid layout promise to finally, FINALLY fill that huge hole at the heart of CSS. I'm really, really excited and optimistic about both.

布局是A数一，并且已经存在了很长时间。 Flexbox和网格布局有望最终最终填补CSS核心的巨大漏洞。 我对两者都感到非常兴奋和乐观。

Right behind layout, though, is the increasing scope and complexity of CSS, which is becoming a real challenge for authors new and old. I mean, CSS1 was really pretty simple. It's about 75 pages printed from the browser with no changes to the defaults, and it described some pretty simple stuff. Set colors, fill backgrounds, change the font face, float elements — nothing was really all that complex. Floats were as complicated as it got.

但是，紧随其后的是CSS的范围和复杂性不断增加，这对新老作者来说都是一个真正的挑战。 我的意思是， CSS1确实非常简单。 它是从浏览器打印的约75页，没有更改默认值，并且描述了一些非常简单的内容。 设置颜色，填充背景，更改字体，浮动元素-其实没有那么复杂。 浮标是如此复杂。

Now we have vaguely inscrutable selectors and gradients and transform matrices and keyframe animations and a whole host of other things that are really not very easy to describe in simple ways, so their descriptions are often not simple. It's hard to see what else could have been done, and yet the problem is there. When you see Bert Bos delivering talks about what's next, you know there's trouble in River City.

现在，我们隐约地掌握了选择器和渐变，以及变换矩阵和关键帧动画以及许多其他事情，这些事情实际上很难用简单的方式描述，因此它们的描述通常也不简单。 很难看到还可以做些什么，但是问题仍然存在。 当您看到Bert Bos 谈论下一步计划时 ，您就会知道River City遇到了麻烦。

A lot of this is a simple side effect of success: if CSS hadn't become such a central part of user interface technologies, it wouldn't have grown as far nor become as complex as it has. Something else, or several something elses, would have already come along. CSS is everywhere now — browsers, chat clients, routers, even operating system UIs. The more places it gets used, the more things people want to add to it. There's an aphorism that's been semi-jokingly called Meyer's Law: Anything that can be done with CSS eventually will be done with CSS. I mean, have you SEEN CSS 3D Clouds? Madness. The very best kind of madness, of course, but still: madness.

其中很多都是成功的简单副作用：如果CSS尚未成为用户界面技术的核心部分，那么它就不会发展得那么远，也不会变得如此复杂。 可能已经有其他的东西。 CSS现在无处不在-浏览器，聊天客户端，路由器，甚至操作系统UI。 它使用的地方越多，人们想要添加的东西就越多。 有一种被戏称为“迈耶定律”的格言： 使用CSS最终可以完成的任何事情都将使用CSS完成。 我的意思是，您看过CSS 3D云吗？ 疯狂。 当然，最好的一种疯狂是：疯狂。

您CSS重置是网络上使用最广泛CSS片段之一。 使用每个修订版更新reset.css时需要注意什么？ (Your CSS reset is one of the most widely used snippets of CSS on the web. What considerations to you take when updating your reset.css with each revision?)

Generally, what I always have in mind is that my goal is not to enforce certain stylistic ideas. It's to strip all elements, aside from form elements, down to the point where they act like a div or a span, visually speaking. That creates a foundation on which authors can build their own stylistic ideas. I get people emailing me to say that I should set all elements to box-sizing: border-box or that I should define foreground and background colors, but that's not what a reset does. That's what authors do with a reset, to make it their own.

通常，我一直牢记的是我的目标不是实施某些风格上的想法。 它是将所有元素(除了表单元素之外)剥离到视觉上就像div或span一样的程度。 这为作者建立自己的风格观念奠定了基础。 我收到一封电子邮件，说我应该将所有元素设置为box-sizing: border-box或者应该定义前景色和背景色，但这不是重置的作用。 这就是作者自己进行的重置操作。

The major revision for reset 2.0 was to correct my one major blunder, which was that I reset focus outlines to zero width with a note that authors should declare some sort of visible outline. That was in keeping with the idea of "set everything to a baseline and then build your preferred effects on top". The problem is that hardly anyone ever did as I requested, leading to widespread focus-outline suppression. I really regret that I created such a huge accessibility problem. So I pulled that bit out when I revised, and publicly apologized for the unintended consequence. It was a huge unforced error, one dearly I wish I could take back.

reset 2.0的主要修订版是为了纠正我的一个重大错误，那就是我将焦点轮廓重置为零宽度，并注意作者应声明某种可见轮廓。 这与“将所有内容设置为基线，然后在顶部构建您喜欢的效果”的想法保持一致。 问题在于，几乎没有人按照我的要求做任何事情，从而导致广泛关注焦点轮廓。 我真的后悔创建了如此巨大的可访问性问题。 因此，当我进行修订时，我将其删除，并为意外的后果向公众道歉。 这是一个巨大的非强制性错误，我非常希望我能收回。

您会说什么是开发人员在使用CSS时最常犯的错误？ (What would you say are the mistakes developers most frequently make when it comes to CSS?)

Removing focus outlines. Seriously, people, stop it. You're not helping anyone, and you're hurting people with accessibility concerns. Cut it out.

删除焦点轮廓。 认真地，人们，阻止它。 您没有在帮助任何人，而是在无障碍性方面伤害了人们。 切掉

Beyond that, the biggest is probably still that developers think CSS gives them absolute control over page layout and presentation. It doesn't, and was never supposed to: CSS gives you presentational influence, and that's it. Granted, that influence is very strong, but it can still be overridden by users, by devices, by any number of things.

除此之外，最大的可能仍然是开发人员认为CSS使他们能够完全控制页面布局和表示。 事实并非如此，而且从未如此：CSS赋予了您呈现性的影响，仅此而已。 当然，这种影响非常强大，但是仍然可以被用户，设备或任何其他事物所取代。

A closely related mistake, now starting to fade, is assuming that you can fix the width of a layout. Responsive design is finally getting people to realize that this is untrue, but unfortunately it's still a pretty common design pattern. Though I suppose that's more of a design mistake than a CSS mistake per se.

一个紧密相关的错误现在开始淡出，它是假定您可以固定布局的宽度。 响应式设计最终使人们意识到这是不正确的，但不幸的是，它仍然是一种非常常见的设计模式。 虽然我认为这更多的是设计错误，而不是CSS错误。

许多开发人员会说，CSS改进在浏览器中的实现速度不够快。 您对在浏览器中实现CSS功能的速度有何看法？ (Many developers would say that CSS advancements aren't implemented within browsers quickly enough. What is your thought on the speed with which CSS features are implemented in browsers?)

I think they're doing pretty well, actually. Given everything that they could add, it's impressive that they're adding as much as they are, and working as hard as they are to get their implementations right the first time.

实际上，我认为他们的表现不错。 鉴于他们可以添加的所有内容，令人印象深刻的是，他们正在添加尽可能多的内容，并且为尽一切努力使首次实现正确。

But then, I remember the IEnterregnum, when practically nothing but bug fixes happened for years on end; and the Browser Wars, when stuff got added so fast and furiously that it was rarely ever done well, let alone done right.

但是后来，我记得IEnterregnum，那时除错误修复外几乎没有其他事情持续了好几年。 以及浏览器大战(Browser Wars)，当东西被如此快速而疯狂地添加时，它就很少做得很好，更不用说做对了。

Not to mention, the stuff that's coming down the pipe, like flexbox and grid layout and exclusions, is really complex and difficult stuff. I've talked with implementors about the complexity of rendering tables — not styled tables, even, just figuring out how to lay out a table based on its context and its content. Grid layout makes that look like peanuts. Gradients are no walk in the park, and there is already work on compositing and filters, and it's pretty amazing, really.

更不用说，诸如Flexbox和网格布局以及排除之类的东西确实是复杂而困难的东西。 我已经与实现者讨论过渲染表的复杂性，甚至不是样式表，甚至只是想出如何根据其上下文和内容来布局表。 网格布局使外观看起来像花生。 渐变色不是在公园里散步，而且已经在合成和过滤器上工作了，这确实很棒。

So, yes, we always want everything complete and perfect and now now NOW, and browser teams are constrained by headcounts and strategic priorities and the need to sleep every so often, so we're always going to wish they would go faster. Against the historical record, I say they're doing pretty darned well.

因此，是的，我们一直希望所有事物都完整和完美，现在就现在， 现在 ，浏览器团队受到人员数量和战略优先级以及每时每刻睡眠的限制，所以我们总是希望他们会更快。 根据历史记录，我说他们做得很好。

CSS属性前缀是CSS社区中的热门话题。 您对此做法有何看法，有没有更好的解决方案？ (CSS property prefixing is a hot topic in the CSS community; what is your opinion of this practice, and is there a better solution?)

I'm one of those contrarians who thought prefixes were not only a great idea, but not taken far enough. So I was always for the practice. Sadly, their actual use in the real world fell short of the ideal, and I expect them to be gone within the next few years.

我是那些认为前缀不仅是个好主意，而且还远远不够的逆势主义者之一。 所以我一直都在练习。 可悲的是，它们在现实世界中的实际使用没有达到理想的水平，我希望它们在未来几年内会消失。

I know that fills a lot of authors with embittered glee, mostly because they hated all the repetition the prefixes incurred, but I really do think it's a loss for the community. Without prefixes or something like them, it's a lot harder to get new features tested by a wide range of people in a short span of time. The fewer the testers, the fewer the found bugs, and the greater the chance of permanent incompatibility. It makes me sad.

我知道这让很多作者感到不安，主要是因为他们讨厌所有重复出现前缀的事情，但是我确实认为这对社区是一种损失。 没有前缀或类似的东西，要在很短的时间内让大量的人测试新功能要困难得多。 测试人员越少，发现的错误越少，永久性不兼容的机会就越大。 这让我很难过。

您对Opera转向WebKit有什么看法？ (Do you have any opinion on Opera's move to WebKit?)

Oh, yes. My opinions are pretty much exactly what John Lilly, ex-CEO of Mozilla, said, so I just point people to his post. But since we're talking CSS nerdery here, I'll add that I'm also sorry to lose a rendering engine because it reduces the number of implementations that can show interoperability. No CSS module can exit the Candidate Recommendation stage unless there are two interoperable implementations of that module. It used to be there were four implementations, so you needed two of four. Now you need two of three. It's not an impassable roadblock, but there's less room to maneuver, as it were.

哦是的 我的观点几乎与Mozilla前首席执行官John Lilly所说的一样 ，所以我只是指出人们对他的看法。 但是由于我们在这里谈论CSS nerdery，所以我要补充一点，我也很抱歉失去一个渲染引擎，因为它减少了可以显示互操作性的实现数量。 除非该模块有两个可互操作的实现，否则任何CSS模块都不能退出“候选推荐标准”阶段。 过去曾经有四个实现，所以您需要四个实现中的两个。 现在您需要三个中的两个。 这不是一个不可逾越的障碍，但实际操作空间却更少。

您可以传递任何移动CSS提示吗？ (Any mobile CSS tips you can pass on?)

Pay attention to whatever Luke Wroblewski, Scott Jehl, Brad Frost, and especially PPK have to say. That's what I do.

请注意Luke Wroblewski ， Scott Jehl ， Brad Frost ，尤其是PPK所说的话。 我就是做这个的。

开发人员如何构建CSS，以便随着应用程序的增长而扩展(即，更易于维护)？ (How can developers structure their CSS so that it can scale (i.e. be more maintainable) as their application grows?)

I think Nicole Sullivan's work on OOCSS is worth studying very closely. CSS preprocessors like LESS or Sass are also very good tools for keeping things neat and tidy, though that does mean you have to keep an eye on the output to make sure it's decently optimal. Not because frameworks are inherently sloppy, but because you're relying on algorithms to generate your CSS for you. There will always be edge cases where the result will be sloppier than what you could manage by hand.

我认为Nicole Sullivan关于OOCSS的工作非常值得研究。 像LESS或Sass这样CSS预处理器也是使事情保持整洁的很好的工具，尽管这确实意味着您必须密切注意输出以确保其达到最佳效果。 并不是因为框架本质上是草率的，而是因为您依赖算法来为您生成CSS。 在某些极端情况下，结果会比您可以手工处理的结果更糟糕。

我一直认为CSS是设计人员和开发人员之间的桥梁，而CSS的简单性是其有效性的关键。 如何在保持语言简单的同时向CSS添加更多逻辑？ (I've always contended that CSS is the bridge between designers and developers, and that CSS' simplicity is the key to its effectiveness. How can we add more logic to CSS while keeping the language simple?)

That's a question for much wiser heads than mine. I always thought things like animations and gradients were too inherently complex to be added to CSS, and yet here we are. This is an area where I think preprocessors really shine: they have already experimented with ways of adding logic to CSS. Now the Working Group can look at what they've done and copy or improve on it. Thus we see formal proposals for variables, and some serious interest in formalizing extensions and mixins.

这是一个比我更明智的头脑的问题。 我一直认为动画和渐变之类的东西天生就太复杂了，无法添加到CSS中，但是我们就在这里。 我认为这是预处理器真正发挥作用的地方：他们已经尝试了向CSS添加逻辑的方法。 现在，工作组可以查看他们所做的工作，并在此基础上进行复制或改进。 因此，我们看到了有关变量的形式化建议，并且对形式化扩展和混合产生了浓厚的兴趣。

HTML5，CSS和JavaScript将在Firefox OS中掀起移动市场的热潮。 您如何看待CSS在移动应用程序中的作用，可能需要进行哪些更改以更好地适应移动设备？ (HTML5, CSS, and JavaScript will be blitzing the mobile market within Firefox OS. What do you think of CSS' role in mobile apps, and what may need to change to better accommodate mobile?)

It's a little astonishing to see everywhere CSS is going, isn't it? I actually think CSS does pretty well at meeting mobile needs, assuming that you actually think of a mobile device as a mobile device and not a tiny desktop monitor. What will need to change is improving the speed of rendering engines, same as with JS.

到处都可以看到CSS有点令人惊讶，不是吗？ 我实际上认为CSS可以很好地满足移动需求，假设您实际上将移动设备视为移动设备，而不是微型台式机显示器。 与JS一样，需要改变的是提高渲染引擎的速度。

您是An Event Apart的共同创始人。 在这些会议上，AEA的参加者可以期望学习什么？ (You're a co-founder of An Event Apart. What can attendees to AEA expect to learn during these sessions?)

New ways of looking at what they do, challenges to their entrenched assumptions, and inspiration to stretch their skills and scope further, plus tons of ideas they can take straight back to the office and put into practice. That sounds like a pretty tall order, I know, but the speakers are just incredible and never cease to blow me away.

观察他们工作方式的新方法，对根深蒂固的假设的挑战以及进一步扩展其技能和范围的灵感，以及可以将大量的想法直接带回办公室并付诸实践的想法。 我知道，这听起来像是一个很高的要求，但是扬声器简直令人难以置信，而且永不停息。

未来我们对Eric Meyer有什么期望？ 您有什么可以分享的吗？ (What can we expect from Eric Meyer in the future? Anything you can share?)

I'm working through the fourth edition of CSS: The Definitive Guide, which is being released a chapter at a time as "pre-books" available in digital or print-on-demand formats. That means you can buy the first few chapters now, and the next few soon. I'm also continuing to do a web history podcast series with Jen Simmons of The Web Ahead, with plans for some great guests in the coming months. I'm speaking a lot in 2013 — partly because I'm onstage at every AEA, but I'll also be at Rust Belt Refresh in my hometown of Cleveland, CSS Day in Amsterdam, and the CSS Dev Conference in Colorado. And who knows what else? I'm sorry I'll miss the inaugural CSSconf, but it conflicted with previous commitments.

我正在研究CSS第四版：权威指南 ，该指南一次以数字或按需印刷形式的“预售书”形式发布。 这意味着您可以现在购买前几章，很快就可以购买。 我还将继续与The Web Ahead的 Jen Simmons一起制作网络历史播客系列，并计划在未来几个月内吸引一些出色的嘉宾。 我在2013年经常要发言-部分是因为我在每个AEA上台，但我也将在我的家乡克利夫兰参加Rust Rust Refresh ，阿姆斯特丹CSS Day以及科罗拉多CSS CSS会议 。 还有谁知道呢？ 很抱歉，我会错过第一届CSSconf ，但是它与以前的承诺相冲突。

Beyond those things, I'll be continuing to do what I've been doing for years now: working with Jeffrey to make An Event Apart better and better, writing CSS tests, and advocating for open standards in every nook and cranny of our online world. It keeps me off the street and out of trouble.

除了这些事情，我将继续做我多年来一直在做的事情：与Jeffrey合作，使An Event越来越好，编写CSS测试，并倡导我们在线的每个角落都存在开放标准世界。 它使我无路可走，没有麻烦。

翻译自: https://davidwalsh.name/eric-meyer

普朗特迈耶稀疏波