Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include at bottom #32

Open
mrijken opened this issue Nov 10, 2014 · 5 comments
Open

Include at bottom #32

mrijken opened this issue Nov 10, 2014 · 5 comments

Comments

@mrijken
Copy link
Contributor

mrijken commented Nov 10, 2014

For some .js files, it's better to include them at the bottom of the html file. Do we want that feature in bowerstatic?

@faassen
Copy link
Owner

faassen commented Nov 11, 2014

Yes, I'd like to support that. We had this in Fanstatic. In Fanstatic I had a whole complicated infrastructure about declaring resources "bottom safe" and including them by default in the bottom of the HTML file if so. I think we need something simpler in BowerStatic; perhaps just an argument to the inclusion so that the developer is in control of this behavior.

Plus perhaps a flag in the bower object that turns bottom includes on or off for all inclusions -- a default for this inclusion flag.

Does that make sense?

@faassen
Copy link
Owner

faassen commented Nov 11, 2014

I just realized that this is related to the renderer (or extension) too. CSS and .ico should never be included at the bottom. So perhaps we should extend the notion of a renderer to also have knowledge about whether can be rendered at the bottom, by default "no".

@faassen
Copy link
Owner

faassen commented Nov 11, 2014

This means it's relevant to issue #34, where we also talk about the renderer infrastructure.

@faassen
Copy link
Owner

faassen commented Nov 18, 2014

See also #37

@faassen
Copy link
Owner

faassen commented Nov 19, 2014

This issue implies we need to have renderer classes that can have a property set inject_bottom or something like that. But this affects the renderer infrastructure somewhat, as now it's function-based. I'd like to retain the function-based API as much as possible but support render classes. So this implies we need to wrap the render functions into a class, probably at the point of registration, if it's a function, with a default of inject_bottom set to False.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants