看到一個 demo 展示瀏覽器內 CSS 的處理能力，看起來已經足夠到可以處理不少貼圖與光線效果的部分了：「CSS FPS」。
This is demo of a CSS powered 3D environment. Geometry is created with HTML elements and CSS transforms. Textures and lightmaps are composed by layering multiple background-images and colour is applied using CSS blend-modes.
不過遊戲應該會需要更多種類的效果，這部份目前應該還是得靠 javascript 來產生... (如果要在瀏覽器裡面跑)
看到「Mercury Goes Open Source!」這篇，Postlight 的團隊開源了 Mercury Web Parser，程式碼在 GitHub 上的 postlight/mercury-parser 可以取得。
這個版本是用 Node.js 寫的，可以從範例看出用法以及結果：
import Mercury from '@postlight/mercury-parser'; Mercury.parse(url).then(result => console.log(result););
{
"title": "Thunder (mascot)",
"content": "<div><div><p>This is the content of the page!</div></div>",
"author": "Wikipedia Contributors",
"date_published": "2016-09-16T20:56:00.000Z",
"lead_image_url": null,
"dek": null,
"next_page_url": null,
"url": "https://en.wikipedia.org/wiki/Thunder_(mascot)",
"domain": "en.wikipedia.org",
"excerpt": "Thunder Thunder is the stage name for the horse who is the official live animal mascot for the Denver Broncos",
"word_count": 4677,
"direction": "ltr",
"total_pages": 1,
"rendered_pages": 1
}先前其他的軟體與服務可以參考「Evaluating Text Extraction Algorithms」這篇的整理與比較，不過這篇連原網站都不見了... 只能從 Internet Archive 上翻出來。
這個主題有不少團隊都做過 (給一個 html 網頁，抓出實際的內容塊落)，但也死了不少團隊... 比較有印象的是 Readability，在 2016 年收掉了：「The Readability bookmarking service will shut down on September 30, 2016.」。
要撈資料可以拿來用...
除了讓 browser 自己決定優先權外，在「Preload Scripts」這邊看到的技巧，可以跟 browser 說明哪些資源比較重要，請儘快先下載：
<link rel="preload" href="main.js" as="script">
Link rel=preload is useful for downloading any important resource more quickly, such as stylesheets that contain critical CSS, fonts that are used in important design elements, and hero images. It's especially important for scripts because they block page content from rendering and consume the most CPU during page load.
以作者的想法，這個技巧應該用在會卡住頁面呈現的部分，確保這些資源可以優先下載。
另外作者也提到了可以直接把這個資訊放到 HTTP header 裡面，理論上會更快：
Link: <main.js>; rel="preload"; as="script"
尤其是 sync script 應該會有幫助，建議可以跑 A/B test 看看效果：
We know that synchronous scripts block rendering, which makes the user experience feel slow. And we know that most scripts today are downloaded synchronously (rather than async). And yet only 1% of sites are using link rel=preload to download their scripts. If your site has any synchronous scripts, do an A/B test adding link rel=preload for them. It's likely this will be a win and help you create a more joyous experience for your users.
看到「jjkaufman/wiv.js」這個專案，然後點開他的 Demo Site「The web site of coughdrop」後笑出來，這把 2000 年網站的特色做到極致了... XD
看程式碼可以看到主體是在 canvas 上操作，然後用 requestAnimationFrame 產生。
在 MDN 上看到「CSS Layout cookbook」，目前整理了六種情境，包括了設計方式與瀏覽器的支援度。
看到「Center an element」有種苦笑的感覺啊... 以前弄這個都是 workaround，現在都有對應的 CSS 可以處理了。
我自己再用的 Trac 本來是走 HTTP 的 Authorization header 登入，但這樣每次重開瀏覽器就要登入一次，覺得麻煩... 就想要找套件改成用 HTML form login。
目前比較有在維護的應該是 AccountManagerPlugin 這套，內建就支援本機密碼，也支援 plugin 掛其他外部服務進去。
但掛進去後發現本來的自動開票機 (i.e. 用 crontab 開票) 就沒辦法登入了，最後找到得用 HttpAuthPlugin 處理。這個套件一開頭就寫了他也是為了 XmlRpcPlugin 而寫的：
This plugin allows you to protect certain paths with HTTP authentication. The AccountManagerPlugin is used to check passwords.
Primarily this is meant to be used with the XmlRpcPlugin, so it will work while using AccountManager's form-based logins.
就是遇到同樣的問題...
想說應該有這樣的東西，就找到「https://tools.ietf.org/html/new-rfcs.rss」這頁，本來以為直接就是 RSS feed 了 (因為網址)，一打開來發現看起來像是個網頁，結果最上面這樣說明：
Don't panic. This web page is actually a data file that is meant to be read by RSS reader programs.
馬上打開來看 page source code，果然是 XSL！
<?xml-stylesheet title="CSS_formatting" type="text/css" href="css/rss.css"?> <?xml-stylesheet title="XSL_formatting" type="text/xml" href="rss2html.xsl"?>
好久沒看到這個了，大概是十年前想要做到資料與效果分離 (client-side rendering) 的方式...
在「Large-scale analysis of style injection by relative path overwrite」這邊看到的，記得這個方式不是新方法，不過還是有人會中...
這種攻擊是組合技，基礎是引用 css 或是 js 時使用相對路徑 (像是 static/style.css 這樣的引用法)，再加上 https://www.example.com/a.php 這樣的頁面通常也可以吃 https://www.example.com/a.php/，甚至是後面再加東西... 在某些情境下組不出來，但精心策劃後就有機會在頁面上弄出奇怪的 xss 或是其他攻擊了。而論文內列出了常見的的組合：
然後拿 Alexa 的排名來看，其實還是有些站台可以打：
防禦的方式也不算太難，absolute path 是個還不錯的方式：
One option is to use only absolute URLs, taking away the relative path expansion.
而 base tag 也是個方式 (不過在 IE 上還是有問題)：
Alternatively you can specify a base tag, though Internet Explorer did not appear to implement the tag correctly (i.e., was still vulnerable) at the time of the evaluation.
另外作者也提到了 document type 的方式 (看起來是建議用 html5 的 <!DOCTYPE html>)，然後 IE 另外做些處理避免失效：
One of the best mitigations is to avoid exploitation by declaring a modern document type that causes rendering in standards compliant mode. This defeats the attack in all browsers apart from IE. For IE it is also necessary to prevent the page being loaded in a frame by using X-Frame-Options , using X-Content-Type-Options to disable ‘content type sniffing,’ and X-UA-Compatible to turn off IE’s compatibility view.
不過大型站台本來就因為業務需求，會把 asset domain 切開 (然後透過 CDN 加速)，而且會設計系統讓 programmer 很容易使用這樣的架構，反而因此比較不會用到 relative path，中這個攻擊的機會就低多了...
看到 GitHub 上的「emilwallner/Screenshot-to-code-in-Keras」這個專案，直接把圖片轉成 HTML。介紹的文章則是「Turning Design Mockups Into Code With Deep Learning」。
有點像是「將 Sketch 輸出成 iOS/Android 的程式碼」與「透過 NN (類神經網路) 訓練好的系統，直接把圖片轉成程式碼」(後面這篇剛好在介紹文章裡也有提到)。
愈來愈有 NN 在逐步取代人類工作的感覺了...
W3C 推出 HTML 5.2，新的 W3C Recommendation...
但網頁開發已經沒有人在管 W3C 的 HTML X.Y 了 (像是之前的 HTML 5.1)，大家都是直接翻資料查某個 feature 的支援度來決定能不能用，像是翻 Can I use... 或是翻 MDN。
就隨便看看吧... o_o