The Disabled attribute has a special use in Roll20, but is often used uncorrectly. There are two main situations you use it:
- To Disable an html element (well, duh). There are often elements, like inputs, textareas, and the like, where you want to keep them as their element but don’t want users to be able to change them. There are good reasons to do this, but there are pitfalls to this approach.
- To Create an autocalc field. If you add the dabled keyword to an input, you can give it;s value a calculation, and then it will calculate that automatically. This is not a standard HTML feature – its specifically a roll20 feature. It was once the only way to automate sheets but now there is a better method: sheet workers. Still, autocalcs have their attractions…
How to use this property?
When you create a disabled element you should do it like this:
<input type="number" name="attr_example" value="10" disabled>
<textarea name="attr_another_example" disabled></textarea>Code language: HTML, XML (xml)Notice this these examples, I do not type disabled="true". The =true part is completely unneccessary and, more to the point, completely ignore.
In HTML these statements all mean exactly the same.
disableddisabled="true"disabled="false"disabled="disabled"disabled="anything"
When HTML sees the disabled keyword, it treats that element as disabled, and discards any properties assigned to the keyword. disabled="true" and disabled="false" are identical, because the = and anything after it is ignored.
You could use disabled="frodo" with exactly the same effect. Just having the word disabled there ensures that element will be disabled.
Disabled or Readonly
When using disabled, that element is now no longer accessible. Users can no longer click it, or enter it. (There are in fact still ways to alter the value enclosed, but they rae arcane and ibscrure and you can safely ignore them.)
So a disabled element is disabled – you can’t interact with it. That has an important side effect: you cant affect it with sheet workers. Sometimes you want the GM or automation to be able to change an element, but you want to make sure that users can’t change it.
The best way to do this is to use the readonly keyword, as for example:
<input type="number" name="attr_example" value="10" readonly>
<textarea name="attr_another_example" readonly></textarea>Code language: HTML, XML (xml)The readonly keyword functions exactly like disabled (with an important exception), except now the element can be altered with sheet workers. Player’s can’t click it or change it, but scripts can. This is perfect for things like, say, stat modifiers. Maybe you want players to be able to change the stat, but the modifier is always based on that stat. Simple: calculate the modfier with a sheet worker and make it readonly.
There’ll be many situations where a readonly attribute is superior to disabled. But what if you are using Autocalc fields…
Autocalc Fields
An autocalc field lets you insert a calculation, and that calculation is calculated automatically:
<input type="number" name="attr_strength" value="10">
<input type="number" name="attr_strength_mod" value="@{strength}/2 -5" disabled>Code language: HTML, XML (xml)Here we have a stat modifier being calculated as an autocalc field. I haven’t discussed autocalc fields in my web desogn guide. That’s because I think everyone should switch to sheet workers – they are a more modern method of automation, and are a lot more efficient.
But autocalc fields are very simple to use and don’t require you to learn a new programming language. So I’ll describe how to use them, the most common pitfalls, and when you must not use them.
How to Build an Autocalc
The value of an autocalc field contains the calculation, and youy can use attribute references like @{strength}. For example:
<input type="number" name="attr_toughness" value="floor(@{con}/2) + @{armor_mod}">Code language: HTML, XML (xml)Autocalc fields support standard functions like floor (to round down), ceil (to round up), and round (to round to the nearest). There are also convoluted tricks to get minimum and maximum values. There are a lot of functions at this CSS Wizardry link (even though this isn’t CSS).
A Thing About Brackets
A common problem with autocalc fields, especially when you have several autocalcs cascading in a chain, is that the output looks incorrect. (It is not, but it looks incorrect.)
Using Autocalcs and Sheet Workers
Since an autocalc field must be disabled, it cannot be affected by a sheet worker: this can be a problem, since sheet workers are designed for automation, and you might want to use autocalcs for automation.
Another problem is that sheet workers can’t use the values calclated by an autocalc field. Let’s say you have this…
<input type="number" name="attr_strength" value="10">
<input type="number" name="attr_strength_mod" value="@{strength}/2 -5" disabled>Code language: HTML, XML (xml)…and you want to use strength_mod in a sheet worker. When you try to grab the strength_mod vallue you are expecting something like +2 or -1, but instead get @{strength}/2 -5.
Sheet workers can only see the text of the calculation – not the calculation itself. Sheet workers and autocalc fields are different systems and should be regarded as completely incompatbile.
This means you cannot use them both for the same calculation. Once you start using sheet workers, you’ll start removing autocalc fields – you cannot have any calc fields “before” the sheet worker in a chained calculation. So when a sheet worker isn’t working properly, check if there is an autocalc field being used, and bypass or replace it.
Why You Should Use Sheet Workers Instead
Autocalc fields are a lot less efficient than sheet workers – an autocalc is recalculated every tme a sheet is opened or the view changes (changing a tab, maximising the sheet, etc), while sheet workers are calculated only on demand. That said, you can still have hundreds or even thousands of autocalc fields on a sheet. Still, if you have really bad lag, that’s one area to investigate.
Also, sheet workers can do more complicated calculations, and you ca’t easily combine autocalcs and sheet workers, so once you start using sheet workers, you’ll probably end up replacing any existing autocalcs with sheet workers. So you might as well get a jump on that process and use sheet workers from the start. I have a guide for that!
Conclusion
Disabled fields are used in two ways: to make an element that is normally interactive become uneditable, and to create autocalc fields. You can often replace the first one with readonly fields, but you don’t need to – sometimes a disabled element is fine.
The second, creating autocalc fields, is something you probably shouldn’t do any more. Create sheet workers instead. They are more cumbersome, but are a lot more efficent.
