On 31 August 2013 00:04, Ryosuke Niwa rn...@apple.com wrote:
It'll be much harder to implement a new dependency API that replies on CSS
selectors if we care about the performance at all.
Where does the performance issue come from? It would only need to be
resolved once on node creation or
On Mon, Sep 2, 2013 at 2:04 PM, Nicholas Shanks cont...@nickshanks.com wrote:
Am I missing something? I assume you want to basically send a whole
bunch of files down the pipe when any one of them is requested, not
send the individual file's bytestream from a zip. If so, then why is
this not
On 9/3/13 2:27 PM, Ryosuke Niwa wrote:
From the fact selector matching is slow.
Hold on. Back up.
Selector matching can't be all that slow per se: browsers do it a
_lot_. Do you mean doing the equivalent of document.querySelectorAll
can be slow?
-Boris
On Thu, 30 May 2013, chris cargile wrote:
there seems to be a limitation that either registerProtocolHanlder()
takes GET requests but not POST requests
Since you are only ever sent a URL, this seems like the appropriate kind
of request, no?
On Thu, 30 May 2013, chris cargile wrote:
On Thu, 6 Jun 2013, Jonas Sicking wrote:
On Thu, Jun 6, 2013 at 2:08 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 15 Feb 2013, Jonas Sicking wrote:
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
On Sat, 8 Jun 2013, Jukka K. Korpela wrote:
2013-06-08 0:13, Ian Hickson wrote:
On Sun, 2 Jun 2013, Jukka K. Korpela wrote:
The purpose presented is to avoid markup generators from being
pressured into replacing the error of omitting the alt attribute
with the even more egregious
On Tue, 28 May 2013, Glenn Maynard wrote:
Jump to a code entry-point essentially maintains a stack of entry
scripts, to determine the outermost script in order to know whether to
run the global clean-up jobs. This assumes that this algorithm will
always be entered and exited as a stack:
Original proposal:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040664.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040666.html
In order to address use cases incDependencies and decDependencies satisfied,
I'm going to add the following proposals:
I
On Sep 3, 2013, at 3:45 AM, Jake Archibald jaffathec...@gmail.com wrote:
On 31 August 2013 00:04, Ryosuke Niwa rn...@apple.com wrote:
It'll be much harder to implement a new dependency API that replies on CSS
selectors if we care about the performance at all.
Where does the performance
On Wed, Sep 4, 2013 at 7:38 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 17 Jun 2013, Silvia Pfeiffer wrote:
On Thu, Jun 13, 2013 at 3:08 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 12 Jun 2013, Silvia Pfeiffer wrote:
As we continue to evolve the functionality of text tracks, we will
On Wed, 12 Jun 2013, Brendan Long wrote:
On 06/11/2013 11:11 PM, Silvia Pfeiffer wrote:
I suggest we rename WebVTTCue [1] to VTTCaptionCue and allow such cues
only on tracks of kind={caption, subtitle}.
Why VTTCaptionCue and not just HTMLCue? It seems like any cue that can
be
The long and short of this is that I renamed supportsContext() to
probablySupportsContext(). It's already implemented in WebKit (and dino
says he's going to rename it in the implementation also).
Fundamentally, it addresses a need that none of the other proposals
addressed: how to know
Per IRC discussion, I misunderstood the timing at which these at which
dependencies are executed. Now I agree it's desirable to have two values for
when needed as proposed by Ian in the original e-mail.
For other people following this thread's sake, a.js will execute immediately as
soon as
Hello folks. Sorry for the late response to several comments in this
mega-thread, I've mostly been traveling/vacationing for the past 2 months.
A teammate asked me to look at this in case I had comments. I don't know
web dev issues very well, so I'm going to restrain myself from offering
many
On 9/3/13 7:13 PM, Ian Hickson wrote:
Wouldn't checking for window.WebGLRenderingContext be just as unreliable
then? I don't understand why it's ok to be able to test that, but why
probablySupportsContext() wouldn't be ok.
I'm a lot more OK with the probablySupportsContext naming than
On Sep 3, 2013, at 5:01 PM, William Chan (陈智昌) willc...@chromium.org wrote:
Hello folks. Sorry for the late response to several comments in this
mega-thread, I've mostly been traveling/vacationing for the past 2 months.
A teammate asked me to look at this in case I had comments. I don't know
2013-09-04 0:09, Ian Hickson wrote:
To a user, even “(an image)” is better than lack of alt attribute
I disagree. The lack of an alt attribute can be used by user agents to
substitute the string (an image), in which case it is the same, or it
can be used to do far more, e.g. image
17 matches
Mail list logo
