Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editorial: update usage of the MIME Sniffing Standard #3455

Merged
merged 3 commits into from Feb 16, 2018
Merged

Conversation

@domenic
Copy link
Member

@domenic domenic commented Feb 5, 2018

This follows whatwg/mimesniff#58 by referencing
the definitions for JavaScript and JSON MIME type that now live in MIME
Sniffing. It also follows whatwg/mimesniff#36 by
using the terms "valid MIME type string" and "valid MIME type string
without parameters" instead of their non-string counterparts that
previously appeared.


"do not merge yet" until whatwg/mimesniff#58 gets merged. Editorial review still appreciated.


/browsing-the-web.html ( diff )
/embedded-content.html ( diff )
/iframe-embed-object.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/input.html ( diff )
/links.html ( diff )
/obsolete.html ( diff )
/scripting.html ( diff )
/semantics.html ( diff )
/system-state.html ( diff )
/webappapis.html ( diff )

Copy link
Member

@annevk annevk left a comment

Some nits here are a bit off-topic.

@@ -57289,18 +57293,18 @@ interface <dfn>HTMLScriptElement</dfn> : <span>HTMLElement</span> {
<li><p>Setting the attribute to any other value means that the script is a <dfn>data
block</dfn>, which is not processed. None of the <code>script</code> attributes (except <code
data-x="attr-script-type">type</code> itself) have any effect on data blocks. Authors must use
a <span>valid MIME type</span> that is not a <span>JavaScript MIME type</span> to denote data
blocks.</p></li>
a <span>valid MIME type string</span> that is not a <span>JavaScript MIME type essence

This comment has been minimized.

@annevk

annevk Feb 16, 2018
Member

I wonder if we really want to allow text/javascript;test=test to denote a data block.

source Outdated
MIME type essence match</span> concept. (In general, it is best not to think of the
<code>script</code> element's <code data-x="attr-script-type">type</code> attribute as related to
MIME types; instead, it has a hard-coded list of strings, which resemble certain MIME types, that
for historical reasons will trigger the same default behavior as omitting the attribute.)</p>

This comment has been minimized.

@annevk

annevk Feb 16, 2018
Member

This newly added text is incorrect as we want you to think about MIME types for data blocks.

This comment has been minimized.

@domenic

domenic Feb 16, 2018
Author Member

I guess I'll just delete it... I still think there's a grain of truth here, but capturing all the subtleties seems hard.

source Outdated

<p class="note">For example, scripts with their <code data-x="attr-script-type">type</code>
attribute set to "<code data-x="">text/javascript; charset=utf-8</code>" will not be
evaluated.</p>
evaluated, even though that is a valid <span>JavaScript MIME type</span>.</p>

This comment has been minimized.

@annevk

annevk Feb 16, 2018
Member

add ", when parsed"?

@@ -92583,7 +92565,7 @@ interface <dfn>MimeType</dfn> {
method.</p>

<p>The <dfn><code data-x="dom-MimeType-type">type</code></dfn> attribute must return the
<span>valid MIME type with no parameters</span> describing the <span>MIME type</span>.</p>
<span>valid MIME type string with no parameters</span> describing the <span>MIME type</span>.</p>

This comment has been minimized.

@annevk

annevk Feb 16, 2018
Member

This doesn't make much sense to me, but I guess that goes for the original too...

This comment has been minimized.

@domenic

domenic Feb 16, 2018
Author Member

Yeah, without re-doing this entire section to be on a more rigorous foundation, I think this is the best we're going to get. (Which is probably not worth the work given how at least some browsers always return empty for these.)

domenic added 2 commits Feb 5, 2018
This follows whatwg/mimesniff#58 by referencing
the definitions for JavaScript and JSON MIME type that now live in MIME
Sniffing. It also follows whatwg/mimesniff#36 by
using the terms "valid MIME type string" and "valid MIME type string
without parameters" instead of their non-string counterparts that
previously appeared.
@domenic domenic force-pushed the move-mime-type-groups branch from f7a48c3 to a02afea Feb 16, 2018
source Outdated
<p>The term <dfn>JSON MIME type</dfn> is used to refer to the <span data-x="MIME type">MIME
types</span> <code>application/json</code>, <code>text/json</code>, and any <span>MIME
type</span> whose subtype ends with the five characters "<code data-x="">+json</code>".

<p>An <dfn>explicitly supported JSON type</dfn> is one for which the user agent is configured to

This comment has been minimized.

@annevk

annevk Feb 16, 2018
Member

Hmm, should we update this at the same time to say JSON MIME type? And make this sentence refer to JSON MIME type?

@annevk
annevk approved these changes Feb 16, 2018
@domenic domenic merged commit fc82f4f into master Feb 16, 2018
2 checks passed
2 checks passed
Participation domenic participates on behalf of Google LLC
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@domenic domenic deleted the move-mime-type-groups branch Feb 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.