Google Groups

Re: [blink-dev] CSS Regions in Blink: status, future work


Eric Seidel Jan 25, 2014 4:13 PM
Posted in group: blink-dev
As noted in the previous goals discussion [1], we perceive an urgent
need to improve Blink on mobile, necessitating focus there.  Focus
means not doing things.

For cross-cutting features like Regions, the cost to the project
scales quadratically -- each additional feature interacts with every
other feature and has a cost proportional to the number of other
features in Blink.  A tiny example of this came up this week when Adam
removed <iframe seamless>.  Removing seamless also removed several
call-sites which existed just to teach seamless and Regions to play
nice together [2].

I have spoken with the most active contributors/maintainers of
core/rendering and the sentiment was that they do not see Regions on
the critical path to mobile success or want its complexity in the
codebase.  I’m sorry.  I wish we had communicated better as Regions
developed (or the market changed) to avoid this surprise.


Dirk (and Mihnea and Morten) wrote:
> As Mihnae mentioned before, ~80% of the 10k LOC are dealing with CSS Fragmentation.

I suspect that you’re right that a large part of the complexity cost
of Regions comes from CSS Fragmentation.

I expect the rendering maintainers would like to remove multi-column
and fragmentation complexity as well.  Multi-column’s 2% usage [3]
seems low to justify its cost.  However, since we’ve shipped
-webkit-column* and  2% is above our removal threshold [4] I can’t see
us easily removing multi-column.  I certainly would welcome
simplification of our multi-column down to a single implementation,
but that implementation should ideally cost us the same or less than
the low-usage one we’ve had for years.

If Opera sees multi-column as being on the critical path to success
for mobile, and has interest in maintaining more of the core/rendering
code and reducing multi-column’s complexity in Blink, I could get
behind that.


Lars wrote:
> From Opera's side we agree with the prioritization of performance optimizations in Blink,
> and we'd be happy to help identify issues and improve that aspect of the Regions code.

I’m very glad to hear that. Chrome and Opera’s goals seem rather
fantastically well aligned about making the mobile web awesome.  I
believe where our opinions may differ is about what the complexity
cost of regions/fragmentation code is and if it’s close enough to
Blink’s critical path towards mobile awesomeness to justify its cost.


Ethan wrote:
> Are you suggesting that the negative opinions of two individual working group members should outweigh
> the positive opinions of two other browser vendors, as indicated by their shipping software?

I hold huge respect for the opinions of both Dave Baron and Hakom and
trust them to have a better understanding of CSS specs than I do.  I
cite their opposition as examples that the dust has not settled on
text fragmentation.  I don’t believe I have a lot of value to add in
choosing the right text fragmentation spec, and I don’t think Blink
should commit to shipping (and indefinitely maintaining) a text
fragmentation system at this time.  We inherited this one from Apple’s
WebKit, we can write/port one at a later time if our users/developers
on the mobile web demand it.


Hakom wrote:
> It should be possible to make compelling ebook readers in browsers.

My goal is to make the mobile web platform successful. In so far as
ebook readers may be a popular class of mobile applications (that’s
not clear to me? [5]), I am interested in supporting their success on
the mobile web platform.  We also have to be careful to weigh the
benefits to one class of applications with the cost the code to
support them imposes on the entire platform.  Right now Blink is full
of many low-usage [6], high-cost features which we perhaps could
afford on Desktop but are hurting us with their compounding-complexity
on Mobile.


On a separate note: I do not believe Blink needs to build-in as
powerful a layout engine as may be possible for print media.  I see
WebKit as often being embedded as a text-layout-engine, almost as a
competitor to LaTeX.  However, I think Blink (and the web platform)
should empower developers to build powerful applications, but should
not necessarily favor one class of applications over another by
embedding special-case logic in its core.  Browsers, as we’re all well
aware, stopped just being document viewers long ago.


To move forward, I propose:
- Work with Adobe to remove CSS Regions from the Blink on a timeframe
which is compatible with their branching needs, etc.
- Work with Opera to understand their short-term needs for
multi-column, if they believe CSS Fragmentation is necessary for
multi-column/blink-mobile-success and if they’re ready to assist in
better integrating and maintaining that code going forward.  If not,
then work with Opera and Adobe to remove CSS Fragmentation as well.


There is also possibly more discussion to be had between the advocates
of these features and the the current maintainers of core/rendering.
I’m only one voice there, so perhaps I should stand out of the way and
let those folks talk.  But as it stands, I do not see us shipping CSS
Regions or its dependent CSS Fragmentation and thus both should be
removed from Blink.


Sincerely,
Eric Seidel

1. https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Z5OzwYh3Wfk/IWooaY5FZowJ
2. https://codereview.chromium.org/138443013/patch/40001/50115
3. http://www.chromestatus.com/metrics/css/timeline/popularity/218
4. https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/bs3NIiqnc8Q/2kF7HNr4kSAJ
5. http://blog.flurry.com/bid/95723/Flurry-Five-Year-Report-It-s-an-App-World-The-Web-Just-Lives-in-It
6. http://www.chromestatus.com/metrics/css/popularity