谁在这里负责？

I tried to resist writing this post. I really, really did. I’ve ranted once about the standards process as it related to responsive images. I had no interest in going there again. I’d prefer not to be known as “that ranty Wisconsin dude who sounds slightly Canadian when he talks”.

我试图抵制写这篇文章。 我真的，真的做到了。 我曾经对标准流程进行过一次批评，因为它与响应式图像有关。 我没有兴趣再去那儿。 我不希望被称为“那个威斯康星州老兄，说话时听起来有点加拿大话”。

Besides, I hesitated to post a condemnation of the current state of affairs when I didn’t have a solution to offer up.

此外，当我没有解决方案时，我犹豫要发表对当前情况的谴责。

But then I read Jeremy Keith’s beautifully written post “A map to build by” discussing the web and our ability to impact what it becomes. In it, Jeremy said:

但是随后，我阅读了杰里米·基思(Jeremy Keith)写的精美文章“构建的地图”，讨论了网络以及我们影响网络发展的能力。 杰里米在其中说：

Perhaps we need our own acts of resistance if we want to change the map of the web. I don’t know what those acts of resistance are. Perhaps publishing on your own website is an act of resistance—one that’s more threatening to the big players than they’d like to admit. Perhaps engaging in civil discourse online is an act of resistance.

如果要更改网络地图，也许我们需要采取自己的抵抗行动。 我不知道这些抵抗行为是什么。 也许在您自己的网站上发布是一种抵制行为-对大型参与者的威胁要大于他们想接受的威胁。 也许在网上进行公民讨论是一种抵制行为。

Jeremy was discussing other issues, but I think those words make sense in many contexts.

杰里米(Jeremy)正在讨论其他问题，但我认为这些词在许多情况下都有意义。

So let’s consider this my act of resistance.

因此，让我们考虑一下这是我的抵抗行为。

If you’ve not been paying attention, the responsive image discussion has continued full-steam ahead, but without any conclusion. If you want to catch-up in full, I highly recommend Bruce Lawson’s excellent review of where we are and Mat Marquis’s gist of where things stand.

如果您没有引起注意，则响应式图像讨论将继续全力以赴，但没有任何结论。 如果您想全面了解，我强烈建议布鲁斯·劳森(Bruce Lawson)对我们的现状进行出色的回顾，并向马特·马奎斯(Mat Marquis)总结事情的要旨 。

For anyone not willing to read the full thing, here’s a TL;DR version:

对于不愿意阅读全部内容的人，这是TL; DR版本：

• The picture element was never received with any sort of enthusiasm by implementors and, while not dead, is barely what you would call alive.
  实现者从未以任何形式的热情来接受图片元素，尽管它还没有死，但几乎没有什么可以称为活着的。
• The srcset attribute was implemented by WebKit for resolution only, and by Blink (also for resolution only) behind an experimental features flag.
  srcset属性由WebKit实现，仅用于分辨率，而由Blink(也仅用于分辨率)在实验性功能标志后面实现。

• Tab Atkins proposed a new approach, src-N, that address the three primary use cases (art direction, resolution, screen size) for responsive images.

  Tab Atkins提出了一种新方法src-N ，该方法解决了响应图像的三个主要用例(艺术方向，分辨率，屏幕尺寸)。

So that’s where we stand today. Just about everyone agrees that srcset is not extendable—hence why no one is implemented the extended syntax for the other use cases. Mozilla, in fact, has come right out and said they have zero interest in it at all—they closed the issue as WONTFIX.

这就是我们今天的立场。 几乎每个人都同意srcset不可扩展，因此为什么没有人为其他用例实现扩展语法。 实际上，Mozilla马上就说出他们对此完全不感兴趣-他们以WONTFIX的名义解决了这个问题 。

On the other hand, just about everyone has some interest in src-N. It solves the use cases, has implementor support from Blink (the Client Hints proposal was even refactored to incorporate src-N) and Mozilla, and has the support of the RICG. Seems like a great situation to be in.

另一方面，几乎每个人都对src-N感兴趣。 它解决了用例，并获得了Blink( 甚至将Client Hints提议重构为合并了src-N )和Mozilla的实现者支持，并获得了RICG的支持。 似乎是一个大局。

The one exception, however, is the WebKit gang who have labeled src-N “a grotesque perversion of the HTML language”. Guess you could say they’re not big fans of the syntax.

但是，一个例外是WebKit帮派，他们将src-N标记为“ HTML语言的怪诞变态” 。 猜猜你可以说他们不是语法的忠实拥护者。

Coincidentally (or perhaps not so much) the same group that came up with srcset is the one implementor not willing to leave it behind. Unfortunately, because this particular implementor wields a big stick, Blink sounds like they’re willing to play follow-the-leader and do as WebKit does.

巧合的是(或可能不是很多)提出srcset的同一个小组是一个不愿抛弃它的实施者。 不幸的是，因为这个特定的实现者挥舞着大棒，所以Blink听起来像他们愿意扮演跟随者的角色，并且像WebKit那样做。

The fact that Blink is apparently calling src-N dead in the water because one implementor opposes (WebKit) and yet haven’t said the same about srcset which is also opposed by an implementor (Mozilla) speaks volumes to the rationale here: it’s not because there isn’t a consensus, it’s because of who is wielding the heavier stick. The fact that the RICG have thrown their support behind src-N appears to not really figure into the equation.

Blink显然在叫src-N死在水中，因为一个实现者反对(WebKit)，但还没有对srcset说同样的事实，而这个事实也遭到实现者(Mozilla)的反对，这说明了这里的基本原理：不是因为没有共识，这是因为谁在挥舞着更重的棍子。 RICG已经在src-N后面提供了支持，这一事实似乎并没有真正纳入考虑范围。

So here we are 21 months after the RICG was started. We finally have a solution that both the RICG and a majority of implementors are interested in, and it looks like it’s at risk of not happening because of one single implementor dissenting opinion. The fact that the currently discussed solution on the WHATWG list is a frankenstein combination of HTML and inline CSS doesn’t do much to elevate my spirits (thread starts here).

因此，这里距RICG启动已经21个月了。 我们终于有了RICG和大多数实施者都对之感兴趣的解决方案，并且由于一个实施者的反对意见，似乎有没有发生的风险。 WHATWG列表上当前讨论的解决方案是HTML和内联CSS的弗兰肯斯坦组合，这一事实并不能起到很大的提振作用( 线程从此处开始 )。

Here’s the thing: the existence of politics in this doesn’t surprise me, it’s an unfortunate reality. I’m also pragmatic enough to recognize why WebKit has such a large influence here. I get all that.

事情就是这样：政治的存在并不令我感到惊讶，这是一个不幸的现实。 我也很务实地认识到WebKit为什么在这里具有如此巨大的影响力。 我明白了

But I find it upsetting that one party can throw this much weight around, discount the opinions of developers and other browser implementors in one fell swoop, and then watch as everyone accepts their opinion as the ultimate conclusion.

但是我感到不安的是，一个聚会可以花这么大的力气，一口气砍掉开发人员和其他浏览器实现者的意见，然后看着所有人都接受他们的意见作为最终结论。

Just as I did last May, I refer back to design principles of HTML once more. In terms of priority, the top three opinions go to three groups, in order:

就像我去年五月所做的一样，我再次提到HTML的设计原理 。 在优先级方面，前三项意见按顺序分为三个组：

1. Users

   用户数

   This is definitely good for users. They’ll benefit from src-N by getting

   这绝对对用户有益。 他们将受益于src-N

   less page weight and improved rendering times, among other things.

   减轻页面重量 ， 改善渲染时间等。

2. Authors

   作者

   The RICG is the representative for the developers in this scenario and they are in support of src-N.

   RICG是这种情况下开发人员的代表，他们支持src-N。

3. Implementors

   实施者

   Here again is almost a full consensus. Mozilla and Blink have shown interest, WebKit is stonewalling.

   这再次是几乎完全的共识。 Mozilla和Blink表现出了兴趣，WebKit处于困境。

I’m no standards expert but when I can place checkboxes next to the top two priorities, and when more representatives of the third priority support something than do not, then it seems to me that thing has merit. If those principles can be thrown out the door when one implementor opposes a solution, then what exactly are they there for in the first place?

我不是标准专家，但是当我可以在最重要的两个优先事项旁边放置复选框时，并且当有更多的第三优先权代表支持某些东西时，我觉得这很有价值。 如果一个实施者反对解决方案时可以抛弃这些原则，那么这些原则究竟是什么呢？

I openly admit I’m not sure how to solve the situation. Here’s what I do know.

我公开承认我不确定如何解决此问题。 这就是我所知道的。

1. We can’t stick our heads in the sand and pretend an attribute that lets us give our fancy iPhones and iPads a big, fat, shiny image is a good enough solution.
   我们不能固执己见，假装一个属性，可以让我们给精美的iPhone和iPad提供大，胖，闪亮的图像，这是一个很好的解决方案。
2. There is a very, very small likelihood of everyone agreeing on one perfect solution. As a result, concessions need to be made. For example, the RICG is supporting src-N because of the interest from implementors despite many members still preferring the picture syntax.
   每个人都同意一个完美解决方案的可能性非常小。 结果，需要做出让步。 例如，尽管许多成员仍然喜欢图片语法，但由于实现者的兴趣，RICG支持src-N。

Given that no solution is likely to be agreed upon by everyone we need to find one that solves the use cases, can be responsibly polyfilled, has the approval of the authors and makes a majority of implementors happy. And then we need to ship it.

鉴于不可能有所有人都同意的解决方案，我们需要找到一种解决用例，可以负责任地填充，得到作者认可并让大多数实现者满意的解决方案。 然后我们需要发货。

Maybe that solution is src-N, maybe it’s something else. But I’d prefer to work on a web where we didn’t have to wait for WebKit, or any other single party for that matter, to make up our minds for us.

也许该解决方案是src-N，也许还有其他东西。 但是我更喜欢在无需等待WebKit或其他任何一方参与的网络上为我们下定决心。

翻译自: https://timkadlec.com/2013/11/whos-in-charge-here/