Re: [filter-effects] New syntax proposal for 'custom' filter function

On Thu, Nov 15, 2012 at 8:51 PM, Rik Cabanier <> wrote:
> On Thu, Nov 15, 2012 at 5:30 PM, David Sheets <> wrote:
>> On Thu, Nov 15, 2012 at 3:55 PM, Dirk Schulze <> wrote:
>> > Just checked, animations use IDENT :P. I definitely don't want a
>> > different syntax for custom() then for animation-name/@keyframes. So yes,
>> > IDENT is fine for me (no quotes).
>> What Accept header will be sent for HTTP requests of shaders with
>> "format" "glsl"?
> I believe we haven't specified about that.
> The shader programs are currently downloaded as text. Do you think the
> programs should be requested for mime types x-shader/x-vertex or
> x-shader/x-fragment?

Those media types are bad for the ecosystem for a number of reasons:
  A. They use "x-" which has been deprecated by RFC 6648
  B. They use a non-standard type (the bit before the "/")
  C. They use subtypes (the bit after the "/") in a media-specific way
  D. They fail to identify the specific media type of the content
(OpenGL ES 2.0 GLSL 1.0)

The Khronos Group, in their role as steward of the OpenGL ES 2.0 GLSL
1.0 language as internet standard, has been delinquent in recommending
a media type for authors to use. Media type registration was brought
to their attention via the public-webgl mailing list 6 months ago but
was met with silence from the body

I do not believe any other entity can make a formal registration
request for a media type in the standards tree; however, if I am
reading RFC 6648 correctly, no formal registration is required (though
one SHOULD be made).

Here is my use case:

I would like to host a shader resource identified by URI Q. This
shader resource has several equivalent representations:

OpenGL ES 2.0 GLSL 1.0
OpenGL ES 3.0 GLSL 3.0
Microsoft Secret Shading Language 1.0
A "literate program" representation in HTML
A "literate program" representation in LaTeX/PDF
A JSON encapsulation holding multiple representations or fallback versions

Each of these representations contains links to the other
representations (in the form of self-references with annotated media
types or media-specific sibling URIs) as well as equivalent content in
variously comments and code blocks.

I would like to provide URI Q for every equivalent shader in my CSS
and have the browser make a single HTTP request with appropriately
ordered media types in the Accept header. A suitable shader will be
returned from the server and will execute in the context of the first
matching at-rule.

I am interested in seeing standardization with the following properties:
  A. A media type in the application/* type tree (supposedly present
best practice) or a new compute/* ("kernel"? "shader"? strawman...)
type tree which admits only media types for numerical modules which
must obviously terminate by design of each language (if you must)
  B. A media subtype in the type tree of (A) which unambiguously
specifies the numerical language of the resource ("webglsl" or "essl"
or "glsl" in this case; which pipeline stage is expected is irrelevant
at the media type level as language resources may not represent an
entire stage or a single resource may have multiple uses)
  C. A clear map between the CSS identification token string and the
media type used in any network request
  D. An intuitive behavior for coalescing custom filter at-rules into
a network request (e.g. equivalent Accept ordering)

Whatever media type is selected, a version parameter should be specified.

Except for this internet standards alignment, I love this proposal.

This brings up some issues with related aspects:

I do not understand why the programming language of a custom filter is
called "format". Maybe "type"?

I do not understand why the value of the format field is "glsl" which
is an ambiguous name for a family of languages some of which may be
used in this context in future. Perhaps "webgl" or "webglsl"?

I do not understand why an IDENT should be used as the name of the
language in this context when this token refers to a browser-intrinsic
dictionary and should correspond directly to a media type.
Additionally, if WebGLSL is recommended and default here, this field
should never be necessary under normal usage. I support the use of
IDENT for the identifier of the at-rule, however.

I'd really appreciate your feedback on these comments.


David Sheets

Received on Monday, 19 November 2012 01:35:58 UTC