Т.е. в нашем случае для DIV-элемента с классом column-right установлено свойство overflow, чтобы этот DIV как родитель выделил место для дочернего float'а в лице картинки с Винни-Пухом, правильно? Но указать родителю overflow — это один из способов заставить родителя выделить место под float-ребенка. В этой же главе автор чуть выше указывает, что есть и другие способы, в том числе поставить родителю float. И в нашем случае у родительского DIV с классом column-right как раз-таки установлено свойство float. Тогда возникает вопрос: зачем ещё добавлять overflow?
Вечков Александр, благодарю!
Разница будет заметна, если мы для .wrapper из моего примера поставим свойство: background: red (или любой другой цвет, неважно). При установке height: 100% окрасится видимая часть окна, т.к. height в данном случае принимает 100% от высоты родителя, т.е. body, а body — 100% от html, а html — 100% высоты окна, т.е. по сути всю видимую высоту. В итоге если высота видимой области окна составляет, например, 500px, то при установке для .wrapper свойства height: 100% мы получим только 500px с красным фоном. Если у нас контента больше и надо скроллить, мы увидим, что часть ниже не окрасилась. А если установим min-height: 100%, то .wrapper окрасится полностью.
SagePtr, всё равно не совсем понимаю... Допустим, я в main запихну контента, чтобы его высота оказалась больше высоты окна. И при свойстве height = 100%, и при свойстве min-height = 100% результат будет одинаковым: футер по прежнему будет снизу, а у окна появится полоса прокрутки. Я в целом понимаю отличие height от min-height, но мне интересен реальный практический пример, в котором внезапно высота может стать меньше, чтобы браузер принудительно обрабатывал её как минимальную. Пока мне в голову не приходит такого примера.
Спасибо. Похоже, что так оно и есть: разные браузеры по-разному обрабатывают readyState окна about:blank. Только вот что за статус «initialized» такой интересный? В документации указывается, что есть только три статуса: loading, interactive и complete. Про initialized ни слова...
Aetae, спасибо!
Вот это чуть больше похоже на то, до чего я пытаюсь докопаться.
Почитал спецификацию, чтобы понять механизм работы then: в нашем случае переданный «голый» alert становится «под капотом» некоей абстрактной переменной fulfillReaction. А свойство промиса [[PromiseResult]] записывается в абстрактную переменную value. Далее вызывается PromiseReactionJob(reaction, argument), где reaction — это fulfillReaction, а argument — value.
В итоге, если упрощать: метод then действительно «под капотом» получает результат выполнения промиса result в качестве value и вызывает callback(value). Иными словами, метод then получает на вход функцию alert, а возвращает alert(value), которая сразу же и вызывается.
В моем вопросе в первом случае мы сами явно передаем result, а во втором случае метод then самостоятельно достает result из [[PromiseResult]] и с ним вызывает callback.
lssssssssssl, в указанном Вами варианте — да, callback вызывается с явным параметром result, переданным из resolve. А во втором случае в вопросе? Мы просто пишем alert, и явным образом ничего не передаем в качестве аргументов. Откуда alert понимает, что надо осуществить вызов именно с аргументом result? :)
...функцию которая принимает 1 аргумент (результат) и что-то с ним делает...
В том-то и дело, что во втором случае alert явным образом ничего не принимает. Если в первом случае мы явно вызываем alert с аргументом result, то во втором случае в alert мы явным образом ничего не передаем. Этот нюанс меня и смутил.
