當網絡標準讓我們失望時
不時地，Web 開發人員站起來，更大聲地抱怨 W3C 和 ECMA 的失敗，因為他們選擇發展（或不發展）網絡技術的方式。我們將委員會的設計稱為失敗，瀏覽器供應商應該只是實施而不用擔心它......除非是微軟，他們不應該在沒有先詢問其他人的情況下做任何事情......以及是否有更好，更快的方式來創造變化.實際上，我對組織結構的關注不如對這些群體缺乏關注的關注。
大問題
在解決問題時，我有一個偏見：一旦問題解決了，我不想再解決它。當問題得到明確定義並且解決方案被理解和接受時，我希望它成為 解決方案並繼續解決新問題。
每個網絡標準委員會都有一項工作，那就是解決他們關注領域的問題。委員會似乎很難確定他們想要解決的問題。公平地說，完全定義問題通常是解決問題中最複雜的部分。然而，有兩組問題可供選擇，儘管已有多年曆史，仍有許多問題尚未解決。
為今天設計，為明天設計
從與從事 Web 標準工作的各種人的交談中，他們基本上試圖解決兩類問題：今天的問題和明天的問題。今天的問題是已知的實體。整個問題上下文是眾所周知的，開發人員創建的解決方案已經存在。明天的問題有點深奧。開發人員可能尚未遇到這些問題，但標準希望為它們的可能性提供幫助。
可以肯定的是，這兩個問題集都值得他們付出應有的時間和努力，從 HTML5 到 ECMAScript 5 的一切都解決了今天的一些問題，同時也解決了未來的一些問題。 getElementsByClassName() 方法和 Selectors API 解決了開發人員希望通過 CSS 類查詢 DOM 和使用 CSS 查詢的問題——兩者在 JavaScript 庫中已經無處不在。跨文檔消息傳遞 API 解決了安全跨框架通信問題，否則開發人員使用多個嵌入式 iframe 來來回傳遞數據。 ECMAScript 5 最終引入了分配 getter 和 setter 以及控制屬性可枚舉性的官方方法。所有這些都是當今的問題，並且被很好地理解並很快變成了官方支持的 API。
明天的問題通常集中在網絡上尚未完成的事情上。我喜歡將此稱為 Photoshop-on-the-web 問題。它是這樣的：假設有一天我想把 Photoshop 寫成一個 Web 應用程序，我需要什麼來實現它？首先，我需要一些方法來直接操作像素數據（由畫布解決）。然後，我需要一些方法來處理大量數據而不凍結瀏覽器 UI（由網絡工作者解決）。當然，我需要能夠直接從桌面讀取文件（由 File API 解決）。
此時您可能會說，“但我現在確實想這樣做！”沒關係，但是這些 API 是在今天之前出現的。明天的一些問題不可避免地會成為今天的問題，但有些可能不會。我們真的需要瀏覽器中的數據庫，還是簡單的鍵值存儲就足夠了？只有未來會告訴我們。
今天未解決的問題
正如我所說，花時間解決今天的問題和展望未來可能會絆倒人們的潛在問題絕對很重要。我絕對不能忍受的是網絡標準委員會經常忽視今天的問題，而是把時間花在明天的問題上。如果一個問題定義明確並影響到大量開發人員，讓我們解決這個問題，這樣就沒有人需要重新解決它。有很多問題我們已經處理了很長時間，但似乎沒有人有興趣解決它們。對我來說，這是網絡標準最大的失敗：未能讓開發人員繼續解決更有趣的問題。
以下是當前尚未解決的問題列表：
- 在 JavaScript 中讀取/寫入 Cookie – Netscape 給了我們
document.cookie.從那以後它根本沒有改變，這意味著任何人想要讀取或寫入 cookie 時，他們必須自己完成所有字符串格式化。在過去的 15 年裡，我們一直在編寫 JavaScript cookie 庫，我們仍然需要它們，因為 API 從未改變以反映我們實際在做什麼。這是網絡發展過程中的明顯失敗。 - JavaScript 字符串格式 – 十年來，我們已經知道我們需要能夠為 HTML 和正則表達式轉義文本，並且我們需要類似於
sprintf()的通用字符串格式 .為什麼這不是一個已解決的問題？為什麼我們每個人都必須一遍又一遍地重寫這樣的功能？下一個版本的 ECMAScript 顯然會有一個名為 quasis 的特性，它試圖使用相同的（新的）語法來解決所有問題。我真的不喜歡這樣，因為在計算機科學領域，一系列已解決的問題沒有向後兼容性。我們不是在這裡開闢新天地，htmlEscape()方法將是一個很好的開始，或者實現String.format().一些理智的東西。 - JavaScript 日期格式 ——再一次，一個已經存在了十多年的問題。為什麼我不能在 JavaScript 中輕鬆地進行日期格式化？ Java 擁有這種能力已經有一段時間了，而且並不可怕。為什麼我們仍在編寫日期格式庫？
- 常見的 UI 範例 - 這個真的讓我很煩。在過去的十年裡，我們一直在編寫大量的 JavaScript 來製作最好的 UI 控件。這些控件在 JavaScript 庫中無處不在，並且通常需要大量代碼才能使它們正常工作。為什麼沒有 HTML 標籤可以讓我創建這些常見的 UI 範例：
- 標籤 – 我們還需要為標籤集創建多少次 JavaScript？甚至還有 ARIA 角色將 HTML 標記為選項卡，為什麼我們不能有一些默認行為是使用這些角色的標籤？我已經厭倦了創建更新版本的標籤。
- 輪播 – 一個非常流行的控件，只不過是一個
<marquee>根據用戶交互定期停止和啟動的標籤。您可以訪問的網站很少，頁面上至少沒有一個輪播。寫了一些，總是很痛苦。為什麼這不能只是 HTML 的一部分？ - 手風琴 - 這裡沒有什麼神奇的。非常接近 HTML5
<details>元素行為。為什麼我不能在本地擁有這個？ - 樹木 ——又一項長達十年之久的發明，我們仍未標準化。事實上，我發表的第二篇文章是關於創建可擴展樹的……那是在 2002 年。ARIA 也有代表樹的角色，那麼為什麼不提供 HTML 原生版本呢？
- JavaScript 觸摸事件 – 儘管觸摸屏技術相對較新，但很快就出現了一些可以標準化的常見模式。為什麼需要破譯多個
touch事件來弄清楚用戶在做什麼？為什麼沒有swipe的事件 ,flick,tap, 和pinch?我不希望獲得計算機科學博士學位才能為支持觸控的網絡編程。
結論
我完全支持前進，不要誤會我的意思，TC-39 和 W3C 在解決當今許多問題方面都做了值得稱道的工作。我只是希望看到更多的解決方案，這樣我們就可以在接下來的十年裡不再重複解決同樣的問題。再過十年，我不想編寫 JavaScript 來解析 cookie 字符串，也不想爭論創建選項卡控件的最佳方法。這些都是現在值得關注的已知問題，以便我們在未來繼續解決更多有趣的問題。
