What is the Browsing Context of a Web Publication? #104
Comments
|
For a web publication, @BigBlueHat, it's whatever domain the WP's manifest and each of its resources are hosted on - because that is how the web works. I don't see the confusion. For a packaged web pub, that is a complex area we have not yet explored. |
|
@lrosenthol "browsing context" !== "domain."
A browsing context may provide (and execute in some cases) content (and scripts) from many domains provided CSP et al allow it. This is all well defined in the HTML spec. Conversely, the Browser Extension spec predefines a (deliberately) limited set of CSP rules and (as needed) generates HTML pages to be the "browsing contexts" for the scripts (which are referenced in the manifest). Some of these pages are sandboxed more than others to limit scope and access to various things on Web or from the browser based on permissions requested and/or permitted by the user. All of these pages (and resources) have browser-specific URLs and live in a separate--not really on the Web--sort of space and execution environment. The first is more "webby." The later potentially provides great security, but means the UA defines much more of what can and can't be done when and where (it's also far less extensible). |
|
@BigBlueHat I agree that it is fully documented in the HTML (and WebSec & WebAppSec specs) - and that's my point. The hosting environment is entirely in control of the context and not the content itself - at least as the web defines it today. And for WP's, given our conversations at TPAC about not-limiting anything for WPs, that is what I would expect. Again, for PWPs, I would expect something more along the lines of an extension with restricted CSP, etc. |
|
@lrosenthol I think you're picking Option 1 then? |
|
@BigBlueHat Yes, I think I am...though with the caveat that individual resources of the publication may live in completely different contexts from the "landing page" (either due to author choice or hosting environment choice) |
|
@lrosenthol resources can love anywhere. The HTML spec defines how to deal with the various scenarios. |
That has to be the typo of year... 🏆 |
|
Do we have to define this? We do envisage two scenarios:
I think we all believe/hope (I certainly do) that the future is (1). But we know that, at first, we have to rely on (2). In other words, we cannot make a choice in the spec, can we? |
I suspect I do not hope so. For me this hinges on what "doing its own thing means". I can't imagine all but the barest wpub being delivered without some author-controlled viewer ("bunch of scripts" , "PWA-like" whatever you want to call it). Should browsers force their "wpub UA" onto users then, as an author/publisher/developer, I simply won't adopt wpub (but instead keep my client-side reading experience). |
|
I am inclined to hope the future is "browser WP aware". This raises the WP adoption question, probably more a question for the Business Group. |
|
The bottom line: at this point we do not really see what the future holds, and the spec should leave options open. |
|
@iherman this isn't about shimming, but about defining spec text that says what browsing context requests are made within. We can either use one that exists on the Web now (the "entry page" most likely) or we have to define a new one. We have to pick one (or find a third option) because the browser/UA needs to know the context in which it works--is that something it understands now (i.e. a document handed to it from the Web) or something we define for it (i.e. a separate operating space ala browser extensions). The two worlds are very different, and choosing one path or the other both dictates and explains much about our specification's future text. |
|
@BigBlueHat, I think I understand what you mean and, I believe, option 1 is the way to go. However, I am not sure what the consequences are on our spec and what restrictions it imposes upon any non-browser implementation in a browser. I think you should write that down more explicitly. |
|
A browsing context defined around a Document (in this case the "entry page") is a known thing in the HTML5 spec: https://www.w3.org/TR/html/browsers.html#sec-browsing-contexts A "non-browser implementation in a browser" would then need to load the "entry page" document allowing the browser/software to create the browsing context, and then build up from there. The browsing context, security policy, and origin restrictions (etc) are consequently defined around that document (its headers, etc), and not defined uniquely (as in outside of HTML) by our specification. |
|
@iherman the exploration going on in #121 is highlighting much of what I was attempting to express here. If the "entry page" provides the browsing context for the publication, then things are pre-defined and consequently rather straightforward (and Anything we do with a JSON manifest will have to be processed within a browsing context--because JSON doesn't provide it's own browsing context, nor scripting, nor any "self knowledge" nor hypermedia. Our options are (as highlighted earlier by this issue):
|
The matter of where the lifecycle (and by extension WebIDL) exists is an issue for the working group to discuss and determine, and not merely an editorial note (as it was previously). This removes the note and references issue #104 in its place.
Change editoral note about context to ref #104
|
(The meeting on 2018-05-07 ended abruptly and I could not say what I wanted...) @dauwhe @BigBlueHat : I am not convinced that we really need to care about context. By default, we do end up in a traditional browsing context by virtue of the landing page, and that seems to be fine. WP defines the content of the publication in terms of all the other affordances that we define, and we already know that there may be several environments that would make use of that content. There may be web applications, there may be extensions in a browser, there may be reading systems, and each may provide a different environment. That is fine. Why do we have to be more specific? |
|
@iherman we don't have to be specific if we're building up from the Web as it is today. However, we already assume and state the existence of a
That statement implies that the processed manifest will be returned within that (as yet) undefined context. Similarly, the WebIDL (aka JavaScript APIs) in the appendix seem to assume such a space exists and that code (from somewhere) will use those APIs to do things. Conversely, if the context is instead the default, top-level browsing context as created by loading the publication's address and "landing page" (spec currently says "entry point"), then we have a preexisting, well defined resource model as built from HTML5 and friends (Content Security Policy, Cross Origin Resource Sharing, et al). Essentially, we won't have any need to say much about browsing context that hasn't already been said, because we'll have one already. Does that clarify things at all? |
|
I think one of the issues is that our current document says in section 6.1
That seems to be defining a new context. If that is not what's intended, then I am confused, and I think others are as well. |
|
I'll be interested in Ivan's reply. But my gut says (for what little that's worth) that we don't want to bite off defining the properties of some new context that we're inventing from whole cloth. |
You are right. And I believe that is a mistake. Trying to retrace the origin of this, I believe @HadrienGardeur copied the relevant section from the WAM, modifying the context reference. This whole section is in question, as far as I am concerned, and it is also deeply related to our relationship to the WAM. Let us not consider this reference as really binding:-)
Absolutely. And this is a decisive point for our discussion. I think (but this is my personal opinion) that we are going towards a direction whereby a WP definition does not specify whether the content is rendered in a Progressive Web App, in the browser directly or via an extension, or in a separate app (or whatever else). That is how I interpret what we said in our discussions on 04-16 that ur goal is to specify the content, and stop there. I would therefore propose to actually close this issue with the answer to the original question (i.e., “What is the Browsing Context of a Web Publication?”) by saying “whatever the implementation chooses it to be.” (Which is, B=by default, just the context of the “entry point” (sorry for the wrong reference:-).) |
|
Well, it's certainly a "mistake" in the same way that defining our own rel value is a mistake. We probably don't need to have our own rel, but I had to include it any way in this super early draft. If we end up using the WAM as our syntax, we'll end up with its context and its rel as well. If we don't use the WAM, we can probably avoid both. |
|
@iherman so, in as much as this is indeed a Web specification, then this spec (like all others served over HTTP and consumed by a browser) would operate within the confines of HTML5's definition of "top-level browsing context" (as created by our "entry point"), is that correct? Other user agent types/scenarios would, consequently, fall outside of this specification, though those UA's would ultimately choose how to deal with the content (as expressed via "WP") and context questions from within a) their own environment's constraints and b) their understanding of the Web Platforms models and intentions (i.e. HTTP headers, CORS, CSP, etc). Does that cover what you were expressing @iherman? |
|
Mostly:-) However, I think
is not the right way of saying this, because we do not say anything about the context in the first place. Every UA would do whatever is natural for it. Defining the context would fall outside of this specification is a better way of saying it. At least in my view:-) |
|
@iherman understood. Currently, however we do state a context exists for the lifecycle and assume there is one by defining WebIDL which must, by its nature, run somewhere--that somewhere being a browsing context typically "hoisted" from an HTML response to a URL. We define a URL as the publication address, we say that address MUST respond with an HTML "entry point", so we (consequently) have our browsing context ready for us (at least on the Web). Everything else (including WebIDL if/when we define some informatively) would need to operate out of that...or we define a new place for it to run. Essentially, we need to remove a lot of stuff that requires having a specific context or that would be in conflict with the browser context that would be created by requesting the publication address. Does that sound right? |
As I said in #104 (comment): I believe that was a mistake and should be removed. I regard the WebIDL as simply a precise, semi-Javascript definition of the run-time structure of what the infoset items translate into. It is just a way of specifying things in a precise manner. Its usage has no consequence on the rest. |
|
I don't really care much about obtaining a manifest and processing a manifest sections since:
But I would strongly object to the idea of removing the WebIDL. This is the closest thing that we have to what user agents will truly work with (and I'm not just talking about browsers) and without this, the whole thing is very abstract and disconnected from how this spec can be implemented. |
|
@HadrienGardeur the "fallback" approach was @iherman's idea. My preference continues to be to have a single HTML document "bind" the rest of the publication. That HTML document MAY (or MAY NOT) use additional means (JSON, JS, CSS, etc) to provide any necessary affordances, but each of those technical determinations should be considered in light of how the Web is constructed currently. Consequently, I believe that everything we put into the specification (appendix or not) MUST have an expressed purpose and use to the implementer of the specification. Hence the WebIDL should either be given implementer value and purpose (which stands counter to @iherman's "Its usage has no consequence on the rest.") or we should remove it until we further determine the need for an API description (regardless of language or runtime used). |
WebIDL, at least in my view, is not only for the specification of an API. It is a precise definition of the data structures that the serialization expects to provide. We could use "simply" Javascript for that purpose, but there are a number of constraints (e.g., typing constraints) that Javascript cannot syntactically express, and WebIDL can. Ie, it is just a specification tool. |
|
I'm having trouble parsing this conversation as someone with less familiarity with the elements being discussed, so I'm going to go through a set of questions which generally helps me and I hope will be helpful to other members that are newer to these issues: 1. What problem are you trying to solve? 2. Why is this the best solution? 3. What alternatives did you consider? (Or in this case, are you considering?)
4. What is the fallback or the backup plan?
|
|
Great summary, @RachelComerford. Thank you. Responding in reverse order... 4. What is the fallback or the backup plan?
Given that:
3. What alternatives did you consider? (Or in this case, are you considering?)
Whatever other options we consider (beyond the one's you've listed), there will be choices made about subsequent request handling (i.e. how does the system get the primary resources, dependencies, etc). In the case of a top-level browsing context created upon requesting the publication address (URL), that process is well known, defined, and extensible. However, if there's a non-displayable/renderable format (such as JSON, XML, YAML, etc), then the "what happens next" is completely undefined--and presumably needs definition. 2. Why is this the best solution?
A JSON manifest could augment an HTML file, but an HTML (or perhaps SVG) response MUST be returned to a URL if we want a) display and b) extensibility. Conversely, if the publication address returns a JSON manifest, there's no known action for the browser to take--and we'd need to create a unique media type to define what a UA should do with that file once found. However, it seems the expectation currently expressed in the spec is that the publication address results simply in a discovery mechanism of a different URL (that of the JSON file), which in turns provides a description of the publication which something else (not the browser, possibly not the HTML...but maybe) would have to process, parse, make requests from, and ultimately build the reading experience--using the JSON as the authority of the binding, styling, internationalizing, etc. JSON is ill equipped for all of those things. JSON-LD adds understanding of IRIs (URIs, URLs, etc), but does not afford the browser any action to take (i.e. should it GET those URLs? should it add them to a...DOM? is there a DOM to add them to?). Hence, it can only be used to inform something else: a Web App, a Web extension, or a not-on-the-Web/not-a-browser Reading System. The JSON(-LD) itself, however, is inert and provides no capabilities in and of itself. 1. What problem are you trying to solve?
The underpinning idea here is that Web Publications are Web Apps (ex: http://guide.couchdb.org/ https://hpbn.co/ https://resilientwebdesign.com/ ), but they lack publication-focused affordances on the Web and consequently do not afford browsers/UAs the information to give the person reading them publication-like experiences (linear progression, cross-publication search, offline reading, etc). They may each attempt to do that in their own idiosyncratic way (and most of those above do try), but the publishers of those publications had to "go it alone" and ultimately the browser has no "understanding" that there is linear progression, that it could provide cross-document search (if it know was were primary resources), and could provide offline reading (by knowing that same list of primary resources). Ultimately, the hope is that we build up from the "Web Publications are Web Apps" (i.e. http://extensiblewebmanifesto.org/ ) and provide additions to the Open Web Platform that enhance those publications rather than displace them with a new (though inert) static description format that must be read through a Reading System (of some kind) for the publication to be experienced. Consequently, I'm continuing to look for the smallest number of steps from existing web publications (lowercase on purpose) to a future Web Publication format the provides the human reader with ehanced experiences afforded for through the standard we specify. |
|
The Working Group just discussed The full IRC log of that discussion<dauwhe> Topic: F2F agenda<dauwhe> ... we won't have a call next Monday <dauwhe> ... holiday in the US <ivan> q+ <dauwhe> ... reach out to the chairs if you have changes for the agenda <dauwhe> q? <garth> http://hotelocho.com/food.html <dauwhe> ... there will be a dinner on Wednesday night (link above) <garth> https://docs.google.com/document/d/1Qe8Q8wMC1LKy_-JO-UCy8bFw4D4VN0si1Q5EPW9c-rY/edit#heading=h.wxsg3gz7h6ps <dauwhe> ... there's a signup sheet in google docs <dauwhe> ... ^ <garth> https://goo.gl/forms/UZ0yv8EBXBujTePw1 <dauwhe> ... and there's a dietary restrictions form <garth> q? <garth> ack ivan <dauwhe> ... please fill it out even if you're not going to the dinner, as it covers lunch and snacks at the F2F <dauwhe> ivan: the same goto meeting channel is open during the F2F, thanks to Laurent <garth> q? <dauwhe> garth: what I wanted to try to do at this juncture <dauwhe> ... we have a handful of issues where there's been a lot of discussion <dauwhe> ... I talked to Ivan in Berlin <dauwhe> ... we grabbed a few of these that we want agreement on before the F2F <dauwhe> ... the first one is, what is the browsing context (104) <garth> https://github.com//issues/104 <dauwhe> github: https://github.com//issues/104 <dauwhe> garth: we want to lose the term publication context because it's not relevant, and I don't think it's in scope for this group <garth> “A WP definition does not specify whether the content is rendered in a Progressive Web App, in the browser directly or via an extension, or in a separate app (or whatever else). Therefore we propose to close this issue with the answer to the original question (i.e., “What is the Browsing Context of a Web Publication?”) by saying “whatever the implementation chooses it to be.” Which is, by default, just the context of the “entry point”. Further[CUT] <dauwhe> ... the proposal we came up with is <garth> to alter the current draft to remove the reference to "Publication Context."” <garth> q? <dauwhe> ... I'll read this and then we can discuss <garth> q? <dauwhe> ... if there happens to be a WAM a publication can be a progressive web app, but we don't have to define it so <garth> q? <dauwhe> q+ <garth> ack dauwhe <bigbluehat> q+ <garth> ack bigbluehat <dauwhe> dauwhe: we should be clear about where script runs in web publications <dauwhe> ... but I'm ok with this language <dauwhe> bigbluehat: my take is similar to dauwhe <dauwhe> ... we're not stating where stuff happens, so we don't need to declare a browsing context <garth> q? <dauwhe> garth: dauwhe is correct that scripts are involved <dauwhe> bigbluehat: there are other concerns about the audience of the specification being unclear <dauwhe> ... I'm not sure who recognizes themselves as an implementor <garth> q? <dauwhe> garth: I don't hesitate to take silence as consent <dkaplan3> q+ <jbuehler> +1 to the last two comments <dauwhe> q? <dauwhe> dkaplan3: I'm going to consent +0 :) <dauwhe> ... we've talked before about the complications of requiring scripts <dauwhe> ... I understand the reality we live in, but we should be wary... <dauwhe> ... define scripts very carefully so they don't create more problems than they solve <dauwhe> garth: let's say we resolve 104 with the above language |
|
Resolved on call: "A WP definition does not specify whether the content is rendered in a Progressive Web App, in the browser directly or via an extension, or in a separate app (or whatever else). Therefore we propose to close this issue with the answer to the original question (i.e., “What is the Browsing Context of a Web Publication?”) by saying “whatever the implementation chooses it to be.” Which is, by default, just the context of the “entry point”. Further propose to alter the current draft to remove the reference to "Publication Context."" |
Assuming Web Publications are being defined for consumption (primarily) from within a Web browser, we need to select (or define) the browsing context within which the UA makes requests, understands its origin, and limits (or does not) access to other resources with regard to CSP, CORS, the Single Origin Policy et al.
As mentioned in this comment raising this issue on #103, there are two (known) options:
Knowing which one we plan to work within will help clarify many things.
The text was updated successfully, but these errors were encountered: