Caveats

  1. Tailwind engine is processing Twig templates by parsing twig files directly and does not bootstrap anything on the backend side (Drupal in this case) hence it cannot "process" variables that are either set in Twig templates or in hook_template_preprocess_HOOK() hooks or similar code where values are generated "on the fly". Here is the example code, what's in Twig expression below for the first class in wrapper_classes[] array will not work, despite the fact that "max-w-[arbitrary_value]" is perfectly applicable by Tailwind CSS design, actually any property can be be defined as an arbitrary value. Simply, variable first_width generated this way in the Twig template is unknown to Tailwind.

    {% set first_width = items[0] and items[0].field_width ? items[0].field_width %}
    {%
      set wrapper_classes = [
        
        /* This one will not work! */
        first_width > 0 ? 'max-w-[' ~ first_width ~ 'px]' : 'max-w-fit',
        
        /* The following 3 will work as designed. */
        'flex',
        'flex-wrap',
        'space-x-4',
      ]
    %}
  2. Similar is and example with preprocess hook, Tailwind's class text-lime-600 will be there on element's title but it will not apply because Tailwind does not read from PHP files (in this case it's ph_tailwindcss.theme php file. Unless text-lime-600 it is already in use in the DOM/markup and Tailwind was able to read it and pack it in the distribution minified CSS file. Remember, one of the best features of Tailwind is - no unused rules and properties, no extra CSS lines  - it parses files per its configuration and packs only whichever classes it finds.

    /**
     * Implements hook_preprocess_HOOK().
     */
    function ph_tailwindcss_preprocess_input(&$variables) {
      if (isset($variables['element']['#title'])) {
        /* This will not work! */
        $variables['title_attributes']['class'][] = 'text-lime-600';
      }
    }

    Fun fact - it is relatively easy to "hack" the outcome. Just to register text-lime-600 and have Tailwind to have it packed in distribution file, somewhere in the Twig template in relation to this case or similar say we could put a dummy element:

    <div class="text-lime-600 hidden"> </div>

    Of course this is far from elegant and not recommended, especially because I believe that we might get some kind of mechanism to resolve these situations.

     

  3. Same is for interactivity in JavaScript, for instance when we are applying or removing some class or attribute on some element, on some event (i.e. click), such generic property - like for instance floating class like in the example below - its properties will needed to be added in the same source PCSS file, but the classic way, out of layers and directives. However that is still a solid remedy, especially for some usual suspects like CKEditor that processes and generates a lot of stuff upon page loading etc.

    switch (event.type) {
      case 'focus':
        if (label) {
          /** This class was NOT found by Tailwind while parsing templates,
           *  it is set dynamic here in JS and will need to be added as a
           *  "classic" CSS with its rules/specifics.
           */
          label.classList.add('floating');
        }
        break;
    ...