-
-
Notifications
You must be signed in to change notification settings - Fork 571
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
Haml 5.2 and 6 #1041
Comments
Yeah, at this point, I'm trying to revive a pretty-dead project solo. Haven't really setup any discussion areas and would definitely be willing to. The google group is definitely long-gone. There are several things I KNOW we want to add in Haml-6.
Things we might want to add:
Also, about half the codebase is dealing with Honestly, I don't have any specific things that I'm planning on not supporting, but I just have a feeling that we're going to run into more edge cases that are going to be nearly impossible to support with a multi-line syntax. And to be clear, I'm making these changes because I'm using Haml in a whole new startup with a team at @veuelive and a growing codebase, and it's clear where Haml isn't staying up-to-snuff. |
Just to add on a bit more about However, the downside of this is that Perl/Lua implementations are abandoned and the Python one gets small compatibility updates every ~2 years. This has meant that the language itself has ossified in an attempt to get disperate parsers+interpreters to have some kind of standardization. When I originally designed Haml, one of the design goals was to make it "Ruby-like" and sort of natively inhabit a space between Ruby, CSS, and Semantic HTML. I certainly wasn't thinking of the language as a competitor to Markdown or some other simple, highly portable markup language. And yet, efforts like I don't regret making content after As you can tell, this isn't yet a plan, but it's a lot of things I'm considering with what to do best to help get Haml back into shape for 2021+. |
Thanks, that gives me a lot more context. Appreciate your efforts. |
For more context, here is my current Gist that includes my ideas for Haml 6. https://gist.github.com/hcatlin/6c5d24d27897b9fa0888a012b612e824 To note... ability to chop-down attributes and the use of & to make a BEM-style parent appender.... in the sample, |
I'm also using HAML at a new startup and still find it to be an excellent companion to the Rails app. We use utility-based CSS (Tailwind) and which pairs well with HAML since there ends up being a fair amount of class names and nesting. Let us know if we can pitch in on anything. |
How much against HAML philosophy would be a change to allow to split long sequence of class names? We use Tailwind as well and end up with things like: %h1.font-bold.text-2xl.lg:text-4xl.text-grey-600.mt-2.lg:mt-6.leading-tight.group-hover:text-black.group-focus:text-black.transition.duration-150.ease-in-out which is far from easy to read compared to an imaginary version: %h1.mt-2
.font-bold.text-2xl.text-grey-600.leading-tight
.transition.duration-150.ease-in-out
.lg:text-4xl.lg:mt-6
.group-hover:text-black
.group-focus:text-black There are obvious implementational problems with this example, I'm asking whether it's completely out of the question for the project. |
I was curious to find out what that meant in real terms but I couldn't find a place where this was discussed. Looking at the haml website, the mailing list has been unused for 3+ years, the blog hasn't been updated since haml 4.
I'm starting a new project and "the next version of haml won't have all the features it currently has" without any mention of what that means is scary.
The text was updated successfully, but these errors were encountered: