* Support distinction between compatibility and core profiles. As is, it looks like GL3 is compatibility and GL4 is core.

* For GL4, show the version which introduced the feature (e.g., GL4.2). For GL3 and earlier I don't care.

* Allow compatibility functions to be filtered out entirely. I don't want glLightModel() or other old fixed-function stuff cluttering up the screen.

* GLSL 3.

* Minor cheat sheet showing differences between, say, GLSL 120, 330, and 4x0. For example, 120 has "attribute" and "varying", while 330 has "in" and "out".

I recommend that everyone use the compiler to help avoid functions and constants from later versions of OpenGL, if you are targeting old versions. For example, if you are targeting 3.3, then you can either use a header file that only defines 3.3, or you can use a header file that puts functions and constants in a namespace (e.g. "using namespace gl_3_3;").

There's a button above the command list that lets you hide stuff that's not available for the version that you have selected. It should be core for all GL versions. If you select 3.0/3.1 then the fixed function stuff is there but when you select 3.2 it gets removed. It's possible the page's design isn't clear here.

The rest of your stuff is in my to do list. Thanks for the feedback. Pull requests welcome :)

    This page is in "Galician". Would you like to translate it?

Is this generated from khronos itself or some other sneaky way?

I haven't got around to reading through the repo yet, so I can't say.

I scraped the docs from the Khronos website when I started the project, about ten months ago. They may be getting out of date by now. At some point I intend to check out all of the changes that Khronos has made since them and apply them to docs.gl. Help maintaining it would be much appreciated :)

I went to add the additional error code and I noticed that Khronos says the invalid operation error should be thrown if texture is NOT the name of an immutable texture object. Is it me or is that not a copy paste error that shouldn't be there?

Now, that makes probably no sense; can someone clarify what these versions mean (apart from API availability described by this table, obviously), and if there's a relationship to the WebGL subset (it is a subset, right?).

"WebGL: OpenGL ES 2.0 for the Web"

See https://github.com/BSVino/docs.gl/issues/9.

Anyway, thanks!

I'm a little disappointed that the text is essentially the same as the man pages, which means all the same failings. It would be great if there was actually useful text in there.

For example, this little zinger:

"glBindTexture lets you create or use a named texture."

It mentions in this single sentence that it lets you create a texture, but there's not a single word of that in the rest of the text, leaving you wondering under what circumstances that happens or why or whether you should do it that way normally.

Then we get the opposite in the paragraph about where a texture is first bound:

"When a texture is first bound, it assumes the specified target: A texture first bound to GL_TEXTURE_1D becomes one-dimensional texture, a texture first bound to GL_TEXTURE_2D becomes two-dimensional texture,..."

and on and on for every constant you can pass in.

Anyway, I'd love to see a docs site that fixes these very confusing problems with GL's documentation. This is a great first step, but if you're looking for future directions, consider fixing what's broken in the existing docs!

The entire site is here: https://github.com/BSVino/docs.gl

I would love for people help improve the language, which I agree is terrible in places. I don't consider myself an OpenGL expert so I haven't tried to improve the language except in places I know very well. That's why I went for including examples instead of reworking the language. But I would be thrilled if some good writers helped clean it up and expand and clarify etc.

Thank you for the feedback. :)

("Method" as the column name is actually incorrect... they're just bare C functions.)

It's pretty standard to have the function's type signature and possibly a short description in the function lists of API docs. Here's a random example:

http://ffmpeg.org/doxygen/trunk/group__lavc__fft.html#func-m...

If a function has the same name across different versions of the OpenGL API, does it also have the same type signature? If so, it would be nice to have a version of this with more details.

The docs should be just about the OpenGL functions, not about how C implements them.

I think we should start to transition to using the word function only in the connotation provided in functional programming languages, where functions are first class citizens and can be treated as values. Also, should probably prefer to imply a lack of side effects from the word function.

Method is clearly a certain function or procedure that is scoped to a class. So that leaves procedure as a name left over for the type of bare function that isn't a value, that is a statement rather than an expression.

I think subroutine and subprogram are just archaic sounding, and don't really imply anything that the others don't. Method, functions, procedures, I think that's all we need.

So, strlen, for example, is a function, and printf is a procedure.

(Yes I know prints returns an int, but it's run for it's side effects primarily.)

What you are talking about might be called a relation, which is more general.

    Array.prototype.filter.call(document.querySelectorAll(".disabled"), function(v){return v.innerHTML === "es2";}).forEach(function(v){v.parentElement.parentElement.removeChild(v.parentElement);});