Re: [whatwg] Canvas: clarification of compositing operations needed

2010-07-29 Thread Leonardo Dutra
People have a very strong feeling about Firefox. This is beautiful, but not
good to it. Firefox is now, over the Windows 7 and Mac, the slowest browser.
Just pick some JavaScripts and test. XUL is the most hard way for builting
an extension and Firefox eats CPU when we run any game built using HTML
Elements.

But this is not the point.

***Composite **A** within the clipping region over the current canvas
bitmap using the current composition operator.*
*
*
The word clipping is the point. I am very sad that input type=color does
not cite the need of a color picker. But This part, is completely bright.

That's why Microsoft agree with Chrome, Chrome with Safari (they don't agree
sometimes) and Opera presents that way too.

A hug.

2010/7/29 David Flanagan da...@davidflanagan.com

 James Robinson wrote:

 On Wed, Jul 28, 2010 at 2:46 PM, Tab Atkins Jr. jackalm...@gmail.commailto:
 jackalm...@gmail.com wrote:

On Wed, Jul 28, 2010 at 2:43 PM, David Flanagan
da...@davidflanagan.com mailto:da...@davidflanagan.com wrote:
  Firefox and Chrome disagree about the implementation of the
  destination-atop, source-in, destination-in, and source-out
compositing
  operators.  Test code is attached.


 I don't think your attachment made it through.
 https://developer.mozilla.org/samples/canvas-tutorial/6_1_canvas_composite.htmlshows
  some of the differences, although it does not cover all cases.


 You didn't miss much.  My example was very similar to the one you link to.



 The spec is certainly clear but that does not make the behavior it
 specifies good.  I find the spec's behavior pretty bizarre and Microsoft has
 expressed a preference for the Safari/Chrome interpretation:
 http://lists.w3.org/Archives/Public/public-canvas-api/2010AprJun/0046.html- 
 although that thread did not get much discussion.


 Thanks for that link.  The thread you reference refers back to an earlier
 thread on this list.  My apologies for not finding it and reading it before
 posting again.


 For example, I think

 drawing a 20x20 image into a 500x500 canvas without scaling with a
 globalCompositeOperation of 'copy' should result in only the 20x20 region
 being cleared out, not the entire canvas.


 Yikes!  It hadn't occurred to me that copy should behave that way.  But
 you're right that that is what the spec requires.  Opera does it that way.
  Firefox, thankfully, does not.

 Perhaps independently of the debate over infinite bitmap vs. shape extents,
 we can agree that copy is a special value that means do not perform
 compositing

David



[whatwg] HTML5 Input (Color)

2010-07-28 Thread Leonardo Dutra
Em 28 de julho de 2010 18:05, Tab Atkins Jr. jackalm...@gmail.com
 escreveu:

 2010/7/28 Leo Dutra ™ leodutra...@gmail.com:
  Hello, everyone.
  I were asking myself about HTML5 input with type color. I'm a
 brazillian
  developer and I see a huge problem with the new input type. The problem
 is
  that RGB color names are expected to be written in English. This is not a
  good, or even, usability.

 There is no official list of localizations of the standard sets of
 colors.  It kind of sucks for people for whom English isn't their
 first language, but nearly all programming languages are based on
 English.

 Further, once you start giving aliases for some languages, it becomes
 hard to justify not giving aliases in *every* language.  This isn't
 very sustainable.


Yes, nearly all programming langs were written and based on English. But
this is not a development tool, IDE or language... it's the presentation to
the non-dev user, and it should be easy and independant of language. Don't
stuck the usability of the *World Wide Web* in some few countries that has
English speaking users, or it'll not take advance.


  I'd like input type=color to work for any
  language without porting acrobatics. So I have a new idea.
  What about a color picker, and no more langs? ARGB or RGBA (with option
 to
  restrict to RGB, maybe other restriction patterns). It's independent of
  language, easy to implement and much more usable. Social themes, HTML5
 slide
  sites, RIAs, and all. Imagine the power of picking any color natively and
  send a 0xff00ff00ff to the server.
  It's still draft, and time to don't twist the web again.

 input type=color is *supposed* to expose a color picker.  That was
 its entire point, actually.  Webkit-based browsers don't do it right
 now, and just expose the validation part, where it requires a valid
 color.  Just wait a bit for the browsers to finish up their forms
 support, and you'll see a proper color picker there, completely
 language-independent.


The  http://goog_1610816/input http://goog_1610816/ element represents a
color well control, for setting the element's value to a string representing
a simple color. - HTML5
Drafthttp://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#color-state
What does String means?


 (Also, btw, input type=color will only allow selecting RGB colors.
 If you want the A, you have to handle it yourself, perhaps with an
 input type=range.)


I think implementing a input type=color value=0xff00ff00ff / or input
type=color value=255,255,255,1 / or similar it's better than a internal
list.
The Universe has infinite colors. Human can see from red to violet. And now,
with rgb names, less. RGB names it's a bad way of picking colors.
I say we MUST have a color picker and a date picker (calendar). It's not
hard and carries much more freedom for development and usability.

Think again.
A hug for you all.