Поле для drag&drop нужно делать, а не на кнопку кидать. Кидать на кнопку — это уже маразм какой-то…
Нет поддержки доступности (речевые технологии, тач-устройства, пульт телевизора).
Речевые?.. Вообще никак не знаком с этим. Как обычный input file с помощью речевых открыть?
Тач? Он не будет работать? Пальцем не попадёшь или что?
Телевизор? Меня интересует сейчас не поддержка телевизоров, а хранилище, с которого будут загружаться файлы. Тебе, как минимум, нужна флешка. Ситуация, наверно, будет такая: Ты идёшь к компу и скидываешь на флешку файлы, достаёшь из компа флешку и идёшь к телевизору, вставляешь её (а usb вход находится сзади, и тебе нужно еще попотеть, чтобы эту флешку вставить) в телевизор, и начинаешь тыкать пультом по форме… Товарищ, я смотрю вы знаете толк в извращениях. Хотя, я наверно не прав. Я подумаю на счёт этого…
Не отображается имя загруженного файла.
Как будто надо. Ты еще попроси превью изображения с функцией перетаскивания… Наша цель: быстро и просто.
Нет отображения ошибок (неверный формат файла, слишком большой размер).
Ну это не моя забота. Для проверки формы пишется отдельная функция, которая меня не касается, и разработчик её расширяет так, как ему вздумается. К примеру, у меня валидацию устраивает yii, и все у меня ошибки нормально отображаются.
Захардкоженные строки текста. Будут трудности с переводом.
На другой язык? Трудности… Трудности будут также для людей с ограниченными возможностями, для детей и для стариков. О каком переводе идёт речь? Для разных языков нужно писать разные сайты с нуля, придерживаясь законам основного дизайна. Писать один и тот же код для нескольких языков тоже самое, что делать резиновые сайты.
Негибкая вёрстка.
Грубые ошибки вёрстки (захардкоженный размер кнопки, не указано семейство шрифтов, не указан цвет фона,
Размер кнопки надо было в процентах указывать?
Слово Tahoma просто так написано? Для красоты?
Цвет фона указан. Он прозрачный.
Вот блин, цвет не контрастный. Чтож теперь делать? Этож обязательное правильно: использовать зелёный цвет. Иначе же форма работать не будет.
transition: all и? Что не так?
Лишняя зависимость от jQuery, когда в ней нет никакой острой необходимости.
Наличие формы, как бы уже подразумевает наличие jquery. Писать на голом javascript тоже самое, что купить машину и ходить пешком.
Не работает при выключенном (сломанном) яваскрипте.
Если яваскрипт у юзверя сломан, то он до моего input file даже не дойдёт. так что тут мне не о чем переживать.
А какие проблемы вы решали?
Внешний вид. На разных браузерах input кроме того, что страшный, так еще и везде разный. Хотелось бы придерживаться основному стилю/дизайну при разработке.
так я описал случай, когда между ними появляется еще один элемент. Мы обращаемся к родителю и у родителя, в дочках, ищем label. Всё просто.
А с чего вы взяли что это не перебор файла? Компьютер сразу знает, где у него находится label for=«id=input»? Ну ка, вспомни, как у тебя на компьютере работает поиск? Так я тебе напомню. Берётся название файла и проверяется это название с файлами на компьютере. Так и тут. Берётся документ (html) и проверяются все строчки на совпадение. Ты ради интереса создай web файл, который будет весить 1гб. И сделай потом label[for="(this).attr('id')"]. Зависло? Странно… Не должно…
Ты можешь сказать, что я утрирую, и что по факту у нас не будет документа в 1гб, и что разницы мы не ощутим между prev() и label for=«id=input», но хочу тебе сказать, а ты это тоже забыл. 100 рублей = 100 раз по 1 рублю. Так вот задержка в 1/100, которую мы, якобы, не ощутим, добавится к другим задержкам, что приведёт потом к тому, что мы тупо сидим и ждём, пока у нас комп сообразит, ибо таких обращений, типа abel for=«id=input», у нас немерено. А потом мы виним железо в зависаниях, виним хром, который много памяти жрёт, виним то, чего винить не должны. Ты не говнокодь, тогда нормально всё будет! Глюков не будет. Или другое сравнение: игры требовательны к железу. Они не требовательны, они просто не оптимизированы.Я на 1000% уверен, что можно оптимизировать любую игру и играть в неё на максимальных настройках графики на старом ПК 2004 года. А из-за таких, как ты, у нас всё на говне и держится. Всё лагает, зависает и требует ОЗУ.
На моём старом пк full HD видео на youtube лагает, просто fps падает. Видимо youtube писали такие, как ты… Спасибо тебе за web 2.0
Сейчас мне стыдно за ваш код. Я, конечно, профан в разработке, но поясните мне: на кой черт нужен var text_label_id = $(this).attr('id');? Мы все знаем, что var используют для обозначения того, или иного куска кода. Чтобы этот кусок стал короче и более понятен, мы используем var. Особенно он полезен, когда этот кусок кода встречается неоднократно, то объявление переменной — просто спасение. Но здесь… Здесь что-то новенькое. Вы только один раз использовали text_label_id, и сделали это, между прочем, на соседней строчке. И самое смешное, что вы дали ему название, которое по своей длине не особо-то и отличается от первоначального источника… $(this).attr('id'); = 19 символов. text_label_id = 13 символов. Оно того стоило?
А теперь поговорим про скорость, мой всё еще не менее дорогой друг.
Что быстрее .prev() или label[for="(this).attr('id')"]? Ну вот серьёзно, представь, что проще сделать?
Давай я для тебя аналогию проведу, а то, мне кажется, ты сразу не поймёшь мою мысль.
Вот смотри: допустим ты живёшь на 50-ом этаже многоэтажного дома. В квартире, к примеру, 297. И вот тебе по срочной необходимости понадобилась соль. Да, банальная такая соль. Ты знаешь, что соль может дать тебе твой сосед Вася, который живёт в соседней квартире на площадке твоего этажа, но номер квартиры забыл и посчитать не можешь. Но так как ты у нас очень педантичный человек, тебе обязательно нужно знать номер квартиры. И что делаешь ты? Ты выходишь из своей квартиры, спускаешься на первый этаж и начинаешь заходить во все квартиры, проверяя, живёт ли в этой квартире Вася. «Вася тут?» — обращаешься ты к жильцу квартиры номер 1. И так далее. Каждую, мать её, квартиру проверяешь. И потом уже, под вечер, когда ты дошел до 298 квартиры, где живёт наш Вася, ты просишь у него соль. Красаучик, ничего не сказать.
Вот и label[for="(this).attr('id')"] тоже самое. Начинаешь перебирать весь документ, в надежде найти label, у которого id равен id input. Ключевое слово, если ты не понял, здесь «весь документ».
ахаха))) спасибо, не заметил) новый язык, получается, изобрёл.
А по поводу зависимости. Сейчас на практике 99% сайтов используют jquery. Зачем сопротивляться тенденции?
…
Поле для drag&drop нужно делать, а не на кнопку кидать. Кидать на кнопку — это уже маразм какой-то…
Речевые?.. Вообще никак не знаком с этим. Как обычный input file с помощью речевых открыть?
Тач? Он не будет работать? Пальцем не попадёшь или что?
Телевизор? Меня интересует сейчас не поддержка телевизоров, а хранилище, с которого будут загружаться файлы. Тебе, как минимум, нужна флешка. Ситуация, наверно, будет такая: Ты идёшь к компу и скидываешь на флешку файлы, достаёшь из компа флешку и идёшь к телевизору, вставляешь её (а usb вход находится сзади, и тебе нужно еще попотеть, чтобы эту флешку вставить) в телевизор, и начинаешь тыкать пультом по форме… Товарищ, я смотрю вы знаете толк в извращениях. Хотя, я наверно не прав. Я подумаю на счёт этого…
Как будто надо. Ты еще попроси превью изображения с функцией перетаскивания… Наша цель: быстро и просто.
Ну это не моя забота. Для проверки формы пишется отдельная функция, которая меня не касается, и разработчик её расширяет так, как ему вздумается. К примеру, у меня валидацию устраивает yii, и все у меня ошибки нормально отображаются.
На другой язык? Трудности… Трудности будут также для людей с ограниченными возможностями, для детей и для стариков. О каком переводе идёт речь? Для разных языков нужно писать разные сайты с нуля, придерживаясь законам основного дизайна. Писать один и тот же код для нескольких языков тоже самое, что делать резиновые сайты.
Размер кнопки надо было в процентах указывать?
Слово Tahoma просто так написано? Для красоты?
Цвет фона указан. Он прозрачный.
Вот блин, цвет не контрастный. Чтож теперь делать? Этож обязательное правильно: использовать зелёный цвет. Иначе же форма работать не будет.
transition: all и? Что не так?
Наличие формы, как бы уже подразумевает наличие jquery. Писать на голом javascript тоже самое, что купить машину и ходить пешком.
Если яваскрипт у юзверя сломан, то он до моего input file даже не дойдёт. так что тут мне не о чем переживать.
Внешний вид. На разных браузерах input кроме того, что страшный, так еще и везде разный. Хотелось бы придерживаться основному стилю/дизайну при разработке.
А с чего вы взяли что это не перебор файла? Компьютер сразу знает, где у него находится label for=«id=input»? Ну ка, вспомни, как у тебя на компьютере работает поиск? Так я тебе напомню. Берётся название файла и проверяется это название с файлами на компьютере. Так и тут. Берётся документ (html) и проверяются все строчки на совпадение. Ты ради интереса создай web файл, который будет весить 1гб. И сделай потом label[for="(this).attr('id')"]. Зависло? Странно… Не должно…
Ты можешь сказать, что я утрирую, и что по факту у нас не будет документа в 1гб, и что разницы мы не ощутим между prev() и label for=«id=input», но хочу тебе сказать, а ты это тоже забыл. 100 рублей = 100 раз по 1 рублю. Так вот задержка в 1/100, которую мы, якобы, не ощутим, добавится к другим задержкам, что приведёт потом к тому, что мы тупо сидим и ждём, пока у нас комп сообразит, ибо таких обращений, типа abel for=«id=input», у нас немерено. А потом мы виним железо в зависаниях, виним хром, который много памяти жрёт, виним то, чего винить не должны. Ты не говнокодь, тогда нормально всё будет! Глюков не будет. Или другое сравнение: игры требовательны к железу. Они не требовательны, они просто не оптимизированы.Я на 1000% уверен, что можно оптимизировать любую игру и играть в неё на максимальных настройках графики на старом ПК 2004 года. А из-за таких, как ты, у нас всё на говне и держится. Всё лагает, зависает и требует ОЗУ.
На моём старом пк full HD видео на youtube лагает, просто fps падает. Видимо youtube писали такие, как ты… Спасибо тебе за web 2.0
А теперь поговорим про скорость, мой всё еще не менее дорогой друг.
Что быстрее .prev() или label[for="(this).attr('id')"]? Ну вот серьёзно, представь, что проще сделать?
Давай я для тебя аналогию проведу, а то, мне кажется, ты сразу не поймёшь мою мысль.
Вот смотри: допустим ты живёшь на 50-ом этаже многоэтажного дома. В квартире, к примеру, 297. И вот тебе по срочной необходимости понадобилась соль. Да, банальная такая соль. Ты знаешь, что соль может дать тебе твой сосед Вася, который живёт в соседней квартире на площадке твоего этажа, но номер квартиры забыл и посчитать не можешь. Но так как ты у нас очень педантичный человек, тебе обязательно нужно знать номер квартиры. И что делаешь ты? Ты выходишь из своей квартиры, спускаешься на первый этаж и начинаешь заходить во все квартиры, проверяя, живёт ли в этой квартире Вася. «Вася тут?» — обращаешься ты к жильцу квартиры номер 1. И так далее. Каждую, мать её, квартиру проверяешь. И потом уже, под вечер, когда ты дошел до 298 квартиры, где живёт наш Вася, ты просишь у него соль. Красаучик, ничего не сказать.
Вот и label[for="(this).attr('id')"] тоже самое. Начинаешь перебирать весь документ, в надежде найти label, у которого id равен id input. Ключевое слово, если ты не понял, здесь «весь документ».
А по поводу зависимости. Сейчас на практике 99% сайтов используют jquery. Зачем сопротивляться тенденции?