Re: [whatwg] Canvas Proposal: aliasClipping property
I think "feathered" isn't a good term. It's vary rarely used in graphics in my experience. "aliasClipping" isn't a good term either, since there's no clipping going on typically. I would just have boolean property named "antialias". 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 Proposal: aliasClipping property
This sounds like a very good proposal, but can we extend it to include other
things than just drawImage? I'm not sure how useful it would be, but it
could perhaps include all the other drawing options, like stroking and
filling paths created with lineTo, arc, etc.
Marius Gundersen
On Sun, Oct 4, 2009 at 9:10 AM, Charles Pritchard wrote:
> There have been a few discussions about anti-aliasing / aliasing in Canvas
> implementations.
> Of those I read through, the conflict remains.
>
> In some implementations: when drawImage is used along with a clipping path,
> feathering is applied. This shows up in several projective transformation
> demos
> contrasting Firefox with Chrome.
>
> I believe that if we allow a toggle for this setting, we can bring some
> compatibility
> to the two systems.
>
> Enumerate two aliasClipping values : "aliased", "feathered"
>
> I consider "anti-aliased" to confusing, I think "feathered" is a better
> name.
>
> .
>
> [Supplemental]
> interface CanvasRenderingContext2D {
>attribute DOMString aliasClipping; // default "feathered"
> }
>
> context . aliasClipping [ = value ]
>
>Returns the current aliasing of the clipping region, as applied to
> rendering operations.
>
>Can be set, to change the aliasing value.
>
>If any of the arguments are not implemented, throws a NOT_SUPPORTED_ERR
> exception.
>
> CanvasRenderingContext2D.prototype.defineSetter('aliasClipping') { throw
> NOT_SUPPORTED_ERR; }
>
>
[whatwg] Canvas Proposal: aliasClipping property
There have been a few discussions about anti-aliasing / aliasing in
Canvas implementations.
Of those I read through, the conflict remains.
In some implementations: when drawImage is used along with a clipping path,
feathering is applied. This shows up in several projective
transformation demos
contrasting Firefox with Chrome.
I believe that if we allow a toggle for this setting, we can bring some
compatibility
to the two systems.
Enumerate two aliasClipping values : "aliased", "feathered"
I consider "anti-aliased" to confusing, I think "feathered" is a better
name.
.
[Supplemental]
interface CanvasRenderingContext2D {
attribute DOMString aliasClipping; // default "feathered"
}
context . aliasClipping [ = value ]
Returns the current aliasing of the clipping region, as applied to
rendering operations.
Can be set, to change the aliasing value.
If any of the arguments are not implemented, throws a
NOT_SUPPORTED_ERR exception.
CanvasRenderingContext2D.prototype.defineSetter('aliasClipping') { throw
NOT_SUPPORTED_ERR; }
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
On Sat, Oct 3, 2009 at 12:03 PM, Keryx Web wrote: > 2009-10-03 00:51, Tab Atkins Jr. skrev: > >> / only have parsing problems in IE6 and IE7. Both of them >> *are*, finally, actually dropping off the radar. Windows 7 will >> accelerate this as people upgrade with an OS that runs IE8 by default. >> Give it 2 years or so and most places will be able to justify >> ignoring IE7 (many/most sites already ignore IE6). > > The IE6/7 problem is not the only one. A number of people, myself included, > have expressed dissatisfaction from a semantic and teachability viewpoint. > > It is not better to let dt/dd have three (or perhaps 2) different meanings, > and different syntactic rules depending upon the parent element than it > would be to have 2 more elements. > > And if the use cases for details and/or figure is so weak, that they would > be dropped JUST BECAUSE they would introduce yet 1 or 2 additional elements > to make them work, than we might as well drop them. > > Do it right or do not do it at all! > > If an element has (1) a whole new semantic meaning in one place than it has > in another place, and (b) different syntactic rules in one place than it has > in another place, it is NOT THE SAME ELEMENT by definition. > > Let's not kid ourselves. We ARE introducing new elements here. It just so > happens that they share the same name as 2 old ones. Or at least the same > abbreviated name, since some people suggest that they would be expanded to > "details type" and "details data", when used with details. > > What further proof do you need to understand that we are de facto > introducing new elements, even if we confusingly, re-use old names? Well, no amount of proof would do so; only a convincing enough argument. I, personally, do not feel that 's semantics change between and . Nor do I feel they have different syntax at all - and do have slightly different syntaxes, but it's very minor and pretty much bound up in the fact that has multiple name/value pairs while has only one, so doesn't *have* to worry about ordering in the same way that does. You see, I've authored lots of internal applications for myself and others in my company. Tree structures figure prominently, since these application are often relatively thin layers over the database structure. Looking back, I appear to be split evenly and arbitrarily between using nested s to handle this structure and using nested headings/sections to handle it. There really doesn't appear to be much rhyme or reason behind my choice of one or the other. Either would be appropriate. The only thing I can see is that possibly the pages I saw more as lists I used s for, while the pages I saw more as documents I used headings/sections for. So, in my mind, / do *not* hold some special meaning that locks them into only ever being used in . is a heading element, nothing more, effectively equivalent to *. is a sectioning element, nothing more, effectively equivalent (though used slightly differently) to . Both and declare the name for some body of data contained in or . Thus using and in to fulfill the same purpose (wrapping the "name" and the "data") is completely natural to me. That's not to say that other solutions wouldn't also be natural, but I find nothing wrong with the status quo on semantic or usability concerns. I mean, would you complain about using or or or or what-have-you in ? The change in semantics and syntax would be as great or greater than /. It so happens that all of those are *worse* from a rendering perspective than /, so we've discarded them as solutions. But none of them are privileged as 'closer' to the syntax or semantics of the toggler and data elements of . ~TJ * I know that the equivalence is not complete - has an effect on the document outline that does not. But aside from that, they're equivalent in my eyes.
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
2009-10-03 00:51, Tab Atkins Jr. skrev: / only have parsing problems in IE6 and IE7. Both of them *are*, finally, actually dropping off the radar. Windows 7 will accelerate this as people upgrade with an OS that runs IE8 by default. Give it 2 years or so and most places will be able to justify ignoring IE7 (many/most sites already ignore IE6). The IE6/7 problem is not the only one. A number of people, myself included, have expressed dissatisfaction from a semantic and teachability viewpoint. It is not better to let dt/dd have three (or perhaps 2) different meanings, and different syntactic rules depending upon the parent element than it would be to have 2 more elements. And if the use cases for details and/or figure is so weak, that they would be dropped JUST BECAUSE they would introduce yet 1 or 2 additional elements to make them work, than we might as well drop them. Do it right or do not do it at all! If an element has (1) a whole new semantic meaning in one place than it has in another place, and (b) different syntactic rules in one place than it has in another place, it is NOT THE SAME ELEMENT by definition. Let's not kid ourselves. We ARE introducing new elements here. It just so happens that they share the same name as 2 old ones. Or at least the same abbreviated name, since some people suggest that they would be expanded to "details type" and "details data", when used with details. What further proof do you need to understand that we are de facto introducing new elements, even if we confusingly, re-use old names? -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
On Sat, Oct 3, 2009 at 3:51 AM, Dean Edwards wrote: > On 03/10/2009 03:38, Tab Atkins Jr. wrote: >> >> Agreed, but won't be usable at all in modern browsers >> (without hacking support in via js) until everyone updates. > > That's the whole point of this thread. We are specifying something that > won't be usable for years. Let's make the spec better so that we can use > sooner. But we won't be able to, really. As it stands, doesn't "work" in any of the modern browsers. You are forced to use js to hack the toggling functionality in. IE6 and IE7 are slightly more broken, in that they require a relatively invasive script hack to get them to the same level of not-working that all the other browsers have. If we mint a new element, we pay the costs of adding yet another vaguely-heading element to add to the dozen+ we already have in the language, and what's the benefit? IE6 and IE7 will require a less invasive hack to get them to the same level of not-working that all the other browsers have. I can definitely understand why it's felt that that's not sufficient benefit to justify it. No modern browser gets anything out of the deal, only a pair of legacy browsers that are, finally, on their way out. And we'd be saddled with still more naming confusion regarding which of the dozen elements is appropriate in as opposed to , , , etc. despite them all serving roughly the same purpose. A permanent cost to solve a temporary problem that will disappear on its own, and one that doesn't even *need* solving - the only benefit is that you get to change your toggle scripts to look for rather than sooner. I wanna use soon too - it gives me the warm fuzzies for some reason even if I have to hack the functionality in myself. But I can accept waiting until IE7 is irrelevant. I'm going to be doing that anyway for a number of other HTML5 features. ~TJ
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
On 03/10/2009 03:38, Tab Atkins Jr. wrote: Agreed, but won't be usable at all in modern browsers (without hacking support in via js) until everyone updates. That's the whole point of this thread. We are specifying something that won't be usable for years. Let's make the spec better so that we can use sooner. -dean
[whatwg] functionality absorbed into ?
Hi All, In talking with authors about HTML5 [1] I’ve found it seems confusing for many people, and I’ve also found it a little difficult to explain so it’s easy to understand (conversation = why? outline algorithm. huh?). Currently it’s only role is to hide subheadings from the outline algorithm and it doesn’t map to a common use pattern for adding semantic meaning. There doesn’t seem to be any tangible benefit to authors in using it. Superfriends suggested a Boolean attribute for to determine if all child - elements are included in the outline[2]. The current model excludes all subtitles from the outline. Assuming that subtitles should not be included in the outline (eg to make sure the highest-ranked title is indeed descriptive), what if by default masked subtitles from the outline algorithm as currently does? This would mean is no longer necessary, and make less optional (it currently feels like solely a CSS hook from an author perspective). Currently #the-header-element[3] mentions a “Little Green Guys With Guns” example in which - elements in the but outside create implied elements via the outline algorithm. If hides all but one - element this won’t happen (this is also a potential issue with the Boolean attribute idea). While the spec states authors should add wrapping s I suspect many won’t bother and rely on implied ones (unless they need CSS hooks). This would also be potentially confusing compared with , and possibly encourage authors to mistakenly add s with s inside of a (copy&paste mistakes etc). While this idea has drawbacks I feel ’s lack of tangible author benefit and ‘occasional use’ nature will result in it not being widely used when it should be. I’d like to hear your opinion on both this idea and the Superfriends Boolean attribute idea (which I haven’t found discussed in the list). Thanks for your time peace - oli PS note elements implied by the outline algorithm aren’t present in the DOM and so are not styled (thanks @vant) [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-hgroup-element [2] http://www.zeldman.com/superfriends/guide/#hgroup [3] http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-header-element
Re: [whatwg] Structured clone algorithm on LocalStorage
On Fri, Oct 2, 2009 at 9:58 PM, Darin Fisher wrote:
> >> >> Not quite sure I follow your proposal. How would you for example
>> >> >> increase the value of a property by one without risking race
>> >> >> conditions? Or keep two values in different properties in sync?
>> I.e.
>> >> >> so that if you update one always update the other, so that they
>> never
>> >> >> have different values.
>> >> >>
>> >> >> / Jonas
>> >> >
>> >> >
>> >> > Easy. Just like with database, the transaction is the storage
>> lock.
>> >> > Any
>> >> > storage
>> >> > operation performed on that transaction are done atomically.
>> However,
>> >> > all
>> >> > storage
>> >> > operations are asynchronous. You basically string together
>> asynchronous
>> >> > storage
>> >> > operations by using the same transaction for each.
>> >> > We could add methods to get/set multiple items at once to
>> simplify life
>> >> > for
>> >> > the coder.
>> >>
>> >> I think I still don't understand your proposal, could you give some
>> >> code examples?
>> >>
>> >
>> >
>> > ripping off database:
>> > interface ValueStorage {
>> > void transaction(in DOMString namespace, in
>> > ValueStorageTransactionCallback callback);
>> > };
>> > interface ValueStorageTransactionCallback {
>> > void handleEvent(in ValueStorageTransaction transaction);
>> > };
>> > interface ValueStorageTransaction {
>> > void readValue(in DOMString name, in ValueStorageReadCallback
>> callback);
>> > void writeValue(in DOMString name, in DOMString value);
>> > };
>> > interface ValueStorageReadCallback {
>> > void handleEvent(in ValueStorageTransaction transaction, in
>> DOMString
>> > value);
>> > };
>> > then, to use these interfaces, you could implement thread-safe
>> increment:
>> > window.localStorage.transaction("slice", function(transaction) {
>> > transaction.readValue("foo", function(transaction, fooValue) {
>> > transaction.writeValue("foo", ++fooValue);
>> > })
>> > })
>> > to fetch multiple values, you could do this:
>> > var values = [];
>> > var numValues = 10;
>> > function readNextValue(transaction) {
>> > if (values.length == numValues)
>> >return; // done!
>> > var index = values.length;
>> > transaction.readValue("value" + index, function(transaction,
>> value) {
>> > values.push(value);
>> > readNextValue(transaction);
>> > })
>> > }
>> > window.localStorage.transaction("slice", readNextValue);
>> > This has the property that all IO is non-blocking and the "lock" is
>> held
>> > only
>> > for a very limited scope. The programmer is however free to extend
>> the
>> > life of the lock as needed.
>>
>> What do you mean by that the "lock" is held for only a very limited
>> scope? You still want to prevent modifications for as long as the
>> transaction is being used right? I.e. no modifications can happen
>> between the read and the write in the first example, and between the
>> different reads in the second.
>>
>
> Yes. I only meant that the programmer doesn't have to call a special
> function to close the transaction. It closes by virtue of the last
> handleEvent
> call referring to the transaction returning.
>
So wouldn't you implement this transaction using a lock? To prevent
other pages from accessing the localStorage?
>>> Yes, but it wouldn't need to be a normal mutex if that's what you mean.
>>> You could just defer callbacks until the transaction completes. It is
>>> purely asynchronous locking.
>>>
>>
>> So how is that then different from from using a Storage API, but only
>> letting you get a reference to the Storage object using a asynchronous API?
>> And of course not allowing the Storage object to be stored in a variable and
>> used outside the callback.
>>
>
> The difference is that storage IO is fully asynchronous in the API I
> proposed. It doesn't have to block the calling thread for reads. I think
> that is important.
>
> We should never design any APIs that involve synchronous IO (filesystem or
> network) from the main UI thread.
>
Ah, that's a different problem from what I thought you talked about
initially.
I wasn't part of the initial design-phase of this API. But as I understand
it, the idea was that it's expected that people will store small enough
amounts of information in localStorage that the database can be kept in
memory. Behind the scenes you can always write to disc asynchronously in
order to reduce risk of dataloss in case of crash.
I'm not sure if this is practical or not. I suspect that many times it won't
be. However even here a asynchronous getter would help since you can read in
the full database in
