Re: [whatwg] Exposing visible string of an input field
(12/09/07 17:49), TAMURA, Kent wrote: Proposal: I'd like to propose adding new IDL attribute to HTMLInputElement. readonly attribute DOMString rawValue; If I understand the main use case correctly. This probably should be called displayValue or something. It returns text content which a user actually see in an input field. * For text, search, url, tel, password types, it's equivalent to 'value' IDL attribute. * For email type, it returns a string which a user is editing. It means it returns a string without Unicode - Punycode conversion and without normalization of whitespace and commas. * For number type, it returns user-editing string. If a user typed '123+++' into a number field, rawValue would be '123+++' as is. * For date, datetime, datetime-local, month, time, week, the attribute returns a string in a field. If a field is text-editable, it should return user-editing string like email and number. If a field has a fixed localized date/time string chosen by a date/time picker, the attribute should return the localized string. * For submit, reset, button types, the attribute returns a label which the field shows. e.g. 'Submit' for input type=submit without value attribute. * For other types, should it return an empty string? What about type=file ? Use case: - We can enable text field selection APIs for email, number, and other types So you want to enable select() etc. for these types? Are there real needs here? - JavaScript-based screen readers can read user-visible content of input fields. For localized strings (date, datetime, datetime-local, month, time, week), it doesn't seem to be difficult to hard-code the string conversion functions into a JavaScript screen reader. For inputs that are being edited (date, datetime, datetime-local, month, time, week, number), I wonder if we should instead remove restrictions like this: # User agents must not allow the user to set the value to a non-empty # string that is not a valid floating-point number. and just let .value returns the raw input while a user is editing the value and let value sanitization algorithm happen afterward. Strings returned by rawValue attribute may be browser-dependent and locale-dependent. However it would be useful. The proposed feature sounds a bit messy to me... Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
[whatwg] DOM4: createHTMLDocument argument
In WebKit the argument to createHTMLDocument is optional, defaulting to the empty string. In DOM4 it is a required argument http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#domimplementation It seems reasonable to change the spec here since it is common to want to create a document without a title. -- erik
[whatwg] [canvas] Proposal for supportsContext
I sent this to the public-h...@w3.org list:
http://www.w3.org/mid/b2fff68c-cd91-4273-8087-ec3058d24...@apple.com
Copied below.
[[[
I propose adding a new method to HTMLCanvasElement:
interface HTMLCanvasElement : HTMLElement {
boolean supportsContext(DOMString contextId, any... arguments);
};
supportsContext takes the same parameters as getContext, and simply returns
true if the corresponding call to getContext would have returned a valid
context, false otherwise.
The justification for this method is that it is sometimes expensive to create a
context. Many authors test for a canvas feature by trying to create a context,
examining the return value, and doing something different if the context was
null. This is ok in most cases, but there are some instances where we don't
want to create a context unless the page is really going to make use of it.
To give a real world example, the popular tool Modernizr tests for the
availability of WebGL by attempting to create a WebGL context. This can happen
even on pages that have no intention of using WebGL - an author has just
inserted Modernizr into their page and is using it to test for another feature.
As I said, creating a context is not a free operation. In fact, on shipping
Safari (Mountain Lion) this causes us to switch to a more powerful GPU
on systems that have two graphics processors.
An alternative (for the WebGL case) would be to have the author test for the
presence of window.WebGLRenderingContext. However, this is not reliable. We may
ship a browser that supports WebGL, but not on the particular hardware
configuration that the user is running. Or it could be a momentary
unavailability. There are a number of visible top-level WebGL apis, and we
don't want to have to hide/show them all based on availability.
]]]
Dean
Re: [whatwg] [canvas] Proposal for supportsContext
On Sep 10, 2012, at 8:14 PM, Dean Jackson d...@apple.com wrote:
I propose adding a new method to HTMLCanvasElement:
interface HTMLCanvasElement : HTMLElement {
boolean supportsContext(DOMString contextId, any... arguments);
};
supportsContext takes the same parameters as getContext, and simply returns
true if the corresponding call to getContext would have returned a valid
context, false otherwise.
What about enabling feature detection by providing a method per context?
interface HTMLCanvasElement : HTMLElement {
object get2DContext();
object getWebGLContext(any... args);
};
That way, developers can use idiomatic JS for feature testing like
pretty much everywhere else on the Web platform:
if (canvas.get2DContext) {
// do stuff with 2D canvas
}
--tobie
Re: [whatwg] [canvas] Proposal for supportsContext
On Sep 10, 2012, at 12:28 PM, Tobie Langel tobie.lan...@gmail.com wrote:
On Sep 10, 2012, at 8:14 PM, Dean Jackson d...@apple.com wrote:
I propose adding a new method to HTMLCanvasElement:
interface HTMLCanvasElement : HTMLElement {
boolean supportsContext(DOMString contextId, any... arguments);
};
supportsContext takes the same parameters as getContext, and simply returns
true if the corresponding call to getContext would have returned a valid
context, false otherwise.
What about enabling feature detection by providing a method per context?
interface HTMLCanvasElement : HTMLElement {
object get2DContext();
object getWebGLContext(any... args);
};
That way, developers can use idiomatic JS for feature testing like
pretty much everywhere else on the Web platform:
if (canvas.get2DContext) {
// do stuff with 2D canvas
}
This doesn't address the problem we are hitting, which is that
it is expensive to create a context. It's also a big change to
an existing operational API.
I'm looking for some way an implementation can suggest that
it supports a particular context without the user having to
create one. As James Robinson pointed out in the WebKit IRC
channel, even the implementation might not know for sure it can
create the context, but I think that's ok. The important
thing is that returning false from supportsContext means that
a corresponding call to getContext would fail.
Dean
Re: [whatwg] [canvas] Proposal for supportsContext
Can't Modernizr just lazy load the WebGL context? (i.e. only try to create
a context if the web page actually asks if WebGL is supported)
On the other hand I would love to see a supportsContext function which can
tell if WebGL is software rendered (i.e. Swiftshader in Chrome). There's
been a lot of discussion about that and how to define it, but in our
experience 2D games rendered with Swiftshader are far slower than rendered
with a software-rendered 2D canvas. We have production code in the wild
which detects Swiftshader by its supported WebGL extensions. I'd love to
replace this even with something vendor specific, like:
canvas.supportsContext(webgl, { -webkit-allowswiftshader: false })
Despite the hardness to define it, I do feel there is a practical need for
this.
Ashley Gullen
Scirra.com
On 10 September 2012 19:14, Dean Jackson d...@apple.com wrote:
I sent this to the public-h...@w3.org list:
http://www.w3.org/mid/b2fff68c-cd91-4273-8087-ec3058d24...@apple.com
Copied below.
[[[
I propose adding a new method to HTMLCanvasElement:
interface HTMLCanvasElement : HTMLElement {
boolean supportsContext(DOMString contextId, any... arguments);
};
supportsContext takes the same parameters as getContext, and simply returns
true if the corresponding call to getContext would have returned a valid
context, false otherwise.
The justification for this method is that it is sometimes expensive to
create a
context. Many authors test for a canvas feature by trying to create a
context,
examining the return value, and doing something different if the context
was
null. This is ok in most cases, but there are some instances where we don't
want to create a context unless the page is really going to make use of it.
To give a real world example, the popular tool Modernizr tests for the
availability of WebGL by attempting to create a WebGL context. This can
happen
even on pages that have no intention of using WebGL - an author has just
inserted Modernizr into their page and is using it to test for another
feature.
As I said, creating a context is not a free operation. In fact, on shipping
Safari (Mountain Lion) this causes us to switch to a more powerful GPU
on systems that have two graphics processors.
An alternative (for the WebGL case) would be to have the author test for
the
presence of window.WebGLRenderingContext. However, this is not reliable.
We may
ship a browser that supports WebGL, but not on the particular hardware
configuration that the user is running. Or it could be a momentary
unavailability. There are a number of visible top-level WebGL apis, and we
don't want to have to hide/show them all based on availability.
]]]
Dean
Re: [whatwg] [canvas] Proposal for supportsContext
On Sep 10, 2012, at 12:35 PM, Ashley Gullen ash...@scirra.com wrote:
Can't Modernizr just lazy load the WebGL context? (i.e. only try to create a
context if the web page actually asks if WebGL is supported)
Yes, it could. But we don't control Modernizr or any other scripts people might
use. I'd rather provide something at the browser-level to protect from bad
practice than expect every page to behave nicely.
On the other hand I would love to see a supportsContext function which can
tell if WebGL is software rendered (i.e. Swiftshader in Chrome). There's
been a lot of discussion about that and how to define it, but in our
experience 2D games rendered with Swiftshader are far slower than rendered
with a software-rendered 2D canvas. We have production code in the wild
which detects Swiftshader by its supported WebGL extensions. I'd love to
replace this even with something vendor specific, like:
canvas.supportsContext(webgl, { -webkit-allowswiftshader: false })
Yes, that was another part of the eventual plan, although I didn't want to
define that yet.
Dean
Despite the hardness to define it, I do feel there is a practical need for
this.
Ashley Gullen
Scirra.com
On 10 September 2012 19:14, Dean Jackson d...@apple.com wrote:
I sent this to the public-h...@w3.org list:
http://www.w3.org/mid/b2fff68c-cd91-4273-8087-ec3058d24...@apple.com
Copied below.
[[[
I propose adding a new method to HTMLCanvasElement:
interface HTMLCanvasElement : HTMLElement {
boolean supportsContext(DOMString contextId, any... arguments);
};
supportsContext takes the same parameters as getContext, and simply returns
true if the corresponding call to getContext would have returned a valid
context, false otherwise.
The justification for this method is that it is sometimes expensive to create
a
context. Many authors test for a canvas feature by trying to create a context,
examining the return value, and doing something different if the context was
null. This is ok in most cases, but there are some instances where we don't
want to create a context unless the page is really going to make use of it.
To give a real world example, the popular tool Modernizr tests for the
availability of WebGL by attempting to create a WebGL context. This can happen
even on pages that have no intention of using WebGL - an author has just
inserted Modernizr into their page and is using it to test for another
feature.
As I said, creating a context is not a free operation. In fact, on shipping
Safari (Mountain Lion) this causes us to switch to a more powerful GPU
on systems that have two graphics processors.
An alternative (for the WebGL case) would be to have the author test for the
presence of window.WebGLRenderingContext. However, this is not reliable. We
may
ship a browser that supports WebGL, but not on the particular hardware
configuration that the user is running. Or it could be a momentary
unavailability. There are a number of visible top-level WebGL apis, and we
don't want to have to hide/show them all based on availability.
]]]
Dean
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
This is pretty tricky to get right -- there's just a general graphics problem in this case. There are valid use cases for both sampling outside and not sampling outside the source rectangle, as well as implementation issues for being able to do source rectangle clamping. For example, should you be able to take a source image and draw it scaled up using 4 rectangles (one for each quadrant) and have the result be equal to just doing it in one draw? Or take any random subimage (for example, for efficient updates of some destination) and draw it in. I do agree that the spec needs some clarity here, but I don't think that just stating that drawImage should always sample in the source is the right thing. At best, I think a new mode toggle or flag would be needed to allow you to select. Additionally, I think there's a related bug filed from a while ago about defining how to sample pixels that are outside of the source bounds -- do you clamp to edge, do you sample transparent black, etc. - Vlad On Mon, Aug 20, 2012 at 10:09 AM, Justin Novosad ju...@chromium.org wrote: Hi Kevin, The same artifact use to be present in Chrome not that long ago. When we fixed it, we chose to interpret original image data as meaning the part of the image data that is within the bounds of the of the source rectangle. Also, it makes more sense to do it that way. I agree that the spec could use more clarity here. I support your case that it is preferable for the filtering algorithm to clamp to the border of the source rectangle rather than to the border the border of the source image. This is essential for implementing sprite maps without having to waste pixels to pad the borders between tiles. -Justin Novosad On Mon, Aug 20, 2012 at 9:38 AM, Kevin Gadd kevin.g...@gmail.com wrote: Hi, I've been digging into an inconsistency between various browsers' Canvas implementations and I think the spec might be allowing undesirable behavior here. The current version of the spec says ( http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawimage ): If the original image data is a bitmap image, the value painted at a point in the destination rectangle is computed by filtering the original image data. The user agent may use any filtering algorithm (for example bilinear interpolation or nearest-neighbor). When the filtering algorithm requires a pixel value from outside the original image data, it must instead use the value from the nearest edge pixel. (That is, the filter uses 'clamp-to-edge' behavior.) While clamp-to-edge is desirable, the way this is specified means that it only ever clamps to the edges of the source bitmap, not to the source rectangle. That means that attempting to do the equivalent of css sprites or video game style 'tile sets' - where a single source image contains many smaller images - is not possible, because the spec allows implementations to read pixels from outside the source rectangle. Unfortunately, at present Internet Explorer and Firefox both read pixels from outside the source rectangle, as demonstrated by this test case: https://dl.dropbox.com/u/1643240/canvas_artifacts.html Worse still, in implementations with imageSmoothingEnabled available, turning off image smoothing is not sufficient to eliminate the artifacts. Google Chrome appears to implement this the way you would probably want it to work - by clamping to the edges of the source rectangle, instead of the source image. I can't think of a good reason to prefer the current behavior over what Chrome does, and I haven't been able to find a reliable way to compensate for the current behavior. Thanks, -kg
Re: [whatwg] [canvas] Proposal for supportsContext
On Sep 10, 2012, at 9:32 PM, Dean Jackson d...@apple.com wrote:
On Sep 10, 2012, at 12:28 PM, Tobie Langel tobie.lan...@gmail.com wrote:
On Sep 10, 2012, at 8:14 PM, Dean Jackson d...@apple.com wrote:
I propose adding a new method to HTMLCanvasElement:
interface HTMLCanvasElement : HTMLElement {
boolean supportsContext(DOMString contextId, any... arguments);
};
supportsContext takes the same parameters as getContext, and simply returns
true if the corresponding call to getContext would have returned a valid
context, false otherwise.
What about enabling feature detection by providing a method per context?
interface HTMLCanvasElement : HTMLElement {
object get2DContext();
object getWebGLContext(any... args);
};
That way, developers can use idiomatic JS for feature testing like
pretty much everywhere else on the Web platform:
if (canvas.get2DContext) {
// do stuff with 2D canvas
}
This doesn't address the problem we are hitting, which is that
it is expensive to create a context.
It does. Only expose the API when you can create the context.
It's also a big change to
an existing operational API.
Agreed. You can always leave the previous method around for backward
compatibility.
--tobie
Re: [whatwg] [canvas] Proposal for supportsContext
On Sep 10, 2012, at 12:44 PM, Tobie Langel tobie.lan...@gmail.com wrote:
What about enabling feature detection by providing a method per context?
interface HTMLCanvasElement : HTMLElement {
object get2DContext();
object getWebGLContext(any... args);
};
That way, developers can use idiomatic JS for feature testing like
pretty much everywhere else on the Web platform:
if (canvas.get2DContext) {
// do stuff with 2D canvas
}
This doesn't address the problem we are hitting, which is that
it is expensive to create a context.
It does. Only expose the API when you can create the context.
This is actually what we could do now. We could hide
window.WebGLRenderingContext
when we can't create one. But then we'd have to hide all these too:
attribute [Conditional=WEBGL] WebGLActiveInfoConstructor
WebGLActiveInfo;
attribute [Conditional=WEBGL] WebGLBufferConstructor WebGLBuffer;
attribute [Conditional=WEBGL] WebGLFramebufferConstructor
WebGLFramebuffer;
attribute [Conditional=WEBGL] WebGLProgramConstructor WebGLProgram;
attribute [Conditional=WEBGL] WebGLRenderbufferConstructor
WebGLRenderbuffer;
attribute [Conditional=WEBGL] WebGLRenderingContextConstructor
WebGLRenderingContext;
attribute [Conditional=WEBGL] WebGLShaderConstructor WebGLShader;
attribute [Conditional=WEBGL] WebGLShaderPrecisionFormatConstructor
WebGLShaderPrecisionFormat;
attribute [Conditional=WEBGL] WebGLTextureConstructor WebGLTexture;
attribute [Conditional=WEBGL] WebGLUniformLocationConstructor
WebGLUniformLocation;
It seems like a pain.
Dean
It's also a big change to
an existing operational API.
Agreed. You can always leave the previous method around for backward
compatibility.
--tobie
Re: [whatwg] [canvas] Proposal for supportsContext
This is actually what we could do now. We could hide window.WebGLRenderingContext when we can't create one. But then we'd have to hide all these too: attribute [Conditional=WEBGL] WebGLActiveInfoConstructor WebGLActiveInfo; attribute [Conditional=WEBGL] WebGLBufferConstructor WebGLBuffer; attribute [Conditional=WEBGL] WebGLFramebufferConstructor WebGLFramebuffer; attribute [Conditional=WEBGL] WebGLProgramConstructor WebGLProgram; attribute [Conditional=WEBGL] WebGLRenderbufferConstructor WebGLRenderbuffer; attribute [Conditional=WEBGL] WebGLRenderingContextConstructor WebGLRenderingContext; attribute [Conditional=WEBGL] WebGLShaderConstructor WebGLShader; attribute [Conditional=WEBGL] WebGLShaderPrecisionFormatConstructor WebGLShaderPrecisionFormat; attribute [Conditional=WEBGL] WebGLTextureConstructor WebGLTexture; attribute [Conditional=WEBGL] WebGLUniformLocationConstructor WebGLUniformLocation; Oh my. All of these are globals!? *Sigh* --tobie
Re: [whatwg] [canvas] Proposal for supportsContext
On Mon, Sep 10, 2012 at 3:56 PM, Tobie Langel tobie.lan...@gmail.comwrote: This is actually what we could do now. We could hide window.WebGLRenderingContext when we can't create one. But then we'd have to hide all these too: attribute [Conditional=WEBGL] WebGLActiveInfoConstructor WebGLActiveInfo; attribute [Conditional=WEBGL] WebGLBufferConstructor WebGLBuffer; attribute [Conditional=WEBGL] WebGLFramebufferConstructor WebGLFramebuffer; attribute [Conditional=WEBGL] WebGLProgramConstructor WebGLProgram; attribute [Conditional=WEBGL] WebGLRenderbufferConstructor WebGLRenderbuffer; attribute [Conditional=WEBGL] WebGLRenderingContextConstructor WebGLRenderingContext; attribute [Conditional=WEBGL] WebGLShaderConstructor WebGLShader; attribute [Conditional=WEBGL] WebGLShaderPrecisionFormatConstructor WebGLShaderPrecisionFormat; attribute [Conditional=WEBGL] WebGLTextureConstructor WebGLTexture; attribute [Conditional=WEBGL] WebGLUniformLocationConstructor WebGLUniformLocation; Oh my. All of these are globals!? *Sigh* Has anyone considered a single global WebGL object with all of those constructors defined as properties? Rick --tobie
Re: [whatwg] [canvas] Proposal for supportsContext
On Sep 10, 2012, at 1:03 PM, Rick Waldron waldron.r...@gmail.com wrote: On Mon, Sep 10, 2012 at 3:56 PM, Tobie Langel tobie.lan...@gmail.com wrote: This is actually what we could do now. We could hide window.WebGLRenderingContext when we can't create one. But then we'd have to hide all these too: attribute [Conditional=WEBGL] WebGLActiveInfoConstructor WebGLActiveInfo; attribute [Conditional=WEBGL] WebGLBufferConstructor WebGLBuffer; attribute [Conditional=WEBGL] WebGLFramebufferConstructor WebGLFramebuffer; attribute [Conditional=WEBGL] WebGLProgramConstructor WebGLProgram; attribute [Conditional=WEBGL] WebGLRenderbufferConstructor WebGLRenderbuffer; attribute [Conditional=WEBGL] WebGLRenderingContextConstructor WebGLRenderingContext; attribute [Conditional=WEBGL] WebGLShaderConstructor WebGLShader; attribute [Conditional=WEBGL] WebGLShaderPrecisionFormatConstructor WebGLShaderPrecisionFormat; attribute [Conditional=WEBGL] WebGLTextureConstructor WebGLTexture; attribute [Conditional=WEBGL] WebGLUniformLocationConstructor WebGLUniformLocation; Oh my. All of these are globals!? *Sigh* Has anyone considered a single global WebGL object with all of those constructors defined as properties? I'm not sure if this is getting slightly off topic. Maybe you could make that proposal to the WebGL working group? Dean
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
On 2012-09-10, at 3:43 PM, Vladimir Vukicevic wrote: This is pretty tricky to get right -- there's just a general graphics problem in this case. There are valid use cases for both sampling outside and not sampling outside the source rectangle, as well as implementation issues for being able to do source rectangle clamping. For example, should you be able to take a source image and draw it scaled up using 4 rectangles (one for each quadrant) and have the result be equal to just doing it in one draw? Or take any random subimage (for example, for efficient updates of some destination) and draw it in. I do agree that the spec needs some clarity here, but I don't think that just stating that drawImage should always sample in the source is the right thing. At best, I think a new mode toggle or flag would be needed to allow you to select. FWIW, there are also negative performance implications to clamping samples to the source rect. Many graphics APIs do not support this kind sampling, and supporting this behaviour on top of those apis requires a temporary copy of the subimage to be made. -Jeff
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
On Mon, Sep 10, 2012 at 4:49 PM, Jeff Muizelaar jmuizel...@mozilla.comwrote: On 2012-09-10, at 3:43 PM, Vladimir Vukicevic wrote: FWIW, there are also negative performance implications to clamping samples to the source rect. Many graphics APIs do not support this kind sampling, and supporting this behaviour on top of those apis requires a temporary copy of the subimage to be made. You are referring to the fact that clamping modes only apply to texture borders in OpenGL and DirectX? That is not that big of a big deal, you can implement the clamp in a shader. I think Vladimir makes a good point that there are valid use cases for both ways. To summarize the issues: * clamping to source rect can cause filtering artefacts at boundaries, especially visible when tiling. * clamping to source image bounds can cause color bleeding artefacts when rendering a sprite from a spritemap.
Re: [whatwg] [canvas] Proposal for supportsContext
On Mon, 10 Sep 2012 13:14:30 -0500, Dean Jackson d...@apple.com wrote: To give a real world example, the popular tool Modernizr tests for the availability of WebGL by attempting to create a WebGL context. This can happen even on pages that have no intention of using WebGL - an author has just inserted Modernizr into their page and is using it to test for another feature. As I said, creating a context is not a free operation. In fact, on shipping Safari (Mountain Lion) this causes us to switch to a more powerful GPU on systems that have two graphics processors. An alternative (for the WebGL case) would be to have the author test for the presence of window.WebGLRenderingContext. However, this is not reliable. This is actually what Modernizr does these days [1], but older versions did in fact create the context. [1] https://github.com/Modernizr/Modernizr/blob/master/modernizr.js#L429-436 -- Mike Taylor Opera Software
Re: [whatwg] [canvas] Proposal for supportsContext
On 10 September 2012 20:39, Dean Jackson d...@apple.com wrote: On Sep 10, 2012, at 12:35 PM, Ashley Gullen ash...@scirra.com wrote: Can't Modernizr just lazy load the WebGL context? (i.e. only try to create a context if the web page actually asks if WebGL is supported) Yes, it could. But we don't control Modernizr or any other scripts people might use. I'd rather provide something at the browser-level to protect from bad practice than expect every page to behave nicely. We can't expect everyone to use good practices, but I think we can expect authors of widely-used libraries to use good practice! I think browser makers would still be tempted to implement supportsContext() in terms of creating a context and seeing if there's an error, since that's the only way to be 100% sure the answer is correct. This does not really solve anything. Also, realistically, any web app actually interested in using WebGL will first create a WebGL context, and if that fails then fall back to something else, so I'm not sure Modernizr actually need a better test for this than their new fixed code. Hiding/showing stuff in Javascript also doesn't really get around the need that you have to create a context to know for sure. Also, nothing so far could be extended to determine software vs. hardware rendering. Perhaps an approach could be taken similarly to HTMLMediaElement's canPlayType(). supportsContext() could return a string, which is one of: probably - the context appears to be supported (but this is not a guarantee) maybe - it is impossible to tell whether the context is supported without creating it. (empty string) - the context is definitely not supported. This avoids returning a simple true/false which implies some kind of guarantee in the true case. For supportsContext(), it could return some other strings as well since there are cases where we know more than HTMLMediaElement: yes - context definitely can be created. I think this would apply for 2d, since I believe in all browsers regardless of the setup it can fall back to a software renderer and the content will work, even if slowly. This also applies to Chrome's SwiftShader support for WebGL, meaning creating a WebGL context is also guaranteed to succeed. slow or software-rendered or emulated or some other term that needs careful definition: context can definitely be created but uses software rendering, e.g. meaning Chrome's SwiftShader will be used for WebGL, or possibly that the user's system does not support hardware-accelerated canvas 2d. Since this can apply simultaneously with yes, perhaps it could also return yes emulated or similar. Ashley
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
On 2012-09-10, at 5:28 PM, Justin Novosad wrote: On Mon, Sep 10, 2012 at 4:49 PM, Jeff Muizelaar jmuizel...@mozilla.com wrote: On 2012-09-10, at 3:43 PM, Vladimir Vukicevic wrote: FWIW, there are also negative performance implications to clamping samples to the source rect. Many graphics APIs do not support this kind sampling, and supporting this behaviour on top of those apis requires a temporary copy of the subimage to be made. You are referring to the fact that clamping modes only apply to texture borders in OpenGL and DirectX? That is not that big of a big deal, you can implement the clamp in a shader. No, I was referring to CoreGraphics, Cairo and Direct2D. -Jeff
Re: [whatwg] [canvas] Proposal for supportsContext
On Mon, Sep 10, 2012 at 2:39 PM, Dean Jackson d...@apple.com wrote: Can't Modernizr just lazy load the WebGL context? (i.e. only try to create a context if the web page actually asks if WebGL is supported) Yes, it could. But we don't control Modernizr or any other scripts people might use. I'd rather provide something at the browser-level to protect from bad practice than expect every page to behave nicely. Expecting pages to use a supportsContext API is still expecting pages to behave nicely. If you really want to protect users from the behavior of pages, you'd really need to make creating the context cheap. For example, don't switch to a high-power GPU until the page actually draws something, and--since many pages use both Canvas and WebGL for one-shot rendering--be sure to switch back to the low-power GPU after some idle time. (That means saving the WebGL state so it can be restored if the context is used again later--or as a last-ditch fallback, triggering context loss. I expect you'd want to be able to downgrade the GPU like this anyway, or else every page that does a quick draw-once-show-forever WebGL render would hurt laptop battery life.) A caching approach could also be used, to avoid creating the actual low-level context if all the page is doing is creating a context and doing a couple getParameter calls. (By the way, I'm not sure about it being bad practice to create a context in advance. It's just standard feature testing, which is exactly how JavaScript developers have been taught to detect features. It doesn't work as well with WebGL as with other APIs, since WebGL availability can change over a single page view, but it'll work most of the time.) On Mon, Sep 10, 2012 at 2:44 PM, Tobie Langel tobie.lan...@gmail.com wrote: It does. Only expose the API when you can create the context. Whether you can create a WebGL context can change after creating the HTMLCanvasElement. (For example, the driver blacklist might be updated, or you might create another context which is mutually exclusive with it.) Of course, properties on an object shouldn't change dynamically. On Mon, Sep 10, 2012 at 3:03 PM, Rick Waldron waldron.r...@gmail.com wrote: Has anyone considered a single global WebGL object with all of those constructors defined as properties? It's too late; WebGL is a shipping, widely-used API. (This isn't a WebGL problem, either; it's just doing what every other API on the platform does. I don't think WebIDL even has a mechanism to put interfaces inside other objects.) -- Glenn Maynard
Re: [whatwg] WebIDL nested interfaces
On Mon, Sep 10, 2012 at 5:39 PM, Tobie Langel tobie.lan...@gmail.comwrote:
It's too late; WebGL is a shipping, widely-used API. (This isn't a WebGL
problem, either; it's just doing what every other API on the platform
does.
I don't think WebIDL even has a mechanism to put interfaces inside other
objects.)
Really? Wouldn't this do the trick:
interface WebGLActiveInfo {
readonly attribute GLint size;
readonly attribute GLenum type;
readonly attribute DOMString name;
};
interface WebGLGlobal {
attribute WebGLActiveInfo activeInfo;
};
partial interface Window {
attribute WebGLGlobal WebGL;
};
This is just creating a global object WebGL containing an object using
the WebGLActiveInfo interface. It's not moving the WebGLActiveInfo
interface itself into an object. It sounds like you want something like
interface WebGL {
interface WebGLActiveInfo {
...
}
}
interface WebGLRenderingContext {
WebGL.WebGLActiveInfo? getActiveAttrib(WebGLProgram? program, GLuint
index);
}
--
Glenn Maynard
Re: [whatwg] WebIDL nested interfaces
On 9/10/12 6:39 PM, Tobie Langel wrote:
interface WebGLActiveInfo {
readonly attribute GLint size;
readonly attribute GLenum type;
readonly attribute DOMString name;
};
That just added a WebGLActiveInfo property on Window.
Unless you meant to make this [NoInterfaceObject]?
interface WebGLGlobal {
attribute WebGLActiveInfo activeInfo;
};
That returns an instance of WebGLActiveInfo. Window.WebGLActiveInfo,
today, is a Function object, not an instance of WebGLActiveInfo.
Also, that IDL just added a WebGLGlobal property on Window. Whose
value is a Function object.
-Boris
Re: [whatwg] [canvas] Proposal for supportsContext
On Mon, Sep 10, 2012 at 3:14 PM, Glenn Maynard gl...@zewt.org wrote: (By the way, I'm not sure about it being bad practice to create a context in advance. It's just standard feature testing, which is exactly how JavaScript developers have been taught to detect features. Indeed, js developers are guided towards feature detection, and rightly so. But which detect to use is a bit of cat 'n mouse and implementors don't play by the same rules here. As Mike Taylor pointed out, Modernizr used to create a context because checking !!window.WebGLRenderingContext is completely unreliable. But the Mozilla and Chrome GPU teams persuaded us to avoid the up-front context creation. On Mon, Sep 10, 2012 at 2:44 PM, Tobie Langel tobie.lan...@gmail.com wrote: Only expose the API when you can create the context. This is the ideal and most expected feature detect typically, though in WebGL's case we share a getContext method with 2d and opera-2dgame, so hiding the constructor global comes in second place. So far, Chrome and Firefox weren't excited about this approach. It's extremely important that we have feature detection techniques that we can trust the result of, across implementations. I'm a big +1 for supportsContext and as an API, it seems to introduce the ability with the least amount of collateral damage. _ Paul Irish, Lead Modernizr Dev
Re: [whatwg] WebIDL nested interfaces
On Tue, Sep 11, 2012 at 12:52 AM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Sep 10, 2012 at 5:39 PM, Tobie Langel tobie.lan...@gmail.com
wrote:
It's too late; WebGL is a shipping, widely-used API. (This isn't a
WebGL
problem, either; it's just doing what every other API on the platform
does.
I don't think WebIDL even has a mechanism to put interfaces inside
other
objects.)
Really? Wouldn't this do the trick:
interface WebGLActiveInfo {
readonly attribute GLint size;
readonly attribute GLenum type;
readonly attribute DOMString name;
};
interface WebGLGlobal {
attribute WebGLActiveInfo activeInfo;
};
partial interface Window {
attribute WebGLGlobal WebGL;
};
This is just creating a global object WebGL containing an object using the
WebGLActiveInfo interface. It's not moving the WebGLActiveInfo interface
itself into an object. It sounds like you want something like
interface WebGL {
interface WebGLActiveInfo {
...
}
}
interface WebGLRenderingContext {
WebGL.WebGLActiveInfo? getActiveAttrib(WebGLProgram? program, GLuint
index);
}
No. It sounds like I should be fast asleep instead of making a fool of
myself and wasting everybody's time.
Sorry folks.
--tobie
[whatwg] Including HTML more directly into SVG
This is a continuation of a discussion started in the #whatwg IRC room, so I'll start somewhat abruptly. 1. Check out http://www.xanthir.com/etc/railroad-diagrams/example.html. See all those boxes full of text in the diagrams? Looks simple, right? Just a box filled with text, with a border and background set on it. Wrong! SVG doesn't have any primitives like that. Instead, you have to position the text, measure its dimensions (or, like I've done, guess at the dimensions based on the font-size and such), then create and position an *independent* rect element behind it, so that it *looks* like there's a box with text inside of it. This would be a lot easier if I could somehow invoke the CSS box model inside of SVG, but the text element doesn't allow that. Closely related to this, SVG doesn't do automatic linebreaking at all. If you want text to break, you have to do it manually, not only determining the break points but also manually setting the line-spacing separation for each individual line. Again, it would be cool to invoke the CSS box model here, so we get full-power inline layout. 2. Unfortunately I don't remember the name of the product I'm about to describe, so I can't link to it, but there is an a11y tool that lets low-vision users interact better with SVG diagrams. They can print out an SVG, attach it over a pressure-sensitive touchpad, then bring up the diagram on the screen as well. Using the touchpad, they can then zoom/pan the SVG, or even ask the computer to read out text at the location they've pressed. Unfortunately, the textual semantics in SVG are pretty impoverished right now; there *aren't* any semantics, besides here is text. It seems pretty obvious that you'd sometimes want to, say, emphasize a span of text inside a larger text block in a diagram, but right now the only way to do that is by using tspan style=font-style:italic; and hoping that the reader supports enough CSS to guess that italicized text should be emphasized. It would be pretty nice if you could use em or the other textual HTML elements here, for the same reason it's nice to use them in HTML rather than relying on visual presentation. 3. Related to the above, it seems useful to be able to embed special elements like input type=date, video, or details into SVG, for the same reasons you'd include them in HTML. Right now, all three of the above *could* be done by using the foreignContent element. This is a horrible solution, though. To use foreignContent, you need to specify a width and height (and we're back to measuring or guessing at the dimensions...) and specify a namespace. This is a lot of weight to put into a document when all you want to do is include some simple text. Another solution could be SVG inventing their own elements for these kinds of things. For example, #1 could be solved with an svg:span or svg:p element. Having duplicate elements in multiple namespaces is regarded as an antipattern, however. Having elements which are duplicates save for their tagname is just as bad - less chameleon namespace problems, more gratuitous and needless naming differences between components of the web platform. My preferred solution is to simply include HTML directly into SVG. This solves #1 perfectly - all that needs to be done is to specify the SVG rendering model in terms of the CSS box model (it's simple, just a slight diff on position:absolute), then span or p works great. This solves #2 as well - you get em and the gang coming along for free, not to mention the block-level elements like hn, lists, etc., all of which can reasonable be used inside of something which is mostly SVG, like a diagram. Finally, it solves #3 just as cleanly, by letting us just use the languages together in a nice, friendly way without duplication or lots of boilerplate wrapper. This requires some minor parsing changes in HTML. Specifically, in http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inforeign (section 12.2.5.5 The rules for parsing tokens in foreign content), the rule that makes any HTML element pop the stack of open elements until it closes the SVG element would need to be removed. I'm aware that this was put in place to avoid breaking a few pages that, seemingly for no reason, include an svg tag at the start of their page with no matching /svg, as including the HTML directly in the svg element would suppress their rendering. However, with my suggested change, these pages would continue working, albeit probably with a slightly different rendering. If this is unacceptable, it's acceptable to me to require a small, simple wrapper element that accomplishes the same thing as foreignContent, but automatically places its contents in the HTML namespace and auto-sizes itself, and have the parser key off of that. This should be avoided if possible, though, as it's annoying for authors with no direct benefit to them. ~TJ
Re: [whatwg] WebIDL nested interfaces
Tobie Langel: No. It sounds like I should be fast asleep instead of making a fool of myself and wasting everybody's time. It is however the kind of thing that Tab wants to do for CSS (have a window.CSS object that is like a namespace object for some CSS interfaces -- the concept for which used to exist in Web IDL a while ago, but which I removed due to disuse). So it might well make sense to add something to Web IDL to handle this again.
