On Nov 25, 2009, at 8:42 PM, Jeremy Orlow wrote:
On Wed, Nov 25, 2009 at 5:16 PM, Nikunj R. Mehta nikunj.me...@oracle.com
wrote:
On Nov 24, 2009, at 7:40 PM, Ian Hickson wrote:
On Fri, 20 Nov 2009, Arthur Barstow wrote:
Based on the responses for this call for comments, I see the next
On Nov 26, 2009, at 13:18, Jonathan Watt wrote:
During a discussion about xml:id I was about to make the throw away comment
that
you could use querySelector to easily work around lack of support for xml:id,
but on checking it turns out that's not the case. querySelector, it seems,
cannot be
On Thu, 26 Nov 2009 09:33:28 -0200, Henri Sivonen hsivo...@iki.fi wrote:
On Nov 26, 2009, at 13:18, Jonathan Watt wrote:
[...]
Isn't the easiest solution not to support xml:id on the Web? It's not
supported in Gecko, WebKit or Trident. What's the upside of adding it?
Besides that,
Jonathan Watt wrote:
During a discussion about xml:id I was about to make the throw away comment that
you could use querySelector to easily work around lack of support for xml:id,
but on checking it turns out that's not the case. querySelector, it seems,
cannot be used to select on a specific
On 2009-11-26 12:33 PM, Henri Sivonen wrote:
On Nov 26, 2009, at 13:18, Jonathan Watt wrote:
During a discussion about xml:id I was about to make the throw away comment
that
you could use querySelector to easily work around lack of support for xml:id,
but on checking it turns out that's
On 2009-11-26 1:16 PM, Lachlan Hunt wrote:
Jonathan Watt wrote:
Maybe the working group could consider adding some sort of non-prefix
namespace support to selectors for the sake of
querySelector/querySelectorsAll,
something like:
[url(http://www.w3.org/XML/1998/namespace;)|id=foo]
On 2009-11-26 2:16 PM, Jonathan Watt wrote:
On 2009-11-26 1:16 PM, Lachlan Hunt wrote:
Jonathan Watt wrote:
Maybe the working group could consider adding some sort of non-prefix
namespace support to selectors for the sake of
querySelector/querySelectorsAll,
something like:
Hi,
I'm trying to implement the element-based localization and I found the spec unclear with regards to the inheritance of th xml:lang attribute and I would like to propose some improved text.
First, this attribute is listed as an optional attribute of the widget element
but the widget
Maciej Stachowiak wrote:
The proposed exit criteria are in a separate thread, but essentially are:
For a set of tests based on HTML, CSS 2.1 selectors and this spec,
there are two implementations that pass every test interoperably, and
do not fail any additional tests based on misimplementing
Jonathan Watt wrote:
On 2009-11-26 12:33 PM, Henri Sivonen wrote:
On Nov 26, 2009, at 13:18, Jonathan Watt wrote:
During a discussion about xml:id I was about to make the throw away comment that
you could use querySelector to easily work around lack of support for xml:id,
but on checking it
Lachlan Hunt wrote:
There must be at least two complete, independent implementations, each
of which must pass 100% of the baseline testsuite and should pass
additional tests, dependent on the following conditions:
...
The current state of implementations is as follows:
Minefield:
Baseline
Hi all,
I'm trying to understand the difference between two tests:
[1]
http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-UEMbyHERkI/000/config.xml
[2]
http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-UEMbyHERkI/003/config.xml
In [1], the first description element is
On Thu, 26 Nov 2009 15:58:56 +0100, Lachlan Hunt
lachlan.h...@lachy.id.au wrote:
Lachlan Hunt wrote:
There must be at least two complete, independent implementations, each
of which must pass 100% of the baseline testsuite and should pass
additional tests, dependent on the following
Hi Marcos,
Marcos Caceres a écrit :
Hi Cyril,
On Fri, Nov 20, 2009 at 5:50 PM, Cyril Concolato
cyril.concol...@enst.fr wrote:
Hi,
The test d1.wgt is about the src attribute of the icon element. It says that
it tests the following assertion:
If the src attribute of this icon element is
BlackBerry 9700 browser:
(Kartikaya Gupta from RIM e-mailed me off list about this to tell me,
I'm unable to verify these results myself without access to the
device.)
Baseline Tests: HTML/CSS2.1:PASS
Additional Tests: HTML/CSS3: PASS
Additional Tests:
On 11/26/09 9:58 AM, Lachlan Hunt wrote:
Actually, correction. Minefield and Opera don't meet the condition if we
keep the shipping requirement in the exit criteria.
Which imo we should. I don't think we want to be opening up that loophole.
The Gecko 1.9.2 branch builds have the
On 11/26/09 11:52 AM, Charles McCathieNevile wrote:
And I don't see any problem with using public development builds.
The main problem I have with them is that they have typically not gone
through the sort of full QA cycle that would point out possible problems
in the implementation of the
Boris Zbarsky wrote:
On 11/26/09 9:58 AM, Lachlan Hunt wrote:
Actually, correction. Minefield and Opera don't meet the condition if we
keep the shipping requirement in the exit criteria.
Which imo we should. I don't think we want to be opening up that loophole.
The Gecko 1.9.2 branch builds
On Thu, 26 Nov 2009 21:05:31 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/26/09 9:58 AM, Lachlan Hunt wrote:
Actually, correction. Minefield and Opera don't meet the condition if we
keep the shipping requirement in the exit criteria.
Which imo we should. I don't think we want to be
Lachlan Hunt wrote:
Maciej Stachowiak wrote:
The proposed exit criteria are in a separate thread, but essentially
are:
For a set of tests based on HTML, CSS 2.1 selectors and this spec,
there are two implementations that pass every test interoperably, and
do not fail any additional tests
On Thu, 26 Nov 2009 23:04:35 +0100, Sean Hogan shogu...@westnet.com.au
wrote:
Lachlan Hunt wrote:
...
* The implementations must be native implementations in shipping
products. (JavaScript library implementations don't count).
What is the reason for the native implementation
21 matches
Mail list logo
