On Mon, Jun 16, 2014 at 6:57 PM, Jussi Kalliokoski
wrote:
>
> var doesFetchSupportJson = function () {
> return fetch("data:application/json;base64,e30=").then(function
> (response) {
> return response.body.to("json");
> }).then(function () {
> return true;
> }).catch(f
On Wed, Jun 18, 2014 at 12:08 PM, Jonas Sicking wrote:
> On Mon, Jun 16, 2014 at 6:57 PM, Jussi Kalliokoski
> wrote:
> >
> > var doesFetchSupportJson = function () {
> > return fetch("data:application/json;base64,e30=").then(function
> > (response) {
> > return response.body.to("json
I just discovered
https://svgwg.org/svg2-draft/embedded.html
This looks very problematic. It ties SVG and HTML5 together in
uncomfortable ways. For example, SVGIframeElement as specced has two
"width" attributes. It's unclear how to keep this making sense as SVG and
HTML5 evolve, e.g. as new attrib
On 6/18/14, 8:59 AM, Robert O'Callahan wrote:
For example, SVGIframeElement as specced has two
"width" attributes.
Which actually means the IDL will fail to be parsed with a conforming
Web IDL parser.
"SVGIframeElement implements HTMLIFrameElement" creates a multiple
inheritance situation t
In the previous incarnation of High density canvases (i.e. getImageDataHD
and friends), we worked under the assumption that it was okay to have a
backing store with a pixel density that is higher than CSS pixel density.
And I think that was perfectly acceptable.
If I recall correctly, the feature
On Jun 18, 2014 6:00 AM, "Robert O'Callahan" wrote:
>
> I just discovered
> https://svgwg.org/svg2-draft/embedded.html
> This looks very problematic. It ties SVG and HTML5 together in
> uncomfortable ways. For example, SVGIframeElement as specced has two
> "width" attributes. It's unclear how to k
On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad wrote:
> I am currently trying an experimental approach where canvases that are
> drawn to, but never read from (no toDataURL or getImageData calls) have
> their contents stored as a command buffer, rather than a pixel buffer.
>
There must be a cli
On Wed, Jun 18, 2014 at 8:30 AM, Justin Novosad wrote:
> In the previous incarnation of High density canvases (i.e. getImageDataHD
> and friends), we worked under the assumption that it was okay to have a
> backing store with a pixel density that is higher than CSS pixel density.
> And I think th
On Thu, Jun 19, 2014 at 11:52 AM, Robert O'Callahan
wrote:
> On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad wrote:
>
>> I am currently trying an experimental approach where canvases that are
>> drawn to, but never read from (no toDataURL or getImageData calls) have
>> their contents stored as a
On 19/06/2014 00:30, Justin Novosad wrote:
> My main point is, there is potentially significant progress in terms
> of HD canvas rendering that can be achieved without any changes to the
> spec (other than perhaps an opt-in flag). If it works out well without
> an explicit opt-in, legacy websites w
10 matches
Mail list logo