Комментарии 64
НЛО прилетело и опубликовало эту надпись здесь
1. Использование PHP
Когда в «студиях» на «своем движке» на каждой странице повторно грузится фоновая графика\логотипы
Когда текст со страница лень вставить в текстовый редактор и проверить на ошибки.
И вообще есть ошибки в дизайне, есть ошибки в безопасности кода, есть ошибки в навигации и логике\структуре сайта.
Но часто писакам, влом читать как надо и как не надо. И они думают что если они прочитали статью 10 ошибок… то все. По каждой тематике порой не одна книга написана. Суть конечно можно ужать.
Все проблемы обычно от-того что всем занимается 1 человек или ему в один прекрасный момент пофиг что он делает говно! Некоторым пофиг сразу. (они сразу не читают и не хотят знать как нужно\лучше\правильно)
Но идея подачи проблема\последствия\Решение правильная имхо. (Но материал подан поверхностно (это не упрек))
Когда текст со страница лень вставить в текстовый редактор и проверить на ошибки.
И вообще есть ошибки в дизайне, есть ошибки в безопасности кода, есть ошибки в навигации и логике\структуре сайта.
Но часто писакам, влом читать как надо и как не надо. И они думают что если они прочитали статью 10 ошибок… то все. По каждой тематике порой не одна книга написана. Суть конечно можно ужать.
Все проблемы обычно от-того что всем занимается 1 человек или ему в один прекрасный момент пофиг что он делает говно! Некоторым пофиг сразу. (они сразу не читают и не хотят знать как нужно\лучше\правильно)
Но идея подачи проблема\последствия\Решение правильная имхо. (Но материал подан поверхностно (это не упрек))
НЛО прилетело и опубликовало эту надпись здесь
Замечено было, что зачастую фразу «PHP — говно» кидают люди, никогда не кодившие на PHP, а просто потому что ругать PHP — модно.Или трогавшие php3 в конце 90х и, возможно, 4 пых в начале нулевых. И пых того времени — говно, хотя и был несколько удобнее того же perl'а для cgi.
В нашу организацию влилась молодая и талантливая команда дизайнеров и веб-программистов. По текущему проекту платежной системы их первое предложение было — ууууу, у вас все на Java, а давайте перепишем все на PHP!
Проблема PHP, как впрочем и любого другого языка, заключается в людях, которые пишут на там где не надо. Такие люди обычно изучают PHP и считают, что всё, дальше уже некуда, на кой черт изучать что-то новое, если все или почти все можно на PHP написать?
Проблема PHP, как впрочем и любого другого языка, заключается в людях, которые пишут на там где не надо. Такие люди обычно изучают PHP и считают, что всё, дальше уже некуда, на кой черт изучать что-то новое, если все или почти все можно на PHP написать?
Это другая сторона вопроса. Некомпетентность и узкий кругозор — это всегда боль для окружающих. Примера ради, когда пихают стек EE куда не надо, тоже получается совсем не конфетка.
Другое дело, что среди php'шников очень много некомпетентного народа, если брать абсолютные цифры. Просто засчёт низкого порога вхождения и его массовости.
Другое дело, что среди php'шников очень много некомпетентного народа, если брать абсолютные цифры. Просто засчёт низкого порога вхождения и его массовости.
Да просто он везде нужен в мелком вэбе. Нужен мелкий сайт. На чем его делать? На PHP, конечно. Брать готовый двиг? Он тоже на PHP. Хочешь — не хочешь, а хоть немного его знать придется чтобы где-то что-то поправить, дописать и т.д
Сайт-визитку для небольшой конторы за пару вечеров любой веб-мастер широкого профиля сделает — хостинга бесплатного хватит, 500р (максимум) на домен, двиг бесплатный залил, шаб где-то взял и чуть подправил. Все, готово, давайте деньги.
Сайт-визитку для небольшой конторы за пару вечеров любой веб-мастер широкого профиля сделает — хостинга бесплатного хватит, 500р (максимум) на домен, двиг бесплатный залил, шаб где-то взял и чуть подправил. Все, готово, давайте деньги.
blah blah blah
Со всем согласен, но не понял как совместимо использование bower, который упоминается в конце, и пункт о минимизации CSS/JS.
И кстати, адаптивный дизайн не панацея. Я бы ставил на мобильную версию.
И кстати, адаптивный дизайн не панацея. Я бы ставил на мобильную версию.
Я бы ставил на мобильную версию.Главное, чтобы был переход на полноценную версию, то очень хочется убивать, когда невозможно с мобильника использовать какой-нибудь критичный функционал.
Я бы ставил на мобильные версии только в случае сложных сервисов, типа соцсетей. Там очень сложные и развесистые интерфейсы, и если делать их адаптивно, они получатся очень тяжелыми и избыточными. Для мелких и большинства средних сайтов адаптивность — оптимальный выбор.
По первому пункту, это вообще не проблема, к примеру в генераторе gulp-webapp сразу при установке компонента, в html автоматически подключаются пути к js и css, а при билде это все склеивается и минимизируется, там правда возникают порой неожиданные проблемы, но все решаемо
Ошибка: Страницы, наполненные полезным контентом, но совершенное недружественные к поисковикам. Не внедрены специальные возможности для слабовидящих пользователей.
А это вы как ухитрились в одну ошибку запихнуть такие никак не связанные друг с другом вещи?
НЛО прилетело и опубликовало эту надпись здесь
применяют span или div в случаях, когда более уместны иные, более подходящие к содержимому тэги;
А можно подробнее? Строчный и блочный контейнеры, что может быть проще и безобиднее? Как их можно использовать не по назначению?
НЛО прилетело и опубликовало эту надпись здесь
Вполне возможная причина — адаптивный дизайн. На маленьких экранах таблица «разваливается» на другую сетку.
НЛО прилетело и опубликовало эту надпись здесь
К сожалению, на практике там всплывают нюансы :) Но в общем и целом решение верное, да.
НЛО прилетело и опубликовало эту надпись здесь
Нюанс в том, что таблица перестает быть таблицей и превращается в гору дивов.
Она теряет табличное поведение, выраженное в том, что ячейки в строке будут всегда иметь одну высоту, а в столбце — одну ширину.
Если данные в таблице гарантированно «красивые», это не составляет очень большой проблемы, но если у нас есть вероятность прихода «нетипичных» данных (очень длинная строка, например) — всё может рассыпаться. Нужно очень внимательно за этим сделить и тщательно тестировать верстку на разных данных.
Она теряет табличное поведение, выраженное в том, что ячейки в строке будут всегда иметь одну высоту, а в столбце — одну ширину.
Если данные в таблице гарантированно «красивые», это не составляет очень большой проблемы, но если у нас есть вероятность прихода «нетипичных» данных (очень длинная строка, например) — всё может рассыпаться. Нужно очень внимательно за этим сделить и тщательно тестировать верстку на разных данных.
НЛО прилетело и опубликовало эту надпись здесь
Я понимаю, что это ожидаемое поведение. Имеется в виду, что в реальных задачах оказывается, что совладать с этой псевдо-таблицей бывает значительно сложнее, чем казалось на первый взгляд в теории. А если там ещё и rowspan/colspan есть — вообще туши свет.
Приём с дополнительными атрибутами интересный, да.
Приём с дополнительными атрибутами интересный, да.
Может дело в том что таблица накладывает ограничения производительности?
>> Может не в тему, но я когда-то видел пример таблицы, сверстанной div-ами
Вы увидели bootstrap.
Вы увидели bootstrap.
.container>.row>.col
table>tr>td
В стародавние времена… таблица отрисовывалась только после получения закрывающего теги. Дивы это финт ушами для данного, неактуального в наши дни, случая.
НЛО прилетело и опубликовало эту надпись здесь
Ну я тут откапал свою старые опыты: "Не очевидные истины. Скелет страницы таблицей. Неправильно." и на сколько я вижу проблемы это не решало. Более того, сейчас посмотрел еще раз в последних лисе и хроме под убунтой и таки там страница в итоге отрисовывается на 14-16 секунде только. Причем отчего-то оба варианта.
Имеется ввиду, что span и div лишены семантического смыслы. В некоторых случаях лучше заменить их на более «значимые» тэги, например, address, nav, header и т.д…
Вероятно, имелось в виду, что нужно использовать не только DIV, но и FOOTER, HEADER, SECTION, ASIDE, NAV; не только SPAN, но и ABBR, CITE и т.д.
Более подходящие — видимо, имеются в виду теги типа ul/li, strong/em, dt/dd и так далее.
Понадергаем рекомендаций из прошлого десятилетия, смешаем теплое с мягким, и получим данную статью. Браво.
Объясните объективно, чем div'ы в сочетании с «display: table;» плохи для создания макета? В HTML нет ни одного тега, предназначенного для создания колонок (недавно появился flex-layout, но он поддерживается не всеми браузерами). В этом плане табличная вёрстка наравне с float, «display: inline-block;» и «position: absolute;».
Ну как минимум margin-ы у элементов с display: table-cell работать не будут. Зачем городить огород, если все можно обычными флоатами сделать
Зато работает padding, суммарная ширина колонок всегда будет 100% и ни одна колонка никогда не съедет вниз. У каждого из описанных подходов свои плюсы и минусы, лучший определяется контекстом. Ладно, использование — это неверная семантика. Но почему вдруг «display: table;» стал запретным, не понимаю.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
По-моему таблицы надо верстать на предназначенных этому тегах)
Странно, что в контексте «У меня в браузере всё работает» даже не упомянут normalize.css.
Некоторые советы настраивают на неверный подход к обеспечению безопасности. Например:
«Неважно, как это будет сделано на стороне браузера, главное, чтобы на сервере были уже проверенные данные.»
На сервер можно отправить какие угодно данные, код на клиенте от этого никак не спасёт. Просто с самого начала, разрабатывая серверную часть, привыкайте не доверять данным, пришедшим с клиента. Всегда проверяйте их на сервере.
«Неважно, как это будет сделано на стороне браузера, главное, чтобы на сервере были уже проверенные данные.»
На сервер можно отправить какие угодно данные, код на клиенте от этого никак не спасёт. Просто с самого начала, разрабатывая серверную часть, привыкайте не доверять данным, пришедшим с клиента. Всегда проверяйте их на сервере.
я бы назвал эту статью Десять ошибок разработчиков для министерства образования ;) недавно маман попросила ей работы на конкурс скинуть, так это ахтунг. мало того, что сайт явно указывал, что единственным браузером, в котором он будет хорошо работать — это ie, мол даже не смейте заходить к нам с других кофеварок… так в общем чтобы разобраться с их 'юзабилити' и загрузить три фото + описание работы, разгадать как оплатить заявку, итп — ушло несколько часов. Теперь троллю её, что она попала в тройку, потому что очень мало кто смог загрузить свои работы )) не для обычных людей уж точно
Я бы сказал, что это ошибки старого разработчика. Те, кто начал работать недавно и не в курсе что такое «вёрстка таблицами».
Напомнили мне про мой первый (и единственный) сайт, который я делал за деньги компании отца в 2000-2001 годах где-то.
Сидел ночами, в emacs-е руками все писал, читал стандарты, в GIMP-е картинки рисовал, создавал огромные таблицы, рисуя руками TR/TD, старался соблюдать все требования, которые мог в те годы найти (интернета, можно сказать, почти не было, Дальний Восток).
Нашел его, залил на хостинг и умилился. Все работает в Firefox корректно до сих пор, хотя сделано с модными тогда фреймами.
Тогда еще принято было писать такое прямо на главной:
==
Данный сайт оптимизирован для разрешения 1024x768 и, частично, для 800x600. Если Вы просматриваете эту страницу при разрешении меньше 800x600 или если страницы при разрешении 800x600 выглядят «некрасиво», то рекомендуем выключить фреймы, чтобы увеличить свободное место на экране. Также для более комфортного просмотра рекомендуем включить поддержку CSS и JavaScript, если она отключена, и не просматривать сайт броузером Netscape Navigator, т.к. он некорректно поддерживает вложенные таблицы и CSS
==
А в коде нашел это:
==
Ваш браузер не поддерживает фреймы
Однако, данный сайт сделан так, что его можно просматривать и браузером, не понимающим фреймы,
для этого перейдите на Главную страницу. И все же, без фреймов, CSS, JavaScript
на данном сайте будет не так удобно, поэтому советуем обносить свой «софт» ;)
==
Особой моей гордостью был придуманный универсальный каталогизатор на javascript, нужно было просто называть картинки и прочие файлы именем нового устройства и он бы автоматически показывал их, по типу и т.п., управление внизу страницы было «инновационным» как для сайтов нашего региона :)
Еще очень «крутой» фишкой для того времени была подгрузка всех картинок в фоне, тоже придумал и радовался. Тогда все сидели на модемах и когда делаешь mouseover, можно было несколько секунд ждать, пока подгрузится нужная картинка.
Дааа, юность, азарт, ночи напролет, всё интересно, все взахлёб изучаешь, впитываешь… Лучшее время.
Вот, кстати, сайт: hiddenman.esy.es/fs (первый попавшийся хостинг). Таблица выбора копировально-множительных аппаратов, подробная информация и т.д.
P.S. А вот к Хроме, кстати. левый фрейм кривовато отображается. А остальное работает и через 15 лет. Кодировка нигде не указана (тогда другой и не было, кроме непопулярной уже KOI8-R, сейчас браузеры сами понимают, какая она, если что, смените кодировку на CP1251 и насладитесь «шедевром». По сути, только раздел Контакты заполнен и Копировальная техника)
Сидел ночами, в emacs-е руками все писал, читал стандарты, в GIMP-е картинки рисовал, создавал огромные таблицы, рисуя руками TR/TD, старался соблюдать все требования, которые мог в те годы найти (интернета, можно сказать, почти не было, Дальний Восток).
Нашел его, залил на хостинг и умилился. Все работает в Firefox корректно до сих пор, хотя сделано с модными тогда фреймами.
Тогда еще принято было писать такое прямо на главной:
==
Данный сайт оптимизирован для разрешения 1024x768 и, частично, для 800x600. Если Вы просматриваете эту страницу при разрешении меньше 800x600 или если страницы при разрешении 800x600 выглядят «некрасиво», то рекомендуем выключить фреймы, чтобы увеличить свободное место на экране. Также для более комфортного просмотра рекомендуем включить поддержку CSS и JavaScript, если она отключена, и не просматривать сайт броузером Netscape Navigator, т.к. он некорректно поддерживает вложенные таблицы и CSS
==
А в коде нашел это:
==
Ваш браузер не поддерживает фреймы
Однако, данный сайт сделан так, что его можно просматривать и браузером, не понимающим фреймы,
для этого перейдите на Главную страницу. И все же, без фреймов, CSS, JavaScript
на данном сайте будет не так удобно, поэтому советуем обносить свой «софт» ;)
==
Особой моей гордостью был придуманный универсальный каталогизатор на javascript, нужно было просто называть картинки и прочие файлы именем нового устройства и он бы автоматически показывал их, по типу и т.п., управление внизу страницы было «инновационным» как для сайтов нашего региона :)
Еще очень «крутой» фишкой для того времени была подгрузка всех картинок в фоне, тоже придумал и радовался. Тогда все сидели на модемах и когда делаешь mouseover, можно было несколько секунд ждать, пока подгрузится нужная картинка.
Дааа, юность, азарт, ночи напролет, всё интересно, все взахлёб изучаешь, впитываешь… Лучшее время.
Вот, кстати, сайт: hiddenman.esy.es/fs (первый попавшийся хостинг). Таблица выбора копировально-множительных аппаратов, подробная информация и т.д.
P.S. А вот к Хроме, кстати. левый фрейм кривовато отображается. А остальное работает и через 15 лет. Кодировка нигде не указана (тогда другой и не было, кроме непопулярной уже KOI8-R, сейчас браузеры сами понимают, какая она, если что, смените кодировку на CP1251 и насладитесь «шедевром». По сути, только раздел Контакты заполнен и Копировальная техника)
За деньги для компании, в смысле. Помню, вроде бы $50 заплатили и я купил себе свой первый пейджер. Сайт еще немного обновлялся, на archive.org нашел, но у себя уже не найду исходники.
Сейчас вспомнил еще, что в те времена успевал невероятно много всего делать, откуда время бралось? За год или два столько всего изучил, столько всяких проектов сделал для Fido, BBS-ок и прочего. А сейчас не успел оглянуться — год прошел — а я так и сижу, читаю какие-то тупые статьи в интернете так ничего и не сделав.
Сейчас вспомнил еще, что в те времена успевал невероятно много всего делать, откуда время бралось? За год или два столько всего изучил, столько всяких проектов сделал для Fido, BBS-ок и прочего. А сейчас не успел оглянуться — год прошел — а я так и сижу, читаю какие-то тупые статьи в интернете так ничего и не сделав.
> Последствия: Использование HTML десятилетней «свежести» может привести к излишнему усложнению разметки страницы
На практике чаще всего наблюдается строго обратная ситуация.
На практике чаще всего наблюдается строго обратная ситуация.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 частых ошибок начинающих веб-разработчиков