HTML+CSS+JavaScript

Здравствуйте!

Есть блоки сообщений со стрелочкой (speech bubbles). Стрелочка реализована с помощью псевдо элемента и ее цвет указан в css таким же, как и цвет фона блока. Это все замечательно работает, до тех пор, пока не нужно изменить цвет блока через javascript.
Собственно, проблема изменить цвет стрелки, после изменения цвета фона блока, сделать их одинаковыми.

Ссылка на пример: http://jsfiddle.net/gczse2nc/1/

а так? http://jsfiddle.net/gczse2nc/2/, в js добавить-убрать стиль

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

а этот цвет потом где будет храниться?

Он хранится в JS объекте, но и добавить его в какой-нибудь data атрибут блока не проблема.

Пользователь вышел-вошел и ему опять менять цвет на тот что ему нравиться?

Нет, зачем? Цвет хранится в настройках, настройки в базе. При входе настройки записываются в JS объект. Я думал вы имеете ввиду хранение в контексте страницы.

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

Для одного цвета и одного пользователя сложности никакой нет. Если пользователь решит выбрать другой цвет, он должен быть применен без перезагрузки страницы. Соответственно, нужно создавать новый класс для нового цвета, либо как-то править существующий. Еще большую сложность добавляет то, что динамически подгружаются сообщения других пользователей. Тут, кроме как, созданием новых отдельных классов, уже не отделаешься.

<script>  $(function() {     $('button').click(function() {         $('#over').remove();         $('span.text').css({background: $(this).text()});         $("body").append('<style id="over">.text:after{border-color: '+$(this).text()+' rgba(0,0,0,0);}</style>');     }); }); </script> <span class="text">Hello, World! This is just text for test</span> <button>Green</button> <button>Blue</button>

Спасибо. Тоже пришел примерно к такому же: http://jsfiddle.net/gczse2nc/4/. Но очень не нравится идея засорять стили.
Наверное, в моем случае, будет проще вместо псевдо элемента использовать обычный вложенный.

>не нравится идея засорять стили.

$('#over').remove(); - удаляется добавленный ранее.

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

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

Слишком много мороки для такой мелочи. Как я уже сказал, проще отказаться от псевдо элемента.

Что сложного то?

$(function() {     $('[id|=msg]').click(function() {         var id = this.id.split('-').pop(), color = '#'+Math.floor(Math.random()*16777215).toString(16);         $('#after'+id).remove();         $(this).css({background: color});         $("body").append('<style id="after'+id+'">.new'+id+':after{border-color:'+color+' rgba(0,0,0,0)}</style>');     }); }); <span id="msg-1" class="text new1">Hello, World! This is just text for test</span><br><br> <span id="msg-2" class="text new2">Hello, World! This is just text for test</span><br><br> <span id="msg-3" class="text new3">Hello, World! This is just text for test</span>

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

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

Так какая разница какие блоки - смысл в том, что нужно связывать нужный блок со стилем, а что это за блок, существующий или добавляемый новый сценарию по боку, какое определите, такие и будут изменяться. Если те, что приходят по асинхронному запросу, и они имеют цвет фона, то получить этот цвет и добавить псевдоэлемент привязанный к этому блоку со цветом фона, это не проблема.

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

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

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

Давайте рассуждать:

1) Есть ли смысл выбирать цвет из 16 млн.? Ответ очевиден - нет, ибо небольшая разница в оттенках цвета практически не будет заметна, и не на каждом цвете удобно будет читать. Это означает, что нужно подобрать набор цветов, как палитру для выбора.

2) Каждый пользователь, это уникальный идентификатор, который может служить частью имени класса блока (как у меня в примере ID: литеры-цифры). И хотя пользователь может менять цвет хоть каждую минуту (вряд ли он это будет делать), количество стилей на странице будет определять не количество блоков, а количество участников чата.

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

В данной задаче стиль блока и стиль пользователя понятия тождественные.

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

Есть ли смысл выбирать цвет из 16 млн.?

Разумеется, нет. Но число возможных вариантов все еще велико, чтобы говорить об ограниченной палитре. Так же, я еще не решил, можно ли будет менять цвет самого текста. Это может добавить контраста.
В общем, подход с палитрой я считаю для себя неприемлемым.

Ну а что касается получим кучу одинаковых стилей и, если это нежелательность иметь одинаковые цвета у различных пользователей, то кто же мешает определять цвет пользователя не пользователем, а сценарием?

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

Каждый пользователь, это уникальный идентификатор, который может служить частью имени класса блока (как у меня в примере ID: литеры-цифры). И хотя пользователь может менять цвет хоть каждую минуту (вряд ли он это будет делать), количество стилей на странице будет определять не количество блоков, а количество участников чата.

Это понятно, и такой вариант может стать для кого-то выходом. Но, я вижу его неудобным в использовании.
Нужно проверять существует ли уже такой стиль, если нет, то добавить. Потом, не забыть удалить стили при удалении сообщений. И прочее. Это усложнение ради усложнения. Которое имеет только один плюс, меньшее кол-во элементов в DOM. Но он не перевешивает минусов, поэтому в этой задаче, это решение я использовать не буду.

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

Но вот сначала пишет 5 сообщений зеленым, потом меняет цвет на красный и пишет еще 3 сообщения. В итоге, имеем 5 зеленых и 3 красных блоков одного и того же пользователя, может я что-то не понимаю в этой "цветомузыке", но действительно к чему такая пестрота, под текущие эмоции? :) Ну и над этим вопросом можно подумать, если так хочется.

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

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

Я бы не использовал такое тоже, не чат а разукрашка. )

>> эти вещи неразрывны - пользователь и его блоки

Тоже можно поспорить, если под "блоком" подразумевается, непосредственно, его цвет (стиль). Если пользователь не выбрал для себя индивидуальный цвет, значит блок будет иметь цвет по-умолчанию. Значит, пользователь, фактически, на блок никак не влияет.
Если пользователь выбрал один цвет, то его последующие сообщения будут иметь этот стиль. Связь присутствует, но если пользователь выберет потом другой цвет, связь с предыдущими сообщения и текущим состоянием пользователя теряется. Я попытался объяснить это на примере 5+3.

>> может я что-то не понимаю в этой "цветомузыке", но действительно к чему такая пестрота, под текущие эмоции?

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

Простой пример:
В чате сидят Ваня, Петя и Катя, и весело болтают. Ваня отошел на минутку, а Катя решила сменить цвет в это время. Когда Ваня вернется, у него может возникнуть замешательство от того, что когда он уходил, у Кати был один цвет, а когда вернулся, все сообщения стали другого цвета. Ему может показаться, что он сходит с ума. В моем же варианте, он может визуально проследить различия стиля сообщений Кати до его ухода и после, таким образом на подсознательном уровне осознав смену стиля Кати.

Или другой пример. Место тоже, герои те же. Только Ваня никуда не уходит.
Когда Катя сменит цвет своих сообщений, они автоматически изменят цвет всех сообщений Кати в браузере Вани и Пети. А если Катя захочет изменить цвет еще несколько раз (она же девочка, ей нужно перепробовать все, чтобы понять какой ей больше нравится), то вот где получится настоящая цветомузыка.

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

По поводу количества цветов. Много это понятие относительное. Для кого-то сто это много, а кому-то и миллиона мало. И я имел ввиду "много" для того, чтобы делать отдельную таблицу стилей для допустимых цветов. Я прекрасно понимаю, что делать палитру для 16 миллионов цветов это тоже излишне, возможно, я ограничу набор цветов каким-то алгоритмом, например, шагом тона. Но буду делать это потом, если возникнет необходимость. Преждевременная оптимизация это тоже зло. :)

Пседоэлементы находятся вне DOM-дерева и к ним нельзя обратиться как к другим HTML-элементам. Можно добавить класс, который описывает новое состояние псевдоэлемента и менять его. Либо динамически добавлять этот же описанный стиль в стили, тем самым переопределяя первый.