Вот когда в конце ссылки на картинку будет стоять не ***.jpg, а ***.htm, тогда и о "слабо" в данном случае можно будет говорить.
41. RadChand2009/06/17 14:00
[ответить]
Гы! Ну вы, батенька, извращенец, однако.
А такую сделать слабо? ;) (смотреть издали)
И еще: (ASCII Art)
40. * (tbam1@rambler.ru) 2008/09/08 22:30
[ответить]
Передача картинки непосредственно в виде кода HTML делает графику практически не отключаемой. Сценарии же JavaScript отключаются так же легко, как и графика. Кроме этого их функциональные возможности сильно зависят от настроек безопасности браузера. Хотя JavaScript изначально не предназначался для формирования и отображения собственной графики его действительно все же можно приспособить для работы в качестве графического редактора. В качестве примера смотрите сценарии JavaScript в статьях: или Однако при тестировании этих сценариев выяснилось, что они работают по разному даже в одинаковых браузерах, но различных версий. При больших объемах вычислений начинают появляться сообщения о перегрузке браузера, а при декодировании графического объекта объемы вычислений всегда будут большими.
В связи с этим, ради повышения надежности срабатывания сценария, пришлось даже отказаться от автоматического перезапуска сценария. Таким образом, использования в теле HTML документов сценариев JavaScript для кодирования - декодирования графических объектов приведет к крайне ненадежному отображению графики на страницах HTML.
38. Incur2008/07/09 15:48
[ответить]
В формате MSWord картинка хранится в виде байтового кода, все в одном файле с текстом (текст кстати тоже закодирован :). MSWord понимает что хранимый в тексте "код" - есть картинка, а также определяет ее графических формат и метод сжатия. После чего востанавливает (дешифрует) ее в изображение, которое мы и видим на экране в самом документе. Все алгоритмы (механизмы) дешифрации реализованы непосредственно в самом MSWord...
Вариант: Почему бы нам, для уменьшения объема трафика, не формировать HTML документ по аналогичной с вордом технологии... Т.е. Картинку можно передавать в обычном закодированном виде (например bmp) в теле HTML документа, но в дополнение в этом же документе передавать механизм дешифровки, например как JavaScript...
Примущества: уменьшение трафика + производительность при дешифровке зависит только от производительности "клиентского" компьютера.
37. Замечательное решение!2007/05/16 21:14
[ответить]
Вообще, это больше похоже на вирусный маркетинг. В этом плане - прекрасный способ привлечь посетителей на вашу страницу с целью конвертации трафика.
Только вот один недостаток - страница очень долго грузится. :)
35. (slkom@sao.ru) 2006/09/26 12:53
[ответить]
>>1.Калугин Владимир
>Браво! Потрясающая находка, правда, лично я еще не знаю, как ее можно применить "по-серьзеному".
хороший способ вставлять рекламу :-(
радует несовместимость...
34. Белов А.М.2005/07/04 14:10
[ответить]
Вроде никогда не говорил, что предлагаемая графика должна заменить все уже существующее. Графических форматов существует огромное количество и пока ни одного универсального. Предлагаемый формат так же предназначен для своей ниши.
К стати в html файлах имеется возможность применения очень скромного количества форматов рисунков. Так, что еще один явно не повредит.
Меньше всего думал, что предлагаемый формат рисунка можно применять при создании сайтов с обширной, да еще и подвижной графикой. Скорее всего, это должны быть статьи с небольшим количеством графиков и простых рисунков или странички, использующие неподвижные относительно небольшие рисунки. Для которых, важен принцип: одна статья - один файл.
Отказываться от фреймов или предлагаемой графики лишь потому, что существуют броузеры их не поддерживающие, по-моему, просто глупо. Это, по всей видимости, проблема уже тех, кто создает такие броузеры и тех, кто ими пользуется. Захотят иметь полную информацию, доработают или сменят броузер.
33. Graf'ich's returned 2005/07/02 02:12
[ответить]
>>32.Кошка Шпрота
>А чего ему удивляться? Классный пиар его статье...
>Даже с соседнего сервера пришли почитать :)))))))