Все верно пишете. Очень важна плавность и последовательность материалов. Причём последовательность даже важнее. Если мы даём на первом курсе базовые конструкции языка, то и закрепляем эти конструкции решением типовых задач, в которых эти же конструкции используются. Да, код студента на первом курсе будет не идеальным, не будет полностью соответствовать подходам, которые используют мидлы и сеньоры, пишущие на последней версии языка. Но ведь это всего лишь промежуточный результат. А нам (и вам, если вы нанимаете) важен конечный результат, который достигается после прохождения всех курсов. И там уже ученик знает, что такое ООП, использует продвинутые возможности языка и инструменты.
А что касается учебника, то да, все материалы не идеальны, все материалы могут постепенно устаревать. Но эти вещи некритичны для итогового результата. Наша задача — выпустить толкового джуна, который сможет дальше профессионально расти. И если у него будут какие-то пробелы в глубоких вопросах безопасности, это нормально, на то он и джун. Просто здесь эти некритичные проблемы почему-то чрезмерно раздуты.
Вы знаете, я не автор курса по пхп, а тут выражаю своё личное мнение. Имею я право на личное отношение к какому-то человеку?
Что касается сообщения выше, оно исключительно для автора поста. Дело в том, что все его предложения методически несостоятельны, а мы себе такие вещи позволить не можем. А тон и стиль его общения не позволяет вести продуктивную дискуссию. При этом видно, что в техническом плане уровень автора достаточно высок.
Что касается вашего вопроса про "а зачем забивать студенту голову тонкостями мегабезопасного составления строчек для баз данных на курсе начального уровня". То собственно, в чём проблема. Наша задача подготовить для рынка джунов, которые будут писать вменяемый код. В конечном счёте, после прохождения всех курсов, они будут писать код с использованием фреймворков и библиотек, то есть проблем с безопасностью их кода не будет. И при этом у них будет достаточное понимание и база, чтобы углубляться в профессиональном мастерстве в нужном им направлении, хоть в вопросе безопасности, хоть в вопросе производительности и так далее.
Проблема с джунами ведь какая? Чтобы трудоустроиться они должны давать какой-то результат бизнесу, то есть уметь достаточно быстро решать определённый класс задач с использованием определённого набора инструментов. И никакой бизнес не будет требовать от джуна глубоких познаний в безопасности. Так чем наш подход по подготовке прикладных специалистов плох?
С версиями тоже есть определённые тонкости. То, что даётся в учебнике в стартовом курсе, это настолько базовые вещи, что они от версии к версии почти и не меняются. По сути, там даётся самый базовый синтаксис языка, простейшие конструкции типа циклов, условий функциий, а также приёмы решения задач с использованием этих конструкций. И, естественно, рассказ про какие-то встроенные функции языка. Так что и обновлять учебник особо не нужно при выходе новой версии языка.
Кстати, вы отредактировали исходный комментарий? Там вроде было про исключения. Контекст обсуждения потерялся просто.
Этот курс для новичков, которые видят PHP в первый раз.
Объём курса ограничен.
И этот объём уже исчерпан текущими материалами.
Курс не единственный в линейке, за ним следуют продвинутые курсы.
Учитывая вводные данные, можно сказать, что внутрь курса уже сложно добавить что-то объёмное.
Так а какие проблемы с добавлением исключений? Проблема в том, что для этого нужно затащить в курс всю концепцию ООП, потому что без этого нормально не рассказать про исключения их работу. Но концепция ООП и так разбирается в последующих курсах, и там же вводится новый принцип обработки ошибок — исключения.
То есть это вопрос чисто методический. На первом курсе люди изучают одни конструкции языка, концепции и способы решения задач, на следующих курсах изучают другие, более продвинутые, конструкции языка, концепции и способы решения задач.
И делать вывод о том, что "раз не затащили исключения в курс для новичков, то качество плохое" — неверно.
Но кто ж из разработчиков задумывается о таких вещах, как методика обучения.
За сим предпочту эту "приятную" дискуссию с вами завершить. Слишком я замшелый для вас, видимо. Не хочу вас позорить тем, что приходится мои спорные аргументы опровергать.
Ещё раз. Тут цель примера не в том, чтобы показать, как "ручками собирать мегабезопасные запросы". Цель проще — показать принцип, "запрос — это строка, её можно собрать ручками, при этом нужно задумываться о безопасности".
Дело в том, что дальше в профессии студенты уже все те же задачи решают с помощью библиотек. То есть знание про то, что запрос можно и вручную собрать нужно им, чтобы понимать, что ничего "волшебного" внутри фреймворков нет, что это просто инструмент, ускоряющий работу. А также это знание нужно, чтобы не быть рабом фреймворков.
Ну и если мы говорим про крутого спеца, который знает тонкости безопасности, и осознанно их применяет, то я за таких специалистов. Просто это рост до такого уровня должен происходить не на этапе "нулевик-джун", а на этапе после трудоустройства, во время профессионального развития. Там человек сможет вспомнить наше "запрос можно и ручками собрать, но надо задумываться о безопасности", и пойдёт копать вглубь. Ведь на это будут и время, и ресурсы, и интерес.
Вот есть начальный курс, цель которого — показать то, как решаются типовые задачи на чистом php. Думаю, тут вы со мной согласитесь, что понимание того, как задачи решаются без фреймворков для новичка важно? Одна из таких задач — составление запросов в базу. Студент должен понимать, что по сути запрос — это строчка, которую он и сам при желании может собрать. Причём собрать любым способом.
Дальше за этим курсом следует ещё несколько курсов, в которых студенты уже учатся пользоваться различными библиотеками и фреймворками. То есть решают привычные задачи, которые они встречали на первом курсе, уже на более высоком уровне. Быстрее, эффективнее и безопаснее.
И в конце профессии выходит студент, который знает, как задачи решаются на самом "низовом" уровне (на чистом php). Но при этом такие задачи он уже решает с помощью фреймворков и библиотек. Ну ведь по факту в поточной или продуктовой разработке все пишут на фреймворках.
И вот главный вопрос: а зачем забивать студенту голову тонкостями мегабезопасного составления строчек для баз данных на курсе начального уровня, если он всё равно в итоге будет для этого пользоваться инструментами, зашитыми во фреймворки? Типа, чтобы он такой грамотный был и если когда-то в жизни придётся писать на чистом пхп, он бы написал безопасно? Чтобы самолюбие своё потешить? Или всё-таки можно эти тонкости опустить и дать человеку тот объём тех знаний, которые ему нунжы для решения задач, чтобы его на работу взяли?
Ваша статья была бы в тему, если бы курс назывался "Информационная безопасность при разработке на PHP". Но курс называется "PHP. Профессиональная веб-разработка".
Если посмотрите на страницу курса, то становится понятно, что этот курс для новичков. Основная его цель — научить нулевиков решать типовые задачи веб-разработки с помощью PHP. Так чтобы они это делали на хорошем профессиональном уровне и могли развиваться дальше.
Можно было бы сказать, что вопросы безопасности тоже должны здесь рассматриваться в полном объёме. Но это не так. Проблема в том, что курс ограничен по объёму материалов и по времени. И за это ограниченное время нужно успеть дать новичку очень много концепций, с которыми он ни разу не сталкивался, от шаблонизации, до работы с базами данных.
Поэтому так глубоко погружаться в вопросы безопасности в таком начальном курсе не получается.
Можно ли поправить материалы таким образом, чтобы по умолчанию там давались самые безопасные приёмы? В принципе, можно. Но какой от этого толк, если не объяснять, почему нужно использовать именно эти приёмы, а не какие-то другие, которыми кишат все примеры в интернете? Если студент не будет знать про все тонкости, связанные с безопасностью тех или иных конструкций и их альтернатив, то и осознанно про безопасность думать не будет.
Так что резюмирую: в фокусе этого курса никогда не была безопасность. Чтобы погрузить студента в тонкости безопасности, чтобы он мог осознанно пользоваться этими знаниями, нужен целый отдельный курс или несколько курсов. А чтобы сделать такие курсы, на это должен быть спрос.
Чтобы во время прохождения курса получить опыт, нужно, чтобы на стороне онлайн-школы была организована коммерческая разработка для тех, кого она учит. Всё просто.
Если школа учит хорошо, то и её отделение с коммерческой разарботкой, которую делают выпускники, тоже будет нормально зарабатывать. Примеры на рынке есть
Я тоже за развитие у верстальщиков и фронтендеров не только дизайнерских навыков, но и редакторских. Многие отсутствия запятых в текстах от заказчика для главной не видят, не то что разрядки. Вопрос лишь в том, в каком порядке прокачивать компетенции. Думаю, самое эффективное — это смежные компетенции (дизайн, редактура) прокачивать уже на этапе карьерного роста.
Мы писали критерии применительно к следующей задаче: "Вёрстка страницы без адаптивности с нуля в условиях полного контроля разметки верстальщиком". То есть это те условия, в которых можно делать "идеальную вёрстку", и они ближе к вёрстке интерфейсов в продуктовых компаниях.
Зачем понимать, как делать "идеальную вёрстку" и как писать "идеальный код"? Чтобы в подходящих условиях делать максимально качественные интерфейсы, а при наличии специфических требований и задач отступать от идеального решения.
С учётом этого и постараюсь ответить на все вопросы.
Присутствие на странице заголовка не является обязательным требованием в вебе. Необходимость в заголовке определяется типом и содержимым страницы.
Думаю, типовой случай страницы в вебе - это информационная страница, документ. И с точки зрения доступности наличие главного заголовка - это очень хорошо. Можете описать специфические задачи, в которых заголовок не нужен? Мы включим их как исключения, или используем в критериях, которые будут касаться этих спецзадач.
Очень размыто в нынешних реалиях. Вызов модального окна должен осуществляться кнопкой или ссылкой? Программная навигация? Отображение компонентов в SPA?
Возможно, формулировка и размыта. Вопрос в другом: считаете ли вы, что хороший верстальщик должен уметь разбираться в том, когда ставить ссылку, а когда кнопку? Если да, то критерий нужен.
Общее правило по выбору кнопки/ссылки у нас получилось сформулировать так, что единственное условие для выбора – это возможность потенциального перехода куда-то по щелку или невозможность перехода куда-то. Конечно, иногда данных с макета недостаточно для принятия решения, и в этом случае надо обращаться к тз или к заказчику.
И сам по себе критерий не может дать чёткий ответ на ваши вопросы, но он говорит о том, что во всех этих ситуациях тег должен быть подобран правильно в зависимости от поставленной задачи и бизнес-логики.
Что? Откуда это взято? Лично я всегда сбрасываю стили таким образом. Даже если я начну лепить простыни для reset.css, то html5 позволяет использовать кастомные элементы. И их эти простыни уже не зацепят.
Основной посыл этого критерия - чтобы не использовали где попало селекторы по тегам. Например, не сбрасывали бы отступы у всех списков с помощью `ul {...}`. Вы в своих специфичных задачах можете использовать глобальные селекторы, если понимаете плюсы-минусы.
А универсальный селектор потому и называется универсальным, что его назначение - установить css-свойства для всех элементов страницы.
Да, такая возможность в CSS присутствует. Но это ведь не означает, что её нужно использовать неаккуратно и напропалую?
Это не критерий. Это просто общепринятая практика. Сами печетесь о корректном каскаде, и сами же игнорируете дополнительные инструменты управления "специфичностью". "Неконтроллируемость" вносят вовсе не идентификаторы или !important, а "говнокод". Ну и никаким количеством "селекторов по классу" вы идентификатор не "перебьёте". Именно в этом и есть его основное назначение. И если пользоваться этим с умом - всё будет контролируемо и читаемо.
Многие критерии и являются просто повторением общепринятых практик. Конкретно этот критерий запрещает ученикам использовать один из инструментов и больше задумываться о том, чтобы не было говнокода.
То же самое что и с идентификаторами. Вам дали инструмент - вы его игнорируете и даже запрещаете, руководствуясь только общепринятой практикой.
А можете подсказать специфичные задачи, где этот инструмент идеально подходит? Мы эти примеры используем в критериях, а также учтём эти применры при обучении этим специфичным задачам.
Удивили. Думал будет "нельзя использовать <br> для управления переносом".
Как раз и хотели запретить распространённую у новичков ошибку и при этом оставить возможность использовать одиночные переносы там, где это нужно.
Вы написали такой талмуд с критериями, но даже не удосужились открыть спецификацию? Т.е. вы не в курсе как HTML5 трактует разделение элементов на строчные и блочные?
К сожалению (а вообще к счастью), HTML5 уже никак не трактует разделение на блочные и строчные (как когда то было в предыдущей версии). В HTML5 ввели категории элементов: фразовые, потоковые и так далее. А названия типов боксов (а не элементов) остались только в CSS. Мне лично это изменение нравится очень сильно, так как отражает важный принцип: разделение содержания и оформления.
Если мне нужно чтобы все картинки на странице были представленные через блочную модель, почему я не могу использовать img{display:block;}? Да, я именно хочу кардинально поменять их поведение. В чём проблема? Ситуация несколько специфичная, но настолько уж. Точно так же далеко не всегда нужно object-fit:contain. Легко может понадобиться и object-fit:cover. В чём тут разница - не объясните?
Всё правильно, вы сами написали, что ситуация специфичная. И если вам для специфичной задачи нужно для всех картинок задать блочные боксы, то это ок. Наша же задача была в этом примере показать один из распространенных способов нормализации картинок, когда можно и глобальный селектор по тегу использовать. И чаще всего для нормализации картинок задают `max-width: 100%`. `object-fit` тоже, думаю, допустим для нормализации
Потому что картинки ведут себя как блочно-строчные по умолчанию (тут надо копать откуда это берётся: из спеки или из общепринятых браузерных стилей по умолчанию), и изменение типа бокса у картинок на блочный кардинально поменяет их поведение.
А та нормализация, которая допускается в критерии, она про перестраховку, чтобы картинка за пределы своего контейнера не вылезала (даже если кто-то вставил картинку, которая намного шире контейнера).
Насколько я понимаю, вопросы был именно про critical css
Что касается pagespeed / lighthouse — при разработке критериев мы учитывали и требования этих инструментов, и тот объём задач, который делает студент на этом курсе. Здесь он верстает сайт из двух страниц, поэтому продвинутые техники оптимизации пока не даём. Но базовые вещи требуем, например, про подбор правильного формата для картинок и оптимизацию графики.
нет пункта про картинки, а именно про отзывчивость
Всё верно, так как на этом курсе нет задач по адаптивной графике, то этот критерий мы не используем, но он есть там, где учатся решать задачи, связанные с адаптивом.
в форматах нет современных
мы от части форматов сознательно отказались, так как фигма из коробки не умеет их отдавать, поэтому нужны какие-то дополнительные инструменты. как вы у себя получаете эти форматы?
в подключении стилей в эпоху хттп2 подключение разными файлами считать за ошибку
для решаемой задачи (вёрстка с нуля сайта из 2-3 страниц) это скорее ошибка, да даже и в более сложных проектах сборщики всё равно склеивают стили в один файл
нет ни слова про критические стили
а разве это не инструмент оптимизации, который нужен на достаточно крупных проектах, а на маленьких нет? то есть это достаточно специфическая вещь?
и есть доля непонятной отсебятины - про стили для тегов (на самом деле от них не уйти при наличии пользовательского ввода - комменты на сайте, статьи в админке через редактор и т.д.)
в блоке "о чём эти критерии" как раз описывается, что мы не охватываем этой системой, в частности мы не охватываем специфичные задачи вёрстки под какие-либо цмс. тут скорее вёрстка в условиях продуктовой компании, когда всю разметку контролирует верстальщик и в которую очень аккуратно подставляются пользовательские данные
то получится верстка для страницы, которую нужно будет дорабатывать для продакшена и работодатели не сильно будут рады, если верстальщик им такую верстку «принесёт» как готовую
какой вид продакшна вы имеете в виду? продакшн в заказной разработке, когда верстают для клиента, который потом будет натягивать вёрстку на какую-то цмс или продакшн в продуктовой разработке, когда с нуля пилится интерфейс продукта?
Кто для вас новичок? Выпускник технического вуза или выпускник исторического факультета, который никогда не программировал. Есть ощущение, что новички бывают сильно разные и для кого-то есть смысл рассказывать про побочные эффекты в базовом курсе, а кому-то ещё про переменные надо долго разжёвывать.
И интерактивные курсы можно делать хорошо. Так, что и профессионалам будет полезно их пройти. У нас многие так курс по флексам проходят или по трансформациям. Намного удобнее, чем спецификацию перечитывать.
Ваш посыл не понятен. Все курсы плохие? Какие-то конкретные курсы плохие? В принципе нельзя сделать хорошие курсы?
Если есть конкретика, найденные ошибки, то опишите их. Разработчики будут рады исправить.
Все верно пишете. Очень важна плавность и последовательность материалов. Причём последовательность даже важнее. Если мы даём на первом курсе базовые конструкции языка, то и закрепляем эти конструкции решением типовых задач, в которых эти же конструкции используются. Да, код студента на первом курсе будет не идеальным, не будет полностью соответствовать подходам, которые используют мидлы и сеньоры, пишущие на последней версии языка. Но ведь это всего лишь промежуточный результат. А нам (и вам, если вы нанимаете) важен конечный результат, который достигается после прохождения всех курсов. И там уже ученик знает, что такое ООП, использует продвинутые возможности языка и инструменты.
А что касается учебника, то да, все материалы не идеальны, все материалы могут постепенно устаревать. Но эти вещи некритичны для итогового результата. Наша задача — выпустить толкового джуна, который сможет дальше профессионально расти. И если у него будут какие-то пробелы в глубоких вопросах безопасности, это нормально, на то он и джун. Просто здесь эти некритичные проблемы почему-то чрезмерно раздуты.
Вы знаете, я не автор курса по пхп, а тут выражаю своё личное мнение. Имею я право на личное отношение к какому-то человеку?
Что касается сообщения выше, оно исключительно для автора поста. Дело в том, что все его предложения методически несостоятельны, а мы себе такие вещи позволить не можем. А тон и стиль его общения не позволяет вести продуктивную дискуссию. При этом видно, что в техническом плане уровень автора достаточно высок.
Что касается вашего вопроса про "а зачем забивать студенту голову тонкостями мегабезопасного составления строчек для баз данных на курсе начального уровня". То собственно, в чём проблема. Наша задача подготовить для рынка джунов, которые будут писать вменяемый код. В конечном счёте, после прохождения всех курсов, они будут писать код с использованием фреймворков и библиотек, то есть проблем с безопасностью их кода не будет. И при этом у них будет достаточное понимание и база, чтобы углубляться в профессиональном мастерстве в нужном им направлении, хоть в вопросе безопасности, хоть в вопросе производительности и так далее.
Проблема с джунами ведь какая? Чтобы трудоустроиться они должны давать какой-то результат бизнесу, то есть уметь достаточно быстро решать определённый класс задач с использованием определённого набора инструментов. И никакой бизнес не будет требовать от джуна глубоких познаний в безопасности. Так чем наш подход по подготовке прикладных специалистов плох?
С версиями тоже есть определённые тонкости. То, что даётся в учебнике в стартовом курсе, это настолько базовые вещи, что они от версии к версии почти и не меняются. По сути, там даётся самый базовый синтаксис языка, простейшие конструкции типа циклов, условий функциий, а также приёмы решения задач с использованием этих конструкций. И, естественно, рассказ про какие-то встроенные функции языка. Так что и обновлять учебник особо не нужно при выходе новой версии языка.
Кстати, вы отредактировали исходный комментарий? Там вроде было про исключения. Контекст обсуждения потерялся просто.
https://habr.com/ru/post/672800/comments/#comment_24496672
Контекст глубже и сложнее. Вот вам вводные:
Этот курс для новичков, которые видят PHP в первый раз.
Объём курса ограничен.
И этот объём уже исчерпан текущими материалами.
Курс не единственный в линейке, за ним следуют продвинутые курсы.
Учитывая вводные данные, можно сказать, что внутрь курса уже сложно добавить что-то объёмное.
Так а какие проблемы с добавлением исключений? Проблема в том, что для этого нужно затащить в курс всю концепцию ООП, потому что без этого нормально не рассказать про исключения их работу. Но концепция ООП и так разбирается в последующих курсах, и там же вводится новый принцип обработки ошибок — исключения.
То есть это вопрос чисто методический. На первом курсе люди изучают одни конструкции языка, концепции и способы решения задач, на следующих курсах изучают другие, более продвинутые, конструкции языка, концепции и способы решения задач.
И делать вывод о том, что "раз не затащили исключения в курс для новичков, то качество плохое" — неверно.
Но кто ж из разработчиков задумывается о таких вещах, как методика обучения.
За сим предпочту эту "приятную" дискуссию с вами завершить. Слишком я замшелый для вас, видимо. Не хочу вас позорить тем, что приходится мои спорные аргументы опровергать.
Ещё раз. Тут цель примера не в том, чтобы показать, как "ручками собирать мегабезопасные запросы". Цель проще — показать принцип, "запрос — это строка, её можно собрать ручками, при этом нужно задумываться о безопасности".
Дело в том, что дальше в профессии студенты уже все те же задачи решают с помощью библиотек. То есть знание про то, что запрос можно и вручную собрать нужно им, чтобы понимать, что ничего "волшебного" внутри фреймворков нет, что это просто инструмент, ускоряющий работу. А также это знание нужно, чтобы не быть рабом фреймворков.
Ну и если мы говорим про крутого спеца, который знает тонкости безопасности, и осознанно их применяет, то я за таких специалистов. Просто это рост до такого уровня должен происходить не на этапе "нулевик-джун", а на этапе после трудоустройства, во время профессионального развития. Там человек сможет вспомнить наше "запрос можно и ручками собрать, но надо задумываться о безопасности", и пойдёт копать вглубь. Ведь на это будут и время, и ресурсы, и интерес.
Давайте перейдём на шажок дальше.
Вот есть начальный курс, цель которого — показать то, как решаются типовые задачи на чистом php. Думаю, тут вы со мной согласитесь, что понимание того, как задачи решаются без фреймворков для новичка важно? Одна из таких задач — составление запросов в базу. Студент должен понимать, что по сути запрос — это строчка, которую он и сам при желании может собрать. Причём собрать любым способом.
Дальше за этим курсом следует ещё несколько курсов, в которых студенты уже учатся пользоваться различными библиотеками и фреймворками. То есть решают привычные задачи, которые они встречали на первом курсе, уже на более высоком уровне. Быстрее, эффективнее и безопаснее.
И в конце профессии выходит студент, который знает, как задачи решаются на самом "низовом" уровне (на чистом php). Но при этом такие задачи он уже решает с помощью фреймворков и библиотек. Ну ведь по факту в поточной или продуктовой разработке все пишут на фреймворках.
И вот главный вопрос: а зачем забивать студенту голову тонкостями мегабезопасного составления строчек для баз данных на курсе начального уровня, если он всё равно в итоге будет для этого пользоваться инструментами, зашитыми во фреймворки? Типа, чтобы он такой грамотный был и если когда-то в жизни придётся писать на чистом пхп, он бы написал безопасно? Чтобы самолюбие своё потешить? Или всё-таки можно эти тонкости опустить и дать человеку тот объём тех знаний, которые ему нунжы для решения задач, чтобы его на работу взяли?
Ваша статья была бы в тему, если бы курс назывался "Информационная безопасность при разработке на PHP". Но курс называется "PHP. Профессиональная веб-разработка".
Если посмотрите на страницу курса, то становится понятно, что этот курс для новичков. Основная его цель — научить нулевиков решать типовые задачи веб-разработки с помощью PHP. Так чтобы они это делали на хорошем профессиональном уровне и могли развиваться дальше.
Можно было бы сказать, что вопросы безопасности тоже должны здесь рассматриваться в полном объёме. Но это не так. Проблема в том, что курс ограничен по объёму материалов и по времени. И за это ограниченное время нужно успеть дать новичку очень много концепций, с которыми он ни разу не сталкивался, от шаблонизации, до работы с базами данных.
Поэтому так глубоко погружаться в вопросы безопасности в таком начальном курсе не получается.
Можно ли поправить материалы таким образом, чтобы по умолчанию там давались самые безопасные приёмы? В принципе, можно. Но какой от этого толк, если не объяснять, почему нужно использовать именно эти приёмы, а не какие-то другие, которыми кишат все примеры в интернете? Если студент не будет знать про все тонкости, связанные с безопасностью тех или иных конструкций и их альтернатив, то и осознанно про безопасность думать не будет.
Так что резюмирую: в фокусе этого курса никогда не была безопасность. Чтобы погрузить студента в тонкости безопасности, чтобы он мог осознанно пользоваться этими знаниями, нужен целый отдельный курс или несколько курсов. А чтобы сделать такие курсы, на это должен быть спрос.
Чтобы во время прохождения курса получить опыт, нужно, чтобы на стороне онлайн-школы была организована коммерческая разработка для тех, кого она учит. Всё просто.
Если школа учит хорошо, то и её отделение с коммерческой разарботкой, которую делают выпускники, тоже будет нормально зарабатывать. Примеры на рынке есть
Я тоже за развитие у верстальщиков и фронтендеров не только дизайнерских навыков, но и редакторских. Многие отсутствия запятых в текстах от заказчика для главной не видят, не то что разрядки. Вопрос лишь в том, в каком порядке прокачивать компетенции. Думаю, самое эффективное — это смежные компетенции (дизайн, редактура) прокачивать уже на этапе карьерного роста.
Правильно, адаптив детально разбирается на втором курсе в профессии. А на первом курсе мы даём необходимую базу.
Мы писали критерии применительно к следующей задаче: "Вёрстка страницы без адаптивности с нуля в условиях полного контроля разметки верстальщиком". То есть это те условия, в которых можно делать "идеальную вёрстку", и они ближе к вёрстке интерфейсов в продуктовых компаниях.
Зачем понимать, как делать "идеальную вёрстку" и как писать "идеальный код"? Чтобы в подходящих условиях делать максимально качественные интерфейсы, а при наличии специфических требований и задач отступать от идеального решения.
С учётом этого и постараюсь ответить на все вопросы.
Думаю, типовой случай страницы в вебе - это информационная страница, документ. И с точки зрения доступности наличие главного заголовка - это очень хорошо. Можете описать специфические задачи, в которых заголовок не нужен? Мы включим их как исключения, или используем в критериях, которые будут касаться этих спецзадач.
Возможно, формулировка и размыта. Вопрос в другом: считаете ли вы, что хороший верстальщик должен уметь разбираться в том, когда ставить ссылку, а когда кнопку? Если да, то критерий нужен.
Общее правило по выбору кнопки/ссылки у нас получилось сформулировать так, что единственное условие для выбора – это возможность потенциального перехода куда-то по щелку или невозможность перехода куда-то. Конечно, иногда данных с макета недостаточно для принятия решения, и в этом случае надо обращаться к тз или к заказчику.
И сам по себе критерий не может дать чёткий ответ на ваши вопросы, но он говорит о том, что во всех этих ситуациях тег должен быть подобран правильно в зависимости от поставленной задачи и бизнес-логики.
Основной посыл этого критерия - чтобы не использовали где попало селекторы по тегам. Например, не сбрасывали бы отступы у всех списков с помощью `ul {...}`. Вы в своих специфичных задачах можете использовать глобальные селекторы, если понимаете плюсы-минусы.
Да, такая возможность в CSS присутствует. Но это ведь не означает, что её нужно использовать неаккуратно и напропалую?
Многие критерии и являются просто повторением общепринятых практик. Конкретно этот критерий запрещает ученикам использовать один из инструментов и больше задумываться о том, чтобы не было говнокода.
А можете подсказать специфичные задачи, где этот инструмент идеально подходит? Мы эти примеры используем в критериях, а также учтём эти применры при обучении этим специфичным задачам.
Как раз и хотели запретить распространённую у новичков ошибку и при этом оставить возможность использовать одиночные переносы там, где это нужно.
К сожалению (а вообще к счастью), HTML5 уже никак не трактует разделение на блочные и строчные (как когда то было в предыдущей версии). В HTML5 ввели категории элементов: фразовые, потоковые и так далее. А названия типов боксов (а не элементов) остались только в CSS. Мне лично это изменение нравится очень сильно, так как отражает важный принцип: разделение содержания и оформления.
Всё правильно, вы сами написали, что ситуация специфичная. И если вам для специфичной задачи нужно для всех картинок задать блочные боксы, то это ок. Наша же задача была в этом примере показать один из распространенных способов нормализации картинок, когда можно и глобальный селектор по тегу использовать. И чаще всего для нормализации картинок задают `max-width: 100%`. `object-fit` тоже, думаю, допустим для нормализации
Спасибо, мы всегда рядом с процессом разработки курсов, хотя лекции уже и не читаем
Потому что картинки ведут себя как блочно-строчные по умолчанию (тут надо копать откуда это берётся: из спеки или из общепринятых браузерных стилей по умолчанию), и изменение типа бокса у картинок на блочный кардинально поменяет их поведение.
А та нормализация, которая допускается в критерии, она про перестраховку, чтобы картинка за пределы своего контейнера не вылезала (даже если кто-то вставил картинку, которая намного шире контейнера).
Насколько я понимаю, вопросы был именно про critical css
Что касается pagespeed / lighthouse — при разработке критериев мы учитывали и требования этих инструментов, и тот объём задач, который делает студент на этом курсе. Здесь он верстает сайт из двух страниц, поэтому продвинутые техники оптимизации пока не даём. Но базовые вещи требуем, например, про подбор правильного формата для картинок и оптимизацию графики.
Давайте по порядку
Всё верно, так как на этом курсе нет задач по адаптивной графике, то этот критерий мы не используем, но он есть там, где учатся решать задачи, связанные с адаптивом.
мы от части форматов сознательно отказались, так как фигма из коробки не умеет их отдавать, поэтому нужны какие-то дополнительные инструменты. как вы у себя получаете эти форматы?
для решаемой задачи (вёрстка с нуля сайта из 2-3 страниц) это скорее ошибка, да даже и в более сложных проектах сборщики всё равно склеивают стили в один файл
а разве это не инструмент оптимизации, который нужен на достаточно крупных проектах, а на маленьких нет? то есть это достаточно специфическая вещь?
в блоке "о чём эти критерии" как раз описывается, что мы не охватываем этой системой, в частности мы не охватываем специфичные задачи вёрстки под какие-либо цмс. тут скорее вёрстка в условиях продуктовой компании, когда всю разметку контролирует верстальщик и в которую очень аккуратно подставляются пользовательские данные
какой вид продакшна вы имеете в виду? продакшн в заказной разработке, когда верстают для клиента, который потом будет натягивать вёрстку на какую-то цмс или продакшн в продуктовой разработке, когда с нуля пилится интерфейс продукта?
Кто для вас новичок? Выпускник технического вуза или выпускник исторического факультета, который никогда не программировал. Есть ощущение, что новички бывают сильно разные и для кого-то есть смысл рассказывать про побочные эффекты в базовом курсе, а кому-то ещё про переменные надо долго разжёвывать.
Ваш посыл не понятен. Все курсы плохие? Какие-то конкретные курсы плохие? В принципе нельзя сделать хорошие курсы?
Если есть конкретика, найденные ошибки, то опишите их. Разработчики будут рады исправить.