Чи завжди добре включати вбудований CSS у плагіни?

Зазвичай у плагін я б додав стилі за допомогою wp_enqueue_style. Однак наразі я створюю плагін, якому потрібно лише кілька рядків CSS, і мені цікаво, чи може бути краще обслуговувати стилі, вкладені для збереження запиту. Очевидно, що у використанні wp_enqueue_style є багато переваг, але чи варто цього додаткового запиту на такий невеликий фрагмент CSS? Чи є якась прийнята "найкраща практика" в цій галузі?

— Дастін
джерело

TL; DR; Enqueue

Використання зовнішньої таблиці стилів

PRO: Усі ваші стилі в одному місці.
PRO: Зменшує кодування веб-сторінок.
PRO: простіше підтримувати плагін.
PRO: Можна використовувати гачки, щоб змінити розташування файлу.
PRO: Можна використовувати гачки для видалення файлу.
PRO: Можна використовувати стилі мінімізації автоматично.
CON: Можна додати додатковий запит HTTP (його можна подолати).

Використання вбудованих стилів

PRO: Можна безпосередньо побачити застосований стиль.
PRO: Немає зайвих HTTP-запитів.
КОН: Не можна використовувати гачки для зміни стилів.
КОН: Не можна використовувати гачки для скасування стилів.
КОН: Неможливо взагалі мінімізувати стилі.
КОН: Потрібно ! Важливо змінити стиль

Як правило, я б сказав: звичайно, якщо ви єдиний, хто користується ним, продовжуйте це і виконайте це в рядку. Але ви говорите про плагін, що означає, що код буде загальнодоступним, тому прагнете до розширення. Зараз у вас є лише кілька ліній стилю:

КОН: Що робити, якщо тих небагато стає більше?
CON: Що робити, якщо хтось розширить ваш плагін?
КОН: Що робити, якщо хтось хоче це змінити?
CON: Що робити, якщо хтось шукає його у файлах css?
CON: Що робити, якщо хтось хоче його автоматично мінімізувати?

Тому завойовуйте. (Переважно умовно, лише якщо плагін потрібен.) Це ж стосується JavaScript . (Але це має бути включено у колонтитул, якщо це можливо.)

— Дерк-Ян
джерело

Чи добре використовувати вбудовані стилі на бекенді?

— ши

@bungeshea Якщо хтось збирається змінити ваш плагін, він, можливо, захоче змінити бекенд занадто правильно;) Просто переконайтеся, що ви запускаєте сценарій лише тоді, коли ви знаходитесь у бекенді. Наприклад: function _your_enqueue( $hook )можна перевірити $ hook, щоб побачити, чи є на вашій сторінці параметрів. Крім того, ви можете використовувати current_screen()для більш простих властивостей. Річ у тім, що ви дозволяєте це робити, але загальне використання - це плагін, що складається з .php-файлу для коду сервера і може мати або не мати файлів зображень, .js та .css.

— Дерк-

Ви зазначаєте, що додатковий запит http можна подолати - чи можете ви це уточнити?

— Дастін

Ви не можете, але користувач плагіна може. Існує кілька плагінів і функцій, записаних до, безпосередньо перед виведенням сторінки, отримайте ВСІ докладені стилі та додайте їх до мінімізованого комбінованого файлу. Незалежно від того, скільки файлів CSS ви додали, глядач побачить лише один. Те саме для javascript. Однак це у вашому випадку не ваша «проблема». Це оптимізація, яка не потрібна. Іноді додатковий запит HTTP не відповідає всім PRO.

— Дерк-

Про останнє речення - стилі AFAIK повинні виводитись у верхній колонтитул, а не у колонтитул

— Марк Каплун

На це важко відповісти, і я дійсно не впевнений, чи є офіційна відповідь.

Я розумію настрої щодо збереження запиту, але стиль вбудованої форми майже завжди виграє. Тема або кінцевий користувач буде важко змінювати ваш CSS.

Зважаючи на це, я думаю, що я зробив би це у відкритому плагіні ...

якщо CSS абсолютно критичний для функціонування плагіна, як це стосується, наприклад, слайд-шоу.
Або, якщо я також включив у плагін фільтр, який дозволяє змінювати або видаляти вбудований CSS.

— s_ha_dum
джерело