Still deciding on everything you guys have suggested, to be honest. I think a better version of “ExtraContent” is possibly on the cards. Seems like something we’d be able to make much better if we integrated it natively.
Is there anything else apart from the colour feature that you think is a must-must-have?
We’re trying to make third-party devs and users happy with this release, well I mean that’s what we’re always trying to do, but sometimes that goes better than others…
Giving themes the ability to specify HTML lang would be awesome.
Giving the theme API access to more control types would be awesome. I don’t don’t make more themes because the API is so cumbersome. You need to create so many CSS files compared to what I can do inside of a stack.
Improving the HTML output of the Style Text engine would be very welcome. This would bring a lot to Stacks as well since its used for text areas.
I had another interesting idea. I always forget about the Health Check stuff. What if there was a little notification flag on it (with the number of errors) to alert people that there are issues that may need to be addressed. Is there a way for plugins to tap into this and add their own Health Checks?
Is the .rw8 extension a temporary thing? Having yet another version specific extension seems wrong. I like it for during the beta because my projects open in RW7 again. Could you simply add a flag inside the plist in a project to reflect what version of RapidWeaver created the file?
Files created or saved in RW8 are not backwards compatible, hence the new file extension. We’re trying to save users from themselves. We’ll see how this goes, we can flip it back if needed.
Great suggestion. And yeah, Health Check is available for plugins (RWPluginHealthCheckProtocol) — ask @simon or @tpbradley if you have any questions on implimenting this. Maybe this is something @isaiah could start supporting in the next version of Stacks
Looking into adding this now!
yeah, understood. The theme API is very basic, and we have talked about overhauling it, but again I’m not sure this will happen for 8 as it’s a huge thing. Would love to do this, but we’ll see how we go.
This will be in the next RW8 beta release. Here’s some information for you:
You’ve always been able to hardcode a language into your theme by using:
<html lang="en">
This will still be the case in RapidWeaver 8. If you want to opt out of this new feature, you’ll want to hardcode a language in your theme.
However, if you don’t hardcode a language then we’ll insert a language attribute in there. We’ve added a new option in General settings for the user to specify their website language.
So if the user selects “French” as their site language, we’ll insert lang="fr" into your <html> tag:
<html lang="fr">
Something to note: if the user selects a language that uses a Right to Left writing direction (such as Persian), we’ll insert this:
<html lang="fa" dir="rtl">
This should also play nicely with any other attributes you’ve inserted into the html tag.
Does that work for you? Is it what you had hoped for? Do you have any more feedback on this feature?
Sweet! The RTL things would be nice. I currently maintain a separate Foundation theme for RTL users. Although, there is more to it then just that attribute, it would be nice if this could be user defined as well.
It could be nice if there was a app wide preference to the values for things like this on new projects.
I’m not sure that’s useful, is it? RTL languages are always RTL, and LTR languages are always LTR. There are no cases where you’d want to specify “Persian” as the language, but then specify “LTR” as the direction - are there?
I suppose we could add the same check to dir as we do for lang - if the theme specifies it already, don’t add it. So if your theme only supports LTR, you could specify:
<html dir="ltr">
Then if a user selects “Persian” as their language, the theme will end up as:
<html dir="ltr" lang="fa">
I can’t see where this would be useful, but it should provide you with the functionality you’re after.
I definitely think that would be useful. I don’t think adding ltr is required though. Only add rtlwhen requested.
If you do decide to do this though, you should probably go one step farther and allow themes to supply separate CSS files for when RTL is set. This could be really nice to have. It would also expose RapidWeaver to a new markets where people could have ignored it for not supporting RTL very well in the past. I have had many users praise me for having an RTL version of my Foundation theme.
Nice idea. I’m not sure the theme API will support something like this, but it’d certainly be possible using javascript:
On document load, check and see if the html element has a dir attribute of rtl. If it does, insert a new style element into the DOM that links to your RTL.css file.
It wouldn’t work when JS is disabled, but I think this is as good as we’re going to get with the current theme API unfortunately. I’ll look into it though.
It would be nice. If the dir attribute exists, at least devs can target it with CSS. It just means that CSS will get published to both RTL and LTR sites. Not the end of the world, but would be nice if ti could be kept separate.
Apple seem to think that Japanese is a Left to Right language (we’re using their NSLocale class to handle this for us), but it’s possible there’s another more suitable option if you want to specify RTL.
This from RW7.5.5 styled page after typing the text gets inline style font attributes.
Might not be possible to work around this but I know some JP writers were requesting this to be changed a few versions ago. Not sure if this has already been fixed/mentioned…
