Make WordPress Core

Opened 11 years ago

Last modified 5 years ago

#25899 new defect (bug)

Adding mediaelement CSS links outside of head tags breaks HTML5 validation

Reported by: alphak's profile AlphaK Owned by:
Milestone: Priority: normal
Severity: minor Version: 3.6
Component: Media Keywords: has-patch
Focuses: Cc:

Description

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.

Attachments (1)

25899.diff (2.0 KB) - added by wonderboymusic 10 years ago.

Download all attachments as: .zip

Change History (10)

#1 @impulsewebdesign
10 years ago

  • Cc impulsewebdesign added

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' );
}
Last edited 10 years ago by impulsewebdesign (previous) (diff)

#2 @wonderboymusic
10 years ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 4.0

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

#3 @wonderboymusic
10 years ago

#25120 was marked as a duplicate.

#4 @dboulet
10 years ago

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.

#5 @wonderboymusic
10 years ago

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

#6 @Ov3rfly
10 years ago

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 );

This ticket was mentioned in IRC in #wordpress-dev by DrewAPicture. View the logs.


10 years ago

#8 @DrewAPicture
10 years ago

  • Milestone changed from 4.0 to Future Release

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

This ticket was mentioned in Slack in #accessibility by accessiblejoe. View the logs.


9 years ago

Note: See TracTickets for help on using tickets.