Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Поймите, не бывает никаких "неявных синглтонов". Синглтон — понятие проектирования, а не реализации. Такие понятия принципиально не могут возникнуть само собой, они могут быть только задуманы.

Так они и были задуманы. Тем чуваком, который придумал ввести id в HTML сто лет тому назад. Он создал этот паттерн проектирования. А когда кто-то пользуется этим атрибутом, он реализует этот паттерн в своём коде.

Конечно, это понятие проектирования. Конечно, такие вещи не берутся ниоткуда. Кто бы спорил.

A>>что делать, когда стандарт разметки прямо предписывает создавать связи через уникальные идентификаторы.
ЕМ>То же, что и всегда: если стандарт позволяет решить задачу стандартными средствами — использовать их, иначе — выходить за пределы стандарта, стараясь действовать разумно.

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

Настоящий же вопрос, который почему-то игнорируется (я думаю, это потому, что на него ответить труднее, чем спорить о словах) таков. Как надо было спроектировать HTML, чтобы не наступать на эти грабли, возможно ли это в принципе, и если да — какой ценой (какие грабли мы получаем взамен).

A>>Ты же писал, что для синглтона нужны типы и инстансы, а без этого не может быть синглтона. И это было главное возражение. Я показал: вот типы, вот инстансы.

ЕМ>Вы поставили телегу впереди лошади. В случае синглтона первична его идея, а типы/экземпляры — способы ее реализации. У Вас же получилось рассуждение "вот элемент, который мог бы быть синглтоном, из чего я заключаю, что это синглтон и есть".

Ну вот. Теперь уже идея. А было написано:

Нет. Синглтон — это тип/класс объекта

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

Здравствуйте, Alekzander, Вы писали:

ЕМ>>не бывает никаких "неявных синглтонов". Синглтон — понятие проектирования, а не реализации. Такие понятия принципиально не могут возникнуть само собой, они могут быть только задуманы.

A>Так они и были задуманы. Тем чуваком, который придумал ввести id в HTML сто лет тому назад.


Нет.

A>Он создал этот паттерн проектирования.

Это не "паттерн проектирования". Если Вам настолько трудно обойтись без того, чтобы щегольнуть модным термином, разберитесь хотя бы со значением каждого из них.

A>Как надо было спроектировать HTML, чтобы не наступать на эти грабли

На тот момент, когда возникла идея сделать HTML, и толком не было понятно, что из этого получится, будет ли оно развиваться, а если будет, то куда и как, практически все варианты были равнозначны. На каждом следующем этапе был выбор — дорабатывать то, что есть, или переделывать с нуля. Даже сейчас вряд ли кто-то возьмется делать заново, ибо через каких-нибудь лет пять все опять может сильно поменяться.

На мой взгляд, куда более насущный вопрос — это накойхер нужен CSS там, где применяется развесистый JS. CSS хорош для "пассивных" страниц, где JS или нет вообще, или он применяется очень аккуратно и локально. Там, где JS генерит почти все содержимое страницы, в CSS нет никакого смысла — куда логичнее иметь простые (ненаследуемые) стили, и ссылаться на них из тэгов HTML (с возможностью объединения нескольких стилей).

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>
ЕМ>Нет.

Эх, Евгений, Евгений... Я пишу развёрнутые аргументированные ответы с примерами кода, а в ответ получаю "Нет" и пару смайлов. Сдаётся мне, наш обмен неравноценен! )

ЕМ>На мой взгляд, куда более насущный вопрос — это накойхер нужен CSS там, где применяется развесистый JS.

Это называется: "Мне нечего сказать по обсуждаемой теме, поэтому давайте поговорим на мою".

Здравствуйте, Alekzander, Вы писали:

A> Так они и были задуманы. Тем чуваком, который придумал ввести id в HTML сто лет тому назад. Он создал этот паттерн проектирования. А когда кто-то пользуется этим атрибутом, он реализует этот паттерн в своём коде.
У тебя с терминологией путаница. Id — это идентификатор. Он используется для уникальной идентификации и потому единственный. А паттерн синглтон — это в первую очередь про глобальное состояние.
А по твоей логике каждый сгенерённый uuid или git-коммит — синглтоны.
По сабжевому вопросу — ну наверное можно использовать что-то вроде xpath для навигации. Но неясно как обеспечивать то, что xpath вернёт только один элемент.
Скажем, пишешь некий <label for="???"> и что делать, если этих самых "???" несколько, кому фокус отдавать?!

Здравствуйте, Alekzander, Вы писали:

A>Я пишу развёрнутые аргументированные ответы с примерами кода, а в ответ получаю "Нет" и пару смайлов.

Ну, если Вы полагаете, что весомость обоснования прямо пропорциональна объему текста и количеству примеров, то попробуйте прикинуть, какого объема/количества Вам будет достаточно от меня, чтоб согласится, например, с идеей божественного происхождения HTML, или с тем, что крокодил более длинный, чем зеленый.

A>Сдаётся мне, наш обмен неравноценен! )

Я несколько раз указал Вам на принципиальное несоответствие Вашей трактовки понятия "синглтон" его определению. Чего еще Вы от меня ждете?

ЕМ>>накойхер нужен CSS там, где применяется развесистый JS.
A>Это называется: "Мне нечего сказать по обсуждаемой теме, поэтому давайте поговорим на мою".

Это как раз непосредственно по Вашей теме. Мне пока как раз хватает CSS в чистом виде, я не использую JS для создания/модификации содержимого страницы.

Здравствуйте, Alekzander, Вы писали:


A>2а. Ссылаться при помощи связки "селектор + квалификатор" ("первый в документе", "первый наружу", "первый вглубь" и, может быть, даже "рандомный в найденном", лол). Тогда селекторы можно указывать относительно какого-то элемента.
Выглядит наиболее перспективным способом. Эдакий relative xpath или что-то в этом роде. (Дисклаймер: я гуем, в том числе и веб, не занимался со времён очаковских и покоренья крыма).
Что беспокоит: потенциальный разрыв между иерархией "скоупов" и иерархией "элементов".
Имеется в виду ситуация типа связи контрола с его лейблом. Логично считать, что пара инпут-лейбл входят в один скоуп "композитный контрол". Тогда можно было бы использовать ссылки в стиле "./label" и "./input", которые вполне себе однозначны из-за локальной уникальности. Но если вдруг вёрстка потребует, скажем, выводить контролы в табличке, где все метки — в одной строке, а все инпуты — в другой, то техническая иерархия будет совсем другой.