страшная правда о ie
 

вот тут своими экспериментами нашел еще один баг осла-сплоера:


div.muha#top
{
border-width: 5px;
border-style: solid;
border-color: red;
}
div.menu#top
{
border-width: 5px;
border-style: solid;
border-color: blue;
}


<div class=muha id=top>
123
</div>

<div class=menu id=top>
123
</div>

=======

второй не будет в рамке, но зато если написать так:

div.muha#top
{
border-width: 5px;
border-style: solid;
border-color: red;
}
div.menu#top1
{
border-width: 5px;
border-style: solid;
border-color: blue;
}


<div class=muha id=top>
123
</div>

<div class=menu id=top1>
123
</div>

все будет нормально, бред какойто

да у него вообще глюк с блоками.

CTEPBA скорее с названиями селекторов..

E-mail, а разве можно так, чтоб названия селекторов дублировались?

Sham нечетко сформулирован вопрос,

названия селекторов классов могут использоваться для разных тегов и могут быть одинаковыми для всех них, ровно также как и названия индификаторов

ff и опера код выше понимает по любому, а вот осел упрям, и непонятно поччему он не определяет и не принимает стиль для элемента имеющего индивикатор и класс определенные в css, когда два одинаковых индефикатора, но относятся к разным классам.

если даже допустить что осел не принимает дубляж от другого класса, то он поидее должен отражать стиль хотябы для первого определенного класса этого идентификатора.

но при таком предположении такие действия браузера смотрятся абсурдно, это равносильно если у нас в php у двух разных используемых классов есть два одинаковых метода, нам php ведь не ругается на то что методы называются одинакого (!), потомучто они находятся в разных областях памяти, а осел по видемости их не разделяет и не один из них не использует, бред.

E-mail, а я все же бы шел по пути меньшего сопротивления: не искал бы и доказывал сомнительные недоработки, а применял бы менее двусмысленные нотации. К примеру getElementById вернет первый элемент, если ему передать в качестве параметра "top". Мало ли, вдруг понадобится ссылка на второй? Вообще, зачем вносить дополнительные двусмысленности (читай потенциальные ошибки) в код коли они "сами" там появляются? :).

Prisonerя в курсе, только эта объектная модель мешает аспектному разделению стилей. ведь мы говорим не только об удобстве создания сценариев но и о визуальном оформлении.

например логичней я себе вижу, надо было создавать фукцию getelementbyclassid , где параметром может быть menu#top , а id это не уникальный идентификатор элемента во всем коде, а уникальный идентификатор одного из элементов класса (в данном примере class=menu).

либо второе решение, также в случае не уникальности, для getElementById выдавать массив всех найденных элементов, где ключом является порядок появления в коде, но при этом стили обрабатывать в зависимости от предка класса.

и никаких двухсмысленностей

Простите, зачем тогда class? class1, class2, class3, ... , classN - чем не уникальность вида className#idName? То, что O и FF, не найдя явных указаний в рекомендациях w3c по рендеру такого рода объявлений, сошлись на мнении и обрабатывают так как решили еще ниочем не говорит. Мне вот лично видится более логичным решение MS - id он и в Африке id, что недвусмысленно говорит нам - хорек, а стало быть никаких сусликов: это оформление уникального элемента. Ну я не знаю как еще пояснить свою мысль :). Ну вот так, наверное, в плюс ко всему уже сказанному - зачем придумывать искусственные методы, если есть существующие и они лаконичны. Просто делают они разную работу и предназначены для разных вещей. Мда.
А зачем? Ну есть у меня 15 ссылок на потенциально разные объекты, как мне с ними работать? Они ведь разные - div, a, span. Кто и где? Вот чем не двусмысленность? id - и есть тот самый инструмент который позволяет оперировать программисту однозначно с тем или иным элементом - хорьком. А суслики это другая история :).

ну замечательно это все для сценариев это и другое выше сказанное, но для стилей использования этого же уникального индефикатора объекта (!) как подкласса: div.menu#top идеотизм если не работает div.muha#top , ведь сам синтаксис записи должен соответствовать представлению, что при ссылки на один класс с подклассом должно быть одно, а при ссылки на другой класс с пускай таким же именем индефикатора как и у других классов будет другое отображаться.

я вижу неудачное интерпретирование для стилей индефикатора как подкласса, раз нельзя использовать аспектное структуирование стилей, надо было использовать отдельный атрибут для подкласса если используется класс, т.е. не <div class=menu id=top> а чтонибудь в духе <div class=menu aspectid=top> ну а для сценариев в случае если они используется можно использовать id как уникальный индефикатор элемента т.е получается запись вида: <div class=menu aspectid=top id=ieia>

при этом сценарии работают используя getelementbyid, а стили понимаются при запясях div.menu#top {1} и div.muha#top {2} и отображаются в соответствии с тем что написано в таблице. И всем хорошо.

а вот и пример из жизни, допустим есть сайт где находится пять зон менюх которые используют стиль:

div.menu{1}

но различаются все по цвету скажем, значит вполне логичней задать каждому по цвету и вполне логично назвать их так как они располагаются на сайте, скажем например для других вебмастеров, и это будет так:

div.menu#top{1-1}
div.menu#center{1-2}
div.menu#left{1-3}
div.menu#right{1-4}
div.menu#bottom{1-5}

но помимо менюх, у нас есть основной каркас который разделен на пять частей но имеет общий стиль:

div.fish{1}

каждая из пяти частей имеет свой разный цвет например, и опятьже логично назвать каждую часть каркаса так как она располажена на странице:

div.fish#top{1-1}
div.fish#center{1-2}
div.fish#left{1-3}
div.fish#right{1-4}
div.fish#bottom{1-5}


и таких блоков на сайте всегда много, где если назвать подкласс не так чтобы название отражало суть блока, будет выглядеть немного ошеломляюще, (не даром разработчики css используют везде одно словестное определение для разных процедур (top left bottom right)), мне же из-за этой недобросовестности придется назвать блок div.fish#top какнибудь вроде div.fish#up, а что для остальных 500 блоков например, которые подразумевают такоеже название "top"? выдумывать "top1" или "up499"??!!

да это вообще жесть.


единственно правельно то что объективно а не субъективно или под давлением и я например это вижу четко и вполне ясно.

Удивительно то, что Вы к этому уже привыкли и пишете как скажут.

Мне начинает надоедать спорить, Вы уж простите. Однако.
Чем запись
схожа с
?
По-моемому лишь правильным применением инструментария. Давайте повторюсь еще раз - Вы смешиваете два мира: id пришел из html как уникальный идентификатор позволяющий ссылаться якорями на ту или иную часть документа. Именно поэтому, появившийся позже, getElementById возвращает первый элемент с данным id, а не массив оных - по тому же самому принципу по которому броузер позицирует страничку при переходе по якорю в рамках текущей страницы - к первому попавшемуся. Хорошенькое было бы дело, если броузер начал или мотаться по страничке показывая все места с данным id, или делил окно, или множил свои экземпляры. Так вот, id пришел из html и стал частично использоваться в JS? в силу чего отменить его роль уже невозможно. Наравне с JS, идеологию id использует и CSS на тех же самых правах - изменить ничего нельзя, расширить - можно. Это банальное наследование.

Я даже знаю почему нет у w3c четких рекомендаций по рендеру первого участка кода и как вследствие еще одно разногласие (вот ведь еще один момент: это разногласие ввиду нечеткости формулировки, а не "еще один баг осла-сплоера") "трех китов". Дело в том, что второй участок кода - это... первый и удивительно зачем выдумывать что-то еще, когда они так похожи. Зачем? Экзотичность записи? Какие-то приемущества? Пустое. Именно поэтому w3c и упустила четкость в формулировке - зачем использовать id в идентификаторах если он не имеет право быть неуникальным?

А что касается , то я руководствуюсь "здравым смыслом и жизненной опытностью" (с) Ф. Ф. Преображенский ;). Причем скорее первым, чем вторым, которого у меня пока что не так уж и много :).

Вы не внимательно читали мой предыдущий пост.

пессимист, Вами легко управлять:).

- запись ужасна сама по себе, такие извращения с регистром надо искоренять из программирования, я представляю сколько ваш совместитель верстальшик бы лазал по коду если у вас будет в одном месте div.fishTop в другом месте div.fishtOp в третьем месте div.fishtoP и так порядка 500 раз, но комбинаций не хватит будете цифры еще ко всему использовать. Кроме того вы в каждом из классов будете повторять один и тот же стиль четыри раза вместо одного.

ну да, а головой подумать у мелкомягких никто не захотел.

Да, мною легко управлять... в данном случае Вы меня успешно утомили. Всего доброго в упорстве.

Это отличный способ записи. Либо пиши смысловые части с большой буквы, либо разделяй их символом подчеркивания _.

OpenFile, GetDlgItemText, GetFileResource и прочие имена API функций вы предлагаете писать как openfile, getdlgitemtext, getfileresource? Оцените разницу в степени читаемости. При чтении исходников, первый вариант намного понятнее, так как написание с большой буквы разделяет написано на отдельные слова

А сколько времени бы программист разбирался при чтении исходника со зрительным опознаванием написанного с маленьких букв всего имени функции, особенно если таких функций несколько тысяч. Расшифруйте и разделите на смысловые части c лету меньше чем за секунду - rtlntstatustodoserror. (RtlNtStatusToDosError)

mrcnn дык именно так оно и делается, посмотрите МОИ примеры кода, именно нижнее подчеркивание должно отделять смысл в переменной функциях методах и т.д.

А извращения с регистром я признаю только в регистроНЕзависимых языках, где в случае опечатки в огромном коде не будет потери времени на поиск ошибки в регистре, тем более ИСКАТЬ тоже затратно и смотря в каком редакторе, да еще знать бы что искать.