Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 145
мелочь, а приятно :)
блочность тут не при чем, скорее ради логики. Логично, что плавающий элемент на странице будет абсолютным. По поводу анахронизма можно долго спорить. Тут, скорее, на вкус и цвет. С моей точки зрения не комильфо назначать идентификаторы неиспользуемым элементам. Тем более, когда для их обозначения есть другие возможности. Все равно для данного примера потребуется плавающий элемент.
>Вообще есть мнение, что якоря через — анахронизм.
А почему?
А почему?
Наверное, потому что можно сделать, например,…
А в url написать someurl/#someid
А в url написать someurl/#someid
Наверное, потому что можно сделать, например,
А в url написать
<div id="someid">…</div>
А в url написать
http://someurl/#someid
В HTML5 атрибут «name» у тэга «a» no longer allowed :-)
Так что еще не совсем анахронизм, но уже вот-вот.
Так что еще не совсем анахронизм, но уже вот-вот.
блин молодчина! мелочь не мелочь а приятней стало.
(микро-эволюция)
(микро-эволюция)
>Вообще есть мнение, что якоря через — анахронизм.
Отлично! мелочь, а удобство сёрфинга повышается -)
А ещё напрягают якоря внизу страницы.
Страница прокручивается до упора, а то место в котором «должен быть» якорь попадает куда бог пошлёт.
И не понятно где этот якорь должен быть, а в браузерах нет никакой подсветки.
А ещё напрягают якоря внизу страницы.
Страница прокручивается до упора, а то место в котором «должен быть» якорь попадает куда бог пошлёт.
И не понятно где этот якорь должен быть, а в браузерах нет никакой подсветки.
Подсветки нету по умолчанию, однако её можно добавить через CSS посредством «:target».
Вот пример нагляднейший:
www.twisty.com/misc/tests/css/target-trick.html
Вот пример нагляднейший:
www.twisty.com/misc/tests/css/target-trick.html
класс =) если бы еще IE его понимал =)
IE приветливо глупо улыбается, как обычно ;-)
Супер! Не знал. Спасибо.
Если бы еще разработчики стали использовать этот псевдокласс, сайты стали бы удобнее.
Если бы еще разработчики стали использовать этот псевдокласс, сайты стали бы удобнее.
Движок MediaWiki его использует, например.
А это значит — и Википедия, и Традиция, и Антикопирайт, и Люркмор.
Кроме того (как на www.habrahabr.ru/blogs/km/60294/ объяснялося), бывают также и корпоративные вики, а не только общественные.
А это значит — и Википедия, и Традиция, и Антикопирайт, и Люркмор.
Кроме того (как на www.habrahabr.ru/blogs/km/60294/ объяснялося), бывают также и корпоративные вики, а не только общественные.
Пропишите пользовательский стиль и не ждите милости от сайтовладельцев.
проверил, даже хвалёная 8-ая версия IE не видит этих псевдоклассов =(
Да уж, всем подсветкам подсветка...)
id forever! (по сабжу)
radikal must die! (по фотохостингу)
radikal must die! (по фотохостингу)
объясните мне, колхознику, чем id в данном примере лучше name.
кем? или чем? по крайней мере name="…" позволяет использовать интовые значения, тогда как id должен начинаться не с цифры
Ну я даже больше скажу: можно использовать кириллицу, правда, Opera её не понимает, но тем не менее
причем тут кирилица? Код в духе /> не валидный, тогда как /> легко проходит валидацию.
только что проверил: код <a name='лепота'></a> так же, как и код <div id='красота'>… — проходит валидацию.
понимает. просто нужно урлкодирование
Ну опять же, элементу с id можно сделать margin, padding в стационарном режиме, не прибегая к каким-то трюкам. Это во-первых. Во-вторых, не нужно «плодить» лишние элементы. А в-третьих Вам уже озвучили.
во-первых, где тут трюк? Во-вторых, повторяю третий раз =)) для того, чтобы якорь был выше элемента, в любом случае придется «плодить» лишний элемент. Исключением может быть лишь наличие паддинга у элемента, что не всегда удобно. Пой пример универсален. В-третьих, сказали, и что? На заборе хуй написан.
Поймите меня верно, я против стереотипов и для меня чье-то не обоснованное заявление не является аксиомой, мне хочется разобраться. Не принимайте мои штыки близко к серду, попробуйте обоснованно отстоять свою точку зрения.
Поймите меня верно, я против стереотипов и для меня чье-то не обоснованное заявление не является аксиомой, мне хочется разобраться. Не принимайте мои штыки близко к серду, попробуйте обоснованно отстоять свою точку зрения.
опять же, с точки зрения логики для отступа лично я использую margin, соответственно якорь его не «отступает». Т.е. обойтись без моего колхозного метода можно удовлетворяя одному требованию — заранее знать, что для подобных элементов вместо margin для внешнего отступа юзать padding. Что, тоже, порой не всегда удобно. хотя в общем, если знать это заранее, верстку можно подогнать. Опять же, мой способ универсален и легко вставится в готовый проект.
Хотя в целом согласен с тем, что лишние элементы на странице в современных проектах ни к чему. Но, опять же, заглянув на лепру, где по 1000+ комментов в постах, там лишних элементов дофуя =) и ничего, работает…
Хотя в целом согласен с тем, что лишние элементы на странице в современных проектах ни к чему. Но, опять же, заглянув на лепру, где по 1000+ комментов в постах, там лишних элементов дофуя =) и ничего, работает…
потому что name — костыль из века войн браузеров. Аналогичный тому, что label в форме соответствует ID, а данные из формы отправляются по name.
Скоро браузеры разучатся понимать name, будут только ID, вот тогда и попляшем :)
Еще можно вспомнить, что getElementById ищет и элементы с name в IE…
Скоро браузеры разучатся понимать name, будут только ID, вот тогда и попляшем :)
Еще можно вспомнить, что getElementById ищет и элементы с name в IE…
костыль, это когда вы ногу сломали и вам ходить не удобно. А name вполне себе свойство, которое живет себе до сих пор. Если на то пошло, то и тег a костыль из века войн браузеров. И все остальные теги тоже. И, уверен, бреузеры еще оооооочень долго будут понимать этот тег. Другое дело, что современные стандарты html и xhtml будут считать эх не валидными, это уже другой разговор. Но до тех времен еще много времени. А бежать впереди паровоза… Энтони Хоар как-то сказал, что: «Преждевременная оптимизация есть корень всех зол» и это внегласное правило пока никто не отменял.
никто не заставляет бежать впереди паровоза, но зачем из него выпадать? :) Ведь все используют ID вместо NAME
У вас какое-то не полное представление о паровозе. Из паровоза выпадают те, кто пишут на сайтах «Сайт открывается только в браузерах семейства IE 5.5», но не те кто использует name. Современный сайт без ID — можно себе представить. Без name — невозможно.
что-то Вас понесло, уважаемый. Если не брать во внимание формы, то я не знаю ни одного приличного сайта, использующего name.
Возьмите хотя бы Яндекс…
Возьмите хотя бы Яндекс…
да? =) а как же тот факт, что яндекс во многом windows-1251 использует? Это не «выпадает из паровоза»?
name достаточно активное свойство, применяется не только в формах. Откройте любую страницу любого современного сайта и с вероятностью 99% хотя бы одно свойство name на странице будет.
Повторю. С моей точки зрения не комильфо назначать идентификаторы неиспользуемым элементам. Тем более, когда для их обозначения есть другие возможности.
name достаточно активное свойство, применяется не только в формах. Откройте любую страницу любого современного сайта и с вероятностью 99% хотя бы одно свойство name на странице будет.
Повторю. С моей точки зрения не комильфо назначать идентификаторы неиспользуемым элементам. Тем более, когда для их обозначения есть другие возможности.
при чем тут windows-1251? теплое с мягким? name и id равноправны для браузера, поэтому ему как-то фиолетово будет (и точки зрения производительности тоже), что вы будете ID использовать, что NAME для якорей. Просто ID обладает более интересными свойствами (как уже справедливо было отмечено ниже), в том числе, и для удобства CSS-селекторов.
Про последние можно вообще холивор разводить и отрывать тем верстальщикам руки, которые активно ID вместо классов используют. Даже если элемент единожды на страницы встречается.
Про последние можно вообще холивор разводить и отрывать тем верстальщикам руки, которые активно ID вместо классов используют. Даже если элемент единожды на страницы встречается.
win1251 был приведен в пример к вашей попытке «этанолизировать» яндекс, к якорям никакого отношения не имеет.
Думаю, для браузера есть разница, используете вы id или name для якорей. Я не знаю каким образом javascript производит выборку по id, но подозреваю, что перед выборкой он формирует индекс из идентификаторов. Есть разница, пробежаться по 20 id, или по 2020? Откройте лепру и проверьте. Какими такими свойствами волшебными обладает id? про css смешно, каждому якорю для коммента будете прописывать css?
Я уже запутался, какую точку зрения вы отстаиваете? сначала вы упорно доказывали, что нужно везде использовать id, а name устарел. Теперь говорите, что и то и то допустимо. Будь пацаном, вывози за базар.
Думаю, для браузера есть разница, используете вы id или name для якорей. Я не знаю каким образом javascript производит выборку по id, но подозреваю, что перед выборкой он формирует индекс из идентификаторов. Есть разница, пробежаться по 20 id, или по 2020? Откройте лепру и проверьте. Какими такими свойствами волшебными обладает id? про css смешно, каждому якорю для коммента будете прописывать css?
Я уже запутался, какую точку зрения вы отстаиваете? сначала вы упорно доказывали, что нужно везде использовать id, а name устарел. Теперь говорите, что и то и то допустимо. Будь пацаном, вывози за базар.
Уважаемый, где Вы видите противоречие. По пунктам пожалуйста.
По поводу «Javascript формирует индекс из идентификаторов» — почитайте, пожалуйста, мат.часть. Этим занимается браузер, а не JS-движок. И глубина проблемы тут налицо (я не поленюсь, сделаю такое же исследование по поводу NAME, как и для ID) — уникальность элементов губит на корню все доброе и полезное.
Но это мы ушли в сторону. Я же лично настаиваю на том, что использование NAME вместо ID для якорей — это прошлый век и «вообще некошерно» :)
По поводу «Javascript формирует индекс из идентификаторов» — почитайте, пожалуйста, мат.часть. Этим занимается браузер, а не JS-движок. И глубина проблемы тут налицо (я не поленюсь, сделаю такое же исследование по поводу NAME, как и для ID) — уникальность элементов губит на корню все доброе и полезное.
Но это мы ушли в сторону. Я же лично настаиваю на том, что использование NAME вместо ID для якорей — это прошлый век и «вообще некошерно» :)
перечитайте ветку ниже. Сначала вы говорите что name устарел, аргументируя это тем, что он устарел =) Потом говорите что все используют id, никто не использует name. А потом предлагаете отрывать руки верстальщикам, которые повсеместно используют id вместо name.
dom действительно строит браузер, но я почти уверен, JS в современных браузерах имеют свой быстрый индекс. В любом случае, кем бы он не был сформирован, бегать по нему JS будет проще, если id будет меньше. То что элементы уникальны — не значит, что их нужно помечать с помощью id. Посмотрите мой пример, в нем мусорный, зачем там идентификация? Ну бред же. А использовать id там только потому, что не смотря на рекомендации w3c вы по своему считаете, что name устарел, это, конечно, ваше право, но это бред. По крайней мере в этом топике.
dom действительно строит браузер, но я почти уверен, JS в современных браузерах имеют свой быстрый индекс. В любом случае, кем бы он не был сформирован, бегать по нему JS будет проще, если id будет меньше. То что элементы уникальны — не значит, что их нужно помечать с помощью id. Посмотрите мой пример, в нем мусорный, зачем там идентификация? Ну бред же. А использовать id там только потому, что не смотря на рекомендации w3c вы по своему считаете, что name устарел, это, конечно, ваше право, но это бред. По крайней мере в этом топике.
я не вижу противоречия: используйте ID вместо NAME только там, где это нужно, и не используйте NAME. И все. Единственная мысль, которую легко вывести из всего треда.
черт, придется лезть в сорсы WebKit, чтобы опровергнуть ваше заявление: индекс строит не JS, а библиотеки (кэширующие, например, Peppy или YASS). Браузер строит свой индекс и довольно шустро может отвечать JS на запросы вида getDocumentById. DOM — привелегия браузера, API для работы с DOM — JS. На стыке этого обычно и происходит наибольшие тормоза и утечки памяти. Сам JS никаких дополнительных индексов не строит.
Кто мусорный-то? Хабр съел. Если ID не нужен, не используем. Использовать вместо него NAME — идиотизм.
черт, придется лезть в сорсы WebKit, чтобы опровергнуть ваше заявление: индекс строит не JS, а библиотеки (кэширующие, например, Peppy или YASS). Браузер строит свой индекс и довольно шустро может отвечать JS на запросы вида getDocumentById. DOM — привелегия браузера, API для работы с DOM — JS. На стыке этого обычно и происходит наибольшие тормоза и утечки памяти. Сам JS никаких дополнительных индексов не строит.
Кто мусорный-то? Хабр съел. Если ID не нужен, не используем. Использовать вместо него NAME — идиотизм.
Я не силен в браузерах, по крайней мере вижу явные упущения по сравнению с вами. Но тормоза браузера при большом количестве элементов на странице видно не вооруженным глазом. Заключение о том, что ID для якорей, которых могут быть тысячи, использовать не стоит из-за мусорки, создаваемой ими в идентификаторах. Заключение логично и пришло моментально, на подсознании.
Сегодня я узнал, что некоторых использование name бесит чуть не до пены у рта =) А так же узнал, что w3c не запрещает использование name, не говорит что это устаревшее свойство и даже наоборот — рекомендует его использование.
Сегодня я узнал, что некоторых использование name бесит чуть не до пены у рта =) А так же узнал, что w3c не запрещает использование name, не говорит что это устаревшее свойство и даже наоборот — рекомендует его использование.
IE8 повесился на том же количестве name, что id. NAME в нем на три порядка хуже:
webo.in/tests/css-efficiency-7/
Остальные для NAME показывают результаты не лучше, чем для ID (FX3 чуть хуже, Chrome2/Safari3/Opera10 все равно быстро).
IE6&7 для каждого NAME вместо ID показывает выигрыш в ~3,5мс.
В общем, ситуация спорная, но я от своих рекомендаций не отступаюсь: IE6/7 — прошлый век, на них нельзя ориентироваться при разработке.
P.S. небольшое пояснение:
id/name — на страницах по 10к элементов
id-clean/name-clean — на страницах только указанное (50...10000) количество элементов.
P.P.S еще статье по теме:
webo.in/articles/habrahabr/19-css-efficiency-tests/
webo.in/articles/habrahabr/25-css-efficiency-tests-2/
webo.in/articles/habrahabr/38-css-efficiency-tests-3/
webo.in/articles/habrahabr/53-semantic-dom-tree/
+ рекомендую почитать дискуссию в блоге Steve Souders
www.stevesouders.com/blog/2009/06/18/simplifying-css-selectors/
P.P.P.S. не стоит регулярно писать, что Вы узнаете много нового — а то народ подумает, что Вы вообще ничего не знаете :)
webo.in/tests/css-efficiency-7/
Остальные для NAME показывают результаты не лучше, чем для ID (FX3 чуть хуже, Chrome2/Safari3/Opera10 все равно быстро).
IE6&7 для каждого NAME вместо ID показывает выигрыш в ~3,5мс.
В общем, ситуация спорная, но я от своих рекомендаций не отступаюсь: IE6/7 — прошлый век, на них нельзя ориентироваться при разработке.
P.S. небольшое пояснение:
id/name — на страницах по 10к элементов
id-clean/name-clean — на страницах только указанное (50...10000) количество элементов.
P.P.S еще статье по теме:
webo.in/articles/habrahabr/19-css-efficiency-tests/
webo.in/articles/habrahabr/25-css-efficiency-tests-2/
webo.in/articles/habrahabr/38-css-efficiency-tests-3/
webo.in/articles/habrahabr/53-semantic-dom-tree/
+ рекомендую почитать дискуссию в блоге Steve Souders
www.stevesouders.com/blog/2009/06/18/simplifying-css-selectors/
P.P.P.S. не стоит регулярно писать, что Вы узнаете много нового — а то народ подумает, что Вы вообще ничего не знаете :)
ie6&7 может и прошлый век, но до сих пор их общая доля составляет 40%, что, согласитесь, не мало. И забивать на них при разработке пока не получается.
За тест спасибо, но он не отражает почти ничего, т.е. мы увидили сколько времени требуется на генерацию подобной страницы, а не на работу с ней. Буду благодарен, если ты напишешь подобный текст. Сначало создание документа, а потом выборка из него по кокретному id столько-то раз, интересно посмотреть, действительно ли браузеру пофиг какой у него пул id.
p.s. я ничего не знаю и регулярно узнаю очень много нового.
За тест спасибо, но он не отражает почти ничего, т.е. мы увидили сколько времени требуется на генерацию подобной страницы, а не на работу с ней. Буду благодарен, если ты напишешь подобный текст. Сначало создание документа, а потом выборка из него по кокретному id столько-то раз, интересно посмотреть, действительно ли браузеру пофиг какой у него пул id.
p.s. я ничего не знаю и регулярно узнаю очень много нового.
я рад за Вас. Читайте больше хороших и умных статей — может быть, тупых вопросов станет меньше. Статьи ведь, в основном, для таких, как Вы, пишутся.
а ведь я никого ни о чем в данной теме не спрашивал, я предложил свое решение проблемы. Причем, я не заставляю никого использовать <a name="">, замените в статье это на <span id=""> и будьте счастливы. a name мой, обоснованный, выбор. Вы же и еще с десяток человек пытаетесь учить меня и окружающих якобы «правильным» манерам, сами же доказывая, что разницы между name и id нет, но и сами же доказываете, что name применять нельзя.
опять вы смешиваете все в одну кучу. Я как представитель русского крыла движения в поддержку веб-стандартов выступаю против устаревших практик использования элементов на странице. Если вам нужен якорь — сделайте ID, ничего при этом не потеряете.
Вы же пытаетесь доказать свою правоту, усиленно при этом подчеркивая, что ничего не знаете. Это уже пахнет каким-то психическим расстройством :)
Вы же пытаетесь доказать свою правоту, усиленно при этом подчеркивая, что ничего не знаете. Это уже пахнет каким-то психическим расстройством :)
Думаю, для браузера есть разница, используете вы id или name для якорей. Я не знаю каким образом javascript производит выборку по id, но подозреваю, что перед выборкой он формирует индекс из идентификаторов. Есть разница, пробежаться по 20 id, или по 2020?
Я не претендую на звание знатока javascript'а на по-вашей логике
document.getElementsByName() должен тоже строить какой-то индекс.
Яндекс использует win-1251 исключительно на тех проектах, которые серьёзно не обновлялись с тех пор, когда эта кодировка была мейнстримом. Все новые проекты, насколько мне известно, создаются в UTF.
Более того, некоторые старые проекты тоже конвертируют — где-то кажется в мае Яндекс.Маркет стал отдаваться в UTF.
Более того, некоторые старые проекты тоже конвертируют — где-то кажется в мае Яндекс.Маркет стал отдаваться в UTF.
Отдается в utf, собирается в win1251. Понятно, что подобный проект взять и перекинуть на утф — дело не для слабонервных, но все же.
Что значит «собирается в win1251»?
это значит что мой yml должен быть в win1251
Эм…
Если вы про шаблоны — то там XSL и он в UTF-8.
Если про базу — не скажу точно.
Если вы про шаблоны — то там XSL и он в UTF-8.
Если про базу — не скажу точно.
да меня не парит что у них там внутри =) я простой клиент, желающий загрузить свой yml и рубить бабло. Но мне вот уже который раз указывают пальцем на выход. На этот раз из-за того, что мой yml не в cp1251, а в утфе.
Какой нафиг YML?
Какой палец и выход, вы о чём?
Какой палец и выход, вы о чём?
яндекс маркет устроен следующим образом. Любой, имеющий интернет-магазин любых товаров может загружать их на маркет с помощью xml файла в формате yml. Этот файл парсится ботом яндекс.маркета и если все тип-топ, товар пользователя волшебным образом появляется на маркете.
Вот именно этот злополучный yml должен быть в кодировки windows-1251. Теперь ясно?
Вот именно этот злополучный yml должен быть в кодировки windows-1251. Теперь ясно?
К счастью, не довелось так глубоко копаться в Маркете. Понял, спасибо.
Дык в чем проблема, отдавайте XML файл в cp1251?
специфика проверки такова: они проверяют магазин 3 раза, т.е. есть 3 попытки пройти проверку. После чего аккаун морозится на 2 недели и у тебя есть еще 3 попытки. После чего вход в маркет уже только платный. первые 3 попытки я израсходовал глупо, но все, что они указали я поправил, честно подождал 2 недели и тут при очередной проверке мне отказывают из-за win1251 =) при этом парсер yml ошибок не выдает и уже 2 недели каждый день собирает мой yml =))) Отдать yml в win1251, поверте, проблем нет =) просто сам подход бесячий =)
> все используют ID вместо NAME
Это не аргумент. Грамотный разработчик использует то, что лучше подходит для решения конкретной задачи по объективным критериям, а не оперирует слепым «как все».
> не знаю ни одного приличного сайта, использующего name
www.w3.org/ неприличный?
Ниже прокомментировал про id vs name — они совсем не отменяют друг друга.
Это не аргумент. Грамотный разработчик использует то, что лучше подходит для решения конкретной задачи по объективным критериям, а не оперирует слепым «как все».
> не знаю ни одного приличного сайта, использующего name
www.w3.org/ неприличный?
Ниже прокомментировал про id vs name — они совсем не отменяют друг друга.
пруфлинк? :-D
Мегаплюшка =)
Тринчик, давай еще пиши заметки, как в старые добрые времена =)
Тринчик, давай еще пиши заметки, как в старые добрые времена =)
Я дико извиняюсь, но можно было бы, например, example.ru прописать в hosts, или хотя бы в фотошопе поправить текст. Неряшливо выглядят эти зачёркнутые строки на скриншотах страничек в браузере (или контактов в мессенджере =).
По теме — интересная идея =) нужно будет воспользоваться =)
По теме — интересная идея =) нужно будет воспользоваться =)
По (действующему) стандарту HTML4 <a name="xxx"> и id="xxx" равноправны и ни один из них не deprecated. Разница в том, что id должен начинаться с буквы и может содержать только [a-z0-9]. Для name такие строгие правила не действуют, например, можно использовать entities. Стандарт даже специально описывает, что если нужны более сложные якоря, то следует использовать <a name>, пруфлинк: www.w3.org/TR/REC-html40/struct/links.html#anchors-with-id (зелененьким внизу)
Действительно, в (будущем) стандарте HTML5 <a name> отменен. Но в нем и правила для id ослаблены (может содержать любые символы, необязательно уникальный).
Но в данный момент единственный способ иметь сложные якоря и соответствовать стандарту — использовать name (то что валидатор w3c пропускает невалидные id — баг).
Действительно, в (будущем) стандарте HTML5 <a name> отменен. Но в нем и правила для id ослаблены (может содержать любые символы, необязательно уникальный).
Но в данный момент единственный способ иметь сложные якоря и соответствовать стандарту — использовать name (то что валидатор w3c пропускает невалидные id — баг).
Отличный адрес в шаблоне браузера. Клиентам дизайн так же уходит? :)
Создавать лишний пустой элемент только для якоря — несусветная древняя глупость.
Всё равно, что отступы отбивать BR'ами.
Всё равно, что отступы отбивать BR'ами.
Долго мотал читал комментарии выше, удивлялся, почему никто раньше этого не написал.
Если почитать ещё парочку комментариев, то можно подивиться точке зрения «это разрешено в HTML 4.01, значит именно так и нужно ставить якоря».
synthesis выше кинул замечательный линк, www.w3.org/TR/REC-html40/struct/links.html#anchors-with-id, где черным по белому, а потом зеленым по белому написано, что применять можно и то и другое, что id обладает своими плюсами и минусами, а name своими.
Для себя я выбрал, я хотел, чтобы якорь был целочисленным, этого можно добиться двумя путями, a name="" и валидная верстка, span id="" и не валидная верстка. Вы имеете свое мнение по этому поводу, которое расходится с w3c, ну что же, это ваше право. Но тогда и не удивляйтесь так, когда вам перечат.
Для себя я выбрал, я хотел, чтобы якорь был целочисленным, этого можно добиться двумя путями, a name="" и валидная верстка, span id="" и не валидная верстка. Вы имеете свое мнение по этому поводу, которое расходится с w3c, ну что же, это ваше право. Но тогда и не удивляйтесь так, когда вам перечат.
Я использую в работе XHTML 1.0, уже делаю некоторые вещи при помощи HTML 5 — везде атрибут
name либо deprecated, либо removed. Поэтому я просто не могу вас понять — как и вы меня со своим HTML 4.01.XHTML 1.0, уважаемый, поддерживает name полностью.
validator.w3.org/check?uri=http%3A%2F%2Fwww.w3.org%2FTR%2Fxhtml1%2F&charset=(detect+automatically)&doctype=Inline&group=0
Да, в спецификации написано, что в следующих версиях он будет deprecated, а id в свое время получит расширенные значения, в том числе целочисленные.
validator.w3.org/check?uri=http%3A%2F%2Fwww.w3.org%2FTR%2Fxhtml1%2F&charset=(detect+automatically)&doctype=Inline&group=0
Да, в спецификации написано, что в следующих версиях он будет deprecated, а id в свое время получит расширенные значения, в том числе целочисленные.
Note that in XHTML 1.0, the name attribute of these elements is formally deprecated, and will be removed in a subsequent version of XHTML.Кажется мы по-разному понимаем значение слова «formally».
видимо по разному, не знаю как вы его понимаете, но я воспринимаю его в данном контексте как «типа». Ибо в DTD свойство name для тега a описано без всяких пометок.
www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
Посоветовался с англоязычными коллегами.
Получается, что «formally» — это «официально», т.е. атрибут помечен как нежелательный. Мне кажется, что употреблять в спецификации обороты «типа» и «какбе» — это чревато проблемами )
Впрочем, какая разница. Я никогда не читал спецификацию безропотно, как библию. У меня есть своя голова на плечах, у вас тоже. Нравится name с интами — расслабьтесь и получайте удовольствие.
Давайте уже закругляться с дискуссией.
Получается, что «formally» — это «официально», т.е. атрибут помечен как нежелательный. Мне кажется, что употреблять в спецификации обороты «типа» и «какбе» — это чревато проблемами )
Впрочем, какая разница. Я никогда не читал спецификацию безропотно, как библию. У меня есть своя голова на плечах, у вас тоже. Нравится name с интами — расслабьтесь и получайте удовольствие.
Давайте уже закругляться с дискуссией.
о, ура. наконец-то вы приняли мою позицию, именно это я и хочу донести вот уже хрен знает сколько времени — мне нравится name с интами, именно поэтому я применяю именно его.
Если углубиться дальше в formally в спецификации то скорее всего мы придем к тому, что formally deprecated там стоит для того, что отучить от name, т.к. от него будут отказываться в последующий версиях. Но не потому, что он вызывает рак кишечника, верно? Про «типа» и «какбе», конечно, было вольным «переводом».
Если углубиться дальше в formally в спецификации то скорее всего мы придем к тому, что formally deprecated там стоит для того, что отучить от name, т.к. от него будут отказываться в последующий версиях. Но не потому, что он вызывает рак кишечника, верно? Про «типа» и «какбе», конечно, было вольным «переводом».
Создавать лишний пустой элемент только для якоря — несусветная древняя глупость.
Всё равно, что отступы отбивать BR'ами.
Всё равно, что отступы отбивать BR'ами.
ну, Вадим, по поводу отступов BR — а если у пользователя стили отключены, а? Какую кашу он увидит без «лишних» BR? :)
Если использовать нормальную разметку — заголовки, параграфы, списки, etc., то всё нормально.
тут можно долго спорить, но я не первый раз сталкиваюсь с дилеммой:
вводить дополнительные div для разбиение каждого input с label на «отдельную» группу как-то не хочется, но это приводит к тому что input «склеиваются» при отключенных стилях.
А со стилями, как ты понимаешь, label{display:block}, и все в ажуре.
fieldset
p
label
input
label
input
label
input
/p
/fieldsetвводить дополнительные div для разбиение каждого input с label на «отдельную» группу как-то не хочется, но это приводит к тому что input «склеиваются» при отключенных стилях.
А со стилями, как ты понимаешь, label{display:block}, и все в ажуре.
Интересно, правда, зачем здесь параграф ;)
А так — наверное такое использование BR'а не слишком зверское.
Когда идут два и больше подряд вместо отступов/полей — вот это уже клиника.
Вопрос ещё в том, кому сайт без стилей понадобился.
А так — наверное такое использование BR'а не слишком зверское.
Когда идут два и больше подряд вместо отступов/полей — вот это уже клиника.
Вопрос ещё в том, кому сайт без стилей понадобился.
Для списка полей удобно использовать ul и li, вместо p.
у меня внутри что-то переворачивается, когда я думаю о списке полей, а о списке. Не хочется мне так думать.
Но сама идея мне нравится. Хотя все равно влечет дополнительную [семантическую] разметку.
Но сама идея мне нравится. Хотя все равно влечет дополнительную [семантическую] разметку.
лейбл — это label. Даже название совпадает. Дополнительно оборачивать label в dt — это, имхо, извращение
Да, в принципе удобно, особенно когда надо какой то стиль применить например только к лейблам. Но это тот же список по сути :)
Вообще, по ходу нет нормального семантичного элемента для списка полей :(
Вообще, по ходу нет нормального семантичного элемента для списка полей :(
У нас на фирме девочка-junior совершенно шикарно решила эту дилемму:
до этого мы писали br, ибо — абзац в форме — некошерно)
<fieldset>
<dl>
<dt> label </dt>
<dd> input </dd>
<dt> label </dt>
<dd> input </dd>
<dt> label </dt>
<dd> input </dd>
</dl>
</fieldset>
до этого мы писали br, ибо — абзац в форме — некошерно)
pepelsbey.net/2009/04/as-my-mother-bore-me/
у вас там брейки в комментах =) идите замазывайте, а то такая несусветная древняя глупость =)
Скажите, а если бы этот «лишний пустой элемент только для якоря» был бы не лишним? если бы я залил бы его фоном красивым и выдал бы за элемент дизайна, это бы загладило мою вину? =)))
у вас там брейки в комментах =) идите замазывайте, а то такая несусветная древняя глупость =)
Скажите, а если бы этот «лишний пустой элемент только для якоря» был бы не лишним? если бы я залил бы его фоном красивым и выдал бы за элемент дизайна, это бы загладило мою вину? =)))
BR — это элемент, который применяется для перевода строки. В этих целях я его и использую. Претензии у меня только к тем ситуациям, когда ставят, два и больше BR'ов для имитации отступа.
Элемент A — это ссылка для перехода на другую страницу или в пределах одной страницы по якорям. А вы его используете чёрт знает как — для указания цели перехода.
Элемент A — это ссылка для перехода на другую страницу или в пределах одной страницы по якорям. А вы его используете чёрт знает как — для указания цели перехода.
да, для указания цели переход, а вы спаны используете для закругления острых краев. Но ведь это считается нормальным, да? Т.е. мусорные теги, которые вы используете для достижения каких-то своих целей, в данном случае дизайна, это нормально, но мусорные теги, точнее тег, который я использую у себя для практичности — это несусветная древняя глупость?
Не поверите, но есть такие специальные элементы, которые не несут смысла.
DIV и SPAN — это просто контейнеры, один блочный, другой строчный.
Я вынужден использовать экстра-разметку, поскольку не все браузеры поддерживают свойство border-radius. А вы делаете это намеренно, причём усиленно пропагандируете эту нелепость.
DIV и SPAN — это просто контейнеры, один блочный, другой строчный.
Я вынужден использовать экстра-разметку, поскольку не все браузеры поддерживают свойство border-radius. А вы делаете это намеренно, причём усиленно пропагандируете эту нелепость.
Вынужден? бедный вы и несчастный =) Я тоже вынужден использовать тег <a>, т.к. на <span name="…"> якорь не сядет. Выходит, я тоже жертва обстоятельств? тоже бедный и несчастный, вынужденный идти на хаки? Нет ну правда, задумайтесь. Кстати, по поводу бордер-радиуса: jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fpepelsbey.net%2F
> Вынужден? бедный вы и несчастный =)
Знайте рамки, здесь не лепра.
Вы сами себя вынудили использовать якоря с именами потому, что, видите ли, «в id нельзя вписать инт». Судя по вашей развязной риторике, вы любитель такой разметки:
…а я вот такой:
И — да, она кажется мне гораздо логичнее.
Вы же проверяете логику только валидатором.
Знайте рамки, здесь не лепра.
Вы сами себя вынудили использовать якоря с именами потому, что, видите ли, «в id нельзя вписать инт». Судя по вашей развязной риторике, вы любитель такой разметки:
<p><a name="15"></a>Comment</p> <p><a name="16"></a>Comment</p>
…а я вот такой:
<ul>
<li id="coment-15">Comment</li>
<li id="coment-15">Comment</li>
</ul>И — да, она кажется мне гораздо логичнее.
Вы же проверяете логику только валидатором.
> Знайте рамки, здесь не лепра.
а то что? карму заминусуют? И что значит «знайте рамки»? Или вас не устраевает формат? Мне хотелось бы прекратить данный разговор еще до его начала. Вы человек уважаемый, а я колхозник, исходя из ветки, думаете мне доставляет удовольствие указывать вам на ваши ошибки и спорить с вами? И о чем мы вообще спорим? Я осветил решение проблемы, вы спорите не по поводу решение, не по поводу методики решения, а по поводу техники, выбранной мной. И, кстати, выбранной w3c. Наглядный пример: www.w3.org/TR/xhtml1/
Что является более действенной пропагандой? мой пост на хабре, или же официальный документ? И если официальный документ не стыдится подобного использования элементов, может все же вы не правы?
Помимо закруглённых краев, вы много где используете пустые элементы для формирования дизайна, не мне вам рассказывать. А по поводу моей развязной риторике — не судите да не судимы будете. На проекте, часть которого представлена на скриншоте, комменты вьются деревом, в основе списки, соответственно деревом.
У вас же в блоге я вижу dl\dt\dd, а не ul\li. Мы вроде не о списках говорим сейчас. Я тоже предпочитаю комментарии верстать списком, это гораздо удобней и, как вы заметили, логичней. Не думаю что мы с вами слишком разные, просто я чуть более категоричен к стереотипам, судя по всему. Мне не хотелось начинать имя с буквы, это логичное желание для программиста, да и урл в духе 1.html#c123 полная кака по сравнению с 1.html#123. И почитав спецификацию и полистав сайт w3c я пришел к выводу, что отказ от использования a name="…" потому, что это якобы устарелая и не правильная форма расставления якорей, всего лишь ошибочный стереотип.
а то что? карму заминусуют? И что значит «знайте рамки»? Или вас не устраевает формат? Мне хотелось бы прекратить данный разговор еще до его начала. Вы человек уважаемый, а я колхозник, исходя из ветки, думаете мне доставляет удовольствие указывать вам на ваши ошибки и спорить с вами? И о чем мы вообще спорим? Я осветил решение проблемы, вы спорите не по поводу решение, не по поводу методики решения, а по поводу техники, выбранной мной. И, кстати, выбранной w3c. Наглядный пример: www.w3.org/TR/xhtml1/
Что является более действенной пропагандой? мой пост на хабре, или же официальный документ? И если официальный документ не стыдится подобного использования элементов, может все же вы не правы?
Помимо закруглённых краев, вы много где используете пустые элементы для формирования дизайна, не мне вам рассказывать. А по поводу моей развязной риторике — не судите да не судимы будете. На проекте, часть которого представлена на скриншоте, комменты вьются деревом, в основе списки, соответственно деревом.
У вас же в блоге я вижу dl\dt\dd, а не ul\li. Мы вроде не о списках говорим сейчас. Я тоже предпочитаю комментарии верстать списком, это гораздо удобней и, как вы заметили, логичней. Не думаю что мы с вами слишком разные, просто я чуть более категоричен к стереотипам, судя по всему. Мне не хотелось начинать имя с буквы, это логичное желание для программиста, да и урл в духе 1.html#c123 полная кака по сравнению с 1.html#123. И почитав спецификацию и полистав сайт w3c я пришел к выводу, что отказ от использования a name="…" потому, что это якобы устарелая и не правильная форма расставления якорей, всего лишь ошибочный стереотип.
> Мне хотелось бы прекратить данный разговор еще до его начала
Отличная идея!
Отличная идея!
«да и урл в духе 1.html#c123 полная кака по сравнению с 1.html#123» — по мне, так не кака будет наверное вот так: 1.html#comment123
это ваше право, в своих проектах используте якоря так, как вам хочется и кажется вернее всего. Однако в моем случае я не представляю, что кроме как комментариев можно «якорить» по инту. А значит зачем линий мусор в имени якоря?
Если я нахожусь на сайте, то естественно, я вижу, что я кликаю на ссылку которая ведет именно на коммент — и подсказка в урле действительно лишняя. А вот если мне кто-то присылает прямую ссылку на коммент — лично мне приятно/удобно видеть в URL, что эта ссылка ведет именно на комментарий №123. Мелочь, но удобство пользования сайтами из таких мелочей обычно и состоит…
понял о чем вы, тут стоит выбирать худшее их зол. Т.е. между привлечением новых клиентов и удобства старых. С одной стороны вам может быть и удобно будет один раз в жизни увидеть в урле красивую ссылку и перейти на проекта. Но если вы уйдете с проекта, то к чему все это? А если останетесь, то зачем вам в будущем постоянно наблюдать эту ссылку?
Вы катались на новых субару? относительно любой новой. У них там мега эффект при включении зажигании. Приборка плавно подсвечивается синим, а стрелки спидометра и тахометра доходят до упора и обратно. Все примерно 3-5 секунд занимает. По началу я балдел от этого, казалось мегафичей, но уже после 5 раз наблюдения подобного меня это бесить начинало. Казалось, что субару хуже фашистов.
Вы катались на новых субару? относительно любой новой. У них там мега эффект при включении зажигании. Приборка плавно подсвечивается синим, а стрелки спидометра и тахометра доходят до упора и обратно. Все примерно 3-5 секунд занимает. По началу я балдел от этого, казалось мегафичей, но уже после 5 раз наблюдения подобного меня это бесить начинало. Казалось, что субару хуже фашистов.
pepelsbey.net/2008/04/semantic-coding-2/
9 ошибок насчитал валидатор.
pepelsbey.net/2009/04/zen-coding-concept/
а тут 94.
не правда ли, в чужом коде ковыряться просто, делая не аргументированные заявления. Намного проще, чем разобраться, почему же в своих комментах не закрываются параграфы.
9 ошибок насчитал валидатор.
pepelsbey.net/2009/04/zen-coding-concept/
а тут 94.
не правда ли, в чужом коде ковыряться просто, делая не аргументированные заявления. Намного проще, чем разобраться, почему же в своих комментах не закрываются параграфы.
мне кажется на сайте с таким адресом можно вообще и без якорей )
оффтоп: гипер правильней писать с “h” ;)
Уважаемй трин, я так понимаю проект мобилз безнадежно заброшен?
а зачем в xxx-porno-latinos-giper-sex.com вообще комментарии?
Больше всего меня в статье приколол url в скриншоте :)
эх. такой холивор пропустил =(
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Плавающие якоря