-
-
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
Doctype doesn't affect format #775
Comments
The single global For example, I have a Middleman website where the majority of the pages are HTML5 but where a subset of content needs to be XHTML 1.0 to have it served as an Apple Help book within a macOS desktop app. As a hack the site has to be built twice, twiddling the Similarly, in every recent Rails app I have worked on, the site itself needs to be HTML5 but emails need to be XHTML. I still haven’t found a good way to do this and simply resort to not using Haml for email templates, which is a shame. I think the doctype directive should override the global |
I have the same problem here. I need to render some of the templates in xhtml in order to generate pdf but the rest of the templates should be html5, otherwise it breaks my styles in some places. For the pdf generation I use the I tried the following options which didn't work:
None of these did work. The only way for the moment is to use something like this in the templates:
for all the empty tags that need closing. This is definitely not the way to go but is currently the only workaround I've found unless I switch to erb... |
Changing compile format inside template is a little hacky. This is just idea: How about allowing to switch format by filename like foo.xhtml.haml or bar.xml.haml? Interface of Haml may have some possibilities. |
Off topic: I think you can write it as (of course we should consider the solution I commented above):
|
@k0kubun I guess it’s a matter of perspective, but I don’t see anything hacky about specifying the format inside the template—what better place to indicate the format that a template is compiled using than in the template itself? This is already basically what the doctype in an HTML document is doing in the first place. From the point of view of pragmatism I wouldn’t have a problem with the filename determining the format, except that doesn’t work in situations where you need a file to be generated in XHTML but with an |
IMO, Haml template is responsible for what it renders, how it is compiled is a different layer and this feature request would make it hard to expect how the template will be compiled. Apart from that, actually we may not have the situation we want to specify But note that this is definitely backward-incompatible. Hardly introduced if it's not discussed well. And I have a following concern: Currently format option decides how doctype is rendered. With this feature, the decision direction will be reversed and we should not decide how doctype is rendered by format option, because format option itself is changed by doctype. It's circular reference and definitely hacky. How do you distinguish |
Hmm, I don’t really think it makes it hard to know how the template will be compiled: it will be compiled according to the global Right now, Haml can’t be used to solve certain common, real world problems because of this shortcoming.
Just to clarify, the problem is not that we want to generate HTML5 documents that contain an XHTML doctype. The problem is that we need certain templates to render in different formats entirely within the same project—e.g. some in HTML5 and some in XHTML. With the current behavior the only thing you can do is choose the doctype that gets output in a particular document, even though the markup being produced does not match that doctype because of the global
I’m not set on any particular solution to this problem—I would just like to be able to render templates in different formats within the same project. So if there’s a backwards-compatible way to achieve that functionality then I’m all for it.
It’s precisely this behavior that is leading to the confusion in the first place, I think. So you’re right that this change would be backwards compared to the current functionality—but I think the current behavior is backwards in the first place. If you look at the tickets I linked above, people are consistently confused by the existence of this
To me, I think the ideal solution would be one where the
I haven’t thought this through fully, though, and I’m not familiar with the Haml internals, and I agree that the above proposal would not be backwards-compatible. The above change would make it work the way I and many people expect it to work in the first place, though, and it would solve the particular problem of not being able to output documents in different formats in the same project. But again, I’m not married to a particular solution—I just would like some way to be able to change the format for individual templates, whatever the best solution for that might be. |
Thank you for your opinion. I'm open to hear other ideas to find the best solution for this. This is a little difficult problem. |
Yes, thanks for discussing it! This is just my perspective as a Haml user—I understand this is a tricky problem to fix and there probably isn’t a good solution that would work for everyone. I do definitely see your point that overriding the format in the templates themselves is hacky certainly from the way Haml currently works, and that having the |
This is definitely interesting. Especially considering changing fashions. When Haml was a new baby OSS project– doctypes were all the rage, but by the time we got around to 2010, we started moving away from them. And at this point, so many people are writing SPAs that I bet half the junior developers I work with aren't even sure what a doctype is. I do feel that as we are a project that specifically supports HTML (and XHTML)– that the doctype should be the primary driver of the output. That makes sense to me and would be my natural assumption. Now, of course, as soon as we do that– we'll have people say "But I WANT my XML document to be HTML5-like!"– except I think we can all agree they'd be wrong. It's much more pleasant to say "Ah, yes, this is an XML file... and here I am declaring it clearly!" and that we then trust that. |
Source:
Expected:
Actual:
With
format: :xhtml
the link tag gets the closing slash so it's valid, but I want HTML5 elsewhere; I shouldn't have to deal with that when the doctype is explicitly set to XML.If the XML doctype always declared strict formatting that would fix this I think.
The text was updated successfully, but these errors were encountered: