А по-моему, интересная вещь. Можно сделать оффлайн приложение, например, на JS. Калькулятор, редактор, да много интересных вещей. Пользователь всегда может что-то сделать даже при отсутсвии интернета.
И это в том числе. Это было основное из-за чего я перебрался на jQuery. Неудобно работать с результатами работы селекторов, из-за этого код получался громоздким.
Ещё можно поработать над перфомансом, он ощутимо хромает.
В любом случае работать всегда есть над чем.
Думаете бесполезно ждать?
Ну неужели! Я уже думал не дождусь, даже успел на jquery перейти.
Всё-таки мне прототайп синтаксисом не нравиться, посмотрим может в будущем позитивные изменения будут.
Я вас понял, тем не менее, микроформаты помогут в любом случае.
В независимости от того как выглядят данные на вашем сайте, можно распарсить их и вывести в нужном вам формате. Например, собрать все емайлы или телефоны. Поисковики, например, могут писать контактную информацию рядом со строкой результата.
Или браузер выводить в красивом окошке.
Если не ошибаюсь для FF есть плугин, которые сообщает вам об используемых на сайте микроформатах.
Микроформаты призваны помочь в этом деле.
Но необходимо их повсеместное использование и понимание поисковиками или браузерами.
Причем первое намного сложнее, тем более в таком секторе, как в вашем примере.
Вроде это не так давно было.
Сейчас с оперой хоть и есть проблемы, но не такие как 6 лет назад. Можно было переписать код, судя по всему не мелкая компания.
Недавно цеплял похожий вирус. Пару дней не мог понять откуда берутся записи в файлах с iframe на сайте. Потом понял, что похоже это с моего компьютера, поменял пароли на фтп, запустил все антивирусы, вроде истребил. Но с тех пор FTP под Windows не пользуюсь.
Представляю )
Но делать сайты на 100% от ширины экрана надо уметь, иначе можно получить плохо читаемый и понимаемый контент.
Не вижу ничего плохого ни в фиксированных, ни в резиновых сайтах. Просто и то и другое надо делать с умом.
Предпочитаю делать плавающую ширину с ограничениями по максимальной и минимальной ширине, если нет других условий по дизайну.
Я вас понял)
Просто сам когда-то учился на таких постах и понимаю, что некоторые просто могут взять в привычку именовать так классы, а осознание что это не гут придет только с опытом.
Не сочтите за занудство, но именование классов типа .form-w-300 — порочная практика.
Перед названием класса я всегда задаю себе вопрос — изменится ли это название класса, если поменяются его свойства. То есть, если завтра вы захотите сделать эту форму в 350px вам придется либо менять класс, либо вводить в заблуждение верстальщиков (а может и вас самого), которые возможно будут править ваш CSS.
Я делал также раньше, смотря на подобные примеры, пока на собственном опыте не убедился в порочности такой практики.
Можно ведь написать что-то типа #login {width:300px;}.
С таблицами будет не так?
Вообще говоря это дело верстальщика, не нужно делать форму на 100% от экрана.
В приведенных вами случаях нет никаких преимуществ таблиц над дивами.
Почему же, я кое-где, например, использую ширину в 35% для лейблов, то есть всё тянется и занимает не половину экрана, а 35% от родительского элемента.
Опять же по этим 35% удобно выравнивать другие элементы (кнопки, подсказки и т.д.).
P.S. В примере sprawsm.com/uni-form/ label шириной 45%.
Uni-From (http://sprawsm.com/uni-form/)
Все примеры из реальной жизни решал или с помощью Uni-From с небольшими допиливаниями или с помощью своих CSS без таблиц.
Ещё можно поработать над перфомансом, он ощутимо хромает.
В любом случае работать всегда есть над чем.
Думаете бесполезно ждать?
Всё-таки мне прототайп синтаксисом не нравиться, посмотрим может в будущем позитивные изменения будут.
А за статью спасибо, будем надается не пригодится)
В независимости от того как выглядят данные на вашем сайте, можно распарсить их и вывести в нужном вам формате. Например, собрать все емайлы или телефоны. Поисковики, например, могут писать контактную информацию рядом со строкой результата.
Или браузер выводить в красивом окошке.
Если не ошибаюсь для FF есть плугин, которые сообщает вам об используемых на сайте микроформатах.
Но необходимо их повсеместное использование и понимание поисковиками или браузерами.
Причем первое намного сложнее, тем более в таком секторе, как в вашем примере.
Сейчас с оперой хоть и есть проблемы, но не такие как 6 лет назад. Можно было переписать код, судя по всему не мелкая компания.
Есть рекомендации и советы.
Но делать сайты на 100% от ширины экрана надо уметь, иначе можно получить плохо читаемый и понимаемый контент.
Не вижу ничего плохого ни в фиксированных, ни в резиновых сайтах. Просто и то и другое надо делать с умом.
Предпочитаю делать плавающую ширину с ограничениями по максимальной и минимальной ширине, если нет других условий по дизайну.
Просто сам когда-то учился на таких постах и понимаю, что некоторые просто могут взять в привычку именовать так классы, а осознание что это не гут придет только с опытом.
Перед названием класса я всегда задаю себе вопрос — изменится ли это название класса, если поменяются его свойства. То есть, если завтра вы захотите сделать эту форму в 350px вам придется либо менять класс, либо вводить в заблуждение верстальщиков (а может и вас самого), которые возможно будут править ваш CSS.
Я делал также раньше, смотря на подобные примеры, пока на собственном опыте не убедился в порочности такой практики.
Можно ведь написать что-то типа #login {width:300px;}.
Вообще говоря это дело верстальщика, не нужно делать форму на 100% от экрана.
В приведенных вами случаях нет никаких преимуществ таблиц над дивами.
Опять же по этим 35% удобно выравнивать другие элементы (кнопки, подсказки и т.д.).
P.S. В примере sprawsm.com/uni-form/ label шириной 45%.
Все примеры из реальной жизни решал или с помощью Uni-From с небольшими допиливаниями или с помощью своих CSS без таблиц.