Со времён систематизации методов объекта console прошло достаточно много времени, некоторые браузеры получили поддержку недостающих ранее методов. Таблица вызывает естественный интерес у разрабочиков, поэтому — почему бы её не обновить, дополнив в одной статье описаниями?
Что-то я не догнал, а с каких пор Node.js является браузером?
Каком к верху. Вначале отчетливо видел бело-золотое. В офисе меня даж на дальтонизм проверить решили. Спустя пару часов видел уже сине-черное ( с проверкой не связано :D ).
Скажите, зачем вам лишние проверки на енвайронмент, если они только усложняют логику сборки? Не проще ли сконфигурировать для каждого свой запуск если енвайронменты отличаются?
Отпишусь пожалуй. Взял сие чудо себе домой. До этого стояли 2х 23", 1920х1080, IPS.
Из плюсов:
— картинка гораздо приятнее
— текст просто шикарен
— углы обзора норм
Из минусов:
— Винда (или дрова, или еще что), не хочет работать без помех на разрешении 3840х2160. (Если кто знает в чём трабла, помогите).
— Многие IDE используют свой рендер шрифтов (сам пишу на PhpStorm). Выглядет отвратно.
Хм. Использую один алиас для быстрого создания Пулл Реквестов (особенно если работаешь на форке). Может кому пригодиться:
При открытии гитхаба в браузере и переходе на ваш feature-branch, URL гитхаба будет выглядеть примерно так: https://github.com/{orgname}/{reponame}/tree/{featurebranch}
Если его немного видоизменить до ( tree/ на compare/{sourcebranch}...): https://github.com/{orgname}/{reponame}/compare/{sourcebranch}...{featurebranch}
То вы сразу перейдёте на страницу создания нужного вам ПР (с правильными ветками!)
Это дико удобно если ваш феатуре бранч нужно мерджить более чем на 1 ветку (у меня часто по 3 ПР на разные ветки в 5+ репозиториях. Экономит время очень заметно)
Ещё круче сделать алиас для консольной команды. Например используя: xdg-open https://github.com/${org_name}/${repo_name}/compare/${arg_source_branch}...${current_feature_branch}
UDP:
ПР между форками выглядит примерно так: https://github.com/${org_name}/${repo_name}/compare/${arg_source_repo_name}:${arg_source_branch}...${current_repo_name}:${current_feature_branch}
Во-первых, как уже ранее говорил, банально — чтобы изменить цвет уже существующего элемента нужно найти элемент, который нужно поправить, затем найти ту переменную, к которой уже присвоен сам цвет. И таких переменных может быть десяток, и они могут быть все в разных, отдельно подключаемых файлах, число которых, как вы понимаете, также может исчисляться десятками.
Во-вторых, аргумент сторонников о том, что удобно: «Изменил в одном месте — поправил все кнопки!» — это для людей, которые не знают или забыли, что такое пакетный реплэйс! Проще, быстрее и надежней найти сразу цвет #ccc и сделать «Replace All».
Еще есть мнимое «удобство» less в том, что легко поменять цвет путем сложения или вычитания прямо в коде, но это опять же в кавычках — поскольку если у человека под рукой графический редактор + если он давно занимается версткой и знает наизусть основные коды цветов — ему не нужно ничего прибавлять или убавлять — он сразу прописывает код.
— Уж сколько раз твердили миру: используйте IDE, а не текстовые редакторы! Они умеют многое, например при помощи клика мышки на используемую функцию из миксина — переходить к её дефиниции в сам миксин.
— Кончено, удобней. Лучше сразу поиск и реплейс по всему проекту, особенно если цвет #ccc.
— Что-то из разряда: «Вааась, какого цета у нас небо было? — Зелёного! — Да блин, ты мне нормально, в хексе скажи!». Ни разу не видил человека, что бы взглянув на цвет он выдавал бы его точный хекс код…
З.Ы. а ещё можно копипастить ЦСС общих элементов для каждой страницы отдельно!
Дело не в «стандартных» или «нестандартных». Вместо объяснений приложу скриншоты пожалуй)
SemanticUI: Свое оформление, чисто, гладко и красиво. Гуд
Fondation: Минимум новшеств, но все выглядит опрятно и симпатично. Гуд
UiKit: Справа обрезан бордер у выпадающих элементов, в том же месте нет закруглений (как буд-то борер уходит «под» элемент). Да и шрифт для цифр не подходит совсем. В целом, выглядит очень неопрятно.
«Это CMS, а мы помним, что за созданием Snow Fall не стоит никакой CMS»
Не соглашусь. В чем проблема создать шаблон для сноуфалл?
Бэк-енд? Отдельный шаблон? Дополнительный JS? Большая форма для енд-юзера?
Ну вот не вижу я проблем, добавить такой шаблон, который можно настраивать по любому «хочу». А выражение "
Причины, по которым эти snowfalling служат плохим примером веб дизайна ..." это чисто — субъективное мнение.
Что-то я не догнал, а с каких пор Node.js является браузером?
Скажите, зачем вам лишние проверки на енвайронмент, если они только усложняют логику сборки? Не проще ли сконфигурировать для каждого свой запуск если енвайронменты отличаются?
Из плюсов:
— картинка гораздо приятнее
— текст просто шикарен
— углы обзора норм
Из минусов:
— Винда (или дрова, или еще что), не хочет работать без помех на разрешении 3840х2160. (Если кто знает в чём трабла, помогите).
— Многие IDE используют свой рендер шрифтов (сам пишу на PhpStorm). Выглядет отвратно.
А так в целом неплохо. Возможно перейду если добавят нормальные дев тулзы.
При открытии гитхаба в браузере и переходе на ваш feature-branch, URL гитхаба будет выглядеть примерно так:
https://github.com/{orgname}/{reponame}/tree/{featurebranch}Если его немного видоизменить до ( tree/ на compare/{sourcebranch}...):
https://github.com/{orgname}/{reponame}/compare/{sourcebranch}...{featurebranch}То вы сразу перейдёте на страницу создания нужного вам ПР (с правильными ветками!)
Это дико удобно если ваш феатуре бранч нужно мерджить более чем на 1 ветку (у меня часто по 3 ПР на разные ветки в 5+ репозиториях. Экономит время очень заметно)
Ещё круче сделать алиас для консольной команды. Например используя:
xdg-open https://github.com/${org_name}/${repo_name}/compare/${arg_source_branch}...${current_feature_branch}UDP:
ПР между форками выглядит примерно так:
https://github.com/${org_name}/${repo_name}/compare/${arg_source_repo_name}:${arg_source_branch}...${current_repo_name}:${current_feature_branch}— Уж сколько раз твердили миру: используйте IDE, а не текстовые редакторы! Они умеют многое, например при помощи клика мышки на используемую функцию из миксина — переходить к её дефиниции в сам миксин.
— Кончено, удобней. Лучше сразу поиск и реплейс по всему проекту, особенно если цвет #ccc.
— Что-то из разряда: «Вааась, какого цета у нас небо было? — Зелёного! — Да блин, ты мне нормально, в хексе скажи!». Ни разу не видил человека, что бы взглянув на цвет он выдавал бы его точный хекс код…
З.Ы. а ещё можно копипастить ЦСС общих элементов для каждой страницы отдельно!
SemanticUI:
Свое оформление, чисто, гладко и красиво. Гуд
Fondation:
Минимум новшеств, но все выглядит опрятно и симпатично. Гуд
UiKit:
Справа обрезан бордер у выпадающих элементов, в том же месте нет закруглений (как буд-то борер уходит «под» элемент). Да и шрифт для цифр не подходит совсем. В целом, выглядит очень неопрятно.
Не соглашусь. В чем проблема создать шаблон для сноуфалл?
Бэк-енд? Отдельный шаблон? Дополнительный JS? Большая форма для енд-юзера?
Ну вот не вижу я проблем, добавить такой шаблон, который можно настраивать по любому «хочу». А выражение "
Причины, по которым эти snowfalling служат плохим примером веб дизайна ..." это чисто — субъективное мнение.