Pull to refresh

Comments 48

Спасибо, отличная статья. Вот бы кто нибудь занялся и на javascript.ru описал все новинки, а то фактически нормального полного и главное русскоязычного справочника нет.
Будет свободное время — запилю. Давно уже думаю, что пора дополнять этот сайт, а то он загибается потихоньку.

Но это будет не очень скоро, думаю, от нескольких недель до месяцев.
Свой сайт лучше запили, javascript.ru — проект одного автора, не больно желающего изменений. По большому счету, нужен коллективный сайт, типа хабра (форум никак не подходит, «блоги» сдохли под влиянием неадекватов) с жестким отбором авторов и отсеиванием всяких Марумов.
Можно попробовать на гитхабе сделать, там уже всё необходимое готово, только сам контент осталось написать.
Честно говоря, жалко пролюбить такое красивое доменное имя)

А автор, мне кажется, не то что бы не желает изменений, а просто забил на него и забыл.
Доменное имя принадлежит не тебе, так что забей :)

Ну в этом и ответ, в консервативности автора. Домен можно приобрести и в другой зоне (даже знаю, в какой). Другой вопрос: кому будет интересно тратить кучу времени на обновление, добавление новых материалов и т. п. Раскрутить такой узкоспециализированный проект ой как не просто.
UFO just landed and posted this here
Я читал, конечно) Это претензия уже точно неактуальна, прошу за неё прощения.
Русскоязычного вообще ничего нет. А если переводят (на энтузиазме или пройдя через ряд проблем связанных с публикецией переводов книг), то с опазданием в 2 года. К тому времени все, что в книге написано успеет устареть. Лучше уж читать со словарем, но в оригинале.
Веб это не математика — срок годности сильно ограничен.
Согласен, по этому сижу на мозиловском сайте, там всё доходчиво, хоть и на английском.
И я говорил не о книгах а о справочнике.
В спецификации как бы и нету delete, автор видимо ошибся просто.
Оперчатался, вместо remove написал delete, блин.
И все шесть методов уже реализованы в WebKit
Упс, ошибся. Пока только remove. Нужно идти спать
Почему используется insertBefore+createDocumentFragment вместо element.insertAdjacentHTML?
Еще ваш код выглядит так как будето был получен кодогенератором, что с ним если не секрет?
insertAdjacentHTML вставляет только строку и интерпретирует как html, не?
Писал сам :) Если не нравится кодстайл, напишите мне в личку, я постараюсь исправиться :)
И снизу правильно написали. Собственно, в данном случае, insertAdjacentHTML не применил, тем более, что я через DOM4 Mutation methods реализую insertAdjacentHTML для FF (он только с 8й версии стал поддерживать эту функцию)
Конструкторы Event и CustomEvent реализованы во всех современных браузерах (уже больше года). Polyfill для старых браузеров.


В современных мобильных WebKit всё ещё нет.
Поддержка свойства reversed есть в Google Chrome. Для остальных браузеров есть Polyfill.
В ночных сборках Firefox 18 поддержка атрибута reversed тоже уже реализована.
Селекторов по родителю всё нет и нет. Понятно, что для CSS это чревато низкой скоростью обработки, но для JS DOM API было бы очень кстати. Придется, как и раньше, использовать либы или писать свои костыли.
Чтобы не конфликтовать с синтаксисом популярных CSS-препроцессоров, новый синтаксис:
ul! > li

Спека
Хм… Таки восклицательный знак вводит в заблуждение, не могут что ли другой символ придумать. W3C, как обычно, не спешат. Только селектор по родителю позволит избавиться от библиотек при работе с DOM. Мот быть к году 2112 определятся наконец.
А вообще, интересно. Есть хоть один браузер, который хавает этот селектор?
Нет. Но можно сделать поддержку, чем я сейчас и занят (в свободное время). Вы можете следить за процессом в репе.
А по поводу знака, так практически больше и не осталось «легких» для понимания специальных символов. Вот $ заняли препроцессоры.
Радует, что кучу полезного функционала jQuery делают более-менее нативным. Но тогда непонятен смысл ваших полифиллов (со всем уважением, труд все-таки), кроме как потыкать новинку. Все равно будем юзать jQuery. Правда, неплохо было бы разработчикам jQuery обратить внимание на DOM API и реализовать свой функционал на нем. А для нас простых разработчиков ничего не изменится.
Мне много чего в jQuery не нравится, чему есть замена в стандарте. Например: jQuery.proxy — убогий аналог Function.prototype.bind, конструкторы событий jQuery.Event — определённые стандартом удобнее, и.д. Ну и моё личное мнение: мне не нравится некоторые реализации функционала в jQuery, например, как реализованы delegate-события.
А чем убог jQuery.proxy, не могли бы пояснить?
function test(a, b, c) {
console.log(this, a, b, c)
}

test.bind(1,2,3,4)() -> //1, 2, 3, 4

jQuery.proxy(test, 1, 2, 3, 4)() -> //1, undefined, undefined, undefined

jQuery.proxy не поддерживает фиксацию параметров функции
Хммм, а я всегда bind реализовывал без фиксации параметров и даже не слышал про таковую.
Function.prototype.bind = function (context) {
	var func = this;
	return function () {
		return func.apply(context, arguments);
	};
};


Спасибо за информацию.
Дурацкий слой «Наверх» слева не даёт мне поставить лайк.
Fail.
Код статьи выложен на github.

офф: подскажите, как вы конвертировали разметку из markdown в хабра-html?
Пишу в PhpStorm (там есть плугин markdown), потом открывать в SublimeText2 и с помощью плугина markdown preview перевожу в html. Игнорируя всё определения стилей, копирую только html. Вставляю в хабраредактор. Дальше copy-past'ом заменяю все примеры кода на <source type="...">, т.к. markdown preview делает не поддерживаемую хабровским <source> разметку.
Примерно так :) Хочу написать конвертор markdown -> harba_topic_format, но пока нету на это времени.

Близится время, когда мы все сможем без напрягов писать на VanillaJS не прикликая никаких других либ… И рай наступит когда даже полифиллы не нужны будут!
remove в прототипе Element — удобный метод, но как быть с select`ами? в прототипе HTMLSelectElement имеется метод remove, который без аргумента удаляет первый option и он по-любому переопределяет прототип Element`а…
на всякий случай оставлю здесь, ведь как всегда опять забуду…
global.HTMLSelectElement && function(HTMLSelectElementPrototype)
{
    HTMLSelectElementPrototype.remove = function()
    {
        if (arguments[0] >= 0) this.remove(arguments[0]);
        else this.parentNode && this.parentNode.removeChild(this);
    };
}(window.HTMLSelectElement.prototype);
А теперь совсем правильно:

window.HTMLSelectElement && function(HTMLSelectElementPrototype)
{
    var removeOption = HTMLSelectElementPrototype.remove;

    HTMLSelectElementPrototype.remove = function()
    {
        if (arguments[0] >= 0) removeOption.call(this, arguments[0]);
        else this.parentNode && this.parentNode.removeChild(this);
    };
}(window.HTMLSelectElement.prototype);
Этот баг-репорт твой?

Только почему ты проверяешь arguments[0] >= 0. Правильней бы было проверить на кол-во атрибутов if(!arguments.length):

var global = this, _tmp_, _Node_prototype = global.Node.prototype;

if((_tmp_ = global.HTMLSelectElement) && (_tmp_ = _tmp_.prototype) && ("remove" in _tmp_)) {
	(function(_HTMLSelectElement_prototype, _HTMLSelectElement_remove) {
		_HTMLSelectElement_prototype["remove"] = function(index) {
			if(!arguments.length)_Node_prototype["remove"].call(this);
			else _HTMLSelectElement_remove.apply(this, arguments);
		}
	})(_tmp_, _tmp_["remove"]);
}
да, мой.
насчёт проверки длинны согласен — дешевле, и судя по комменту так и запилят.
почему тянешь прототип Node, а не Element? remove в Element`е лежит. или в опере это не так?)
не проще ли вместо проверок в try засунуть?
твой код тяжело читается. почему не написать как-нить так:

try {
    (function(HTMLSelectElementPrototype) 
    {
        var removeOption = HTMLSelectElementPrototype.remove;
        
        HTMLSelectElementPrototype.remove = function() 
        {
            if (arguments.length)
                removeOption.apply(this, arguments);
            else
                this.parentNode && this.parentNode.removeChild(this);
        };
    })(this.HTMLSelectElement.prototype);
} catch (e) {}

Функции в которых используется try{}catch(e){} не оптимизируются оптимизатором в V8, поэтому я лучше напишу больше проверок.
И DOM4 метод «remove» должен лежать именно в Node.prototype, чтобы он был у текстовых нод. У меня в полифиле ошибка, которую я уже локально поправил, просто ещё не выливал на github — тестирую
а можешь дать ссыль на эту спеку? по приведенной в статье ссылке remove находится именно у Element`а, а это дискриминирует текстовые ноды в правах на самоуничтожение…
Это я опять поторопился. На самом деле для текстовых нод, DOM4 методы должны быть в CharacterData.
Поэтому, пока последние изменения и не выкладываю github — тестирую и ищу баги.
Sign up to leave a comment.

Articles