• Программирование деформирует человека как личность?

    milssky
    @milssky
    Координатор племени фиолетовых обезьянок
    Выгорание в чистом виде.
    1. Сходить к психологу.
    2. Решить остальные проблемы со здоровьем.
    3. Оставлять работу на работе.
    Ответ написан
    Комментировать
  • Программирование деформирует человека как личность?

    glaphire
    @glaphire
    PHP developer
    У Вас был существенный дисбаланс в жизни (ничего помимо работы), я не согласна с теми, кто говорит что "разработка это не Ваше", скорее нужно пересмотреть приоритеты в жизни. Психолог может помочь, если Вы действительно созрели копаться в себе. Люди не выгорают, когда все их внутренние потребности закрыты, кому-то это закрывает кодинг, а кому-то спорт, путешествия, семья... Но это не значит, что нужно бросать разработку, просто подобрать работу покомфортнее) Говорю частично из своего опыта
    Ответ написан
    1 комментарий
  • Фронтенд это настоящее программирование?

    @dimoff66
    Кратко о себе: Я есть
    Вы поймите откуда это идет: у людей с комплексом неполноценности есть потребность самоутверждаться.

    Если человек с комплексом неполноценности пишет на с++, он заявляет - только с++ это трушно, всякие питоны это дерьмо.

    Если человек с комплексом неполноценности пишет на питоне или ноде, он заявляет - бэкенд настоящие программисты, фронтенд дерьмо. Хотя чего там сложного на бэке? Получил запрос, сделал запрос к базе, отдал результат. Чем лучше спроектирована база - тем меньше манипуляций.

    Но человеку, пишущему на фронте тоже ведь надо самоутверждаться? Для него Бог придумал программистов 1С. То что они пишут на русском языке делает их нетрушными.

    Программистам 1С самоутверждаться не перед кем, поэтому они гнобят бухгалтеров.

    Весь мир сплошное самоутверждение, особенно в программировании, так как от постоянного интеллектуального напряжения засираются мозги. Выход - делать что тебе нравится и не попадаться в ловушку слов.
    Ответ написан
    2 комментария
  • Фронтенд это настоящее программирование?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Наши фронты регулярно юморят на эту тему. На каждом планировании спринта крики "Я же не настоящий программист, зачем вы на меня такие сложные задачи назначаете?!"
    Ответ написан
    Комментировать
  • Фронтенд это настоящее программирование?

    mrusklon
    @mrusklon
    Не получается? Яростно гугли!
    а вам нужно любимым делом заниматься или думать насколько это круто?
    Ответ написан
    11 комментариев
  • Как сегодня писать сайты?

    Epsiloncool
    @Epsiloncool
    Программер, веб-девелопер, гейм-девелопер
    Нормальный вопрос, вспомните себя в молодости: какие были наполеоновские планы по захвату мира? У каждого такие были (а у некоторых даже ещё есть). Но я не буду писать что-то на тему "автор школьник, гыыы", а возьму и отвечу. Потому что я в теме с 2001 года и, кажется, понимаю о чём вопрос.

    Подавляющему количеству бизнесов сегодня не нужен сайт. Инста и фейсбук отлично продают физические товары и услуги. Более половины предпринимателей, тех, которым я лет 5-6 назад делал сайт, сейчас успешно продаются в VK, инсте или FB и ничего не хотят слышать про "свой собственный сайт".

    Большинство из оставшихся не нуждаются в сложных многостраничных сайтах. На самом деле, есть статистика, что простые одностраничные сайты продают в 2-5-10 раз лучше, чем многостраничники. Пользователю просто некуда уходить - там есть самая главная информация о продукте и кнопка "заказать". Он прочитал и заказал. Если пользователь начинает бродить по сайту, он устаёт, его мозг "забивается" и он решает отложить покупку "на потом". Этих предпринимателей успешно закрывают Викс, ЛПгенератор, Тильда и прочие многочисленные "кон стру кторы сайтов". Сделать "сайт" на этих платформах сможет даже школьник (и они делают). Это работа точно не для профессиональной студии разработки сайтов.

    Что делать, если людям нужно продавать больше, чем один товар? Ещё одна требовательная категория - это потенциальные владельцы интернет-магазинов. Раньше был мощный пласт разработки - это как раз таки разработка интернет-магазина. И этот пласт, как вы, наверное, догадались, почти закрыт сервисами.

    И вот сюда, в принципе, вы можете пойти. Ещё не все потребности закрыты. Можно делать модули для OpenCart, допиливать магазы на Woocommerce, есть такой удобный SaaS-сервис Shopify, который тоже имеет API и поддерживает сторонние модули - есть где порезвиться.
    Но опять-таки это не разработка с нуля.

    Многие студии концентрируются на разработке уникального дизайна сайта. Тема интересная и в своё время была довольно прибыльной. Но сегодня в интернетах куча готовых шаблонов, из которых 98% бизнесов выбирают себе дизайн и немножко поднастроив, получают уникальный сайт. Вы можете попробовать зайти сюда, но придётся довольно долго искать хорошего клиента.

    А вот куда можно реально пойти - это разработка больших программных продуктов. Таких заказов мало, куда меньше, чем владельцев микро-бизнесов. Это разработка SaaS, главным образом. Разработка маркетплейсов, сервисов и всё такое прочее, что ещё долго не будет закрыто конструкторами. И вы можете использовать для этого симфони, даже WP и CodeIgniter. Если есть мощь и знание - можете попробовать использовать Nodejs или даже Go.
    Опять-таки скажу ещё раз, что в этой теме не очень много заказов, но все они стоящие. И часто приходится делать не на том, на чём вы привыкли, а на том, что требует сам сервис. Обычно это включает в себя много разных технологий - морда на React, Vue, Angular, основной бэкенд на Nodejs или Go (никаких CMS!), как правило, сразу заказывают и мобильное приложение - так что будьте готовы делать. На первых порах можете проехать на PhoneGap, но часто это решение не годится, заказчики пошли умные, умеют гуглить.

    В общем, вперёд. И самое главное, что я хотел бы сказать - если вы будете рассчитывать на много простых заказов, то не преуспеете, с большой вероятностью. Потому что простые заказы умеет делать каждый школьник, а у него больше свободного времени и не надо платить зарплату подрядчикам, так что он вас победит.
    Нужно идти туда, где школьники не справляются в одиночку - там, где нужно много современных технологий одновременно. Вот где золотая жила для IT компаний.

    Удачи!
    Ответ написан
    2 комментария
  • Объясните что такое полиморфизм простыми словами ?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Да ладно, парни. Ну хватит уже, к чему такие сложности? Берём и читаем. Вообще совсем не обязательно читать про архитектуру и абстракции именно по своему языку, хотя javascript в этом плане родился уродом.

    Ок. Полиморфизм ни в коем случае нельзя рассматривать отдельно от других фундаментальных понятий - абстракция, инкапсуляция и наследование. Объект и подобные прилагаются из аксиом (хотя это-то тоже аксиомы).

    Собственно, представим себе рядом стакан, кружку, чайник, кофемашину, велосипед и скейт. Что между ними всеми общего? Ну как минимум то, что они есть. То есть это - объекты, которые были созданы. Но как они были созданы? Скорее всего на заводе производителя по чертежам. Ок, чертежём назовём конструктор. Ну а класс? А что это такое? А его нет в нашей вселенной - эта сущность есть абстракция, что живёт лишь в наших мыслях. В реальном мире её нет и никогда не будет, такова уж физика - ей по барабану, что птицы и млекопитающие имеют дальних родственников - она лишь обеспечивает возможность естесственного отбора. А уж родственников друг другу находим мы, люди.

    С объектами и классами разобрались, а что же там с нашими стаканами и велосипедами. Мы уже поняли, что всё это объект, то есть грубо можно все объекты наследовать от какого-нибудь суперпредка, суперкласса, что и реализовано в некоторых языках. Но что другого общего между скейтом и стаканом, например? Конечно, можно углубляться и считать, что они все из молекул, и они все из твёрдых веществ. Однако это всё бред и СПГС, так что ответ прост - да ничего. То есть это совершенно разные объекты с совершенно разным функционалом. Более того - естесственно компьютерные модели и иерархии будут сильно отличатся от физик и химий. И это нормально, вопрос об адекватностях моделей ставиться лишь когда модель неадекватна, а до тех пор пилить можно что угодно, лишь бы работало.

    Вот. У нас есть супер-предок Object, от которого дефолтно наследуются все объекты. Допустим, то что объекты состоят из атомов и есть то, что наследуют все объекты. Но все дополнения и правки - полиморфизм. Так, из атомов мы слепили колёса и приделали на доску - ок, это скейт. На него можно встать и катиться, а сильно извернувшись и полетать в трёх метрах над землёй, прямо таки излучая своё яркое эго. В то время как стакан - это мы слепили из атомов плотную ёмкость, из которой вода не выливается под действием силы тяжести. И прямое применение стакана - налив воды опрокинуть его над ртом, чтобы вода вытекла прямо в желудок. Так делают настоящие пацаны, не заботясь об икоте или страхе утонуть, так что вот - полиморфизм.

    Однако что с остальным? У нас ещё абстракция, инкапсуляция и наследование. Ок, начнём с наследования, так оно наиболее близко. Вот что у нас общего между стаканом и кружкой? Ну в оба можно налить воду, но у кружки есть ручка чтобы держаться. То есть можно придумать некий общий класс - ёмкость. Однако что это за класс? Можно например за этот класс взять стакан, тогда все ёмкости по дефолту стаканы, а всё остальное - видоизменённые стаканы. Но кому-то больше нравяться кувшины, например некоторые чики насят их на голове, считая что это удобно. Ну и пусть носят, но как-то же решить надо, что главнее и идеальнее. Так вот - недостяжимый идеал и есть главный - это называется абстрактный класс. То есть ёмкость, что невозможно создать, для которого нет полного чертежа. А все чертежи, что дополнили до полного - есть наследованные классы от класса ёмкость.

    Тут мы подошли к абстракции. Вот такое иерархическое наследование приводит нас к, возможно главной, идее ООП. Вот мы взяли и выделили всё, куда можно налить воду в отдельный класс, нарисовали общий чертёж, но специально не доделали его, оставив зазор для будущих творцов, и назвали чертёж - ёмкость. Тысячи лет изобретатили всех миров создают свои ёмкости, одна лучше другой. Для разных людей - по разному, конечно. Но каждый раз группировать молекулы стекла определённым образом - непростая задача. Поэтому ремесленники пошли на хитрость, они создали тайный совет ремесленников мира и решили делиться друг с другом своими наработками. То есть создавать мелкие чертежи и объявлять классом, например, извлистой ручки в форме ленты Мёбиуса, например. Возможно такая ручка удобно только инопланетным существам, но чертёж создан и к нему можно ссылаться при создании своего чертежа. Таким образом мы абстрагируемся от низкоуровневой задачи "формирования ёмкостей посредством перемещения молекул" к "конструированию ёмкости посредством совмещения деталей, элементов". Это и есть абстракция.

    Но мы подошли к последнему пункту - инкапсуляция. Она неразрывна с абстракцией, и по сути благодаря ей она и работает. Инкапсуляция - это своеборазный клей (или синяя изолента), которым склеивают разные чертежи в один. То есть совмещение деталей для создания своей - это и есть инкапсуляция. Причём при совмещении мы можем не описывать детали этого совмещения (то есть члены класса могут быть приватными), таким образом помогая абстрагироваться тем, кто этот чертёж использует. Вот посмотрим на чайник - что это такое? Это стакан (или кружка) к которому снизу (а может внутри по середине?) приклеен нагревательный элемент. Пустив по нему ток, согласно инкапсулированному в нагревательный элемент закону Ома, будет выделяться тепло и нагреваться вода. А кофемашина? Это куда более сложное устройство, с множеством насосов, ёмкостей, шлюзов, измельчителей и чайников. И всё склееное клеем. А может синей изолентой. Это снова инкапсуляция.

    Таким образом, абстракция невозможна без инкапсуляции и наследовании, как невозможен полиморфизм без, собственно, наследования. Ну а полиморфизм невозможен ещё и без инкапсуляции, которая банально бесполезна без наследования и полиморфизма. Вот такие тут треугольники с пирогами. Жаль только про пирог наврали. И про день рожденье.
    Ответ написан
    3 комментария
  • HTML + CSS - законченный сайт?

    approximate_solution
    @approximate_solution
    JS Developer. Angular\React\Vue\Ember
    большой портал с информацией (в плане множество статей)

    Вот тут вы и устанете, без использования шаблонизаторов, вручную постоянно копируя участки кода.
    Вопрос такой можно ли оставить статичный сайт (не вникать в js, php и тд) и залить его?

    2020 год, масса инструментария можно решить задачу автоматизации вашего сайта, самая простая cms + админка решит ваши проблемы. Они простые, на ознакомление и посадку у вас уйдет не больше 2-4 дней, а позже съэкономит вагон времени.
    К тому же портал с статьями должен регулироваться хотя бы минимальной логикой - поиск статьи, фильтр статьи, тэги. Иначе у вас будет не проект, а огрызок из 2007 года.
    Ответ написан
    Комментировать
  • Почему программисты идут работать в Яндекс?

    @PurplePowder
    Немного про меня: работаю в Яндексе уже 6.5 лет, большую часть из которых проработал в браузере, а сейчас работаю в облаке. Приходил джуном-мидлом, сейчас работаю ведущим разработчиком. Также я один из интервьюеров, кто проводит эти самые алгоритмические секции (каунтер секций перевалил за 250 за пару лет).
    Так вот, если по пунктам, то:

    1) Один из этапов собеседования всегда связан с алгоритмами (даже несмотря на то, что в работе они использоваться не будут).


    Это не совсем верно. На этой секции проверяют не столько зубодробительные алгоритмы, сколько навык написания кода. Да, над задачами нужно будет подумать и применить сортировку/хэшмап/что-то еще, но основной сигнал как раз в том, как человек пишет код. Думает ли он наперед, какие баги сажает, в состоянии ли написать цикл без off by one, если посадил баг, то как будет чинить (проверит по кейсам или попросит кейс? если дать кейс, то найдет ли проблему сам?) - эти навыки как раз дает опыт. На мой взгляд тут нет никакого rocket science

    2) Как правило, собеседование состоит минимум из трех этапов.


    Выше уже ответили, но я уточню - минимум из трех секций с написанием кода. Важно то, что разные интервьюеры не видят других оценок, пока не поставят свою. Это "усредняет" результат - в итоговом фидбеке меньше влияния конкретного интервьюера и конкретных задач. Но помимо этих секций еще может быть секция по архитектуре или еще какая-нибудь специфичная для проекта секция (кому-то важно знание C++, а где-то - отладка с осциллографом)

    3) Требования выше, чем в среднем требуется для рассматриваемой позиции (особенно это касается джуниоров).


    Define "в среднем"? Если говорить по-честному, то грейды в разных компаниях очень сильно разнятся. Человек может быть старшим в компании Х, но при этом отсобеседоваться на уровне младшего разработчика. С другой стороны я видел как люди уходили на должность старшего разработчика после стажировки в Яндексе. Важно, что я говорю именно про то, что везде оценивают людей по-разному

    4) Заработная плата ниже, чем в среднем по рынку.

    Опять же смотря что брать за среднее. Я не жалуюсь :) Но если серьезно, то у нас в стране еще пока не научились воспринимать бонусы типа акций компании как зарплату и считают чем-то ненастоящим. Хотя если их учесть, то получается иной расклад.
    Впрочем еще бывают случаи, когда людям переплачивают на текущем месте. То есть человек дорос до старшего/ведущего/CTO в текущей конторе и у него была какая-то определенная компенсация, но мы его оцениваем на мидла по навыкам и предлагам компенсацию ниже. Что поделать, так тоже бывает.

    Поэтому я не могу понять: что именно с точки зрения специалиста может получить программист, который пойдет к ним работать? Особенно опытный.

    Если ставить вопрос в таком несколько прагматичном ключе, то:
    - Масштаб. Когда DAU исчисляется миллионами, то это вносит очень много нюансов в том числе в разработку. Не так много мест (особенно в России), где можно получить такой опыт
    - Если после предыдущего пункта сразу подумалось "а чего бы тогда не сразу в FAANG?", то в Яндексе интересных и важных задач все еще больше, чем рук, которые способны их решить. То есть большой простор для роста влияния на проект и не только
    - На мой взгляд рост не ограничен примерно ничем. Если человек готов к дополнительной ответственности и способен ее вывезти, то все будет только рады дать ее ему

    Добавлю еще менее прагматичного от себя:
    - Люди и атмосфера. Работать действительно очень комфортно. Правда трудно объяснить детально в чем это выражается, да и это субъективное ощущение
    - Всегда можно учиться чему-то новому. Во-первых можно переходить между проектами, даже если делаешь довольно серьезный шаг в сторону от текущих навыков (до перехода в облако я не знал ничего про распределенные системы/сеть, сейчас знаю). А во-вторых можно поделать что-то помимо своих основных задач (например, я делаю доклады, пишу статьи, собеседую людей, помогаю студентам)
    Ответ написан
    Комментировать
  • Лучший ресурс(ресурсы) для изучения React.js для новичков?

    Hecc
    @Hecc
    Frontend. Дизайн. Шрифт.
    Если не шарите в вебе, начните не с реакта, а более основных технологий, которые там используются.
    В первую очередь, это нативный JS + HTML\CSS.

    Ресурсы:
    HTML\CSS:
    HTML Academy
    JS:
    Learn Javascript
    MDN
    You don't know JS
    EggHead : JS

    И вот пройдя вот это все, переходить уже к реакту:
    Офф. дока
    EggHead: React
    Ответ написан
    Комментировать
  • Как найти работу начинающему верстальщику?

    ArsenyMatytsyn
    @ArsenyMatytsyn Куратор тега CSS
    Руководитель frontend направления, предприниматель
    На сегодняшний день верстальщик это стек минимум из 3х языков, включая JS. Нет понимания JS, нет нормальной рабочей верстки. Даже если тебе попадаются проекты без JS (покажите мне такие), то отсутствие знания не освобождает от ответственности.

    Поэтому, чтобы называться начинающим верстальщиком, тебе нужен как минимум базовый JS. Без него ты никому не нужен, даже гавностудиям. Его ты можешь получить на курсах и в свободном доступе. Да хотя бы тут. Материал годный, рекомендую.

    Ну и напоследок, фронтендер = верстальщик, просто у нас в русском языке есть такой самостоятельный термин.

    Так что я рекомендую закрыть этот минус и идти договариваться подмастерьем (джуном).
    Ответ написан
    Комментировать
  • Как закреплять теорию javascript на практике без знания английского языка?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Ну типа ок создаю массив, объект, объект в массиве, заменяю, удаляю, передвигаю, делаю реверс функцию, создаю и вызываю коллбеки, и.......для чего все это?)))
    В книгах из практики максимум сделать морской бой и все.

    Для практики на js есть море ПОЛЕЗНЫХ! задач:
    1. Видеоплеер с автораспознаванием голоса в титры и с автопереводом.
    2. Аудио-микшер с автосведением треков и эффектами.
    3. Генератор блок-схем из кода
    4. Корректор орфографических ошибок
    5. Визуальный редактор html-шаблона с авто-генерацией исходного кода.
    6. Распознавание похожих объектов, нарисованных от руки в канвасе с представленными эталонами (для свободного рисования диаграмм и схем).
    7. Библиотека поддержки свободного размещения и авто-компоновки произвольных веб-элементов с любой формой (а не только прямоугольных, как при стандартной вёрстке) с расчётом контура касания и т.д.
    Ответ написан
    Комментировать
  • Как закреплять теорию javascript на практике без знания английского языка?

    @McBernar
    Согласен. Как бы, возможно, глупо вопрос не звучал, но большинство туториалов построены на синтетических примерах.

    Тут знаете какое дело. Все эти массивы, циклы, классы и функции сами по себе бесполезны. Но вспомните обучение русскому языку в школе — сначала человек знакомится с буквами. Потом начинаются слоги. Потом слова. Потом предложения. И только уже после можно начинать писать диктанты и даже пробовать себя в сочинениях. Вы не напишете диктант, не умея собирать буквы в слова. Хотя сам по себе навык писать букву «а» не нужен.

    Вот так и с js. На этих базовых конструкциях вы потом сможете собирать полноценные алгоритмы. Превращать буквы в слова. Ну а слова-алгоритмы в предложения-программы.

    Могу вам посоветовать одно — придумать себе задачу и начать ее реализовывать. Начните с простого — todo-приложение, куда можно заносить задачи, помечать их выполненными, изменять и удалять.

    Сразу столкнетесь с кучей вопросов. Как связать dom и js. Как хранить данные. Как создавать новый объект тудушки. Какую структуру данных использовать для тудушек, как их изменять и удалять. Вот и начнете применять свои знания о классах и массивах на практике.

    Ну а если не получится — всегда можно пойти в ютуб и вбить в поиск “todo приложение js”.
    Ответ написан
    Комментировать
  • Что надо знать юристу в IT?

    CityCat4
    @CityCat4
    //COPY01 EXEC PGM=IEBGENER
    Пробуйте, кто же мешает-то? А чтобы понять чем придется заниматься - ну попробуйте отвечать на вопросы тега "Юриспруденция в ИТ".

    Что может понадобиться:
    Авторское право
    Доменные споры
    Все, что касается вирусов и вмешательства в работу компьютерных систем
    Закон Яровой
    Закон о суверенном Рунете
    ПДн
    Все что относится к Роскомнадзору, законности и незаконности блокировок
    Все что относится к VPN, Tor, I2P
    Торренты

    В тырнете можно найти множество практики по делам такого вида.
    Ответ написан
    2 комментария
  • Нормально ли иметь много React компонентов в небольшом проекте?

    neuotq
    @neuotq
    Прокрастинация
    Сразу отмечу что Юрий Бура отличный профессионал своего дела, курс его не изучал, но беглый взгляд показал что поход у него хороший, системный и он старается все же доносить суть. Главная целье его курса научиться пользоваться реактом, понять суть современного подхода к фроентенду в целом.
    Далее уже по существу. Нужно погрузится в саму историю и причны появления Реакта. Инженеры в facebook в одно время сильно замучались строить интерфейсы, генерировать всё эту ерунду было сложно, еще проблемы уязвимостей (куча форм, для комментарией, постов, картинко и тп), недобный и громозкий PHP код заставил их задуматься об упрощении. Хотелось писать интерфейс как обычну функцию с параметрами, поэтому они придумали xhp, которые позволил буквально писать формы сразу в php (hack), легко, наглядно. Быстро видно что происходит, меньше ошибок, и легко использовать код формы (вместе с всей ее логикой построения, это и генерация формы на основе данных, и тп) заного много раз. Этот же подход был очень удобен и для других частей интерфейса, меня, списка постов и тп.
    И это, с развитием новых концепций, браузеров, технологий и требований к быстроте интерфейса вдохновила их перенести этот концепт на JS, так родился React. Его революционность была в том, что на выходе резко упростились любые манипуляция с интерфейсом на фронтенде, сильно упал порог входа, получили легко читаемый и понятный код для решения практических задач (понятно, что при желании можно и тут засрать, но до этого в принципе большенство интерфейсов на js писалось через большие муки, с кучей неудобного кода, компромисами и тд и тп, а теперь все это взял на себя реакт).
    Что мы имеем:
    есть какая-либо часть интерфейса, логически независимая от других, с определенной структурой внутри - делаем компонент. Компонент это не только то, что мы обязательно будем использовать повторно (например), но понятная логически обособленная часть интерфейса, у которой может быть своя логика внутри, и своя функция на сайте снаружи.
    Ничего страшного если сразу всё не продумал или на определенном этапе что-то идёт не идеально и тп.
    Конечно хорошо иметь план на проект и проектировать многие вещи сразу, но рефакторинг, пивоты, изменения - вот реальность жизни.
    Так что не волнуйся, первое что сделай измени восприятие самого интерфейса и приложения в целом. Теперь ты делаешь не сайт на html, а приложение с интерфейсом. Вот когда в таком ключе смотреть, то намного легче.
    Ответ написан
    Комментировать
  • Как сверстать ссылку с текстом по центру?

    Aetae
    @Aetae
    Тлен
    В нормальном браузере можно просто сделать так:
    a {
      display: inline-flex;
      flex-wrap: wrap;
      justify-content: center;
      align-items: center;
      text-align: center;
    }

    А вот если нужна поддержка ослика 11, то придётся грязно костылять(чем я сейчас заниматься, конечно, не буду:)).
    Ответ написан
  • Как сверстать ссылку с текстом по центру?

    SeaInside
    @SeaInside
    15 лет пилю все эти штуки
    Вот и появилось поколение людей, которые из ссылок будут делать гриды...
    Ваша задача не решается при таких вводных никак.

    Мы можем выровнять текстовый контент внутри по центру (1), но при переполнении он и останется по центру (2).

    Если есть возможность добавить внутрь вложенный элемент, то задача решается (3 и 4).



    ---

    Когда-нибудь это будет решаться так:
    .flex {
      align-items: safe center;
    }

    Но эта штука уже два года в черновиках и движений в эту сторону нет особо.
    Ответ написан
    3 комментария
  • Удаленщики развиваются медленнее?

    Adamos
    @Adamos
    Развитие специалиста определяется решаемыми им задачами, а не местонахождением опоры под его задницей.
    Ответ написан
    10 комментариев