Adding mediaelement CSS links outside of head tags breaks HTML5 validation

[AlphaK]

Medialement CSS links are added by default outside of the head element.

It seems to come from /wp-includes/class.wp-styles.php:

        function do_footer_items() { // HTML 5 allows styles in the body, grab late enqueued items and output them in the footer.
                $this->do_items(false, 1);
                return $this->done;
        }

Indeed style elements are allowed in the body in HTML5, provided it is a style element - not link element - and provided it has the scoped attribute. See ​http://www.w3.org/TR/2011/WD-html5-author-20110705/the-style-element.html#the-style-element

Here are the medialements genetared tags in the body:

<link rel='stylesheet' id='mediaelement-css'  href='http://mydomain/wp-includes/js/mediaelement/mediaelementplayer.min.css?ver=2.13.0' type='text/css' media='all' />
<link rel='stylesheet' id='wp-mediaelement-css'  href='http://mydomain/wp-includes/js/mediaelement/wp-mediaelement.css?ver=3.7.1' type='text/css' media='all' />

But this breaks W3C's HTML5 validation.

According to ​http://www.w3.org/TR/2011/WD-html5-author-20110705/the-link-element.html :
Link elements must be used in metadata content.

According to ​http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-link-element :
If the rel attribute is used, the element is restricted to the head element. When used with the itemprop attribute, the element can be used both in the head element and in the body of the page, subject to the constraints of the microdata model.

[impulsewebdesign]

This issue is still present in version 3.8.

Adding the following code to wp-includes/media.php could be a solution:

function wp_mediaelement_scripts(){
	$library = apply_filters( 'wp_audio_shortcode_library', 'mediaelement' );
	if ( 'mediaelement' === $library && did_action( 'init' ) ) {
		wp_enqueue_style( 'wp-mediaelement' );
		wp_enqueue_script( 'wp-mediaelement' );
	}
}
add_action( 'wp_enqueue_scripts', 'wp_mediaelement_scripts' );

Then the following code should be removed from functions wp_audio_shortcode() and wp_video_shortcode() in wp-includes/media.php:

$library = apply_filters( 'wp_audio_shortcode_library', 'mediaelement' );
if ( 'mediaelement' === $library && did_action( 'init' ) ) {
    wp_enqueue_style( 'wp-mediaelement' );
    wp_enqueue_script( 'wp-mediaelement' );
}

[wonderboymusic]

Yeah, loading CSS in the footer sucks. 25899.diff​ is a proposed solution.

[wonderboymusic]

#25120 was marked as a duplicate.

[dboulet]

If I understand correctly: the solution proposed in the patch only works when the shortcode is present within post content—it won’t help if the shortcode is used elsewhere, such as in a call to do_shortcode() in a plugin or theme.

[wonderboymusic]

correct - I think the actual fix might be outputting the <link> immediately instead of enqueue'ing - I haven't researched this at all though

[Ov3rfly]

In addition currently the wp_audio_shortcode_library filter unfortunately can not be used to block the enqueue'ing (and adding the script/style/IE9fix to header with some workaround) by returning something else than 'mediaelement' from the filter, because $library is not only used for the filter but also later in code...

$library = apply_filters( 'wp_audio_shortcode_library', 'mediaelement' );
if ( 'mediaelement' === $library && did_action( 'init' ) ) {
	wp_enqueue_style( 'wp-mediaelement' );
	wp_enqueue_script( 'wp-mediaelement' );
}

[...]

if ( 'mediaelement' === $library )
	$html .= wp_mediaelement_fallback( $fileurl );

[...]

return apply_filters( 'wp_audio_shortcode', $html, $atts, $audio, $post_id, $library );

[DrewAPicture]

Seems like we need a consensus on the best way forward here. Punting.