Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome 26 Beta: Template Element and Unprefixed CSS Transitions

blog.chromium.org

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Chrome 26 Beta: Template Element and Unprefixed CSS Transitions

#11

Post by patrickaljord »

Mahn wrote: post #8
UberMouse wrote: post #6

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

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

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.

Re: Chrome 26 Beta: Template Element and Unprefixed CSS Transitions

#12

Post by derefr »

pixie_ wrote: post #9

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

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.

Re: Chrome 26 Beta: Template Element and Unprefixed CSS Transitions

#13

Post by bengoodger »

derefr wrote: post #12
pixie_ wrote: post #9

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

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…

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.

Re: Chrome 26 Beta: Template Element and Unprefixed CSS Transitions

#16

Post by Encosia »

mzarate06 wrote: post #2

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.

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

Re: Chrome 26 Beta: Template Element and Unprefixed CSS Transitions

#17

Post by JoshTriplett »

Mahn wrote: post #8
UberMouse wrote: post #6

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

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

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.

Re: Chrome 26 Beta: Template Element and Unprefixed CSS Transitions

#18

Post by aubonpanzer »

fatjokes wrote: post #15

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.

Word.

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

Re: Chrome 26 Beta: Template Element and Unprefixed CSS Transitions

#20

Post by derefr »

bengoodger wrote: post #13
derefr wrote: post #12

Earlier quoted context omitted.

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…

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 forwar…

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

Post reply on HN