

Chrome 26 Beta: Template Element and Unprefixed CSS Transitions - avolcano
http://blog.chromium.org/2013/02/chrome-26-beta-template-element.html

======
comex
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
I hear Google may be using it in Chromebook Pixel.

------
fatjokes
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.

~~~
ry0ohki
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
I have exactly the same issue, I've not found anyone else experiencing it and
it's actually quite hard to google for ;)

~~~
fatjokes
Oh... yay? Now I know I'm not alone! It happens quite frequently.

~~~
AUmrysh
I used to have an issue on linux (ubuntu and mint-debian) where chrome and
chromium would freeze the entire computer if left running long enough. I never
did find a solution for that.

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

~~~
derefr
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
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.

~~~
derefr
It probably is a good idea to get the code "out of sight", yes, but "deleting
the code from the repo altogether" still seems a bit odd to me.

I guess I'm too used to DCVSes with light feature branching--I would expect
every piece of code to end up in your codebase as a result of a merge commit,
and be backed out by backing out that merge commit--leaving the unmerged
feature branch itself available indefinitely if anyone ever does want to take
up the reins on that particular idea again. As it is, it feels a bit like a
publisher shredding every manuscript that contains a typo ;)

\---

Oh! And since I have a Chrome developer on the line, so to speak: when are we
going to see nearest-neighbour image-scaling
(<https://bugs.webkit.org/show_bug.cgi?id=56627>) in Chrome for Windows/Linux?
As it is, I get an _itch_ whenever I see pixel-art emoticons with CSS- or
device-zoom applied to them. :)

~~~
skybrian
It's not really deleting the code since it's still there in version history.
You can always revert the revert to get a similar effect.

------
mzarate06
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
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).

------
mixmastamyk
Another article here today pointed me to this: <http://caniuse.com/calc>

CSS calc() unprefixed on Chrome 26+

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

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

~~~
patrickaljord
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.

------
gosukiwi
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.

~~~
patrickaljord
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.

~~~
gosukiwi
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 ;(

~~~
justatdotin
that's your job. deal with it. or don't.

------
VeejayRampay
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
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
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.

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

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

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

