On Mon, 21 Nov 2011 00:47:05 +0100, Mark Nottingham m...@mnot.net wrote:
For example, some browsers still (!) support blink, but that doesn't
mean we should promote its use.
FWIW, blink is defined as a feature in HTML5 browsers are expected to
implement.
--
Anne van Kesteren
On Mon, Nov 21, 2011 at 12:05 PM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 21 Nov 2011 00:47:05 +0100, Mark Nottingham m...@mnot.net wrote:
For example, some browsers still (!) support blink, but that doesn't
mean we should promote its use.
FWIW, blink is defined as a feature in
Great,
thanks for moving this forward.
Question: are we going to have also a wiki or will we re-use one of the
wiki from dap and/or web-apps?
I'm trying to flash out some thoughts around home discovery VS web intents
and a wiki is a simple tool to outline some ideas.
/g
On Fri, 18 Nov
On Wed, Nov 16, 2011 at 12:40 PM, Henri Sivonen hsivo...@iki.fi wrote:
* Making XHR not support HTML parsing in the synchronous mode.
In reference to the other thread about discouraging synchronous XHR
(outside Workers), this change ended up being made in Gecko. (HTML
parsing in XHR still
What's the current state of matchesSelector? Are we confident enough in
the name and such to unprefix it?
-Boris
On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarsky bzbar...@mit.edu wrote:
What's the current state of matchesSelector? Are we confident enough in the
name and such to unprefix it?
I think that matchesSelector suffers from the same verbosity that qSA
does, and would benefit from the same
On 11/21/11 10:56 AM, Tab Atkins Jr. wrote:
On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarskybzbar...@mit.edu wrote:
What's the current state of matchesSelector? Are we confident enough in the
name and such to unprefix it?
I think that matchesSelector suffers from the same verbosity that qSA
There's discussion about introducing find and findAll as an alternative to
querySelector[All]. However, window.find exists already in Firefox and
WebKit, and is for in-page text search. There's a placeholder for it in
the spec.
On Mon, Nov 21, 2011 at 8:28 AM, Simon Pieters sim...@opera.com wrote:
There's discussion about introducing find and findAll as an alternative to
querySelector[All]. However, window.find exists already in Firefox and
WebKit, and is for in-page text search. There's a placeholder for it in the
On Mon, Nov 21, 2011 at 8:23 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/21/11 10:56 AM, Tab Atkins Jr. wrote:
On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarskybzbar...@mit.edu wrote:
What's the current state of matchesSelector? Are we confident enough in
the
name and such to unprefix
On 11/21/11 11:31 AM, Tab Atkins Jr. wrote:
1) Make sense.
2) Not break existing content.
3) Be short.
.matches
.is
The sticking point here is obviously item #2. Data needed on use of
matches and is as barewords in on* attributes, specifically.
-Boris
window.find() covers a use case not easily replicated by other APIs:
searching within the page for text that crosses node boundaries. There
was a thread on the WHATWG mailing list about this:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-July/032588.html
Tim
On 21 November 2011
Hi,
As part of LC, I've received quite a bit of offline feedback that because of
some issue in Webkit, it's difficult for implementers to reuse the WebStorage
interface in a widget context: the problem is that Widget's use of Web storage
slightly modifies some of the behaviour of the storage
On Mon, Nov 21, 2011 at 9:03 AM, Tim Down timd...@gmail.com wrote:
window.find() covers a use case not easily replicated by other APIs:
searching within the page for text that crosses node boundaries. There
was a thread on the WHATWG mailing list about this:
On Mon, Nov 21, 2011 at 6:30 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Wed, Nov 16, 2011 at 12:40 PM, Henri Sivonen hsivo...@iki.fi wrote:
* Making XHR not support HTML parsing in the synchronous mode.
In reference to the other thread about discouraging synchronous XHR
(outside Workers),
On 11/20/11 8:33 PM, ext ashok malhotra wrote:
The idea is not to remove APIs.
We have several client-side storage facilities that cover different
but overlapping
usecases. Can we step back and look at what we have and come up,
perhaps, with a
smaller set of facilities and better
On Nov 21, 2011, at 18:08 , Marcos Caceres wrote:
As part of LC, I've received quite a bit of offline feedback that because of
some issue in Webkit, it's difficult for implementers to reuse the WebStorage
interface in a widget context: the problem is that Widget's use of Web
storage
Hello everyone,
I've noticed that the find/findAll methods are currently being discussed and
there is one thing that might be a good idea to consider.
Currently, it's quite uncomfortable to use XPath in javascript. The
document.evalute method has lots of arguments and we have to remember
On Mon, Nov 21, 2011 at 11:34 AM, Martin Kadlec bs-ha...@myopera.comwrote:
Hello everyone,
I've noticed that the find/findAll methods are currently being discussed
and there is one thing that might be a good idea to consider.
Currently, it's quite uncomfortable to use XPath in javascript.
On Monday, 21 November 2011 at 21:42, Robin Berjon wrote:
On Nov 21, 2011, at 18:08 , Marcos Caceres wrote:
As part of LC, I've received quite a bit of offline feedback that because
of some issue in Webkit, it's difficult for implementers to reuse the
WebStorage interface in a widget
On Nov 21, 2011 11:29 PM, Martin Kadlec bs-ha...@myopera.com wrote:
On Monday, 21 November 2011 2:18 PM, James Robinson jam...@google.com
wrote:
XPath is dead on the web. Let's leave it that way.
- James
Why? XPath is in lot's of cases much more powerful than CSS selectors and
all
On Mon, Nov 21, 2011 at 2:28 PM, Martin Kadlec bs-ha...@myopera.com wrote:
On Monday, 21 November 2011 2:18 PM, James Robinson jam...@google.com
wrote:
XPath is dead on the web. Let's leave it that way.
Why? XPath is in lot's of cases much more powerful than CSS selectors and all
browsers
On Mon, Nov 21, 2011 at 11:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
The sticking point here is obviously item #2. Data needed on use of
matches and is as barewords in on* attributes, specifically.
I don't follow. matchesSelector is on Element, not Node, right? Why
is it relevant to on*
On Mon, Nov 21, 2011 at 11:29 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
That only interferes if .find() for selectors is defined on window.
qSA is only defined on Document and Element, though, and I see no
reason that .find wouldn't be the same.
So then we get another built-in method that
On Mon, Nov 21, 2011 at 5:31 PM, Aryeh Gregor a...@aryeh.name wrote:
On Mon, Nov 21, 2011 at 11:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
The sticking point here is obviously item #2. Data needed on use of
matches and is as barewords in on* attributes, specifically.
I don't follow.
On Mon, Nov 21, 2011 at 8:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You're not misunderstanding, but you're wrong. ^_^ The element
itself is put in the lookup chain before document. See this testcase:
!DOCTYPE html
button onclick=alert(namespaceURI)foo/button
(namespaceURI was
On 22/11/11 3:23 AM, Boris Zbarsky wrote:
On 11/21/11 10:56 AM, Tab Atkins Jr. wrote:
On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarskybzbar...@mit.edu wrote:
What's the current state of matchesSelector? Are we confident
enough in the
name and such to unprefix it?
I think that
I think this is the only sane solution to this problem. Lets split up the
Element interface. I'm not attached to these names, but something
like ElementExposed and Element. Element inherits (mixins?) ElementExposed
and only the methods on ElementExposed are exposed to the on* lookup chain.
On 11/21/11 8:31 PM, Aryeh Gregor wrote:
The lookup chain is first document
then window, with no elements anywhere, right?
The lookup order is the element the on* attribute is on, then the
element's form if it's a form control (more or less; details are in the
spec), then the document, then
On 11/21/11 9:58 PM, Ojan Vafai wrote:
I think this is the only sane solution to this problem. Lets split up
the Element interface. I'm not attached to these names, but something
like ElementExposed and Element. Element inherits (mixins?)
ElementExposed and only the methods on ElementExposed are
Yehuda Katz
(ph) 718.877.1325
On Mon, Nov 21, 2011 at 2:28 PM, Martin Kadlec bs-ha...@myopera.com wrote:
On Monday, 21 November 2011 2:18 PM, James Robinson jam...@google.com
wrote:
XPath is dead on the web. Let's leave it that way.
- James
Why? XPath is in lot's of cases much more
Yehuda Katz
(ph) 718.877.1325
On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/21/11 11:31 AM, Tab Atkins Jr. wrote:
1) Make sense.
2) Not break existing content.
3) Be short.
.matches
.is
I like .is, the name jQuery uses for this purpose. Any reason
32 matches
Mail list logo
