С непривычки она наоборот усложняет поддержку, но иначе никак комбинацию четырёх логических маргинов не записать:
/* это margin: a b c d */
margin-top: a;
margin-right: b;
margin-bottom: c;
margin-left: d;
/* а это margin: logical a d b c*/
margin-block-start: a;
margin-inline-start: d;
margin-block-end: c;
margin-inline-end: b;
С мультиязычностью данных. У нас одна страна — один язык данных. В некоторых случаях интерфейс доступен на нескольких языках, но сами данные (наполнение карточек, карта, язык поиска и т.д.) только на одном.
Это больше стратегический проект с явными, но не измеримыми как деньги/MAU, долгосрочными целями. Понимали нарастающую необходимость при общении с партнёрами, а поводом к старту разработки были именно какие-то конкретные договорённости, не могу точно сказать. В результате, как и ожидалось, заметно повысилась узнаваемость, стало легче договариваться с местными властями и бизнесом, и т.д.
Да, это решит проблему с выделением текста и навигацией по коду. Но кажется будет ещё сложнее сопоставить код и его реальное отображение в браузере.
И это не избавит от писем вроде «ребята, в этом адресе [арабский_текст_с_цифрой_слева] номер дома должен идти в конце строки». А он вроде и так в конце, строка же читается справа налево. А оказывается, что в LTR почтовом клиенте цифра в начале (слева) потому что она реально в начале строки, и в RTL контексте она окажется тоже в начале (справа). Брр!
Да, 2ГИС — это про точность данных, многое заботливо собирается и выверяется руками. Если это убрать, у такого сервиса с 2ГИС общей будет только графическая оболочка — никаких конкурентных преимуществ в плане точности, никакой любви пользователей, рекламодателей и т.д. Это сильно заметно, когда у нас в каком-нибудь регионе появляются проблемы с актуальностью информации — сервис остаётся приятным и привычным, но без 100% доверия к данным это ну совсем не то.
Да, почти всех зацепило — до этого у нас не было проектов с мультиязычностью данных. Внутренние продукты, хранилища данных, почти все API, поиск проезда, рендеринг тайлов карты, и т.д. Получился такой крутой повод сделать наконец большой шаг к настоящей мультиязычности.
В плане организации работы — как обычная, просто очень большая, задача с нечёткими требованиями. Что-то улучшили, слили (так чтобы эти изменения не ломали английскую версию), отдали арабским коллегам на ревью, получили фидбек. И так несколько месяцев. Проблема «то ли верно, то ли бред» — да, от этого больнее всего было. Особенно искать, на чьей стороне проблема, когда например в почтовом клиенте (LTR) текст выглядит не так, как в итоге на сайте (RTL), но оба варианта на первый взгляд — почти одинаковые закорючки.
Экономическая целесообразность тут у каждого своя. В случае 2ГИС это вклад даже не столько в увеличение активной аудитории, сколько в узнаваемость бренда среди пользователей и потенциальных партнёров, т.к. качественных арабских сервисов почти нет. Можно назвать это персональным подходом. И на данный момент о затраченных усилиях ничуть не жалеем.
Вот специальный отдел разработки арабской версии создавать для нас было бы точно слишком сложно и дорого. Это же я тут только проблемы с фронтендом описываю, а за ним стоят ещё десятки команд. Плюс к этому, огромную работу провёл именно наш дубайский офис, все вместе переводили и помогали адаптировать. Без них бы вряд ли что-то хорошее смогло выйти.
Зато после единовременной адаптации все новые фичи достаются всем локальным версиям условно бесплатно — перевёл, вёрстку проверил, зарелизил.
Но если нет особых предпочтений, зачем например брать jsRender, который если верить тесту — проигрывает остальным?
Надо прикинуть, нужен ли embedded javascript, посмотреть простоту рендера тех же шаблонов на сервере (если нужно), размеры и активность сообществ, качество документации, количество зависимостей и выбрать в итоге то, что больше подходит для поставленных целей. Только полный обзор может сказать, что какой-нибудь jsRender проигрывает остальным.
Тест на jsperf как раз и показывает, что разницы нет. Не должен какой-то мнимый выигрыш в скорости быть критерием выбора шаблонизатора (оговорюсь: если задача — рендерить по 1000 шаблонов на каждой странице, и не должно тормозить на android 2.1, то на скорость шаблонизатора можно смотреть. Но всё равно адски тормозить при этом будет не рендер шаблонизатора).
Основная проблема реализации – всплывающее окно из iframe перекрывающее по высоте родителя. На своём сайте можно спокойно вызвать Modal через parent iframe’а, но в данном случает домен у iframe другой и браузер будет защищаться.
Но ведь с помощью postMessage можно послать те же данные в parent, поймать на той стороне сообщение и показать тот самый Modal так же спокойно, или я ошибаюсь? Рассматривался такой вариант? Плюсы — баннер не меняет размер, минусы — нужно тщательно защищать стили модального окна от переопределения их стилями сайта партнёра.
.load — это навешивание обработчика на событие 'load' в данном контексте. Сначала вешаем обработчики, потом загружаем изображение (присваивая значение imgsrc атрибуту src).
Мой вам совет — не стесняйтесь упрощать себе разработку с помощью инструментов, созданных сообществом.
Я считаю их подключение лишним. Они «толстые». Для единичных проблем не имеет смысла подключать большую библиотеку
Как раз лишнее — это долго возиться с элементарными вещами и реализовывать их далеко не оптимальными способами. Те же jQuery и Bootstrap на этапе освоения веб-разработки помогут сделать сайт (и внешне, и внутренне) менее «страшненьким».
Хотя почему хром себя так неоднозначно ведёт — вопрос. Вот наглядный пример, когда при первоначальной отрисовке получается одно, а при перерисовке — озвученная выше ситуация: http://thican.net/~camusensei/chromium_bug/floatProblem.html (надо дважды кнопку нажать)
С непривычки она наоборот усложняет поддержку, но иначе никак комбинацию четырёх логических маргинов не записать:
И это не избавит от писем вроде «ребята, в этом адресе [арабский_текст_с_цифрой_слева] номер дома должен идти в конце строки». А он вроде и так в конце, строка же читается справа налево. А оказывается, что в LTR почтовом клиенте цифра в начале (слева) потому что она реально в начале строки, и в RTL контексте она окажется тоже в начале (справа). Брр!
В плане организации работы — как обычная, просто очень большая, задача с нечёткими требованиями. Что-то улучшили, слили (так чтобы эти изменения не ломали английскую версию), отдали арабским коллегам на ревью, получили фидбек. И так несколько месяцев. Проблема «то ли верно, то ли бред» — да, от этого больнее всего было. Особенно искать, на чьей стороне проблема, когда например в почтовом клиенте (LTR) текст выглядит не так, как в итоге на сайте (RTL), но оба варианта на первый взгляд — почти одинаковые закорючки.
Вот специальный отдел разработки арабской версии создавать для нас было бы точно слишком сложно и дорого. Это же я тут только проблемы с фронтендом описываю, а за ним стоят ещё десятки команд. Плюс к этому, огромную работу провёл именно наш дубайский офис, все вместе переводили и помогали адаптировать. Без них бы вряд ли что-то хорошее смогло выйти.
Зато после единовременной адаптации все новые фичи достаются всем локальным версиям условно бесплатно — перевёл, вёрстку проверил, зарелизил.
[href*=dejurka]через adblock или user styles.Надо прикинуть, нужен ли embedded javascript, посмотреть простоту рендера тех же шаблонов на сервере (если нужно), размеры и активность сообществ, качество документации, количество зависимостей и выбрать в итоге то, что больше подходит для поставленных целей. Только полный обзор может сказать, что какой-нибудь jsRender проигрывает остальным.
Но ведь с помощью postMessage можно послать те же данные в parent, поймать на той стороне сообщение и показать тот самый Modal так же спокойно, или я ошибаюсь? Рассматривался такой вариант? Плюсы — баннер не меняет размер, минусы — нужно тщательно защищать стили модального окна от переопределения их стилями сайта партнёра.
Failed to load resource: the server responded with a status of 404 (Not Found)
http://alpha.hstor.org/storage/habramedia/images/thumbs/avatars/29/90/08/110549/small_110549.jpg
эквивалентен этому
.load— это навешивание обработчика на событие 'load' в данном контексте. Сначала вешаем обработчики, потом загружаем изображение (присваивая значение imgsrc атрибуту src).Как раз лишнее — это долго возиться с элементарными вещами и реализовывать их далеко не оптимальными способами. Те же jQuery и Bootstrap на этапе освоения веб-разработки помогут сделать сайт (и внешне, и внутренне) менее «страшненьким».
Вот что происходит в таких случаях: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Visual_formatting_model#Anonymous_block_boxes
Хотя почему хром себя так неоднозначно ведёт — вопрос. Вот наглядный пример, когда при первоначальной отрисовке получается одно, а при перерисовке — озвученная выше ситуация: http://thican.net/~camusensei/chromium_bug/floatProblem.html (надо дважды кнопку нажать)