Re: [whatwg] Is EBCDIC support needed for not breaking the Web?

2008-06-02 Thread Henri Sivonen

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

2008-06-02 Thread Anne van Kesteren
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

2008-06-02 Thread Matthew Paul Thomas
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

2008-06-02 Thread Vladimir Vukicevic


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

2008-06-02 Thread Vladimir Vukicevic


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

2008-06-02 Thread Oliver Hunt
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

2008-06-02 Thread Vladimir Vukicevic


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

2008-06-02 Thread David Hyatt
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

2008-06-02 Thread Vladimir Vukicevic


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

2008-06-02 Thread David Hyatt

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

2008-06-02 Thread Oliver Hunt
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

2008-06-02 Thread Vladimir Vukicevic


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

2008-06-02 Thread David Hyatt

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

2008-06-02 Thread Robert O'Callahan
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

2008-06-02 Thread Robert O'Callahan
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

2008-06-02 Thread Oliver Hunt


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

2008-06-02 Thread Ernest Cline


-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.