В том то и дело, что мобильный сафари — та еще коробка с сюрпризами. Остается надеяться, что браузерные движки идентичны.
Но на доверии вот, к сожалению, далеко не уйдешь. Еще одного сета тестов это не отменяет.
Ясно. Просто вы, видимо, мало сталкивались с научной деятельностью, поэтому ясной терминологии у вас нет. То, что вы говорите это не структура знаний, а способы работы с ними. Знание
Интересная идея. Её можно было-бы развить — сразу евалить django-like шаблоны, заполняя фейковыми данными. Это бы избавило от лишнего шага в разработке — верстки, позволив сверстанный темплейт сразу подключать на настоящие данные. Помимо этого, каждый раз можно было-бы видеть живые данные, вместо статического lorem ipsum.
Я как-то начал, но не закончил.
Вы уж извините, но у вас весьма специфичный американизированный жаргон. Некоторым он может показаться даже неприятным, как минимум — странным. Почему-бы не использовать русские простые термины взамен?
Удобное время для собеседований
Зарплаты или финансовые возможности
задействовать в работе на 100%
рынок труда
сделайте «домашнюю работу», или предварительную работу
Спасибо за статью, есть интересные подходы, в частности, отсутствие блока подсказки как такового.
Но несколько нюансов.
1. Как отрегулировать задержку появления и исчезновения? Показанный случай лишь частность, уступает стандартным тултипам.
2. Чтобы можно было сделать обводку со скруглением (border-radius, box-shadow) вокруг подсказки, tip возможно имело смысл делать не через треугольник бордера, а через поворот (rotation) блока?
3. Подсказки могут уходить за пределы видимости окна, что вообще стоило бы учитывать.
4. Что, если хочется сделать появления тултипа анимированным, хотя-бы фейдом?
5. Что делать с контентом, который хочется отформатировать внутри подсказки?
Да, действительно, такое в програмимровании есть, и действительно на чужом коде можно учиться. Еще можно учиться, участвуя в OpenSource-проекте, пытаясь написать свой проект, или по книгам, или в команде, или экспериментируя, или еще каким угодно другим способом.
Не совсем понял, как это относится к опыту, изложенному в первом комментарии. Если вы подразумевали, что я не пытался читать чужой код — вы крайне неправы. Вообще именно об этом я и написал. Код на LS местами ментальная бомба и набор бессвязных символов, а все — за счет чрезмерной краткости вкупе с неоднозначностью.
Пытался пересесть на CoffeeScript, а затем на LiveScript — развитие Coffee — не пошло: времени на поиск наиболее удачной записи той или иной конструкции стало убиваться в разы больше, банальные вещи (типа запуска функции без аргументов) надо гуглить, появились сомнения, хорошо ли написано то или иное. В JS такой проблемы нет: как делать те или иные вещи вопросов или сомнений не возникает, код пишется гладко. Более того, некоторые особенно лаконичные решения на LS при прочтении выглядят как каша, могут взрывать мозг на ходу. Одни и те же нотации используются для разных вещей.
Считаю, что в языке главное не краткость записи, а интуитивность, самоочевидность и поддерживаемость. Если компилятор не предлагает принципиально новых решений, а только сокращает нотацию, то особенной выгоды в нем не будет, если посмотреть на это честно, прагматично и сосчитать реальную выгоду/издержки. Важно не то, насколько сократился код и насколько в нем стало меньше символов, а распространенность решений, степень уверенности, с которой можно полагаться на эти решения и удобство работы/отладки. Хорошо, если через пару лет откроешь код, и поймешь, что он написан качественно, понятно и по хорошим практикам. Плохо, если откроешь через пару лет код, и поймешь, что теперь не понимаешь как это работает и вообще этот язык больше не поддерживается.
Но на доверии вот, к сожалению, далеко не уйдешь. Еще одного сета тестов это не отменяет.
Знание
Прочитал. Причем тут структура знаний?
По всей видимости нет. Рановато пока на него переходить.
Я как-то начал, но не закончил.
Вы уж извините, но у вас весьма специфичный американизированный жаргон. Некоторым он может показаться даже неприятным, как минимум — странным. Почему-бы не использовать русские простые термины взамен?
Приятно и без запинок.
Но несколько нюансов.
1. Как отрегулировать задержку появления и исчезновения? Показанный случай лишь частность, уступает стандартным тултипам.
2. Чтобы можно было сделать обводку со скруглением (border-radius, box-shadow) вокруг подсказки, tip возможно имело смысл делать не через треугольник бордера, а через поворот (rotation) блока?
3. Подсказки могут уходить за пределы видимости окна, что вообще стоило бы учитывать.
4. Что, если хочется сделать появления тултипа анимированным, хотя-бы фейдом?
5. Что делать с контентом, который хочется отформатировать внутри подсказки?
Не совсем понял, как это относится к опыту, изложенному в первом комментарии. Если вы подразумевали, что я не пытался читать чужой код — вы крайне неправы. Вообще именно об этом я и написал. Код на LS местами ментальная бомба и набор бессвязных символов, а все — за счет чрезмерной краткости вкупе с неоднозначностью.
Считаю, что в языке главное не краткость записи, а интуитивность, самоочевидность и поддерживаемость. Если компилятор не предлагает принципиально новых решений, а только сокращает нотацию, то особенной выгоды в нем не будет, если посмотреть на это честно, прагматично и сосчитать реальную выгоду/издержки. Важно не то, насколько сократился код и насколько в нем стало меньше символов, а распространенность решений, степень уверенности, с которой можно полагаться на эти решения и удобство работы/отладки. Хорошо, если через пару лет откроешь код, и поймешь, что он написан качественно, понятно и по хорошим практикам. Плохо, если откроешь через пару лет код, и поймешь, что теперь не понимаешь как это работает и вообще этот язык больше не поддерживается.
background-position:0 bottom
, и всё хорошо.