Month Abbreviation Format

Picky, picky, picky - I know it's legal to abbreviate the name of a month in a document, but I notice when that's done using BARR and BDEP the abbreviation does not have a "." at the end. (Mar vs Mar.) Any way to fix that or is there an option for a "long date" with everything spelled out?

Can't you just hard code the . after the tag? Seems to work for me.

But the tag inserts the full date, not just the month. So wouldn't that be putting a period after the year?

Let's ask the OR team to provide regex and css handling within custom fields so we can modify them on the fly, like adding a period at the end of Mar or changing font colors!

Strictly speaking, you *can* use CSS within custom fields.

**WARNING TO OTHER READERS** - you can REALLY mess things up doing this if you don't know what you are doing. CSS is very complicated, with unpredictable effects. You should always test *extremely thoroughly* after making any manual CSS configurations.

That said...

Here are the instructions for setting up a Custom Field:

https://www.ownerrez.com/support/articles/custom-fields

Notice that one of the options is whether you want to use a Rich Text field, or not. For most purposes, we recommend *not* using Rich Text because it adds needless complexity. E.g. just use plain text for your WiFi password or door code, you can do any formatting needed in the Email Template where the field code is used.

But, if you are using the field to generate a formatted block, what the Rich Text editor is actually doing is creating HTML under the covers. Most users don't know HTML and won't ever want to see raw code, but you can both see and edit it if you want to, by using the Edit HTML button in the editor. It looks like this: < >

And just like any other web page using HTML, you can insert CSS statements into the code. The Rich Text editor itself often won't properly render your CSS, but if the field is eventually being displayed in a browser (such as, on your Hosted Website), the browser will see the CSS and apply it.

Regex is a whole 'nother kettle of fish. I quail at the thought of trying to support users doing that, or trying to fix the confusion that can arise. I wouldn't anticipate that level of programming complexity will ever be available.

Ken - I agree about the regex, but I'm curious about your css comment.

The scenario I was envisioning is when I want to highlight a single word within a block of OR's insertable field text such as the table of billing details, for sending in an email. I don't currently have a website, but making emails readable is super important and sometimes css can help with that.

Is it possible to use CSS at all within email templates? I did a quick search and didn't see anything. I currently don't have any need to do that, but it might be handy sometime. And I hadn't noticed the <> in the text editor but seems like I could add anything I want to an email template in terms of formatting using css, right? But I'm pretty sure even if that works I couldn't do anything to a block of insertable text unless OR updated that capability within the definitions of the field itself.

None of this is any kind of priority, there are lots of other fun features that should be ahead of this I think ;-)

Email templates are already Rich Text Editors, so yes, you can set CSS inside of them as I've described above. Properly done, this CSS would apply to anything in the resulting email, including the data generated by field codes included in the template.

"Seems like I could add anything I want to an email template in terms of formatting using css, right?"

Yes, that's exactly right - including completely bollixing it up. Remember, email templates ultimately become an email that somebody is going to read in one of a million different email programs, whose support of CSS is nothing like as solid or consistent as with browsers.

"But I'm pretty sure even if that works I couldn't do anything to a block of insertable text unless OR updated that capability within the definitions of the field itself."

Not quite. When the email template is sent, the field code is simply replaced with whatever the content of that field is supposed to be. Whatever formatting is wrapped around the field code, will be applied to the value of the code. You probably already have this in one of your templates - are any of the field codes bold, or a different color? When you send the email, it'll be the actual value of the field that's bolded or colored. This is a very common usage, it's just not obvious what's actually going on under the covers.

And as noted earlier, if you program a custom field code to be Rich Text, then yes you have the capability of setting CSS inside the value of the field itself. I guess you're right that this isn't contained in the *definition* of the field, just one instance of it. Not even sure how we'd implement that, it would be a complex and confusing corner case, so I wouldn't expect that functionality.

OK, gentlemen! That jumped WAYYYY over. Hahahaaa! Mine was a simple request - that OR format it's dates to put a period after any abbreviated month name. Ken?

Being a bit of a grammar pedant myself, I do sympathize with your desire to properly signify the abbreviation.

But I don't think the engineers would consider this to be a particularly urgent matter to fix, I'm afraid. Also, the world seems to be going more and more towards not including the periods anyway.

And your legal folks are perfectly on board with that being accepted as part of a contract? (My "other life" involves a lot of contract work.)

Not sure what you're referring to, or how the presence or absence of a month abbreviation period would affect a contract. Maybe you posted this comment on the wrong thread?

Nope - continuing the chat about adding a period after Jan Feb Mar, etc. Format says an abbreviation in the middle of a sentence should have a period to show there are additional letters that weren't included. All the contracts I've done I would write "contingency to be satisfied on or before March 13, 2020." Using your date format that would come out as "on or before Mar 13, 2020." My question is does it make a difference, for a legal document (a guest contract/agreement), that you aren't writing it as "on or before Mar. 13, 2020." Like I said, picky.

Oh. Well, I'm not a lawyer, but as I recall from my b-school law classes, I think it's pretty unlikely that the presence or absence of an abbreviatory period would make any difference in any sane jurisdiction. A general principle of contract law is to consider the clear intent of the contract as written, and I don't see a lot of room for debate on that regardless of the period.

Of course every jurisdiction is different, so to be absolutely sure, you'd need to consult an attorney in the jurisdiction you operate in. In my personal, non-lawyerly opinion, they'd say "No" and happily send you a bill after they finished chuckling. :-)

lololololol!