On Wed, 2017-01-25 at 15:29 +0000, Andrea Giammarchi wrote: > If I might ask my last question: who makes the decision of "what > ships where"?
Whoever is working on the feature. If the people working on the feature decide to enable it in WebKitGTK+, then we'll get it. If not, we'll never get it until someone working on WebKitGTK+ decides they want it. Nobody keeps track of the delta in feature differences between the two ports. It's certainly something that would be desirable. > As example, how comes Safari is shipping customElements but latest > WebKitGTK+ doesn't even have them behind a flag? Ah, I figured this out: the problem is you are testing the stable branch. In 2.14 there is a hidden and unsupported -DENABLE_CUSTOM_ELEMENTS build flag you can try using, but it might not be enough because it'll probably be disabled at runtime as well, and we have no way to enumerate or enable runtime experimental features except for CSS grid. We have a WebKitGTK+ experimental features environment variable that only covers CSS grid and does not map to the actual experimental features we have in WebKit. We should probably remove this or fix it somehow because it's surely not working properly right now: it's not OK for it to only work for only one particular experimental feature. But if you're testing 2.15.3, custom elements should be enabled and working by default. At least I see a progress bar on the custom element demo page, exactly the same as in Chromium, whereas in 2.14 I don't see anything. So the problem is just different release cycles. We really do need the full six months to make sure we're releasing a stable product. 2.16 will be released in two months. Michael _______________________________________________ webkit-gtk mailing list webkit-gtk@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-gtk
