Repository navigation
javascript media types in §3.1.2 #1353
Description
The spec lists two media types:
- application/javascript
- text/javascript
the second one is listed as obsolete in RFC4329; on the other hand, it lists application/ecmascript as valid and text/ecmascript, too,as obsolete.
I would propose to allow for all four, but marking the text/* as obsolete (ie, discourage authors to use it)
Activity
mattgarrish commentedon Oct 23, 2020
This only applies to the package document declaration. You can use any media type in the actual html files. Do we really need to have four possibilities? It's more likely to cause issues with older reading systems.
iherman commentedon Oct 24, 2020
If it is only for package document, then we should probably say that the one that authors SHOULD use is application/javascript but make a note that the other three are acceptable, but not RECOMMENDED to be used. Newer content following this would work with older and newer RS-s, older contents will also be handled.
The current text does put application/javascript and text/javascript on equal footing, and that contradicts RFC4329...
mattgarrish commentedon Oct 24, 2020
Because up until 3.2 only text/javascript was allowed and exists in a lot of EPUBs that publishers don't want rejected from vendors because it's no longer recommended (i.e., warning). It's not about providing complete coverage of all possible media types, as there are 10+ other ways of indicating a javascript.
Adding more without addressing the whole issue of core media types just provides another angle of rejection from vendors who don't update their validation every time there's a new specification.
iherman commentedon Oct 24, 2020
I think we can forget about the historical stuff as listed in full list of js references. Let us consider RFC4329 which lists four or these, and that is already quite enough :-)
There are several issues
application/ecmascript, per RFC4329, is perfectly o.k. even if not widely used. I do not think we should disallow something that is standard compliantapplication/{javascript,ecmascript}and not their text equivalent. We may hit the problem that future web cores or other javascript tools may have issues withtext/*, and we want to avoid thatWe may list all four as possibilities, without formally designating
text/*as wrong (ie, epubcheck should not flag their usage), but add an editorial note to make it clear that authors should not (as opposed to SHOULD NOT) use these, because they are considered to obsolete.Would that work?
mattgarrish commentedon Oct 24, 2020
I just think this is more important an issue for content (where you're not bound to the validation/CMT constraints of the package) and potentially more problematic than it's worth for the package on its own.
But it's not a hill I'm going to die on, as the hackneyed saying goes, as I'm more interested in solving non-content document CMTs more broadly so we don't continue to run into this problem going forward.
OriKuttner commentedon Oct 24, 2020
dauwhe commentedon May 4, 2021
I don't have any particular interest in “encouraging” the use of a particular media type. What is defined in the package document doesn't matter for script execution! But I worry that we disallow the perfectly valid
application/ecmascript. I would propose adding this.mattgarrish commentedon May 7, 2021
I can live with this, since it's at least a recommended media type. Adding an obsolete media type to match a mistaken use of an obsolete media type is bad form.
Since we're adding other new media types, I suppose the pain of rejection from old validators is no more or less than for the others.