The main issue with backwards-compat here isn't that we aren't willing to break it, but that we should have a clear and easy-to-understand migration path. We need to be able to add a deprecation message and let that sit for a version before we make any breaking changes.
Detecting the parent element seems like a reasonable way to make this transition... if someone wants to work this into a patch, along with a deprecation warning (see Haml::Engine for an example), I'll merge it. Chris Eppstein wrote: > The implicit tags thread got me thinking that another idea would be to > be smart and add the style tag if one is not found in the nesting > scope of the :sass filter. That would be a nice backward-compatible > way to address this issue. > > chris > > On Oct 20, 6:57 am, John Schult <[EMAIL PROTECTED]> wrote: > >> On Sep 3, 5:29 pm, Chris Eppstein <[EMAIL PROTECTED]> wrote: >> >> >>> Regarding the :sass filter: I can imagine that we could set an option >>> that preserves backwards compatibility but can be easily turned off >>> for the correct behavior. Or we could break backwards compatibility on >>> master and document that change for the next release. Or we could >>> issue a deprecation warning for one release and then break backwards >>> compatibility one release later... In other words, I don't see any >>> reason to not proceed forward in making the framework better just >>> because we have users. >>> >> I would tend to agree. Having to use %script and then :sass is >> inconsistent. I understand that not all filters output a tag, but the >> ones that can should. >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/haml?hl=en -~----------~----~----~----~------~----~------~--~---
