Chrome 26 Beta: Template Element and Unprefixed CSS Transitions

http://blog.chromium.org/2013/02/chrome-26-beta-template-element.html

by avolcano • 13 years ago

63 34 13 years ago

blog.chromium.org

mzarate06• 13 years ago

I like the Template element, but what I'd really like is a way to escape out of JavaScript and html directly to my JavaScript views. That'd be more convenient than splitting client side view development across the JavaScript logic and html templates that reside somewhere else.

Plus, I think that'd offer caching benefits vs. having to send templates across the wire every time.

Encosia• 13 years ago

I keep most of my templates in separate .htm files and load them via XHR for a handful of reasons, including caching as you mentioned. Works great.

It would be nice if the new template element had built-in support for that (e.g. a src attribute and maybe some sort of control for loading immediately, after document ready, and/or on demand).

gosukiwi2• 13 years ago

Awesome indeed, the thing that always makes me sad though is that you'll always have that IE 8 user which can't see your website properly, sure, you can use Javascript to make up for it, but it kills the whole emotion of using something awesome.

patrickaljord2• 13 years ago

Why does it kill the emotion? With yepnope (and other libs) you can do conditional loading and only use the JS shims on IE8 while the other always-green browsers use the awesome stuff.

gosukiwi2• 13 years ago

I know, and it's awesome but I'd like to just say "Cool! Now I can use this awesome technology and forget about the 100 JS alternatives for doing the same thing", but I still cannot forget about those ;(

comex• 13 years ago

Not to mention the controversial Encrypted Media Extensions. I'm curious to see who the first to use them will be, and how easy the implementation will be to break.

mtgx• 13 years ago

I hear Google may be using it in Chromebook Pixel.

UberMouse• 13 years ago

I don't see how the template element is something special, can't you use that Javascript on any container?

Mahn• 13 years ago

I suppose it's just for semantic purposes, just like the "article" element; ie, to make the markup pretty.

patrickaljord2• 13 years ago

FTA:

> The element allows you to store HTML fragments that you intend to use for any reason at any time during the lifetime of your page, but that aren’t ready or shouldn’t be used during page load.

It's faster because it's not interpreted until it's actually being used. Think of all these mustache templates or display: none elements that are not needed on page load.

JoshTriplett• 13 years ago

Not just to make the markup pretty. It also means that if you view the page without scripting, or with a screen reader, you'll get results that make sense. And it means that robots, scrapers, indexers, and search engines can actually see the template content, which they can't easily do if you embed it in Javascript document.createElement calls.

defen• 13 years ago

The <template> element and the Object.observe method both seem tailor-made for speeding up angular.js based apps.

mixmastamyk• 13 years ago

Another article here today pointed me to this: http://caniuse.com/calc

CSS calc() unprefixed on Chrome 26+

pixie_• 13 years ago

How about fixing the bug that caused MathML to be removed in version 25.

derefr2• 13 years ago

Webkit/Chromium/Chrome's project development process is interesting. From what I've seen on the bug trackers, whenever a piece of code (no matter what size) causes any sort of stability/performance regression at all, the patches committing it are aggressively backed out and dropped on the floor, with the expectation that whoever cared enough to commit them in the first place will realize their code was pulled, fix it, and re-commit.

This causes features to sometimes just "go missing" for long periods of time, if the original committer (i.e. the code's only advocate with commit privs) A. works for some big company that's not Google or Apple, and thus has other responsibilities; B. was just "helpfully" pushing the code they wrote for their own private fork of Webkit/Chromium; and C. doesn't much care what happens to it in the OSS project after that.

bengoodger• 13 years ago

There's definitely a mindset on Chrome that:

- any feature, no matter how small, has some cost (code size, testing, cognitive complexity, etc), and frequently contributes in some way to making the product and/or other development slower. - as a developer, user, product manager etc, it's up to you to figure out how to convince other people your change is a good idea, and how your change will be maintained going forward, if you have to switch projects for instance.

We have a long history on the Chrome team of deleting code that was only relevant to one or two developers and those developers moved onto something else. It's the only way to stay sane at our scale, frankly, and we don't even do it as much as we should.

fatjokes3• 13 years ago

Is anybody else's Chrome on Mac crashing frequently? I'd like them to fix that first. Also, the whole no Flash on Linux thing.

aubonpanzer• 13 years ago

Word.

EDIT: chrome has flash on linux, last i checked. are you using your package manager's version of chromium?

fatjokes3• 13 years ago

Nope, google-chrome.

I found a fix shortly after I posted this comment.

They fixed in v24 (but mine isn't upgrading automatically, even after restart from v22). So instead, I followed this:

http://productforums.google.com/d/msg/chrome/PEgELQH5zcg/c5l...

ry0ohki• 13 years ago

Yes, started about a week ago, crashes (but Mac OS doesn't seem to detect it as a crash), I'm not using any plugins, etc...

thehodge• 13 years ago

I have exactly the same issue, I've not found anyone else experiencing it and it's actually quite hard to google for ;)

cgcardona• 13 years ago

Yes starting with Chrome 25 on Mac I've had at least one crash every single day.

I honestly used to go weeks or longer without any crashes.

shadowmatter• 13 years ago

I have word that #45 may have the solution in this issue: https://code.google.com/p/chromium/issues/detail?id=175341

salmanapk• 13 years ago

Does this break Meteor.js? (It uses <template> for.. templates)

mvzink• 13 years ago

Seems like it shouldn't, since it appears to require invoking JS code to use the templates.

kevincennis• 13 years ago

This would be a lot more exciting if there were a way to insert data dynamically like Handlebars, Mustache, etc.

VeejayRampay• 13 years ago

Templates look nice, but I really wonder how different this technique is from document fragments that one can create using document.createDocumentFragment and other related DOM handling through the convenient JS API.

malandrew• 13 years ago

What's the performance on <template>? This approach seems like it'd be slower than having templates precompiled on the server and already served as JavaScript.

adlpz• 13 years ago

I assume the only overhead will be how much they weight in your DOM (this is inevitable anyway) and whatever time it takes to clone the element. So probably it will be actually faster than compiling server-side and XHR-ing on-demand because you don't touch the network.

Chrome 26 Beta: Template Element and Unprefixed CSS Transitions

Related Stories