Updated: Comment #8

Problem/Motivation

The breakpoint module was the first implementer of config entities. There are numerous issues:

Proposed resolution

  • Remove breakpoint module from 8.x core and move to contrib
  • Remove picture module from 8.x core and move to contrib
  • Make toolbar module add its own media queries
  • Remove breakpoint config from Bartik, Seven, and Stark

This major because if we don't do this we have a lot of work to modernise these modules. Contrib will be a great place to explore this functionality.

Remaining tasks

Decide.

User interface changes

Removal of the picture module's UI.

API changes

Removal of the breakpoint module's API.

#1855412: Enable picture.module by default for standard install profile.
#1880606: Introduce a configuration UI for theme-based breakpoints
#1883526: Decide on the picture polyfill to use
#1851018: Improve breakpoint configuration implementation.
#1937914: Special handling for setting the BreakpointGroup::breakpoints property during ConfigStorageController::importChange()
#2132551: Picture module uses config keys with a dot

Issues that will be impacted

We are working to improve Breakpoint in the following issues

#2030585: Expand Breakpoint with methods
#2030587: Expand BreakpointGroup with methods
#1820512: Move Breakpoint module closer to meeting Drupal standards
#1828606: Make BREAKPOINT resources inheritable

Files: 
CommentFileSizeAuthor
#5 3-5-interdiff.txt725 bytesalexpott
#5 2120875.5.patch126.86 KBalexpott
PASSED: [[SimpleTest]]: [MySQL] 58,911 pass(es).
[ View ]
#3 2120875.3.patch126.05 KBalexpott
FAILED: [[SimpleTest]]: [MySQL] 58,147 pass(es), 28 fail(s), and 56 exception(s).
[ View ]

Comments

Issue summary:View changes

Updated issue summary.

Picture module is a major piece of the mobile initiative. I'm not even sure why it's off by default.

All the JS/CSS work in the world won't come close to bandwidth savings from picture+breakpoint module. If there is an issue it should be fixed instead of removed.

Issue tags:+JavaScript, +mobile

also, tag

Status:Active» Needs review
Issue tags:+Needs manual testing
StatusFileSize
new126.05 KB
FAILED: [[SimpleTest]]: [MySQL] 58,147 pass(es), 28 fail(s), and 56 exception(s).
[ View ]

We still need to get agreement here... but here's a patch to sure what'll change in the toolbar module

This issue does not deny that there are huge benefits to frontend performance to be made just that Drupal core probably not the place to explore this - this area is changing rapidly and afaics the browser vendors and standards groups are still to settle on an implementation.

As you can see from the patch the way the toolbar module is using breakpoints is not at all as configuration - i.e. as something that could be edited and there is value in deploying. The config will always be the same on dev and production - the breakpoint labels are hardcoded into the toolbar.js file :)

Status:Needs review» Needs work

The last submitted patch, 2120875.3.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new126.86 KB
PASSED: [[SimpleTest]]: [MySQL] 58,911 pass(es).
[ View ]
new725 bytes

Whoops

There's also #1855412: Enable picture.module by default for standard install profile.

Also related: #2061377: Allow image style/picture mapping to be selected in Text Editor's image dialog (necessary for structured content) which would then in facto enable picture module for standard and would be a huge win for site builders.

I would rather help modernising the modules then throwing them out tbh.

Issue summary:View changes

Ok in core code but not in an issue summary created by a Brit

Issue summary:View changes

update summary with more related issues

I'm not suggesting "throwing them out" - I'm suggesting that contrib will be a better place to explore this functionality because the standards for responsive images are still in flux, the UI for breakpoints has been punted to 9.x (#1880606: Introduce a configuration UI for theme-based breakpoints) and the current modules are not working correctly.

Issue summary:View changes

Updated issue summary.

To explain from a CMI perspective why the breakpoint needs a lot of work. Breakpoints currently have two config entities - Breakpoint and BreakpointGroup. Unlike other config entities in order to declare breakpoints modules have a simple config file eg toolbar.breakpoints.yml or bartik.breakpoints.yml on install the breakpoint module then creates the config entities. This is an anti pattern - the node module has views.view.frontpage.yml for example.

I'm probably biased, but I agree with @swentel (#7), we can fix this.

Breakpoints and picture are one of the important aspects of the Mobile Initiative and if we move this back to contrib a lot of Drupal sites are not going to follow back practice for mobile devices. You're right that the whole picture discussion is still going on, but the idea was to make sure that Drupal will be ready whenever there's a decision.

#3 If toolbar is using hard coded breakpoints, it should probably be fixed to allow people to customize them.

#8 The interface referenced in #1880606: Introduce a configuration UI for theme-based breakpoints was part of the spark initiative, the original was way simpler, and can probably be added to Drupal 8

#9 You're right about the CMI, but since the moment breakpoints was added to core, a lot has changed, IMHO these are things that can easily be fixed.

Before any decision is made, I would like to here feedback from some more people.

Not having a UI is not an argument for removal. We should stop trying to add UI's for everything.

However I agree that its not fully clear yet why this should be in core.

#11

Reasons why this should be core:

  1. Best practice for responsive web design, so it's easier for site builders to use this. For Drupal 7 there are a lot of modules for mobile/responsive images, but - just a guess - only 10% of all Drupal 7 sites are using a responsive theme and even less are using a solution for handling images on mobile devices.
  2. Good promotion for Drupal 8, it can be announced as a CMS ready for the 21th century adopting a lot of best practices out of the box
  3. Implementing this in contrib will be a lot harder. For Drupal 7 this is already hard, because a lot of contrib modules are extending the image module (think colorbox, flexslider), to be able to support these for picture (Drupal 7) we each time have to add conditions in the picture module.

One other remark: it might be a good idea to merge picture and image into one module, so it's easier for contrib to extend both at the same time, but this is off topic in this issue.

Issue summary:View changes

Updated issue summary.

#8 Can you explain "the current modules are not working correctly" a bit?

#9 Regarding the anti-pattern (which it is), it was developed like that to make it easy for themers. I still think it was a good idea back, but I admit it feels strange if only breakpoint will be doing this.

So to solve this we can change the way breakpoints handles the config, we can force modules and themes to define the group as well and use an extended syntax to do so.

So toolbar.breakpoints.yml will become breakpoint.toolbar.yml with something like this

label: Toolbar
description: 'Breakpoints used for the toolbar.'
status: true
module: toolbar
id: toolbar
uuid: ....
group:
  default:
    narrow:
      label: 'Narrow'
      mediaquery: 'only screen and (min-width: 16.5em)'
    standard:
      label: 'Standard'
      mediaquery: 'only screen and (min-width: 38.125em)'
    wide:
      label: 'Wide'
      mediaquery: 'only screen and (min-width: 52em)'

I'm suggesting that contrib will be a better place to explore this functionality because the standards for responsive images are still in flux

I think this is a very good point. Will we end up in a situation where Drupal is very out of date in the way it handles responsive images as new techniques emerge? As best practices change, core would need to be updated. Will Drupal be able to make an exception here and do point releases where picture module changes significantly? If not, then I am afraid I agree with @alexpott regarding Picture being removed from core.

Over the life of D8, if picture module is no longer considered a "best practice" (say its 2014) and Picture is locked into "2013 best practices" then it will become another unused core module (thinking about Poll module or Blog here... ) people will inevitably move to another contrib that replaces Picture. I could see breakpoints having a similar problem.

#15 Yes and No, it might be that the picture proposal isn't accepted (for the moment the focus is on scr-N and CH), but the PHP side stays the same: you have one image that has to be represented using multiple image styles. The output (HTML) and the polyfill (js) might change, this means the twig template and attached js library might change, which in fact is only a small part of the code.

Off-topic, but also of interest: srcset needs to be handled as well, since it is already implemented by blink, so following the same reasoning, should we remove image from core as well? Same goes for CH. So we need a way to output plain images and a way to handle complex cases where a site administrator has to define what needs to be outputted and when. So site administrators need a way to define multiple sets of rules (any combination of multiplier, media query and image styles), like mentioned before (#12) , if we don't provide the basics in core it will not be used and/or will be hard to implement in contrib.

#3 If toolbar is using hard coded breakpoints, it should probably be fixed to allow people to customize them.

The tight coupling between Toolbar and Breakpoint exists because we need to trigger specific behaviors at relatively ordered breakpoints. The value of the breakpoints can be changed, but the number and order cannot. What would it mean to define a breakpoint for Toolbar if we can't associate it with a callback on the front end. In that way, about the only thing an end user can do is adjust the points at which the Toolbar breaks into different behaviors, but not the number of points at which this occurs.

#17 Thanks for clarifying

I've done some work on modernising the breakpoint module see #1851018: Improve breakpoint configuration implementation.

Priority:Major» Critical

Is the potential removal still on the table? I think we need to decide fast since people start postponing issues because of this issue. Hence bumping to critical.

IMO these two modules are key cornerstones of the Mobile initiative, and I'd like them to stay. If we're seriously attempting to say we can't ship Drupal 8 without removing them, then this needs to be assigned to Dries. Shipping "mobile-first" Drupal without a responsive image solution (and it's fine if that solution gets revised in later point releases) seems like a bad idea to me, though.

...it's fine if that solution gets revised in later point releases

If thats the case, then I agree and they should both stay in core.

If I had to place my bet right now, it would be that the markup approach that gets standardizes is the src-N attribute proposal, rather than the picture element.

I think that's more than fine: the Responsive Images Community Group that has been pushing for the picture element seems like it's on board with src-N, as it provides similar tools to address the responsive images use cases, except that it does so with attributes like src-1 and src-1, rather than source elements that are children of the picture element. The syntax is a bit different, but the logic is pretty similar. I would imagine that it would be pretty feasible to adapt the code used for Picture to generate src-N output instead.

Coupling src-N with client hints would be even more powerful: if we can work out a way for Drupal to help make client hints easier to implement, that will be huge win.

Browser developers seem to be much more interested in implementing src-N than picture right now, and I would expect we will likely see first implementations rather soon, well before Drupal 8 is ready to launch.

Whether or not that's the case, however, picturefill works today as a viable responsive images solution. I've used Picture and Breakpoint on a D7 site to provide significant performance benefits on smaller screens. Picturefill doesn't have performance benefits that are as significant as if browsers build in a responsive images solution, where image sources can be picked up by the image preloader and thus load faster, but picturefill still helps to save significant bandwidth.

Even if src-N isn't 100% ready to go, I'd think it's still worth using picturefill for now. If the markup pattern changes, and src-N is implemented, that could be swapped out in an 8.1 release.

In the meantime, I think it makes a lot of sense to continue to work on improving how Breakpoint and Picture are working with CMI, so that when a markup pattern is finalized, the rest is ready to go.

I still hold out hope that something like #1880606: Introduce a configuration UI for theme-based breakpoints can be brought back from the grave (even if it's in a point release), because something like that would make it much easier to configure breakpoint groups.

The challenge with picture and with src-N is that they are based on selecting the size of the image source files solely on the viewport width, because that's the only data point that browsers can know soon enough to get the image source picked up in the image preloader. If you have a multi-column layout, and if you have several different types of images (hero image, gallery image, sidebar image, etc.), it gets complicated very quickly. For each type of image, you need to understand the maximum amount of space the image will take up within the layout each time a breakpoint shifts the layout. Calculating that by hand can be a pain. However with something along the lines of #1880606: Introduce a configuration UI for theme-based breakpoints, if Drupal understood how many grid columns existed at each breakpoint, and how many columns an image type filled at each breakpoint, then it would be very straightforward to calculate what image sizes are required at each breakpoint for each image type. If a site builder didn't have to make those calculations manually, it would be a huge, huge win and would position Drupal as hands-down one of the best solutions to provide easy-to-use responsive images out of the box.

Again, maybe that doesn't make 8.0. Maybe it's 8.1 or 8.2. Or if not, then in contrib. But for me, that's the long-term vision for how Drupal can provide a really top-notch responsive images solution.

But for now, just getting picturefill into an 8.0 release would provide a solid option, particularly if there was a commitment to swap it out with whatever is the final solution for responsive images, such as src-N.

Just changing the markup after release is not going to be an option if it's going to break themes - unless we adopt semantic versioning and explicitly break the markup in a minor release, or just tell people that any <picture styling is going to get broken in a point release if we don't.

I don't have very strong views on removing vs. fixing. Even if we remove, we could potentially re-introduce the module to core after 8.0 once it's up to date with CMI and/or if browser implementations appear/settle down, so it's not necessarily even either/or.

Assigned:Unassigned» Dries

#24 The markup is probably going to change, but I don't really see huge problem doing so. For the moment the output will be a set of <span> tags, if - for example - srcN gets adopted and implemented after 8.0 release, the markup will change to <img src1="">. But the problem of backwards compatibility with existing browser will stay, so it will always be a moving target, but that doesn't mean that we can provide site builders with a sane default approach.

Most themers I know will use classes to do the styling, they - mostly - will never write css like

span {
  ...
}
img {
  ...
}

And even ig they do, the changes to theme's are going to be minimal.

Like said before (#1, #16, #23), if we remove it from core, we'll break the mobile initiative and we'll teach site builders some bad habits.

Assigning to Dries so he'll sees it ;-)

#24: even if the markup changes, themes would/should be unaffected, as attiks already explains. I think it is wise though to explicitly inform people that the responsive images implementation might change over time, and that's only natural because there's no standard yet.

I'd push for leaving the modules, and improving where we can for D8 release,
but an explicit warning that these are bleeding edge implementations and subject to change.

Ideally, any improvements in D8 which involve markup changes, would be 'optional'.
So should any improvements break a custom theme, then the site admin could switch on 'compatibility mode', and retain the 'old' markup.
I have no idea how complicated that might be.

Issue summary:View changes

added #2030587

Personally I think that #1851018-26: Improve breakpoint configuration implementation. is justification for removing these modules from core since it says

Is there any possibility we could still get UI for breakpoints in before release? It's going to be difficult for people to make much use of Picture without the ability to configure breakpoints.

AFAICS there is no chance of getting the UI in. Which is one of my major concerns since we're guessing use cases with the current data structure.

#28, #29 The UI developed in http://drupalcode.org/project/breakpoints.git/tree/refs/heads/core_ui:/b... should still be pretty usable, I don't really see a problem with adding a simple UI to define breakpoints and groups. The discussion last year got derailed because we were aiming for an improved UI, mostly based on the layout module. Is there really no change to add a UI (BTW just asking)

Regarding the use cases, the same modules are used in Drupal 7 and by others (non-Drupal)

You're right that it will be more difficult for people to make optimal use of picture, but even with a UI it isn't going to be easy, that's one of the reason the proposed UI was not accepted. Multiple UI's might be a good idea to handle this problem, so people who want full control can use one, while people who wants a more fancy simplified version can use an other one. Comparable to views and simpleviews if you want.

Why is an UI even essential? Once theme breakpoints are being detected again, users can just define picture mappings based on theme breakpoints, and AFAICT that's perfectly fine for simple out of the box usage?

#31 You're right, even without an UI basic use is covered

If there's no UI, then it's critical for themes to provide their breakpoints so those can be picked up.

With that, you can at least assign different image sizes to the primary breakpoints.

Maybe a contrib module could handle setting up secondary breakpoints to allow more fine-grained shifts of image sizes in between the primary breakpoint, if necessary.

It would be nice if a theme could ship with some default picture mappings. That would allow a themer to set up a few different types of images (hero, sidebar, etc.) with different sizes for each breakpoint, without a site builder having to figure that out. Is something like that possible with the current way this implements CMI?

If we have no UI can someone explain to me how to update theme breakpoints? I want to change them during theme/site development. Is there a way to do this?

Change the breakpoint values in the appropriate .yml file: https://drupal.org/documentation/modules/breakpoint

@John Pitcairn, the only way I can see to do this is import single, aka find the right config file in the active store, copy it, change the values and import it. You can export single also, but you have to guess the breakpoint from the simple select list. Changing the themes breakpoint config does update the active store (works as designed afaict).

So great, yes there is a way to update them, so basic usage (#31, #32) is possible with no UI for Breakpoint module, however being able to change them more easily/quikly would be pretty nice.

Jeff, the breakpoints configuration has just been improved. This patch dropped just a few hours after your last post:

https://drupal.org/node/1851018

You might want to pull the latest 8.x and see if this addresses your concerns.

On another note, just an update that there's been a big discussion about responsive image syntax the last week between browser developers and on the WHATWG list.

The discussion of the src-n proposal has resulted in a revival of a slightly modified version of the picture elements. We'll see if this development holds, but it appears that browser implementors' concerns about picture may have been resolved.

If that is the case, and the picture element ships, Drupal's going to look really, really smart for being one of the first CMS's out the gate with working support for the picture element!

If a new attribute may be added to browsers like src-n it will take roughly 3-5 years to get propper support in all browsers. Beeing realistic it may takes 2 years to make it working in a few browsers. That's really far away... In this case contrib may really be better to run something that has no standard we can rely on.

For what it's worth, I don't think it's unreasonable for themers—like myself—to manually set our breakpoints in code, as long as the process is well documented. Theming means that sometimes you have to edit a text file and I'm OK with that. So the lack of a comprehensive UI for setting breakpoints should not be used as a reason to pull the functionality out of Core, IMHO.

Likewise, Re #39, I don't see the current lack of browser support as a reason for pulling this feature. We should strive to stay ahead of the curve, rather than play catch-up later. This is a difficult, long-standing issue and if we can provide a solid default solution now then I find that commendable, even if we need to make some modifications to it in the coming years as standards solidify.

Yeah, but are we really able to make large changes in core if things change fundamentally and api changes are required? I don't think so...

From what I've read in this issue, we aren't really talking about API changes. At most it sounds like we're talking about markup changes—and likely minor ones—so I don't see any big blocks to making such updates to core. Especially if the core release cycle changes, as is being proposed. Plus, if you really think browser support is 3-5 years away, then we should be on D9 by then, so there will be an opportunity for big API changes, if we should need them.

@mdrummond cheers for that, yes I had seen that issue.

Personally I'd like to see the modules stay, and if no Breakpoints UI in 8 then maybe in 8.1. If we could build one in contrib then that would be great until we get something into core.

Agree with @jstoller that if things are well documented then it's not really a problem, even non-technical users can do this in code, it's pretty strait forward.

I dont think everything, in core needs a UI. I don't think it makes a lot of sense to have a UI that you really can't do a whole lot with it.

Yeah, I kind of agree as well, I think this is a hard one, as in how will this play out in the real world. I tend to think users will want to tweak breakpoints and not be bound by their themes breakpoints or what's supplied by core, you might indeed want customised groups that apply to different site sections etc - but this is doable in code and not that hard, so yeah, no UI is a reasonable argument, certainly.

Also agree it doesn't need a UI and if one comes in contrib like @Jeff Burnz said it could make it into 8.1. Personally don't care for either of them, but I'm sure they'll grow on me like other stuff did and these two responsive design solutions are in HUGE demand at the moment. So +1 for keeping it.

@hass I think one browsers come to consensus on a markup solution (which seems shockingly close right now, but it's seemed that way before, so I'm crossing my fingers), you will see built-in support much, much faster than you're suggesting. We're talking weeks or months, not years. If you're talking about legacy support in older browsers, picture has always had a polyfill so that it can work in older browsers. The only question is whether we ship with the span syntax being used in picturefill or the picture-source syntax that's being proposed. And that comes down to if there's real consensus on picture-source, and if there's native support in browsers like Chrome, Firefox and Blink. Safari and IE have longer-release cycles for major changes like this, but you never know. Point is, as long as we have a polyfill, we're good to go.

As for not having a UI, a UI is nice, but if it comes down to shipping d8 with no UI for breakpoints or shipping d8 with no picture and breakpoints, I pick no breakpoints UI. This is too useful a tool to leave out of d8. If it's in contrib, it's going to be used pretty rarely. If it's in core, I'd bet it gets used more, and that means improved performance for Drupal sites that use it, particularly on mobile devices.

Since there's no UI, I think one thing that would be helpful is if it was doable for themes to ship not only with their theme breakpoints, but with some intelligent defaults of picture mappings to image styles. For example, a theme might ship with picture mapping sets for a hero image (always full width of main content column), a sidebar image (floats to right within main content column on larger displays, full width on small displays) and thumbnails (smaller images used as previews on section pages or news summary pages).

I'm not sure if it's possible for themes to include those default mappings and image styles with CMI, but that would be really nice. Because then when somebody installs a theme, they don't have to worry about doing all the calculations necessary to set up picture and breakpoints to get responsive images working. They'd at least have one set of options that would work out of the box, and they'd have a working set of defaults that they could tweak or that they could look at as they figured out how to set up their own breakpoints, image styles and picture mappings for their particular site.

Just a thought on how to make things easier. Not sure if it's possible right now.

So I think there's clearly a call to keep this functionality in core. But what there isn't is folks helping resolve some of the issues in the issue summary, which would help assuage the concerns of the folks working on CMI and hitting problems with these modules. Any takers on that?

I do not think that I get this features soon on ipad/iphone. Apple is not the fastest and using chrome may solve something for me, but not for the masses :-(. I would wonder a lot if a core maintainer will change html code in a theme function as this will break production themes. This has been refused nearly all times in last years. Don't get me wrong, I'd like this mobile features, but outside of core we can change theme functions very fast if required. However I believe this browser support is not weeks away if they still discuss a standard... W3C stuff takes mostly years... at least to get reliable and all browsers support - we are ages away from this :-(

I've been actively following progress on picture, and while the W3C can move slow, we really are close to agreement on the implementation method, which is what has held things up. And again we can always ship with the Polyfill and update to a native element in a "feature release," assuming that happens.

I will look at the issues in the summary. I don't know how much help I will be, but I can try!

#34 There will be a UI in contrib, the reason it isn't part of core is that there wasn't a consensus on the UI/DX, see #43, #44, #45, #46

#39 You're right it might take this long, but if we don't make it part of core a lot of Drupal 8 sites are not going to be responsive and this will reflect on Drupal as a whole. As said in #40 we should not play a catch-up game, but we should stay ahead.

#41 The plan for the moment is to use the span based picture polyfill, since we (at least I) made an agreement to not add the picture tag to the stable Drupal 8 version, unless there's a consensus on the tag. The only thing that might change is the output: span vs picture vs img tag and maybe some attributes. If we have to do this in Drupal 8.n it might be a problem, but it isn't going to break a site. We might even opt to use a different formatter so older site still use the old output, and newer sites will use the standard.

#48 I'm more than willing to help, but I would like a to see this issue closed, so we can close the discussion about removal, since I'm - a bit - biased I think somebody else needs to close it.

#49 The changes to the output are normally not going to break themes, unless you start styling using tags, not classes.

@mdrummond thanks for clarifying

Issue summary:View changes
Status:Needs review» Closed (won't fix)
Issue tags:+revisit before beta

Agreed that we can make changes to responsive image markup post-release, so we can drop that line of concern. #2135189: Proposal to manage the Drupal 8 release cycle is to allow us to do that with relatively little risk.

I'm more than willing to help, but I would like a to see this issue closed, so we can close the discussion about removal

Makes sense. Thanks, attiks.

Closing, but marking "revisit before release" because if there continues to be no movement on the issues in the issue summary, we may need to come back to this.

I tried to go through all of the attached issues to check on their status and get them moving as necessary. Some need rerolls. I can try to tackle some of those if I have time, unless somebody else gets to them first.

Should a meta issue be created to track progress on this?

I think if we create a META, it would be good to do something along the lines of "META: Improve code quality Picture and Breakpoint modules," rather than a depressing title that indicates Picture and Breakpoint are on the chopping block.

There's movement in Chrome regarding img[srcset] and <picture>.

http://blog.chromium.org/2014/02/chrome-34-responsive-images-and_9316.html

srcset will help resolve this problem by letting Web developers provide multiple resources in varying resolutions for a single image. The browser can then pick the resource that matches the device's capabilities. Here’s an example of the code:

<img alt="A rad wolf." src="pic1x.jpg" srcset="pic1x.jpg 1x, pic2x.jpg 2x, pic4x.jpg 4x">

Note that the src attribute is not needed for browsers that support srcset, but it’s good for backwards compatibility. Kudos to external Blink developer Yoav Weiss for implementing and driving consensus for this feature. Stay tuned for the element, which will also help web developers with responsive design.

And @paul_irish's tweet that clued me in:

https://twitter.com/paul_irish/status/439129693975883776

The <picture element is on the horizon.

Awesome. Mozilla is planning on launching picture support within the next month as well. Zeldman had a good Big Web Show podcast with responsive images community group leader Mat Marquis about progress on responsive images. Short version: picture is coming. And soon. Firefox, Chrome and Opera first. Safari may be close behind, and Microsoft has tended to support picture, so IE is probably on the horizon too.

If all that actually comes together, we may be able to have the native picture element in D8 with polyfill support.

Mat Marquis is a Boston guy. I bet you could get him to drop by Acquia some time for a chat with those interested.

Mat and I have an open line of communication. Drupal's been involved with his <picture> campaign for a couple years now.