11–20 of 37 posts
I have to agree with this article in that there is FAR too much text being added to the webpage for this functionality. Separating it out into a separate file is the way to go. You know, like CSS already does.
I wonder what the trade off is for 1KB of text or an extra HTTP request.
1) It's much easier to stick meta tags in HTML than it is to reference an external file in many cases (blog hosting services, hosted storefronts, etc).
2) Sites that make the best use of that menu will have different data depending on what page is pinned. We didn't do much implementation, but assuming enough people used IE9 we'd probably make that set of meta tags page dependent. Separating it into an external link when it's page specific data doesn't make a bunch of sense. Particularly page specific data that changes frequently.
Also, that 1kb of text is more like 260 bytes gzipped (as it is for us). We'll survive. :)
Earlier quoted context omitted.
I wonder what the trade off is for 1KB of text or an extra HTTP request.
Wouldn't the trade-off be between an extra 1KB on every page vs. a single extra HTTP request per user?
I have to agree with this article in that there is FAR too much text being added to the webpage for this functionality. Separating it out into a separate file is the way to go. You know, like CSS already does.
I wonder what the trade off is for 1KB of text or an extra HTTP request.
I have to agree with this article in that there is FAR too much text being added to the webpage for this functionality. Separating it out into a separate file is the way to go. You know, like CSS already does.
I wonder what the trade off is for 1KB of text or an extra HTTP request.
The main argument seems to be that the metadata involved here is to do with the site, not the page, whereas tags should be for resource-specific use.
Earlier quoted context omitted.
I wonder what the trade off is for 1KB of text or an extra HTTP request.
Bear in mind that a HTTP Request is significantly slower than the bytes in the page. A request could be anything from .25s to 2 whole seconds, if the bandwidth is saturated. Not least problems with blocking other parallel downloads and delaying the initial paint. HTTP requests that are not images or the CSS are to be absolutely avoided!
Edit: Additionally, how does what's in the pinned menu get updated? Does it need to make a full page request to get the new items? This will needlessly inflate pageview numbers in that case (I'm sure the "fix" for that will be that Microsoft will change the User Agent to say that it's not the browser but rather than pinned menu making the request). As for implementation, does the browser create the menu from the this and it's static? Or does the URL to the page get passed to the menu bar where it is pinned and then the menu bar is responsible for making the request? Or does the browser actually run the menu bar -- this seems like the wrong kind of integration.
I have to agree with this article in that there is FAR too much text being added to the webpage for this functionality. Separating it out into a separate file is the way to go. You know, like CSS already does.
I wonder what the trade off is for 1KB of text or an extra HTTP request.
Previous discussion for background: http://news.ycombinator.com/item?id=1704173
Earlier quoted context omitted.
Perhaps, if the points to a menu.xml you don't control? I'm not sure what you could do with this that couldn't also be done with ...
Sorry, I wasn't more clear. I meant the browser feature, not the specific implementation. I think the idea in the article was fantastic, and would be much cleaner for developers.