Replies

Then make them real pages.

Completely agree with you there!

Big modals that are basically fake web pages—even if coded accessibly—feel deceptive, lacking in material honesty.

If it’s true that screen reader users expect all links to go to a new page, then are regular internal page links (that use IDs) an anti-pattern to be avoided?

e.g. Wikipedia articles with a table of contents. Fragment identifier URLs.

There’s the story of T.E. Lawrence losing the first manuscript of The Seven Pillars Of Wisdom on a train …though it’s more likely that the story is his version of “the dog ate my homework” because he didn’t like what he’d written.

Well, this is a weird example but look at the output of this XML https://thesession.org/tunes/new?format=xml with and without the extension enabled. With the extension, you can see the JavaScript dumped to the screen.

Ah, interesting! I had that installed until very recently too: I had to disable it when I discovered it was inserting JavaScript into every response (making debugging very difficult). We should tell the good folks at @DuckDuckGo.

It loads for me: Firefox 82.0.1 on Mac.

Do you think maybe a browser extension might be the culprit? (I speak from bitter hair-pulling experience.)

I brainstormed that for a bit:

https://github.com/w3c/web-share/issues/176#issuecomment-694090749

I’m going to apologise to Roy Fielding for even thinking it.

Can’t beat a good vinaigrette:

https://principiagastronomica.com/post/24

I like the fallback you get with a link (assuming it’s using a valid fragment identifier)—if anything goes screwy with the JavaScript, the link still works.

I’d be interested in getting your take on the logic I’m using here: https://adactio.com/journal/17546

…generally you can’t go wrong with a button. … That said, I think that links can also make sense in certain situations.

Yeah, that’s fair—if I had a time machine, I’d love to go back and make cookies same-origin only.

And JavaScript!

https://adactio.com/journal/16099

Yeah …spicy!

It’s that emphasis on “between origins” that gets me (though I understand the security concerns, of course). Jake’s original proposal seemed more focused on same-origin page-level transitions …which is most single page apps today.

You’re right. I don’t have any in-depth knowledge here. I was trying to describe a proposal being incubated. I used an example. It was a bad example, I guess.

From now on I’ll just describe portals as “spicy iframes” and leave it at that.

Jake, I’m not saying that if a technology is useful for AMP then it must be bad—see rel=”prerender”, as you say.

I was honestly, genuinely trying to give an example of where portals could be used based on the description in the explainer.

Note that I didn’t say that portals came from AMP; I said they would help the AMP use case.

But I think I must be misunderstanding portals because it sounds to me like it would work great for the AMP top stories carousel.

Apologies. I thought the use-case sounded a lot like AMP’s top stories:

…show another page as an inset, and then activate it to perform a seamless transition to a new state, where the formerly-inset page becomes the top-level document.

Don’t get me wrong: it would be great if portals led to navigation transitions, but right now it looks like the focus is more on “like making an iframe go full page” e.g. an item in a news carousel on a search engine.

My description of portals was genuine. I gave a use case (AMP) and a comparison (iframes). I didn’t pass any judgement (although I can see how just mentioning AMP implies ickiness by association).

Portals are a proposal from Google that would help their AMP use case (it would allow a web page to be pre-rendered, kind of like an iframe).

https://github.com/wicg/portals