Blink-WebKit split endangers some browser features
Developers may have to adapt to browsers that lose features, such as CSS Variables, as Google and Apple part ways in browser development.
- Shankland covered the tech industry for more than 25 years and was a science writer for five years before that. He has deep expertise in microprocessors, digital photography, computer hardware and software, internet standards, web technology, and more.
CSS Variables, a handy technology to ease Web page programming, could be one casualty in Safari with Google moving its resources to its browser engine, Blink.
Google engineers wanted to "fork" the WebKit browser engine project that underlies both Safari and Chrome so they could accelerate the pace of Chrome development and adopt changes too extensive to fit into a single open-source project. Even though splitting Blink away from WebKit may make each browser engine more nimble, it also means it's harder to cooperate.
That's because common features must be developed and maintained by duplicate teams for each project, rather than by a single shared team. It's a complication of open-source software forks, as in the cases of OpenOffice.org vs. LibreOffice for office productivity suites, GCC vs. EGCS for software compilers, and the Mambo and Joomla content-management software projects.
Over the weekend, WebKit started grappling with one such situation with CSS Variables. This newer Web standard lets programmers define variables, such as "main-bg-color" and then reuse that variable repeatedly.
Judging by the list of unmaintained features in WebKit -- some of them used in WebKit-based browsers -- it doesn't look like this will be the last discussion over how to handle once-maintained features.
The CSS Variables discussion began Sunday with a post by Apple's Andreas Kling on the WebKit developers' mailing list.
"I'd like to remove the CSS variable feature from the tree now that Chromium has left, as they were the only ones shipping it AFAIK [as far as I know]," Kling wrote. He added shortly afterward: "This is not about variables being a bad feature; it's about removing unmaintained code. We can easily restore the code and continue/complete the implementation later, if/when the functionality is wanted."
One who spoke out against the idea was Web developer Jon Rimmer. In a comment on the bug discussion, he said: "As a web developer, I have to say that this is an extremely disappointing decision. Apple should be turning this feature on in their browsers, not removing it." And on the mailing list, he added:
It seems like WebKit is at a crossroads: You can deal with the engineering shortfall that Google's departure has left you with by simplifying the architecture, cutting out their features and continuing at a reduced pace, or by stepping up yourselves to fill the gap. I think it would be better for the Web and for WebKit if you chose the latter.
This latter opinion triggered a frosty reception.
But there could be a solution in sight: Open-source programmer Karen Shaeffer said she might be able to maintain the feature.
"I am very interested in webkit, and this seems like a good time to step up to help the team," she said, requesting a week to make the decision.
"If waiting a week means we get a new contributor," responded Apple's Benjamin Poulain, "that sounds like a good deal."