From odinho at opera.com  Fri Feb  1 02:19:32 2013
From: odinho at opera.com (=?utf-8?Q?Odin_H=C3=B8rthe_Omdal?=)
Date: Fri, 01 Feb 2013 11:19:32 +0100
Subject: [whatwg] IRC and WWW integration proposal
In-Reply-To: <20130201074159.4079f494@desudesudesu>
References: <20130201142600.dea98ee7b58e2637550be2c4@gmail.com>
	<20130201052458.269aac46@desudesudesu>
	<20130201150126.16a706397a491368142a8815@gmail.com>
	<20130201055511.332ca0b8@desudesudesu>
	<CAKDHDYn5NREvNDZRdNFOnu4NeYdF73fnoW2Sr9-3ZQHw2Qra0Q@mail.gmail.com>
	<20130201074159.4079f494@desudesudesu>
Message-ID: <op.wrtoaujr49xobu@odinho-fido>

On Fri, 01 Feb 2013 07:41:59 +0100, Nils Dagsson Moskopp  
<nils at dieweltistgarnichtso.net> wrote:

> Shane Allen <shane at snoonet.org> schrieb am Thu, 31 Jan 2013 23:40:11
> -0600:
>
>> > A protocol attribute for <link> elements would be totally hilarious.
>> Not if the device is a tablet, or a phone running a browser that
>> supports it. Need support from a page/article or even a project? Hit
>> a button, and if the protocol is implemented, you're in the IRC
>> channel able to garnish that support instantly.
> We probably misunderstood each other. Protocols are mentioned at the
> beginning of a URL; having a protocol attribute on a <link> element
> would therefore be redundant.

To illustrate:

   <link rel=chat protocol=irc href=irc://irc.freenode.com/whatwg>

Instead of:

   <link rel=chat href=irc://irc.freenode.com/whatwg>

Or a more fitting example of how it could be used:

   <a href="http://whatwg.org" protocol="http">WHATWG</a>

But, what happens now?

   <a href="http://whatwg.org" protocol="mailto">WHATWG</a>



Hilarious :-)

-- 
Odin H?rthe Omdal (Velmont/odinho) ? Core, Opera Software, http://opera.com

From glenn at zewt.org  Fri Feb  1 07:39:53 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 1 Feb 2013 09:39:53 -0600
Subject: [whatwg] Why do we have <input type='month'> and <input
	type='week'>?
In-Reply-To: <op.wrry8kurh8on37@bruce-pc>
References: <510988C1.1040900@lamouri.fr>
	<op.wrry8kurh8on37@bruce-pc>
Message-ID: <CABirCh_ua8cumCqZcASOTOdwCmsi0yPdVYvoRT23eBstszdy2A@mail.gmail.com>

On Thu, Jan 31, 2013 at 6:20 AM, Bruce Lawson <brucel at opera.com> wrote:

> The use-case for an input type I imagine is that a browser can have a
> select-like UI (Jan, Feb, March, April ...) which, in a French language
> browser becomes "Janvier, Fevrier, Mars, Avril .. " (or even Vend?miaire to
> Fructidor for FRC fans).
>

FYI, I would find this annoying.  CC expiry entry forms are typically
select boxes containing 01-12.  The text lines up with what's on my credit
card, so I don't have to translate "07" to "July" in my head when entering
it off of my card.  Any month picker for credit card expiry dates should
always have month numbers (of course, names *in addition* to numbers are
fine, though probably pointless).

-- 
Glenn Maynard

From mkwst at google.com  Sat Feb  2 10:11:23 2013
From: mkwst at google.com (Mike West)
Date: Sat, 2 Feb 2013 19:11:23 +0100
Subject: [whatwg] Sandboxed IFrames and downloads.
Message-ID: <CAKXHy=eHTuTehhaAsFdumu-Rr1sgJZfRMGKOfnYUKcEV+T3gSw@mail.gmail.com>

It's currently possible to force a download by serving a file with a
"Content-Disposition: attachment; filename=..." header. Notably, this
mechanism can be used to download a file with minimal user interaction by
including the resource to be downloaded in an IFrame. This holds even for
sandboxed IFrames, as demonstrated by
http://lcamtuf.coredump.cx/sandboxed.html (clicking that link will download
a file, fair warning).

It seems consistent with the general thought behind the `sandbox` attribute
that it should control downloads as well as the bits it already locks down.
I'd propose adjusting the spec to include a sandboxed downloads flag,
which, when present, would block all downloads from inside the frame (or,
perhaps only require user confirmation?). This restriction could be lifted
via an 'allow-downloads' keyword, if present in the sandbox attribute's
token list.

WDYT?

--
Mike West <mkwst at google.com>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 M?nchen, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

From nathan.f77 at gmail.com  Mon Feb  4 14:09:07 2013
From: nathan.f77 at gmail.com (Nathan Broadbent)
Date: Tue, 5 Feb 2013 11:09:07 +1300
Subject: [whatwg] Proposal: Add window.getLastError (or modify invocation
 arguments of window.onerror)
Message-ID: <CAPXHQbNKO46DaDKamu=n5Z=ieYjVELxTcSZAJ1wDGdwBbGFzEA@mail.gmail.com>

Hi,

The current information passed to window.onerror rarely provides
sufficient information to find the cause of the error. The column
number argument will be a big step forward, but a stack trace would be
especially useful. I would like to add my support for improving the
window.onerror arguments, with a fifth argument for stack trace. Is
there anything that James or I could do to move this discussion along?


Best,
Nathan


> Alright... so what's next?  I'm assuming this needs further discussion with
> other WHATWG members chiming in.  If I can help, please let me know. I'd
> like to see this request through.
> Sincerely,
>     James Greene

On Fri, May 11, 2012 at 12:26 PM, Simon Pieters <simonp at opera.com> wrote:
> On Fri, 11 May 2012 17:14:00 +0200, James Greene <james.m.greene at gmail.com>
> wrote:
>
>  Simon:
>> Yeah, I misunderstood your previous mention of having it as a [fifth]
>> string argument.  I somehow associated that automatically with the
>> "message" parameter (the only string argument, I suppose) but I also
>> noticed my mistake after I sent the email.
>>
>
> OK.
>
>
>  I personally am interested in adding the stack trace, yes,
>>
>
> OK, thanks.
>
>
>  but ideally I
>> would just have access to the full "Error" object so I can always have an
>> up-to-date model if the "Error" object continues to change (as it probably
>> will).
>>
>
> That's fair enough. Though not all exceptions are Errors -- DOMException
> currently isn't, though I think some people want it to somehow inherit from
> Error.
>
>
>  For example, some devs may be interested in the "Error" object's
>> "name" property, which is already a part of the object today but is not
>> provided to "window.onerror" callbacks.  And again, if additional
>> properties are added in the future, it's just more and more properties
>> that
>> may need to get incrementally added to the "window.onerror" invocation
>> arguments list.  For example, I proposed the addition of an "innerError"
>> property (or some would call it "cause") for chaining errors and masking
>> internal errors that consumers shouldn't see, instead providing a
>> customer-facing message.
>>
>
> Yeah.
>
>
>  You keep mentioning compile errors and how they don't have associated
>> "Error" objects but it sounds like they still reach the "window.onerror"
>> callbacks.  Can you add a little commentary on that?
>>
>
> Here are some examples:
>
> <script> onerror = function(a,b,c) { alert(a+b+c) }; </script>
> <script> foo(); </script> <!-- "runtime" error; uncaught exception -->
> <script> for (;) </script> <!-- "compile" error; no exception, but onerror
> is invoked -->
> <script> setTimeout('for (;)', 0); </script> <!-- also compile error -->
> <img src="" onerror="for(;)"> <!-- also compile error -->
>
>
>
>  I thought they
>> utilized the "SyntaxError" class but perhaps that's only for "eval()"
>> calls...?
>>
>
> Yes. Since the script doesn't compile, the same script can't catch any
> exception in a try/catch block. onerror is just invoked with the
> appropriate arguments, and currently doesn't expose any object. Hence,
> compile errors currently do not expose any exception that Web pages can
> observe. However, if we change onerror and expose the exception object for
> uncaught exceptions, it would certainly make sense to specify that compile
> errors be exposed using SyntaxError exceptions.
>
> If we expose the exception object in onerror (which I actually think makes
> sense), what do we want to happen for cross-origin script errors? null? The
> current arguments are masked as ("Script error.", "", 0, 0).
>
>
>  I may also be thinking of this differently as a JS engineer
>> versus a browser vendor, so please help clue me in.  I'm interested to
>> learn more on this, and it may help me better appreciate why the
>> "window.onerror" callback mechanism *didn't* just pass an "Error" object
>> from the beginning.
>>
>
> I think onerror is an old feature dating back from old Netscape or IE
> (don't know which). Then other browsers just copied it.
>
>
>  I appreciate your continued feedback. Thanks!
>>
>
> cheers
>
> --
> Simon Pieters
> Opera Software
>

From dhtmlkitchen at gmail.com  Mon Feb  4 14:40:51 2013
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 4 Feb 2013 14:40:51 -0800
Subject: [whatwg] Proposal: Add window.getLastError (or modify
 invocation arguments of window.onerror)
In-Reply-To: <CAPXHQbNKO46DaDKamu=n5Z=ieYjVELxTcSZAJ1wDGdwBbGFzEA@mail.gmail.com>
References: <CAPXHQbNKO46DaDKamu=n5Z=ieYjVELxTcSZAJ1wDGdwBbGFzEA@mail.gmail.com>
Message-ID: <CABZUbM1CgRW_O=gZ_uPGuoGgqiwEqF8hwUB-g+XF32ocVSZXGQ@mail.gmail.com>

On 2/4/13, Nathan Broadbent <nathan.f77 at gmail.com> wrote:
> Hi,
>
Hi Nathan -

> The current information passed to window.onerror rarely provides
> sufficient information to find the cause of the error. The column
That's putting it mildly.

> number argument will be a big step forward, but a stack trace would be
> especially useful. I would like to add my support for improving the
> window.onerror arguments, with a fifth argument for stack trace. Is
> there anything that James or I could do to move this discussion along?

I'm not married to the idea of having it be stuck onto window.onerror.
There should be some way to get at the stack trace.

[whatwg] window.onerror -ancient feature needs upgrade
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-September/012552.html

| There needs to be a way to capture errors on the window.
|
| A method that passes an Error to the handler. One possible solution
| would be to leverage the existing event system:
|
| addEventListener( "error", genericErrorEventHandler, false );
|
| function genericErrorEventHandler( errorEvent ) {
| };

There's a number of bugs for global error stack info.

Bug 355430 - Stack information of uncaught Error object should be
available in window.onerror
https://bugzilla.mozilla.org/show_bug.cgi?id=355430

Bug 104408 - Summary: Add exception object and stack trace to window.onerror
https://bugs.webkit.org/show_bug.cgi?id=104408

| "The spec explicitly states that onerror gives you the
| error string, url, and line number.  We can't arbitrarily
| extends a spec as we see fit."

Bug 55092 - Stack information of uncaught Error object should be
available in window.onerror
https://bugs.webkit.org/show_bug.cgi?id=55092
"Is there anything else blocking this?"

https://bugs.webkit.org/show_bug.cgi?id=13646
(Apparently I "duplicated" that bug before the original, which came
four years later O_o (or "search first!")).


[...]

>>  but ideally I
>>> would just have access to the full "Error" object so I can always have
>>> an
>>> up-to-date model if the "Error" object continues to change (as it
>>> probably
>>> will).
>>>
I agree.

>>
>> That's fair enough. Though not all exceptions are Errors -- DOMException
>> currently isn't, though I think some people want it to somehow inherit
>> from
>> Error.
>>
Why not?

>>
>>  For example, some devs may be interested in the "Error" object's
>>> "name" property, which is already a part of the object today but is not
>>> provided to "window.onerror" callbacks.  And again, if additional
>>> properties are added in the future, it's just more and more properties
>>> that
>>> may need to get incrementally added to the "window.onerror" invocation
>>> arguments list.  For example, I proposed the addition of an "innerError"
>>> property (or some would call it "cause") for chaining errors and masking
>>> internal errors that consumers shouldn't see, instead providing a
>>> customer-facing message.
>>>
>>
>> Yeah.
>>
Yep. Pass an error object with a stack trace.



>>
>> Yes. Since the script doesn't compile, the same script can't catch any
>> exception in a try/catch block. onerror is just invoked with the
>> appropriate arguments, and currently doesn't expose any object. Hence,
>> compile errors currently do not expose any exception that Web pages can
>> observe. However, if we change onerror and expose the exception object
>> for
>> uncaught exceptions, it would certainly make sense to specify that
>> compile
>> errors be exposed using SyntaxError exceptions.
>>
Early errors?
www.ecma-international.org/ecma-262/5.1/#sec-16
-- 
Garrett
Twitter: @xkit
personx.tumblr.com

From oliver at apple.com  Mon Feb  4 14:44:37 2013
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 04 Feb 2013 14:44:37 -0800
Subject: [whatwg] Proposal: Add window.getLastError (or modify
 invocation arguments of window.onerror)
In-Reply-To: <CABZUbM1CgRW_O=gZ_uPGuoGgqiwEqF8hwUB-g+XF32ocVSZXGQ@mail.gmail.com>
References: <CAPXHQbNKO46DaDKamu=n5Z=ieYjVELxTcSZAJ1wDGdwBbGFzEA@mail.gmail.com>
	<CABZUbM1CgRW_O=gZ_uPGuoGgqiwEqF8hwUB-g+XF32ocVSZXGQ@mail.gmail.com>
Message-ID: <2A18872E-7F61-4470-A887-00CFEE9196AF@apple.com>


On Feb 4, 2013, at 2:40 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
>>> That's fair enough. Though not all exceptions are Errors -- DOMException
>>> currently isn't, though I think some people want it to somehow inherit
>>> from
>>> Error.
>>> 
> Why not?

That's something lost in the mists of time, however just asking it w.r.t DOMException misses the point that any value in js can be thrown - there's no requirement that it be an object, let alone a subtype of Error.

> 
>>> 
>>> For example, some devs may be interested in the "Error" object's
>>>> "name" property, which is already a part of the object today but is not
>>>> provided to "window.onerror" callbacks.  And again, if additional
>>>> properties are added in the future, it's just more and more properties
>>>> that
>>>> may need to get incrementally added to the "window.onerror" invocation
>>>> arguments list.  For example, I proposed the addition of an "innerError"
>>>> property (or some would call it "cause") for chaining errors and masking
>>>> internal errors that consumers shouldn't see, instead providing a
>>>> customer-facing message.
>>>> 
>>> 
>>> Yeah.
>>> 
> Yep. Pass an error object with a stack trace.

That's tricky - what is your "stack trace"?  You can very easily end up leaking private information across frames.

--Oliver

From esprehn at chromium.org  Mon Feb  4 23:20:27 2013
From: esprehn at chromium.org (Elliott Sprehn)
Date: Tue, 5 Feb 2013 02:20:27 -0500
Subject: [whatwg] Proposal: Add window.getLastError (or modify
 invocation arguments of window.onerror)
In-Reply-To: <2A18872E-7F61-4470-A887-00CFEE9196AF@apple.com>
References: <CAPXHQbNKO46DaDKamu=n5Z=ieYjVELxTcSZAJ1wDGdwBbGFzEA@mail.gmail.com>
	<CABZUbM1CgRW_O=gZ_uPGuoGgqiwEqF8hwUB-g+XF32ocVSZXGQ@mail.gmail.com>
	<2A18872E-7F61-4470-A887-00CFEE9196AF@apple.com>
Message-ID: <CAO9Q3iK0uq6yGjLLMfnpWSZnKpr+2scAbbSKcp3Our031on_+g@mail.gmail.com>

On Mon, Feb 4, 2013 at 5:44 PM, Oliver Hunt <oliver at apple.com> wrote:

> ...
> That's tricky - what is your "stack trace"?  You can very easily end up
> leaking private information across frames.
>
>
window.onerror is triggered across non-same origin frames?

- E

From cam at mcc.id.au  Tue Feb  5 22:41:04 2013
From: cam at mcc.id.au (Cameron McCormack)
Date: Wed, 06 Feb 2013 17:41:04 +1100
Subject: [whatwg] supporting HTMLElement.dataset on SVG elements
Message-ID: <5111FB00.6000907@mcc.id.au>

As part of aligning SVG with some not-so-HTML-specific features of HTML, 
the SVG WG would like to support data-* attributes on SVG elements.  In 
mixed HTML/SVG documents, it seems like you would want to be able to use 
these attributes regardless of whether the elements are HTML or SVG, or 
indeed MathML.

Does it make sense to move HTMLElement.dataset up to Element, so that 
all elements can benefit from it?  If not, could this attribute be split 
out on to a separate interface that we could have SVGElement implement?

(I'm also going to be looking at the other global attributes that HTML 
elements have to see if any make sense in SVG too.)

Thanks,

Cameron

From wang.tietao at outlook.com  Tue Feb  5 22:45:53 2013
From: wang.tietao at outlook.com (=?gb2312?B?zfXM+szX?=)
Date: Wed, 6 Feb 2013 14:45:53 +0800
Subject: [whatwg] A question about the drawimage() canvas function
Message-ID: <BLU002-W472F6B1FD8225099BAFE56EF070@phx.gbl>

Hi, there:
This is about the drawimage() canvas function in html5.
What should the following code ouput?
///////////////<html> <head>  <title>drawImage with an incorrect type for the image argument (part two)</title>  <style> canvas { display:none } </style>  <script>   window.onload = function(){    var r = document.getElementById('r');    ctx = document.getElementsByTagName('canvas')[0].getContext('2d');    var passed = false;    var message = "";    try{     ctx.drawImage((new Image()), 0, 0, 150, 150);     message = "No exception thrown"    }catch(e){      passed = e.code === e.INDEX_SIZE_ERR;      if (!passed) {message = "Got exception code " + e.code + " expected 1 (INDEX_SIZE_ERR)"}    }    r.textContent = passed ? "PASS" : "FAIL";    if (message) {r.textContent += " (" + message + ")"}   }  </script> </head> <body>  <p id="r">FAIL (Script did not run.)</p>  <canvas></canvas> </body></html>///////////////
In Chrome(24.0.1312.57) and Firefox(18.0.1), the output is:PASS
while in Opera(12.12) and IE(10.0.9200.16439) it is:FAIL (No exception thrown)

So, what should the result be? and what is the standard for this?
Thanks,-Tietao Wang 		 	   		  

From davidc at nag.co.uk  Wed Feb  6 02:56:43 2013
From: davidc at nag.co.uk (David Carlisle)
Date: Wed, 06 Feb 2013 10:56:43 +0000
Subject: [whatwg] supporting HTMLElement.dataset on SVG elements
In-Reply-To: <5111FB00.6000907@mcc.id.au>
References: <5111FB00.6000907@mcc.id.au>
Message-ID: <511236EB.8060304@nag.co.uk>

On 06/02/2013 06:41, Cameron McCormack wrote:
> As part of aligning SVG with some not-so-HTML-specific features of
> HTML, the SVG WG would like to support data-* attributes on SVG
> elements.  In mixed HTML/SVG documents, it seems like you would want
> to be able to use these attributes regardless of whether the elements
> are HTML or SVG, or indeed MathML.
>
> Does it make sense to move HTMLElement.dataset up to Element, so that
>  all elements can benefit from it?  If not, could this attribute be
> split out on to a separate interface that we could have SVGElement
> implement?
>
> (I'm also going to be looking at the other global attributes that
> HTML elements have to see if any make sense in SVG too.)
>
> Thanks,
>
> Cameron
>

I'm also in favour of making any reasonable global feature act the same
way across html/mathml/svg (hence the earlier request to move innerHTML
and friends up to Element so they apply to MathML).

David


________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________

From annevk at annevk.nl  Wed Feb  6 10:25:59 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Wed, 6 Feb 2013 18:25:59 +0000
Subject: [whatwg] supporting HTMLElement.dataset on SVG elements
In-Reply-To: <5111FB00.6000907@mcc.id.au>
References: <5111FB00.6000907@mcc.id.au>
Message-ID: <CADnb78hU_16CakFXh=zWJxz4i_mx5wC708dMEqk81Bq2JKAWVA@mail.gmail.com>

On Wed, Feb 6, 2013 at 6:41 AM, Cameron McCormack <cam at mcc.id.au> wrote:
> Does it make sense to move HTMLElement.dataset up to Element, so that all
> elements can benefit from it?  If not, could this attribute be split out on
> to a separate interface that we could have SVGElement implement?

Idea: just like the long term goal is to merge HTMLDocument into
Document (already done spec-wise), maybe the long term goal for
HTMLElement should be to become Element? This poops a bit on XML, but
certainly less than <template>.


-- 
http://annevankesteren.nl/

From dhtmlkitchen at gmail.com  Wed Feb  6 11:18:00 2013
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Wed, 6 Feb 2013 11:18:00 -0800
Subject: [whatwg] supporting HTMLElement.dataset on SVG elements
In-Reply-To: <5111FB00.6000907@mcc.id.au>
References: <5111FB00.6000907@mcc.id.au>
Message-ID: <CABZUbM3DhSsXNw+_Mvf-AexM8YjyexHsXMCJ9ht9O6SnQu_qaQ@mail.gmail.com>

On 2/5/13, Cameron McCormack <cam at mcc.id.au> wrote:
> As part of aligning SVG with some not-so-HTML-specific features of HTML,
> the SVG WG would like to support data-* attributes on SVG elements.  In
> mixed HTML/SVG documents, it seems like you would want to be able to use
> these attributes regardless of whether the elements are HTML or SVG, or
> indeed MathML.
>
> Does it make sense to move HTMLElement.dataset up to Element, so that
> all elements can benefit from it?  If not, could this attribute be split
> out on to a separate interface that we could have SVGElement implement?
>
What is the cost of extracting a common interface?

Are there any cases, existing or potential, where global attributes
might create conflict or make no sense?
http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#global-attributes

HTMLUnknownElement looks like it wants to fill the role of common
interface, but due to class hierarchy, it can't.
http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#htmlunknownelement

| interface must be used for HTML elements that are not
| defined by this specification (or other applicable specifications).

a new interface, such as UnknownElement or GenericElement could
accommodate shared features and avoid potential situations where those
features wouldn't make sense on a common Element superclass.
GenericElement could be implemented by HTMLElement and SVGElement and
all subclasses thereof including HTMLUnknownElement, plus whatever
they use in Math ML and whoever else wants to inherit from
GenericElement.
-- 
Garrett
Twitter: @xkit
personx.tumblr.com

From julian.viereck at googlemail.com  Thu Feb  7 00:38:09 2013
From: julian.viereck at googlemail.com (Julian Viereck)
Date: Thu, 07 Feb 2013 09:38:09 +0100
Subject: [whatwg] Proposal: HTMLCanvasElement.printCallback API
In-Reply-To: <CAPJYB1hfmBgULy=3=1EGWfQpTdPqUPe=CHQtgfKieiCtVDU=GQ@mail.gmail.com>
References: <76AFD13D-458E-4ADC-AE90-DFC7D4642A31@gmail.com>
	<51004407.10007@gmail.com>
	<CAPJYB1hfmBgULy=3=1EGWfQpTdPqUPe=CHQtgfKieiCtVDU=GQ@mail.gmail.com>
Message-ID: <511367F1.5080602@gmail.com>

On 1/28/13 6:25 AM, Elliott Sprehn wrote:
> 1) I feel like this should probably be an event. I don't know why 
> we're inventing new callback facilities everywhere.
>
> canvas.onprintcanvas = function(e) { e.printState ... }

Not sure I get what you're trying to say. Do you want the function to be 
an event, such that you can do

   canvas.addEventListener('printCallback', function(e) { ...} )

or just rename the `canvas.printCallback` to `canvas.onprintcallback`?

A event might be dispatched to multiple listeners. In the scenario with 
the print callback it makes only sense to have one function that defines 
the look of the canvas during printing. Therefore I've choosen to not 
use the event-listener pattern but instead a single callback function.

> 2) What does "send the canvas' content without rasterization to the 
> printer" mean? How are blending and overlapping images handled? Your 
> current description makes it sound like if I did two drawImage() calls 
> it would make my printer print the images on top of each other.
The drawing is done exactly the same as you expect it to show up on the 
screen including blending and overlapping.

Here is an example using the canvas.printCallback API. It draws shapes 
over each other:
- test html page: 
https://bug745025.bugzilla.mozilla.org/attachment.cgi?id=625810
- output: 
https://docs.google.com/file/d/0B4VOqqwjYRMLS05JNVZpZWt3MG8/edit?usp=sharing

Is this clear or does it need more clearification?

Very best,

Julian

From annevk at annevk.nl  Thu Feb  7 05:13:45 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Thu, 7 Feb 2013 13:13:45 +0000
Subject: [whatwg] DOMError not constructable
In-Reply-To: <CANr5HFVAz4QcOoimM+v7THBx6Hyoa0Ys9vMitMCYTTs_-LF6jA@mail.gmail.com>
References: <CANr5HFVAz4QcOoimM+v7THBx6Hyoa0Ys9vMitMCYTTs_-LF6jA@mail.gmail.com>
Message-ID: <CADnb78hv7WjZTH9zAkwQB0+ACgtKAkZVKh=awD5LDzrc6c6AjA@mail.gmail.com>

On Thu, Jan 17, 2013 at 2:02 PM, Alex Russell <slightlyoff at google.com> wrote:
> It appears that WebIDL-ese has afflicted DOMError and DOMException:
> http://dom.spec.whatwg.org/#interface-domerror
>
> These should be constructable, with a single "name" DOMStrong parameter or
> an argument bag which allows setting of the name property.

DOMError:

https://github.com/whatwg/dom/commit/3f5761ef179f6784dc08c6955c5673db7552fa6e

DOMException:

http://lists.w3.org/Archives/Public/public-script-coord/2013JanMar/0049.html

(I took so long to reply because I was waiting for heycam to reply to
the above, but I thought I might as well move ahead with DOMError for
now.)

Thanks!


-- 
http://annevankesteren.nl/

From neerja at kynex.com  Thu Feb  7 06:47:12 2013
From: neerja at kynex.com (Neerja Anand)
Date: Thu, 7 Feb 2013 09:47:12 -0500
Subject: [whatwg] XML data islands related question
Message-ID: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>

Hello - it appears that XML data islands (originally created by Microsoft)
have been discontinued in the newer browsers. We wanted to request they
could be supported as an addon/plugin into the browser if not incorporated
into the browser by default. We understand that this was a Microsoft only
feature but they are extremely helpful to our business and their
discontinuation would highly affect our business. Our request is to make
them as an HTML5 standard, so all browsers would then have to support this
feature. This would make the life of us developers much easier. We are not
asking for Microsoft's version of XML data islands specifically, but would
want this feature as a standard in some version. We noticed there is
something new called Data Block which may be similar to XML data islands,
but couldn't find much information on it to proceed. If you know of Data
Blocks being an alternative to XML data islands, then if you could provide
some documentation or point us to the location where we can get more
information (with examples on how to use them) that would be very helpful as
well.

 

Any feedback on this would be appreciated.

 

Thanks very much in advance!

 

Neerja Anand

neerja at kynex.com

 


From slightlyoff at google.com  Thu Feb  7 06:47:54 2013
From: slightlyoff at google.com (Alex Russell)
Date: Thu, 7 Feb 2013 06:47:54 -0800
Subject: [whatwg] DOMError not constructable
In-Reply-To: <CADnb78hv7WjZTH9zAkwQB0+ACgtKAkZVKh=awD5LDzrc6c6AjA@mail.gmail.com>
References: <CANr5HFVAz4QcOoimM+v7THBx6Hyoa0Ys9vMitMCYTTs_-LF6jA@mail.gmail.com>
	<CADnb78hv7WjZTH9zAkwQB0+ACgtKAkZVKh=awD5LDzrc6c6AjA@mail.gmail.com>
Message-ID: <CANr5HFUJ_ORkNx9Pdx6khZmabRSsFWr-Sw5MHsZzcw7GLgR+mQ@mail.gmail.com>

LGTM++

On Thursday, February 7, 2013, Anne van Kesteren wrote:

> On Thu, Jan 17, 2013 at 2:02 PM, Alex Russell <slightlyoff at google.com<javascript:;>>
> wrote:
> > It appears that WebIDL-ese has afflicted DOMError and DOMException:
> > http://dom.spec.whatwg.org/#interface-domerror
> >
> > These should be constructable, with a single "name" DOMStrong parameter
> or
> > an argument bag which allows setting of the name property.
>
> DOMError:
>
>
> https://github.com/whatwg/dom/commit/3f5761ef179f6784dc08c6955c5673db7552fa6e
>
> DOMException:
>
>
> http://lists.w3.org/Archives/Public/public-script-coord/2013JanMar/0049.html
>
> (I took so long to reply because I was waiting for heycam to reply to
> the above, but I thought I might as well move ahead with DOMError for
> now.)
>
> Thanks!
>
>
> --
> http://annevankesteren.nl/
>

From mat at matcarey.co.uk  Thu Feb  7 06:58:48 2013
From: mat at matcarey.co.uk (Mat Carey)
Date: Thu, 7 Feb 2013 14:58:48 +0000
Subject: [whatwg] XML data islands related question
In-Reply-To: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
References: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
Message-ID: <CAN7jg5O8cqOeUqaWpg8+2hPS26xW=xGO_Cos6BG1KfmDP1mLpg@mail.gmail.com>

I've been thinking about this too...

> We wanted to request they could be supported as an addon/plugin into the
browser if not incorporated into the browser by default

I came to the conclusion that if I care enough I should write a browser
plugin having reverse engineered the data island spec which would allow
people with my plugin to use these sites, then bring this to WHATWG to
suggest wider adoption.

I'm not particularly active on WHATWG but the general approach seems to be
that if you have a good idea you should go and create it, show that it
works and then bring it to WHATWG for a wider adoption.

My advice would be to have a look and see if anyone's already started a
project to reverse engineer this, if they have join it, if they haven't
start it.

I decided previously that I don't care enough to do this work myself, if
there's someone else working towards this I might be willing to help in an
open source project and I'm sure there's others who would do the same.

I could be wrong - if I am I'm sure someone will correct me.

Mat Carey


On Thu, Feb 7, 2013 at 2:47 PM, Neerja Anand <neerja at kynex.com> wrote:

> Hello - it appears that XML data islands (originally created by Microsoft)
> have been discontinued in the newer browsers. We wanted to request they
> could be supported as an addon/plugin into the browser if not incorporated
> into the browser by default. We understand that this was a Microsoft only
> feature but they are extremely helpful to our business and their
> discontinuation would highly affect our business. Our request is to make
> them as an HTML5 standard, so all browsers would then have to support this
> feature. This would make the life of us developers much easier. We are not
> asking for Microsoft's version of XML data islands specifically, but would
> want this feature as a standard in some version. We noticed there is
> something new called Data Block which may be similar to XML data islands,
> but couldn't find much information on it to proceed. If you know of Data
> Blocks being an alternative to XML data islands, then if you could provide
> some documentation or point us to the location where we can get more
> information (with examples on how to use them) that would be very helpful
> as
> well.
>
>
>
> Any feedback on this would be appreciated.
>
>
>
> Thanks very much in advance!
>
>
>
> Neerja Anand
>
> neerja at kynex.com
>
>
>
>


-- 
Web Developer & Consultant
mat at matcarey.co.uk
www.matcarey.co.uk
07952258096

From Randy at ProWebDesign.nl  Thu Feb  7 07:55:42 2013
From: Randy at ProWebDesign.nl (Randy)
Date: Thu, 7 Feb 2013 16:55:42 +0100
Subject: [whatwg] XML data islands related question
In-Reply-To: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
References: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
Message-ID: <C77B8029-E9B2-4722-ABF1-9A1C3F88DEE6@ProWebDesign.nl>

As far as I'm aware, Data Blocks should be or is part of HTML5. See https://developer.mozilla.org/en/docs/Using_XML_Data_Islands_in_Mozilla for more info. 

HTH

Sent from your iPhone

On 7 feb. 2013, at 15:47, "Neerja Anand" <neerja at kynex.com> wrote:

> Hello - it appears that XML data islands (originally created by Microsoft)
> have been discontinued in the newer browsers. We wanted to request they
> could be supported as an addon/plugin into the browser if not incorporated
> into the browser by default. We understand that this was a Microsoft only
> feature but they are extremely helpful to our business and their
> discontinuation would highly affect our business. Our request is to make
> them as an HTML5 standard, so all browsers would then have to support this
> feature. This would make the life of us developers much easier. We are not
> asking for Microsoft's version of XML data islands specifically, but would
> want this feature as a standard in some version. We noticed there is
> something new called Data Block which may be similar to XML data islands,
> but couldn't find much information on it to proceed. If you know of Data
> Blocks being an alternative to XML data islands, then if you could provide
> some documentation or point us to the location where we can get more
> information (with examples on how to use them) that would be very helpful as
> well.
> 
> 
> 
> Any feedback on this would be appreciated.
> 
> 
> 
> Thanks very much in advance!
> 
> 
> 
> Neerja Anand
> 
> neerja at kynex.com
> 
> 
> 

From slightlyoff at google.com  Thu Feb  7 09:16:25 2013
From: slightlyoff at google.com (Alex Russell)
Date: Thu, 7 Feb 2013 09:16:25 -0800
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
Message-ID: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>

While using the shiny new URL spec in some API work, I've got a couple of
questions, some sparked by Jake's excellent insights:


   1. It doesn't appear straightforward to test if two URL objects
   reference the same path. The serialization algorithm has as flag for
   omitting the fragment, but not the query. Is there something in the API
   that I'm missing that would make this easier than custom-serializing 2 URLs
   to omit queries and then test string equality?
   2. The word "search" seems drived from window.location's use of that. Is
   it only included for compat with window.location? if so, can we drop it and
   spec window.location to use a subclass that provides it?

Thanks.

From annevk at annevk.nl  Thu Feb  7 09:27:34 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Thu, 7 Feb 2013 17:27:34 +0000
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
Message-ID: <CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>

On Thu, Feb 7, 2013 at 5:16 PM, Alex Russell <slightlyoff at google.com> wrote:
> It doesn't appear straightforward to test if two URL objects reference the
> same path. The serialization algorithm has as flag for omitting the
> fragment, but not the query. Is there something in the API that I'm missing
> that would make this easier than custom-serializing 2 URLs to omit queries
> and then test string equality?

new URL(path, base).pathname == new URL(path2, base).pathname ought to work.


> The word "search" seems drived from window.location's use of that. Is it
> only included for compat with window.location? if so, can we drop it and
> spec window.location to use a subclass that provides it?

It's used by <a>, <area>, Location, and WorkerLocation. I think we
should just embrace that the string variant is named search
personally.


-- 
http://annevankesteren.nl/

From jkorpela at cs.tut.fi  Thu Feb  7 10:03:07 2013
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Thu, 07 Feb 2013 20:03:07 +0200
Subject: [whatwg] XML data islands related question
In-Reply-To: <C77B8029-E9B2-4722-ABF1-9A1C3F88DEE6@ProWebDesign.nl>
References: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
	<C77B8029-E9B2-4722-ABF1-9A1C3F88DEE6@ProWebDesign.nl>
Message-ID: <5113EC5B.8050500@cs.tut.fi>

2013-02-07 17:55, Randy wrote:

> As far as I'm aware, Data Blocks should be or is part of HTML5.  See
 > https://developer.mozilla.org/en/docs/Using_XML_Data_Islands_in_Mozilla
 > for more info.

It's a somewhat similar concept, but it's about embedded data in 
general, not specifically XML data. Moreover, the <xml> element (which 
was, as far as I can see, implemented only in IE versions 5 and 6) was 
specifically for XML data, implying the idea that the browser parses the 
XML data and makes it available in a certain way that you could use with 
HTML attributes.

Although <xml> had its merits, it seems to be water under the bridge 
now, not supported even by modern versions of IE (though they seem to 
have an excuse for a surrogate for broken support: <xml>foobar</xml> 
gets ignored, whereas other browsers ignore just the tags and render 
foobar).

The current WHATWG HTML document, as well as the W3C HTML5 CR, defines 
<script> really as a multi-purpose element:
"The script element allows authors to include dynamic script and data 
blocks in their documents."
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#the-script-element

So the name is really a misnomer, though it reflects the most common use 
of the element. The content can be plain text, XML text, or text in any 
format, as long as you take care of parsing it. In practice, if the type 
attribute is set to any value except one of the strings interpreted as 
referring to JavaScript, the content is taken just as a block of text 
data, made available to client-side scripting but otherwise ignored.

However, browsers do not seem to support using a src attribute then; the 
non-script data must be inline, as element content, not fetched from an 
external source. I suppose the usual suspects (security considerations) 
are to be blaimed. This however means that the technique is not 
comparable to <xml>, which allowed external references.

It might be useful to mention explicitly in the spec that browsers do 
not generally allow non-script to be specified via the src attribute. 
And perhaps the spec should say that this is implementation-dependent 
and recommend that such references should be allowed, with due security 
considerations.

It's a bit odd that if you wish to set up a standalone application 
running in a browser (often called "HTML5 application", without implying 
any particular version of HTML5), you can include e.g. scripts and 
images in separate files but not plain text or XML data

Yucca


From alain.couthures at agencexml.com  Thu Feb  7 10:16:04 2013
From: alain.couthures at agencexml.com (Alain Couthures)
Date: Thu, 07 Feb 2013 19:16:04 +0100
Subject: [whatwg] XML data islands related question
In-Reply-To: <5113EC5B.8050500@cs.tut.fi>
References: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
	<C77B8029-E9B2-4722-ABF1-9A1C3F88DEE6@ProWebDesign.nl>
	<5113EC5B.8050500@cs.tut.fi>
Message-ID: <5113EF64.8030105@agencexml.com>

Le 07/02/2013 19:03, Jukka K. Korpela a ?crit :
>
>
> It's a bit odd that if you wish to set up a standalone application 
> running in a browser (often called "HTML5 application", without 
> implying any particular version of HTML5), you can include e.g. 
> scripts and images in separate files but not plain text or XML data
A good workaround is to use the SCRIPT element with a type attribute set 
to "text/xml": the browser will not try to interpret it! I use it myself 
in my XForms implementation to store fragments of XHTML+XForms.

-Alain

From jkorpela at cs.tut.fi  Thu Feb  7 10:29:23 2013
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Thu, 07 Feb 2013 20:29:23 +0200
Subject: [whatwg] XML data islands related question
In-Reply-To: <5113EF64.8030105@agencexml.com>
References: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
	<C77B8029-E9B2-4722-ABF1-9A1C3F88DEE6@ProWebDesign.nl>
	<5113EC5B.8050500@cs.tut.fi> <5113EF64.8030105@agencexml.com>
Message-ID: <5113F283.1070209@cs.tut.fi>

2013-02-07 20:16, Alain Couthures wrote:

> Le 07/02/2013 19:03, Jukka K. Korpela a ?crit :
>>
>> It's a bit odd that if you wish to set up a standalone application
>> running in a browser (often called "HTML5 application", without
>> implying any particular version of HTML5), you can include e.g.
>> scripts and images in separate files but not plain text or XML data
> A good workaround is to use the SCRIPT element with a type attribute set
> to "text/xml": the browser will not try to interpret it! I use it myself
> in my XForms implementation to store fragments of XHTML+XForms.

My point was that although this is possible for data inserted into an 
HTML document, as <script> element content, it does not work for 
external data, specified via the src attribute. And I think it would be 
unrealistic to *require* support to external references, it might be a 
good idea to mention it as allowed and perhaps recommended.

Yucca



From esprehn at gmail.com  Thu Feb  7 10:47:22 2013
From: esprehn at gmail.com (Elliott Sprehn)
Date: Thu, 7 Feb 2013 10:47:22 -0800
Subject: [whatwg] Proposal: HTMLCanvasElement.printCallback API
In-Reply-To: <511367F1.5080602@gmail.com>
References: <76AFD13D-458E-4ADC-AE90-DFC7D4642A31@gmail.com>
	<51004407.10007@gmail.com>
	<CAPJYB1hfmBgULy=3=1EGWfQpTdPqUPe=CHQtgfKieiCtVDU=GQ@mail.gmail.com>
	<511367F1.5080602@gmail.com>
Message-ID: <CAPJYB1jOqPqpDhs+R-2ErXM19ZxXkws9rZfv5PHohd=aKSAotQ@mail.gmail.com>

On Thu, Feb 7, 2013 at 12:38 AM, Julian Viereck <
julian.viereck at googlemail.com> wrote:

> On 1/28/13 6:25 AM, Elliott Sprehn wrote:
>
>> 1) I feel like this should probably be an event. I don't know why we're
>> inventing new callback facilities everywhere.
>>
>> canvas.onprintcanvas = function(e) { e.printState ... }
>>
>
> Not sure I get what you're trying to say. Do you want the function to be
> an event, such that you can do
>
>   canvas.addEventListener('**printCallback', function(e) { ...} )
>
> or just rename the `canvas.printCallback` to `canvas.onprintcallback`?
>
>
It should be an event. There are legitimate reasons for multiple listeners,
for instance I might have a listener on body that adds watermarks and a
listener on the canvas that does just the drawing.

Not using events also limits my ability to globally hook the facility. For
instance I'd like to do:

$(document).printcanvas(function(e) {
  if (drawingFunctions[e.target.id])
    drawingFunctions[e.target.id](e.target);
});

I also still don't understand why this is specific to canvas. Why can't I
do the same thing for <img> ? Cocoa lets me hook NSView drawRect: and draw
whatever I want at print time.


>  2) What does "send the canvas' content without rasterization to the
>> printer" mean? How are blending and overlapping images handled? Your
>> current description makes it sound like if I did two drawImage() calls it
>> would make my printer print the images on top of each other.
>>
> The drawing is done exactly the same as you expect it to show up on the
> screen including blending and overlapping.
>
> Here is an example using the canvas.printCallback API. It draws shapes
> over each other:
> - test html page: https://bug745025.bugzilla.**
> mozilla.org/attachment.cgi?id=**625810<https://bug745025.bugzilla.mozilla.org/attachment.cgi?id=625810>
> - output: https://docs.google.com/file/**d/**0B4VOqqwjYRMLS05JNVZpZWt3MG8/
> **edit?usp=sharing<https://docs.google.com/file/d/0B4VOqqwjYRMLS05JNVZpZWt3MG8/edit?usp=sharing>
>
> Is this clear or does it need more clearification?
>

Ah, you don't mean sent to the physical printer without rasterization then,
you mean it's just spooled to the printer driver which may rasterize it to
send it to the device. That seems to run into operating system and
implementation limitations. I don't know if the spec should require that
behavior.

- E

From robert at ocallahan.org  Thu Feb  7 13:10:40 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 8 Feb 2013 10:10:40 +1300
Subject: [whatwg] Proposal: HTMLCanvasElement.printCallback API
In-Reply-To: <CAPJYB1jOqPqpDhs+R-2ErXM19ZxXkws9rZfv5PHohd=aKSAotQ@mail.gmail.com>
References: <76AFD13D-458E-4ADC-AE90-DFC7D4642A31@gmail.com>
	<51004407.10007@gmail.com>
	<CAPJYB1hfmBgULy=3=1EGWfQpTdPqUPe=CHQtgfKieiCtVDU=GQ@mail.gmail.com>
	<511367F1.5080602@gmail.com>
	<CAPJYB1jOqPqpDhs+R-2ErXM19ZxXkws9rZfv5PHohd=aKSAotQ@mail.gmail.com>
Message-ID: <CAOp6jLbf2tFrEb3dksbQUNoqtyp2EtQmJUF=Zt2s34fvTn1dEA@mail.gmail.com>

On Fri, Feb 8, 2013 at 7:47 AM, Elliott Sprehn <esprehn at gmail.com> wrote:

> I also still don't understand why this is specific to canvas. Why can't I
> do the same thing for <img> ? Cocoa lets me hook NSView drawRect: and draw
> whatever I want at print time.
>

I answered that on January 29.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From neerja at kynex.com  Thu Feb  7 14:17:18 2013
From: neerja at kynex.com (Neerja Anand)
Date: Thu, 7 Feb 2013 17:17:18 -0500
Subject: [whatwg] XML data islands related question
In-Reply-To: <CAN7jg5O8cqOeUqaWpg8+2hPS26xW=xGO_Cos6BG1KfmDP1mLpg@mail.gmail.com>
References: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
	<CAN7jg5O8cqOeUqaWpg8+2hPS26xW=xGO_Cos6BG1KfmDP1mLpg@mail.gmail.com>
Message-ID: <3A65A16AA10A4391ACCDDE13506408F2@kynex.lan>

Hello Mat - well this feature is already developed by Microsoft, it is just
discontinued now in the newer browsers. It won't really be a point to
reinvent the wheel if the work has already been done to include data island,
and then bind that data to the fields on the page. If you could get that
code from Microsoft and include that as your standard, then other browsers
would have to incorporate it. So our hope is that you would be able to get
in touch with Microsoft to get this functionality and update your standards.

 

Please let us know if that is doable. Alternatively if you have Microsoft's
contact information then I could reach out to them to request handing over
that code to you.

 

Please advise on how to proceed.

 

Thanks very much.

 

Neerja

 

  _____  

From: Mat Carey [mailto:mat at matcarey.co.uk] 
Sent: Thursday, February 07, 2013 9:59 AM
To: Neerja Anand
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] XML data islands related question

 

I've been thinking about this too...

 

> We wanted to request they could be supported as an addon/plugin into the
browser if not incorporated into the browser by default

 

I came to the conclusion that if I care enough I should write a browser
plugin having reverse engineered the data island spec which would allow
people with my plugin to use these sites, then bring this to WHATWG to
suggest wider adoption.

 

I'm not particularly active on WHATWG but the general approach seems to be
that if you have a good idea you should go and create it, show that it works
and then bring it to WHATWG for a wider adoption.

 

My advice would be to have a look and see if anyone's already started a
project to reverse engineer this, if they have join it, if they haven't
start it.

 

I decided previously that I don't care enough to do this work myself, if
there's someone else working towards this I might be willing to help in an
open source project and I'm sure there's others who would do the same.

 

I could be wrong - if I am I'm sure someone will correct me.

 

Mat Carey

 

On Thu, Feb 7, 2013 at 2:47 PM, Neerja Anand <neerja at kynex.com> wrote:

Hello - it appears that XML data islands (originally created by Microsoft)
have been discontinued in the newer browsers. We wanted to request they
could be supported as an addon/plugin into the browser if not incorporated
into the browser by default. We understand that this was a Microsoft only
feature but they are extremely helpful to our business and their
discontinuation would highly affect our business. Our request is to make
them as an HTML5 standard, so all browsers would then have to support this
feature. This would make the life of us developers much easier. We are not
asking for Microsoft's version of XML data islands specifically, but would
want this feature as a standard in some version. We noticed there is
something new called Data Block which may be similar to XML data islands,
but couldn't find much information on it to proceed. If you know of Data
Blocks being an alternative to XML data islands, then if you could provide
some documentation or point us to the location where we can get more
information (with examples on how to use them) that would be very helpful as
well.



Any feedback on this would be appreciated.



Thanks very much in advance!



Neerja Anand

neerja at kynex.com








 

-- 

Web Developer & Consultant 

 <mailto:mat at matcarey.co.uk> mat at matcarey.co.uk
 <http://www.matcarey.co.uk/> www.matcarey.co.uk 

07952258096 


From gman at google.com  Thu Feb  7 16:24:18 2013
From: gman at google.com (Gregg Tavares)
Date: Thu, 7 Feb 2013 16:24:18 -0800
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
Message-ID: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>

 Anyone have time to give me some advice, tips, pointers?

In the next WebGL we have Query/Sync objects. In C/C++ land the user can
insert some drawing commands that will happen asynchronously on the GPU.
They can also insert a query. They can then poll that query (did this
finish?).

We'd like to expose that to JavaScript. I've been pushing to making it a
callback in JavaScript rather than polling. Most graphics developers I talk
to hate this idea.

My assumptions have been

(a) polling is kind of maybe not allowed in JS (though I have no proof,
only heresy)

Are there any "rules" or things in the spec that make polling apis
untenable?


(b) polling is often error prone and those errors can be avoided using
callbacks and I'm assuming designing an API that is hard or impossible to
use wrong is a good thing.

To give an example, in GL I can render in 2 threads. Let's say in one
thread I'm rendering to a texture and in the other thread I'd like to use
that texture to render something else.

I can insert a query in the first thread, and poll that query in the second
thread. When the query says the texture is ready the second thread can
render with it.

The problem is, if I forget to query things won't fail I'll just get the
wrong results. But I might not. It might be that rendering on thread #1
takes 1ms and it takes 2ms before thread 2 tries to render so things just
appear to work, no queries needed. But then something (another tab, another
app) slows the the system down. Thread #1 takes 4ms now and Thread #2 which
is just assuming things take 2ms renders and sees old or half rendered
results.

We can encapsulate some of this. In WebGL we can require that the texture
being used in both threads be a wrapped object, a SharedTexture, and we can
require SharedTextures can be used in only 1 thread at a time. You acquire
and release it on a particular thread. And so now comes the issue:

Should acquire block, poll or use a callback

block = evil

poll has the issue that I can try to use the texture even when I haven't
acquired it. See the example above. It allows not polling and assuming the
texture will be available. That might work most of the time but on some
machine or under certain circumstances the acquire will fail. Apps that
forget to check for success because the API let them ignore failure will
then fail in strange and random ways. It basically exposes race conditions

callback seems to make it much harder to use wrong. You get a callback when
the texture has been acquired. Now you can't use it without calling acquire
period.

But. that comes back to (a) above. Move devs I've talked to really don't
want to use callbacks. They're all good devs and they know what they're
doing and they don't want to deal with what they consider callback/closure
hell. Especially when they need to acquire multiple things at once.

I'm in the callback camp. (1) to protect programmers from mistakes they
won't find until the exceptional happens and (2) because I'm under the
impression that browser vendors would say "no" to polling. But, maybe it
doesn't matter and polling is fine.

note: this issue already exists in the Web API today with images. Example:

img.src = "someimage.jpg"
setTimeout(function() {
   ctx.drawImage(img, 0, 0);
}, 1000);

Assumes the image will be available in 1 second which may or may not be
true. The API could have been designed to make this much harder to get
wrong (though not impossible). If you had get some kind of ImageHandle to
call drawImage and you could only get that ImageHandle in the 'load' event
of an image

Images are not quite analogous though as there is no polling built in
polling on an image to find out if it's finished.

From glenn at zewt.org  Thu Feb  7 17:32:03 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Thu, 7 Feb 2013 19:32:03 -0600
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
In-Reply-To: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
References: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
Message-ID: <CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>

On Thu, Feb 7, 2013 at 6:24 PM, Gregg Tavares <gman at google.com> wrote:

>  Anyone have time to give me some advice, tips, pointers?
>
> In the next WebGL we have Query/Sync objects. In C/C++ land the user can
> insert some drawing commands that will happen asynchronously on the GPU.
> They can also insert a query. They can then poll that query (did this
> finish?).
>

Before I get into the technical discussion of polling vs. events, I'd like
to look at this briefly from a higher level.

A big problem with WebGL is that it tends to disregard the conventions of
the platform; it "does its own thing".  For example, it uses slews of
functions with different names, instead of collapsing logical overloads.
It also has another slew of functions--deleteBuffer, deleteFramebuffer,
deleteShader--which could easily have been a single "delete(WebGLObject)",
or much better a "delete()" function on WebGLObject.  This makes WebGL feel
more like a naive copy of OpenGL, designed by a C programmer, than a
well-thought-out binding.

This is just to say: callbacks are the pattern on on the platform, not
polling, and WebGL should follow that pattern, not go its own way and make
up its own conventions.  If people don't understand why the platform's
conventions are what they are, and think they should be something else,
please encourage them to come here and discuss it--not to try to make WebGL
its own isolated island.  That's damaging to WebGL and the platform as a
whole.

We'd like to expose that to JavaScript. I've been pushing to making it a
> callback in JavaScript rather than polling. Most graphics developers I talk
> to hate this idea.
>

Polling is expensive, especially if you don't already have a render loop to
poll from (eg. single-shot rendering, and load screens).

It's also latent.  If you're polling from requestAnimationFrame (for
example), you're probably checking every 16ms.  That means there may be up
to 16ms extra delay, if the task finished right after the last poll.  This
encourages people to set timers that run as fast as possible, in order to
lower latency, which makes it more and more expensive and runs up against
timer throttling.

But. that comes back to (a) above. Move devs I've talked to really don't
> want to use callbacks. They're all good devs and they know what they're
> doing and they don't want to deal with what they consider callback/closure
> hell. Especially when they need to acquire multiple things at once.
>

There's no "callback hell"; it's very easy to wait for many things to
finish with just a single callback.  Here's an example, which loads a bunch
of images with <img>, and calls a function when they're all done loading:

https://zewt.org/~glenn/load-lots-of-images.html

It's very simple: each time an image finishes loading, the callback checks
whether all resources have finished loading.  If there are still images in
the process of loading, it returns and waits for the next one to finish.
Otherwise, it's done.  There's just a single, trivial closure.

Images are not quite analogous though as there is no polling built in
> polling on an image to find out if it's finished.
>

Actually, there is.  Changing "img.onload = onload" to "setInterval(onload,
100)" (and adding a clearInterval in the appropriate place) in the above
sample turns it into a poll.

-- 
Glenn Maynard

From slightlyoff at google.com  Fri Feb  8 04:11:24 2013
From: slightlyoff at google.com (Alex Russell)
Date: Fri, 8 Feb 2013 04:11:24 -0800
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
Message-ID: <CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>

On Thursday, February 7, 2013, Anne van Kesteren wrote:

> On Thu, Feb 7, 2013 at 5:16 PM, Alex Russell <slightlyoff at google.com<javascript:;>>
> wrote:
> > It doesn't appear straightforward to test if two URL objects reference
> the
> > same path. The serialization algorithm has as flag for omitting the
> > fragment, but not the query. Is there something in the API that I'm
> missing
> > that would make this easier than custom-serializing 2 URLs to omit
> queries
> > and then test string equality?
>
> new URL(path, base).pathname == new URL(path2, base).pathname ought to
> work.
>

But if I've been vended a URL object from some API, I first have to compare
the bases. I'd like a way to ask something like "is the full URL
up-to-and-including this component the same?" E.g., if I have an API that's
handed two URLs (a and b), I'd like to be able to write something like:

    if (a.toString("path") == b.toString("path")) {
      ...
    }


> > The word "search" seems drived from window.location's use of that. Is it
> > only included for compat with window.location? if so, can we drop it and
> > spec window.location to use a subclass that provides it?
>
> It's used by <a>, <area>, Location, and WorkerLocation. I think we
> should just embrace that the string variant is named search
> personally.
>

I'm less fussed on this point, but I do think naming matters. If we can do
better, I think we should.

From cabanier at gmail.com  Fri Feb  8 04:25:24 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Fri, 8 Feb 2013 23:25:24 +1100
Subject: [whatwg] Adding the imageSmoothingEnabled back into 2dContext
	Level 2 spec.
In-Reply-To: <dbdbd50110e64b48a7b26e5e26875e2c@SN2PR03MB045.namprd03.prod.outlook.com>
References: <dbdbd50110e64b48a7b26e5e26875e2c@SN2PR03MB045.namprd03.prod.outlook.com>
Message-ID: <CAGN7qDAf_tBWfhD=EogOpQ_TrZzCkSNk0ijY+FfMa-N7XP+L0w@mail.gmail.com>

I agree we should bring it back.

Personally, it would be nice that have a more formal definition of what
smoothing actually means so user agents can implement it similarly.

Rik

On Tue, Feb 5, 2013 at 7:14 AM, Jay Munro <jaymunro at microsoft.com> wrote:

> For CR, we took the imageSmoothingEnable feature out because it hadn't
> been given a chance to be discussed by the working group. For level 2, I'm
> adding it back in, but asking for any discussion that needs to be made
> first.
>
> Silence will be taken to mean there is no objection, but positive
> responses are encouraged.  If I don't hear any objections by Monday Feb 11,
> I'll check it in.
>
> The following is the pending check in:
>
>
> @@ -40677,6 +40677,10 @@ dictionary <dfn>TrackEventInit</dfn> :
> <span>EventInit</span> {
>    // compositing
>             attribute unrestricted double <span
> title="dom-context-2d-globalAlpha">globalAlpha</span>; // (default 1.0)
>             attribute DOMString <span
> title="dom-context-2d-globalCompositeOperation">globalCompositeOperation</span>;
> // (default source-over)
> +
> +  // image smoothing
> +           attribute boolean <span
> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</span>;
> // (default true)
> +
>  <!--
>    // v7 we've also received requests for:
>    - turning off antialiasing to avoid seams when patterns are painted
> next to each other
> @@ -40945,7 +40949,8 @@ interface <dfn>Path</dfn> {
>
> title="dom-context-2d-globalCompositeOperation">globalCompositeOperation</code>,
> <code
>     title="dom-context-2d-font">font</code>, <code
>     title="dom-context-2d-textAlign">textAlign</code>, <code
> -   title="dom-context-2d-textBaseline">textBaseline</code>.</li>
> +   title="dom-context-2d-textBaseline">textBaseline</code>, <code
> +
> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>.</li>
>    </ul>
>
>    <p class="note">The <span>current default path</span> and the
> @@ -43416,10 +43421,16 @@ try {
>
>    <p>If the original image data is a bitmap image, the value painted
>    at a point in the area of the repetitions is computed by filtering
> -  the original image data. The user agent may use any filtering
> +  the original image data. If the <code
> +
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> +  then the user agent may use any filtering
>    algorithm (for example bilinear interpolation or nearest-neighbor).
> -  When the filtering algorithm requires a pixel value from outside the
> -  original image data, it must instead use the value from wrapping the
> +  If the <code
> +
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> +  attribute is set to false, the image must be rendered using
> +  nearest-neighbor interpolation. When such the filtering algorithm
> +  requires a pixel value from outside the original image data, it
> +  must instead use the value from wrapping the
>    pixel's coordinates to the original image's dimensions. (That is,
>    the filter uses 'repeat' behavior, regardless of the value of
>    <var title="">repetition</var>.)
> @@ -44539,6 +44550,18 @@ v6DVT (also check for '- -' bits in the part
> above) -->
>    <p class="note">This specification does not define the algorithm to
>    use when scaling the image, if necessary.</p>
>
> +  <p>If the <code
> +
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> +  attribute is set to true, then the user agent should attempt to
> +  apply a smoothing algorithm to the image data when it is scaled.
> +  Otherwise, the image must be rendered using nearest-neighbor
> +  interpolation.</p>
> +
> +  <p class="note">This specification does not define the precise
> +  algorithm to use when scaling an image when the <code
> +
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> +  attribute is set to true.</p>
> +
>    <p class="note">When a canvas is drawn onto itself, the <span>drawing
>    model</span> requires the source to be copied before the image is drawn
>    back onto the canvas, so it is possible to copy parts of a canvas
> @@ -46040,6 +46063,36 @@ function AddCloud(data, x, y) { ... }</pre>
>
>    </div>
>
> +  <h6>Image smoothing</h6>
> +
> +  <dl class="domintro">
> +
> +   <dt><var title="">context</var> . <code
> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code> [
> = <var title="">value</var> ]</dt>
> +
> +   <dd>
> +
> +    <p>Returns whether pattern fills and the <code
> +    title="dom-context-2d-drawImage">drawImage()</code> method will
> +    attempt to smooth images if they have to rescale them (as opposed
> +    to just rendering the images with "big pixels").</p>
> +
> +    <p>Can be set, to change whether images are smoothed (true) or not
> +    (false).</p>
> +
> +   </dd>
> +
> +  </dl>
> +
> +  <div class="impl">
> +
> +  <p>The <dfn
> +
>  title="dom-context-2d-imageSmoothingEnabled"><code>imageSmoothingEnabled</code></dfn>
> +  attribute, on getting, must return the last value it was set to. On
> +  setting, it must be set to the new value. When the
> +  <code>CanvasRenderingContext2D</code> object is created, the
> +  attribute must be set to true.</p>
> +
> +  </div>
>
>
>
>
>
>
>

From annevk at annevk.nl  Fri Feb  8 04:38:33 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Fri, 8 Feb 2013 12:38:33 +0000
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
	<CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
Message-ID: <CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>

On Fri, Feb 8, 2013 at 12:11 PM, Alex Russell <slightlyoff at google.com> wrote:
> But if I've been vended a URL object from some API, I first have to compare
> the bases. I'd like a way to ask something like "is the full URL
> up-to-and-including this component the same?" E.g., if I have an API that's
> handed two URLs (a and b), I'd like to be able to write something like:
>
>     if (a.toString("path") == b.toString("path")) {
>       ...
>     }

What you're saying and what your API proposal is saying seems
different. Do you want to compare the path, or do you want to compare
the scheme, host, etc. but not query and fragment?

I've been thinking of URL.compare(url, options) where in options you
can say to ignore certain components and maybe additionally a way so
you can normalize away percent-encoding for some cases as the parser
does not do that. Thus far you're the only one who seems to be
requesting this feature. I haven't really figured out a way to
quantify demand somehow.


-- 
http://annevankesteren.nl/

From derhoermi at gmx.net  Fri Feb  8 05:40:30 2013
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Fri, 08 Feb 2013 14:40:30 +0100
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
	<CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
	<CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
Message-ID: <4sv9h8pmgt919d2v9vh23tds8kd6nod7jq@hive.bjoern.hoehrmann.de>

* Anne van Kesteren wrote:
>On Fri, Feb 8, 2013 at 12:11 PM, Alex Russell <slightlyoff at google.com> wrote:
>> But if I've been vended a URL object from some API, I first have to compare
>> the bases. I'd like a way to ask something like "is the full URL
>> up-to-and-including this component the same?" E.g., if I have an API that's
>> handed two URLs (a and b), I'd like to be able to write something like:
>>
>>     if (a.toString("path") == b.toString("path")) {
>>       ...
>>     }
>
>What you're saying and what your API proposal is saying seems
>different. Do you want to compare the path, or do you want to compare
>the scheme, host, etc. but not query and fragment?

I believe you are supposed to read the code above as "serialize this to
a string up to and including the path component" which would be in line
with the description.
-- 
Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de
25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From slightlyoff at google.com  Fri Feb  8 06:07:19 2013
From: slightlyoff at google.com (Alex Russell)
Date: Fri, 8 Feb 2013 06:07:19 -0800
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <4sv9h8pmgt919d2v9vh23tds8kd6nod7jq@hive.bjoern.hoehrmann.de>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
	<CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
	<CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
	<4sv9h8pmgt919d2v9vh23tds8kd6nod7jq@hive.bjoern.hoehrmann.de>
Message-ID: <CANr5HFViGRuAsNo5Lm1DQpthBNf110KvPyQ+jU8oMYAaht-5pw@mail.gmail.com>

On Friday, February 8, 2013, Bjoern Hoehrmann wrote:

> * Anne van Kesteren wrote:
> >On Fri, Feb 8, 2013 at 12:11 PM, Alex Russell <slightlyoff at google.com<javascript:;>>
> wrote:
> >> But if I've been vended a URL object from some API, I first have to
> compare
> >> the bases. I'd like a way to ask something like "is the full URL
> >> up-to-and-including this component the same?" E.g., if I have an API
> that's
> >> handed two URLs (a and b), I'd like to be able to write something like:
> >>
> >>     if (a.toString("path") == b.toString("path")) {
> >>       ...
> >>     }
> >
> >What you're saying and what your API proposal is saying seems
> >different. Do you want to compare the path, or do you want to compare
> >the scheme, host, etc. but not query and fragment?
>
> I believe you are supposed to read the code above as "serialize this to
> a string up to and including the path component" which would be in line
> with the description.
>

Yes, that. Thanks Bj?rn. The goal is to serialize up to and including the
path.

From glenn at zewt.org  Fri Feb  8 07:03:39 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 8 Feb 2013 09:03:39 -0600
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
	<CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
	<CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
Message-ID: <CABirCh-g8hF7872XF=-=Nif5W8TcKuD8F9VZpDFQ=21XtK4Dbg@mail.gmail.com>

On Fri, Feb 8, 2013 at 6:38 AM, Anne van Kesteren <annevk at annevk.nl> wrote:

> I've been thinking of URL.compare(url, options) where in options you
> can say to ignore certain components and maybe additionally a way so
> you can normalize away percent-encoding for some cases as the parser
> does not do that. Thus far you're the only one who seems to be
> requesting this feature. I haven't really figured out a way to
> quantify demand somehow.
>

A compare method is probably useful, since you'd also want case-insensitive
comparisons for some parts and not others (eg. lowercase protocol and host
before comparing).  Comparing only certain components doesn't seem very
common, though, and simple for people to do themselves:

function get_url_path(url)
{
    url = new URL(url);
    url.search = "";
    url.hash = "";
    return url;
}

if(get_url_path(url1).toString() == get_url_path(url2).toString())
    ;

-- 
Glenn Maynard

From annevk at annevk.nl  Fri Feb  8 08:09:25 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Fri, 8 Feb 2013 16:09:25 +0000
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CABirCh-g8hF7872XF=-=Nif5W8TcKuD8F9VZpDFQ=21XtK4Dbg@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
	<CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
	<CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
	<CABirCh-g8hF7872XF=-=Nif5W8TcKuD8F9VZpDFQ=21XtK4Dbg@mail.gmail.com>
Message-ID: <CADnb78je1Yfmpp8d4ODRaDxSvMjKLFySnCt-iZTTt137VKoCtQ@mail.gmail.com>

On Fri, Feb 8, 2013 at 3:03 PM, Glenn Maynard <glenn at zewt.org> wrote:
> A compare method is probably useful, since you'd also want case-insensitive
> comparisons for some parts and not others (eg. lowercase protocol and host
> before comparing).

Scheme and host are normalized by the parser already.


-- 
http://annevankesteren.nl/

From chunwang at microsoft.com  Fri Feb  8 09:53:23 2013
From: chunwang at microsoft.com (Chundong Wang)
Date: Fri, 8 Feb 2013 17:53:23 +0000
Subject: [whatwg] A question about portrait-secondary of screen orientation
Message-ID: <bdbc8728d2634143a050f9d86543627e@SN2PR03MB078.namprd03.prod.outlook.com>

Hello - Got a question of screen orientation on portrait/landscape.

Let's say we have a device doesn't support portrait-secondary, by spec<http://www.w3.org/TR/screen-orientation/> we should remove it from allow list which is fine. However if web developer specified "portrait" instead of "portrait-primary" for lockOrientation(), which I suppose is a common case, we'll have to expand it to "portrait-primary, portrait-secondary" according spec. In this case the lockOrientation() would fail because orientations isn't a supported orientation set. I don't think it'll satisfy the original purpose of "portrait".

IMHO, we should explain this more detailed.  We could either,

1.       Only expand "portrait"(or "landscape") into allowed orientations, or;

2.       Filter out disallowed orientations from orientation sequence and lock the screen with that list.

Thoughts?

CD

From glenn at zewt.org  Fri Feb  8 16:32:34 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 8 Feb 2013 18:32:34 -0600
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CADnb78je1Yfmpp8d4ODRaDxSvMjKLFySnCt-iZTTt137VKoCtQ@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
	<CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
	<CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
	<CABirCh-g8hF7872XF=-=Nif5W8TcKuD8F9VZpDFQ=21XtK4Dbg@mail.gmail.com>
	<CADnb78je1Yfmpp8d4ODRaDxSvMjKLFySnCt-iZTTt137VKoCtQ@mail.gmail.com>
Message-ID: <CABirCh97E_xzvnt=Kd9JdZbR4dJJ79KW2BUnw9h7OABVhX4PtQ@mail.gmail.com>

On Fri, Feb 8, 2013 at 10:09 AM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Fri, Feb 8, 2013 at 3:03 PM, Glenn Maynard <glenn at zewt.org> wrote:
> > A compare method is probably useful, since you'd also want
> case-insensitive
> > comparisons for some parts and not others (eg. lowercase protocol and
> host
> > before comparing).
>
> Scheme and host are normalized by the parser already.
>

That's strange.  I'd expect case to round-trip.

Where does this happen for the hostname?  I only see "case" related to ipv6
and scheme.

-- 
Glenn Maynard

From annevk at annevk.nl  Sat Feb  9 00:00:06 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Sat, 9 Feb 2013 08:00:06 +0000
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CABirCh97E_xzvnt=Kd9JdZbR4dJJ79KW2BUnw9h7OABVhX4PtQ@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
	<CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
	<CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
	<CABirCh-g8hF7872XF=-=Nif5W8TcKuD8F9VZpDFQ=21XtK4Dbg@mail.gmail.com>
	<CADnb78je1Yfmpp8d4ODRaDxSvMjKLFySnCt-iZTTt137VKoCtQ@mail.gmail.com>
	<CABirCh97E_xzvnt=Kd9JdZbR4dJJ79KW2BUnw9h7OABVhX4PtQ@mail.gmail.com>
Message-ID: <CADnb78iEP9Mr=bnYkGLerj3JmDe1foXA4-xWgX4C-m0s0wg_1Q@mail.gmail.com>

On Sat, Feb 9, 2013 at 12:32 AM, Glenn Maynard <glenn at zewt.org> wrote:
> That's strange.  I'd expect case to round-trip.

Why?


> Where does this happen for the hostname?  I only see "case" related to ipv6
> and scheme.

Host parsing is not defined yet: http://annevankesteren.nl/2012/11/idna-hell


-- 
http://annevankesteren.nl/

From bobowencode at gmail.com  Sat Feb  9 08:26:12 2013
From: bobowencode at gmail.com (Bob Owen)
Date: Sat, 9 Feb 2013 16:26:12 +0000
Subject: [whatwg] HTML Specification update request: bug 20939
Message-ID: <CA+dJEEDvYM+HKC9vvNF70PXYxz7ATiBdoSmfiFNCXxWyg-u2FQ@mail.gmail.com>

Hi,

While discussing with Boris Zbarsky, some work I am doing on sandboxing for
Mozilla, we realised that the sections in the HTML specification on
browsing context security and browsing context names, could do with some
clarification with regard to the effects of sandboxing.

http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#security-nav
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context-names

The non-normative table, in the browsing context names section, does cover
many of the effects.
However, if the normative text in these two sections is read on its own,
without knowledge of the sandboxing sections, then the reader could easily
come away with an incorrect understanding.

I have raised the following bug detailing all of this.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20939

The bug also contains some suggestions for new rows that could be added to
the non-normative table.

Thanks,
Bob

From jackalmage at gmail.com  Sat Feb  9 08:43:11 2013
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Sat, 9 Feb 2013 09:43:11 -0700
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
In-Reply-To: <CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>
References: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
	<CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>
Message-ID: <CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>

On Thu, Feb 7, 2013 at 6:32 PM, Glenn Maynard <glenn at zewt.org> wrote:
> This is just to say: callbacks are the pattern on on the platform, not
> polling, and WebGL should follow that pattern, not go its own way and make
> up its own conventions.  If people don't understand why the platform's
> conventions are what they are, and think they should be something else,
> please encourage them to come here and discuss it--not to try to make WebGL
> its own isolated island.  That's damaging to WebGL and the platform as a
> whole.

Completely correct, and I agree.

That said, there *are* still some isolated use-cases for polling.  ^_^
 When an event-based approach would potentially deliver far too many
events, with separation between them perhaps less than 1ms, exposing a
polling-based API instead can be useful.  I haven't followed the
Gamepad API lately, but I know this was at least considered for some
of the types of feedback, such as the exact position of joysticks or
pressure on buttons, both of which can change very rapidly in
realistic scenarios.

Outside of these kinds of constraints, though, polling is a no-no, for
the reasons that Glenn gives.

~TJ

From glenn at zewt.org  Sat Feb  9 09:00:00 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Sat, 9 Feb 2013 11:00:00 -0600
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
In-Reply-To: <CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>
References: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
	<CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>
	<CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>
Message-ID: <CABirCh_bR9XvOCEjX_8TyJq+5juzsqr3_7vjkwYen_NF_3bJPw@mail.gmail.com>

On Sat, Feb 9, 2013 at 10:43 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> That said, there *are* still some isolated use-cases for polling.  ^_^
>  When an event-based approach would potentially deliver far too many
> events, with separation between them perhaps less than 1ms, exposing a
> polling-based API instead can be useful.  I haven't followed the
> Gamepad API lately, but I know this was at least considered for some
> of the types of feedback, such as the exact position of joysticks or
> pressure on buttons, both of which can change very rapidly in
> realistic scenarios.
>

A polling API doesn't help you there, since you can't poll every 1ms in
script (certainly not in the UI thread, and probably not reliably even in a
worker).  In fact, since setTimeout will be throttled but events fired by
the browser don't have to be, events can be sent faster than you can poll
in the UI thread (though this is probably a bad idea most of the time).

The solution is probably a matter of buffering the changes, and limiting
how frequently "something was buffered" events fire.  That way, you can get
low-latency, high-time-resolution data if you want it, by reading all a
list of changes made since the last event, without trying to poll at 1kHz
in script.  (I have a vague recollection of proposing exactly this, but I
don't think it went anywhere and I haven't seen any discussion about the
gamepad API here or on -webapps in a long time.)

-- 
Glenn Maynard

From ashley at scirra.com  Mon Feb 11 12:30:39 2013
From: ashley at scirra.com (Ashley Gullen)
Date: Mon, 11 Feb 2013 20:30:39 +0000
Subject: [whatwg] Adding the imageSmoothingEnabled back into 2dContext
 Level 2 spec.
In-Reply-To: <CAGN7qDAf_tBWfhD=EogOpQ_TrZzCkSNk0ijY+FfMa-N7XP+L0w@mail.gmail.com>
References: <dbdbd50110e64b48a7b26e5e26875e2c@SN2PR03MB045.namprd03.prod.outlook.com>
	<CAGN7qDAf_tBWfhD=EogOpQ_TrZzCkSNk0ijY+FfMa-N7XP+L0w@mail.gmail.com>
Message-ID: <CAABs73jN6KOmtgb=aLuY=8mzP2PG7PR3drOHQqpLT+q6FtSVzg@mail.gmail.com>

I would re-emphasise this is important for many game applications.  Here's
an image showing the effect it can have from a recent blog post I wrote:
https://www.scirra.com/images/sampling-point-linear.png
For a game in this style it is essential to be able to force
nearest-neighbour.  Games in that "retro" style are often unplayable
because they look so awful if they get bilinear interpolation forced on
them.  On the other hand, modern hi-res style games which intend to use
bilinear interpolation only look marginally worse if they get
nearest-neighbour.  So I think the existing spec was fine as it was:
imageSmoothingEnabled = false means "require nearest-neighbour
interpolation", imageSmoothingEnabled = true means "any smoothing
algorithm, or nearest-neighbour".

I would also emphasise this should definitely also apply to patterns, for
the same reason: games are likely to use a pattern to render tiles, and
those should be rendered with the same interpolation as everything else.

Ashley



On 8 February 2013 12:25, Rik Cabanier <cabanier at gmail.com> wrote:

> I agree we should bring it back.
>
> Personally, it would be nice that have a more formal definition of what
> smoothing actually means so user agents can implement it similarly.
>
> Rik
>
> On Tue, Feb 5, 2013 at 7:14 AM, Jay Munro <jaymunro at microsoft.com> wrote:
>
> > For CR, we took the imageSmoothingEnable feature out because it hadn't
> > been given a chance to be discussed by the working group. For level 2,
> I'm
> > adding it back in, but asking for any discussion that needs to be made
> > first.
> >
> > Silence will be taken to mean there is no objection, but positive
> > responses are encouraged.  If I don't hear any objections by Monday Feb
> 11,
> > I'll check it in.
> >
> > The following is the pending check in:
> >
> >
> > @@ -40677,6 +40677,10 @@ dictionary <dfn>TrackEventInit</dfn> :
> > <span>EventInit</span> {
> >    // compositing
> >             attribute unrestricted double <span
> > title="dom-context-2d-globalAlpha">globalAlpha</span>; // (default 1.0)
> >             attribute DOMString <span
> >
> title="dom-context-2d-globalCompositeOperation">globalCompositeOperation</span>;
> > // (default source-over)
> > +
> > +  // image smoothing
> > +           attribute boolean <span
> >
> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</span>;
> > // (default true)
> > +
> >  <!--
> >    // v7 we've also received requests for:
> >    - turning off antialiasing to avoid seams when patterns are painted
> > next to each other
> > @@ -40945,7 +40949,8 @@ interface <dfn>Path</dfn> {
> >
> >
> title="dom-context-2d-globalCompositeOperation">globalCompositeOperation</code>,
> > <code
> >     title="dom-context-2d-font">font</code>, <code
> >     title="dom-context-2d-textAlign">textAlign</code>, <code
> > -   title="dom-context-2d-textBaseline">textBaseline</code>.</li>
> > +   title="dom-context-2d-textBaseline">textBaseline</code>, <code
> > +
> >
> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>.</li>
> >    </ul>
> >
> >    <p class="note">The <span>current default path</span> and the
> > @@ -43416,10 +43421,16 @@ try {
> >
> >    <p>If the original image data is a bitmap image, the value painted
> >    at a point in the area of the repetitions is computed by filtering
> > -  the original image data. The user agent may use any filtering
> > +  the original image data. If the <code
> > +
> >
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> > +  then the user agent may use any filtering
> >    algorithm (for example bilinear interpolation or nearest-neighbor).
> > -  When the filtering algorithm requires a pixel value from outside the
> > -  original image data, it must instead use the value from wrapping the
> > +  If the <code
> > +
> >
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> > +  attribute is set to false, the image must be rendered using
> > +  nearest-neighbor interpolation. When such the filtering algorithm
> > +  requires a pixel value from outside the original image data, it
> > +  must instead use the value from wrapping the
> >    pixel's coordinates to the original image's dimensions. (That is,
> >    the filter uses 'repeat' behavior, regardless of the value of
> >    <var title="">repetition</var>.)
> > @@ -44539,6 +44550,18 @@ v6DVT (also check for '- -' bits in the part
> > above) -->
> >    <p class="note">This specification does not define the algorithm to
> >    use when scaling the image, if necessary.</p>
> >
> > +  <p>If the <code
> > +
> >
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> > +  attribute is set to true, then the user agent should attempt to
> > +  apply a smoothing algorithm to the image data when it is scaled.
> > +  Otherwise, the image must be rendered using nearest-neighbor
> > +  interpolation.</p>
> > +
> > +  <p class="note">This specification does not define the precise
> > +  algorithm to use when scaling an image when the <code
> > +
> >
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> > +  attribute is set to true.</p>
> > +
> >    <p class="note">When a canvas is drawn onto itself, the <span>drawing
> >    model</span> requires the source to be copied before the image is
> drawn
> >    back onto the canvas, so it is possible to copy parts of a canvas
> > @@ -46040,6 +46063,36 @@ function AddCloud(data, x, y) { ... }</pre>
> >
> >    </div>
> >
> > +  <h6>Image smoothing</h6>
> > +
> > +  <dl class="domintro">
> > +
> > +   <dt><var title="">context</var> . <code
> >
> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code> [
> > = <var title="">value</var> ]</dt>
> > +
> > +   <dd>
> > +
> > +    <p>Returns whether pattern fills and the <code
> > +    title="dom-context-2d-drawImage">drawImage()</code> method will
> > +    attempt to smooth images if they have to rescale them (as opposed
> > +    to just rendering the images with "big pixels").</p>
> > +
> > +    <p>Can be set, to change whether images are smoothed (true) or not
> > +    (false).</p>
> > +
> > +   </dd>
> > +
> > +  </dl>
> > +
> > +  <div class="impl">
> > +
> > +  <p>The <dfn
> > +
> >
>  title="dom-context-2d-imageSmoothingEnabled"><code>imageSmoothingEnabled</code></dfn>
> > +  attribute, on getting, must return the last value it was set to. On
> > +  setting, it must be set to the new value. When the
> > +  <code>CanvasRenderingContext2D</code> object is created, the
> > +  attribute must be set to true.</p>
> > +
> > +  </div>
> >
> >
> >
> >
> >
> >
> >
>

From anewpage.media at gmail.com  Mon Feb 11 14:33:06 2013
From: anewpage.media at gmail.com (Brian Blakely)
Date: Mon, 11 Feb 2013 17:33:06 -0500
Subject: [whatwg] Canonical Image and Color
Message-ID: <CAJGQg4EwgYOqf5y67Q_=WN=UewBZvkXzs5ZG8wQDrD2AM3GGnQ@mail.gmail.com>

* Proposal

Meta elements for defining a canonical image and color to be associated
with the page(s) in which they are included.  This is intended for use by
user agents and third-party applications (such as social networks),
referred to collectively as "parsers" in this document.  It is inspired by
Microsoft's recent work in site pinning and Apple's "standalone" webapp
implementation in iOS Safari.

* Example

<meta name="image" content="path/to/image.png" />
<meta name="color" content="#123456" />

* Image

Value may be a relative or absolute path to file.  No restrictions on
filetype or resolution.  May also be an animated image or video format.
 Filetypes supported and handling therein is relegated to the parser.

* Color

Value may be any of the CSS named colors, hex codes, RGB, HSL and their
alpha-channel variants.  Once attained by the parser, use is at that
parser's discretion.

From jackalmage at gmail.com  Mon Feb 11 14:41:09 2013
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 11 Feb 2013 14:41:09 -0800
Subject: [whatwg] Canonical Image and Color
In-Reply-To: <CAJGQg4EwgYOqf5y67Q_=WN=UewBZvkXzs5ZG8wQDrD2AM3GGnQ@mail.gmail.com>
References: <CAJGQg4EwgYOqf5y67Q_=WN=UewBZvkXzs5ZG8wQDrD2AM3GGnQ@mail.gmail.com>
Message-ID: <CAAWBYDC_T=-GgUtpyApWUsaQ3yDuHvQiZKg0BzB8e44RZedGZw@mail.gmail.com>

On Mon, Feb 11, 2013 at 2:33 PM, Brian Blakely <anewpage.media at gmail.com> wrote:
> * Proposal
>
> Meta elements for defining a canonical image and color to be associated
> with the page(s) in which they are included.  This is intended for use by
> user agents and third-party applications (such as social networks),
> referred to collectively as "parsers" in this document.  It is inspired by
> Microsoft's recent work in site pinning and Apple's "standalone" webapp
> implementation in iOS Safari.

Can you elaborate?  I have no idea what UAs and third-party apps would
do with a "canonical image" or "canonical color".

~TJ

From anewpage.media at gmail.com  Mon Feb 11 16:17:25 2013
From: anewpage.media at gmail.com (Brian Blakely)
Date: Mon, 11 Feb 2013 19:17:25 -0500
Subject: [whatwg] Canonical Image and Color
In-Reply-To: <CAAWBYDC_T=-GgUtpyApWUsaQ3yDuHvQiZKg0BzB8e44RZedGZw@mail.gmail.com>
References: <CAJGQg4EwgYOqf5y67Q_=WN=UewBZvkXzs5ZG8wQDrD2AM3GGnQ@mail.gmail.com>
	<CAAWBYDC_T=-GgUtpyApWUsaQ3yDuHvQiZKg0BzB8e44RZedGZw@mail.gmail.com>
Message-ID: <CAJGQg4FY4WHvCK09dG=Fs=_w31oEuJ-CaraNH7uMhCxjYbmhyQ@mail.gmail.com>

Sure thing.  Let me go through the use cases that I see as applicable
today, derived from instances where an existing vendor or service currently
utilizes a non-standard implementation.

* Social network sharing

Facebook currently scrapes "OpenGraph tags" from shared pages to create a
content snippet.  One such tag is og:image, which specifies the image to
display in that snippet.  Twitter and Google+ use these same tags in
addition to their own implementations for developers.  For the title and
description of the snippet, scrapers will fall back to <title> and the meta
description.  A canonical image would serve the same purpose, but for
visual content.

* News aggregation

Flipboard, a highly visual, magazine-style news and article reader,
displays a hero image from the target page.  It does this by parsing and
analyzing the <img> elements in a page, sometimes displaying a non-optimal
or even vacant result.  A canonical image would allow developers to control
this kind of representation with more specificity, and provide the 3rd
party app with another presentation option.

* OS Integration

Apple currently parses their own "apple-touch-icon" element that specifies
which image will serve as a web application's icon after the user has added
to the homescreen.  Android's browser uses this same element, while
Microsoft uses a similar "msapplication-TileImage".  When these element is
not specified, a screenshot of the website is used instead or, in
Microsoft's case, the favicon.  Firefox OS has still another means of
implementation for this.  A canonical image could either replace or provide
an additional fallback for this functionality.

* Color

In all these cases, a canonical color allows external parsers to provide
further branding or additional flourish in their representation of apps and
pages.  Microsoft's "msapplication-TileColor" and
"msapplication-navbutton-color" elements aim to fulfill this purpose in IE
by coloring the app's tile on the Windows 8 homescreen and IE's own
navigation UI, respectively.


On Mon, Feb 11, 2013 at 5:41 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Mon, Feb 11, 2013 at 2:33 PM, Brian Blakely <anewpage.media at gmail.com>
> wrote:
> > * Proposal
> >
> > Meta elements for defining a canonical image and color to be associated
> > with the page(s) in which they are included.  This is intended for use by
> > user agents and third-party applications (such as social networks),
> > referred to collectively as "parsers" in this document.  It is inspired
> by
> > Microsoft's recent work in site pinning and Apple's "standalone" webapp
> > implementation in iOS Safari.
>
> Can you elaborate?  I have no idea what UAs and third-party apps would
> do with a "canonical image" or "canonical color".
>
> ~TJ
>

From esprehn at gmail.com  Mon Feb 11 20:52:43 2013
From: esprehn at gmail.com (Elliott Sprehn)
Date: Mon, 11 Feb 2013 20:52:43 -0800
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
In-Reply-To: <CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>
References: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
	<CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>
	<CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>
Message-ID: <CAPJYB1hxRKU6UAcQMDALTb=jQR-0c+Eg-hPsUn3fiHp=eaenOw@mail.gmail.com>

On Sat, Feb 9, 2013 at 8:43 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:

> On Thu, Feb 7, 2013 at 6:32 PM, Glenn Maynard <glenn at zewt.org> wrote:
> > This is just to say: callbacks are the pattern on on the platform, not
> > polling, and WebGL should follow that pattern, not go its own way and
> make
> > up its own conventions.  If people don't understand why the platform's
> > conventions are what they are, and think they should be something else,
> > please encourage them to come here and discuss it--not to try to make
> WebGL
> > its own isolated island.  That's damaging to WebGL and the platform as a
> > whole.
>
> Completely correct, and I agree.
>
> That said, there *are* still some isolated use-cases for polling.  ^_^
>  When an event-based approach would potentially deliver far too many
> events, with separation between them perhaps less than 1ms, exposing a
> polling-based API instead can be useful.


I disagree, there's no reasonable reason for polling. If the events would
fire too frequently then the API should be designed to batch up the
notifications and fire at specific checkpoints like rAf or end of micro
task.

There's no reason to poll on the web.

- E

From jackalmage at gmail.com  Mon Feb 11 22:17:58 2013
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 11 Feb 2013 22:17:58 -0800
Subject: [whatwg] Canonical Image and Color
In-Reply-To: <CAJGQg4FY4WHvCK09dG=Fs=_w31oEuJ-CaraNH7uMhCxjYbmhyQ@mail.gmail.com>
References: <CAJGQg4EwgYOqf5y67Q_=WN=UewBZvkXzs5ZG8wQDrD2AM3GGnQ@mail.gmail.com>
	<CAAWBYDC_T=-GgUtpyApWUsaQ3yDuHvQiZKg0BzB8e44RZedGZw@mail.gmail.com>
	<CAJGQg4FY4WHvCK09dG=Fs=_w31oEuJ-CaraNH7uMhCxjYbmhyQ@mail.gmail.com>
Message-ID: <CAAWBYDBhDSy0VBEQmSnF6L=FD_6fRq_+9RjfWr3MmRUNuCQrAA@mail.gmail.com>

On Mon, Feb 11, 2013 at 4:17 PM, Brian Blakely <anewpage.media at gmail.com> wrote:
> Sure thing.  Let me go through the use cases that I see as applicable today,
> derived from instances where an existing vendor or service currently
> utilizes a non-standard implementation.
>
> * Social network sharing
>
> Facebook currently scrapes "OpenGraph tags" from shared pages to create a
> content snippet.  One such tag is og:image, which specifies the image to
> display in that snippet.  Twitter and Google+ use these same tags in
> addition to their own implementations for developers.  For the title and
> description of the snippet, scrapers will fall back to <title> and the meta
> description.  A canonical image would serve the same purpose, but for visual
> content.
>
> * News aggregation
>
> Flipboard, a highly visual, magazine-style news and article reader, displays
> a hero image from the target page.  It does this by parsing and analyzing
> the <img> elements in a page, sometimes displaying a non-optimal or even
> vacant result.  A canonical image would allow developers to control this
> kind of representation with more specificity, and provide the 3rd party app
> with another presentation option.
>
> * OS Integration
>
> Apple currently parses their own "apple-touch-icon" element that specifies
> which image will serve as a web application's icon after the user has added
> to the homescreen.  Android's browser uses this same element, while
> Microsoft uses a similar "msapplication-TileImage".  When these element is
> not specified, a screenshot of the website is used instead or, in
> Microsoft's case, the favicon.  Firefox OS has still another means of
> implementation for this.  A canonical image could either replace or provide
> an additional fallback for this functionality.

These all seem fairly reasonable.  Are you sure that all of the
use-cases would use the same image?

> * Color
>
> In all these cases, a canonical color allows external parsers to provide
> further branding or additional flourish in their representation of apps and
> pages.  Microsoft's "msapplication-TileColor" and
> "msapplication-navbutton-color" elements aim to fulfill this purpose in IE
> by coloring the app's tile on the Windows 8 homescreen and IE's own
> navigation UI, respectively.

Sure, seems reasonable.

~TJ

From dhtmlkitchen at gmail.com  Mon Feb 11 22:56:52 2013
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 11 Feb 2013 22:56:52 -0800
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
In-Reply-To: <CABirCh_bR9XvOCEjX_8TyJq+5juzsqr3_7vjkwYen_NF_3bJPw@mail.gmail.com>
References: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
	<CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>
	<CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>
	<CABirCh_bR9XvOCEjX_8TyJq+5juzsqr3_7vjkwYen_NF_3bJPw@mail.gmail.com>
Message-ID: <CABZUbM35r-oFE1B4ZtAAAb=gUQcL_xujjCHniksYcsbhx1POsg@mail.gmail.com>

On 2/9/13, Glenn Maynard <glenn at zewt.org> wrote:
> On Sat, Feb 9, 2013 at 10:43 AM, Tab Atkins Jr.
> <jackalmage at gmail.com>wrote:
>
>> That said, there *are* still some isolated use-cases for polling.  ^_^
>>  When an event-based approach would potentially deliver far too many
>> events, with separation between them perhaps less than 1ms, exposing a
>> polling-based API instead can be useful.  I haven't followed the
>> Gamepad API lately, but I know this was at least considered for some
>> of the types of feedback, such as the exact position of joysticks or
>> pressure on buttons, both of which can change very rapidly in
>> realistic scenarios.
>>
>
> A polling API doesn't help you there, since you can't poll every 1ms in
> script (certainly not in the UI thread, and probably not reliably even in a
> worker).  In fact, since setTimeout will be throttled but events fired by
> the browser don't have to be, events can be sent faster than you can poll
> in the UI thread (though this is probably a bad idea most of the time).
>
> The solution is probably a matter of buffering the changes, and limiting
> how frequently "something was buffered" events fire.
Are you proposing event quantization threshold?


That type of solution can work for handling the situation where the
event fires too many times like resize and mousemove events. But it is
a little cumbersome to write out event throttlers by hand.

The MOUSE_MOVE_THRESHOLD is no phenomenon really, but useful in such
situations and I'm not boasting at all. Here is the explanation of my
idea which I started using around 2007, IIRC:
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/bc5274b75820e5ff/96fbac718201ebbf?pli=1

Anyway, if the idea is to set an event quantization threshold, it
should be done at the time of registering the callback. And I see no
good reason why that should be modifiable. A hypothetical a 'quant'
property example (it can't be expected to work, just trying to sketch
out the idea).

 var listener = {
  handleEvent : function(ev) { console.log(ev); },
  quant : 40
 };
//  or even
 function handleEvent (ev) { console.log(ev); }
 handleEvent.quant = 40;

 var booleanParametersSuck = false;

 document.addEventListener("mousemove",  listener, booleanParametersSuck);

That way, you can get
> low-latency, high-time-resolution data if you want it, by reading all a
> list of changes made since the last event, without trying to poll at 1kHz
> in script.  (I have a vague recollection of proposing exactly this, but I
> don't think it went anywhere and I haven't seen any discussion about the
> gamepad API here or on -webapps in a long time.)
>
Planck time is the smallest unit of time. Where does it go?
-- 
Garrett
Twitter: @xkit
personx.tumblr.com

From dhtmlkitchen at gmail.com  Mon Feb 11 23:28:06 2013
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 11 Feb 2013 23:28:06 -0800
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
In-Reply-To: <CABZUbM35r-oFE1B4ZtAAAb=gUQcL_xujjCHniksYcsbhx1POsg@mail.gmail.com>
References: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
	<CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>
	<CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>
	<CABirCh_bR9XvOCEjX_8TyJq+5juzsqr3_7vjkwYen_NF_3bJPw@mail.gmail.com>
	<CABZUbM35r-oFE1B4ZtAAAb=gUQcL_xujjCHniksYcsbhx1POsg@mail.gmail.com>
Message-ID: <CABZUbM1ExTEcZaRsbbuVrFqYFugyHBkzpOM5MsJikbSZSuzmQA@mail.gmail.com>

On 2/11/13, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

[...]
>
>  var listener = {
>   handleEvent : function(ev) { console.log(ev); },
>   quant : 40
>  };
> //  or even
>  function handleEvent (ev) { console.log(ev); }
>  handleEvent.quant = 40;
>
Second example should have been
 function listener(ev) { console.log(ev); }
 listener.quant = 40;

>  var booleanParametersSuck = false;
>
>  document.addEventListener("mousemove",  listener, booleanParametersSuck);


Also, for those unfamiliar with the standard specification of
EventListener, particularly with the second parameter being an Object
with a handleEvent property that is a Function:
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener
-- 
Garrett
Twitter: @xkit
personx.tumblr.com

From mounir at lamouri.fr  Tue Feb 12 09:20:49 2013
From: mounir at lamouri.fr (Mounir Lamouri)
Date: Tue, 12 Feb 2013 17:20:49 +0000
Subject: [whatwg] Why do we have <input type='month'> and <input
	type='week'>?
In-Reply-To: <CABirCh_ua8cumCqZcASOTOdwCmsi0yPdVYvoRT23eBstszdy2A@mail.gmail.com>
References: <510988C1.1040900@lamouri.fr> <op.wrry8kurh8on37@bruce-pc>
	<CABirCh_ua8cumCqZcASOTOdwCmsi0yPdVYvoRT23eBstszdy2A@mail.gmail.com>
Message-ID: <511A79F1.5050501@lamouri.fr>

On 01/02/13 15:39, Glenn Maynard wrote:
> On Thu, Jan 31, 2013 at 6:20 AM, Bruce Lawson <brucel at opera.com> wrote:
> 
>> The use-case for an input type I imagine is that a browser can have a
>> select-like UI (Jan, Feb, March, April ...) which, in a French language
>> browser becomes "Janvier, Fevrier, Mars, Avril .. " (or even Vend?miaire to
>> Fructidor for FRC fans).
>>
> 
> FYI, I would find this annoying.  CC expiry entry forms are typically
> select boxes containing 01-12.  The text lines up with what's on my credit
> card, so I don't have to translate "07" to "July" in my head when entering
> it off of my card.  Any month picker for credit card expiry dates should
> always have month numbers (of course, names *in addition* to numbers are
> fine, though probably pointless).

That's exactly why I think the use case is weak: it is easy to implement
a month picker:
<select name='month'><!--fill with option for each
month--></select><select name='year'><!-- fill with option for each year
you want to show --></select>

Given how easy it is, authors might quickly end up expecting specific
behaviour that the UAs do not provide. For example, Having "01 -
January" or "January - 01" or even "01" instead of "January". They could
want the year to show up as 2 digits or 1 digit, as a textfield, a
<select> or an <input type='number'> with a min and a max.
Anyway, I still believe that the pros of <input type='month'> are quite
low but in another hand, it shouldn't cost too much for UA to implement
it if or date-time-related types are already implemented and it provides
a real benefit on Mobile.

Regarding week, I still believe that the use cases are pretty weak but
the most important issue is that there is no good UI for this on Mobile
AFAIK.

Cheers,
--
Mounir

From jackalmage at gmail.com  Tue Feb 12 09:26:16 2013
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 12 Feb 2013 09:26:16 -0800
Subject: [whatwg] Why do we have <input type='month'> and <input
	type='week'>?
In-Reply-To: <511A79F1.5050501@lamouri.fr>
References: <510988C1.1040900@lamouri.fr> <op.wrry8kurh8on37@bruce-pc>
	<CABirCh_ua8cumCqZcASOTOdwCmsi0yPdVYvoRT23eBstszdy2A@mail.gmail.com>
	<511A79F1.5050501@lamouri.fr>
Message-ID: <CAAWBYDCQppyNtUmr-xAt0Tn9Ydbd1bE6WYQTVSfThvZCPGJoVw@mail.gmail.com>

On Tue, Feb 12, 2013 at 9:20 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:
> On 01/02/13 15:39, Glenn Maynard wrote:
>> FYI, I would find this annoying.  CC expiry entry forms are typically
>> select boxes containing 01-12.  The text lines up with what's on my credit
>> card, so I don't have to translate "07" to "July" in my head when entering
>> it off of my card.  Any month picker for credit card expiry dates should
>> always have month numbers (of course, names *in addition* to numbers are
>> fine, though probably pointless).
>
> That's exactly why I think the use case is weak: it is easy to implement
> a month picker:
> <select name='month'><!--fill with option for each
> month--></select><select name='year'><!-- fill with option for each year
> you want to show --></select>
>
> Given how easy it is, authors might quickly end up expecting specific
> behaviour that the UAs do not provide. For example, Having "01 -
> January" or "January - 01" or even "01" instead of "January". They could
> want the year to show up as 2 digits or 1 digit, as a textfield, a
> <select> or an <input type='number'> with a min and a max.
> Anyway, I still believe that the pros of <input type='month'> are quite
> low but in another hand, it shouldn't cost too much for UA to implement
> it if or date-time-related types are already implemented and it provides
> a real benefit on Mobile.

The fact that authors today have a random assortment of displays for
the exact same feature (credit card expirys) is something that would
be great to fix, not bemoan as a loss to the world. ^_^

~TJ

From jkorpela at cs.tut.fi  Tue Feb 12 09:39:50 2013
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Tue, 12 Feb 2013 19:39:50 +0200
Subject: [whatwg] Why do we have <input type='month'> and <input
	type='week'>?
In-Reply-To: <CAAWBYDCQppyNtUmr-xAt0Tn9Ydbd1bE6WYQTVSfThvZCPGJoVw@mail.gmail.com>
References: <510988C1.1040900@lamouri.fr> <op.wrry8kurh8on37@bruce-pc>
	<CABirCh_ua8cumCqZcASOTOdwCmsi0yPdVYvoRT23eBstszdy2A@mail.gmail.com>
	<511A79F1.5050501@lamouri.fr>
	<CAAWBYDCQppyNtUmr-xAt0Tn9Ydbd1bE6WYQTVSfThvZCPGJoVw@mail.gmail.com>
Message-ID: <511A7E66.7010906@cs.tut.fi>

2013-02-12 19:26, Tab Atkins Jr. wrote:

> The fact that authors today have a random assortment of displays for
> the exact same feature (credit card expirys) is something that would
> be great to fix, not bemoan as a loss to the world. ^_^

Well, maybe, from some point of view, but is there really something to 
be fixed, and is it probable that <input type=month> would fix it?

I have seen many input widgets for such data and used them a lot in test 
purchases. In general, the more advanced they try to be, the more 
annoying they get. I can type "03/15", or whatever reads in the card, 
rather fast. But if I have to pick things up from dropdowns or click on 
something in a calendar picker, I surely hope I won't need to do this a 
dozen more times.

What are the odds that browser vendors will implement <input type=month> 
in a simple manner that allows fast typing as one input method? Rather 
small I think.

This would make the most obvious, and perhaps the most common, use for 
<input type=month> a case *against* it.  Credit card expiry month is 
best handled with a text input field, with suitable checks on the input 
string. There may be *other* cases where graphic widgets are good when 
selecting a month, but authors can use libraries for such purpose, and I 
don't see any particular reason why this should be standardized across 
pages but not across browsers.

Even if <input type=month> became widely supported, many, probably most, 
authors will keep using libraries or their own code, because they get 
consistent look and feel and functionality across browsers. Some authors 
would be misled into using <input type=month> for any month input 
because that's "logical" or "semantic" (as it is in a sense), but this 
will create questionable user experience in many common cases.

Yucca


From jackalmage at gmail.com  Tue Feb 12 09:47:47 2013
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 12 Feb 2013 09:47:47 -0800
Subject: [whatwg] Why do we have <input type='month'> and <input
	type='week'>?
In-Reply-To: <511A7E66.7010906@cs.tut.fi>
References: <510988C1.1040900@lamouri.fr> <op.wrry8kurh8on37@bruce-pc>
	<CABirCh_ua8cumCqZcASOTOdwCmsi0yPdVYvoRT23eBstszdy2A@mail.gmail.com>
	<511A79F1.5050501@lamouri.fr>
	<CAAWBYDCQppyNtUmr-xAt0Tn9Ydbd1bE6WYQTVSfThvZCPGJoVw@mail.gmail.com>
	<511A7E66.7010906@cs.tut.fi>
Message-ID: <CAAWBYDBxWHZwZJqiS=T3JDBfXUEcQ36gMcfgX8cJDyOSoXDWYw@mail.gmail.com>

On Tue, Feb 12, 2013 at 9:39 AM, Jukka K. Korpela <jkorpela at cs.tut.fi> wrote:
> 2013-02-12 19:26, Tab Atkins Jr. wrote:
>> The fact that authors today have a random assortment of displays for
>> the exact same feature (credit card expirys) is something that would
>> be great to fix, not bemoan as a loss to the world. ^_^
>
> Well, maybe, from some point of view, but is there really something to be
> fixed, and is it probable that <input type=month> would fix it?
>
> I have seen many input widgets for such data and used them a lot in test
> purchases. In general, the more advanced they try to be, the more annoying
> they get. I can type "03/15", or whatever reads in the card, rather fast.
> But if I have to pick things up from dropdowns or click on something in a
> calendar picker, I surely hope I won't need to do this a dozen more times.
>
> What are the odds that browser vendors will implement <input type=month> in
> a simple manner that allows fast typing as one input method? Rather small I
> think.
>
> This would make the most obvious, and perhaps the most common, use for
> <input type=month> a case *against* it.  Credit card expiry month is best
> handled with a text input field, with suitable checks on the input string.
> There may be *other* cases where graphic widgets are good when selecting a
> month, but authors can use libraries for such purpose, and I don't see any
> particular reason why this should be standardized across pages but not
> across browsers.

This argument appears to apply equally well to all the date inputs,
and perhaps most of the other new inputs.  I believe it's wrong.

* Most people don't type very fast.  We email-happy people are an
exception.  For most, clicking on things is faster and easier.
* Experience shows that most authors appear to prefer a pair of
dropdowns for selecting month and year, rather than a text input.
Might as well move closer to author expectations.
* Text inputs are permanently subject to the vagaries of whatever
arcane syntax the author happened to want (or didn't want, but
accidentally required when they miswrote their regex) - Do I just type
two numbers with a slash? Or do I use a dash? Or a space?  What if I
use a slash surrounded by spaces? Or do I use the month name? Long or
short name? Two digit or four digit year? - while visual inputs put
your options in front of you and avoid all of that.

> Even if <input type=month> became widely supported, many, probably most,
> authors will keep using libraries or their own code, because they get
> consistent look and feel and functionality across browsers. Some authors
> would be misled into using <input type=month> for any month input because
> that's "logical" or "semantic" (as it is in a sense), but this will create
> questionable user experience in many common cases.

This same argument keeps getting deployed against type="date".  We'll
see what actually happens.  I expect (and deeply hope) that the ease
of use of the built-ins will win the day, once they're supported on
every browser sites expect their visitors to use.

~TJ

From cabanier at gmail.com  Tue Feb 12 09:49:55 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Wed, 13 Feb 2013 04:49:55 +1100
Subject: [whatwg] Adding the imageSmoothingEnabled back into 2dContext
 Level 2 spec.
In-Reply-To: <CAABs73jN6KOmtgb=aLuY=8mzP2PG7PR3drOHQqpLT+q6FtSVzg@mail.gmail.com>
References: <dbdbd50110e64b48a7b26e5e26875e2c@SN2PR03MB045.namprd03.prod.outlook.com>
	<CAGN7qDAf_tBWfhD=EogOpQ_TrZzCkSNk0ijY+FfMa-N7XP+L0w@mail.gmail.com>
	<CAABs73jN6KOmtgb=aLuY=8mzP2PG7PR3drOHQqpLT+q6FtSVzg@mail.gmail.com>
Message-ID: <CAGN7qDBbMHBJwTH7gZjrb1WH+21WPR-hzrpk0e0EvdvnaCqUsQ@mail.gmail.com>

Is there an implementation report on this?
If browsers stabilized on this feature, it might be time to drop the prefix.

On Tue, Feb 12, 2013 at 7:30 AM, Ashley Gullen <ashley at scirra.com> wrote:

> I would re-emphasise this is important for many game applications.  Here's
> an image showing the effect it can have from a recent blog post I wrote:
> https://www.scirra.com/images/sampling-point-linear.png
> For a game in this style it is essential to be able to force
> nearest-neighbour.  Games in that "retro" style are often unplayable
> because they look so awful if they get bilinear interpolation forced on
> them.  On the other hand, modern hi-res style games which intend to use
> bilinear interpolation only look marginally worse if they get
> nearest-neighbour.  So I think the existing spec was fine as it was:
> imageSmoothingEnabled = false means "require nearest-neighbour
> interpolation", imageSmoothingEnabled = true means "any smoothing
> algorithm, or nearest-neighbour".
>
> I would also emphasise this should definitely also apply to patterns, for
> the same reason: games are likely to use a pattern to render tiles, and
> those should be rendered with the same interpolation as everything else.
>
> Ashley
>
>
>
> On 8 February 2013 12:25, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> I agree we should bring it back.
>>
>> Personally, it would be nice that have a more formal definition of what
>> smoothing actually means so user agents can implement it similarly.
>>
>> Rik
>>
>> On Tue, Feb 5, 2013 at 7:14 AM, Jay Munro <jaymunro at microsoft.com> wrote:
>>
>> > For CR, we took the imageSmoothingEnable feature out because it hadn't
>> > been given a chance to be discussed by the working group. For level 2,
>> I'm
>> > adding it back in, but asking for any discussion that needs to be made
>> > first.
>> >
>> > Silence will be taken to mean there is no objection, but positive
>> > responses are encouraged.  If I don't hear any objections by Monday Feb
>> 11,
>> > I'll check it in.
>> >
>> > The following is the pending check in:
>> >
>> >
>> > @@ -40677,6 +40677,10 @@ dictionary <dfn>TrackEventInit</dfn> :
>> > <span>EventInit</span> {
>> >    // compositing
>> >             attribute unrestricted double <span
>> > title="dom-context-2d-globalAlpha">globalAlpha</span>; // (default 1.0)
>> >             attribute DOMString <span
>> >
>> title="dom-context-2d-globalCompositeOperation">globalCompositeOperation</span>;
>> > // (default source-over)
>> > +
>> > +  // image smoothing
>> > +           attribute boolean <span
>> >
>> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</span>;
>> > // (default true)
>> > +
>> >  <!--
>> >    // v7 we've also received requests for:
>> >    - turning off antialiasing to avoid seams when patterns are painted
>> > next to each other
>> > @@ -40945,7 +40949,8 @@ interface <dfn>Path</dfn> {
>> >
>> >
>> title="dom-context-2d-globalCompositeOperation">globalCompositeOperation</code>,
>> > <code
>> >     title="dom-context-2d-font">font</code>, <code
>> >     title="dom-context-2d-textAlign">textAlign</code>, <code
>> > -   title="dom-context-2d-textBaseline">textBaseline</code>.</li>
>> > +   title="dom-context-2d-textBaseline">textBaseline</code>, <code
>> > +
>> >
>> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>.</li>
>> >    </ul>
>> >
>> >    <p class="note">The <span>current default path</span> and the
>> > @@ -43416,10 +43421,16 @@ try {
>> >
>> >    <p>If the original image data is a bitmap image, the value painted
>> >    at a point in the area of the repetitions is computed by filtering
>> > -  the original image data. The user agent may use any filtering
>> > +  the original image data. If the <code
>> > +
>> >
>>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
>> > +  then the user agent may use any filtering
>> >    algorithm (for example bilinear interpolation or nearest-neighbor).
>> > -  When the filtering algorithm requires a pixel value from outside the
>> > -  original image data, it must instead use the value from wrapping the
>> > +  If the <code
>> > +
>> >
>>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
>> > +  attribute is set to false, the image must be rendered using
>> > +  nearest-neighbor interpolation. When such the filtering algorithm
>> > +  requires a pixel value from outside the original image data, it
>> > +  must instead use the value from wrapping the
>> >    pixel's coordinates to the original image's dimensions. (That is,
>> >    the filter uses 'repeat' behavior, regardless of the value of
>> >    <var title="">repetition</var>.)
>> > @@ -44539,6 +44550,18 @@ v6DVT (also check for '- -' bits in the part
>> > above) -->
>> >    <p class="note">This specification does not define the algorithm to
>> >    use when scaling the image, if necessary.</p>
>> >
>> > +  <p>If the <code
>> > +
>> >
>>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
>> > +  attribute is set to true, then the user agent should attempt to
>> > +  apply a smoothing algorithm to the image data when it is scaled.
>> > +  Otherwise, the image must be rendered using nearest-neighbor
>> > +  interpolation.</p>
>> > +
>> > +  <p class="note">This specification does not define the precise
>> > +  algorithm to use when scaling an image when the <code
>> > +
>> >
>>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
>> > +  attribute is set to true.</p>
>> > +
>> >    <p class="note">When a canvas is drawn onto itself, the <span>drawing
>> >    model</span> requires the source to be copied before the image is
>> drawn
>> >    back onto the canvas, so it is possible to copy parts of a canvas
>> > @@ -46040,6 +46063,36 @@ function AddCloud(data, x, y) { ... }</pre>
>> >
>> >    </div>
>> >
>> > +  <h6>Image smoothing</h6>
>> > +
>> > +  <dl class="domintro">
>> > +
>> > +   <dt><var title="">context</var> . <code
>> >
>> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code> [
>> > = <var title="">value</var> ]</dt>
>> > +
>> > +   <dd>
>> > +
>> > +    <p>Returns whether pattern fills and the <code
>> > +    title="dom-context-2d-drawImage">drawImage()</code> method will
>> > +    attempt to smooth images if they have to rescale them (as opposed
>> > +    to just rendering the images with "big pixels").</p>
>> > +
>> > +    <p>Can be set, to change whether images are smoothed (true) or not
>> > +    (false).</p>
>> > +
>> > +   </dd>
>> > +
>> > +  </dl>
>> > +
>> > +  <div class="impl">
>> > +
>> > +  <p>The <dfn
>> > +
>> >
>>  title="dom-context-2d-imageSmoothingEnabled"><code>imageSmoothingEnabled</code></dfn>
>> > +  attribute, on getting, must return the last value it was set to. On
>> > +  setting, it must be set to the new value. When the
>> > +  <code>CanvasRenderingContext2D</code> object is created, the
>> > +  attribute must be set to true.</p>
>> > +
>> > +  </div>
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>
>

From senorblanco at chromium.org  Tue Feb 12 14:56:49 2013
From: senorblanco at chromium.org (Stephen White)
Date: Tue, 12 Feb 2013 17:56:49 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
Message-ID: <CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>

On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 29 Mar 2012, Jeremy Apthorp wrote:
> > On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp <jeremya at chromium.org
> >wrote:
> > > On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson <ian at hixie.ch> wrote:
> > >> On Fri, 13 Jan 2012, Jeremy Apthorp wrote:
> > >> >
> > >> > I'd like to draw non-antialiased lines in a <canvas>. Currently it
> > >> > seems that the only way to do this is to directly access the pixel
> > >> > data.
> > >> >
> > >> > Is there a reason there's no way to turn off antialiasing?
> > >>
> > >> What's the use case?
> > >
> > > Pixel-art style games.
> >
> > Specifically: even with the new image smoothing stuff in place for
> > drawImage, a 1:2 diagonal line will still be anti-aliased (only the
> > antialiasing will look silly scaled up to 2x).
>
> Do you have an example of a game where lines are drawn using a line API
> without antialiasing, then scaled up? Most "pixel art" games I've seen
> tend to use bitmaps for that kind of thing.
>
>
> On Mon, 12 Nov 2012, Justin Novosad wrote:
> >
> > For many types of apps, DOM-based rendering is uncompetitively slow
> > [so we should make text rendering in canvas more controllable]
>
> This seems like something we should fix, not something we should work
> around by having people use canvas instead. Using canvas has all kinds of
> terrible side-effects, like reducing the likely accessibility of the page,
> making searcheability much worse, etc.
>
> Also, do you have any metrics showing the magnitude of this problem on
> real-world sites that might consider using canvas instead?
>
>
> > If LCD text were enable-able, authors would have to be mindful of a
> > number of caveats in order to avoid rendering artifacts.
>
> Do we have any reason to believe the majority of authors would make the
> right decisions here?
>
> (The main reason we haven't provided control over things like antialiasing
> is that many authors tend to make terribly bad decisions.) (Before anyone
> gets offended, by the way: that you are reading this almost guarantees
> that you are above average in terms of authoring ability.)
>
>
> On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote:
> >
> > We'd have to define what happens when you use subpixel antialiasing
> > "incorrectly", because we can be pretty sure authors will use it
> > incorrectly and expect to get interoperable behavior.
>
> That's certainly true.
>
>
> > Mozilla supports a "mozOpaque" attribute which makes the canvas buffer
> > RGBX (initialized to solid black) and enables subpixel antialiasing for
> > most text drawing. That might be enough to address your use-cases.
>
> I haven't specified this; if other vendors intend to implement this let me
> know and I can spec it. I'm not sure it's worth it though.
>

[blowing the dust off this thread]

Folks on the Chrome team are looking into implementing this attribute, and
would be interested in seeing it spec'ed.

Thanks,

Stephen


>
> On Wed, 14 Nov 2012, Robert O'Callahan wrote:
> > On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad <junov at chromium.org>
> wrote:
> > >
> > > Are there precedents for exposing features with documented caveats?
> > > (excluding caveats that were discovered after the fact)
> >
> > Yes, and many of them have been extremely problematic, because Web
> > authors will ignore the caveats.
>
> Right. I'd really like to avoid adding more if we can help it.
>
>
> On Wed, 14 Nov 2012, Justin Novosad wrote:
> >
> > There is a recent improvement in Chrome called "deferred 2D canvas
> > rendering" (enabled by default as of Chrome 23).  It is a mechanism that
> > records 2d canvas commands during JS execution, and only executes them
> > for real when the render buffer needs to be resolved (draw to screen,
> > getImageData, toDataURL, etc.).  If you want to check it out, the guts
> > are in Skia: SkGPipe is a sort of FIFO for graphics commands,
> > SkDeferredCanvas is a wrapper that manages the GPipe and automatically
> > flushes it and applies some command culling optimizations.
> >
> > So to come back to the problem of with and without subpixel AA buffers:
> > if rendering is deferred, the non-AA buffer would never get rasterized
> > (and possibly never even allocated), unless it needs to be.  Obviously
> > there are practical limitations, for example we cannot store an
> > unlimited stream of recorded commands, so if the canvas draws
> > indefinitely without ever being cleared, at some point we have to
> > rasterize the non-AA buffer just so that we can safely discard the
> > recording data. Also, if at record time the necessary conditions for
> > subpixel AA are not met, perhaps we just forget about it.
> >
> > I admit this is a complex solution for implementors, but it makes the
> > management of subpixel-AA safety transparent to web authors.
>
> I think it'd be reasonable (for some definition of reasonable that
> relates to whether it's compatible with the spec, anyway) for implementors
> to do this today, without having to expose any control to the author.
>
>
> On Thu, 15 Nov 2012, Fred Andrews wrote:
> >
> > The canvas that scripts draw into could be over-sized with the UA down
> > sampling this to fit the target size and taking into account the
> > sub-pixel screen layout when doing so.
>
> On Thu, 15 Nov 2012, Justin Novosad wrote:
> >
> > Obviously, that would be costly (x3 pixels), but I think it is a very
> > realistic solution and relatively low hanging fruit. The over-sizing of
> > the canvas would have to be handled under the hood by the UA though,
> > because it depends on LCD component ordering and orientation, which
> > means querying the OS/display driver. A lot of the kinks with the
> > over-sized canvas approach have already been ironed out for solving the
> > problem of High-DPI support ( put/getImageDataHD ), and I like the idea
> > of unifying the two. Implementing this would mostly be a matter of
> > adding per color component compositing of canvases. Also, the pixel
> > aspect ratio would have to be taken into account for line drawing.
>
> getImageDataHD() requires that the pixels be square, but so long as that
> is taken into consideration (e.g. by dropping down to square pixels if the
> author calls putImageDataHD()) I think this could probably be made to work
> within the spec's current requirements.
>
>
> > Regarding the concerns about accessibility, I think the problem can be
> > solved by using HitRegions with labels.
>
> Oh it _can_ be solved. That's not the problem. Accessibility is not about
> what is _possible_, it's about what actually _is_. Most authors,
> realistically speaking, aren't goin to be using hit regions sufficiently
> for us to declare victory here.
>
>
> > Come to think of it, there should be an option to make the UA do this
> > automatically: create a HitRegion with a label every time text is drawn
> > to a canvas.
>
> I considered doing that, but it gets really fiddly when you're doing
> things like text that fades over multiple frames. In the end I decided
> that the magic wasn't worth it, as it would likely screw up more often
> than it would actually help.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

From cabanier at gmail.com  Tue Feb 12 15:14:24 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Tue, 12 Feb 2013 15:14:24 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
Message-ID: <CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>

On Tue, Feb 12, 2013 at 2:56 PM, Stephen White <senorblanco at chromium.org>wrote:

> On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson <ian at hixie.ch> wrote:
>
> > On Thu, 29 Mar 2012, Jeremy Apthorp wrote:
> > > On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp <jeremya at chromium.org
> > >wrote:
> > > > On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson <ian at hixie.ch> wrote:
> > > >> On Fri, 13 Jan 2012, Jeremy Apthorp wrote:
> > > >> >
> > > >> > I'd like to draw non-antialiased lines in a <canvas>. Currently it
> > > >> > seems that the only way to do this is to directly access the pixel
> > > >> > data.
> > > >> >
> > > >> > Is there a reason there's no way to turn off antialiasing?
> > > >>
> > > >> What's the use case?
> > > >
> > > > Pixel-art style games.
> > >
> > > Specifically: even with the new image smoothing stuff in place for
> > > drawImage, a 1:2 diagonal line will still be anti-aliased (only the
> > > antialiasing will look silly scaled up to 2x).
> >
> > Do you have an example of a game where lines are drawn using a line API
> > without antialiasing, then scaled up? Most "pixel art" games I've seen
> > tend to use bitmaps for that kind of thing.
> >
> >
> > On Mon, 12 Nov 2012, Justin Novosad wrote:
> > >
> > > For many types of apps, DOM-based rendering is uncompetitively slow
> > > [so we should make text rendering in canvas more controllable]
> >
> > This seems like something we should fix, not something we should work
> > around by having people use canvas instead. Using canvas has all kinds of
> > terrible side-effects, like reducing the likely accessibility of the
> page,
> > making searcheability much worse, etc.
> >
> > Also, do you have any metrics showing the magnitude of this problem on
> > real-world sites that might consider using canvas instead?
> >
> >
> > > If LCD text were enable-able, authors would have to be mindful of a
> > > number of caveats in order to avoid rendering artifacts.
> >
> > Do we have any reason to believe the majority of authors would make the
> > right decisions here?
> >
> > (The main reason we haven't provided control over things like
> antialiasing
> > is that many authors tend to make terribly bad decisions.) (Before anyone
> > gets offended, by the way: that you are reading this almost guarantees
> > that you are above average in terms of authoring ability.)
> >
> >
> > On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote:
> > >
> > > We'd have to define what happens when you use subpixel antialiasing
> > > "incorrectly", because we can be pretty sure authors will use it
> > > incorrectly and expect to get interoperable behavior.
> >
> > That's certainly true.
> >
> >
> > > Mozilla supports a "mozOpaque" attribute which makes the canvas buffer
> > > RGBX (initialized to solid black) and enables subpixel antialiasing for
> > > most text drawing. That might be enough to address your use-cases.
> >
> > I haven't specified this; if other vendors intend to implement this let
> me
> > know and I can spec it. I'm not sure it's worth it though.
> >
>
> [blowing the dust off this thread]
>
> Folks on the Chrome team are looking into implementing this attribute, and
> would be interested in seeing it spec'ed.


What are you implementing? Initializing the canvas to black or subpixel
antialiasing?


>
> >
> > On Wed, 14 Nov 2012, Robert O'Callahan wrote:
> > > On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad <junov at chromium.org>
> > wrote:
> > > >
> > > > Are there precedents for exposing features with documented caveats?
> > > > (excluding caveats that were discovered after the fact)
> > >
> > > Yes, and many of them have been extremely problematic, because Web
> > > authors will ignore the caveats.
> >
> > Right. I'd really like to avoid adding more if we can help it.
> >
> >
> > On Wed, 14 Nov 2012, Justin Novosad wrote:
> > >
> > > There is a recent improvement in Chrome called "deferred 2D canvas
> > > rendering" (enabled by default as of Chrome 23).  It is a mechanism
> that
> > > records 2d canvas commands during JS execution, and only executes them
> > > for real when the render buffer needs to be resolved (draw to screen,
> > > getImageData, toDataURL, etc.).  If you want to check it out, the guts
> > > are in Skia: SkGPipe is a sort of FIFO for graphics commands,
> > > SkDeferredCanvas is a wrapper that manages the GPipe and automatically
> > > flushes it and applies some command culling optimizations.
> > >
> > > So to come back to the problem of with and without subpixel AA buffers:
> > > if rendering is deferred, the non-AA buffer would never get rasterized
> > > (and possibly never even allocated), unless it needs to be.  Obviously
> > > there are practical limitations, for example we cannot store an
> > > unlimited stream of recorded commands, so if the canvas draws
> > > indefinitely without ever being cleared, at some point we have to
> > > rasterize the non-AA buffer just so that we can safely discard the
> > > recording data. Also, if at record time the necessary conditions for
> > > subpixel AA are not met, perhaps we just forget about it.
> > >
> > > I admit this is a complex solution for implementors, but it makes the
> > > management of subpixel-AA safety transparent to web authors.
> >
> > I think it'd be reasonable (for some definition of reasonable that
> > relates to whether it's compatible with the spec, anyway) for
> implementors
> > to do this today, without having to expose any control to the author.
> >
> >
> > On Thu, 15 Nov 2012, Fred Andrews wrote:
> > >
> > > The canvas that scripts draw into could be over-sized with the UA down
> > > sampling this to fit the target size and taking into account the
> > > sub-pixel screen layout when doing so.
> >
> > On Thu, 15 Nov 2012, Justin Novosad wrote:
> > >
> > > Obviously, that would be costly (x3 pixels), but I think it is a very
> > > realistic solution and relatively low hanging fruit. The over-sizing of
> > > the canvas would have to be handled under the hood by the UA though,
> > > because it depends on LCD component ordering and orientation, which
> > > means querying the OS/display driver. A lot of the kinks with the
> > > over-sized canvas approach have already been ironed out for solving the
> > > problem of High-DPI support ( put/getImageDataHD ), and I like the idea
> > > of unifying the two. Implementing this would mostly be a matter of
> > > adding per color component compositing of canvases. Also, the pixel
> > > aspect ratio would have to be taken into account for line drawing.
> >
> > getImageDataHD() requires that the pixels be square, but so long as that
> > is taken into consideration (e.g. by dropping down to square pixels if
> the
> > author calls putImageDataHD()) I think this could probably be made to
> work
> > within the spec's current requirements.
> >
> >
> > > Regarding the concerns about accessibility, I think the problem can be
> > > solved by using HitRegions with labels.
> >
> > Oh it _can_ be solved. That's not the problem. Accessibility is not about
> > what is _possible_, it's about what actually _is_. Most authors,
> > realistically speaking, aren't goin to be using hit regions sufficiently
> > for us to declare victory here.
> >
> >
> > > Come to think of it, there should be an option to make the UA do this
> > > automatically: create a HitRegion with a label every time text is drawn
> > > to a canvas.
> >
> > I considered doing that, but it gets really fiddly when you're doing
> > things like text that fades over multiple frames. In the end I decided
> > that the magic wasn't worth it, as it would likely screw up more often
> > than it would actually help.
> >
> > --
> > Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> > http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> > Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> >
>

From esprehn at gmail.com  Tue Feb 12 15:46:28 2013
From: esprehn at gmail.com (Elliott Sprehn)
Date: Tue, 12 Feb 2013 15:46:28 -0800
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
In-Reply-To: <CABZUbM35r-oFE1B4ZtAAAb=gUQcL_xujjCHniksYcsbhx1POsg@mail.gmail.com>
References: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
	<CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>
	<CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>
	<CABirCh_bR9XvOCEjX_8TyJq+5juzsqr3_7vjkwYen_NF_3bJPw@mail.gmail.com>
	<CABZUbM35r-oFE1B4ZtAAAb=gUQcL_xujjCHniksYcsbhx1POsg@mail.gmail.com>
Message-ID: <CAPJYB1ifqP2x4p90yZoCrXCCCbc4Y0V40eke7M3DdEmfGy-urw@mail.gmail.com>

On Mon, Feb 11, 2013 at 10:56 PM, Garrett Smith <dhtmlkitchen at gmail.com>wrote:

> On 2/9/13, Glenn Maynard <glenn at zewt.org> wrote:
> > On Sat, Feb 9, 2013 at 10:43 AM, Tab Atkins Jr.
> > <jackalmage at gmail.com>wrote:
> >
> >> That said, there *are* still some isolated use-cases for polling.  ^_^
> >>  When an event-based approach would potentially deliver far too many
> >> events, with separation between them perhaps less than 1ms, exposing a
> >> polling-based API instead can be useful.  I haven't followed the
> >> Gamepad API lately, but I know this was at least considered for some
> >> of the types of feedback, such as the exact position of joysticks or
> >> pressure on buttons, both of which can change very rapidly in
> >> realistic scenarios.
> >>
> >
> > A polling API doesn't help you there, since you can't poll every 1ms in
> > script (certainly not in the UI thread, and probably not reliably even
> in a
> > worker).  In fact, since setTimeout will be throttled but events fired by
> > the browser don't have to be, events can be sent faster than you can poll
> > in the UI thread (though this is probably a bad idea most of the time).
> >
> > The solution is probably a matter of buffering the changes, and limiting
> > how frequently "something was buffered" events fire.
> Are you proposing event quantization threshold?
>

There's no reason to have a threshold. We should just batch and deliver at
checkpoints like end-of-microtask (MutationObserver) or rAf (Animations).

- E

From dbaron at dbaron.org  Tue Feb 12 21:06:37 2013
From: dbaron at dbaron.org (L. David Baron)
Date: Tue, 12 Feb 2013 21:06:37 -0800
Subject: [whatwg] scoped style sheets and @-rules
In-Reply-To: <CAAWBYDCkDWH6hMvWztuTdqVXvADhd768NdVxnGd=TXTe55ApZA@mail.gmail.com>
References: <20130121143923.GA6959@crum.dbaron.org>
	<CAAWBYDCkDWH6hMvWztuTdqVXvADhd768NdVxnGd=TXTe55ApZA@mail.gmail.com>
Message-ID: <20130213050637.GA29746@crum.dbaron.org>

On Monday 2013-01-21 11:17 -0800, Tab Atkins Jr. wrote:
> On Mon, Jan 21, 2013 at 6:39 AM, L. David Baron <dbaron at dbaron.org> wrote:
> > Thus I think the specification should mandate that @keyframes and
> > @font-face are ignored in scoped style sheets, just like @page.
> >
> > I think it would also be good if the specification left the effects
> > of unknown @-rules undefined until whether they should be supported
> > can be properly considered.
> 
> Should we ignore them entirely, or just ignore the scoped-ness and
> have them fill in the global dictionary?

I prefer ignoring them entirely, since authors will notice if things
aren't working as expected.

-David

-- 
?   L. David Baron                         http://dbaron.org/   ?
?   Mozilla                           http://www.mozilla.org/   ?

From Bronislav.Klucka at bauglir.com  Wed Feb 13 00:35:17 2013
From: Bronislav.Klucka at bauglir.com (=?UTF-8?B?QnJvbmlzbGF2IEtsdcSNa2E=?=)
Date: Wed, 13 Feb 2013 09:35:17 +0100
Subject: [whatwg] Fwd: Re: Why do we have <input type='month'> and <input
 type='week'>?
In-Reply-To: <511B47F5.1000500@bauglir.com>
References: <511B47F5.1000500@bauglir.com>
Message-ID: <511B5045.9020304@bauglir.com>




-------- Original Message --------
Subject: 	Re: [whatwg] Why do we have <input type='month'> and <input 
type='week'>?
Date: 	Wed, 13 Feb 2013 08:59:49 +0100
From: 	Bronislav Klu?ka <Bronislav.Klucka at bauglir.com>
To: 	Jukka K. Korpela <jkorpela at cs.tut.fi>



On 12.2.2013 18:39, Jukka K. Korpela wrote:
> 2013-02-12 19:26, Tab Atkins Jr. wrote:
>
>> The fact that authors today have a random assortment of displays for
>> the exact same feature (credit card expirys) is something that would
>> be great to fix, not bemoan as a loss to the world. ^_^
>
> Well, maybe, from some point of view, but is there really something to
> be fixed, and is it probable that <input type=month> would fix it?
>
> I have seen many input widgets for such data and used them a lot in
> test purchases. In general, the more advanced they try to be, the more
> annoying they get. I can type "03/15", or whatever reads in the card,
> rather fast. But if I have to pick things up from dropdowns or click
> on something in a calendar picker, I surely hope I won't need to do
> this a dozen more times.
Well you can type 03/15, regular user from Czech republic would newer
write it as such. And how should I know,  what would user in Israel,
India, Chile wrote?
>
> What are the odds that browser vendors will implement <input
> type=month> in a simple manner that allows fast typing as one input
> method? Rather small I think.
>
> This would make the most obvious, and perhaps the most common, use for
> <input type=month> a case *against* it.  Credit card expiry month is
> best handled with a text input field, with suitable checks on the
> input string. There may be *other* cases where graphic widgets are
> good when selecting a month, but authors can use libraries for such
> purpose, and I don't see any particular reason why this should be
> standardized across pages but not across browsers.
>
> Even if <input type=month> became widely supported, many, probably
> most, authors will keep using libraries or their own code, because
> they get consistent look and feel and functionality across browsers.
> Some authors would be misled into using <input type=month> for any
> month input because that's "logical" or "semantic" (as it is in a
> sense), but this will create questionable user experience in many
> common cases.
I dont know, how about you, but I'm using libraries because of missing
functionality and I do not want to.


Brona




From ian at invigoreight.com  Wed Feb 13 02:31:32 2013
From: ian at invigoreight.com (Ian Yang)
Date: Wed, 13 Feb 2013 18:31:32 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
Message-ID: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>

Hi editors and all other folks,

I saw the SitePoint article "Introducing the New HTML5 <main>
Element<http://www.sitepoint.com/html5-main-element/>"
yesterday. Does that mean <main> element has been approved by all editors
of the working group?

However, in spec, it still says that <main> element is not a sectioning
element. That means, in document outline, main content will form another
tree structure instead of appearing under the original website tree
structure. Can we have somebody advise on this? Is there a special
consideration to not making <main> a sectioning element?


Sincerely,
Ian Yang

From glenn at zewt.org  Wed Feb 13 06:35:22 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Wed, 13 Feb 2013 08:35:22 -0600
Subject: [whatwg] Why do we have <input type='month'> and <input
	type='week'>?
In-Reply-To: <511A79F1.5050501@lamouri.fr>
References: <510988C1.1040900@lamouri.fr> <op.wrry8kurh8on37@bruce-pc>
	<CABirCh_ua8cumCqZcASOTOdwCmsi0yPdVYvoRT23eBstszdy2A@mail.gmail.com>
	<511A79F1.5050501@lamouri.fr>
Message-ID: <CABirCh9QfvN8HYqAdYJVobhthnQ7McCQbmbBO5UsjcCy8PWkZQ@mail.gmail.com>

On Tue, Feb 12, 2013 at 11:20 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:

> Regarding week, I still believe that the use cases are pretty weak but
>
the most important issue is that there is no good UI for this on Mobile
> AFAIK.
>

There aren't stock widgets, but this isn't a hard UI problem to solve.  For
example, two panes: a year scroller and a scroller containing a vertical
strip of calendars, where you scroll vertically to the row corresponding
with the week you want to select.

A trickier issue for weeks is which day the week starts on.  To me,
calendar weeks start on Sunday and end on Saturday.  I'd find it weird to
be shown a Monday-aligned calendar, but this is hard to localize, since the
browser can't return anything but Monday-based week numbers.  This would
probably work better if the result was a date, not a week number, so it
could return both Sundays and Mondays, but this might lead to localization
bugs.

-- 
Glenn Maynard

From senorblanco at chromium.org  Wed Feb 13 07:45:34 2013
From: senorblanco at chromium.org (Stephen White)
Date: Wed, 13 Feb 2013 10:45:34 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
Message-ID: <CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>

On Tue, Feb 12, 2013 at 6:14 PM, Rik Cabanier <cabanier at gmail.com> wrote:

>
>
> On Tue, Feb 12, 2013 at 2:56 PM, Stephen White <senorblanco at chromium.org>wrote:
>
>> On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson <ian at hixie.ch> wrote:
>>
>> > On Thu, 29 Mar 2012, Jeremy Apthorp wrote:
>> > > On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp <
>> jeremya at chromium.org
>> > >wrote:
>> > > > On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson <ian at hixie.ch> wrote:
>> > > >> On Fri, 13 Jan 2012, Jeremy Apthorp wrote:
>> > > >> >
>> > > >> > I'd like to draw non-antialiased lines in a <canvas>. Currently
>> it
>> > > >> > seems that the only way to do this is to directly access the
>> pixel
>> > > >> > data.
>> > > >> >
>> > > >> > Is there a reason there's no way to turn off antialiasing?
>> > > >>
>> > > >> What's the use case?
>> > > >
>> > > > Pixel-art style games.
>> > >
>> > > Specifically: even with the new image smoothing stuff in place for
>> > > drawImage, a 1:2 diagonal line will still be anti-aliased (only the
>> > > antialiasing will look silly scaled up to 2x).
>> >
>> > Do you have an example of a game where lines are drawn using a line API
>> > without antialiasing, then scaled up? Most "pixel art" games I've seen
>> > tend to use bitmaps for that kind of thing.
>> >
>> >
>> > On Mon, 12 Nov 2012, Justin Novosad wrote:
>> > >
>> > > For many types of apps, DOM-based rendering is uncompetitively slow
>> > > [so we should make text rendering in canvas more controllable]
>> >
>> > This seems like something we should fix, not something we should work
>> > around by having people use canvas instead. Using canvas has all kinds
>> of
>> > terrible side-effects, like reducing the likely accessibility of the
>> page,
>> > making searcheability much worse, etc.
>> >
>> > Also, do you have any metrics showing the magnitude of this problem on
>> > real-world sites that might consider using canvas instead?
>> >
>> >
>> > > If LCD text were enable-able, authors would have to be mindful of a
>> > > number of caveats in order to avoid rendering artifacts.
>> >
>> > Do we have any reason to believe the majority of authors would make the
>> > right decisions here?
>> >
>> > (The main reason we haven't provided control over things like
>> antialiasing
>> > is that many authors tend to make terribly bad decisions.) (Before
>> anyone
>> > gets offended, by the way: that you are reading this almost guarantees
>> > that you are above average in terms of authoring ability.)
>> >
>> >
>> > On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote:
>> > >
>> > > We'd have to define what happens when you use subpixel antialiasing
>> > > "incorrectly", because we can be pretty sure authors will use it
>> > > incorrectly and expect to get interoperable behavior.
>> >
>> > That's certainly true.
>> >
>> >
>> > > Mozilla supports a "mozOpaque" attribute which makes the canvas buffer
>> > > RGBX (initialized to solid black) and enables subpixel antialiasing
>> for
>> > > most text drawing. That might be enough to address your use-cases.
>> >
>> > I haven't specified this; if other vendors intend to implement this let
>> me
>> > know and I can spec it. I'm not sure it's worth it though.
>> >
>>
>> [blowing the dust off this thread]
>>
>> Folks on the Chrome team are looking into implementing this attribute, and
>> would be interested in seeing it spec'ed.
>
>
> What are you implementing? Initializing the canvas to black or subpixel
> antialiasing?
>

We're interested in both aspects:  the opportunity for culling and blending
optimizations at composite time, as well as enabling subpixel AA.

Stephen

>
>
>>
>> >
>> > On Wed, 14 Nov 2012, Robert O'Callahan wrote:
>> > > On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad <junov at chromium.org>
>> > wrote:
>> > > >
>> > > > Are there precedents for exposing features with documented caveats?
>> > > > (excluding caveats that were discovered after the fact)
>> > >
>> > > Yes, and many of them have been extremely problematic, because Web
>> > > authors will ignore the caveats.
>> >
>> > Right. I'd really like to avoid adding more if we can help it.
>> >
>> >
>> > On Wed, 14 Nov 2012, Justin Novosad wrote:
>> > >
>> > > There is a recent improvement in Chrome called "deferred 2D canvas
>> > > rendering" (enabled by default as of Chrome 23).  It is a mechanism
>> that
>> > > records 2d canvas commands during JS execution, and only executes them
>> > > for real when the render buffer needs to be resolved (draw to screen,
>> > > getImageData, toDataURL, etc.).  If you want to check it out, the guts
>> > > are in Skia: SkGPipe is a sort of FIFO for graphics commands,
>> > > SkDeferredCanvas is a wrapper that manages the GPipe and automatically
>> > > flushes it and applies some command culling optimizations.
>> > >
>> > > So to come back to the problem of with and without subpixel AA
>> buffers:
>> > > if rendering is deferred, the non-AA buffer would never get rasterized
>> > > (and possibly never even allocated), unless it needs to be.  Obviously
>> > > there are practical limitations, for example we cannot store an
>> > > unlimited stream of recorded commands, so if the canvas draws
>> > > indefinitely without ever being cleared, at some point we have to
>> > > rasterize the non-AA buffer just so that we can safely discard the
>> > > recording data. Also, if at record time the necessary conditions for
>> > > subpixel AA are not met, perhaps we just forget about it.
>> > >
>> > > I admit this is a complex solution for implementors, but it makes the
>> > > management of subpixel-AA safety transparent to web authors.
>> >
>> > I think it'd be reasonable (for some definition of reasonable that
>> > relates to whether it's compatible with the spec, anyway) for
>> implementors
>> > to do this today, without having to expose any control to the author.
>> >
>> >
>> > On Thu, 15 Nov 2012, Fred Andrews wrote:
>> > >
>> > > The canvas that scripts draw into could be over-sized with the UA down
>> > > sampling this to fit the target size and taking into account the
>> > > sub-pixel screen layout when doing so.
>> >
>> > On Thu, 15 Nov 2012, Justin Novosad wrote:
>> > >
>> > > Obviously, that would be costly (x3 pixels), but I think it is a very
>> > > realistic solution and relatively low hanging fruit. The over-sizing
>> of
>> > > the canvas would have to be handled under the hood by the UA though,
>> > > because it depends on LCD component ordering and orientation, which
>> > > means querying the OS/display driver. A lot of the kinks with the
>> > > over-sized canvas approach have already been ironed out for solving
>> the
>> > > problem of High-DPI support ( put/getImageDataHD ), and I like the
>> idea
>> > > of unifying the two. Implementing this would mostly be a matter of
>> > > adding per color component compositing of canvases. Also, the pixel
>> > > aspect ratio would have to be taken into account for line drawing.
>> >
>> > getImageDataHD() requires that the pixels be square, but so long as that
>> > is taken into consideration (e.g. by dropping down to square pixels if
>> the
>> > author calls putImageDataHD()) I think this could probably be made to
>> work
>> > within the spec's current requirements.
>> >
>> >
>> > > Regarding the concerns about accessibility, I think the problem can be
>> > > solved by using HitRegions with labels.
>> >
>> > Oh it _can_ be solved. That's not the problem. Accessibility is not
>> about
>> > what is _possible_, it's about what actually _is_. Most authors,
>> > realistically speaking, aren't goin to be using hit regions sufficiently
>> > for us to declare victory here.
>> >
>> >
>> > > Come to think of it, there should be an option to make the UA do this
>> > > automatically: create a HitRegion with a label every time text is
>> drawn
>> > > to a canvas.
>> >
>> > I considered doing that, but it gets really fiddly when you're doing
>> > things like text that fades over multiple frames. In the end I decided
>> > that the magic wasn't worth it, as it would likely screw up more often
>> > than it would actually help.
>> >
>> > --
>> > Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> > http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._
>> ,.
>> > Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>> >
>>
>
>

From ehs at pobox.com  Wed Feb 13 08:18:20 2013
From: ehs at pobox.com (Ed Summers)
Date: Wed, 13 Feb 2013 11:18:20 -0500
Subject: [whatwg] itemtypes from same vocabulary
Message-ID: <CABzDd=70TtoPhqQzpop+Y8YeeOM_SCwi8+hog=r-4yMn3G79zw@mail.gmail.com>

Hi all,

I am looking for some guidance about the use of multiple itemtypes in
microdata [1], specifically the phrase "defined to use the same
vocabulary" in:

"""
The item types must all be types defined in applicable specifications
and must all be defined to use the same vocabulary.
"""

For example, does this mean that I can't say:

<div itemscope itemtype="http://acme.com/Foo http://zenith.com/Bar"> ... </div>

The reason I ask is that there is some desire over in the schema.org
community [2] to provide a mechanism for schema.org to be specialized.
For example, in the case of an audiobook:

<div itemscope itemtype="http://schema.org/Book
http://www.productontology.org/id/Audiobook"> ... </div>

The idea being not to overload schema.org with more vocabulary, and to
let vocabularies grow a bit more organically. This schema.org group is
currently thinking of using a one off property additionalType that
would be used like so:

<div itemscope itemtype="http://schema.org/Book">
  <link itemprop="additionalType"
href="http://www.productontology.org/id/Audiobook">
  ...
</div>

I personally find this to be kind of distasteful since it replicates
the mechanics that microdata's itemtype already offers.

So, my question: is it the case that itemtype cannot reference types
in different vocabularies like the example above? If so, I'm curious
to know what the rationale was, and if perhaps it could be relaxed.

//Ed

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#items
[2] http://lists.w3.org/Archives/Public/public-schemabibex/2013Feb/0000.html

From lin.w.clark at gmail.com  Wed Feb 13 08:23:59 2013
From: lin.w.clark at gmail.com (Lin Clark)
Date: Wed, 13 Feb 2013 11:23:59 -0500
Subject: [whatwg] itemtypes from same vocabulary
In-Reply-To: <CABzDd=70TtoPhqQzpop+Y8YeeOM_SCwi8+hog=r-4yMn3G79zw@mail.gmail.com>
References: <CABzDd=70TtoPhqQzpop+Y8YeeOM_SCwi8+hog=r-4yMn3G79zw@mail.gmail.com>
Message-ID: <CACho_Av7dsGmxUozJv6Aj1xNhZJh9ESSujWKcA_KtX5AcT_Feg@mail.gmail.com>

Itemtype cannot reference different vocabs. Here are two relevant
discussions that I know of, one with Hixie and the other with the HTML Data
Task Force.

http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0364.html
http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0072.html


On Wed, Feb 13, 2013 at 11:18 AM, Ed Summers <ehs at pobox.com> wrote:

> Hi all,
>
> I am looking for some guidance about the use of multiple itemtypes in
> microdata [1], specifically the phrase "defined to use the same
> vocabulary" in:
>
> """
> The item types must all be types defined in applicable specifications
> and must all be defined to use the same vocabulary.
> """
>
> For example, does this mean that I can't say:
>
> <div itemscope itemtype="http://acme.com/Foo http://zenith.com/Bar"> ...
> </div>
>
> The reason I ask is that there is some desire over in the schema.org
> community [2] to provide a mechanism for schema.org to be specialized.
> For example, in the case of an audiobook:
>
> <div itemscope itemtype="http://schema.org/Book
> http://www.productontology.org/id/Audiobook"> ... </div>
>
> The idea being not to overload schema.org with more vocabulary, and to
> let vocabularies grow a bit more organically. This schema.org group is
> currently thinking of using a one off property additionalType that
> would be used like so:
>
> <div itemscope itemtype="http://schema.org/Book">
>   <link itemprop="additionalType"
> href="http://www.productontology.org/id/Audiobook">
>   ...
> </div>
>
> I personally find this to be kind of distasteful since it replicates
> the mechanics that microdata's itemtype already offers.
>
> So, my question: is it the case that itemtype cannot reference types
> in different vocabularies like the example above? If so, I'm curious
> to know what the rationale was, and if perhaps it could be relaxed.
>
> //Ed
>
> [1]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#items
> [2]
> http://lists.w3.org/Archives/Public/public-schemabibex/2013Feb/0000.html
>



-- 
Lin Clark
Drupal Consultant

lin-clark.com
twitter.com/linclark

From ehs at pobox.com  Wed Feb 13 08:29:05 2013
From: ehs at pobox.com (Ed Summers)
Date: Wed, 13 Feb 2013 11:29:05 -0500
Subject: [whatwg] itemtypes from same vocabulary
In-Reply-To: <CACho_Av7dsGmxUozJv6Aj1xNhZJh9ESSujWKcA_KtX5AcT_Feg@mail.gmail.com>
References: <CABzDd=70TtoPhqQzpop+Y8YeeOM_SCwi8+hog=r-4yMn3G79zw@mail.gmail.com>
	<CACho_Av7dsGmxUozJv6Aj1xNhZJh9ESSujWKcA_KtX5AcT_Feg@mail.gmail.com>
Message-ID: <CABzDd=6C_WQo9uyVowX+tBGvijMGx7VRvbeoRQKtaF4uHwduBQ@mail.gmail.com>

Hi Lin,

I'm confused because it looks like Microdata currently allows multiple
itemtypes to be expressed:

"""
The itemtype attribute, if specified, must have a value that is an
unordered set of unique space-separated tokens that are
case-sensitive, each of which is a valid URL that is an absolute URL,
and all of which are defined to use the same vocabulary. The
attribute's value must have at least one token. [1]
"""

I am seeking clarification about what is meant by 'same vocabulary',
the rationale, and whether it can be relaxed.

//Ed

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#items

On Wed, Feb 13, 2013 at 11:23 AM, Lin Clark <lin.w.clark at gmail.com> wrote:
> Itemtype cannot reference different vocabs. Here are two relevant
> discussions that I know of, one with Hixie and the other with the HTML Data
> Task Force.
>
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0364.html
> http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0072.html
>
>
> On Wed, Feb 13, 2013 at 11:18 AM, Ed Summers <ehs at pobox.com> wrote:
>>
>> Hi all,
>>
>> I am looking for some guidance about the use of multiple itemtypes in
>> microdata [1], specifically the phrase "defined to use the same
>> vocabulary" in:
>>
>> """
>> The item types must all be types defined in applicable specifications
>> and must all be defined to use the same vocabulary.
>> """
>>
>> For example, does this mean that I can't say:
>>
>> <div itemscope itemtype="http://acme.com/Foo http://zenith.com/Bar"> ...
>> </div>
>>
>> The reason I ask is that there is some desire over in the schema.org
>> community [2] to provide a mechanism for schema.org to be specialized.
>> For example, in the case of an audiobook:
>>
>> <div itemscope itemtype="http://schema.org/Book
>> http://www.productontology.org/id/Audiobook"> ... </div>
>>
>> The idea being not to overload schema.org with more vocabulary, and to
>> let vocabularies grow a bit more organically. This schema.org group is
>> currently thinking of using a one off property additionalType that
>> would be used like so:
>>
>> <div itemscope itemtype="http://schema.org/Book">
>>   <link itemprop="additionalType"
>> href="http://www.productontology.org/id/Audiobook">
>>   ...
>> </div>
>>
>> I personally find this to be kind of distasteful since it replicates
>> the mechanics that microdata's itemtype already offers.
>>
>> So, my question: is it the case that itemtype cannot reference types
>> in different vocabularies like the example above? If so, I'm curious
>> to know what the rationale was, and if perhaps it could be relaxed.
>>
>> //Ed
>>
>> [1]
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#items
>> [2]
>> http://lists.w3.org/Archives/Public/public-schemabibex/2013Feb/0000.html
>
>
>
>
> --
> Lin Clark
> Drupal Consultant
>
> lin-clark.com
> twitter.com/linclark

From lin.w.clark at gmail.com  Wed Feb 13 08:36:58 2013
From: lin.w.clark at gmail.com (Lin Clark)
Date: Wed, 13 Feb 2013 11:36:58 -0500
Subject: [whatwg] itemtypes from same vocabulary
In-Reply-To: <CABzDd=6C_WQo9uyVowX+tBGvijMGx7VRvbeoRQKtaF4uHwduBQ@mail.gmail.com>
References: <CABzDd=70TtoPhqQzpop+Y8YeeOM_SCwi8+hog=r-4yMn3G79zw@mail.gmail.com>
	<CACho_Av7dsGmxUozJv6Aj1xNhZJh9ESSujWKcA_KtX5AcT_Feg@mail.gmail.com>
	<CABzDd=6C_WQo9uyVowX+tBGvijMGx7VRvbeoRQKtaF4uHwduBQ@mail.gmail.com>
Message-ID: <CACho_At=xBDkwcNV5AssDbMfsdk1FtjEFBSa7AM1fVxohy46Rg@mail.gmail.com>

Sorry if it wasn't clear, at the time that those discussions took place,
only one itemtype could be used. Since then, the spec was changed to allow
multiple itemtypes from the same vocabulary.

However, both discussions also touch on the issue of using multiple
vocabularies in itemtype. For example, my response [1] in the first.

[1]
http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0383.html


On Wed, Feb 13, 2013 at 11:29 AM, Ed Summers <ehs at pobox.com> wrote:

> Hi Lin,
>
> I'm confused because it looks like Microdata currently allows multiple
> itemtypes to be expressed:
>
> """
> The itemtype attribute, if specified, must have a value that is an
> unordered set of unique space-separated tokens that are
> case-sensitive, each of which is a valid URL that is an absolute URL,
> and all of which are defined to use the same vocabulary. The
> attribute's value must have at least one token. [1]
> """
>
> I am seeking clarification about what is meant by 'same vocabulary',
> the rationale, and whether it can be relaxed.
>
> //Ed
>
> [1]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#items
>
> On Wed, Feb 13, 2013 at 11:23 AM, Lin Clark <lin.w.clark at gmail.com> wrote:
> > Itemtype cannot reference different vocabs. Here are two relevant
> > discussions that I know of, one with Hixie and the other with the HTML
> Data
> > Task Force.
> >
> >
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0364.html
> >
> http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0072.html
> >
> >
> > On Wed, Feb 13, 2013 at 11:18 AM, Ed Summers <ehs at pobox.com> wrote:
> >>
> >> Hi all,
> >>
> >> I am looking for some guidance about the use of multiple itemtypes in
> >> microdata [1], specifically the phrase "defined to use the same
> >> vocabulary" in:
> >>
> >> """
> >> The item types must all be types defined in applicable specifications
> >> and must all be defined to use the same vocabulary.
> >> """
> >>
> >> For example, does this mean that I can't say:
> >>
> >> <div itemscope itemtype="http://acme.com/Foo http://zenith.com/Bar">
> ...
> >> </div>
> >>
> >> The reason I ask is that there is some desire over in the schema.org
> >> community [2] to provide a mechanism for schema.org to be specialized.
> >> For example, in the case of an audiobook:
> >>
> >> <div itemscope itemtype="http://schema.org/Book
> >> http://www.productontology.org/id/Audiobook"> ... </div>
> >>
> >> The idea being not to overload schema.org with more vocabulary, and to
> >> let vocabularies grow a bit more organically. This schema.org group is
> >> currently thinking of using a one off property additionalType that
> >> would be used like so:
> >>
> >> <div itemscope itemtype="http://schema.org/Book">
> >>   <link itemprop="additionalType"
> >> href="http://www.productontology.org/id/Audiobook">
> >>   ...
> >> </div>
> >>
> >> I personally find this to be kind of distasteful since it replicates
> >> the mechanics that microdata's itemtype already offers.
> >>
> >> So, my question: is it the case that itemtype cannot reference types
> >> in different vocabularies like the example above? If so, I'm curious
> >> to know what the rationale was, and if perhaps it could be relaxed.
> >>
> >> //Ed
> >>
> >> [1]
> >>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#items
> >> [2]
> >>
> http://lists.w3.org/Archives/Public/public-schemabibex/2013Feb/0000.html
> >
> >
> >
> >
> > --
> > Lin Clark
> > Drupal Consultant
> >
> > lin-clark.com
> > twitter.com/linclark
>



-- 
Lin Clark
Drupal Consultant

lin-clark.com
twitter.com/linclark

From faulkner.steve at gmail.com  Wed Feb 13 08:59:09 2013
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Wed, 13 Feb 2013 16:59:09 +0000
Subject: [whatwg]  Is <main> now an official HTML5 element?
Message-ID: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>

Hi Ian,

I cannot speak for whatwg, but from the W3C HTML spec side the main element
is in the HTML 5.1 spec and has been implemented in browsers and so will be
added to HTML5 spec at some point as it likely meets the CR exit criteria.

as for it being a sectioning element, there is currently an open bug on
that, which we be dealt with.

If you want to discuss the specification of the main element in HTML 5.1
specification feel free mail the html wg list. If you want to discuss
definition as per the whatwg spec this is the place, although I will
obviously follow ant discussions with interest

regards
SteveF


Date: Wed, 13 Feb 2013 18:31:32 +0800
> From: Ian Yang <ian at invigoreight.com>
> To: whatwg <whatwg at whatwg.org>
> Subject: [whatwg] Is <main> now an official HTML5 element?
> Message-ID:
>         <CABr1FsfcaX8=B8TReG8Sz36W=

h1w0hRY61+LG=Cebo-ZUWYfqA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi editors and all other folks,

I saw the SitePoint article "Introducing the New HTML5 <main>
Element<http://www.sitepoint.com/html5-main-element/>"
yesterday. Does that mean <main> element has been approved by all editors
of the working group?

However, in spec, it still says that <main> element is not a sectioning
element. That means, in document outline, main content will form another
tree structure instead of appearing under the original website tree
structure. Can we have somebody advise on this? Is there a special
consideration to not making <main> a sectioning element?


Sincerely,
Ian Yan

From ian at hixie.ch  Wed Feb 13 09:06:52 2013
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 13 Feb 2013 17:06:52 +0000 (UTC)
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
References: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>

On Wed, 13 Feb 2013, Ian Yang wrote:
> 
> I saw the SitePoint article "Introducing the New HTML5 <main> 
> Element<http://www.sitepoint.com/html5-main-element/>" yesterday. Does 
> that mean <main> element has been approved by all editors of the working 
> group?

<main> is currently in the HTML standard. That doesn't mean much, though. 
What means something is that <main> is now implemented by two browsers in 
their development builds. Once they ship in final versions, that's the 
point at which we know that the feature is part of the platform.


> However, in spec, it still says that <main> element is not a sectioning
> element.

Correct. Broadly speaking, sectioning elements are those with headings; 
<main> doesn't typically have a heading, it contains the content after the 
heading, distinguishing it from the content that is "merely" heading and 
navigation and so forth.


> That means, in document outline, main content will form another
> tree structure instead of appearing under the original website tree
> structure.

I'm not sure what you mean here. The main content doesn't appear in the 
outline; the outline only contains the headers, essentially.


> Can we have somebody advise on this? Is there a special consideration to 
> not making <main> a sectioning element?

There's already corresponding sectioning elements to indicate something 
that is "main" content -- <article> or <section>, depending on what 
exactly the content is.


The spec goes into some detail about this, including with examples, here:

   http://whatwg.org/html#the-main-part-of-the-content
   http://whatwg.org/html#the-main-element
   http://whatwg.org/html#usage-summary-0
   http://whatwg.org/html#sample-outlines

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From cabanier at gmail.com  Wed Feb 13 09:22:29 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Wed, 13 Feb 2013 09:22:29 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
Message-ID: <CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>

For blending optimizations, it might be better to introduce a function
instead of a boolean attribute like 'opaque'.
What you really want, is to matte [1] the canvas with a solid color so you
can optimize compositing.

How about this API:

void applyMatte(DOMString color); // color is a CSS rgb color value (alpha
is ignored)


When you call this function, the canvas is matted with that color. If it's
the first drawing call, you can just fill the canvas with that color (no
compositing needed)
After matting, you no longer have to read or update the alpha channel since
it's always 1 which should speed up drawing.

1: http://en.wikipedia.org/wiki/Matte_(filmmaking)

On Wed, Feb 13, 2013 at 7:45 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Tue, Feb 12, 2013 at 6:14 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>>
>>
>> On Tue, Feb 12, 2013 at 2:56 PM, Stephen White <senorblanco at chromium.org>wrote:
>>
>>> On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>
>>> > On Thu, 29 Mar 2012, Jeremy Apthorp wrote:
>>> > > On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp <
>>> jeremya at chromium.org
>>> > >wrote:
>>> > > > On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson <ian at hixie.ch> wrote:
>>> > > >> On Fri, 13 Jan 2012, Jeremy Apthorp wrote:
>>> > > >> >
>>> > > >> > I'd like to draw non-antialiased lines in a <canvas>. Currently
>>> it
>>> > > >> > seems that the only way to do this is to directly access the
>>> pixel
>>> > > >> > data.
>>> > > >> >
>>> > > >> > Is there a reason there's no way to turn off antialiasing?
>>> > > >>
>>> > > >> What's the use case?
>>> > > >
>>> > > > Pixel-art style games.
>>> > >
>>> > > Specifically: even with the new image smoothing stuff in place for
>>> > > drawImage, a 1:2 diagonal line will still be anti-aliased (only the
>>> > > antialiasing will look silly scaled up to 2x).
>>> >
>>> > Do you have an example of a game where lines are drawn using a line API
>>> > without antialiasing, then scaled up? Most "pixel art" games I've seen
>>> > tend to use bitmaps for that kind of thing.
>>> >
>>> >
>>> > On Mon, 12 Nov 2012, Justin Novosad wrote:
>>> > >
>>> > > For many types of apps, DOM-based rendering is uncompetitively slow
>>> > > [so we should make text rendering in canvas more controllable]
>>> >
>>> > This seems like something we should fix, not something we should work
>>> > around by having people use canvas instead. Using canvas has all kinds
>>> of
>>> > terrible side-effects, like reducing the likely accessibility of the
>>> page,
>>> > making searcheability much worse, etc.
>>> >
>>> > Also, do you have any metrics showing the magnitude of this problem on
>>> > real-world sites that might consider using canvas instead?
>>> >
>>> >
>>> > > If LCD text were enable-able, authors would have to be mindful of a
>>> > > number of caveats in order to avoid rendering artifacts.
>>> >
>>> > Do we have any reason to believe the majority of authors would make the
>>> > right decisions here?
>>> >
>>> > (The main reason we haven't provided control over things like
>>> antialiasing
>>> > is that many authors tend to make terribly bad decisions.) (Before
>>> anyone
>>> > gets offended, by the way: that you are reading this almost guarantees
>>> > that you are above average in terms of authoring ability.)
>>> >
>>> >
>>> > On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote:
>>> > >
>>> > > We'd have to define what happens when you use subpixel antialiasing
>>> > > "incorrectly", because we can be pretty sure authors will use it
>>> > > incorrectly and expect to get interoperable behavior.
>>> >
>>> > That's certainly true.
>>> >
>>> >
>>> > > Mozilla supports a "mozOpaque" attribute which makes the canvas
>>> buffer
>>> > > RGBX (initialized to solid black) and enables subpixel antialiasing
>>> for
>>> > > most text drawing. That might be enough to address your use-cases.
>>> >
>>> > I haven't specified this; if other vendors intend to implement this
>>> let me
>>> > know and I can spec it. I'm not sure it's worth it though.
>>> >
>>>
>>> [blowing the dust off this thread]
>>>
>>> Folks on the Chrome team are looking into implementing this attribute,
>>> and
>>> would be interested in seeing it spec'ed.
>>
>>
>> What are you implementing? Initializing the canvas to black or subpixel
>> antialiasing?
>>
>
> We're interested in both aspects:  the opportunity for culling and
> blending optimizations at composite time, as well as enabling subpixel AA.
>
> Stephen
>
>>
>>
>>>
>>> >
>>> > On Wed, 14 Nov 2012, Robert O'Callahan wrote:
>>> > > On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad <junov at chromium.org>
>>> > wrote:
>>> > > >
>>> > > > Are there precedents for exposing features with documented caveats?
>>> > > > (excluding caveats that were discovered after the fact)
>>> > >
>>> > > Yes, and many of them have been extremely problematic, because Web
>>> > > authors will ignore the caveats.
>>> >
>>> > Right. I'd really like to avoid adding more if we can help it.
>>> >
>>> >
>>> > On Wed, 14 Nov 2012, Justin Novosad wrote:
>>> > >
>>> > > There is a recent improvement in Chrome called "deferred 2D canvas
>>> > > rendering" (enabled by default as of Chrome 23).  It is a mechanism
>>> that
>>> > > records 2d canvas commands during JS execution, and only executes
>>> them
>>> > > for real when the render buffer needs to be resolved (draw to screen,
>>> > > getImageData, toDataURL, etc.).  If you want to check it out, the
>>> guts
>>> > > are in Skia: SkGPipe is a sort of FIFO for graphics commands,
>>> > > SkDeferredCanvas is a wrapper that manages the GPipe and
>>> automatically
>>> > > flushes it and applies some command culling optimizations.
>>> > >
>>> > > So to come back to the problem of with and without subpixel AA
>>> buffers:
>>> > > if rendering is deferred, the non-AA buffer would never get
>>> rasterized
>>> > > (and possibly never even allocated), unless it needs to be.
>>>  Obviously
>>> > > there are practical limitations, for example we cannot store an
>>> > > unlimited stream of recorded commands, so if the canvas draws
>>> > > indefinitely without ever being cleared, at some point we have to
>>> > > rasterize the non-AA buffer just so that we can safely discard the
>>> > > recording data. Also, if at record time the necessary conditions for
>>> > > subpixel AA are not met, perhaps we just forget about it.
>>> > >
>>> > > I admit this is a complex solution for implementors, but it makes the
>>> > > management of subpixel-AA safety transparent to web authors.
>>> >
>>> > I think it'd be reasonable (for some definition of reasonable that
>>> > relates to whether it's compatible with the spec, anyway) for
>>> implementors
>>> > to do this today, without having to expose any control to the author.
>>> >
>>> >
>>> > On Thu, 15 Nov 2012, Fred Andrews wrote:
>>> > >
>>> > > The canvas that scripts draw into could be over-sized with the UA
>>> down
>>> > > sampling this to fit the target size and taking into account the
>>> > > sub-pixel screen layout when doing so.
>>> >
>>> > On Thu, 15 Nov 2012, Justin Novosad wrote:
>>> > >
>>> > > Obviously, that would be costly (x3 pixels), but I think it is a very
>>> > > realistic solution and relatively low hanging fruit. The over-sizing
>>> of
>>> > > the canvas would have to be handled under the hood by the UA though,
>>> > > because it depends on LCD component ordering and orientation, which
>>> > > means querying the OS/display driver. A lot of the kinks with the
>>> > > over-sized canvas approach have already been ironed out for solving
>>> the
>>> > > problem of High-DPI support ( put/getImageDataHD ), and I like the
>>> idea
>>> > > of unifying the two. Implementing this would mostly be a matter of
>>> > > adding per color component compositing of canvases. Also, the pixel
>>> > > aspect ratio would have to be taken into account for line drawing.
>>> >
>>> > getImageDataHD() requires that the pixels be square, but so long as
>>> that
>>> > is taken into consideration (e.g. by dropping down to square pixels if
>>> the
>>> > author calls putImageDataHD()) I think this could probably be made to
>>> work
>>> > within the spec's current requirements.
>>> >
>>> >
>>> > > Regarding the concerns about accessibility, I think the problem can
>>> be
>>> > > solved by using HitRegions with labels.
>>> >
>>> > Oh it _can_ be solved. That's not the problem. Accessibility is not
>>> about
>>> > what is _possible_, it's about what actually _is_. Most authors,
>>> > realistically speaking, aren't goin to be using hit regions
>>> sufficiently
>>> > for us to declare victory here.
>>> >
>>> >
>>> > > Come to think of it, there should be an option to make the UA do this
>>> > > automatically: create a HitRegion with a label every time text is
>>> drawn
>>> > > to a canvas.
>>> >
>>> > I considered doing that, but it gets really fiddly when you're doing
>>> > things like text that fades over multiple frames. In the end I decided
>>> > that the magic wasn't worth it, as it would likely screw up more often
>>> > than it would actually help.
>>> >
>>> > --
>>> > Ian Hickson               U+1047E                )\._.,--....,'``.
>>>  fL
>>> > http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._
>>> ,.
>>> > Things that are impossible just take longer.
>>> `._.-(,_..'--(,_..'`-.;.'
>>> >
>>>
>>
>>
>

From senorblanco at chromium.org  Wed Feb 13 11:25:22 2013
From: senorblanco at chromium.org (Stephen White)
Date: Wed, 13 Feb 2013 14:25:22 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
Message-ID: <CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>

On Wed, Feb 13, 2013 at 12:22 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> For blending optimizations, it might be better to introduce a function
> instead of a boolean attribute like 'opaque'.
> What you really want, is to matte [1] the canvas with a solid color so you
> can optimize compositing.
>
> How about this API:
>
> void applyMatte(DOMString color); // color is a CSS rgb color value (alpha
> is ignored)
>
>
> When you call this function, the canvas is matted with that color. If it's
> the first drawing call, you can just fill the canvas with that color (no
> compositing needed)
> After matting, you no longer have to read or update the alpha channel
> since it's always 1 which should speed up drawing.
>

Just to be sure we're on the same page, when I mentioned compositing
optimizations, I was referring to compositing the canvas backing store into
the page, not compositing operations within the canvas itself.

One advantage of using an element attribute is that it could be used at
backing store allocation time, to allocate RGB instead of RGBA.  Forcing a
reallocation of the backing store on attribute change would be consistent
with changing width and height of the canvas, which have the same effect.
 Doing so on a context operation would not.

If we did use a context function approach as you suggest, how would
subpixel AA be handled?  Would it be enabled on first call of the function
and never disabled?  Is there a way to query if the canvas is opaque once
it's called?  (I'm assuming that all changes to canvas alpha after the
first call would have to be ignored, since otherwise you'd have to sniff
every operation to see if it affected alpha, and "reset the bit", although
perhaps I'm misunderstanding your proposal.)

Stephen

From mounir at lamouri.fr  Wed Feb 13 11:29:12 2013
From: mounir at lamouri.fr (Mounir Lamouri)
Date: Wed, 13 Feb 2013 19:29:12 +0000
Subject: [whatwg] inputmode feedback
Message-ID: <511BE988.7070208@lamouri.fr>

Hi,

Mozilla did implement an inputmode attribute for the <input> element a
few months ago and the HTML specification has been updated after that to
introduce that attribute. Given that the specification and our
implementation was not matching, we decided to delay the release of that
feature [1] and not advertise it. We unfortunately had to push a
"x-inputmode" attribute in Firefox OS because our UI needed that feature
but we expect to replace this with a proper inputmode implementation as
soon as possible.

Basically, the Mozilla's inputmode attribute is describing behaviour,
the allowed value are mostly self-explanatory: auto, uppercase,
lowercase, titlecase, autocapitalized, digit and numeric.
Autocapitalized is capitalizing words at the beginning of a sentence and
the difference between digit and numeric is whether or not there should
be a decimal separator and numeric operators available.

The attribute as specified in HTML seems to focus on use cases, it
provides more semantic and takes into account the handling of
suggestions/corrections. However, the current set of values seems overly
complex.

To begin with, I think we should get rid of the "latin" prefix. The
three modes with that prefix are "latin", "latin-name" and "latin-prose"
but in none of those situations "latin" is mandatory.
The first one could be "text": we want to have typing aid enabled and
any other feature related to entering some basic non-formatted text.
(The difference between "verbatim" and this type is weak and "text"
might not be the best way to improve this.)
The second one is simply "name": whatever the script is, we want to
enter a name in this field.
The last one is "latin-prose": like the others, the use case is to write
some formatted-text, the script shouldn't have any impact.

Regarding the three Japanese specific types, it is not clear if
inputmode is the best way to solve the use cases intended to be solved.
Actually, 'kana' and 'katakana' are trying to give a hint about the
script that has to be used which seems to be orthogonal with the other
types. We could allow inputmode to have a set of values but that would
make the behaviour way more complex so I wonder if we couldn't try to
solve that problem with another attribute like inputscript.

Mozilla's implementation has 'numeric' and 'digit' and 'numeric' in the
HTML specification seems to match what we called 'digit'. It is not very
important but I believe it would be nicer to have 'numeric' renamed
'digit' to make things clearer and to keep the 'numeric' keyword
available in case of we need it later.

Mozilla's implementation also includes 'uppercase' which is a common use
case in the web and could be interesting but it isn't as important as
other types so it can be kept aside for later. The priority for us here
being to make the Web Platform competitive with native apps on Mobile.

Finally, it is not clear why 'tel', 'email' and 'url' are available.
Actually, tel would make sense if it wasn't already implemented as a
type (because the type is mostly an inputmode) but all of those
inputmode already have an associated type. The specification even say
"rarely necessary" and suggest to use the type. Why adding those
keywords in the first place then? I feel like we shouldn't add stuff
that we do not believe is useful. If it happens to be useful, we should
listen to feedback and see if we can fix the types (like make it easier
to have them not validate).

To conclude, Mozilla is interested in implementing this set of keywords:
verbatim, text, name, prose and digit (or numeric).
We would be interested to hear from other vendors. Is anybody planning
to implement inputmode? if that's the case, which set of keywords is
going to be implemented?

Feedback is welcome :)

[1] This is definitely working with Firefox Android Nightly, I don't
know for other channels.

Thanks,
--
Mounir

From cabanier at gmail.com  Wed Feb 13 14:31:12 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Wed, 13 Feb 2013 14:31:12 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
Message-ID: <CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>

On Wed, Feb 13, 2013 at 11:25 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Wed, Feb 13, 2013 at 12:22 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> For blending optimizations, it might be better to introduce a function
>> instead of a boolean attribute like 'opaque'.
>> What you really want, is to matte [1] the canvas with a solid color so
>> you can optimize compositing.
>>
>> How about this API:
>>
>> void applyMatte(DOMString color); // color is a CSS rgb color value
>> (alpha is ignored)
>>
>>
>> When you call this function, the canvas is matted with that color. If
>> it's the first drawing call, you can just fill the canvas with that color
>> (no compositing needed)
>> After matting, you no longer have to read or update the alpha channel
>> since it's always 1 which should speed up drawing.
>>
>
> Just to be sure we're on the same page, when I mentioned compositing
> optimizations, I was referring to compositing the canvas backing store into
> the page, not compositing operations within the canvas itself.
>

sorry, I didn't mean to say blending. This is for optimizing compositing
within the canvas and of the canvas into the page.


>
> One advantage of using an element attribute is that it could be used at
> backing store allocation time, to allocate RGB instead of RGBA.  Forcing a
> reallocation of the backing store on attribute change would be consistent
> with changing width and height of the canvas, which have the same effect.
>  Doing so on a context operation would not.
>

why not? There is no reason for you to allocate the backing store until
it's needed.
The strange thing with an element attribute is that you can't change it
back and it's also detached from the JS code that does the drawing.


>
> If we did use a context function approach as you suggest, how would
> subpixel AA be handled?  Would it be enabled on first call of the function
> and never disabled?
>

I did not think about subpixel AA.
If I read the mozilla proposal correctly, they do AA if they know that the
canvas is opaque.
So, with my proposal, there would be no AA until you call 'applyMatte'
(assuming you follow the mozilla way of doing AA).


> Is there a way to query if the canvas is opaque once it's called?
>

Wouldn't the user know that he called 'applyMatte'? Also why do you want to
query it?


>  (I'm assuming that all changes to canvas alpha after the first call would
> have to be ignored, since otherwise you'd have to sniff every operation to
> see if it affected alpha, and "reset the bit", although perhaps I'm
> misunderstanding your proposal.)
>

No, you don't have to do that and can still use alpha.
Simple alpha compositing is defined as follows [1] (in premultiplied alpha):

co = cs + cb x (1 - ?s)
?o = ?s + ?b x (1 - ?s)


If you know that the backdrop is matted (?b = 1), the second formula always
resolves to 1 so you can skip it.

1:
https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#porterduffcompositingoperators_srcover

From ian at invigoreight.com  Wed Feb 13 16:28:07 2013
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 14 Feb 2013 08:28:07 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
Message-ID: <CABr1FsfyfqfYCYeKkhxoPjH4V3Ng6z3_TpXxa30ug9HwodzXwg@mail.gmail.com>

Hi Steve,

Thanks. And sorry, but til now I still don't understand the differences
between whatwg and html wg. Could you please explain?

Regards,
Ian

On Thu, Feb 14, 2013 at 12:59 AM, Steve Faulkner
<faulkner.steve at gmail.com>wrote:

> Hi Ian,
>
> I cannot speak for whatwg, but from the W3C HTML spec side the main element
> is in the HTML 5.1 spec and has been implemented in browsers and so will be
> added to HTML5 spec at some point as it likely meets the CR exit criteria.
>
> as for it being a sectioning element, there is currently an open bug on
> that, which we be dealt with.
>
> If you want to discuss the specification of the main element in HTML 5.1
> specification feel free mail the html wg list. If you want to discuss
> definition as per the whatwg spec this is the place, although I will
> obviously follow ant discussions with interest
>
> regards
> SteveF
>
>
> Date: Wed, 13 Feb 2013 18:31:32 +0800
> > From: Ian Yang <ian at invigoreight.com>
> > To: whatwg <whatwg at whatwg.org>
> > Subject: [whatwg] Is <main> now an official HTML5 element?
> > Message-ID:
> >         <CABr1FsfcaX8=B8TReG8Sz36W=
>
> h1w0hRY61+LG=Cebo-ZUWYfqA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi editors and all other folks,
>
> I saw the SitePoint article "Introducing the New HTML5 <main>
> Element<http://www.sitepoint.com/html5-main-element/>"
> yesterday. Does that mean <main> element has been approved by all editors
> of the working group?
>
> However, in spec, it still says that <main> element is not a sectioning
> element. That means, in document outline, main content will form another
> tree structure instead of appearing under the original website tree
> structure. Can we have somebody advise on this? Is there a special
> consideration to not making <main> a sectioning element?
>
>
> Sincerely,
> Ian Yan
>

From aurelioderosa at gmail.com  Wed Feb 13 16:31:36 2013
From: aurelioderosa at gmail.com (Aurelio De Rosa)
Date: Thu, 14 Feb 2013 01:31:36 +0100
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CABr1FsfyfqfYCYeKkhxoPjH4V3Ng6z3_TpXxa30ug9HwodzXwg@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
	<CABr1FsfyfqfYCYeKkhxoPjH4V3Ng6z3_TpXxa30ug9HwodzXwg@mail.gmail.com>
Message-ID: <CANbOm4h=VFnQxuYhb40SizEEC8irMVi+9ZQ5E39ngm-TzEaKdg@mail.gmail.com>

I think this should answer your question:

http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F

Best regards

2013/2/14 Ian Yang <ian at invigoreight.com>

> Hi Steve,
>
> Thanks. And sorry, but til now I still don't understand the differences
> between whatwg and html wg. Could you please explain?
>
> Regards,
> Ian
>
> On Thu, Feb 14, 2013 at 12:59 AM, Steve Faulkner
> <faulkner.steve at gmail.com>wrote:
>
> > Hi Ian,
> >
> > I cannot speak for whatwg, but from the W3C HTML spec side the main
> element
> > is in the HTML 5.1 spec and has been implemented in browsers and so will
> be
> > added to HTML5 spec at some point as it likely meets the CR exit
> criteria.
> >
> > as for it being a sectioning element, there is currently an open bug on
> > that, which we be dealt with.
> >
> > If you want to discuss the specification of the main element in HTML 5.1
> > specification feel free mail the html wg list. If you want to discuss
> > definition as per the whatwg spec this is the place, although I will
> > obviously follow ant discussions with interest
> >
> > regards
> > SteveF
> >
> >
> > Date: Wed, 13 Feb 2013 18:31:32 +0800
> > > From: Ian Yang <ian at invigoreight.com>
> > > To: whatwg <whatwg at whatwg.org>
> > > Subject: [whatwg] Is <main> now an official HTML5 element?
> > > Message-ID:
> > >         <CABr1FsfcaX8=B8TReG8Sz36W=
> >
> > h1w0hRY61+LG=Cebo-ZUWYfqA at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Hi editors and all other folks,
> >
> > I saw the SitePoint article "Introducing the New HTML5 <main>
> > Element<http://www.sitepoint.com/html5-main-element/>"
> > yesterday. Does that mean <main> element has been approved by all editors
> > of the working group?
> >
> > However, in spec, it still says that <main> element is not a sectioning
> > element. That means, in document outline, main content will form another
> > tree structure instead of appearing under the original website tree
> > structure. Can we have somebody advise on this? Is there a special
> > consideration to not making <main> a sectioning element?
> >
> >
> > Sincerely,
> > Ian Yan
> >
>



-- 
Aurelio De Rosa
email: aurelioderosa at gmail.com
email:  a.derosa at audero.it
website: www.audero.it
user group: ug.audero.it

From ian at invigoreight.com  Wed Feb 13 16:36:08 2013
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 14 Feb 2013 08:36:08 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CANbOm4h=VFnQxuYhb40SizEEC8irMVi+9ZQ5E39ngm-TzEaKdg@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
	<CABr1FsfyfqfYCYeKkhxoPjH4V3Ng6z3_TpXxa30ug9HwodzXwg@mail.gmail.com>
	<CANbOm4h=VFnQxuYhb40SizEEC8irMVi+9ZQ5E39ngm-TzEaKdg@mail.gmail.com>
Message-ID: <CABr1Fsdv996h--xNuH-3JqXd177n7p86L_URgTvbO6EUOK2Q+A@mail.gmail.com>

Hi Aurelio,

I see. So whatwg mainly focus on the development of HTML and APIs needed
for web applications. Thank you very much.

Kind Regards,
Ian

On Thu, Feb 14, 2013 at 8:31 AM, Aurelio De Rosa <aurelioderosa at gmail.com>wrote:

> I think this should answer your question:
>
> http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F
>
> Best regards
>
>
> 2013/2/14 Ian Yang <ian at invigoreight.com>
>
>> Hi Steve,
>>
>> Thanks. And sorry, but til now I still don't understand the differences
>> between whatwg and html wg. Could you please explain?
>>
>> Regards,
>> Ian
>>
>> On Thu, Feb 14, 2013 at 12:59 AM, Steve Faulkner
>> <faulkner.steve at gmail.com>wrote:
>>
>> > Hi Ian,
>> >
>> > I cannot speak for whatwg, but from the W3C HTML spec side the main
>> element
>> > is in the HTML 5.1 spec and has been implemented in browsers and so
>> will be
>> > added to HTML5 spec at some point as it likely meets the CR exit
>> criteria.
>> >
>> > as for it being a sectioning element, there is currently an open bug on
>> > that, which we be dealt with.
>> >
>> > If you want to discuss the specification of the main element in HTML 5.1
>> > specification feel free mail the html wg list. If you want to discuss
>> > definition as per the whatwg spec this is the place, although I will
>> > obviously follow ant discussions with interest
>> >
>> > regards
>> > SteveF
>> >
>> >
>> > Date: Wed, 13 Feb 2013 18:31:32 +0800
>> > > From: Ian Yang <ian at invigoreight.com>
>> > > To: whatwg <whatwg at whatwg.org>
>> > > Subject: [whatwg] Is <main> now an official HTML5 element?
>> > > Message-ID:
>> > >         <CABr1FsfcaX8=B8TReG8Sz36W=
>> >
>> > h1w0hRY61+LG=Cebo-ZUWYfqA at mail.gmail.com>
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>> > Hi editors and all other folks,
>> >
>> > I saw the SitePoint article "Introducing the New HTML5 <main>
>> > Element<http://www.sitepoint.com/html5-main-element/>"
>> > yesterday. Does that mean <main> element has been approved by all
>> editors
>> > of the working group?
>> >
>> > However, in spec, it still says that <main> element is not a sectioning
>> > element. That means, in document outline, main content will form another
>> > tree structure instead of appearing under the original website tree
>> > structure. Can we have somebody advise on this? Is there a special
>> > consideration to not making <main> a sectioning element?
>> >
>> >
>> > Sincerely,
>> > Ian Yan
>> >
>>
>
>
>
> --
> Aurelio De Rosa
> email: aurelioderosa at gmail.com
> email:  a.derosa at audero.it
> website: www.audero.it
> user group: ug.audero.it
>

From ian at invigoreight.com  Wed Feb 13 17:21:10 2013
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 14 Feb 2013 09:21:10 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>
References: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
	<Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>
Message-ID: <CABr1FsdDTh4FFLWrcgGspH=gFSH_D5h_-Mq8KUmFgaczDgawiw@mail.gmail.com>

On Thu, Feb 14, 2013 at 1:06 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 13 Feb 2013, Ian Yang wrote:
> >
> > I saw the SitePoint article "Introducing the New HTML5 <main>
> > Element<http://www.sitepoint.com/html5-main-element/>" yesterday. Does
> > that mean <main> element has been approved by all editors of the working
> > group?
>
> <main> is currently in the HTML standard. That doesn't mean much, though.
> What means something is that <main> is now implemented by two browsers in
> their development builds. Once they ship in final versions, that's the
> point at which we know that the feature is part of the platform.
>
>
> > However, in spec, it still says that <main> element is not a sectioning
> > element.
>
> Correct. Broadly speaking, sectioning elements are those with headings;
> <main> doesn't typically have a heading, it contains the content after the
> heading, distinguishing it from the content that is "merely" heading and
> navigation and so forth.
>
>
> > That means, in document outline, main content will form another
> > tree structure instead of appearing under the original website tree
> > structure.
>
> I'm not sure what you mean here. The main content doesn't appear in the
> outline; the outline only contains the headers, essentially.
>
>
> > Can we have somebody advise on this? Is there a special consideration to
> > not making <main> a sectioning element?
>
> There's already corresponding sectioning elements to indicate something
> that is "main" content -- <article> or <section>, depending on what
> exactly the content is.
>
>
> The spec goes into some detail about this, including with examples, here:
>
>    http://whatwg.org/html#the-main-part-of-the-content
>    http://whatwg.org/html#the-main-element
>    http://whatwg.org/html#usage-summary-0
>    http://whatwg.org/html#sample-outlines
>

Thanks Hickson for providing information, especially those example links.

In the past, I always regarded a sectioning main content area is an
indispensable part in a document. Today, information above tell me that the
main content area seem doesn't need to be a titled section.

So it seems that the following markup contains one unnecessary <section>
and one unnecessary <h1>, and they cause one unnecessary indent in document
outline.

<!DOCTYPE html>
<title>lorem ipsum</title>
<header>
    <h1>Branding</h1>
    <nav>
        <h1>Navigation</h1>
        lorem ipsum
    </nav>
</header>
<section id="main" role="main">
    <h1>Main Content</h1>
    <section>
        <h1>Welcome</h1>
        lorem ipsum
    </section>
    <section>
        <h1>Intro</h1>
        lorem ipsum
    </section>
    <aside id="comp" role="complementary">
        <h1>Complementary Content</h1>
        <article>
            <h1>Latest News</h1>
            lorem ipsum
        </article>
        <article>
            <h1>Recent Comments</h1>
            lorem ipsum
        </article>
    </aside>
</section>
<footer>
    lorem ipsum
</footer>

1. Branding
        1. Navigation
        2. Main Content
                1. Welcome
                2. Intro
                3. Complementary Content
                        1. Latest News
                        2. Recent Comments


And the following markup and document outline are more appropriate. Since
the <main> is not a sectioning element, now it only serves as an element
for keyboard navigation (id="main") and for assistive technology to quick
navigate to (role="main").

<!DOCTYPE html>
<title>lorem ipsum</title>
<header>
    <h1>Branding</h1>
    <nav>
        <h1>Navigation</h1>
        lorem ipsum
    </nav>
</header>
<main id="main" role="main">
    <section>
        <h1>Welcome</h1>
        lorem ipsum
    </section>
    <section>
        <h1>Intro</h1>
        lorem ipsum
    </section>
    <aside id="comp" role="complementary">
        <h1>Complementary Content</h1>
        <article>
            <h1>Latest News</h1>
            lorem ipsum
        </article>
        <article>
            <h1>Recent Comments</h1>
            lorem ipsum
        </article>
    </aside>
</main>
<footer>
    lorem ipsum
</footer>

1. Branding
        1. Navigation
        2. Welcome
        3. Intro
        4. Complementary Content
                1. Latest News
                2. Recent Comments


If any of my above understanding is flawed, please point it out for me.
Thank you all.


Sincerely,
Ian Yang

From senorblanco at chromium.org  Wed Feb 13 17:39:24 2013
From: senorblanco at chromium.org (Stephen White)
Date: Wed, 13 Feb 2013 20:39:24 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
Message-ID: <CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>

On Wed, Feb 13, 2013 at 5:31 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> On Wed, Feb 13, 2013 at 11:25 AM, Stephen White <senorblanco at chromium.org
> >wrote:
>
> > On Wed, Feb 13, 2013 at 12:22 PM, Rik Cabanier <cabanier at gmail.com>
> wrote:
> >
> >> For blending optimizations, it might be better to introduce a function
> >> instead of a boolean attribute like 'opaque'.
> >> What you really want, is to matte [1] the canvas with a solid color so
> >> you can optimize compositing.
> >>
> >> How about this API:
> >>
> >> void applyMatte(DOMString color); // color is a CSS rgb color value
> >> (alpha is ignored)
> >>
> >>
> >> When you call this function, the canvas is matted with that color. If
> >> it's the first drawing call, you can just fill the canvas with that
> color
> >> (no compositing needed)
> >> After matting, you no longer have to read or update the alpha channel
> >> since it's always 1 which should speed up drawing.
> >>
> >
> > Just to be sure we're on the same page, when I mentioned compositing
> > optimizations, I was referring to compositing the canvas backing store
> into
> > the page, not compositing operations within the canvas itself.
> >
>
> sorry, I didn't mean to say blending. This is for optimizing compositing
> within the canvas and of the canvas into the page.
>
>
> >
> > One advantage of using an element attribute is that it could be used at
> > backing store allocation time, to allocate RGB instead of RGBA.  Forcing
> a
> > reallocation of the backing store on attribute change would be consistent
> > with changing width and height of the canvas, which have the same effect.
> >  Doing so on a context operation would not.
> >
>
> why not? There is no reason for you to allocate the backing store until
> it's needed.
>

True.  I was just trying to understand when you would use this function
more than once during canvas lifetime.  Presumably, that's the reason for
having a function, no?  If so, and you don't maintain any special state
about the opacity of the canvas, how is this different from an rgb()
fillRect()?


> The strange thing with an element attribute is that you can't change it
> back and it's also detached from the JS code that does the drawing.
>
>
You can change it back programmatically through the DOM, as you can with
the element width and height.


> > If we did use a context function approach as you suggest, how would
> > subpixel AA be handled?  Would it be enabled on first call of the
> function
> > and never disabled?
> >
>
> I did not think about subpixel AA.
> If I read the mozilla proposal correctly, they do AA if they know that the
> canvas is opaque.
> So, with my proposal, there would be no AA until you call 'applyMatte'
> (assuming you follow the mozilla way of doing AA).


OK, so there would have to be a bit of state saved at that point, in order
to know if subpixel AA is allowable?

At any rate, I don't think this works if you subsequently modify the
canvas's alpha (see below).

>
>
> > Is there a way to query if the canvas is opaque once it's called?
> >
>
> Wouldn't the user know that he called 'applyMatte'? Also why do you want to
> query it?


>
> >  (I'm assuming that all changes to canvas alpha after the first call
> would
> > have to be ignored, since otherwise you'd have to sniff every operation
> to
> > see if it affected alpha, and "reset the bit", although perhaps I'm
> > misunderstanding your proposal.)
> >
>
> No, you don't have to do that and can still use alpha.
> Simple alpha compositing is defined as follows [1] (in premultiplied
> alpha):
>
> co = cs + cb x (1 - ?s)
> ?o = ?s + ?b x (1 - ?s)
>
>
> If you know that the backdrop is matted (?b = 1), the second formula always
> resolves to 1 so you can skip it.
>

The problem is, canvas supports more than simple (source-over) compositing,
so there are ways of modifying the destination alpha back to non-1, e.g., a
primitive with non-1 alpha drawn with source-copy, or via putImageData().
 At that point, the state of the canvas's alpha is unknown, so the page
compositor can make no assumptions about its opacity.

Stephen

From ian at invigoreight.com  Wed Feb 13 18:50:22 2013
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 14 Feb 2013 10:50:22 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CABr1FsdDTh4FFLWrcgGspH=gFSH_D5h_-Mq8KUmFgaczDgawiw@mail.gmail.com>
References: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
	<Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>
	<CABr1FsdDTh4FFLWrcgGspH=gFSH_D5h_-Mq8KUmFgaczDgawiw@mail.gmail.com>
Message-ID: <CABr1FschgJcVXGYRGt_4fEVWog922PvHc_rS3hd2Obp8TmizFg@mail.gmail.com>

Sorry, maybe the markup structure still needs some modifications.

One thing needs to be figured out is that should <aside
role="complementary"> be contained within <main role="main">? Or rather, is
<aside role="complementary"> a supporting content for the entire document
or just for <main role="main">? If it is the latter, then <aside> is fine
being within <main>.

The spec doesn't look like it has clearly defined the relationship between
<main> and <aside>.

Any opinion will be appreciated. Thanks.


Kind Regards,
Ian Yang

From cabanier at gmail.com  Wed Feb 13 18:55:19 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Thu, 14 Feb 2013 13:55:19 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
Message-ID: <CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>

On Thu, Feb 14, 2013 at 12:39 PM, Stephen White <senorblanco at chromium.org>wrote:

> On Wed, Feb 13, 2013 at 5:31 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> On Wed, Feb 13, 2013 at 11:25 AM, Stephen White <senorblanco at chromium.org
>> >wrote:
>>
>> > On Wed, Feb 13, 2013 at 12:22 PM, Rik Cabanier <cabanier at gmail.com>
>> wrote:
>> >
>> >> For blending optimizations, it might be better to introduce a function
>> >> instead of a boolean attribute like 'opaque'.
>> >> What you really want, is to matte [1] the canvas with a solid color so
>> >> you can optimize compositing.
>> >>
>> >> How about this API:
>> >>
>> >> void applyMatte(DOMString color); // color is a CSS rgb color value
>> >> (alpha is ignored)
>> >>
>> >>
>> >> When you call this function, the canvas is matted with that color. If
>> >> it's the first drawing call, you can just fill the canvas with that
>> color
>> >> (no compositing needed)
>> >> After matting, you no longer have to read or update the alpha channel
>> >> since it's always 1 which should speed up drawing.
>> >>
>> >
>> > Just to be sure we're on the same page, when I mentioned compositing
>> > optimizations, I was referring to compositing the canvas backing store
>> into
>> > the page, not compositing operations within the canvas itself.
>> >
>>
>> sorry, I didn't mean to say blending. This is for optimizing compositing
>> within the canvas and of the canvas into the page.
>>
>>
>> >
>> > One advantage of using an element attribute is that it could be used at
>> > backing store allocation time, to allocate RGB instead of RGBA.
>>  Forcing a
>> > reallocation of the backing store on attribute change would be
>> consistent
>> > with changing width and height of the canvas, which have the same
>> effect.
>> >  Doing so on a context operation would not.
>> >
>>
>> why not? There is no reason for you to allocate the backing store until
>> it's needed.
>>
>
> True.  I was just trying to understand when you would use this function
> more than once during canvas lifetime.  Presumably, that's the reason for
> having a function, no?
>

You would need it again if you draw with a compositing mode that removes
alpha (like 'copy')


>  If so, and you don't maintain any special state about the opacity of the
> canvas, how is this different from an rgb() fillRect()?
>

pretty much the same except
- ignore alpha
- use destination-over
- automatically fills the whole canvas


>
>
>> The strange thing with an element attribute is that you can't change it
>> back and it's also detached from the JS code that does the drawing.
>>
>>
> You can change it back programmatically through the DOM, as you can with
> the element width and height.
>

But would it do something when you set it back? How would you know what
part was painted black or originally transparent?


>
>
>> > If we did use a context function approach as you suggest, how would
>> > subpixel AA be handled?  Would it be enabled on first call of the
>> function
>> > and never disabled?
>> >
>>
>> I did not think about subpixel AA.
>> If I read the mozilla proposal correctly, they do AA if they know that the
>> canvas is opaque.
>> So, with my proposal, there would be no AA until you call 'applyMatte'
>> (assuming you follow the mozilla way of doing AA).
>
>
> OK, so there would have to be a bit of state saved at that point, in order
> to know if subpixel AA is allowable?
>

Yes. It would be an optimisation under the hood that an advanced user can
use.


>
> At any rate, I don't think this works if you subsequently modify the
> canvas's alpha (see below).
>
>>
>>
>> > Is there a way to query if the canvas is opaque once it's called?
>> >
>>
>> Wouldn't the user know that he called 'applyMatte'? Also why do you want
>> to
>> query it?
>
>
>>
>> >  (I'm assuming that all changes to canvas alpha after the first call
>> would
>> > have to be ignored, since otherwise you'd have to sniff every operation
>> to
>> > see if it affected alpha, and "reset the bit", although perhaps I'm
>> > misunderstanding your proposal.)
>> >
>>
>> No, you don't have to do that and can still use alpha.
>> Simple alpha compositing is defined as follows [1] (in premultiplied
>> alpha):
>>
>> co = cs + cb x (1 - ?s)
>> ?o = ?s + ?b x (1 - ?s)
>>
>>
>> If you know that the backdrop is matted (?b = 1), the second formula
>> always
>> resolves to 1 so you can skip it.
>>
>
> The problem is, canvas supports more than simple (source-over)
> compositing, so there are ways of modifying the destination alpha back to
> non-1, e.g., a primitive with non-1 alpha drawn with source-copy, or via
> putImageData().  At that point, the state of the canvas's alpha is unknown,
> so the page compositor can make no assumptions about its opacity.
>

What would happen if you set 'opaque' to true and you draw with alpha and
'copy' compositing? It seems that that has the same issue (unless you're OK
with breaking drawing).

From robert at ocallahan.org  Wed Feb 13 19:12:16 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 14 Feb 2013 16:12:16 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
Message-ID: <CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>

On Thu, Feb 14, 2013 at 3:55 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> What would happen if you set 'opaque' to true and you draw with alpha and
> 'copy' compositing? It seems that that has the same issue (unless you're OK
> with breaking drawing).
>

The alpha values of all moz-opaque canvas pixels are simply not affected by
compositing.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From cabanier at gmail.com  Wed Feb 13 19:18:33 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Thu, 14 Feb 2013 14:18:33 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
Message-ID: <CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>

On Thu, Feb 14, 2013 at 2:12 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Feb 14, 2013 at 3:55 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> What would happen if you set 'opaque' to true and you draw with alpha and
>> 'copy' compositing? It seems that that has the same issue (unless you're
>> OK
>> with breaking drawing).
>>
>
> The alpha values of all moz-opaque canvas pixels are simply not affected
> by compositing.
>

Exactly! So, this will break drawing as the pixels with no alpha will be
black with no way to undo that.

From robert at ocallahan.org  Wed Feb 13 19:27:32 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 14 Feb 2013 16:27:32 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
Message-ID: <CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>

On Thu, Feb 14, 2013 at 4:18 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> On Thu, Feb 14, 2013 at 2:12 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Thu, Feb 14, 2013 at 3:55 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>
>>> What would happen if you set 'opaque' to true and you draw with alpha and
>>> 'copy' compositing? It seems that that has the same issue (unless you're
>>> OK
>>> with breaking drawing).
>>>
>>
>> The alpha values of all moz-opaque canvas pixels are simply not affected
>> by compositing.
>>
>
> Exactly! So, this will break drawing as the pixels with no alpha will be
> black with no way to undo that.
>

I don't know what you mean by "no way to undo that" or "break drawing".

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From cabanier at gmail.com  Wed Feb 13 20:16:56 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Thu, 14 Feb 2013 15:16:56 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
Message-ID: <CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>

On Thu, Feb 14, 2013 at 2:27 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Feb 14, 2013 at 4:18 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> On Thu, Feb 14, 2013 at 2:12 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>
>>> On Thu, Feb 14, 2013 at 3:55 PM, Rik Cabanier <cabanier at gmail.com>wrote:
>>>
>>>> What would happen if you set 'opaque' to true and you draw with alpha
>>>> and
>>>> 'copy' compositing? It seems that that has the same issue (unless
>>>> you're OK
>>>> with breaking drawing).
>>>>
>>>
>>> The alpha values of all moz-opaque canvas pixels are simply not affected
>>> by compositing.
>>>
>>
>> Exactly! So, this will break drawing as the pixels with no alpha will be
>> black with no way to undo that.
>>
>
> I don't know what you mean by "no way to undo that" or "break drawing".
>
>
My proposal doesn't change anything for the user as it has no side effects
(apart from faster drawing when possible).
Setting 'opaque' on the canvas actually changes how compositing works. For
instance, if you use 'copy' compositing with a partially transparent image,
you will draw black pixels where the image has no coverage. In addition,
partially transparent pixels will look darker the more transparent they are.

Looking at the WebKit implementation, I'm unsure how 'opaque' can
implemented for accelerated canvas. It might work with non-accelerated
canvas but would have to run some experiments.
I also look at mozilla's Core Graphics implementation and unless I'm
missing something, it doesn't have special code to handle 'opaque'. When do
you use this parameter?

From robert at ocallahan.org  Wed Feb 13 20:35:31 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 14 Feb 2013 17:35:31 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
Message-ID: <CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>

On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> Looking at the WebKit implementation, I'm unsure how 'opaque' can
> implemented for accelerated canvas. It might work with non-accelerated
> canvas but would have to run some experiments.
> I also look at mozilla's Core Graphics implementation and unless I'm
> missing something, it doesn't have special code to handle 'opaque'. When do
> you use this parameter?
>

CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That
selects a surface format that is passed down to the graphics layer when
creating the canvas surface. It's true that we don't currently do anything
with that when drawing with CoreGraphics. That would need to be cleaned up
before we started promoting this feature.

Now that you mention it, having to modify the definition of compositing is
a bit of a bummer for the 'opaque' attribute approach. I think we could do
everything we want using your approach --- internally keeping a flag to
indicate whether the alpha values of the canvas are all 1, setting it when
the canvas is filled with a solid color and clearing it when non-over
drawing (or clear()) are used. Let's try that!

But I think "matte" is unnecessarily obscure. How about adding a
clear(DOMString) method that does a 'copy' of the color to the entire
canvas buffer? The color could default to rgba(0,0,0,0).

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From chaals at yandex-team.ru  Wed Feb 13 20:37:16 2013
From: chaals at yandex-team.ru (Charles McCathie Nevile)
Date: Thu, 14 Feb 2013 05:37:16 +0100
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CANbOm4h=VFnQxuYhb40SizEEC8irMVi+9ZQ5E39ngm-TzEaKdg@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
	<CABr1FsfyfqfYCYeKkhxoPjH4V3Ng6z3_TpXxa30ug9HwodzXwg@mail.gmail.com>
	<CANbOm4h=VFnQxuYhb40SizEEC8irMVi+9ZQ5E39ngm-TzEaKdg@mail.gmail.com>
Message-ID: <op.wsha4ehcy3oazb@chaals.local>

Hi Ian,

On Thu, 14 Feb 2013 01:31:36 +0100, Aurelio De Rosa  
<aurelioderosa at gmail.com> wrote:

> I think this should answer your question:
>
> http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F

It doesn't seem to provide much useful information on the differences.

According to its charter <http://www.whatwg.org/charter>, WHAT-WG is a  
group of 9 individuals who work with a very simple set of rules (basically  
the editor of a specification decides what should be in it, but the 9  
people can decide other things by "overwhelming majority"). There is a  
mailing list, IRC, etc, and everyone else who contributes to the  
discussion is called a contributor.
More about how WHAT-WG works is described at  
http://wiki.whatwg.org/wiki/FAQ

The HTML WG is one of the working groups of W3C. The working group has a  
charter that describes some of how it works:  
<http://www.w3.org/2007/03/HTML-WG-charter> W3C itself is a consortium of  
member organisations, and the links from the HTML WG charter to the  
process document will lead you into more information about how W3C works.  
Note that in my personal opinion the Wikipedia page about W3C is outdated  
and very poor quality information.

cheers

Chaals

> Best regards
>
> 2013/2/14 Ian Yang <ian at invigoreight.com>
>
>> Hi Steve,
>>
>> Thanks. And sorry, but til now I still don't understand the differences
>> between whatwg and html wg. Could you please explain?
>>
>> Regards,
>> Ian
>>
>> On Thu, Feb 14, 2013 at 12:59 AM, Steve Faulkner
>> <faulkner.steve at gmail.com>wrote:
>>
>> > Hi Ian,
>> >
>> > I cannot speak for whatwg, but from the W3C HTML spec side the main
>> element
>> > is in the HTML 5.1 spec and has been implemented in browsers and so  
>> will
>> be
>> > added to HTML5 spec at some point as it likely meets the CR exit
>> criteria.
>> >
>> > as for it being a sectioning element, there is currently an open bug  
>> on
>> > that, which we be dealt with.
>> >
>> > If you want to discuss the specification of the main element in HTML  
>> 5.1
>> > specification feel free mail the html wg list. If you want to discuss
>> > definition as per the whatwg spec this is the place, although I will
>> > obviously follow ant discussions with interest
>> >
>> > regards
>> > SteveF
>> >
>> >
>> > Date: Wed, 13 Feb 2013 18:31:32 +0800
>> > > From: Ian Yang <ian at invigoreight.com>
>> > > To: whatwg <whatwg at whatwg.org>
>> > > Subject: [whatwg] Is <main> now an official HTML5 element?
>> > > Message-ID:
>> > >         <CABr1FsfcaX8=B8TReG8Sz36W=
>> >
>> > h1w0hRY61+LG=Cebo-ZUWYfqA at mail.gmail.com>
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>> > Hi editors and all other folks,
>> >
>> > I saw the SitePoint article "Introducing the New HTML5 <main>
>> > Element<http://www.sitepoint.com/html5-main-element/>"
>> > yesterday. Does that mean <main> element has been approved by all  
>> editors
>> > of the working group?
>> >
>> > However, in spec, it still says that <main> element is not a  
>> sectioning
>> > element. That means, in document outline, main content will form  
>> another
>> > tree structure instead of appearing under the original website tree
>> > structure. Can we have somebody advise on this? Is there a special
>> > consideration to not making <main> a sectioning element?
>> >
>> >
>> > Sincerely,
>> > Ian Yan
>> >
>>
>
>
>


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals at yandex-team.ru         Find more at http://yandex.com

From ian at invigoreight.com  Wed Feb 13 20:46:42 2013
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 14 Feb 2013 12:46:42 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <op.wsha4ehcy3oazb@chaals.local>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
	<CABr1FsfyfqfYCYeKkhxoPjH4V3Ng6z3_TpXxa30ug9HwodzXwg@mail.gmail.com>
	<CANbOm4h=VFnQxuYhb40SizEEC8irMVi+9ZQ5E39ngm-TzEaKdg@mail.gmail.com>
	<op.wsha4ehcy3oazb@chaals.local>
Message-ID: <CABr1FsfzQmR60Ew_6mZ8BneQ78gnDE2cmKxyAwPjSj+ig9+ZUw@mail.gmail.com>

On Thu, Feb 14, 2013 at 12:37 PM, Charles McCathie Nevile <
chaals at yandex-team.ru> wrote:

> Hi Ian,
>
>
> On Thu, 14 Feb 2013 01:31:36 +0100, Aurelio De Rosa <
> aurelioderosa at gmail.com> wrote:
>
>  I think this should answer your question:
>>
>> http://wiki.whatwg.org/wiki/**FAQ#What_is_the_WHATWG.3F<http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F>
>>
>
> It doesn't seem to provide much useful information on the differences.
>
> According to its charter <http://www.whatwg.org/charter**>, WHAT-WG is a
> group of 9 individuals who work with a very simple set of rules (basically
> the editor of a specification decides what should be in it, but the 9
> people can decide other things by "overwhelming majority"). There is a
> mailing list, IRC, etc, and everyone else who contributes to the discussion
> is called a contributor.
> More about how WHAT-WG works is described at http://wiki.whatwg.org/wiki/*
> *FAQ <http://wiki.whatwg.org/wiki/FAQ>
>
> The HTML WG is one of the working groups of W3C. The working group has a
> charter that describes some of how it works: <http://www.w3.org/2007/03/**
> HTML-WG-charter <http://www.w3.org/2007/03/HTML-WG-charter>> W3C itself
> is a consortium of member organisations, and the links from the HTML WG
> charter to the process document will lead you into more information about
> how W3C works. Note that in my personal opinion the Wikipedia page about
> W3C is outdated and very poor quality information.
>
> cheers
>
> Chaals
>
>
Hi Charles,

Thank you for providing resources. I will try to determine what topic
belongs to which group in the future.

Kind Regards,
Ian


>
>  Best regards
>>
>> 2013/2/14 Ian Yang <ian at invigoreight.com>
>>
>>  Hi Steve,
>>>
>>> Thanks. And sorry, but til now I still don't understand the differences
>>> between whatwg and html wg. Could you please explain?
>>>
>>> Regards,
>>> Ian
>>>
>>> On Thu, Feb 14, 2013 at 12:59 AM, Steve Faulkner
>>> <faulkner.steve at gmail.com>**wrote:
>>>
>>> > Hi Ian,
>>> >
>>> > I cannot speak for whatwg, but from the W3C HTML spec side the main
>>> element
>>> > is in the HTML 5.1 spec and has been implemented in browsers and so
>>> will
>>> be
>>> > added to HTML5 spec at some point as it likely meets the CR exit
>>> criteria.
>>> >
>>> > as for it being a sectioning element, there is currently an open bug on
>>> > that, which we be dealt with.
>>> >
>>> > If you want to discuss the specification of the main element in HTML
>>> 5.1
>>> > specification feel free mail the html wg list. If you want to discuss
>>> > definition as per the whatwg spec this is the place, although I will
>>> > obviously follow ant discussions with interest
>>> >
>>> > regards
>>> > SteveF
>>> >
>>> >
>>> > Date: Wed, 13 Feb 2013 18:31:32 +0800
>>> > > From: Ian Yang <ian at invigoreight.com>
>>> > > To: whatwg <whatwg at whatwg.org>
>>> > > Subject: [whatwg] Is <main> now an official HTML5 element?
>>> > > Message-ID:
>>> > >         <CABr1FsfcaX8=B8TReG8Sz36W=
>>> >
>>> > h1w0hRY61+LG=Cebo-ZUWYfqA@**mail.gmail.com<Cebo-ZUWYfqA at mail.gmail.com>
>>> >
>>> > Content-Type: text/plain; charset=ISO-8859-1
>>> >
>>> > Hi editors and all other folks,
>>> >
>>> > I saw the SitePoint article "Introducing the New HTML5 <main>
>>> > Element<http://www.sitepoint.**com/html5-main-element/<http://www.sitepoint.com/html5-main-element/>
>>> >"
>>> > yesterday. Does that mean <main> element has been approved by all
>>> editors
>>> > of the working group?
>>> >
>>> > However, in spec, it still says that <main> element is not a sectioning
>>> > element. That means, in document outline, main content will form
>>> another
>>> > tree structure instead of appearing under the original website tree
>>> > structure. Can we have somebody advise on this? Is there a special
>>> > consideration to not making <main> a sectioning element?
>>> >
>>> >
>>> > Sincerely,
>>> > Ian Yan
>>> >
>>>
>>>
>>
>>
>>
>
> --
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>       chaals at yandex-team.ru         Find more at http://yandex.com
>

From silviapfeiffer1 at gmail.com  Wed Feb 13 21:12:23 2013
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Thu, 14 Feb 2013 16:12:23 +1100
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CABr1FsfzQmR60Ew_6mZ8BneQ78gnDE2cmKxyAwPjSj+ig9+ZUw@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
	<CABr1FsfyfqfYCYeKkhxoPjH4V3Ng6z3_TpXxa30ug9HwodzXwg@mail.gmail.com>
	<CANbOm4h=VFnQxuYhb40SizEEC8irMVi+9ZQ5E39ngm-TzEaKdg@mail.gmail.com>
	<op.wsha4ehcy3oazb@chaals.local>
	<CABr1FsfzQmR60Ew_6mZ8BneQ78gnDE2cmKxyAwPjSj+ig9+ZUw@mail.gmail.com>
Message-ID: <CAHp8n2=pq7zJsA1++V8Cc=EWvMw3Qb3WVp1GTi5bLHhCJFK44w@mail.gmail.com>

> I will try to determine what topic
> belongs to which group in the future.

The simple answer is: have your discussion wherever you feel comfortable to
have it. Even if the specs differ, in the end what matters is what browsers
implement.

If a discussion about a topic is more appropriate in a different forum (and
that could also be the W3C CSS WG, a W3C Community Group, a IETF list or
other list), ppl will soon enough tell you.

HTH.
Silvia.

From ian at hixie.ch  Wed Feb 13 21:28:45 2013
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 14 Feb 2013 05:28:45 +0000 (UTC)
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CABr1FschgJcVXGYRGt_4fEVWog922PvHc_rS3hd2Obp8TmizFg@mail.gmail.com>
References: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
	<Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>
	<CABr1FsdDTh4FFLWrcgGspH=gFSH_D5h_-Mq8KUmFgaczDgawiw@mail.gmail.com>
	<CABr1FschgJcVXGYRGt_4fEVWog922PvHc_rS3hd2Obp8TmizFg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1302140439270.3956@ps20323.dreamhostps.com>

On Thu, 14 Feb 2013, Ian Yang wrote:
> 
> In the past, I always regarded a sectioning main content area is an 
> indispensable part in a document. Today, information above tell me that 
> the main content area seem doesn't need to be a titled section.

I'm not sure what you mean.

<main> is just there to help you if you need to style the main part of the 
doc, basically. It's separate from marking up a _section_ of the document, 
which is what you would do using <section> or <article>.


> So it seems that the following markup contains one unnecessary <section> 
> and one unnecessary <h1>, and they cause one unnecessary indent in 
> document outline.
> 
> <!DOCTYPE html>
> <title>lorem ipsum</title>
> <header>
>     <h1>Branding</h1>
>     <nav>
>         <h1>Navigation</h1>
>         lorem ipsum
>     </nav>
> </header>
> <section id="main" role="main">
>     <h1>Main Content</h1>
>     <section>
>         <h1>Welcome</h1>
>         lorem ipsum
>     </section>
>     <section>
>         <h1>Intro</h1>
>         lorem ipsum
>     </section>
>     <aside id="comp" role="complementary">
>         <h1>Complementary Content</h1>
>         <article>
>             <h1>Latest News</h1>
>             lorem ipsum
>         </article>
>         <article>
>             <h1>Recent Comments</h1>
>             lorem ipsum
>         </article>
>     </aside>
> </section>
> <footer>
>     lorem ipsum
> </footer>
> 
> 1. Branding
>         1. Navigation
>         2. Main Content
>                 1. Welcome
>                 2. Intro
>                 3. Complementary Content
>                         1. Latest News
>                         2. Recent Comments

It's easier to discuss with concrete cases. I haven't seen any pages that 
actually have an explicit "main content" section title, that seems a bit 
weird. You don't typically have a section in a book that contains the 
chapters, separate from the section that contains the table of contents or 
the appendices.


> And the following markup and document outline are more appropriate. 
>
> <!DOCTYPE html>
> <title>lorem ipsum</title>
> <header>
>     <h1>Branding</h1>
>     <nav>
>         <h1>Navigation</h1>
>         lorem ipsum
>     </nav>
> </header>
> <main id="main" role="main">
>     <section>
>         <h1>Welcome</h1>
>         lorem ipsum
>     </section>
>     <section>
>         <h1>Intro</h1>
>         lorem ipsum
>     </section>
>     <aside id="comp" role="complementary">
>         <h1>Complementary Content</h1>
>         <article>
>             <h1>Latest News</h1>
>             lorem ipsum
>         </article>
>         <article>
>             <h1>Recent Comments</h1>
>             lorem ipsum
>         </article>
>     </aside>
> </main>
> <footer>
>     lorem ipsum
> </footer>
> 
> 1. Branding
>         1. Navigation
>         2. Welcome
>         3. Intro
>         4. Complementary Content
>                 1. Latest News
>                 2. Recent Comments

That's fine too (modulo my comments below). You could also just not bother 
with the <main> element here, as in:

   <!DOCTYPE html>
   <title>lorem ipsum</title>
   <header>
       <h1>Branding</h1>
       <nav>
           <h1>Navigation</h1>
           lorem ipsum
       </nav>
   </header>
   <section>
       <h1>Welcome</h1>
       lorem ipsum
   </section>
   <section>
       <h1>Intro</h1>
       lorem ipsum
   </section>
   <aside>
       <h1>Complementary Content</h1>
       <article>
           <h1>Latest News</h1>
           lorem ipsum
       </article>
       <article>
           <h1>Recent Comments</h1>
           lorem ipsum
       </article>
   </aside>
   <footer>
       lorem ipsum
   </footer>
   
   1. Branding
           1. Navigation
           2. Welcome
           3. Intro
           4. Complementary Content
                   1. Latest News
                   2. Recent Comments

It's really an authoring choice.


> Since the <main> is not a sectioning element, now it only serves as an 
> element for keyboard navigation (id="main") and for assistive technology 
> to quick navigate to (role="main").

It mainly serves as a styling hook. (Accessibility tools can't rely on the 
page having a "main" element or an element with role=main, since most 
pages don't use it. HTML actually provides enough hooks already for UAs to 
help users navigate a page.)


On Thu, 14 Feb 2013, Ian Yang wrote:
> 
> One thing needs to be figured out is that should <aside
> role="complementary"> be contained within <main role="main">? Or rather, is
> <aside role="complementary"> a supporting content for the entire document
> or just for <main role="main">? If it is the latter, then <aside> is fine
> being within <main>.

The two elements are orthogonal. You can use one in the other or vice 
versa, or have them separate, or just one, or have neither.


> The spec doesn't look like it has clearly defined the relationship 
> between <main> and <aside>.

There is no relationship.

One indicates a section of a page that consists of content that is 
tangentially related to the content around the aside element, and which 
could be considered separate from that content, e.g. a sidebar. The other 
is just a container for the dominant contents of an element.

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From ian at invigoreight.com  Wed Feb 13 21:49:51 2013
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 14 Feb 2013 13:49:51 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <Pine.LNX.4.64.1302140439270.3956@ps20323.dreamhostps.com>
References: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
	<Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>
	<CABr1FsdDTh4FFLWrcgGspH=gFSH_D5h_-Mq8KUmFgaczDgawiw@mail.gmail.com>
	<CABr1FschgJcVXGYRGt_4fEVWog922PvHc_rS3hd2Obp8TmizFg@mail.gmail.com>
	<Pine.LNX.4.64.1302140439270.3956@ps20323.dreamhostps.com>
Message-ID: <CABr1Fsfzg0tnExV6ZaC1_sj4CW9tfzo2BapkP+GqYL9EndkMWg@mail.gmail.com>

Hi Hickson,

Thanks for the help.

There is one thing which makes me confused. You mentioned the <main> is
"mainly serves as a styling hook." If what we need is just a styling hook,
why was <main> introduced? We could just use <div>. So iiuic, the <main>
still has its purpose because it natively has the role "main". Please
correct me if I'm wrong.


Kind Regards,
Ian Yang

From cabanier at gmail.com  Wed Feb 13 21:54:11 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Thu, 14 Feb 2013 16:54:11 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
Message-ID: <CAGN7qDAF_NjB8DHMXjmFd4qARifGTQOZZgQ3-jUU5qREYjsZuA@mail.gmail.com>

On Thu, Feb 14, 2013 at 3:35 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> Looking at the WebKit implementation, I'm unsure how 'opaque' can
>> implemented for accelerated canvas. It might work with non-accelerated
>> canvas but would have to run some experiments.
>> I also look at mozilla's Core Graphics implementation and unless I'm
>> missing something, it doesn't have special code to handle 'opaque'. When do
>> you use this parameter?
>>
>
> CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That
> selects a surface format that is passed down to the graphics layer when
> creating the canvas surface. It's true that we don't currently do anything
> with that when drawing with CoreGraphics. That would need to be cleaned up
> before we started promoting this feature.
>
> Now that you mention it, having to modify the definition of compositing is
> a bit of a bummer for the 'opaque' attribute approach. I think we could do
> everything we want using your approach --- internally keeping a flag to
> indicate whether the alpha values of the canvas are all 1, setting it when
> the canvas is filled with a solid color and clearing it when non-over
> drawing (or clear()) are used. Let's try that!
>
> But I think "matte" is unnecessarily obscure. How about adding a
> clear(DOMString) method that does a 'copy' of the color to the entire
> canvas buffer? The color could default to rgba(0,0,0,0).


Yes, that would work.
Drawbacks are:
- you can't draw onto a transparent backdrop and apply matting.
- if you use a compositing mode that changes the canvas alpha to something
else than 1, you can't optimize the drawing any more.

Both these are caused because 'clear' removes the canvas content.

From ian at hixie.ch  Wed Feb 13 22:55:51 2013
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 14 Feb 2013 06:55:51 +0000 (UTC)
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CABr1Fsfzg0tnExV6ZaC1_sj4CW9tfzo2BapkP+GqYL9EndkMWg@mail.gmail.com>
References: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
	<Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>
	<CABr1FsdDTh4FFLWrcgGspH=gFSH_D5h_-Mq8KUmFgaczDgawiw@mail.gmail.com>
	<CABr1FschgJcVXGYRGt_4fEVWog922PvHc_rS3hd2Obp8TmizFg@mail.gmail.com>
	<Pine.LNX.4.64.1302140439270.3956@ps20323.dreamhostps.com>
	<CABr1Fsfzg0tnExV6ZaC1_sj4CW9tfzo2BapkP+GqYL9EndkMWg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1302140654260.3956@ps20323.dreamhostps.com>

On Thu, 14 Feb 2013, Ian Yang wrote:
> 
> There is one thing which makes me confused. You mentioned the <main> is 
> "mainly serves as a styling hook." If what we need is just a styling 
> hook, why was <main> introduced? We could just use <div>.

Yeah, that was my argument too. But browser vendors added it, and the spec 
matches reality, so I added it to the spec.


> So iiuic, the <main> still has its purpose because it natively has the 
> role "main". Please correct me if I'm wrong.

The "main" role isn't necessary. IMHO it's a mistake in ARIA that this 
role even exists.

But that's a discussion for the ARIA list; this list is the wrong place 
to discuss ARIA.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From faulkner.steve at gmail.com  Wed Feb 13 23:24:42 2013
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Thu, 14 Feb 2013 07:24:42 +0000
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
Message-ID: <CA+ri+Vn6OUUaMXmzekMBLADypsaoATPtJhjsZb73yxhNTosO6A@mail.gmail.com>

Silvia wrote:

> Even if the specs differ, in the end what matters is what browsers
> implement.

Partially agree, it matters what conformance checkers implement and in the
case of <main>.
the major HTML conformance checker will implement the conformance rules in
the W3C HTML spec.
This will leave the WHATWG spec not matching reality.

It should also be noted that as implemented in browsers <main> is
implemented as per the W3C spec i.e.
<main> is mapped to role=main and because of this <main> is interpreted by
AT as a main landmark already.
This leaves the WHATWG spec not matching reality.

Beyond the priorities and domain of the browser vendors is the conformance
requirements and advice the HTML spec provides
to authors which can directly impact the experience for users. So I suggest
non browser differences matter very much.


regards
SteveF

From ian at invigoreight.com  Thu Feb 14 01:41:46 2013
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 14 Feb 2013 17:41:46 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <Pine.LNX.4.64.1302140654260.3956@ps20323.dreamhostps.com>
References: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
	<Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>
	<CABr1FsdDTh4FFLWrcgGspH=gFSH_D5h_-Mq8KUmFgaczDgawiw@mail.gmail.com>
	<CABr1FschgJcVXGYRGt_4fEVWog922PvHc_rS3hd2Obp8TmizFg@mail.gmail.com>
	<Pine.LNX.4.64.1302140439270.3956@ps20323.dreamhostps.com>
	<CABr1Fsfzg0tnExV6ZaC1_sj4CW9tfzo2BapkP+GqYL9EndkMWg@mail.gmail.com>
	<Pine.LNX.4.64.1302140654260.3956@ps20323.dreamhostps.com>
Message-ID: <CABr1FsfEru_Gvuvx=xyZ0mHKJernBsdsrxZq7vjfRPOO5RGZzQ@mail.gmail.com>

On Thu, Feb 14, 2013 at 2:55 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 14 Feb 2013, Ian Yang wrote:
> >
> > There is one thing which makes me confused. You mentioned the <main> is
> > "mainly serves as a styling hook." If what we need is just a styling
> > hook, why was <main> introduced? We could just use <div>.
>
> Yeah, that was my argument too. But browser vendors added it, and the spec
> matches reality, so I added it to the spec.
>
>
> > So iiuic, the <main> still has its purpose because it natively has the
> > role "main". Please correct me if I'm wrong.
>
> The "main" role isn't necessary. IMHO it's a mistake in ARIA that this
> role even exists.
>
> But that's a discussion for the ARIA list; this list is the wrong place
> to discuss ARIA.
>

I see. Thanks anyway.

Regards,
Ian Yang

From faulkner.steve at gmail.com  Thu Feb 14 02:24:00 2013
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Thu, 14 Feb 2013 10:24:00 +0000
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CA+ri+Vn6OUUaMXmzekMBLADypsaoATPtJhjsZb73yxhNTosO6A@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
	<CA+ri+Vn6OUUaMXmzekMBLADypsaoATPtJhjsZb73yxhNTosO6A@mail.gmail.com>
Message-ID: <CA+ri+VmBu8HtbatoMZA0qv9qn3CjQQfv9R=tGOX6cHUPmP4bfw@mail.gmail.com>

Chaals wrote:

The HTML WG is one of the working groups of W3C. The working group has a
charter that describes some of how it works:
<http://www.w3.org/2007/03/HTML-WG-charter>


for those interested there is the up to date proposed charter which is
being reviewed currently:

http://www.w3.org/html/wg/charter/2012/


regards
SteveF

From senorblanco at chromium.org  Thu Feb 14 02:59:20 2013
From: senorblanco at chromium.org (Stephen White)
Date: Thu, 14 Feb 2013 05:59:20 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
Message-ID: <CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>

On Wed, Feb 13, 2013 at 11:35 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> Looking at the WebKit implementation, I'm unsure how 'opaque' can
>> implemented for accelerated canvas. It might work with non-accelerated
>> canvas but would have to run some experiments.
>> I also look at mozilla's Core Graphics implementation and unless I'm
>> missing something, it doesn't have special code to handle 'opaque'. When do
>> you use this parameter?
>>
>
> CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That
> selects a surface format that is passed down to the graphics layer when
> creating the canvas surface. It's true that we don't currently do anything
> with that when drawing with CoreGraphics. That would need to be cleaned up
> before we started promoting this feature.
>
> Now that you mention it, having to modify the definition of compositing is
> a bit of a bummer for the 'opaque' attribute approach. I think we could do
> everything we want using your approach --- internally keeping a flag to
> indicate whether the alpha values of the canvas are all 1, setting it when
> the canvas is filled with a solid color and clearing it when non-over
> drawing (or clear()) are used. Let's try that!
>

I think this is difficult to do in the general case, such as putImageData()
or drawImage() or patterns, since you would need to examine all the pixels
of the source image to determine if they contain non-1 alpha.  This would
be cost-prohibitive.

If it's just for the purposes of optimization, you could be conservative
and simply clear the flag when there's the potential for (but not certainty
of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
the behaviour becomes quite unpredictable for the web developer and hard to
spec crisply.

We could consider separating the two concepts again.  In an earlier thread,
there was an attempt to automatically determine all the places where it's
safe to enabled subpixel AA, but that seemed to result in a complex
implementation, with all cases still not being covered (such as
canvas-to-canvas drawImage()). The other alternative is programmatic
control over subpixel AA, using a context attribute. That was the first
thing that Justin proposed in the earlier thread, and would be my
preference as well (a fully-loaded footgun:  you can shoot yourself with
it, but the behaviour and performance characteristics are very easy to
understand and spec).  But there didn't seem to be agreement around that
either.

Which is how I ended up at the "moz-opaque" flag.  it restricts canvas to
the subset of operations which result in a 1 alpha in the backing store, to
allow optimizations and the use of subpixel AA.  I think that is actually
quite a useful subset (generally, the subset that doesn't need destination
alpha).  I believe the same thing can be achieved in WebGL by setting the
"alpha" attribute to false in WebGLContextAttributes.

Stephen


> But I think "matte" is unnecessarily obscure. How about adding a
> clear(DOMString) method that does a 'copy' of the color to the entire
> canvas buffer? The color could default to rgba(0,0,0,0).
>
>
> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>

From ian at hixie.ch  Thu Feb 14 07:21:06 2013
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 14 Feb 2013 15:21:06 +0000 (UTC)
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CA+ri+Vn6OUUaMXmzekMBLADypsaoATPtJhjsZb73yxhNTosO6A@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
	<CA+ri+Vn6OUUaMXmzekMBLADypsaoATPtJhjsZb73yxhNTosO6A@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1302141517190.3956@ps20323.dreamhostps.com>

On Thu, 14 Feb 2013, Steve Faulkner wrote:
> 
> Partially agree, it matters what conformance checkers implement and in 
> the case of <main>. the major HTML conformance checker will implement 
> the conformance rules in the W3C HTML spec. This will leave the WHATWG 
> spec not matching reality.

When it comes to conformance requirements, the reality that is most 
important to follow is usage, not validator implementations. But input 
from validator implementors is naturally taken into consideration. Should 
there be specific feedback from Henri or Mike on this topic, I will 
naturally examine it along with all other feedback.


> It should also be noted that as implemented in browsers <main> is 
> implemented as per the W3C spec i.e. <main> is mapped to role=main and 
> because of this <main> is interpreted by AT as a main landmark already. 
> This leaves the WHATWG spec not matching reality.

The spec already matches reality here as far as I can tell.


> Beyond the priorities and domain of the browser vendors is the 
> conformance requirements and advice the HTML spec provides to authors 
> which can directly impact the experience for users. So I suggest non 
> browser differences matter very much.

Agreed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From cabanier at gmail.com  Thu Feb 14 09:32:25 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Thu, 14 Feb 2013 09:32:25 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
Message-ID: <CAGN7qDBW+2Q_HAA5jTOPkpMDYZn88otpHmgJu2WTRF+fd=YnmQ@mail.gmail.com>

On Thu, Feb 14, 2013 at 2:59 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Wed, Feb 13, 2013 at 11:35 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>
>>> Looking at the WebKit implementation, I'm unsure how 'opaque' can
>>> implemented for accelerated canvas. It might work with non-accelerated
>>> canvas but would have to run some experiments.
>>> I also look at mozilla's Core Graphics implementation and unless I'm
>>> missing something, it doesn't have special code to handle 'opaque'. When do
>>> you use this parameter?
>>>
>>
>> CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That
>> selects a surface format that is passed down to the graphics layer when
>> creating the canvas surface. It's true that we don't currently do anything
>> with that when drawing with CoreGraphics. That would need to be cleaned up
>> before we started promoting this feature.
>>
>> Now that you mention it, having to modify the definition of compositing
>> is a bit of a bummer for the 'opaque' attribute approach. I think we could
>> do everything we want using your approach --- internally keeping a flag to
>> indicate whether the alpha values of the canvas are all 1, setting it when
>> the canvas is filled with a solid color and clearing it when non-over
>> drawing (or clear()) are used. Let's try that!
>>
>
> I think this is difficult to do in the general case, such as
> putImageData() or drawImage() or patterns, since you would need to examine
> all the pixels of the source image to determine if they contain non-1
> alpha.  This would be cost-prohibitive.
>

You only have to do that if you use compositing modes such as source-in
though.
In addition, you could detect at low cost that the CanvasImageSource is
opaque so some compositing modes would not reset.


>
> If it's just for the purposes of optimization, you could be conservative
> and simply clear the flag when there's the potential for (but not certainty
> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
> the behaviour becomes quite unpredictable for the web developer and hard to
> spec crisply.
>

Yes, that is worrisome. It seems another flag is in ordre.


>
> We could consider separating the two concepts again.  In an earlier
> thread, there was an attempt to automatically determine all the places
> where it's safe to enabled subpixel AA, but that seemed to result in a
> complex implementation, with all cases still not being covered (such as
> canvas-to-canvas drawImage()). The other alternative is programmatic
> control over subpixel AA, using a context attribute. That was the first
> thing that Justin proposed in the earlier thread, and would be my
> preference as well (a fully-loaded footgun:  you can shoot yourself with
> it, but the behaviour and performance characteristics are very easy to
> understand and spec).  But there didn't seem to be agreement around that
> either.
>

Can you refresh me on the issue with that? Is the cost too high?


>
> Which is how I ended up at the "moz-opaque" flag.  it restricts canvas to
> the subset of operations which result in a 1 alpha in the backing store, to
> allow optimizations and the use of subpixel AA.  I think that is actually
> quite a useful subset (generally, the subset that doesn't need destination
> alpha).  I believe the same thing can be achieved in WebGL by setting the
> "alpha" attribute to false in WebGLContextAttributes.
>

My fear is that this is too disruptive as it changes how canvas compositing
works.
It might also not be implemented easily on all platforms (especially the
ones that use the operating system to draw)


>
>
>> But I think "matte" is unnecessarily obscure. How about adding a
>> clear(DOMString) method that does a 'copy' of the color to the entire
>> canvas buffer? The color could default to rgba(0,0,0,0).
>>
>>
>> Rob
>> --
>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>
>
>

From senorblanco at chromium.org  Thu Feb 14 10:14:11 2013
From: senorblanco at chromium.org (Stephen White)
Date: Thu, 14 Feb 2013 13:14:11 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDBW+2Q_HAA5jTOPkpMDYZn88otpHmgJu2WTRF+fd=YnmQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAGN7qDBW+2Q_HAA5jTOPkpMDYZn88otpHmgJu2WTRF+fd=YnmQ@mail.gmail.com>
Message-ID: <CAPeKFThC=e-gXWV=F_r8JtA6D+jgHnvZCeyXZ4NGXLVzmDupNQ@mail.gmail.com>

On Thu, Feb 14, 2013 at 12:32 PM, Rik Cabanier <cabanier at gmail.com> wrote:

>
>
> On Thu, Feb 14, 2013 at 2:59 AM, Stephen White <senorblanco at chromium.org>wrote:
>
>> On Wed, Feb 13, 2013 at 11:35 PM, Robert O'Callahan <robert at ocallahan.org
>> > wrote:
>>
>>> On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier <cabanier at gmail.com>wrote:
>>>
>>>> Looking at the WebKit implementation, I'm unsure how 'opaque' can
>>>> implemented for accelerated canvas. It might work with non-accelerated
>>>> canvas but would have to run some experiments.
>>>> I also look at mozilla's Core Graphics implementation and unless I'm
>>>> missing something, it doesn't have special code to handle 'opaque'. When do
>>>> you use this parameter?
>>>>
>>>
>>> CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That
>>> selects a surface format that is passed down to the graphics layer when
>>> creating the canvas surface. It's true that we don't currently do anything
>>> with that when drawing with CoreGraphics. That would need to be cleaned up
>>> before we started promoting this feature.
>>>
>>> Now that you mention it, having to modify the definition of compositing
>>> is a bit of a bummer for the 'opaque' attribute approach. I think we could
>>> do everything we want using your approach --- internally keeping a flag to
>>> indicate whether the alpha values of the canvas are all 1, setting it when
>>> the canvas is filled with a solid color and clearing it when non-over
>>> drawing (or clear()) are used. Let's try that!
>>>
>>
>> I think this is difficult to do in the general case, such as
>> putImageData() or drawImage() or patterns, since you would need to examine
>> all the pixels of the source image to determine if they contain non-1
>> alpha.  This would be cost-prohibitive.
>>
>
> You only have to do that if you use compositing modes such as source-in
> though.
>

putImageData() ignores compositing mode, though, so it would always have to
be treated as alpha-modifying. If you declare with moz-opaque that the
canvas is opaque, you can still apply the optimization even with
putImageData().

In addition, you could detect at low cost that the CanvasImageSource is
> opaque so some compositing modes would not reset.
>

Not always.  For example, a partially-loaded bitmap has to be treated as
non-opaque until fully loaded, IIRC. And for canvas-to-canvas draws, you'd
be applying the same conservative algorithm that determined the opacity of
the source canvas, so it might miss some optimization cases that an
explicit declaration wouldn't.


> If it's just for the purposes of optimization, you could be conservative
>> and simply clear the flag when there's the potential for (but not certainty
>> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
>> the behaviour becomes quite unpredictable for the web developer and hard to
>> spec crisply.
>>
>
> Yes, that is worrisome. It seems another flag is in ordre.
>
>
>>
>> We could consider separating the two concepts again.  In an earlier
>> thread, there was an attempt to automatically determine all the places
>> where it's safe to enabled subpixel AA, but that seemed to result in a
>> complex implementation, with all cases still not being covered (such as
>> canvas-to-canvas drawImage()). The other alternative is programmatic
>> control over subpixel AA, using a context attribute. That was the first
>> thing that Justin proposed in the earlier thread, and would be my
>> preference as well (a fully-loaded footgun:  you can shoot yourself with
>> it, but the behaviour and performance characteristics are very easy to
>> understand and spec).  But there didn't seem to be agreement around that
>> either.
>>
>
> Can you refresh me on the issue with that? Is the cost too high?
>

Robert's comment:

> We'd have to define what happens when you use subpixel antialiasing "inco
rrectly",
> because we can be pretty sure authors will use it incorrectly and expect
to get interoperable behavior.

Ian Hickson's comment earlier in this thread:

> Do we have any reason to believe the majority of authors would make the
> right decisions here?
>
> (The main reason we haven't provided control over things like
antialiasing
> is that many authors tend to make terribly bad decisions.) (Before anyone
> gets offended, by the way: that you are reading this almost guarantees
> that you are above average in terms of authoring ability.)


>
>>
>> Which is how I ended up at the "moz-opaque" flag.  it restricts canvas to
>> the subset of operations which result in a 1 alpha in the backing store, to
>> allow optimizations and the use of subpixel AA.  I think that is actually
>> quite a useful subset (generally, the subset that doesn't need destination
>> alpha).  I believe the same thing can be achieved in WebGL by setting the
>> "alpha" attribute to false in WebGLContextAttributes.
>>
>
> My fear is that this is too disruptive as it changes how canvas
> compositing works.
>

It's opt-in, so it wouldn't affect existing content.


> It might also not be implemented easily on all platforms (especially the
> ones that use the operating system to draw)
>

It's pretty straightforward to implement with OpenGL:  allocate the backing
store as GL_RGB instead of GL_RGBA, or (if unsupported) clear the buffer to
opaque black and use glColorMask() to disable alpha writes.  Then for speed
during page compositing, disable blending.

Stephen

>
>
>>
>>
>>> But I think "matte" is unnecessarily obscure. How about adding a
>>> clear(DOMString) method that does a 'copy' of the color to the entire
>>> canvas buffer? The color could default to rgba(0,0,0,0).
>>>
>>>
>>> Rob
>>> --
>>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>>
>>
>>
>

From cabanier at gmail.com  Thu Feb 14 10:50:42 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Thu, 14 Feb 2013 10:50:42 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFThC=e-gXWV=F_r8JtA6D+jgHnvZCeyXZ4NGXLVzmDupNQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAGN7qDBW+2Q_HAA5jTOPkpMDYZn88otpHmgJu2WTRF+fd=YnmQ@mail.gmail.com>
	<CAPeKFThC=e-gXWV=F_r8JtA6D+jgHnvZCeyXZ4NGXLVzmDupNQ@mail.gmail.com>
Message-ID: <CAGN7qDD1n41DgY=_rZZwHR3xhwZxi9eaSSMO5JcvXCHioJ8+1A@mail.gmail.com>

On Thu, Feb 14, 2013 at 10:14 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Thu, Feb 14, 2013 at 12:32 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>>
>>
>> On Thu, Feb 14, 2013 at 2:59 AM, Stephen White <senorblanco at chromium.org>wrote:
>>
>>> On Wed, Feb 13, 2013 at 11:35 PM, Robert O'Callahan <
>>> robert at ocallahan.org> wrote:
>>>
>>>> On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier <cabanier at gmail.com>wrote:
>>>>
>>>>> Looking at the WebKit implementation, I'm unsure how 'opaque' can
>>>>> implemented for accelerated canvas. It might work with non-accelerated
>>>>> canvas but would have to run some experiments.
>>>>> I also look at mozilla's Core Graphics implementation and unless I'm
>>>>> missing something, it doesn't have special code to handle 'opaque'. When do
>>>>> you use this parameter?
>>>>>
>>>>
>>>> CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That
>>>> selects a surface format that is passed down to the graphics layer when
>>>> creating the canvas surface. It's true that we don't currently do anything
>>>> with that when drawing with CoreGraphics. That would need to be cleaned up
>>>> before we started promoting this feature.
>>>>
>>>> Now that you mention it, having to modify the definition of compositing
>>>> is a bit of a bummer for the 'opaque' attribute approach. I think we could
>>>> do everything we want using your approach --- internally keeping a flag to
>>>> indicate whether the alpha values of the canvas are all 1, setting it when
>>>> the canvas is filled with a solid color and clearing it when non-over
>>>> drawing (or clear()) are used. Let's try that!
>>>>
>>>
>>> I think this is difficult to do in the general case, such as
>>> putImageData() or drawImage() or patterns, since you would need to examine
>>> all the pixels of the source image to determine if they contain non-1
>>> alpha.  This would be cost-prohibitive.
>>>
>>
>> You only have to do that if you use compositing modes such as source-in
>> though.
>>
>
> putImageData() ignores compositing mode, though, so it would always have
> to be treated as alpha-modifying. If you declare with moz-opaque that the
> canvas is opaque, you can still apply the optimization even with
> putImageData().
>

no. Not if you use an opaque ImageDataSourece (such as a JPEG image or a
canvas source that knows that it's opaque.


> In addition, you could detect at low cost that the CanvasImageSource is
>> opaque so some compositing modes would not reset.
>>
>
> Not always.  For example, a partially-loaded bitmap has to be treated as
> non-opaque until fully loaded, IIRC.
>

partially loaded images are supposed to be ignored when you draw with them.


> And for canvas-to-canvas draws, you'd be applying the same conservative
> algorithm that determined the opacity of the source canvas, so it might
> miss some optimization cases that an explicit declaration wouldn't.\
>

Yes. You'd have to explicitly matte the other canvas too (if you use
putImageData or certain compositing modes).
That's still better than breaking compositing though...


>
>
>> If it's just for the purposes of optimization, you could be conservative
>>> and simply clear the flag when there's the potential for (but not certainty
>>> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
>>> the behaviour becomes quite unpredictable for the web developer and hard to
>>> spec crisply.
>>>
>>
>> Yes, that is worrisome. It seems another flag is in ordre.
>>
>>
>>>
>>> We could consider separating the two concepts again.  In an earlier
>>> thread, there was an attempt to automatically determine all the places
>>> where it's safe to enabled subpixel AA, but that seemed to result in a
>>> complex implementation, with all cases still not being covered (such as
>>> canvas-to-canvas drawImage()). The other alternative is programmatic
>>> control over subpixel AA, using a context attribute. That was the first
>>> thing that Justin proposed in the earlier thread, and would be my
>>> preference as well (a fully-loaded footgun:  you can shoot yourself with
>>> it, but the behaviour and performance characteristics are very easy to
>>> understand and spec).  But there didn't seem to be agreement around that
>>> either.
>>>
>>
>> Can you refresh me on the issue with that? Is the cost too high?
>>
>
> Robert's comment:
>
> > We'd have to define what happens when you use subpixel antialiasing
> "incorrectly",
> > because we can be pretty sure authors will use it incorrectly and
> expect to get interoperable behavior.
>
> Ian Hickson's comment earlier in this thread:
>
> > Do we have any reason to believe the majority of authors would make the
> > right decisions here?
> >
> > (The main reason we haven't provided control over things like
> antialiasing
> > is that many authors tend to make terribly bad decisions.) (Before
> anyone
> > gets offended, by the way: that you are reading this almost guarantees
> > that you are above average in terms of authoring ability.)
>

What is the technical issue? Why does anti-aliasing only work if you have
an opaque canvas?


>
>
>>
>>>
>>> Which is how I ended up at the "moz-opaque" flag.  it restricts canvas
>>> to the subset of operations which result in a 1 alpha in the backing store,
>>> to allow optimizations and the use of subpixel AA.  I think that is
>>> actually quite a useful subset (generally, the subset that doesn't need
>>> destination alpha).  I believe the same thing can be achieved in WebGL by
>>> setting the "alpha" attribute to false in WebGLContextAttributes.
>>>
>>
>> My fear is that this is too disruptive as it changes how canvas
>> compositing works.
>>
>
> It's opt-in, so it wouldn't affect existing content.
>
>
>> It might also not be implemented easily on all platforms (especially the
>> ones that use the operating system to draw)
>>
>
> It's pretty straightforward to implement with OpenGL:  allocate the
> backing store as GL_RGB instead of GL_RGBA, or (if unsupported) clear the
> buffer to opaque black and use glColorMask() to disable alpha writes.  Then
> for speed during page compositing, disable blending.
>

How about the accelerated core graphics backend? Direct2D?


>
> Stephen
>
>>
>>
>>>
>>>
>>>> But I think "matte" is unnecessarily obscure. How about adding a
>>>> clear(DOMString) method that does a 'copy' of the color to the entire
>>>> canvas buffer? The color could default to rgba(0,0,0,0).
>>>>
>>>>
>>>> Rob
>>>> --
>>>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>>>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>>>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>>>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>>>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>>>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>>>
>>>
>>>
>>
>

From robert at ocallahan.org  Thu Feb 14 19:21:20 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 15 Feb 2013 16:21:20 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
Message-ID: <CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>

On Thu, Feb 14, 2013 at 11:59 PM, Stephen White <senorblanco at chromium.org>wrote:

> I think this is difficult to do in the general case, such as
> putImageData() or drawImage() or patterns, since you would need to examine
> all the pixels of the source image to determine if they contain non-1
> alpha.  This would be cost-prohibitive.


> If it's just for the purposes of optimization, you could be conservative
> and simply clear the flag when there's the potential for (but not certainty
> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
> the behaviour becomes quite unpredictable for the web developer and hard to
> spec crisply.
>

What if we just said
a) non-over operators clear the subpixel AA flag
b) putImageData clears the subpixel AA flag
Both of these are infrequently used AFAIK. Authors could work around most
cases of b) by doing putImageData to another canvas and compositing it into
the destination with 'over'.

How bad would that be? Would it help if we added an attribute to the canvas
to let authors detect whether the subpixel AA flag is set?

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From ehs at pobox.com  Thu Feb 14 19:32:02 2013
From: ehs at pobox.com (Ed Summers)
Date: Thu, 14 Feb 2013 22:32:02 -0500
Subject: [whatwg] itemtypes from same vocabulary
In-Reply-To: <CACho_At=xBDkwcNV5AssDbMfsdk1FtjEFBSa7AM1fVxohy46Rg@mail.gmail.com>
References: <CABzDd=70TtoPhqQzpop+Y8YeeOM_SCwi8+hog=r-4yMn3G79zw@mail.gmail.com>
	<CACho_Av7dsGmxUozJv6Aj1xNhZJh9ESSujWKcA_KtX5AcT_Feg@mail.gmail.com>
	<CABzDd=6C_WQo9uyVowX+tBGvijMGx7VRvbeoRQKtaF4uHwduBQ@mail.gmail.com>
	<CACho_At=xBDkwcNV5AssDbMfsdk1FtjEFBSa7AM1fVxohy46Rg@mail.gmail.com>
Message-ID: <CABzDd=4-Kk=7-xBxvSNCjh1RQU6dwfxmTbdo-Y2RLWbtB8CW7Q@mail.gmail.com>

Thanks for the further pointer Lin. I can see that the change request
to allow multiple itemtypes came from John Giannandrea (Google), and
specifically concerned schema.org.

In John's email [1] he proposed limiting multiple types to being from
the same origin domain, not the same vocabulary as is stated in the
Microdata spec. It sounds like an obvious question, but is there a
precise definition of what is meant by "same vocabulary"? Or is it
just a hand wavy way of talking about what humans understand when
putting the itemtype URLs in their browsers, reading, and
understanding that they are types that are part of some larger
coherent whole?

//Ed

[1] http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0364.html

On Wed, Feb 13, 2013 at 11:36 AM, Lin Clark <lin.w.clark at gmail.com> wrote:
> Sorry if it wasn't clear, at the time that those discussions took place,
> only one itemtype could be used. Since then, the spec was changed to allow
> multiple itemtypes from the same vocabulary.
>
> However, both discussions also touch on the issue of using multiple
> vocabularies in itemtype. For example, my response [1] in the first.
>
> [1]
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0383.html

From cabanier at gmail.com  Thu Feb 14 19:44:13 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Fri, 15 Feb 2013 14:44:13 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
Message-ID: <CAGN7qDCQyb-_ioWRWoxBiQwAL7N2K5rPukbjWt7g-XjFfC509A@mail.gmail.com>

On Fri, Feb 15, 2013 at 2:21 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Feb 14, 2013 at 11:59 PM, Stephen White <senorblanco at chromium.org>wrote:
>
>> I think this is difficult to do in the general case, such as
>> putImageData() or drawImage() or patterns, since you would need to examine
>> all the pixels of the source image to determine if they contain non-1
>> alpha.  This would be cost-prohibitive.
>
>
>> If it's just for the purposes of optimization, you could be conservative
>> and simply clear the flag when there's the potential for (but not certainty
>> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
>> the behaviour becomes quite unpredictable for the web developer and hard to
>> spec crisply.
>>
>
> What if we just said
> a) non-over operators clear the subpixel AA flag
> b) putImageData clears the subpixel AA flag
> Both of these are infrequently used AFAIK. Authors could work around most
> cases of b) by doing putImageData to another canvas and compositing it into
> the destination with 'over'.
>

Yes, that's pretty much my proposal. Except putImageData could detect it
but that might be too hard for authors to figure out.


>
> How bad would that be? Would it help if we added an attribute to the
> canvas to let authors detect whether the subpixel AA flag is set?


I think that would be very helpful.

So, if you clear (or matte) the canvas, the flag becomes true but if you do
an operator that removes alpha, it will become false.


>
>
> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>

From mkwst at google.com  Fri Feb 15 00:08:35 2013
From: mkwst at google.com (Mike West)
Date: Fri, 15 Feb 2013 09:08:35 +0100
Subject: [whatwg] Sandboxed IFrames and downloads.
In-Reply-To: <CAKXHy=eHTuTehhaAsFdumu-Rr1sgJZfRMGKOfnYUKcEV+T3gSw@mail.gmail.com>
References: <CAKXHy=eHTuTehhaAsFdumu-Rr1sgJZfRMGKOfnYUKcEV+T3gSw@mail.gmail.com>
Message-ID: <CAKXHy=exj5SjiUiwFxdypd0HQrSPpHnaPFA5rQg0MWH1gU-GPg@mail.gmail.com>

Ping. Is this a terrible idea? :)

--
Mike West <mkwst at google.com>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 M?nchen, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91


On Sat, Feb 2, 2013 at 7:11 PM, Mike West <mkwst at google.com> wrote:

> It's currently possible to force a download by serving a file with a
> "Content-Disposition: attachment; filename=..." header. Notably, this
> mechanism can be used to download a file with minimal user interaction by
> including the resource to be downloaded in an IFrame. This holds even for
> sandboxed IFrames, as demonstrated by
> http://lcamtuf.coredump.cx/sandboxed.html (clicking that link will
> download a file, fair warning).
>
> It seems consistent with the general thought behind the `sandbox`
> attribute that it should control downloads as well as the bits it already
> locks down. I'd propose adjusting the spec to include a sandboxed downloads
> flag, which, when present, would block all downloads from inside the frame
> (or, perhaps only require user confirmation?). This restriction could be
> lifted via an 'allow-downloads' keyword, if present in the sandbox
> attribute's token list.
>
> WDYT?
>
> --
> Mike West <mkwst at google.com>, Developer Advocate
> Google Germany GmbH, Dienerstrasse 12, 80331 M?nchen, Germany
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>

From kochi at google.com  Fri Feb 15 00:28:03 2013
From: kochi at google.com (=?UTF-8?B?VGFrYXlvc2hpIEtvY2hpICjmsrPlhoUg6ZqG5LuBKQ==?=)
Date: Fri, 15 Feb 2013 17:28:03 +0900
Subject: [whatwg] inputmode feedback
In-Reply-To: <511BE988.7070208@lamouri.fr>
References: <511BE988.7070208@lamouri.fr>
Message-ID: <CADP2=hp-yPwWAKpeuPUwaAF=LmMfyC0Uw2_KxgQGY7cr3GaKuA@mail.gmail.com>

Hello Mounir,

On Thu, Feb 14, 2013 at 4:29 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:

> Regarding the three Japanese specific types, it is not clear if
> inputmode is the best way to solve the use cases intended to be solved.
> Actually, 'kana' and 'katakana' are trying to give a hint about the
> script that has to be used which seems to be orthogonal with the other
> types. We could allow inputmode to have a set of values but that would
> make the behaviour way more complex so I wonder if we couldn't try to
> solve that problem with another attribute like inputscript.
>
>
"three Japanese specific types"? 'kana', 'katakana', and 'full-width-latin"?

I agree that it is weird 'kana' and 'katakana' are listed as inputmode
attribute,
and 'inputscript' sounds more reasonable place where they should be listed.

As you probably know, there is also 'ime-mode' CSS style which IE/FF
implements
(and still proposed in CSS3 UI at http://www.w3.org/TR/css3-ui/#ime-mode),
which makes this more complex to use.

People may want to control IME input mode like the way Flash can,
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/IME.html
but it it is unfortunate that controlling IME from web apps is so
distributed (CSS, input attribute,
DOM lv3 compositionevent and IME API).

That said, even though authors of web apps may want to force the IME mode or
its script mode for user's sake, it may cause user's confusion as they are
so accustomed to change mode manually where such mode is required.
So if a web app sets some mode, the user may toggle it back to unintended
mode
and get frustrated.

-- 
Takayoshi Kochi

From whatwg-20070806 at james-ross.co.uk  Fri Feb 15 01:30:17 2013
From: whatwg-20070806 at james-ross.co.uk (James Ross)
Date: Fri, 15 Feb 2013 09:30:17 +0000
Subject: [whatwg] Sandboxed IFrames and downloads.
In-Reply-To: <CAKXHy=exj5SjiUiwFxdypd0HQrSPpHnaPFA5rQg0MWH1gU-GPg@mail.gmail.com>
References: <CAKXHy=eHTuTehhaAsFdumu-Rr1sgJZfRMGKOfnYUKcEV+T3gSw@mail.gmail.com>,
	<CAKXHy=exj5SjiUiwFxdypd0HQrSPpHnaPFA5rQg0MWH1gU-GPg@mail.gmail.com>
Message-ID: <DUB002-W5348442820BDCFFF2C96E8E30E0@phx.gbl>

A quick test across browsers would suggest others think it is a reasonable protection to include: both Internet Explorer 10 and Firefox 18 block (ignore) the download attempt in the sandboxed <iframe>.
  
 I couldn't find any documentation on either browser doing this, though, or if they have a sandbox flag to allow it.

-- 
James Ross silver at warwickcompsoc.co.uk
 > From: mkwst at google.com
> Date: Fri, 15 Feb 2013 09:08:35 +0100
> To: whatwg at whatwg.org
> Subject: Re: [whatwg] Sandboxed IFrames and downloads.
> 
> Ping. Is this a terrible idea? :)
> 
> --
> Mike West <mkwst at google.com>, Developer Advocate
> Google Germany GmbH, Dienerstrasse 12, 80331 M?nchen, Germany
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
> 
> 
> On Sat, Feb 2, 2013 at 7:11 PM, Mike West <mkwst at google.com> wrote:
> 
> > It's currently possible to force a download by serving a file with a
> > "Content-Disposition: attachment; filename=..." header. Notably, this
> > mechanism can be used to download a file with minimal user interaction by
> > including the resource to be downloaded in an IFrame. This holds even for
> > sandboxed IFrames, as demonstrated by
> > http://lcamtuf.coredump.cx/sandboxed.html (clicking that link will
> > download a file, fair warning).
> >
> > It seems consistent with the general thought behind the `sandbox`
> > attribute that it should control downloads as well as the bits it already
> > locks down. I'd propose adjusting the spec to include a sandboxed downloads
> > flag, which, when present, would block all downloads from inside the frame
> > (or, perhaps only require user confirmation?). This restriction could be
> > lifted via an 'allow-downloads' keyword, if present in the sandbox
> > attribute's token list.
> >
> > WDYT?
> >
> > --
> > Mike West <mkwst at google.com>, Developer Advocate
> > Google Germany GmbH, Dienerstrasse 12, 80331 M?nchen, Germany
> > Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
> >
 		 	   		  

From jonas at sicking.cc  Fri Feb 15 01:45:16 2013
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 15 Feb 2013 01:45:16 -0800
Subject: [whatwg] inputmode feedback
In-Reply-To: <511BE988.7070208@lamouri.fr>
References: <511BE988.7070208@lamouri.fr>
Message-ID: <CA+c2ei_d41LaAy_WNpFLawfTmSe-OpmG=wL7VyvbWwG1iVKrDQ@mail.gmail.com>

On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:
> Hi,
>
> Mozilla did implement an inputmode attribute for the <input> element a
> few months ago and the HTML specification has been updated after that to
> introduce that attribute. Given that the specification and our
> implementation was not matching, we decided to delay the release of that
> feature [1] and not advertise it. We unfortunately had to push a
> "x-inputmode" attribute in Firefox OS because our UI needed that feature
> but we expect to replace this with a proper inputmode implementation as
> soon as possible.
>
> Basically, the Mozilla's inputmode attribute is describing behaviour,
> the allowed value are mostly self-explanatory: auto, uppercase,
> lowercase, titlecase, autocapitalized, digit and numeric.

What's the difference between "auto" and "autocapitalized"?

> To conclude, Mozilla is interested in implementing this set of keywords:
> verbatim, text, name, prose and digit (or numeric).

I have to say, these feel a lot less understandable than the types
currently implemented in x-inputmode.

Using semantic names might give us the warm fuzzies, but is there
really any semantic use we will get out of these that we wouldn't by
using "lowercase", "titlecase" or "autocapitalized"?

I take it verbatim and name would disable any spelling corrections,
and name would also titlecase? But the difference between text and
prose seems really hard to understand. I can't even understand the
actual behavioral difference (which is what authors actually care
about) reading the spec, much less guessing by the name.

/ Jonas

From jonas at sicking.cc  Fri Feb 15 01:50:58 2013
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 15 Feb 2013 01:50:58 -0800
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CAOp6jLYEKjS3Cg8pPfrzSSPbKCgD0uRO9uu0M-6PLZ7FObqVsQ@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CADnb78hnVHE-fV=LTw0WCjbNgWbbo1+qZ9BsMeNM-xqg4f+cjw@mail.gmail.com>
	<CAOp6jLYEKjS3Cg8pPfrzSSPbKCgD0uRO9uu0M-6PLZ7FObqVsQ@mail.gmail.com>
Message-ID: <CA+c2ei-bq6qbV4HMcYWWN0iWTP68XFbUQpZD39zWuU2qo4y6ow@mail.gmail.com>

On Thu, Jan 24, 2013 at 2:49 AM, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Thu, Jan 24, 2013 at 9:44 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
>
>> On Wed, Jan 23, 2013 at 4:19 AM, Robert O'Callahan <robert at ocallahan.org>
>> wrote:
>> > I think this would be a worthwhile addition to the Web platform.
>>
>> It's somewhat ironic this happened, especially with Mozilla leading! I
>> advocated this approach from the start:
>>
>> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1515.html
>> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1576.html
>>
>
> Heh. I apologize on Jonas' behalf :-).

I don't think that I've argued against it. What I've argued against is
having this be the *only* way to read out of a blob and into things
that traditionally use URLs.

I.e. I've just been arguing that we need createObjectURL as well.

Also, for what it's worth, I'm holding out hope that we can change
createObjectURL to be autorevoking by default. That's what the latest
drafts are saying and no implementation has objected, despite repeated
pokings.

/ Jonas

From robert at ocallahan.org  Fri Feb 15 02:43:58 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 15 Feb 2013 23:43:58 +1300
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CA+c2ei-bq6qbV4HMcYWWN0iWTP68XFbUQpZD39zWuU2qo4y6ow@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CADnb78hnVHE-fV=LTw0WCjbNgWbbo1+qZ9BsMeNM-xqg4f+cjw@mail.gmail.com>
	<CAOp6jLYEKjS3Cg8pPfrzSSPbKCgD0uRO9uu0M-6PLZ7FObqVsQ@mail.gmail.com>
	<CA+c2ei-bq6qbV4HMcYWWN0iWTP68XFbUQpZD39zWuU2qo4y6ow@mail.gmail.com>
Message-ID: <CAOp6jLa+ZJC=2GxNdxkhX0VOPmNGdg921-do=kLHYqFAHJFqnA@mail.gmail.com>

On Fri, Feb 15, 2013 at 10:50 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> Also, for what it's worth, I'm holding out hope that we can change
> createObjectURL to be autorevoking by default. That's what the latest
> drafts are saying and no implementation has objected, despite repeated
> pokings.
>

Has any implementation actually taken the plunge?

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From jonas at sicking.cc  Fri Feb 15 04:37:58 2013
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 15 Feb 2013 04:37:58 -0800
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CAOp6jLa+ZJC=2GxNdxkhX0VOPmNGdg921-do=kLHYqFAHJFqnA@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CADnb78hnVHE-fV=LTw0WCjbNgWbbo1+qZ9BsMeNM-xqg4f+cjw@mail.gmail.com>
	<CAOp6jLYEKjS3Cg8pPfrzSSPbKCgD0uRO9uu0M-6PLZ7FObqVsQ@mail.gmail.com>
	<CA+c2ei-bq6qbV4HMcYWWN0iWTP68XFbUQpZD39zWuU2qo4y6ow@mail.gmail.com>
	<CAOp6jLa+ZJC=2GxNdxkhX0VOPmNGdg921-do=kLHYqFAHJFqnA@mail.gmail.com>
Message-ID: <CA+c2ei_TGhJmmOgQvUB1nr6Py_+1j4Oe0DKMR7anDQyrAXwV0w@mail.gmail.com>

On Fri, Feb 15, 2013 at 2:43 AM, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Fri, Feb 15, 2013 at 10:50 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> Also, for what it's worth, I'm holding out hope that we can change
>> createObjectURL to be autorevoking by default. That's what the latest
>> drafts are saying and no implementation has objected, despite repeated
>> pokings.
>
> Has any implementation actually taken the plunge?

It's a fairly recent change to the spec, so no. I think we should give
it a try in Firefox.

/ Jonas

From glenn at zewt.org  Fri Feb 15 06:46:02 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 15 Feb 2013 08:46:02 -0600
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
Message-ID: <CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>

On Tue, Jan 22, 2013 at 9:19 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> Currently the only way to use one of these objects as the source of a media
> element is via "element.src = URL.createObjectURL(object)". This is
> problematic because the URLs minted by createObjectURL require manual
> revocation. (Forms of auto-revocation have been proposed but a) they seem
> difficult to spec in a rational way and b) we will not be able to make
> auto-revocation the default.)


a) This isn't the case.  The tricky bit was defining precisely when
autorevocation happens; this has been resolved (the "global script clean-up
jobs list").  There's a remaining piece (
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765), but while it'll take
some thought to do that in a clean way (so it can be applied to different
APIs concisely), there's nothing magic there.
b) Even if we can't make it the default, there are much cleaner solutions
than bloating other APIs.  For example, a separate method can default to
auto-revoke, so you can say eg. img.src = blob.createRevokingURL().  I
don't like adding APIs that are just copies of other APIs with different
defaults, but it's much less evil than adding a whole separate mechanism.
In any case, explicitly saying img.src = URL.createObjectURL(blob,
{autoRevoke: true}) isn't actually that painful.

-- 
Glenn Maynard

From senorblanco at chromium.org  Fri Feb 15 07:35:42 2013
From: senorblanco at chromium.org (Stephen White)
Date: Fri, 15 Feb 2013 10:35:42 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
Message-ID: <CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>

On Thu, Feb 14, 2013 at 10:21 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Feb 14, 2013 at 11:59 PM, Stephen White <senorblanco at chromium.org>wrote:
>
>> I think this is difficult to do in the general case, such as
>> putImageData() or drawImage() or patterns, since you would need to examine
>> all the pixels of the source image to determine if they contain non-1
>> alpha.  This would be cost-prohibitive.
>
>
>> If it's just for the purposes of optimization, you could be conservative
>> and simply clear the flag when there's the potential for (but not certainty
>> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
>> the behaviour becomes quite unpredictable for the web developer and hard to
>> spec crisply.
>>
>
> What if we just said
> a) non-over operators clear the subpixel AA flag
> b) putImageData clears the subpixel AA flag
> Both of these are infrequently used AFAIK. Authors could work around most
> cases of b) by doing putImageData to another canvas and compositing it into
> the destination with 'over'.
>

Even with these constraints, I don't think we can guarantee that it's safe
to use LCD AA text. Once you've drawn with LCD AA text, even if it's safe
at the time of drawing, there's no guarantee that it will be safe later.
 For instance, if you then drawImage() that canvas rotated into another
canvas, or even just full-page-zoom it, you'll see colour fringing. Or
apply CSS 2D or 3D transforms. There are also existing apps which use
canvas for 2D text glyphs, and then transform and place them rotated in
WebGL. Those will show colour fringing. Even within canvas, there may be a
way to break it if the LCD AA text is drawn first and a dest-alpha
compositing mode is used overtop (I haven't verified this though).

So I'm starting to think that LCD AA text really has to be opt-in, to avoid
breaking existing content. By opting it, you're agreeing that these
artifacts are acceptable for your app. For example, you know that even if
you're going to do a canvas-to-canvas draw, you're always going to draw at
1:1 scale and no rotation.

Stephen



>
> How bad would that be? Would it help if we added an attribute to the
> canvas to let authors detect whether the subpixel AA flag is set?
>
>
> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>

From cabanier at gmail.com  Fri Feb 15 08:04:08 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Sat, 16 Feb 2013 03:04:08 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
Message-ID: <CAGN7qDA59YvDOkGFTLzG7-Bn3s4m7aav7O7UemeQ+BuZXN-gXw@mail.gmail.com>

On Sat, Feb 16, 2013 at 2:35 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Thu, Feb 14, 2013 at 10:21 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Thu, Feb 14, 2013 at 11:59 PM, Stephen White <senorblanco at chromium.org
>> > wrote:
>>
>>> I think this is difficult to do in the general case, such as
>>> putImageData() or drawImage() or patterns, since you would need to examine
>>> all the pixels of the source image to determine if they contain non-1
>>> alpha.  This would be cost-prohibitive.
>>
>>
>>> If it's just for the purposes of optimization, you could be conservative
>>> and simply clear the flag when there's the potential for (but not certainty
>>> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
>>> the behaviour becomes quite unpredictable for the web developer and hard to
>>> spec crisply.
>>>
>>
>> What if we just said
>> a) non-over operators clear the subpixel AA flag
>> b) putImageData clears the subpixel AA flag
>> Both of these are infrequently used AFAIK. Authors could work around most
>> cases of b) by doing putImageData to another canvas and compositing it into
>> the destination with 'over'.
>>
>
> Even with these constraints, I don't think we can guarantee that it's safe
> to use LCD AA text. Once you've drawn with LCD AA text, even if it's safe
> at the time of drawing, there's no guarantee that it will be safe later.
>  For instance, if you then drawImage() that canvas rotated into another
> canvas, or even just full-page-zoom it, you'll see colour fringing. Or
> apply CSS 2D or 3D transforms. There are also existing apps which use
> canvas for 2D text glyphs, and then transform and place them rotated in
> WebGL. Those will show colour fringing. Even within canvas, there may be a
> way to break it if the LCD AA text is drawn first and a dest-alpha
> compositing mode is used overtop (I haven't verified this though).
>
> So I'm starting to think that LCD AA text really has to be opt-in, to
> avoid breaking existing content. By opting it, you're agreeing that these
> artifacts are acceptable for your app. For example, you know that even if
> you're going to do a canvas-to-canvas draw, you're always going to draw at
> 1:1 scale and no rotation.
>

When you talk about LCD AA, do you talk about this?
http://en.wikipedia.org/wiki/Subpixel_rendering
If so, I don't think it would ever be safe to draw in such a way with
canvas as you can't expect an author to align canvas pixels with LCD pixels.

I assumed that we were just talking about regular pixel AA like we (=adobe)
do in our graphics products for line art.


>
>

>> How bad would that be? Would it help if we added an attribute to the
>> canvas to let authors detect whether the subpixel AA flag is set?
>>
>>
>> Rob
>> --
>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>
>
>

From cabanier at gmail.com  Fri Feb 15 08:08:16 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Sat, 16 Feb 2013 03:08:16 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDCQyb-_ioWRWoxBiQwAL7N2K5rPukbjWt7g-XjFfC509A@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAGN7qDCQyb-_ioWRWoxBiQwAL7N2K5rPukbjWt7g-XjFfC509A@mail.gmail.com>
Message-ID: <CAGN7qDAUNVsuA6_8tW56EqtijTTwjxc5uRjYCM4bw+FvVDbeQA@mail.gmail.com>

As an other alternative, we could also introduce a 'matteColor' attribute.
It's default would be 'transparent'.

If it's set to a css color, the canvas will be matted to that color. In
addition if you use putImageData or a compositing operator that changes
alpha, you always matte with that color afterwards (if needed).

This is actually pretty close to the 'opaque' keyword except
- it's on the canvas context
- you can specify a color
- it doesn't force reallocation of the canvas

On Fri, Feb 15, 2013 at 2:44 PM, Rik Cabanier <cabanier at gmail.com> wrote:

>
>
> On Fri, Feb 15, 2013 at 2:21 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Thu, Feb 14, 2013 at 11:59 PM, Stephen White <senorblanco at chromium.org
>> > wrote:
>>
>>> I think this is difficult to do in the general case, such as
>>> putImageData() or drawImage() or patterns, since you would need to examine
>>> all the pixels of the source image to determine if they contain non-1
>>> alpha.  This would be cost-prohibitive.
>>
>>
>>> If it's just for the purposes of optimization, you could be conservative
>>> and simply clear the flag when there's the potential for (but not certainty
>>> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
>>> the behaviour becomes quite unpredictable for the web developer and hard to
>>> spec crisply.
>>>
>>
>> What if we just said
>> a) non-over operators clear the subpixel AA flag
>> b) putImageData clears the subpixel AA flag
>> Both of these are infrequently used AFAIK. Authors could work around most
>> cases of b) by doing putImageData to another canvas and compositing it into
>> the destination with 'over'.
>>
>
> Yes, that's pretty much my proposal. Except putImageData could detect it
> but that might be too hard for authors to figure out.
>
>
>>
>> How bad would that be? Would it help if we added an attribute to the
>> canvas to let authors detect whether the subpixel AA flag is set?
>
>
> I think that would be very helpful.
>
> So, if you clear (or matte) the canvas, the flag becomes true but if you
> do an operator that removes alpha, it will become false.
>
>
>>
>>
>> Rob
>> --
>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>
>
>

From ian at hixie.ch  Fri Feb 15 11:13:33 2013
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 15 Feb 2013 19:13:33 +0000 (UTC)
Subject: [whatwg] Sandboxed IFrames and downloads.
In-Reply-To: <CAKXHy=exj5SjiUiwFxdypd0HQrSPpHnaPFA5rQg0MWH1gU-GPg@mail.gmail.com>
References: <CAKXHy=eHTuTehhaAsFdumu-Rr1sgJZfRMGKOfnYUKcEV+T3gSw@mail.gmail.com>
	<CAKXHy=exj5SjiUiwFxdypd0HQrSPpHnaPFA5rQg0MWH1gU-GPg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1302151912050.3956@ps20323.dreamhostps.com>

On Fri, 15 Feb 2013, Mike West wrote:
>
> Ping. Is this a terrible idea? :)

Sorry for the delay in answering e-mails. Since last quarter I mostly 
responded to e-mails while neglecting the bug stream, this quarter I'm 
mostly focusing on the bugs and neglecting the e-mails.

All e-mails with substantive feedback (such as yours) sent to this list 
will eventually get a response.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From robert at ocallahan.org  Fri Feb 15 11:37:27 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Sat, 16 Feb 2013 08:37:27 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
Message-ID: <CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>

On Sat, Feb 16, 2013 at 4:35 AM, Stephen White <senorblanco at chromium.org>wrote:

> Even with these constraints, I don't think we can guarantee that it's safe
> to use LCD AA text. Once you've drawn with LCD AA text, even if it's safe
> at the time of drawing, there's no guarantee that it will be safe later.
>  For instance, if you then drawImage() that canvas rotated into another
> canvas, or even just full-page-zoom it, you'll see colour fringing. Or
> apply CSS 2D or 3D transforms. There are also existing apps which use
> canvas for 2D text glyphs, and then transform and place them rotated in
> WebGL. Those will show colour fringing.


This came up on the list earlier.

Even within canvas, there may be a way to break it if the LCD AA text is
> drawn first and a dest-alpha compositing mode is used overtop (I haven't
> verified this though).


I don't think that's a problem. All destination alpha values will be 1 even
after the subpixel AA test is painted, and you'll treat it as normal.

So I'm starting to think that LCD AA text really has to be opt-in, to avoid
> breaking existing content. By opting it, you're agreeing that these
> artifacts are acceptable for your app. For example, you know that even if
> you're going to do a canvas-to-canvas draw, you're always going to draw at
> 1:1 scale and no rotation.
>

It's difficult to know that on a mobile browser or any other browser where
you have some kind of fast zoom UI.

The suggestion on the list earlier was to keep two versions of the canvas
buffer: one with grayscale AA, another with subpixel AA, and composite with
the subpixel AA buffer when we can do that safely, otherwise use the
grayscale AA version. In many implementations there would be a performance
hit for this, so it would make sense to have authors opt-in to that
performance hit.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From robert at ocallahan.org  Fri Feb 15 12:10:14 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Sat, 16 Feb 2013 09:10:14 +1300
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
Message-ID: <CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>

On Sat, Feb 16, 2013 at 3:46 AM, Glenn Maynard <glenn at zewt.org> wrote:

> a) This isn't the case.  The tricky bit was defining precisely when
> autorevocation happens; this has been resolved (the "global script clean-up
> jobs list").  There's a remaining piece (
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765), but while it'll
> take some thought to do that in a clean way (so it can be applied to
> different APIs concisely), there's nothing magic there.
>

Serves me right for checking the latest published version instead of the
real spec... Sorry.

It may be that "there's nothing magic there", but in comment #17 Ian seems
less than enthusiastic ("this is nuts, IMHO").

Even if you get past that, you still have the problem that revoked URLs are
useless. It's impossible to do something equivalent to video2.src =
video1.src (which works today). Also, getting access to the underlying
source object is a valuable feature, especially for MediaStream and
MediaSource objects which have interesting APIs on them.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From senorblanco at chromium.org  Fri Feb 15 14:09:16 2013
From: senorblanco at chromium.org (Stephen White)
Date: Fri, 15 Feb 2013 17:09:16 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
Message-ID: <CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>

On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Sat, Feb 16, 2013 at 4:35 AM, Stephen White <senorblanco at chromium.org>wrote:
>
>> Even with these constraints, I don't think we can guarantee that it's
>> safe to use LCD AA text. Once you've drawn with LCD AA text, even if it's
>> safe at the time of drawing, there's no guarantee that it will be safe
>> later.  For instance, if you then drawImage() that canvas rotated into
>> another canvas, or even just full-page-zoom it, you'll see colour fringing.
>> Or apply CSS 2D or 3D transforms. There are also existing apps which use
>> canvas for 2D text glyphs, and then transform and place them rotated in
>> WebGL. Those will show colour fringing.
>
>
> This came up on the list earlier.
>
> Even within canvas, there may be a way to break it if the LCD AA text is
>> drawn first and a dest-alpha compositing mode is used overtop (I haven't
>> verified this though).
>
>
> I don't think that's a problem. All destination alpha values will be 1
> even after the subpixel AA test is painted, and you'll treat it as normal.
>

I was thinking something like this:

- draw subpixel AA text over an opaque background
- draw a partially-transparent rect with destination-atop mode over the
subpixel AA text

Now some of the subpixel AA text is still there, but the destination alpha
is non-1, so things will go bad when you composite into the page.  (At
least I think it will.. Porter-Duff makes my head spin sometimes.)


>  So I'm starting to think that LCD AA text really has to be opt-in, to
>> avoid breaking existing content. By opting it, you're agreeing that these
>> artifacts are acceptable for your app. For example, you know that even if
>> you're going to do a canvas-to-canvas draw, you're always going to draw at
>> 1:1 scale and no rotation.
>>
>
> It's difficult to know that on a mobile browser or any other browser where
> you have some kind of fast zoom UI.
>
> The suggestion on the list earlier was to keep two versions of the canvas
> buffer: one with grayscale AA, another with subpixel AA, and composite with
> the subpixel AA buffer when we can do that safely, otherwise use the
> grayscale AA version. In many implementations there would be a performance
> hit for this, so it would make sense to have authors opt-in to that
> performance hit.
>

It would also be a needless performance hit if the developer knew that they
always wanted subpixel AA, and that their app would never fringe.


> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>

So let me take a stab at a brief summary of the proposals so far, and the
pros and cons of each (correct me if I missed anything):

moz-opaque
pro:  fairly easy to implement
pro:  no performance hit over regular rendering
pro:  many opportunities for optimization
pro:  catches all in-canvas cases of color fringing
con:  does not handle any out-of-canvas color fringing
con:  opt-in

automatic opacity detection
pro:  catches most (all?) cases of in-canvas color fringing
pro:  some opportunties for optimization (must be conservative in some
cases)
con:  does not catch color fringing on CSS transforms, canvas -> WebGL, etc

context attribute (something like:  context.textAntialising = { 'none',
'grayscale', 'subpixel' })
pro:  very easy to implement
pro:  no performance hit
con:  does not catch any cases of color fringing; completely up to web
developer
con:  opt-in

deferred canvas rendering (collect commands into a buffer, flush buffer
only when compositing canvas to page, and decide on subpixel AA at that
point)
pro:  catches all cases of color fringing
con:  in some cases, requires an infinite buffer (e.g., a canvas that never
clears, and only accumulates drawing frame-to-frame means you must
accumulate commands indefinitely)
con:  difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
con:  may introduce performance hit due to re-rendering with and without
subpixel AA (in cases where you would rather have just gone without)

two buffers (one grayscale, one LCD AA)
pro:  handles all cases of color fringing
pro:  moderately easy to implement
con:  RAM (or VRAM) usage is doubled
con:  possibly-unnecessary performance hit
con:  must be opt-in

From robert at ocallahan.org  Sat Feb 16 01:09:22 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Sat, 16 Feb 2013 22:09:22 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
Message-ID: <CAOp6jLaF2gxn2D4XGKSj7CqBWt9rje_nNKzzF9aQCzg89AhHPQ@mail.gmail.com>

On Sat, Feb 16, 2013 at 11:09 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Sat, Feb 16, 2013 at 4:35 AM, Stephen White <senorblanco at chromium.org>wrote:
>>
>>> Even within canvas, there may be a way to break it if the LCD AA text is
>>> drawn first and a dest-alpha compositing mode is used overtop (I haven't
>>> verified this though).
>>
>>
>> I don't think that's a problem. All destination alpha values will be 1
>> even after the subpixel AA test is painted, and you'll treat it as normal.
>>
>
> I was thinking something like this:
>
> - draw subpixel AA text over an opaque background
> - draw a partially-transparent rect with destination-atop mode over the
> subpixel AA text
>
>  Now some of the subpixel AA text is still there, but the destination
> alpha is non-1, so things will go bad when you composite into the page.
>  (At least I think it will.. Porter-Duff makes my head spin sometimes.)
>

I don't see the problem. After the first step, you have an RGBA buffer that
represents exactly the result of the rendering. The second step treats it
exactly like any other RGBA buffer. Am I being dense?


> The suggestion on the list earlier was to keep two versions of the canvas
>> buffer: one with grayscale AA, another with subpixel AA, and composite with
>> the subpixel AA buffer when we can do that safely, otherwise use the
>> grayscale AA version. In many implementations there would be a performance
>> hit for this, so it would make sense to have authors opt-in to that
>> performance hit.
>>
>
> It would also be a needless performance hit if the developer knew that
> they always wanted subpixel AA, and that their app would never fringe.
>

I don't think the developer can ever know that. They'd have to assume the
browser/platform does not have a quick-zoom feature, which is an assumption
developers shouldn't be making. Although I guess we could just declare that
that case isn't important enough to matter.

So let me take a stab at a brief summary of the proposals so far, and the
> pros and cons of each (correct me if I missed anything):
>
> moz-opaque
> pro:  fairly easy to implement
> pro:  no performance hit over regular rendering
> pro:  many opportunities for optimization
> pro:  catches all in-canvas cases of color fringing
> con:  does not handle any out-of-canvas color fringing
> con:  opt-in
>

Additional con: requires changes to canvas compositing spec and possibly
implementations.


> automatic opacity detection
> pro:  catches most (all?) cases of in-canvas color fringing
> pro:  some opportunties for optimization (must be conservative in some
> cases)
> con:  does not catch color fringing on CSS transforms, canvas -> WebGL, etc
>
> context attribute (something like:  context.textAntialising = { 'none',
> 'grayscale', 'subpixel' })
> pro:  very easy to implement
> pro:  no performance hit
> con:  does not catch any cases of color fringing; completely up to web
> developer
> con:  opt-in
>

Additional con: requires specification and implementation of what happens
when subpixel AA is drawn over transparent background.

deferred canvas rendering (collect commands into a buffer, flush buffer
> only when compositing canvas to page, and decide on subpixel AA at that
> point)
> pro:  catches all cases of color fringing
> con:  in some cases, requires an infinite buffer (e.g., a canvas that
> never clears, and only accumulates drawing frame-to-frame means you must
> accumulate commands indefinitely)
>

Not really true, you can just give up on the complex cases and draw
grayscale whenever you feel like it.


> con:  difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
> con:  may introduce performance hit due to re-rendering with and without
> subpixel AA (in cases where you would rather have just gone without)
>
> two buffers (one grayscale, one LCD AA)
> pro:  handles all cases of color fringing
> pro:  moderately easy to implement
> con:  RAM (or VRAM) usage is doubled
> con:  possibly-unnecessary performance hit
> con:  must be opt-in
>

Sounds right with the above modifications.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From robert at ocallahan.org  Sat Feb 16 01:12:02 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Sat, 16 Feb 2013 22:12:02 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
Message-ID: <CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>

On Sat, Feb 16, 2013 at 11:09 AM, Stephen White <senorblanco at chromium.org>wrote:

> deferred canvas rendering (collect commands into a buffer, flush buffer
> only when compositing canvas to page, and decide on subpixel AA at that
> point)
> pro:  catches all cases of color fringing
> con:  in some cases, requires an infinite buffer (e.g., a canvas that
> never clears, and only accumulates drawing frame-to-frame means you must
> accumulate commands indefinitely)
> con:  difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
> con:  may introduce performance hit due to re-rendering with and without
> subpixel AA (in cases where you would rather have just gone without)
>
> two buffers (one grayscale, one LCD AA)
> pro:  handles all cases of color fringing
> pro:  moderately easy to implement
> con:  RAM (or VRAM) usage is doubled
> con:  possibly-unnecessary performance hit
> con:  must be opt-in
>

Both of these schemes can actually be optimized some more: As long as no
text is drawn to a canvas, you can freely rasterize (in the first case) or
use just one buffer (in the second case). In fact, this is true as long as
no text is drawn to a canvas over non-opaque pixels. So a lot of canvas
usage could be handled with little or no performance hit.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From glenn at zewt.org  Sat Feb 16 11:43:08 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Sat, 16 Feb 2013 13:43:08 -0600
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
	<CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>
Message-ID: <CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>

On Fri, Feb 15, 2013 at 2:10 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Sat, Feb 16, 2013 at 3:46 AM, Glenn Maynard <glenn at zewt.org> wrote:
>
>> a) This isn't the case.  The tricky bit was defining precisely when
>> autorevocation happens; this has been resolved (the "global script clean-up
>> jobs list").  There's a remaining piece (
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765), but while it'll
>> take some thought to do that in a clean way (so it can be applied to
>> different APIs concisely), there's nothing magic there.
>>
>
> Serves me right for checking the latest published version instead of the
> real spec... Sorry.
>
> It may be that "there's nothing magic there", but in comment #17 Ian seems
> less than enthusiastic ("this is nuts, IMHO").
>

He didn't explain why it's nuts. (Putting aside the apparent
misunderstandings in comment #14, eg. "prose everywhere that might
eventually use part of a string as a URL", since I replied to that and he
didn't respond to my reply.)

Since we have a real URL parser now, I think we have a reasonable way to do
this: capture the blob in the parser, returning it as part of the parsed
URL.  Then, it becomes straightforward: if an APIs parses URLs
synchronously these URLs will work, and if they parse asynchronously then
they won't.

The XHR spec would just work, since it already parses URLs synchronously
from open().  HTMLImageElement.src and srcset would need to parse the URL
synchronously, rather than waiting for the "update the image data" to
happen.

If there are APIs that can't guarantee if they'll parse synchronously or
asynchronously, then it should tell the parser to never capture blobs, to
guarantee that they never work rather than being nondeterministic.

Even if you get past that, you still have the problem that revoked URLs are
> useless. It's impossible to do something equivalent to video2.src =
> video1.src (which works today).
>

True, though cloneNode() should definitely work.  On the other hand,
.innerHTML works with blob URLs if the URL is still in scope, but would
never work here (not something I use often, but I guess some people still
do).

 Also, getting access to the underlying source object is a valuable
> feature, especially for MediaStream and MediaSource objects which have
> interesting APIs on them.
>

I don't know anything about those, but you can always stash a reference to
an object on the img, even if img doesn't care about it.  "img.src =
URL.createBlobURL(blob); img.xActualBlob = blob;"  It's not as nice as
having them tied together, but it's not terrible.

-- 
Glenn Maynard

From nils at dieweltistgarnichtso.net  Sun Feb 17 05:04:15 2013
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 17 Feb 2013 14:04:15 +0100
Subject: [whatwg] IRC and WWW integration proposal
In-Reply-To: <20130201154150.14251e2a80fe4f69051f4ad8@gmail.com>
References: <20130201142600.dea98ee7b58e2637550be2c4@gmail.com>
	<20130201052458.269aac46@desudesudesu>
	<20130201150126.16a706397a491368142a8815@gmail.com>
	<20130201055511.332ca0b8@desudesudesu>
	<20130201154150.14251e2a80fe4f69051f4ad8@gmail.com>
Message-ID: <20130217140415.22fd996b@desudesudesu>

Gryllida <gryllida at gmail.com> schrieb am Fri, 1 Feb 2013 15:41:50 +1030:

> [?]
>
> It is rather common to have a channel for a website, not just one
> page. There are some exceptions of sites which have subsites with a
> channel for each. A {IRC, XMPP} channel is "an official chat medium
> aiming to serve as an official {support, development, contact}
> means". For example, https://developer.mozilla.org/en/Themes
> irc://irc.mozilla.org/themedev - discussion of theme development for
> Mozilla platform http://www.ubuntu.com/* irc://irc.ubuntu.com/ -
> official support channel for the distro the w3c network for
> individual sections of website - channels for development
> collaboration and meetings &c

Those relations are not the same. The Mozilla example shows a
*discussion about* the collection described by by the referring
document, the Ubuntu example shows *support for* the software available
at the referring page. The W3C example is probably similar to the
Mozilla example, only that it would refer to discussions about
documents.

> I think a protocol attribute might be redundant as it is a part of
> the URL.

Indeed.

> It may be worth noting that every part of the note I originally sent
> is possible to look up and you can try finding proper way to phrase
> things (I have no experience in writing documentation of this sort).

I do not understand.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

From nils at dieweltistgarnichtso.net  Sun Feb 17 05:19:32 2013
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 17 Feb 2013 14:19:32 +0100
Subject: [whatwg] use of article to markup comments
In-Reply-To: <op.wris4smuh8on37@bruce-pc>
References: <CA+ri+V=SnGtwaFT=D9MnZoFkFFb_iX0nXnOGyOH298uDAYCMhQ@mail.gmail.com>
	<op.wris4smuh8on37@bruce-pc>
Message-ID: <20130217141932.7ca5ed8a@desudesudesu>

"Bruce Lawson" <brucel at opera.com> schrieb am Sat, 26 Jan 2013 13:30:18
-0000:

> In short, why should the spec suggest any specific method of marking
> up comments?

As someone who is interested in semantics and tired of scraping
content and applying scrappy heuristics: If it is clear that an
<article> within an <article> represents a comments one can easily:
  * programmatically find article comments in HTML
  * write interoperable stylesheets for comments, using the selector
    ?article > article?
  * use HTML fragments in a document store for content management (I
    wrote a blog software with a git backend yesterday and plan to add
    this feature)

Without having one interoperable way all that becomes a lot harder.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

From nils at dieweltistgarnichtso.net  Sun Feb 17 05:23:48 2013
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 17 Feb 2013 14:23:48 +0100
Subject: [whatwg] use of article to markup comments
In-Reply-To: <5105726A.2000905@custom-anything.com>
References: <CA+ri+V=SnGtwaFT=D9MnZoFkFFb_iX0nXnOGyOH298uDAYCMhQ@mail.gmail.com>
	<op.wris4smuh8on37@bruce-pc> <5105726A.2000905@custom-anything.com>
Message-ID: <20130217142348.300a169a@desudesudesu>

Adrian Testa-Avila <whatwg at custom-anything.com> schrieb am Sun, 27 Jan
2013 10:31:06 -0800:

> So, maybe a better question is why should the spec suggest only one 
> specific method?

Answer: As someone consuming HTML and XML content, I find it extremely
unhelpful if equivalent semantics are expressed in mand different ways.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

From nils at dieweltistgarnichtso.net  Sun Feb 17 05:48:56 2013
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 17 Feb 2013 14:48:56 +0100
Subject: [whatwg] metadata attribute for media
In-Reply-To: <50C7DC9A.1070000@mozilla.com>
References: <505BA783.2030202@mozilla.com> <op.wlac76p9sr6mfa@kirk>
	<50B406DA.70708@mozilla.com> <50B52E51.1000707@mozilla.com>
	<Pine.LNX.4.64.1212120051040.9975@ps20323.dreamhostps.com>
	<50C7DC9A.1070000@mozilla.com>
Message-ID: <20130217144856.72a25d99@desudesudesu>

Ralph Giles <giles at mozilla.com> schrieb am Tue, 11 Dec 2012 17:23:38
-0800:

> On 12-12-11 4:58 PM, Ian Hickson wrote:
> 
> [?]
>
> > I don't think we should have an open-ended API without fixed names, 
> > because that is a recipe for an interoperability disaster.
> 
> I agree it would have interoperability issues. My own implementation
> experience is that the easy thing to do is to mirror whatever
> representation your playback framework offers, which can result in
> per-platform differences as well as per-media-format (and per tagging
> application, etc.).

Just doing ?the easiest thing? when you are a content-emitter (e.g. a
software developer just mirroring what the platform provides)
does make it easier for the sender while making it harder for the
receiver ? it creates ?computational dark energy? that has to be
consumed somehow at the receiving side, as someone has to map all of
these platform-specific conventions onto common semantics.

I rather not have a world in which one needs even more JavaScript blobs
just to provide basic functionality cross-browser.

> That said, I'm not convinced this is an issue given the primary
> use-case, which is pretty much that web content wants to do more
> sophisticated things with the metadata than the user-agent's
> standardized parsing allows. If one cares to that extent, and is
> already handling format differences, dealing with vendor variation on
> top isn't that much more effort.

I disagree, strongly.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

From glenn at zewt.org  Sun Feb 17 09:35:46 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Sun, 17 Feb 2013 11:35:46 -0600
Subject: [whatwg] scoped style sheets and @-rules
In-Reply-To: <20130121143923.GA6959@crum.dbaron.org>
References: <20130121143923.GA6959@crum.dbaron.org>
Message-ID: <CABirCh_+USnDWAqTOXXWQNeKM+qwa2TX04Nym=833Zkqcu4ncg@mail.gmail.com>

On Mon, Jan 21, 2013 at 8:39 AM, L. David Baron <dbaron at dbaron.org> wrote:

> But I think it's a large amount of extra implementation complexity
> to honor @-rules whose purpose is to build global dictionaries (in
> particular, @keyframes and @font-face), and I suspect the end result
> of honoring them would yield technology that's more confusing for
> authors.  Anything that can be done by changing the meaning of an
> @keyframes or @font-face rule within a subtree could also be done by
> declaring a different animation rule or font-family within that
> subtree.  I suspect the extra clarity from the latter makes it a
> better authoring practice anyway, so I don't think implementations
> should be required to add support for a feature that it's better to
> not use.
>

You could make the same argument against most of @scoped: you don't need to
define a scoped style for a class, just use a different class name.

It seems more likely that you'd want to use this for font-faces or
keyframes so that you can be sure the name won't collide.  For example, a
templating system might output

<div>
    <style scoped>
    @font-face { font-family: "font"; src: url("font.ttf"); }
    </style>
    <span style="font-family: font;">content</span>
</div>

where the font URL is dynamically generated and the span is entered by the
user, who's been told that the font-family "font" will be defined to
something.  The template doesn't need to worry about colliding with a
font-family by that name elsewhere (including other instances of the same
template or elsewhere in the document).

I don't know about implementation complexity (though I don't know why
creating a stack of font-face dictionaries would be any more complex than
creating a stack of style rules), but I don't think this is any more
complex for authors than the rest of @scoped.

-- 
Glenn Maynard

From jonathan at garbee.me  Sun Feb 17 13:10:21 2013
From: jonathan at garbee.me (Jonathan Garbee)
Date: Sun, 17 Feb 2013 16:10:21 -0500
Subject: [whatwg] IRC and WWW integration proposal
In-Reply-To: <20130201142600.dea98ee7b58e2637550be2c4@gmail.com>
References: <20130201142600.dea98ee7b58e2637550be2c4@gmail.com>
Message-ID: <CANQy2y2jTxgQtsEdTuwBLWpd5deACFV2=nJp81m3RVvxV+BypA@mail.gmail.com>

Usecase 1: This can already be covered by having the bot/engine look for an
irc protocol link on the page.

Usecase 2 part one: Operating systems already do this. They see an irc://
protocol and ask what to open it with or use their already assigned option.
No need for a browser to take this over.

Usecase 2 part two: Most browsers offer extension platforms, someone can
easily create one to look for irc:// links and display something based on
that.

I personally am not seeing any major benefit by having the proposed
additions added into spec(s). Just more work for developers both on
browsers and websites if they chose to support this.

-Garbee



>   Usecase 1: I search for python and see a link to their website in search
> results, and the search engine looks up both title and IRC info - so I see
> webpage title, and a link to its irc network or channel.
>   Usecase 2: Browsers implement some interface to display IRC channel link
> or window when user visits a page. Advantages:
>   - The websites will benefit from this and will not have to manually
> embed qwebirc or Mibbit instances into their webpages anymore[1], leaving
> the IRC client preference to the user (choose from locally installed
> clients, or a client provided by the website).
>   - User would not have to skim a page of text to locate and click an
> irc:// link manually, as such links would be a part of browser interface
> (an IRC icon like RSS feed icon?).
>
>

From robert at ocallahan.org  Sun Feb 17 13:17:49 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 18 Feb 2013 10:17:49 +1300
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CA+c2ei_TGhJmmOgQvUB1nr6Py_+1j4Oe0DKMR7anDQyrAXwV0w@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CADnb78hnVHE-fV=LTw0WCjbNgWbbo1+qZ9BsMeNM-xqg4f+cjw@mail.gmail.com>
	<CAOp6jLYEKjS3Cg8pPfrzSSPbKCgD0uRO9uu0M-6PLZ7FObqVsQ@mail.gmail.com>
	<CA+c2ei-bq6qbV4HMcYWWN0iWTP68XFbUQpZD39zWuU2qo4y6ow@mail.gmail.com>
	<CAOp6jLa+ZJC=2GxNdxkhX0VOPmNGdg921-do=kLHYqFAHJFqnA@mail.gmail.com>
	<CA+c2ei_TGhJmmOgQvUB1nr6Py_+1j4Oe0DKMR7anDQyrAXwV0w@mail.gmail.com>
Message-ID: <CAOp6jLbXdnwyrnD9-9kdHu3=xwnj6RZ1ZOhUtCEea4eDkHHDVg@mail.gmail.com>

On Sat, Feb 16, 2013 at 1:37 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Fri, Feb 15, 2013 at 2:43 AM, Robert O'Callahan <robert at ocallahan.org>
> wrote:
> > On Fri, Feb 15, 2013 at 10:50 PM, Jonas Sicking <jonas at sicking.cc>
> wrote:
> >>
> >> Also, for what it's worth, I'm holding out hope that we can change
> >> createObjectURL to be autorevoking by default. That's what the latest
> >> drafts are saying and no implementation has objected, despite repeated
> >> pokings.
> >
> > Has any implementation actually taken the plunge?
>
> It's a fairly recent change to the spec, so no. I think we should give
> it a try in Firefox.
>

Ugh, can't we take turns with other browsers or draw straws or something?
Or study existing code using createObjectURL to get some data first?

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From robert at ocallahan.org  Sun Feb 17 13:25:51 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 18 Feb 2013 10:25:51 +1300
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
	<CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>
	<CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>
Message-ID: <CAOp6jLZhBfchM1zzrfYWvifoYicVQ1kOYdE4EEA+zW_jrQ-Jzg@mail.gmail.com>

On Sun, Feb 17, 2013 at 8:43 AM, Glenn Maynard <glenn at zewt.org> wrote:

> On Fri, Feb 15, 2013 at 2:10 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
> Even if you get past that, you still have the problem that revoked URLs
>> are useless. It's impossible to do something equivalent to video2.src =
>> video1.src (which works today).
>>
>
> True, though cloneNode() should definitely work.  On the other hand,
> .innerHTML works with blob URLs if the URL is still in scope, but would
> never work here (not something I use often, but I guess some people still
> do).
>

cloneNode() won't work for autorevoked URLs, because it is defined to only
clone attributes and children, not internal state (with a few exceptions
for Web compatibility). (Don't tell me that it shouldn't work that way; I
argued that long ago and lost :-).) innerHTML-based cloning would work in
the same cases cloneNode() would: i.e. not at all for autorevoked URLs or
srcObject.


>  Also, getting access to the underlying source object is a valuable
>> feature, especially for MediaStream and MediaSource objects which have
>> interesting APIs on them.
>>
>
> I don't know anything about those, but you can always stash a reference to
> an object on the img, even if img doesn't care about it.  "img.src =
> URL.createBlobURL(blob); img.xActualBlob = blob;"  It's not as nice as
> having them tied together, but it's not terrible.
>

Yes, you can work around not having an API for this, if you control both
the setting and the getting. It's still a workaround.

I think the stakes are not that high here. Lack of srcObject can be worked
around in most cases. On the other hand adding srcObject is not a big
burden --- I don't think it needs to be added to every resource-loading
element. It's useful for media elements, maybe <img>, and dubiously
<iframe> (all of which already have multiple ways to specify the resource
to load).

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From jonathan at garbee.me  Sun Feb 17 14:56:29 2013
From: jonathan at garbee.me (Jonathan Garbee)
Date: Sun, 17 Feb 2013 17:56:29 -0500
Subject: [whatwg] IRC and WWW integration proposal
In-Reply-To: <CANQy2y2jTxgQtsEdTuwBLWpd5deACFV2=nJp81m3RVvxV+BypA@mail.gmail.com>
References: <20130201142600.dea98ee7b58e2637550be2c4@gmail.com>
	<CANQy2y2jTxgQtsEdTuwBLWpd5deACFV2=nJp81m3RVvxV+BypA@mail.gmail.com>
Message-ID: <CANQy2y0cK4DWv43qhk_=Br6=HuBHy8MpUJQzN1XU=sNLeueJsw@mail.gmail.com>

I'll actually follow up my last post with this.

Is there any scenario where something can be done with these changes, or
any one of them, that today isn't possible with the current specifications?
I simply don't see one myself. If you could give a scenario, then could you
possibly make an example page and write a polyfill that would show the
use-case? It may help us better understand any other use-case that is
currently not possible and show us what functionality to look at in order
to create something for the (a?) spec that would work.


On Sun, Feb 17, 2013 at 4:10 PM, Jonathan Garbee <jonathan at garbee.me> wrote:

> Usecase 1: This can already be covered by having the bot/engine look for
> an irc protocol link on the page.
>
> Usecase 2 part one: Operating systems already do this. They see an irc://
> protocol and ask what to open it with or use their already assigned option.
> No need for a browser to take this over.
>
> Usecase 2 part two: Most browsers offer extension platforms, someone can
> easily create one to look for irc:// links and display something based on
> that.
>
> I personally am not seeing any major benefit by having the proposed
> additions added into spec(s). Just more work for developers both on
> browsers and websites if they chose to support this.
>
> -Garbee
>
>
>
>>   Usecase 1: I search for python and see a link to their website in
>> search results, and the search engine looks up both title and IRC info - so
>> I see webpage title, and a link to its irc network or channel.
>>   Usecase 2: Browsers implement some interface to display IRC channel
>> link or window when user visits a page. Advantages:
>>   - The websites will benefit from this and will not have to manually
>> embed qwebirc or Mibbit instances into their webpages anymore[1], leaving
>> the IRC client preference to the user (choose from locally installed
>> clients, or a client provided by the website).
>>   - User would not have to skim a page of text to locate and click an
>> irc:// link manually, as such links would be a part of browser interface
>> (an IRC icon like RSS feed icon?).
>>
>>
>

From silviapfeiffer1 at gmail.com  Sun Feb 17 15:39:58 2013
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Mon, 18 Feb 2013 10:39:58 +1100
Subject: [whatwg] use of article to markup comments
In-Reply-To: <20130217141932.7ca5ed8a@desudesudesu>
References: <CA+ri+V=SnGtwaFT=D9MnZoFkFFb_iX0nXnOGyOH298uDAYCMhQ@mail.gmail.com>
	<op.wris4smuh8on37@bruce-pc> <20130217141932.7ca5ed8a@desudesudesu>
Message-ID: <CAHp8n2=qaVdfYgy_KH3yiq9ze8h7LBEJ7e9CRqevHeG5i-unEw@mail.gmail.com>

On Mon, Feb 18, 2013 at 12:19 AM, Nils Dagsson Moskopp <
nils at dieweltistgarnichtso.net> wrote:

> "Bruce Lawson" <brucel at opera.com> schrieb am Sat, 26 Jan 2013 13:30:18
> -0000:
>
> > In short, why should the spec suggest any specific method of marking
> > up comments?
>
> As someone who is interested in semantics and tired of scraping
> content and applying scrappy heuristics: If it is clear that an
> <article> within an <article> represents a comments one can easily:
>


<article> in <article> could be a comment. Or it could be something else
entirely. Your heuristic may work in many cases, but certainly not in all.
If we really wanted to be sure where to find the semantic concept of a
comment, we should introduce a meaningful element for it such as <comment>.

Silvia.

From nils at dieweltistgarnichtso.net  Sun Feb 17 22:36:33 2013
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Mon, 18 Feb 2013 07:36:33 +0100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <gemini.mf0z4700mwz2o09e7.stewart.brodie@antplc.com>
References: <CA+ri+V=W6P2EPvzKQB7NQD7YXgjL5RQgKfbWJoGuit7q8L6m8w@mail.gmail.com>
	<CA+ri+V=TrN88Cn-fS4KrbV4j2+1_3_vo-+-7s86dgxi9TF6izw@mail.gmail.com>
	<gemini.mf0z4700mwz2o09e7.stewart.brodie@antplc.com>
Message-ID: <20130218073633.71166b46@desudesudesu>

Stewart Brodie <stewart.brodie at antplc.com> schrieb am Fri, 14 Dec 2012
14:33:43 +0000:

> Steve Faulkner <faulkner.steve at gmail.com> wrote:
> 
> > Stewart wrote:
> > 
> > It doesn't necessarily.  I've come across pages that expect the
> > head to be displayed too.  e.g. tests at
> > http://meyerweb.com/eric/css/tests/css3/like
> > http://meyerweb.com/eric/css/tests/css3/show.php?p=caption-side
> 
> > Is this a common mark up pattern?
> 
> I've not gone looking for any other real-world examples - that's the
> only one I've seen.  However, I can't think of any reason why it
> shouldn't work, as it's just a block box like the body element
> (usually) is.

I have some rules in my user stylesheet for this ? among these one that
displays the hyperlink with a small orange feed icon for elements
matching ?link[rel=alternate][title][type='application/rss+xml']?. I use
conkeror (a web browser modeled after Emacs ? scripting buffers ful of
HTML using JavaScript), the configuration can be found here:
<https://raw.github.com/erlehmann/dotfiles/27cf8d18faad4d8deeb47ebaadcf91ce26357aa6/.conkerorrc>

When I tried to actually use this for a web page I found that while
Gecko (from conkeror) generates Hyperlinks for <link> elements, WebKit
(at least that from Chromium Version 22.0.1229.94) does not. Therefore,
I decided against using this styling pattern for my blog sofware.

I suggest people test for themselves, as I suspect I may have done
something wrong with my user stylesheets in Chromium ? it seems
counter-intuitive that a <link> Element does not create a hyperlink:
<data:text/html;charset=utf-8;base64,PCFET0NUWVBFIEhUTUw%2BPHRpdGxlPkxpbmsgRWxlbWVudCBTdHlsaW5nIFRlc3Q8L3RpdGxlPjxzdHlsZT5oZWFkLGxpbmt7ZGlzcGxheTpibG9ja31saW5rW3RpdGxlXVt0eXBlPSdhcHBsaWNhdGlvbi9yc3MreG1sJ106OmJlZm9yZXtjb250ZW50OidMaW5rOiAnIGF0dHIodGl0bGUpfTwvc3R5bGU%2BPGxpbmsgcmVsPSJhbHRlcm5hdGUiIHRpdGxlPSJGZWVkIiB0eXBlPSJhcHBsaWNhdGlvbi9yc3MreG1sIiBocmVmPSJodHRwOi8vZXhhbXBsZS5vcmcvZmVlZCI%2BYm9keQ0K>

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

From annevk at annevk.nl  Mon Feb 18 01:37:33 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Mon, 18 Feb 2013 09:37:33 +0000
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
	<CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>
	<CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>
Message-ID: <CADnb78j1HQ_fE7Q63sV_1Rg4cuMNXTxgbw_-QPLhWzXS==1TJw@mail.gmail.com>

On Sat, Feb 16, 2013 at 7:43 PM, Glenn Maynard <glenn at zewt.org> wrote:
> Since we have a real URL parser now, I think we have a reasonable way to do
> this: capture the blob in the parser, returning it as part of the parsed
> URL.

Although this might theoretically work, I suspect it'll take a while
before browsers get URL parsers that match the architecture of the
specification. (They all have somewhat different architectures at the
moment and trying to extend them in any meaningful manner at this
point seems like asking for trouble.)


-- 
http://annevankesteren.nl/

From annevk at annevk.nl  Mon Feb 18 01:39:42 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Mon, 18 Feb 2013 09:39:42 +0000
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CAOp6jLZhBfchM1zzrfYWvifoYicVQ1kOYdE4EEA+zW_jrQ-Jzg@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
	<CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>
	<CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>
	<CAOp6jLZhBfchM1zzrfYWvifoYicVQ1kOYdE4EEA+zW_jrQ-Jzg@mail.gmail.com>
Message-ID: <CADnb78hZC742zfNK5=sW8XnVRUTSvxcS6PDzBqxWoYXVcCNxMQ@mail.gmail.com>

On Sun, Feb 17, 2013 at 9:25 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> cloneNode() won't work for autorevoked URLs, because it is defined to only
> clone attributes and children, not internal state (with a few exceptions
> for Web compatibility). (Don't tell me that it shouldn't work that way; I
> argued that long ago and lost :-).)

We explicitly allow for it today.
http://dom.spec.whatwg.org/#concept-node-clone-ext

That was added of course for the compatibility reasons you mention
(mostly form controls) but I don't see why at this point in time we
should still avoid using it for other means.


-- 
http://annevankesteren.nl/

From robert at ocallahan.org  Mon Feb 18 01:59:43 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 18 Feb 2013 22:59:43 +1300
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CADnb78hZC742zfNK5=sW8XnVRUTSvxcS6PDzBqxWoYXVcCNxMQ@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
	<CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>
	<CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>
	<CAOp6jLZhBfchM1zzrfYWvifoYicVQ1kOYdE4EEA+zW_jrQ-Jzg@mail.gmail.com>
	<CADnb78hZC742zfNK5=sW8XnVRUTSvxcS6PDzBqxWoYXVcCNxMQ@mail.gmail.com>
Message-ID: <CAOp6jLYmSYQE-2HQ841Rh-0udhwFXhRPLH_nFuje4U2KwHOqUw@mail.gmail.com>

On Mon, Feb 18, 2013 at 10:39 PM, Anne van Kesteren <annevk at annevk.nl>wrote:

> On Sun, Feb 17, 2013 at 9:25 PM, Robert O'Callahan <robert at ocallahan.org>
> wrote:
> > cloneNode() won't work for autorevoked URLs, because it is defined to
> only
> > clone attributes and children, not internal state (with a few exceptions
> > for Web compatibility). (Don't tell me that it shouldn't work that way; I
> > argued that long ago and lost :-).)
>
> We explicitly allow for it today.
> http://dom.spec.whatwg.org/#concept-node-clone-ext
>
> That was added of course for the compatibility reasons you mention
> (mostly form controls) but I don't see why at this point in time we
> should still avoid using it for other means.
>

IIRC Ian argued against it last time. If he's changed his mind, I'd like to
hear him say so :-).

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From glenn at zewt.org  Mon Feb 18 09:46:13 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Mon, 18 Feb 2013 11:46:13 -0600
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CAOp6jLZhBfchM1zzrfYWvifoYicVQ1kOYdE4EEA+zW_jrQ-Jzg@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
	<CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>
	<CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>
	<CAOp6jLZhBfchM1zzrfYWvifoYicVQ1kOYdE4EEA+zW_jrQ-Jzg@mail.gmail.com>
Message-ID: <CABirCh8W0KriqfH5-dD+ynUviVM3-ddv8hwrBMD4mOZvp0FawA@mail.gmail.com>

On Sun, Feb 17, 2013 at 3:17 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

>  Ugh, can't we take turns with other browsers or draw straws or something?
> Or study existing code using createObjectURL to get some data first?
>

I don't know if you have any way of testing this in bulk, but once you have
the auto-revoke infrastructure in place, it's probably straightforward to
instrument non-auto-revoking blob URLs to see where they're actually used
after their initial top-level script stack has returned (eg. where this
change would be breaking).

cloneNode() won't work for autorevoked URLs, because it is defined to only
> clone attributes and children, not internal state (with a few exceptions
> for Web compatibility). (Don't tell me that it shouldn't work that way; I
> argued that long ago and lost :-).)


It may be worth raising the argument again, since we have additional
information now (this feature), though it's not high up on my list.


On Mon, Feb 18, 2013 at 3:37 AM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Sat, Feb 16, 2013 at 7:43 PM, Glenn Maynard <glenn at zewt.org> wrote:
> > Since we have a real URL parser now, I think we have a reasonable way to
> do
> > this: capture the blob in the parser, returning it as part of the parsed
> > URL.
>
> Although this might theoretically work, I suspect it'll take a while
> before browsers get URL parsers that match the architecture of the
> specification. (They all have somewhat different architectures at the
> moment and trying to extend them in any meaningful manner at this
> point seems like asking for trouble.)
>

That's fine, since the main goal is to have a simple, consistent way of
making it clear in specs exactly when the blob of a blob URL is captured.
Whether that's actually implemented as part of the URL parser or at a
higher level is an implementation detail.

I suspect this will also fix some underdefined behavior with the
non-autorevoking blobs we have today.  For example:

    var url = URL.createObjectURL(blob);
    img.src = url;
    URL.revokeObjectURL(url);

I think according to spec this may or may not work, since "update the image
data" might or might not happen synchronously.  This actually does work in
Chrome and Firefox, so I'm guessing it wouldn't actually be web-compatible
to do that.  Capturing the blob when @src (and srcset) is assigned would
fix this, so the blob is captured synchronously even if the browser isn't
going to load the image right away.

-- 
Glenn Maynard

From giles at mozilla.com  Mon Feb 18 09:51:03 2013
From: giles at mozilla.com (Ralph Giles)
Date: Mon, 18 Feb 2013 09:51:03 -0800
Subject: [whatwg] metadata attribute for media
In-Reply-To: <20130217144856.72a25d99@desudesudesu>
References: <505BA783.2030202@mozilla.com> <op.wlac76p9sr6mfa@kirk>
	<50B406DA.70708@mozilla.com> <50B52E51.1000707@mozilla.com>
	<Pine.LNX.4.64.1212120051040.9975@ps20323.dreamhostps.com>
	<50C7DC9A.1070000@mozilla.com>
	<20130217144856.72a25d99@desudesudesu>
Message-ID: <51226A07.2070206@mozilla.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/02/13 05:48 AM, Nils Dagsson Moskopp wrote:

> If one cares to that extent, and is
>> already handling format differences, dealing with vendor
>> variation on top isn't that much more effort.
> 
> I disagree, strongly.

Ok, thanks for the feedback. Do you like my subsequent proposal better?

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-January/038705.html

 -r

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRImnnAAoJEEcAD3uxRB3vHBwH/14a91L4oN6nktTttTRvQQFf
hmtz52nAO7BdInpG68fRACgLVsz2eT+eWakAAMuzh7T57NH9ZNCSWp1Rk/AM3BXD
akx6QXQuk9eOwuRlk+BIVIUaKVFyod9D133BdTjGqF6/cVmn7emmIm9BWB0sxXrE
3CPuALqs+07ExHbyB/UsE5BWqsJRccJHg9QnJwXd4aMtHbIg37KAcfgN4aYVTHQV
B1I95Uh1Ron2LUCNI9P+Pm8WPQGDcj0cuwFcueRMYy2O26a1xHisOew/l3Cz46Ex
Oq6gAX3Lz/y5LxFhnnlPIeBDhBE9bB0r4jqOtY3FNA+dcUruKI769nIw5WtTmd4=
=zJ6M
-----END PGP SIGNATURE-----

From senorblanco at chromium.org  Mon Feb 18 15:01:15 2013
From: senorblanco at chromium.org (Stephen White)
Date: Mon, 18 Feb 2013 18:01:15 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLaF2gxn2D4XGKSj7CqBWt9rje_nNKzzF9aQCzg89AhHPQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLaF2gxn2D4XGKSj7CqBWt9rje_nNKzzF9aQCzg89AhHPQ@mail.gmail.com>
Message-ID: <CAPeKFTjS3nGhCO+PTV_sSuPYYux-aP1bXiKiVmW10gFgUF_XoA@mail.gmail.com>

On Sat, Feb 16, 2013 at 4:09 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Sat, Feb 16, 2013 at 11:09 AM, Stephen White <senorblanco at chromium.org>wrote:
>
>> On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>
>>> On Sat, Feb 16, 2013 at 4:35 AM, Stephen White <senorblanco at chromium.org
>>> > wrote:
>>>
>>>> Even within canvas, there may be a way to break it if the LCD AA text
>>>> is drawn first and a dest-alpha compositing mode is used overtop (I haven't
>>>> verified this though).
>>>
>>>
>>> I don't think that's a problem. All destination alpha values will be 1
>>> even after the subpixel AA test is painted, and you'll treat it as normal.
>>>
>>
>>  I was thinking something like this:
>>
>> - draw subpixel AA text over an opaque background
>> - draw a partially-transparent rect with destination-atop mode over the
>> subpixel AA text
>>
>>  Now some of the subpixel AA text is still there, but the destination
>> alpha is non-1, so things will go bad when you composite into the page.
>>  (At least I think it will.. Porter-Duff makes my head spin sometimes.)
>>
>
> I don't see the problem. After the first step, you have an RGBA buffer
> that represents exactly the result of the rendering. The second step treats
> it exactly like any other RGBA buffer. Am I being dense?
>

No, it's probably me.  I was thinking that since there was a way to
introduce non-1 alpha into the backing store after-the-fact, it would break
the previously-performed subpixel coverage blending.  But perhaps not.


>
>> The suggestion on the list earlier was to keep two versions of the canvas
>>> buffer: one with grayscale AA, another with subpixel AA, and composite with
>>> the subpixel AA buffer when we can do that safely, otherwise use the
>>> grayscale AA version. In many implementations there would be a performance
>>> hit for this, so it would make sense to have authors opt-in to that
>>> performance hit.
>>>
>>
>> It would also be a needless performance hit if the developer knew that
>> they always wanted subpixel AA, and that their app would never fringe.
>>
>
> I don't think the developer can ever know that. They'd have to assume the
> browser/platform does not have a quick-zoom feature, which is an assumption
> developers shouldn't be making. Although I guess we could just declare that
> that case isn't important enough to matter.
>

Well, pretty much all devices that have pinch-zoom today are high-DPI, and
don't implement subpixel AA.  :)   But no, I don't think that's not a good
assumption to bake into the web platform.


> So let me take a stab at a brief summary of the proposals so far, and the
>> pros and cons of each (correct me if I missed anything):
>>
>> moz-opaque
>> pro:  fairly easy to implement
>> pro:  no performance hit over regular rendering
>> pro:  many opportunities for optimization
>> pro:  catches all in-canvas cases of color fringing
>> con:  does not handle any out-of-canvas color fringing
>> con:  opt-in
>>
>
> Additional con: requires changes to canvas compositing spec and possibly
> implementations.
>

Yes, since it's new behaviour it'll require spec changes.  I guess we can
consider that as part of "con" of being opt-in.

automatic opacity detection
>> pro:  catches most (all?) cases of in-canvas color fringing
>> pro:  some opportunties for optimization (must be conservative in some
>> cases)
>>
> con:  does not catch color fringing on CSS transforms, canvas -> WebGL, etc
>>
>> context attribute (something like:  context.textAntialising = { 'none',
>> 'grayscale', 'subpixel' })
>> pro:  very easy to implement
>> pro:  no performance hit
>> con:  does not catch any cases of color fringing; completely up to web
>> developer
>> con:  opt-in
>>
>
> Additional con: requires specification and implementation of what happens
> when subpixel AA is drawn over transparent background.
>

> deferred canvas rendering (collect commands into a buffer, flush buffer
>> only when compositing canvas to page, and decide on subpixel AA at that
>> point)
>> pro:  catches all cases of color fringing
>> con:  in some cases, requires an infinite buffer (e.g., a canvas that
>> never clears, and only accumulates drawing frame-to-frame means you must
>> accumulate commands indefinitely)
>>
>
> Not really true, you can just give up on the complex cases and draw
> grayscale whenever you feel like it.
>

And leave the behaviour unspecified, I'm guessing?  Doesn't that least to
inconsistent behaviour between browsers?  Even within one implementation,
if you had content whose command stream varied over the maximum buffer
length threshold, it'd toggle between subpixel and grayscale AA. Not sure
if this is a case worth worrying about, but it does feel like it's exposing
more of the implementation that one would like.

Stephen

>
>
>> con:  difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
>> con:  may introduce performance hit due to re-rendering with and without
>> subpixel AA (in cases where you would rather have just gone without)
>>
>> two buffers (one grayscale, one LCD AA)
>> pro:  handles all cases of color fringing
>> pro:  moderately easy to implement
>> con:  RAM (or VRAM) usage is doubled
>> con:  possibly-unnecessary performance hit
>> con:  must be opt-in
>>
>
> Sounds right with the above modifications.


>
> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>

From robert at ocallahan.org  Mon Feb 18 15:29:13 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 19 Feb 2013 12:29:13 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTjS3nGhCO+PTV_sSuPYYux-aP1bXiKiVmW10gFgUF_XoA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLaF2gxn2D4XGKSj7CqBWt9rje_nNKzzF9aQCzg89AhHPQ@mail.gmail.com>
	<CAPeKFTjS3nGhCO+PTV_sSuPYYux-aP1bXiKiVmW10gFgUF_XoA@mail.gmail.com>
Message-ID: <CAOp6jLY5Vhss+DF6PaWEGrv9FD6nk6YdP1S+vm7dyudEG63rWw@mail.gmail.com>

On Tue, Feb 19, 2013 at 12:01 PM, Stephen White <senorblanco at chromium.org>wrote:

> On Sat, Feb 16, 2013 at 4:09 AM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> Not really true, you can just give up on the complex cases and draw
>> grayscale whenever you feel like it.
>>
>
> And leave the behaviour unspecified, I'm guessing?  Doesn't that least to
> inconsistent behaviour between browsers?  Even within one implementation,
> if you had content whose command stream varied over the maximum buffer
> length threshold, it'd toggle between subpixel and grayscale AA. Not sure
> if this is a case worth worrying about, but it does feel like it's exposing
> more of the implementation that one would like.
>

You could avoid toggling by disabling subpixel AA permanently if you're
forced over the buffer threshold.

I don't think we should try to specify exactly when subpixel AA happens.
There's huge variation across platforms and UAs already and it very rarely
matters for interop; when subpixel AA fails the site still works. I think
we should treat this as a quality-of-implementation issue, possibly
assisted by author hints.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From cabanier at gmail.com  Mon Feb 18 18:52:36 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Mon, 18 Feb 2013 19:52:36 -0700
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTjS3nGhCO+PTV_sSuPYYux-aP1bXiKiVmW10gFgUF_XoA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLaF2gxn2D4XGKSj7CqBWt9rje_nNKzzF9aQCzg89AhHPQ@mail.gmail.com>
	<CAPeKFTjS3nGhCO+PTV_sSuPYYux-aP1bXiKiVmW10gFgUF_XoA@mail.gmail.com>
Message-ID: <CAGN7qDAAksMxCjcUhqA-Sj37ORuZeHDm2W3_zKX-k5u8cfrvoA@mail.gmail.com>

On Mon, Feb 18, 2013 at 4:01 PM, Stephen White <senorblanco at chromium.org>wrote:

> On Sat, Feb 16, 2013 at 4:09 AM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Sat, Feb 16, 2013 at 11:09 AM, Stephen White <senorblanco at chromium.org
>> > wrote:
>>
>>> On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan <robert at ocallahan.org
>>> > wrote:
>>>
>>>> On Sat, Feb 16, 2013 at 4:35 AM, Stephen White <
>>>> senorblanco at chromium.org> wrote:
>>>>
>>>>> Even within canvas, there may be a way to break it if the LCD AA text
>>>>> is drawn first and a dest-alpha compositing mode is used overtop (I haven't
>>>>> verified this though).
>>>>
>>>>
>>>> I don't think that's a problem. All destination alpha values will be 1
>>>> even after the subpixel AA test is painted, and you'll treat it as normal.
>>>>
>>>
>>>  I was thinking something like this:
>>>
>>> - draw subpixel AA text over an opaque background
>>> - draw a partially-transparent rect with destination-atop mode over the
>>> subpixel AA text
>>>
>>>  Now some of the subpixel AA text is still there, but the destination
>>> alpha is non-1, so things will go bad when you composite into the page.
>>>  (At least I think it will.. Porter-Duff makes my head spin sometimes.)
>>>
>>
>> I don't see the problem. After the first step, you have an RGBA buffer
>> that represents exactly the result of the rendering. The second step treats
>> it exactly like any other RGBA buffer. Am I being dense?
>>
>
> No, it's probably me.  I was thinking that since there was a way to
> introduce non-1 alpha into the backing store after-the-fact, it would break
> the previously-performed subpixel coverage blending.  But perhaps not.
>

If MozOpaque is set or matteColor (or some other property that we can agree
upon), you will be guaranteed that there will never be alpha in the backing
store when you draw the text. We would also need to define under what
compositing modes subpixel AA happens.


>
>
>>
>>> The suggestion on the list earlier was to keep two versions of the
>>>> canvas buffer: one with grayscale AA, another with subpixel AA, and
>>>> composite with the subpixel AA buffer when we can do that safely, otherwise
>>>> use the grayscale AA version. In many implementations there would be a
>>>> performance hit for this, so it would make sense to have authors opt-in to
>>>> that performance hit.
>>>>
>>>
>>> It would also be a needless performance hit if the developer knew that
>>> they always wanted subpixel AA, and that their app would never fringe.
>>>
>>
>> I don't think the developer can ever know that. They'd have to assume the
>> browser/platform does not have a quick-zoom feature, which is an assumption
>> developers shouldn't be making. Although I guess we could just declare that
>> that case isn't important enough to matter.
>>
>
> Well, pretty much all devices that have pinch-zoom today are high-DPI, and
> don't implement subpixel AA.  :)   But no, I don't think that's not a good
> assumption to bake into the web platform.
>
>
>> So let me take a stab at a brief summary of the proposals so far, and the
>>> pros and cons of each (correct me if I missed anything):
>>>
>>> moz-opaque
>>> pro:  fairly easy to implement
>>> pro:  no performance hit over regular rendering
>>> pro:  many opportunities for optimization
>>> pro:  catches all in-canvas cases of color fringing
>>> con:  does not handle any out-of-canvas color fringing
>>> con:  opt-in
>>>
>>
>> Additional con: requires changes to canvas compositing spec and possibly
>> implementations.
>>
>
> Yes, since it's new behaviour it'll require spec changes.  I guess we can
> consider that as part of "con" of being opt-in.
>
> automatic opacity detection
>>> pro:  catches most (all?) cases of in-canvas color fringing
>>> pro:  some opportunties for optimization (must be conservative in some
>>> cases)
>>>
>>  con:  does not catch color fringing on CSS transforms, canvas -> WebGL,
>>> etc
>>>
>>> context attribute (something like:  context.textAntialising = { 'none',
>>> 'grayscale', 'subpixel' })
>>> pro:  very easy to implement
>>> pro:  no performance hit
>>> con:  does not catch any cases of color fringing; completely up to web
>>> developer
>>> con:  opt-in
>>>
>>
>> Additional con: requires specification and implementation of what happens
>> when subpixel AA is drawn over transparent background.
>>
>
>> deferred canvas rendering (collect commands into a buffer, flush buffer
>>> only when compositing canvas to page, and decide on subpixel AA at that
>>> point)
>>> pro:  catches all cases of color fringing
>>> con:  in some cases, requires an infinite buffer (e.g., a canvas that
>>> never clears, and only accumulates drawing frame-to-frame means you must
>>> accumulate commands indefinitely)
>>>
>>
>> Not really true, you can just give up on the complex cases and draw
>> grayscale whenever you feel like it.
>>
>
> And leave the behaviour unspecified, I'm guessing?  Doesn't that least to
> inconsistent behaviour between browsers?  Even within one implementation,
> if you had content whose command stream varied over the maximum buffer
> length threshold, it'd toggle between subpixel and grayscale AA. Not sure
> if this is a case worth worrying about, but it does feel like it's exposing
> more of the implementation that one would like.
>

So basically, this will be a feature for browsers that have no pinch-zoom
and cases where the author is sure that the canvas DPI matches the screen
DPI.
I personally like the look of regular AA text better than subpixel AA text
so I would like a way to turn it off. I guess it would be up to the browser
to make it a preference.


>
>>
>>> con:  difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
>>> con:  may introduce performance hit due to re-rendering with and without
>>> subpixel AA (in cases where you would rather have just gone without)
>>>
>>> two buffers (one grayscale, one LCD AA)
>>> pro:  handles all cases of color fringing
>>> pro:  moderately easy to implement
>>> con:  RAM (or VRAM) usage is doubled
>>> con:  possibly-unnecessary performance hit
>>> con:  must be opt-in
>>>
>>
>> Sounds right with the above modifications.
>
>
>>
>> Rob
>> --
>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>
>
>

From senorblanco at chromium.org  Mon Feb 18 20:19:17 2013
From: senorblanco at chromium.org (Stephen White)
Date: Mon, 18 Feb 2013 23:19:17 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
Message-ID: <CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>

On Sat, Feb 16, 2013 at 4:12 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Sat, Feb 16, 2013 at 11:09 AM, Stephen White <senorblanco at chromium.org>wrote:
>
>> deferred canvas rendering (collect commands into a buffer, flush buffer
>> only when compositing canvas to page, and decide on subpixel AA at that
>> point)
>> pro:  catches all cases of color fringing
>> con:  in some cases, requires an infinite buffer (e.g., a canvas that
>> never clears, and only accumulates drawing frame-to-frame means you must
>> accumulate commands indefinitely)
>> con:  difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
>> con:  may introduce performance hit due to re-rendering with and without
>> subpixel AA (in cases where you would rather have just gone without)
>>
>> two buffers (one grayscale, one LCD AA)
>> pro:  handles all cases of color fringing
>> pro:  moderately easy to implement
>> con:  RAM (or VRAM) usage is doubled
>> con:  possibly-unnecessary performance hit
>> con:  must be opt-in
>>
>
> Both of these schemes can actually be optimized some more: As long as no
> text is drawn to a canvas, you can freely rasterize (in the first case) or
> use just one buffer (in the second case). In fact, this is true as long as
> no text is drawn to a canvas over non-opaque pixels. So a lot of canvas
> usage could be handled with little or no performance hit.


Even with text on an opaque background, I think you still have to worry
about the case of transformed canvases.  E.g., text drawn over an opaque
background into a single still frame canvas, but then subsequently rotated
via CSS transforms from 0 degrees through non-0.  The first frame can use
subpixel AA, but then subsequent frames can't.  So I think you need to keep
the command stream around (first case) or
always render two buffers as soon as you draw text.  That seems like a
pretty heavy burden.

For canvas->WebGL the problem becomes pretty much intractable, since
there's no way to know what a given shader will do to the pixels.  So I
think you'd always have to give up and do grayscale AA in that case.

Stephen

>
>
> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>

From robert at ocallahan.org  Mon Feb 18 20:40:40 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 19 Feb 2013 17:40:40 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
Message-ID: <CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>

On Tue, Feb 19, 2013 at 5:19 PM, Stephen White <senorblanco at chromium.org>wrote:

> Even with text on an opaque background, I think you still have to worry
> about the case of transformed canvases.  E.g., text drawn over an opaque
> background into a single still frame canvas, but then subsequently rotated
> via CSS transforms from 0 degrees through non-0.  The first frame can use
> subpixel AA, but then subsequent frames can't.  So I think you need to keep
> the command stream around (first case) or
> always render two buffers as soon as you draw text.  That seems like a
> pretty heavy burden.
>
> For canvas->WebGL the problem becomes pretty much intractable, since
> there's no way to know what a given shader will do to the pixels.  So I
> think you'd always have to give up and do grayscale AA in that case.
>

Yes, you're quite right.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From nyarly at gmail.com  Tue Feb 19 01:00:30 2013
From: nyarly at gmail.com (Judson Lester)
Date: Tue, 19 Feb 2013 01:00:30 -0800
Subject: [whatwg] Input elements & microdata
Message-ID: <CAOpbp3fdcX3K0JGg3ARgzXwbDW06Uoxhn+PhAZrnhqWCaqMYWA@mail.gmail.com>

There was an email from last year suggesting that the values of input
elements be derived from their value attributes - the purpose there being
to be able to control the form via the microdata interface.  I've only been
able to read it in the archives - the brief exchange was between Igor
Nikolev and Ian Hickson, who was curious about use cases.

Conversely, it would be useful to be able to use input elements to contain
item values, and at the moment, since their values would be derived from
their textContent, they're useless for that.  Specifically, it's often
reasonable to present a representation as the default values in a form and
allow for updates simply by posting the changed values.  It seems unwieldy
to need to replicate that information in e.g. data elements.

While it would be simple to treat the defaultValue as the item property
value for elements (and for radio inputs, let the representation mark the
selected input as the itemprop), it seems counter to the spirit of the
proposal.  The alternative would be to do something like excluding
unsuccessful input elements during the property crawl - which would allow
all such inputs to be marked as itemprop="name" and only the selected one
contribute to the itemscope's property list.

I think Igor had a point though - a consequence of making input elements
useful as itemprop elements would be that it ought to be possible to assign
values to inputs via HTMLElement.itemValue= and see those values reflected
in the form.  It seems like it wouldn't be the best means to manipulate
form data though, since e.g. radio inputs would behave strangely under the
current interface (yes_radio.itemValue="no" should probably change the
value of the button, not which button is selected).

I find the use case of a form to present key/value data compelling, and
being able to apply microdata vocabularies to same strikes me as
particularly useful.

Judson

From cabanier at gmail.com  Tue Feb 19 20:31:35 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Wed, 20 Feb 2013 15:31:35 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
Message-ID: <CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>

So now we have:
- don't do this on pinch-zoom devices
- don't do this for HW accelerated canvases
- don't do this if the canvas dpi doesn't match the screen
- don't do this if there are transforms
- authors will have to be very careful when using this feature since it can
turn on or off or cause rendering glitches.

Is it still worth pursuing this?

On Tue, Feb 19, 2013 at 3:40 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Tue, Feb 19, 2013 at 5:19 PM, Stephen White <senorblanco at chromium.org>wrote:
>
>> Even with text on an opaque background, I think you still have to worry
>> about the case of transformed canvases.  E.g., text drawn over an opaque
>> background into a single still frame canvas, but then subsequently rotated
>> via CSS transforms from 0 degrees through non-0.  The first frame can use
>> subpixel AA, but then subsequent frames can't.  So I think you need to keep
>> the command stream around (first case) or
>> always render two buffers as soon as you draw text.  That seems like a
>> pretty heavy burden.
>>
>> For canvas->WebGL the problem becomes pretty much intractable, since
>> there's no way to know what a given shader will do to the pixels.  So I
>> think you'd always have to give up and do grayscale AA in that case.
>>
>
> Yes, you're quite right.
>
>
> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>

From annevk at annevk.nl  Wed Feb 20 02:55:35 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Wed, 20 Feb 2013 10:55:35 +0000
Subject: [whatwg] Canvas: Fonts in workers
Message-ID: <CADnb78jYOs1ec2NXY10jH6fMzTtB_ofyJYUdVG80m7h-TeH8WA@mail.gmail.com>

I think currently the specification assumes FontLoader is the solution
to fonts in workers. However, 1) FontLoader as currently designed does
not work in workers. 2) Even if slightly modified it would not work in
shared workers as FontLoader is pretty much tied to the document that
has the relevant @font-face declarations. I don't really have a good
solution to this problem.


-- 
http://annevankesteren.nl/

From hsivonen at iki.fi  Wed Feb 20 07:10:20 2013
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 20 Feb 2013 17:10:20 +0200
Subject: [whatwg] Mapping hz-gb-2312,
	iso-2022-kr and iso-2022-cn to a replacement encoding
Message-ID: <CAJQvAufgLgexA3Y-XDEk99QgfK4wsha_F8bxmcNx7AG=7jhKuA@mail.gmail.com>

Hi,

In reference to:
https://code.google.com/p/chromium/issues/detail?id=15701

Would you be willling to re-remove hz-gb-2312, iso-2022-kr and
iso-2022-cn support from Chrome if their labels were aliased to an
XSS-safe replacement encoding like the one proposed in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21057 instead of making
the labels behave as unknown?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From gphemsley at gmail.com  Wed Feb 20 12:39:09 2013
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Wed, 20 Feb 2013 15:39:09 -0500
Subject: [whatwg] WHATWG Wiki Licensing Changes
Message-ID: <CAH4e3M4hTbXttH+U9mmsrS6UDa2SQbVCzvCcgAkXvUU=1Kpfqw@mail.gmail.com>

Hello all,

Be advised that all edits made to the WHATWG Wiki after today
(2013-02-20) will be released under the Creative Commons Zero (CC0)
Universal Public Domain Declaration. All edits made prior to today
will remain licensed under the MIT License previously in place, unless
a user or a page specifically opts out of MIT and into CC0.

For the full details, see [[WHATWG Wiki:Copyrights]]:
http://wiki.whatwg.org/wiki/WHATWG_Wiki:Copyrights

Wiki users are encouraged to release their previous edits under the
CC0 declaration by adding the {{CC0 user}} template to their User
page:
http://wiki.whatwg.org/wiki/Template:CC0_user

Pages that were created prior to today should be tagged with {{CC0
page}} once all its contributing editors have opted in to {{CC0 user}}
or have otherwise provided a waiver of the MIT License:
http://wiki.whatwg.org/wiki/Template:CC0_page

This change attempts to make it easier and clearer for individuals
wishing modify and reuse the information on the wiki, with a
particular eye towards incorporating text in future specifications.

To facilitate determining how a page is licensed, there are also two
categories that list which users and pages have opted in to CC0:
http://wiki.whatwg.org/wiki/Category:CC0_users
http://wiki.whatwg.org/wiki/Category:CC0_pages

Remember: If a page is not specifically tagged with {{CC0 page}}, be
sure to check the history of the page to determine whether its
contents are available to reuse without restrictions. Pages created
before 2013-02-20 will need to be verified with each contributing
editor to determine the reuse restrictions on the page.

Regards,
Gordon

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From rniwa at apple.com  Wed Feb 20 17:14:21 2013
From: rniwa at apple.com (Ryosuke Niwa)
Date: Wed, 20 Feb 2013 17:14:21 -0800
Subject: [whatwg] inputmode feedback
In-Reply-To: <CADP2=hp-yPwWAKpeuPUwaAF=LmMfyC0Uw2_KxgQGY7cr3GaKuA@mail.gmail.com>
References: <511BE988.7070208@lamouri.fr>
	<CADP2=hp-yPwWAKpeuPUwaAF=LmMfyC0Uw2_KxgQGY7cr3GaKuA@mail.gmail.com>
Message-ID: <80D1B5C9-E6AD-41B4-B1D3-8804003AF568@apple.com>

On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:
> To conclude, Mozilla is interested in implementing this set of keywords:
> verbatim, text, name, prose and digit (or numeric).

Why is name not an input type?

How does one decide whether a given semantics should be introduced as a type or a mode?

On Feb 15, 2013, at 12:28 AM, Takayoshi Kochi (?? ??) <kochi at google.com> wrote:

> Hello Mounir,
> 
> On Thu, Feb 14, 2013 at 4:29 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:
> 
>> Regarding the three Japanese specific types, it is not clear if
>> inputmode is the best way to solve the use cases intended to be solved.
>> Actually, 'kana' and 'katakana' are trying to give a hint about the
>> script that has to be used which seems to be orthogonal with the other
>> types. We could allow inputmode to have a set of values but that would
>> make the behaviour way more complex so I wonder if we couldn't try to
>> solve that problem with another attribute like inputscript.
>> 
> "three Japanese specific types"? 'kana', 'katakana', and 'full-width-latin"?
> 
> I agree that it is weird 'kana' and 'katakana' are listed as inputmode
> attribute, and 'inputscript' sounds more reasonable place where they should be listed.

Given the text in the spec "[t]he inputmode content attribute is an enumerated attribute that specifies what kind of input mechanism would be most helpful for users entering content into the form control," it makes sense for input mode to include kana and katakana.

On the other hand, I'm surprised to find that these modes are very specific to Japanese.

- R. Niwa


From jonas at sicking.cc  Wed Feb 20 21:47:43 2013
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 20 Feb 2013 21:47:43 -0800
Subject: [whatwg] Canvas: Fonts in workers
In-Reply-To: <CADnb78jYOs1ec2NXY10jH6fMzTtB_ofyJYUdVG80m7h-TeH8WA@mail.gmail.com>
References: <CADnb78jYOs1ec2NXY10jH6fMzTtB_ofyJYUdVG80m7h-TeH8WA@mail.gmail.com>
Message-ID: <CA+c2ei9hd6htE6-3=-nmtqf8MGSJUD+hiewQA+OawQVp+LYEmg@mail.gmail.com>

On Wed, Feb 20, 2013 at 2:55 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> I think currently the specification assumes FontLoader is the solution
> to fonts in workers. However, 1) FontLoader as currently designed does
> not work in workers. 2) Even if slightly modified it would not work in
> shared workers as FontLoader is pretty much tied to the document that
> has the relevant @font-face declarations. I don't really have a good
> solution to this problem.

In general, we need to define which fonts are available to use when
drawing text into a canvas in a worker. For a dedicated worker we
could say that it's the same set as is available in the document,
except that that set can change at any time as new fonts are loaded.
And for a shared worker this is even more complicated since multiple
documents, with different sets of fonts, can be connected to the same
shared worker.

We could possibly still use the the FontLoader interface if we do the following:
* FontLoader needs to drop the dependency on CSSFontFaceRule (or at
least make the dependency optional and not available in workers).
* We'll expose a global FontLoader object per worker scope.
* The worker can't use any downloaded fonts other than the ones loaded
through the global FontLoader for that scope.

/ Jonas

From ian at hixie.ch  Wed Feb 20 21:59:41 2013
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 21 Feb 2013 05:59:41 +0000 (UTC)
Subject: [whatwg] Canvas: Fonts in workers
In-Reply-To: <CA+c2ei9hd6htE6-3=-nmtqf8MGSJUD+hiewQA+OawQVp+LYEmg@mail.gmail.com>
References: <CADnb78jYOs1ec2NXY10jH6fMzTtB_ofyJYUdVG80m7h-TeH8WA@mail.gmail.com>
	<CA+c2ei9hd6htE6-3=-nmtqf8MGSJUD+hiewQA+OawQVp+LYEmg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1302210558350.3956@ps20323.dreamhostps.com>

On Wed, 20 Feb 2013, Jonas Sicking wrote:
> On Wed, Feb 20, 2013 at 2:55 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> > I think currently the specification assumes FontLoader is the solution 
> > to fonts in workers. However, 1) FontLoader as currently designed does 
> > not work in workers. 2) Even if slightly modified it would not work in 
> > shared workers as FontLoader is pretty much tied to the document that 
> > has the relevant @font-face declarations. I don't really have a good 
> > solution to this problem.
> 
> In general, we need to define which fonts are available to use when 
> drawing text into a canvas in a worker. For a dedicated worker we could 
> say that it's the same set as is available in the document, except that 
> that set can change at any time as new fonts are loaded. And for a 
> shared worker this is even more complicated since multiple documents, 
> with different sets of fonts, can be connected to the same shared 
> worker.
> 
> We could possibly still use the the FontLoader interface if we do the following:
> * FontLoader needs to drop the dependency on CSSFontFaceRule (or at
> least make the dependency optional and not available in workers).
> * We'll expose a global FontLoader object per worker scope.
> * The worker can't use any downloaded fonts other than the ones loaded
> through the global FontLoader for that scope.

My expectation was that this is how FontLoader would work for workers. (We 
can't rely on what fonts are in the Document since that's shared state, 
and workers try to avoid shared state as a design principle.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From annevk at annevk.nl  Thu Feb 21 02:47:37 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Thu, 21 Feb 2013 10:47:37 +0000
Subject: [whatwg] Canvas: Fonts in workers
In-Reply-To: <Pine.LNX.4.64.1302210558350.3956@ps20323.dreamhostps.com>
References: <CADnb78jYOs1ec2NXY10jH6fMzTtB_ofyJYUdVG80m7h-TeH8WA@mail.gmail.com>
	<CA+c2ei9hd6htE6-3=-nmtqf8MGSJUD+hiewQA+OawQVp+LYEmg@mail.gmail.com>
	<Pine.LNX.4.64.1302210558350.3956@ps20323.dreamhostps.com>
Message-ID: <CADnb78jiZn6PxARiKUx8jzjWQQfRkKpmX9mT_Q6sV0p=muBAcA@mail.gmail.com>

On Thu, Feb 21, 2013 at 5:59 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 20 Feb 2013, Jonas Sicking wrote:
>> We could possibly still use the the FontLoader interface if we do the following:
>> * FontLoader needs to drop the dependency on CSSFontFaceRule (or at
>> least make the dependency optional and not available in workers).
>> * We'll expose a global FontLoader object per worker scope.
>> * The worker can't use any downloaded fonts other than the ones loaded
>> through the global FontLoader for that scope.
>
> My expectation was that this is how FontLoader would work for workers. (We
> can't rely on what fonts are in the Document since that's shared state,
> and workers try to avoid shared state as a design principle.)

Sure, but FontLoader is tightly coupled with the document since it
does not actually supply URLs for the fonts itself, it relies on
@font-face for that. It just indicates whether the font is loaded or
that it should be loaded.


-- 
http://annevankesteren.nl/

From ian at hixie.ch  Thu Feb 21 08:45:12 2013
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 21 Feb 2013 16:45:12 +0000 (UTC)
Subject: [whatwg] Canvas: Fonts in workers
In-Reply-To: <CADnb78jiZn6PxARiKUx8jzjWQQfRkKpmX9mT_Q6sV0p=muBAcA@mail.gmail.com>
References: <CADnb78jYOs1ec2NXY10jH6fMzTtB_ofyJYUdVG80m7h-TeH8WA@mail.gmail.com>
	<CA+c2ei9hd6htE6-3=-nmtqf8MGSJUD+hiewQA+OawQVp+LYEmg@mail.gmail.com>
	<Pine.LNX.4.64.1302210558350.3956@ps20323.dreamhostps.com>
	<CADnb78jiZn6PxARiKUx8jzjWQQfRkKpmX9mT_Q6sV0p=muBAcA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1302211645030.3956@ps20323.dreamhostps.com>

On Thu, 21 Feb 2013, Anne van Kesteren wrote:
> On Thu, Feb 21, 2013 at 5:59 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 20 Feb 2013, Jonas Sicking wrote:
> >> We could possibly still use the the FontLoader interface if we do the 
> >> following: * FontLoader needs to drop the dependency on 
> >> CSSFontFaceRule (or at least make the dependency optional and not 
> >> available in workers). * We'll expose a global FontLoader object per 
> >> worker scope. * The worker can't use any downloaded fonts other than 
> >> the ones loaded through the global FontLoader for that scope.
> >
> > My expectation was that this is how FontLoader would work for workers. 
> > (We can't rely on what fonts are in the Document since that's shared 
> > state, and workers try to avoid shared state as a design principle.)
> 
> Sure, but FontLoader is tightly coupled with the document since it does 
> not actually supply URLs for the fonts itself, it relies on @font-face 
> for that. It just indicates whether the font is loaded or that it should 
> be loaded.

Then we should fix that. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From senorblanco at chromium.org  Thu Feb 21 11:12:35 2013
From: senorblanco at chromium.org (Stephen White)
Date: Thu, 21 Feb 2013 14:12:35 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
Message-ID: <CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>

On Tue, Feb 19, 2013 at 11:31 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> So now we have:
> - don't do this on pinch-zoom devices
> - don't do this for HW accelerated canvases
> - don't do this if the canvas dpi doesn't match the screen
>
- don't do this if there are transforms
> - authors will have to be very careful when using this feature since it
> can turn on or off or cause rendering glitches.
>
> Is it still worth pursuing this?
>

I believe it is.  Even with those constraints, there are a large number of
applications which can benefit from text which looks as good as the native
platform can provide.

That said, I also think Robert is right that we should not spec out
precisely when subpixel AA text will occur in any of these automatic modes,
since:

1)  there are some platforms/devices which don't do LCD text at all
2)  It may be too restrictive for the browser implementor, e.g., they may
be essentially required to implement deferred rendering or two backing
stores in order to meet the resulting spec, which seems onerous

Subpixel AA text aside, I still think it's worth spec'ing out mozOpaque, if
only just for the optimization opportunities that we don't get with an
automatic solution (e.g., putImageData).  Its implementation is fairly
straightforward (much more so than the other options above), and it won't
break any existing content.

To me, the "it breaks compositing" argument falls into the "doctor, it
hurts when I do this" category:  the user is specifically opting into an
opaque backing store, and so the changes in behaviour for compositing modes
which reference destination alpha are expected, just as they are when using
DST_ALPHA blending modes in a WebGL context created with the "alpha"
attribute set to false.

Stephen


>
> On Tue, Feb 19, 2013 at 3:40 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Tue, Feb 19, 2013 at 5:19 PM, Stephen White <senorblanco at chromium.org>wrote:
>>
>>> Even with text on an opaque background, I think you still have to worry
>>> about the case of transformed canvases.  E.g., text drawn over an opaque
>>> background into a single still frame canvas, but then subsequently rotated
>>> via CSS transforms from 0 degrees through non-0.  The first frame can use
>>> subpixel AA, but then subsequent frames can't.  So I think you need to keep
>>> the command stream around (first case) or
>>> always render two buffers as soon as you draw text.  That seems like a
>>> pretty heavy burden.
>>>
>>> For canvas->WebGL the problem becomes pretty much intractable, since
>>> there's no way to know what a given shader will do to the pixels.  So I
>>> think you'd always have to give up and do grayscale AA in that case.
>>>
>>
>> Yes, you're quite right.
>>
>>
>> Rob
>> --
>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>
>
>

From cmhjones at gmail.com  Thu Feb 21 11:42:40 2013
From: cmhjones at gmail.com (Cameron Jones)
Date: Thu, 21 Feb 2013 19:42:40 +0000
Subject: [whatwg] HTTP Forms extension specification
Message-ID: <CALGrgesd24R=Dhf0KE8aJfTVLR10MME2QGD8T2Gt+ndUkFXMng@mail.gmail.com>

Hello wg,

I've just committed an initial draft of HTTP extensions for Forms:

http://cameronjones.github.com/form-http-extensions/index.html

The document can be considered within the public domain for integration.

Thanks,
Cameron Jones

From robert at ocallahan.org  Thu Feb 21 15:33:48 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 22 Feb 2013 12:33:48 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
Message-ID: <CAOp6jLaH=g6gYmKYDiM1uNLzatMo=0D6uQ8aBhUkeCJNyH_9Yg@mail.gmail.com>

I think Rik is convincing me that we shouldn't expose mozOpaque or any
other explicit subpixel AA control to the Web. It will be very easy for Web
authors to test it in one place and discover that it works without
realizing that they're causing problems for some users.

I think a fully automatic solution that tries to use subpixel AA but is
always able to render grayscale AA if needed is the way to go. Possibly
with an author hint to suggest opting into a more expensive rendering path.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From cabanier at gmail.com  Thu Feb 21 16:01:49 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Fri, 22 Feb 2013 11:01:49 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLaH=g6gYmKYDiM1uNLzatMo=0D6uQ8aBhUkeCJNyH_9Yg@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
	<CAOp6jLaH=g6gYmKYDiM1uNLzatMo=0D6uQ8aBhUkeCJNyH_9Yg@mail.gmail.com>
Message-ID: <CAGN7qDB2M7r9AYyZavPo11NL7hRBXuNT+0SHdXe=OF8_kZK5iQ@mail.gmail.com>

On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> I think Rik is convincing me that we shouldn't expose mozOpaque or any
> other explicit subpixel AA control to the Web. It will be very easy for Web
> authors to test it in one place and discover that it works without
> realizing that they're causing problems for some users.
>
> I think a fully automatic solution that tries to use subpixel AA but is
> always able to render grayscale AA if needed is the way to go. Possibly
> with an author hint to suggest opting into a more expensive rendering path.
>
>
Great! I think matteColor (or matteStyle to be more consistent) can easily
be implemented. We can optimize rendering later.

So, if a mattecolor is set the UA can assume that:
- all compositing operation within the canvas can ignore background alpha
- the canvas can be copied directly to the screen (unless another effect is
applied to the canvas element or its ancestor)

If mattecolor is set, the UA should matte with that color. If a compositing
operation (that introduces alpha) is used, the matte operation needs to be
repeated.

Rik

From annevk at annevk.nl  Fri Feb 22 02:05:51 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Fri, 22 Feb 2013 10:05:51 +0000
Subject: [whatwg] HTTP Forms extension specification
In-Reply-To: <CALGrgesd24R=Dhf0KE8aJfTVLR10MME2QGD8T2Gt+ndUkFXMng@mail.gmail.com>
References: <CALGrgesd24R=Dhf0KE8aJfTVLR10MME2QGD8T2Gt+ndUkFXMng@mail.gmail.com>
Message-ID: <CADnb78hqMt=thXvbbeamVwiKcLAV4NjbX60FGqE2CcDBSTXyWQ@mail.gmail.com>

On Thu, Feb 21, 2013 at 7:42 PM, Cameron Jones <cmhjones at gmail.com> wrote:
> I've just committed an initial draft of HTTP extensions for Forms:
>
> http://cameronjones.github.com/form-http-extensions/index.html
>
> The document can be considered within the public domain for integration.

I'd recommend making CC0 the license then, rather than CCA.

Motivation would also useful. It's not entirely clear to me why this
complexity is warranted. And the complexity seems lacking, e.g. you're
not putting the necessary restrictions on header names and values as
far as I can tell.

(Spelling: HTTP, XMLHttpRequest, JavaScript, my name is with a
lowercase v if you include the first name.)


-- 
http://annevankesteren.nl/

From cmhjones at gmail.com  Fri Feb 22 06:29:00 2013
From: cmhjones at gmail.com (Cameron Jones)
Date: Fri, 22 Feb 2013 14:29:00 +0000
Subject: [whatwg] HTTP Forms extension specification
In-Reply-To: <CADnb78hqMt=thXvbbeamVwiKcLAV4NjbX60FGqE2CcDBSTXyWQ@mail.gmail.com>
References: <CALGrgesd24R=Dhf0KE8aJfTVLR10MME2QGD8T2Gt+ndUkFXMng@mail.gmail.com>
	<CADnb78hqMt=thXvbbeamVwiKcLAV4NjbX60FGqE2CcDBSTXyWQ@mail.gmail.com>
Message-ID: <CALGrgesxyCarfoHDsTSiHbg2S0rEKvUHnGVEeBfUGudmTJ=+uQ@mail.gmail.com>

On Fri, Feb 22, 2013 at 10:05 AM, Anne van Kesteren <annevk at annevk.nl>wrote:

> On Thu, Feb 21, 2013 at 7:42 PM, Cameron Jones <cmhjones at gmail.com> wrote:
> > I've just committed an initial draft of HTTP extensions for Forms:
> >
> > http://cameronjones.github.com/form-http-extensions/index.html
> >
> > The document can be considered within the public domain for integration.
>
> I'd recommend making CC0 the license then, rather than CCA.
>


Done, and spelling fixed.


>
> Motivation would also useful. It's not entirely clear to me why this
> complexity is warranted.


The motivations are the same which support declarative over imperative
programming, access to the HTTP protocol methods and headers (ETags,
versioning), greater flexibility over payload binding and the ability to
avoid using cookies for session continuation. The access to HTTP Auth
provides greater security over non-HTTPS than is currently possible while
retaining the ability to style forms for login\logout which users have come
to expect. This is all in the absence of requiring JavaScript to be on.

For a (slightly inflamed from a rant-able persona, so please read with
potential sensitivities off) further examination of the use cases and
rationale, the specification is the reification of the proposal i wrote
last year:

http://www.w3.org/wiki/User:Cjones/ISSUE-195



> And the complexity seems lacking, e.g. you're
> not putting the necessary restrictions on header names and values as
> far as I can tell.
>
>
The HTTP headers are restricted using a copy-paste of those in XHR which is
included in the form submission process. Happy to hear any suggestions to
improve the structure or general authoring.

Thanks,
Cameron Jones

From senorblanco at chromium.org  Fri Feb 22 07:59:48 2013
From: senorblanco at chromium.org (Stephen White)
Date: Fri, 22 Feb 2013 10:59:48 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDB2M7r9AYyZavPo11NL7hRBXuNT+0SHdXe=OF8_kZK5iQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
	<CAOp6jLaH=g6gYmKYDiM1uNLzatMo=0D6uQ8aBhUkeCJNyH_9Yg@mail.gmail.com>
	<CAGN7qDB2M7r9AYyZavPo11NL7hRBXuNT+0SHdXe=OF8_kZK5iQ@mail.gmail.com>
Message-ID: <CAPeKFTiVrKfzTZOCvshynH3yUyDePz+6ObJpjYGGvLOj_630CA@mail.gmail.com>

On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier <cabanier at gmail.com> wrote:

>
>
> On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> I think Rik is convincing me that we shouldn't expose mozOpaque or any
>> other explicit subpixel AA control to the Web. It will be very easy for Web
>> authors to test it in one place and discover that it works without
>> realizing that they're causing problems for some users.
>>
>> I think a fully automatic solution that tries to use subpixel AA but is
>> always able to render grayscale AA if needed is the way to go. Possibly
>> with an author hint to suggest opting into a more expensive rendering path.
>
>
Here are the problems I see with that approach:

1)  In order to avoid a performance hit for existing content, it still
requires a spec change (the hint)
2)  Even with the hint, when the author knows they want LCD AA, they still
incur a performance penalty of drawing to two buffers.
3)  It still can't handle all cases, such as canvas -> WebGL, which will
have to remain grayscale-only, even when the author knows it would be safe
for their application.

Also, what form should this authoring hint take?  Is it going to explicitly
call out LCD AA?  In that case, how is it better than an opt-in canvas
attribute?  If it doesn't explicitly call out LCD AA, but that's the only
effect it has, what should it be called?

I also have concerns that the knowledge of when it's safe to use the LCD AA
buffer is going to spread throughout the browser codebase, even in areas
which currently have no knowledge of canvas, in order to handle all the
special cases.  This may just be an implementation detail (and may be
avoidable, this is TBD), but it does have the potential to introduce
dependencies or complicate implementation.


>>
> Great! I think matteColor (or matteStyle to be more consistent) can easily
> be implemented. We can optimize rendering later.
>

> So, if a mattecolor is set the UA can assume that:
>

Maybe I'm missing something, but if we're going down the automatic road,
why do we need a new function/attribute?  Why not simply detect when a
canvas-sized fillRect() has been performed with an opaque fillStyle?  This
would also allow optimization of existing content.

Stephen

- all compositing operation within the canvas can ignore background alpha
> - the canvas can be copied directly to the screen (unless another effect
> is applied to the canvas element or its ancestor)
>
> If mattecolor is set, the UA should matte with that color. If a
> compositing operation (that introduces alpha) is used, the matte operation
> needs to be repeated.
>
> Rik
>

From annevk at annevk.nl  Fri Feb 22 08:37:45 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Fri, 22 Feb 2013 16:37:45 +0000
Subject: [whatwg] HTTP Forms extension specification
In-Reply-To: <CALGrgesxyCarfoHDsTSiHbg2S0rEKvUHnGVEeBfUGudmTJ=+uQ@mail.gmail.com>
References: <CALGrgesd24R=Dhf0KE8aJfTVLR10MME2QGD8T2Gt+ndUkFXMng@mail.gmail.com>
	<CADnb78hqMt=thXvbbeamVwiKcLAV4NjbX60FGqE2CcDBSTXyWQ@mail.gmail.com>
	<CALGrgesxyCarfoHDsTSiHbg2S0rEKvUHnGVEeBfUGudmTJ=+uQ@mail.gmail.com>
Message-ID: <CADnb78iosSFzc9KTjmqiSMrTo2J9BKFXCy+OhJ5tNVoeADBRnQ@mail.gmail.com>

On Fri, Feb 22, 2013 at 2:29 PM, Cameron Jones <cmhjones at gmail.com> wrote:
> The HTTP headers are restricted using a copy-paste of those in XHR which is
> included in the form submission process. Happy to hear any suggestions to
> improve the structure or general authoring.

You are not making the same checks as
http://xhr.spec.whatwg.org/#the-setrequestheader%28%29-method does.
E.g. I could inject a header value in your algorithm that is CRLF
followed by "Referer: mahahah".

Not really convinced by the use cases, but maybe someone else is.


-- 
http://annevankesteren.nl/

From cmhjones at gmail.com  Fri Feb 22 08:46:04 2013
From: cmhjones at gmail.com (Cameron Jones)
Date: Fri, 22 Feb 2013 16:46:04 +0000
Subject: [whatwg] HTTP Forms extension specification
In-Reply-To: <CADnb78iosSFzc9KTjmqiSMrTo2J9BKFXCy+OhJ5tNVoeADBRnQ@mail.gmail.com>
References: <CALGrgesd24R=Dhf0KE8aJfTVLR10MME2QGD8T2Gt+ndUkFXMng@mail.gmail.com>
	<CADnb78hqMt=thXvbbeamVwiKcLAV4NjbX60FGqE2CcDBSTXyWQ@mail.gmail.com>
	<CALGrgesxyCarfoHDsTSiHbg2S0rEKvUHnGVEeBfUGudmTJ=+uQ@mail.gmail.com>
	<CADnb78iosSFzc9KTjmqiSMrTo2J9BKFXCy+OhJ5tNVoeADBRnQ@mail.gmail.com>
Message-ID: <CALGrget--2AJfgYEndJt8geNT6VxzUXAiNQ8eQyQYun_Lfw2pg@mail.gmail.com>

On Fri, Feb 22, 2013 at 4:37 PM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Fri, Feb 22, 2013 at 2:29 PM, Cameron Jones <cmhjones at gmail.com> wrote:
> > The HTTP headers are restricted using a copy-paste of those in XHR which
> is
> > included in the form submission process. Happy to hear any suggestions to
> > improve the structure or general authoring.
>
> You are not making the same checks as
> http://xhr.spec.whatwg.org/#the-setrequestheader%28%29-method does.
> E.g. I could inject a header value in your algorithm that is CRLF
> followed by "Referer: mahahah".
>
>
Ahh, yes i see the references....i'll fix that now.

Thanks,
cam

From ian at hixie.ch  Fri Feb 22 08:52:38 2013
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 22 Feb 2013 16:52:38 +0000 (UTC)
Subject: [whatwg] inputmode feedback
In-Reply-To: <80D1B5C9-E6AD-41B4-B1D3-8804003AF568@apple.com>
References: <511BE988.7070208@lamouri.fr>
	<CADP2=hp-yPwWAKpeuPUwaAF=LmMfyC0Uw2_KxgQGY7cr3GaKuA@mail.gmail.com>
	<80D1B5C9-E6AD-41B4-B1D3-8804003AF568@apple.com>
Message-ID: <Pine.LNX.4.64.1302221649260.3956@ps20323.dreamhostps.com>

On Wed, 20 Feb 2013, Ryosuke Niwa wrote:
> 
> Why is name not an input type?

There's a section that discusses it a bit:

http://whatwg.org/html#the-difference-between-the-field-type,-the-autofill-field-name,-and-the-input-modality

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From cabanier at gmail.com  Fri Feb 22 10:48:02 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Fri, 22 Feb 2013 10:48:02 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTiVrKfzTZOCvshynH3yUyDePz+6ObJpjYGGvLOj_630CA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
	<CAOp6jLaH=g6gYmKYDiM1uNLzatMo=0D6uQ8aBhUkeCJNyH_9Yg@mail.gmail.com>
	<CAGN7qDB2M7r9AYyZavPo11NL7hRBXuNT+0SHdXe=OF8_kZK5iQ@mail.gmail.com>
	<CAPeKFTiVrKfzTZOCvshynH3yUyDePz+6ObJpjYGGvLOj_630CA@mail.gmail.com>
Message-ID: <CAGN7qDDwfh+wN8=X1ipwc=ReKYafBg8eZv8PBmv=Zn9cQhXp7w@mail.gmail.com>

On Fri, Feb 22, 2013 at 7:59 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>>
>>
>> On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan <robert at ocallahan.org
>> > wrote:
>>
>>> I think Rik is convincing me that we shouldn't expose mozOpaque or any
>>> other explicit subpixel AA control to the Web. It will be very easy for Web
>>> authors to test it in one place and discover that it works without
>>> realizing that they're causing problems for some users.
>>>
>>> I think a fully automatic solution that tries to use subpixel AA but is
>>> always able to render grayscale AA if needed is the way to go. Possibly
>>> with an author hint to suggest opting into a more expensive rendering path.
>>
>>
> Here are the problems I see with that approach:
>
> 1)  In order to avoid a performance hit for existing content, it still
> requires a spec change (the hint)
> 2)  Even with the hint, when the author knows they want LCD AA, they still
> incur a performance penalty of drawing to two buffers.
> 3)  It still can't handle all cases, such as canvas -> WebGL, which will
> have to remain grayscale-only, even when the author knows it would be safe
> for their application.
>
> Also, what form should this authoring hint take?  Is it going to
> explicitly call out LCD AA?  In that case, how is it better than an opt-in
> canvas attribute?  If it doesn't explicitly call out LCD AA, but that's the
> only effect it has, what should it be called?
>
> I also have concerns that the knowledge of when it's safe to use the LCD
> AA buffer is going to spread throughout the browser codebase, even in areas
> which currently have no knowledge of canvas, in order to handle all the
> special cases.  This may just be an implementation detail (and may be
> avoidable, this is TBD), but it does have the potential to introduce
> dependencies or complicate implementation.
>

Since this is a feature for advanced users, we should let them handle all
the cases. (I would even allow subpixel AA on a transparent canvas)
Handling all the edge cases in the browser will be extremely difficult (if
it's even possible) and will just frustrate those advanced users since it
will get in their way.


>
>
>>>
>> Great! I think matteColor (or matteStyle to be more consistent) can
>> easily be implemented. We can optimize rendering later.
>>
>
>> So, if a mattecolor is set the UA can assume that:
>>
>
> Maybe I'm missing something, but if we're going down the automatic road,
> why do we need a new function/attribute?  Why not simply detect when a
> canvas-sized fillRect() has been performed with an opaque fillStyle?  This
> would also allow optimization of existing content.
>

Doesn't that seem slightly hacky?
So, if the canvas detects that you did a fillrect with a constant color, it
should assume that it's opaque?  This seems confusing from an author's
perspective.
In addition, compositing modes that introduce alpha will turn the bit off
again and there would be no way to turn it back on.


>
> - all compositing operation within the canvas can ignore background alpha
>> - the canvas can be copied directly to the screen (unless another effect
>> is applied to the canvas element or its ancestor)
>>
>> If mattecolor is set, the UA should matte with that color. If a
>> compositing operation (that introduces alpha) is used, the matte operation
>> needs to be repeated.
>>
>> Rik
>>
>
>

From cabanier at gmail.com  Fri Feb 22 16:53:29 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Sat, 23 Feb 2013 11:53:29 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTiVrKfzTZOCvshynH3yUyDePz+6ObJpjYGGvLOj_630CA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
	<CAOp6jLaH=g6gYmKYDiM1uNLzatMo=0D6uQ8aBhUkeCJNyH_9Yg@mail.gmail.com>
	<CAGN7qDB2M7r9AYyZavPo11NL7hRBXuNT+0SHdXe=OF8_kZK5iQ@mail.gmail.com>
	<CAPeKFTiVrKfzTZOCvshynH3yUyDePz+6ObJpjYGGvLOj_630CA@mail.gmail.com>
Message-ID: <CAGN7qDD03fR2NdYvsjLkXTqAWPWwYxLJgHAN475oCbFYcq9X1w@mail.gmail.com>

On Sat, Feb 23, 2013 at 2:59 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>>
>>
>> On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan <robert at ocallahan.org
>> > wrote:
>>
>>> I think Rik is convincing me that we shouldn't expose mozOpaque or any
>>> other explicit subpixel AA control to the Web. It will be very easy for Web
>>> authors to test it in one place and discover that it works without
>>> realizing that they're causing problems for some users.
>>>
>>> I think a fully automatic solution that tries to use subpixel AA but is
>>> always able to render grayscale AA if needed is the way to go. Possibly
>>> with an author hint to suggest opting into a more expensive rendering path.
>>
>>
> Here are the problems I see with that approach:
>
> 1)  In order to avoid a performance hit for existing content, it still
> requires a spec change (the hint)
>

What is the performance hit?


> 2)  Even with the hint, when the author knows they want LCD AA, they still
> incur a performance penalty of drawing to two buffers.
>

Why are there 2 buffers? You just draw on top of the existing content. It
is up to the author to ensure correct output.


> 3)  It still can't handle all cases, such as canvas -> WebGL, which will
> have to remain grayscale-only, even when the author knows it would be safe
> for their application.
>

That is OK. A UA is not required to implement this.


>
> Also, what form should this authoring hint take?  Is it going to
> explicitly call out LCD AA?  In that case, how is it better than an opt-in
> canvas attribute?  If it doesn't explicitly call out LCD AA, but that's the
> only effect it has, what should it be called?
>
> I also have concerns that the knowledge of when it's safe to use the LCD
> AA buffer is going to spread throughout the browser codebase, even in areas
> which currently have no knowledge of canvas, in order to handle all the
> special cases.  This may just be an implementation detail (and may be
> avoidable, this is TBD), but it does have the potential to introduce
> dependencies or complicate implementation.
>
>
>>>
>> Great! I think matteColor (or matteStyle to be more consistent) can
>> easily be implemented. We can optimize rendering later.
>>
>
>> So, if a mattecolor is set the UA can assume that:
>>
>
> Maybe I'm missing something, but if we're going down the automatic road,
> why do we need a new function/attribute?  Why not simply detect when a
> canvas-sized fillRect() has been performed with an opaque fillStyle?  This
> would also allow optimization of existing content.
>
> Stephen
>
> - all compositing operation within the canvas can ignore background alpha
>> - the canvas can be copied directly to the screen (unless another effect
>> is applied to the canvas element or its ancestor)
>>
>> If mattecolor is set, the UA should matte with that color. If a
>> compositing operation (that introduces alpha) is used, the matte operation
>> needs to be repeated.
>>
>
I experimented with adding MatteStyle  for Core Graphics in mozilla and
webkit and got the basics of it working.
So, it's definitely possible to add to the browsers.

From robert at ocallahan.org  Sat Feb 23 03:48:45 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Sun, 24 Feb 2013 00:48:45 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTiVrKfzTZOCvshynH3yUyDePz+6ObJpjYGGvLOj_630CA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
	<CAOp6jLaH=g6gYmKYDiM1uNLzatMo=0D6uQ8aBhUkeCJNyH_9Yg@mail.gmail.com>
	<CAGN7qDB2M7r9AYyZavPo11NL7hRBXuNT+0SHdXe=OF8_kZK5iQ@mail.gmail.com>
	<CAPeKFTiVrKfzTZOCvshynH3yUyDePz+6ObJpjYGGvLOj_630CA@mail.gmail.com>
Message-ID: <CAOp6jLaQjFBH_42vXrvzJz5XG0N4Dm7tw4gvaL-5tUVo38POzg@mail.gmail.com>

On Sat, Feb 23, 2013 at 4:59 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan <robert at ocallahan.org
>> > wrote:
>>
>>> I think a fully automatic solution that tries to use subpixel AA but is
>>> always able to render grayscale AA if needed is the way to go. Possibly
>>> with an author hint to suggest opting into a more expensive rendering path.
>>
>>
> Here are the problems I see with that approach:
>
> 1)  In order to avoid a performance hit for existing content, it still
> requires a spec change (the hint)
> 2)  Even with the hint, when the author knows they want LCD AA, they still
> incur a performance penalty of drawing to two buffers.
> 3)  It still can't handle all cases, such as canvas -> WebGL, which will
> have to remain grayscale-only, even when the author knows it would be safe
> for their application.
>

I agree those are problems. All of the available options have problems.

Also, what form should this authoring hint take?  Is it going to explicitly
> call out LCD AA?  In that case, how is it better than an opt-in canvas
> attribute?  If it doesn't explicitly call out LCD AA, but that's the only
> effect it has, what should it be called?
>

Perhaps we could use "text-rendering:optimizeLegibility" on the canvas
element.

I also have concerns that the knowledge of when it's safe to use the LCD AA
> buffer is going to spread throughout the browser codebase, even in areas
> which currently have no knowledge of canvas, in order to handle all the
> special cases.  This may just be an implementation detail (and may be
> avoidable, this is TBD), but it does have the potential to introduce
> dependencies or complicate implementation.
>

Maybe.

Maybe I'm missing something, but if we're going down the automatic road,
> why do we need a new function/attribute?  Why not simply detect when a
> canvas-sized fillRect() has been performed with an opaque fillStyle?  This
> would also allow optimization of existing content.


I agree.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]

From faulkner.steve at gmail.com  Sat Feb 23 05:41:22 2013
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Sat, 23 Feb 2013 13:41:22 +0000
Subject: [whatwg] Main element - Rationale? use cases? and data?
Message-ID: <72D15240-63D1-47D7-9F3D-F415B4BF4EC6@gmail.com>

Is there any rationale, uses cases or data available that supports the current definition of the <main> element in the WHATWG spec? In particular the author conformance requirements and advice.

I looked around but couldn't find any. 

Regards 

SteveF

From annevk at annevk.nl  Sun Feb 24 10:32:56 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Sun, 24 Feb 2013 18:32:56 +0000
Subject: [whatwg] Fetch: cross-origin redirect to a data URL
Message-ID: <CADnb78hZqcvdazTLzTAFGWZUHviucnZ4O648vk7eT0nO2Fz7SA@mail.gmail.com>

Say <img> does a cross-origin request. The response to that request is
a redirect with the appropriate CORS headers set. The new location is
a data URL. Should that URL be tainted or not? I tend to think we
should make that work.

(By the way, if you're interested. I'm working on a new specification
that merges HTML fetch and CORS, named Fetch.
http://wiki.whatwg.org/wiki/Fetch has the rough outline so far,
including an algorithm at the bottom. The idea is that everything in
the platform that does network requests ties into that (in particular
the fetch function which dispatches as appropriate).)


-- 
http://annevankesteren.nl/

From w3c at adambarth.com  Sun Feb 24 20:30:30 2013
From: w3c at adambarth.com (Adam Barth)
Date: Sun, 24 Feb 2013 20:30:30 -0800
Subject: [whatwg] Fetch: cross-origin redirect to a data URL
In-Reply-To: <CADnb78hZqcvdazTLzTAFGWZUHviucnZ4O648vk7eT0nO2Fz7SA@mail.gmail.com>
References: <CADnb78hZqcvdazTLzTAFGWZUHviucnZ4O648vk7eT0nO2Fz7SA@mail.gmail.com>
Message-ID: <CAJE5ia-tNs1_VOcCLqHbkDuFUH3kWbiBgTh-_6O_acfZwS1wcg@mail.gmail.com>

I don't think there is a security problem with that.  It's just a
question of how much it complicates the model.

Adam


On Sun, Feb 24, 2013 at 10:32 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> Say <img> does a cross-origin request. The response to that request is
> a redirect with the appropriate CORS headers set. The new location is
> a data URL. Should that URL be tainted or not? I tend to think we
> should make that work.
>
> (By the way, if you're interested. I'm working on a new specification
> that merges HTML fetch and CORS, named Fetch.
> http://wiki.whatwg.org/wiki/Fetch has the rough outline so far,
> including an algorithm at the bottom. The idea is that everything in
> the platform that does network requests ties into that (in particular
> the fetch function which dispatches as appropriate).)
>
>
> --
> http://annevankesteren.nl/

From bruant.d at gmail.com  Mon Feb 25 00:41:23 2013
From: bruant.d at gmail.com (David Bruant)
Date: Mon, 25 Feb 2013 09:41:23 +0100
Subject: [whatwg] Cross-origin iframe and @sandbox=allow-same-origin
Message-ID: <512B23B3.10203@gmail.com>

Hi,

The current description of the allow-same-origin sandbox token in the 
spec is:
" The allow-same-origin keyword allows the content to be treated as 
being from the same origin instead of forcing it into a unique origin;"

This is a very scary wording. Understood naively, I understand I could 
host a page in the "davidbruant.github.com" domain with an iframe to 
anywhere (pick your favorite social network/email client website), add 
@sandbox="allow-same-origin" and suddenly, I'd be able to look at the 
content (since the iframe would be treated as being from the same origin).

Obviously, that's not how it works (I say "obviously", because browser 
vendors would have not implemented what I just described. If they had, 
the world might have collapsed quickly).
 From what I've tested both in Firefox and Chrome, when I have an iframe 
from a different domain, I can get the contentDocument, but it looks 
like about:blank from what I can observe in the container. Where is this 
behavior described?


Also, in some notes [1], I can read:
"Second, [allow-same-origin] can be used to embed content from a 
third-party site, sandboxed to prevent that site from opening pop-up 
windows, etc, without preventing the embedded page from communicating 
back to its originating site, using the database APIs to store data, etc."

I fail to understand what is specific about allow-same-origin that 
allows that without adding also allow-scripts or allow-forms.


As a more general question: does iframe at sandbox="allow-same-origin" make 
a page and a cross-origin iframe further connected than they are 
currently without the keyword?

Thanks,

David

[1] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#attr-iframe-sandbox-allow-same-origin

From annevk at annevk.nl  Mon Feb 25 01:49:29 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Mon, 25 Feb 2013 09:49:29 +0000
Subject: [whatwg] Fetch: cross-origin redirect to a data URL
In-Reply-To: <CAJE5ia-tNs1_VOcCLqHbkDuFUH3kWbiBgTh-_6O_acfZwS1wcg@mail.gmail.com>
References: <CADnb78hZqcvdazTLzTAFGWZUHviucnZ4O648vk7eT0nO2Fz7SA@mail.gmail.com>
	<CAJE5ia-tNs1_VOcCLqHbkDuFUH3kWbiBgTh-_6O_acfZwS1wcg@mail.gmail.com>
Message-ID: <CADnb78iXvHc_t=SykfR-rU9cwEsuMq7ZrAFJ77TvUq71yb24ig@mail.gmail.com>

On Mon, Feb 25, 2013 at 4:30 AM, Adam Barth <w3c at adambarth.com> wrote:
> I don't think there is a security problem with that.  It's just a
> question of how much it complicates the model.

Well currently for http://software.hixie.ch/utilities/cgi/data/data
Chrome generates a network error if you hit "Generate" with the reason
"unsafe redirect". And that's a simple http to data URL redirect
without CORS coming into play.


-- 
http://annevankesteren.nl/

From jmajnert at gmail.com  Mon Feb 25 02:13:36 2013
From: jmajnert at gmail.com (Janusz Majnert)
Date: Mon, 25 Feb 2013 11:13:36 +0100
Subject: [whatwg] Cross-origin iframe and @sandbox=allow-same-origin
In-Reply-To: <512B23B3.10203@gmail.com>
References: <512B23B3.10203@gmail.com>
Message-ID: <CAOeF0ew9PWtTgE-HHMKax7aYvG19o9SAwuwapXyVYTqQq3jibA@mail.gmail.com>

Hi,
>From what I understand, it goes like this:
Using the sandboxing flag on an iframe causes several fine-grained
flags to be set (point 3 of the algorithm). One of the flags -
"sandboxed origin browsing context flag"[1] forces the document into
unique origin and blocks access to document.cookie and localStorage.
This flag is set unless "allow-same-origin" is used.

So in effect, using "allow-same-origin" on an iframe containing
third-party site will sandbox it but will still allow it to use its
own document.cookie and localStorage, without giving any access to
parent browsing context. The other fine-grained sandboxing flags will
block it. In the example you gave, the "sandboxed navigation browsing
context flag"[2] would kick in and prevent this behaviour.


Regards,
Janusz Majnert


[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#sandboxed-origin-browsing-context-flag
[2] http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#sandboxed-navigation-browsing-context-flag



2013/2/25 David Bruant <bruant.d at gmail.com>:
> Hi,
>
> The current description of the allow-same-origin sandbox token in the spec
> is:
> " The allow-same-origin keyword allows the content to be treated as being
> from the same origin instead of forcing it into a unique origin;"
>
> This is a very scary wording. Understood naively, I understand I could host
> a page in the "davidbruant.github.com" domain with an iframe to anywhere
> (pick your favorite social network/email client website), add
> @sandbox="allow-same-origin" and suddenly, I'd be able to look at the
> content (since the iframe would be treated as being from the same origin).
>
> Obviously, that's not how it works (I say "obviously", because browser
> vendors would have not implemented what I just described. If they had, the
> world might have collapsed quickly).
> From what I've tested both in Firefox and Chrome, when I have an iframe from
> a different domain, I can get the contentDocument, but it looks like
> about:blank from what I can observe in the container. Where is this behavior
> described?
>
>
> Also, in some notes [1], I can read:
> "Second, [allow-same-origin] can be used to embed content from a third-party
> site, sandboxed to prevent that site from opening pop-up windows, etc,
> without preventing the embedded page from communicating back to its
> originating site, using the database APIs to store data, etc."
>
> I fail to understand what is specific about allow-same-origin that allows
> that without adding also allow-scripts or allow-forms.
>
>
> As a more general question: does iframe at sandbox="allow-same-origin" make a
> page and a cross-origin iframe further connected than they are currently
> without the keyword?
>
> Thanks,
>
> David
>
> [1]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#attr-iframe-sandbox-allow-same-origin

From ian at hixie.ch  Mon Feb 25 10:10:32 2013
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 25 Feb 2013 18:10:32 +0000 (UTC)
Subject: [whatwg] Cross-origin iframe and @sandbox=allow-same-origin
In-Reply-To: <512B23B3.10203@gmail.com>
References: <512B23B3.10203@gmail.com>
Message-ID: <Pine.LNX.4.64.1302251805110.15713@ps20323.dreamhostps.com>

On Mon, 25 Feb 2013, David Bruant wrote:
> 
> The current description of the allow-same-origin sandbox token in the 
> spec is: " The allow-same-origin keyword allows the content to be 
> treated as being from the same origin instead of forcing it into a 
> unique origin;"
> 
> This is a very scary wording.

True. Note though that it's non-normative, so it doesn't affect 
implementors at all. (There's no "MUST" requirement and no "IS" 
definition, so it's just describing what's going on, not requiring 
anything or defining anything.)

I've made the wording less scary though.


> Also, in some notes [1], I can read:
> "Second, [allow-same-origin] can be used to embed content from a third-party
> site, sandboxed to prevent that site from opening pop-up windows, etc, without
> preventing the embedded page from communicating back to its originating site,
> using the database APIs to store data, etc."
> 
> I fail to understand what is specific about allow-same-origin that 
> allows that without adding also allow-scripts or allow-forms.

If you don't have allow-same-origin, the content ends up in a unique 
origin, not its "real" origin.


> As a more general question: does iframe at sandbox="allow-same-origin" make a
> page and a cross-origin iframe further connected than they are currently
> without the keyword?

The only difference is that without the keyword, the content is in a 
unique origin, and with it, its origin is left as normal.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From bruant.d at gmail.com  Mon Feb 25 10:26:28 2013
From: bruant.d at gmail.com (David Bruant)
Date: Mon, 25 Feb 2013 19:26:28 +0100
Subject: [whatwg] Cross-origin iframe and @sandbox=allow-same-origin
In-Reply-To: <Pine.LNX.4.64.1302251805110.15713@ps20323.dreamhostps.com>
References: <512B23B3.10203@gmail.com>
	<Pine.LNX.4.64.1302251805110.15713@ps20323.dreamhostps.com>
Message-ID: <512BACD4.9020907@gmail.com>

Le 25/02/2013 19:10, Ian Hickson a ?crit :
> On Mon, 25 Feb 2013, David Bruant wrote:
>> As a more general question: does iframe at sandbox="allow-same-origin" make a
>> page and a cross-origin iframe further connected than they are currently
>> without the keyword?
> The only difference is that without the keyword, the content is in a
> unique origin, and with it, its origin is left as normal.
Oh ok. "same origin" means "the content keeps the same (its own) 
origin". I had originally understood "the parent and iframe behave as if 
they were from the same origin", hence my confusion.

Everything makes a lot more sense now.

Thanks,

David

From w3c at adambarth.com  Mon Feb 25 12:00:21 2013
From: w3c at adambarth.com (Adam Barth)
Date: Mon, 25 Feb 2013 12:00:21 -0800
Subject: [whatwg] Fetch: cross-origin redirect to a data URL
In-Reply-To: <CADnb78iXvHc_t=SykfR-rU9cwEsuMq7ZrAFJ77TvUq71yb24ig@mail.gmail.com>
References: <CADnb78hZqcvdazTLzTAFGWZUHviucnZ4O648vk7eT0nO2Fz7SA@mail.gmail.com>
	<CAJE5ia-tNs1_VOcCLqHbkDuFUH3kWbiBgTh-_6O_acfZwS1wcg@mail.gmail.com>
	<CADnb78iXvHc_t=SykfR-rU9cwEsuMq7ZrAFJ77TvUq71yb24ig@mail.gmail.com>
Message-ID: <CAJE5ia9xRQDCCVc8ZPV-JjKR+=jtrOt9F+a8ud5=_z5dj1LuRA@mail.gmail.com>

On Mon, Feb 25, 2013 at 1:49 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Mon, Feb 25, 2013 at 4:30 AM, Adam Barth <w3c at adambarth.com> wrote:
>> I don't think there is a security problem with that.  It's just a
>> question of how much it complicates the model.
>
> Well currently for http://software.hixie.ch/utilities/cgi/data/data
> Chrome generates a network error if you hit "Generate" with the reason
> "unsafe redirect". And that's a simple http to data URL redirect
> without CORS coming into play.

Yes, that's to defend against a different sort of attack.  In some
browsers, like Firefox, data URLs inherit the security context of
their authors.  If a web site as an open redirect, an attacker might
be able to trick the site into redirecting to a data URL of the
attackers choice and thereby XSS the site.

Chrome wouldn't be vulnerable to that attack because Chrome runs data
URLs in unique origins, but Chrome blocks those sorts of redirects so
that web sites don't use them and don't cause trouble for Firefox.

Adam

From bzbarsky at MIT.EDU  Mon Feb 25 12:06:36 2013
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 25 Feb 2013 15:06:36 -0500
Subject: [whatwg] Fetch: cross-origin redirect to a data URL
In-Reply-To: <CAJE5ia9xRQDCCVc8ZPV-JjKR+=jtrOt9F+a8ud5=_z5dj1LuRA@mail.gmail.com>
References: <CADnb78hZqcvdazTLzTAFGWZUHviucnZ4O648vk7eT0nO2Fz7SA@mail.gmail.com>
	<CAJE5ia-tNs1_VOcCLqHbkDuFUH3kWbiBgTh-_6O_acfZwS1wcg@mail.gmail.com>
	<CADnb78iXvHc_t=SykfR-rU9cwEsuMq7ZrAFJ77TvUq71yb24ig@mail.gmail.com>
	<CAJE5ia9xRQDCCVc8ZPV-JjKR+=jtrOt9F+a8ud5=_z5dj1LuRA@mail.gmail.com>
Message-ID: <512BC44C.3000408@mit.edu>

On 2/25/13 3:00 PM, Adam Barth wrote:
> Yes, that's to defend against a different sort of attack.  In some
> browsers, like Firefox, data URLs inherit the security context of
> their authors.

This is not the case for data: URLs that are the target of a redirect, 
for what it's worth.  At least in Firefox, last I checked.

The only argument I've seen for Chrome's behavior is in 
https://bugzilla.mozilla.org/show_bug.cgi?id=786275

-Boris


From annevk at annevk.nl  Tue Feb 26 03:35:35 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Tue, 26 Feb 2013 11:35:35 +0000
Subject: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest
Message-ID: <CADnb78hXku4Ay5qJ1sJoLbA42jmUHBBFLt4=MbHytVXMMS21ng@mail.gmail.com>

There's an unfortunate mismatch currently. new
XMLHttpRequest({anon:true}) will generate a request where a) origin is
a globally unique identifier b) referrer source is the URL
about:blank, and c) credentials are omitted. From those
crossorigin="anonymous" only does c. Can we still change
crossorigin="anonymous" to match the anonymous flag semantics of
XMLHttpRequest or is it too late?


-- 
http://annevankesteren.nl/

From cabanier at gmail.com  Tue Feb 26 09:03:13 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Tue, 26 Feb 2013 09:03:13 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
Message-ID: <CAGN7qDDh_+NZN+gsZb_CeBTcHkO6SineL5mq_DrJDRHnzd+ACg@mail.gmail.com>

FYI
http://www.istartedsomething.com/20120303/cleartype-takes-a-back-seat-for-windows-8-metro/
IE 10 removed subpixel positioning and just use regular AA.

On Thu, Feb 21, 2013 at 11:12 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Tue, Feb 19, 2013 at 11:31 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> So now we have:
>> - don't do this on pinch-zoom devices
>> - don't do this for HW accelerated canvases
>> - don't do this if the canvas dpi doesn't match the screen
>>
> - don't do this if there are transforms
>> - authors will have to be very careful when using this feature since it
>> can turn on or off or cause rendering glitches.
>>
>> Is it still worth pursuing this?
>>
>
> I believe it is.  Even with those constraints, there are a large number of
> applications which can benefit from text which looks as good as the native
> platform can provide.
>
> That said, I also think Robert is right that we should not spec out
> precisely when subpixel AA text will occur in any of these automatic modes,
> since:
>
> 1)  there are some platforms/devices which don't do LCD text at all
> 2)  It may be too restrictive for the browser implementor, e.g., they may
> be essentially required to implement deferred rendering or two backing
> stores in order to meet the resulting spec, which seems onerous
>
> Subpixel AA text aside, I still think it's worth spec'ing out mozOpaque,
> if only just for the optimization opportunities that we don't get with an
> automatic solution (e.g., putImageData).  Its implementation is fairly
> straightforward (much more so than the other options above), and it won't
> break any existing content.
>
> To me, the "it breaks compositing" argument falls into the "doctor, it
> hurts when I do this" category:  the user is specifically opting into an
> opaque backing store, and so the changes in behaviour for compositing modes
> which reference destination alpha are expected, just as they are when using
> DST_ALPHA blending modes in a WebGL context created with the "alpha"
> attribute set to false.
>
> Stephen
>
>
>>
>> On Tue, Feb 19, 2013 at 3:40 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>
>>> On Tue, Feb 19, 2013 at 5:19 PM, Stephen White <senorblanco at chromium.org
>>> > wrote:
>>>
>>>> Even with text on an opaque background, I think you still have to worry
>>>> about the case of transformed canvases.  E.g., text drawn over an opaque
>>>> background into a single still frame canvas, but then subsequently rotated
>>>> via CSS transforms from 0 degrees through non-0.  The first frame can use
>>>> subpixel AA, but then subsequent frames can't.  So I think you need to keep
>>>> the command stream around (first case) or
>>>> always render two buffers as soon as you draw text.  That seems like a
>>>> pretty heavy burden.
>>>>
>>>> For canvas->WebGL the problem becomes pretty much intractable, since
>>>> there's no way to know what a given shader will do to the pixels.  So I
>>>> think you'd always have to give up and do grayscale AA in that case.
>>>>
>>>
>>> Yes, you're quite right.
>>>
>>>
>>> Rob
>>> --
>>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>>
>>
>>
>

From derhoermi at gmx.net  Tue Feb 26 10:11:04 2013
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue, 26 Feb 2013 19:11:04 +0100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDDh_+NZN+gsZb_CeBTcHkO6SineL5mq_DrJDRHnzd+ACg@mail.gmail.com>
References: <CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
	<CAGN7qDDh_+NZN+gsZb_CeBTcHkO6SineL5mq_DrJDRHnzd+ACg@mail.gmail.com>
Message-ID: <g8upi89vgal65681n58dtpm0iv4uodks88@hive.bjoern.hoehrmann.de>

* Rik Cabanier wrote:
>FYI
>http://www.istartedsomething.com/20120303/cleartype-takes-a-back-seat-for-windows-8-metro/
>IE 10 removed subpixel positioning and just use regular AA.

The article seems to be about Windows 8 and neither it nor the comments
seem to discuss Internet Explorer 10 on Windows 7. Are you sure this is
a property of Internet Explorer 10 regardless of the Windows version,
and given that the article is a year old, that this is still current?
-- 
Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de
25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From cabanier at gmail.com  Tue Feb 26 12:48:26 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Tue, 26 Feb 2013 12:48:26 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <g8upi89vgal65681n58dtpm0iv4uodks88@hive.bjoern.hoehrmann.de>
References: <CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
	<CAGN7qDDh_+NZN+gsZb_CeBTcHkO6SineL5mq_DrJDRHnzd+ACg@mail.gmail.com>
	<g8upi89vgal65681n58dtpm0iv4uodks88@hive.bjoern.hoehrmann.de>
Message-ID: <CAGN7qDDtf5gTsj+HWt2FcYVHLzWb+rq-m_k_hUSr6t=BW-2xVg@mail.gmail.com>

I experimented a bit and t is still active on Windows 7.

On Tue, Feb 26, 2013 at 10:11 AM, Bjoern Hoehrmann <derhoermi at gmx.net>wrote:

> * Rik Cabanier wrote:
> >FYI
> >
> http://www.istartedsomething.com/20120303/cleartype-takes-a-back-seat-for-windows-8-metro/
> >IE 10 removed subpixel positioning and just use regular AA.
>
> The article seems to be about Windows 8 and neither it nor the comments
> seem to discuss Internet Explorer 10 on Windows 7. Are you sure this is
> a property of Internet Explorer 10 regardless of the Windows version,
> and given that the article is a year old, that this is still current?
> --
> Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
> Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de
> 25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/
>

From w3c at adambarth.com  Tue Feb 26 14:52:28 2013
From: w3c at adambarth.com (Adam Barth)
Date: Tue, 26 Feb 2013 14:52:28 -0800
Subject: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest
In-Reply-To: <CADnb78hXku4Ay5qJ1sJoLbA42jmUHBBFLt4=MbHytVXMMS21ng@mail.gmail.com>
References: <CADnb78hXku4Ay5qJ1sJoLbA42jmUHBBFLt4=MbHytVXMMS21ng@mail.gmail.com>
Message-ID: <CAJE5ia9_=cQsL5PP+r2Aq4-5gcjvs77Z+=ZLL4cbCNOgHsJ8ew@mail.gmail.com>

WebKit hasn't implemented either, so we don't have any implementation
constraints in this area.

Adam


On Tue, Feb 26, 2013 at 3:35 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> There's an unfortunate mismatch currently. new
> XMLHttpRequest({anon:true}) will generate a request where a) origin is
> a globally unique identifier b) referrer source is the URL
> about:blank, and c) credentials are omitted. From those
> crossorigin="anonymous" only does c. Can we still change
> crossorigin="anonymous" to match the anonymous flag semantics of
> XMLHttpRequest or is it too late?
>
>
> --
> http://annevankesteren.nl/

From kbr at google.com  Tue Feb 26 16:02:05 2013
From: kbr at google.com (Kenneth Russell)
Date: Tue, 26 Feb 2013 16:02:05 -0800
Subject: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest
In-Reply-To: <CAJE5ia9_=cQsL5PP+r2Aq4-5gcjvs77Z+=ZLL4cbCNOgHsJ8ew@mail.gmail.com>
References: <CADnb78hXku4Ay5qJ1sJoLbA42jmUHBBFLt4=MbHytVXMMS21ng@mail.gmail.com>
	<CAJE5ia9_=cQsL5PP+r2Aq4-5gcjvs77Z+=ZLL4cbCNOgHsJ8ew@mail.gmail.com>
Message-ID: <CAMYvS2c_54Lq_nLwDKnkLWnPoRFxaQ2LvKE8i_Q=Zi6PLwdCjQ@mail.gmail.com>

Are you referring to the crossOrigin attribute on HTMLImageElement and
HTMLMediaElement? Those are implemented in WebKit. It should be fine
to change crossOrigin="anonymous" requests to satisfy (a) and (b). Any
server that satisfies these anonymous requests in a way compatible
with UAs' caching will ignore the incoming origin and the referrer.

-Ken


On Tue, Feb 26, 2013 at 2:52 PM, Adam Barth <w3c at adambarth.com> wrote:
> WebKit hasn't implemented either, so we don't have any implementation
> constraints in this area.
>
> Adam
>
>
> On Tue, Feb 26, 2013 at 3:35 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
>> There's an unfortunate mismatch currently. new
>> XMLHttpRequest({anon:true}) will generate a request where a) origin is
>> a globally unique identifier b) referrer source is the URL
>> about:blank, and c) credentials are omitted. From those
>> crossorigin="anonymous" only does c. Can we still change
>> crossorigin="anonymous" to match the anonymous flag semantics of
>> XMLHttpRequest or is it too late?
>>
>>
>> --
>> http://annevankesteren.nl/

From w3c at adambarth.com  Tue Feb 26 16:10:34 2013
From: w3c at adambarth.com (Adam Barth)
Date: Tue, 26 Feb 2013 16:10:34 -0800
Subject: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest
In-Reply-To: <CAMYvS2c_54Lq_nLwDKnkLWnPoRFxaQ2LvKE8i_Q=Zi6PLwdCjQ@mail.gmail.com>
References: <CADnb78hXku4Ay5qJ1sJoLbA42jmUHBBFLt4=MbHytVXMMS21ng@mail.gmail.com>
	<CAJE5ia9_=cQsL5PP+r2Aq4-5gcjvs77Z+=ZLL4cbCNOgHsJ8ew@mail.gmail.com>
	<CAMYvS2c_54Lq_nLwDKnkLWnPoRFxaQ2LvKE8i_Q=Zi6PLwdCjQ@mail.gmail.com>
Message-ID: <CAJE5ia-n=s1ccBpJR++Yb7OaA=9+AbDDH+O9ho+92ThU8bvnGQ@mail.gmail.com>

Ah, my mistake.  Kenneth is right.  I didn't realize you were talking
about the crossorigin attributes.

Adam


On Tue, Feb 26, 2013 at 4:02 PM, Kenneth Russell <kbr at google.com> wrote:
> Are you referring to the crossOrigin attribute on HTMLImageElement and
> HTMLMediaElement? Those are implemented in WebKit. It should be fine
> to change crossOrigin="anonymous" requests to satisfy (a) and (b). Any
> server that satisfies these anonymous requests in a way compatible
> with UAs' caching will ignore the incoming origin and the referrer.
>
> -Ken
>
>
> On Tue, Feb 26, 2013 at 2:52 PM, Adam Barth <w3c at adambarth.com> wrote:
>> WebKit hasn't implemented either, so we don't have any implementation
>> constraints in this area.
>>
>> Adam
>>
>>
>> On Tue, Feb 26, 2013 at 3:35 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
>>> There's an unfortunate mismatch currently. new
>>> XMLHttpRequest({anon:true}) will generate a request where a) origin is
>>> a globally unique identifier b) referrer source is the URL
>>> about:blank, and c) credentials are omitted. From those
>>> crossorigin="anonymous" only does c. Can we still change
>>> crossorigin="anonymous" to match the anonymous flag semantics of
>>> XMLHttpRequest or is it too late?
>>>
>>>
>>> --
>>> http://annevankesteren.nl/

From adamk at chromium.org  Wed Feb 27 12:39:04 2013
From: adamk at chromium.org (Adam Klein)
Date: Wed, 27 Feb 2013 12:39:04 -0800
Subject: [whatwg] HTML parsing, the stack of open elements,
	and foreign content
Message-ID: <CAEvLGcLVj+KfQ04kOCysdMBYL5fdMh2xJ7-qcLFdrsbsshnkfQ@mail.gmail.com>

Consider the following script:

tr = document.createElement('tr')
tr.innerHTML = '<math><tr><mo><td>';

That is, the fragment is parsed with tr as the context element. What
should the generated DOM be? Note that <mo> is a "MathML text
integration point", which causes the <td> to be processed not as
foreign content but as a normal HTML token. This leads to the
following DOM in WebKit:

<tr>
    <math math>
        <math tr>
            <math mo>
    <td>

(the "math" prefixes denote that these are elements with the MathML
namespace.) In Gecko, I instead get:

<tr>
    <math math>
        <math tr>
            <math mo>
            <td>

Note that the <td> in both cases is an HTML element, even though in
Gecko it's in a MathML tree.

The spec for what should happen to that <td> is the first step of
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-intr

This case clearly seems like a bug in Gecko: it's treating the <math
tr> as if it's an HTML <tr>. That is, it's comparing only the local
name (or "tag name" as the spec usually refers to it).

But this same ambiguity exists elsewhere in the spec. For example, the
very next item under "in row" says "If the stack of open elements does
not have an element in table scope with the same tag name as the
token" (in this case, it's looking for a <tr>).

I think the HTML parser ought to specify more precisely how to deal
with namespaces in the stack of open elements, given that that stack
can contain elements of varying namespaces.

- Adam

From annevk at annevk.nl  Thu Feb 28 08:33:57 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Thu, 28 Feb 2013 16:33:57 +0000
Subject: [whatwg] Fetch: cross-origin redirect to a data URL
In-Reply-To: <512BC44C.3000408@mit.edu>
References: <CADnb78hZqcvdazTLzTAFGWZUHviucnZ4O648vk7eT0nO2Fz7SA@mail.gmail.com>
	<CAJE5ia-tNs1_VOcCLqHbkDuFUH3kWbiBgTh-_6O_acfZwS1wcg@mail.gmail.com>
	<CADnb78iXvHc_t=SykfR-rU9cwEsuMq7ZrAFJ77TvUq71yb24ig@mail.gmail.com>
	<CAJE5ia9xRQDCCVc8ZPV-JjKR+=jtrOt9F+a8ud5=_z5dj1LuRA@mail.gmail.com>
	<512BC44C.3000408@mit.edu>
Message-ID: <CADnb78jhON72NBksHNxncAxVwtCmD0Ojp-eVqOoXeBMUJHWb=w@mail.gmail.com>

On Mon, Feb 25, 2013 at 8:06 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 2/25/13 3:00 PM, Adam Barth wrote:
>> Yes, that's to defend against a different sort of attack.  In some
>> browsers, like Firefox, data URLs inherit the security context of
>> their authors.
>
> This is not the case for data: URLs that are the target of a redirect, for
> what it's worth.  At least in Firefox, last I checked.

Does it matter if it's a same-origin redirect though? It seems then it
should be okay (given there's no cross-origin URL in the redirect
chain).


> The only argument I've seen for Chrome's behavior is in
> https://bugzilla.mozilla.org/show_bug.cgi?id=786275

That seems to argue for even stricter rules. Basically stopping
navigation to data URLs.


-- 
http://annevankesteren.nl/

From annevk at annevk.nl  Thu Feb 28 10:54:36 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Thu, 28 Feb 2013 18:54:36 +0000
Subject: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest
In-Reply-To: <CAMYvS2c_54Lq_nLwDKnkLWnPoRFxaQ2LvKE8i_Q=Zi6PLwdCjQ@mail.gmail.com>
References: <CADnb78hXku4Ay5qJ1sJoLbA42jmUHBBFLt4=MbHytVXMMS21ng@mail.gmail.com>
	<CAJE5ia9_=cQsL5PP+r2Aq4-5gcjvs77Z+=ZLL4cbCNOgHsJ8ew@mail.gmail.com>
	<CAMYvS2c_54Lq_nLwDKnkLWnPoRFxaQ2LvKE8i_Q=Zi6PLwdCjQ@mail.gmail.com>
Message-ID: <CADnb78gxQn8a_La6rQYVWTd59-vpyYNBW3U=omHufMyRxEGQHQ@mail.gmail.com>

On Wed, Feb 27, 2013 at 12:02 AM, Kenneth Russell <kbr at google.com> wrote:
> Are you referring to the crossOrigin attribute on HTMLImageElement and
> HTMLMediaElement? Those are implemented in WebKit. It should be fine
> to change crossOrigin="anonymous" requests to satisfy (a) and (b). Any
> server that satisfies these anonymous requests in a way compatible
> with UAs' caching will ignore the incoming origin and the referrer.

Cool, hopefully we can make that change then. That would at least keep
the naming and semantics somewhat consistent.


-- 
http://annevankesteren.nl/

From odinho at opera.com  Fri Feb  1 02:19:32 2013
From: odinho at opera.com (=?utf-8?Q?Odin_H=C3=B8rthe_Omdal?=)
Date: Fri, 01 Feb 2013 11:19:32 +0100
Subject: [whatwg] IRC and WWW integration proposal
In-Reply-To: <20130201074159.4079f494@desudesudesu>
References: <20130201142600.dea98ee7b58e2637550be2c4@gmail.com>
	<20130201052458.269aac46@desudesudesu>
	<20130201150126.16a706397a491368142a8815@gmail.com>
	<20130201055511.332ca0b8@desudesudesu>
	<CAKDHDYn5NREvNDZRdNFOnu4NeYdF73fnoW2Sr9-3ZQHw2Qra0Q@mail.gmail.com>
	<20130201074159.4079f494@desudesudesu>
Message-ID: <op.wrtoaujr49xobu@odinho-fido>

On Fri, 01 Feb 2013 07:41:59 +0100, Nils Dagsson Moskopp  
<nils at dieweltistgarnichtso.net> wrote:

> Shane Allen <shane at snoonet.org> schrieb am Thu, 31 Jan 2013 23:40:11
> -0600:
>
>> > A protocol attribute for <link> elements would be totally hilarious.
>> Not if the device is a tablet, or a phone running a browser that
>> supports it. Need support from a page/article or even a project? Hit
>> a button, and if the protocol is implemented, you're in the IRC
>> channel able to garnish that support instantly.
> We probably misunderstood each other. Protocols are mentioned at the
> beginning of a URL; having a protocol attribute on a <link> element
> would therefore be redundant.

To illustrate:

   <link rel=chat protocol=irc href=irc://irc.freenode.com/whatwg>

Instead of:

   <link rel=chat href=irc://irc.freenode.com/whatwg>

Or a more fitting example of how it could be used:

   <a href="http://whatwg.org" protocol="http">WHATWG</a>

But, what happens now?

   <a href="http://whatwg.org" protocol="mailto">WHATWG</a>



Hilarious :-)

-- 
Odin H?rthe Omdal (Velmont/odinho) ? Core, Opera Software, http://opera.com


From glenn at zewt.org  Fri Feb  1 07:39:53 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 1 Feb 2013 09:39:53 -0600
Subject: [whatwg] Why do we have <input type='month'> and <input
	type='week'>?
In-Reply-To: <op.wrry8kurh8on37@bruce-pc>
References: <510988C1.1040900@lamouri.fr>
	<op.wrry8kurh8on37@bruce-pc>
Message-ID: <CABirCh_ua8cumCqZcASOTOdwCmsi0yPdVYvoRT23eBstszdy2A@mail.gmail.com>

On Thu, Jan 31, 2013 at 6:20 AM, Bruce Lawson <brucel at opera.com> wrote:

> The use-case for an input type I imagine is that a browser can have a
> select-like UI (Jan, Feb, March, April ...) which, in a French language
> browser becomes "Janvier, Fevrier, Mars, Avril .. " (or even Vend?miaire to
> Fructidor for FRC fans).
>

FYI, I would find this annoying.  CC expiry entry forms are typically
select boxes containing 01-12.  The text lines up with what's on my credit
card, so I don't have to translate "07" to "July" in my head when entering
it off of my card.  Any month picker for credit card expiry dates should
always have month numbers (of course, names *in addition* to numbers are
fine, though probably pointless).

-- 
Glenn Maynard


From mkwst at google.com  Sat Feb  2 10:11:23 2013
From: mkwst at google.com (Mike West)
Date: Sat, 2 Feb 2013 19:11:23 +0100
Subject: [whatwg] Sandboxed IFrames and downloads.
Message-ID: <CAKXHy=eHTuTehhaAsFdumu-Rr1sgJZfRMGKOfnYUKcEV+T3gSw@mail.gmail.com>

It's currently possible to force a download by serving a file with a
"Content-Disposition: attachment; filename=..." header. Notably, this
mechanism can be used to download a file with minimal user interaction by
including the resource to be downloaded in an IFrame. This holds even for
sandboxed IFrames, as demonstrated by
http://lcamtuf.coredump.cx/sandboxed.html (clicking that link will download
a file, fair warning).

It seems consistent with the general thought behind the `sandbox` attribute
that it should control downloads as well as the bits it already locks down.
I'd propose adjusting the spec to include a sandboxed downloads flag,
which, when present, would block all downloads from inside the frame (or,
perhaps only require user confirmation?). This restriction could be lifted
via an 'allow-downloads' keyword, if present in the sandbox attribute's
token list.

WDYT?

--
Mike West <mkwst at google.com>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 M?nchen, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91


From nathan.f77 at gmail.com  Mon Feb  4 14:09:07 2013
From: nathan.f77 at gmail.com (Nathan Broadbent)
Date: Tue, 5 Feb 2013 11:09:07 +1300
Subject: [whatwg] Proposal: Add window.getLastError (or modify invocation
 arguments of window.onerror)
Message-ID: <CAPXHQbNKO46DaDKamu=n5Z=ieYjVELxTcSZAJ1wDGdwBbGFzEA@mail.gmail.com>

Hi,

The current information passed to window.onerror rarely provides
sufficient information to find the cause of the error. The column
number argument will be a big step forward, but a stack trace would be
especially useful. I would like to add my support for improving the
window.onerror arguments, with a fifth argument for stack trace. Is
there anything that James or I could do to move this discussion along?


Best,
Nathan


> Alright... so what's next?  I'm assuming this needs further discussion with
> other WHATWG members chiming in.  If I can help, please let me know. I'd
> like to see this request through.
> Sincerely,
>     James Greene

On Fri, May 11, 2012 at 12:26 PM, Simon Pieters <simonp at opera.com> wrote:
> On Fri, 11 May 2012 17:14:00 +0200, James Greene <james.m.greene at gmail.com>
> wrote:
>
>  Simon:
>> Yeah, I misunderstood your previous mention of having it as a [fifth]
>> string argument.  I somehow associated that automatically with the
>> "message" parameter (the only string argument, I suppose) but I also
>> noticed my mistake after I sent the email.
>>
>
> OK.
>
>
>  I personally am interested in adding the stack trace, yes,
>>
>
> OK, thanks.
>
>
>  but ideally I
>> would just have access to the full "Error" object so I can always have an
>> up-to-date model if the "Error" object continues to change (as it probably
>> will).
>>
>
> That's fair enough. Though not all exceptions are Errors -- DOMException
> currently isn't, though I think some people want it to somehow inherit from
> Error.
>
>
>  For example, some devs may be interested in the "Error" object's
>> "name" property, which is already a part of the object today but is not
>> provided to "window.onerror" callbacks.  And again, if additional
>> properties are added in the future, it's just more and more properties
>> that
>> may need to get incrementally added to the "window.onerror" invocation
>> arguments list.  For example, I proposed the addition of an "innerError"
>> property (or some would call it "cause") for chaining errors and masking
>> internal errors that consumers shouldn't see, instead providing a
>> customer-facing message.
>>
>
> Yeah.
>
>
>  You keep mentioning compile errors and how they don't have associated
>> "Error" objects but it sounds like they still reach the "window.onerror"
>> callbacks.  Can you add a little commentary on that?
>>
>
> Here are some examples:
>
> <script> onerror = function(a,b,c) { alert(a+b+c) }; </script>
> <script> foo(); </script> <!-- "runtime" error; uncaught exception -->
> <script> for (;) </script> <!-- "compile" error; no exception, but onerror
> is invoked -->
> <script> setTimeout('for (;)', 0); </script> <!-- also compile error -->
> <img src="" onerror="for(;)"> <!-- also compile error -->
>
>
>
>  I thought they
>> utilized the "SyntaxError" class but perhaps that's only for "eval()"
>> calls...?
>>
>
> Yes. Since the script doesn't compile, the same script can't catch any
> exception in a try/catch block. onerror is just invoked with the
> appropriate arguments, and currently doesn't expose any object. Hence,
> compile errors currently do not expose any exception that Web pages can
> observe. However, if we change onerror and expose the exception object for
> uncaught exceptions, it would certainly make sense to specify that compile
> errors be exposed using SyntaxError exceptions.
>
> If we expose the exception object in onerror (which I actually think makes
> sense), what do we want to happen for cross-origin script errors? null? The
> current arguments are masked as ("Script error.", "", 0, 0).
>
>
>  I may also be thinking of this differently as a JS engineer
>> versus a browser vendor, so please help clue me in.  I'm interested to
>> learn more on this, and it may help me better appreciate why the
>> "window.onerror" callback mechanism *didn't* just pass an "Error" object
>> from the beginning.
>>
>
> I think onerror is an old feature dating back from old Netscape or IE
> (don't know which). Then other browsers just copied it.
>
>
>  I appreciate your continued feedback. Thanks!
>>
>
> cheers
>
> --
> Simon Pieters
> Opera Software
>


From dhtmlkitchen at gmail.com  Mon Feb  4 14:40:51 2013
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 4 Feb 2013 14:40:51 -0800
Subject: [whatwg] Proposal: Add window.getLastError (or modify
 invocation arguments of window.onerror)
In-Reply-To: <CAPXHQbNKO46DaDKamu=n5Z=ieYjVELxTcSZAJ1wDGdwBbGFzEA@mail.gmail.com>
References: <CAPXHQbNKO46DaDKamu=n5Z=ieYjVELxTcSZAJ1wDGdwBbGFzEA@mail.gmail.com>
Message-ID: <CABZUbM1CgRW_O=gZ_uPGuoGgqiwEqF8hwUB-g+XF32ocVSZXGQ@mail.gmail.com>

On 2/4/13, Nathan Broadbent <nathan.f77 at gmail.com> wrote:
> Hi,
>
Hi Nathan -

> The current information passed to window.onerror rarely provides
> sufficient information to find the cause of the error. The column
That's putting it mildly.

> number argument will be a big step forward, but a stack trace would be
> especially useful. I would like to add my support for improving the
> window.onerror arguments, with a fifth argument for stack trace. Is
> there anything that James or I could do to move this discussion along?

I'm not married to the idea of having it be stuck onto window.onerror.
There should be some way to get at the stack trace.

[whatwg] window.onerror -ancient feature needs upgrade
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-September/012552.html

| There needs to be a way to capture errors on the window.
|
| A method that passes an Error to the handler. One possible solution
| would be to leverage the existing event system:
|
| addEventListener( "error", genericErrorEventHandler, false );
|
| function genericErrorEventHandler( errorEvent ) {
| };

There's a number of bugs for global error stack info.

Bug 355430 - Stack information of uncaught Error object should be
available in window.onerror
https://bugzilla.mozilla.org/show_bug.cgi?id=355430

Bug 104408 - Summary: Add exception object and stack trace to window.onerror
https://bugs.webkit.org/show_bug.cgi?id=104408

| "The spec explicitly states that onerror gives you the
| error string, url, and line number.  We can't arbitrarily
| extends a spec as we see fit."

Bug 55092 - Stack information of uncaught Error object should be
available in window.onerror
https://bugs.webkit.org/show_bug.cgi?id=55092
"Is there anything else blocking this?"

https://bugs.webkit.org/show_bug.cgi?id=13646
(Apparently I "duplicated" that bug before the original, which came
four years later O_o (or "search first!")).


[...]

>>  but ideally I
>>> would just have access to the full "Error" object so I can always have
>>> an
>>> up-to-date model if the "Error" object continues to change (as it
>>> probably
>>> will).
>>>
I agree.

>>
>> That's fair enough. Though not all exceptions are Errors -- DOMException
>> currently isn't, though I think some people want it to somehow inherit
>> from
>> Error.
>>
Why not?

>>
>>  For example, some devs may be interested in the "Error" object's
>>> "name" property, which is already a part of the object today but is not
>>> provided to "window.onerror" callbacks.  And again, if additional
>>> properties are added in the future, it's just more and more properties
>>> that
>>> may need to get incrementally added to the "window.onerror" invocation
>>> arguments list.  For example, I proposed the addition of an "innerError"
>>> property (or some would call it "cause") for chaining errors and masking
>>> internal errors that consumers shouldn't see, instead providing a
>>> customer-facing message.
>>>
>>
>> Yeah.
>>
Yep. Pass an error object with a stack trace.



>>
>> Yes. Since the script doesn't compile, the same script can't catch any
>> exception in a try/catch block. onerror is just invoked with the
>> appropriate arguments, and currently doesn't expose any object. Hence,
>> compile errors currently do not expose any exception that Web pages can
>> observe. However, if we change onerror and expose the exception object
>> for
>> uncaught exceptions, it would certainly make sense to specify that
>> compile
>> errors be exposed using SyntaxError exceptions.
>>
Early errors?
www.ecma-international.org/ecma-262/5.1/#sec-16
-- 
Garrett
Twitter: @xkit
personx.tumblr.com


From oliver at apple.com  Mon Feb  4 14:44:37 2013
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 04 Feb 2013 14:44:37 -0800
Subject: [whatwg] Proposal: Add window.getLastError (or modify
 invocation arguments of window.onerror)
In-Reply-To: <CABZUbM1CgRW_O=gZ_uPGuoGgqiwEqF8hwUB-g+XF32ocVSZXGQ@mail.gmail.com>
References: <CAPXHQbNKO46DaDKamu=n5Z=ieYjVELxTcSZAJ1wDGdwBbGFzEA@mail.gmail.com>
	<CABZUbM1CgRW_O=gZ_uPGuoGgqiwEqF8hwUB-g+XF32ocVSZXGQ@mail.gmail.com>
Message-ID: <2A18872E-7F61-4470-A887-00CFEE9196AF@apple.com>


On Feb 4, 2013, at 2:40 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
>>> That's fair enough. Though not all exceptions are Errors -- DOMException
>>> currently isn't, though I think some people want it to somehow inherit
>>> from
>>> Error.
>>> 
> Why not?

That's something lost in the mists of time, however just asking it w.r.t DOMException misses the point that any value in js can be thrown - there's no requirement that it be an object, let alone a subtype of Error.

> 
>>> 
>>> For example, some devs may be interested in the "Error" object's
>>>> "name" property, which is already a part of the object today but is not
>>>> provided to "window.onerror" callbacks.  And again, if additional
>>>> properties are added in the future, it's just more and more properties
>>>> that
>>>> may need to get incrementally added to the "window.onerror" invocation
>>>> arguments list.  For example, I proposed the addition of an "innerError"
>>>> property (or some would call it "cause") for chaining errors and masking
>>>> internal errors that consumers shouldn't see, instead providing a
>>>> customer-facing message.
>>>> 
>>> 
>>> Yeah.
>>> 
> Yep. Pass an error object with a stack trace.

That's tricky - what is your "stack trace"?  You can very easily end up leaking private information across frames.

--Oliver


From esprehn at chromium.org  Mon Feb  4 23:20:27 2013
From: esprehn at chromium.org (Elliott Sprehn)
Date: Tue, 5 Feb 2013 02:20:27 -0500
Subject: [whatwg] Proposal: Add window.getLastError (or modify
 invocation arguments of window.onerror)
In-Reply-To: <2A18872E-7F61-4470-A887-00CFEE9196AF@apple.com>
References: <CAPXHQbNKO46DaDKamu=n5Z=ieYjVELxTcSZAJ1wDGdwBbGFzEA@mail.gmail.com>
	<CABZUbM1CgRW_O=gZ_uPGuoGgqiwEqF8hwUB-g+XF32ocVSZXGQ@mail.gmail.com>
	<2A18872E-7F61-4470-A887-00CFEE9196AF@apple.com>
Message-ID: <CAO9Q3iK0uq6yGjLLMfnpWSZnKpr+2scAbbSKcp3Our031on_+g@mail.gmail.com>

On Mon, Feb 4, 2013 at 5:44 PM, Oliver Hunt <oliver at apple.com> wrote:

> ...
> That's tricky - what is your "stack trace"?  You can very easily end up
> leaking private information across frames.
>
>
window.onerror is triggered across non-same origin frames?

- E


From cam at mcc.id.au  Tue Feb  5 22:41:04 2013
From: cam at mcc.id.au (Cameron McCormack)
Date: Wed, 06 Feb 2013 17:41:04 +1100
Subject: [whatwg] supporting HTMLElement.dataset on SVG elements
Message-ID: <5111FB00.6000907@mcc.id.au>

As part of aligning SVG with some not-so-HTML-specific features of HTML, 
the SVG WG would like to support data-* attributes on SVG elements.  In 
mixed HTML/SVG documents, it seems like you would want to be able to use 
these attributes regardless of whether the elements are HTML or SVG, or 
indeed MathML.

Does it make sense to move HTMLElement.dataset up to Element, so that 
all elements can benefit from it?  If not, could this attribute be split 
out on to a separate interface that we could have SVGElement implement?

(I'm also going to be looking at the other global attributes that HTML 
elements have to see if any make sense in SVG too.)

Thanks,

Cameron


From wang.tietao at outlook.com  Tue Feb  5 22:45:53 2013
From: wang.tietao at outlook.com (=?gb2312?B?zfXM+szX?=)
Date: Wed, 6 Feb 2013 14:45:53 +0800
Subject: [whatwg] A question about the drawimage() canvas function
Message-ID: <BLU002-W472F6B1FD8225099BAFE56EF070@phx.gbl>

Hi, there:
This is about the drawimage() canvas function in html5.
What should the following code ouput?
///////////////<html> <head>  <title>drawImage with an incorrect type for the image argument (part two)</title>  <style> canvas { display:none } </style>  <script>   window.onload = function(){    var r = document.getElementById('r');    ctx = document.getElementsByTagName('canvas')[0].getContext('2d');    var passed = false;    var message = "";    try{     ctx.drawImage((new Image()), 0, 0, 150, 150);     message = "No exception thrown"    }catch(e){      passed = e.code === e.INDEX_SIZE_ERR;      if (!passed) {message = "Got exception code " + e.code + " expected 1 (INDEX_SIZE_ERR)"}    }    r.textContent = passed ? "PASS" : "FAIL";    if (message) {r.textContent += " (" + message + ")"}   }  </script> </head> <body>  <p id="r">FAIL (Script did not run.)</p>  <canvas></canvas> </body></html>///////////////
In Chrome(24.0.1312.57) and Firefox(18.0.1), the output is:PASS
while in Opera(12.12) and IE(10.0.9200.16439) it is:FAIL (No exception thrown)

So, what should the result be? and what is the standard for this?
Thanks,-Tietao Wang 		 	   		  

From davidc at nag.co.uk  Wed Feb  6 02:56:43 2013
From: davidc at nag.co.uk (David Carlisle)
Date: Wed, 06 Feb 2013 10:56:43 +0000
Subject: [whatwg] supporting HTMLElement.dataset on SVG elements
In-Reply-To: <5111FB00.6000907@mcc.id.au>
References: <5111FB00.6000907@mcc.id.au>
Message-ID: <511236EB.8060304@nag.co.uk>

On 06/02/2013 06:41, Cameron McCormack wrote:
> As part of aligning SVG with some not-so-HTML-specific features of
> HTML, the SVG WG would like to support data-* attributes on SVG
> elements.  In mixed HTML/SVG documents, it seems like you would want
> to be able to use these attributes regardless of whether the elements
> are HTML or SVG, or indeed MathML.
>
> Does it make sense to move HTMLElement.dataset up to Element, so that
>  all elements can benefit from it?  If not, could this attribute be
> split out on to a separate interface that we could have SVGElement
> implement?
>
> (I'm also going to be looking at the other global attributes that
> HTML elements have to see if any make sense in SVG too.)
>
> Thanks,
>
> Cameron
>

I'm also in favour of making any reasonable global feature act the same
way across html/mathml/svg (hence the earlier request to move innerHTML
and friends up to Element so they apply to MathML).

David


________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________


From annevk at annevk.nl  Wed Feb  6 10:25:59 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Wed, 6 Feb 2013 18:25:59 +0000
Subject: [whatwg] supporting HTMLElement.dataset on SVG elements
In-Reply-To: <5111FB00.6000907@mcc.id.au>
References: <5111FB00.6000907@mcc.id.au>
Message-ID: <CADnb78hU_16CakFXh=zWJxz4i_mx5wC708dMEqk81Bq2JKAWVA@mail.gmail.com>

On Wed, Feb 6, 2013 at 6:41 AM, Cameron McCormack <cam at mcc.id.au> wrote:
> Does it make sense to move HTMLElement.dataset up to Element, so that all
> elements can benefit from it?  If not, could this attribute be split out on
> to a separate interface that we could have SVGElement implement?

Idea: just like the long term goal is to merge HTMLDocument into
Document (already done spec-wise), maybe the long term goal for
HTMLElement should be to become Element? This poops a bit on XML, but
certainly less than <template>.


-- 
http://annevankesteren.nl/


From dhtmlkitchen at gmail.com  Wed Feb  6 11:18:00 2013
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Wed, 6 Feb 2013 11:18:00 -0800
Subject: [whatwg] supporting HTMLElement.dataset on SVG elements
In-Reply-To: <5111FB00.6000907@mcc.id.au>
References: <5111FB00.6000907@mcc.id.au>
Message-ID: <CABZUbM3DhSsXNw+_Mvf-AexM8YjyexHsXMCJ9ht9O6SnQu_qaQ@mail.gmail.com>

On 2/5/13, Cameron McCormack <cam at mcc.id.au> wrote:
> As part of aligning SVG with some not-so-HTML-specific features of HTML,
> the SVG WG would like to support data-* attributes on SVG elements.  In
> mixed HTML/SVG documents, it seems like you would want to be able to use
> these attributes regardless of whether the elements are HTML or SVG, or
> indeed MathML.
>
> Does it make sense to move HTMLElement.dataset up to Element, so that
> all elements can benefit from it?  If not, could this attribute be split
> out on to a separate interface that we could have SVGElement implement?
>
What is the cost of extracting a common interface?

Are there any cases, existing or potential, where global attributes
might create conflict or make no sense?
http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#global-attributes

HTMLUnknownElement looks like it wants to fill the role of common
interface, but due to class hierarchy, it can't.
http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#htmlunknownelement

| interface must be used for HTML elements that are not
| defined by this specification (or other applicable specifications).

a new interface, such as UnknownElement or GenericElement could
accommodate shared features and avoid potential situations where those
features wouldn't make sense on a common Element superclass.
GenericElement could be implemented by HTMLElement and SVGElement and
all subclasses thereof including HTMLUnknownElement, plus whatever
they use in Math ML and whoever else wants to inherit from
GenericElement.
-- 
Garrett
Twitter: @xkit
personx.tumblr.com


From julian.viereck at googlemail.com  Thu Feb  7 00:38:09 2013
From: julian.viereck at googlemail.com (Julian Viereck)
Date: Thu, 07 Feb 2013 09:38:09 +0100
Subject: [whatwg] Proposal: HTMLCanvasElement.printCallback API
In-Reply-To: <CAPJYB1hfmBgULy=3=1EGWfQpTdPqUPe=CHQtgfKieiCtVDU=GQ@mail.gmail.com>
References: <76AFD13D-458E-4ADC-AE90-DFC7D4642A31@gmail.com>
	<51004407.10007@gmail.com>
	<CAPJYB1hfmBgULy=3=1EGWfQpTdPqUPe=CHQtgfKieiCtVDU=GQ@mail.gmail.com>
Message-ID: <511367F1.5080602@gmail.com>

On 1/28/13 6:25 AM, Elliott Sprehn wrote:
> 1) I feel like this should probably be an event. I don't know why 
> we're inventing new callback facilities everywhere.
>
> canvas.onprintcanvas = function(e) { e.printState ... }

Not sure I get what you're trying to say. Do you want the function to be 
an event, such that you can do

   canvas.addEventListener('printCallback', function(e) { ...} )

or just rename the `canvas.printCallback` to `canvas.onprintcallback`?

A event might be dispatched to multiple listeners. In the scenario with 
the print callback it makes only sense to have one function that defines 
the look of the canvas during printing. Therefore I've choosen to not 
use the event-listener pattern but instead a single callback function.

> 2) What does "send the canvas' content without rasterization to the 
> printer" mean? How are blending and overlapping images handled? Your 
> current description makes it sound like if I did two drawImage() calls 
> it would make my printer print the images on top of each other.
The drawing is done exactly the same as you expect it to show up on the 
screen including blending and overlapping.

Here is an example using the canvas.printCallback API. It draws shapes 
over each other:
- test html page: 
https://bug745025.bugzilla.mozilla.org/attachment.cgi?id=625810
- output: 
https://docs.google.com/file/d/0B4VOqqwjYRMLS05JNVZpZWt3MG8/edit?usp=sharing

Is this clear or does it need more clearification?

Very best,

Julian


From annevk at annevk.nl  Thu Feb  7 05:13:45 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Thu, 7 Feb 2013 13:13:45 +0000
Subject: [whatwg] DOMError not constructable
In-Reply-To: <CANr5HFVAz4QcOoimM+v7THBx6Hyoa0Ys9vMitMCYTTs_-LF6jA@mail.gmail.com>
References: <CANr5HFVAz4QcOoimM+v7THBx6Hyoa0Ys9vMitMCYTTs_-LF6jA@mail.gmail.com>
Message-ID: <CADnb78hv7WjZTH9zAkwQB0+ACgtKAkZVKh=awD5LDzrc6c6AjA@mail.gmail.com>

On Thu, Jan 17, 2013 at 2:02 PM, Alex Russell <slightlyoff at google.com> wrote:
> It appears that WebIDL-ese has afflicted DOMError and DOMException:
> http://dom.spec.whatwg.org/#interface-domerror
>
> These should be constructable, with a single "name" DOMStrong parameter or
> an argument bag which allows setting of the name property.

DOMError:

https://github.com/whatwg/dom/commit/3f5761ef179f6784dc08c6955c5673db7552fa6e

DOMException:

http://lists.w3.org/Archives/Public/public-script-coord/2013JanMar/0049.html

(I took so long to reply because I was waiting for heycam to reply to
the above, but I thought I might as well move ahead with DOMError for
now.)

Thanks!


-- 
http://annevankesteren.nl/


From neerja at kynex.com  Thu Feb  7 06:47:12 2013
From: neerja at kynex.com (Neerja Anand)
Date: Thu, 7 Feb 2013 09:47:12 -0500
Subject: [whatwg] XML data islands related question
Message-ID: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>

Hello - it appears that XML data islands (originally created by Microsoft)
have been discontinued in the newer browsers. We wanted to request they
could be supported as an addon/plugin into the browser if not incorporated
into the browser by default. We understand that this was a Microsoft only
feature but they are extremely helpful to our business and their
discontinuation would highly affect our business. Our request is to make
them as an HTML5 standard, so all browsers would then have to support this
feature. This would make the life of us developers much easier. We are not
asking for Microsoft's version of XML data islands specifically, but would
want this feature as a standard in some version. We noticed there is
something new called Data Block which may be similar to XML data islands,
but couldn't find much information on it to proceed. If you know of Data
Blocks being an alternative to XML data islands, then if you could provide
some documentation or point us to the location where we can get more
information (with examples on how to use them) that would be very helpful as
well.

 

Any feedback on this would be appreciated.

 

Thanks very much in advance!

 

Neerja Anand

neerja at kynex.com

 



From slightlyoff at google.com  Thu Feb  7 06:47:54 2013
From: slightlyoff at google.com (Alex Russell)
Date: Thu, 7 Feb 2013 06:47:54 -0800
Subject: [whatwg] DOMError not constructable
In-Reply-To: <CADnb78hv7WjZTH9zAkwQB0+ACgtKAkZVKh=awD5LDzrc6c6AjA@mail.gmail.com>
References: <CANr5HFVAz4QcOoimM+v7THBx6Hyoa0Ys9vMitMCYTTs_-LF6jA@mail.gmail.com>
	<CADnb78hv7WjZTH9zAkwQB0+ACgtKAkZVKh=awD5LDzrc6c6AjA@mail.gmail.com>
Message-ID: <CANr5HFUJ_ORkNx9Pdx6khZmabRSsFWr-Sw5MHsZzcw7GLgR+mQ@mail.gmail.com>

LGTM++

On Thursday, February 7, 2013, Anne van Kesteren wrote:

> On Thu, Jan 17, 2013 at 2:02 PM, Alex Russell <slightlyoff at google.com<javascript:;>>
> wrote:
> > It appears that WebIDL-ese has afflicted DOMError and DOMException:
> > http://dom.spec.whatwg.org/#interface-domerror
> >
> > These should be constructable, with a single "name" DOMStrong parameter
> or
> > an argument bag which allows setting of the name property.
>
> DOMError:
>
>
> https://github.com/whatwg/dom/commit/3f5761ef179f6784dc08c6955c5673db7552fa6e
>
> DOMException:
>
>
> http://lists.w3.org/Archives/Public/public-script-coord/2013JanMar/0049.html
>
> (I took so long to reply because I was waiting for heycam to reply to
> the above, but I thought I might as well move ahead with DOMError for
> now.)
>
> Thanks!
>
>
> --
> http://annevankesteren.nl/
>


From mat at matcarey.co.uk  Thu Feb  7 06:58:48 2013
From: mat at matcarey.co.uk (Mat Carey)
Date: Thu, 7 Feb 2013 14:58:48 +0000
Subject: [whatwg] XML data islands related question
In-Reply-To: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
References: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
Message-ID: <CAN7jg5O8cqOeUqaWpg8+2hPS26xW=xGO_Cos6BG1KfmDP1mLpg@mail.gmail.com>

I've been thinking about this too...

> We wanted to request they could be supported as an addon/plugin into the
browser if not incorporated into the browser by default

I came to the conclusion that if I care enough I should write a browser
plugin having reverse engineered the data island spec which would allow
people with my plugin to use these sites, then bring this to WHATWG to
suggest wider adoption.

I'm not particularly active on WHATWG but the general approach seems to be
that if you have a good idea you should go and create it, show that it
works and then bring it to WHATWG for a wider adoption.

My advice would be to have a look and see if anyone's already started a
project to reverse engineer this, if they have join it, if they haven't
start it.

I decided previously that I don't care enough to do this work myself, if
there's someone else working towards this I might be willing to help in an
open source project and I'm sure there's others who would do the same.

I could be wrong - if I am I'm sure someone will correct me.

Mat Carey


On Thu, Feb 7, 2013 at 2:47 PM, Neerja Anand <neerja at kynex.com> wrote:

> Hello - it appears that XML data islands (originally created by Microsoft)
> have been discontinued in the newer browsers. We wanted to request they
> could be supported as an addon/plugin into the browser if not incorporated
> into the browser by default. We understand that this was a Microsoft only
> feature but they are extremely helpful to our business and their
> discontinuation would highly affect our business. Our request is to make
> them as an HTML5 standard, so all browsers would then have to support this
> feature. This would make the life of us developers much easier. We are not
> asking for Microsoft's version of XML data islands specifically, but would
> want this feature as a standard in some version. We noticed there is
> something new called Data Block which may be similar to XML data islands,
> but couldn't find much information on it to proceed. If you know of Data
> Blocks being an alternative to XML data islands, then if you could provide
> some documentation or point us to the location where we can get more
> information (with examples on how to use them) that would be very helpful
> as
> well.
>
>
>
> Any feedback on this would be appreciated.
>
>
>
> Thanks very much in advance!
>
>
>
> Neerja Anand
>
> neerja at kynex.com
>
>
>
>


-- 
Web Developer & Consultant
mat at matcarey.co.uk
www.matcarey.co.uk
07952258096


From Randy at ProWebDesign.nl  Thu Feb  7 07:55:42 2013
From: Randy at ProWebDesign.nl (Randy)
Date: Thu, 7 Feb 2013 16:55:42 +0100
Subject: [whatwg] XML data islands related question
In-Reply-To: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
References: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
Message-ID: <C77B8029-E9B2-4722-ABF1-9A1C3F88DEE6@ProWebDesign.nl>

As far as I'm aware, Data Blocks should be or is part of HTML5. See https://developer.mozilla.org/en/docs/Using_XML_Data_Islands_in_Mozilla for more info. 

HTH

Sent from your iPhone

On 7 feb. 2013, at 15:47, "Neerja Anand" <neerja at kynex.com> wrote:

> Hello - it appears that XML data islands (originally created by Microsoft)
> have been discontinued in the newer browsers. We wanted to request they
> could be supported as an addon/plugin into the browser if not incorporated
> into the browser by default. We understand that this was a Microsoft only
> feature but they are extremely helpful to our business and their
> discontinuation would highly affect our business. Our request is to make
> them as an HTML5 standard, so all browsers would then have to support this
> feature. This would make the life of us developers much easier. We are not
> asking for Microsoft's version of XML data islands specifically, but would
> want this feature as a standard in some version. We noticed there is
> something new called Data Block which may be similar to XML data islands,
> but couldn't find much information on it to proceed. If you know of Data
> Blocks being an alternative to XML data islands, then if you could provide
> some documentation or point us to the location where we can get more
> information (with examples on how to use them) that would be very helpful as
> well.
> 
> 
> 
> Any feedback on this would be appreciated.
> 
> 
> 
> Thanks very much in advance!
> 
> 
> 
> Neerja Anand
> 
> neerja at kynex.com
> 
> 
> 


From slightlyoff at google.com  Thu Feb  7 09:16:25 2013
From: slightlyoff at google.com (Alex Russell)
Date: Thu, 7 Feb 2013 09:16:25 -0800
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
Message-ID: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>

While using the shiny new URL spec in some API work, I've got a couple of
questions, some sparked by Jake's excellent insights:


   1. It doesn't appear straightforward to test if two URL objects
   reference the same path. The serialization algorithm has as flag for
   omitting the fragment, but not the query. Is there something in the API
   that I'm missing that would make this easier than custom-serializing 2 URLs
   to omit queries and then test string equality?
   2. The word "search" seems drived from window.location's use of that. Is
   it only included for compat with window.location? if so, can we drop it and
   spec window.location to use a subclass that provides it?

Thanks.


From annevk at annevk.nl  Thu Feb  7 09:27:34 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Thu, 7 Feb 2013 17:27:34 +0000
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
Message-ID: <CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>

On Thu, Feb 7, 2013 at 5:16 PM, Alex Russell <slightlyoff at google.com> wrote:
> It doesn't appear straightforward to test if two URL objects reference the
> same path. The serialization algorithm has as flag for omitting the
> fragment, but not the query. Is there something in the API that I'm missing
> that would make this easier than custom-serializing 2 URLs to omit queries
> and then test string equality?

new URL(path, base).pathname == new URL(path2, base).pathname ought to work.


> The word "search" seems drived from window.location's use of that. Is it
> only included for compat with window.location? if so, can we drop it and
> spec window.location to use a subclass that provides it?

It's used by <a>, <area>, Location, and WorkerLocation. I think we
should just embrace that the string variant is named search
personally.


-- 
http://annevankesteren.nl/


From jkorpela at cs.tut.fi  Thu Feb  7 10:03:07 2013
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Thu, 07 Feb 2013 20:03:07 +0200
Subject: [whatwg] XML data islands related question
In-Reply-To: <C77B8029-E9B2-4722-ABF1-9A1C3F88DEE6@ProWebDesign.nl>
References: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
	<C77B8029-E9B2-4722-ABF1-9A1C3F88DEE6@ProWebDesign.nl>
Message-ID: <5113EC5B.8050500@cs.tut.fi>

2013-02-07 17:55, Randy wrote:

> As far as I'm aware, Data Blocks should be or is part of HTML5.  See
 > https://developer.mozilla.org/en/docs/Using_XML_Data_Islands_in_Mozilla
 > for more info.

It's a somewhat similar concept, but it's about embedded data in 
general, not specifically XML data. Moreover, the <xml> element (which 
was, as far as I can see, implemented only in IE versions 5 and 6) was 
specifically for XML data, implying the idea that the browser parses the 
XML data and makes it available in a certain way that you could use with 
HTML attributes.

Although <xml> had its merits, it seems to be water under the bridge 
now, not supported even by modern versions of IE (though they seem to 
have an excuse for a surrogate for broken support: <xml>foobar</xml> 
gets ignored, whereas other browsers ignore just the tags and render 
foobar).

The current WHATWG HTML document, as well as the W3C HTML5 CR, defines 
<script> really as a multi-purpose element:
"The script element allows authors to include dynamic script and data 
blocks in their documents."
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#the-script-element

So the name is really a misnomer, though it reflects the most common use 
of the element. The content can be plain text, XML text, or text in any 
format, as long as you take care of parsing it. In practice, if the type 
attribute is set to any value except one of the strings interpreted as 
referring to JavaScript, the content is taken just as a block of text 
data, made available to client-side scripting but otherwise ignored.

However, browsers do not seem to support using a src attribute then; the 
non-script data must be inline, as element content, not fetched from an 
external source. I suppose the usual suspects (security considerations) 
are to be blaimed. This however means that the technique is not 
comparable to <xml>, which allowed external references.

It might be useful to mention explicitly in the spec that browsers do 
not generally allow non-script to be specified via the src attribute. 
And perhaps the spec should say that this is implementation-dependent 
and recommend that such references should be allowed, with due security 
considerations.

It's a bit odd that if you wish to set up a standalone application 
running in a browser (often called "HTML5 application", without implying 
any particular version of HTML5), you can include e.g. scripts and 
images in separate files but not plain text or XML data

Yucca



From alain.couthures at agencexml.com  Thu Feb  7 10:16:04 2013
From: alain.couthures at agencexml.com (Alain Couthures)
Date: Thu, 07 Feb 2013 19:16:04 +0100
Subject: [whatwg] XML data islands related question
In-Reply-To: <5113EC5B.8050500@cs.tut.fi>
References: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
	<C77B8029-E9B2-4722-ABF1-9A1C3F88DEE6@ProWebDesign.nl>
	<5113EC5B.8050500@cs.tut.fi>
Message-ID: <5113EF64.8030105@agencexml.com>

Le 07/02/2013 19:03, Jukka K. Korpela a ?crit :
>
>
> It's a bit odd that if you wish to set up a standalone application 
> running in a browser (often called "HTML5 application", without 
> implying any particular version of HTML5), you can include e.g. 
> scripts and images in separate files but not plain text or XML data
A good workaround is to use the SCRIPT element with a type attribute set 
to "text/xml": the browser will not try to interpret it! I use it myself 
in my XForms implementation to store fragments of XHTML+XForms.

-Alain


From jkorpela at cs.tut.fi  Thu Feb  7 10:29:23 2013
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Thu, 07 Feb 2013 20:29:23 +0200
Subject: [whatwg] XML data islands related question
In-Reply-To: <5113EF64.8030105@agencexml.com>
References: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
	<C77B8029-E9B2-4722-ABF1-9A1C3F88DEE6@ProWebDesign.nl>
	<5113EC5B.8050500@cs.tut.fi> <5113EF64.8030105@agencexml.com>
Message-ID: <5113F283.1070209@cs.tut.fi>

2013-02-07 20:16, Alain Couthures wrote:

> Le 07/02/2013 19:03, Jukka K. Korpela a ?crit :
>>
>> It's a bit odd that if you wish to set up a standalone application
>> running in a browser (often called "HTML5 application", without
>> implying any particular version of HTML5), you can include e.g.
>> scripts and images in separate files but not plain text or XML data
> A good workaround is to use the SCRIPT element with a type attribute set
> to "text/xml": the browser will not try to interpret it! I use it myself
> in my XForms implementation to store fragments of XHTML+XForms.

My point was that although this is possible for data inserted into an 
HTML document, as <script> element content, it does not work for 
external data, specified via the src attribute. And I think it would be 
unrealistic to *require* support to external references, it might be a 
good idea to mention it as allowed and perhaps recommended.

Yucca




From esprehn at gmail.com  Thu Feb  7 10:47:22 2013
From: esprehn at gmail.com (Elliott Sprehn)
Date: Thu, 7 Feb 2013 10:47:22 -0800
Subject: [whatwg] Proposal: HTMLCanvasElement.printCallback API
In-Reply-To: <511367F1.5080602@gmail.com>
References: <76AFD13D-458E-4ADC-AE90-DFC7D4642A31@gmail.com>
	<51004407.10007@gmail.com>
	<CAPJYB1hfmBgULy=3=1EGWfQpTdPqUPe=CHQtgfKieiCtVDU=GQ@mail.gmail.com>
	<511367F1.5080602@gmail.com>
Message-ID: <CAPJYB1jOqPqpDhs+R-2ErXM19ZxXkws9rZfv5PHohd=aKSAotQ@mail.gmail.com>

On Thu, Feb 7, 2013 at 12:38 AM, Julian Viereck <
julian.viereck at googlemail.com> wrote:

> On 1/28/13 6:25 AM, Elliott Sprehn wrote:
>
>> 1) I feel like this should probably be an event. I don't know why we're
>> inventing new callback facilities everywhere.
>>
>> canvas.onprintcanvas = function(e) { e.printState ... }
>>
>
> Not sure I get what you're trying to say. Do you want the function to be
> an event, such that you can do
>
>   canvas.addEventListener('**printCallback', function(e) { ...} )
>
> or just rename the `canvas.printCallback` to `canvas.onprintcallback`?
>
>
It should be an event. There are legitimate reasons for multiple listeners,
for instance I might have a listener on body that adds watermarks and a
listener on the canvas that does just the drawing.

Not using events also limits my ability to globally hook the facility. For
instance I'd like to do:

$(document).printcanvas(function(e) {
  if (drawingFunctions[e.target.id])
    drawingFunctions[e.target.id](e.target);
});

I also still don't understand why this is specific to canvas. Why can't I
do the same thing for <img> ? Cocoa lets me hook NSView drawRect: and draw
whatever I want at print time.


>  2) What does "send the canvas' content without rasterization to the
>> printer" mean? How are blending and overlapping images handled? Your
>> current description makes it sound like if I did two drawImage() calls it
>> would make my printer print the images on top of each other.
>>
> The drawing is done exactly the same as you expect it to show up on the
> screen including blending and overlapping.
>
> Here is an example using the canvas.printCallback API. It draws shapes
> over each other:
> - test html page: https://bug745025.bugzilla.**
> mozilla.org/attachment.cgi?id=**625810<https://bug745025.bugzilla.mozilla.org/attachment.cgi?id=625810>
> - output: https://docs.google.com/file/**d/**0B4VOqqwjYRMLS05JNVZpZWt3MG8/
> **edit?usp=sharing<https://docs.google.com/file/d/0B4VOqqwjYRMLS05JNVZpZWt3MG8/edit?usp=sharing>
>
> Is this clear or does it need more clearification?
>

Ah, you don't mean sent to the physical printer without rasterization then,
you mean it's just spooled to the printer driver which may rasterize it to
send it to the device. That seems to run into operating system and
implementation limitations. I don't know if the spec should require that
behavior.

- E


From robert at ocallahan.org  Thu Feb  7 13:10:40 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 8 Feb 2013 10:10:40 +1300
Subject: [whatwg] Proposal: HTMLCanvasElement.printCallback API
In-Reply-To: <CAPJYB1jOqPqpDhs+R-2ErXM19ZxXkws9rZfv5PHohd=aKSAotQ@mail.gmail.com>
References: <76AFD13D-458E-4ADC-AE90-DFC7D4642A31@gmail.com>
	<51004407.10007@gmail.com>
	<CAPJYB1hfmBgULy=3=1EGWfQpTdPqUPe=CHQtgfKieiCtVDU=GQ@mail.gmail.com>
	<511367F1.5080602@gmail.com>
	<CAPJYB1jOqPqpDhs+R-2ErXM19ZxXkws9rZfv5PHohd=aKSAotQ@mail.gmail.com>
Message-ID: <CAOp6jLbf2tFrEb3dksbQUNoqtyp2EtQmJUF=Zt2s34fvTn1dEA@mail.gmail.com>

On Fri, Feb 8, 2013 at 7:47 AM, Elliott Sprehn <esprehn at gmail.com> wrote:

> I also still don't understand why this is specific to canvas. Why can't I
> do the same thing for <img> ? Cocoa lets me hook NSView drawRect: and draw
> whatever I want at print time.
>

I answered that on January 29.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From neerja at kynex.com  Thu Feb  7 14:17:18 2013
From: neerja at kynex.com (Neerja Anand)
Date: Thu, 7 Feb 2013 17:17:18 -0500
Subject: [whatwg] XML data islands related question
In-Reply-To: <CAN7jg5O8cqOeUqaWpg8+2hPS26xW=xGO_Cos6BG1KfmDP1mLpg@mail.gmail.com>
References: <BCACAFB7B93242259F21C5C53CE4F502@kynex.lan>
	<CAN7jg5O8cqOeUqaWpg8+2hPS26xW=xGO_Cos6BG1KfmDP1mLpg@mail.gmail.com>
Message-ID: <3A65A16AA10A4391ACCDDE13506408F2@kynex.lan>

Hello Mat - well this feature is already developed by Microsoft, it is just
discontinued now in the newer browsers. It won't really be a point to
reinvent the wheel if the work has already been done to include data island,
and then bind that data to the fields on the page. If you could get that
code from Microsoft and include that as your standard, then other browsers
would have to incorporate it. So our hope is that you would be able to get
in touch with Microsoft to get this functionality and update your standards.

 

Please let us know if that is doable. Alternatively if you have Microsoft's
contact information then I could reach out to them to request handing over
that code to you.

 

Please advise on how to proceed.

 

Thanks very much.

 

Neerja

 

  _____  

From: Mat Carey [mailto:mat at matcarey.co.uk] 
Sent: Thursday, February 07, 2013 9:59 AM
To: Neerja Anand
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] XML data islands related question

 

I've been thinking about this too...

 

> We wanted to request they could be supported as an addon/plugin into the
browser if not incorporated into the browser by default

 

I came to the conclusion that if I care enough I should write a browser
plugin having reverse engineered the data island spec which would allow
people with my plugin to use these sites, then bring this to WHATWG to
suggest wider adoption.

 

I'm not particularly active on WHATWG but the general approach seems to be
that if you have a good idea you should go and create it, show that it works
and then bring it to WHATWG for a wider adoption.

 

My advice would be to have a look and see if anyone's already started a
project to reverse engineer this, if they have join it, if they haven't
start it.

 

I decided previously that I don't care enough to do this work myself, if
there's someone else working towards this I might be willing to help in an
open source project and I'm sure there's others who would do the same.

 

I could be wrong - if I am I'm sure someone will correct me.

 

Mat Carey

 

On Thu, Feb 7, 2013 at 2:47 PM, Neerja Anand <neerja at kynex.com> wrote:

Hello - it appears that XML data islands (originally created by Microsoft)
have been discontinued in the newer browsers. We wanted to request they
could be supported as an addon/plugin into the browser if not incorporated
into the browser by default. We understand that this was a Microsoft only
feature but they are extremely helpful to our business and their
discontinuation would highly affect our business. Our request is to make
them as an HTML5 standard, so all browsers would then have to support this
feature. This would make the life of us developers much easier. We are not
asking for Microsoft's version of XML data islands specifically, but would
want this feature as a standard in some version. We noticed there is
something new called Data Block which may be similar to XML data islands,
but couldn't find much information on it to proceed. If you know of Data
Blocks being an alternative to XML data islands, then if you could provide
some documentation or point us to the location where we can get more
information (with examples on how to use them) that would be very helpful as
well.



Any feedback on this would be appreciated.



Thanks very much in advance!



Neerja Anand

neerja at kynex.com








 

-- 

Web Developer & Consultant 

 <mailto:mat at matcarey.co.uk> mat at matcarey.co.uk
 <http://www.matcarey.co.uk/> www.matcarey.co.uk 

07952258096 



From gman at google.com  Thu Feb  7 16:24:18 2013
From: gman at google.com (Gregg Tavares)
Date: Thu, 7 Feb 2013 16:24:18 -0800
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
Message-ID: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>

 Anyone have time to give me some advice, tips, pointers?

In the next WebGL we have Query/Sync objects. In C/C++ land the user can
insert some drawing commands that will happen asynchronously on the GPU.
They can also insert a query. They can then poll that query (did this
finish?).

We'd like to expose that to JavaScript. I've been pushing to making it a
callback in JavaScript rather than polling. Most graphics developers I talk
to hate this idea.

My assumptions have been

(a) polling is kind of maybe not allowed in JS (though I have no proof,
only heresy)

Are there any "rules" or things in the spec that make polling apis
untenable?


(b) polling is often error prone and those errors can be avoided using
callbacks and I'm assuming designing an API that is hard or impossible to
use wrong is a good thing.

To give an example, in GL I can render in 2 threads. Let's say in one
thread I'm rendering to a texture and in the other thread I'd like to use
that texture to render something else.

I can insert a query in the first thread, and poll that query in the second
thread. When the query says the texture is ready the second thread can
render with it.

The problem is, if I forget to query things won't fail I'll just get the
wrong results. But I might not. It might be that rendering on thread #1
takes 1ms and it takes 2ms before thread 2 tries to render so things just
appear to work, no queries needed. But then something (another tab, another
app) slows the the system down. Thread #1 takes 4ms now and Thread #2 which
is just assuming things take 2ms renders and sees old or half rendered
results.

We can encapsulate some of this. In WebGL we can require that the texture
being used in both threads be a wrapped object, a SharedTexture, and we can
require SharedTextures can be used in only 1 thread at a time. You acquire
and release it on a particular thread. And so now comes the issue:

Should acquire block, poll or use a callback

block = evil

poll has the issue that I can try to use the texture even when I haven't
acquired it. See the example above. It allows not polling and assuming the
texture will be available. That might work most of the time but on some
machine or under certain circumstances the acquire will fail. Apps that
forget to check for success because the API let them ignore failure will
then fail in strange and random ways. It basically exposes race conditions

callback seems to make it much harder to use wrong. You get a callback when
the texture has been acquired. Now you can't use it without calling acquire
period.

But. that comes back to (a) above. Move devs I've talked to really don't
want to use callbacks. They're all good devs and they know what they're
doing and they don't want to deal with what they consider callback/closure
hell. Especially when they need to acquire multiple things at once.

I'm in the callback camp. (1) to protect programmers from mistakes they
won't find until the exceptional happens and (2) because I'm under the
impression that browser vendors would say "no" to polling. But, maybe it
doesn't matter and polling is fine.

note: this issue already exists in the Web API today with images. Example:

img.src = "someimage.jpg"
setTimeout(function() {
   ctx.drawImage(img, 0, 0);
}, 1000);

Assumes the image will be available in 1 second which may or may not be
true. The API could have been designed to make this much harder to get
wrong (though not impossible). If you had get some kind of ImageHandle to
call drawImage and you could only get that ImageHandle in the 'load' event
of an image

Images are not quite analogous though as there is no polling built in
polling on an image to find out if it's finished.


From glenn at zewt.org  Thu Feb  7 17:32:03 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Thu, 7 Feb 2013 19:32:03 -0600
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
In-Reply-To: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
References: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
Message-ID: <CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>

On Thu, Feb 7, 2013 at 6:24 PM, Gregg Tavares <gman at google.com> wrote:

>  Anyone have time to give me some advice, tips, pointers?
>
> In the next WebGL we have Query/Sync objects. In C/C++ land the user can
> insert some drawing commands that will happen asynchronously on the GPU.
> They can also insert a query. They can then poll that query (did this
> finish?).
>

Before I get into the technical discussion of polling vs. events, I'd like
to look at this briefly from a higher level.

A big problem with WebGL is that it tends to disregard the conventions of
the platform; it "does its own thing".  For example, it uses slews of
functions with different names, instead of collapsing logical overloads.
It also has another slew of functions--deleteBuffer, deleteFramebuffer,
deleteShader--which could easily have been a single "delete(WebGLObject)",
or much better a "delete()" function on WebGLObject.  This makes WebGL feel
more like a naive copy of OpenGL, designed by a C programmer, than a
well-thought-out binding.

This is just to say: callbacks are the pattern on on the platform, not
polling, and WebGL should follow that pattern, not go its own way and make
up its own conventions.  If people don't understand why the platform's
conventions are what they are, and think they should be something else,
please encourage them to come here and discuss it--not to try to make WebGL
its own isolated island.  That's damaging to WebGL and the platform as a
whole.

We'd like to expose that to JavaScript. I've been pushing to making it a
> callback in JavaScript rather than polling. Most graphics developers I talk
> to hate this idea.
>

Polling is expensive, especially if you don't already have a render loop to
poll from (eg. single-shot rendering, and load screens).

It's also latent.  If you're polling from requestAnimationFrame (for
example), you're probably checking every 16ms.  That means there may be up
to 16ms extra delay, if the task finished right after the last poll.  This
encourages people to set timers that run as fast as possible, in order to
lower latency, which makes it more and more expensive and runs up against
timer throttling.

But. that comes back to (a) above. Move devs I've talked to really don't
> want to use callbacks. They're all good devs and they know what they're
> doing and they don't want to deal with what they consider callback/closure
> hell. Especially when they need to acquire multiple things at once.
>

There's no "callback hell"; it's very easy to wait for many things to
finish with just a single callback.  Here's an example, which loads a bunch
of images with <img>, and calls a function when they're all done loading:

https://zewt.org/~glenn/load-lots-of-images.html

It's very simple: each time an image finishes loading, the callback checks
whether all resources have finished loading.  If there are still images in
the process of loading, it returns and waits for the next one to finish.
Otherwise, it's done.  There's just a single, trivial closure.

Images are not quite analogous though as there is no polling built in
> polling on an image to find out if it's finished.
>

Actually, there is.  Changing "img.onload = onload" to "setInterval(onload,
100)" (and adding a clearInterval in the appropriate place) in the above
sample turns it into a poll.

-- 
Glenn Maynard


From slightlyoff at google.com  Fri Feb  8 04:11:24 2013
From: slightlyoff at google.com (Alex Russell)
Date: Fri, 8 Feb 2013 04:11:24 -0800
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
Message-ID: <CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>

On Thursday, February 7, 2013, Anne van Kesteren wrote:

> On Thu, Feb 7, 2013 at 5:16 PM, Alex Russell <slightlyoff at google.com<javascript:;>>
> wrote:
> > It doesn't appear straightforward to test if two URL objects reference
> the
> > same path. The serialization algorithm has as flag for omitting the
> > fragment, but not the query. Is there something in the API that I'm
> missing
> > that would make this easier than custom-serializing 2 URLs to omit
> queries
> > and then test string equality?
>
> new URL(path, base).pathname == new URL(path2, base).pathname ought to
> work.
>

But if I've been vended a URL object from some API, I first have to compare
the bases. I'd like a way to ask something like "is the full URL
up-to-and-including this component the same?" E.g., if I have an API that's
handed two URLs (a and b), I'd like to be able to write something like:

    if (a.toString("path") == b.toString("path")) {
      ...
    }


> > The word "search" seems drived from window.location's use of that. Is it
> > only included for compat with window.location? if so, can we drop it and
> > spec window.location to use a subclass that provides it?
>
> It's used by <a>, <area>, Location, and WorkerLocation. I think we
> should just embrace that the string variant is named search
> personally.
>

I'm less fussed on this point, but I do think naming matters. If we can do
better, I think we should.


From cabanier at gmail.com  Fri Feb  8 04:25:24 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Fri, 8 Feb 2013 23:25:24 +1100
Subject: [whatwg] Adding the imageSmoothingEnabled back into 2dContext
	Level 2 spec.
In-Reply-To: <dbdbd50110e64b48a7b26e5e26875e2c@SN2PR03MB045.namprd03.prod.outlook.com>
References: <dbdbd50110e64b48a7b26e5e26875e2c@SN2PR03MB045.namprd03.prod.outlook.com>
Message-ID: <CAGN7qDAf_tBWfhD=EogOpQ_TrZzCkSNk0ijY+FfMa-N7XP+L0w@mail.gmail.com>

I agree we should bring it back.

Personally, it would be nice that have a more formal definition of what
smoothing actually means so user agents can implement it similarly.

Rik

On Tue, Feb 5, 2013 at 7:14 AM, Jay Munro <jaymunro at microsoft.com> wrote:

> For CR, we took the imageSmoothingEnable feature out because it hadn't
> been given a chance to be discussed by the working group. For level 2, I'm
> adding it back in, but asking for any discussion that needs to be made
> first.
>
> Silence will be taken to mean there is no objection, but positive
> responses are encouraged.  If I don't hear any objections by Monday Feb 11,
> I'll check it in.
>
> The following is the pending check in:
>
>
> @@ -40677,6 +40677,10 @@ dictionary <dfn>TrackEventInit</dfn> :
> <span>EventInit</span> {
>    // compositing
>             attribute unrestricted double <span
> title="dom-context-2d-globalAlpha">globalAlpha</span>; // (default 1.0)
>             attribute DOMString <span
> title="dom-context-2d-globalCompositeOperation">globalCompositeOperation</span>;
> // (default source-over)
> +
> +  // image smoothing
> +           attribute boolean <span
> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</span>;
> // (default true)
> +
>  <!--
>    // v7 we've also received requests for:
>    - turning off antialiasing to avoid seams when patterns are painted
> next to each other
> @@ -40945,7 +40949,8 @@ interface <dfn>Path</dfn> {
>
> title="dom-context-2d-globalCompositeOperation">globalCompositeOperation</code>,
> <code
>     title="dom-context-2d-font">font</code>, <code
>     title="dom-context-2d-textAlign">textAlign</code>, <code
> -   title="dom-context-2d-textBaseline">textBaseline</code>.</li>
> +   title="dom-context-2d-textBaseline">textBaseline</code>, <code
> +
> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>.</li>
>    </ul>
>
>    <p class="note">The <span>current default path</span> and the
> @@ -43416,10 +43421,16 @@ try {
>
>    <p>If the original image data is a bitmap image, the value painted
>    at a point in the area of the repetitions is computed by filtering
> -  the original image data. The user agent may use any filtering
> +  the original image data. If the <code
> +
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> +  then the user agent may use any filtering
>    algorithm (for example bilinear interpolation or nearest-neighbor).
> -  When the filtering algorithm requires a pixel value from outside the
> -  original image data, it must instead use the value from wrapping the
> +  If the <code
> +
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> +  attribute is set to false, the image must be rendered using
> +  nearest-neighbor interpolation. When such the filtering algorithm
> +  requires a pixel value from outside the original image data, it
> +  must instead use the value from wrapping the
>    pixel's coordinates to the original image's dimensions. (That is,
>    the filter uses 'repeat' behavior, regardless of the value of
>    <var title="">repetition</var>.)
> @@ -44539,6 +44550,18 @@ v6DVT (also check for '- -' bits in the part
> above) -->
>    <p class="note">This specification does not define the algorithm to
>    use when scaling the image, if necessary.</p>
>
> +  <p>If the <code
> +
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> +  attribute is set to true, then the user agent should attempt to
> +  apply a smoothing algorithm to the image data when it is scaled.
> +  Otherwise, the image must be rendered using nearest-neighbor
> +  interpolation.</p>
> +
> +  <p class="note">This specification does not define the precise
> +  algorithm to use when scaling an image when the <code
> +
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> +  attribute is set to true.</p>
> +
>    <p class="note">When a canvas is drawn onto itself, the <span>drawing
>    model</span> requires the source to be copied before the image is drawn
>    back onto the canvas, so it is possible to copy parts of a canvas
> @@ -46040,6 +46063,36 @@ function AddCloud(data, x, y) { ... }</pre>
>
>    </div>
>
> +  <h6>Image smoothing</h6>
> +
> +  <dl class="domintro">
> +
> +   <dt><var title="">context</var> . <code
> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code> [
> = <var title="">value</var> ]</dt>
> +
> +   <dd>
> +
> +    <p>Returns whether pattern fills and the <code
> +    title="dom-context-2d-drawImage">drawImage()</code> method will
> +    attempt to smooth images if they have to rescale them (as opposed
> +    to just rendering the images with "big pixels").</p>
> +
> +    <p>Can be set, to change whether images are smoothed (true) or not
> +    (false).</p>
> +
> +   </dd>
> +
> +  </dl>
> +
> +  <div class="impl">
> +
> +  <p>The <dfn
> +
>  title="dom-context-2d-imageSmoothingEnabled"><code>imageSmoothingEnabled</code></dfn>
> +  attribute, on getting, must return the last value it was set to. On
> +  setting, it must be set to the new value. When the
> +  <code>CanvasRenderingContext2D</code> object is created, the
> +  attribute must be set to true.</p>
> +
> +  </div>
>
>
>
>
>
>
>


From annevk at annevk.nl  Fri Feb  8 04:38:33 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Fri, 8 Feb 2013 12:38:33 +0000
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
	<CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
Message-ID: <CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>

On Fri, Feb 8, 2013 at 12:11 PM, Alex Russell <slightlyoff at google.com> wrote:
> But if I've been vended a URL object from some API, I first have to compare
> the bases. I'd like a way to ask something like "is the full URL
> up-to-and-including this component the same?" E.g., if I have an API that's
> handed two URLs (a and b), I'd like to be able to write something like:
>
>     if (a.toString("path") == b.toString("path")) {
>       ...
>     }

What you're saying and what your API proposal is saying seems
different. Do you want to compare the path, or do you want to compare
the scheme, host, etc. but not query and fragment?

I've been thinking of URL.compare(url, options) where in options you
can say to ignore certain components and maybe additionally a way so
you can normalize away percent-encoding for some cases as the parser
does not do that. Thus far you're the only one who seems to be
requesting this feature. I haven't really figured out a way to
quantify demand somehow.


-- 
http://annevankesteren.nl/


From derhoermi at gmx.net  Fri Feb  8 05:40:30 2013
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Fri, 08 Feb 2013 14:40:30 +0100
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
	<CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
	<CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
Message-ID: <4sv9h8pmgt919d2v9vh23tds8kd6nod7jq@hive.bjoern.hoehrmann.de>

* Anne van Kesteren wrote:
>On Fri, Feb 8, 2013 at 12:11 PM, Alex Russell <slightlyoff at google.com> wrote:
>> But if I've been vended a URL object from some API, I first have to compare
>> the bases. I'd like a way to ask something like "is the full URL
>> up-to-and-including this component the same?" E.g., if I have an API that's
>> handed two URLs (a and b), I'd like to be able to write something like:
>>
>>     if (a.toString("path") == b.toString("path")) {
>>       ...
>>     }
>
>What you're saying and what your API proposal is saying seems
>different. Do you want to compare the path, or do you want to compare
>the scheme, host, etc. but not query and fragment?

I believe you are supposed to read the code above as "serialize this to
a string up to and including the path component" which would be in line
with the description.
-- 
Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de
25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 


From slightlyoff at google.com  Fri Feb  8 06:07:19 2013
From: slightlyoff at google.com (Alex Russell)
Date: Fri, 8 Feb 2013 06:07:19 -0800
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <4sv9h8pmgt919d2v9vh23tds8kd6nod7jq@hive.bjoern.hoehrmann.de>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
	<CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
	<CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
	<4sv9h8pmgt919d2v9vh23tds8kd6nod7jq@hive.bjoern.hoehrmann.de>
Message-ID: <CANr5HFViGRuAsNo5Lm1DQpthBNf110KvPyQ+jU8oMYAaht-5pw@mail.gmail.com>

On Friday, February 8, 2013, Bjoern Hoehrmann wrote:

> * Anne van Kesteren wrote:
> >On Fri, Feb 8, 2013 at 12:11 PM, Alex Russell <slightlyoff at google.com<javascript:;>>
> wrote:
> >> But if I've been vended a URL object from some API, I first have to
> compare
> >> the bases. I'd like a way to ask something like "is the full URL
> >> up-to-and-including this component the same?" E.g., if I have an API
> that's
> >> handed two URLs (a and b), I'd like to be able to write something like:
> >>
> >>     if (a.toString("path") == b.toString("path")) {
> >>       ...
> >>     }
> >
> >What you're saying and what your API proposal is saying seems
> >different. Do you want to compare the path, or do you want to compare
> >the scheme, host, etc. but not query and fragment?
>
> I believe you are supposed to read the code above as "serialize this to
> a string up to and including the path component" which would be in line
> with the description.
>

Yes, that. Thanks Bj?rn. The goal is to serialize up to and including the
path.


From glenn at zewt.org  Fri Feb  8 07:03:39 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 8 Feb 2013 09:03:39 -0600
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
	<CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
	<CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
Message-ID: <CABirCh-g8hF7872XF=-=Nif5W8TcKuD8F9VZpDFQ=21XtK4Dbg@mail.gmail.com>

On Fri, Feb 8, 2013 at 6:38 AM, Anne van Kesteren <annevk at annevk.nl> wrote:

> I've been thinking of URL.compare(url, options) where in options you
> can say to ignore certain components and maybe additionally a way so
> you can normalize away percent-encoding for some cases as the parser
> does not do that. Thus far you're the only one who seems to be
> requesting this feature. I haven't really figured out a way to
> quantify demand somehow.
>

A compare method is probably useful, since you'd also want case-insensitive
comparisons for some parts and not others (eg. lowercase protocol and host
before comparing).  Comparing only certain components doesn't seem very
common, though, and simple for people to do themselves:

function get_url_path(url)
{
    url = new URL(url);
    url.search = "";
    url.hash = "";
    return url;
}

if(get_url_path(url1).toString() == get_url_path(url2).toString())
    ;

-- 
Glenn Maynard


From annevk at annevk.nl  Fri Feb  8 08:09:25 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Fri, 8 Feb 2013 16:09:25 +0000
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CABirCh-g8hF7872XF=-=Nif5W8TcKuD8F9VZpDFQ=21XtK4Dbg@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
	<CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
	<CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
	<CABirCh-g8hF7872XF=-=Nif5W8TcKuD8F9VZpDFQ=21XtK4Dbg@mail.gmail.com>
Message-ID: <CADnb78je1Yfmpp8d4ODRaDxSvMjKLFySnCt-iZTTt137VKoCtQ@mail.gmail.com>

On Fri, Feb 8, 2013 at 3:03 PM, Glenn Maynard <glenn at zewt.org> wrote:
> A compare method is probably useful, since you'd also want case-insensitive
> comparisons for some parts and not others (eg. lowercase protocol and host
> before comparing).

Scheme and host are normalized by the parser already.


-- 
http://annevankesteren.nl/


From chunwang at microsoft.com  Fri Feb  8 09:53:23 2013
From: chunwang at microsoft.com (Chundong Wang)
Date: Fri, 8 Feb 2013 17:53:23 +0000
Subject: [whatwg] A question about portrait-secondary of screen orientation
Message-ID: <bdbc8728d2634143a050f9d86543627e@SN2PR03MB078.namprd03.prod.outlook.com>

Hello - Got a question of screen orientation on portrait/landscape.

Let's say we have a device doesn't support portrait-secondary, by spec<http://www.w3.org/TR/screen-orientation/> we should remove it from allow list which is fine. However if web developer specified "portrait" instead of "portrait-primary" for lockOrientation(), which I suppose is a common case, we'll have to expand it to "portrait-primary, portrait-secondary" according spec. In this case the lockOrientation() would fail because orientations isn't a supported orientation set. I don't think it'll satisfy the original purpose of "portrait".

IMHO, we should explain this more detailed.  We could either,

1.       Only expand "portrait"(or "landscape") into allowed orientations, or;

2.       Filter out disallowed orientations from orientation sequence and lock the screen with that list.

Thoughts?

CD


From glenn at zewt.org  Fri Feb  8 16:32:34 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 8 Feb 2013 18:32:34 -0600
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CADnb78je1Yfmpp8d4ODRaDxSvMjKLFySnCt-iZTTt137VKoCtQ@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
	<CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
	<CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
	<CABirCh-g8hF7872XF=-=Nif5W8TcKuD8F9VZpDFQ=21XtK4Dbg@mail.gmail.com>
	<CADnb78je1Yfmpp8d4ODRaDxSvMjKLFySnCt-iZTTt137VKoCtQ@mail.gmail.com>
Message-ID: <CABirCh97E_xzvnt=Kd9JdZbR4dJJ79KW2BUnw9h7OABVhX4PtQ@mail.gmail.com>

On Fri, Feb 8, 2013 at 10:09 AM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Fri, Feb 8, 2013 at 3:03 PM, Glenn Maynard <glenn at zewt.org> wrote:
> > A compare method is probably useful, since you'd also want
> case-insensitive
> > comparisons for some parts and not others (eg. lowercase protocol and
> host
> > before comparing).
>
> Scheme and host are normalized by the parser already.
>

That's strange.  I'd expect case to round-trip.

Where does this happen for the hostname?  I only see "case" related to ipv6
and scheme.

-- 
Glenn Maynard


From annevk at annevk.nl  Sat Feb  9 00:00:06 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Sat, 9 Feb 2013 08:00:06 +0000
Subject: [whatwg] [URL] Cargo-cult naming in URL and matching
In-Reply-To: <CABirCh97E_xzvnt=Kd9JdZbR4dJJ79KW2BUnw9h7OABVhX4PtQ@mail.gmail.com>
References: <CANr5HFVi7KHpp1w2wrxwWLmBRPfHk-BoYE5KqDy4eA7jKvyDvA@mail.gmail.com>
	<CADnb78hZBXsyMfbH86xFbc96sGeDpARoUFyFuTe7nQpRzmiAiw@mail.gmail.com>
	<CANr5HFWtknWqK1z0zOx-ZY3wbGUjPXyxQOg8U7wORQDrRXK6nA@mail.gmail.com>
	<CADnb78i_JBHUafq5jLrmfE=FvitP_k6V06x19jJQNeDFbUOCQg@mail.gmail.com>
	<CABirCh-g8hF7872XF=-=Nif5W8TcKuD8F9VZpDFQ=21XtK4Dbg@mail.gmail.com>
	<CADnb78je1Yfmpp8d4ODRaDxSvMjKLFySnCt-iZTTt137VKoCtQ@mail.gmail.com>
	<CABirCh97E_xzvnt=Kd9JdZbR4dJJ79KW2BUnw9h7OABVhX4PtQ@mail.gmail.com>
Message-ID: <CADnb78iEP9Mr=bnYkGLerj3JmDe1foXA4-xWgX4C-m0s0wg_1Q@mail.gmail.com>

On Sat, Feb 9, 2013 at 12:32 AM, Glenn Maynard <glenn at zewt.org> wrote:
> That's strange.  I'd expect case to round-trip.

Why?


> Where does this happen for the hostname?  I only see "case" related to ipv6
> and scheme.

Host parsing is not defined yet: http://annevankesteren.nl/2012/11/idna-hell


-- 
http://annevankesteren.nl/


From bobowencode at gmail.com  Sat Feb  9 08:26:12 2013
From: bobowencode at gmail.com (Bob Owen)
Date: Sat, 9 Feb 2013 16:26:12 +0000
Subject: [whatwg] HTML Specification update request: bug 20939
Message-ID: <CA+dJEEDvYM+HKC9vvNF70PXYxz7ATiBdoSmfiFNCXxWyg-u2FQ@mail.gmail.com>

Hi,

While discussing with Boris Zbarsky, some work I am doing on sandboxing for
Mozilla, we realised that the sections in the HTML specification on
browsing context security and browsing context names, could do with some
clarification with regard to the effects of sandboxing.

http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#security-nav
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context-names

The non-normative table, in the browsing context names section, does cover
many of the effects.
However, if the normative text in these two sections is read on its own,
without knowledge of the sandboxing sections, then the reader could easily
come away with an incorrect understanding.

I have raised the following bug detailing all of this.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20939

The bug also contains some suggestions for new rows that could be added to
the non-normative table.

Thanks,
Bob


From jackalmage at gmail.com  Sat Feb  9 08:43:11 2013
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Sat, 9 Feb 2013 09:43:11 -0700
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
In-Reply-To: <CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>
References: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
	<CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>
Message-ID: <CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>

On Thu, Feb 7, 2013 at 6:32 PM, Glenn Maynard <glenn at zewt.org> wrote:
> This is just to say: callbacks are the pattern on on the platform, not
> polling, and WebGL should follow that pattern, not go its own way and make
> up its own conventions.  If people don't understand why the platform's
> conventions are what they are, and think they should be something else,
> please encourage them to come here and discuss it--not to try to make WebGL
> its own isolated island.  That's damaging to WebGL and the platform as a
> whole.

Completely correct, and I agree.

That said, there *are* still some isolated use-cases for polling.  ^_^
 When an event-based approach would potentially deliver far too many
events, with separation between them perhaps less than 1ms, exposing a
polling-based API instead can be useful.  I haven't followed the
Gamepad API lately, but I know this was at least considered for some
of the types of feedback, such as the exact position of joysticks or
pressure on buttons, both of which can change very rapidly in
realistic scenarios.

Outside of these kinds of constraints, though, polling is a no-no, for
the reasons that Glenn gives.

~TJ


From glenn at zewt.org  Sat Feb  9 09:00:00 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Sat, 9 Feb 2013 11:00:00 -0600
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
In-Reply-To: <CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>
References: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
	<CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>
	<CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>
Message-ID: <CABirCh_bR9XvOCEjX_8TyJq+5juzsqr3_7vjkwYen_NF_3bJPw@mail.gmail.com>

On Sat, Feb 9, 2013 at 10:43 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> That said, there *are* still some isolated use-cases for polling.  ^_^
>  When an event-based approach would potentially deliver far too many
> events, with separation between them perhaps less than 1ms, exposing a
> polling-based API instead can be useful.  I haven't followed the
> Gamepad API lately, but I know this was at least considered for some
> of the types of feedback, such as the exact position of joysticks or
> pressure on buttons, both of which can change very rapidly in
> realistic scenarios.
>

A polling API doesn't help you there, since you can't poll every 1ms in
script (certainly not in the UI thread, and probably not reliably even in a
worker).  In fact, since setTimeout will be throttled but events fired by
the browser don't have to be, events can be sent faster than you can poll
in the UI thread (though this is probably a bad idea most of the time).

The solution is probably a matter of buffering the changes, and limiting
how frequently "something was buffered" events fire.  That way, you can get
low-latency, high-time-resolution data if you want it, by reading all a
list of changes made since the last event, without trying to poll at 1kHz
in script.  (I have a vague recollection of proposing exactly this, but I
don't think it went anywhere and I haven't seen any discussion about the
gamepad API here or on -webapps in a long time.)

-- 
Glenn Maynard


From ashley at scirra.com  Mon Feb 11 12:30:39 2013
From: ashley at scirra.com (Ashley Gullen)
Date: Mon, 11 Feb 2013 20:30:39 +0000
Subject: [whatwg] Adding the imageSmoothingEnabled back into 2dContext
 Level 2 spec.
In-Reply-To: <CAGN7qDAf_tBWfhD=EogOpQ_TrZzCkSNk0ijY+FfMa-N7XP+L0w@mail.gmail.com>
References: <dbdbd50110e64b48a7b26e5e26875e2c@SN2PR03MB045.namprd03.prod.outlook.com>
	<CAGN7qDAf_tBWfhD=EogOpQ_TrZzCkSNk0ijY+FfMa-N7XP+L0w@mail.gmail.com>
Message-ID: <CAABs73jN6KOmtgb=aLuY=8mzP2PG7PR3drOHQqpLT+q6FtSVzg@mail.gmail.com>

I would re-emphasise this is important for many game applications.  Here's
an image showing the effect it can have from a recent blog post I wrote:
https://www.scirra.com/images/sampling-point-linear.png
For a game in this style it is essential to be able to force
nearest-neighbour.  Games in that "retro" style are often unplayable
because they look so awful if they get bilinear interpolation forced on
them.  On the other hand, modern hi-res style games which intend to use
bilinear interpolation only look marginally worse if they get
nearest-neighbour.  So I think the existing spec was fine as it was:
imageSmoothingEnabled = false means "require nearest-neighbour
interpolation", imageSmoothingEnabled = true means "any smoothing
algorithm, or nearest-neighbour".

I would also emphasise this should definitely also apply to patterns, for
the same reason: games are likely to use a pattern to render tiles, and
those should be rendered with the same interpolation as everything else.

Ashley



On 8 February 2013 12:25, Rik Cabanier <cabanier at gmail.com> wrote:

> I agree we should bring it back.
>
> Personally, it would be nice that have a more formal definition of what
> smoothing actually means so user agents can implement it similarly.
>
> Rik
>
> On Tue, Feb 5, 2013 at 7:14 AM, Jay Munro <jaymunro at microsoft.com> wrote:
>
> > For CR, we took the imageSmoothingEnable feature out because it hadn't
> > been given a chance to be discussed by the working group. For level 2,
> I'm
> > adding it back in, but asking for any discussion that needs to be made
> > first.
> >
> > Silence will be taken to mean there is no objection, but positive
> > responses are encouraged.  If I don't hear any objections by Monday Feb
> 11,
> > I'll check it in.
> >
> > The following is the pending check in:
> >
> >
> > @@ -40677,6 +40677,10 @@ dictionary <dfn>TrackEventInit</dfn> :
> > <span>EventInit</span> {
> >    // compositing
> >             attribute unrestricted double <span
> > title="dom-context-2d-globalAlpha">globalAlpha</span>; // (default 1.0)
> >             attribute DOMString <span
> >
> title="dom-context-2d-globalCompositeOperation">globalCompositeOperation</span>;
> > // (default source-over)
> > +
> > +  // image smoothing
> > +           attribute boolean <span
> >
> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</span>;
> > // (default true)
> > +
> >  <!--
> >    // v7 we've also received requests for:
> >    - turning off antialiasing to avoid seams when patterns are painted
> > next to each other
> > @@ -40945,7 +40949,8 @@ interface <dfn>Path</dfn> {
> >
> >
> title="dom-context-2d-globalCompositeOperation">globalCompositeOperation</code>,
> > <code
> >     title="dom-context-2d-font">font</code>, <code
> >     title="dom-context-2d-textAlign">textAlign</code>, <code
> > -   title="dom-context-2d-textBaseline">textBaseline</code>.</li>
> > +   title="dom-context-2d-textBaseline">textBaseline</code>, <code
> > +
> >
> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>.</li>
> >    </ul>
> >
> >    <p class="note">The <span>current default path</span> and the
> > @@ -43416,10 +43421,16 @@ try {
> >
> >    <p>If the original image data is a bitmap image, the value painted
> >    at a point in the area of the repetitions is computed by filtering
> > -  the original image data. The user agent may use any filtering
> > +  the original image data. If the <code
> > +
> >
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> > +  then the user agent may use any filtering
> >    algorithm (for example bilinear interpolation or nearest-neighbor).
> > -  When the filtering algorithm requires a pixel value from outside the
> > -  original image data, it must instead use the value from wrapping the
> > +  If the <code
> > +
> >
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> > +  attribute is set to false, the image must be rendered using
> > +  nearest-neighbor interpolation. When such the filtering algorithm
> > +  requires a pixel value from outside the original image data, it
> > +  must instead use the value from wrapping the
> >    pixel's coordinates to the original image's dimensions. (That is,
> >    the filter uses 'repeat' behavior, regardless of the value of
> >    <var title="">repetition</var>.)
> > @@ -44539,6 +44550,18 @@ v6DVT (also check for '- -' bits in the part
> > above) -->
> >    <p class="note">This specification does not define the algorithm to
> >    use when scaling the image, if necessary.</p>
> >
> > +  <p>If the <code
> > +
> >
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> > +  attribute is set to true, then the user agent should attempt to
> > +  apply a smoothing algorithm to the image data when it is scaled.
> > +  Otherwise, the image must be rendered using nearest-neighbor
> > +  interpolation.</p>
> > +
> > +  <p class="note">This specification does not define the precise
> > +  algorithm to use when scaling an image when the <code
> > +
> >
>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
> > +  attribute is set to true.</p>
> > +
> >    <p class="note">When a canvas is drawn onto itself, the <span>drawing
> >    model</span> requires the source to be copied before the image is
> drawn
> >    back onto the canvas, so it is possible to copy parts of a canvas
> > @@ -46040,6 +46063,36 @@ function AddCloud(data, x, y) { ... }</pre>
> >
> >    </div>
> >
> > +  <h6>Image smoothing</h6>
> > +
> > +  <dl class="domintro">
> > +
> > +   <dt><var title="">context</var> . <code
> >
> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code> [
> > = <var title="">value</var> ]</dt>
> > +
> > +   <dd>
> > +
> > +    <p>Returns whether pattern fills and the <code
> > +    title="dom-context-2d-drawImage">drawImage()</code> method will
> > +    attempt to smooth images if they have to rescale them (as opposed
> > +    to just rendering the images with "big pixels").</p>
> > +
> > +    <p>Can be set, to change whether images are smoothed (true) or not
> > +    (false).</p>
> > +
> > +   </dd>
> > +
> > +  </dl>
> > +
> > +  <div class="impl">
> > +
> > +  <p>The <dfn
> > +
> >
>  title="dom-context-2d-imageSmoothingEnabled"><code>imageSmoothingEnabled</code></dfn>
> > +  attribute, on getting, must return the last value it was set to. On
> > +  setting, it must be set to the new value. When the
> > +  <code>CanvasRenderingContext2D</code> object is created, the
> > +  attribute must be set to true.</p>
> > +
> > +  </div>
> >
> >
> >
> >
> >
> >
> >
>


From anewpage.media at gmail.com  Mon Feb 11 14:33:06 2013
From: anewpage.media at gmail.com (Brian Blakely)
Date: Mon, 11 Feb 2013 17:33:06 -0500
Subject: [whatwg] Canonical Image and Color
Message-ID: <CAJGQg4EwgYOqf5y67Q_=WN=UewBZvkXzs5ZG8wQDrD2AM3GGnQ@mail.gmail.com>

* Proposal

Meta elements for defining a canonical image and color to be associated
with the page(s) in which they are included.  This is intended for use by
user agents and third-party applications (such as social networks),
referred to collectively as "parsers" in this document.  It is inspired by
Microsoft's recent work in site pinning and Apple's "standalone" webapp
implementation in iOS Safari.

* Example

<meta name="image" content="path/to/image.png" />
<meta name="color" content="#123456" />

* Image

Value may be a relative or absolute path to file.  No restrictions on
filetype or resolution.  May also be an animated image or video format.
 Filetypes supported and handling therein is relegated to the parser.

* Color

Value may be any of the CSS named colors, hex codes, RGB, HSL and their
alpha-channel variants.  Once attained by the parser, use is at that
parser's discretion.


From jackalmage at gmail.com  Mon Feb 11 14:41:09 2013
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 11 Feb 2013 14:41:09 -0800
Subject: [whatwg] Canonical Image and Color
In-Reply-To: <CAJGQg4EwgYOqf5y67Q_=WN=UewBZvkXzs5ZG8wQDrD2AM3GGnQ@mail.gmail.com>
References: <CAJGQg4EwgYOqf5y67Q_=WN=UewBZvkXzs5ZG8wQDrD2AM3GGnQ@mail.gmail.com>
Message-ID: <CAAWBYDC_T=-GgUtpyApWUsaQ3yDuHvQiZKg0BzB8e44RZedGZw@mail.gmail.com>

On Mon, Feb 11, 2013 at 2:33 PM, Brian Blakely <anewpage.media at gmail.com> wrote:
> * Proposal
>
> Meta elements for defining a canonical image and color to be associated
> with the page(s) in which they are included.  This is intended for use by
> user agents and third-party applications (such as social networks),
> referred to collectively as "parsers" in this document.  It is inspired by
> Microsoft's recent work in site pinning and Apple's "standalone" webapp
> implementation in iOS Safari.

Can you elaborate?  I have no idea what UAs and third-party apps would
do with a "canonical image" or "canonical color".

~TJ


From anewpage.media at gmail.com  Mon Feb 11 16:17:25 2013
From: anewpage.media at gmail.com (Brian Blakely)
Date: Mon, 11 Feb 2013 19:17:25 -0500
Subject: [whatwg] Canonical Image and Color
In-Reply-To: <CAAWBYDC_T=-GgUtpyApWUsaQ3yDuHvQiZKg0BzB8e44RZedGZw@mail.gmail.com>
References: <CAJGQg4EwgYOqf5y67Q_=WN=UewBZvkXzs5ZG8wQDrD2AM3GGnQ@mail.gmail.com>
	<CAAWBYDC_T=-GgUtpyApWUsaQ3yDuHvQiZKg0BzB8e44RZedGZw@mail.gmail.com>
Message-ID: <CAJGQg4FY4WHvCK09dG=Fs=_w31oEuJ-CaraNH7uMhCxjYbmhyQ@mail.gmail.com>

Sure thing.  Let me go through the use cases that I see as applicable
today, derived from instances where an existing vendor or service currently
utilizes a non-standard implementation.

* Social network sharing

Facebook currently scrapes "OpenGraph tags" from shared pages to create a
content snippet.  One such tag is og:image, which specifies the image to
display in that snippet.  Twitter and Google+ use these same tags in
addition to their own implementations for developers.  For the title and
description of the snippet, scrapers will fall back to <title> and the meta
description.  A canonical image would serve the same purpose, but for
visual content.

* News aggregation

Flipboard, a highly visual, magazine-style news and article reader,
displays a hero image from the target page.  It does this by parsing and
analyzing the <img> elements in a page, sometimes displaying a non-optimal
or even vacant result.  A canonical image would allow developers to control
this kind of representation with more specificity, and provide the 3rd
party app with another presentation option.

* OS Integration

Apple currently parses their own "apple-touch-icon" element that specifies
which image will serve as a web application's icon after the user has added
to the homescreen.  Android's browser uses this same element, while
Microsoft uses a similar "msapplication-TileImage".  When these element is
not specified, a screenshot of the website is used instead or, in
Microsoft's case, the favicon.  Firefox OS has still another means of
implementation for this.  A canonical image could either replace or provide
an additional fallback for this functionality.

* Color

In all these cases, a canonical color allows external parsers to provide
further branding or additional flourish in their representation of apps and
pages.  Microsoft's "msapplication-TileColor" and
"msapplication-navbutton-color" elements aim to fulfill this purpose in IE
by coloring the app's tile on the Windows 8 homescreen and IE's own
navigation UI, respectively.


On Mon, Feb 11, 2013 at 5:41 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Mon, Feb 11, 2013 at 2:33 PM, Brian Blakely <anewpage.media at gmail.com>
> wrote:
> > * Proposal
> >
> > Meta elements for defining a canonical image and color to be associated
> > with the page(s) in which they are included.  This is intended for use by
> > user agents and third-party applications (such as social networks),
> > referred to collectively as "parsers" in this document.  It is inspired
> by
> > Microsoft's recent work in site pinning and Apple's "standalone" webapp
> > implementation in iOS Safari.
>
> Can you elaborate?  I have no idea what UAs and third-party apps would
> do with a "canonical image" or "canonical color".
>
> ~TJ
>


From esprehn at gmail.com  Mon Feb 11 20:52:43 2013
From: esprehn at gmail.com (Elliott Sprehn)
Date: Mon, 11 Feb 2013 20:52:43 -0800
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
In-Reply-To: <CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>
References: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
	<CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>
	<CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>
Message-ID: <CAPJYB1hxRKU6UAcQMDALTb=jQR-0c+Eg-hPsUn3fiHp=eaenOw@mail.gmail.com>

On Sat, Feb 9, 2013 at 8:43 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:

> On Thu, Feb 7, 2013 at 6:32 PM, Glenn Maynard <glenn at zewt.org> wrote:
> > This is just to say: callbacks are the pattern on on the platform, not
> > polling, and WebGL should follow that pattern, not go its own way and
> make
> > up its own conventions.  If people don't understand why the platform's
> > conventions are what they are, and think they should be something else,
> > please encourage them to come here and discuss it--not to try to make
> WebGL
> > its own isolated island.  That's damaging to WebGL and the platform as a
> > whole.
>
> Completely correct, and I agree.
>
> That said, there *are* still some isolated use-cases for polling.  ^_^
>  When an event-based approach would potentially deliver far too many
> events, with separation between them perhaps less than 1ms, exposing a
> polling-based API instead can be useful.


I disagree, there's no reasonable reason for polling. If the events would
fire too frequently then the API should be designed to batch up the
notifications and fire at specific checkpoints like rAf or end of micro
task.

There's no reason to poll on the web.

- E


From jackalmage at gmail.com  Mon Feb 11 22:17:58 2013
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 11 Feb 2013 22:17:58 -0800
Subject: [whatwg] Canonical Image and Color
In-Reply-To: <CAJGQg4FY4WHvCK09dG=Fs=_w31oEuJ-CaraNH7uMhCxjYbmhyQ@mail.gmail.com>
References: <CAJGQg4EwgYOqf5y67Q_=WN=UewBZvkXzs5ZG8wQDrD2AM3GGnQ@mail.gmail.com>
	<CAAWBYDC_T=-GgUtpyApWUsaQ3yDuHvQiZKg0BzB8e44RZedGZw@mail.gmail.com>
	<CAJGQg4FY4WHvCK09dG=Fs=_w31oEuJ-CaraNH7uMhCxjYbmhyQ@mail.gmail.com>
Message-ID: <CAAWBYDBhDSy0VBEQmSnF6L=FD_6fRq_+9RjfWr3MmRUNuCQrAA@mail.gmail.com>

On Mon, Feb 11, 2013 at 4:17 PM, Brian Blakely <anewpage.media at gmail.com> wrote:
> Sure thing.  Let me go through the use cases that I see as applicable today,
> derived from instances where an existing vendor or service currently
> utilizes a non-standard implementation.
>
> * Social network sharing
>
> Facebook currently scrapes "OpenGraph tags" from shared pages to create a
> content snippet.  One such tag is og:image, which specifies the image to
> display in that snippet.  Twitter and Google+ use these same tags in
> addition to their own implementations for developers.  For the title and
> description of the snippet, scrapers will fall back to <title> and the meta
> description.  A canonical image would serve the same purpose, but for visual
> content.
>
> * News aggregation
>
> Flipboard, a highly visual, magazine-style news and article reader, displays
> a hero image from the target page.  It does this by parsing and analyzing
> the <img> elements in a page, sometimes displaying a non-optimal or even
> vacant result.  A canonical image would allow developers to control this
> kind of representation with more specificity, and provide the 3rd party app
> with another presentation option.
>
> * OS Integration
>
> Apple currently parses their own "apple-touch-icon" element that specifies
> which image will serve as a web application's icon after the user has added
> to the homescreen.  Android's browser uses this same element, while
> Microsoft uses a similar "msapplication-TileImage".  When these element is
> not specified, a screenshot of the website is used instead or, in
> Microsoft's case, the favicon.  Firefox OS has still another means of
> implementation for this.  A canonical image could either replace or provide
> an additional fallback for this functionality.

These all seem fairly reasonable.  Are you sure that all of the
use-cases would use the same image?

> * Color
>
> In all these cases, a canonical color allows external parsers to provide
> further branding or additional flourish in their representation of apps and
> pages.  Microsoft's "msapplication-TileColor" and
> "msapplication-navbutton-color" elements aim to fulfill this purpose in IE
> by coloring the app's tile on the Windows 8 homescreen and IE's own
> navigation UI, respectively.

Sure, seems reasonable.

~TJ


From dhtmlkitchen at gmail.com  Mon Feb 11 22:56:52 2013
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 11 Feb 2013 22:56:52 -0800
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
In-Reply-To: <CABirCh_bR9XvOCEjX_8TyJq+5juzsqr3_7vjkwYen_NF_3bJPw@mail.gmail.com>
References: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
	<CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>
	<CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>
	<CABirCh_bR9XvOCEjX_8TyJq+5juzsqr3_7vjkwYen_NF_3bJPw@mail.gmail.com>
Message-ID: <CABZUbM35r-oFE1B4ZtAAAb=gUQcL_xujjCHniksYcsbhx1POsg@mail.gmail.com>

On 2/9/13, Glenn Maynard <glenn at zewt.org> wrote:
> On Sat, Feb 9, 2013 at 10:43 AM, Tab Atkins Jr.
> <jackalmage at gmail.com>wrote:
>
>> That said, there *are* still some isolated use-cases for polling.  ^_^
>>  When an event-based approach would potentially deliver far too many
>> events, with separation between them perhaps less than 1ms, exposing a
>> polling-based API instead can be useful.  I haven't followed the
>> Gamepad API lately, but I know this was at least considered for some
>> of the types of feedback, such as the exact position of joysticks or
>> pressure on buttons, both of which can change very rapidly in
>> realistic scenarios.
>>
>
> A polling API doesn't help you there, since you can't poll every 1ms in
> script (certainly not in the UI thread, and probably not reliably even in a
> worker).  In fact, since setTimeout will be throttled but events fired by
> the browser don't have to be, events can be sent faster than you can poll
> in the UI thread (though this is probably a bad idea most of the time).
>
> The solution is probably a matter of buffering the changes, and limiting
> how frequently "something was buffered" events fire.
Are you proposing event quantization threshold?


That type of solution can work for handling the situation where the
event fires too many times like resize and mousemove events. But it is
a little cumbersome to write out event throttlers by hand.

The MOUSE_MOVE_THRESHOLD is no phenomenon really, but useful in such
situations and I'm not boasting at all. Here is the explanation of my
idea which I started using around 2007, IIRC:
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/bc5274b75820e5ff/96fbac718201ebbf?pli=1

Anyway, if the idea is to set an event quantization threshold, it
should be done at the time of registering the callback. And I see no
good reason why that should be modifiable. A hypothetical a 'quant'
property example (it can't be expected to work, just trying to sketch
out the idea).

 var listener = {
  handleEvent : function(ev) { console.log(ev); },
  quant : 40
 };
//  or even
 function handleEvent (ev) { console.log(ev); }
 handleEvent.quant = 40;

 var booleanParametersSuck = false;

 document.addEventListener("mousemove",  listener, booleanParametersSuck);

That way, you can get
> low-latency, high-time-resolution data if you want it, by reading all a
> list of changes made since the last event, without trying to poll at 1kHz
> in script.  (I have a vague recollection of proposing exactly this, but I
> don't think it went anywhere and I haven't seen any discussion about the
> gamepad API here or on -webapps in a long time.)
>
Planck time is the smallest unit of time. Where does it go?
-- 
Garrett
Twitter: @xkit
personx.tumblr.com


From dhtmlkitchen at gmail.com  Mon Feb 11 23:28:06 2013
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 11 Feb 2013 23:28:06 -0800
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
In-Reply-To: <CABZUbM35r-oFE1B4ZtAAAb=gUQcL_xujjCHniksYcsbhx1POsg@mail.gmail.com>
References: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
	<CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>
	<CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>
	<CABirCh_bR9XvOCEjX_8TyJq+5juzsqr3_7vjkwYen_NF_3bJPw@mail.gmail.com>
	<CABZUbM35r-oFE1B4ZtAAAb=gUQcL_xujjCHniksYcsbhx1POsg@mail.gmail.com>
Message-ID: <CABZUbM1ExTEcZaRsbbuVrFqYFugyHBkzpOM5MsJikbSZSuzmQA@mail.gmail.com>

On 2/11/13, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

[...]
>
>  var listener = {
>   handleEvent : function(ev) { console.log(ev); },
>   quant : 40
>  };
> //  or even
>  function handleEvent (ev) { console.log(ev); }
>  handleEvent.quant = 40;
>
Second example should have been
 function listener(ev) { console.log(ev); }
 listener.quant = 40;

>  var booleanParametersSuck = false;
>
>  document.addEventListener("mousemove",  listener, booleanParametersSuck);


Also, for those unfamiliar with the standard specification of
EventListener, particularly with the second parameter being an Object
with a handleEvent property that is a Function:
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener
-- 
Garrett
Twitter: @xkit
personx.tumblr.com


From mounir at lamouri.fr  Tue Feb 12 09:20:49 2013
From: mounir at lamouri.fr (Mounir Lamouri)
Date: Tue, 12 Feb 2013 17:20:49 +0000
Subject: [whatwg] Why do we have <input type='month'> and <input
	type='week'>?
In-Reply-To: <CABirCh_ua8cumCqZcASOTOdwCmsi0yPdVYvoRT23eBstszdy2A@mail.gmail.com>
References: <510988C1.1040900@lamouri.fr> <op.wrry8kurh8on37@bruce-pc>
	<CABirCh_ua8cumCqZcASOTOdwCmsi0yPdVYvoRT23eBstszdy2A@mail.gmail.com>
Message-ID: <511A79F1.5050501@lamouri.fr>

On 01/02/13 15:39, Glenn Maynard wrote:
> On Thu, Jan 31, 2013 at 6:20 AM, Bruce Lawson <brucel at opera.com> wrote:
> 
>> The use-case for an input type I imagine is that a browser can have a
>> select-like UI (Jan, Feb, March, April ...) which, in a French language
>> browser becomes "Janvier, Fevrier, Mars, Avril .. " (or even Vend?miaire to
>> Fructidor for FRC fans).
>>
> 
> FYI, I would find this annoying.  CC expiry entry forms are typically
> select boxes containing 01-12.  The text lines up with what's on my credit
> card, so I don't have to translate "07" to "July" in my head when entering
> it off of my card.  Any month picker for credit card expiry dates should
> always have month numbers (of course, names *in addition* to numbers are
> fine, though probably pointless).

That's exactly why I think the use case is weak: it is easy to implement
a month picker:
<select name='month'><!--fill with option for each
month--></select><select name='year'><!-- fill with option for each year
you want to show --></select>

Given how easy it is, authors might quickly end up expecting specific
behaviour that the UAs do not provide. For example, Having "01 -
January" or "January - 01" or even "01" instead of "January". They could
want the year to show up as 2 digits or 1 digit, as a textfield, a
<select> or an <input type='number'> with a min and a max.
Anyway, I still believe that the pros of <input type='month'> are quite
low but in another hand, it shouldn't cost too much for UA to implement
it if or date-time-related types are already implemented and it provides
a real benefit on Mobile.

Regarding week, I still believe that the use cases are pretty weak but
the most important issue is that there is no good UI for this on Mobile
AFAIK.

Cheers,
--
Mounir


From jackalmage at gmail.com  Tue Feb 12 09:26:16 2013
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 12 Feb 2013 09:26:16 -0800
Subject: [whatwg] Why do we have <input type='month'> and <input
	type='week'>?
In-Reply-To: <511A79F1.5050501@lamouri.fr>
References: <510988C1.1040900@lamouri.fr> <op.wrry8kurh8on37@bruce-pc>
	<CABirCh_ua8cumCqZcASOTOdwCmsi0yPdVYvoRT23eBstszdy2A@mail.gmail.com>
	<511A79F1.5050501@lamouri.fr>
Message-ID: <CAAWBYDCQppyNtUmr-xAt0Tn9Ydbd1bE6WYQTVSfThvZCPGJoVw@mail.gmail.com>

On Tue, Feb 12, 2013 at 9:20 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:
> On 01/02/13 15:39, Glenn Maynard wrote:
>> FYI, I would find this annoying.  CC expiry entry forms are typically
>> select boxes containing 01-12.  The text lines up with what's on my credit
>> card, so I don't have to translate "07" to "July" in my head when entering
>> it off of my card.  Any month picker for credit card expiry dates should
>> always have month numbers (of course, names *in addition* to numbers are
>> fine, though probably pointless).
>
> That's exactly why I think the use case is weak: it is easy to implement
> a month picker:
> <select name='month'><!--fill with option for each
> month--></select><select name='year'><!-- fill with option for each year
> you want to show --></select>
>
> Given how easy it is, authors might quickly end up expecting specific
> behaviour that the UAs do not provide. For example, Having "01 -
> January" or "January - 01" or even "01" instead of "January". They could
> want the year to show up as 2 digits or 1 digit, as a textfield, a
> <select> or an <input type='number'> with a min and a max.
> Anyway, I still believe that the pros of <input type='month'> are quite
> low but in another hand, it shouldn't cost too much for UA to implement
> it if or date-time-related types are already implemented and it provides
> a real benefit on Mobile.

The fact that authors today have a random assortment of displays for
the exact same feature (credit card expirys) is something that would
be great to fix, not bemoan as a loss to the world. ^_^

~TJ


From jkorpela at cs.tut.fi  Tue Feb 12 09:39:50 2013
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Tue, 12 Feb 2013 19:39:50 +0200
Subject: [whatwg] Why do we have <input type='month'> and <input
	type='week'>?
In-Reply-To: <CAAWBYDCQppyNtUmr-xAt0Tn9Ydbd1bE6WYQTVSfThvZCPGJoVw@mail.gmail.com>
References: <510988C1.1040900@lamouri.fr> <op.wrry8kurh8on37@bruce-pc>
	<CABirCh_ua8cumCqZcASOTOdwCmsi0yPdVYvoRT23eBstszdy2A@mail.gmail.com>
	<511A79F1.5050501@lamouri.fr>
	<CAAWBYDCQppyNtUmr-xAt0Tn9Ydbd1bE6WYQTVSfThvZCPGJoVw@mail.gmail.com>
Message-ID: <511A7E66.7010906@cs.tut.fi>

2013-02-12 19:26, Tab Atkins Jr. wrote:

> The fact that authors today have a random assortment of displays for
> the exact same feature (credit card expirys) is something that would
> be great to fix, not bemoan as a loss to the world. ^_^

Well, maybe, from some point of view, but is there really something to 
be fixed, and is it probable that <input type=month> would fix it?

I have seen many input widgets for such data and used them a lot in test 
purchases. In general, the more advanced they try to be, the more 
annoying they get. I can type "03/15", or whatever reads in the card, 
rather fast. But if I have to pick things up from dropdowns or click on 
something in a calendar picker, I surely hope I won't need to do this a 
dozen more times.

What are the odds that browser vendors will implement <input type=month> 
in a simple manner that allows fast typing as one input method? Rather 
small I think.

This would make the most obvious, and perhaps the most common, use for 
<input type=month> a case *against* it.  Credit card expiry month is 
best handled with a text input field, with suitable checks on the input 
string. There may be *other* cases where graphic widgets are good when 
selecting a month, but authors can use libraries for such purpose, and I 
don't see any particular reason why this should be standardized across 
pages but not across browsers.

Even if <input type=month> became widely supported, many, probably most, 
authors will keep using libraries or their own code, because they get 
consistent look and feel and functionality across browsers. Some authors 
would be misled into using <input type=month> for any month input 
because that's "logical" or "semantic" (as it is in a sense), but this 
will create questionable user experience in many common cases.

Yucca



From jackalmage at gmail.com  Tue Feb 12 09:47:47 2013
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 12 Feb 2013 09:47:47 -0800
Subject: [whatwg] Why do we have <input type='month'> and <input
	type='week'>?
In-Reply-To: <511A7E66.7010906@cs.tut.fi>
References: <510988C1.1040900@lamouri.fr> <op.wrry8kurh8on37@bruce-pc>
	<CABirCh_ua8cumCqZcASOTOdwCmsi0yPdVYvoRT23eBstszdy2A@mail.gmail.com>
	<511A79F1.5050501@lamouri.fr>
	<CAAWBYDCQppyNtUmr-xAt0Tn9Ydbd1bE6WYQTVSfThvZCPGJoVw@mail.gmail.com>
	<511A7E66.7010906@cs.tut.fi>
Message-ID: <CAAWBYDBxWHZwZJqiS=T3JDBfXUEcQ36gMcfgX8cJDyOSoXDWYw@mail.gmail.com>

On Tue, Feb 12, 2013 at 9:39 AM, Jukka K. Korpela <jkorpela at cs.tut.fi> wrote:
> 2013-02-12 19:26, Tab Atkins Jr. wrote:
>> The fact that authors today have a random assortment of displays for
>> the exact same feature (credit card expirys) is something that would
>> be great to fix, not bemoan as a loss to the world. ^_^
>
> Well, maybe, from some point of view, but is there really something to be
> fixed, and is it probable that <input type=month> would fix it?
>
> I have seen many input widgets for such data and used them a lot in test
> purchases. In general, the more advanced they try to be, the more annoying
> they get. I can type "03/15", or whatever reads in the card, rather fast.
> But if I have to pick things up from dropdowns or click on something in a
> calendar picker, I surely hope I won't need to do this a dozen more times.
>
> What are the odds that browser vendors will implement <input type=month> in
> a simple manner that allows fast typing as one input method? Rather small I
> think.
>
> This would make the most obvious, and perhaps the most common, use for
> <input type=month> a case *against* it.  Credit card expiry month is best
> handled with a text input field, with suitable checks on the input string.
> There may be *other* cases where graphic widgets are good when selecting a
> month, but authors can use libraries for such purpose, and I don't see any
> particular reason why this should be standardized across pages but not
> across browsers.

This argument appears to apply equally well to all the date inputs,
and perhaps most of the other new inputs.  I believe it's wrong.

* Most people don't type very fast.  We email-happy people are an
exception.  For most, clicking on things is faster and easier.
* Experience shows that most authors appear to prefer a pair of
dropdowns for selecting month and year, rather than a text input.
Might as well move closer to author expectations.
* Text inputs are permanently subject to the vagaries of whatever
arcane syntax the author happened to want (or didn't want, but
accidentally required when they miswrote their regex) - Do I just type
two numbers with a slash? Or do I use a dash? Or a space?  What if I
use a slash surrounded by spaces? Or do I use the month name? Long or
short name? Two digit or four digit year? - while visual inputs put
your options in front of you and avoid all of that.

> Even if <input type=month> became widely supported, many, probably most,
> authors will keep using libraries or their own code, because they get
> consistent look and feel and functionality across browsers. Some authors
> would be misled into using <input type=month> for any month input because
> that's "logical" or "semantic" (as it is in a sense), but this will create
> questionable user experience in many common cases.

This same argument keeps getting deployed against type="date".  We'll
see what actually happens.  I expect (and deeply hope) that the ease
of use of the built-ins will win the day, once they're supported on
every browser sites expect their visitors to use.

~TJ


From cabanier at gmail.com  Tue Feb 12 09:49:55 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Wed, 13 Feb 2013 04:49:55 +1100
Subject: [whatwg] Adding the imageSmoothingEnabled back into 2dContext
 Level 2 spec.
In-Reply-To: <CAABs73jN6KOmtgb=aLuY=8mzP2PG7PR3drOHQqpLT+q6FtSVzg@mail.gmail.com>
References: <dbdbd50110e64b48a7b26e5e26875e2c@SN2PR03MB045.namprd03.prod.outlook.com>
	<CAGN7qDAf_tBWfhD=EogOpQ_TrZzCkSNk0ijY+FfMa-N7XP+L0w@mail.gmail.com>
	<CAABs73jN6KOmtgb=aLuY=8mzP2PG7PR3drOHQqpLT+q6FtSVzg@mail.gmail.com>
Message-ID: <CAGN7qDBbMHBJwTH7gZjrb1WH+21WPR-hzrpk0e0EvdvnaCqUsQ@mail.gmail.com>

Is there an implementation report on this?
If browsers stabilized on this feature, it might be time to drop the prefix.

On Tue, Feb 12, 2013 at 7:30 AM, Ashley Gullen <ashley at scirra.com> wrote:

> I would re-emphasise this is important for many game applications.  Here's
> an image showing the effect it can have from a recent blog post I wrote:
> https://www.scirra.com/images/sampling-point-linear.png
> For a game in this style it is essential to be able to force
> nearest-neighbour.  Games in that "retro" style are often unplayable
> because they look so awful if they get bilinear interpolation forced on
> them.  On the other hand, modern hi-res style games which intend to use
> bilinear interpolation only look marginally worse if they get
> nearest-neighbour.  So I think the existing spec was fine as it was:
> imageSmoothingEnabled = false means "require nearest-neighbour
> interpolation", imageSmoothingEnabled = true means "any smoothing
> algorithm, or nearest-neighbour".
>
> I would also emphasise this should definitely also apply to patterns, for
> the same reason: games are likely to use a pattern to render tiles, and
> those should be rendered with the same interpolation as everything else.
>
> Ashley
>
>
>
> On 8 February 2013 12:25, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> I agree we should bring it back.
>>
>> Personally, it would be nice that have a more formal definition of what
>> smoothing actually means so user agents can implement it similarly.
>>
>> Rik
>>
>> On Tue, Feb 5, 2013 at 7:14 AM, Jay Munro <jaymunro at microsoft.com> wrote:
>>
>> > For CR, we took the imageSmoothingEnable feature out because it hadn't
>> > been given a chance to be discussed by the working group. For level 2,
>> I'm
>> > adding it back in, but asking for any discussion that needs to be made
>> > first.
>> >
>> > Silence will be taken to mean there is no objection, but positive
>> > responses are encouraged.  If I don't hear any objections by Monday Feb
>> 11,
>> > I'll check it in.
>> >
>> > The following is the pending check in:
>> >
>> >
>> > @@ -40677,6 +40677,10 @@ dictionary <dfn>TrackEventInit</dfn> :
>> > <span>EventInit</span> {
>> >    // compositing
>> >             attribute unrestricted double <span
>> > title="dom-context-2d-globalAlpha">globalAlpha</span>; // (default 1.0)
>> >             attribute DOMString <span
>> >
>> title="dom-context-2d-globalCompositeOperation">globalCompositeOperation</span>;
>> > // (default source-over)
>> > +
>> > +  // image smoothing
>> > +           attribute boolean <span
>> >
>> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</span>;
>> > // (default true)
>> > +
>> >  <!--
>> >    // v7 we've also received requests for:
>> >    - turning off antialiasing to avoid seams when patterns are painted
>> > next to each other
>> > @@ -40945,7 +40949,8 @@ interface <dfn>Path</dfn> {
>> >
>> >
>> title="dom-context-2d-globalCompositeOperation">globalCompositeOperation</code>,
>> > <code
>> >     title="dom-context-2d-font">font</code>, <code
>> >     title="dom-context-2d-textAlign">textAlign</code>, <code
>> > -   title="dom-context-2d-textBaseline">textBaseline</code>.</li>
>> > +   title="dom-context-2d-textBaseline">textBaseline</code>, <code
>> > +
>> >
>> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>.</li>
>> >    </ul>
>> >
>> >    <p class="note">The <span>current default path</span> and the
>> > @@ -43416,10 +43421,16 @@ try {
>> >
>> >    <p>If the original image data is a bitmap image, the value painted
>> >    at a point in the area of the repetitions is computed by filtering
>> > -  the original image data. The user agent may use any filtering
>> > +  the original image data. If the <code
>> > +
>> >
>>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
>> > +  then the user agent may use any filtering
>> >    algorithm (for example bilinear interpolation or nearest-neighbor).
>> > -  When the filtering algorithm requires a pixel value from outside the
>> > -  original image data, it must instead use the value from wrapping the
>> > +  If the <code
>> > +
>> >
>>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
>> > +  attribute is set to false, the image must be rendered using
>> > +  nearest-neighbor interpolation. When such the filtering algorithm
>> > +  requires a pixel value from outside the original image data, it
>> > +  must instead use the value from wrapping the
>> >    pixel's coordinates to the original image's dimensions. (That is,
>> >    the filter uses 'repeat' behavior, regardless of the value of
>> >    <var title="">repetition</var>.)
>> > @@ -44539,6 +44550,18 @@ v6DVT (also check for '- -' bits in the part
>> > above) -->
>> >    <p class="note">This specification does not define the algorithm to
>> >    use when scaling the image, if necessary.</p>
>> >
>> > +  <p>If the <code
>> > +
>> >
>>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
>> > +  attribute is set to true, then the user agent should attempt to
>> > +  apply a smoothing algorithm to the image data when it is scaled.
>> > +  Otherwise, the image must be rendered using nearest-neighbor
>> > +  interpolation.</p>
>> > +
>> > +  <p class="note">This specification does not define the precise
>> > +  algorithm to use when scaling an image when the <code
>> > +
>> >
>>  title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code>
>> > +  attribute is set to true.</p>
>> > +
>> >    <p class="note">When a canvas is drawn onto itself, the <span>drawing
>> >    model</span> requires the source to be copied before the image is
>> drawn
>> >    back onto the canvas, so it is possible to copy parts of a canvas
>> > @@ -46040,6 +46063,36 @@ function AddCloud(data, x, y) { ... }</pre>
>> >
>> >    </div>
>> >
>> > +  <h6>Image smoothing</h6>
>> > +
>> > +  <dl class="domintro">
>> > +
>> > +   <dt><var title="">context</var> . <code
>> >
>> title="dom-context-2d-imageSmoothingEnabled">imageSmoothingEnabled</code> [
>> > = <var title="">value</var> ]</dt>
>> > +
>> > +   <dd>
>> > +
>> > +    <p>Returns whether pattern fills and the <code
>> > +    title="dom-context-2d-drawImage">drawImage()</code> method will
>> > +    attempt to smooth images if they have to rescale them (as opposed
>> > +    to just rendering the images with "big pixels").</p>
>> > +
>> > +    <p>Can be set, to change whether images are smoothed (true) or not
>> > +    (false).</p>
>> > +
>> > +   </dd>
>> > +
>> > +  </dl>
>> > +
>> > +  <div class="impl">
>> > +
>> > +  <p>The <dfn
>> > +
>> >
>>  title="dom-context-2d-imageSmoothingEnabled"><code>imageSmoothingEnabled</code></dfn>
>> > +  attribute, on getting, must return the last value it was set to. On
>> > +  setting, it must be set to the new value. When the
>> > +  <code>CanvasRenderingContext2D</code> object is created, the
>> > +  attribute must be set to true.</p>
>> > +
>> > +  </div>
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>
>


From senorblanco at chromium.org  Tue Feb 12 14:56:49 2013
From: senorblanco at chromium.org (Stephen White)
Date: Tue, 12 Feb 2013 17:56:49 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
Message-ID: <CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>

On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 29 Mar 2012, Jeremy Apthorp wrote:
> > On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp <jeremya at chromium.org
> >wrote:
> > > On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson <ian at hixie.ch> wrote:
> > >> On Fri, 13 Jan 2012, Jeremy Apthorp wrote:
> > >> >
> > >> > I'd like to draw non-antialiased lines in a <canvas>. Currently it
> > >> > seems that the only way to do this is to directly access the pixel
> > >> > data.
> > >> >
> > >> > Is there a reason there's no way to turn off antialiasing?
> > >>
> > >> What's the use case?
> > >
> > > Pixel-art style games.
> >
> > Specifically: even with the new image smoothing stuff in place for
> > drawImage, a 1:2 diagonal line will still be anti-aliased (only the
> > antialiasing will look silly scaled up to 2x).
>
> Do you have an example of a game where lines are drawn using a line API
> without antialiasing, then scaled up? Most "pixel art" games I've seen
> tend to use bitmaps for that kind of thing.
>
>
> On Mon, 12 Nov 2012, Justin Novosad wrote:
> >
> > For many types of apps, DOM-based rendering is uncompetitively slow
> > [so we should make text rendering in canvas more controllable]
>
> This seems like something we should fix, not something we should work
> around by having people use canvas instead. Using canvas has all kinds of
> terrible side-effects, like reducing the likely accessibility of the page,
> making searcheability much worse, etc.
>
> Also, do you have any metrics showing the magnitude of this problem on
> real-world sites that might consider using canvas instead?
>
>
> > If LCD text were enable-able, authors would have to be mindful of a
> > number of caveats in order to avoid rendering artifacts.
>
> Do we have any reason to believe the majority of authors would make the
> right decisions here?
>
> (The main reason we haven't provided control over things like antialiasing
> is that many authors tend to make terribly bad decisions.) (Before anyone
> gets offended, by the way: that you are reading this almost guarantees
> that you are above average in terms of authoring ability.)
>
>
> On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote:
> >
> > We'd have to define what happens when you use subpixel antialiasing
> > "incorrectly", because we can be pretty sure authors will use it
> > incorrectly and expect to get interoperable behavior.
>
> That's certainly true.
>
>
> > Mozilla supports a "mozOpaque" attribute which makes the canvas buffer
> > RGBX (initialized to solid black) and enables subpixel antialiasing for
> > most text drawing. That might be enough to address your use-cases.
>
> I haven't specified this; if other vendors intend to implement this let me
> know and I can spec it. I'm not sure it's worth it though.
>

[blowing the dust off this thread]

Folks on the Chrome team are looking into implementing this attribute, and
would be interested in seeing it spec'ed.

Thanks,

Stephen


>
> On Wed, 14 Nov 2012, Robert O'Callahan wrote:
> > On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad <junov at chromium.org>
> wrote:
> > >
> > > Are there precedents for exposing features with documented caveats?
> > > (excluding caveats that were discovered after the fact)
> >
> > Yes, and many of them have been extremely problematic, because Web
> > authors will ignore the caveats.
>
> Right. I'd really like to avoid adding more if we can help it.
>
>
> On Wed, 14 Nov 2012, Justin Novosad wrote:
> >
> > There is a recent improvement in Chrome called "deferred 2D canvas
> > rendering" (enabled by default as of Chrome 23).  It is a mechanism that
> > records 2d canvas commands during JS execution, and only executes them
> > for real when the render buffer needs to be resolved (draw to screen,
> > getImageData, toDataURL, etc.).  If you want to check it out, the guts
> > are in Skia: SkGPipe is a sort of FIFO for graphics commands,
> > SkDeferredCanvas is a wrapper that manages the GPipe and automatically
> > flushes it and applies some command culling optimizations.
> >
> > So to come back to the problem of with and without subpixel AA buffers:
> > if rendering is deferred, the non-AA buffer would never get rasterized
> > (and possibly never even allocated), unless it needs to be.  Obviously
> > there are practical limitations, for example we cannot store an
> > unlimited stream of recorded commands, so if the canvas draws
> > indefinitely without ever being cleared, at some point we have to
> > rasterize the non-AA buffer just so that we can safely discard the
> > recording data. Also, if at record time the necessary conditions for
> > subpixel AA are not met, perhaps we just forget about it.
> >
> > I admit this is a complex solution for implementors, but it makes the
> > management of subpixel-AA safety transparent to web authors.
>
> I think it'd be reasonable (for some definition of reasonable that
> relates to whether it's compatible with the spec, anyway) for implementors
> to do this today, without having to expose any control to the author.
>
>
> On Thu, 15 Nov 2012, Fred Andrews wrote:
> >
> > The canvas that scripts draw into could be over-sized with the UA down
> > sampling this to fit the target size and taking into account the
> > sub-pixel screen layout when doing so.
>
> On Thu, 15 Nov 2012, Justin Novosad wrote:
> >
> > Obviously, that would be costly (x3 pixels), but I think it is a very
> > realistic solution and relatively low hanging fruit. The over-sizing of
> > the canvas would have to be handled under the hood by the UA though,
> > because it depends on LCD component ordering and orientation, which
> > means querying the OS/display driver. A lot of the kinks with the
> > over-sized canvas approach have already been ironed out for solving the
> > problem of High-DPI support ( put/getImageDataHD ), and I like the idea
> > of unifying the two. Implementing this would mostly be a matter of
> > adding per color component compositing of canvases. Also, the pixel
> > aspect ratio would have to be taken into account for line drawing.
>
> getImageDataHD() requires that the pixels be square, but so long as that
> is taken into consideration (e.g. by dropping down to square pixels if the
> author calls putImageDataHD()) I think this could probably be made to work
> within the spec's current requirements.
>
>
> > Regarding the concerns about accessibility, I think the problem can be
> > solved by using HitRegions with labels.
>
> Oh it _can_ be solved. That's not the problem. Accessibility is not about
> what is _possible_, it's about what actually _is_. Most authors,
> realistically speaking, aren't goin to be using hit regions sufficiently
> for us to declare victory here.
>
>
> > Come to think of it, there should be an option to make the UA do this
> > automatically: create a HitRegion with a label every time text is drawn
> > to a canvas.
>
> I considered doing that, but it gets really fiddly when you're doing
> things like text that fades over multiple frames. In the end I decided
> that the magic wasn't worth it, as it would likely screw up more often
> than it would actually help.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>


From cabanier at gmail.com  Tue Feb 12 15:14:24 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Tue, 12 Feb 2013 15:14:24 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
Message-ID: <CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>

On Tue, Feb 12, 2013 at 2:56 PM, Stephen White <senorblanco at chromium.org>wrote:

> On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson <ian at hixie.ch> wrote:
>
> > On Thu, 29 Mar 2012, Jeremy Apthorp wrote:
> > > On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp <jeremya at chromium.org
> > >wrote:
> > > > On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson <ian at hixie.ch> wrote:
> > > >> On Fri, 13 Jan 2012, Jeremy Apthorp wrote:
> > > >> >
> > > >> > I'd like to draw non-antialiased lines in a <canvas>. Currently it
> > > >> > seems that the only way to do this is to directly access the pixel
> > > >> > data.
> > > >> >
> > > >> > Is there a reason there's no way to turn off antialiasing?
> > > >>
> > > >> What's the use case?
> > > >
> > > > Pixel-art style games.
> > >
> > > Specifically: even with the new image smoothing stuff in place for
> > > drawImage, a 1:2 diagonal line will still be anti-aliased (only the
> > > antialiasing will look silly scaled up to 2x).
> >
> > Do you have an example of a game where lines are drawn using a line API
> > without antialiasing, then scaled up? Most "pixel art" games I've seen
> > tend to use bitmaps for that kind of thing.
> >
> >
> > On Mon, 12 Nov 2012, Justin Novosad wrote:
> > >
> > > For many types of apps, DOM-based rendering is uncompetitively slow
> > > [so we should make text rendering in canvas more controllable]
> >
> > This seems like something we should fix, not something we should work
> > around by having people use canvas instead. Using canvas has all kinds of
> > terrible side-effects, like reducing the likely accessibility of the
> page,
> > making searcheability much worse, etc.
> >
> > Also, do you have any metrics showing the magnitude of this problem on
> > real-world sites that might consider using canvas instead?
> >
> >
> > > If LCD text were enable-able, authors would have to be mindful of a
> > > number of caveats in order to avoid rendering artifacts.
> >
> > Do we have any reason to believe the majority of authors would make the
> > right decisions here?
> >
> > (The main reason we haven't provided control over things like
> antialiasing
> > is that many authors tend to make terribly bad decisions.) (Before anyone
> > gets offended, by the way: that you are reading this almost guarantees
> > that you are above average in terms of authoring ability.)
> >
> >
> > On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote:
> > >
> > > We'd have to define what happens when you use subpixel antialiasing
> > > "incorrectly", because we can be pretty sure authors will use it
> > > incorrectly and expect to get interoperable behavior.
> >
> > That's certainly true.
> >
> >
> > > Mozilla supports a "mozOpaque" attribute which makes the canvas buffer
> > > RGBX (initialized to solid black) and enables subpixel antialiasing for
> > > most text drawing. That might be enough to address your use-cases.
> >
> > I haven't specified this; if other vendors intend to implement this let
> me
> > know and I can spec it. I'm not sure it's worth it though.
> >
>
> [blowing the dust off this thread]
>
> Folks on the Chrome team are looking into implementing this attribute, and
> would be interested in seeing it spec'ed.


What are you implementing? Initializing the canvas to black or subpixel
antialiasing?


>
> >
> > On Wed, 14 Nov 2012, Robert O'Callahan wrote:
> > > On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad <junov at chromium.org>
> > wrote:
> > > >
> > > > Are there precedents for exposing features with documented caveats?
> > > > (excluding caveats that were discovered after the fact)
> > >
> > > Yes, and many of them have been extremely problematic, because Web
> > > authors will ignore the caveats.
> >
> > Right. I'd really like to avoid adding more if we can help it.
> >
> >
> > On Wed, 14 Nov 2012, Justin Novosad wrote:
> > >
> > > There is a recent improvement in Chrome called "deferred 2D canvas
> > > rendering" (enabled by default as of Chrome 23).  It is a mechanism
> that
> > > records 2d canvas commands during JS execution, and only executes them
> > > for real when the render buffer needs to be resolved (draw to screen,
> > > getImageData, toDataURL, etc.).  If you want to check it out, the guts
> > > are in Skia: SkGPipe is a sort of FIFO for graphics commands,
> > > SkDeferredCanvas is a wrapper that manages the GPipe and automatically
> > > flushes it and applies some command culling optimizations.
> > >
> > > So to come back to the problem of with and without subpixel AA buffers:
> > > if rendering is deferred, the non-AA buffer would never get rasterized
> > > (and possibly never even allocated), unless it needs to be.  Obviously
> > > there are practical limitations, for example we cannot store an
> > > unlimited stream of recorded commands, so if the canvas draws
> > > indefinitely without ever being cleared, at some point we have to
> > > rasterize the non-AA buffer just so that we can safely discard the
> > > recording data. Also, if at record time the necessary conditions for
> > > subpixel AA are not met, perhaps we just forget about it.
> > >
> > > I admit this is a complex solution for implementors, but it makes the
> > > management of subpixel-AA safety transparent to web authors.
> >
> > I think it'd be reasonable (for some definition of reasonable that
> > relates to whether it's compatible with the spec, anyway) for
> implementors
> > to do this today, without having to expose any control to the author.
> >
> >
> > On Thu, 15 Nov 2012, Fred Andrews wrote:
> > >
> > > The canvas that scripts draw into could be over-sized with the UA down
> > > sampling this to fit the target size and taking into account the
> > > sub-pixel screen layout when doing so.
> >
> > On Thu, 15 Nov 2012, Justin Novosad wrote:
> > >
> > > Obviously, that would be costly (x3 pixels), but I think it is a very
> > > realistic solution and relatively low hanging fruit. The over-sizing of
> > > the canvas would have to be handled under the hood by the UA though,
> > > because it depends on LCD component ordering and orientation, which
> > > means querying the OS/display driver. A lot of the kinks with the
> > > over-sized canvas approach have already been ironed out for solving the
> > > problem of High-DPI support ( put/getImageDataHD ), and I like the idea
> > > of unifying the two. Implementing this would mostly be a matter of
> > > adding per color component compositing of canvases. Also, the pixel
> > > aspect ratio would have to be taken into account for line drawing.
> >
> > getImageDataHD() requires that the pixels be square, but so long as that
> > is taken into consideration (e.g. by dropping down to square pixels if
> the
> > author calls putImageDataHD()) I think this could probably be made to
> work
> > within the spec's current requirements.
> >
> >
> > > Regarding the concerns about accessibility, I think the problem can be
> > > solved by using HitRegions with labels.
> >
> > Oh it _can_ be solved. That's not the problem. Accessibility is not about
> > what is _possible_, it's about what actually _is_. Most authors,
> > realistically speaking, aren't goin to be using hit regions sufficiently
> > for us to declare victory here.
> >
> >
> > > Come to think of it, there should be an option to make the UA do this
> > > automatically: create a HitRegion with a label every time text is drawn
> > > to a canvas.
> >
> > I considered doing that, but it gets really fiddly when you're doing
> > things like text that fades over multiple frames. In the end I decided
> > that the magic wasn't worth it, as it would likely screw up more often
> > than it would actually help.
> >
> > --
> > Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> > http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> > Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> >
>


From esprehn at gmail.com  Tue Feb 12 15:46:28 2013
From: esprehn at gmail.com (Elliott Sprehn)
Date: Tue, 12 Feb 2013 15:46:28 -0800
Subject: [whatwg] Polling APIs in JavaScript vs Callbacks
In-Reply-To: <CABZUbM35r-oFE1B4ZtAAAb=gUQcL_xujjCHniksYcsbhx1POsg@mail.gmail.com>
References: <CAKZ+BNowkrkuHByMWxW9XB5BVhkyc9+NQ=Xq3n_vKyWdas-LjQ@mail.gmail.com>
	<CABirCh-HdfNLVo2NvFt43DKR9N54V0rD6zu+8KTwWcBuS=g_zQ@mail.gmail.com>
	<CAAWBYDCZuFYVKxz_5kdz7oszmPSwYD_GU9qN_DuF6qo0sY1LVg@mail.gmail.com>
	<CABirCh_bR9XvOCEjX_8TyJq+5juzsqr3_7vjkwYen_NF_3bJPw@mail.gmail.com>
	<CABZUbM35r-oFE1B4ZtAAAb=gUQcL_xujjCHniksYcsbhx1POsg@mail.gmail.com>
Message-ID: <CAPJYB1ifqP2x4p90yZoCrXCCCbc4Y0V40eke7M3DdEmfGy-urw@mail.gmail.com>

On Mon, Feb 11, 2013 at 10:56 PM, Garrett Smith <dhtmlkitchen at gmail.com>wrote:

> On 2/9/13, Glenn Maynard <glenn at zewt.org> wrote:
> > On Sat, Feb 9, 2013 at 10:43 AM, Tab Atkins Jr.
> > <jackalmage at gmail.com>wrote:
> >
> >> That said, there *are* still some isolated use-cases for polling.  ^_^
> >>  When an event-based approach would potentially deliver far too many
> >> events, with separation between them perhaps less than 1ms, exposing a
> >> polling-based API instead can be useful.  I haven't followed the
> >> Gamepad API lately, but I know this was at least considered for some
> >> of the types of feedback, such as the exact position of joysticks or
> >> pressure on buttons, both of which can change very rapidly in
> >> realistic scenarios.
> >>
> >
> > A polling API doesn't help you there, since you can't poll every 1ms in
> > script (certainly not in the UI thread, and probably not reliably even
> in a
> > worker).  In fact, since setTimeout will be throttled but events fired by
> > the browser don't have to be, events can be sent faster than you can poll
> > in the UI thread (though this is probably a bad idea most of the time).
> >
> > The solution is probably a matter of buffering the changes, and limiting
> > how frequently "something was buffered" events fire.
> Are you proposing event quantization threshold?
>

There's no reason to have a threshold. We should just batch and deliver at
checkpoints like end-of-microtask (MutationObserver) or rAf (Animations).

- E


From dbaron at dbaron.org  Tue Feb 12 21:06:37 2013
From: dbaron at dbaron.org (L. David Baron)
Date: Tue, 12 Feb 2013 21:06:37 -0800
Subject: [whatwg] scoped style sheets and @-rules
In-Reply-To: <CAAWBYDCkDWH6hMvWztuTdqVXvADhd768NdVxnGd=TXTe55ApZA@mail.gmail.com>
References: <20130121143923.GA6959@crum.dbaron.org>
	<CAAWBYDCkDWH6hMvWztuTdqVXvADhd768NdVxnGd=TXTe55ApZA@mail.gmail.com>
Message-ID: <20130213050637.GA29746@crum.dbaron.org>

On Monday 2013-01-21 11:17 -0800, Tab Atkins Jr. wrote:
> On Mon, Jan 21, 2013 at 6:39 AM, L. David Baron <dbaron at dbaron.org> wrote:
> > Thus I think the specification should mandate that @keyframes and
> > @font-face are ignored in scoped style sheets, just like @page.
> >
> > I think it would also be good if the specification left the effects
> > of unknown @-rules undefined until whether they should be supported
> > can be properly considered.
> 
> Should we ignore them entirely, or just ignore the scoped-ness and
> have them fill in the global dictionary?

I prefer ignoring them entirely, since authors will notice if things
aren't working as expected.

-David

-- 
?   L. David Baron                         http://dbaron.org/   ?
?   Mozilla                           http://www.mozilla.org/   ?


From Bronislav.Klucka at bauglir.com  Wed Feb 13 00:35:17 2013
From: Bronislav.Klucka at bauglir.com (=?UTF-8?B?QnJvbmlzbGF2IEtsdcSNa2E=?=)
Date: Wed, 13 Feb 2013 09:35:17 +0100
Subject: [whatwg] Fwd: Re: Why do we have <input type='month'> and <input
 type='week'>?
In-Reply-To: <511B47F5.1000500@bauglir.com>
References: <511B47F5.1000500@bauglir.com>
Message-ID: <511B5045.9020304@bauglir.com>




-------- Original Message --------
Subject: 	Re: [whatwg] Why do we have <input type='month'> and <input 
type='week'>?
Date: 	Wed, 13 Feb 2013 08:59:49 +0100
From: 	Bronislav Klu?ka <Bronislav.Klucka at bauglir.com>
To: 	Jukka K. Korpela <jkorpela at cs.tut.fi>



On 12.2.2013 18:39, Jukka K. Korpela wrote:
> 2013-02-12 19:26, Tab Atkins Jr. wrote:
>
>> The fact that authors today have a random assortment of displays for
>> the exact same feature (credit card expirys) is something that would
>> be great to fix, not bemoan as a loss to the world. ^_^
>
> Well, maybe, from some point of view, but is there really something to
> be fixed, and is it probable that <input type=month> would fix it?
>
> I have seen many input widgets for such data and used them a lot in
> test purchases. In general, the more advanced they try to be, the more
> annoying they get. I can type "03/15", or whatever reads in the card,
> rather fast. But if I have to pick things up from dropdowns or click
> on something in a calendar picker, I surely hope I won't need to do
> this a dozen more times.
Well you can type 03/15, regular user from Czech republic would newer
write it as such. And how should I know,  what would user in Israel,
India, Chile wrote?
>
> What are the odds that browser vendors will implement <input
> type=month> in a simple manner that allows fast typing as one input
> method? Rather small I think.
>
> This would make the most obvious, and perhaps the most common, use for
> <input type=month> a case *against* it.  Credit card expiry month is
> best handled with a text input field, with suitable checks on the
> input string. There may be *other* cases where graphic widgets are
> good when selecting a month, but authors can use libraries for such
> purpose, and I don't see any particular reason why this should be
> standardized across pages but not across browsers.
>
> Even if <input type=month> became widely supported, many, probably
> most, authors will keep using libraries or their own code, because
> they get consistent look and feel and functionality across browsers.
> Some authors would be misled into using <input type=month> for any
> month input because that's "logical" or "semantic" (as it is in a
> sense), but this will create questionable user experience in many
> common cases.
I dont know, how about you, but I'm using libraries because of missing
functionality and I do not want to.


Brona





From ian at invigoreight.com  Wed Feb 13 02:31:32 2013
From: ian at invigoreight.com (Ian Yang)
Date: Wed, 13 Feb 2013 18:31:32 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
Message-ID: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>

Hi editors and all other folks,

I saw the SitePoint article "Introducing the New HTML5 <main>
Element<http://www.sitepoint.com/html5-main-element/>"
yesterday. Does that mean <main> element has been approved by all editors
of the working group?

However, in spec, it still says that <main> element is not a sectioning
element. That means, in document outline, main content will form another
tree structure instead of appearing under the original website tree
structure. Can we have somebody advise on this? Is there a special
consideration to not making <main> a sectioning element?


Sincerely,
Ian Yang


From glenn at zewt.org  Wed Feb 13 06:35:22 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Wed, 13 Feb 2013 08:35:22 -0600
Subject: [whatwg] Why do we have <input type='month'> and <input
	type='week'>?
In-Reply-To: <511A79F1.5050501@lamouri.fr>
References: <510988C1.1040900@lamouri.fr> <op.wrry8kurh8on37@bruce-pc>
	<CABirCh_ua8cumCqZcASOTOdwCmsi0yPdVYvoRT23eBstszdy2A@mail.gmail.com>
	<511A79F1.5050501@lamouri.fr>
Message-ID: <CABirCh9QfvN8HYqAdYJVobhthnQ7McCQbmbBO5UsjcCy8PWkZQ@mail.gmail.com>

On Tue, Feb 12, 2013 at 11:20 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:

> Regarding week, I still believe that the use cases are pretty weak but
>
the most important issue is that there is no good UI for this on Mobile
> AFAIK.
>

There aren't stock widgets, but this isn't a hard UI problem to solve.  For
example, two panes: a year scroller and a scroller containing a vertical
strip of calendars, where you scroll vertically to the row corresponding
with the week you want to select.

A trickier issue for weeks is which day the week starts on.  To me,
calendar weeks start on Sunday and end on Saturday.  I'd find it weird to
be shown a Monday-aligned calendar, but this is hard to localize, since the
browser can't return anything but Monday-based week numbers.  This would
probably work better if the result was a date, not a week number, so it
could return both Sundays and Mondays, but this might lead to localization
bugs.

-- 
Glenn Maynard


From senorblanco at chromium.org  Wed Feb 13 07:45:34 2013
From: senorblanco at chromium.org (Stephen White)
Date: Wed, 13 Feb 2013 10:45:34 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
Message-ID: <CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>

On Tue, Feb 12, 2013 at 6:14 PM, Rik Cabanier <cabanier at gmail.com> wrote:

>
>
> On Tue, Feb 12, 2013 at 2:56 PM, Stephen White <senorblanco at chromium.org>wrote:
>
>> On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson <ian at hixie.ch> wrote:
>>
>> > On Thu, 29 Mar 2012, Jeremy Apthorp wrote:
>> > > On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp <
>> jeremya at chromium.org
>> > >wrote:
>> > > > On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson <ian at hixie.ch> wrote:
>> > > >> On Fri, 13 Jan 2012, Jeremy Apthorp wrote:
>> > > >> >
>> > > >> > I'd like to draw non-antialiased lines in a <canvas>. Currently
>> it
>> > > >> > seems that the only way to do this is to directly access the
>> pixel
>> > > >> > data.
>> > > >> >
>> > > >> > Is there a reason there's no way to turn off antialiasing?
>> > > >>
>> > > >> What's the use case?
>> > > >
>> > > > Pixel-art style games.
>> > >
>> > > Specifically: even with the new image smoothing stuff in place for
>> > > drawImage, a 1:2 diagonal line will still be anti-aliased (only the
>> > > antialiasing will look silly scaled up to 2x).
>> >
>> > Do you have an example of a game where lines are drawn using a line API
>> > without antialiasing, then scaled up? Most "pixel art" games I've seen
>> > tend to use bitmaps for that kind of thing.
>> >
>> >
>> > On Mon, 12 Nov 2012, Justin Novosad wrote:
>> > >
>> > > For many types of apps, DOM-based rendering is uncompetitively slow
>> > > [so we should make text rendering in canvas more controllable]
>> >
>> > This seems like something we should fix, not something we should work
>> > around by having people use canvas instead. Using canvas has all kinds
>> of
>> > terrible side-effects, like reducing the likely accessibility of the
>> page,
>> > making searcheability much worse, etc.
>> >
>> > Also, do you have any metrics showing the magnitude of this problem on
>> > real-world sites that might consider using canvas instead?
>> >
>> >
>> > > If LCD text were enable-able, authors would have to be mindful of a
>> > > number of caveats in order to avoid rendering artifacts.
>> >
>> > Do we have any reason to believe the majority of authors would make the
>> > right decisions here?
>> >
>> > (The main reason we haven't provided control over things like
>> antialiasing
>> > is that many authors tend to make terribly bad decisions.) (Before
>> anyone
>> > gets offended, by the way: that you are reading this almost guarantees
>> > that you are above average in terms of authoring ability.)
>> >
>> >
>> > On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote:
>> > >
>> > > We'd have to define what happens when you use subpixel antialiasing
>> > > "incorrectly", because we can be pretty sure authors will use it
>> > > incorrectly and expect to get interoperable behavior.
>> >
>> > That's certainly true.
>> >
>> >
>> > > Mozilla supports a "mozOpaque" attribute which makes the canvas buffer
>> > > RGBX (initialized to solid black) and enables subpixel antialiasing
>> for
>> > > most text drawing. That might be enough to address your use-cases.
>> >
>> > I haven't specified this; if other vendors intend to implement this let
>> me
>> > know and I can spec it. I'm not sure it's worth it though.
>> >
>>
>> [blowing the dust off this thread]
>>
>> Folks on the Chrome team are looking into implementing this attribute, and
>> would be interested in seeing it spec'ed.
>
>
> What are you implementing? Initializing the canvas to black or subpixel
> antialiasing?
>

We're interested in both aspects:  the opportunity for culling and blending
optimizations at composite time, as well as enabling subpixel AA.

Stephen

>
>
>>
>> >
>> > On Wed, 14 Nov 2012, Robert O'Callahan wrote:
>> > > On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad <junov at chromium.org>
>> > wrote:
>> > > >
>> > > > Are there precedents for exposing features with documented caveats?
>> > > > (excluding caveats that were discovered after the fact)
>> > >
>> > > Yes, and many of them have been extremely problematic, because Web
>> > > authors will ignore the caveats.
>> >
>> > Right. I'd really like to avoid adding more if we can help it.
>> >
>> >
>> > On Wed, 14 Nov 2012, Justin Novosad wrote:
>> > >
>> > > There is a recent improvement in Chrome called "deferred 2D canvas
>> > > rendering" (enabled by default as of Chrome 23).  It is a mechanism
>> that
>> > > records 2d canvas commands during JS execution, and only executes them
>> > > for real when the render buffer needs to be resolved (draw to screen,
>> > > getImageData, toDataURL, etc.).  If you want to check it out, the guts
>> > > are in Skia: SkGPipe is a sort of FIFO for graphics commands,
>> > > SkDeferredCanvas is a wrapper that manages the GPipe and automatically
>> > > flushes it and applies some command culling optimizations.
>> > >
>> > > So to come back to the problem of with and without subpixel AA
>> buffers:
>> > > if rendering is deferred, the non-AA buffer would never get rasterized
>> > > (and possibly never even allocated), unless it needs to be.  Obviously
>> > > there are practical limitations, for example we cannot store an
>> > > unlimited stream of recorded commands, so if the canvas draws
>> > > indefinitely without ever being cleared, at some point we have to
>> > > rasterize the non-AA buffer just so that we can safely discard the
>> > > recording data. Also, if at record time the necessary conditions for
>> > > subpixel AA are not met, perhaps we just forget about it.
>> > >
>> > > I admit this is a complex solution for implementors, but it makes the
>> > > management of subpixel-AA safety transparent to web authors.
>> >
>> > I think it'd be reasonable (for some definition of reasonable that
>> > relates to whether it's compatible with the spec, anyway) for
>> implementors
>> > to do this today, without having to expose any control to the author.
>> >
>> >
>> > On Thu, 15 Nov 2012, Fred Andrews wrote:
>> > >
>> > > The canvas that scripts draw into could be over-sized with the UA down
>> > > sampling this to fit the target size and taking into account the
>> > > sub-pixel screen layout when doing so.
>> >
>> > On Thu, 15 Nov 2012, Justin Novosad wrote:
>> > >
>> > > Obviously, that would be costly (x3 pixels), but I think it is a very
>> > > realistic solution and relatively low hanging fruit. The over-sizing
>> of
>> > > the canvas would have to be handled under the hood by the UA though,
>> > > because it depends on LCD component ordering and orientation, which
>> > > means querying the OS/display driver. A lot of the kinks with the
>> > > over-sized canvas approach have already been ironed out for solving
>> the
>> > > problem of High-DPI support ( put/getImageDataHD ), and I like the
>> idea
>> > > of unifying the two. Implementing this would mostly be a matter of
>> > > adding per color component compositing of canvases. Also, the pixel
>> > > aspect ratio would have to be taken into account for line drawing.
>> >
>> > getImageDataHD() requires that the pixels be square, but so long as that
>> > is taken into consideration (e.g. by dropping down to square pixels if
>> the
>> > author calls putImageDataHD()) I think this could probably be made to
>> work
>> > within the spec's current requirements.
>> >
>> >
>> > > Regarding the concerns about accessibility, I think the problem can be
>> > > solved by using HitRegions with labels.
>> >
>> > Oh it _can_ be solved. That's not the problem. Accessibility is not
>> about
>> > what is _possible_, it's about what actually _is_. Most authors,
>> > realistically speaking, aren't goin to be using hit regions sufficiently
>> > for us to declare victory here.
>> >
>> >
>> > > Come to think of it, there should be an option to make the UA do this
>> > > automatically: create a HitRegion with a label every time text is
>> drawn
>> > > to a canvas.
>> >
>> > I considered doing that, but it gets really fiddly when you're doing
>> > things like text that fades over multiple frames. In the end I decided
>> > that the magic wasn't worth it, as it would likely screw up more often
>> > than it would actually help.
>> >
>> > --
>> > Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> > http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._
>> ,.
>> > Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>> >
>>
>
>


From ehs at pobox.com  Wed Feb 13 08:18:20 2013
From: ehs at pobox.com (Ed Summers)
Date: Wed, 13 Feb 2013 11:18:20 -0500
Subject: [whatwg] itemtypes from same vocabulary
Message-ID: <CABzDd=70TtoPhqQzpop+Y8YeeOM_SCwi8+hog=r-4yMn3G79zw@mail.gmail.com>

Hi all,

I am looking for some guidance about the use of multiple itemtypes in
microdata [1], specifically the phrase "defined to use the same
vocabulary" in:

"""
The item types must all be types defined in applicable specifications
and must all be defined to use the same vocabulary.
"""

For example, does this mean that I can't say:

<div itemscope itemtype="http://acme.com/Foo http://zenith.com/Bar"> ... </div>

The reason I ask is that there is some desire over in the schema.org
community [2] to provide a mechanism for schema.org to be specialized.
For example, in the case of an audiobook:

<div itemscope itemtype="http://schema.org/Book
http://www.productontology.org/id/Audiobook"> ... </div>

The idea being not to overload schema.org with more vocabulary, and to
let vocabularies grow a bit more organically. This schema.org group is
currently thinking of using a one off property additionalType that
would be used like so:

<div itemscope itemtype="http://schema.org/Book">
  <link itemprop="additionalType"
href="http://www.productontology.org/id/Audiobook">
  ...
</div>

I personally find this to be kind of distasteful since it replicates
the mechanics that microdata's itemtype already offers.

So, my question: is it the case that itemtype cannot reference types
in different vocabularies like the example above? If so, I'm curious
to know what the rationale was, and if perhaps it could be relaxed.

//Ed

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#items
[2] http://lists.w3.org/Archives/Public/public-schemabibex/2013Feb/0000.html


From lin.w.clark at gmail.com  Wed Feb 13 08:23:59 2013
From: lin.w.clark at gmail.com (Lin Clark)
Date: Wed, 13 Feb 2013 11:23:59 -0500
Subject: [whatwg] itemtypes from same vocabulary
In-Reply-To: <CABzDd=70TtoPhqQzpop+Y8YeeOM_SCwi8+hog=r-4yMn3G79zw@mail.gmail.com>
References: <CABzDd=70TtoPhqQzpop+Y8YeeOM_SCwi8+hog=r-4yMn3G79zw@mail.gmail.com>
Message-ID: <CACho_Av7dsGmxUozJv6Aj1xNhZJh9ESSujWKcA_KtX5AcT_Feg@mail.gmail.com>

Itemtype cannot reference different vocabs. Here are two relevant
discussions that I know of, one with Hixie and the other with the HTML Data
Task Force.

http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0364.html
http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0072.html


On Wed, Feb 13, 2013 at 11:18 AM, Ed Summers <ehs at pobox.com> wrote:

> Hi all,
>
> I am looking for some guidance about the use of multiple itemtypes in
> microdata [1], specifically the phrase "defined to use the same
> vocabulary" in:
>
> """
> The item types must all be types defined in applicable specifications
> and must all be defined to use the same vocabulary.
> """
>
> For example, does this mean that I can't say:
>
> <div itemscope itemtype="http://acme.com/Foo http://zenith.com/Bar"> ...
> </div>
>
> The reason I ask is that there is some desire over in the schema.org
> community [2] to provide a mechanism for schema.org to be specialized.
> For example, in the case of an audiobook:
>
> <div itemscope itemtype="http://schema.org/Book
> http://www.productontology.org/id/Audiobook"> ... </div>
>
> The idea being not to overload schema.org with more vocabulary, and to
> let vocabularies grow a bit more organically. This schema.org group is
> currently thinking of using a one off property additionalType that
> would be used like so:
>
> <div itemscope itemtype="http://schema.org/Book">
>   <link itemprop="additionalType"
> href="http://www.productontology.org/id/Audiobook">
>   ...
> </div>
>
> I personally find this to be kind of distasteful since it replicates
> the mechanics that microdata's itemtype already offers.
>
> So, my question: is it the case that itemtype cannot reference types
> in different vocabularies like the example above? If so, I'm curious
> to know what the rationale was, and if perhaps it could be relaxed.
>
> //Ed
>
> [1]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#items
> [2]
> http://lists.w3.org/Archives/Public/public-schemabibex/2013Feb/0000.html
>



-- 
Lin Clark
Drupal Consultant

lin-clark.com
twitter.com/linclark


From ehs at pobox.com  Wed Feb 13 08:29:05 2013
From: ehs at pobox.com (Ed Summers)
Date: Wed, 13 Feb 2013 11:29:05 -0500
Subject: [whatwg] itemtypes from same vocabulary
In-Reply-To: <CACho_Av7dsGmxUozJv6Aj1xNhZJh9ESSujWKcA_KtX5AcT_Feg@mail.gmail.com>
References: <CABzDd=70TtoPhqQzpop+Y8YeeOM_SCwi8+hog=r-4yMn3G79zw@mail.gmail.com>
	<CACho_Av7dsGmxUozJv6Aj1xNhZJh9ESSujWKcA_KtX5AcT_Feg@mail.gmail.com>
Message-ID: <CABzDd=6C_WQo9uyVowX+tBGvijMGx7VRvbeoRQKtaF4uHwduBQ@mail.gmail.com>

Hi Lin,

I'm confused because it looks like Microdata currently allows multiple
itemtypes to be expressed:

"""
The itemtype attribute, if specified, must have a value that is an
unordered set of unique space-separated tokens that are
case-sensitive, each of which is a valid URL that is an absolute URL,
and all of which are defined to use the same vocabulary. The
attribute's value must have at least one token. [1]
"""

I am seeking clarification about what is meant by 'same vocabulary',
the rationale, and whether it can be relaxed.

//Ed

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#items

On Wed, Feb 13, 2013 at 11:23 AM, Lin Clark <lin.w.clark at gmail.com> wrote:
> Itemtype cannot reference different vocabs. Here are two relevant
> discussions that I know of, one with Hixie and the other with the HTML Data
> Task Force.
>
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0364.html
> http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0072.html
>
>
> On Wed, Feb 13, 2013 at 11:18 AM, Ed Summers <ehs at pobox.com> wrote:
>>
>> Hi all,
>>
>> I am looking for some guidance about the use of multiple itemtypes in
>> microdata [1], specifically the phrase "defined to use the same
>> vocabulary" in:
>>
>> """
>> The item types must all be types defined in applicable specifications
>> and must all be defined to use the same vocabulary.
>> """
>>
>> For example, does this mean that I can't say:
>>
>> <div itemscope itemtype="http://acme.com/Foo http://zenith.com/Bar"> ...
>> </div>
>>
>> The reason I ask is that there is some desire over in the schema.org
>> community [2] to provide a mechanism for schema.org to be specialized.
>> For example, in the case of an audiobook:
>>
>> <div itemscope itemtype="http://schema.org/Book
>> http://www.productontology.org/id/Audiobook"> ... </div>
>>
>> The idea being not to overload schema.org with more vocabulary, and to
>> let vocabularies grow a bit more organically. This schema.org group is
>> currently thinking of using a one off property additionalType that
>> would be used like so:
>>
>> <div itemscope itemtype="http://schema.org/Book">
>>   <link itemprop="additionalType"
>> href="http://www.productontology.org/id/Audiobook">
>>   ...
>> </div>
>>
>> I personally find this to be kind of distasteful since it replicates
>> the mechanics that microdata's itemtype already offers.
>>
>> So, my question: is it the case that itemtype cannot reference types
>> in different vocabularies like the example above? If so, I'm curious
>> to know what the rationale was, and if perhaps it could be relaxed.
>>
>> //Ed
>>
>> [1]
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#items
>> [2]
>> http://lists.w3.org/Archives/Public/public-schemabibex/2013Feb/0000.html
>
>
>
>
> --
> Lin Clark
> Drupal Consultant
>
> lin-clark.com
> twitter.com/linclark


From lin.w.clark at gmail.com  Wed Feb 13 08:36:58 2013
From: lin.w.clark at gmail.com (Lin Clark)
Date: Wed, 13 Feb 2013 11:36:58 -0500
Subject: [whatwg] itemtypes from same vocabulary
In-Reply-To: <CABzDd=6C_WQo9uyVowX+tBGvijMGx7VRvbeoRQKtaF4uHwduBQ@mail.gmail.com>
References: <CABzDd=70TtoPhqQzpop+Y8YeeOM_SCwi8+hog=r-4yMn3G79zw@mail.gmail.com>
	<CACho_Av7dsGmxUozJv6Aj1xNhZJh9ESSujWKcA_KtX5AcT_Feg@mail.gmail.com>
	<CABzDd=6C_WQo9uyVowX+tBGvijMGx7VRvbeoRQKtaF4uHwduBQ@mail.gmail.com>
Message-ID: <CACho_At=xBDkwcNV5AssDbMfsdk1FtjEFBSa7AM1fVxohy46Rg@mail.gmail.com>

Sorry if it wasn't clear, at the time that those discussions took place,
only one itemtype could be used. Since then, the spec was changed to allow
multiple itemtypes from the same vocabulary.

However, both discussions also touch on the issue of using multiple
vocabularies in itemtype. For example, my response [1] in the first.

[1]
http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0383.html


On Wed, Feb 13, 2013 at 11:29 AM, Ed Summers <ehs at pobox.com> wrote:

> Hi Lin,
>
> I'm confused because it looks like Microdata currently allows multiple
> itemtypes to be expressed:
>
> """
> The itemtype attribute, if specified, must have a value that is an
> unordered set of unique space-separated tokens that are
> case-sensitive, each of which is a valid URL that is an absolute URL,
> and all of which are defined to use the same vocabulary. The
> attribute's value must have at least one token. [1]
> """
>
> I am seeking clarification about what is meant by 'same vocabulary',
> the rationale, and whether it can be relaxed.
>
> //Ed
>
> [1]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#items
>
> On Wed, Feb 13, 2013 at 11:23 AM, Lin Clark <lin.w.clark at gmail.com> wrote:
> > Itemtype cannot reference different vocabs. Here are two relevant
> > discussions that I know of, one with Hixie and the other with the HTML
> Data
> > Task Force.
> >
> >
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0364.html
> >
> http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0072.html
> >
> >
> > On Wed, Feb 13, 2013 at 11:18 AM, Ed Summers <ehs at pobox.com> wrote:
> >>
> >> Hi all,
> >>
> >> I am looking for some guidance about the use of multiple itemtypes in
> >> microdata [1], specifically the phrase "defined to use the same
> >> vocabulary" in:
> >>
> >> """
> >> The item types must all be types defined in applicable specifications
> >> and must all be defined to use the same vocabulary.
> >> """
> >>
> >> For example, does this mean that I can't say:
> >>
> >> <div itemscope itemtype="http://acme.com/Foo http://zenith.com/Bar">
> ...
> >> </div>
> >>
> >> The reason I ask is that there is some desire over in the schema.org
> >> community [2] to provide a mechanism for schema.org to be specialized.
> >> For example, in the case of an audiobook:
> >>
> >> <div itemscope itemtype="http://schema.org/Book
> >> http://www.productontology.org/id/Audiobook"> ... </div>
> >>
> >> The idea being not to overload schema.org with more vocabulary, and to
> >> let vocabularies grow a bit more organically. This schema.org group is
> >> currently thinking of using a one off property additionalType that
> >> would be used like so:
> >>
> >> <div itemscope itemtype="http://schema.org/Book">
> >>   <link itemprop="additionalType"
> >> href="http://www.productontology.org/id/Audiobook">
> >>   ...
> >> </div>
> >>
> >> I personally find this to be kind of distasteful since it replicates
> >> the mechanics that microdata's itemtype already offers.
> >>
> >> So, my question: is it the case that itemtype cannot reference types
> >> in different vocabularies like the example above? If so, I'm curious
> >> to know what the rationale was, and if perhaps it could be relaxed.
> >>
> >> //Ed
> >>
> >> [1]
> >>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#items
> >> [2]
> >>
> http://lists.w3.org/Archives/Public/public-schemabibex/2013Feb/0000.html
> >
> >
> >
> >
> > --
> > Lin Clark
> > Drupal Consultant
> >
> > lin-clark.com
> > twitter.com/linclark
>



-- 
Lin Clark
Drupal Consultant

lin-clark.com
twitter.com/linclark


From faulkner.steve at gmail.com  Wed Feb 13 08:59:09 2013
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Wed, 13 Feb 2013 16:59:09 +0000
Subject: [whatwg]  Is <main> now an official HTML5 element?
Message-ID: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>

Hi Ian,

I cannot speak for whatwg, but from the W3C HTML spec side the main element
is in the HTML 5.1 spec and has been implemented in browsers and so will be
added to HTML5 spec at some point as it likely meets the CR exit criteria.

as for it being a sectioning element, there is currently an open bug on
that, which we be dealt with.

If you want to discuss the specification of the main element in HTML 5.1
specification feel free mail the html wg list. If you want to discuss
definition as per the whatwg spec this is the place, although I will
obviously follow ant discussions with interest

regards
SteveF


Date: Wed, 13 Feb 2013 18:31:32 +0800
> From: Ian Yang <ian at invigoreight.com>
> To: whatwg <whatwg at whatwg.org>
> Subject: [whatwg] Is <main> now an official HTML5 element?
> Message-ID:
>         <CABr1FsfcaX8=B8TReG8Sz36W=

h1w0hRY61+LG=Cebo-ZUWYfqA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi editors and all other folks,

I saw the SitePoint article "Introducing the New HTML5 <main>
Element<http://www.sitepoint.com/html5-main-element/>"
yesterday. Does that mean <main> element has been approved by all editors
of the working group?

However, in spec, it still says that <main> element is not a sectioning
element. That means, in document outline, main content will form another
tree structure instead of appearing under the original website tree
structure. Can we have somebody advise on this? Is there a special
consideration to not making <main> a sectioning element?


Sincerely,
Ian Yan


From ian at hixie.ch  Wed Feb 13 09:06:52 2013
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 13 Feb 2013 17:06:52 +0000 (UTC)
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
References: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>

On Wed, 13 Feb 2013, Ian Yang wrote:
> 
> I saw the SitePoint article "Introducing the New HTML5 <main> 
> Element<http://www.sitepoint.com/html5-main-element/>" yesterday. Does 
> that mean <main> element has been approved by all editors of the working 
> group?

<main> is currently in the HTML standard. That doesn't mean much, though. 
What means something is that <main> is now implemented by two browsers in 
their development builds. Once they ship in final versions, that's the 
point at which we know that the feature is part of the platform.


> However, in spec, it still says that <main> element is not a sectioning
> element.

Correct. Broadly speaking, sectioning elements are those with headings; 
<main> doesn't typically have a heading, it contains the content after the 
heading, distinguishing it from the content that is "merely" heading and 
navigation and so forth.


> That means, in document outline, main content will form another
> tree structure instead of appearing under the original website tree
> structure.

I'm not sure what you mean here. The main content doesn't appear in the 
outline; the outline only contains the headers, essentially.


> Can we have somebody advise on this? Is there a special consideration to 
> not making <main> a sectioning element?

There's already corresponding sectioning elements to indicate something 
that is "main" content -- <article> or <section>, depending on what 
exactly the content is.


The spec goes into some detail about this, including with examples, here:

   http://whatwg.org/html#the-main-part-of-the-content
   http://whatwg.org/html#the-main-element
   http://whatwg.org/html#usage-summary-0
   http://whatwg.org/html#sample-outlines

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From cabanier at gmail.com  Wed Feb 13 09:22:29 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Wed, 13 Feb 2013 09:22:29 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
Message-ID: <CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>

For blending optimizations, it might be better to introduce a function
instead of a boolean attribute like 'opaque'.
What you really want, is to matte [1] the canvas with a solid color so you
can optimize compositing.

How about this API:

void applyMatte(DOMString color); // color is a CSS rgb color value (alpha
is ignored)


When you call this function, the canvas is matted with that color. If it's
the first drawing call, you can just fill the canvas with that color (no
compositing needed)
After matting, you no longer have to read or update the alpha channel since
it's always 1 which should speed up drawing.

1: http://en.wikipedia.org/wiki/Matte_(filmmaking)

On Wed, Feb 13, 2013 at 7:45 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Tue, Feb 12, 2013 at 6:14 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>>
>>
>> On Tue, Feb 12, 2013 at 2:56 PM, Stephen White <senorblanco at chromium.org>wrote:
>>
>>> On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>
>>> > On Thu, 29 Mar 2012, Jeremy Apthorp wrote:
>>> > > On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp <
>>> jeremya at chromium.org
>>> > >wrote:
>>> > > > On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson <ian at hixie.ch> wrote:
>>> > > >> On Fri, 13 Jan 2012, Jeremy Apthorp wrote:
>>> > > >> >
>>> > > >> > I'd like to draw non-antialiased lines in a <canvas>. Currently
>>> it
>>> > > >> > seems that the only way to do this is to directly access the
>>> pixel
>>> > > >> > data.
>>> > > >> >
>>> > > >> > Is there a reason there's no way to turn off antialiasing?
>>> > > >>
>>> > > >> What's the use case?
>>> > > >
>>> > > > Pixel-art style games.
>>> > >
>>> > > Specifically: even with the new image smoothing stuff in place for
>>> > > drawImage, a 1:2 diagonal line will still be anti-aliased (only the
>>> > > antialiasing will look silly scaled up to 2x).
>>> >
>>> > Do you have an example of a game where lines are drawn using a line API
>>> > without antialiasing, then scaled up? Most "pixel art" games I've seen
>>> > tend to use bitmaps for that kind of thing.
>>> >
>>> >
>>> > On Mon, 12 Nov 2012, Justin Novosad wrote:
>>> > >
>>> > > For many types of apps, DOM-based rendering is uncompetitively slow
>>> > > [so we should make text rendering in canvas more controllable]
>>> >
>>> > This seems like something we should fix, not something we should work
>>> > around by having people use canvas instead. Using canvas has all kinds
>>> of
>>> > terrible side-effects, like reducing the likely accessibility of the
>>> page,
>>> > making searcheability much worse, etc.
>>> >
>>> > Also, do you have any metrics showing the magnitude of this problem on
>>> > real-world sites that might consider using canvas instead?
>>> >
>>> >
>>> > > If LCD text were enable-able, authors would have to be mindful of a
>>> > > number of caveats in order to avoid rendering artifacts.
>>> >
>>> > Do we have any reason to believe the majority of authors would make the
>>> > right decisions here?
>>> >
>>> > (The main reason we haven't provided control over things like
>>> antialiasing
>>> > is that many authors tend to make terribly bad decisions.) (Before
>>> anyone
>>> > gets offended, by the way: that you are reading this almost guarantees
>>> > that you are above average in terms of authoring ability.)
>>> >
>>> >
>>> > On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote:
>>> > >
>>> > > We'd have to define what happens when you use subpixel antialiasing
>>> > > "incorrectly", because we can be pretty sure authors will use it
>>> > > incorrectly and expect to get interoperable behavior.
>>> >
>>> > That's certainly true.
>>> >
>>> >
>>> > > Mozilla supports a "mozOpaque" attribute which makes the canvas
>>> buffer
>>> > > RGBX (initialized to solid black) and enables subpixel antialiasing
>>> for
>>> > > most text drawing. That might be enough to address your use-cases.
>>> >
>>> > I haven't specified this; if other vendors intend to implement this
>>> let me
>>> > know and I can spec it. I'm not sure it's worth it though.
>>> >
>>>
>>> [blowing the dust off this thread]
>>>
>>> Folks on the Chrome team are looking into implementing this attribute,
>>> and
>>> would be interested in seeing it spec'ed.
>>
>>
>> What are you implementing? Initializing the canvas to black or subpixel
>> antialiasing?
>>
>
> We're interested in both aspects:  the opportunity for culling and
> blending optimizations at composite time, as well as enabling subpixel AA.
>
> Stephen
>
>>
>>
>>>
>>> >
>>> > On Wed, 14 Nov 2012, Robert O'Callahan wrote:
>>> > > On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad <junov at chromium.org>
>>> > wrote:
>>> > > >
>>> > > > Are there precedents for exposing features with documented caveats?
>>> > > > (excluding caveats that were discovered after the fact)
>>> > >
>>> > > Yes, and many of them have been extremely problematic, because Web
>>> > > authors will ignore the caveats.
>>> >
>>> > Right. I'd really like to avoid adding more if we can help it.
>>> >
>>> >
>>> > On Wed, 14 Nov 2012, Justin Novosad wrote:
>>> > >
>>> > > There is a recent improvement in Chrome called "deferred 2D canvas
>>> > > rendering" (enabled by default as of Chrome 23).  It is a mechanism
>>> that
>>> > > records 2d canvas commands during JS execution, and only executes
>>> them
>>> > > for real when the render buffer needs to be resolved (draw to screen,
>>> > > getImageData, toDataURL, etc.).  If you want to check it out, the
>>> guts
>>> > > are in Skia: SkGPipe is a sort of FIFO for graphics commands,
>>> > > SkDeferredCanvas is a wrapper that manages the GPipe and
>>> automatically
>>> > > flushes it and applies some command culling optimizations.
>>> > >
>>> > > So to come back to the problem of with and without subpixel AA
>>> buffers:
>>> > > if rendering is deferred, the non-AA buffer would never get
>>> rasterized
>>> > > (and possibly never even allocated), unless it needs to be.
>>>  Obviously
>>> > > there are practical limitations, for example we cannot store an
>>> > > unlimited stream of recorded commands, so if the canvas draws
>>> > > indefinitely without ever being cleared, at some point we have to
>>> > > rasterize the non-AA buffer just so that we can safely discard the
>>> > > recording data. Also, if at record time the necessary conditions for
>>> > > subpixel AA are not met, perhaps we just forget about it.
>>> > >
>>> > > I admit this is a complex solution for implementors, but it makes the
>>> > > management of subpixel-AA safety transparent to web authors.
>>> >
>>> > I think it'd be reasonable (for some definition of reasonable that
>>> > relates to whether it's compatible with the spec, anyway) for
>>> implementors
>>> > to do this today, without having to expose any control to the author.
>>> >
>>> >
>>> > On Thu, 15 Nov 2012, Fred Andrews wrote:
>>> > >
>>> > > The canvas that scripts draw into could be over-sized with the UA
>>> down
>>> > > sampling this to fit the target size and taking into account the
>>> > > sub-pixel screen layout when doing so.
>>> >
>>> > On Thu, 15 Nov 2012, Justin Novosad wrote:
>>> > >
>>> > > Obviously, that would be costly (x3 pixels), but I think it is a very
>>> > > realistic solution and relatively low hanging fruit. The over-sizing
>>> of
>>> > > the canvas would have to be handled under the hood by the UA though,
>>> > > because it depends on LCD component ordering and orientation, which
>>> > > means querying the OS/display driver. A lot of the kinks with the
>>> > > over-sized canvas approach have already been ironed out for solving
>>> the
>>> > > problem of High-DPI support ( put/getImageDataHD ), and I like the
>>> idea
>>> > > of unifying the two. Implementing this would mostly be a matter of
>>> > > adding per color component compositing of canvases. Also, the pixel
>>> > > aspect ratio would have to be taken into account for line drawing.
>>> >
>>> > getImageDataHD() requires that the pixels be square, but so long as
>>> that
>>> > is taken into consideration (e.g. by dropping down to square pixels if
>>> the
>>> > author calls putImageDataHD()) I think this could probably be made to
>>> work
>>> > within the spec's current requirements.
>>> >
>>> >
>>> > > Regarding the concerns about accessibility, I think the problem can
>>> be
>>> > > solved by using HitRegions with labels.
>>> >
>>> > Oh it _can_ be solved. That's not the problem. Accessibility is not
>>> about
>>> > what is _possible_, it's about what actually _is_. Most authors,
>>> > realistically speaking, aren't goin to be using hit regions
>>> sufficiently
>>> > for us to declare victory here.
>>> >
>>> >
>>> > > Come to think of it, there should be an option to make the UA do this
>>> > > automatically: create a HitRegion with a label every time text is
>>> drawn
>>> > > to a canvas.
>>> >
>>> > I considered doing that, but it gets really fiddly when you're doing
>>> > things like text that fades over multiple frames. In the end I decided
>>> > that the magic wasn't worth it, as it would likely screw up more often
>>> > than it would actually help.
>>> >
>>> > --
>>> > Ian Hickson               U+1047E                )\._.,--....,'``.
>>>  fL
>>> > http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._
>>> ,.
>>> > Things that are impossible just take longer.
>>> `._.-(,_..'--(,_..'`-.;.'
>>> >
>>>
>>
>>
>


From senorblanco at chromium.org  Wed Feb 13 11:25:22 2013
From: senorblanco at chromium.org (Stephen White)
Date: Wed, 13 Feb 2013 14:25:22 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
Message-ID: <CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>

On Wed, Feb 13, 2013 at 12:22 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> For blending optimizations, it might be better to introduce a function
> instead of a boolean attribute like 'opaque'.
> What you really want, is to matte [1] the canvas with a solid color so you
> can optimize compositing.
>
> How about this API:
>
> void applyMatte(DOMString color); // color is a CSS rgb color value (alpha
> is ignored)
>
>
> When you call this function, the canvas is matted with that color. If it's
> the first drawing call, you can just fill the canvas with that color (no
> compositing needed)
> After matting, you no longer have to read or update the alpha channel
> since it's always 1 which should speed up drawing.
>

Just to be sure we're on the same page, when I mentioned compositing
optimizations, I was referring to compositing the canvas backing store into
the page, not compositing operations within the canvas itself.

One advantage of using an element attribute is that it could be used at
backing store allocation time, to allocate RGB instead of RGBA.  Forcing a
reallocation of the backing store on attribute change would be consistent
with changing width and height of the canvas, which have the same effect.
 Doing so on a context operation would not.

If we did use a context function approach as you suggest, how would
subpixel AA be handled?  Would it be enabled on first call of the function
and never disabled?  Is there a way to query if the canvas is opaque once
it's called?  (I'm assuming that all changes to canvas alpha after the
first call would have to be ignored, since otherwise you'd have to sniff
every operation to see if it affected alpha, and "reset the bit", although
perhaps I'm misunderstanding your proposal.)

Stephen


From mounir at lamouri.fr  Wed Feb 13 11:29:12 2013
From: mounir at lamouri.fr (Mounir Lamouri)
Date: Wed, 13 Feb 2013 19:29:12 +0000
Subject: [whatwg] inputmode feedback
Message-ID: <511BE988.7070208@lamouri.fr>

Hi,

Mozilla did implement an inputmode attribute for the <input> element a
few months ago and the HTML specification has been updated after that to
introduce that attribute. Given that the specification and our
implementation was not matching, we decided to delay the release of that
feature [1] and not advertise it. We unfortunately had to push a
"x-inputmode" attribute in Firefox OS because our UI needed that feature
but we expect to replace this with a proper inputmode implementation as
soon as possible.

Basically, the Mozilla's inputmode attribute is describing behaviour,
the allowed value are mostly self-explanatory: auto, uppercase,
lowercase, titlecase, autocapitalized, digit and numeric.
Autocapitalized is capitalizing words at the beginning of a sentence and
the difference between digit and numeric is whether or not there should
be a decimal separator and numeric operators available.

The attribute as specified in HTML seems to focus on use cases, it
provides more semantic and takes into account the handling of
suggestions/corrections. However, the current set of values seems overly
complex.

To begin with, I think we should get rid of the "latin" prefix. The
three modes with that prefix are "latin", "latin-name" and "latin-prose"
but in none of those situations "latin" is mandatory.
The first one could be "text": we want to have typing aid enabled and
any other feature related to entering some basic non-formatted text.
(The difference between "verbatim" and this type is weak and "text"
might not be the best way to improve this.)
The second one is simply "name": whatever the script is, we want to
enter a name in this field.
The last one is "latin-prose": like the others, the use case is to write
some formatted-text, the script shouldn't have any impact.

Regarding the three Japanese specific types, it is not clear if
inputmode is the best way to solve the use cases intended to be solved.
Actually, 'kana' and 'katakana' are trying to give a hint about the
script that has to be used which seems to be orthogonal with the other
types. We could allow inputmode to have a set of values but that would
make the behaviour way more complex so I wonder if we couldn't try to
solve that problem with another attribute like inputscript.

Mozilla's implementation has 'numeric' and 'digit' and 'numeric' in the
HTML specification seems to match what we called 'digit'. It is not very
important but I believe it would be nicer to have 'numeric' renamed
'digit' to make things clearer and to keep the 'numeric' keyword
available in case of we need it later.

Mozilla's implementation also includes 'uppercase' which is a common use
case in the web and could be interesting but it isn't as important as
other types so it can be kept aside for later. The priority for us here
being to make the Web Platform competitive with native apps on Mobile.

Finally, it is not clear why 'tel', 'email' and 'url' are available.
Actually, tel would make sense if it wasn't already implemented as a
type (because the type is mostly an inputmode) but all of those
inputmode already have an associated type. The specification even say
"rarely necessary" and suggest to use the type. Why adding those
keywords in the first place then? I feel like we shouldn't add stuff
that we do not believe is useful. If it happens to be useful, we should
listen to feedback and see if we can fix the types (like make it easier
to have them not validate).

To conclude, Mozilla is interested in implementing this set of keywords:
verbatim, text, name, prose and digit (or numeric).
We would be interested to hear from other vendors. Is anybody planning
to implement inputmode? if that's the case, which set of keywords is
going to be implemented?

Feedback is welcome :)

[1] This is definitely working with Firefox Android Nightly, I don't
know for other channels.

Thanks,
--
Mounir


From cabanier at gmail.com  Wed Feb 13 14:31:12 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Wed, 13 Feb 2013 14:31:12 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
Message-ID: <CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>

On Wed, Feb 13, 2013 at 11:25 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Wed, Feb 13, 2013 at 12:22 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> For blending optimizations, it might be better to introduce a function
>> instead of a boolean attribute like 'opaque'.
>> What you really want, is to matte [1] the canvas with a solid color so
>> you can optimize compositing.
>>
>> How about this API:
>>
>> void applyMatte(DOMString color); // color is a CSS rgb color value
>> (alpha is ignored)
>>
>>
>> When you call this function, the canvas is matted with that color. If
>> it's the first drawing call, you can just fill the canvas with that color
>> (no compositing needed)
>> After matting, you no longer have to read or update the alpha channel
>> since it's always 1 which should speed up drawing.
>>
>
> Just to be sure we're on the same page, when I mentioned compositing
> optimizations, I was referring to compositing the canvas backing store into
> the page, not compositing operations within the canvas itself.
>

sorry, I didn't mean to say blending. This is for optimizing compositing
within the canvas and of the canvas into the page.


>
> One advantage of using an element attribute is that it could be used at
> backing store allocation time, to allocate RGB instead of RGBA.  Forcing a
> reallocation of the backing store on attribute change would be consistent
> with changing width and height of the canvas, which have the same effect.
>  Doing so on a context operation would not.
>

why not? There is no reason for you to allocate the backing store until
it's needed.
The strange thing with an element attribute is that you can't change it
back and it's also detached from the JS code that does the drawing.


>
> If we did use a context function approach as you suggest, how would
> subpixel AA be handled?  Would it be enabled on first call of the function
> and never disabled?
>

I did not think about subpixel AA.
If I read the mozilla proposal correctly, they do AA if they know that the
canvas is opaque.
So, with my proposal, there would be no AA until you call 'applyMatte'
(assuming you follow the mozilla way of doing AA).


> Is there a way to query if the canvas is opaque once it's called?
>

Wouldn't the user know that he called 'applyMatte'? Also why do you want to
query it?


>  (I'm assuming that all changes to canvas alpha after the first call would
> have to be ignored, since otherwise you'd have to sniff every operation to
> see if it affected alpha, and "reset the bit", although perhaps I'm
> misunderstanding your proposal.)
>

No, you don't have to do that and can still use alpha.
Simple alpha compositing is defined as follows [1] (in premultiplied alpha):

co = cs + cb x (1 - ?s)
?o = ?s + ?b x (1 - ?s)


If you know that the backdrop is matted (?b = 1), the second formula always
resolves to 1 so you can skip it.

1:
https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#porterduffcompositingoperators_srcover


From ian at invigoreight.com  Wed Feb 13 16:28:07 2013
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 14 Feb 2013 08:28:07 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
Message-ID: <CABr1FsfyfqfYCYeKkhxoPjH4V3Ng6z3_TpXxa30ug9HwodzXwg@mail.gmail.com>

Hi Steve,

Thanks. And sorry, but til now I still don't understand the differences
between whatwg and html wg. Could you please explain?

Regards,
Ian

On Thu, Feb 14, 2013 at 12:59 AM, Steve Faulkner
<faulkner.steve at gmail.com>wrote:

> Hi Ian,
>
> I cannot speak for whatwg, but from the W3C HTML spec side the main element
> is in the HTML 5.1 spec and has been implemented in browsers and so will be
> added to HTML5 spec at some point as it likely meets the CR exit criteria.
>
> as for it being a sectioning element, there is currently an open bug on
> that, which we be dealt with.
>
> If you want to discuss the specification of the main element in HTML 5.1
> specification feel free mail the html wg list. If you want to discuss
> definition as per the whatwg spec this is the place, although I will
> obviously follow ant discussions with interest
>
> regards
> SteveF
>
>
> Date: Wed, 13 Feb 2013 18:31:32 +0800
> > From: Ian Yang <ian at invigoreight.com>
> > To: whatwg <whatwg at whatwg.org>
> > Subject: [whatwg] Is <main> now an official HTML5 element?
> > Message-ID:
> >         <CABr1FsfcaX8=B8TReG8Sz36W=
>
> h1w0hRY61+LG=Cebo-ZUWYfqA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi editors and all other folks,
>
> I saw the SitePoint article "Introducing the New HTML5 <main>
> Element<http://www.sitepoint.com/html5-main-element/>"
> yesterday. Does that mean <main> element has been approved by all editors
> of the working group?
>
> However, in spec, it still says that <main> element is not a sectioning
> element. That means, in document outline, main content will form another
> tree structure instead of appearing under the original website tree
> structure. Can we have somebody advise on this? Is there a special
> consideration to not making <main> a sectioning element?
>
>
> Sincerely,
> Ian Yan
>


From aurelioderosa at gmail.com  Wed Feb 13 16:31:36 2013
From: aurelioderosa at gmail.com (Aurelio De Rosa)
Date: Thu, 14 Feb 2013 01:31:36 +0100
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CABr1FsfyfqfYCYeKkhxoPjH4V3Ng6z3_TpXxa30ug9HwodzXwg@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
	<CABr1FsfyfqfYCYeKkhxoPjH4V3Ng6z3_TpXxa30ug9HwodzXwg@mail.gmail.com>
Message-ID: <CANbOm4h=VFnQxuYhb40SizEEC8irMVi+9ZQ5E39ngm-TzEaKdg@mail.gmail.com>

I think this should answer your question:

http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F

Best regards

2013/2/14 Ian Yang <ian at invigoreight.com>

> Hi Steve,
>
> Thanks. And sorry, but til now I still don't understand the differences
> between whatwg and html wg. Could you please explain?
>
> Regards,
> Ian
>
> On Thu, Feb 14, 2013 at 12:59 AM, Steve Faulkner
> <faulkner.steve at gmail.com>wrote:
>
> > Hi Ian,
> >
> > I cannot speak for whatwg, but from the W3C HTML spec side the main
> element
> > is in the HTML 5.1 spec and has been implemented in browsers and so will
> be
> > added to HTML5 spec at some point as it likely meets the CR exit
> criteria.
> >
> > as for it being a sectioning element, there is currently an open bug on
> > that, which we be dealt with.
> >
> > If you want to discuss the specification of the main element in HTML 5.1
> > specification feel free mail the html wg list. If you want to discuss
> > definition as per the whatwg spec this is the place, although I will
> > obviously follow ant discussions with interest
> >
> > regards
> > SteveF
> >
> >
> > Date: Wed, 13 Feb 2013 18:31:32 +0800
> > > From: Ian Yang <ian at invigoreight.com>
> > > To: whatwg <whatwg at whatwg.org>
> > > Subject: [whatwg] Is <main> now an official HTML5 element?
> > > Message-ID:
> > >         <CABr1FsfcaX8=B8TReG8Sz36W=
> >
> > h1w0hRY61+LG=Cebo-ZUWYfqA at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Hi editors and all other folks,
> >
> > I saw the SitePoint article "Introducing the New HTML5 <main>
> > Element<http://www.sitepoint.com/html5-main-element/>"
> > yesterday. Does that mean <main> element has been approved by all editors
> > of the working group?
> >
> > However, in spec, it still says that <main> element is not a sectioning
> > element. That means, in document outline, main content will form another
> > tree structure instead of appearing under the original website tree
> > structure. Can we have somebody advise on this? Is there a special
> > consideration to not making <main> a sectioning element?
> >
> >
> > Sincerely,
> > Ian Yan
> >
>



-- 
Aurelio De Rosa
email: aurelioderosa at gmail.com
email:  a.derosa at audero.it
website: www.audero.it
user group: ug.audero.it


From ian at invigoreight.com  Wed Feb 13 16:36:08 2013
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 14 Feb 2013 08:36:08 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CANbOm4h=VFnQxuYhb40SizEEC8irMVi+9ZQ5E39ngm-TzEaKdg@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
	<CABr1FsfyfqfYCYeKkhxoPjH4V3Ng6z3_TpXxa30ug9HwodzXwg@mail.gmail.com>
	<CANbOm4h=VFnQxuYhb40SizEEC8irMVi+9ZQ5E39ngm-TzEaKdg@mail.gmail.com>
Message-ID: <CABr1Fsdv996h--xNuH-3JqXd177n7p86L_URgTvbO6EUOK2Q+A@mail.gmail.com>

Hi Aurelio,

I see. So whatwg mainly focus on the development of HTML and APIs needed
for web applications. Thank you very much.

Kind Regards,
Ian

On Thu, Feb 14, 2013 at 8:31 AM, Aurelio De Rosa <aurelioderosa at gmail.com>wrote:

> I think this should answer your question:
>
> http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F
>
> Best regards
>
>
> 2013/2/14 Ian Yang <ian at invigoreight.com>
>
>> Hi Steve,
>>
>> Thanks. And sorry, but til now I still don't understand the differences
>> between whatwg and html wg. Could you please explain?
>>
>> Regards,
>> Ian
>>
>> On Thu, Feb 14, 2013 at 12:59 AM, Steve Faulkner
>> <faulkner.steve at gmail.com>wrote:
>>
>> > Hi Ian,
>> >
>> > I cannot speak for whatwg, but from the W3C HTML spec side the main
>> element
>> > is in the HTML 5.1 spec and has been implemented in browsers and so
>> will be
>> > added to HTML5 spec at some point as it likely meets the CR exit
>> criteria.
>> >
>> > as for it being a sectioning element, there is currently an open bug on
>> > that, which we be dealt with.
>> >
>> > If you want to discuss the specification of the main element in HTML 5.1
>> > specification feel free mail the html wg list. If you want to discuss
>> > definition as per the whatwg spec this is the place, although I will
>> > obviously follow ant discussions with interest
>> >
>> > regards
>> > SteveF
>> >
>> >
>> > Date: Wed, 13 Feb 2013 18:31:32 +0800
>> > > From: Ian Yang <ian at invigoreight.com>
>> > > To: whatwg <whatwg at whatwg.org>
>> > > Subject: [whatwg] Is <main> now an official HTML5 element?
>> > > Message-ID:
>> > >         <CABr1FsfcaX8=B8TReG8Sz36W=
>> >
>> > h1w0hRY61+LG=Cebo-ZUWYfqA at mail.gmail.com>
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>> > Hi editors and all other folks,
>> >
>> > I saw the SitePoint article "Introducing the New HTML5 <main>
>> > Element<http://www.sitepoint.com/html5-main-element/>"
>> > yesterday. Does that mean <main> element has been approved by all
>> editors
>> > of the working group?
>> >
>> > However, in spec, it still says that <main> element is not a sectioning
>> > element. That means, in document outline, main content will form another
>> > tree structure instead of appearing under the original website tree
>> > structure. Can we have somebody advise on this? Is there a special
>> > consideration to not making <main> a sectioning element?
>> >
>> >
>> > Sincerely,
>> > Ian Yan
>> >
>>
>
>
>
> --
> Aurelio De Rosa
> email: aurelioderosa at gmail.com
> email:  a.derosa at audero.it
> website: www.audero.it
> user group: ug.audero.it
>


From ian at invigoreight.com  Wed Feb 13 17:21:10 2013
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 14 Feb 2013 09:21:10 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>
References: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
	<Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>
Message-ID: <CABr1FsdDTh4FFLWrcgGspH=gFSH_D5h_-Mq8KUmFgaczDgawiw@mail.gmail.com>

On Thu, Feb 14, 2013 at 1:06 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 13 Feb 2013, Ian Yang wrote:
> >
> > I saw the SitePoint article "Introducing the New HTML5 <main>
> > Element<http://www.sitepoint.com/html5-main-element/>" yesterday. Does
> > that mean <main> element has been approved by all editors of the working
> > group?
>
> <main> is currently in the HTML standard. That doesn't mean much, though.
> What means something is that <main> is now implemented by two browsers in
> their development builds. Once they ship in final versions, that's the
> point at which we know that the feature is part of the platform.
>
>
> > However, in spec, it still says that <main> element is not a sectioning
> > element.
>
> Correct. Broadly speaking, sectioning elements are those with headings;
> <main> doesn't typically have a heading, it contains the content after the
> heading, distinguishing it from the content that is "merely" heading and
> navigation and so forth.
>
>
> > That means, in document outline, main content will form another
> > tree structure instead of appearing under the original website tree
> > structure.
>
> I'm not sure what you mean here. The main content doesn't appear in the
> outline; the outline only contains the headers, essentially.
>
>
> > Can we have somebody advise on this? Is there a special consideration to
> > not making <main> a sectioning element?
>
> There's already corresponding sectioning elements to indicate something
> that is "main" content -- <article> or <section>, depending on what
> exactly the content is.
>
>
> The spec goes into some detail about this, including with examples, here:
>
>    http://whatwg.org/html#the-main-part-of-the-content
>    http://whatwg.org/html#the-main-element
>    http://whatwg.org/html#usage-summary-0
>    http://whatwg.org/html#sample-outlines
>

Thanks Hickson for providing information, especially those example links.

In the past, I always regarded a sectioning main content area is an
indispensable part in a document. Today, information above tell me that the
main content area seem doesn't need to be a titled section.

So it seems that the following markup contains one unnecessary <section>
and one unnecessary <h1>, and they cause one unnecessary indent in document
outline.

<!DOCTYPE html>
<title>lorem ipsum</title>
<header>
    <h1>Branding</h1>
    <nav>
        <h1>Navigation</h1>
        lorem ipsum
    </nav>
</header>
<section id="main" role="main">
    <h1>Main Content</h1>
    <section>
        <h1>Welcome</h1>
        lorem ipsum
    </section>
    <section>
        <h1>Intro</h1>
        lorem ipsum
    </section>
    <aside id="comp" role="complementary">
        <h1>Complementary Content</h1>
        <article>
            <h1>Latest News</h1>
            lorem ipsum
        </article>
        <article>
            <h1>Recent Comments</h1>
            lorem ipsum
        </article>
    </aside>
</section>
<footer>
    lorem ipsum
</footer>

1. Branding
        1. Navigation
        2. Main Content
                1. Welcome
                2. Intro
                3. Complementary Content
                        1. Latest News
                        2. Recent Comments


And the following markup and document outline are more appropriate. Since
the <main> is not a sectioning element, now it only serves as an element
for keyboard navigation (id="main") and for assistive technology to quick
navigate to (role="main").

<!DOCTYPE html>
<title>lorem ipsum</title>
<header>
    <h1>Branding</h1>
    <nav>
        <h1>Navigation</h1>
        lorem ipsum
    </nav>
</header>
<main id="main" role="main">
    <section>
        <h1>Welcome</h1>
        lorem ipsum
    </section>
    <section>
        <h1>Intro</h1>
        lorem ipsum
    </section>
    <aside id="comp" role="complementary">
        <h1>Complementary Content</h1>
        <article>
            <h1>Latest News</h1>
            lorem ipsum
        </article>
        <article>
            <h1>Recent Comments</h1>
            lorem ipsum
        </article>
    </aside>
</main>
<footer>
    lorem ipsum
</footer>

1. Branding
        1. Navigation
        2. Welcome
        3. Intro
        4. Complementary Content
                1. Latest News
                2. Recent Comments


If any of my above understanding is flawed, please point it out for me.
Thank you all.


Sincerely,
Ian Yang


From senorblanco at chromium.org  Wed Feb 13 17:39:24 2013
From: senorblanco at chromium.org (Stephen White)
Date: Wed, 13 Feb 2013 20:39:24 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
Message-ID: <CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>

On Wed, Feb 13, 2013 at 5:31 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> On Wed, Feb 13, 2013 at 11:25 AM, Stephen White <senorblanco at chromium.org
> >wrote:
>
> > On Wed, Feb 13, 2013 at 12:22 PM, Rik Cabanier <cabanier at gmail.com>
> wrote:
> >
> >> For blending optimizations, it might be better to introduce a function
> >> instead of a boolean attribute like 'opaque'.
> >> What you really want, is to matte [1] the canvas with a solid color so
> >> you can optimize compositing.
> >>
> >> How about this API:
> >>
> >> void applyMatte(DOMString color); // color is a CSS rgb color value
> >> (alpha is ignored)
> >>
> >>
> >> When you call this function, the canvas is matted with that color. If
> >> it's the first drawing call, you can just fill the canvas with that
> color
> >> (no compositing needed)
> >> After matting, you no longer have to read or update the alpha channel
> >> since it's always 1 which should speed up drawing.
> >>
> >
> > Just to be sure we're on the same page, when I mentioned compositing
> > optimizations, I was referring to compositing the canvas backing store
> into
> > the page, not compositing operations within the canvas itself.
> >
>
> sorry, I didn't mean to say blending. This is for optimizing compositing
> within the canvas and of the canvas into the page.
>
>
> >
> > One advantage of using an element attribute is that it could be used at
> > backing store allocation time, to allocate RGB instead of RGBA.  Forcing
> a
> > reallocation of the backing store on attribute change would be consistent
> > with changing width and height of the canvas, which have the same effect.
> >  Doing so on a context operation would not.
> >
>
> why not? There is no reason for you to allocate the backing store until
> it's needed.
>

True.  I was just trying to understand when you would use this function
more than once during canvas lifetime.  Presumably, that's the reason for
having a function, no?  If so, and you don't maintain any special state
about the opacity of the canvas, how is this different from an rgb()
fillRect()?


> The strange thing with an element attribute is that you can't change it
> back and it's also detached from the JS code that does the drawing.
>
>
You can change it back programmatically through the DOM, as you can with
the element width and height.


> > If we did use a context function approach as you suggest, how would
> > subpixel AA be handled?  Would it be enabled on first call of the
> function
> > and never disabled?
> >
>
> I did not think about subpixel AA.
> If I read the mozilla proposal correctly, they do AA if they know that the
> canvas is opaque.
> So, with my proposal, there would be no AA until you call 'applyMatte'
> (assuming you follow the mozilla way of doing AA).


OK, so there would have to be a bit of state saved at that point, in order
to know if subpixel AA is allowable?

At any rate, I don't think this works if you subsequently modify the
canvas's alpha (see below).

>
>
> > Is there a way to query if the canvas is opaque once it's called?
> >
>
> Wouldn't the user know that he called 'applyMatte'? Also why do you want to
> query it?


>
> >  (I'm assuming that all changes to canvas alpha after the first call
> would
> > have to be ignored, since otherwise you'd have to sniff every operation
> to
> > see if it affected alpha, and "reset the bit", although perhaps I'm
> > misunderstanding your proposal.)
> >
>
> No, you don't have to do that and can still use alpha.
> Simple alpha compositing is defined as follows [1] (in premultiplied
> alpha):
>
> co = cs + cb x (1 - ?s)
> ?o = ?s + ?b x (1 - ?s)
>
>
> If you know that the backdrop is matted (?b = 1), the second formula always
> resolves to 1 so you can skip it.
>

The problem is, canvas supports more than simple (source-over) compositing,
so there are ways of modifying the destination alpha back to non-1, e.g., a
primitive with non-1 alpha drawn with source-copy, or via putImageData().
 At that point, the state of the canvas's alpha is unknown, so the page
compositor can make no assumptions about its opacity.

Stephen


From ian at invigoreight.com  Wed Feb 13 18:50:22 2013
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 14 Feb 2013 10:50:22 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CABr1FsdDTh4FFLWrcgGspH=gFSH_D5h_-Mq8KUmFgaczDgawiw@mail.gmail.com>
References: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
	<Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>
	<CABr1FsdDTh4FFLWrcgGspH=gFSH_D5h_-Mq8KUmFgaczDgawiw@mail.gmail.com>
Message-ID: <CABr1FschgJcVXGYRGt_4fEVWog922PvHc_rS3hd2Obp8TmizFg@mail.gmail.com>

Sorry, maybe the markup structure still needs some modifications.

One thing needs to be figured out is that should <aside
role="complementary"> be contained within <main role="main">? Or rather, is
<aside role="complementary"> a supporting content for the entire document
or just for <main role="main">? If it is the latter, then <aside> is fine
being within <main>.

The spec doesn't look like it has clearly defined the relationship between
<main> and <aside>.

Any opinion will be appreciated. Thanks.


Kind Regards,
Ian Yang


From cabanier at gmail.com  Wed Feb 13 18:55:19 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Thu, 14 Feb 2013 13:55:19 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
Message-ID: <CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>

On Thu, Feb 14, 2013 at 12:39 PM, Stephen White <senorblanco at chromium.org>wrote:

> On Wed, Feb 13, 2013 at 5:31 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> On Wed, Feb 13, 2013 at 11:25 AM, Stephen White <senorblanco at chromium.org
>> >wrote:
>>
>> > On Wed, Feb 13, 2013 at 12:22 PM, Rik Cabanier <cabanier at gmail.com>
>> wrote:
>> >
>> >> For blending optimizations, it might be better to introduce a function
>> >> instead of a boolean attribute like 'opaque'.
>> >> What you really want, is to matte [1] the canvas with a solid color so
>> >> you can optimize compositing.
>> >>
>> >> How about this API:
>> >>
>> >> void applyMatte(DOMString color); // color is a CSS rgb color value
>> >> (alpha is ignored)
>> >>
>> >>
>> >> When you call this function, the canvas is matted with that color. If
>> >> it's the first drawing call, you can just fill the canvas with that
>> color
>> >> (no compositing needed)
>> >> After matting, you no longer have to read or update the alpha channel
>> >> since it's always 1 which should speed up drawing.
>> >>
>> >
>> > Just to be sure we're on the same page, when I mentioned compositing
>> > optimizations, I was referring to compositing the canvas backing store
>> into
>> > the page, not compositing operations within the canvas itself.
>> >
>>
>> sorry, I didn't mean to say blending. This is for optimizing compositing
>> within the canvas and of the canvas into the page.
>>
>>
>> >
>> > One advantage of using an element attribute is that it could be used at
>> > backing store allocation time, to allocate RGB instead of RGBA.
>>  Forcing a
>> > reallocation of the backing store on attribute change would be
>> consistent
>> > with changing width and height of the canvas, which have the same
>> effect.
>> >  Doing so on a context operation would not.
>> >
>>
>> why not? There is no reason for you to allocate the backing store until
>> it's needed.
>>
>
> True.  I was just trying to understand when you would use this function
> more than once during canvas lifetime.  Presumably, that's the reason for
> having a function, no?
>

You would need it again if you draw with a compositing mode that removes
alpha (like 'copy')


>  If so, and you don't maintain any special state about the opacity of the
> canvas, how is this different from an rgb() fillRect()?
>

pretty much the same except
- ignore alpha
- use destination-over
- automatically fills the whole canvas


>
>
>> The strange thing with an element attribute is that you can't change it
>> back and it's also detached from the JS code that does the drawing.
>>
>>
> You can change it back programmatically through the DOM, as you can with
> the element width and height.
>

But would it do something when you set it back? How would you know what
part was painted black or originally transparent?


>
>
>> > If we did use a context function approach as you suggest, how would
>> > subpixel AA be handled?  Would it be enabled on first call of the
>> function
>> > and never disabled?
>> >
>>
>> I did not think about subpixel AA.
>> If I read the mozilla proposal correctly, they do AA if they know that the
>> canvas is opaque.
>> So, with my proposal, there would be no AA until you call 'applyMatte'
>> (assuming you follow the mozilla way of doing AA).
>
>
> OK, so there would have to be a bit of state saved at that point, in order
> to know if subpixel AA is allowable?
>

Yes. It would be an optimisation under the hood that an advanced user can
use.


>
> At any rate, I don't think this works if you subsequently modify the
> canvas's alpha (see below).
>
>>
>>
>> > Is there a way to query if the canvas is opaque once it's called?
>> >
>>
>> Wouldn't the user know that he called 'applyMatte'? Also why do you want
>> to
>> query it?
>
>
>>
>> >  (I'm assuming that all changes to canvas alpha after the first call
>> would
>> > have to be ignored, since otherwise you'd have to sniff every operation
>> to
>> > see if it affected alpha, and "reset the bit", although perhaps I'm
>> > misunderstanding your proposal.)
>> >
>>
>> No, you don't have to do that and can still use alpha.
>> Simple alpha compositing is defined as follows [1] (in premultiplied
>> alpha):
>>
>> co = cs + cb x (1 - ?s)
>> ?o = ?s + ?b x (1 - ?s)
>>
>>
>> If you know that the backdrop is matted (?b = 1), the second formula
>> always
>> resolves to 1 so you can skip it.
>>
>
> The problem is, canvas supports more than simple (source-over)
> compositing, so there are ways of modifying the destination alpha back to
> non-1, e.g., a primitive with non-1 alpha drawn with source-copy, or via
> putImageData().  At that point, the state of the canvas's alpha is unknown,
> so the page compositor can make no assumptions about its opacity.
>

What would happen if you set 'opaque' to true and you draw with alpha and
'copy' compositing? It seems that that has the same issue (unless you're OK
with breaking drawing).


From robert at ocallahan.org  Wed Feb 13 19:12:16 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 14 Feb 2013 16:12:16 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
Message-ID: <CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>

On Thu, Feb 14, 2013 at 3:55 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> What would happen if you set 'opaque' to true and you draw with alpha and
> 'copy' compositing? It seems that that has the same issue (unless you're OK
> with breaking drawing).
>

The alpha values of all moz-opaque canvas pixels are simply not affected by
compositing.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From cabanier at gmail.com  Wed Feb 13 19:18:33 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Thu, 14 Feb 2013 14:18:33 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
Message-ID: <CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>

On Thu, Feb 14, 2013 at 2:12 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Feb 14, 2013 at 3:55 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> What would happen if you set 'opaque' to true and you draw with alpha and
>> 'copy' compositing? It seems that that has the same issue (unless you're
>> OK
>> with breaking drawing).
>>
>
> The alpha values of all moz-opaque canvas pixels are simply not affected
> by compositing.
>

Exactly! So, this will break drawing as the pixels with no alpha will be
black with no way to undo that.


From robert at ocallahan.org  Wed Feb 13 19:27:32 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 14 Feb 2013 16:27:32 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
Message-ID: <CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>

On Thu, Feb 14, 2013 at 4:18 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> On Thu, Feb 14, 2013 at 2:12 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Thu, Feb 14, 2013 at 3:55 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>
>>> What would happen if you set 'opaque' to true and you draw with alpha and
>>> 'copy' compositing? It seems that that has the same issue (unless you're
>>> OK
>>> with breaking drawing).
>>>
>>
>> The alpha values of all moz-opaque canvas pixels are simply not affected
>> by compositing.
>>
>
> Exactly! So, this will break drawing as the pixels with no alpha will be
> black with no way to undo that.
>

I don't know what you mean by "no way to undo that" or "break drawing".

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From cabanier at gmail.com  Wed Feb 13 20:16:56 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Thu, 14 Feb 2013 15:16:56 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
Message-ID: <CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>

On Thu, Feb 14, 2013 at 2:27 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Feb 14, 2013 at 4:18 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> On Thu, Feb 14, 2013 at 2:12 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>
>>> On Thu, Feb 14, 2013 at 3:55 PM, Rik Cabanier <cabanier at gmail.com>wrote:
>>>
>>>> What would happen if you set 'opaque' to true and you draw with alpha
>>>> and
>>>> 'copy' compositing? It seems that that has the same issue (unless
>>>> you're OK
>>>> with breaking drawing).
>>>>
>>>
>>> The alpha values of all moz-opaque canvas pixels are simply not affected
>>> by compositing.
>>>
>>
>> Exactly! So, this will break drawing as the pixels with no alpha will be
>> black with no way to undo that.
>>
>
> I don't know what you mean by "no way to undo that" or "break drawing".
>
>
My proposal doesn't change anything for the user as it has no side effects
(apart from faster drawing when possible).
Setting 'opaque' on the canvas actually changes how compositing works. For
instance, if you use 'copy' compositing with a partially transparent image,
you will draw black pixels where the image has no coverage. In addition,
partially transparent pixels will look darker the more transparent they are.

Looking at the WebKit implementation, I'm unsure how 'opaque' can
implemented for accelerated canvas. It might work with non-accelerated
canvas but would have to run some experiments.
I also look at mozilla's Core Graphics implementation and unless I'm
missing something, it doesn't have special code to handle 'opaque'. When do
you use this parameter?


From robert at ocallahan.org  Wed Feb 13 20:35:31 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 14 Feb 2013 17:35:31 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
Message-ID: <CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>

On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> Looking at the WebKit implementation, I'm unsure how 'opaque' can
> implemented for accelerated canvas. It might work with non-accelerated
> canvas but would have to run some experiments.
> I also look at mozilla's Core Graphics implementation and unless I'm
> missing something, it doesn't have special code to handle 'opaque'. When do
> you use this parameter?
>

CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That
selects a surface format that is passed down to the graphics layer when
creating the canvas surface. It's true that we don't currently do anything
with that when drawing with CoreGraphics. That would need to be cleaned up
before we started promoting this feature.

Now that you mention it, having to modify the definition of compositing is
a bit of a bummer for the 'opaque' attribute approach. I think we could do
everything we want using your approach --- internally keeping a flag to
indicate whether the alpha values of the canvas are all 1, setting it when
the canvas is filled with a solid color and clearing it when non-over
drawing (or clear()) are used. Let's try that!

But I think "matte" is unnecessarily obscure. How about adding a
clear(DOMString) method that does a 'copy' of the color to the entire
canvas buffer? The color could default to rgba(0,0,0,0).

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From chaals at yandex-team.ru  Wed Feb 13 20:37:16 2013
From: chaals at yandex-team.ru (Charles McCathie Nevile)
Date: Thu, 14 Feb 2013 05:37:16 +0100
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CANbOm4h=VFnQxuYhb40SizEEC8irMVi+9ZQ5E39ngm-TzEaKdg@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
	<CABr1FsfyfqfYCYeKkhxoPjH4V3Ng6z3_TpXxa30ug9HwodzXwg@mail.gmail.com>
	<CANbOm4h=VFnQxuYhb40SizEEC8irMVi+9ZQ5E39ngm-TzEaKdg@mail.gmail.com>
Message-ID: <op.wsha4ehcy3oazb@chaals.local>

Hi Ian,

On Thu, 14 Feb 2013 01:31:36 +0100, Aurelio De Rosa  
<aurelioderosa at gmail.com> wrote:

> I think this should answer your question:
>
> http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F

It doesn't seem to provide much useful information on the differences.

According to its charter <http://www.whatwg.org/charter>, WHAT-WG is a  
group of 9 individuals who work with a very simple set of rules (basically  
the editor of a specification decides what should be in it, but the 9  
people can decide other things by "overwhelming majority"). There is a  
mailing list, IRC, etc, and everyone else who contributes to the  
discussion is called a contributor.
More about how WHAT-WG works is described at  
http://wiki.whatwg.org/wiki/FAQ

The HTML WG is one of the working groups of W3C. The working group has a  
charter that describes some of how it works:  
<http://www.w3.org/2007/03/HTML-WG-charter> W3C itself is a consortium of  
member organisations, and the links from the HTML WG charter to the  
process document will lead you into more information about how W3C works.  
Note that in my personal opinion the Wikipedia page about W3C is outdated  
and very poor quality information.

cheers

Chaals

> Best regards
>
> 2013/2/14 Ian Yang <ian at invigoreight.com>
>
>> Hi Steve,
>>
>> Thanks. And sorry, but til now I still don't understand the differences
>> between whatwg and html wg. Could you please explain?
>>
>> Regards,
>> Ian
>>
>> On Thu, Feb 14, 2013 at 12:59 AM, Steve Faulkner
>> <faulkner.steve at gmail.com>wrote:
>>
>> > Hi Ian,
>> >
>> > I cannot speak for whatwg, but from the W3C HTML spec side the main
>> element
>> > is in the HTML 5.1 spec and has been implemented in browsers and so  
>> will
>> be
>> > added to HTML5 spec at some point as it likely meets the CR exit
>> criteria.
>> >
>> > as for it being a sectioning element, there is currently an open bug  
>> on
>> > that, which we be dealt with.
>> >
>> > If you want to discuss the specification of the main element in HTML  
>> 5.1
>> > specification feel free mail the html wg list. If you want to discuss
>> > definition as per the whatwg spec this is the place, although I will
>> > obviously follow ant discussions with interest
>> >
>> > regards
>> > SteveF
>> >
>> >
>> > Date: Wed, 13 Feb 2013 18:31:32 +0800
>> > > From: Ian Yang <ian at invigoreight.com>
>> > > To: whatwg <whatwg at whatwg.org>
>> > > Subject: [whatwg] Is <main> now an official HTML5 element?
>> > > Message-ID:
>> > >         <CABr1FsfcaX8=B8TReG8Sz36W=
>> >
>> > h1w0hRY61+LG=Cebo-ZUWYfqA at mail.gmail.com>
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>> > Hi editors and all other folks,
>> >
>> > I saw the SitePoint article "Introducing the New HTML5 <main>
>> > Element<http://www.sitepoint.com/html5-main-element/>"
>> > yesterday. Does that mean <main> element has been approved by all  
>> editors
>> > of the working group?
>> >
>> > However, in spec, it still says that <main> element is not a  
>> sectioning
>> > element. That means, in document outline, main content will form  
>> another
>> > tree structure instead of appearing under the original website tree
>> > structure. Can we have somebody advise on this? Is there a special
>> > consideration to not making <main> a sectioning element?
>> >
>> >
>> > Sincerely,
>> > Ian Yan
>> >
>>
>
>
>


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals at yandex-team.ru         Find more at http://yandex.com


From ian at invigoreight.com  Wed Feb 13 20:46:42 2013
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 14 Feb 2013 12:46:42 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <op.wsha4ehcy3oazb@chaals.local>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
	<CABr1FsfyfqfYCYeKkhxoPjH4V3Ng6z3_TpXxa30ug9HwodzXwg@mail.gmail.com>
	<CANbOm4h=VFnQxuYhb40SizEEC8irMVi+9ZQ5E39ngm-TzEaKdg@mail.gmail.com>
	<op.wsha4ehcy3oazb@chaals.local>
Message-ID: <CABr1FsfzQmR60Ew_6mZ8BneQ78gnDE2cmKxyAwPjSj+ig9+ZUw@mail.gmail.com>

On Thu, Feb 14, 2013 at 12:37 PM, Charles McCathie Nevile <
chaals at yandex-team.ru> wrote:

> Hi Ian,
>
>
> On Thu, 14 Feb 2013 01:31:36 +0100, Aurelio De Rosa <
> aurelioderosa at gmail.com> wrote:
>
>  I think this should answer your question:
>>
>> http://wiki.whatwg.org/wiki/**FAQ#What_is_the_WHATWG.3F<http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F>
>>
>
> It doesn't seem to provide much useful information on the differences.
>
> According to its charter <http://www.whatwg.org/charter**>, WHAT-WG is a
> group of 9 individuals who work with a very simple set of rules (basically
> the editor of a specification decides what should be in it, but the 9
> people can decide other things by "overwhelming majority"). There is a
> mailing list, IRC, etc, and everyone else who contributes to the discussion
> is called a contributor.
> More about how WHAT-WG works is described at http://wiki.whatwg.org/wiki/*
> *FAQ <http://wiki.whatwg.org/wiki/FAQ>
>
> The HTML WG is one of the working groups of W3C. The working group has a
> charter that describes some of how it works: <http://www.w3.org/2007/03/**
> HTML-WG-charter <http://www.w3.org/2007/03/HTML-WG-charter>> W3C itself
> is a consortium of member organisations, and the links from the HTML WG
> charter to the process document will lead you into more information about
> how W3C works. Note that in my personal opinion the Wikipedia page about
> W3C is outdated and very poor quality information.
>
> cheers
>
> Chaals
>
>
Hi Charles,

Thank you for providing resources. I will try to determine what topic
belongs to which group in the future.

Kind Regards,
Ian


>
>  Best regards
>>
>> 2013/2/14 Ian Yang <ian at invigoreight.com>
>>
>>  Hi Steve,
>>>
>>> Thanks. And sorry, but til now I still don't understand the differences
>>> between whatwg and html wg. Could you please explain?
>>>
>>> Regards,
>>> Ian
>>>
>>> On Thu, Feb 14, 2013 at 12:59 AM, Steve Faulkner
>>> <faulkner.steve at gmail.com>**wrote:
>>>
>>> > Hi Ian,
>>> >
>>> > I cannot speak for whatwg, but from the W3C HTML spec side the main
>>> element
>>> > is in the HTML 5.1 spec and has been implemented in browsers and so
>>> will
>>> be
>>> > added to HTML5 spec at some point as it likely meets the CR exit
>>> criteria.
>>> >
>>> > as for it being a sectioning element, there is currently an open bug on
>>> > that, which we be dealt with.
>>> >
>>> > If you want to discuss the specification of the main element in HTML
>>> 5.1
>>> > specification feel free mail the html wg list. If you want to discuss
>>> > definition as per the whatwg spec this is the place, although I will
>>> > obviously follow ant discussions with interest
>>> >
>>> > regards
>>> > SteveF
>>> >
>>> >
>>> > Date: Wed, 13 Feb 2013 18:31:32 +0800
>>> > > From: Ian Yang <ian at invigoreight.com>
>>> > > To: whatwg <whatwg at whatwg.org>
>>> > > Subject: [whatwg] Is <main> now an official HTML5 element?
>>> > > Message-ID:
>>> > >         <CABr1FsfcaX8=B8TReG8Sz36W=
>>> >
>>> > h1w0hRY61+LG=Cebo-ZUWYfqA@**mail.gmail.com<Cebo-ZUWYfqA at mail.gmail.com>
>>> >
>>> > Content-Type: text/plain; charset=ISO-8859-1
>>> >
>>> > Hi editors and all other folks,
>>> >
>>> > I saw the SitePoint article "Introducing the New HTML5 <main>
>>> > Element<http://www.sitepoint.**com/html5-main-element/<http://www.sitepoint.com/html5-main-element/>
>>> >"
>>> > yesterday. Does that mean <main> element has been approved by all
>>> editors
>>> > of the working group?
>>> >
>>> > However, in spec, it still says that <main> element is not a sectioning
>>> > element. That means, in document outline, main content will form
>>> another
>>> > tree structure instead of appearing under the original website tree
>>> > structure. Can we have somebody advise on this? Is there a special
>>> > consideration to not making <main> a sectioning element?
>>> >
>>> >
>>> > Sincerely,
>>> > Ian Yan
>>> >
>>>
>>>
>>
>>
>>
>
> --
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>       chaals at yandex-team.ru         Find more at http://yandex.com
>


From silviapfeiffer1 at gmail.com  Wed Feb 13 21:12:23 2013
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Thu, 14 Feb 2013 16:12:23 +1100
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CABr1FsfzQmR60Ew_6mZ8BneQ78gnDE2cmKxyAwPjSj+ig9+ZUw@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
	<CABr1FsfyfqfYCYeKkhxoPjH4V3Ng6z3_TpXxa30ug9HwodzXwg@mail.gmail.com>
	<CANbOm4h=VFnQxuYhb40SizEEC8irMVi+9ZQ5E39ngm-TzEaKdg@mail.gmail.com>
	<op.wsha4ehcy3oazb@chaals.local>
	<CABr1FsfzQmR60Ew_6mZ8BneQ78gnDE2cmKxyAwPjSj+ig9+ZUw@mail.gmail.com>
Message-ID: <CAHp8n2=pq7zJsA1++V8Cc=EWvMw3Qb3WVp1GTi5bLHhCJFK44w@mail.gmail.com>

> I will try to determine what topic
> belongs to which group in the future.

The simple answer is: have your discussion wherever you feel comfortable to
have it. Even if the specs differ, in the end what matters is what browsers
implement.

If a discussion about a topic is more appropriate in a different forum (and
that could also be the W3C CSS WG, a W3C Community Group, a IETF list or
other list), ppl will soon enough tell you.

HTH.
Silvia.


From ian at hixie.ch  Wed Feb 13 21:28:45 2013
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 14 Feb 2013 05:28:45 +0000 (UTC)
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CABr1FschgJcVXGYRGt_4fEVWog922PvHc_rS3hd2Obp8TmizFg@mail.gmail.com>
References: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
	<Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>
	<CABr1FsdDTh4FFLWrcgGspH=gFSH_D5h_-Mq8KUmFgaczDgawiw@mail.gmail.com>
	<CABr1FschgJcVXGYRGt_4fEVWog922PvHc_rS3hd2Obp8TmizFg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1302140439270.3956@ps20323.dreamhostps.com>

On Thu, 14 Feb 2013, Ian Yang wrote:
> 
> In the past, I always regarded a sectioning main content area is an 
> indispensable part in a document. Today, information above tell me that 
> the main content area seem doesn't need to be a titled section.

I'm not sure what you mean.

<main> is just there to help you if you need to style the main part of the 
doc, basically. It's separate from marking up a _section_ of the document, 
which is what you would do using <section> or <article>.


> So it seems that the following markup contains one unnecessary <section> 
> and one unnecessary <h1>, and they cause one unnecessary indent in 
> document outline.
> 
> <!DOCTYPE html>
> <title>lorem ipsum</title>
> <header>
>     <h1>Branding</h1>
>     <nav>
>         <h1>Navigation</h1>
>         lorem ipsum
>     </nav>
> </header>
> <section id="main" role="main">
>     <h1>Main Content</h1>
>     <section>
>         <h1>Welcome</h1>
>         lorem ipsum
>     </section>
>     <section>
>         <h1>Intro</h1>
>         lorem ipsum
>     </section>
>     <aside id="comp" role="complementary">
>         <h1>Complementary Content</h1>
>         <article>
>             <h1>Latest News</h1>
>             lorem ipsum
>         </article>
>         <article>
>             <h1>Recent Comments</h1>
>             lorem ipsum
>         </article>
>     </aside>
> </section>
> <footer>
>     lorem ipsum
> </footer>
> 
> 1. Branding
>         1. Navigation
>         2. Main Content
>                 1. Welcome
>                 2. Intro
>                 3. Complementary Content
>                         1. Latest News
>                         2. Recent Comments

It's easier to discuss with concrete cases. I haven't seen any pages that 
actually have an explicit "main content" section title, that seems a bit 
weird. You don't typically have a section in a book that contains the 
chapters, separate from the section that contains the table of contents or 
the appendices.


> And the following markup and document outline are more appropriate. 
>
> <!DOCTYPE html>
> <title>lorem ipsum</title>
> <header>
>     <h1>Branding</h1>
>     <nav>
>         <h1>Navigation</h1>
>         lorem ipsum
>     </nav>
> </header>
> <main id="main" role="main">
>     <section>
>         <h1>Welcome</h1>
>         lorem ipsum
>     </section>
>     <section>
>         <h1>Intro</h1>
>         lorem ipsum
>     </section>
>     <aside id="comp" role="complementary">
>         <h1>Complementary Content</h1>
>         <article>
>             <h1>Latest News</h1>
>             lorem ipsum
>         </article>
>         <article>
>             <h1>Recent Comments</h1>
>             lorem ipsum
>         </article>
>     </aside>
> </main>
> <footer>
>     lorem ipsum
> </footer>
> 
> 1. Branding
>         1. Navigation
>         2. Welcome
>         3. Intro
>         4. Complementary Content
>                 1. Latest News
>                 2. Recent Comments

That's fine too (modulo my comments below). You could also just not bother 
with the <main> element here, as in:

   <!DOCTYPE html>
   <title>lorem ipsum</title>
   <header>
       <h1>Branding</h1>
       <nav>
           <h1>Navigation</h1>
           lorem ipsum
       </nav>
   </header>
   <section>
       <h1>Welcome</h1>
       lorem ipsum
   </section>
   <section>
       <h1>Intro</h1>
       lorem ipsum
   </section>
   <aside>
       <h1>Complementary Content</h1>
       <article>
           <h1>Latest News</h1>
           lorem ipsum
       </article>
       <article>
           <h1>Recent Comments</h1>
           lorem ipsum
       </article>
   </aside>
   <footer>
       lorem ipsum
   </footer>
   
   1. Branding
           1. Navigation
           2. Welcome
           3. Intro
           4. Complementary Content
                   1. Latest News
                   2. Recent Comments

It's really an authoring choice.


> Since the <main> is not a sectioning element, now it only serves as an 
> element for keyboard navigation (id="main") and for assistive technology 
> to quick navigate to (role="main").

It mainly serves as a styling hook. (Accessibility tools can't rely on the 
page having a "main" element or an element with role=main, since most 
pages don't use it. HTML actually provides enough hooks already for UAs to 
help users navigate a page.)


On Thu, 14 Feb 2013, Ian Yang wrote:
> 
> One thing needs to be figured out is that should <aside
> role="complementary"> be contained within <main role="main">? Or rather, is
> <aside role="complementary"> a supporting content for the entire document
> or just for <main role="main">? If it is the latter, then <aside> is fine
> being within <main>.

The two elements are orthogonal. You can use one in the other or vice 
versa, or have them separate, or just one, or have neither.


> The spec doesn't look like it has clearly defined the relationship 
> between <main> and <aside>.

There is no relationship.

One indicates a section of a page that consists of content that is 
tangentially related to the content around the aside element, and which 
could be considered separate from that content, e.g. a sidebar. The other 
is just a container for the dominant contents of an element.

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at invigoreight.com  Wed Feb 13 21:49:51 2013
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 14 Feb 2013 13:49:51 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <Pine.LNX.4.64.1302140439270.3956@ps20323.dreamhostps.com>
References: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
	<Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>
	<CABr1FsdDTh4FFLWrcgGspH=gFSH_D5h_-Mq8KUmFgaczDgawiw@mail.gmail.com>
	<CABr1FschgJcVXGYRGt_4fEVWog922PvHc_rS3hd2Obp8TmizFg@mail.gmail.com>
	<Pine.LNX.4.64.1302140439270.3956@ps20323.dreamhostps.com>
Message-ID: <CABr1Fsfzg0tnExV6ZaC1_sj4CW9tfzo2BapkP+GqYL9EndkMWg@mail.gmail.com>

Hi Hickson,

Thanks for the help.

There is one thing which makes me confused. You mentioned the <main> is
"mainly serves as a styling hook." If what we need is just a styling hook,
why was <main> introduced? We could just use <div>. So iiuic, the <main>
still has its purpose because it natively has the role "main". Please
correct me if I'm wrong.


Kind Regards,
Ian Yang


From cabanier at gmail.com  Wed Feb 13 21:54:11 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Thu, 14 Feb 2013 16:54:11 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
Message-ID: <CAGN7qDAF_NjB8DHMXjmFd4qARifGTQOZZgQ3-jUU5qREYjsZuA@mail.gmail.com>

On Thu, Feb 14, 2013 at 3:35 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> Looking at the WebKit implementation, I'm unsure how 'opaque' can
>> implemented for accelerated canvas. It might work with non-accelerated
>> canvas but would have to run some experiments.
>> I also look at mozilla's Core Graphics implementation and unless I'm
>> missing something, it doesn't have special code to handle 'opaque'. When do
>> you use this parameter?
>>
>
> CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That
> selects a surface format that is passed down to the graphics layer when
> creating the canvas surface. It's true that we don't currently do anything
> with that when drawing with CoreGraphics. That would need to be cleaned up
> before we started promoting this feature.
>
> Now that you mention it, having to modify the definition of compositing is
> a bit of a bummer for the 'opaque' attribute approach. I think we could do
> everything we want using your approach --- internally keeping a flag to
> indicate whether the alpha values of the canvas are all 1, setting it when
> the canvas is filled with a solid color and clearing it when non-over
> drawing (or clear()) are used. Let's try that!
>
> But I think "matte" is unnecessarily obscure. How about adding a
> clear(DOMString) method that does a 'copy' of the color to the entire
> canvas buffer? The color could default to rgba(0,0,0,0).


Yes, that would work.
Drawbacks are:
- you can't draw onto a transparent backdrop and apply matting.
- if you use a compositing mode that changes the canvas alpha to something
else than 1, you can't optimize the drawing any more.

Both these are caused because 'clear' removes the canvas content.


From ian at hixie.ch  Wed Feb 13 22:55:51 2013
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 14 Feb 2013 06:55:51 +0000 (UTC)
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CABr1Fsfzg0tnExV6ZaC1_sj4CW9tfzo2BapkP+GqYL9EndkMWg@mail.gmail.com>
References: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
	<Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>
	<CABr1FsdDTh4FFLWrcgGspH=gFSH_D5h_-Mq8KUmFgaczDgawiw@mail.gmail.com>
	<CABr1FschgJcVXGYRGt_4fEVWog922PvHc_rS3hd2Obp8TmizFg@mail.gmail.com>
	<Pine.LNX.4.64.1302140439270.3956@ps20323.dreamhostps.com>
	<CABr1Fsfzg0tnExV6ZaC1_sj4CW9tfzo2BapkP+GqYL9EndkMWg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1302140654260.3956@ps20323.dreamhostps.com>

On Thu, 14 Feb 2013, Ian Yang wrote:
> 
> There is one thing which makes me confused. You mentioned the <main> is 
> "mainly serves as a styling hook." If what we need is just a styling 
> hook, why was <main> introduced? We could just use <div>.

Yeah, that was my argument too. But browser vendors added it, and the spec 
matches reality, so I added it to the spec.


> So iiuic, the <main> still has its purpose because it natively has the 
> role "main". Please correct me if I'm wrong.

The "main" role isn't necessary. IMHO it's a mistake in ARIA that this 
role even exists.

But that's a discussion for the ARIA list; this list is the wrong place 
to discuss ARIA.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From faulkner.steve at gmail.com  Wed Feb 13 23:24:42 2013
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Thu, 14 Feb 2013 07:24:42 +0000
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
Message-ID: <CA+ri+Vn6OUUaMXmzekMBLADypsaoATPtJhjsZb73yxhNTosO6A@mail.gmail.com>

Silvia wrote:

> Even if the specs differ, in the end what matters is what browsers
> implement.

Partially agree, it matters what conformance checkers implement and in the
case of <main>.
the major HTML conformance checker will implement the conformance rules in
the W3C HTML spec.
This will leave the WHATWG spec not matching reality.

It should also be noted that as implemented in browsers <main> is
implemented as per the W3C spec i.e.
<main> is mapped to role=main and because of this <main> is interpreted by
AT as a main landmark already.
This leaves the WHATWG spec not matching reality.

Beyond the priorities and domain of the browser vendors is the conformance
requirements and advice the HTML spec provides
to authors which can directly impact the experience for users. So I suggest
non browser differences matter very much.


regards
SteveF


From ian at invigoreight.com  Thu Feb 14 01:41:46 2013
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 14 Feb 2013 17:41:46 +0800
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <Pine.LNX.4.64.1302140654260.3956@ps20323.dreamhostps.com>
References: <CABr1FsfcaX8=B8TReG8Sz36W=h1w0hRY61+LG=Cebo-ZUWYfqA@mail.gmail.com>
	<Pine.LNX.4.64.1302131654160.3956@ps20323.dreamhostps.com>
	<CABr1FsdDTh4FFLWrcgGspH=gFSH_D5h_-Mq8KUmFgaczDgawiw@mail.gmail.com>
	<CABr1FschgJcVXGYRGt_4fEVWog922PvHc_rS3hd2Obp8TmizFg@mail.gmail.com>
	<Pine.LNX.4.64.1302140439270.3956@ps20323.dreamhostps.com>
	<CABr1Fsfzg0tnExV6ZaC1_sj4CW9tfzo2BapkP+GqYL9EndkMWg@mail.gmail.com>
	<Pine.LNX.4.64.1302140654260.3956@ps20323.dreamhostps.com>
Message-ID: <CABr1FsfEru_Gvuvx=xyZ0mHKJernBsdsrxZq7vjfRPOO5RGZzQ@mail.gmail.com>

On Thu, Feb 14, 2013 at 2:55 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 14 Feb 2013, Ian Yang wrote:
> >
> > There is one thing which makes me confused. You mentioned the <main> is
> > "mainly serves as a styling hook." If what we need is just a styling
> > hook, why was <main> introduced? We could just use <div>.
>
> Yeah, that was my argument too. But browser vendors added it, and the spec
> matches reality, so I added it to the spec.
>
>
> > So iiuic, the <main> still has its purpose because it natively has the
> > role "main". Please correct me if I'm wrong.
>
> The "main" role isn't necessary. IMHO it's a mistake in ARIA that this
> role even exists.
>
> But that's a discussion for the ARIA list; this list is the wrong place
> to discuss ARIA.
>

I see. Thanks anyway.

Regards,
Ian Yang


From faulkner.steve at gmail.com  Thu Feb 14 02:24:00 2013
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Thu, 14 Feb 2013 10:24:00 +0000
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CA+ri+Vn6OUUaMXmzekMBLADypsaoATPtJhjsZb73yxhNTosO6A@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
	<CA+ri+Vn6OUUaMXmzekMBLADypsaoATPtJhjsZb73yxhNTosO6A@mail.gmail.com>
Message-ID: <CA+ri+VmBu8HtbatoMZA0qv9qn3CjQQfv9R=tGOX6cHUPmP4bfw@mail.gmail.com>

Chaals wrote:

The HTML WG is one of the working groups of W3C. The working group has a
charter that describes some of how it works:
<http://www.w3.org/2007/03/HTML-WG-charter>


for those interested there is the up to date proposed charter which is
being reviewed currently:

http://www.w3.org/html/wg/charter/2012/


regards
SteveF


From senorblanco at chromium.org  Thu Feb 14 02:59:20 2013
From: senorblanco at chromium.org (Stephen White)
Date: Thu, 14 Feb 2013 05:59:20 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
Message-ID: <CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>

On Wed, Feb 13, 2013 at 11:35 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> Looking at the WebKit implementation, I'm unsure how 'opaque' can
>> implemented for accelerated canvas. It might work with non-accelerated
>> canvas but would have to run some experiments.
>> I also look at mozilla's Core Graphics implementation and unless I'm
>> missing something, it doesn't have special code to handle 'opaque'. When do
>> you use this parameter?
>>
>
> CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That
> selects a surface format that is passed down to the graphics layer when
> creating the canvas surface. It's true that we don't currently do anything
> with that when drawing with CoreGraphics. That would need to be cleaned up
> before we started promoting this feature.
>
> Now that you mention it, having to modify the definition of compositing is
> a bit of a bummer for the 'opaque' attribute approach. I think we could do
> everything we want using your approach --- internally keeping a flag to
> indicate whether the alpha values of the canvas are all 1, setting it when
> the canvas is filled with a solid color and clearing it when non-over
> drawing (or clear()) are used. Let's try that!
>

I think this is difficult to do in the general case, such as putImageData()
or drawImage() or patterns, since you would need to examine all the pixels
of the source image to determine if they contain non-1 alpha.  This would
be cost-prohibitive.

If it's just for the purposes of optimization, you could be conservative
and simply clear the flag when there's the potential for (but not certainty
of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
the behaviour becomes quite unpredictable for the web developer and hard to
spec crisply.

We could consider separating the two concepts again.  In an earlier thread,
there was an attempt to automatically determine all the places where it's
safe to enabled subpixel AA, but that seemed to result in a complex
implementation, with all cases still not being covered (such as
canvas-to-canvas drawImage()). The other alternative is programmatic
control over subpixel AA, using a context attribute. That was the first
thing that Justin proposed in the earlier thread, and would be my
preference as well (a fully-loaded footgun:  you can shoot yourself with
it, but the behaviour and performance characteristics are very easy to
understand and spec).  But there didn't seem to be agreement around that
either.

Which is how I ended up at the "moz-opaque" flag.  it restricts canvas to
the subset of operations which result in a 1 alpha in the backing store, to
allow optimizations and the use of subpixel AA.  I think that is actually
quite a useful subset (generally, the subset that doesn't need destination
alpha).  I believe the same thing can be achieved in WebGL by setting the
"alpha" attribute to false in WebGLContextAttributes.

Stephen


> But I think "matte" is unnecessarily obscure. How about adding a
> clear(DOMString) method that does a 'copy' of the color to the entire
> canvas buffer? The color could default to rgba(0,0,0,0).
>
>
> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>


From ian at hixie.ch  Thu Feb 14 07:21:06 2013
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 14 Feb 2013 15:21:06 +0000 (UTC)
Subject: [whatwg] Is <main> now an official HTML5 element?
In-Reply-To: <CA+ri+Vn6OUUaMXmzekMBLADypsaoATPtJhjsZb73yxhNTosO6A@mail.gmail.com>
References: <CA+ri+V=-Ksp=oy7rk=qDQMwSk5Y7gwY+gY67-TWKCOgVdE4E6A@mail.gmail.com>
	<CA+ri+Vn6OUUaMXmzekMBLADypsaoATPtJhjsZb73yxhNTosO6A@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1302141517190.3956@ps20323.dreamhostps.com>

On Thu, 14 Feb 2013, Steve Faulkner wrote:
> 
> Partially agree, it matters what conformance checkers implement and in 
> the case of <main>. the major HTML conformance checker will implement 
> the conformance rules in the W3C HTML spec. This will leave the WHATWG 
> spec not matching reality.

When it comes to conformance requirements, the reality that is most 
important to follow is usage, not validator implementations. But input 
from validator implementors is naturally taken into consideration. Should 
there be specific feedback from Henri or Mike on this topic, I will 
naturally examine it along with all other feedback.


> It should also be noted that as implemented in browsers <main> is 
> implemented as per the W3C spec i.e. <main> is mapped to role=main and 
> because of this <main> is interpreted by AT as a main landmark already. 
> This leaves the WHATWG spec not matching reality.

The spec already matches reality here as far as I can tell.


> Beyond the priorities and domain of the browser vendors is the 
> conformance requirements and advice the HTML spec provides to authors 
> which can directly impact the experience for users. So I suggest non 
> browser differences matter very much.

Agreed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From cabanier at gmail.com  Thu Feb 14 09:32:25 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Thu, 14 Feb 2013 09:32:25 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
Message-ID: <CAGN7qDBW+2Q_HAA5jTOPkpMDYZn88otpHmgJu2WTRF+fd=YnmQ@mail.gmail.com>

On Thu, Feb 14, 2013 at 2:59 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Wed, Feb 13, 2013 at 11:35 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>
>>> Looking at the WebKit implementation, I'm unsure how 'opaque' can
>>> implemented for accelerated canvas. It might work with non-accelerated
>>> canvas but would have to run some experiments.
>>> I also look at mozilla's Core Graphics implementation and unless I'm
>>> missing something, it doesn't have special code to handle 'opaque'. When do
>>> you use this parameter?
>>>
>>
>> CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That
>> selects a surface format that is passed down to the graphics layer when
>> creating the canvas surface. It's true that we don't currently do anything
>> with that when drawing with CoreGraphics. That would need to be cleaned up
>> before we started promoting this feature.
>>
>> Now that you mention it, having to modify the definition of compositing
>> is a bit of a bummer for the 'opaque' attribute approach. I think we could
>> do everything we want using your approach --- internally keeping a flag to
>> indicate whether the alpha values of the canvas are all 1, setting it when
>> the canvas is filled with a solid color and clearing it when non-over
>> drawing (or clear()) are used. Let's try that!
>>
>
> I think this is difficult to do in the general case, such as
> putImageData() or drawImage() or patterns, since you would need to examine
> all the pixels of the source image to determine if they contain non-1
> alpha.  This would be cost-prohibitive.
>

You only have to do that if you use compositing modes such as source-in
though.
In addition, you could detect at low cost that the CanvasImageSource is
opaque so some compositing modes would not reset.


>
> If it's just for the purposes of optimization, you could be conservative
> and simply clear the flag when there's the potential for (but not certainty
> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
> the behaviour becomes quite unpredictable for the web developer and hard to
> spec crisply.
>

Yes, that is worrisome. It seems another flag is in ordre.


>
> We could consider separating the two concepts again.  In an earlier
> thread, there was an attempt to automatically determine all the places
> where it's safe to enabled subpixel AA, but that seemed to result in a
> complex implementation, with all cases still not being covered (such as
> canvas-to-canvas drawImage()). The other alternative is programmatic
> control over subpixel AA, using a context attribute. That was the first
> thing that Justin proposed in the earlier thread, and would be my
> preference as well (a fully-loaded footgun:  you can shoot yourself with
> it, but the behaviour and performance characteristics are very easy to
> understand and spec).  But there didn't seem to be agreement around that
> either.
>

Can you refresh me on the issue with that? Is the cost too high?


>
> Which is how I ended up at the "moz-opaque" flag.  it restricts canvas to
> the subset of operations which result in a 1 alpha in the backing store, to
> allow optimizations and the use of subpixel AA.  I think that is actually
> quite a useful subset (generally, the subset that doesn't need destination
> alpha).  I believe the same thing can be achieved in WebGL by setting the
> "alpha" attribute to false in WebGLContextAttributes.
>

My fear is that this is too disruptive as it changes how canvas compositing
works.
It might also not be implemented easily on all platforms (especially the
ones that use the operating system to draw)


>
>
>> But I think "matte" is unnecessarily obscure. How about adding a
>> clear(DOMString) method that does a 'copy' of the color to the entire
>> canvas buffer? The color could default to rgba(0,0,0,0).
>>
>>
>> Rob
>> --
>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>
>
>


From senorblanco at chromium.org  Thu Feb 14 10:14:11 2013
From: senorblanco at chromium.org (Stephen White)
Date: Thu, 14 Feb 2013 13:14:11 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDBW+2Q_HAA5jTOPkpMDYZn88otpHmgJu2WTRF+fd=YnmQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAGN7qDBW+2Q_HAA5jTOPkpMDYZn88otpHmgJu2WTRF+fd=YnmQ@mail.gmail.com>
Message-ID: <CAPeKFThC=e-gXWV=F_r8JtA6D+jgHnvZCeyXZ4NGXLVzmDupNQ@mail.gmail.com>

On Thu, Feb 14, 2013 at 12:32 PM, Rik Cabanier <cabanier at gmail.com> wrote:

>
>
> On Thu, Feb 14, 2013 at 2:59 AM, Stephen White <senorblanco at chromium.org>wrote:
>
>> On Wed, Feb 13, 2013 at 11:35 PM, Robert O'Callahan <robert at ocallahan.org
>> > wrote:
>>
>>> On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier <cabanier at gmail.com>wrote:
>>>
>>>> Looking at the WebKit implementation, I'm unsure how 'opaque' can
>>>> implemented for accelerated canvas. It might work with non-accelerated
>>>> canvas but would have to run some experiments.
>>>> I also look at mozilla's Core Graphics implementation and unless I'm
>>>> missing something, it doesn't have special code to handle 'opaque'. When do
>>>> you use this parameter?
>>>>
>>>
>>> CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That
>>> selects a surface format that is passed down to the graphics layer when
>>> creating the canvas surface. It's true that we don't currently do anything
>>> with that when drawing with CoreGraphics. That would need to be cleaned up
>>> before we started promoting this feature.
>>>
>>> Now that you mention it, having to modify the definition of compositing
>>> is a bit of a bummer for the 'opaque' attribute approach. I think we could
>>> do everything we want using your approach --- internally keeping a flag to
>>> indicate whether the alpha values of the canvas are all 1, setting it when
>>> the canvas is filled with a solid color and clearing it when non-over
>>> drawing (or clear()) are used. Let's try that!
>>>
>>
>> I think this is difficult to do in the general case, such as
>> putImageData() or drawImage() or patterns, since you would need to examine
>> all the pixels of the source image to determine if they contain non-1
>> alpha.  This would be cost-prohibitive.
>>
>
> You only have to do that if you use compositing modes such as source-in
> though.
>

putImageData() ignores compositing mode, though, so it would always have to
be treated as alpha-modifying. If you declare with moz-opaque that the
canvas is opaque, you can still apply the optimization even with
putImageData().

In addition, you could detect at low cost that the CanvasImageSource is
> opaque so some compositing modes would not reset.
>

Not always.  For example, a partially-loaded bitmap has to be treated as
non-opaque until fully loaded, IIRC. And for canvas-to-canvas draws, you'd
be applying the same conservative algorithm that determined the opacity of
the source canvas, so it might miss some optimization cases that an
explicit declaration wouldn't.


> If it's just for the purposes of optimization, you could be conservative
>> and simply clear the flag when there's the potential for (but not certainty
>> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
>> the behaviour becomes quite unpredictable for the web developer and hard to
>> spec crisply.
>>
>
> Yes, that is worrisome. It seems another flag is in ordre.
>
>
>>
>> We could consider separating the two concepts again.  In an earlier
>> thread, there was an attempt to automatically determine all the places
>> where it's safe to enabled subpixel AA, but that seemed to result in a
>> complex implementation, with all cases still not being covered (such as
>> canvas-to-canvas drawImage()). The other alternative is programmatic
>> control over subpixel AA, using a context attribute. That was the first
>> thing that Justin proposed in the earlier thread, and would be my
>> preference as well (a fully-loaded footgun:  you can shoot yourself with
>> it, but the behaviour and performance characteristics are very easy to
>> understand and spec).  But there didn't seem to be agreement around that
>> either.
>>
>
> Can you refresh me on the issue with that? Is the cost too high?
>

Robert's comment:

> We'd have to define what happens when you use subpixel antialiasing "inco
rrectly",
> because we can be pretty sure authors will use it incorrectly and expect
to get interoperable behavior.

Ian Hickson's comment earlier in this thread:

> Do we have any reason to believe the majority of authors would make the
> right decisions here?
>
> (The main reason we haven't provided control over things like
antialiasing
> is that many authors tend to make terribly bad decisions.) (Before anyone
> gets offended, by the way: that you are reading this almost guarantees
> that you are above average in terms of authoring ability.)


>
>>
>> Which is how I ended up at the "moz-opaque" flag.  it restricts canvas to
>> the subset of operations which result in a 1 alpha in the backing store, to
>> allow optimizations and the use of subpixel AA.  I think that is actually
>> quite a useful subset (generally, the subset that doesn't need destination
>> alpha).  I believe the same thing can be achieved in WebGL by setting the
>> "alpha" attribute to false in WebGLContextAttributes.
>>
>
> My fear is that this is too disruptive as it changes how canvas
> compositing works.
>

It's opt-in, so it wouldn't affect existing content.


> It might also not be implemented easily on all platforms (especially the
> ones that use the operating system to draw)
>

It's pretty straightforward to implement with OpenGL:  allocate the backing
store as GL_RGB instead of GL_RGBA, or (if unsupported) clear the buffer to
opaque black and use glColorMask() to disable alpha writes.  Then for speed
during page compositing, disable blending.

Stephen

>
>
>>
>>
>>> But I think "matte" is unnecessarily obscure. How about adding a
>>> clear(DOMString) method that does a 'copy' of the color to the entire
>>> canvas buffer? The color could default to rgba(0,0,0,0).
>>>
>>>
>>> Rob
>>> --
>>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>>
>>
>>
>


From cabanier at gmail.com  Thu Feb 14 10:50:42 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Thu, 14 Feb 2013 10:50:42 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFThC=e-gXWV=F_r8JtA6D+jgHnvZCeyXZ4NGXLVzmDupNQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAGN7qDBW+2Q_HAA5jTOPkpMDYZn88otpHmgJu2WTRF+fd=YnmQ@mail.gmail.com>
	<CAPeKFThC=e-gXWV=F_r8JtA6D+jgHnvZCeyXZ4NGXLVzmDupNQ@mail.gmail.com>
Message-ID: <CAGN7qDD1n41DgY=_rZZwHR3xhwZxi9eaSSMO5JcvXCHioJ8+1A@mail.gmail.com>

On Thu, Feb 14, 2013 at 10:14 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Thu, Feb 14, 2013 at 12:32 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>>
>>
>> On Thu, Feb 14, 2013 at 2:59 AM, Stephen White <senorblanco at chromium.org>wrote:
>>
>>> On Wed, Feb 13, 2013 at 11:35 PM, Robert O'Callahan <
>>> robert at ocallahan.org> wrote:
>>>
>>>> On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier <cabanier at gmail.com>wrote:
>>>>
>>>>> Looking at the WebKit implementation, I'm unsure how 'opaque' can
>>>>> implemented for accelerated canvas. It might work with non-accelerated
>>>>> canvas but would have to run some experiments.
>>>>> I also look at mozilla's Core Graphics implementation and unless I'm
>>>>> missing something, it doesn't have special code to handle 'opaque'. When do
>>>>> you use this parameter?
>>>>>
>>>>
>>>> CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That
>>>> selects a surface format that is passed down to the graphics layer when
>>>> creating the canvas surface. It's true that we don't currently do anything
>>>> with that when drawing with CoreGraphics. That would need to be cleaned up
>>>> before we started promoting this feature.
>>>>
>>>> Now that you mention it, having to modify the definition of compositing
>>>> is a bit of a bummer for the 'opaque' attribute approach. I think we could
>>>> do everything we want using your approach --- internally keeping a flag to
>>>> indicate whether the alpha values of the canvas are all 1, setting it when
>>>> the canvas is filled with a solid color and clearing it when non-over
>>>> drawing (or clear()) are used. Let's try that!
>>>>
>>>
>>> I think this is difficult to do in the general case, such as
>>> putImageData() or drawImage() or patterns, since you would need to examine
>>> all the pixels of the source image to determine if they contain non-1
>>> alpha.  This would be cost-prohibitive.
>>>
>>
>> You only have to do that if you use compositing modes such as source-in
>> though.
>>
>
> putImageData() ignores compositing mode, though, so it would always have
> to be treated as alpha-modifying. If you declare with moz-opaque that the
> canvas is opaque, you can still apply the optimization even with
> putImageData().
>

no. Not if you use an opaque ImageDataSourece (such as a JPEG image or a
canvas source that knows that it's opaque.


> In addition, you could detect at low cost that the CanvasImageSource is
>> opaque so some compositing modes would not reset.
>>
>
> Not always.  For example, a partially-loaded bitmap has to be treated as
> non-opaque until fully loaded, IIRC.
>

partially loaded images are supposed to be ignored when you draw with them.


> And for canvas-to-canvas draws, you'd be applying the same conservative
> algorithm that determined the opacity of the source canvas, so it might
> miss some optimization cases that an explicit declaration wouldn't.\
>

Yes. You'd have to explicitly matte the other canvas too (if you use
putImageData or certain compositing modes).
That's still better than breaking compositing though...


>
>
>> If it's just for the purposes of optimization, you could be conservative
>>> and simply clear the flag when there's the potential for (but not certainty
>>> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
>>> the behaviour becomes quite unpredictable for the web developer and hard to
>>> spec crisply.
>>>
>>
>> Yes, that is worrisome. It seems another flag is in ordre.
>>
>>
>>>
>>> We could consider separating the two concepts again.  In an earlier
>>> thread, there was an attempt to automatically determine all the places
>>> where it's safe to enabled subpixel AA, but that seemed to result in a
>>> complex implementation, with all cases still not being covered (such as
>>> canvas-to-canvas drawImage()). The other alternative is programmatic
>>> control over subpixel AA, using a context attribute. That was the first
>>> thing that Justin proposed in the earlier thread, and would be my
>>> preference as well (a fully-loaded footgun:  you can shoot yourself with
>>> it, but the behaviour and performance characteristics are very easy to
>>> understand and spec).  But there didn't seem to be agreement around that
>>> either.
>>>
>>
>> Can you refresh me on the issue with that? Is the cost too high?
>>
>
> Robert's comment:
>
> > We'd have to define what happens when you use subpixel antialiasing
> "incorrectly",
> > because we can be pretty sure authors will use it incorrectly and
> expect to get interoperable behavior.
>
> Ian Hickson's comment earlier in this thread:
>
> > Do we have any reason to believe the majority of authors would make the
> > right decisions here?
> >
> > (The main reason we haven't provided control over things like
> antialiasing
> > is that many authors tend to make terribly bad decisions.) (Before
> anyone
> > gets offended, by the way: that you are reading this almost guarantees
> > that you are above average in terms of authoring ability.)
>

What is the technical issue? Why does anti-aliasing only work if you have
an opaque canvas?


>
>
>>
>>>
>>> Which is how I ended up at the "moz-opaque" flag.  it restricts canvas
>>> to the subset of operations which result in a 1 alpha in the backing store,
>>> to allow optimizations and the use of subpixel AA.  I think that is
>>> actually quite a useful subset (generally, the subset that doesn't need
>>> destination alpha).  I believe the same thing can be achieved in WebGL by
>>> setting the "alpha" attribute to false in WebGLContextAttributes.
>>>
>>
>> My fear is that this is too disruptive as it changes how canvas
>> compositing works.
>>
>
> It's opt-in, so it wouldn't affect existing content.
>
>
>> It might also not be implemented easily on all platforms (especially the
>> ones that use the operating system to draw)
>>
>
> It's pretty straightforward to implement with OpenGL:  allocate the
> backing store as GL_RGB instead of GL_RGBA, or (if unsupported) clear the
> buffer to opaque black and use glColorMask() to disable alpha writes.  Then
> for speed during page compositing, disable blending.
>

How about the accelerated core graphics backend? Direct2D?


>
> Stephen
>
>>
>>
>>>
>>>
>>>> But I think "matte" is unnecessarily obscure. How about adding a
>>>> clear(DOMString) method that does a 'copy' of the color to the entire
>>>> canvas buffer? The color could default to rgba(0,0,0,0).
>>>>
>>>>
>>>> Rob
>>>> --
>>>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>>>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>>>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>>>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>>>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>>>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>>>
>>>
>>>
>>
>


From robert at ocallahan.org  Thu Feb 14 19:21:20 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 15 Feb 2013 16:21:20 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
Message-ID: <CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>

On Thu, Feb 14, 2013 at 11:59 PM, Stephen White <senorblanco at chromium.org>wrote:

> I think this is difficult to do in the general case, such as
> putImageData() or drawImage() or patterns, since you would need to examine
> all the pixels of the source image to determine if they contain non-1
> alpha.  This would be cost-prohibitive.


> If it's just for the purposes of optimization, you could be conservative
> and simply clear the flag when there's the potential for (but not certainty
> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
> the behaviour becomes quite unpredictable for the web developer and hard to
> spec crisply.
>

What if we just said
a) non-over operators clear the subpixel AA flag
b) putImageData clears the subpixel AA flag
Both of these are infrequently used AFAIK. Authors could work around most
cases of b) by doing putImageData to another canvas and compositing it into
the destination with 'over'.

How bad would that be? Would it help if we added an attribute to the canvas
to let authors detect whether the subpixel AA flag is set?

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From ehs at pobox.com  Thu Feb 14 19:32:02 2013
From: ehs at pobox.com (Ed Summers)
Date: Thu, 14 Feb 2013 22:32:02 -0500
Subject: [whatwg] itemtypes from same vocabulary
In-Reply-To: <CACho_At=xBDkwcNV5AssDbMfsdk1FtjEFBSa7AM1fVxohy46Rg@mail.gmail.com>
References: <CABzDd=70TtoPhqQzpop+Y8YeeOM_SCwi8+hog=r-4yMn3G79zw@mail.gmail.com>
	<CACho_Av7dsGmxUozJv6Aj1xNhZJh9ESSujWKcA_KtX5AcT_Feg@mail.gmail.com>
	<CABzDd=6C_WQo9uyVowX+tBGvijMGx7VRvbeoRQKtaF4uHwduBQ@mail.gmail.com>
	<CACho_At=xBDkwcNV5AssDbMfsdk1FtjEFBSa7AM1fVxohy46Rg@mail.gmail.com>
Message-ID: <CABzDd=4-Kk=7-xBxvSNCjh1RQU6dwfxmTbdo-Y2RLWbtB8CW7Q@mail.gmail.com>

Thanks for the further pointer Lin. I can see that the change request
to allow multiple itemtypes came from John Giannandrea (Google), and
specifically concerned schema.org.

In John's email [1] he proposed limiting multiple types to being from
the same origin domain, not the same vocabulary as is stated in the
Microdata spec. It sounds like an obvious question, but is there a
precise definition of what is meant by "same vocabulary"? Or is it
just a hand wavy way of talking about what humans understand when
putting the itemtype URLs in their browsers, reading, and
understanding that they are types that are part of some larger
coherent whole?

//Ed

[1] http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0364.html

On Wed, Feb 13, 2013 at 11:36 AM, Lin Clark <lin.w.clark at gmail.com> wrote:
> Sorry if it wasn't clear, at the time that those discussions took place,
> only one itemtype could be used. Since then, the spec was changed to allow
> multiple itemtypes from the same vocabulary.
>
> However, both discussions also touch on the issue of using multiple
> vocabularies in itemtype. For example, my response [1] in the first.
>
> [1]
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0383.html


From cabanier at gmail.com  Thu Feb 14 19:44:13 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Fri, 15 Feb 2013 14:44:13 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
Message-ID: <CAGN7qDCQyb-_ioWRWoxBiQwAL7N2K5rPukbjWt7g-XjFfC509A@mail.gmail.com>

On Fri, Feb 15, 2013 at 2:21 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Feb 14, 2013 at 11:59 PM, Stephen White <senorblanco at chromium.org>wrote:
>
>> I think this is difficult to do in the general case, such as
>> putImageData() or drawImage() or patterns, since you would need to examine
>> all the pixels of the source image to determine if they contain non-1
>> alpha.  This would be cost-prohibitive.
>
>
>> If it's just for the purposes of optimization, you could be conservative
>> and simply clear the flag when there's the potential for (but not certainty
>> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
>> the behaviour becomes quite unpredictable for the web developer and hard to
>> spec crisply.
>>
>
> What if we just said
> a) non-over operators clear the subpixel AA flag
> b) putImageData clears the subpixel AA flag
> Both of these are infrequently used AFAIK. Authors could work around most
> cases of b) by doing putImageData to another canvas and compositing it into
> the destination with 'over'.
>

Yes, that's pretty much my proposal. Except putImageData could detect it
but that might be too hard for authors to figure out.


>
> How bad would that be? Would it help if we added an attribute to the
> canvas to let authors detect whether the subpixel AA flag is set?


I think that would be very helpful.

So, if you clear (or matte) the canvas, the flag becomes true but if you do
an operator that removes alpha, it will become false.


>
>
> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>


From mkwst at google.com  Fri Feb 15 00:08:35 2013
From: mkwst at google.com (Mike West)
Date: Fri, 15 Feb 2013 09:08:35 +0100
Subject: [whatwg] Sandboxed IFrames and downloads.
In-Reply-To: <CAKXHy=eHTuTehhaAsFdumu-Rr1sgJZfRMGKOfnYUKcEV+T3gSw@mail.gmail.com>
References: <CAKXHy=eHTuTehhaAsFdumu-Rr1sgJZfRMGKOfnYUKcEV+T3gSw@mail.gmail.com>
Message-ID: <CAKXHy=exj5SjiUiwFxdypd0HQrSPpHnaPFA5rQg0MWH1gU-GPg@mail.gmail.com>

Ping. Is this a terrible idea? :)

--
Mike West <mkwst at google.com>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 M?nchen, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91


On Sat, Feb 2, 2013 at 7:11 PM, Mike West <mkwst at google.com> wrote:

> It's currently possible to force a download by serving a file with a
> "Content-Disposition: attachment; filename=..." header. Notably, this
> mechanism can be used to download a file with minimal user interaction by
> including the resource to be downloaded in an IFrame. This holds even for
> sandboxed IFrames, as demonstrated by
> http://lcamtuf.coredump.cx/sandboxed.html (clicking that link will
> download a file, fair warning).
>
> It seems consistent with the general thought behind the `sandbox`
> attribute that it should control downloads as well as the bits it already
> locks down. I'd propose adjusting the spec to include a sandboxed downloads
> flag, which, when present, would block all downloads from inside the frame
> (or, perhaps only require user confirmation?). This restriction could be
> lifted via an 'allow-downloads' keyword, if present in the sandbox
> attribute's token list.
>
> WDYT?
>
> --
> Mike West <mkwst at google.com>, Developer Advocate
> Google Germany GmbH, Dienerstrasse 12, 80331 M?nchen, Germany
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>


From kochi at google.com  Fri Feb 15 00:28:03 2013
From: kochi at google.com (=?UTF-8?B?VGFrYXlvc2hpIEtvY2hpICjmsrPlhoUg6ZqG5LuBKQ==?=)
Date: Fri, 15 Feb 2013 17:28:03 +0900
Subject: [whatwg] inputmode feedback
In-Reply-To: <511BE988.7070208@lamouri.fr>
References: <511BE988.7070208@lamouri.fr>
Message-ID: <CADP2=hp-yPwWAKpeuPUwaAF=LmMfyC0Uw2_KxgQGY7cr3GaKuA@mail.gmail.com>

Hello Mounir,

On Thu, Feb 14, 2013 at 4:29 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:

> Regarding the three Japanese specific types, it is not clear if
> inputmode is the best way to solve the use cases intended to be solved.
> Actually, 'kana' and 'katakana' are trying to give a hint about the
> script that has to be used which seems to be orthogonal with the other
> types. We could allow inputmode to have a set of values but that would
> make the behaviour way more complex so I wonder if we couldn't try to
> solve that problem with another attribute like inputscript.
>
>
"three Japanese specific types"? 'kana', 'katakana', and 'full-width-latin"?

I agree that it is weird 'kana' and 'katakana' are listed as inputmode
attribute,
and 'inputscript' sounds more reasonable place where they should be listed.

As you probably know, there is also 'ime-mode' CSS style which IE/FF
implements
(and still proposed in CSS3 UI at http://www.w3.org/TR/css3-ui/#ime-mode),
which makes this more complex to use.

People may want to control IME input mode like the way Flash can,
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/IME.html
but it it is unfortunate that controlling IME from web apps is so
distributed (CSS, input attribute,
DOM lv3 compositionevent and IME API).

That said, even though authors of web apps may want to force the IME mode or
its script mode for user's sake, it may cause user's confusion as they are
so accustomed to change mode manually where such mode is required.
So if a web app sets some mode, the user may toggle it back to unintended
mode
and get frustrated.

-- 
Takayoshi Kochi


From whatwg-20070806 at james-ross.co.uk  Fri Feb 15 01:30:17 2013
From: whatwg-20070806 at james-ross.co.uk (James Ross)
Date: Fri, 15 Feb 2013 09:30:17 +0000
Subject: [whatwg] Sandboxed IFrames and downloads.
In-Reply-To: <CAKXHy=exj5SjiUiwFxdypd0HQrSPpHnaPFA5rQg0MWH1gU-GPg@mail.gmail.com>
References: <CAKXHy=eHTuTehhaAsFdumu-Rr1sgJZfRMGKOfnYUKcEV+T3gSw@mail.gmail.com>,
	<CAKXHy=exj5SjiUiwFxdypd0HQrSPpHnaPFA5rQg0MWH1gU-GPg@mail.gmail.com>
Message-ID: <DUB002-W5348442820BDCFFF2C96E8E30E0@phx.gbl>

A quick test across browsers would suggest others think it is a reasonable protection to include: both Internet Explorer 10 and Firefox 18 block (ignore) the download attempt in the sandboxed <iframe>.
  
 I couldn't find any documentation on either browser doing this, though, or if they have a sandbox flag to allow it.

-- 
James Ross silver at warwickcompsoc.co.uk
 > From: mkwst at google.com
> Date: Fri, 15 Feb 2013 09:08:35 +0100
> To: whatwg at whatwg.org
> Subject: Re: [whatwg] Sandboxed IFrames and downloads.
> 
> Ping. Is this a terrible idea? :)
> 
> --
> Mike West <mkwst at google.com>, Developer Advocate
> Google Germany GmbH, Dienerstrasse 12, 80331 M?nchen, Germany
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
> 
> 
> On Sat, Feb 2, 2013 at 7:11 PM, Mike West <mkwst at google.com> wrote:
> 
> > It's currently possible to force a download by serving a file with a
> > "Content-Disposition: attachment; filename=..." header. Notably, this
> > mechanism can be used to download a file with minimal user interaction by
> > including the resource to be downloaded in an IFrame. This holds even for
> > sandboxed IFrames, as demonstrated by
> > http://lcamtuf.coredump.cx/sandboxed.html (clicking that link will
> > download a file, fair warning).
> >
> > It seems consistent with the general thought behind the `sandbox`
> > attribute that it should control downloads as well as the bits it already
> > locks down. I'd propose adjusting the spec to include a sandboxed downloads
> > flag, which, when present, would block all downloads from inside the frame
> > (or, perhaps only require user confirmation?). This restriction could be
> > lifted via an 'allow-downloads' keyword, if present in the sandbox
> > attribute's token list.
> >
> > WDYT?
> >
> > --
> > Mike West <mkwst at google.com>, Developer Advocate
> > Google Germany GmbH, Dienerstrasse 12, 80331 M?nchen, Germany
> > Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
> >
 		 	   		  

From jonas at sicking.cc  Fri Feb 15 01:45:16 2013
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 15 Feb 2013 01:45:16 -0800
Subject: [whatwg] inputmode feedback
In-Reply-To: <511BE988.7070208@lamouri.fr>
References: <511BE988.7070208@lamouri.fr>
Message-ID: <CA+c2ei_d41LaAy_WNpFLawfTmSe-OpmG=wL7VyvbWwG1iVKrDQ@mail.gmail.com>

On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:
> Hi,
>
> Mozilla did implement an inputmode attribute for the <input> element a
> few months ago and the HTML specification has been updated after that to
> introduce that attribute. Given that the specification and our
> implementation was not matching, we decided to delay the release of that
> feature [1] and not advertise it. We unfortunately had to push a
> "x-inputmode" attribute in Firefox OS because our UI needed that feature
> but we expect to replace this with a proper inputmode implementation as
> soon as possible.
>
> Basically, the Mozilla's inputmode attribute is describing behaviour,
> the allowed value are mostly self-explanatory: auto, uppercase,
> lowercase, titlecase, autocapitalized, digit and numeric.

What's the difference between "auto" and "autocapitalized"?

> To conclude, Mozilla is interested in implementing this set of keywords:
> verbatim, text, name, prose and digit (or numeric).

I have to say, these feel a lot less understandable than the types
currently implemented in x-inputmode.

Using semantic names might give us the warm fuzzies, but is there
really any semantic use we will get out of these that we wouldn't by
using "lowercase", "titlecase" or "autocapitalized"?

I take it verbatim and name would disable any spelling corrections,
and name would also titlecase? But the difference between text and
prose seems really hard to understand. I can't even understand the
actual behavioral difference (which is what authors actually care
about) reading the spec, much less guessing by the name.

/ Jonas


From jonas at sicking.cc  Fri Feb 15 01:50:58 2013
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 15 Feb 2013 01:50:58 -0800
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CAOp6jLYEKjS3Cg8pPfrzSSPbKCgD0uRO9uu0M-6PLZ7FObqVsQ@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CADnb78hnVHE-fV=LTw0WCjbNgWbbo1+qZ9BsMeNM-xqg4f+cjw@mail.gmail.com>
	<CAOp6jLYEKjS3Cg8pPfrzSSPbKCgD0uRO9uu0M-6PLZ7FObqVsQ@mail.gmail.com>
Message-ID: <CA+c2ei-bq6qbV4HMcYWWN0iWTP68XFbUQpZD39zWuU2qo4y6ow@mail.gmail.com>

On Thu, Jan 24, 2013 at 2:49 AM, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Thu, Jan 24, 2013 at 9:44 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
>
>> On Wed, Jan 23, 2013 at 4:19 AM, Robert O'Callahan <robert at ocallahan.org>
>> wrote:
>> > I think this would be a worthwhile addition to the Web platform.
>>
>> It's somewhat ironic this happened, especially with Mozilla leading! I
>> advocated this approach from the start:
>>
>> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1515.html
>> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1576.html
>>
>
> Heh. I apologize on Jonas' behalf :-).

I don't think that I've argued against it. What I've argued against is
having this be the *only* way to read out of a blob and into things
that traditionally use URLs.

I.e. I've just been arguing that we need createObjectURL as well.

Also, for what it's worth, I'm holding out hope that we can change
createObjectURL to be autorevoking by default. That's what the latest
drafts are saying and no implementation has objected, despite repeated
pokings.

/ Jonas


From robert at ocallahan.org  Fri Feb 15 02:43:58 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 15 Feb 2013 23:43:58 +1300
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CA+c2ei-bq6qbV4HMcYWWN0iWTP68XFbUQpZD39zWuU2qo4y6ow@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CADnb78hnVHE-fV=LTw0WCjbNgWbbo1+qZ9BsMeNM-xqg4f+cjw@mail.gmail.com>
	<CAOp6jLYEKjS3Cg8pPfrzSSPbKCgD0uRO9uu0M-6PLZ7FObqVsQ@mail.gmail.com>
	<CA+c2ei-bq6qbV4HMcYWWN0iWTP68XFbUQpZD39zWuU2qo4y6ow@mail.gmail.com>
Message-ID: <CAOp6jLa+ZJC=2GxNdxkhX0VOPmNGdg921-do=kLHYqFAHJFqnA@mail.gmail.com>

On Fri, Feb 15, 2013 at 10:50 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> Also, for what it's worth, I'm holding out hope that we can change
> createObjectURL to be autorevoking by default. That's what the latest
> drafts are saying and no implementation has objected, despite repeated
> pokings.
>

Has any implementation actually taken the plunge?

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From jonas at sicking.cc  Fri Feb 15 04:37:58 2013
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 15 Feb 2013 04:37:58 -0800
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CAOp6jLa+ZJC=2GxNdxkhX0VOPmNGdg921-do=kLHYqFAHJFqnA@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CADnb78hnVHE-fV=LTw0WCjbNgWbbo1+qZ9BsMeNM-xqg4f+cjw@mail.gmail.com>
	<CAOp6jLYEKjS3Cg8pPfrzSSPbKCgD0uRO9uu0M-6PLZ7FObqVsQ@mail.gmail.com>
	<CA+c2ei-bq6qbV4HMcYWWN0iWTP68XFbUQpZD39zWuU2qo4y6ow@mail.gmail.com>
	<CAOp6jLa+ZJC=2GxNdxkhX0VOPmNGdg921-do=kLHYqFAHJFqnA@mail.gmail.com>
Message-ID: <CA+c2ei_TGhJmmOgQvUB1nr6Py_+1j4Oe0DKMR7anDQyrAXwV0w@mail.gmail.com>

On Fri, Feb 15, 2013 at 2:43 AM, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Fri, Feb 15, 2013 at 10:50 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> Also, for what it's worth, I'm holding out hope that we can change
>> createObjectURL to be autorevoking by default. That's what the latest
>> drafts are saying and no implementation has objected, despite repeated
>> pokings.
>
> Has any implementation actually taken the plunge?

It's a fairly recent change to the spec, so no. I think we should give
it a try in Firefox.

/ Jonas


From glenn at zewt.org  Fri Feb 15 06:46:02 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 15 Feb 2013 08:46:02 -0600
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
Message-ID: <CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>

On Tue, Jan 22, 2013 at 9:19 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> Currently the only way to use one of these objects as the source of a media
> element is via "element.src = URL.createObjectURL(object)". This is
> problematic because the URLs minted by createObjectURL require manual
> revocation. (Forms of auto-revocation have been proposed but a) they seem
> difficult to spec in a rational way and b) we will not be able to make
> auto-revocation the default.)


a) This isn't the case.  The tricky bit was defining precisely when
autorevocation happens; this has been resolved (the "global script clean-up
jobs list").  There's a remaining piece (
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765), but while it'll take
some thought to do that in a clean way (so it can be applied to different
APIs concisely), there's nothing magic there.
b) Even if we can't make it the default, there are much cleaner solutions
than bloating other APIs.  For example, a separate method can default to
auto-revoke, so you can say eg. img.src = blob.createRevokingURL().  I
don't like adding APIs that are just copies of other APIs with different
defaults, but it's much less evil than adding a whole separate mechanism.
In any case, explicitly saying img.src = URL.createObjectURL(blob,
{autoRevoke: true}) isn't actually that painful.

-- 
Glenn Maynard


From senorblanco at chromium.org  Fri Feb 15 07:35:42 2013
From: senorblanco at chromium.org (Stephen White)
Date: Fri, 15 Feb 2013 10:35:42 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
Message-ID: <CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>

On Thu, Feb 14, 2013 at 10:21 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Feb 14, 2013 at 11:59 PM, Stephen White <senorblanco at chromium.org>wrote:
>
>> I think this is difficult to do in the general case, such as
>> putImageData() or drawImage() or patterns, since you would need to examine
>> all the pixels of the source image to determine if they contain non-1
>> alpha.  This would be cost-prohibitive.
>
>
>> If it's just for the purposes of optimization, you could be conservative
>> and simply clear the flag when there's the potential for (but not certainty
>> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
>> the behaviour becomes quite unpredictable for the web developer and hard to
>> spec crisply.
>>
>
> What if we just said
> a) non-over operators clear the subpixel AA flag
> b) putImageData clears the subpixel AA flag
> Both of these are infrequently used AFAIK. Authors could work around most
> cases of b) by doing putImageData to another canvas and compositing it into
> the destination with 'over'.
>

Even with these constraints, I don't think we can guarantee that it's safe
to use LCD AA text. Once you've drawn with LCD AA text, even if it's safe
at the time of drawing, there's no guarantee that it will be safe later.
 For instance, if you then drawImage() that canvas rotated into another
canvas, or even just full-page-zoom it, you'll see colour fringing. Or
apply CSS 2D or 3D transforms. There are also existing apps which use
canvas for 2D text glyphs, and then transform and place them rotated in
WebGL. Those will show colour fringing. Even within canvas, there may be a
way to break it if the LCD AA text is drawn first and a dest-alpha
compositing mode is used overtop (I haven't verified this though).

So I'm starting to think that LCD AA text really has to be opt-in, to avoid
breaking existing content. By opting it, you're agreeing that these
artifacts are acceptable for your app. For example, you know that even if
you're going to do a canvas-to-canvas draw, you're always going to draw at
1:1 scale and no rotation.

Stephen



>
> How bad would that be? Would it help if we added an attribute to the
> canvas to let authors detect whether the subpixel AA flag is set?
>
>
> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>


From cabanier at gmail.com  Fri Feb 15 08:04:08 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Sat, 16 Feb 2013 03:04:08 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
Message-ID: <CAGN7qDA59YvDOkGFTLzG7-Bn3s4m7aav7O7UemeQ+BuZXN-gXw@mail.gmail.com>

On Sat, Feb 16, 2013 at 2:35 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Thu, Feb 14, 2013 at 10:21 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Thu, Feb 14, 2013 at 11:59 PM, Stephen White <senorblanco at chromium.org
>> > wrote:
>>
>>> I think this is difficult to do in the general case, such as
>>> putImageData() or drawImage() or patterns, since you would need to examine
>>> all the pixels of the source image to determine if they contain non-1
>>> alpha.  This would be cost-prohibitive.
>>
>>
>>> If it's just for the purposes of optimization, you could be conservative
>>> and simply clear the flag when there's the potential for (but not certainty
>>> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
>>> the behaviour becomes quite unpredictable for the web developer and hard to
>>> spec crisply.
>>>
>>
>> What if we just said
>> a) non-over operators clear the subpixel AA flag
>> b) putImageData clears the subpixel AA flag
>> Both of these are infrequently used AFAIK. Authors could work around most
>> cases of b) by doing putImageData to another canvas and compositing it into
>> the destination with 'over'.
>>
>
> Even with these constraints, I don't think we can guarantee that it's safe
> to use LCD AA text. Once you've drawn with LCD AA text, even if it's safe
> at the time of drawing, there's no guarantee that it will be safe later.
>  For instance, if you then drawImage() that canvas rotated into another
> canvas, or even just full-page-zoom it, you'll see colour fringing. Or
> apply CSS 2D or 3D transforms. There are also existing apps which use
> canvas for 2D text glyphs, and then transform and place them rotated in
> WebGL. Those will show colour fringing. Even within canvas, there may be a
> way to break it if the LCD AA text is drawn first and a dest-alpha
> compositing mode is used overtop (I haven't verified this though).
>
> So I'm starting to think that LCD AA text really has to be opt-in, to
> avoid breaking existing content. By opting it, you're agreeing that these
> artifacts are acceptable for your app. For example, you know that even if
> you're going to do a canvas-to-canvas draw, you're always going to draw at
> 1:1 scale and no rotation.
>

When you talk about LCD AA, do you talk about this?
http://en.wikipedia.org/wiki/Subpixel_rendering
If so, I don't think it would ever be safe to draw in such a way with
canvas as you can't expect an author to align canvas pixels with LCD pixels.

I assumed that we were just talking about regular pixel AA like we (=adobe)
do in our graphics products for line art.


>
>

>> How bad would that be? Would it help if we added an attribute to the
>> canvas to let authors detect whether the subpixel AA flag is set?
>>
>>
>> Rob
>> --
>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>
>
>


From cabanier at gmail.com  Fri Feb 15 08:08:16 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Sat, 16 Feb 2013 03:08:16 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDCQyb-_ioWRWoxBiQwAL7N2K5rPukbjWt7g-XjFfC509A@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAGN7qDCQyb-_ioWRWoxBiQwAL7N2K5rPukbjWt7g-XjFfC509A@mail.gmail.com>
Message-ID: <CAGN7qDAUNVsuA6_8tW56EqtijTTwjxc5uRjYCM4bw+FvVDbeQA@mail.gmail.com>

As an other alternative, we could also introduce a 'matteColor' attribute.
It's default would be 'transparent'.

If it's set to a css color, the canvas will be matted to that color. In
addition if you use putImageData or a compositing operator that changes
alpha, you always matte with that color afterwards (if needed).

This is actually pretty close to the 'opaque' keyword except
- it's on the canvas context
- you can specify a color
- it doesn't force reallocation of the canvas

On Fri, Feb 15, 2013 at 2:44 PM, Rik Cabanier <cabanier at gmail.com> wrote:

>
>
> On Fri, Feb 15, 2013 at 2:21 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Thu, Feb 14, 2013 at 11:59 PM, Stephen White <senorblanco at chromium.org
>> > wrote:
>>
>>> I think this is difficult to do in the general case, such as
>>> putImageData() or drawImage() or patterns, since you would need to examine
>>> all the pixels of the source image to determine if they contain non-1
>>> alpha.  This would be cost-prohibitive.
>>
>>
>>> If it's just for the purposes of optimization, you could be conservative
>>> and simply clear the flag when there's the potential for (but not certainty
>>> of) non-1 alpha.  But if you're also using that flag to allow subpixel AA,
>>> the behaviour becomes quite unpredictable for the web developer and hard to
>>> spec crisply.
>>>
>>
>> What if we just said
>> a) non-over operators clear the subpixel AA flag
>> b) putImageData clears the subpixel AA flag
>> Both of these are infrequently used AFAIK. Authors could work around most
>> cases of b) by doing putImageData to another canvas and compositing it into
>> the destination with 'over'.
>>
>
> Yes, that's pretty much my proposal. Except putImageData could detect it
> but that might be too hard for authors to figure out.
>
>
>>
>> How bad would that be? Would it help if we added an attribute to the
>> canvas to let authors detect whether the subpixel AA flag is set?
>
>
> I think that would be very helpful.
>
> So, if you clear (or matte) the canvas, the flag becomes true but if you
> do an operator that removes alpha, it will become false.
>
>
>>
>>
>> Rob
>> --
>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>
>
>


From ian at hixie.ch  Fri Feb 15 11:13:33 2013
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 15 Feb 2013 19:13:33 +0000 (UTC)
Subject: [whatwg] Sandboxed IFrames and downloads.
In-Reply-To: <CAKXHy=exj5SjiUiwFxdypd0HQrSPpHnaPFA5rQg0MWH1gU-GPg@mail.gmail.com>
References: <CAKXHy=eHTuTehhaAsFdumu-Rr1sgJZfRMGKOfnYUKcEV+T3gSw@mail.gmail.com>
	<CAKXHy=exj5SjiUiwFxdypd0HQrSPpHnaPFA5rQg0MWH1gU-GPg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1302151912050.3956@ps20323.dreamhostps.com>

On Fri, 15 Feb 2013, Mike West wrote:
>
> Ping. Is this a terrible idea? :)

Sorry for the delay in answering e-mails. Since last quarter I mostly 
responded to e-mails while neglecting the bug stream, this quarter I'm 
mostly focusing on the bugs and neglecting the e-mails.

All e-mails with substantive feedback (such as yours) sent to this list 
will eventually get a response.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From robert at ocallahan.org  Fri Feb 15 11:37:27 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Sat, 16 Feb 2013 08:37:27 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
Message-ID: <CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>

On Sat, Feb 16, 2013 at 4:35 AM, Stephen White <senorblanco at chromium.org>wrote:

> Even with these constraints, I don't think we can guarantee that it's safe
> to use LCD AA text. Once you've drawn with LCD AA text, even if it's safe
> at the time of drawing, there's no guarantee that it will be safe later.
>  For instance, if you then drawImage() that canvas rotated into another
> canvas, or even just full-page-zoom it, you'll see colour fringing. Or
> apply CSS 2D or 3D transforms. There are also existing apps which use
> canvas for 2D text glyphs, and then transform and place them rotated in
> WebGL. Those will show colour fringing.


This came up on the list earlier.

Even within canvas, there may be a way to break it if the LCD AA text is
> drawn first and a dest-alpha compositing mode is used overtop (I haven't
> verified this though).


I don't think that's a problem. All destination alpha values will be 1 even
after the subpixel AA test is painted, and you'll treat it as normal.

So I'm starting to think that LCD AA text really has to be opt-in, to avoid
> breaking existing content. By opting it, you're agreeing that these
> artifacts are acceptable for your app. For example, you know that even if
> you're going to do a canvas-to-canvas draw, you're always going to draw at
> 1:1 scale and no rotation.
>

It's difficult to know that on a mobile browser or any other browser where
you have some kind of fast zoom UI.

The suggestion on the list earlier was to keep two versions of the canvas
buffer: one with grayscale AA, another with subpixel AA, and composite with
the subpixel AA buffer when we can do that safely, otherwise use the
grayscale AA version. In many implementations there would be a performance
hit for this, so it would make sense to have authors opt-in to that
performance hit.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From robert at ocallahan.org  Fri Feb 15 12:10:14 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Sat, 16 Feb 2013 09:10:14 +1300
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
Message-ID: <CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>

On Sat, Feb 16, 2013 at 3:46 AM, Glenn Maynard <glenn at zewt.org> wrote:

> a) This isn't the case.  The tricky bit was defining precisely when
> autorevocation happens; this has been resolved (the "global script clean-up
> jobs list").  There's a remaining piece (
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765), but while it'll
> take some thought to do that in a clean way (so it can be applied to
> different APIs concisely), there's nothing magic there.
>

Serves me right for checking the latest published version instead of the
real spec... Sorry.

It may be that "there's nothing magic there", but in comment #17 Ian seems
less than enthusiastic ("this is nuts, IMHO").

Even if you get past that, you still have the problem that revoked URLs are
useless. It's impossible to do something equivalent to video2.src =
video1.src (which works today). Also, getting access to the underlying
source object is a valuable feature, especially for MediaStream and
MediaSource objects which have interesting APIs on them.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From senorblanco at chromium.org  Fri Feb 15 14:09:16 2013
From: senorblanco at chromium.org (Stephen White)
Date: Fri, 15 Feb 2013 17:09:16 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
Message-ID: <CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>

On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Sat, Feb 16, 2013 at 4:35 AM, Stephen White <senorblanco at chromium.org>wrote:
>
>> Even with these constraints, I don't think we can guarantee that it's
>> safe to use LCD AA text. Once you've drawn with LCD AA text, even if it's
>> safe at the time of drawing, there's no guarantee that it will be safe
>> later.  For instance, if you then drawImage() that canvas rotated into
>> another canvas, or even just full-page-zoom it, you'll see colour fringing.
>> Or apply CSS 2D or 3D transforms. There are also existing apps which use
>> canvas for 2D text glyphs, and then transform and place them rotated in
>> WebGL. Those will show colour fringing.
>
>
> This came up on the list earlier.
>
> Even within canvas, there may be a way to break it if the LCD AA text is
>> drawn first and a dest-alpha compositing mode is used overtop (I haven't
>> verified this though).
>
>
> I don't think that's a problem. All destination alpha values will be 1
> even after the subpixel AA test is painted, and you'll treat it as normal.
>

I was thinking something like this:

- draw subpixel AA text over an opaque background
- draw a partially-transparent rect with destination-atop mode over the
subpixel AA text

Now some of the subpixel AA text is still there, but the destination alpha
is non-1, so things will go bad when you composite into the page.  (At
least I think it will.. Porter-Duff makes my head spin sometimes.)


>  So I'm starting to think that LCD AA text really has to be opt-in, to
>> avoid breaking existing content. By opting it, you're agreeing that these
>> artifacts are acceptable for your app. For example, you know that even if
>> you're going to do a canvas-to-canvas draw, you're always going to draw at
>> 1:1 scale and no rotation.
>>
>
> It's difficult to know that on a mobile browser or any other browser where
> you have some kind of fast zoom UI.
>
> The suggestion on the list earlier was to keep two versions of the canvas
> buffer: one with grayscale AA, another with subpixel AA, and composite with
> the subpixel AA buffer when we can do that safely, otherwise use the
> grayscale AA version. In many implementations there would be a performance
> hit for this, so it would make sense to have authors opt-in to that
> performance hit.
>

It would also be a needless performance hit if the developer knew that they
always wanted subpixel AA, and that their app would never fringe.


> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>

So let me take a stab at a brief summary of the proposals so far, and the
pros and cons of each (correct me if I missed anything):

moz-opaque
pro:  fairly easy to implement
pro:  no performance hit over regular rendering
pro:  many opportunities for optimization
pro:  catches all in-canvas cases of color fringing
con:  does not handle any out-of-canvas color fringing
con:  opt-in

automatic opacity detection
pro:  catches most (all?) cases of in-canvas color fringing
pro:  some opportunties for optimization (must be conservative in some
cases)
con:  does not catch color fringing on CSS transforms, canvas -> WebGL, etc

context attribute (something like:  context.textAntialising = { 'none',
'grayscale', 'subpixel' })
pro:  very easy to implement
pro:  no performance hit
con:  does not catch any cases of color fringing; completely up to web
developer
con:  opt-in

deferred canvas rendering (collect commands into a buffer, flush buffer
only when compositing canvas to page, and decide on subpixel AA at that
point)
pro:  catches all cases of color fringing
con:  in some cases, requires an infinite buffer (e.g., a canvas that never
clears, and only accumulates drawing frame-to-frame means you must
accumulate commands indefinitely)
con:  difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
con:  may introduce performance hit due to re-rendering with and without
subpixel AA (in cases where you would rather have just gone without)

two buffers (one grayscale, one LCD AA)
pro:  handles all cases of color fringing
pro:  moderately easy to implement
con:  RAM (or VRAM) usage is doubled
con:  possibly-unnecessary performance hit
con:  must be opt-in


From robert at ocallahan.org  Sat Feb 16 01:09:22 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Sat, 16 Feb 2013 22:09:22 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
Message-ID: <CAOp6jLaF2gxn2D4XGKSj7CqBWt9rje_nNKzzF9aQCzg89AhHPQ@mail.gmail.com>

On Sat, Feb 16, 2013 at 11:09 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Sat, Feb 16, 2013 at 4:35 AM, Stephen White <senorblanco at chromium.org>wrote:
>>
>>> Even within canvas, there may be a way to break it if the LCD AA text is
>>> drawn first and a dest-alpha compositing mode is used overtop (I haven't
>>> verified this though).
>>
>>
>> I don't think that's a problem. All destination alpha values will be 1
>> even after the subpixel AA test is painted, and you'll treat it as normal.
>>
>
> I was thinking something like this:
>
> - draw subpixel AA text over an opaque background
> - draw a partially-transparent rect with destination-atop mode over the
> subpixel AA text
>
>  Now some of the subpixel AA text is still there, but the destination
> alpha is non-1, so things will go bad when you composite into the page.
>  (At least I think it will.. Porter-Duff makes my head spin sometimes.)
>

I don't see the problem. After the first step, you have an RGBA buffer that
represents exactly the result of the rendering. The second step treats it
exactly like any other RGBA buffer. Am I being dense?


> The suggestion on the list earlier was to keep two versions of the canvas
>> buffer: one with grayscale AA, another with subpixel AA, and composite with
>> the subpixel AA buffer when we can do that safely, otherwise use the
>> grayscale AA version. In many implementations there would be a performance
>> hit for this, so it would make sense to have authors opt-in to that
>> performance hit.
>>
>
> It would also be a needless performance hit if the developer knew that
> they always wanted subpixel AA, and that their app would never fringe.
>

I don't think the developer can ever know that. They'd have to assume the
browser/platform does not have a quick-zoom feature, which is an assumption
developers shouldn't be making. Although I guess we could just declare that
that case isn't important enough to matter.

So let me take a stab at a brief summary of the proposals so far, and the
> pros and cons of each (correct me if I missed anything):
>
> moz-opaque
> pro:  fairly easy to implement
> pro:  no performance hit over regular rendering
> pro:  many opportunities for optimization
> pro:  catches all in-canvas cases of color fringing
> con:  does not handle any out-of-canvas color fringing
> con:  opt-in
>

Additional con: requires changes to canvas compositing spec and possibly
implementations.


> automatic opacity detection
> pro:  catches most (all?) cases of in-canvas color fringing
> pro:  some opportunties for optimization (must be conservative in some
> cases)
> con:  does not catch color fringing on CSS transforms, canvas -> WebGL, etc
>
> context attribute (something like:  context.textAntialising = { 'none',
> 'grayscale', 'subpixel' })
> pro:  very easy to implement
> pro:  no performance hit
> con:  does not catch any cases of color fringing; completely up to web
> developer
> con:  opt-in
>

Additional con: requires specification and implementation of what happens
when subpixel AA is drawn over transparent background.

deferred canvas rendering (collect commands into a buffer, flush buffer
> only when compositing canvas to page, and decide on subpixel AA at that
> point)
> pro:  catches all cases of color fringing
> con:  in some cases, requires an infinite buffer (e.g., a canvas that
> never clears, and only accumulates drawing frame-to-frame means you must
> accumulate commands indefinitely)
>

Not really true, you can just give up on the complex cases and draw
grayscale whenever you feel like it.


> con:  difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
> con:  may introduce performance hit due to re-rendering with and without
> subpixel AA (in cases where you would rather have just gone without)
>
> two buffers (one grayscale, one LCD AA)
> pro:  handles all cases of color fringing
> pro:  moderately easy to implement
> con:  RAM (or VRAM) usage is doubled
> con:  possibly-unnecessary performance hit
> con:  must be opt-in
>

Sounds right with the above modifications.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From robert at ocallahan.org  Sat Feb 16 01:12:02 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Sat, 16 Feb 2013 22:12:02 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
Message-ID: <CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>

On Sat, Feb 16, 2013 at 11:09 AM, Stephen White <senorblanco at chromium.org>wrote:

> deferred canvas rendering (collect commands into a buffer, flush buffer
> only when compositing canvas to page, and decide on subpixel AA at that
> point)
> pro:  catches all cases of color fringing
> con:  in some cases, requires an infinite buffer (e.g., a canvas that
> never clears, and only accumulates drawing frame-to-frame means you must
> accumulate commands indefinitely)
> con:  difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
> con:  may introduce performance hit due to re-rendering with and without
> subpixel AA (in cases where you would rather have just gone without)
>
> two buffers (one grayscale, one LCD AA)
> pro:  handles all cases of color fringing
> pro:  moderately easy to implement
> con:  RAM (or VRAM) usage is doubled
> con:  possibly-unnecessary performance hit
> con:  must be opt-in
>

Both of these schemes can actually be optimized some more: As long as no
text is drawn to a canvas, you can freely rasterize (in the first case) or
use just one buffer (in the second case). In fact, this is true as long as
no text is drawn to a canvas over non-opaque pixels. So a lot of canvas
usage could be handled with little or no performance hit.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From glenn at zewt.org  Sat Feb 16 11:43:08 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Sat, 16 Feb 2013 13:43:08 -0600
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
	<CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>
Message-ID: <CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>

On Fri, Feb 15, 2013 at 2:10 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Sat, Feb 16, 2013 at 3:46 AM, Glenn Maynard <glenn at zewt.org> wrote:
>
>> a) This isn't the case.  The tricky bit was defining precisely when
>> autorevocation happens; this has been resolved (the "global script clean-up
>> jobs list").  There's a remaining piece (
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765), but while it'll
>> take some thought to do that in a clean way (so it can be applied to
>> different APIs concisely), there's nothing magic there.
>>
>
> Serves me right for checking the latest published version instead of the
> real spec... Sorry.
>
> It may be that "there's nothing magic there", but in comment #17 Ian seems
> less than enthusiastic ("this is nuts, IMHO").
>

He didn't explain why it's nuts. (Putting aside the apparent
misunderstandings in comment #14, eg. "prose everywhere that might
eventually use part of a string as a URL", since I replied to that and he
didn't respond to my reply.)

Since we have a real URL parser now, I think we have a reasonable way to do
this: capture the blob in the parser, returning it as part of the parsed
URL.  Then, it becomes straightforward: if an APIs parses URLs
synchronously these URLs will work, and if they parse asynchronously then
they won't.

The XHR spec would just work, since it already parses URLs synchronously
from open().  HTMLImageElement.src and srcset would need to parse the URL
synchronously, rather than waiting for the "update the image data" to
happen.

If there are APIs that can't guarantee if they'll parse synchronously or
asynchronously, then it should tell the parser to never capture blobs, to
guarantee that they never work rather than being nondeterministic.

Even if you get past that, you still have the problem that revoked URLs are
> useless. It's impossible to do something equivalent to video2.src =
> video1.src (which works today).
>

True, though cloneNode() should definitely work.  On the other hand,
.innerHTML works with blob URLs if the URL is still in scope, but would
never work here (not something I use often, but I guess some people still
do).

 Also, getting access to the underlying source object is a valuable
> feature, especially for MediaStream and MediaSource objects which have
> interesting APIs on them.
>

I don't know anything about those, but you can always stash a reference to
an object on the img, even if img doesn't care about it.  "img.src =
URL.createBlobURL(blob); img.xActualBlob = blob;"  It's not as nice as
having them tied together, but it's not terrible.

-- 
Glenn Maynard


From nils at dieweltistgarnichtso.net  Sun Feb 17 05:04:15 2013
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 17 Feb 2013 14:04:15 +0100
Subject: [whatwg] IRC and WWW integration proposal
In-Reply-To: <20130201154150.14251e2a80fe4f69051f4ad8@gmail.com>
References: <20130201142600.dea98ee7b58e2637550be2c4@gmail.com>
	<20130201052458.269aac46@desudesudesu>
	<20130201150126.16a706397a491368142a8815@gmail.com>
	<20130201055511.332ca0b8@desudesudesu>
	<20130201154150.14251e2a80fe4f69051f4ad8@gmail.com>
Message-ID: <20130217140415.22fd996b@desudesudesu>

Gryllida <gryllida at gmail.com> schrieb am Fri, 1 Feb 2013 15:41:50 +1030:

> [?]
>
> It is rather common to have a channel for a website, not just one
> page. There are some exceptions of sites which have subsites with a
> channel for each. A {IRC, XMPP} channel is "an official chat medium
> aiming to serve as an official {support, development, contact}
> means". For example, https://developer.mozilla.org/en/Themes
> irc://irc.mozilla.org/themedev - discussion of theme development for
> Mozilla platform http://www.ubuntu.com/* irc://irc.ubuntu.com/ -
> official support channel for the distro the w3c network for
> individual sections of website - channels for development
> collaboration and meetings &c

Those relations are not the same. The Mozilla example shows a
*discussion about* the collection described by by the referring
document, the Ubuntu example shows *support for* the software available
at the referring page. The W3C example is probably similar to the
Mozilla example, only that it would refer to discussions about
documents.

> I think a protocol attribute might be redundant as it is a part of
> the URL.

Indeed.

> It may be worth noting that every part of the note I originally sent
> is possible to look up and you can try finding proper way to phrase
> things (I have no experience in writing documentation of this sort).

I do not understand.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>


From nils at dieweltistgarnichtso.net  Sun Feb 17 05:19:32 2013
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 17 Feb 2013 14:19:32 +0100
Subject: [whatwg] use of article to markup comments
In-Reply-To: <op.wris4smuh8on37@bruce-pc>
References: <CA+ri+V=SnGtwaFT=D9MnZoFkFFb_iX0nXnOGyOH298uDAYCMhQ@mail.gmail.com>
	<op.wris4smuh8on37@bruce-pc>
Message-ID: <20130217141932.7ca5ed8a@desudesudesu>

"Bruce Lawson" <brucel at opera.com> schrieb am Sat, 26 Jan 2013 13:30:18
-0000:

> In short, why should the spec suggest any specific method of marking
> up comments?

As someone who is interested in semantics and tired of scraping
content and applying scrappy heuristics: If it is clear that an
<article> within an <article> represents a comments one can easily:
  * programmatically find article comments in HTML
  * write interoperable stylesheets for comments, using the selector
    ?article > article?
  * use HTML fragments in a document store for content management (I
    wrote a blog software with a git backend yesterday and plan to add
    this feature)

Without having one interoperable way all that becomes a lot harder.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>


From nils at dieweltistgarnichtso.net  Sun Feb 17 05:23:48 2013
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 17 Feb 2013 14:23:48 +0100
Subject: [whatwg] use of article to markup comments
In-Reply-To: <5105726A.2000905@custom-anything.com>
References: <CA+ri+V=SnGtwaFT=D9MnZoFkFFb_iX0nXnOGyOH298uDAYCMhQ@mail.gmail.com>
	<op.wris4smuh8on37@bruce-pc> <5105726A.2000905@custom-anything.com>
Message-ID: <20130217142348.300a169a@desudesudesu>

Adrian Testa-Avila <whatwg at custom-anything.com> schrieb am Sun, 27 Jan
2013 10:31:06 -0800:

> So, maybe a better question is why should the spec suggest only one 
> specific method?

Answer: As someone consuming HTML and XML content, I find it extremely
unhelpful if equivalent semantics are expressed in mand different ways.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>


From nils at dieweltistgarnichtso.net  Sun Feb 17 05:48:56 2013
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 17 Feb 2013 14:48:56 +0100
Subject: [whatwg] metadata attribute for media
In-Reply-To: <50C7DC9A.1070000@mozilla.com>
References: <505BA783.2030202@mozilla.com> <op.wlac76p9sr6mfa@kirk>
	<50B406DA.70708@mozilla.com> <50B52E51.1000707@mozilla.com>
	<Pine.LNX.4.64.1212120051040.9975@ps20323.dreamhostps.com>
	<50C7DC9A.1070000@mozilla.com>
Message-ID: <20130217144856.72a25d99@desudesudesu>

Ralph Giles <giles at mozilla.com> schrieb am Tue, 11 Dec 2012 17:23:38
-0800:

> On 12-12-11 4:58 PM, Ian Hickson wrote:
> 
> [?]
>
> > I don't think we should have an open-ended API without fixed names, 
> > because that is a recipe for an interoperability disaster.
> 
> I agree it would have interoperability issues. My own implementation
> experience is that the easy thing to do is to mirror whatever
> representation your playback framework offers, which can result in
> per-platform differences as well as per-media-format (and per tagging
> application, etc.).

Just doing ?the easiest thing? when you are a content-emitter (e.g. a
software developer just mirroring what the platform provides)
does make it easier for the sender while making it harder for the
receiver ? it creates ?computational dark energy? that has to be
consumed somehow at the receiving side, as someone has to map all of
these platform-specific conventions onto common semantics.

I rather not have a world in which one needs even more JavaScript blobs
just to provide basic functionality cross-browser.

> That said, I'm not convinced this is an issue given the primary
> use-case, which is pretty much that web content wants to do more
> sophisticated things with the metadata than the user-agent's
> standardized parsing allows. If one cares to that extent, and is
> already handling format differences, dealing with vendor variation on
> top isn't that much more effort.

I disagree, strongly.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>


From glenn at zewt.org  Sun Feb 17 09:35:46 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Sun, 17 Feb 2013 11:35:46 -0600
Subject: [whatwg] scoped style sheets and @-rules
In-Reply-To: <20130121143923.GA6959@crum.dbaron.org>
References: <20130121143923.GA6959@crum.dbaron.org>
Message-ID: <CABirCh_+USnDWAqTOXXWQNeKM+qwa2TX04Nym=833Zkqcu4ncg@mail.gmail.com>

On Mon, Jan 21, 2013 at 8:39 AM, L. David Baron <dbaron at dbaron.org> wrote:

> But I think it's a large amount of extra implementation complexity
> to honor @-rules whose purpose is to build global dictionaries (in
> particular, @keyframes and @font-face), and I suspect the end result
> of honoring them would yield technology that's more confusing for
> authors.  Anything that can be done by changing the meaning of an
> @keyframes or @font-face rule within a subtree could also be done by
> declaring a different animation rule or font-family within that
> subtree.  I suspect the extra clarity from the latter makes it a
> better authoring practice anyway, so I don't think implementations
> should be required to add support for a feature that it's better to
> not use.
>

You could make the same argument against most of @scoped: you don't need to
define a scoped style for a class, just use a different class name.

It seems more likely that you'd want to use this for font-faces or
keyframes so that you can be sure the name won't collide.  For example, a
templating system might output

<div>
    <style scoped>
    @font-face { font-family: "font"; src: url("font.ttf"); }
    </style>
    <span style="font-family: font;">content</span>
</div>

where the font URL is dynamically generated and the span is entered by the
user, who's been told that the font-family "font" will be defined to
something.  The template doesn't need to worry about colliding with a
font-family by that name elsewhere (including other instances of the same
template or elsewhere in the document).

I don't know about implementation complexity (though I don't know why
creating a stack of font-face dictionaries would be any more complex than
creating a stack of style rules), but I don't think this is any more
complex for authors than the rest of @scoped.

-- 
Glenn Maynard


From jonathan at garbee.me  Sun Feb 17 13:10:21 2013
From: jonathan at garbee.me (Jonathan Garbee)
Date: Sun, 17 Feb 2013 16:10:21 -0500
Subject: [whatwg] IRC and WWW integration proposal
In-Reply-To: <20130201142600.dea98ee7b58e2637550be2c4@gmail.com>
References: <20130201142600.dea98ee7b58e2637550be2c4@gmail.com>
Message-ID: <CANQy2y2jTxgQtsEdTuwBLWpd5deACFV2=nJp81m3RVvxV+BypA@mail.gmail.com>

Usecase 1: This can already be covered by having the bot/engine look for an
irc protocol link on the page.

Usecase 2 part one: Operating systems already do this. They see an irc://
protocol and ask what to open it with or use their already assigned option.
No need for a browser to take this over.

Usecase 2 part two: Most browsers offer extension platforms, someone can
easily create one to look for irc:// links and display something based on
that.

I personally am not seeing any major benefit by having the proposed
additions added into spec(s). Just more work for developers both on
browsers and websites if they chose to support this.

-Garbee



>   Usecase 1: I search for python and see a link to their website in search
> results, and the search engine looks up both title and IRC info - so I see
> webpage title, and a link to its irc network or channel.
>   Usecase 2: Browsers implement some interface to display IRC channel link
> or window when user visits a page. Advantages:
>   - The websites will benefit from this and will not have to manually
> embed qwebirc or Mibbit instances into their webpages anymore[1], leaving
> the IRC client preference to the user (choose from locally installed
> clients, or a client provided by the website).
>   - User would not have to skim a page of text to locate and click an
> irc:// link manually, as such links would be a part of browser interface
> (an IRC icon like RSS feed icon?).
>
>


From robert at ocallahan.org  Sun Feb 17 13:17:49 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 18 Feb 2013 10:17:49 +1300
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CA+c2ei_TGhJmmOgQvUB1nr6Py_+1j4Oe0DKMR7anDQyrAXwV0w@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CADnb78hnVHE-fV=LTw0WCjbNgWbbo1+qZ9BsMeNM-xqg4f+cjw@mail.gmail.com>
	<CAOp6jLYEKjS3Cg8pPfrzSSPbKCgD0uRO9uu0M-6PLZ7FObqVsQ@mail.gmail.com>
	<CA+c2ei-bq6qbV4HMcYWWN0iWTP68XFbUQpZD39zWuU2qo4y6ow@mail.gmail.com>
	<CAOp6jLa+ZJC=2GxNdxkhX0VOPmNGdg921-do=kLHYqFAHJFqnA@mail.gmail.com>
	<CA+c2ei_TGhJmmOgQvUB1nr6Py_+1j4Oe0DKMR7anDQyrAXwV0w@mail.gmail.com>
Message-ID: <CAOp6jLbXdnwyrnD9-9kdHu3=xwnj6RZ1ZOhUtCEea4eDkHHDVg@mail.gmail.com>

On Sat, Feb 16, 2013 at 1:37 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Fri, Feb 15, 2013 at 2:43 AM, Robert O'Callahan <robert at ocallahan.org>
> wrote:
> > On Fri, Feb 15, 2013 at 10:50 PM, Jonas Sicking <jonas at sicking.cc>
> wrote:
> >>
> >> Also, for what it's worth, I'm holding out hope that we can change
> >> createObjectURL to be autorevoking by default. That's what the latest
> >> drafts are saying and no implementation has objected, despite repeated
> >> pokings.
> >
> > Has any implementation actually taken the plunge?
>
> It's a fairly recent change to the spec, so no. I think we should give
> it a try in Firefox.
>

Ugh, can't we take turns with other browsers or draw straws or something?
Or study existing code using createObjectURL to get some data first?

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From robert at ocallahan.org  Sun Feb 17 13:25:51 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 18 Feb 2013 10:25:51 +1300
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
	<CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>
	<CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>
Message-ID: <CAOp6jLZhBfchM1zzrfYWvifoYicVQ1kOYdE4EEA+zW_jrQ-Jzg@mail.gmail.com>

On Sun, Feb 17, 2013 at 8:43 AM, Glenn Maynard <glenn at zewt.org> wrote:

> On Fri, Feb 15, 2013 at 2:10 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
> Even if you get past that, you still have the problem that revoked URLs
>> are useless. It's impossible to do something equivalent to video2.src =
>> video1.src (which works today).
>>
>
> True, though cloneNode() should definitely work.  On the other hand,
> .innerHTML works with blob URLs if the URL is still in scope, but would
> never work here (not something I use often, but I guess some people still
> do).
>

cloneNode() won't work for autorevoked URLs, because it is defined to only
clone attributes and children, not internal state (with a few exceptions
for Web compatibility). (Don't tell me that it shouldn't work that way; I
argued that long ago and lost :-).) innerHTML-based cloning would work in
the same cases cloneNode() would: i.e. not at all for autorevoked URLs or
srcObject.


>  Also, getting access to the underlying source object is a valuable
>> feature, especially for MediaStream and MediaSource objects which have
>> interesting APIs on them.
>>
>
> I don't know anything about those, but you can always stash a reference to
> an object on the img, even if img doesn't care about it.  "img.src =
> URL.createBlobURL(blob); img.xActualBlob = blob;"  It's not as nice as
> having them tied together, but it's not terrible.
>

Yes, you can work around not having an API for this, if you control both
the setting and the getting. It's still a workaround.

I think the stakes are not that high here. Lack of srcObject can be worked
around in most cases. On the other hand adding srcObject is not a big
burden --- I don't think it needs to be added to every resource-loading
element. It's useful for media elements, maybe <img>, and dubiously
<iframe> (all of which already have multiple ways to specify the resource
to load).

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From jonathan at garbee.me  Sun Feb 17 14:56:29 2013
From: jonathan at garbee.me (Jonathan Garbee)
Date: Sun, 17 Feb 2013 17:56:29 -0500
Subject: [whatwg] IRC and WWW integration proposal
In-Reply-To: <CANQy2y2jTxgQtsEdTuwBLWpd5deACFV2=nJp81m3RVvxV+BypA@mail.gmail.com>
References: <20130201142600.dea98ee7b58e2637550be2c4@gmail.com>
	<CANQy2y2jTxgQtsEdTuwBLWpd5deACFV2=nJp81m3RVvxV+BypA@mail.gmail.com>
Message-ID: <CANQy2y0cK4DWv43qhk_=Br6=HuBHy8MpUJQzN1XU=sNLeueJsw@mail.gmail.com>

I'll actually follow up my last post with this.

Is there any scenario where something can be done with these changes, or
any one of them, that today isn't possible with the current specifications?
I simply don't see one myself. If you could give a scenario, then could you
possibly make an example page and write a polyfill that would show the
use-case? It may help us better understand any other use-case that is
currently not possible and show us what functionality to look at in order
to create something for the (a?) spec that would work.


On Sun, Feb 17, 2013 at 4:10 PM, Jonathan Garbee <jonathan at garbee.me> wrote:

> Usecase 1: This can already be covered by having the bot/engine look for
> an irc protocol link on the page.
>
> Usecase 2 part one: Operating systems already do this. They see an irc://
> protocol and ask what to open it with or use their already assigned option.
> No need for a browser to take this over.
>
> Usecase 2 part two: Most browsers offer extension platforms, someone can
> easily create one to look for irc:// links and display something based on
> that.
>
> I personally am not seeing any major benefit by having the proposed
> additions added into spec(s). Just more work for developers both on
> browsers and websites if they chose to support this.
>
> -Garbee
>
>
>
>>   Usecase 1: I search for python and see a link to their website in
>> search results, and the search engine looks up both title and IRC info - so
>> I see webpage title, and a link to its irc network or channel.
>>   Usecase 2: Browsers implement some interface to display IRC channel
>> link or window when user visits a page. Advantages:
>>   - The websites will benefit from this and will not have to manually
>> embed qwebirc or Mibbit instances into their webpages anymore[1], leaving
>> the IRC client preference to the user (choose from locally installed
>> clients, or a client provided by the website).
>>   - User would not have to skim a page of text to locate and click an
>> irc:// link manually, as such links would be a part of browser interface
>> (an IRC icon like RSS feed icon?).
>>
>>
>


From silviapfeiffer1 at gmail.com  Sun Feb 17 15:39:58 2013
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Mon, 18 Feb 2013 10:39:58 +1100
Subject: [whatwg] use of article to markup comments
In-Reply-To: <20130217141932.7ca5ed8a@desudesudesu>
References: <CA+ri+V=SnGtwaFT=D9MnZoFkFFb_iX0nXnOGyOH298uDAYCMhQ@mail.gmail.com>
	<op.wris4smuh8on37@bruce-pc> <20130217141932.7ca5ed8a@desudesudesu>
Message-ID: <CAHp8n2=qaVdfYgy_KH3yiq9ze8h7LBEJ7e9CRqevHeG5i-unEw@mail.gmail.com>

On Mon, Feb 18, 2013 at 12:19 AM, Nils Dagsson Moskopp <
nils at dieweltistgarnichtso.net> wrote:

> "Bruce Lawson" <brucel at opera.com> schrieb am Sat, 26 Jan 2013 13:30:18
> -0000:
>
> > In short, why should the spec suggest any specific method of marking
> > up comments?
>
> As someone who is interested in semantics and tired of scraping
> content and applying scrappy heuristics: If it is clear that an
> <article> within an <article> represents a comments one can easily:
>


<article> in <article> could be a comment. Or it could be something else
entirely. Your heuristic may work in many cases, but certainly not in all.
If we really wanted to be sure where to find the semantic concept of a
comment, we should introduce a meaningful element for it such as <comment>.

Silvia.


From nils at dieweltistgarnichtso.net  Sun Feb 17 22:36:33 2013
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Mon, 18 Feb 2013 07:36:33 +0100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <gemini.mf0z4700mwz2o09e7.stewart.brodie@antplc.com>
References: <CA+ri+V=W6P2EPvzKQB7NQD7YXgjL5RQgKfbWJoGuit7q8L6m8w@mail.gmail.com>
	<CA+ri+V=TrN88Cn-fS4KrbV4j2+1_3_vo-+-7s86dgxi9TF6izw@mail.gmail.com>
	<gemini.mf0z4700mwz2o09e7.stewart.brodie@antplc.com>
Message-ID: <20130218073633.71166b46@desudesudesu>

Stewart Brodie <stewart.brodie at antplc.com> schrieb am Fri, 14 Dec 2012
14:33:43 +0000:

> Steve Faulkner <faulkner.steve at gmail.com> wrote:
> 
> > Stewart wrote:
> > 
> > It doesn't necessarily.  I've come across pages that expect the
> > head to be displayed too.  e.g. tests at
> > http://meyerweb.com/eric/css/tests/css3/like
> > http://meyerweb.com/eric/css/tests/css3/show.php?p=caption-side
> 
> > Is this a common mark up pattern?
> 
> I've not gone looking for any other real-world examples - that's the
> only one I've seen.  However, I can't think of any reason why it
> shouldn't work, as it's just a block box like the body element
> (usually) is.

I have some rules in my user stylesheet for this ? among these one that
displays the hyperlink with a small orange feed icon for elements
matching ?link[rel=alternate][title][type='application/rss+xml']?. I use
conkeror (a web browser modeled after Emacs ? scripting buffers ful of
HTML using JavaScript), the configuration can be found here:
<https://raw.github.com/erlehmann/dotfiles/27cf8d18faad4d8deeb47ebaadcf91ce26357aa6/.conkerorrc>

When I tried to actually use this for a web page I found that while
Gecko (from conkeror) generates Hyperlinks for <link> elements, WebKit
(at least that from Chromium Version 22.0.1229.94) does not. Therefore,
I decided against using this styling pattern for my blog sofware.

I suggest people test for themselves, as I suspect I may have done
something wrong with my user stylesheets in Chromium ? it seems
counter-intuitive that a <link> Element does not create a hyperlink:
<data:text/html;charset=utf-8;base64,PCFET0NUWVBFIEhUTUw%2BPHRpdGxlPkxpbmsgRWxlbWVudCBTdHlsaW5nIFRlc3Q8L3RpdGxlPjxzdHlsZT5oZWFkLGxpbmt7ZGlzcGxheTpibG9ja31saW5rW3RpdGxlXVt0eXBlPSdhcHBsaWNhdGlvbi9yc3MreG1sJ106OmJlZm9yZXtjb250ZW50OidMaW5rOiAnIGF0dHIodGl0bGUpfTwvc3R5bGU%2BPGxpbmsgcmVsPSJhbHRlcm5hdGUiIHRpdGxlPSJGZWVkIiB0eXBlPSJhcHBsaWNhdGlvbi9yc3MreG1sIiBocmVmPSJodHRwOi8vZXhhbXBsZS5vcmcvZmVlZCI%2BYm9keQ0K>

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>


From annevk at annevk.nl  Mon Feb 18 01:37:33 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Mon, 18 Feb 2013 09:37:33 +0000
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
	<CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>
	<CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>
Message-ID: <CADnb78j1HQ_fE7Q63sV_1Rg4cuMNXTxgbw_-QPLhWzXS==1TJw@mail.gmail.com>

On Sat, Feb 16, 2013 at 7:43 PM, Glenn Maynard <glenn at zewt.org> wrote:
> Since we have a real URL parser now, I think we have a reasonable way to do
> this: capture the blob in the parser, returning it as part of the parsed
> URL.

Although this might theoretically work, I suspect it'll take a while
before browsers get URL parsers that match the architecture of the
specification. (They all have somewhat different architectures at the
moment and trying to extend them in any meaningful manner at this
point seems like asking for trouble.)


-- 
http://annevankesteren.nl/


From annevk at annevk.nl  Mon Feb 18 01:39:42 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Mon, 18 Feb 2013 09:39:42 +0000
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CAOp6jLZhBfchM1zzrfYWvifoYicVQ1kOYdE4EEA+zW_jrQ-Jzg@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
	<CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>
	<CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>
	<CAOp6jLZhBfchM1zzrfYWvifoYicVQ1kOYdE4EEA+zW_jrQ-Jzg@mail.gmail.com>
Message-ID: <CADnb78hZC742zfNK5=sW8XnVRUTSvxcS6PDzBqxWoYXVcCNxMQ@mail.gmail.com>

On Sun, Feb 17, 2013 at 9:25 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> cloneNode() won't work for autorevoked URLs, because it is defined to only
> clone attributes and children, not internal state (with a few exceptions
> for Web compatibility). (Don't tell me that it shouldn't work that way; I
> argued that long ago and lost :-).)

We explicitly allow for it today.
http://dom.spec.whatwg.org/#concept-node-clone-ext

That was added of course for the compatibility reasons you mention
(mostly form controls) but I don't see why at this point in time we
should still avoid using it for other means.


-- 
http://annevankesteren.nl/


From robert at ocallahan.org  Mon Feb 18 01:59:43 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 18 Feb 2013 22:59:43 +1300
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CADnb78hZC742zfNK5=sW8XnVRUTSvxcS6PDzBqxWoYXVcCNxMQ@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
	<CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>
	<CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>
	<CAOp6jLZhBfchM1zzrfYWvifoYicVQ1kOYdE4EEA+zW_jrQ-Jzg@mail.gmail.com>
	<CADnb78hZC742zfNK5=sW8XnVRUTSvxcS6PDzBqxWoYXVcCNxMQ@mail.gmail.com>
Message-ID: <CAOp6jLYmSYQE-2HQ841Rh-0udhwFXhRPLH_nFuje4U2KwHOqUw@mail.gmail.com>

On Mon, Feb 18, 2013 at 10:39 PM, Anne van Kesteren <annevk at annevk.nl>wrote:

> On Sun, Feb 17, 2013 at 9:25 PM, Robert O'Callahan <robert at ocallahan.org>
> wrote:
> > cloneNode() won't work for autorevoked URLs, because it is defined to
> only
> > clone attributes and children, not internal state (with a few exceptions
> > for Web compatibility). (Don't tell me that it shouldn't work that way; I
> > argued that long ago and lost :-).)
>
> We explicitly allow for it today.
> http://dom.spec.whatwg.org/#concept-node-clone-ext
>
> That was added of course for the compatibility reasons you mention
> (mostly form controls) but I don't see why at this point in time we
> should still avoid using it for other means.
>

IIRC Ian argued against it last time. If he's changed his mind, I'd like to
hear him say so :-).

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From glenn at zewt.org  Mon Feb 18 09:46:13 2013
From: glenn at zewt.org (Glenn Maynard)
Date: Mon, 18 Feb 2013 11:46:13 -0600
Subject: [whatwg] Assigning media resources represented as DOM objects
 to a media element
In-Reply-To: <CAOp6jLZhBfchM1zzrfYWvifoYicVQ1kOYdE4EEA+zW_jrQ-Jzg@mail.gmail.com>
References: <CAOp6jLYUnKsBxg7Urf==1ZDSkj9QXG8x6or8iwSTzaG9B8-yQg@mail.gmail.com>
	<CABirCh-FcD1fP+=k4RUFAKa3CvvH582rvZLpe8gLM4sOepMAfA@mail.gmail.com>
	<CAOp6jLaJexsW0KWzgfO_U-M3r-K=+Su13c6+5EJyvEYVDha0Hw@mail.gmail.com>
	<CABirCh_5mOL3g-+kzD9YyM-_jRy4FrnJoWLGXyC4mbL-z9Cp6A@mail.gmail.com>
	<CAOp6jLZhBfchM1zzrfYWvifoYicVQ1kOYdE4EEA+zW_jrQ-Jzg@mail.gmail.com>
Message-ID: <CABirCh8W0KriqfH5-dD+ynUviVM3-ddv8hwrBMD4mOZvp0FawA@mail.gmail.com>

On Sun, Feb 17, 2013 at 3:17 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

>  Ugh, can't we take turns with other browsers or draw straws or something?
> Or study existing code using createObjectURL to get some data first?
>

I don't know if you have any way of testing this in bulk, but once you have
the auto-revoke infrastructure in place, it's probably straightforward to
instrument non-auto-revoking blob URLs to see where they're actually used
after their initial top-level script stack has returned (eg. where this
change would be breaking).

cloneNode() won't work for autorevoked URLs, because it is defined to only
> clone attributes and children, not internal state (with a few exceptions
> for Web compatibility). (Don't tell me that it shouldn't work that way; I
> argued that long ago and lost :-).)


It may be worth raising the argument again, since we have additional
information now (this feature), though it's not high up on my list.


On Mon, Feb 18, 2013 at 3:37 AM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Sat, Feb 16, 2013 at 7:43 PM, Glenn Maynard <glenn at zewt.org> wrote:
> > Since we have a real URL parser now, I think we have a reasonable way to
> do
> > this: capture the blob in the parser, returning it as part of the parsed
> > URL.
>
> Although this might theoretically work, I suspect it'll take a while
> before browsers get URL parsers that match the architecture of the
> specification. (They all have somewhat different architectures at the
> moment and trying to extend them in any meaningful manner at this
> point seems like asking for trouble.)
>

That's fine, since the main goal is to have a simple, consistent way of
making it clear in specs exactly when the blob of a blob URL is captured.
Whether that's actually implemented as part of the URL parser or at a
higher level is an implementation detail.

I suspect this will also fix some underdefined behavior with the
non-autorevoking blobs we have today.  For example:

    var url = URL.createObjectURL(blob);
    img.src = url;
    URL.revokeObjectURL(url);

I think according to spec this may or may not work, since "update the image
data" might or might not happen synchronously.  This actually does work in
Chrome and Firefox, so I'm guessing it wouldn't actually be web-compatible
to do that.  Capturing the blob when @src (and srcset) is assigned would
fix this, so the blob is captured synchronously even if the browser isn't
going to load the image right away.

-- 
Glenn Maynard


From giles at mozilla.com  Mon Feb 18 09:51:03 2013
From: giles at mozilla.com (Ralph Giles)
Date: Mon, 18 Feb 2013 09:51:03 -0800
Subject: [whatwg] metadata attribute for media
In-Reply-To: <20130217144856.72a25d99@desudesudesu>
References: <505BA783.2030202@mozilla.com> <op.wlac76p9sr6mfa@kirk>
	<50B406DA.70708@mozilla.com> <50B52E51.1000707@mozilla.com>
	<Pine.LNX.4.64.1212120051040.9975@ps20323.dreamhostps.com>
	<50C7DC9A.1070000@mozilla.com>
	<20130217144856.72a25d99@desudesudesu>
Message-ID: <51226A07.2070206@mozilla.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/02/13 05:48 AM, Nils Dagsson Moskopp wrote:

> If one cares to that extent, and is
>> already handling format differences, dealing with vendor
>> variation on top isn't that much more effort.
> 
> I disagree, strongly.

Ok, thanks for the feedback. Do you like my subsequent proposal better?

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-January/038705.html

 -r

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRImnnAAoJEEcAD3uxRB3vHBwH/14a91L4oN6nktTttTRvQQFf
hmtz52nAO7BdInpG68fRACgLVsz2eT+eWakAAMuzh7T57NH9ZNCSWp1Rk/AM3BXD
akx6QXQuk9eOwuRlk+BIVIUaKVFyod9D133BdTjGqF6/cVmn7emmIm9BWB0sxXrE
3CPuALqs+07ExHbyB/UsE5BWqsJRccJHg9QnJwXd4aMtHbIg37KAcfgN4aYVTHQV
B1I95Uh1Ron2LUCNI9P+Pm8WPQGDcj0cuwFcueRMYy2O26a1xHisOew/l3Cz46Ex
Oq6gAX3Lz/y5LxFhnnlPIeBDhBE9bB0r4jqOtY3FNA+dcUruKI769nIw5WtTmd4=
=zJ6M
-----END PGP SIGNATURE-----


From senorblanco at chromium.org  Mon Feb 18 15:01:15 2013
From: senorblanco at chromium.org (Stephen White)
Date: Mon, 18 Feb 2013 18:01:15 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLaF2gxn2D4XGKSj7CqBWt9rje_nNKzzF9aQCzg89AhHPQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLaF2gxn2D4XGKSj7CqBWt9rje_nNKzzF9aQCzg89AhHPQ@mail.gmail.com>
Message-ID: <CAPeKFTjS3nGhCO+PTV_sSuPYYux-aP1bXiKiVmW10gFgUF_XoA@mail.gmail.com>

On Sat, Feb 16, 2013 at 4:09 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Sat, Feb 16, 2013 at 11:09 AM, Stephen White <senorblanco at chromium.org>wrote:
>
>> On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>
>>> On Sat, Feb 16, 2013 at 4:35 AM, Stephen White <senorblanco at chromium.org
>>> > wrote:
>>>
>>>> Even within canvas, there may be a way to break it if the LCD AA text
>>>> is drawn first and a dest-alpha compositing mode is used overtop (I haven't
>>>> verified this though).
>>>
>>>
>>> I don't think that's a problem. All destination alpha values will be 1
>>> even after the subpixel AA test is painted, and you'll treat it as normal.
>>>
>>
>>  I was thinking something like this:
>>
>> - draw subpixel AA text over an opaque background
>> - draw a partially-transparent rect with destination-atop mode over the
>> subpixel AA text
>>
>>  Now some of the subpixel AA text is still there, but the destination
>> alpha is non-1, so things will go bad when you composite into the page.
>>  (At least I think it will.. Porter-Duff makes my head spin sometimes.)
>>
>
> I don't see the problem. After the first step, you have an RGBA buffer
> that represents exactly the result of the rendering. The second step treats
> it exactly like any other RGBA buffer. Am I being dense?
>

No, it's probably me.  I was thinking that since there was a way to
introduce non-1 alpha into the backing store after-the-fact, it would break
the previously-performed subpixel coverage blending.  But perhaps not.


>
>> The suggestion on the list earlier was to keep two versions of the canvas
>>> buffer: one with grayscale AA, another with subpixel AA, and composite with
>>> the subpixel AA buffer when we can do that safely, otherwise use the
>>> grayscale AA version. In many implementations there would be a performance
>>> hit for this, so it would make sense to have authors opt-in to that
>>> performance hit.
>>>
>>
>> It would also be a needless performance hit if the developer knew that
>> they always wanted subpixel AA, and that their app would never fringe.
>>
>
> I don't think the developer can ever know that. They'd have to assume the
> browser/platform does not have a quick-zoom feature, which is an assumption
> developers shouldn't be making. Although I guess we could just declare that
> that case isn't important enough to matter.
>

Well, pretty much all devices that have pinch-zoom today are high-DPI, and
don't implement subpixel AA.  :)   But no, I don't think that's not a good
assumption to bake into the web platform.


> So let me take a stab at a brief summary of the proposals so far, and the
>> pros and cons of each (correct me if I missed anything):
>>
>> moz-opaque
>> pro:  fairly easy to implement
>> pro:  no performance hit over regular rendering
>> pro:  many opportunities for optimization
>> pro:  catches all in-canvas cases of color fringing
>> con:  does not handle any out-of-canvas color fringing
>> con:  opt-in
>>
>
> Additional con: requires changes to canvas compositing spec and possibly
> implementations.
>

Yes, since it's new behaviour it'll require spec changes.  I guess we can
consider that as part of "con" of being opt-in.

automatic opacity detection
>> pro:  catches most (all?) cases of in-canvas color fringing
>> pro:  some opportunties for optimization (must be conservative in some
>> cases)
>>
> con:  does not catch color fringing on CSS transforms, canvas -> WebGL, etc
>>
>> context attribute (something like:  context.textAntialising = { 'none',
>> 'grayscale', 'subpixel' })
>> pro:  very easy to implement
>> pro:  no performance hit
>> con:  does not catch any cases of color fringing; completely up to web
>> developer
>> con:  opt-in
>>
>
> Additional con: requires specification and implementation of what happens
> when subpixel AA is drawn over transparent background.
>

> deferred canvas rendering (collect commands into a buffer, flush buffer
>> only when compositing canvas to page, and decide on subpixel AA at that
>> point)
>> pro:  catches all cases of color fringing
>> con:  in some cases, requires an infinite buffer (e.g., a canvas that
>> never clears, and only accumulates drawing frame-to-frame means you must
>> accumulate commands indefinitely)
>>
>
> Not really true, you can just give up on the complex cases and draw
> grayscale whenever you feel like it.
>

And leave the behaviour unspecified, I'm guessing?  Doesn't that least to
inconsistent behaviour between browsers?  Even within one implementation,
if you had content whose command stream varied over the maximum buffer
length threshold, it'd toggle between subpixel and grayscale AA. Not sure
if this is a case worth worrying about, but it does feel like it's exposing
more of the implementation that one would like.

Stephen

>
>
>> con:  difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
>> con:  may introduce performance hit due to re-rendering with and without
>> subpixel AA (in cases where you would rather have just gone without)
>>
>> two buffers (one grayscale, one LCD AA)
>> pro:  handles all cases of color fringing
>> pro:  moderately easy to implement
>> con:  RAM (or VRAM) usage is doubled
>> con:  possibly-unnecessary performance hit
>> con:  must be opt-in
>>
>
> Sounds right with the above modifications.


>
> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>


From robert at ocallahan.org  Mon Feb 18 15:29:13 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 19 Feb 2013 12:29:13 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTjS3nGhCO+PTV_sSuPYYux-aP1bXiKiVmW10gFgUF_XoA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLaF2gxn2D4XGKSj7CqBWt9rje_nNKzzF9aQCzg89AhHPQ@mail.gmail.com>
	<CAPeKFTjS3nGhCO+PTV_sSuPYYux-aP1bXiKiVmW10gFgUF_XoA@mail.gmail.com>
Message-ID: <CAOp6jLY5Vhss+DF6PaWEGrv9FD6nk6YdP1S+vm7dyudEG63rWw@mail.gmail.com>

On Tue, Feb 19, 2013 at 12:01 PM, Stephen White <senorblanco at chromium.org>wrote:

> On Sat, Feb 16, 2013 at 4:09 AM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> Not really true, you can just give up on the complex cases and draw
>> grayscale whenever you feel like it.
>>
>
> And leave the behaviour unspecified, I'm guessing?  Doesn't that least to
> inconsistent behaviour between browsers?  Even within one implementation,
> if you had content whose command stream varied over the maximum buffer
> length threshold, it'd toggle between subpixel and grayscale AA. Not sure
> if this is a case worth worrying about, but it does feel like it's exposing
> more of the implementation that one would like.
>

You could avoid toggling by disabling subpixel AA permanently if you're
forced over the buffer threshold.

I don't think we should try to specify exactly when subpixel AA happens.
There's huge variation across platforms and UAs already and it very rarely
matters for interop; when subpixel AA fails the site still works. I think
we should treat this as a quality-of-implementation issue, possibly
assisted by author hints.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From cabanier at gmail.com  Mon Feb 18 18:52:36 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Mon, 18 Feb 2013 19:52:36 -0700
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTjS3nGhCO+PTV_sSuPYYux-aP1bXiKiVmW10gFgUF_XoA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLaF2gxn2D4XGKSj7CqBWt9rje_nNKzzF9aQCzg89AhHPQ@mail.gmail.com>
	<CAPeKFTjS3nGhCO+PTV_sSuPYYux-aP1bXiKiVmW10gFgUF_XoA@mail.gmail.com>
Message-ID: <CAGN7qDAAksMxCjcUhqA-Sj37ORuZeHDm2W3_zKX-k5u8cfrvoA@mail.gmail.com>

On Mon, Feb 18, 2013 at 4:01 PM, Stephen White <senorblanco at chromium.org>wrote:

> On Sat, Feb 16, 2013 at 4:09 AM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Sat, Feb 16, 2013 at 11:09 AM, Stephen White <senorblanco at chromium.org
>> > wrote:
>>
>>> On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan <robert at ocallahan.org
>>> > wrote:
>>>
>>>> On Sat, Feb 16, 2013 at 4:35 AM, Stephen White <
>>>> senorblanco at chromium.org> wrote:
>>>>
>>>>> Even within canvas, there may be a way to break it if the LCD AA text
>>>>> is drawn first and a dest-alpha compositing mode is used overtop (I haven't
>>>>> verified this though).
>>>>
>>>>
>>>> I don't think that's a problem. All destination alpha values will be 1
>>>> even after the subpixel AA test is painted, and you'll treat it as normal.
>>>>
>>>
>>>  I was thinking something like this:
>>>
>>> - draw subpixel AA text over an opaque background
>>> - draw a partially-transparent rect with destination-atop mode over the
>>> subpixel AA text
>>>
>>>  Now some of the subpixel AA text is still there, but the destination
>>> alpha is non-1, so things will go bad when you composite into the page.
>>>  (At least I think it will.. Porter-Duff makes my head spin sometimes.)
>>>
>>
>> I don't see the problem. After the first step, you have an RGBA buffer
>> that represents exactly the result of the rendering. The second step treats
>> it exactly like any other RGBA buffer. Am I being dense?
>>
>
> No, it's probably me.  I was thinking that since there was a way to
> introduce non-1 alpha into the backing store after-the-fact, it would break
> the previously-performed subpixel coverage blending.  But perhaps not.
>

If MozOpaque is set or matteColor (or some other property that we can agree
upon), you will be guaranteed that there will never be alpha in the backing
store when you draw the text. We would also need to define under what
compositing modes subpixel AA happens.


>
>
>>
>>> The suggestion on the list earlier was to keep two versions of the
>>>> canvas buffer: one with grayscale AA, another with subpixel AA, and
>>>> composite with the subpixel AA buffer when we can do that safely, otherwise
>>>> use the grayscale AA version. In many implementations there would be a
>>>> performance hit for this, so it would make sense to have authors opt-in to
>>>> that performance hit.
>>>>
>>>
>>> It would also be a needless performance hit if the developer knew that
>>> they always wanted subpixel AA, and that their app would never fringe.
>>>
>>
>> I don't think the developer can ever know that. They'd have to assume the
>> browser/platform does not have a quick-zoom feature, which is an assumption
>> developers shouldn't be making. Although I guess we could just declare that
>> that case isn't important enough to matter.
>>
>
> Well, pretty much all devices that have pinch-zoom today are high-DPI, and
> don't implement subpixel AA.  :)   But no, I don't think that's not a good
> assumption to bake into the web platform.
>
>
>> So let me take a stab at a brief summary of the proposals so far, and the
>>> pros and cons of each (correct me if I missed anything):
>>>
>>> moz-opaque
>>> pro:  fairly easy to implement
>>> pro:  no performance hit over regular rendering
>>> pro:  many opportunities for optimization
>>> pro:  catches all in-canvas cases of color fringing
>>> con:  does not handle any out-of-canvas color fringing
>>> con:  opt-in
>>>
>>
>> Additional con: requires changes to canvas compositing spec and possibly
>> implementations.
>>
>
> Yes, since it's new behaviour it'll require spec changes.  I guess we can
> consider that as part of "con" of being opt-in.
>
> automatic opacity detection
>>> pro:  catches most (all?) cases of in-canvas color fringing
>>> pro:  some opportunties for optimization (must be conservative in some
>>> cases)
>>>
>>  con:  does not catch color fringing on CSS transforms, canvas -> WebGL,
>>> etc
>>>
>>> context attribute (something like:  context.textAntialising = { 'none',
>>> 'grayscale', 'subpixel' })
>>> pro:  very easy to implement
>>> pro:  no performance hit
>>> con:  does not catch any cases of color fringing; completely up to web
>>> developer
>>> con:  opt-in
>>>
>>
>> Additional con: requires specification and implementation of what happens
>> when subpixel AA is drawn over transparent background.
>>
>
>> deferred canvas rendering (collect commands into a buffer, flush buffer
>>> only when compositing canvas to page, and decide on subpixel AA at that
>>> point)
>>> pro:  catches all cases of color fringing
>>> con:  in some cases, requires an infinite buffer (e.g., a canvas that
>>> never clears, and only accumulates drawing frame-to-frame means you must
>>> accumulate commands indefinitely)
>>>
>>
>> Not really true, you can just give up on the complex cases and draw
>> grayscale whenever you feel like it.
>>
>
> And leave the behaviour unspecified, I'm guessing?  Doesn't that least to
> inconsistent behaviour between browsers?  Even within one implementation,
> if you had content whose command stream varied over the maximum buffer
> length threshold, it'd toggle between subpixel and grayscale AA. Not sure
> if this is a case worth worrying about, but it does feel like it's exposing
> more of the implementation that one would like.
>

So basically, this will be a feature for browsers that have no pinch-zoom
and cases where the author is sure that the canvas DPI matches the screen
DPI.
I personally like the look of regular AA text better than subpixel AA text
so I would like a way to turn it off. I guess it would be up to the browser
to make it a preference.


>
>>
>>> con:  difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
>>> con:  may introduce performance hit due to re-rendering with and without
>>> subpixel AA (in cases where you would rather have just gone without)
>>>
>>> two buffers (one grayscale, one LCD AA)
>>> pro:  handles all cases of color fringing
>>> pro:  moderately easy to implement
>>> con:  RAM (or VRAM) usage is doubled
>>> con:  possibly-unnecessary performance hit
>>> con:  must be opt-in
>>>
>>
>> Sounds right with the above modifications.
>
>
>>
>> Rob
>> --
>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>
>
>


From senorblanco at chromium.org  Mon Feb 18 20:19:17 2013
From: senorblanco at chromium.org (Stephen White)
Date: Mon, 18 Feb 2013 23:19:17 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
Message-ID: <CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>

On Sat, Feb 16, 2013 at 4:12 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Sat, Feb 16, 2013 at 11:09 AM, Stephen White <senorblanco at chromium.org>wrote:
>
>> deferred canvas rendering (collect commands into a buffer, flush buffer
>> only when compositing canvas to page, and decide on subpixel AA at that
>> point)
>> pro:  catches all cases of color fringing
>> con:  in some cases, requires an infinite buffer (e.g., a canvas that
>> never clears, and only accumulates drawing frame-to-frame means you must
>> accumulate commands indefinitely)
>> con:  difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
>> con:  may introduce performance hit due to re-rendering with and without
>> subpixel AA (in cases where you would rather have just gone without)
>>
>> two buffers (one grayscale, one LCD AA)
>> pro:  handles all cases of color fringing
>> pro:  moderately easy to implement
>> con:  RAM (or VRAM) usage is doubled
>> con:  possibly-unnecessary performance hit
>> con:  must be opt-in
>>
>
> Both of these schemes can actually be optimized some more: As long as no
> text is drawn to a canvas, you can freely rasterize (in the first case) or
> use just one buffer (in the second case). In fact, this is true as long as
> no text is drawn to a canvas over non-opaque pixels. So a lot of canvas
> usage could be handled with little or no performance hit.


Even with text on an opaque background, I think you still have to worry
about the case of transformed canvases.  E.g., text drawn over an opaque
background into a single still frame canvas, but then subsequently rotated
via CSS transforms from 0 degrees through non-0.  The first frame can use
subpixel AA, but then subsequent frames can't.  So I think you need to keep
the command stream around (first case) or
always render two buffers as soon as you draw text.  That seems like a
pretty heavy burden.

For canvas->WebGL the problem becomes pretty much intractable, since
there's no way to know what a given shader will do to the pixels.  So I
think you'd always have to give up and do grayscale AA in that case.

Stephen

>
>
> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>


From robert at ocallahan.org  Mon Feb 18 20:40:40 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 19 Feb 2013 17:40:40 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
Message-ID: <CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>

On Tue, Feb 19, 2013 at 5:19 PM, Stephen White <senorblanco at chromium.org>wrote:

> Even with text on an opaque background, I think you still have to worry
> about the case of transformed canvases.  E.g., text drawn over an opaque
> background into a single still frame canvas, but then subsequently rotated
> via CSS transforms from 0 degrees through non-0.  The first frame can use
> subpixel AA, but then subsequent frames can't.  So I think you need to keep
> the command stream around (first case) or
> always render two buffers as soon as you draw text.  That seems like a
> pretty heavy burden.
>
> For canvas->WebGL the problem becomes pretty much intractable, since
> there's no way to know what a given shader will do to the pixels.  So I
> think you'd always have to give up and do grayscale AA in that case.
>

Yes, you're quite right.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From nyarly at gmail.com  Tue Feb 19 01:00:30 2013
From: nyarly at gmail.com (Judson Lester)
Date: Tue, 19 Feb 2013 01:00:30 -0800
Subject: [whatwg] Input elements & microdata
Message-ID: <CAOpbp3fdcX3K0JGg3ARgzXwbDW06Uoxhn+PhAZrnhqWCaqMYWA@mail.gmail.com>

There was an email from last year suggesting that the values of input
elements be derived from their value attributes - the purpose there being
to be able to control the form via the microdata interface.  I've only been
able to read it in the archives - the brief exchange was between Igor
Nikolev and Ian Hickson, who was curious about use cases.

Conversely, it would be useful to be able to use input elements to contain
item values, and at the moment, since their values would be derived from
their textContent, they're useless for that.  Specifically, it's often
reasonable to present a representation as the default values in a form and
allow for updates simply by posting the changed values.  It seems unwieldy
to need to replicate that information in e.g. data elements.

While it would be simple to treat the defaultValue as the item property
value for elements (and for radio inputs, let the representation mark the
selected input as the itemprop), it seems counter to the spirit of the
proposal.  The alternative would be to do something like excluding
unsuccessful input elements during the property crawl - which would allow
all such inputs to be marked as itemprop="name" and only the selected one
contribute to the itemscope's property list.

I think Igor had a point though - a consequence of making input elements
useful as itemprop elements would be that it ought to be possible to assign
values to inputs via HTMLElement.itemValue= and see those values reflected
in the form.  It seems like it wouldn't be the best means to manipulate
form data though, since e.g. radio inputs would behave strangely under the
current interface (yes_radio.itemValue="no" should probably change the
value of the button, not which button is selected).

I find the use case of a form to present key/value data compelling, and
being able to apply microdata vocabularies to same strikes me as
particularly useful.

Judson


From cabanier at gmail.com  Tue Feb 19 20:31:35 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Wed, 20 Feb 2013 15:31:35 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
Message-ID: <CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>

So now we have:
- don't do this on pinch-zoom devices
- don't do this for HW accelerated canvases
- don't do this if the canvas dpi doesn't match the screen
- don't do this if there are transforms
- authors will have to be very careful when using this feature since it can
turn on or off or cause rendering glitches.

Is it still worth pursuing this?

On Tue, Feb 19, 2013 at 3:40 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Tue, Feb 19, 2013 at 5:19 PM, Stephen White <senorblanco at chromium.org>wrote:
>
>> Even with text on an opaque background, I think you still have to worry
>> about the case of transformed canvases.  E.g., text drawn over an opaque
>> background into a single still frame canvas, but then subsequently rotated
>> via CSS transforms from 0 degrees through non-0.  The first frame can use
>> subpixel AA, but then subsequent frames can't.  So I think you need to keep
>> the command stream around (first case) or
>> always render two buffers as soon as you draw text.  That seems like a
>> pretty heavy burden.
>>
>> For canvas->WebGL the problem becomes pretty much intractable, since
>> there's no way to know what a given shader will do to the pixels.  So I
>> think you'd always have to give up and do grayscale AA in that case.
>>
>
> Yes, you're quite right.
>
>
> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>


From annevk at annevk.nl  Wed Feb 20 02:55:35 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Wed, 20 Feb 2013 10:55:35 +0000
Subject: [whatwg] Canvas: Fonts in workers
Message-ID: <CADnb78jYOs1ec2NXY10jH6fMzTtB_ofyJYUdVG80m7h-TeH8WA@mail.gmail.com>

I think currently the specification assumes FontLoader is the solution
to fonts in workers. However, 1) FontLoader as currently designed does
not work in workers. 2) Even if slightly modified it would not work in
shared workers as FontLoader is pretty much tied to the document that
has the relevant @font-face declarations. I don't really have a good
solution to this problem.


-- 
http://annevankesteren.nl/


From hsivonen at iki.fi  Wed Feb 20 07:10:20 2013
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 20 Feb 2013 17:10:20 +0200
Subject: [whatwg] Mapping hz-gb-2312,
	iso-2022-kr and iso-2022-cn to a replacement encoding
Message-ID: <CAJQvAufgLgexA3Y-XDEk99QgfK4wsha_F8bxmcNx7AG=7jhKuA@mail.gmail.com>

Hi,

In reference to:
https://code.google.com/p/chromium/issues/detail?id=15701

Would you be willling to re-remove hz-gb-2312, iso-2022-kr and
iso-2022-cn support from Chrome if their labels were aliased to an
XSS-safe replacement encoding like the one proposed in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21057 instead of making
the labels behave as unknown?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/


From gphemsley at gmail.com  Wed Feb 20 12:39:09 2013
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Wed, 20 Feb 2013 15:39:09 -0500
Subject: [whatwg] WHATWG Wiki Licensing Changes
Message-ID: <CAH4e3M4hTbXttH+U9mmsrS6UDa2SQbVCzvCcgAkXvUU=1Kpfqw@mail.gmail.com>

Hello all,

Be advised that all edits made to the WHATWG Wiki after today
(2013-02-20) will be released under the Creative Commons Zero (CC0)
Universal Public Domain Declaration. All edits made prior to today
will remain licensed under the MIT License previously in place, unless
a user or a page specifically opts out of MIT and into CC0.

For the full details, see [[WHATWG Wiki:Copyrights]]:
http://wiki.whatwg.org/wiki/WHATWG_Wiki:Copyrights

Wiki users are encouraged to release their previous edits under the
CC0 declaration by adding the {{CC0 user}} template to their User
page:
http://wiki.whatwg.org/wiki/Template:CC0_user

Pages that were created prior to today should be tagged with {{CC0
page}} once all its contributing editors have opted in to {{CC0 user}}
or have otherwise provided a waiver of the MIT License:
http://wiki.whatwg.org/wiki/Template:CC0_page

This change attempts to make it easier and clearer for individuals
wishing modify and reuse the information on the wiki, with a
particular eye towards incorporating text in future specifications.

To facilitate determining how a page is licensed, there are also two
categories that list which users and pages have opted in to CC0:
http://wiki.whatwg.org/wiki/Category:CC0_users
http://wiki.whatwg.org/wiki/Category:CC0_pages

Remember: If a page is not specifically tagged with {{CC0 page}}, be
sure to check the history of the page to determine whether its
contents are available to reuse without restrictions. Pages created
before 2013-02-20 will need to be verified with each contributing
editor to determine the reuse restrictions on the page.

Regards,
Gordon

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/


From rniwa at apple.com  Wed Feb 20 17:14:21 2013
From: rniwa at apple.com (Ryosuke Niwa)
Date: Wed, 20 Feb 2013 17:14:21 -0800
Subject: [whatwg] inputmode feedback
In-Reply-To: <CADP2=hp-yPwWAKpeuPUwaAF=LmMfyC0Uw2_KxgQGY7cr3GaKuA@mail.gmail.com>
References: <511BE988.7070208@lamouri.fr>
	<CADP2=hp-yPwWAKpeuPUwaAF=LmMfyC0Uw2_KxgQGY7cr3GaKuA@mail.gmail.com>
Message-ID: <80D1B5C9-E6AD-41B4-B1D3-8804003AF568@apple.com>

On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:
> To conclude, Mozilla is interested in implementing this set of keywords:
> verbatim, text, name, prose and digit (or numeric).

Why is name not an input type?

How does one decide whether a given semantics should be introduced as a type or a mode?

On Feb 15, 2013, at 12:28 AM, Takayoshi Kochi (?? ??) <kochi at google.com> wrote:

> Hello Mounir,
> 
> On Thu, Feb 14, 2013 at 4:29 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:
> 
>> Regarding the three Japanese specific types, it is not clear if
>> inputmode is the best way to solve the use cases intended to be solved.
>> Actually, 'kana' and 'katakana' are trying to give a hint about the
>> script that has to be used which seems to be orthogonal with the other
>> types. We could allow inputmode to have a set of values but that would
>> make the behaviour way more complex so I wonder if we couldn't try to
>> solve that problem with another attribute like inputscript.
>> 
> "three Japanese specific types"? 'kana', 'katakana', and 'full-width-latin"?
> 
> I agree that it is weird 'kana' and 'katakana' are listed as inputmode
> attribute, and 'inputscript' sounds more reasonable place where they should be listed.

Given the text in the spec "[t]he inputmode content attribute is an enumerated attribute that specifies what kind of input mechanism would be most helpful for users entering content into the form control," it makes sense for input mode to include kana and katakana.

On the other hand, I'm surprised to find that these modes are very specific to Japanese.

- R. Niwa



From jonas at sicking.cc  Wed Feb 20 21:47:43 2013
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 20 Feb 2013 21:47:43 -0800
Subject: [whatwg] Canvas: Fonts in workers
In-Reply-To: <CADnb78jYOs1ec2NXY10jH6fMzTtB_ofyJYUdVG80m7h-TeH8WA@mail.gmail.com>
References: <CADnb78jYOs1ec2NXY10jH6fMzTtB_ofyJYUdVG80m7h-TeH8WA@mail.gmail.com>
Message-ID: <CA+c2ei9hd6htE6-3=-nmtqf8MGSJUD+hiewQA+OawQVp+LYEmg@mail.gmail.com>

On Wed, Feb 20, 2013 at 2:55 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> I think currently the specification assumes FontLoader is the solution
> to fonts in workers. However, 1) FontLoader as currently designed does
> not work in workers. 2) Even if slightly modified it would not work in
> shared workers as FontLoader is pretty much tied to the document that
> has the relevant @font-face declarations. I don't really have a good
> solution to this problem.

In general, we need to define which fonts are available to use when
drawing text into a canvas in a worker. For a dedicated worker we
could say that it's the same set as is available in the document,
except that that set can change at any time as new fonts are loaded.
And for a shared worker this is even more complicated since multiple
documents, with different sets of fonts, can be connected to the same
shared worker.

We could possibly still use the the FontLoader interface if we do the following:
* FontLoader needs to drop the dependency on CSSFontFaceRule (or at
least make the dependency optional and not available in workers).
* We'll expose a global FontLoader object per worker scope.
* The worker can't use any downloaded fonts other than the ones loaded
through the global FontLoader for that scope.

/ Jonas


From ian at hixie.ch  Wed Feb 20 21:59:41 2013
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 21 Feb 2013 05:59:41 +0000 (UTC)
Subject: [whatwg] Canvas: Fonts in workers
In-Reply-To: <CA+c2ei9hd6htE6-3=-nmtqf8MGSJUD+hiewQA+OawQVp+LYEmg@mail.gmail.com>
References: <CADnb78jYOs1ec2NXY10jH6fMzTtB_ofyJYUdVG80m7h-TeH8WA@mail.gmail.com>
	<CA+c2ei9hd6htE6-3=-nmtqf8MGSJUD+hiewQA+OawQVp+LYEmg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1302210558350.3956@ps20323.dreamhostps.com>

On Wed, 20 Feb 2013, Jonas Sicking wrote:
> On Wed, Feb 20, 2013 at 2:55 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> > I think currently the specification assumes FontLoader is the solution 
> > to fonts in workers. However, 1) FontLoader as currently designed does 
> > not work in workers. 2) Even if slightly modified it would not work in 
> > shared workers as FontLoader is pretty much tied to the document that 
> > has the relevant @font-face declarations. I don't really have a good 
> > solution to this problem.
> 
> In general, we need to define which fonts are available to use when 
> drawing text into a canvas in a worker. For a dedicated worker we could 
> say that it's the same set as is available in the document, except that 
> that set can change at any time as new fonts are loaded. And for a 
> shared worker this is even more complicated since multiple documents, 
> with different sets of fonts, can be connected to the same shared 
> worker.
> 
> We could possibly still use the the FontLoader interface if we do the following:
> * FontLoader needs to drop the dependency on CSSFontFaceRule (or at
> least make the dependency optional and not available in workers).
> * We'll expose a global FontLoader object per worker scope.
> * The worker can't use any downloaded fonts other than the ones loaded
> through the global FontLoader for that scope.

My expectation was that this is how FontLoader would work for workers. (We 
can't rely on what fonts are in the Document since that's shared state, 
and workers try to avoid shared state as a design principle.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From annevk at annevk.nl  Thu Feb 21 02:47:37 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Thu, 21 Feb 2013 10:47:37 +0000
Subject: [whatwg] Canvas: Fonts in workers
In-Reply-To: <Pine.LNX.4.64.1302210558350.3956@ps20323.dreamhostps.com>
References: <CADnb78jYOs1ec2NXY10jH6fMzTtB_ofyJYUdVG80m7h-TeH8WA@mail.gmail.com>
	<CA+c2ei9hd6htE6-3=-nmtqf8MGSJUD+hiewQA+OawQVp+LYEmg@mail.gmail.com>
	<Pine.LNX.4.64.1302210558350.3956@ps20323.dreamhostps.com>
Message-ID: <CADnb78jiZn6PxARiKUx8jzjWQQfRkKpmX9mT_Q6sV0p=muBAcA@mail.gmail.com>

On Thu, Feb 21, 2013 at 5:59 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 20 Feb 2013, Jonas Sicking wrote:
>> We could possibly still use the the FontLoader interface if we do the following:
>> * FontLoader needs to drop the dependency on CSSFontFaceRule (or at
>> least make the dependency optional and not available in workers).
>> * We'll expose a global FontLoader object per worker scope.
>> * The worker can't use any downloaded fonts other than the ones loaded
>> through the global FontLoader for that scope.
>
> My expectation was that this is how FontLoader would work for workers. (We
> can't rely on what fonts are in the Document since that's shared state,
> and workers try to avoid shared state as a design principle.)

Sure, but FontLoader is tightly coupled with the document since it
does not actually supply URLs for the fonts itself, it relies on
@font-face for that. It just indicates whether the font is loaded or
that it should be loaded.


-- 
http://annevankesteren.nl/


From ian at hixie.ch  Thu Feb 21 08:45:12 2013
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 21 Feb 2013 16:45:12 +0000 (UTC)
Subject: [whatwg] Canvas: Fonts in workers
In-Reply-To: <CADnb78jiZn6PxARiKUx8jzjWQQfRkKpmX9mT_Q6sV0p=muBAcA@mail.gmail.com>
References: <CADnb78jYOs1ec2NXY10jH6fMzTtB_ofyJYUdVG80m7h-TeH8WA@mail.gmail.com>
	<CA+c2ei9hd6htE6-3=-nmtqf8MGSJUD+hiewQA+OawQVp+LYEmg@mail.gmail.com>
	<Pine.LNX.4.64.1302210558350.3956@ps20323.dreamhostps.com>
	<CADnb78jiZn6PxARiKUx8jzjWQQfRkKpmX9mT_Q6sV0p=muBAcA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1302211645030.3956@ps20323.dreamhostps.com>

On Thu, 21 Feb 2013, Anne van Kesteren wrote:
> On Thu, Feb 21, 2013 at 5:59 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 20 Feb 2013, Jonas Sicking wrote:
> >> We could possibly still use the the FontLoader interface if we do the 
> >> following: * FontLoader needs to drop the dependency on 
> >> CSSFontFaceRule (or at least make the dependency optional and not 
> >> available in workers). * We'll expose a global FontLoader object per 
> >> worker scope. * The worker can't use any downloaded fonts other than 
> >> the ones loaded through the global FontLoader for that scope.
> >
> > My expectation was that this is how FontLoader would work for workers. 
> > (We can't rely on what fonts are in the Document since that's shared 
> > state, and workers try to avoid shared state as a design principle.)
> 
> Sure, but FontLoader is tightly coupled with the document since it does 
> not actually supply URLs for the fonts itself, it relies on @font-face 
> for that. It just indicates whether the font is loaded or that it should 
> be loaded.

Then we should fix that. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From senorblanco at chromium.org  Thu Feb 21 11:12:35 2013
From: senorblanco at chromium.org (Stephen White)
Date: Thu, 21 Feb 2013 14:12:35 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
Message-ID: <CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>

On Tue, Feb 19, 2013 at 11:31 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> So now we have:
> - don't do this on pinch-zoom devices
> - don't do this for HW accelerated canvases
> - don't do this if the canvas dpi doesn't match the screen
>
- don't do this if there are transforms
> - authors will have to be very careful when using this feature since it
> can turn on or off or cause rendering glitches.
>
> Is it still worth pursuing this?
>

I believe it is.  Even with those constraints, there are a large number of
applications which can benefit from text which looks as good as the native
platform can provide.

That said, I also think Robert is right that we should not spec out
precisely when subpixel AA text will occur in any of these automatic modes,
since:

1)  there are some platforms/devices which don't do LCD text at all
2)  It may be too restrictive for the browser implementor, e.g., they may
be essentially required to implement deferred rendering or two backing
stores in order to meet the resulting spec, which seems onerous

Subpixel AA text aside, I still think it's worth spec'ing out mozOpaque, if
only just for the optimization opportunities that we don't get with an
automatic solution (e.g., putImageData).  Its implementation is fairly
straightforward (much more so than the other options above), and it won't
break any existing content.

To me, the "it breaks compositing" argument falls into the "doctor, it
hurts when I do this" category:  the user is specifically opting into an
opaque backing store, and so the changes in behaviour for compositing modes
which reference destination alpha are expected, just as they are when using
DST_ALPHA blending modes in a WebGL context created with the "alpha"
attribute set to false.

Stephen


>
> On Tue, Feb 19, 2013 at 3:40 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Tue, Feb 19, 2013 at 5:19 PM, Stephen White <senorblanco at chromium.org>wrote:
>>
>>> Even with text on an opaque background, I think you still have to worry
>>> about the case of transformed canvases.  E.g., text drawn over an opaque
>>> background into a single still frame canvas, but then subsequently rotated
>>> via CSS transforms from 0 degrees through non-0.  The first frame can use
>>> subpixel AA, but then subsequent frames can't.  So I think you need to keep
>>> the command stream around (first case) or
>>> always render two buffers as soon as you draw text.  That seems like a
>>> pretty heavy burden.
>>>
>>> For canvas->WebGL the problem becomes pretty much intractable, since
>>> there's no way to know what a given shader will do to the pixels.  So I
>>> think you'd always have to give up and do grayscale AA in that case.
>>>
>>
>> Yes, you're quite right.
>>
>>
>> Rob
>> --
>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>
>
>


From cmhjones at gmail.com  Thu Feb 21 11:42:40 2013
From: cmhjones at gmail.com (Cameron Jones)
Date: Thu, 21 Feb 2013 19:42:40 +0000
Subject: [whatwg] HTTP Forms extension specification
Message-ID: <CALGrgesd24R=Dhf0KE8aJfTVLR10MME2QGD8T2Gt+ndUkFXMng@mail.gmail.com>

Hello wg,

I've just committed an initial draft of HTTP extensions for Forms:

http://cameronjones.github.com/form-http-extensions/index.html

The document can be considered within the public domain for integration.

Thanks,
Cameron Jones


From robert at ocallahan.org  Thu Feb 21 15:33:48 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 22 Feb 2013 12:33:48 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
Message-ID: <CAOp6jLaH=g6gYmKYDiM1uNLzatMo=0D6uQ8aBhUkeCJNyH_9Yg@mail.gmail.com>

I think Rik is convincing me that we shouldn't expose mozOpaque or any
other explicit subpixel AA control to the Web. It will be very easy for Web
authors to test it in one place and discover that it works without
realizing that they're causing problems for some users.

I think a fully automatic solution that tries to use subpixel AA but is
always able to render grayscale AA if needed is the way to go. Possibly
with an author hint to suggest opting into a more expensive rendering path.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From cabanier at gmail.com  Thu Feb 21 16:01:49 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Fri, 22 Feb 2013 11:01:49 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAOp6jLaH=g6gYmKYDiM1uNLzatMo=0D6uQ8aBhUkeCJNyH_9Yg@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
	<CAOp6jLaH=g6gYmKYDiM1uNLzatMo=0D6uQ8aBhUkeCJNyH_9Yg@mail.gmail.com>
Message-ID: <CAGN7qDB2M7r9AYyZavPo11NL7hRBXuNT+0SHdXe=OF8_kZK5iQ@mail.gmail.com>

On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> I think Rik is convincing me that we shouldn't expose mozOpaque or any
> other explicit subpixel AA control to the Web. It will be very easy for Web
> authors to test it in one place and discover that it works without
> realizing that they're causing problems for some users.
>
> I think a fully automatic solution that tries to use subpixel AA but is
> always able to render grayscale AA if needed is the way to go. Possibly
> with an author hint to suggest opting into a more expensive rendering path.
>
>
Great! I think matteColor (or matteStyle to be more consistent) can easily
be implemented. We can optimize rendering later.

So, if a mattecolor is set the UA can assume that:
- all compositing operation within the canvas can ignore background alpha
- the canvas can be copied directly to the screen (unless another effect is
applied to the canvas element or its ancestor)

If mattecolor is set, the UA should matte with that color. If a compositing
operation (that introduces alpha) is used, the matte operation needs to be
repeated.

Rik


From annevk at annevk.nl  Fri Feb 22 02:05:51 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Fri, 22 Feb 2013 10:05:51 +0000
Subject: [whatwg] HTTP Forms extension specification
In-Reply-To: <CALGrgesd24R=Dhf0KE8aJfTVLR10MME2QGD8T2Gt+ndUkFXMng@mail.gmail.com>
References: <CALGrgesd24R=Dhf0KE8aJfTVLR10MME2QGD8T2Gt+ndUkFXMng@mail.gmail.com>
Message-ID: <CADnb78hqMt=thXvbbeamVwiKcLAV4NjbX60FGqE2CcDBSTXyWQ@mail.gmail.com>

On Thu, Feb 21, 2013 at 7:42 PM, Cameron Jones <cmhjones at gmail.com> wrote:
> I've just committed an initial draft of HTTP extensions for Forms:
>
> http://cameronjones.github.com/form-http-extensions/index.html
>
> The document can be considered within the public domain for integration.

I'd recommend making CC0 the license then, rather than CCA.

Motivation would also useful. It's not entirely clear to me why this
complexity is warranted. And the complexity seems lacking, e.g. you're
not putting the necessary restrictions on header names and values as
far as I can tell.

(Spelling: HTTP, XMLHttpRequest, JavaScript, my name is with a
lowercase v if you include the first name.)


-- 
http://annevankesteren.nl/


From cmhjones at gmail.com  Fri Feb 22 06:29:00 2013
From: cmhjones at gmail.com (Cameron Jones)
Date: Fri, 22 Feb 2013 14:29:00 +0000
Subject: [whatwg] HTTP Forms extension specification
In-Reply-To: <CADnb78hqMt=thXvbbeamVwiKcLAV4NjbX60FGqE2CcDBSTXyWQ@mail.gmail.com>
References: <CALGrgesd24R=Dhf0KE8aJfTVLR10MME2QGD8T2Gt+ndUkFXMng@mail.gmail.com>
	<CADnb78hqMt=thXvbbeamVwiKcLAV4NjbX60FGqE2CcDBSTXyWQ@mail.gmail.com>
Message-ID: <CALGrgesxyCarfoHDsTSiHbg2S0rEKvUHnGVEeBfUGudmTJ=+uQ@mail.gmail.com>

On Fri, Feb 22, 2013 at 10:05 AM, Anne van Kesteren <annevk at annevk.nl>wrote:

> On Thu, Feb 21, 2013 at 7:42 PM, Cameron Jones <cmhjones at gmail.com> wrote:
> > I've just committed an initial draft of HTTP extensions for Forms:
> >
> > http://cameronjones.github.com/form-http-extensions/index.html
> >
> > The document can be considered within the public domain for integration.
>
> I'd recommend making CC0 the license then, rather than CCA.
>


Done, and spelling fixed.


>
> Motivation would also useful. It's not entirely clear to me why this
> complexity is warranted.


The motivations are the same which support declarative over imperative
programming, access to the HTTP protocol methods and headers (ETags,
versioning), greater flexibility over payload binding and the ability to
avoid using cookies for session continuation. The access to HTTP Auth
provides greater security over non-HTTPS than is currently possible while
retaining the ability to style forms for login\logout which users have come
to expect. This is all in the absence of requiring JavaScript to be on.

For a (slightly inflamed from a rant-able persona, so please read with
potential sensitivities off) further examination of the use cases and
rationale, the specification is the reification of the proposal i wrote
last year:

http://www.w3.org/wiki/User:Cjones/ISSUE-195



> And the complexity seems lacking, e.g. you're
> not putting the necessary restrictions on header names and values as
> far as I can tell.
>
>
The HTTP headers are restricted using a copy-paste of those in XHR which is
included in the form submission process. Happy to hear any suggestions to
improve the structure or general authoring.

Thanks,
Cameron Jones


From senorblanco at chromium.org  Fri Feb 22 07:59:48 2013
From: senorblanco at chromium.org (Stephen White)
Date: Fri, 22 Feb 2013 10:59:48 -0500
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDB2M7r9AYyZavPo11NL7hRBXuNT+0SHdXe=OF8_kZK5iQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
	<CAOp6jLaH=g6gYmKYDiM1uNLzatMo=0D6uQ8aBhUkeCJNyH_9Yg@mail.gmail.com>
	<CAGN7qDB2M7r9AYyZavPo11NL7hRBXuNT+0SHdXe=OF8_kZK5iQ@mail.gmail.com>
Message-ID: <CAPeKFTiVrKfzTZOCvshynH3yUyDePz+6ObJpjYGGvLOj_630CA@mail.gmail.com>

On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier <cabanier at gmail.com> wrote:

>
>
> On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> I think Rik is convincing me that we shouldn't expose mozOpaque or any
>> other explicit subpixel AA control to the Web. It will be very easy for Web
>> authors to test it in one place and discover that it works without
>> realizing that they're causing problems for some users.
>>
>> I think a fully automatic solution that tries to use subpixel AA but is
>> always able to render grayscale AA if needed is the way to go. Possibly
>> with an author hint to suggest opting into a more expensive rendering path.
>
>
Here are the problems I see with that approach:

1)  In order to avoid a performance hit for existing content, it still
requires a spec change (the hint)
2)  Even with the hint, when the author knows they want LCD AA, they still
incur a performance penalty of drawing to two buffers.
3)  It still can't handle all cases, such as canvas -> WebGL, which will
have to remain grayscale-only, even when the author knows it would be safe
for their application.

Also, what form should this authoring hint take?  Is it going to explicitly
call out LCD AA?  In that case, how is it better than an opt-in canvas
attribute?  If it doesn't explicitly call out LCD AA, but that's the only
effect it has, what should it be called?

I also have concerns that the knowledge of when it's safe to use the LCD AA
buffer is going to spread throughout the browser codebase, even in areas
which currently have no knowledge of canvas, in order to handle all the
special cases.  This may just be an implementation detail (and may be
avoidable, this is TBD), but it does have the potential to introduce
dependencies or complicate implementation.


>>
> Great! I think matteColor (or matteStyle to be more consistent) can easily
> be implemented. We can optimize rendering later.
>

> So, if a mattecolor is set the UA can assume that:
>

Maybe I'm missing something, but if we're going down the automatic road,
why do we need a new function/attribute?  Why not simply detect when a
canvas-sized fillRect() has been performed with an opaque fillStyle?  This
would also allow optimization of existing content.

Stephen

- all compositing operation within the canvas can ignore background alpha
> - the canvas can be copied directly to the screen (unless another effect
> is applied to the canvas element or its ancestor)
>
> If mattecolor is set, the UA should matte with that color. If a
> compositing operation (that introduces alpha) is used, the matte operation
> needs to be repeated.
>
> Rik
>


From annevk at annevk.nl  Fri Feb 22 08:37:45 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Fri, 22 Feb 2013 16:37:45 +0000
Subject: [whatwg] HTTP Forms extension specification
In-Reply-To: <CALGrgesxyCarfoHDsTSiHbg2S0rEKvUHnGVEeBfUGudmTJ=+uQ@mail.gmail.com>
References: <CALGrgesd24R=Dhf0KE8aJfTVLR10MME2QGD8T2Gt+ndUkFXMng@mail.gmail.com>
	<CADnb78hqMt=thXvbbeamVwiKcLAV4NjbX60FGqE2CcDBSTXyWQ@mail.gmail.com>
	<CALGrgesxyCarfoHDsTSiHbg2S0rEKvUHnGVEeBfUGudmTJ=+uQ@mail.gmail.com>
Message-ID: <CADnb78iosSFzc9KTjmqiSMrTo2J9BKFXCy+OhJ5tNVoeADBRnQ@mail.gmail.com>

On Fri, Feb 22, 2013 at 2:29 PM, Cameron Jones <cmhjones at gmail.com> wrote:
> The HTTP headers are restricted using a copy-paste of those in XHR which is
> included in the form submission process. Happy to hear any suggestions to
> improve the structure or general authoring.

You are not making the same checks as
http://xhr.spec.whatwg.org/#the-setrequestheader%28%29-method does.
E.g. I could inject a header value in your algorithm that is CRLF
followed by "Referer: mahahah".

Not really convinced by the use cases, but maybe someone else is.


-- 
http://annevankesteren.nl/


From cmhjones at gmail.com  Fri Feb 22 08:46:04 2013
From: cmhjones at gmail.com (Cameron Jones)
Date: Fri, 22 Feb 2013 16:46:04 +0000
Subject: [whatwg] HTTP Forms extension specification
In-Reply-To: <CADnb78iosSFzc9KTjmqiSMrTo2J9BKFXCy+OhJ5tNVoeADBRnQ@mail.gmail.com>
References: <CALGrgesd24R=Dhf0KE8aJfTVLR10MME2QGD8T2Gt+ndUkFXMng@mail.gmail.com>
	<CADnb78hqMt=thXvbbeamVwiKcLAV4NjbX60FGqE2CcDBSTXyWQ@mail.gmail.com>
	<CALGrgesxyCarfoHDsTSiHbg2S0rEKvUHnGVEeBfUGudmTJ=+uQ@mail.gmail.com>
	<CADnb78iosSFzc9KTjmqiSMrTo2J9BKFXCy+OhJ5tNVoeADBRnQ@mail.gmail.com>
Message-ID: <CALGrget--2AJfgYEndJt8geNT6VxzUXAiNQ8eQyQYun_Lfw2pg@mail.gmail.com>

On Fri, Feb 22, 2013 at 4:37 PM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Fri, Feb 22, 2013 at 2:29 PM, Cameron Jones <cmhjones at gmail.com> wrote:
> > The HTTP headers are restricted using a copy-paste of those in XHR which
> is
> > included in the form submission process. Happy to hear any suggestions to
> > improve the structure or general authoring.
>
> You are not making the same checks as
> http://xhr.spec.whatwg.org/#the-setrequestheader%28%29-method does.
> E.g. I could inject a header value in your algorithm that is CRLF
> followed by "Referer: mahahah".
>
>
Ahh, yes i see the references....i'll fix that now.

Thanks,
cam


From ian at hixie.ch  Fri Feb 22 08:52:38 2013
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 22 Feb 2013 16:52:38 +0000 (UTC)
Subject: [whatwg] inputmode feedback
In-Reply-To: <80D1B5C9-E6AD-41B4-B1D3-8804003AF568@apple.com>
References: <511BE988.7070208@lamouri.fr>
	<CADP2=hp-yPwWAKpeuPUwaAF=LmMfyC0Uw2_KxgQGY7cr3GaKuA@mail.gmail.com>
	<80D1B5C9-E6AD-41B4-B1D3-8804003AF568@apple.com>
Message-ID: <Pine.LNX.4.64.1302221649260.3956@ps20323.dreamhostps.com>

On Wed, 20 Feb 2013, Ryosuke Niwa wrote:
> 
> Why is name not an input type?

There's a section that discusses it a bit:

http://whatwg.org/html#the-difference-between-the-field-type,-the-autofill-field-name,-and-the-input-modality

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From cabanier at gmail.com  Fri Feb 22 10:48:02 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Fri, 22 Feb 2013 10:48:02 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTiVrKfzTZOCvshynH3yUyDePz+6ObJpjYGGvLOj_630CA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
	<CAOp6jLaH=g6gYmKYDiM1uNLzatMo=0D6uQ8aBhUkeCJNyH_9Yg@mail.gmail.com>
	<CAGN7qDB2M7r9AYyZavPo11NL7hRBXuNT+0SHdXe=OF8_kZK5iQ@mail.gmail.com>
	<CAPeKFTiVrKfzTZOCvshynH3yUyDePz+6ObJpjYGGvLOj_630CA@mail.gmail.com>
Message-ID: <CAGN7qDDwfh+wN8=X1ipwc=ReKYafBg8eZv8PBmv=Zn9cQhXp7w@mail.gmail.com>

On Fri, Feb 22, 2013 at 7:59 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>>
>>
>> On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan <robert at ocallahan.org
>> > wrote:
>>
>>> I think Rik is convincing me that we shouldn't expose mozOpaque or any
>>> other explicit subpixel AA control to the Web. It will be very easy for Web
>>> authors to test it in one place and discover that it works without
>>> realizing that they're causing problems for some users.
>>>
>>> I think a fully automatic solution that tries to use subpixel AA but is
>>> always able to render grayscale AA if needed is the way to go. Possibly
>>> with an author hint to suggest opting into a more expensive rendering path.
>>
>>
> Here are the problems I see with that approach:
>
> 1)  In order to avoid a performance hit for existing content, it still
> requires a spec change (the hint)
> 2)  Even with the hint, when the author knows they want LCD AA, they still
> incur a performance penalty of drawing to two buffers.
> 3)  It still can't handle all cases, such as canvas -> WebGL, which will
> have to remain grayscale-only, even when the author knows it would be safe
> for their application.
>
> Also, what form should this authoring hint take?  Is it going to
> explicitly call out LCD AA?  In that case, how is it better than an opt-in
> canvas attribute?  If it doesn't explicitly call out LCD AA, but that's the
> only effect it has, what should it be called?
>
> I also have concerns that the knowledge of when it's safe to use the LCD
> AA buffer is going to spread throughout the browser codebase, even in areas
> which currently have no knowledge of canvas, in order to handle all the
> special cases.  This may just be an implementation detail (and may be
> avoidable, this is TBD), but it does have the potential to introduce
> dependencies or complicate implementation.
>

Since this is a feature for advanced users, we should let them handle all
the cases. (I would even allow subpixel AA on a transparent canvas)
Handling all the edge cases in the browser will be extremely difficult (if
it's even possible) and will just frustrate those advanced users since it
will get in their way.


>
>
>>>
>> Great! I think matteColor (or matteStyle to be more consistent) can
>> easily be implemented. We can optimize rendering later.
>>
>
>> So, if a mattecolor is set the UA can assume that:
>>
>
> Maybe I'm missing something, but if we're going down the automatic road,
> why do we need a new function/attribute?  Why not simply detect when a
> canvas-sized fillRect() has been performed with an opaque fillStyle?  This
> would also allow optimization of existing content.
>

Doesn't that seem slightly hacky?
So, if the canvas detects that you did a fillrect with a constant color, it
should assume that it's opaque?  This seems confusing from an author's
perspective.
In addition, compositing modes that introduce alpha will turn the bit off
again and there would be no way to turn it back on.


>
> - all compositing operation within the canvas can ignore background alpha
>> - the canvas can be copied directly to the screen (unless another effect
>> is applied to the canvas element or its ancestor)
>>
>> If mattecolor is set, the UA should matte with that color. If a
>> compositing operation (that introduces alpha) is used, the matte operation
>> needs to be repeated.
>>
>> Rik
>>
>
>


From cabanier at gmail.com  Fri Feb 22 16:53:29 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Sat, 23 Feb 2013 11:53:29 +1100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTiVrKfzTZOCvshynH3yUyDePz+6ObJpjYGGvLOj_630CA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
	<CAOp6jLaH=g6gYmKYDiM1uNLzatMo=0D6uQ8aBhUkeCJNyH_9Yg@mail.gmail.com>
	<CAGN7qDB2M7r9AYyZavPo11NL7hRBXuNT+0SHdXe=OF8_kZK5iQ@mail.gmail.com>
	<CAPeKFTiVrKfzTZOCvshynH3yUyDePz+6ObJpjYGGvLOj_630CA@mail.gmail.com>
Message-ID: <CAGN7qDD03fR2NdYvsjLkXTqAWPWwYxLJgHAN475oCbFYcq9X1w@mail.gmail.com>

On Sat, Feb 23, 2013 at 2:59 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>>
>>
>> On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan <robert at ocallahan.org
>> > wrote:
>>
>>> I think Rik is convincing me that we shouldn't expose mozOpaque or any
>>> other explicit subpixel AA control to the Web. It will be very easy for Web
>>> authors to test it in one place and discover that it works without
>>> realizing that they're causing problems for some users.
>>>
>>> I think a fully automatic solution that tries to use subpixel AA but is
>>> always able to render grayscale AA if needed is the way to go. Possibly
>>> with an author hint to suggest opting into a more expensive rendering path.
>>
>>
> Here are the problems I see with that approach:
>
> 1)  In order to avoid a performance hit for existing content, it still
> requires a spec change (the hint)
>

What is the performance hit?


> 2)  Even with the hint, when the author knows they want LCD AA, they still
> incur a performance penalty of drawing to two buffers.
>

Why are there 2 buffers? You just draw on top of the existing content. It
is up to the author to ensure correct output.


> 3)  It still can't handle all cases, such as canvas -> WebGL, which will
> have to remain grayscale-only, even when the author knows it would be safe
> for their application.
>

That is OK. A UA is not required to implement this.


>
> Also, what form should this authoring hint take?  Is it going to
> explicitly call out LCD AA?  In that case, how is it better than an opt-in
> canvas attribute?  If it doesn't explicitly call out LCD AA, but that's the
> only effect it has, what should it be called?
>
> I also have concerns that the knowledge of when it's safe to use the LCD
> AA buffer is going to spread throughout the browser codebase, even in areas
> which currently have no knowledge of canvas, in order to handle all the
> special cases.  This may just be an implementation detail (and may be
> avoidable, this is TBD), but it does have the potential to introduce
> dependencies or complicate implementation.
>
>
>>>
>> Great! I think matteColor (or matteStyle to be more consistent) can
>> easily be implemented. We can optimize rendering later.
>>
>
>> So, if a mattecolor is set the UA can assume that:
>>
>
> Maybe I'm missing something, but if we're going down the automatic road,
> why do we need a new function/attribute?  Why not simply detect when a
> canvas-sized fillRect() has been performed with an opaque fillStyle?  This
> would also allow optimization of existing content.
>
> Stephen
>
> - all compositing operation within the canvas can ignore background alpha
>> - the canvas can be copied directly to the screen (unless another effect
>> is applied to the canvas element or its ancestor)
>>
>> If mattecolor is set, the UA should matte with that color. If a
>> compositing operation (that introduces alpha) is used, the matte operation
>> needs to be repeated.
>>
>
I experimented with adding MatteStyle  for Core Graphics in mozilla and
webkit and got the basics of it working.
So, it's definitely possible to add to the browsers.


From robert at ocallahan.org  Sat Feb 23 03:48:45 2013
From: robert at ocallahan.org (Robert O'Callahan)
Date: Sun, 24 Feb 2013 00:48:45 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTiVrKfzTZOCvshynH3yUyDePz+6ObJpjYGGvLOj_630CA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
	<CAOp6jLaH=g6gYmKYDiM1uNLzatMo=0D6uQ8aBhUkeCJNyH_9Yg@mail.gmail.com>
	<CAGN7qDB2M7r9AYyZavPo11NL7hRBXuNT+0SHdXe=OF8_kZK5iQ@mail.gmail.com>
	<CAPeKFTiVrKfzTZOCvshynH3yUyDePz+6ObJpjYGGvLOj_630CA@mail.gmail.com>
Message-ID: <CAOp6jLaQjFBH_42vXrvzJz5XG0N4Dm7tw4gvaL-5tUVo38POzg@mail.gmail.com>

On Sat, Feb 23, 2013 at 4:59 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan <robert at ocallahan.org
>> > wrote:
>>
>>> I think a fully automatic solution that tries to use subpixel AA but is
>>> always able to render grayscale AA if needed is the way to go. Possibly
>>> with an author hint to suggest opting into a more expensive rendering path.
>>
>>
> Here are the problems I see with that approach:
>
> 1)  In order to avoid a performance hit for existing content, it still
> requires a spec change (the hint)
> 2)  Even with the hint, when the author knows they want LCD AA, they still
> incur a performance penalty of drawing to two buffers.
> 3)  It still can't handle all cases, such as canvas -> WebGL, which will
> have to remain grayscale-only, even when the author knows it would be safe
> for their application.
>

I agree those are problems. All of the available options have problems.

Also, what form should this authoring hint take?  Is it going to explicitly
> call out LCD AA?  In that case, how is it better than an opt-in canvas
> attribute?  If it doesn't explicitly call out LCD AA, but that's the only
> effect it has, what should it be called?
>

Perhaps we could use "text-rendering:optimizeLegibility" on the canvas
element.

I also have concerns that the knowledge of when it's safe to use the LCD AA
> buffer is going to spread throughout the browser codebase, even in areas
> which currently have no knowledge of canvas, in order to handle all the
> special cases.  This may just be an implementation detail (and may be
> avoidable, this is TBD), but it does have the potential to introduce
> dependencies or complicate implementation.
>

Maybe.

Maybe I'm missing something, but if we're going down the automatic road,
> why do we need a new function/attribute?  Why not simply detect when a
> canvas-sized fillRect() has been performed with an opaque fillStyle?  This
> would also allow optimization of existing content.


I agree.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]


From faulkner.steve at gmail.com  Sat Feb 23 05:41:22 2013
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Sat, 23 Feb 2013 13:41:22 +0000
Subject: [whatwg] Main element - Rationale? use cases? and data?
Message-ID: <72D15240-63D1-47D7-9F3D-F415B4BF4EC6@gmail.com>

Is there any rationale, uses cases or data available that supports the current definition of the <main> element in the WHATWG spec? In particular the author conformance requirements and advice.

I looked around but couldn't find any. 

Regards 

SteveF

From annevk at annevk.nl  Sun Feb 24 10:32:56 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Sun, 24 Feb 2013 18:32:56 +0000
Subject: [whatwg] Fetch: cross-origin redirect to a data URL
Message-ID: <CADnb78hZqcvdazTLzTAFGWZUHviucnZ4O648vk7eT0nO2Fz7SA@mail.gmail.com>

Say <img> does a cross-origin request. The response to that request is
a redirect with the appropriate CORS headers set. The new location is
a data URL. Should that URL be tainted or not? I tend to think we
should make that work.

(By the way, if you're interested. I'm working on a new specification
that merges HTML fetch and CORS, named Fetch.
http://wiki.whatwg.org/wiki/Fetch has the rough outline so far,
including an algorithm at the bottom. The idea is that everything in
the platform that does network requests ties into that (in particular
the fetch function which dispatches as appropriate).)


-- 
http://annevankesteren.nl/


From w3c at adambarth.com  Sun Feb 24 20:30:30 2013
From: w3c at adambarth.com (Adam Barth)
Date: Sun, 24 Feb 2013 20:30:30 -0800
Subject: [whatwg] Fetch: cross-origin redirect to a data URL
In-Reply-To: <CADnb78hZqcvdazTLzTAFGWZUHviucnZ4O648vk7eT0nO2Fz7SA@mail.gmail.com>
References: <CADnb78hZqcvdazTLzTAFGWZUHviucnZ4O648vk7eT0nO2Fz7SA@mail.gmail.com>
Message-ID: <CAJE5ia-tNs1_VOcCLqHbkDuFUH3kWbiBgTh-_6O_acfZwS1wcg@mail.gmail.com>

I don't think there is a security problem with that.  It's just a
question of how much it complicates the model.

Adam


On Sun, Feb 24, 2013 at 10:32 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> Say <img> does a cross-origin request. The response to that request is
> a redirect with the appropriate CORS headers set. The new location is
> a data URL. Should that URL be tainted or not? I tend to think we
> should make that work.
>
> (By the way, if you're interested. I'm working on a new specification
> that merges HTML fetch and CORS, named Fetch.
> http://wiki.whatwg.org/wiki/Fetch has the rough outline so far,
> including an algorithm at the bottom. The idea is that everything in
> the platform that does network requests ties into that (in particular
> the fetch function which dispatches as appropriate).)
>
>
> --
> http://annevankesteren.nl/


From bruant.d at gmail.com  Mon Feb 25 00:41:23 2013
From: bruant.d at gmail.com (David Bruant)
Date: Mon, 25 Feb 2013 09:41:23 +0100
Subject: [whatwg] Cross-origin iframe and @sandbox=allow-same-origin
Message-ID: <512B23B3.10203@gmail.com>

Hi,

The current description of the allow-same-origin sandbox token in the 
spec is:
" The allow-same-origin keyword allows the content to be treated as 
being from the same origin instead of forcing it into a unique origin;"

This is a very scary wording. Understood naively, I understand I could 
host a page in the "davidbruant.github.com" domain with an iframe to 
anywhere (pick your favorite social network/email client website), add 
@sandbox="allow-same-origin" and suddenly, I'd be able to look at the 
content (since the iframe would be treated as being from the same origin).

Obviously, that's not how it works (I say "obviously", because browser 
vendors would have not implemented what I just described. If they had, 
the world might have collapsed quickly).
 From what I've tested both in Firefox and Chrome, when I have an iframe 
from a different domain, I can get the contentDocument, but it looks 
like about:blank from what I can observe in the container. Where is this 
behavior described?


Also, in some notes [1], I can read:
"Second, [allow-same-origin] can be used to embed content from a 
third-party site, sandboxed to prevent that site from opening pop-up 
windows, etc, without preventing the embedded page from communicating 
back to its originating site, using the database APIs to store data, etc."

I fail to understand what is specific about allow-same-origin that 
allows that without adding also allow-scripts or allow-forms.


As a more general question: does iframe at sandbox="allow-same-origin" make 
a page and a cross-origin iframe further connected than they are 
currently without the keyword?

Thanks,

David

[1] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#attr-iframe-sandbox-allow-same-origin


From annevk at annevk.nl  Mon Feb 25 01:49:29 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Mon, 25 Feb 2013 09:49:29 +0000
Subject: [whatwg] Fetch: cross-origin redirect to a data URL
In-Reply-To: <CAJE5ia-tNs1_VOcCLqHbkDuFUH3kWbiBgTh-_6O_acfZwS1wcg@mail.gmail.com>
References: <CADnb78hZqcvdazTLzTAFGWZUHviucnZ4O648vk7eT0nO2Fz7SA@mail.gmail.com>
	<CAJE5ia-tNs1_VOcCLqHbkDuFUH3kWbiBgTh-_6O_acfZwS1wcg@mail.gmail.com>
Message-ID: <CADnb78iXvHc_t=SykfR-rU9cwEsuMq7ZrAFJ77TvUq71yb24ig@mail.gmail.com>

On Mon, Feb 25, 2013 at 4:30 AM, Adam Barth <w3c at adambarth.com> wrote:
> I don't think there is a security problem with that.  It's just a
> question of how much it complicates the model.

Well currently for http://software.hixie.ch/utilities/cgi/data/data
Chrome generates a network error if you hit "Generate" with the reason
"unsafe redirect". And that's a simple http to data URL redirect
without CORS coming into play.


-- 
http://annevankesteren.nl/


From jmajnert at gmail.com  Mon Feb 25 02:13:36 2013
From: jmajnert at gmail.com (Janusz Majnert)
Date: Mon, 25 Feb 2013 11:13:36 +0100
Subject: [whatwg] Cross-origin iframe and @sandbox=allow-same-origin
In-Reply-To: <512B23B3.10203@gmail.com>
References: <512B23B3.10203@gmail.com>
Message-ID: <CAOeF0ew9PWtTgE-HHMKax7aYvG19o9SAwuwapXyVYTqQq3jibA@mail.gmail.com>

Hi,
>From what I understand, it goes like this:
Using the sandboxing flag on an iframe causes several fine-grained
flags to be set (point 3 of the algorithm). One of the flags -
"sandboxed origin browsing context flag"[1] forces the document into
unique origin and blocks access to document.cookie and localStorage.
This flag is set unless "allow-same-origin" is used.

So in effect, using "allow-same-origin" on an iframe containing
third-party site will sandbox it but will still allow it to use its
own document.cookie and localStorage, without giving any access to
parent browsing context. The other fine-grained sandboxing flags will
block it. In the example you gave, the "sandboxed navigation browsing
context flag"[2] would kick in and prevent this behaviour.


Regards,
Janusz Majnert


[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#sandboxed-origin-browsing-context-flag
[2] http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#sandboxed-navigation-browsing-context-flag



2013/2/25 David Bruant <bruant.d at gmail.com>:
> Hi,
>
> The current description of the allow-same-origin sandbox token in the spec
> is:
> " The allow-same-origin keyword allows the content to be treated as being
> from the same origin instead of forcing it into a unique origin;"
>
> This is a very scary wording. Understood naively, I understand I could host
> a page in the "davidbruant.github.com" domain with an iframe to anywhere
> (pick your favorite social network/email client website), add
> @sandbox="allow-same-origin" and suddenly, I'd be able to look at the
> content (since the iframe would be treated as being from the same origin).
>
> Obviously, that's not how it works (I say "obviously", because browser
> vendors would have not implemented what I just described. If they had, the
> world might have collapsed quickly).
> From what I've tested both in Firefox and Chrome, when I have an iframe from
> a different domain, I can get the contentDocument, but it looks like
> about:blank from what I can observe in the container. Where is this behavior
> described?
>
>
> Also, in some notes [1], I can read:
> "Second, [allow-same-origin] can be used to embed content from a third-party
> site, sandboxed to prevent that site from opening pop-up windows, etc,
> without preventing the embedded page from communicating back to its
> originating site, using the database APIs to store data, etc."
>
> I fail to understand what is specific about allow-same-origin that allows
> that without adding also allow-scripts or allow-forms.
>
>
> As a more general question: does iframe at sandbox="allow-same-origin" make a
> page and a cross-origin iframe further connected than they are currently
> without the keyword?
>
> Thanks,
>
> David
>
> [1]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#attr-iframe-sandbox-allow-same-origin


From ian at hixie.ch  Mon Feb 25 10:10:32 2013
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 25 Feb 2013 18:10:32 +0000 (UTC)
Subject: [whatwg] Cross-origin iframe and @sandbox=allow-same-origin
In-Reply-To: <512B23B3.10203@gmail.com>
References: <512B23B3.10203@gmail.com>
Message-ID: <Pine.LNX.4.64.1302251805110.15713@ps20323.dreamhostps.com>

On Mon, 25 Feb 2013, David Bruant wrote:
> 
> The current description of the allow-same-origin sandbox token in the 
> spec is: " The allow-same-origin keyword allows the content to be 
> treated as being from the same origin instead of forcing it into a 
> unique origin;"
> 
> This is a very scary wording.

True. Note though that it's non-normative, so it doesn't affect 
implementors at all. (There's no "MUST" requirement and no "IS" 
definition, so it's just describing what's going on, not requiring 
anything or defining anything.)

I've made the wording less scary though.


> Also, in some notes [1], I can read:
> "Second, [allow-same-origin] can be used to embed content from a third-party
> site, sandboxed to prevent that site from opening pop-up windows, etc, without
> preventing the embedded page from communicating back to its originating site,
> using the database APIs to store data, etc."
> 
> I fail to understand what is specific about allow-same-origin that 
> allows that without adding also allow-scripts or allow-forms.

If you don't have allow-same-origin, the content ends up in a unique 
origin, not its "real" origin.


> As a more general question: does iframe at sandbox="allow-same-origin" make a
> page and a cross-origin iframe further connected than they are currently
> without the keyword?

The only difference is that without the keyword, the content is in a 
unique origin, and with it, its origin is left as normal.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From bruant.d at gmail.com  Mon Feb 25 10:26:28 2013
From: bruant.d at gmail.com (David Bruant)
Date: Mon, 25 Feb 2013 19:26:28 +0100
Subject: [whatwg] Cross-origin iframe and @sandbox=allow-same-origin
In-Reply-To: <Pine.LNX.4.64.1302251805110.15713@ps20323.dreamhostps.com>
References: <512B23B3.10203@gmail.com>
	<Pine.LNX.4.64.1302251805110.15713@ps20323.dreamhostps.com>
Message-ID: <512BACD4.9020907@gmail.com>

Le 25/02/2013 19:10, Ian Hickson a ?crit :
> On Mon, 25 Feb 2013, David Bruant wrote:
>> As a more general question: does iframe at sandbox="allow-same-origin" make a
>> page and a cross-origin iframe further connected than they are currently
>> without the keyword?
> The only difference is that without the keyword, the content is in a
> unique origin, and with it, its origin is left as normal.
Oh ok. "same origin" means "the content keeps the same (its own) 
origin". I had originally understood "the parent and iframe behave as if 
they were from the same origin", hence my confusion.

Everything makes a lot more sense now.

Thanks,

David


From w3c at adambarth.com  Mon Feb 25 12:00:21 2013
From: w3c at adambarth.com (Adam Barth)
Date: Mon, 25 Feb 2013 12:00:21 -0800
Subject: [whatwg] Fetch: cross-origin redirect to a data URL
In-Reply-To: <CADnb78iXvHc_t=SykfR-rU9cwEsuMq7ZrAFJ77TvUq71yb24ig@mail.gmail.com>
References: <CADnb78hZqcvdazTLzTAFGWZUHviucnZ4O648vk7eT0nO2Fz7SA@mail.gmail.com>
	<CAJE5ia-tNs1_VOcCLqHbkDuFUH3kWbiBgTh-_6O_acfZwS1wcg@mail.gmail.com>
	<CADnb78iXvHc_t=SykfR-rU9cwEsuMq7ZrAFJ77TvUq71yb24ig@mail.gmail.com>
Message-ID: <CAJE5ia9xRQDCCVc8ZPV-JjKR+=jtrOt9F+a8ud5=_z5dj1LuRA@mail.gmail.com>

On Mon, Feb 25, 2013 at 1:49 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Mon, Feb 25, 2013 at 4:30 AM, Adam Barth <w3c at adambarth.com> wrote:
>> I don't think there is a security problem with that.  It's just a
>> question of how much it complicates the model.
>
> Well currently for http://software.hixie.ch/utilities/cgi/data/data
> Chrome generates a network error if you hit "Generate" with the reason
> "unsafe redirect". And that's a simple http to data URL redirect
> without CORS coming into play.

Yes, that's to defend against a different sort of attack.  In some
browsers, like Firefox, data URLs inherit the security context of
their authors.  If a web site as an open redirect, an attacker might
be able to trick the site into redirecting to a data URL of the
attackers choice and thereby XSS the site.

Chrome wouldn't be vulnerable to that attack because Chrome runs data
URLs in unique origins, but Chrome blocks those sorts of redirects so
that web sites don't use them and don't cause trouble for Firefox.

Adam


From bzbarsky at MIT.EDU  Mon Feb 25 12:06:36 2013
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 25 Feb 2013 15:06:36 -0500
Subject: [whatwg] Fetch: cross-origin redirect to a data URL
In-Reply-To: <CAJE5ia9xRQDCCVc8ZPV-JjKR+=jtrOt9F+a8ud5=_z5dj1LuRA@mail.gmail.com>
References: <CADnb78hZqcvdazTLzTAFGWZUHviucnZ4O648vk7eT0nO2Fz7SA@mail.gmail.com>
	<CAJE5ia-tNs1_VOcCLqHbkDuFUH3kWbiBgTh-_6O_acfZwS1wcg@mail.gmail.com>
	<CADnb78iXvHc_t=SykfR-rU9cwEsuMq7ZrAFJ77TvUq71yb24ig@mail.gmail.com>
	<CAJE5ia9xRQDCCVc8ZPV-JjKR+=jtrOt9F+a8ud5=_z5dj1LuRA@mail.gmail.com>
Message-ID: <512BC44C.3000408@mit.edu>

On 2/25/13 3:00 PM, Adam Barth wrote:
> Yes, that's to defend against a different sort of attack.  In some
> browsers, like Firefox, data URLs inherit the security context of
> their authors.

This is not the case for data: URLs that are the target of a redirect, 
for what it's worth.  At least in Firefox, last I checked.

The only argument I've seen for Chrome's behavior is in 
https://bugzilla.mozilla.org/show_bug.cgi?id=786275

-Boris



From annevk at annevk.nl  Tue Feb 26 03:35:35 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Tue, 26 Feb 2013 11:35:35 +0000
Subject: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest
Message-ID: <CADnb78hXku4Ay5qJ1sJoLbA42jmUHBBFLt4=MbHytVXMMS21ng@mail.gmail.com>

There's an unfortunate mismatch currently. new
XMLHttpRequest({anon:true}) will generate a request where a) origin is
a globally unique identifier b) referrer source is the URL
about:blank, and c) credentials are omitted. From those
crossorigin="anonymous" only does c. Can we still change
crossorigin="anonymous" to match the anonymous flag semantics of
XMLHttpRequest or is it too late?


-- 
http://annevankesteren.nl/


From cabanier at gmail.com  Tue Feb 26 09:03:13 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Tue, 26 Feb 2013 09:03:13 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAPeKFTjrqXppBaG4HjDkWocPdsjhuPaMtUs91byzwMg8xhfa0Q@mail.gmail.com>
	<CAGN7qDDmtzWVJ928ZoRZOf0uFgpFCHUaSQTiaSOvAyR2Y-ipPA@mail.gmail.com>
	<CAPeKFTjGneJm7CqcPsXNcdC4LjXOoHipACPg7nafgqSuxtazVQ@mail.gmail.com>
	<CAGN7qDBok6prgE3iKGU53+nXzm9C-Yg75uUtuG009793MS7pXA@mail.gmail.com>
	<CAPeKFTjSEfvMFR7N-61qV19baBFToUwneYJ-7KfcToE4u+cqPA@mail.gmail.com>
	<CAGN7qDAOEZnOdzSpd3ZDFUsnK8Y=5sDsfmV5eiVdV73oYeys+A@mail.gmail.com>
	<CAPeKFTie+gA116b+Q3XP7fkFeRWC1XQsNF_1qPyBF29xNSMmgQ@mail.gmail.com>
	<CAGN7qDBiKL8fYd2jpGo7zm7gE8nzNqjworj=ctt5TV5bg1t4hw@mail.gmail.com>
	<CAOp6jLY1EyaXz=SVTomoUb0e2HJ5fNGVbfH8rOtqfhjSUFasKw@mail.gmail.com>
	<CAGN7qDADm6JjQ56SEGVOjfD=Z4W_gpf7tgb4yNBq_av-f_gQKA@mail.gmail.com>
	<CAOp6jLZtqW3zoeVNe+agB3wgL4wj7hbZLYLDXWEeDKnrtkB7ig@mail.gmail.com>
	<CAGN7qDDZEcd4+sZKiF8Tc15ABq+Lwp-M7Uao2nNHEF=Q9mT-Vg@mail.gmail.com>
	<CAOp6jLYtNT1-jtUu8AMLoMXevcPPpTWgk+CXZ8iTO9fODBS+Fg@mail.gmail.com>
	<CAPeKFTihWYcn8cF3D-EGzyUksJLfrjDSZfDPfm47PNygMj195Q@mail.gmail.com>
	<CAOp6jLaeP6jqhZ_Dkk-eZ5n2n4bs_yFiW98dztNmqVf-V4HqvQ@mail.gmail.com>
	<CAPeKFTibgdnd6h1-SM_yb4AQrwmNoXW9dDHroTGNuSiW0cYJ2g@mail.gmail.com>
	<CAOp6jLYLcPML31FpdCo9vyNvxEuVwxGNwx4RdOrhp5sv9-F__A@mail.gmail.com>
	<CAPeKFThH2RU0VDzvLsF45Sy6-tFFszsHD29osCKzjm78KS5YTQ@mail.gmail.com>
	<CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
Message-ID: <CAGN7qDDh_+NZN+gsZb_CeBTcHkO6SineL5mq_DrJDRHnzd+ACg@mail.gmail.com>

FYI
http://www.istartedsomething.com/20120303/cleartype-takes-a-back-seat-for-windows-8-metro/
IE 10 removed subpixel positioning and just use regular AA.

On Thu, Feb 21, 2013 at 11:12 AM, Stephen White <senorblanco at chromium.org>wrote:

> On Tue, Feb 19, 2013 at 11:31 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> So now we have:
>> - don't do this on pinch-zoom devices
>> - don't do this for HW accelerated canvases
>> - don't do this if the canvas dpi doesn't match the screen
>>
> - don't do this if there are transforms
>> - authors will have to be very careful when using this feature since it
>> can turn on or off or cause rendering glitches.
>>
>> Is it still worth pursuing this?
>>
>
> I believe it is.  Even with those constraints, there are a large number of
> applications which can benefit from text which looks as good as the native
> platform can provide.
>
> That said, I also think Robert is right that we should not spec out
> precisely when subpixel AA text will occur in any of these automatic modes,
> since:
>
> 1)  there are some platforms/devices which don't do LCD text at all
> 2)  It may be too restrictive for the browser implementor, e.g., they may
> be essentially required to implement deferred rendering or two backing
> stores in order to meet the resulting spec, which seems onerous
>
> Subpixel AA text aside, I still think it's worth spec'ing out mozOpaque,
> if only just for the optimization opportunities that we don't get with an
> automatic solution (e.g., putImageData).  Its implementation is fairly
> straightforward (much more so than the other options above), and it won't
> break any existing content.
>
> To me, the "it breaks compositing" argument falls into the "doctor, it
> hurts when I do this" category:  the user is specifically opting into an
> opaque backing store, and so the changes in behaviour for compositing modes
> which reference destination alpha are expected, just as they are when using
> DST_ALPHA blending modes in a WebGL context created with the "alpha"
> attribute set to false.
>
> Stephen
>
>
>>
>> On Tue, Feb 19, 2013 at 3:40 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>
>>> On Tue, Feb 19, 2013 at 5:19 PM, Stephen White <senorblanco at chromium.org
>>> > wrote:
>>>
>>>> Even with text on an opaque background, I think you still have to worry
>>>> about the case of transformed canvases.  E.g., text drawn over an opaque
>>>> background into a single still frame canvas, but then subsequently rotated
>>>> via CSS transforms from 0 degrees through non-0.  The first frame can use
>>>> subpixel AA, but then subsequent frames can't.  So I think you need to keep
>>>> the command stream around (first case) or
>>>> always render two buffers as soon as you draw text.  That seems like a
>>>> pretty heavy burden.
>>>>
>>>> For canvas->WebGL the problem becomes pretty much intractable, since
>>>> there's no way to know what a given shader will do to the pixels.  So I
>>>> think you'd always have to give up and do grayscale AA in that case.
>>>>
>>>
>>> Yes, you're quite right.
>>>
>>>
>>> Rob
>>> --
>>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, ?Lbh xabj gung gur ehyref bs gur
>>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>>> ? whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>>> tvir uvf yvsr nf n enafbz sbe znal.? [Znggurj 20:25-28]
>>>
>>
>>
>


From derhoermi at gmx.net  Tue Feb 26 10:11:04 2013
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue, 26 Feb 2013 19:11:04 +0100
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAGN7qDDh_+NZN+gsZb_CeBTcHkO6SineL5mq_DrJDRHnzd+ACg@mail.gmail.com>
References: <CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
	<CAGN7qDDh_+NZN+gsZb_CeBTcHkO6SineL5mq_DrJDRHnzd+ACg@mail.gmail.com>
Message-ID: <g8upi89vgal65681n58dtpm0iv4uodks88@hive.bjoern.hoehrmann.de>

* Rik Cabanier wrote:
>FYI
>http://www.istartedsomething.com/20120303/cleartype-takes-a-back-seat-for-windows-8-metro/
>IE 10 removed subpixel positioning and just use regular AA.

The article seems to be about Windows 8 and neither it nor the comments
seem to discuss Internet Explorer 10 on Windows 7. Are you sure this is
a property of Internet Explorer 10 regardless of the Windows version,
and given that the article is a year old, that this is still current?
-- 
Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de
25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 


From cabanier at gmail.com  Tue Feb 26 12:48:26 2013
From: cabanier at gmail.com (Rik Cabanier)
Date: Tue, 26 Feb 2013 12:48:26 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <g8upi89vgal65681n58dtpm0iv4uodks88@hive.bjoern.hoehrmann.de>
References: <CAOp6jLYqPnF3umH_H9mEfC6XQ2amhSTLaeTGTU+QpPA9q_gr1w@mail.gmail.com>
	<CAPeKFThbsu7uY2ymz1HHOGnnf1y2+=ovkNeCnoqsxhydLx_ovg@mail.gmail.com>
	<CAOp6jLa=yX3ao7WO1Q+sscDrW5ya346XNoiHrygkN7TSR9CoBw@mail.gmail.com>
	<CAGN7qDDFDSN4rBL5Xm7a53xhbrRLfXhYWpz_axo+93ysKBXcng@mail.gmail.com>
	<CAPeKFTjEef6+M0KoJaBu6Zx2OP=QAPqOxv42nLswbwkHCxNqxA@mail.gmail.com>
	<CAGN7qDDh_+NZN+gsZb_CeBTcHkO6SineL5mq_DrJDRHnzd+ACg@mail.gmail.com>
	<g8upi89vgal65681n58dtpm0iv4uodks88@hive.bjoern.hoehrmann.de>
Message-ID: <CAGN7qDDtf5gTsj+HWt2FcYVHLzWb+rq-m_k_hUSr6t=BW-2xVg@mail.gmail.com>

I experimented a bit and t is still active on Windows 7.

On Tue, Feb 26, 2013 at 10:11 AM, Bjoern Hoehrmann <derhoermi at gmx.net>wrote:

> * Rik Cabanier wrote:
> >FYI
> >
> http://www.istartedsomething.com/20120303/cleartype-takes-a-back-seat-for-windows-8-metro/
> >IE 10 removed subpixel positioning and just use regular AA.
>
> The article seems to be about Windows 8 and neither it nor the comments
> seem to discuss Internet Explorer 10 on Windows 7. Are you sure this is
> a property of Internet Explorer 10 regardless of the Windows version,
> and given that the article is a year old, that this is still current?
> --
> Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
> Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de
> 25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/
>


From w3c at adambarth.com  Tue Feb 26 14:52:28 2013
From: w3c at adambarth.com (Adam Barth)
Date: Tue, 26 Feb 2013 14:52:28 -0800
Subject: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest
In-Reply-To: <CADnb78hXku4Ay5qJ1sJoLbA42jmUHBBFLt4=MbHytVXMMS21ng@mail.gmail.com>
References: <CADnb78hXku4Ay5qJ1sJoLbA42jmUHBBFLt4=MbHytVXMMS21ng@mail.gmail.com>
Message-ID: <CAJE5ia9_=cQsL5PP+r2Aq4-5gcjvs77Z+=ZLL4cbCNOgHsJ8ew@mail.gmail.com>

WebKit hasn't implemented either, so we don't have any implementation
constraints in this area.

Adam


On Tue, Feb 26, 2013 at 3:35 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> There's an unfortunate mismatch currently. new
> XMLHttpRequest({anon:true}) will generate a request where a) origin is
> a globally unique identifier b) referrer source is the URL
> about:blank, and c) credentials are omitted. From those
> crossorigin="anonymous" only does c. Can we still change
> crossorigin="anonymous" to match the anonymous flag semantics of
> XMLHttpRequest or is it too late?
>
>
> --
> http://annevankesteren.nl/


From kbr at google.com  Tue Feb 26 16:02:05 2013
From: kbr at google.com (Kenneth Russell)
Date: Tue, 26 Feb 2013 16:02:05 -0800
Subject: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest
In-Reply-To: <CAJE5ia9_=cQsL5PP+r2Aq4-5gcjvs77Z+=ZLL4cbCNOgHsJ8ew@mail.gmail.com>
References: <CADnb78hXku4Ay5qJ1sJoLbA42jmUHBBFLt4=MbHytVXMMS21ng@mail.gmail.com>
	<CAJE5ia9_=cQsL5PP+r2Aq4-5gcjvs77Z+=ZLL4cbCNOgHsJ8ew@mail.gmail.com>
Message-ID: <CAMYvS2c_54Lq_nLwDKnkLWnPoRFxaQ2LvKE8i_Q=Zi6PLwdCjQ@mail.gmail.com>

Are you referring to the crossOrigin attribute on HTMLImageElement and
HTMLMediaElement? Those are implemented in WebKit. It should be fine
to change crossOrigin="anonymous" requests to satisfy (a) and (b). Any
server that satisfies these anonymous requests in a way compatible
with UAs' caching will ignore the incoming origin and the referrer.

-Ken


On Tue, Feb 26, 2013 at 2:52 PM, Adam Barth <w3c at adambarth.com> wrote:
> WebKit hasn't implemented either, so we don't have any implementation
> constraints in this area.
>
> Adam
>
>
> On Tue, Feb 26, 2013 at 3:35 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
>> There's an unfortunate mismatch currently. new
>> XMLHttpRequest({anon:true}) will generate a request where a) origin is
>> a globally unique identifier b) referrer source is the URL
>> about:blank, and c) credentials are omitted. From those
>> crossorigin="anonymous" only does c. Can we still change
>> crossorigin="anonymous" to match the anonymous flag semantics of
>> XMLHttpRequest or is it too late?
>>
>>
>> --
>> http://annevankesteren.nl/


From w3c at adambarth.com  Tue Feb 26 16:10:34 2013
From: w3c at adambarth.com (Adam Barth)
Date: Tue, 26 Feb 2013 16:10:34 -0800
Subject: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest
In-Reply-To: <CAMYvS2c_54Lq_nLwDKnkLWnPoRFxaQ2LvKE8i_Q=Zi6PLwdCjQ@mail.gmail.com>
References: <CADnb78hXku4Ay5qJ1sJoLbA42jmUHBBFLt4=MbHytVXMMS21ng@mail.gmail.com>
	<CAJE5ia9_=cQsL5PP+r2Aq4-5gcjvs77Z+=ZLL4cbCNOgHsJ8ew@mail.gmail.com>
	<CAMYvS2c_54Lq_nLwDKnkLWnPoRFxaQ2LvKE8i_Q=Zi6PLwdCjQ@mail.gmail.com>
Message-ID: <CAJE5ia-n=s1ccBpJR++Yb7OaA=9+AbDDH+O9ho+92ThU8bvnGQ@mail.gmail.com>

Ah, my mistake.  Kenneth is right.  I didn't realize you were talking
about the crossorigin attributes.

Adam


On Tue, Feb 26, 2013 at 4:02 PM, Kenneth Russell <kbr at google.com> wrote:
> Are you referring to the crossOrigin attribute on HTMLImageElement and
> HTMLMediaElement? Those are implemented in WebKit. It should be fine
> to change crossOrigin="anonymous" requests to satisfy (a) and (b). Any
> server that satisfies these anonymous requests in a way compatible
> with UAs' caching will ignore the incoming origin and the referrer.
>
> -Ken
>
>
> On Tue, Feb 26, 2013 at 2:52 PM, Adam Barth <w3c at adambarth.com> wrote:
>> WebKit hasn't implemented either, so we don't have any implementation
>> constraints in this area.
>>
>> Adam
>>
>>
>> On Tue, Feb 26, 2013 at 3:35 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
>>> There's an unfortunate mismatch currently. new
>>> XMLHttpRequest({anon:true}) will generate a request where a) origin is
>>> a globally unique identifier b) referrer source is the URL
>>> about:blank, and c) credentials are omitted. From those
>>> crossorigin="anonymous" only does c. Can we still change
>>> crossorigin="anonymous" to match the anonymous flag semantics of
>>> XMLHttpRequest or is it too late?
>>>
>>>
>>> --
>>> http://annevankesteren.nl/


From adamk at chromium.org  Wed Feb 27 12:39:04 2013
From: adamk at chromium.org (Adam Klein)
Date: Wed, 27 Feb 2013 12:39:04 -0800
Subject: [whatwg] HTML parsing, the stack of open elements,
	and foreign content
Message-ID: <CAEvLGcLVj+KfQ04kOCysdMBYL5fdMh2xJ7-qcLFdrsbsshnkfQ@mail.gmail.com>

Consider the following script:

tr = document.createElement('tr')
tr.innerHTML = '<math><tr><mo><td>';

That is, the fragment is parsed with tr as the context element. What
should the generated DOM be? Note that <mo> is a "MathML text
integration point", which causes the <td> to be processed not as
foreign content but as a normal HTML token. This leads to the
following DOM in WebKit:

<tr>
    <math math>
        <math tr>
            <math mo>
    <td>

(the "math" prefixes denote that these are elements with the MathML
namespace.) In Gecko, I instead get:

<tr>
    <math math>
        <math tr>
            <math mo>
            <td>

Note that the <td> in both cases is an HTML element, even though in
Gecko it's in a MathML tree.

The spec for what should happen to that <td> is the first step of
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-intr

This case clearly seems like a bug in Gecko: it's treating the <math
tr> as if it's an HTML <tr>. That is, it's comparing only the local
name (or "tag name" as the spec usually refers to it).

But this same ambiguity exists elsewhere in the spec. For example, the
very next item under "in row" says "If the stack of open elements does
not have an element in table scope with the same tag name as the
token" (in this case, it's looking for a <tr>).

I think the HTML parser ought to specify more precisely how to deal
with namespaces in the stack of open elements, given that that stack
can contain elements of varying namespaces.

- Adam


From annevk at annevk.nl  Thu Feb 28 08:33:57 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Thu, 28 Feb 2013 16:33:57 +0000
Subject: [whatwg] Fetch: cross-origin redirect to a data URL
In-Reply-To: <512BC44C.3000408@mit.edu>
References: <CADnb78hZqcvdazTLzTAFGWZUHviucnZ4O648vk7eT0nO2Fz7SA@mail.gmail.com>
	<CAJE5ia-tNs1_VOcCLqHbkDuFUH3kWbiBgTh-_6O_acfZwS1wcg@mail.gmail.com>
	<CADnb78iXvHc_t=SykfR-rU9cwEsuMq7ZrAFJ77TvUq71yb24ig@mail.gmail.com>
	<CAJE5ia9xRQDCCVc8ZPV-JjKR+=jtrOt9F+a8ud5=_z5dj1LuRA@mail.gmail.com>
	<512BC44C.3000408@mit.edu>
Message-ID: <CADnb78jhON72NBksHNxncAxVwtCmD0Ojp-eVqOoXeBMUJHWb=w@mail.gmail.com>

On Mon, Feb 25, 2013 at 8:06 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 2/25/13 3:00 PM, Adam Barth wrote:
>> Yes, that's to defend against a different sort of attack.  In some
>> browsers, like Firefox, data URLs inherit the security context of
>> their authors.
>
> This is not the case for data: URLs that are the target of a redirect, for
> what it's worth.  At least in Firefox, last I checked.

Does it matter if it's a same-origin redirect though? It seems then it
should be okay (given there's no cross-origin URL in the redirect
chain).


> The only argument I've seen for Chrome's behavior is in
> https://bugzilla.mozilla.org/show_bug.cgi?id=786275

That seems to argue for even stricter rules. Basically stopping
navigation to data URLs.


-- 
http://annevankesteren.nl/


From annevk at annevk.nl  Thu Feb 28 10:54:36 2013
From: annevk at annevk.nl (Anne van Kesteren)
Date: Thu, 28 Feb 2013 18:54:36 +0000
Subject: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest
In-Reply-To: <CAMYvS2c_54Lq_nLwDKnkLWnPoRFxaQ2LvKE8i_Q=Zi6PLwdCjQ@mail.gmail.com>
References: <CADnb78hXku4Ay5qJ1sJoLbA42jmUHBBFLt4=MbHytVXMMS21ng@mail.gmail.com>
	<CAJE5ia9_=cQsL5PP+r2Aq4-5gcjvs77Z+=ZLL4cbCNOgHsJ8ew@mail.gmail.com>
	<CAMYvS2c_54Lq_nLwDKnkLWnPoRFxaQ2LvKE8i_Q=Zi6PLwdCjQ@mail.gmail.com>
Message-ID: <CADnb78gxQn8a_La6rQYVWTd59-vpyYNBW3U=omHufMyRxEGQHQ@mail.gmail.com>

On Wed, Feb 27, 2013 at 12:02 AM, Kenneth Russell <kbr at google.com> wrote:
> Are you referring to the crossOrigin attribute on HTMLImageElement and
> HTMLMediaElement? Those are implemented in WebKit. It should be fine
> to change crossOrigin="anonymous" requests to satisfy (a) and (b). Any
> server that satisfies these anonymous requests in a way compatible
> with UAs' caching will ignore the incoming origin and the referrer.

Cool, hopefully we can make that change then. That would at least keep
the naming and semantics somewhat consistent.


-- 
http://annevankesteren.nl/