On Dec 4, 2013, at 11:01 AM, Ian Hickson wrote:
> On Tue, 3 Dec 2013, Ryosuke Niwa wrote:
>> On Dec 3, 2013, at 3:51 PM, Ian Hickson wrote:
>>> On Tue, 3 Dec 2013, Ryosuke Niwa wrote:
On Dec 3, 2013, at 10:42 AM, Adam Barth
wrote:
Do we really need a stack? Can't we set th
On Wed, Dec 4, 2013 at 11:32 AM, Jürg Lehni wrote:
>
> On Nov 29, 2013, at 06:03 , Rik Cabanier wrote:
>
> > I agree it's not the most useful API but it will be helpful. From one of
> the previous message:
> > It would be a very fast way to set a cached path in the graphics state
> > and:
>
> In
On Wed, Dec 4, 2013 at 11:10 AM, Jürg Lehni wrote:
> I somehow managed to oversee all the things that happened in this
> discussion, but I'm very happy to see that Path2D is being proposed and
> agreed on now. It's also what I've originally suggested on April 10 this
> year, and I completely agre
On Wed, 4 Dec 2013, Dimitri Glazkov wrote:
>
> The gist of the argument was that we should let UAs decide how they want
> to design controls and avoid limiting their options by standardizing
> behavior of pseudo-elements.
I'm not suggesting that we define the actual bindings. Just that we
desc
On Nov 29, 2013, at 06:03 , Rik Cabanier wrote:
> I agree it's not the most useful API but it will be helpful. From one of the
> previous message:
> It would be a very fast way to set a cached path in the graphics state
> and:
In the case of Paper.js, this optimization was not possible precise
This discussion seems to have stalled.
Implementing this would help us greatly to optimize aspects of Paper.js, as
double buffering into separate canvases is very slow and costly. Is this still
on the map?
There appears to be a library that emulates this functionality, using the same
approach
I
On Wed, Dec 4, 2013 at 11:41 AM, Jürg Lehni wrote:
> This discussion seems to have stalled.
>
> Implementing this would help us greatly to optimize aspects of Paper.js,
> as double buffering into separate canvases is very slow and costly. Is this
> still on the map?
>
> There appears to be a
On Dec 4, 2013, at 20:10 , Jürg Lehni wrote:
> oversee
...and with "oversee" I meant "ignore". I't s a common German mistake.
I somehow managed to oversee all the things that happened in this discussion,
but I'm very happy to see that Path2D is being proposed and agreed on now. It's
also what I've originally suggested on April 10 this year, and I completely
agree that it leaves much less doubt about its functionality a
On Tue, 3 Dec 2013, Ryosuke Niwa wrote:
> On Dec 3, 2013, at 3:51 PM, Ian Hickson wrote:
> > On Tue, 3 Dec 2013, Ryosuke Niwa wrote:
> >> On Dec 3, 2013, at 10:42 AM, Adam Barth
> >> wrote:
> >>
> >> Do we really need a stack? Can't we set the form element pointer
> >> aside when we push the
On Wed, Dec 4, 2013 at 10:30 AM, Ian Hickson wrote:
> On Tue, 3 Dec 2013, Dimitri Glazkov wrote:
> > > >
> > > > Yeah, the idea is you'd bind to the scroll box to change the whole
> > > > scroll UI, but you could also then override specific pseudos of the
> > > > scroll box to style subparts of t
On Tue, 3 Dec 2013, Dimitri Glazkov wrote:
> > >
> > > Yeah, the idea is you'd bind to the scroll box to change the whole
> > > scroll UI, but you could also then override specific pseudos of the
> > > scroll box to style subparts of the default (or custom) scrollbox
> > > UI. This part was neve
On Tue, Dec 3, 2013 at 10:32 PM, Jonas Sicking wrote:
> On Dec 3, 2013 9:39 PM, "Dimitri Glazkov" wrote:
>
> >> Web components can't define pseudo elements. So no.
> >>
> >> This sadly also means that you can't write a CSS which styles the
> default
> >> UA UI if that is used, and styles an atta
Thanks to some feedback I got, I worked out the preloading algorithm in
some more detail.
It will enable efficient preloading of images in my srcalt proposal, as
well as images with the proposed postpone attribute, and improve overall
performance. The algorithm is meant to supersede the simple pr
> And Shadow-DOM doesn't let you style an existing control, just fully
> replace the rendering. So styling a textfield means doing a full
> editor with all the crappiness that contentEditable pulls in. Yes, a
> lot of the contentEditable stuff can and should be improved, so
> possibly this could be
15 matches
Mail list logo
