Я вынужден с вами несколько не согласиться. Если шрифт в заголовке нужен такой, то таким он должен быть у большинства. Если нет возможности вставить кастомный шрифт, тогда лучше вставить картинку. Сайт для людей прежде всего!
Если этот кастомный шрифт нужен абы был, то тогда незачем его вообще лепить.
Вы меня не слышите. Тянуть — не проблема. Я говорю о другом. Когда узор нарисован так, что его нельзя тянуть.
Вот попробуйте сейчас нарисовать любую аброкадабру (такую, которую нельзя взять и оборвать в произвольной точке), скажем 123 пикселя. А потом сверстайте блок, который должен тянуться.
В таком случае нахрена спрашивается кастомный шрифт? С такой непритязательностью для блоков с текстом всегда можно найти адекватную замену из стандартных шрифтов.
Скруглённые углы — ладно, да иногда бывают заморочки, но это всё решаемо, было бы желание.
А вот шрифты… попробуйте сейчас сверстать под все IE с нестандартным шрифтом. А сглаживание? Эх…
Что значит упростить? Что значит лень реализовать идею на javascript?
Вы сами верстальщик и должны понимать, что подпирание вёрстки JS-костылями не допустимо. Да, бывают исключительные ситуации, когда совсем баста и для идеала такой костыль приставляется, но в любом случае это решение грязное.
Привожу банальный пример. Есть макет, в нём блок. Блок должен тянутся по вертикали. Но по бордюру блок обрамлён узором. Когда дизайнер нарисовал макет и подогнал внутри текст под высоту кратного узора — всё выглядит супер. Но сразу проблема как это сверстать? Если подкладывать картинку бэкграундом — то узор будет разрываться. Подпирать костылём? Хорошо, подопрём. Допустим узор 100 пикселей в высоту. Блок у нас в высоту должен быть 120 пикселей. Получается, что костылём нам нужно вытянуть блок до 200 пикселей, чтобы узор не оборвался? В итоге имеем жуткие 80 пикселей пустого места. А если узор пикселей на 200-250?
А такая ситуация очень распространена. Дизайнер привык рисовать буклеты/плакаты и прочую полиграфию и для него невдомёк, что блок может тянутся.
Проблема глубже. Когда дизайнер по лени совершает ошибку — она часто скрытая, внутренняя и никому кроме последующего исполнителя (верстальщика не видна). Заказчик может одобрить дизайн, опираясь на свой субъективный взгляд, даже не представляя какими сложностями могут обернутся те или иные детали. А верстальщик потом ломает голову, как ему сбалансировать, между pixel-perfect, кроссбраузерностью и «тянучестью» блоков.
И совсем другое дело примеры приведённые в статье. Мы видим банальную некомпетентность верстальщика. Если дизайнер поставил свой цвет ссылок, то такой он и должен оказаться после вёрстки. А если верстальщик самовольно внёс изменения в макет, то му просто нужно отбивать за это руки. И эти ошибки видны моментально. Заказчик просто вправе не принять такую работу.
Да, но по условию была именно 8-ка, поэтому можно было пользоваться всеми её преимуществами.
Да, сначала я тоже задумывался о делении на части, но потом несколько раз попробовал сделать полную, начальную выгрузку. Всё выгрузилось и обработалось на сервере без сбоев. А уж частичное обновление и подавно работает.
Но, да, при больших размерах обмена, действительно стоило бы делить данные на части. Спасибо, за замечание.
Заказы обратно выгружать не захотел сам заказчик, по своим личным причинам. Но если бы уж и потребовалась обработка заказов, то её бы я реализовал наверное так:
1С стучится, по указанному URL, где выводится список новых, необработанных заказов. Далее парсим 1С'кой информацию о новых заказах, пишем её в базу, при успехе отправляем запрос на сайт, подтверждающий успешную обработку заказа. После чего данный заказ пропадает из списка необработанных.
Знаете, вынужден с вами не согласиться. Да, хорошо огородиться и каждому барахтаться в своей песочнице. Но кто-то ведь должен всё это контролировать, искать правильные архитектурные решения, а для этого необходимо знать, как минимум основы всех частей системы.
На сайте и есть счётчик сообщений, и в админке видна полная статистика, вплоть до того сколько и когда изменилось.
Если скрипт рухнет в момент обработки, то он не удалит архив с сообщением и при следующем запуске попробует вновь, т.е. данные утеряны не будут.
Складывать в xml картинки смысла было мало. Боюсь, что php-скрипт, который вытаскивает их из xml и сохраняет поштучно, будет работать медленнее, нежели вызываемая внешняя утиль, специально заточенная под подобные операции. Но соглашусь с вами, действительно как вариант это можно иметь ввиду. Спасибо.
Если этот кастомный шрифт нужен абы был, то тогда незачем его вообще лепить.
Да, вот и приходится менять макет в таком случае. Но ведь на первоначальном, нарисованном макете эта ошибка для не-верстальщика не очевидна.
Вот попробуйте сейчас нарисовать любую аброкадабру (такую, которую нельзя взять и оборвать в произвольной точке), скажем 123 пикселя. А потом сверстайте блок, который должен тянуться.
Во-первых, как он спасёт от проблемы описанной в моём предыдущем комментарии, а во-вторых, как много браузеров его понимают?
Но ведь нужна кроссбраузерная вёрстка.
А вот шрифты… попробуйте сейчас сверстать под все IE с нестандартным шрифтом. А сглаживание? Эх…
Вы сами верстальщик и должны понимать, что подпирание вёрстки JS-костылями не допустимо. Да, бывают исключительные ситуации, когда совсем баста и для идеала такой костыль приставляется, но в любом случае это решение грязное.
Привожу банальный пример. Есть макет, в нём блок. Блок должен тянутся по вертикали. Но по бордюру блок обрамлён узором. Когда дизайнер нарисовал макет и подогнал внутри текст под высоту кратного узора — всё выглядит супер. Но сразу проблема как это сверстать? Если подкладывать картинку бэкграундом — то узор будет разрываться. Подпирать костылём? Хорошо, подопрём. Допустим узор 100 пикселей в высоту. Блок у нас в высоту должен быть 120 пикселей. Получается, что костылём нам нужно вытянуть блок до 200 пикселей, чтобы узор не оборвался? В итоге имеем жуткие 80 пикселей пустого места. А если узор пикселей на 200-250?
А такая ситуация очень распространена. Дизайнер привык рисовать буклеты/плакаты и прочую полиграфию и для него невдомёк, что блок может тянутся.
И это всего лишь один из банальнейших примеров.
И совсем другое дело примеры приведённые в статье. Мы видим банальную некомпетентность верстальщика. Если дизайнер поставил свой цвет ссылок, то такой он и должен оказаться после вёрстки. А если верстальщик самовольно внёс изменения в макет, то му просто нужно отбивать за это руки. И эти ошибки видны моментально. Заказчик просто вправе не принять такую работу.
Думаю, что скоро будет проект, где как раз и будет синхронизация покупателей, выгрузка скидок, заказов, детали обработки заказов и тд.
Да, сначала я тоже задумывался о делении на части, но потом несколько раз попробовал сделать полную, начальную выгрузку. Всё выгрузилось и обработалось на сервере без сбоев. А уж частичное обновление и подавно работает.
Но, да, при больших размерах обмена, действительно стоило бы делить данные на части. Спасибо, за замечание.
1С стучится, по указанному URL, где выводится список новых, необработанных заказов. Далее парсим 1С'кой информацию о новых заказах, пишем её в базу, при успехе отправляем запрос на сайт, подтверждающий успешную обработку заказа. После чего данный заказ пропадает из списка необработанных.
Если скрипт рухнет в момент обработки, то он не удалит архив с сообщением и при следующем запуске попробует вновь, т.е. данные утеряны не будут.
Складывать в xml картинки смысла было мало. Боюсь, что php-скрипт, который вытаскивает их из xml и сохраняет поштучно, будет работать медленнее, нежели вызываемая внешняя утиль, специально заточенная под подобные операции. Но соглашусь с вами, действительно как вариант это можно иметь ввиду. Спасибо.