Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
Хорошо быть гуглом: придумал новую крутую фичу для embed'ов YouTube, пошёл добавил её в веб стандарты.
Логичное продолжение развития AMP технологии
Например, когда пользователь просматривает новостной сайт и заканчивает чтение страницы, то есть доходит до нижней её части, то ссылки на «похожие статьи» будут встроены в качестве порталов. Зачем веб-разработчику оформлять их таким образом? Преимущество использования порталов по сравнению с классическими ссылками заключается в том, что содержимое внутри порталов может быть предварительно загружено и предварительно отрендерено с загрузкой всего дерева DOM, то есть оно отобразится мгновенно.
Что-то я слабо представляю, как должен работать этот пример. Если содержимое «похожей статьи» будет загружено со всем деревом DOM, то и порталы на ней тоже будут загружены. В результате это приведет к тому, что похожие статьи зациклятся друг на друга или по цепочке загрузят вообще все новости на сайте.
> может переписывать URL в адресной строке браузера
Ясно-понятно, опять AMP пропихивают.
Ясно-понятно, опять AMP пропихивают.
Открыл страничку почитать абзац — загрузил вдобавок пол-интернета. Удобная технология, экономящая мобильный трафик и уменьшающая время загрузки, ага.
Если люди начнут использовать это действительно как «порталы» — плавные переходы между сайтами, то будет классно.
Но скорее всего мы увидим ещё больше мошеннических сайтов
Но скорее всего мы увидим ещё больше мошеннических сайтов
Дайте угадаю, в целях безопасности в эти порталы не смогут стучаться плагины браузера и блокировщики рекламы там работать не будут?
Да нет. Как это не смогут плагины стучаться?! Если через JS туда можно обратиться (а как иначе-то), то всё ок.
А безопасность как же? Это что же получается, любая XSS-уязвимость превращается в источник слива данных с десятков ресурсов?
Ну и вторая проблема — непонятно, как работать с показами. Засунул 10 порталов — получил 10 показов рекламы с одного открытия страницы?
Ну и вторая проблема — непонятно, как работать с показами. Засунул 10 порталов — получил 10 показов рекламы с одного открытия страницы?
Насколько я понял, прямого доступа к DOM не будет. Будет возможность отправить сообщение порталу, а портал, в свою очередь сможет отправлять сообщения хосту. А так же будет возможность проверить, что сайт загружен как портал. Что делать с принятыми сообщениями, каждый решает сам. Т.е. фактически, каждый сайт сам будет определять какое API и возможности он предоставляет для работы с собой, как с порталом.
// Send message to the portal element
const portal = document.querySelector('portal');
portal.postMessage({someKey: someValue}, ORIGIN);
// Receive message via window.portalHost
window.portalHost.addEventListener('message', evt => {
const data = evt.data.someKey;
// handle the event
});
Ну это же для баннеров и так понятно. Чего они опять развели это «добро для всех в интернете».
Сначала подумал: отличная же новость, шротные конторки переберутся на это новье, а мы как потребители просто вырезаем плагином или на прокси теги portal, и страницы загрузятся без довесков… Эх, мечты, мечты!
ух ты… У меня браузер будет загружать и рендерить предварительно статьи и иной шлак, который я даже не буду в 99% случаев смотреть… Представляю уже главную страницу какого ни будь рамблера, которая будет жрать 32гб памяти и грузить все 16 потоков…
Порталы надо закопать и забыть. А фреймам убрать доступ через WindowsProxy.
Порталы надо закопать и забыть. А фреймам убрать доступ через WindowsProxy.
Интересно может ли быть Портал в Портале?
<spacetimeportal to="target"></spacetimeportal>
Давайте загрузим еще больше всего! Мало же уже того, что есть.
> Например, когда пользователь просматривает новостной сайт и заканчивает чтение страницы, то есть доходит до нижней её части, то ссылки на «похожие статьи» будут встроены в качестве порталов. Зачем веб-разработчику оформлять их таким образом? Преимущество использования порталов по сравнению с классическими ссылками заключается в том, что содержимое внутри порталов может быть предварительно загружено и предварительно отрендерено с загрузкой всего дерева DOM
То есть новостные сайты, которые уже сейчас часто тормозят и свопятся (попробуйте из агрегатора Яндекса на [виртуальной] 32-битной машине, например), станут вообще неподъемными, в т.ч. по трафику и батарее.
Опять же, фреймы были такими сделаны не просто так, а для безопасности.
Этот веб испортился, несите следующий.
То есть новостные сайты, которые уже сейчас часто тормозят и свопятся (попробуйте из агрегатора Яндекса на [виртуальной] 32-битной машине, например), станут вообще неподъемными, в т.ч. по трафику и батарее.
Опять же, фреймы были такими сделаны не просто так, а для безопасности.
Этот веб испортился, несите следующий.
Вопрос, скорее в том, что нового в данном случае дают порталы. Такие «новости» можно реализовать и сейчас, обычный js давно это позволяет. Вопрос, конечно, в том, зачем их именно рендерить предварительно, но можно и так.
Полагаю, что суть portal таки не таком использовании. Но реальных кейсов статья не раскрыла.
Вероятно, такие порталы смогут быть поверх других сайтов, не пропадая при навигации. Такая функциональность реализована в некоторых приложения под Андроид (youtube, карты). Я думаю, кто слушал музыку на вКонтакте, положительно оценивали возможность ходить по страницам не прерывая плеер. Но там это могло работать только внутри самой соц. сети, а новый стандарт предполагает, что плеер какого-то ютуба может висеть где-то сбоку и не пропадать при переходе по любым сайтам.
Однако, это догадка, из текста статьи не очень понятно, что конкретно предлагается. В ролике, увы, не увидел чего-то, что не реализовывается на iframe+js. В прочем, реальную ссылку на контент внутри iframe (на другом домене) таки не выйдет, но это как-то слабовато для целого нового тега.
Полагаю, что суть portal таки не таком использовании. Но реальных кейсов статья не раскрыла.
Вероятно, такие порталы смогут быть поверх других сайтов, не пропадая при навигации. Такая функциональность реализована в некоторых приложения под Андроид (youtube, карты). Я думаю, кто слушал музыку на вКонтакте, положительно оценивали возможность ходить по страницам не прерывая плеер. Но там это могло работать только внутри самой соц. сети, а новый стандарт предполагает, что плеер какого-то ютуба может висеть где-то сбоку и не пропадать при переходе по любым сайтам.
Однако, это догадка, из текста статьи не очень понятно, что конкретно предлагается. В ролике, увы, не увидел чего-то, что не реализовывается на iframe+js. В прочем, реальную ссылку на контент внутри iframe (на другом домене) таки не выйдет, но это как-то слабовато для целого нового тега.
Господа, помогите чайнику. Я человек уже в возрасте, слабо во всех этих современных вещах разбираюсь. Решил попробовать тег portal вместо iframe. Браузер новый google beta, поддержку portal включил. Вставил новый url так же как и в iframe, только использовал тег portal. Указанный url вставился, только там не работают ссылки, не регаируют на нажатие мыши. Что не так , что еще прописать сюда надо чтобы все заработало? Подскажите пожалуйста. Спасибо.
Не понял.
Т.е. теперь можно брутфорсить врагов с клиентских машин, которые, случайно зашли на мой порносайтик?
Т.е. теперь можно брутфорсить врагов с клиентских машин, которые, случайно зашли на мой порносайтик?
Преимущество использования порталов по сравнению с классическими ссылками заключается в том, что содержимое внутри порталов может быть предварительно загружено и предварительно отрендерено с загрузкой всего дерева DOM, то есть оно отобразится мгновенно.
хм, а чем это принципиально отличается от
rel="preload"?Более того,может переписывать URL в адресной строке браузера, то есть этот тег полезнее в качестве инструмента навигации. Опять же,<portal>на такое не способен.<iframe>
а разве аттрибуты для ссылки
target="_parent" / target="top" не делаю то, что нужно?
А если в портальном сайте тоже портал будет? Следующая технология от гугла — фракталы :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новый HTML-элемент <portal> от Google призван заменить фреймы