> On Aug 1, 2017, at 6:32 PM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > > 02.08.2017, 01:12, "Maciej Stachowiak" <m...@apple.com > <mailto:m...@apple.com>>: >>> On Aug 1, 2017, at 5:55 PM, Konstantin Tokarev <annu...@yandex.ru> wrote: >>> >>> 02.08.2017, 00:49, "Sam Weinig" <wei...@apple.com>: >>>>> On Aug 1, 2017, at 6:57 AM, Dean Jackson <d...@apple.com> wrote: >>>>> >>>>>> On 24 Jul 2017, at 22:44, Brian Burg <bb...@apple.com> wrote: >>>>>> >>>>>> Hi WebKittens, >>>>>> >>>>>> In WebKit, the various web-exposed timing APIs–Resource Timing, User >>>>>> Timing, and Navigation Timing are guarded by the ENABLE_WEB_TIMING >>>>>> feature flag. >>>>>> >>>>>> It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build >>>>>> systems by default, and we have not experienced any fallout from >>>>>> shipping these features in Safari Technology Preview. I think it’s time >>>>>> to remove the feature flag. Are there any objections? Is there a port >>>>>> in-tree that’s compiling without this feature? >>>>>> >>>>>> If I don’t hear anything, the flag’s removal will be tracked in >>>>>> <https://bugs.webkit.org/show_bug.cgi?id=174795>. >>>>> >>>>> In general I think we should be more enthusiastic about removing >>>>> feature flags that are guarding core parts of the Web platform. Web >>>>> Timing is a great example. >>>>> >>>>> Some others I see: >>>>> >>>>> ENABLE_CANVAS_PATH >>>>> ENABLE_CSS_COMPOSITING >>>>> ENABLE_CSS_SELECTORS_LEVEL4 >>>>> ENABLE_FETCH_API >>>>> ENABLE_GEOLOCATION >>>>> ENABLE_INDEXED_DATABASE >>>>> ENABLE_STREAMS_API >>>>> ENABLE_CSS_SCROLL_SNAP >>>>> ENABLE_WEBGL >>>>> ENABLE_WEB_AUDIO >>>>> ENABLE_WEB_SOCKETS >>>> >>>> I think WebGL is still not supported on Windows in WebKitLegacy, so we >>>> may need to keep that one. >>>> >>>> I’d like to add ENABLE_VIDEO to that list, given how core it is to the >>>> platform, and how many other features depend on it. >>> >>> I think it's a bad idea to remove ENABLE_VIDEO. Not only because there are >>> lots of non-browser applications that need HTML renderer (document viewers, >>> mail clients, instant messengers, RSS readers, etc.) which don't need >>> video, but also because it greatly raises the bar for implementing new >>> ports (e.g. recently announced Android port didn't implement video at that >>> time) >> >> I think all of the clients you mentioned actually do need video (or at least >> benefit from it). In any case, most clients like that don't usually bundle >> their own WebKit. They use a shared copy. > > That's not true for Windows, where each application is shipping its own > libraries, and is also not true for macOS in case port other than Mac is > used. And such "small" applications surely benefit from reduced size and > reduced dependencies.
Chromium Embedded Framework is an obvious comparison project for use cases like that. CEF is arguably more popular as a bundled engine than WebKit, so we probably don't need more flexibility than they provide. Does CEF let you compile out video support? Regards, Maciej > >> Usually a copy that is also used by a web browser. So if they really want to >> disable video, they need a runtime flag, not a compile-time flag. >> >> The port argument is potentially more compelling. It would carry more weight >> if there are platforms that can't supply the required back end at all, or >> where support is not expected any time soon. It's ok for new ports to be >> initially incomplete, using stubs or extra ifdefs that we wouldn't want >> upstream. >> >> Regards, >> Maciej >> >>>> - Sam >>>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> webkit-dev@lists.webkit.org >>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>> >>> -- >>> Regards, >>> Konstantin >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> https://lists.webkit.org/mailman/listinfo/webkit-dev > > -- > Regards, > Konstantin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
