Done! ... very sorry about this.
On May 16, 8:23 pm, "marius d." wrote:
> ooops .. checking it right now :(
>
> On May 16, 7:53 pm, David Pollak
> wrote:
>
> > I think you missed a file during your checkin. The Tail object is missing
> > :-(
>
> > On Sat, May 16, 2009 at 7:15 AM, marius d. wr
ooops .. checking it right now :(
On May 16, 7:53 pm, David Pollak
wrote:
> I think you missed a file during your checkin. The Tail object is missing
> :-(
>
>
>
> On Sat, May 16, 2009 at 7:15 AM, marius d. wrote:
>
> > Folks,
>
> > I just added builtin snippet support.
I think you missed a file during your checkin. The Tail object is missing
:-(
On Sat, May 16, 2009 at 7:15 AM, marius d. wrote:
>
> Folks,
>
> I just added builtin snippet support.
Folks,
I just added builtin snippet support.
On Sun, May 10, 2009 at 10:39 PM, marius d. wrote:
>
>
>
> On May 10, 10:08 pm, Viktor Klang wrote:
> > What I've been noodling about for some time is to have dependency
> management
> > as a part of the framework. That could be easily obtained by having
> widgets
> > etc register their dependen
On May 10, 9:35 pm, Timothy Perrett wrote:
> Yeah google analytics is a good use case. I think talking about
> smashing static files is off topic, but there is some value in having
> a tail merge for when you want to put stuff in just before the body
> tag. My only thinking right now is that wh
Been thinking about this more, just trying to explore where this idea
leads:
- Where tail merge would really shine is that a snippet could be
embedded inside a div tag, for example, but still have a tail pushed
to the end of the page body.
- Script entries in the head and tail blocks could be qui
On May 10, 10:08 pm, Viktor Klang wrote:
> What I've been noodling about for some time is to have dependency management
> as a part of the framework. That could be easily obtained by having widgets
> etc register their dependencies in a SessionVar[List[Dependency]] and then
> simply add a Dispa
What I've been noodling about for some time is to have dependency management
as a part of the framework. That could be easily obtained by having widgets
etc register their dependencies in a SessionVar[List[Dependency]] and then
simply add a DispatchPF to serve those dependencies as one package with
On Sun, May 10, 2009 at 7:02 AM, marius d. wrote:
>
>
>
> On May 10, 4:57 pm, David Pollak
> wrote:
> > On Sun, May 10, 2009 at 6:55 AM, marius d.
> wrote:
> >
> > > People can choose to "smash" multiple js/css files into a single one,
> > > in fact it is a common practice. However for scripts
Yeah google analytics is a good use case. I think talking about
smashing static files is off topic, but there is some value in having
a tail merge for when you want to put stuff in just before the body
tag. My only thinking right now is that why do we need a specific
snippet to do this? Right now,
A nice use for this "tail merge" would be for the Google Analytics
tracking code, especially the ecommerce tracking code.
Here's something to keep an eye on as well: http://blog.digg.com/?p=621
-- still very new and in development.
--Bryan
On May 10, 9:57 am, David Pollak
wrote:
> On Sun, May
fyi. if you smash css into a single file but continue using relative
urls in the css you'll end up with a slower page in the case that
you're using asset hosts to work around the browsers http connection
limit. when smashing into one file make sure to also apply the asset
host trick to any url() s
On May 10, 4:57 pm, David Pollak
wrote:
> On Sun, May 10, 2009 at 6:55 AM, marius d. wrote:
>
> > People can choose to "smash" multiple js/css files into a single one,
> > in fact it is a common practice. However for scripts that can be
> > deferred putting them at the bottom of the page can i
On Sun, May 10, 2009 at 6:55 AM, marius d. wrote:
>
> People can choose to "smash" multiple js/css files into a single one,
> in fact it is a common practice. However for scripts that can be
> deferred putting them at the bottom of the page can improve rendering.
Okay.. so we're not actually pu
People can choose to "smash" multiple js/css files into a single one,
in fact it is a common practice. However for scripts that can be
deferred putting them at the bottom of the page can improve rendering.
Br's,
Marius
On May 10, 4:42 pm, David Pollak
wrote:
> On Fri, May 8, 2009 at 5:26 PM, Ti
On Fri, May 8, 2009 at 5:26 PM, Timothy Perrett wrote:
>
>
> Sounds like this could be a neat addition. Looking forward to see what you
> come up with :-)
>
I'm not 100% keen on it. Loading a ton of stuff into the HTML page (rather
than having stuff cached by the browser) makes for larger page s
Me or marius? Personally, I'm full of ideas :)
On May 9, 1:26 am, Timothy Perrett wrote:
> Sounds like this could be a neat addition. Looking forward to see what you
> come up with :-)
>
> Cheers, Tim
>
> On 08/05/2009 20:19, "marius d." wrote:
>
>
>
>
>
> > A built in snippet might me a good
Sounds like this could be a neat addition. Looking forward to see what you
come up with :-)
Cheers, Tim
On 08/05/2009 20:19, "marius d." wrote:
>
> A built in snippet might me a good addition. I could
> probably allocate some time to noodle on it.
>
> Br's,
> Marius
>
> On May 8, 5:05 pm,
I like it.
Chas.
marius d. wrote:
> A built in snippet might me a good addition. I could
> probably allocate some time to noodle on it.
>
> Br's,
> Marius
>
> On May 8, 5:05 pm, KWright wrote:
>> It's becoming an established best practice that scripts should be put
>> at the END of a page, w
A built in snippet might me a good addition. I could
probably allocate some time to noodle on it.
Br's,
Marius
On May 8, 5:05 pm, KWright wrote:
> It's becoming an established best practice that scripts should be put
> at the END of a page, where possible, in order to speed up download
> times
21 matches
Mail list logo
