Re: [w3ctag/design-reviews] Base used to resolve relative URIs to absolute URIs in HTML5 data-blocks (#312)

My understanding is that this issue is only about what happens for relative URL handling when `application/ld+json` blocks are put in `script` elements inside of HTML.  (And maybe there's a secondary question about default language, but I'm less concerned about that one.)

So I think one question here is to what extent these data blocks might be used by browsers at some point in the future.  If there's an intent that they might be used by browsers, then making underlying technical decisions about how to resolve relative URLs that are different from what browsers do seems like it might be a bad idea.  In this case, I think browsers do normally honor the HTML `<base>` element, but don't honor `xml:base` or `<link rel=canonical>`, though that's worth double-checking.

I'm also curious what the explainer is referring to when it says:

> The barrier to entry is higher as a DOM processor is needed

What's the alternative way of extracting script elements from an HTML document that's not considered a DOM processor?  Is it a proper HTML parser that just sends (SAX-like?) events rather than constructing a DOM?  (And wouldn't it be possible to process `<base>` elements in a conformant way in that setup?)  Or is it something simpler?

-----

On the flip side:

> If javascript execution is required to be processed, the barrier to entry is signficantly higher

I tend to think it's pretty bad for content to produce different base URLs with or without script enabled; I'm substantially more comfortable calling that an authoring mistake, and more OK with different processors producing different results in that case.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/312#issuecomment-434667433