Unfortunately it's not that easy. Developers sometimes do use different MIME types so we can't just render no type attribute when in HTML mode.

Are you talking about custom mime types not in this list?
http://www.webmaster-toolkit.com/mime-types.shtml

Just as an example take this snippet: http://ejohn.org/blog/javascript-micro-templating/

In more general terms, HTML5 still allows different MIME types for script elements (and link too but that's a bit different). HTML5's change is only that there's now a default value if the attribute is not present.

html is simply more forgiving now. As i understand it (the official spec isn't an easy read) it is also not really the case that there is a default value for these assets (not just js), instead the browser checks what type the file is and proceeds on that basis. The browser checks whatever the case.

Thus declaring an incorrect type attribute should not work because the browser will determine the file type and ignore the type attribute. At that point, type attributes are superfluous at best. Current recommendations are that type attributes are not used and, as we will be touting a shiny 'we're all html5' badge, I think we should do the best we can to match best practice.

No, no, no.

Well not quite. Browsers do take the type attribute into account. Sane browsers (which means all but IE, IE can be forced to this behavior with a HTTP header) don't sniff for content.

The HTML5 spec says for the type element on the link element:

For external resource links, the type attribute is used as a hint to user agents so that they can avoid fetching resources they do not support. If the attribute is present, then the user agent must assume that the resource is of the given type (even if that is not a valid MIME type, e.g. the empty string). If the attribute is omitted, but the external resource link type has a default type defined, then the user agent must assume that the resource is of that type. If the UA does not support the given MIME type for the given link relationship, then the UA should not obtain the resource; if the UA does support the given MIME type for the given link relationship, then the UA should obtain the resource at the appropriate time as specified for the external resource link's particular type. If the attribute is omitted, and the external resource link type does not have a default type defined, but the user agent would obtain the resource if the type was known and supported, then the user agent should obtain the resource under the assumption that it will be supported.

User agents must not consider the type attribute authoritative — upon fetching the resource, user agents must not use the type attribute to determine its actual type. Only the actual type (as defined in the next paragraph) is used to determine whether to apply the resource, not the aforementioned assumed type.

By obtaining the actual type is not content sniffing meant but relying on the Content-Type header.

For the script element (which is more relevant because it gets trickier):

The type attribute gives the language of the script or format of the data. If the attribute is present, its value must be a valid MIME type. The charset parameter must not be specified. The default, which is used if the attribute is absent, is "text/javascript".

And for information why content sniffing is not a good thing I recommend: http://www.h-online.com/security/features/Risky-MIME-sniffing-in-Internet-Explorer-746229.html

BTW I just noticed against what repro this was done. This would have to be fixed in the platform, not the CMS.

@realityking Oops! you are true. I'll have no problem in submitting it to platform before merging this but can we finish the debate here?

What about something like:

    // Generate stylesheet links
    foreach ($document->_styleSheets as $strSrc => $strAttr)
    {
        $buffer .= $tab . '<link rel="stylesheet" href="' . $strSrc . '"';
        if (!is_null($strAttr['mime']) && (!$document->isHtml5() || ($document->isHtml5() && $strAttr['mime'] != 'text/css')))
        {
            $buffer .= ' type="' . $strAttr['mime'] . '"';
        }
        if (!is_null($strAttr['media']))
        {
            $buffer .= ' media="' . $strAttr['media'] . '"';
        }
        if ($temp = JArrayHelper::toString($strAttr['attribs']))
        {
            $buffer .= ' ' . $temp;
        }
        $buffer .= $tagEnd . $lnEnd;
    }

This way we will remove the type if it's the standard type but keep it when it's a custom one. For javascript maybe an in_array with all the javascript types commonly used (text/javascript is the default type in HTML5 but is marked as obsolete by IANA that recommends application/javascript ....that doesn't work on IE9..... ). So for example something like:

    // Generate script file links
    foreach ($document->_scripts as $strSrc => $strAttr)
    {
        $buffer .= $tab . '<script src="' . $strSrc . '"';
        $defaultMimes = array(
            'text/javascript', 'application/javascript', 'text/x-javascript', 'application/x-javascript'
        );
        if (!is_null($strAttr['mime']) && (!$document->isHtml5() || ($document->isHtml5() && !in_array($strAttr['mime'], $defaultMimes)) ))
        {
            $buffer .= ' type="' . $strAttr['mime'] . '"';
        }
        if ($strAttr['defer'])
        {
            $buffer .= ' defer="defer"';
        }
        if ($strAttr['async'])
        {
            $buffer .= ' async="async"';
        }
        $buffer .= '></script>' . $lnEnd;
    }

This will allow developers to remove types keeping the flexibility for use custom mime types.

Yeah we can finish the debate here. Just please link to this page for any final pull request made to the platform.

That would work. It could actually be a bit simplified:

// Generate script file links
    foreach ($document->_scripts as $strSrc => $strAttr)
    {
        $buffer .= $tab . '<script src="' . $strSrc . '"';
        $defaultMimes = array(
            'text/javascript', 'application/javascript', 'text/x-javascript', 'application/x-javascript'
        );
        if (!is_null($strAttr['mime']) && (!$document->isHtml5() || !in_array($strAttr['mime'], $defaultMimes)))
        {
            $buffer .= ' type="' . $strAttr['mime'] . '"';
        }
        if ($strAttr['defer'])
        {
            $buffer .= ' defer="defer"';
        }
        if ($strAttr['async'])
        {
            $buffer .= ' async="async"';
        }
        $buffer .= '></script>' . $lnEnd;
    }

I have to read up on the different javascript MIME types but IIRC correctly they only have a subtle different when sent as the Content-Type header but not in the HTML type attribute.

Question now is if it's worth it ;) (I don't care either way, I just wanna keep the ability to set other MIME types)

Thanks!

I've commited as suggested. If you give me the Ok I'll make a pull request to the platform.

+1 to output beautiful code

Hi all,

What's the status on this one? Also, is there a tracker item for it?

Any update on this one?

@Achal-Aggarwal Would you take a look at this one and see how it relates to your project (if at all)?

Updated vs the latest master branch and created the issue tracker link:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=32162&start=0