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


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

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

A>Как бы вы организовали связи между узлами разметки, если бы проектировали язык разметки с нуля?

A>5. Ваши варианты.

Теже селекторы, но иерархичные с поддержкой вложенности и namespace-ов и параметрических шаблонов

Т.е. нужен доступ "снаружи внутрь"?

Ну тогда предлагаю к атрибуту scope добавить опциональное значение. Если указать scope="last", то всё работает так же, как сейчас, но также можно писать last.name для доступа "внутрь".

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

Q>Я вот как-то столкнулся с тем, что мне нужно наследование в html, что бы в одном html-документе можно было определить виртуальные или абстрактные теги, которые будет переопределяться или заполнятся в html-документах наследниках и плюс они будет добавлять свое содержимое. Почему бы это не сделать?

Это потребовало бы связей между двумя документами. О чём я мечтаю примерно с 2000-го года.

Да вроде в языках программирования всё давно придумали. Идентификаторы с областями видимости. Вложенные идентификаторы "затеняют" внешние. Т.е. вопрос лишь в том, как грамотно спроектировать эти области видимости. Самый очевидный вариант это использовать специальный элемент, не влияющий на визуальное отображение. Ну или использовать атрибут у существующего элемента.

<div id="name">Name:</div>
<div scope>
  <label for="name">Last name</label>
  <input id="name">
</div>
<div scope>
  <label for="name">First name</label>
  <input id="name">
</div>
<a href="#name">Back<a>

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

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

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

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

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

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

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

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

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

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

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

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

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

Возможные варианты.

0. Нынешний. У элементов есть id. Элементы ссылаются друг на друга указанием id таргета (на уровне стандарта: for, aria-controls и т.д.). id уникален в скоупе документа.

Проблема в том, что это синглтон со всеми вытекающими. Например, нам нужно временно (или даже постоянно) склонировать узел для технических нужд, и мы приплыли. Другая проблема — шаблонизация. Представим себе, что у нас есть пара элементов. Тот же input и label к нему. Их нельзя просто объединить в шаблон и инстанцировать, заменяя чисто текст, нужно ещё каждый раз генерировать бессмысленный идентификатор, только для того, чтобы создать связь. Эта связь никому не интересна за пределами шаблона, но о ней приходится думать снаружи (лично я добавил к шаблонизатору специальную переменную "автоидентификатор").

1. Понизить скоуп id. Наверно, тогда что-то сломается? Вам для чего-нибудь нужна уникальность id на уровне документа? Другой вопрос: понижать до какого уровня? До парента? Или ломать ветки как с position: relative, т.е. до первого помеченного (например, абсолютным позиционированием) элемента выше по дереву?

2. Ссылаться не при помощи id, а при помощи селекторов. Но как тогда быть с конфликтами? Брать первый попавшийся? Брать ближайший в иерархии? И хотя это даёт бОльшую гибкость, увы, селекторы не решают проблему скоупа.

2а. Ссылаться при помощи связки "селектор + квалификатор" ("первый в документе", "первый наружу", "первый вглубь" и, может быть, даже "рандомный в найденном", лол). Тогда селекторы можно указывать относительно какого-то элемента.

3. Оформлять связи специальными элементами-скобками: <group><input><label></group>. Если элементы разнесены, ничего не получится. Т.е. сгодится для for, но не для aria-controls.

4. Вынести описание связей из разметки куда-нибудь ещё (в специальные элементы, в заголовок документа, в DSL). Непонятно, правда, как при описании связи ссылаться на сами элементы... Похоже, это тупиковая идея 

5. Ваши варианты.

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

A>>Как бы вы организовали связи между узлами разметки, если бы проектировали язык разметки с нуля?

A>>5. Ваши варианты.

_>Теже селекторы, но иерархичные с поддержкой вложенности и namespace-ов и параметрических шаблонов

А можно пример кода?

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

A>это синглтон со всеми вытекающими

Это не синглтон, а объект с уникальным идентификатором.

A>нам нужно временно (или даже постоянно) склонировать узел для технических нужд, и мы приплыли.

Если операция копирования не возвращает нового уникального идентификатора — безусловно.

A>Представим себе, что у нас есть пара элементов. Тот же input и label к нему. Их нельзя просто объединить в шаблон и инстанцировать, заменяя чисто текст, нужно ещё каждый раз генерировать бессмысленный идентификатор, только для того, чтобы создать связь.

Он не более "бессмысленный", чем номер телефона или СНИЛС. Как без него идентифицировать объект?

A>Эта связь никому не интересна за пределами шаблона

Тогда нужны области видимости идентификаторов. Вы ее реализовали путем добавления "автоидентификатора".

A>Вам для чего-нибудь нужна уникальность id на уровне документа?

Бывает.

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

ЕМ>Это не синглтон, а объект с уникальным идентификатором...

...который может быть только один. Значит, или это Дункан МакКлауд, или всё-таки синглтон.

A>>Вам для чего-нибудь нужна уникальность id на уровне документа?

ЕМ>Бывает.

А например?

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

A>Как бы вы организовали связи между узлами разметки, если бы проектировали язык разметки с нуля?

A>Возможные варианты.

A>0. Нынешний. У элементов есть id. Элементы ссылаются друг на друга указанием id таргета (на уровне стандарта: for, aria-controls и т.д.). id уникален в скоупе документа.

A>Проблема в том, что это синглтон со всеми вытекающими. Например, нам нужно временно (или даже постоянно) склонировать узел для технических нужд, и мы приплыли. Другая проблема — шаблонизация. Представим себе, что у нас есть пара элементов. Тот же input и label к нему. Их нельзя просто объединить в шаблон и инстанцировать, заменяя чисто текст, нужно ещё каждый раз генерировать бессмысленный идентификатор, только для того, чтобы создать связь. Эта связь никому не интересна за пределами шаблона, но о ней приходится думать снаружи (лично я добавил к шаблонизатору специальную переменную "автоидентификатор").

A>1. Понизить скоуп id. Наверно, тогда что-то сломается? Вам для чего-нибудь нужна уникальность id на уровне документа? Другой вопрос: понижать до какого уровня? До парента? Или ломать ветки как с position: relative, т.е. до первого помеченного (например, абсолютным позиционированием) элемента выше по дереву?

A>2. Ссылаться не при помощи id, а при помощи селекторов. Но как тогда быть с конфликтами? Брать первый попавшийся? Брать ближайший в иерархии? И хотя это даёт бОльшую гибкость, увы, селекторы не решают проблему скоупа.

A>2а. Ссылаться при помощи связки "селектор + квалификатор" ("первый в документе", "первый наружу", "первый вглубь" и, может быть, даже "рандомный в найденном", лол). Тогда селекторы можно указывать относительно какого-то элемента.

A>3. Оформлять связи специальными элементами-скобками: <group><input><label></group>. Если элементы разнесены, ничего не получится. Т.е. сгодится для for, но не для aria-controls.

A>4. Вынести описание связей из разметки куда-нибудь ещё (в специальные элементы, в заголовок документа, в DSL). Непонятно, правда, как при описании связи ссылаться на сами элементы... Похоже, это тупиковая идея 

A>5. Ваши варианты.

Path + index

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

A>...который может быть только один. Значит, или это Дункан МакКлауд, или всё-таки синглтон.

Нет. Синглтон — это тип/класс объекта, сущность, которая, по замыслу, может существовать только в одном экземпляре, ибо наличие дополнительных экземпляров, по тому же замыслу, бессмысленно.

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

Следовательно, при копировании нужно попросту создавать новый идентифкатор.

A>>>Вам для чего-нибудь нужна уникальность id на уровне документа?
ЕМ>>Бывает.

A>А например?

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

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

vsb>Да вроде в языках программирования всё давно придумали. Идентификаторы с областями видимости. Вложенные идентификаторы "затеняют" внешние. Т.е. вопрос лишь в том, как грамотно спроектировать эти области видимости. Самый очевидный вариант это использовать специальный элемент, не влияющий на визуальное отображение. Ну или использовать атрибут у существующего элемента.

vsb>

vsb><div id="name">Name:</div>
vsb><div scope>
vsb>  <label for="name">Last name</label>
vsb>  <input id="name">
vsb></div>
vsb><div scope>
vsb>  <label for="name">First name</label>
vsb>  <input id="name">
vsb></div>
vsb><a href="#name">Back<a>
vsb>

А если есть тулбар вверху, который управляет компоновкой блока внизу, и каждая кнопка тулбара включает/выключает элемент в этом нижнем блоке? Нужно настроить связи между ними так, как они сейчас настраиваются через aria-controls + id. Иными словами, включить их внутрь <scope> или <div scope> не выйдет.

Я потому и взял два этих разных примера (for и aria-controls), чтобы на проблему можно было посмотреть с разных сторон.

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

ЕМ>Нет. Синглтон — это тип/класс объекта, сущность, которая, по замыслу, может существовать только в одном экземпляре, ибо наличие дополнительных экземпляров, по тому же замыслу, бессмысленно.

Так там ЕСТЬ тип/класс. Просто он имплиситный.

По сути, что надо для экспицирования? Встроить шаблонизатор в стандарт. Но он делается так просто (буквально несколько строчек), что типы в разметке присутствуют ПОЧТИ явно. Даже элемент для этого имеется (<template>).

A>>А например?

ЕМ>Ну вот как раз в тех случаях, когда элемент может быть только один (заголовок, подвал и т.п.), и копировать его бессмысленно.

А это — как раз таки самая традиционная мотивация делать синглтон. На той стадии, когда грабли уже разложены, но ещё не наступлены

Ладно, я понял твою позицию: проблемы нет, оставить всё как есть.

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

A>Так там ЕСТЬ тип/класс. Просто он имплиситный.

"Имплиситных" синглтонов не бывает. Если у Вас есть один апельсин — какие могут быть основания называть "синглтоном" хоть непосредственно его, хоть тип/класс фрукта?

A>Встроить шаблонизатор в стандарт.

А точно надо? Какой процент задач в HTML/CSS он мог бы решить без привлечения JS?

A>Ладно, я понял твою позицию: проблемы нет, оставить всё как есть.

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

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

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

Хорошо, начнём от истоков.

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

Далее. Паттерн проектирования отражает некое представление о правильном устройстве чего-нибудь. Синглтон отражает следующее: "Экземпляр [чего-нибудь] может быть только один". Теперь смотрим, что ты написал:

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

Если ты считаешь, что элемент типа "подвал" может быть только один, и копировать его бессмысленно, это буквально и есть синглтон. Синглтоннее не бывает.

Паттерн этот является ошибкой проектирования (быдло называет их "антипаттерны", но такой подход неявно приписывает обычным паттернам качество "хороший", "безошибочный", поэтому я этим словом не пользуюсь). Ошибка тут в том, что в природе даже конь с двумя... подвалами нет-нет, да уродится. Вопрос времени, когда это противоречие всплывёт в коде. А если часто и много решать задачи заданной предметной области, это время существенно сокращается. Поэтому пара-тройка лет плотной работы с разметкой отучает пользоваться id в тех местах, где он не требуется стандартом, а в тех, где требуется — думать о замене.

A>>Встроить шаблонизатор в стандарт.

ЕМ>А точно надо? Какой процент задач в HTML/CSS он мог бы решить без привлечения JS?

Я не говорил, что надо. Это вырвано из контекста. Я сказал, что если это сделать де-юре (де-факто все и так пишут одно и то же со времён Мусташа, включая синтаксис фигурных скобок и использование data-атрибутов), то неявное инстанцирование станет явным. Это чисто мысленное упражнение, если кому-то без инстанцирования трудно понять, где тут типы, а где экземпляры.

Кроме того, сейчас шаблоны и де-юре наполовину стандартизированы, со стороны разметки. Если помнишь, раньше для них все юзали <script>, а потом появился специальный <template>.

A>>Ладно, я понял твою позицию: проблемы нет, оставить всё как есть.

ЕМ>Проблемы как раз есть, но вряд ли стоит начинать их решение именно с обсуждаемой. Это ж даже не проблема — так, мелкое неудобство.

Мой список претензий к HTML/JS/CSS длиной до Луны, периодически я что-то из него озвучиваю.

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

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


ЕМ>>Проблемы как раз есть, но вряд ли стоит начинать их решение именно с обсуждаемой. Это ж даже не проблема — так, мелкое неудобство.

A>Мой список претензий к HTML/JS/CSS длиной до Луны, периодически я что-то из него озвучиваю.

A>В данном же случае, прежде, чем критиковать, надо понять, как нужно было сделать правильно и можно ли вообще что-то улучшить.

Я вот как-то столкнулся с тем, что мне нужно наследование в html, что бы в одном html-документе можно было определить виртуальные или абстрактные теги, которые будет переопределяться или заполнятся в html-документах наследниках и плюс они будет добавлять свое содержимое. Почему бы это не сделать?

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

A>Если ты считаешь, что элемент типа "подвал" может быть только один, и копировать его бессмысленно, это буквально и есть синглтон.

Безусловно. "Подвал" — это именно тип/класс, поэтому конкретный единственный элемент совершенно естественно получает свой единственный, уникальный id, и никаких проблем с его использованием не возникает, ибо не возникает мысли его зачем-то копировать в рамках этого же HTML.

A>пара-тройка лет плотной работы с разметкой отучает пользоваться id в тех местах, где он не требуется стандартом, а в тех, где требуется — думать о замене.

Можно примеров? Чтоб элемент действительно был единственным по замыслу, и замысел впоследствии не изменился, однако потребность в создании дополнительных экземпляров таки возникла.

A>неявное инстанцирование станет явным.

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

A>прежде, чем критиковать, надо понять, как нужно было сделать правильно

Я критиковал не саму идею использования шаблонов, а прежде всего утверждение, что присвоение id любому элементу якобы автоматически делает из него синглон (как концепцию).

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

ЕМ>Можно примеров? Чтоб элемент действительно был единственным по замыслу, и замысел впоследствии не изменился, однако потребность в создании дополнительных экземпляров таки возникла.

Например, закольцовывание в слайдере, когда из загруженных в него элементов невидимым остаётся один. Как в детской "садюжке": слева пол-Пети и справа пол-Пети

Ты скажешь: "пререндеринг", а я скажу: элементы с видео и с анимациями. Ссылку не дам по соображениям приватности, но пример из жизни.

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

ЕМ>Я критиковал не саму идею использования шаблонов, а прежде всего утверждение, что присвоение id любому элементу якобы автоматически делает из него синглон (как концепцию).

Я же, вроде, обосновал?

Вот простой тип по имени template.out-link:

<template class="out-link">
    <a href="{url}" target="_blank" class="text-nowrap out-link {classes}" data-{name}="{value}">
        {text}
        <svg width="16" height="16" class="inline">
            <use href="#bi-box-arrow-up-right"></use>
        </svg>
    </a>
</template>

Вот синглтонный тип по имени template.the-out-link:

<template class="the-out-link">
    <a id="the-link" href="{url}" target="_blank" class="text-nowrap out-link {classes}" data-{name}="{value}">
        {text}
        <svg width="16" height="16" class="inline">
            <use href="#bi-box-arrow-up-right"></use>
        </svg>
    </a>
</template>

Вот инстанцирование:

<!-- Создаём инстанс простого типа -->
<span data-template="template.out-link" data-template-params='{ "text": "popper.js", "url": "https://popper.js.org/" }'></span>

<!-- Создаём инстанс синглтонного типа -->
<span data-template="template.the-out-link" data-template-params='{ "text": "The Google, The great and terrible", "url": "https://google.com/" }'></span>

Что тебя смущает?

То, что вместо проверки компилятором, кому можно инстанцировать, а кому нельзя (обычно так обеспечивается уникальность инстанса: инстанцировать дают доверенному агенту, который по контракту обязывается чекать уникальность), проверка идёт в коде шаблонизации, который чекает уникальность идентификаторов и кидает исключения?

Или то, что код шаблонизации не включён в браузер и его пишет сам программист?

Или то, что ЛЮБОЙ КУСОК HTML'я может быть типом для шаблонизатора (или закольцованного слайдера), и ЛЮБОЙ КУСОК HTML'я может быть инстансом, порождённым шаблонизатором (или закольцованным слайдером)? В этом всё дело? Я бы поставил на этот пункт

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

A>закольцовывание в слайдере, когда из загруженных в него элементов невидимым остаётся один.
A>Ты скажешь: "рендеринг"

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

A>Что тебя смущает?

В самой идее с шаблонами — ничего. Но, коль их стандартной реализации нет, а все делается руками через JS, то нет никакой разницы, во что оборачивать содержимое шаблона — в template, или в любой самодельный тэг, как присваивать идентификаторы, как подставлять параметры и т.п. И нет никаких оснований называть это именно "шаблоном", а не каким-нибудь "образцом".

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

A>>закольцовывание в слайдере, когда из загруженных в него элементов невидимым остаётся один.
A>>Ты скажешь: "рендеринг"

ЕМ>Нет, я скажу, что по замыслу это не является синглтоном. Не понимаю, почему Вы упорно смешиваете то, что задумано изначально, с тем, что может получиться в частном случае.

Как это не является? Человек думает: Я ТОЧНО ЗНАЮ, что эта конструкция уникальна и будет таковой всегда. Потом её оказывается нужно вставить в слайдер. И внезапно выясняется, что предположение не подтвердилось. Это классическая грабелька, на которую наступает не только каждый, кто создаёт явные синглтоны, но и каждый, кто сознательно не уничтожает неявные.

Что можно сделать в этой ситуации? Если связь динамическая, прописывается в коде, то хоть полноценных квалификаторов к селекторам и нет, можно задать исходную точку и направление для поиска вверх или вниз (в терминологии jQuery это .parents()/.find()). Если заморочиться и таким образом убрать неявный синглтон, можно решить часть проблем. Но не следующую: что делать, когда стандарт разметки прямо предписывает создавать связи через уникальные идентификаторы.

Что и послужило основанием для создания этой темы.

A>>Что тебя смущает?

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

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

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

A>Человек думает: Я ТОЧНО ЗНАЮ, что эта конструкция уникальна и будет таковой всегда. Потом её оказывается нужно вставить в слайдер.

Это означает, что человек думал одно, а озвучил (хотя бы для себя) другое. Перепутал термины, или сам толком не понимал, что под ними имеется в виду.

Поэтому, если нет уверенности в точном понимании терминов, лучше избегать их. Вместо "синглтон" говорить "элемент данных, для которого достаточно единственного экземляра".

A>И внезапно выясняется, что предположение не подтвердилось. Это классическая грабелька, на которую наступает не только каждый, кто создаёт явные синглтоны, но и каждый, кто сознательно не уничтожает неявные.

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

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

A>что делать, когда стандарт разметки прямо предписывает создавать связи через уникальные идентификаторы.

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

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 для создания/модификации содержимого страницы.