Dev Chat Summary: September 6th (4.9 week 6)

This post summarizes the dev chat meeting from September 6th (agendaSlack archive).

4.9 schedule review

  • 3 weeks until the feature project merge deadline, 4 weeks until Beta 1
  • Customizer improvements for merging Changeset drafting and scheduling has yet to kick off development, designs are nearing completion (see: #39896 and #28721)
  • Gallery widget is still under development but it seems to have stalled, TODO’s noted on related GitHub PR
    • @joemcgill to look into avoiding serializing attachments data in the widget this week
  • @obenland working on wrestling the widget mapping issue when switching themes (see: #39693)
  • Page on Front progressing slowly, likely not ready for dev before Feature Merge
  • Theme switching issue for nav menu mapping has already been merged in trunk (see: #39692)
  • CodeMirror feature plugin (aka Better Code Editing) needs testing and a few outstanding issues that would benefit from contributors. Plan is to merge this week.
  • @psykro to look into #9757
  • “Add Media” button in the Text widget great opportunity for new contributors
  • #35827 could use an owner and remaining items in 4.9 Goals post could use contributors to help land in the release

Editor update

Iterating in trunk

  • @matt: I’m fine with more iteration happening in trunk vs how we’re bouncing patches around Trac so much
  • @matt: I’m okay with parts of trunk being broken as we iterate in this phase of dev
  • @desrosj: Do we have an established process for reverting things that break?
  • @obenland: I think we’re not talking about “PHP fatals”-broken, but rather a feature maybe not fully functional

HTML5 input types for validation

  • @afercia: any thoughts about relying on HTML5 input types browsers built-in validation only?
  • @azaozz: used to be buggy, seems to be working properly now
  • @afercia: seems to me still premature to rely on required for validation
  • @afercia: looking to leads to make a decision as new browsers support policy
  • @asaozz: Worth some testing, especially on the “lower end”, IE11
  • @afercia: there are still CSS rules in ie.css for Internet Explorer 6 (and 7, and 8). Can they just be dropped?
  • @azaozz: no need of ie.css in my honest opinion
  • @azaozz: intention is not to completely break old browsers if they still work, but to stop testing in them
  • @clorith: concerned about users locked into older browsers, like IE8, and keeping option for them to enqueue scripts relevant to their browser
  • @afercia: I wanted to start the discussion about this as it relates to the new browsers support policy

General announcements

#4-9, #core, #core-customize, #core-editor, #dev-chat, #gallery, #gutenberg, #html5, #summary, #trunk, #widgets

HTML5 Galleries & Captions in WordPress 3.9

WordPress 3.6 introduced HTML5 versions of popular template tags, starting out with comments, the comment form, and the search form. With the 3.9 release we add galleries and captions to that list. Now, when adding HTML5 support for those features, WordPress will use <figure> and <figcaption> elements, instead of the generic definition list markup.

To declare that your theme supports these new HTML5 features, add the following call to your theme’s functions.php file, preferably in a callback to the after_setup_theme action:

add_theme_support( 'html5', array( 'gallery', 'caption' ) );

For forward compatibility reasons, the second argument with the specific parts can’t be omitted when registering support. Otherwise a theme would automatically declare its support for HTML5 features that might be added in the future, possibly breaking its visually because of it.

For both galleries and captions not only the markup changes when a theme declares its support for them, there are also peripheral changes that come with it.

Galleries

By default, galleries will not include inline styles anymore when in HTML5 mode. This caters to the trend of disabling default gallery styles through the use_default_gallery_style filter, a filter that even the last two default themes used. With that, theme developers can always start with a clean slate when creating their own set of gallery styles.

We also took the opportunity to remove the line breaks between rows of images. Not only did they encourage an inferior way of positioning elements, more importantly they were non-semantic html elements that are meant for presentational use, and they made it harder to style galleries.

Captions

Up until now, captions received an additional 10 pixels of width, to keep text flowing around the caption, from bumping into the image. As @nacin put it, this has vexxed theme developers for years, and even resulted in the addition of a filter in WordPress 3.7 to manipulate the caption width.

We were not able to completely remove the inline style in HTML5 mode, it’s still necessary to force captions to wrap, but we’re no longer the adding 10px of width. We also removed caption styles in the editor, bringing it on par with how non-captioned images are displayed:

Twenty Thirteen and Twenty Fourteen have been updated to support both features, while retaining backwards compatibility with older WordPress versions. There is a remote possibility however, that child themes that use element selectors to overwrite gallery or caption styles can lose those customizations. Please test your child themes with the current development versions of the last two default themes.

If there are any questions about the current implementation, feel free to leave a comment below.

#3-9, #dev-notes, #editor, #gallery, #html5, #themes

Galleries are now drag-and-drop sortable …

Galleries are now drag-and-drop sortable thanks to Aaron Campbell.

#gallery, #ui