Hi all,
It’s been a while since the Adobe WebPlatform team started contributing to the CSS Regions implementation in WebKit, and then also in Blink after the split. During this period, CSS Regions got enabled by default, albeit with prefixes, in Safari on iOS and OS X. Moving forward, we think that web developers would benefit from having CSS Regions enabled by default in Blink/Chrome too.
The existing CSS Regions implementation in Blink matches what Safari shipped on iOS/OS X. Since our goal is to ensure a solid CSS Regions implementation before shipping in Blink, we would like to reach an agreement with the Blink community about the things that need to be solved before enabling this feature by default.
In order to keep track of things, we created a list of master bugs for the engineering items:
* master bug for CSSRegions in Blink: https://code.google.com/p/chromium/issues/detail?id=236427
* master bug for the engineering items that should be done before unflagging/enabling by default:
https://code.google.com/p/chromium/issues/detail?id=319872
Below i will highlight the main areas we will focus our engineering contributions on in the next months, towards our goal of enabling regions by default in Blink.
1. CSS Regions and accelerated compositing
* Goal: enable accelerated compositing for content that is fragmented in regions
* Meta bug: https://code.google.com/p/chromium/issues/detail?id=319299
* Blink: started discussion on graphics-dev https://groups.google.com/a/chromium.org/forum/#!topic/graphics-dev/8Jp8aZ2Qji4
(Note: implementation close to finish in WebKit)
2. CSS Regions and overflow content
* Goal: make sure that content that overflows regions is correctly handled, without painting artefacts and hit testing in overflow content is working properly
* Meta bug: https://code.google.com/p/chromium/issues/detail?id=319306 (includes overflow among other things)
* Blink: layout overflow work started, visual overflow to be done after
(Note: layout overflow handling landed in WebKit, visual overflow handling close to land in WebKit)
3. CSS Regions and CSSOM
* Goal: make sure that CSSOM API for regions is implementable and updated to the latest WD.
* Meta bug: https://code.google.com/p/chromium/issues/detail?id=319326
* Blink: the most important change is the use of Map for modelling the document named flows collection
4. CSS Regions and selection
* Goal: make sure that selection/editable content is working properly (and spec compliant) in regions and that cut/copy/paste do something reasonable
* Meta bug: https://code.google.com/p/chromium/issues/detail?id=319310
* Blink: added selection tests, started work on fixing issues in partnership with Igalia (http://code.google.com/p/chromium/issues/detail?id=319305)
5. CSS Regions interoperability with transforms
* Goal: make sure that the content flowed in regions and the regions themselves work properly when transformed
* Meta bug: https://code.google.com/p/chromium/issues/detail?id=319317
* Blink: requires work for 1. and 2. to be completed
6. CSS Regions interoperability with new layout modules
* Goal: make sure that CSS Regions work properly with flexbox, grid and multi-column
* Meta bug: https://code.google.com/p/chromium/issues/detail?id=319319
* Blink: we already fixed couple of issues related to regions and flex box, bug fixing remaining
7. Unprefix CSS Regions properties/APIs
* Meta bug: https://code.google.com/p/chromium/issues/detail?id=320543
In addition to the above items, there are a couple of engineering items that should not impact the decision of shipping regions, but are needed to fully implement the CSS Regions spec. We think that these items should be worked on after regions are enabled by default/shipped in Blink:
* CSSOM Region interface: we validated with Adam Barth that the Region interface can be implemented as described in the current version of the spec (https://codereview.chromium.org/38943008/)
* CSSOM regionFragmentChange event (http://dev.w3.org/csswg/css-regions/#named-flow-events)
* Region styling (http://dev.w3.org/csswg/css-regions/#the-region-pseudo-element)
** basic support (colour and background-color) available already in Blink
** Meta bug: https://code.google.com/p/chromium/issues/detail?id=319383
* CSS Regions support in WebInspector
** Meta bug: https://code.google.com/p/chromium/issues/detail?id=319370
* flow-into: ‘content’ (http://dev.w3.org/csswg/css-regions/#the-flow-into-property)
* Multi-column regions (http://dev.w3.org/csswg/css-regions/#multi-column-regions)
** Goal: add support for making a region from a multicolumn element
** Meta bug: https://code.google.com/p/chromium/issues/detail?id=320552
* Pseudo-elements processing model (http://dev.w3.org/csswg/css-regions/#processing-model)
* CSS Regions and Shadow DOM
** Meta bug: https://code.google.com/p/chromium/issues/detail?id=319878
Mihnea-Vlad Ovidenie wrote:
> It’s been a while since the Adobe WebPlatform team started
> contributing to the CSS Regions implementation in WebKit, and then
> also in Blink after the split. During this period, CSS Regions got
> enabled by default, albeit with prefixes, in Safari on iOS and OS
> X. Moving forward, we think that web developers would benefit from
> having CSS Regions enabled by default in Blink/Chrome too.
I don't agree. The current approach taken in CSS Regions is, I
believe, harmful to the web. It mixes document style and structure,
abuses HTML tags for presentational purposes, requires code that is
vastly more complex and verbose than is needed to achieve common
layouts, and leads to per-document style sheets that are
non-responsive to the users' environment. I've expanded on these views
here:
http://alistapart.com/blog/post/css-regions-considered-harmful
If Regions are turned on, it will be very hard to turn them off again.
Caution should therefore be taken.
That being said, I believe in reusing code for fragmentation so that
pagination and multi-column layout can be done using the same code. I
believe Adobe has contributed good code for this purpose.
Cheers,
-h&kon
Håkon Wium Lie CTO °þe®ª
how...@opera.com http://people.opera.com/howcome
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Regions brings a large amount of both future and current complexity to
Blink. Both complexity inherent in the spec as well as complexity of
the current implementation. All features have some complexity cost,
but looking closely at Regions I have come to believe the cost/benefit
to be very imbalanced, especially in the context of Blink’s current
goals [6].
As you and others have excellently stated, Regions addresses some very
real deficiencies of the web platform. But I believe Blink (hopefully
with Adobe’s help) will need to find other simpler/smaller ways to
address these deficiencies. Perhaps we can find solutions via other
proposals (Mozilla’s Fragments [7] or Opera’s Figures [8]?) or (yet
unproposed) exposure of basic text layout primitives (like iOS? [9])
to allow frameworks to implement region-like layouts for the web in
JavaScript.
All the other solutions are only changing the CSS API surface and not the actual result. Basically, they are all trying to achieve almost the same thing with a different degree of flexibility. Any CSS API we choose to implement will have the same amount of complexity because it actually needs to split paragraphs across arbitrarily sized boxes.
I hope that despite this bump in the road you and your team at Adobe
will be interested in continuing to work with Blink. After the
short-term performance needs are addressed, I too believe the mobile
web will come to demand advanced text layouts like some of what
Regions enables. I just believe that at the time we add those, we
have to do so in a 60hz-smooth simple-to-maintain fashion and I hope
you and Adobe will be a part of that.
Sincerely,
Eric Seidel
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
☆PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Lars Erik Bolstad wrote:Indeed. In order to compete with native apps, the Web needs both high
> 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.
performance, and the ability to create paged & multicol presentations
(without invoking JS).
Our Blink-based implementation of this functionality currently relies
on fragmentation being done by the Regions code. It makes sense to use
the same code for all fragmentation, including pagination and multicol
support. The question of code reuse is separate from whether Regions
should be exposed through CSS or HTML.
I trust you take this into consideration before rushing to delete code we've contributed to Blink.
How many of those 10000 lines would need to be kept in order for the multi column support to still work, but removing anything that is only needed for providing CSS Regions to the end user? Would the lines that are kept be "all over the place" or would they be in only a limited area?
Looking at your patch, ~10000 lines out of ~586000 (we counted also the comments and blank lines from your provided link) account for 1.7% of the total C++ code in Blink. We also counted 31 files of contained CSSRegions functionality with about 6300 lines. The css regions related functionality in WebInspector touches 11 files with about 1500 lines.
Thus remain ~ 2200 lines of C++ (code, comments, blanks) functionality including parsing, css properties exposure, js exposure and layout and rendering (we assume that whatever you need to parse, expose in css and js will also touch a good amount of files).
We suspect your are mainly concerned about layout and rendering code. If so, we pledge to work together, address these concerns and make sure that the regions code does not hamper your Blink 2014 goals.
As others in this thread - Opera’s Morten, Lars and Hakon - have already pointed out, multicolumn based on regions offers a superior approach to the old multicolumn code.
At this point, we feel it is important to discuss a bit about why fragmentation is a hard problem to solve. This is the first question one needs to ask when seeing the numbers that came out of your patch. The answer has its root in the layout model of the engine: one element - one renderer - one box paradigm. Fragmentation brings more complexity to the table: one element - one renderer - multiple boxes (fragments).
The difference between the other layout modules you mention (flexbox and grid) and fragmentation based layout modules is the complexity of having multiple fragments for an element. An implementation handling fragmentation needs to:
- handle fragments of varying width for elements
- determine what content goes in what fragment
- paint those fragments on the screen, isolated from each other
- handle hit-testing in each fragment (it’s no longer enough to know the hit target element, you have to know the hit target fragment as well)
- make existing Web APIs fragmentation aware (e.g. getBoundingClientRects(), events etc.)
- handling weird dependencies between fragment containers caused by the content in one fragment container affecting the content in previous fragment containers
Looking at this list, we think that having about 1.7% of the code size dedicated to fragmentation is actually good news for a layout engine.
Regarding flow threads, they appeared after multiple failed solutions for the fragmentation problem. For example, the multi-column implementation followed a rough path:
- the old implementation - at paint time only, filled with bugs and limitations.
- the current implementation - at layout time and paint time, fixed a lot of issues but the code is intrusive and had some security bugs (https://bugs.webkit.org/show_bug.cgi?id=38402 - see the complexity of the patch)
- the new implementation - it came up as a relatively thin layer on top of RenderFlowThread. Most of the fragmentation complexity of multi-columns is handled by the generic flow thread class.
Flow threads are the most complete and bug free existing solution to fragmentation due to extensive testing, mostly happening while developing regions (which also lead to a lot of code interference).
Therefore, it is our opinion that RenderFlowThreads && co. offer an elegant, unifying solution to fragmentation. There’s surely place for optimisations and code isolation even more than it is today. After reading Blink’s 2014 goals from your email, we’ve started thinking about how we can align Regions to those goals. For starters, we noticed that the compiled code built on top of the CSS Regions foundations, that includes the new multi-column implementation, accounts for only ~300KB of the total 110MB, the size of the Content Shell (on a Mac machine).
As discussed in our proposed 2014 Goals for Blink [6] I believe
Blink’s focus this year must be on mobile and specifically mobile
performance. Speaking with other rendering experts, I have come to
understand that Regions both does not play well with existing
performance optimizations as well as (through its pervasive
complexity) impedes ongoing simplification and optimization work to
our core rendering code.
It would be a real benefit to hear more about the performance optimisations - ongoing and future - that are impacted by regions code.
Specifically about the impact on existing performance optimisations, could you be more specific? We have run the existing performance tests with and without regions and we did not notice any performance regressions.Complaints from core rendering engineers, my
readings of the Regions spec, and then finally my preparing this diff
(only to find these huge complexity costs) are what eventually
reversed my opinion on Regions.
In the past, we tried our best through blog posts, code samples and presentations (BlinkOn included), to introduce the regions concepts. The problems regions address are complex and we wanted to make sure that regions concepts are understood correctly not only by a few CSS experts but rather by the web communities. Again, I believe that dialog and cooperation are key here to make sure everybody has an informed opinion that is critically important as a base for any future decision.
I believe if Blink were offered a patch to add CSS Regions today
(inverse of [4]), it would not be accepted. Considering this
complexity and the objections from other browsers, I do not see how
it’s possible for Blink to ship Regions.
As you and others have excellently stated, Regions addresses some very
real deficiencies of the web platform. But I believe Blink (hopefully
with Adobe’s help) will need to find other simpler/smaller ways to
address these deficiencies. Perhaps we can find solutions via other
proposals (Mozilla’s Fragments [7] or Opera’s Figures [8]?) or (yet
unproposed) exposure of basic text layout primitives (like iOS? [9])
to allow frameworks to implement region-like layouts for the web in
JavaScript.
Time will tell whether the proposals you quote are the solution for the problems regions are trying to solve. Implementing fragmentation natively is hard and each proposal will have to deal with its complexity. Again, I pledge to work together for better containment of the code and reduce invasiveness.
Our experiments using a CSS Regions polyfill written in JavaScript showed that on mobile, the polyfill is not a viable alternative for now to the native implementation.
I hope that despite this bump in the road you and your team at Adobe
will be interested in continuing to work with Blink. After the
short-term performance needs are addressed, I too believe the mobile
web will come to demand advanced text layouts like some of what
Regions enables. I just believe that at the time we add those, we
have to do so in a 60hz-smooth simple-to-maintain fashion and I hope
you and Adobe will be a part of that.
Sincerely,
Eric Seidel
as for these goals, are they published anywhere on beforehand?
If someone else is to try to implement anything with fragmenting some time in the future, they will likely have to spend as long as the CSS Region team to get the code into production quality level -- meaning years. But if Chromium sets the goals for Blink on a yearly basis, throwing out anything that isn't a 100% fit for their short-term strategy, then it seems like it will be quite a huge risk to try to start projects of that magnitude for anyone else than those making decisions within the Chromium team.
Now this will hit hard on Adobe and Opera, yet Håkon's complaints about CSS Regions were the initial argument for this action. It seemed his argument was build around the idea that his "CSS Generated Content for Paged Media Module"specification would be better, yet the decision to throw out items that are not part of the short-term plan seems to make it impossible to try to implement this in the future as well.
So my question is: Will you release something like a preliminary five year plan of objectives for the next few years?
On Fri, Jan 24, 2014 at 8:40 AM, Johannes Wilm <ma...@johanneswilm.org> wrote:
as for these goals, are they published anywhere on beforehand?Eric linked to them in his post:
If someone else is to try to implement anything with fragmenting some time in the future, they will likely have to spend as long as the CSS Region team to get the code into production quality level -- meaning years. But if Chromium sets the goals for Blink on a yearly basis, throwing out anything that isn't a 100% fit for their short-term strategy, then it seems like it will be quite a huge risk to try to start projects of that magnitude for anyone else than those making decisions within the Chromium team.In the past, we haven't had as narrow a focus as we have this year. Instead, we've taken the approach of encouraging innovation by letting a thousand flowers bloom. I don't think that's a good approach this year because the world is changing rapidly and we need to adapt.
Now this will hit hard on Adobe and Opera, yet Håkon's complaints about CSS Regions were the initial argument for this action. It seemed his argument was build around the idea that his "CSS Generated Content for Paged Media Module"specification would be better, yet the decision to throw out items that are not part of the short-term plan seems to make it impossible to try to implement this in the future as well.
So my question is: Will you release something like a preliminary five year plan of objectives for the next few years?I don't think we've written out objectives for five years in the future. If we had written five-year objectives four years ago, I doubt they'd correctly anticipate which problems are important to solve today.
Hi Mihnea,I think you and Eric are talking past each other to a certain extent. My understanding of the discussion thus far is as follow:1) Eric's argument is that Blink's current goals are focused on mobile, particularly mobile performance. The reason we have a tight focus this year is that the web is behind on mobile and needs to improve substantially in the coming year in order to become a compelling platform on which to write mobile applications. Regions (and text fragmentation in general) doesn't help support this goal and, because of the complexity it introduces in the codebase, it actually makes it harder for the web to succeed on mobile.2) If I understand your argument correctly, you're saying that fragmentation is an important part of text layout and that the implementation complexity in Regions is arising because text fragmentation is a complicated problem. You're arguing that Regions is a good approach to implementing text fragmentation because it's simpler than other approaches and can provide a foundation upon which to build other text fragmentation features, such as multi-column. Alternatives to Regions aren't sufficient to solve the text fragmentation problem because they are either not sophisticated enough (e.g., Mozilla's Fragments proposal) or they don't perform well enough (e.g., a JavaScript implementation).Do you see the disconnect between these two arguments? Eric is arguing that we don't need to solve text fragmentation problem and that our efforts to do so are impeding our overriding goal of improving mobile performance.
You're arguing that Regions is a good solution to the text fragmentation problem.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
The new multicolumn implementation is much more conformant with the CSS Break spec than the old implementation. It would be a big step back for web compatibility to throw out the new code in favor of the old, non-conformant code.
I think complaints that (1) is complex in that every layout system has to think about how to do fragmentation are valid, but I think you signed up for that the minute you shipped a browser with the ability to print Web pages. My own opinion is that if you choose to ship a feature, you should want that feature to be as high quality as possible. If you're going to ship with printing and multi-column layout, then you have fragmentation in your engine, and the implementation of both should be high quality.
It seems to me that the real issue that is putting (1) and (2) at risk is that you need an owner of the code in Blink, and that the fact that it is unowned seems to be the real issue here.
One last point: I think it's a bit silly for fragmentation advocates to be bashing the current multi-column code as being "buggy" or "low quality." The multi-column code that ships in WebKit and Blink is perfectly fine. The primary intent behind the re-write is to enable new functionality, and the new code has ported the bulk of its logic from the old. While some long standing bugs have been fixed during the re-write (e.g., painting/stacking) those bugs could have been fixed in the old code as well.
[...]
>
> CSS experts from both Mozilla [1, 2] and Opera [3] have stated
> publicly their opposition to implementing CSS Regions and have
> commented at length on the Regions’ spec complexity.
For a more complete picture, I’ll note that Microsoft shipped an earlier draft of the feature back in IE10, and Apple shipped a modern implementation, based on the same WebKit code that Blink inherited, on iOS7 (Sept 2013) and Mavericks.
On Sun, Jan 26, 2014 at 12:18 AM, Alan Stearns <famu...@gmail.com> wrote:The new multicolumn implementation is much more conformant with the CSS Break spec than the old implementation. It would be a big step back for web compatibility to throw out the new code in favor of the old, non-conformant code.
That's unfortunate, but it's a cost we're willing to accept in order to focus on achieving other goals. As Eric wrote, focusing on mobile performance means not doing other things, and we're choosing to improve mobile performance instead of improving CSS Break spec conformance.
On Sun, Jan 26, 2014 at 9:42 AM, David Hyatt <daveh...@gmail.com> wrote:
I think complaints that (1) is complex in that every layout system has to think about how to do fragmentation are valid, but I think you signed up for that the minute you shipped a browser with the ability to print Web pages.
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.
[...] 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.
I would also like to argue that some of the features of CSS Fragmentation are not relevant for the vast majority of real world content and we should never support them. Specifically the ability to split arbitrary boxes across variable width containers is not something that I find magazines, document printing, or native frameworks actually do and it introduces lots of complexity.
It also produces counter intuitive behavior like http://jsfiddle.net/6xXFg/ where the flex box is painted three times with three different widths, but the flex items are not. I think we should seek to have this feature removed from multi column as well, which would similarly reduce the complexity cost of the multi column code in blink.
In blink we're pushing for simpler primitives that empower developers to build frameworks and applications. In that spirit we do not believe that use cases like dynamically moving menu items when the window resizes using regions make sense. It's fine if developers need to write some script for that, we're building an application platform, not a document viewer.
A major difference is that printing is to all same sized fragments.
I do not believe the complexity that RenderLayer has sprouted for painting region based multi column,
On Sunday, January 26, 2014 4:52:19 PM UTC-6, Elliott Sprehn wrote:In blink we're pushing for simpler primitives that empower developers to build frameworks and applications. In that spirit we do not believe that use cases like dynamically moving menu items when the window resizes using regions make sense. It's fine if developers need to write some script for that, we're building an application platform, not a document viewer.I guess that's where there's just a fundamental disconnect. You don't care about viewing books/magazines on a tablet I guess. That seems very short-sighted to me, but maybe you don't consider tablets to be mobile.
On Sunday, January 26, 2014 4:52:19 PM UTC-6, Elliott Sprehn wrote:I would also like to argue that some of the features of CSS Fragmentation are not relevant for the vast majority of real world content and we should never support them. Specifically the ability to split arbitrary boxes across variable width containers is not something that I find magazines, document printing, or native frameworks actually do and it introduces lots of complexity.This occurs quite regularly. It's even a desired feature of printing (the ability to have landscape pages for figures, etc. mixed in with portrait pages). It occurs regularly in magazines as well with both spans and sidebars.
I do not believe the complexity that RenderLayer has sprouted for painting region based multi column,You realize the old multi-column code has a bunch of stuff in RenderLayer also? The new multi-column RenderLayer code is required just to have a painting/stacking-compliant multi-column model. All other browsers besides WebKit and Blink get that right. Obviously the old multi-column code could be removed from RenderLayer as well once the new code is ready.The new multi-column code doesn't carry significantly more complexity or cost than the old code, yet you want to keep the old code but dump the new code. This doesn't make much sense to me. If the new code was vastly more complicated or something, than I could see that, but if anything, it's simpler and easier to understand than the old code, and it's much less intrusive into RenderBlock/BlockFlow than the old multi-column code.It seems like you're basically saying that multi-column is so unimportant that you don't even want to let people fix bugs with it (e.g., the RenderLayer code necessary to get the painting/stacking right). If that's the case, then you should just remove the feature completely. Leaving it in but refusing to let anyone improve it is just bizarre.
Hey again,Ok, given that there won't be understanding on this issue, how about making it easier to do this in Javascript? The most obvious thing it seems would help would be a simple way for the Javascript to have access to information about how much of a text (or element with subnodes) fits into a container without causing overflow. A second, less essential, piece of information would be where line breaks occur. Without this information available, javascript developers (like me) will have to try letter by letter exactly how much they can put into a container without causing overflow.Without knowing the specifics of the sources, I would imagine that this information is available internally anyway, so exposing it to the Javascript shouldn't hurt performance much.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Compare that to the approach used for text fragmentation in TypeKit:In that approach, you can only fragment runs of text not arbitrary UIViews. IMHO, an approach like that would impose much less complexity on the engine because not every block layout primitive would need to deal with fragmentation.Adam