-
Notifications
You must be signed in to change notification settings - Fork 16
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
CSS selectors #31
Comments
This makes perfect sense and would allow targeting elements with super high precision. |
It's an interesting idea, and given that the core is getting fragments out of a template, initially I would say it's a good request for jinja2-fragments. On the other hand, the implementation would be very different from how jinja2-fragments is currently working. Right now it's leveraging jinja blocks, which jinja is already able to "chop". For CSS selectors, we would need to rely on some dependency (if any exists) to extract the fragment. And following this train of thought, at this point we don't even care if it's a jinja template or some other template format. Which makes me wonder if having a separate library (css-fragments?) would be more appropriate. Then, one could extract the fragment using the CSS selector, and then pass that fragment to their template engine of choice. I'll leave the issue open for now as I thinks it's an interesting conversation to follow. |
"css-fragments" would be a misleading name imo. Something like BeautifulSoup would provide the necessary tools to select by both css and id. |
Oh, with my comment I didn't mean to rename jinja2-fragments, but to build that functionality on a new library. As you suggest, HTML fragments would probably be a better name for that. I'm not familiar enough with BeautifulSoup to assess if that new library would make sense, though, if BeautifulSoup is already very easy to use in the way described above. |
I haven't used Flask and Jinja for a long time and just stumbled upon this project via the htmx website.
So maybe my suggestion doesn't make much sense. But here it is:
Have you considered using CSS selectors in a
render_
function instead of (or in addition to) marking the blocks explicitly with{%block%}
and `{%endblock%} in the template and giving them a label?That would provide way more flexibility, but only work for html.
It would also now be unclear that this template is being depended on (and how),
but maybe this drawback is acceptable or could otherwise be mitigated.
The text was updated successfully, but these errors were encountered: