Use the .shadow-inner utility to apply a subtle inset box shadow to an element. This can be useful for things like form controls or wells.
.shadow-inner
<divclass="shadow-inner"></div>
No shadow
Use .shadow-none to remove an existing box shadow from an element. This is most commonly used to remove a shadow that was applied at a smaller breakpoint.
.shadow-none
<divclass="shadow-none"></div>
Responsive
To control the shadow of an element at a specific breakpoint, add a {screen}: prefix to any existing shadow utility. For example, use md:shadow-lg to apply the shadow-lg utility at only medium screen sizes and above.
For more information about Tailwind's responsive design features, check out the Responsive Designdocumentation.
By default Tailwind provides three drop shadow utilities, one inner shadow utility, and a utility for removing existing shadows. You can change, add, or remove these by editing the shadows section of your Tailwind config.
If a default shadow is provided, it will be used for the non-suffixed .shadow utility. Any other keys will be used as suffixes, for example the key '2' will create a corresponding .shadow-2 utility.
By default, only responsive variants are generated for shadow utilities.
You can control which variants are generated for the shadow utilities by modifying the shadowsproperty in the modules section of your Tailwind config file.
For example, this config will also generate hover and focus variants:
{
// ...
modules: {
// ...
- shadows: ['responsive'],
+ shadows: ['responsive', 'hover', 'focus'],
}
}
Disabling
If you don't plan to use the shadow utilities in your project, you can disable them entirely by setting the shadows property to false in the modules section of your config file:
The text-justify property in CSS is a companion to the text-align property that is used to set the justification method of text when text-align is set to the justify value.
inter-word: Specifies that text is justified by adjusting the spacing between words, effectively creating additional word spacing. This is effectively a variation of the word-spacingproperty.
inter-character: Specifies that text is justfiied by adjusting the spacing between characters, effectively creating additional character spacing. This is effectively a variation of the letter-spacing property.
auto: Allows the browser to determine whether justification is better handled as inter-word or inter-character. This can be helpful in multi-lingual scenarios where the content language is unknown until rendered, allowing the browser user agent to choose accordingly based on which method better fits the language context.
none: Disables justification methods, effectively removing any justification opportunities, or overriding where a justification method may occur in the cascade.
Justified text is a fancy way of saying how text fills the box that contains it. In fact, you may already be well acquainted with justifying text and don't even know it. If you have ever used text editing software like Word and Google Docs, then you might be familiar with these icons:
Text align and justification options in the Google Docs toolbar
Those first three set the text alignment, just like the CSS text-alignproperty, where the text can be aligned to the left, right or completely centered.
That fourth icon is the justify option and it tells the content to fill the entire width of the document so that each line is flush right to the edge, regardless of whether it affects the spacing between words.
Justifying content in Google Docs adds spacing between words to occupy the full document width at each line
The text-justify property allows us to do the same, but with additional flexibility to determine whether the spacing method used to justify the content is managed between words or characters.
The text-justify property is included in the CSS Text Module Level 3 specification, which is currently in Editor's Draft status at the time of this writing.
This property is currently listed as "at risk" of being dropped in the Candidate Recommendation period. As such, it is not recommended to use this property in production as it is unlikely to be adopted as a standard across all browsers in the near future.
Current support is limited to Firefox 55+. Internet Explorer 11 and Edge 14+ also support the property, but only the inter-word value as well as unofficial values not included in the W3C specification.
This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.
<input type="number"> will open a numeric software keyboard on modern mobile operating systems. Not every user can input decimal numbers into this convenient field without proper localization. Half the world uses a comma and the other half uses a period as their decimal mark. (In Latin scripts.) Does your web application take that into consideration? Do the browsers?
Why <input type="number"> and what is the problem?
Touch software keyboards, or “soft keyboards”, can adapt to the input type that is requested from the user. If an email address is requested for a login, the soft keyboard can be made to include an at sign. For numeric input, the keyboard can include larger numbers like on a dialpad, a decimal mark, and a minus sign. These adaptive soft keyboards are a big convenience to users as they do not have to manually change the views of their already‐hard‐to‐use keyboard.
The problem with these soft keyboards and even with regular analog keyboards, is the decimal mark. Roughly half the world uses a comma as their decimal mark, and the other (mainly former colonies of the British Empire) uses a period instead.[1] In computing, decimal marks are usually presented in a way following the locale of system. However, the stored value in memory is always represented with a period.
Inputting an invalid value into a <input type="number"> will, as per the specification, set the value to an empty string. The value presented to the user will still be whatever they typed, but the form will not actually submit any data. This is a big usability as well as functional problem for web applications.
What does the W3C recommendation say?
The value of an <input type="number"> must always be either a valid integer (number) or a valid decimal number. The specification defines the decimal separator as a period regardless of the locale.[2] However, the value the user inputs or the value that is displayed to the user does not need to meet this technical requirement. The specification does not define how exactly this should be handled, but suggests the following:
“Browsers are encouraged to use user interfaces that present […] numbers according to the conventions of either the locale implied by the input element’s language or the user’s preferred locale. Using the page’s locale will ensure consistency with page‐provided data.” [3]
Additionally, all browsers except Internet Explorer will strip any whitespace characters and thousand separators (space, comma, or period depending on locale — see below) from the value.
Following this logic we can make a test[4] and get the following web browser support comparison chart:
Browser support
UI language refers to the user interface language of the browser or operating system as set by the user. Element language refers to the language of the form widget (<input type="number" lang="en-150">) or page (<html lang="en-150">) as set by the page author. In the table, European English represents the comma‐locales and English represent the period‐locales.
I have not made any investigation into support of Arabic or other script’s decimal marks. I would expect the results to be similar or worse.
Notes on browser support
Those familiar with the browser landscape might recognize that Google led projects — Blink/Chromium (used by Chrome, Opera, Yandex, Vivaldi, and others) and Android — have the most problems. There is an ongoing discussion that holds promises for their implementations to be fixed. Even if that discussion bears fruits in the near future, end‐users will still encounter problems on older systems that do not necessarily receive updates.
Apple’s implementation in Safari and iOS is noteworthy. Instead of relying on hints from the locale or page author, the browser allows interchangeable use of commas and periods in all locales.
Internet Explorer does not support number inputs, as defined in the HTML5 recommendation. It does support bringing up numeric software keyboard if the input element sets its type to number. This is kind of okay, as user‐provided input can be validated and corrected with JavaScript or server‐side.
Recommendation for web authors
Set the form language explicit as an attribute of the input element or the form itself. For example, <input type="number" lang="en-150"> Web pages do not always set the language on their root element. For form input, this actually matters and setting it on the form or input element will help your users complete the task of filling in numbers.
I’m almost tempted to recommend you always set the input language of all <input type="number"> to a locale that uses commas to get both period and comma support. This could cause issues in the future if browsers decide to stop supporting periods when commas are expected. As of today, however, this is not the case but could change.
The value of an <input type="number"> is always — except in Internet Explorer — set to a valid decimal number. There is no way to read the raw value the user input. When an invalid value is provided, the display value is left as the user provided it. However, the value is cleared and set to an empty string. This is the expected behavior!
Some browsers will validate the input and confusingly show a red border around the input. Thus prompting the user to correct the input. This can be somewhat unclear to the user. Using JavaScript, the input element’s valid property from ValidityState can be tested. This can be used to display a custom error message, shake animation, or otherwise prompt the user to correct the information. Another way with more reliable support is to read the input element’s input event. Process the event by checking that the input element’s value is not an empty string and is a valid decimal number (for Internet Explorer and legacy browsers), and then prompt the user to provide a valid input. Using the input event is highly encouraged over other events (like key, paste, or change) as this support clipboard, keyboard, handwriting, IME, and other forms of input. Consider using the widely supported blur event as a fallback for legacy browsers, even though it is less reliable than the input event.
It is hard to instruct the user on what input is expected as you cannot test whether the form will be localized or not! Every browser supports input with a period as the decimal separator, so this can safely be used. To reduce the chance of errors, you could consider setting the input element’s placeholder attribute to a valid floating‐point number even when this does not match the user’s locale.
Having a fallback parsing in JavaScript is recommended as older browsers do not support numeric input types. Take care to ensure that any server validation is identical to the client-side validation done by the browser (with type="number") and in JavaScript.
Recommendation to implementors (browsers)
Please support period and commas used interchangeably as the decimal mark regardless of any locale hinting. Apple has got the right idea here!
When it comes to thousand separators[5], it is simply a matter of stripping out every decimal mark symbol (whether it be a period or a comma) except the last one. The International System of Units (SI) recommends using a space to group digits to reduce format confusion. After reading this article, I hope you agree.
