------ Original Message ------
From: "Henri Sivonen" <hsivo...@mozilla.com>
Section 4.2 refers to Gecko's XPCOM embedding API, which hasn't been
supported in quite a while. It also refers to the Trident embedding
API. Putting aside for the moment the it's bad from Mozilla
perspective to treat a Web engine as a generic platform capability as
opposed to it being a thing that one chooses from a number of
competitive options, it seems bad to build on the assumption that on
Windows the platform capability is Trident, which isn't getting new
Web features anymore.
While I'm admittedly way, way out of my swim lane here, I'd like to
second one Henri's concerns; the specification as proposed doesn't admit
that Trident is effectively gone and that the Mozilla API referenced in
(1.) embedding is marked as "Obsolete" in places and otherwise full of
red flags:
https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Embedding_Mozilla/Roll_your_own_browser
... but I'm equally concerned that this specification repeatedly assumes
that a possibly-unbounded amount of poorly-defined work done by
unspecified other people will manifest itself somehow:
"To be useful, we’ll need to require support for a large number external
standards (i.e., [X]HTML, CSS, SVG, ECMAScript, and possibly others).
Our three-year release cycle is likely sufficient to maintain a proper
list of such standards, but it’s still a large list, and to be clear,
the transitive closure of this list is huge. Nevertheless..."
"Required security and functionality updates on many platforms for
web-content support may be far more frequent than updates to the C++
standard library, and a web_view in the C++ standard library should
automatically use this frequently-updated web-content software."
"I fully expect that, if we decide to go down this route, additional
utilities and abstractions will be added to go along with it."
"It should be noted that, as a limitation derived from current
implementations, the URI scheme handlers provide a kind of virtual
file-system interface, and as such, do not support POST data being
provided to the handler along with the URI itself. To support that, and
other protocols directly, we may need to provide an actual socket-based
server to which the web_view could connect."
"Implementations are encouraged to support the latest WHATWG living
standards, [wai-aria], [WebGL], [webrtc], [webvtt1], [SVG11], CSS
standards, DOM standards, and otherwise maximize compatibility with
other implementations (see, e.g., Can I use... )"
"It is expected that, for security reasons, implementations might
restrict or disable this interface for web content provided by some
remote sources."
In short, there is a _lot_ of "should", "might" and "may" in this
specification. I have to admit that on a re-read, the basic idea of a
standard API used to invoke an _existing external third-party browser_ -
that a C++ program might want to define some content and interactions
and maybe ask questions and get reasonably well-formed answers back - is
about 99% less incredibly bonkers than my initial impressions, and there
may well be something there worth pursuing, but as drafted this spec
presumes a lot of future work and glosses over a lot of serious
questions as a result.
- mhoye
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
