Как бы вы организовали связи между узлами разметки, если бы проектировали язык разметки с нуля?
Возможные варианты.
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. Ваши варианты.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>Как бы вы организовали связи между узлами разметки, если бы проектировали язык разметки с нуля?
A>5. Ваши варианты.
Теже селекторы, но иерархичные с поддержкой вложенности и namespace-ов и параметрических шаблонов
Здравствуйте, kov_serg, Вы писали:
A>>Как бы вы организовали связи между узлами разметки, если бы проектировали язык разметки с нуля?
A>>5. Ваши варианты.
_>Теже селекторы, но иерархичные с поддержкой вложенности и namespace-ов и параметрических шаблонов
А можно пример кода?
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>это синглтон со всеми вытекающими
Это не синглтон, а объект с уникальным идентификатором.
A>нам нужно временно (или даже постоянно) склонировать узел для технических нужд, и мы приплыли.
Если операция копирования не возвращает нового уникального идентификатора — безусловно.
A>Представим себе, что у нас есть пара элементов. Тот же input и label к нему. Их нельзя просто объединить в шаблон и инстанцировать, заменяя чисто текст, нужно ещё каждый раз генерировать бессмысленный идентификатор, только для того, чтобы создать связь.
Он не более "бессмысленный", чем номер телефона или СНИЛС. Как без него идентифицировать объект?
A>Эта связь никому не интересна за пределами шаблона
Тогда нужны области видимости идентификаторов. Вы ее реализовали путем добавления "автоидентификатора".
A>Вам для чего-нибудь нужна уникальность id на уровне документа?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это не синглтон, а объект с уникальным идентификатором...
...который может быть только один. Значит, или это Дункан МакКлауд, или всё-таки синглтон.
A>>Вам для чего-нибудь нужна уникальность id на уровне документа?
ЕМ>Бывает.
А например?
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, 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. Ваши варианты.
Да вроде в языках программирования всё давно придумали. Идентификаторы с областями видимости. Вложенные идентификаторы "затеняют" внешние. Т.е. вопрос лишь в том, как грамотно спроектировать эти области видимости. Самый очевидный вариант это использовать специальный элемент, не влияющий на визуальное отображение. Ну или использовать атрибут у существующего элемента.
Здравствуйте, Alekzander, Вы писали:
A>...который может быть только один. Значит, или это Дункан МакКлауд, или всё-таки синглтон.
Нет. Синглтон — это тип/класс объекта, сущность, которая, по замыслу, может существовать только в одном экземпляре, ибо наличие дополнительных экземпляров, по тому же замыслу, бессмысленно.
Блок HTML, имеющий идентификатор — это всего-навсего элемент данных. Его идентификатор эквивалентен подобен какому-нибудь адресу в памяти. Но адрес в памяти является "имманентным" — невозможно скопировать в памяти блок данных, сохранив адрес неизменным. А в HTML это как блок данных в памяти, одно из полей которого содержит произвольный идентификатор, поэтому копирование с его сохранением возможно, просто дальнейшая обработка будет невозможна.
Следовательно, при копировании нужно попросту создавать новый идентифкатор.
A>>>Вам для чего-нибудь нужна уникальность id на уровне документа? ЕМ>>Бывает.
A>А например?
Ну вот как раз в тех случаях, когда элемент может быть только один (заголовок, подвал и т.п.), и копировать его бессмысленно.
Здравствуйте, vsb, Вы писали:
vsb>Да вроде в языках программирования всё давно придумали. Идентификаторы с областями видимости. Вложенные идентификаторы "затеняют" внешние. Т.е. вопрос лишь в том, как грамотно спроектировать эти области видимости. Самый очевидный вариант это использовать специальный элемент, не влияющий на визуальное отображение. Ну или использовать атрибут у существующего элемента.
vsb>
А если есть тулбар вверху, который управляет компоновкой блока внизу, и каждая кнопка тулбара включает/выключает элемент в этом нижнем блоке? Нужно настроить связи между ними так, как они сейчас настраиваются через aria-controls + id. Иными словами, включить их внутрь <scope> или <div scope> не выйдет.
Я потому и взял два этих разных примера (for и aria-controls), чтобы на проблему можно было посмотреть с разных сторон.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Нет. Синглтон — это тип/класс объекта, сущность, которая, по замыслу, может существовать только в одном экземпляре, ибо наличие дополнительных экземпляров, по тому же замыслу, бессмысленно.
Так там ЕСТЬ тип/класс. Просто он имплиситный.
По сути, что надо для экспицирования? Встроить шаблонизатор в стандарт. Но он делается так просто (буквально несколько строчек), что типы в разметке присутствуют ПОЧТИ явно. Даже элемент для этого имеется (<template>).
A>>А например?
ЕМ>Ну вот как раз в тех случаях, когда элемент может быть только один (заголовок, подвал и т.п.), и копировать его бессмысленно.
А это — как раз таки самая традиционная мотивация делать синглтон. На той стадии, когда грабли уже разложены, но ещё не наступлены
Ладно, я понял твою позицию: проблемы нет, оставить всё как есть.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Ну тогда предлагаю к атрибуту scope добавить опциональное значение. Если указать scope="last", то всё работает так же, как сейчас, но также можно писать last.name для доступа "внутрь".
Здравствуйте, Alekzander, Вы писали:
A>Так там ЕСТЬ тип/класс. Просто он имплиситный.
"Имплиситных" синглтонов не бывает. Если у Вас есть один апельсин — какие могут быть основания называть "синглтоном" хоть непосредственно его, хоть тип/класс фрукта?
A>Встроить шаблонизатор в стандарт.
А точно надо? Какой процент задач в HTML/CSS он мог бы решить без привлечения JS?
A>Ладно, я понял твою позицию: проблемы нет, оставить всё как есть.
Проблемы как раз есть, но вряд ли стоит начинать их решение именно с обсуждаемой. Это ж даже не проблема — так, мелкое неудобство.
Здравствуйте, Евгений Музыченко, Вы писали:
A>>Так там ЕСТЬ тип/класс. Просто он имплиситный. ЕМ>"Имплиситных" синглтонов не бывает. Если у Вас есть один апельсин — какие могут быть основания называть "синглтоном" хоть непосредственно его, хоть тип/класс фрукта?
Хорошо, начнём от истоков.
Синглтон это паттерн проектирования. С этим, надеюсь, ты спорить не будешь?
Далее. Паттерн проектирования отражает некое представление о правильном устройстве чего-нибудь. Синглтон отражает следующее: "Экземпляр [чего-нибудь] может быть только один". Теперь смотрим, что ты написал:
Ну вот как раз в тех случаях, когда элемент может быть только один (заголовок, подвал и т.п.), и копировать его бессмысленно.
Если ты считаешь, что элемент типа "подвал" может быть только один, и копировать его бессмысленно, это буквально и есть синглтон. Синглтоннее не бывает.
Паттерн этот является ошибкой проектирования (быдло называет их "антипаттерны", но такой подход неявно приписывает обычным паттернам качество "хороший", "безошибочный", поэтому я этим словом не пользуюсь). Ошибка тут в том, что в природе даже конь с двумя... подвалами нет-нет, да уродится. Вопрос времени, когда это противоречие всплывёт в коде. А если часто и много решать задачи заданной предметной области, это время существенно сокращается. Поэтому пара-тройка лет плотной работы с разметкой отучает пользоваться id в тех местах, где он не требуется стандартом, а в тех, где требуется — думать о замене.
A>>Встроить шаблонизатор в стандарт.
ЕМ>А точно надо? Какой процент задач в HTML/CSS он мог бы решить без привлечения JS?
Я не говорил, что надо. Это вырвано из контекста. Я сказал, что если это сделать де-юре (де-факто все и так пишут одно и то же со времён Мусташа, включая синтаксис фигурных скобок и использование data-атрибутов), то неявное инстанцирование станет явным. Это чисто мысленное упражнение, если кому-то без инстанцирования трудно понять, где тут типы, а где экземпляры.
Кроме того, сейчас шаблоны и де-юре наполовину стандартизированы, со стороны разметки. Если помнишь, раньше для них все юзали <script>, а потом появился специальный <template>.
A>>Ладно, я понял твою позицию: проблемы нет, оставить всё как есть.
ЕМ>Проблемы как раз есть, но вряд ли стоит начинать их решение именно с обсуждаемой. Это ж даже не проблема — так, мелкое неудобство.
Мой список претензий к HTML/JS/CSS длиной до Луны, периодически я что-то из него озвучиваю.
В данном же случае, прежде, чем критиковать, надо понять, как нужно было сделать правильно и можно ли вообще что-то улучшить.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
ЕМ>>Проблемы как раз есть, но вряд ли стоит начинать их решение именно с обсуждаемой. Это ж даже не проблема — так, мелкое неудобство.
A>Мой список претензий к HTML/JS/CSS длиной до Луны, периодически я что-то из него озвучиваю.
A>В данном же случае, прежде, чем критиковать, надо понять, как нужно было сделать правильно и можно ли вообще что-то улучшить.
Я вот как-то столкнулся с тем, что мне нужно наследование в html, что бы в одном html-документе можно было определить виртуальные или абстрактные теги, которые будет переопределяться или заполнятся в html-документах наследниках и плюс они будет добавлять свое содержимое. Почему бы это не сделать?
Здравствуйте, Qulac, Вы писали:
Q>Я вот как-то столкнулся с тем, что мне нужно наследование в html, что бы в одном html-документе можно было определить виртуальные или абстрактные теги, которые будет переопределяться или заполнятся в html-документах наследниках и плюс они будет добавлять свое содержимое. Почему бы это не сделать?
Это потребовало бы связей между двумя документами. О чём я мечтаю примерно с 2000-го года.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>Если ты считаешь, что элемент типа "подвал" может быть только один, и копировать его бессмысленно, это буквально и есть синглтон.
Безусловно. "Подвал" — это именно тип/класс, поэтому конкретный единственный элемент совершенно естественно получает свой единственный, уникальный id, и никаких проблем с его использованием не возникает, ибо не возникает мысли его зачем-то копировать в рамках этого же HTML.
A>пара-тройка лет плотной работы с разметкой отучает пользоваться id в тех местах, где он не требуется стандартом, а в тех, где требуется — думать о замене.
Можно примеров? Чтоб элемент действительно был единственным по замыслу, и замысел впоследствии не изменился, однако потребность в создании дополнительных экземпляров таки возникла.
A>неявное инстанцирование станет явным.
Если будет механизм явного порождения экземпляров, он будет порождать и их идентификаторы. Иначе никак.
A>прежде, чем критиковать, надо понять, как нужно было сделать правильно
Я критиковал не саму идею использования шаблонов, а прежде всего утверждение, что присвоение id любому элементу якобы автоматически делает из него синглон (как концепцию).
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Можно примеров? Чтоб элемент действительно был единственным по замыслу, и замысел впоследствии не изменился, однако потребность в создании дополнительных экземпляров таки возникла.
Например, закольцовывание в слайдере, когда из загруженных в него элементов невидимым остаётся один. Как в детской "садюжке": слева пол-Пети и справа пол-Пети
Ты скажешь: "пререндеринг", а я скажу: элементы с видео и с анимациями. Ссылку не дам по соображениям приватности, но пример из жизни.
А так, хорошие примеры, как ни парадоксально, именно мне привести трудно: зная, во что это может вылиться, я принимаю превентивные меры, и спотыкаюсь о такие примеры крайне редко.
ЕМ>Я критиковал не саму идею использования шаблонов, а прежде всего утверждение, что присвоение id любому элементу якобы автоматически делает из него синглон (как концепцию).
<!-- Создаём инстанс простого типа -->
<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'я может быть инстансом, порождённым шаблонизатором (или закольцованным слайдером)? В этом всё дело? Я бы поставил на этот пункт
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>закольцовывание в слайдере, когда из загруженных в него элементов невидимым остаётся один. A>Ты скажешь: "рендеринг"
Нет, я скажу, что по замыслу это не является синглтоном. Не понимаю, почему Вы упорно смешиваете то, что задумано изначально, с тем, что может получиться в частном случае.
A>Что тебя смущает?
В самой идее с шаблонами — ничего. Но, коль их стандартной реализации нет, а все делается руками через JS, то нет никакой разницы, во что оборачивать содержимое шаблона — в template, или в любой самодельный тэг, как присваивать идентификаторы, как подставлять параметры и т.п. И нет никаких оснований называть это именно "шаблоном", а не каким-нибудь "образцом".
Здравствуйте, Евгений Музыченко, Вы писали:
A>>закольцовывание в слайдере, когда из загруженных в него элементов невидимым остаётся один. A>>Ты скажешь: "рендеринг"
ЕМ>Нет, я скажу, что по замыслу это не является синглтоном. Не понимаю, почему Вы упорно смешиваете то, что задумано изначально, с тем, что может получиться в частном случае.
Как это не является? Человек думает: Я ТОЧНО ЗНАЮ, что эта конструкция уникальна и будет таковой всегда. Потом её оказывается нужно вставить в слайдер. И внезапно выясняется, что предположение не подтвердилось. Это классическая грабелька, на которую наступает не только каждый, кто создаёт явные синглтоны, но и каждый, кто сознательно не уничтожает неявные.
Что можно сделать в этой ситуации? Если связь динамическая, прописывается в коде, то хоть полноценных квалификаторов к селекторам и нет, можно задать исходную точку и направление для поиска вверх или вниз (в терминологии jQuery это .parents()/.find()). Если заморочиться и таким образом убрать неявный синглтон, можно решить часть проблем. Но не следующую: что делать, когда стандарт разметки прямо предписывает создавать связи через уникальные идентификаторы.
Что и послужило основанием для создания этой темы.
A>>Что тебя смущает?
ЕМ>В самой идее с шаблонами — ничего. Но, коль их стандартной реализации нет, а все делается руками через JS, то нет никакой разницы, во что оборачивать содержимое шаблона — в template, или в любой самодельный тэг, как присваивать идентификаторы, как подставлять параметры и т.п. И нет никаких оснований называть это именно "шаблоном", а не каким-нибудь "образцом".
Ты же писал, что для синглтона нужны типы и инстансы, а без этого не может быть синглтона. И это было главное возражение. Я показал: вот типы, вот инстансы. Раз ты их сам не увидел.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>Человек думает: Я ТОЧНО ЗНАЮ, что эта конструкция уникальна и будет таковой всегда. Потом её оказывается нужно вставить в слайдер.
Это означает, что человек думал одно, а озвучил (хотя бы для себя) другое. Перепутал термины, или сам толком не понимал, что под ними имеется в виду.
Поэтому, если нет уверенности в точном понимании терминов, лучше избегать их. Вместо "синглтон" говорить "элемент данных, для которого достаточно единственного экземляра".
A>И внезапно выясняется, что предположение не подтвердилось. Это классическая грабелька, на которую наступает не только каждый, кто создаёт явные синглтоны, но и каждый, кто сознательно не уничтожает неявные.
В первую очередь на такие грабли наступают те, кто чрезмерно увлекается модными терминами в ущерб описательности.
Поймите, не бывает никаких "неявных синглтонов". Синглтон — понятие проектирования, а не реализации. Такие понятия принципиально не могут возникнуть само собой, они могут быть только задуманы. Так же, как в природе не могут возникнуть реальные объекты "куб", "шар" или "эллипсоид" — это абстрактные понятия, которые могут быть созданы только разумом.
A>что делать, когда стандарт разметки прямо предписывает создавать связи через уникальные идентификаторы.
То же, что и всегда: если стандарт позволяет решить задачу стандартными средствами — использовать их, иначе — выходить за пределы стандарта, стараясь действовать разумно.
A>Ты же писал, что для синглтона нужны типы и инстансы, а без этого не может быть синглтона. И это было главное возражение. Я показал: вот типы, вот инстансы.
Вы поставили телегу впереди лошади. В случае синглтона первична его идея, а типы/экземпляры — способы ее реализации. У Вас же получилось рассуждение "вот элемент, который мог бы быть синглтоном, из чего я заключаю, что это синглтон и есть".
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Поймите, не бывает никаких "неявных синглтонов". Синглтон — понятие проектирования, а не реализации. Такие понятия принципиально не могут возникнуть само собой, они могут быть только задуманы.
Так они и были задуманы. Тем чуваком, который придумал ввести id в HTML сто лет тому назад. Он создал этот паттерн проектирования. А когда кто-то пользуется этим атрибутом, он реализует этот паттерн в своём коде.
Конечно, это понятие проектирования. Конечно, такие вещи не берутся ниоткуда. Кто бы спорил.
A>>что делать, когда стандарт разметки прямо предписывает создавать связи через уникальные идентификаторы. ЕМ>То же, что и всегда: если стандарт позволяет решить задачу стандартными средствами — использовать их, иначе — выходить за пределы стандарта, стараясь действовать разумно.
Это был риторический вопрос. Когда мы попадаем в такую ситуацию, уже немного поздно ими задаваться.
Настоящий же вопрос, который почему-то игнорируется (я думаю, это потому, что на него ответить труднее, чем спорить о словах) таков. Как надо было спроектировать HTML, чтобы не наступать на эти грабли, возможно ли это в принципе, и если да — какой ценой (какие грабли мы получаем взамен).
A>>Ты же писал, что для синглтона нужны типы и инстансы, а без этого не может быть синглтона. И это было главное возражение. Я показал: вот типы, вот инстансы.
ЕМ>Вы поставили телегу впереди лошади. В случае синглтона первична его идея, а типы/экземпляры — способы ее реализации. У Вас же получилось рассуждение "вот элемент, который мог бы быть синглтоном, из чего я заключаю, что это синглтон и есть".
Ну вот. Теперь уже идея. А было написано:
Нет. Синглтон — это тип/класс объекта
Возражение и аргумент, и аргумент даже выделен болдом. Короче, я свою часть выполнил, показал, где тут тип/класс, и могу умыть руки.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
ЕМ>>не бывает никаких "неявных синглтонов". Синглтон — понятие проектирования, а не реализации. Такие понятия принципиально не могут возникнуть само собой, они могут быть только задуманы.
A>Так они и были задуманы. Тем чуваком, который придумал ввести id в HTML сто лет тому назад.
Нет.
A>Он создал этот паттерн проектирования.
Это не "паттерн проектирования". Если Вам настолько трудно обойтись без того, чтобы щегольнуть модным термином, разберитесь хотя бы со значением каждого из них.
A>Как надо было спроектировать HTML, чтобы не наступать на эти грабли
На тот момент, когда возникла идея сделать HTML, и толком не было понятно, что из этого получится, будет ли оно развиваться, а если будет, то куда и как, практически все варианты были равнозначны. На каждом следующем этапе был выбор — дорабатывать то, что есть, или переделывать с нуля. Даже сейчас вряд ли кто-то возьмется делать заново, ибо через каких-нибудь лет пять все опять может сильно поменяться.
На мой взгляд, куда более насущный вопрос — это накойхер нужен CSS там, где применяется развесистый JS. CSS хорош для "пассивных" страниц, где JS или нет вообще, или он применяется очень аккуратно и локально. Там, где JS генерит почти все содержимое страницы, в CSS нет никакого смысла — куда логичнее иметь простые (ненаследуемые) стили, и ссылаться на них из тэгов HTML (с возможностью объединения нескольких стилей).
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> ЕМ>Нет.
Эх, Евгений, Евгений... Я пишу развёрнутые аргументированные ответы с примерами кода, а в ответ получаю "Нет" и пару смайлов. Сдаётся мне, наш обмен неравноценен! )
ЕМ>На мой взгляд, куда более насущный вопрос — это накойхер нужен CSS там, где применяется развесистый JS.
Это называется: "Мне нечего сказать по обсуждаемой теме, поэтому давайте поговорим на мою".
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A> Так они и были задуманы. Тем чуваком, который придумал ввести id в HTML сто лет тому назад. Он создал этот паттерн проектирования. А когда кто-то пользуется этим атрибутом, он реализует этот паттерн в своём коде.
У тебя с терминологией путаница. Id — это идентификатор. Он используется для уникальной идентификации и потому единственный. А паттерн синглтон — это в первую очередь про глобальное состояние.
А по твоей логике каждый сгенерённый uuid или git-коммит — синглтоны.
По сабжевому вопросу — ну наверное можно использовать что-то вроде xpath для навигации. Но неясно как обеспечивать то, что xpath вернёт только один элемент.
Скажем, пишешь некий <label for="???"> и что делать, если этих самых "???" несколько, кому фокус отдавать?!
Здравствуйте, Alekzander, Вы писали:
A>Я пишу развёрнутые аргументированные ответы с примерами кода, а в ответ получаю "Нет" и пару смайлов.
Ну, если Вы полагаете, что весомость обоснования прямо пропорциональна объему текста и количеству примеров, то попробуйте прикинуть, какого объема/количества Вам будет достаточно от меня, чтоб согласится, например, с идеей божественного происхождения HTML, или с тем, что крокодил более длинный, чем зеленый.
A>Сдаётся мне, наш обмен неравноценен! )
Я несколько раз указал Вам на принципиальное несоответствие Вашей трактовки понятия "синглтон" его определению. Чего еще Вы от меня ждете?
ЕМ>>накойхер нужен CSS там, где применяется развесистый JS. A>Это называется: "Мне нечего сказать по обсуждаемой теме, поэтому давайте поговорим на мою".
Это как раз непосредственно по Вашей теме. Мне пока как раз хватает CSS в чистом виде, я не использую JS для создания/модификации содержимого страницы.
A>2а. Ссылаться при помощи связки "селектор + квалификатор" ("первый в документе", "первый наружу", "первый вглубь" и, может быть, даже "рандомный в найденном", лол). Тогда селекторы можно указывать относительно какого-то элемента.
Выглядит наиболее перспективным способом. Эдакий relative xpath или что-то в этом роде. (Дисклаймер: я гуем, в том числе и веб, не занимался со времён очаковских и покоренья крыма).
Что беспокоит: потенциальный разрыв между иерархией "скоупов" и иерархией "элементов".
Имеется в виду ситуация типа связи контрола с его лейблом. Логично считать, что пара инпут-лейбл входят в один скоуп "композитный контрол". Тогда можно было бы использовать ссылки в стиле "./label" и "./input", которые вполне себе однозначны из-за локальной уникальности. Но если вдруг вёрстка потребует, скажем, выводить контролы в табличке, где все метки — в одной строке, а все инпуты — в другой, то техническая иерархия будет совсем другой.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
