Hi Marcos,
A widget engine, in our use of the term, is a server-side web
application that publishes widgets and implements the Widget API as a
web service accessible via AJAX. As it stands all browsers will block
any cross-domain Javascript requests, and this will apply in all cases
On Jan 27, 2009, at 00:18, Alex Russell wrote:
We just need to invent a pseudo-property for elements which can be
matched by a :not([someProperty=your_ns_here]).
To select SVG elements while avoiding HTML elements of the same name,
a selector that prohibits the local name foreignObject
On Wed, 28 Jan 2009 10:55:49 +0100, Henri Sivonen hsivo...@iki.fi wrote:
On Jan 27, 2009, at 00:18, Alex Russell wrote:
We just need to invent a pseudo-property for elements which can be
matched by a :not([someProperty=your_ns_here]).
To select SVG elements while avoiding HTML elements of
Hi Boris,
On 1/23/09 2:25 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Marcos Caceres wrote:
Ok. I'll need to run this by the working group as I had something like
this in very early drafts of the spec and received criticism for being
overly prescriptive (It could have been that I wrote the
Maybe it was already proposed, but are there any problem to just add a
new argument to querySelectors and querySelectorsAll, with namespace
bindings?
I don't mean anything like XPathNSResolver or things like that. I just
mean a ES Object, where enumerable property names are namespace
prefixes,
Hi Scott,
On Wed, Jan 28, 2009 at 9:51 AM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
Hi Marcos,
A widget engine, in our use of the term, is a server-side web application
that publishes widgets and implements the Widget API as a web service
accessible via AJAX. As it stands all
I asked that question a little ago. I was answered, and agreed, that
CSS selectors are easier to understand, are already known by authors
because of their use in CSS and most important they're highly
optimized in UAs.
2009/1/28 Anne van Kesteren ann...@opera.com:
On Wed, 28 Jan 2009 14:25:29
On Wed, 28 Jan 2009 14:32:05 +0100, Giovanni Campagna
scampa.giova...@gmail.com wrote:
I asked that question a little ago. I was answered, and agreed, that
CSS selectors are easier to understand, are already known by authors
because of their use in CSS and most important they're highly
Giovanni Campagna wrote:
Maybe it was already proposed, but are there any problem to just add a
new argument to querySelectors and querySelectorsAll, with namespace
bindings?
The original spec did contain an NSResolover argument, which was based
upon the XPathNSResolver. It was dropped for
@Anne:
well, assuming that an author will need to match elements across
multiple namespaces, it will be easier to use XPath (that also is
compatible across multiple browsers) than to use horrible workarounds
like svg :not(foreignObject) *[href] (all svg links) or svg
not(timesheet) animation (all
a) authors create multiply namespaced documents, so they need a way to
reliably traverse those documents (either with namespace support or
not)
b) svg links support attributes that xhtml links (i mean xhtml2 links,
ie any element with a href) do not: modifying those attributes is a
use case (for
Marcos Caceres wrote:
Ok, that sounds like a completely reasonable proposal. And you are right, I
had thought about this in totally the wrong way. I did as you suggested:
* widget engines may now support SVG 1.1.
* authors, however, should try to conform to SVG Tiny 1.2.
* conformance
Boris Zbarsky wrote:
Sort of. We use JAR, not ZIP. Any JAR file is a ZIP file, but not vice
versa. In particular, the JAR spec [1] defines that all non-ASCII bytes
are UTF-8.
That [1] is http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html
-Boris
Giovanni Campagna wrote:
well, assuming that an author will need to match elements across
multiple namespaces, it will be easier to use XPath (that also is
compatible across multiple browsers) than to use horrible workarounds
like svg :not(foreignObject) *[href] (all svg links) or svg
Marcos, All,
On Jan 22, 2009, at 9:16 AM, ext Marcos Caceres wrote:
In the PC spec, I would really like to drop the access element's
plugins attribute and just leave it to implementations to cope with
proprietary content types. Does anyone have a problem with this?
Given we have no related
Below is the draft agenda for the January 29 Widgets Voice Conference
(VC).
So that we can focus on comments related to the LCWD of the Widgets
Packaging and Configuration spec, the Widgets Digital Signature spec
is not included on this week's agenda.
Inputs and discussion on all of
2009/1/28 Boris Zbarsky bzbar...@mit.edu:
Giovanni Campagna wrote:
well, assuming that an author will need to match elements across
multiple namespaces, it will be easier to use XPath (that also is
compatible across multiple browsers) than to use horrible workarounds
like svg
Giovanni Campagna wrote:
2009/1/28 Boris Zbarsky bzbar...@mit.edu:
Giovanni Campagna wrote:
well, assuming that an author will need to match elements across
multiple namespaces, it will be easier to use XPath (that also is
compatible across multiple browsers) than to use horrible workarounds
2009/1/28 Boris Zbarsky bzbar...@mit.edu:
Giovanni Campagna wrote:
2009/1/28 Boris Zbarsky bzbar...@mit.edu:
Giovanni Campagna wrote:
well, assuming that an author will need to match elements across
multiple namespaces, it will be easier to use XPath (that also is
compatible across
On Wed, Jan 28, 2009 at 3:09 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Marcos Caceres wrote:
Ok, that sounds like a completely reasonable proposal. And you are right,
I
had thought about this in totally the wrong way. I did as you suggested:
* widget engines may now support SVG 1.1.
*
Hi, Folks-
Boris Zbarsky wrote (on 1/23/09 9:25 AM):
Marcos Caceres wrote:
That really depends on what the goal is. What _is_ the goal?
The goals are as follows:
1. Widget engines optionally support SVG Tiny for the icon format
(though they can have the capability to render full SVG).
Marcos Caceres wrote:
Ok, as I know little of SVG, I've asked Doug Scheppers to help me
That sounds like an excellent plan. Thank you!
It is, but this affects more than just Zip. See also [3] with the
problems Limewire had in respect to normalization of Unicode on MacOs
X.
Note that this
On Wed, Jan 28, 2009 at 7:22 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Marcos Caceres wrote:
My gut feeling is that we run with this known issue; We have a warning
in the spec that authors should avoid using file names outside the
ASCII range.
I can live with that, as long as the issue has
A reminder for people interested in Widgets specs ...
January 31 is the deadline for comments for the 22 December 2008 Last
Call Working Draft of the Widgets 1.0: Packaging and Configuration spec:
http://www.w3.org/TR/2008/WD-widgets-20081222/
-Regards, Art Barstow
Begin forwarded
Version cited: WD 28 January 2009
URL: http://www.w3.org/TR/2008/WD-widgets-20081222/
Aware of latest editor's draft at: http://dev.w3.org/2006/waf/widgets/
Minor observation in editor's draft: the text suggests that the Conformance
Checker must warm the author if the icon does not conform to
Hi Rotan,
On Wed, Jan 28, 2009 at 9:52 PM, Rotan Hanrahan
rotan.hanra...@mobileaware.com wrote:
Version cited: WD 28 January 2009
URL: http://www.w3.org/TR/2008/WD-widgets-20081222/
Aware of latest editor's draft at: http://dev.w3.org/2006/waf/widgets/
Minor observation in editor's draft:
Giovanni Campagna wrote:
2009/1/28 Boris Zbarsky bzbar...@mit.edu:
svg xmlns=http://www.w3.org/2000/svg;
g
foreignObject
foo xmlns= href=This is my random href attribute/
/foreignObject
/g
/svg
The foo element matches the svg :not(foreignObject) *[href] selector.
Phillips, Addison wrote:
Dear Webapps WG,
I am writing on behalf of the I18N Core WG who discussed the Selectors
API WD in our call of 3 December [1].
We reviewed the Selectors API working draft. In reviewing this draft,
we did not find any internationalization issues in the text of the
28 matches
Mail list logo
