Re: [whatwg] Request: Canvas Tag CSS
The Canvas element itself can be styled with CSS ( borders, size, outlines, background, ... ) but what is done in the CanvasContext does not end up in the DOM tree and therefore their styling can not be affected using CSS. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA Between Anne, Thomas and I, we have clearly shown that the individual shapes within a canvas element can indeed be effected by CSS at the time of their rendering and re-rendering(such as in an animation). Please refer to the other posts in this thread. I have proposed a solution that greatly simplifies effecting canvas shapes with CSS. Anne and Thomas have offered two work-arounds, one of which is rather complex, and the other is a strange hack and only slightly less complex. There is no question at this point of whether my solution will work or not. It will. Now it is simply a matter of interest. Is the benefit worth the extra time required by the UA's to implement it? I think so. It does not seem it would be a major endeavor for the UAs. They just see the following lines, and return the the correct property value. If the rule and property is defined in two or more stylesheets, the property in the rule of the last stylesheet in the array of stylesheets trumps those that came before. ctx.fillStyle = 'css(myButton, fill-style)'; ctx.lineWidth = 'css(myButton, line-width)'; lineargradient.addColorStop(0,'css(firstStop, color-stop)'); - Greg
Re: [whatwg] Request: Canvas Tag CSS
On Tue, Apr 8, 2008 at 11:37 AM, Greg Houston wrote: Between Anne, Thomas and I, we have clearly shown that the individual shapes within a canvas element can indeed be effected by CSS at the time of their rendering and re-rendering(such as in an animation). at the time of their rendering is the key. You cannot they are affected by CSS, it's just that your script reads the current property value from a stylesheet and uses it to draw the shapes. Affected by CSS would mean (at least that's my interpretation) reacting to CSS changes (document.styleSheets[0].cssRules[0].style.color = black; or simply selecting an alternate stylesheet from your browsers view menu). Maybe you could say initialized from CSS... I have proposed a solution that greatly simplifies effecting canvas shapes with CSS. Anne and Thomas have offered two work-arounds, one of which is rather complex, and the other is a strange hack and only slightly less complex. Anne also proposed you the Simplest Thing That Could Possibly Work: use search/replace in both CSS and JS. Want to change #123456 into #567890? search #123456 and replace with #567890. I understand what you're asking for, I just don't see the need, as it seems to me it'll do more harm than good: as soon as designers will start to style your canvas using CSS, they'll start using properties that you don't support in your drawing script. I mean, as Matthieu said, canvas is imperative while CSS is declarative, so most of CSS cannot be used with canvas. The only thing you can do is read values from the CSS and use them in your canvas script. In my opinion, you'd rather have a script consisting only of variable definitions (à la *.ini or *.properties files) and have your designers only update this file (and never touch nor even see the script responsible for the actual drawing). Also, given than there are multiple ways of solving the problem (including ones allowing you to read values from CSS), I suggest pushing the debate to a later canvas version. In brief, if you really want to style diagrams using CSS, use SVG, or just don't complain that doing it with canvas is tricky. -- Thomas Broyer
Re: [whatwg] Request: Canvas Tag CSS
Thomas Broyer wrote: On Tue, Apr 8, 2008 at 11:37 AM, Greg Houston wrote: Between Anne, Thomas and I, we have clearly shown that the individual shapes within a canvas element can indeed be effected by CSS at the time of their rendering and re-rendering(such as in an animation). at the time of their rendering is the key. You cannot they are affected by CSS, it's just that your script reads the current property value from a stylesheet and uses it to draw the shapes. Affected by CSS would mean (at least that's my interpretation) reacting to CSS changes This is one of the reasons for the C in CSS. Further and/or higher changes must cascade and affect the document. (document.styleSheets[0].cssRules[0].style.color = black; or simply selecting an alternate stylesheet from your browsers view menu). Maybe you could say initialized from CSS... I have proposed a solution that greatly simplifies effecting canvas shapes with CSS. Anne and Thomas have offered two work-arounds, one of which is rather complex, and the other is a strange hack and only slightly less complex. Anne also proposed you the Simplest Thing That Could Possibly Work: use search/replace in both CSS and JS. Want to change #123456 into #567890? search #123456 and replace with #567890. I understand what you're asking for, I just don't see the need, as it seems to me it'll do more harm than good: as soon as designers will start to style your canvas using CSS, they'll start using properties that you don't support in your drawing script. I mean, as Matthieu said, canvas is imperative while CSS is declarative, so most of CSS cannot be used with canvas. The only thing you can do is read values from the CSS and use them in your canvas script. This is screaming over-engineering. There is a standard to do that, and more, already and it's called SVG. In my opinion, you'd rather have a script consisting only of variable definitions (à la *.ini or *.properties files) and have your designers only update this file (and never touch nor even see the script responsible for the actual drawing). Also, given than there are multiple ways of solving the problem (including ones allowing you to read values from CSS), I suggest pushing the debate to a later canvas version. In brief, if you really want to style diagrams using CSS, use SVG, or just don't complain that doing it with canvas is tricky. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Request: Canvas Tag CSS
Dnia 08-04-2008, Wt o godzinie 12:39 +0200, Thomas Broyer pisze: On Tue, Apr 8, 2008 at 11:37 AM, Greg Houston wrote: Between Anne, Thomas and I, we have clearly shown that the individual shapes within a canvas element can indeed be effected by CSS at the time of their rendering and re-rendering(such as in an animation). at the time of their rendering is the key. You cannot they are affected by CSS, it's just that your script reads the current property value from a stylesheet and uses it to draw the shapes. Affected by CSS would mean (at least that's my interpretation) reacting to CSS changes (document.styleSheets[0].cssRules[0].style.color = black; or simply selecting an alternate stylesheet from your browsers view menu). Maybe you could say initialized from CSS... It is, however, far more convenient to initialize from JSON. I have proposed a solution that greatly simplifies effecting canvas shapes with CSS. Anne and Thomas have offered two work-arounds, one of which is rather complex, and the other is a strange hack and only slightly less complex. Anne also proposed you the Simplest Thing That Could Possibly Work: use search/replace in both CSS and JS. Want to change #123456 into #567890? search #123456 and replace with #567890. Search for #123456 and replace with preferred_colour_for_feature_X() I understand what you're asking for, I just don't see the need, as it seems to me it'll do more harm than good: as soon as designers will start to style your canvas using CSS, they'll start using properties that you don't support in your drawing script. I mean, as Matthieu said, canvas is imperative while CSS is declarative, so most of CSS cannot be used with canvas. The only thing you can do is read values from the CSS and use them in your canvas script. In my opinion, you'd rather have a script consisting only of variable definitions (à la *.ini or *.properties files) and have your designers only update this file (and never touch nor even see the script responsible for the actual drawing). I would recommend using functions instead of variables, or using JSON for the whole feature set. Chris
Re: [whatwg] Hyperlinks with |title| attribute
On 5 Apr 2008, at 11:57 pm, Ian Hickson wrote: On Sat, 5 Apr 2008, Christoph Päper wrote: Should (or may) user agents display the content of the |title| attribute of an |a| element in the GUI window caption (if the window manager used supports such), when the user followed the link and the retrieved resource is in a format that does not support specifying a title by itself (e.g. many image formats)? What about resources that could have a title but do not (e.g. a non-conformant HTML document without |title| element)? The alternatives are to display nothing or the name of the resource (file name), the final part of the path. I do not believe this is in scope for the specification. I don't see an interoperability issue here. But it does sound like a potential security issue, re-titling external documents. — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Request: Canvas Tag CSS
If users need to be able to restyle content in order to see it, how would this work with Canvas? Should UAs provide daltonization functionality for Canvas content, for example? http://www.vischeck.com/daltonize/ -- Benjamin Hawkes-Lewis
Re: [whatwg] Request: Canvas Tag CSS
On Tue, 08 Apr 2008 18:44:31 +0200, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: If users need to be able to restyle content in order to see it, how would this work with Canvas? Should UAs provide daltonization functionality for Canvas content, for example? http://www.vischeck.com/daltonize/ As far as that goes I don't think you should classify canvas any different from a scripted img. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[whatwg] ApplicationCache add/remove and relative URIs
The spec for the add and remove ApplicationCache methods does not say what to do about how relative URIs should be resolved. I think it would be most intuitive to resolve them agains't the URI o the document that the ApplicationCache object is associated with. Comments? Anders
Re: [whatwg] Request: Canvas Tag CSS
I will take the responses as votes, and the nays overwhelmingly win. Thank you for your consideration and debate. In the sum, the primary reason against is that changes to the CSS would not immediately effect the canvas drawing, which is the accepted behavior of CSS, i.e., instant results. The primary reasons for were, 1. not having to locate site styling in two different locations(e.g., the CSS and an ini file) with the caveat that dynamic changes to the CSS would not effect the canvas until the canvas was re-rendered, and 2, not requiring a complex search and replace when the UA could do this work. There were further reasons for and against for both. On Tue, Apr 8, 2008 at 9:38 AM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: Dnia 08-04-2008, Wt o godzinie 12:39 +0200, Thomas Broyer pisze: In my opinion, you'd rather have a script consisting only of variable definitions (à la *.ini or *.properties files) and have your designers only update this file (and never touch nor even see the script responsible for the actual drawing). I would recommend using functions instead of variables, or using JSON for the whole feature set. Currently in my use case a user can style each canvas instance with either the ini.js or an XHR JSON data request. The styling is stored in a JavaScript object that is passed as an argument to the constructor that creates each instance of the canvas. Cheers, Greg
Re: [whatwg] Hyperlinks with |title| attribute
Nicholas Shanks: On 5 Apr 2008, at 11:57 pm, Ian Hickson wrote: On Sat, 5 Apr 2008, Christoph Päper wrote: Should (or may) user agents display the content of the |title| attribute of an |a| element in the GUI window caption (...), when the user followed the link and the retrieved resource is in a format that does not support specifying a title by itself (...)? I do not believe this is in scope for the specification. But it does sound like a potential security issue, re-titling external documents. It would be perhaps (on a very low scale), if it was about retitling, but it is just about titling.
[whatwg] Clarification of Storage interface details
Section 4.10 has 2 details I'd like clarification on, that I think will probably result in changes to the spec. 1 - The entire section describes the StorageEvent interface, and specifies where StorageEvents should be fired when setItem() is called on any Storage object. I asked the mailing list last week and am now reiterating the question: Shouldn't this event fire for removeItem() as well? Hixie seemed to agree in IRC that it should, but I'd love to see it in writing ;) 2 - There is no mention of an onstorage attribute one can set on their body element. With this omission, it seems that the only way to actually listen for a storage event is to perform an addEventListener on the body. The technical docs for the IE8 beta indicate they support onstorage, and I tend to think it should be an official part of the spec. Thoughts? ~Brady
Re: [whatwg] ApplicationCache add/remove and relative URIs
Anders Carlsson wrote: The spec for the add and remove ApplicationCache methods does not say what to do about how relative URIs should be resolved. I think it would be most intuitive to resolve them agains't the URI o the document that the ApplicationCache object is associated with. Generally I believe URIs have been resolved against the URI of the document that the script that invoked the method is associated with. For example, if I have origin A and pages A_1 and A_2, a script on A_1 that uses, say, A_2.XMLHttpRequest.open with a relative URI will have that URI resolved against A_1.location.href. Similar precedent applies to loading scripts or iframes, calculating the sender's URI for events dispatched by postMessage, and other such uses. Think of it this way: a relative URI used from script is lexically scoped to the document that loaded the script, and any relative URIs used have the same semantics any time that code executes -- they're not dependent on the location of the document associated with the ApplicationCache, which might or might not be what you actually expected it to be at runtime. What you suggest goes against a lot of precedent, from my point of view. If only for consistency, I think we're better off making relative URIs be lexically scoped such that they're resolved against the location of the document in which the script is executed. Jeff
