-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Less browser: append a new style tag instead of changing the content of existing tags #3199
Comments
Seems like a legit request. I suppose the rationale (I'm guessing) was that the existing style tag is not relevant. The fact that calling |
True. I also completely agree that |
That would be my guess as well. That is, this behavior was not "designed" this way, it's just a legacy effect of a few features introduced over time. |
Re-reading this issue, replacing a style tag is really the safest way to get a "fresh" set of styles. That is, if your Without a bunch of re-factoring, I don't know that any change there is really possible. |
I can think of a way to fix this issue without too much refactoring: We could rely on the presence of a While loading the styles, if this attribute exists, we would use If you dislike the idea of generating ids, then only doing the first part (checking for the existence of the attribute and the presence of the "target" style element with this id in the DOM) would already be enough to let users of |
Hi,
This is a feature request concerning
less-browser
.Current behavior
There are currently 2 ways of compiling a less resource to css client-side: either put it in a
<style type="text/less">
or href it in a<link type="text/less">
. less will react to these two things.Unfortunately it reacts in two different ways: for
<link>
, it downloads the resource, compiles it and adds it to a new<style>
(see less-browser/index.js#L186). But for<style>
, it compiles the content of the tag and replaces it in place (see less-browser/index.js#L68).Description of the proposed feature
A single behavior would be nicer, and I believe that adding a new
<style>
tag is the best option (as opposed to changing tags that were put in the DOM by the application using less). With the current behavior indeed, using a<style type="text/less">
, forces you to re-append it to the DOM each time that you perform aless.modifyVars
.You might say that if I want the less resource to stay there and be taken into account at each new
modifyVars
, I can just use a<link>
tag. But it's not always handy. For instance, if you develop a library, using a<link>
forces projects using you to maintain a custom webpack config, whereas using a<style>
lets you bundle the resource yourself.If changing the behavior is not possible, it could be enough to add a convention for it (for instance, if the style tag containing the less resource has an id, then it could remain untouched in the DOM and another style tag with the compiled css could be appended by less)
I hope that this is helpful. Anyway, thanks for the great tool!
The text was updated successfully, but these errors were encountered: