Javascript.RU

Создать новую тему Ответ
 
Опции темы Искать в теме
  #11 (permalink)  
Старый 05.02.2020, 00:55
Аватар для Malleys
Профессор
Отправить личное сообщение для Malleys Посмотреть профиль Найти все сообщения от Malleys
 
Регистрация: 20.12.2009
Сообщений: 1,714

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

Сообщение от Poznakomlus
Когда то import небыло, тем более parcel.
Да, не было import, однако это не значит, что нужно изобретать костыли, которые намертво прибивают ваш код к определённым инструментам, которые диктуют, как вам писать код. Был Google Closure Compiler, который вы можете использовать до сих пор.

Сообщение от voraa
Если постоянно думать о браузерах 5-ти летней давности и старше, то почти ни чем нельзя пользоваться.
В принципе можно! Если в пишете код, совместимый со стандартами, то его вполне можно преобразовать при помощи Google Closure Compiler, Babel, Webpack и пр. Однако если придерживаться точки зрения Poznakomlus, который предлагает переписать весь код под RequireJS, то он не понимает того, что он намертво привязан к RequireJS. Если я пишу код ECMAScript2020 и использую parcel, и вдруг оказывается, что что-то мне вдруг он не нравится, то я легко могу parcel заменить на Google Closure Compiler, а если и он мне вдруг не понравится, то я могу легко его заменить на webpack и т. д. А ещё есть rollup.

Сообщение от Poznakomlus
RequireJS works in IE 6+, Firefox 2+, Safari 3.2+, Chrome 3+, and Opera 10+.
Т. е. я вполне могу написать код, который работает в IE 5 или в Netscape Navigator, но благодаря RequireJS он перестанет там работать?! У инструментов, которые я вам перечислил, таких проблем нет!

Сообщение от Poznakomlus
это да, но веб-компоненты в пример мы ждем очень долго
Давай ты не будешь свой ожидания переносить на всех! Веб-компоненты уже поддерживаются во всех современных браузерах — https://caniuse.com/#feat=custom-elementsv1. Ещё о них — https://www.webcomponents.org/

Сообщение от Poznakomlus
мы ждем очень долго иначе большинство фреймворков пошло [бы] в утиль
Совсем нет! Например, веб-компоненты никак не заменяют работу с виртуальным DOM.

Сообщение от Poznakomlus
вы спрашиваете процент старых браузеров, я привел данные из документации это минимальные версии браузеров
Версии, которые тут же увеличатся, как только вы начнёте использовать нечто, чего нет в супер старинных браузерах. (Например, работа с <canvas>, SVG, шрифтами и пр.)

Сообщение от voraa
И почему ИЕ6, а не ИЕ4 или НетскэйпНавигатор
У него очевидно в детстве ничего кроме IE 6 не было. Мне например сразу не понравился IE 8 (или 7?), поскольку даже на моём первом телефоне (Sony Ericsson W580i) работало SVG и CSS применялся правильно и JavaScript работал, а IE часто показывало только пустую белую страницу с обрывками текста!

Сообщение от voraa
Но сайтопрограммеры почему то принуждают себя (или принуждаются) к этому.
Я к ничему такому не принуждаю себя! Для меня всегда была важна поддержка браузерами стандартов, а IE это делал очень-очень плохо. Даже 10 лет назад были альтернативы, которые делали это лучше, чем IE. Сегодня нам не нужно оглядываться на эту ошибку Microsoft. Люди сегодня практически его не используют, поскольку в нём большинство сайтов не работает, да и устройства и ОС заменяют на новые, где его уже нет!

Последний раз редактировалось Malleys, 05.02.2020 в 01:00.
Ответить с цитированием
  #12 (permalink)  
Старый 05.02.2020, 01:35
Аватар для Aetae
Тлен
Отправить личное сообщение для Aetae Посмотреть профиль Найти все сообщения от Aetae
 
Регистрация: 02.01.2010
Сообщений: 6,520

Сообщение от voraa Посмотреть сообщение
Ну представьте, если бы производители игр (или более нужных программ) ориентировались на Вин-95 на Пентиуме-4?
Сейчас производители игр ориентируются на консоли. Которые всегда устаревшие по характеристикам и с геймпадами как основным устройством ввода, что, соответственно, тормозит развитие графония и примитизирует интерфейсы. Увы.
__________________
29375, 35
Ответить с цитированием
  #13 (permalink)  
Старый 05.02.2020, 09:32
Аватар для voraa
Профессор
Отправить личное сообщение для voraa Посмотреть профиль Найти все сообщения от voraa
 
Регистрация: 03.02.2020
Сообщений: 2,720

Сообщение от Malleys Посмотреть сообщение
В принципе можно! Если в пишете код, совместимый со стандартами, то его вполне можно преобразовать при помощи Google Closure Compiler, Babel, Webpack и пр. Однако если придерживаться точки зрения Poznakomlus, который предлагает переписать весь код под RequireJS, то он не понимает того, что он намертво привязан к RequireJS. Если я пишу код ECMAScript2020 и использую parcel, и вдруг оказывается, что что-то мне вдруг он не нравится, то я легко могу parcel заменить на Google Closure Compiler, а если и он мне вдруг не понравится, то я могу легко его заменить на webpack и т. д. А ещё есть rollup.

Т. е. я вполне могу написать код, который работает в IE 5 или в Netscape Navigator,
Код то вы перенесете. И то не весь. Вы уже писали про canvas, но есть еще всякие прокси, типизированные массивы (они могут быть промоделированы, но теряется главное, для чего они были задуманы - скорость). Даже классы переносятся не на 100% (например наследование от Array)
Но сайт это не только Javascript, это еще и HTML и CSS. С ними то как быть?
Ответить с цитированием
  #14 (permalink)  
Старый 05.02.2020, 12:29
Аватар для Vlasenko Fedor
Профессор
Отправить личное сообщение для Vlasenko Fedor Посмотреть профиль Найти все сообщения от Vlasenko Fedor
 
Регистрация: 13.03.2013
Сообщений: 1,572

Malleys, Google Closure Compiler, каим боком к import относится
Сообщение от Malleys
Если я пишу код ECMAScript2020 и использую parcel, и вдруг оказывается, что что-то мне вдруг он не нравится, то я легко могу parcel заменить на Google Closure Compiler
Разберитесь это разные сервисы и либы. У них абсолютно разные назначения и функционал.
Сообщение от Malleys
У него очевидно в детстве ничего кроме IE 6 не было
конечно не было, не было и IE 6. Ведь это был MK53,Специалист
У тех библиотек которые вы предлагаете есть версии совместимости(минимальные) так-же.
Сообщение от Malleys
Я к ничему такому не принуждаю себя! Для меня всегда была важна поддержка браузерами стандартов, а IE это делал очень-очень плохо. Даже 10 лет назад были альтернативы, которые делали это лучше, чем IE. Сегодня нам не нужно оглядываться на эту ошибку Microsoft. Люди сегодня практически его не используют, поскольку в нём большинство сайтов не работает, да и устройства и ОС заменяют на новые, где его уже нет!
Malleys, не стоит тролить мелгомягких, это их бизнес и им решать. Они при этом еще и зарабатыают неплохо. В качестве примера я привел sandbox системы где вполне будет использоватся старая версия браузера и у вас не будет возможность ничего с ней поделать.
Сообщение от Malleys
Совсем нет! Например, веб-компоненты никак не заменяют работу с виртуальным DOM.
Виртуальный DOM и двойной датабиндинг был бы реализован в них. И мой прогноз, что лучшии из этих технологий реализуют в языке.

Я переписывать ничего не предлагал, зачем вы сочиняете от моего имени?
Не нравится мое мнение, что скажите про 12 тысяч других. Или это тоже не аргумент?
Научитесь считатся с мнениями других. Мы все в жизни ошибаемся, в любых сферах. Но учитывать , обращать на мнения доугих стоит. Они могут быть правильными или неправильными в вашем понимании (но рассмотреть и учитывать их нужно, с вашими весами). Глядишь через какой-то промежуток времени помеяется взгляд.

Последний раз редактировалось Vlasenko Fedor, 05.02.2020 в 12:31.
Ответить с цитированием
  #15 (permalink)  
Старый 05.02.2020, 14:53
Аватар для Malleys
Профессор
Отправить личное сообщение для Malleys Посмотреть профиль Найти все сообщения от Malleys
 
Регистрация: 20.12.2009
Сообщений: 1,714

Сообщение от voraa
Вы уже писали про canvas, но есть еще всякие прокси, типизированные массивы (они могут быть промоделированы, но теряется главное, для чего они были задуманы - скорость). Даже классы переносятся не на 100% (например наследование от Array)
Но сайт это не только Javascript, это еще и HTML и CSS. С ними то как быть?
Для всего этого есть полифилы, да, в старых браузерах работает медленней, но и сами старые браузеры работают медленней в общем.

Далее для Poznakomlus...
Сообщение от Poznakomlus
Google Closure Compiler, каким боком к import относится
Самым прямым, он (почти?) полностью поддерживает синтаксис JavaScript. Да и вообще практически все такие инструменты давно уже поддерживают import.
Сообщение от Poznakomlus
У них абсолютно разные назначения и функционал.
У них полностью одно и тоже назначение — преобразование кода.

Сообщение от Poznakomlus
не стоит троллить мелкомягких, это их бизнес и им решать.
Они зарабатывают явно не из-за IE 6–8, которые они больше не поддерживают! Современный Microsoft — это совсем другое дело, а вы, что-то всё мечтаете о старом Microsoft с «хрюшами» и IE 6.

Сообщение от Poznakomlus
Виртуальный DOM и двойной датабиндинг был бы реализован в них. И мой прогноз, что лучшии из этих технологий реализуют в языке.
Я не вижу никакой практической пользы от того, что в браузерное API будет внедрена какая-то библиотека, которая решает какой-то частный случай, даже если вам кажется, что это очень полезно. Когда-то некоторые грезили, что в браузерах будет jQuery, но совершенно непонятно, зачем там нужна обвязка вокруг уже существующего API.

И почему виртуальный DOM должен реализован внутри веб-компонент? Разве веб-компонент не должен быть представим при помощи виртуального DOM (конечно же должен, что мы и видим, используя, например, React), как и все остальные HTML-элементы. И вообще идея виртуального DOM заключается в том, что есть некий объект o1, который описывает, как должен выглядеть реальный DOM без привязки к нему. После некого изменения появляется другой объект o2, который сравнивается с o1. Различия применяются к реальному DOM. Это один из способов изменения реального DOM, но совершенно непонятно, зачем внутри веб-компонент нужна обвязка вокруг уже существующего API.

Не нужно решая проблемы всё время добавлять новый синтаксис или библиотеки в ядро языка.

Вы написали, что ждёте «веб-компоненты». Не совсем понятно, что заключается в «ожидании». Они уже поддерживаются во всех современных браузерах. Скорей вы предполагаете, что они должны делать совсем не то, для чего они предназначены.

Сообщение от Poznakomlus
качестве примера я привел sandbox системы где вполне будет использоватся старая версия браузера
И что мешает исправить? Неужто то самое «рꙋкожопіе»!

Сообщение от Poznakomlus
И мой прогноз, что лучшии из этих технологий реализуют в языке.
На примере самоволки от IE достаточно научится тому, чтобы не выстреливать второй раз по ногам.

Сообщение от Poznakomlus
Я переписывать ничего не предлагал, зачем вы сочиняете от моего имени?
А разве там import будет работать? Нет? Ну значит придется переписать код в «говнокод», чтобы заработало! Твои призывы к использованию RequireJS как раз равносильны тому, как если бы ты так и сказал — «перепиши и заработает».

Сообщение от Poznakomlus
Не нравится мое мнение, что скажите про 12 тысяч других.
А что, каждое твоё мнение должно восхвалятся и высоко почитаться?
Сообщение от Poznakomlus
Научитесь считатся с мнениями других.
Т. е. вы ожидаете, чтобы вам оказывали почести?
Сообщение от Poznakomlus
Мы все в жизни ошибаемся, в любых сферах.
А это уже как некий культ Феди! Культ «Ѳеодоръ»
Сообщение от Poznakomlus
Они могут быть правильными или неправильными в вашем понимании (но рассмотреть и учитывать их нужно, с вашими весами).
Ещё и цензура?! Твоё священное мнение может нравиться, а может и нет, но оно никак не может быть «неправильным». Другое дело если вы захотели обманом и всякими хитростями выдать желаемое за действительное (например, «все, что вамъ нꙋжно длѧ разработки днѧ сего IE6 jQuery RequireJS Ѳеодоръ рекомендꙋетъ»), но это уже искусство.

Последний раз редактировалось Malleys, 05.02.2020 в 14:57.
Ответить с цитированием
  #16 (permalink)  
Старый 05.02.2020, 15:03
Аватар для Vlasenko Fedor
Профессор
Отправить личное сообщение для Vlasenko Fedor Посмотреть профиль Найти все сообщения от Vlasenko Fedor
 
Регистрация: 13.03.2013
Сообщений: 1,572

Malleys,
ты троль точка
Ответить с цитированием
  #17 (permalink)  
Старый 05.02.2020, 15:50
Аватар для voraa
Профессор
Отправить личное сообщение для voraa Посмотреть профиль Найти все сообщения от voraa
 
Регистрация: 03.02.2020
Сообщений: 2,720

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

Далее для Poznakomlus...
Самым прямым, он (почти?) полностью поддерживает синтаксис JavaScript. Да и вообще практически все такие инструменты давно уже поддерживают import. У них полностью одно и тоже назначение — преобразование кода.
Какие полифилы? Вы о чем? Назовите мне полифил для прокси? Назовите мне полифил для правильного наследования Array?
Какой полифил для css position:sticky; ?

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

Google Closure Compiler вообще не при чем ту. Он только сжимает существующий код без всяких преобразований, типа заменим эту функцию на две другие. (И то тут столкнулся, что свежий Compiler не справляется с новыми синтаксическими конструкциями Javascript, которые уже реализованы в Хроме)

Сообщение от Malleys Посмотреть сообщение
Я не вижу никакой практической пользы от того, что в браузерное API будет внедрена какая-то библиотека, которая решает какой-то частный случай, даже если вам кажется, что это очень полезно.
Но тем не менее так делалось. Те же Promise были раньше по разному реализованы в библиотеках, прежде чем войти в язык. И всякие forEach, map... тоже были как отдельные библиотеки, прежде, чем стали стандартом API.
Ответить с цитированием
  #18 (permalink)  
Старый 06.02.2020, 10:54
Аватар для Malleys
Профессор
Отправить личное сообщение для Malleys Посмотреть профиль Найти все сообщения от Malleys
 
Регистрация: 20.12.2009
Сообщений: 1,714

Сообщение от voraa
Те же Promise были раньше по разному реализованы в библиотеках, прежде чем войти в язык. И всякие forEach, map... тоже были как отдельные библиотеки, прежде, чем стали стандартом API.
Класс Promise, методы forEach, map, filter, reduce и пр. для работы с массивами не «решают какой-то частный случай», они могут быть использованы для широкого круга задач, также они были уже реализованы во многих языках до того, как появились в JS. Такое полезно в любом окружении, включая браузер.

А VDOM — это узкая задача, что именно будет улучшено в ядре? Какой широкий спектр задач удастся решать? Какие примеры реализации в других языках программирования? Непредвзятые ответы «нет», а значит достаточно библиотеки. (Или вы мечтаете, что в ядро однажды будет включен весь NPM-регистр?)

Сообщение от voraa
Мы используем новые возможности новых браузеров, что бы работало быстро. И зачем их пихать в старые браузеры, если они станут работать медленнее из-за их интерпретации, чем если бы мы решали эту задачу по-другому сразу используя возможности только старых браузеров.
Разработчики скорей всего не задумываются, что новые возможности, которые работают хорошо в новых браузерах, начинают работать там же чуть хуже (или совсем хуже и требуют больше памяти, процессорного времени) после преобразования кода в ES3. Однако возможно код ES2020, который работает в современных браузерах не преобразовывать (только минификация), или преобразовать до ES2018 или ES2016, что не так критично. А старым браузерам давать тот самый ES3. Это возможно благодаря атрибуту nomodule у элемента <script>

<script type="module" src="app.js"></script>
<script nomodule src="fallback-app.js"></script>
Поскольку все современные браузеры понимают type="module" и игнорируют скрипты с nomodule, то в них будет загружен app.js. А поскольку старые браузеры игнорируют скрипты с неправильным type и не понимают nomodule, то в них будет загружен fallback-app.js.

Сообщение от voraa
Какие полифилы? Вы о чем? Назовите мне полифил для прокси? Назовите мне полифил для правильного наследования Array?
Какой полифил для css position:sticky; ?
Достаточно широкий круг возможностей доступен в старых браузерах благодаря Polyfill service — https://polyfill.io/v3/url-builder/ Хотя он всё меньше нужен становится.

Если вам в проекте так критически важно «правильное наследование Array», то ведь не сложно добавить одну строчку с __proto__ в объявлении класса (__proto__ широко доступен с 2010–2013 годов) https://caniuse.com/#feat=mdn-javasc...s_object_proto

«Хочу, чтобы всё работало в IE6» выглядит как теоретический бред, который не несёт никакого практического смысла — Proxy работает во всех современных браузерах с 2015–2016 годов — https://caniuse.com/#feat=mdn-javascript_builtins_proxy Этого вполне достаточно, даже если вы обновляете браузер раз в полтора года!

position: sticky; работает с 2014–2017 годов, в основном ничего не ломается, если не поддерживается. Частное решение — position: fixed; Учитывая, что есть @supports, который поддерживается с 2013–2015 годов (https://caniuse.com/#feat=mdn-css_at-rules_supports), вы можете сделать альтернативное представление элемента для любителей старых браузеров!

А все эти ваши борьбы с системами, где по какой-то параноидальной причине запрещено обновить браузер 15-ти летней давности похожи на Специальную Олимпиаду. Сам же Microsoft активно призывает пользователей переезжать на новый Edge. https://www.microsoft.com/en-us/edge

Также может не стоит исключать SSR, но всё зависит от того, что вы делаете. Например, если делаешь что-то с использованием WebGL, как не крути не трансформируй код, и не придумывай фантастические полифилы, а WebGL в первую очередь должен поддерживаться!

Сообщение от voraa
Google Closure Compiler вообще не при чем ту. Он только сжимает существующий код без всяких преобразований, типа заменим эту функцию на две другие. (И то тут столкнулся, что свежий Compiler не справляется с новыми синтаксическими конструкциями Javascript, которые уже реализованы в Хроме)
Может всё зависит от того, с какими аргументами вы его запускаете? В первую очередь он для стандартного JS. Вам нужно съездить в Вавилон для экспериментов.
Ответить с цитированием
  #19 (permalink)  
Старый 06.02.2020, 12:23
Аватар для voraa
Профессор
Отправить личное сообщение для voraa Посмотреть профиль Найти все сообщения от voraa
 
Регистрация: 03.02.2020
Сообщений: 2,720

Сообщение от Malleys Посмотреть сообщение
Достаточно широкий круг возможностей доступен в старых браузерах благодаря Polyfill service — https://polyfill.io/v3/url-builder/ Хотя он всё меньше нужен становится.
Прокси даже с Бабилоном не поддерживаются https://kangax.github.io/compat-table/es6/
Сообщение от Malleys Посмотреть сообщение
Это возможно благодаря атрибуту nomodule у элемента <script>
Т.е. писать двойной код. Отдельно для старого, отдельно для нового.
Но если одинаково хорошо работает и там и там, то зачем нужен новый?
Вот только что наткнулся, что оказывается даже edge 18 не поддерживает в css rgba(0,0,0,50%). И никакой бабилон, или вебпак тут не помогут. Перетряхивать весь код и приводить к какому то старому варианту. А зачем тогда новый нужен?

Сообщение от Malleys Посмотреть сообщение
Если вам в проекте так критически важно «правильное наследование Array», то ведь не сложно добавить одну строчку с __proto__ в объявлении класса (__proto__ широко доступен с 2010–2013 годов) https://caniuse.com/#feat=mdn-javasc...s_object_proto
Это не спасает. Что я не делал наследования и с помощью __proto__?
Многое наследуется, но a[i] = x не изменяет length, если i больше.
Такое возможно только при наследовании с классами. Там немного другой механизм.

Сообщение от Malleys Посмотреть сообщение
А все эти ваши борьбы с системами, где по какой-то параноидальной причине запрещено обновить браузер 15-ти летней давности похожи на Специальную Олимпиаду. Сам же Microsoft активно призывает пользователей переезжать на новый Edge. https://www.microsoft.com/en-us/edge
Это не моя борьба. Я то как раз предлагаю послать их куда подальше. Кто не обновляет - ну значит не нужно ему новые сайты смотреть.

Хуже когда и совершенно новые браузеры не следуют стандартам и творят хрен знает что. Тут уже больше недели трахаюсь с FF (совершенно свежая 72 версия) что они там с pointer events творят!
Тут прочитал на бугзиле их переписку (месячной давности) по этой теме (Правда она наверно относится к мобильной версии). Так они там с удивлением обнаруживают, что оказывается Хром (и даже Едж 18) производят захват событий! Оказывается! А стандарты и спецификации не дано посмотреть? Потом обсуждения про то, что НЕОЖИДАННО вылетает событие pointercancel.... Так у меня и на десктопе в 72 версии FF тоже самое! А десктопная версия в caniuse отмечена как полностью рабочая. Начинаю хренеть с поделки под названием firefox.
Ответить с цитированием
  #20 (permalink)  
Старый 06.02.2020, 15:40
Аватар для Malleys
Профессор
Отправить личное сообщение для Malleys Посмотреть профиль Найти все сообщения от Malleys
 
Регистрация: 20.12.2009
Сообщений: 1,714

Сообщение от voraa
Прокси даже с Бабилоном не поддерживаются
Так всё правильно, это реализуется на уровне движка. Смотрите правее в той же таблице — поддерживается во всех последних браузерах. Не поддерживается в Babel — значит он никак не меняет такой код, что и не нужно поскольку так и так поддерживается во всех браузерах.

Сообщение от voraa
Т.е. писать двойной код. Отдельно для старого, отдельно для нового.
Нет! Скорей разные сборки — ES2020 и ES3 + может плагины и полифилы и затычки и скрывалки.

Сообщение от voraa
даже edge 18 не поддерживает в css rgba(0,0,0,50%).
Сообщение от voraa
Перетряхивать весь код
Stylus или SCSS в помощь

Сообщение от voraa
Это не спасает. Что я не делал наследования и с помощью __proto__?
Многое наследуется, но a[i] = x не изменяет length, если i больше.
Такое возможно только при наследовании с классами. Там немного другой механизм.
Синтаксис классов — это синтаксический сахар для функции и prototype. Никакого особого механизма нет. Вот, например...
{
	class ArrayFiller extends Array {
		constructor(count, filler) {
			super(count);
			this.fill(filler);
		}
		/* остальные методы */
	}

	const af = new ArrayFiller(5, "a");
	console.log(af.length); // 5
	af[10] = "b";
	console.log(af.length); // 11
	af.length = 1;
	console.log(af); // ArrayFiller ["a"]
	console.log(af instanceof ArrayFiller); // true
}

равносильно...
{
	function ArrayFiller(count, filler) {
		var af = new Array(count);
		af.__proto__ = ArrayFiller.prototype;
		af.fill(filler);
		return af;
	}

	ArrayFiller.prototype = {
		__proto__: Array.prototype,
		constructor: ArrayFiller
		/* остальные методы */
	};

	var af = new ArrayFiller(5, "a");
	console.log(af.length); // 5
	af[10] = "b";
	console.log(af.length); // 11
	af.length = 1;
	console.log(af); // ["a"]
	console.log(af instanceof ArrayFiller); // true
}
Такой же способ использовался в Chrome DevTools для наследования от HTMLDivElement и пр. HTML-элементов.

Последний раз редактировалось Malleys, 06.02.2020 в 15:43.
Ответить с цитированием
Ответ



Опции темы Искать в теме
Искать в теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Вывыод контента через JS inet_boy Элементы интерфейса 0 18.11.2013 03:00
Ошибка в коде Js, Неправильно работает скрипт. Julia Panatova Общие вопросы Javascript 1 19.01.2011 14:12
Ошибка в коде Js, Неправильно работает скрипт. Julia Panatova Общие вопросы Javascript 7 07.01.2011 13:41
Вопрос про подключение js prog90 Общие вопросы Javascript 4 03.01.2011 18:48
подключение стороннего js скрипта friend Общие вопросы Javascript 2 24.05.2008 19:51