cramforce

AMP is just HTML.

Since this exclusively uses web tech there is absolutely nothing publishers cannot do today.

A big problem is that they don't and AMP is as much about fixing that as about technology.

Doc bug. Github issue is here https://github.com/ampproject/amphtml/issues/96

Fixing right now.

It isn't valid technically HTML but custom attributes aren't really that unheard of. Certainly there are no known user agents that have even close to a problem with it.

As to discovery: You use a link rel=amphtml tag on the canonical and then point the AMP file back via a link rel=canonical

They can, of course, be the same file if your AMP file is the canonical.

The idea is that that would be very easy :)

Chrome has supported this since about 2011. It is not actually new. And because it was implemented before the WebKit/blink fork even Safari supports it as well. Firefox is the 3rd browser.

Not a zero sum game though (although I do realize this is hackernews :). addEventListener is sometimes strictly better than using jsaction. i.e. it supports removing event listeners. That is fine. Right tool for the job.

onclick-like functionality is coming back to frameworks. Angular and Polymer both have variations of what jsaction provides as a single-purpose library. It is sometimes just much nicer to bind stuff together directly.

It could probably be integrated nicely with backbone. This is much more low level.

It is 2.5KB to 6KB (depending on enabled flags) gzipped which is still in the realm on inlining into the HTML – thus avoiding a roundtrip for enabling event handling (even if all the handlers do is download the modules that have the actual implementation).

Actually you can also see traces of the jsaction attribute in the G+ product. G+ isn't using this from the group up though. It has a pretty long history at Google, so I'm not even sure where it came from. Should have been either Maps or Search.

Well they did not. Until Chrome changed the behavior to comply with http://www.w3.org/TR/CSS21/zindex.html

The spec says Chrome is right (was recently changed). Chrome is not the only browser. iOS browsers, the Android browser and Chrome for Android have always used the new behavior. The reason for the change is faster scroll performance, particularly on mobile.

The spec agrees with you, but even MDC does not: https://developer.mozilla.org/en/DOM/DOM_event_reference/DOM...

DOMContentLoaded, in all important browsers, does block to wait for CSS. Manipulating the DOM before this event both increases the chance to make changes before first-paint (decreases "jigger" on page load) and gives you the chance to request more resources earlier.

Also works with encryption.

At the last JSConf, 370 attendees, ~1000 devices online. You are absolutely right. At a certain density all bets are off. We were pretty close to this point at several points in time. The problem gets much harder with more people.

The blog post is very much not about technical details. Having people who actually care is what really counts. This is all, of course, presented in term of not-for-profit-conf where paying people to get it right is usually not an option.

No Mesh magic involved. Just set them all to the same SSID and it will magically work.

Hardware: http://www.ubnt.com/unifi Monitor software: tail -f

You're right I changed the language. Actually we did use 5Ghz for the purpose you described extensively in previous years.

I might have been a little harsh on the 5GHz. There is currently a pretty widespread active problem (might depend on AP hardware/software) with some Apple hardware that is pretty much impossible to debug on a large scale, so that the only option we found was to disable it.

I was there, too and I had a little tears in my eyes.