Re: [whatwg] Is EBCDIC support needed for not breaking the Web?
On Jun 2, 2008, at 04:27, Benjamin Smedberg wrote: Henri Sivonen wrote: Firefox and Opera being able get away with not supporting EBCDIC flavors suggests that EBCDIC-based encodings cannot be particularly Web-relevant. Even if saying that browsers MUST NOT support them might end up being a dead letter, it seems that it would be feasible to say that browsers SHOULD NOT support them or at least MUST NOT let a heuristic detector guess EBCDIC (for security reasons). Gecko does support UTF-7 and will continue to do so because UTF-7 is still in use as a character set for mail encoding and multi-part MIME documents. Does/will Gecko support UTF-7 as a possible heuristic detector guess on the Web/HTTP side? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Proposal for a link attribute to replace a href
On Mon, 02 Jun 2008 05:26:40 +0200, Ernest Cline [EMAIL PROTECTED] wrote: The a element can already do this and it would be backwards compatible. Backwards compatible with some user agents but not with the specs. Sure, but anchor is not backwards compatible with specs or user agents. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Context help in Web Forms
Ian Hickson wrote on 27/05/08 07:47: On Mon, 12 Nov 2007, Matthew Paul Thomas wrote: On Oct 30, 2007, at 6:01 PM, Ian Hickson wrote: On Mon, 13 Jun 2005, Matthew Thomas wrote: ... Many applications provide inline help which is not a label, and the same attributes would be appropriate here: div rel=help for=phone-numberpThe full number, including country code./p pExample: samp+61 3 1234 5678/samp/p/div How would UAs use this? UAs likely wouldn't, but scripts could. For example, a form might include sparing help by default, with a style sheet hiding more exhaustive help (as indicated by rel=help). Then a script could add a small help button after each control that has associated help (i.e. each control with name=x where there exists an element on the page with rel=help for=x). When a control's help button was clicked, the control's help would be shown. ... The data-* attributes are intended for scripts like this. ... The disadvantage of using a data-* attribute is that more kinds of mistakes would be undetectable by a validator. It would have no idea that (a) the value of the attribute must be the ID of an element elsewhere in the document, and (b) each value must be unique within the document. I wonder if the data-* attribute naming scheme could be classified somehow to allow basic type checking like this. I expect there will be other cases where authors want an attribute value to match the ID of an element in the page. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] createImageData
Sorry it took me a bit to respond here... so, ok, based on the discussion, I'd suggest: - user-created ImageData-like objects should be supported, e.g. with language such as: The first argument to the method must be an ImageData object returned by createImageData(), getImageData(), or an object constructed with the necessary properties by the user. If the object was constructed by the user, its width and height dimensions are specified in device pixels (which may not map directly to CSS pixels). If null or any other object is given that does not present the ImageData interface, then the putImageData() method must raise a TYPE_MISMATCH_ERR exception. - ImageData objects returned by createImageData or getImageData should behave as currently specified; that is, they should explicitly clamp on pixel assignment. That gives users a choice over which approach they want to take, and whether they want clamping or not. How's that sound? - Vlad
[whatwg] [canvas] imageRenderingQuality property
I'd like to propose adding an imageRenderingQuality property on the canvas 2D context to allow authors to choose speed vs. quality when rendering images (especially transformed ones). This is modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty : attribute string imageRenderingQuality; 'auto' (default): The user agent shall make appropriate tradeoffs to balance speed and quality, but quality shall be given more importance than speed. 'optimizeQuality': Emphasize quality over rendering speed. 'optimizeSpeed': Emphasize speed over rendering quality. No specific image sampling algorithm is specified for any of these properties, with the exception that, at a minimum, nearest-neighbour resampling should be used. One alternative is to specify 'best', 'good', 'fast', with good being the default, as opposed to the SVG names; I think those names are more descriptive, but there might be value in keeping the names consistent with SVG, especially if that property bubbles up into general CSS usage. - Vlad
Re: [whatwg] [canvas] imageRenderingQuality property
Um, could you actually give some kind of reasoning for these? I am not aware of any significant performance issues in Canvas that cannot be almost directly attributed to JavaScript itself rather than the canvas. --Oliver On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote: I'd like to propose adding an imageRenderingQuality property on the canvas 2D context to allow authors to choose speed vs. quality when rendering images (especially transformed ones). This is modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty : attribute string imageRenderingQuality; 'auto' (default): The user agent shall make appropriate tradeoffs to balance speed and quality, but quality shall be given more importance than speed. 'optimizeQuality': Emphasize quality over rendering speed. 'optimizeSpeed': Emphasize speed over rendering quality. No specific image sampling algorithm is specified for any of these properties, with the exception that, at a minimum, nearest-neighbour resampling should be used. One alternative is to specify 'best', 'good', 'fast', with good being the default, as opposed to the SVG names; I think those names are more descriptive, but there might be value in keeping the names consistent with SVG, especially if that property bubbles up into general CSS usage. - Vlad
Re: [whatwg] [canvas] imageRenderingQuality property
Sure; bilinear filtering is slower than nearest neighbour sampling, and in many cases the app author would like to be able to decide that tradeoff (or, at least, to be able to say I want this to go as fast as possible, regardless of quality). Some apps might also render to a canvas just once, and would prefer to do it at the highest quality filtering available even if it's more expensive than the default. - Vlad On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote: Um, could you actually give some kind of reasoning for these? I am not aware of any significant performance issues in Canvas that cannot be almost directly attributed to JavaScript itself rather than the canvas. --Oliver On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote: I'd like to propose adding an imageRenderingQuality property on the canvas 2D context to allow authors to choose speed vs. quality when rendering images (especially transformed ones). This is modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty : attribute string imageRenderingQuality; 'auto' (default): The user agent shall make appropriate tradeoffs to balance speed and quality, but quality shall be given more importance than speed. 'optimizeQuality': Emphasize quality over rendering speed. 'optimizeSpeed': Emphasize speed over rendering quality. No specific image sampling algorithm is specified for any of these properties, with the exception that, at a minimum, nearest- neighbour resampling should be used. One alternative is to specify 'best', 'good', 'fast', with good being the default, as opposed to the SVG names; I think those names are more descriptive, but there might be value in keeping the names consistent with SVG, especially if that property bubbles up into general CSS usage. - Vlad
Re: [whatwg] [canvas] imageRenderingQuality property
I like the idea of this property. I actually would love to see the SVG property applied to HTML img as well. :) dave On Jun 2, 2008, at 4:15 PM, Vladimir Vukicevic wrote: Sure; bilinear filtering is slower than nearest neighbour sampling, and in many cases the app author would like to be able to decide that tradeoff (or, at least, to be able to say I want this to go as fast as possible, regardless of quality). Some apps might also render to a canvas just once, and would prefer to do it at the highest quality filtering available even if it's more expensive than the default. - Vlad On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote: Um, could you actually give some kind of reasoning for these? I am not aware of any significant performance issues in Canvas that cannot be almost directly attributed to JavaScript itself rather than the canvas. --Oliver On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote: I'd like to propose adding an imageRenderingQuality property on the canvas 2D context to allow authors to choose speed vs. quality when rendering images (especially transformed ones). This is modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty : attribute string imageRenderingQuality; 'auto' (default): The user agent shall make appropriate tradeoffs to balance speed and quality, but quality shall be given more importance than speed. 'optimizeQuality': Emphasize quality over rendering speed. 'optimizeSpeed': Emphasize speed over rendering quality. No specific image sampling algorithm is specified for any of these properties, with the exception that, at a minimum, nearest- neighbour resampling should be used. One alternative is to specify 'best', 'good', 'fast', with good being the default, as opposed to the SVG names; I think those names are more descriptive, but there might be value in keeping the names consistent with SVG, especially if that property bubbles up into general CSS usage. - Vlad
Re: [whatwg] [canvas] imageRenderingQuality property
Yeah, I agree -- I thought that there was some plan somewhere to uplift a bunch of these SVG CSS properties into general usage? I know that Gecko uplifted text-rendering, we should figure out what else makes sense to pull up. (If image-rendering were uplifted, it would apply to canvas, for the scaling/transformation of the canvas element itself as opposed to the canvas rendering content.) - Vlad On Jun 2, 2008, at 2:26 PM, David Hyatt wrote: I like the idea of this property. I actually would love to see the SVG property applied to HTML img as well. :) dave On Jun 2, 2008, at 4:15 PM, Vladimir Vukicevic wrote: Sure; bilinear filtering is slower than nearest neighbour sampling, and in many cases the app author would like to be able to decide that tradeoff (or, at least, to be able to say I want this to go as fast as possible, regardless of quality). Some apps might also render to a canvas just once, and would prefer to do it at the highest quality filtering available even if it's more expensive than the default. - Vlad On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote: Um, could you actually give some kind of reasoning for these? I am not aware of any significant performance issues in Canvas that cannot be almost directly attributed to JavaScript itself rather than the canvas. --Oliver On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote: I'd like to propose adding an imageRenderingQuality property on the canvas 2D context to allow authors to choose speed vs. quality when rendering images (especially transformed ones). This is modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty : attribute string imageRenderingQuality; 'auto' (default): The user agent shall make appropriate tradeoffs to balance speed and quality, but quality shall be given more importance than speed. 'optimizeQuality': Emphasize quality over rendering speed. 'optimizeSpeed': Emphasize speed over rendering quality. No specific image sampling algorithm is specified for any of these properties, with the exception that, at a minimum, nearest- neighbour resampling should be used. One alternative is to specify 'best', 'good', 'fast', with good being the default, as opposed to the SVG names; I think those names are more descriptive, but there might be value in keeping the names consistent with SVG, especially if that property bubbles up into general CSS usage. - Vlad
Re: [whatwg] [canvas] imageRenderingQuality property
On Jun 2, 2008, at 4:34 PM, Vladimir Vukicevic wrote: Yeah, I agree -- I thought that there was some plan somewhere to uplift a bunch of these SVG CSS properties into general usage? I know that Gecko uplifted text-rendering, we should figure out what else makes sense to pull up. (If image-rendering were uplifted, it would apply to canvas, for the scaling/transformation of the canvas element itself as opposed to the canvas rendering content.) - Vlad Right, that would be my expectation as well (that the CSS property could be applied to canvas to control the quality when rendering the canvas buffer itself). dave
Re: [whatwg] [canvas] imageRenderingQuality property
That's exactly what i would be afraid of people doing. If I have a fast system why should i have to experience low quality rendering? It should be the job of the platform to determine what level of performance or quality can be achieved on a given device. Typically such a property would be considered a hint, and as such would likely be ignored. If honouring this property was _required_ rather than being a hint you would hit the following problems: * Low power devices would have a significant potential for poor performance if a developer found that their desktop performed well so set the requirement to high quality. * High power devices would be forced to use low quality rendering modes when perfectly capable of providing better quality without significant performance penalty. Neither of these apply if the property were just a hint, but now you have to think about what happens to content that uses this property in 18 months time. You've told the UA to use a low quality rendering when it may no longer be necessary, so now the UA has a choice it either always obeys the property meaning lower quality than is necessary so that new content performs well, or it ignores the property in which case new content performs badly. The correct behaviour would be for the UA to work out itself what it can do, which it needs to be able to do anyway, in order to satisfy the auto option. --Oliver On Jun 2, 2008, at 2:15 PM, Vladimir Vukicevic wrote: Sure; bilinear filtering is slower than nearest neighbour sampling, and in many cases the app author would like to be able to decide that tradeoff (or, at least, to be able to say I want this to go as fast as possible, regardless of quality). Some apps might also render to a canvas just once, and would prefer to do it at the highest quality filtering available even if it's more expensive than the default. - Vlad On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote: Um, could you actually give some kind of reasoning for these? I am not aware of any significant performance issues in Canvas that cannot be almost directly attributed to JavaScript itself rather than the canvas. --Oliver On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote: I'd like to propose adding an imageRenderingQuality property on the canvas 2D context to allow authors to choose speed vs. quality when rendering images (especially transformed ones). This is modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty : attribute string imageRenderingQuality; 'auto' (default): The user agent shall make appropriate tradeoffs to balance speed and quality, but quality shall be given more importance than speed. 'optimizeQuality': Emphasize quality over rendering speed. 'optimizeSpeed': Emphasize speed over rendering quality. No specific image sampling algorithm is specified for any of these properties, with the exception that, at a minimum, nearest- neighbour resampling should be used. One alternative is to specify 'best', 'good', 'fast', with good being the default, as opposed to the SVG names; I think those names are more descriptive, but there might be value in keeping the names consistent with SVG, especially if that property bubbles up into general CSS usage. - Vlad
Re: [whatwg] [canvas] imageRenderingQuality property
On Jun 2, 2008, at 2:39 PM, Oliver Hunt wrote: That's exactly what i would be afraid of people doing. If I have a fast system why should i have to experience low quality rendering? It should be the job of the platform to determine what level of performance or quality can be achieved on a given device. Typically such a property would be considered a hint, and as such would likely be ignored. If honouring this property was _required_ rather than being a hint you would hit the following problems: * Low power devices would have a significant potential for poor performance if a developer found that their desktop performed well so set the requirement to high quality. * High power devices would be forced to use low quality rendering modes when perfectly capable of providing better quality without significant performance penalty. Neither of these apply if the property were just a hint, but now you have to think about what happens to content that uses this property in 18 months time. You've told the UA to use a low quality rendering when it may no longer be necessary, so now the UA has a choice it either always obeys the property meaning lower quality than is necessary so that new content performs well, or it ignores the property in which case new content performs badly. If web apps misuse the property, then bugs should be filed on those apps that incorrectly use the property, and the app developer should fix them. The web platform shouldn't prevent developers from exercising control over how their content is rendered; most developers, as you say, probably shouldn't change anything from the default 'auto'. But the capability should be there. Arbitrarily deciding what developers can and can't do isn't interesting from the perspective of creating a full-featured platform, IMO. No matter how fast smooth/bilinear filtering is, something more complex is always going to be slower, and something less complex is always going to be faster. If those perf differences are significant to the web app, no matter how small, you're going to want to be able to have that control. If they're not, then you should just be using 'auto' and let the UA handle it. - Vlad On Jun 2, 2008, at 2:15 PM, Vladimir Vukicevic wrote: Sure; bilinear filtering is slower than nearest neighbour sampling, and in many cases the app author would like to be able to decide that tradeoff (or, at least, to be able to say I want this to go as fast as possible, regardless of quality). Some apps might also render to a canvas just once, and would prefer to do it at the highest quality filtering available even if it's more expensive than the default. - Vlad On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote: Um, could you actually give some kind of reasoning for these? I am not aware of any significant performance issues in Canvas that cannot be almost directly attributed to JavaScript itself rather than the canvas. --Oliver On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote: I'd like to propose adding an imageRenderingQuality property on the canvas 2D context to allow authors to choose speed vs. quality when rendering images (especially transformed ones). This is modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty : attribute string imageRenderingQuality; 'auto' (default): The user agent shall make appropriate tradeoffs to balance speed and quality, but quality shall be given more importance than speed. 'optimizeQuality': Emphasize quality over rendering speed. 'optimizeSpeed': Emphasize speed over rendering quality. No specific image sampling algorithm is specified for any of these properties, with the exception that, at a minimum, nearest- neighbour resampling should be used. One alternative is to specify 'best', 'good', 'fast', with good being the default, as opposed to the SVG names; I think those names are more descriptive, but there might be value in keeping the names consistent with SVG, especially if that property bubbles up into general CSS usage. - Vlad
Re: [whatwg] [canvas] imageRenderingQuality property
On Jun 2, 2008, at 4:57 PM, Vladimir Vukicevic wrote: On Jun 2, 2008, at 2:39 PM, Oliver Hunt wrote: That's exactly what i would be afraid of people doing. If I have a fast system why should i have to experience low quality rendering? It should be the job of the platform to determine what level of performance or quality can be achieved on a given device. Typically such a property would be considered a hint, and as such would likely be ignored. If honouring this property was _required_ rather than being a hint you would hit the following problems: * Low power devices would have a significant potential for poor performance if a developer found that their desktop performed well so set the requirement to high quality. * High power devices would be forced to use low quality rendering modes when perfectly capable of providing better quality without significant performance penalty. Neither of these apply if the property were just a hint, but now you have to think about what happens to content that uses this property in 18 months time. You've told the UA to use a low quality rendering when it may no longer be necessary, so now the UA has a choice it either always obeys the property meaning lower quality than is necessary so that new content performs well, or it ignores the property in which case new content performs badly. If web apps misuse the property, then bugs should be filed on those apps that incorrectly use the property, and the app developer should fix them. The web platform shouldn't prevent developers from exercising control over how their content is rendered; most developers, as you say, probably shouldn't change anything from the default 'auto'. But the capability should be there. Arbitrarily deciding what developers can and can't do isn't interesting from the perspective of creating a full-featured platform, IMO. No matter how fast smooth/bilinear filtering is, something more complex is always going to be slower, and something less complex is always going to be faster. If those perf differences are significant to the web app, no matter how small, you're going to want to be able to have that control. If they're not, then you should just be using 'auto' and let the UA handle it. I completely agree. Almost any feature can be abused. It's not our job to withhold features just because they can be abused. It's also worth pointing out that this is a common graphical knob supported by Cairo and CoreGraphics. It is a proprietary MS CSS property and an SVG CSS property. In other words, it seems to be a pretty widely implemented feature and as such seems like it would be a worthwhile addition to canvas. If we add this, we should also add support for text rendering quality as well, since canvas is picking up the ability to draw text. dave ([EMAIL PROTECTED])
Re: [whatwg] [canvas] imageRenderingQuality property
On Tue, Jun 3, 2008 at 9:34 AM, Vladimir Vukicevic [EMAIL PROTECTED] wrote: Yeah, I agree -- I thought that there was some plan somewhere to uplift a bunch of these SVG CSS properties into general usage? I know that Gecko uplifted text-rendering, we should figure out what else makes sense to pull up. Sort of off topic, but as you said, we uplifted 'text-rendering' in Gecko 1.9. I'm experimenting with 'clip-path', 'mask' and 'filter'. We're also looking at uplifting 'pointer-events'. For the non-hint properties we have to be more careful because it needs to be specified what they mean for non-SVG content; uplifting the hint properties is a lot easier. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] [canvas] imageRenderingQuality property
On Tue, Jun 3, 2008 at 9:39 AM, Oliver Hunt [EMAIL PROTECTED] wrote: That's exactly what i would be afraid of people doing. If I have a fast system why should i have to experience low quality rendering? It should be the job of the platform to determine what level of performance or quality can be achieved on a given device. Right, it is. The user-agent is free to map all property values to maximum quality. Typically such a property would be considered a hint, and as such would likely be ignored. Ignored by who? Neither of these apply if the property were just a hint, but now you have to think about what happens to content that uses this property in 18 months time. You've told the UA to use a low quality rendering when it may no longer be necessary, so now the UA has a choice it either always obeys the property meaning lower quality than is necessary so that new content performs well, or it ignores the property in which case new content performs badly. If the quality knob is no longer necessary, why would new content perform badly? These hint properties are opt-in for UAs. If you don't like the idea, just treat all values as auto. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] [canvas] imageRenderingQuality property
On Jun 2, 2008, at 3:19 PM, Robert O'Callahan wrote: On Tue, Jun 3, 2008 at 9:39 AM, Oliver Hunt [EMAIL PROTECTED] wrote: That's exactly what i would be afraid of people doing. If I have a fast system why should i have to experience low quality rendering? It should be the job of the platform to determine what level of performance or quality can be achieved on a given device. Right, it is. The user-agent is free to map all property values to maximum quality. Typically such a property would be considered a hint, and as such would likely be ignored. Ignored by who? Given a few years all UA's as the majority of content saying low quality will be old, and therefore targeting slower UAs and platforms (given moore's law, and the fact that all UAs are currently getting faster this seems a reasonable assertion) so respecting it would mean the majority of sites using low quality mode would not need to. Neither of these apply if the property were just a hint, but now you have to think about what happens to content that uses this property in 18 months time. You've told the UA to use a low quality rendering when it may no longer be necessary, so now the UA has a choice it either always obeys the property meaning lower quality than is necessary so that new content performs well, or it ignores the property in which case new content performs badly. If the quality knob is no longer necessary, why would new content perform badly? The issue is not that certain operations are slower than others, the issue is that anything that requires the developer to choose between performance/quality is going to become obsolete as the performance trade offs are constantly moving and are not the same from UA to UA, from platform to platform. I think the issue of performance is a complex one that will not benefit in the long term from a simple on off switch. Conceivably we could introduce new rendering primitives, such as CanvasSprite, CanvasLayer, or some such which would, i suspect, provide a similar benefit, but be more resilient in the face of changing performance characteristics. Rob --Oliver
Re: [whatwg] Proposal for a link attribute to replace a href
-Original Message- From: Anne van Kesteren [EMAIL PROTECTED] Sent: Jun 2, 2008 5:39 AM On Mon, 02 Jun 2008 05:26:40 +0200, Ernest Cline [EMAIL PROTECTED] wrote: The a element can already do this and it would be backwards compatible. Backwards compatible with some user agents but not with the specs. Sure, but anchor is not backwards compatible with specs or user agents. That might be a reason to adjust the spec for a to have it match current behavior, but in my opinion it would be better to provide for the block/inline distinction to be handled with recourse to CSS by having separate elements as is the case for div/span. There are alternatives to obtain this behavior in old browsers without using a in a block context, so the loss of backward compatibility would be a minor issue at most. That said, adjusting the spec to have a follow current behavior would be better than leaving the spec as it is and not have any spec compliant method to provide a block level hyperlink without the use of scripting.