Re: [selectors-api] Selectors API I18N Review...

[fantasai]

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
document. However, we would like to point out that the CSS3 Selectors
themselves have outstanding internationalization comments not addressed
in the current version of that document [4] and which would (we think)
impact anyone who were to implement the Selectors API. Our comments on
CSS3 Selectors are located at [2]. We also note that Unicode Normalization
is not treated anywhere in this draft or in CSS3 Selectors.
...
[1] http://www.w3.org/2008/12/03-core-minutes.html
[2] http://www.w3.org/International/reviews/0601-css3-selectors/ 
[3] http://lists.w3.org/Archives/Member/member-i18n-core/2008Dec/0006.html 
[4] http://www.w3.org/TR/css3-selectors/ aka http://www.w3.org/TR/2005/WD-css3-selectors-20051215 


I have reviewed all of your outstanding comments on Selectors, and with
the exception of a request for a bidi example [1], all of them have been
dealt with in the upcoming draft [2].

As far as I know (and perhaps my memory does not go back far enough, I
have only been in the WG since 2004), the CSS Working Group has no record
of the I18n Working Group raising an issue with regards to Unicode
Normalization in any of our specs. If the I18nWG would like us to address
this issue, please raise an issue against /our/ specs, preferably with a
recommended solution. Such an issue would potentially affect the following
specs at least:
  [CSS21]  CSS2.1
  [css3-namespace] CSS Namespaces
  [css3-selectors] Selectors Level 3
  [css3-content]   CSS Generated and Replaced Content Level 3
  [css3-page]  CSS Paged Media Level 3
  [css3-gcpm]  CSS Generated Content for Paged Media Level 3

I will note that a previous version of the Selectors module included a
paragraph on Unicode normalization in the Conformance Requirements section:
  http://www.w3.org/TR/2001/CR-css3-selectors-2003/#Conformance
which appears to have been removed in response to comments as described here:
  http://lists.w3.org/Archives/Member/w3c-css-wg/2005OctDec/0158.html

[1] http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0049.html
[2] http://dev.w3.org/csswg/selectors3

~fantasai

Re: [selectors-api] SVG WG Review of Selectors API

[Lachlan Hunt]

Giovanni Campagna wrote:

2009/1/28 Boris Zbarsky :

 http://www.w3.org/2000/svg";>
   
 
   
 
   
 

The  element matches the "svg :not(foreignObject) *[href]" selector.
 Indeed, "*[href]" matches the  element, ":not(foreignObject)" matches
the , and "svg" matches the .


One point in favour of namespace support then!


The purely technical limitations are already well understood.  This in 
itself is not a point in favour of introducing namespaces.  The above 
problem occurs with any other kind of selector using :not() in the 
sequence, wanting a way to filter out a specific element from the 
ancestor chain.  It's not just a namespace related limitation.  The 
issue remains the lack of clear use cases demonstrating *why* the 
problem should be solved.  That is, why should we address that 
particular technical limitation above?



1. Why is the author mixing SVG and, presumably, HTML in this case?  I know
there are use cases for this in general, but we should be specific about
which.


Because SVG allows for greater presentation than HTML and CSS, but
this greater presentation only applies to a small part of the
document. Or because I have two versions of the same page, one in SVG
and one in HTML, switched by CSS and media queries or JS.


This is not a use case.  They're technical reasons for choosing SVG as 
the solution to some particular use case or problem.  What is the 
specific use case that is being addressed?


For example, this is a hypothetical use case I've made up to demonstrate 
what I'm looking for.  (Of course, I would expect any real use case to 
not simply be made up like this one, but rather based on something real 
world authors would want to do, ideally supported by real world examples.)


---

A city rail transport website wants to provide a map of the rail 
network.  The map is drawn in a diagram style, just like the London Tube 
map.  The map user needs to be able to zoom in and scale the map easily, 
and clicking on a station on the provides more information about that 
station and the lines that pass through it.


SVG is being used because it's scalable and scripts can be used to scale 
it easily as the user zooms in.  The linking abilities also allow the 
user to click on a station, and the solution is deemed to be better than 
the alternative using a PNG and an image map.


---


2. Why does the SVG contain links?  This may be partially answered by the
previous question.  Preumably this means that it's not meant as a purely
decorative image and the links provide the user with something useful.


Because SVG links follow the SVG rendering model: they're positioned, 
stroked, alpha blended, animated. Instead HTML links are flowed and 
follow the CSS rendering model. Only their container (foreignObject) 
is part of the SVG image. Either you put an foreignObject for each 
link, or you don't use HTML links.


Again, this does not answer the question of what the links are being 
used for.  It just provides more technical details about the solution.


However, note that the above example use case I provided answers both 
the first and second questions clearly by itself.  It does not, however, 
answer the third or fourth.  (If I knew of some use cases that answered 
those questions, we wouldn't be having this discussion)



3. Why does the SVG image contain links using elements from a foreign
namespace in addition to links using elements from its own namespace?


As I said earlier, SVG links are different from HTML links in that
HTML is flowed. If I want to have a rich user interface with animating
buttons on the top of my SVG, but I want to have some HTML content in
the same image, I need HTML links.


This does not explain why the image would use SVG elements for some 
links and HTML elemenets for others within the same image.  As far as I 
can tell, the above use case I provided doesn't need to use HTML links 
at all, so it's probably not one that is suitable for answering the 
questions I asked you, nor providing justification for adding namespace 
support.  However, I only provided it for illustrative purposes to show 
what a use case is.  It's the responsibility of you and others who are 
pushing for the namespace feature to present real use cases, not mine.



4. What is the author trying to achieve using a script that needs to obtain
those links, and why does it only affect links from the SVG namespace, and
not all links within the SVG image, including those from other namespaces
within ?


As I said before, scripting may need those for imperative animation, 
usually more powerful (but less performant) than declarative one. It 
may need only SVG links because SVG links are completely different 
than HTML links. Setting a strokeColor CSS property on HTML link has 
no effect.


In that case, if there are no HTML links within the image, what problem 
would a namespace resolution feature solve?



If you can think of any other questions, feel free to ask them and answ

Re: Typographical errors

[Marcos Caceres]

Hi Rotan,
On Wed, Jan 28, 2009 at 9:52 PM, Rotan Hanrahan
 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: the text suggests that the Conformance
> Checker must warm the author if the icon does not conform to SVG Tiny.
> Perhaps the author is already warm enough, and should be warNed instead.

hehe, fixed.

> Cross-reference issue: The link to the requirement R20 (claiming to be
> "Iconic Representations") in section 1.2 of the draft (cited) should
> actually be a link to R19 (actually "Iconic Representation"). R20 is
> actually the "Configuration Parameters" requirement as the following link
> demonstrates:
> http://www.w3.org/TR/widgets-reqs/#r20.-x

Ah, the reason they don't line up is that these have been updated to
link to the unpublished draft of the requirements document.

> On this point, I suspect a review of all the R** numbers and links is
> advised. (Using descriptive anchors instead of number sequences would have
> avoided this lack of synchronization between the documents.)

Yeah, I think we will republish a bunch of these documents together so
they don't get out of sync.

> These observations are trivial, but I know that the editor will provide the
> corrections, and I thank the editor in advance for this.

Thank you for taking the time to send in those corrections!

-- 
Marcos Caceres
http://datadriven.com.au

Typographical errors

[Rotan Hanrahan]

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 SVG Tiny. Perhaps 
the author is already warm enough, and should be warNed instead.

Cross-reference issue: The link to the requirement R20 (claiming to be "Iconic 
Representations") in section 1.2 of the draft (cited) should actually be a link 
to R19 (actually "Iconic Representation"). R20 is actually the "Configuration 
Parameters" requirement as the following link demonstrates:
http://www.w3.org/TR/widgets-reqs/#r20.-

On this point, I suspect a review of all the R** numbers and links is advised. 
(Using descriptive anchors instead of number sequences would have avoided this 
lack of synchronization between the documents.)

These observations are trivial, but I know that the editor will provide the 
corrections, and I thank the editor in advance for this.

Regards,

---Rotan.




Rotan Hanrahan
Chief Innovations Architect
MobileAware

Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec

[Arthur Barstow]

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:


 

-Regards, Art Barstow

Begin forwarded message:


Resent-From: public-webapps@w3.org
From: "ext Arthur Barstow" 
Date: January 9, 2009 1:38:51 PM EST
To: public-webapps 
Subject: Request for Comments: Last Call WD of Widgets 1.0:  
Packaging & Configuration spec; deadline 31 Jan 2009
Archived-At: 



Bcc: public-i18n-c...@w3.org, public-b...@w3.org, wai-xt...@w3.org,  
public-m...@w3.org

Reply-to: public-webapps@w3.org (archived at [1])

The Web Applications WG [2] explicitly seeks comments from the  
I18N, Mobile Web BP, Mobile Web Test Suites and WAI P&F Working  
Groups regarding the 22 December 2008 Last Call Working Draft of  
the Widgets 1.0: Packaging and Configuration spec:


 

Comments from all others, including the Web Apps community are also  
encouraged.


The comment period ends on 31 January 2009.

-Regards, Art Barstow

P.S. Note: Bcc was used to help reduce cross-posting. Please send  
all replies to public-webapps@w3.org


[1] 
[2] 

Re: Request for Comments: Last Call WD of Widgets 1.0: Packaging & Configuration spec; deadline 31 Jan 2009

[Marcos Caceres]

On Wed, Jan 28, 2009 at 7:54 PM, Ian Hickson  wrote:
> On Wed, 28 Jan 2009, Marcos Caceres wrote:
>> On 1/23/09 2:25 PM, "Boris Zbarsky"  wrote:
>> >
>> >"There may be implementation-specific limits on the range of
>> > integers allowed, and behavior outside such limits is undefined."
>>
>> You should probably tell the HTML5 guys about this too, as it may be
>> relevant there.
>
> HTML5 already says:
>
>   User agents may impose implementation-specific limits on otherwise
>   unconstrained inputs, e.g. to prevent denial of service attacks, to
>   guard against running out of memory, or to work around
>   platform-specific limitations.
>
> ...and there are several other statements in the spec to handle specific
> cases (e.g. out-of-JS-Number-range attribute values reflected into the
> DOM, or handling out-of-control scripts).

Thanks for the clarification. Useful statement, I'll add that
somewhere too into the spec.

-- 
Marcos Caceres
http://datadriven.com.au

Re: Request for Comments: Last Call WD of Widgets 1.0: Packaging & Configuration spec; deadline 31 Jan 2009

[Ian Hickson]

On Wed, 28 Jan 2009, Marcos Caceres wrote:
> On 1/23/09 2:25 PM, "Boris Zbarsky"  wrote:
> > 
> >"There may be implementation-specific limits on the range of
> > integers allowed, and behavior outside such limits is undefined."
> 
> You should probably tell the HTML5 guys about this too, as it may be 
> relevant there.

HTML5 already says:

   User agents may impose implementation-specific limits on otherwise 
   unconstrained inputs, e.g. to prevent denial of service attacks, to 
   guard against running out of memory, or to work around 
   platform-specific limitations.

...and there are several other statements in the spec to handle specific 
cases (e.g. out-of-JS-Number-range attribute values reflected into the 
DOM, or handling out-of-control scripts).

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Request for Comments: Last Call WD of Widgets 1.0: Packaging & Configuration spec; deadline 31 Jan 2009

[Marcos Caceres]

On Wed, Jan 28, 2009 at 7:22 PM, Boris Zbarsky  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 been considered.  In
> practice, I'll just hope that everyone involved migrates to UTF-8 and is
> done with it.

Agreed. Glad we reached some level of consensus wrt to this.

Kind regards,
Marcos
-- 
Marcos Caceres
http://datadriven.com.au

Re: Request for Comments: Last Call WD of Widgets 1.0: Packaging & Configuration spec; deadline 31 Jan 2009

[Boris Zbarsky]

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 is a pretty old article.  I agree that this stuff doesn't 
work as well as would be ideal, of course.



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.


AFAIK, JAR uses Java's Modified UTF-8 so it's quite proprietary.


The only difference between standard UTF-8 and Modified UTF-8 is how the 
character U+ is encoded.  If someone is putting that particular 
character in their filenames, I have no problem saying that behavior is 
undefined as long as it's secure.



The use of modified UTF-8 in Java wrt Zip has led to significant problems
[2] (this bug appeared in 1999 (!)


Looks like that bug is more about the fact that using Java's 
ZIP-manipulation functionality on JARs fails because the 
ZIP-manipulation stuff uses the OS-default encoding...


Which does bring us back to the issue of ZIP tools sucking in this 
regard, of course.



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 been considered.  In 
practice, I'll just hope that everyone involved migrates to UTF-8 and is 
done with it.


-Boris

SVG as Widget Icon (was: Request for Comments: Last Call WD of Widgets 1.0: Packaging & Configuration spec; deadline 31 Jan 2009)

[Doug Schepers]

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).
>>   2. For the purpose of widgets, icons are written by authors to
>> conform to SVG Tiny (not full)
>>   3. Widget engines that support full, can render icons in SVG Tiny...
>> but, for interop, widget engines should not render icons written in
>> SVG Full 1.1 (unless the icon also conforms to SVG Tiny).
> 
> Goal 3 is what my original comment was about, basically.  It means that
> a widget engine cannot make use of various existing SVG implementations
> that just happen to support more than just SVG Tiny.  In particular, it
> means that Gecko, say, would not be able to implement this specification
> without sprinkling code all over to validate SVG files against SVG Tiny
> (something we don't plan to do, since that's not the profile we're
> implementing).
> 
> I understand where you're coming from with this goal, but I'm not sure
> it's worth the restriction it imposes.
> 
> Things will get even worse once SVG Tiny 1.2 is a REC, since at that
> point I fully expect pretty much all SVG engines supporting SVG Tiny to
> implement that specification, and at that point there will be no SVG
> engines that can be used for Widgets at all (since all of them will
> render things that are not valid SVG Tiny 1.1).

SVG Tiny 1.2 became a Recommendation in December 2008, and even previous
to that, most commercial SVG Tiny UAs (those for mobile devices) had
already implemented SVG Tiny 1.2.


> So unless you really mean to exclude SVG engines that happen to
> implement SVG Full 1.1, SVG Tiny 1.2, SVG Basic 1.1 from being used in
> widget implementations (possibly forcing the widget UA to ship two
> separate SVG engines, one for widgets and one for everything else it's
> doing), I think you should drop goal 3 and leave the authoring requirement.
> 
> That is, just have image/svg+xml work the same way in Widgets as it does
> over HTTP, with the authoring requirement, presumably enforced by
> validators of widgets but not widget UAs, that the images conform to SVG
> Tiny (1.1 or any version; up to you).

I think that rather than specifying a particular spec or profile, the
Widgets spec should instead reference a feature set that is appropriate
for use as a icon.

My recommendation is that you include normative references not only to
SVG Tiny 1.1, but also SVG Full 1.1 (which is largely implemented in
desktop browsers, and probably has the most current implementations),
and SVG Tiny 1.2 (which is the most recent SVG Rec, and is deployed most
widely on mobiles).  That way, as Boris said, any SVG-capable UA can
meet the conformance requirements.

In the next version of the SVG spec, we will make it easier to reference
particular needs and use cases, but in the meantime, I think the best
thing would be to outline what capabilities should and should not be
allowed for presenting an SVG icon.  Specifically, static image
rendering must (or should) be required, but for security reasons, no
script and no interaction (not even linking) should be allowed; however,
declarative animation should be allowed, so that authors can provide
animated icons (assuming the UA supports it... right now, FF doesn't,
but should soon).  It is rather more questionable whether video or audio
should be allowed, or things like HTML embedded in 
(which seems okay to me).

This is the same set of restrictions we would expect for referencing an
SVG as an , as I discuss in my little overview page on the matter.
[1]  Again, this is something I think FF and WebKit are working on this,
and Opera supports this already.

I wish it were easier to simply point to a section of an SVG spec that
describes these capabilities (again, next spec version...), but for now,
the Widgets spec should describe these constraints explicitly (if
briefly), referencing these featurestrings:

SVG 1.1
 "http://www.w3.org/TR/SVG11/feature#SVG-static";

SVG Tiny 1.2
 "http://www.w3.org/Graphics/SVG/feature/1.2/#SVG-animated";

If you would like me to work up proposed spec text, I could oblige you.

On another topic, I would like to use Widgets with pure SVG content,
rather than including HTML... I didn't see a clear way to do this, nor
was it explicitly disallowed.  I'll review the spec more to see if there
are problems in this regard.

[1] http://www.schepers.cc/svg/blendups/embedding.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: [widgets] Removing plugins attribute

[Marcos Caceres]

On Wed, Jan 28, 2009 at 4:02 PM, Arthur Barstow  wrote:
> Marcos, All,
>
> On Jan 22, 2009, at 9:16 AM, ext Marcos Caceres wrote:
>
>>
>> In the P&C 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 requirements, I agree this should be removed from
> P&C v1.

Hearing no objections, I've removed it from the spec.

Kind regards,
Marcos

-- 
Marcos Caceres
http://datadriven.com.au

Re: Request for Comments: Last Call WD of Widgets 1.0: Packaging & Configuration spec; deadline 31 Jan 2009

[Marcos Caceres]

On Wed, Jan 28, 2009 at 3:09 PM, Boris Zbarsky  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.
>>  * authors, however, should try to conform to SVG Tiny 1.2.
>>  * conformance checkers should warn authors when their icons don't conform
>> to SVG tiny 1.2.
>
> Note that SVG Tiny 1.2 is not a subset of SVG 1.1, by the way...  I'm not
> sure whether that should affect this section; just pointing it out.

Bah :(

> I think it makes more sense to just allow widget engines to implement
> whatever SVG version they want (as in, place no restrictions on it, past the
> fact that .svg files should be processed per the image/svg+xml MIME type
> registration).

Ok, as I know little of SVG, I've asked Doug Scheppers to help me
specify this properly. Once we have a concrete solution, I will run it
by you again for your approval.

>> Correct. So what is wrong with limiting sniffing to the table in the spec?
>
> Nothing.  In fact it's highly desirable.

Ok. Cool.

>> Or to the content-sniffing internet draft I pointed you to earlier?... I'm
>> not sure I'm understanding what you want me to specify here.
>
> I was just pointing out that current implementations of something like
> widgets which don't use a MIME manifest or some such use an alternate system
> (aggressive extension sniffing) that we don't want to use here.

Ok. The working group is aware of the potential security implications
and will try to work with the editors of [2] to make sure our use
cases are covered.

>> Understood. However, wouldn't you have to deal with the fact that
>> non-conforming zip implementations are used to create the widgets in the
>> first place.
>
> That's a good question, actually.  I'm not sure I have enough of a grasp of
> the issue to tell you what this would mean for a widget UA in practice
>
>>> Do we have any data to support this supposition?  That's certainly how
>>> things work with web pages, and in small market segments like Western
>>> Europe there are multiple encodings in common use (ISO-8859-1 and
>>> UTF-8).
>>
>> No, not directly. I only have anecdotal evidence: a podcast from the
>> Harvard
>> Business Review about globalization and the internet, but I don't have a
>> pointer. In that podcast, some research was presented that indicated that
>> only 15% of internet traffic actually leaves the boundaries of a country
>> and
>> is decreasing. That means that 85% or more of all communication would, in
>> theory, be done using the same language and, by extension, the same
>> character encoding.
>
> Unfortunately, the language to character encoding mapping is not
> one-to-one...  See above about Western Europe.

Ok, point taken.

>> I reached similar conclusions through my own testing/research [1]. Note
>> that
>> on Mac it is apparently some proprietary variant of UTF-8 in fully
>> decomposed canonical form. I'm not sure what different flavors of Linux
>> use
>
> Nowadays UTF-8 for the most part, at least for new data being created.
>
>> but again: things seem bad on the file name encoding front. In essence,
>> you
>> can't share Zip files across OS if they contain characters outside the
>> ASCII
>> range.
>
> This seems like a problem to me...

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. This probably gets worst from OS to OS I'm impressed computers
work at all! :)

>> By "reality" I meant the reality about zip implementations - i.e., no
>> respect for encodings.
>
> OK.
>
>> MHTML *may* be more technically superior and architecturally better, but
>> there is more tool support for Zip than MTHML. AFAIK, MHTML packaging
>> tools
>> do not ship with any operating system. Zipping tools do.
>
> Quite true.  At the same time, we're discussing the fact that once you want
> non-ASCII filenames the zip tools hinder more than help, right?

Correct.

>> Also, Mozilla uses it to ship add-ons right? What, if any,
>> problems have you guys experienced wrt to zip in internationalized
>> contexts?
>
> 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.

AFAIK, JAR uses Java's Modified UTF-8 so it's quite proprietary. The
use of modified UTF-8 in Java wrt Zip has led to significant problems
[2] (this bug appeared in 1999 (!), and it is now the second most
voted on bug in Sun's bug database), and has even prompted the
creation of custom Zipping libraries, like TrueZip, to overcome Java's
implementation issues of Zip and it's issues with encoding problems.

>> Again, I'm not sure how to proceed.
>
> That really depends on how much you care about allowing any ZIP
> implementation to be used for creating widgets vs how much you care about
> intern

Re: [selectors-api] SVG WG Review of Selectors API

[Giovanni Campagna]

2009/1/28 Boris Zbarsky :
> Giovanni Campagna wrote:
>>
>> 2009/1/28 Boris Zbarsky :
>>>
>>> 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)
>>>
>>> I should note that that selector doesn't actually work to select things
>>> that
>>> are not inside a foreignObject...  Offhand, I see no way to do that, in
>>> fact.
>>
>> Why shouldn't it?
>
>  http://www.w3.org/2000/svg";>
>
>  
>
>  
>
>  
>
> The  element matches the "svg :not(foreignObject) *[href]" selector.
>  Indeed, "*[href]" matches the  element, ":not(foreignObject)" matches
> the , and "svg" matches the .
One point in favour of namespace support then!

>> It is the summary of the email Lachlan linked, with pros and cons of
>> various solutions.
>
> Oh, ok.  So that was just reiterating what had already been said.  Gotcha.
>
>> It is not only SVG, it is any markup language that may be mixed to
>> build a compound document.
>
> There is a lot less of a problem with languages that don't have colliding
> localNames.
Mix HTML with SMIL and you get duplicate  and . Mix HTML
with XForms and you get duplicate ,,,.
Is not only SVG

Giovanni

Re: [selectors-api] SVG WG Review of Selectors API

[Boris Zbarsky]

Giovanni Campagna wrote:

2009/1/28 Boris Zbarsky :

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)

I should note that that selector doesn't actually work to select things that
are not inside a foreignObject...  Offhand, I see no way to do that, in
fact.

Why shouldn't it?


  http://www.w3.org/2000/svg";>

  

  

  

The  element matches the "svg :not(foreignObject) *[href]" 
selector.  Indeed, "*[href]" matches the  element, 
":not(foreignObject)" matches the , and "svg" matches the .



It is the summary of the email Lachlan linked, with pros and cons of
various solutions.


Oh, ok.  So that was just reiterating what had already been said.  Gotcha.


It is not only SVG, it is any markup language that may be mixed to
build a compound document.


There is a lot less of a problem with languages that don't have 
colliding localNames.


-Boris

Re: [selectors-api] SVG WG Review of Selectors API

[Giovanni Campagna]

2009/1/28 Boris Zbarsky :
> 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)
>
> I should note that that selector doesn't actually work to select things that
> are not inside a foreignObject...  Offhand, I see no way to do that, in
> fact.
Why shouldn't it?

>> 1) discussion of pros and cons of available technologies (don't use
>> functions or objects to avoid infinite loops or recursion, don't use
>> string to avoid syntax problems), it looks that a NSResolver object (a
>> wrapped hash map, not an interface for a js function like
>> XPathNSResolver) is the best solutions
>
> Would you be willing to expand on why you think that's the best solution?
>  (Maybe it is; I'd just like to know the analysis that led to this
> decision.)
It is the summary of the email Lachlan linked, with pros and cons of
various solutions. The only argument against NSResolver (called
NamespaceResolver in that email) is that we need some new IDL in the
spec.
>
> It would be really nice to make progress here, since I do think that
> namespace support in Selectors API would be quite useful for the SVG case...
>
> -Boris
>
It is not only SVG, it is any markup language that may be mixed to
build a compound document.

2009/1/28 Lachlan Hunt :
> 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
>> not(timesheet) animation" (all SVG but not SMIL animations), or
>> "select[bind], select[ref]" (xforms selects)
>> I think that those example are even easier to rewrite as
>> "svg|*[href]", "svg|animation", "xforms|select", provided a reliable
>> namespace binding mechanisms (the one I proposed)
>
> The use case should try to answer the following questions.  Try to be as
> specific and realistic as possible, and provide links to real world examples
> if you can.
>
> Let's go with the first example you gave of selecting all SVG links: "svg
> :not(foreignObject) *[href]".
>
> Note that the example selector provided won't actually work to select all
> SVG links, at least not in the general case.  The only way that could work
> is like this:
>
> "svg>:not(foreignObject)>[href],
>  svg>:not(foreignObject)>:not(foreignObject)>[href],
>  svg>:not(foreignObject)>:not(foreignObject)>:not(foreignObject)>[href],
>  ..."
Again I ask the same question I asked to Boris: why "svg
*:not(foreignObject) *[href]" is not supposed to work?
>
> 1. Why is the author mixing SVG and, presumably, HTML in this case?  I know
> there are use cases for this in general, but we should be specific about
> which.
Because SVG allows for greater presentation than HTML and CSS, but
this greater presentation only applies to a small part of the
document. Or because I have two versions of the same page, one in SVG
and one in HTML, switched by CSS and media queries or JS.
> 2. Why does the SVG contain links?  This may be partially answered by the
> previous question.  Preumably this means that it's not meant as a purely
> decorative image and the links provide the user with something useful.
Because SVG links follow the SVG rendering model: they're positioned,
stroked, alpha blended, animated. Instead HTML links are flowed and
follow the CSS rendering model. Only their container (foreignObject)
is part of the SVG image. Either you put an foreignObject for each
link, or you don't use HTML links.
> 3. Why does the SVG image contain links using elements from a foreign
> namespace in addition to links using elements from its own namespace?
As I said earlier, SVG links are different from HTML links in that
HTML is flowed. If I want to have a rich user interface with animating
buttons on the top of my SVG, but I want to have some HTML content in
the same image, I need HTML links.
> 4. What is the author trying to achieve using a script that needs to obtain
> those links, and why does it only affect links from the SVG namespace, and
> not all links within the SVG image, including those from other namespaces
> within ?
As I said before, scripting may need those for imperative animation,
usually more powerful (but less performant) than declarative one. It
may need only SVG links because SVG links are completely different
than HTML links. Setting a strokeColor CSS property on HTML link has
no effect.
> If you can think of any other questions, feel free to ask them and answer
> them.  The more information we have about the use cases, the easier it will
> be to evaluate them and find an appropriate solution.
This is was not a complete use case, it was just an example.
> --
> Lachlan Hunt - Opera Software

[widgets] Agenda for 29 January 2009 Voice Conference

[Arthur Barstow]

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 the agenda topics before the meeting  
is encouraged.


Logistics:

  Time: 24:00 Tokyo; 17:00 Helsinki; 16:00 Paris; 15:00 London;  
10:00 Boston; 07:00 Seattle

  Duration = 60 minutes
  Zakim Bridge +1.617.761.6200, conference 9231 ("WAF1")
  IRC channel = #wam; irc.w3.org:6665
  Confidentiality of minutes = Public

Agenda:

1. Review and tweak agenda

2. Announcements

3. P&C Last Call WD; deadline for comments is 31 January:
 

a. Requirements for Window modes:

 Action-291: http://www.w3.org/2008/webapps/track/actions/291

b. Renaming "thumbnail" to "screenshot"?

 


c. SVG dependency (raised by Boris):

 


d. File extension and MIME mapping (raised by Boris):

 


e. Zip files and Encoding:

 


4. API and Events spec: getting to FPWD:

 

5. Widget Testing: Marcos' proposal to organize the test suite by spec:

 


6. AOB

a. Proposal to change VC time to one hour earlier.

Re: [widgets] Removing plugins attribute

[Arthur Barstow]

Marcos, All,

On Jan 22, 2009, at 9:16 AM, ext Marcos Caceres wrote:



In the P&C 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 requirements, I agree this should be removed  
from P&C v1.


-Regards, Art Barstow

Re: [selectors-api] SVG WG Review of Selectors API

[Lachlan Hunt]

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
not(timesheet) animation" (all SVG but not SMIL animations), or
"select[bind], select[ref]" (xforms selects)
I think that those example are even easier to rewrite as
"svg|*[href]", "svg|animation", "xforms|select", provided a reliable
namespace binding mechanisms (the one I proposed)


The use case should try to answer the following questions.  Try to be as 
specific and realistic as possible, and provide links to real world 
examples if you can.


Let's go with the first example you gave of selecting all SVG links: 
"svg :not(foreignObject) *[href]".


Note that the example selector provided won't actually work to select 
all SVG links, at least not in the general case.  The only way that 
could work is like this:


"svg>:not(foreignObject)>[href],
 svg>:not(foreignObject)>:not(foreignObject)>[href],
 svg>:not(foreignObject)>:not(foreignObject)>:not(foreignObject)>[href],
 ..."


1. Why is the author mixing SVG and, presumably, HTML in this case?  I 
know there are use cases for this in general, but we should be specific 
about which.


2. Why does the SVG contain links?  This may be partially answered by 
the previous question.  Preumably this means that it's not meant as a 
purely decorative image and the links provide the user with something 
useful.


3. Why does the SVG image contain links using elements from a foreign 
namespace in addition to links using elements from its own namespace?


4. What is the author trying to achieve using a script that needs to 
obtain those links, and why does it only affect links from the SVG 
namespace, and not all links within the SVG image, including those from 
other namespaces within ?


If you can think of any other questions, feel free to ask them and 
answer them.  The more information we have about the use cases, the 
easier it will be to evaluate them and find an appropriate solution.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: Request for Comments: Last Call WD of Widgets 1.0: Packaging & Configuration spec; deadline 31 Jan 2009

[Boris Zbarsky]

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

Re: [selectors-api] SVG WG Review of Selectors API

[Boris Zbarsky]

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)


I should note that that selector doesn't actually work to select things 
that are not inside a foreignObject...  Offhand, I see no way to do 
that, in fact.



1) discussion of pros and cons of available technologies (don't use
functions or objects to avoid infinite loops or recursion, don't use
string to avoid syntax problems), it looks that a NSResolver object (a
wrapped hash map, not an interface for a js function like
XPathNSResolver) is the best solutions


Would you be willing to expand on why you think that's the best 
solution?  (Maybe it is; I'd just like to know the analysis that led to 
this decision.)


It would be really nice to make progress here, since I do think that 
namespace support in Selectors API would be quite useful for the SVG case...


-Boris

Re: Request for Comments: Last Call WD of Widgets 1.0: Packaging & Configuration spec; deadline 31 Jan 2009

[Boris Zbarsky]

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 checkers should warn authors when their icons don't conform
to SVG tiny 1.2.  


Note that SVG Tiny 1.2 is not a subset of SVG 1.1, by the way...  I'm 
not sure whether that should affect this section; just pointing it out.


I think it makes more sense to just allow widget engines to implement 
whatever SVG version they want (as in, place no restrictions on it, past 
the fact that .svg files should be processed per the image/svg+xml MIME 
type registration).



Correct. So what is wrong with limiting sniffing to the table in the spec?


Nothing.  In fact it's highly desirable.


Or to the content-sniffing internet draft I pointed you to earlier?... I'm
not sure I'm understanding what you want me to specify here.


I was just pointing out that current implementations of something like 
widgets which don't use a MIME manifest or some such use an alternate 
system (aggressive extension sniffing) that we don't want to use here.



Understood. However, wouldn't you have to deal with the fact that
non-conforming zip implementations are used to create the widgets in the
first place. 


That's a good question, actually.  I'm not sure I have enough of a grasp 
of the issue to tell you what this would mean for a widget UA in 
practice



Do we have any data to support this supposition?  That's certainly how
things work with web pages, and in small market segments like Western
Europe there are multiple encodings in common use (ISO-8859-1 and
UTF-8).  


No, not directly. I only have anecdotal evidence: a podcast from the Harvard
Business Review about globalization and the internet, but I don't have a
pointer. In that podcast, some research was presented that indicated that
only 15% of internet traffic actually leaves the boundaries of a country and
is decreasing. That means that 85% or more of all communication would, in
theory, be done using the same language and, by extension, the same
character encoding.


Unfortunately, the language to character encoding mapping is not 
one-to-one...  See above about Western Europe.



I reached similar conclusions through my own testing/research [1]. Note that
on Mac it is apparently some proprietary variant of UTF-8 in fully
decomposed canonical form. I'm not sure what different flavors of Linux use


Nowadays UTF-8 for the most part, at least for new data being created.


but again: things seem bad on the file name encoding front. In essence, you
can't share Zip files across OS if they contain characters outside the ASCII
range.


This seems like a problem to me...


By "reality" I meant the reality about zip implementations - i.e., no
respect for encodings.


OK.


MHTML *may* be more technically superior and architecturally better, but
there is more tool support for Zip than MTHML. AFAIK, MHTML packaging tools
do not ship with any operating system. Zipping tools do.


Quite true.  At the same time, we're discussing the fact that once you 
want non-ASCII filenames the zip tools hinder more than help, right?



I don't have any statistics, but I assume Zip is used around the world - I
mean the fact that it is a standard tool on all OS has to mean something
significant.


True.


Also, Mozilla uses it to ship add-ons right? What, if any,
problems have you guys experienced wrt to zip in internationalized contexts?


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.



Again, I'm not sure how to proceed.


That really depends on how much you care about allowing any ZIP 
implementation to be used for creating widgets vs how much you care 
about internationalization issues that might arise as a result...



"In result, excluding any U+0020 SPACE characters, convert any sequence of
one or more characters marked with the [Unicode] property "White_Space" into
a single U+0020 SPACE."

The next step collapses sequences of two or more U+0020 SPACE into a single
U+0020 SPACE.


Sounds great.

-Boris

Re: [selectors-api] SVG WG Review of Selectors API

[Giovanni Campagna]

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 example to disable them and to create a little popup,
like GMail in editing mode does)
the same applies obviously for any element: different elements need a
way to be selected differently.
Reasons may be various: if I want to submit xform using xhr, I must
differentiate between html select and xforms select (this is a
concrete use case). If I want to imperatively animate xhtml links (to
do something more complex than declarative animations and to avoid
putting any element in a dedicated svg) i need to fetch all links
(*[href]) in the xhtml namespaces.

Even if there weren't use case (but there are), we should not
constrain the features of language. Newer authors, with newer ideas
and newer languages, will thank us if we put namespace support in
selectors API.

Giovanni

2009/1/28 Anne van Kesteren :
> On Wed, 28 Jan 2009 15:28:42 +0100, Giovanni Campagna
>  wrote:
>>
>> @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 SVG but not SMIL animations), or
>> "select[bind], select[ref]" (xforms selects)
>> I think that those example are even easier to rewrite as
>> "svg|*[href]", "svg|animation", "xforms|select", provided a reliable
>> namespace binding mechanisms (the one I proposed)
>
> Well, a) that's quite an assumption which needs to be elaborated on somehow
> and b) those are indeed examples of things you can select easier with
> namespace support but it is not at all clear why you want to do such a thing
> in the first place. I.e. they are not use cases.
>
>
> --
> Anne van Kesteren
> 
> 
>

Re: [selectors-api] SVG WG Review of Selectors API

[Anne van Kesteren]

On Wed, 28 Jan 2009 15:28:42 +0100, Giovanni Campagna  
 wrote:

@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 SVG but not SMIL animations), or
"select[bind], select[ref]" (xforms selects)
I think that those example are even easier to rewrite as
"svg|*[href]", "svg|animation", "xforms|select", provided a reliable
namespace binding mechanisms (the one I proposed)


Well, a) that's quite an assumption which needs to be elaborated on  
somehow and b) those are indeed examples of things you can select easier  
with namespace support but it is not at all clear why you want to do such  
a thing in the first place. I.e. they are not use cases.



--
Anne van Kesteren

Re: [selectors-api] SVG WG Review of Selectors API

[Giovanni Campagna]

@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 SVG but not SMIL animations), or
"select[bind], select[ref]" (xforms selects)
I think that those example are even easier to rewrite as
"svg|*[href]", "svg|animation", "xforms|select", provided a reliable
namespace binding mechanisms (the one I proposed)


@Lachlan:
I read all the old topic, the main points are:
1) discussion of pros and cons of available technologies (don't use
functions or objects to avoid infinite loops or recursion, don't use
string to avoid syntax problems), it looks that a NSResolver object (a
wrapped hash map, not an interface for a js function like
XPathNSResolver) is the best solutions
2) discussion of use cases for namespace resolution: authors are not
required to use javascript libraries (like Anne suggests), but current
workarounds are difficult, so use cases exist
3) decision to drop namespace support in current version: my proposal
is not necessarily for current version, but in version 2 (or level 2)
of selectors api we definetely need it.

Re: [selectors-api] SVG WG Review of Selectors API

[Lachlan Hunt]

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 technical reasons and lack 
of use cases.  For a discussion of alternatives, see the thread 
beginning this message:


http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0115.html


Hope you'll put this feature at least in version 2 of Selectors API,
or people will go back to XPath.


It would really help a lot if those who believe being able to resolve 
namespaces is an important feature, could document clear use cases that 
cannot be solved easily without, or would be solved more easily with, 
support for namespaces.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api] SVG WG Review of Selectors API

[Anne van Kesteren]

On Wed, 28 Jan 2009 14:32:05 +0100, Giovanni Campagna  
 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
optimized in UAs.


Ok. I note that in your original e-mail you did not explain why authors  
would go back to XPath if we did not give namespace support in the next  
version of the API. Do you expect that namespace usage which requires  
using namespaced selectors will increase significantly in the upcoming  
years justifying the added complexity? And if you do expect that, why?


Although namespace support was dropped in part because of technical  
issues, not having compelling use cases is something I think we should  
overcome first. Because if there are no compelling use cases, making the  
API more complex is not worth it.



--
Anne van Kesteren

Re: [selectors-api] SVG WG Review of Selectors API

[Giovanni Campagna]

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 :
> On Wed, 28 Jan 2009 14:25:29 +0100, Giovanni Campagna
>  wrote:
>>
>> Hope you'll put this feature at least in version 2 of Selectors API,
>> or people will go back to XPath.
>
> If that were the case, why would they switch in the first place?
>
>
> --
> Anne van Kesteren
> 
> 
>

Re: Using W3C widgets in a web container: two implementations contrasted

[Marcos Caceres]

Hi Scott,
On Wed, Jan 28, 2009 at 9:51 AM, Scott Wilson
 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 browsers will block any cross-domain
> Javascript requests, and this will apply in all cases where a Widget is
> making use of an external web API (e.g., a weather API, or external RSS
> feed). The only other options are:
>
> (1) always use JSONP calls instead of regular AJAX - but this requires
> changes at the service endpoint to support JSONP, which isn't really the
> widget ethos, which is about exposing web services in new ways without
> redesigning the services themselves
> (2) constrain widgets to only invoke web services from within the same
> domain that hosts the widget - but this is extremely limiting, and couples
> the widget engine host to the web API host.
> (3) have widgets invoke external requests via a server-side proxy offered in
> the same domain as the widget engine that is serving the widget
>
> If the W3 work on access policy - for allowing read-only AJAX requests -
> gets built into browsers, then the requirement for server-side proxies for
> web widgets may be less in the future, as most widgets only make GET
> requests to external web services.
>
> Note that Google also implements a server-side proxy for Gadgets to access
> external content, with the method "_IG_FetchContent(url, callbackFunc)",
> which is similar to the Palette approach.

Ok, I see where you are coming from now. Our definition of widget is
different. Please see the Differences from Web Widgets section in the
Widgets Landscape document [1]. Our intention is to allow the
interactions you describe to occur on the client side without
requiring assistance from the server side.

Kind regards,
Marcos

[1] http://www.w3.org/TR/widgets-land/#differences


-- 
Marcos Caceres
http://datadriven.com.au

Re: [selectors-api] SVG WG Review of Selectors API

[Anne van Kesteren]

On Wed, 28 Jan 2009 14:25:29 +0100, Giovanni Campagna  
 wrote:

Hope you'll put this feature at least in version 2 of Selectors API,
or people will go back to XPath.


If that were the case, why would they switch in the first place?


--
Anne van Kesteren

Re: [selectors-api] SVG WG Review of Selectors API

[Giovanni Campagna]

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, and their values are their URI. Invalid properties (whose
name doesn't match the production for a namespace prefix in Namespaces
in XML or whose value is not an URI) are simply ignored.
That is, for any enumerable property in the new argument, a @namespace
declaration will be implied. No other information will be considered
(such as inherited bindings or @namespace declarations outside), any
prefix not bound at selector resolution will cause a NAMESPACE_ERR.

1) people consider it adequate etc: well, it is easy to do (just
{xhtm: "http://www.w3.org/1999/xhtml";, svg:
"http://www.w3.org/2000/svg"; }) and poweful
2) don't have security issues: are there any security issues with
namespaces in general?
3) don't have undefined behaviour: as I said, it acts like an implied
sequence of @namespace, whose are fully covered (in good and bad
behaviour) by Namespaces in CSS

Hope you'll put this feature at least in version 2 of Selectors API,
or people will go back to XPath.

Giovanni

Re: Request for Comments: Last Call WD of Widgets 1.0: Packaging & Configuration spec; deadline 31 Jan 2009

[Marcos Caceres]

Hi Boris, 
On 1/23/09 2:25 PM, "Boris Zbarsky"  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 text
>> incorrectly). Can you please suggest some text that we could use?
> 
>"There may be implementation-specific limits on the range of
> integers allowed, and behavior outside such limits is undefined."
> 
> is one option.

Sounds good. Added that to the spec as a note in the relevant section.

You should probably tell the HTML5 guys about this too, as it may be
relevant there. 
 
>>> 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).
>>   2. For the purpose of widgets, icons are written by authors to
>> conform to SVG Tiny (not full)
>>   3. Widget engines that support full, can render icons in SVG Tiny...
>> but, for interop, widget engines should not render icons written in
>> SVG Full 1.1 (unless the icon also conforms to SVG Tiny).
> 
> Goal 3 is what my original comment was about, basically.  It means that
> a widget engine cannot make use of various existing SVG implementations
> that just happen to support more than just SVG Tiny.  In particular, it
> means that Gecko, say, would not be able to implement this specification
> without sprinkling code all over to validate SVG files against SVG Tiny
> (something we don't plan to do, since that's not the profile we're
> implementing).
> 
> I understand where you're coming from with this goal, but I'm not sure
> it's worth the restriction it imposes.
> 
> Things will get even worse once SVG Tiny 1.2 is a REC, since at that
> point I fully expect pretty much all SVG engines supporting SVG Tiny to
> implement that specification, and at that point there will be no SVG
> engines that can be used for Widgets at all (since all of them will
> render things that are not valid SVG Tiny 1.1).
> 
> So unless you really mean to exclude SVG engines that happen to
> implement SVG Full 1.1, SVG Tiny 1.2, SVG Basic 1.1 from being used in
> widget implementations (possibly forcing the widget UA to ship two
> separate SVG engines, one for widgets and one for everything else it's
> doing), I think you should drop goal 3 and leave the authoring requirement.
> 
> That is, just have image/svg+xml work the same way in Widgets as it does
> over HTTP, with the authoring requirement, presumably enforced by
> validators of widgets but not widget UAs, that the images conform to SVG
> Tiny (1.1 or any version; up to you).

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 checkers should warn authors when their icons don't conform
to SVG tiny 1.2.  

>>> Sure.  I have no real opinions on the form this would take, to be honest.
>> 
>> Just to be clear, do you feel strongly that this should be a feature
>> in Widgets 1.0?
> 
> I'd think so, yes.  That would make it much easier to migrate existing
> web content into widgets as needed...

Ok. I have asked the chair add this to this week's teleconf agenda so the
group can make a final decision about this. I'm unsure as if I _personally_
want to support this for version 1.0, but will certainly want to see this in
version 2.0. Other members of the working group might want this, but none
who are actually implementing have asked for it so far. My concern is that
we will enter a world of hurt if we introduce this feature because we will
have to deal with all sorts of additional MIME related issues. However, if
it turns out that just defining a manifest format as I proposed in the
previous email is all that is needed, then this could be doable for 1.0.
 
>>> A number of them presumably do sniffing by extension.  Gecko certainly does
>>> for its jar: handling.  This specification explicitly prohibits that,
>>> though.
>> 
>> Sorry, I don't understand - we make file extension to MIME mapping a
>> priority over sniffing: Step 1  of section "Rules for Identifying the
>> MIME Type of a file" reads as follows:
>> 
>> "1. If the file entry has a file extension, attempt to match the file
>> extension to one in the first column in the file identification table.
>> If there is a match, then return the MIME Type value. "
> 
> When I say "sniffing by extension" I don't mean that table.  I mean
> looking for an extension-to-type mapping anywhere it can be found.  For
> example, Gecko will look in some built-in tables it has, in user
> preferences, in the list of past files the user has opened in helper
> applications, in the extension lists that NPAPI plug-ins install, and 

Re: [selectors-api] SVG WG Review of Selectors API

[Erik Dahlström]

On Wed, 28 Jan 2009 10:55:49 +0100, Henri Sivonen  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=])".
>
>
> To select SVG elements while avoiding HTML elements of the same name,
> a selector that prohibits the local name foreignObject between an
> ancestor svg element and the selector subject would be good enough.

That wouldn't work for the general case though, since XML elements can occur 
anywhere in the svg markup. For an example, see Sun's Lively kernel[1].

But it's likely that there are selectors that would work for a majority of 
cases. Your statement does require that namespaces are not supported in the 
markup where the selectors API is used, or that it's guaranteed that no such 
markup occurs even though it may be permitted. Also such elements may be 
inserted through DOM calls, making the assumption about 'foreignObject' 
encapsulation invalid.

Cheers
/Erik

[1] http://research.sun.com/projects/lively/index.xhtml

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Re: [selectors-api] SVG WG Review of Selectors API

[Henri Sivonen]

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=])".



To select SVG elements while avoiding HTML elements of the same name,  
a selector that prohibits the local name foreignObject between an  
ancestor svg element and the selector subject would be good enough.


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: Using W3C widgets in a web container: two implementations contrasted

[Scott Wilson]

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  
where a Widget is making use of an external web API (e.g., a weather  
API, or external RSS feed). The only other options are:


(1) always use JSONP calls instead of regular AJAX - but this requires  
changes at the service endpoint to support JSONP, which isn't really  
the widget ethos, which is about exposing web services in new ways  
without redesigning the services themselves
(2) constrain widgets to only invoke web services from within the same  
domain that hosts the widget - but this is extremely limiting, and  
couples the widget engine host to the web API host.
(3) have widgets invoke external requests via a server-side proxy  
offered in the same domain as the widget engine that is serving the  
widget


If the W3 work on access policy - for allowing read-only AJAX requests  
- gets built into browsers, then the requirement for server-side  
proxies for web widgets may be less in the future, as most widgets  
only make GET requests to external web services.


Note that Google also implements a server-side proxy for Gadgets to  
access external content, with the method "_IG_FetchContent(url,  
callbackFunc)", which is similar to the Palette approach.


Scott

On 27 Jan 2009, at 22:51, Marcos Caceres wrote:




Our concern in our implementations was to run in existing
browsers, hence the proxy solution... But maybe I misunderstand  
what you

call the "widget engine" in your sentence ?


I was envisioning that a widget engine would leverage browser
technology and would have the appropriate modifications made to allow
the functionality required by the specification. Whether it is
possible to do this is an implementation detail, but what is in the
spec must certainly be able to happen in reality. I haven't built a
widget engine, but I assume that it must be possible to modify a
widget engine to only access a predefined set of domains without
requiring a server-side proxy.