Re: Are web components *seriously* not namespaced?
Glen -
Glenn has the answer.
So we're going to come up with yet-another-registry rather than use one
that already exists and guarantees (at least as far can be guaranteed)
uniqueness: DNS.
The ramifications of not making HTML5 be XHTML5 will be with us for a very
long time indeed.
Cheers,
- Bill
On Wed, Feb 4, 2015 at 3:41 PM, Dimitri Glazkov dglaz...@google.com wrote:
The proposed solution is using registries:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578
The registry API hasn't been spec'd yet.
:DG
On Wed, Feb 4, 2015 at 1:31 PM, Glen glen...@gmail.com wrote:
I know I'm rather late to the party, but I've been doing a lot of reading
lately about web components and related technologies, and the one thing
that confounds me is the fact that web components appear not to have any
real namespacing.
Can someone explain why this is so, and what the justification is? Or is
it just a case of it was too complicated, this is good enough?
I see this has been brought up once before @
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
but nothing changed.
It's not going to be long before x-tabs has been defined by 1,000,000
people (slight exaggeration), and you have no idea what it is or where it
came from without looking through imports/scripts etc. Also you want to
keep things short, so you call your element ms-panel (you work for Monkey
Solutions LLC), but then someone else on the team is importing ms-panel
from Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
!-- /scripts/monkey-solutions/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://monkey-solutions.com/namespace;
});
/script
!-- /scripts/microsoft/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://microsoft.com/namespace;
});
/script
!-- Uses last defined element, as it currently works. --
ms-panel
!-- Redefine the namespace prefix for one of the custom elements. --
element name=panel namespace=https://microsoft.com/namespace;
prefix=msft /
ms-panel
msft-panel
You could also assign a prefix to all elements within a namespace like
this:
element name=* namespace=https://microsoft.com/namespace;
prefix=msft /
You can override the prefix multiple times and the closest element
definition is used.
Please note that the above syntax is just an example of what could be
used.
Another BIG pro here is that IDEs can pull in information about the
elements by sending an HTTP request to the namespace URI so that a tooltip
could be displayed with an element description, author, sample usage, etc.
I really do hope that it's not too late to make such a change.
Regards,
Glen.
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
All - I'm going to throw my 2 cents in here and say that, whatever ends up happening with scoping, that the equivalent of the current querySelector()/querySelectorAll() should be named matchesSelector(). As a longtime Web developer (and trainer of other Web developers) it is important to me to have consistency in naming above all else. JS libraries can always alias / wrap these names should they so desire. Name shortening has already been occurring... if we had followed 'old W3C DOM-style naming', querySelectorAll() would've been 'documentGetElementsBySelector()'. Providing a balance between short names and descriptive names is important. One of the things that drives me nuts about the (non-standard) 'document.evaluate()' call (exists on FF / Webkit to query using XPath), is that it is not explicit enough... 'evaluate' what? JS? XPath? CSS? While I don't disagree that shorter names could've been chosen all of those years ago, as Austin Powers would say, That train has sailed, baby... Cheers, - BIll On Nov 25, 2011, at 8:04 AM, Sean Hogan wrote: On 25/11/11 6:49 PM, Lachlan Hunt wrote: On 2011-11-25 01:07, Sean Hogan wrote: On 24/11/11 7:46 PM, Lachlan Hunt wrote: On 2011-11-23 23:38, Sean Hogan wrote: - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. The matches method will not change behaviour depending on whether or not there is an explicit :scope because it is always evaluated in the context of the entire tree. There is never an implied :scope inserted into the selector, so there will not be two alternative matches methods. If and when there is a need for a matching method that does imply :scope (which I provided a use-case for in http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html) then it could be called matches(). Oh, it wasn't clear that you were talking about a case involving explicit reference nodes before. But adding two separate methods that are only subtly different would add more complexity for authors, since the difference will not always be obvious where there is no explicit reference nodes supplied and they may get them confused. In fact, with a method that always prepends :scope, it could result in an unexpected result in some cases: e.g. root.matches(html.foo); root.matchesSelector(html.foo); These aren't obviously different, but when you consider that the first would always prepend :scope under your proposal, the first would unexpectedly return false, since it's equivalent to: root.matchesSelector(:scope html.foo); This would happen whether the root element is the root of the document, or the root of a disconnected tree. We could instead address your use case by implying :scope if a refElement or refNodes is supplied. That way, if the author calls .matches() without any refNodes, they get the expected result with no implied :scope. If they do supply refNodes, and there is no explicit :scope, then imply :scope at the beginning. This approach would be completely backwards compatible with the existing implementations, as nothing changes until refNodes/refElement and :scope are supported. You mentioned this before, but anyway: el.matches(div span) - ok el.matches( div span) - throws, because no :scope implied el.matches(div :scope span) - ok, but can't match anything el.matches( div span, refNode) - ok el.matches(div :scope span, refNode) - ok el.matches(div span, refNode) - what does this do? How do you know that the intention isn't to just ignore the refNode if there is no explicit :scope? I guess if you wanted this last behavior, you could call something like /:scope\b/.test(selector) before-hand and if it is false then not pass the refNode to matches(). I'm not sure if there are other problematic cases. Sean
Client-side cross origin
All - As a longtime developer of client-side Web applications, I have longed for such a mechanism that would allow the user to explicitly opt-in to allow cross-origin access. This access would be: * explicit opt-in * per site I can imagine a user scenario thusly: - User loads page from SiteA - Page from SiteA tries to access a 'web service' on SiteB. - Browser prompts user and says This page would like to access a service on SiteB. - If user approves, the browser allows the cross-origin request. - Security as far as SiteB is concerned should be implemented by SiteB... it is SiteB's responsibility for having made such a service available on the web. The browser may assist by passing along credential information, etc. of the current user to SiteB. In any case, SiteB has no additional configuration to do like is currently required with CORS. As far as SiteB is concerned, this call could be coming from another server - as long as the login/security credentials prove out, it doesn't matter. Right now, Mozilla via signed scripts and IE via a popup dialog (not XDomain request here - the old 'cross-origin' stuff IE has) provide some measure of cross-origin access from the browser side. Chrome, via an extension, allows cross-origin and so does Mozilla. The problem with Mozilla's current signed script solution is that it is cumbersome, doesn't give the user enough information and is going away in future Mozilla releases. It also provides no credential information to the server being called. The problem with IE's non-XDomain solution is that it also gives the user very little information other than 'a cross-site request is being made' and also provides no credential information to the server being called. The problem with Mozilla's and Chrome's extension version is that its an additional install for users of the page in question and also provide no credential information to the server being called. So far, CORS is the most widely implemented standard, but has the unfortunate side effect of requiring additional server-side configuration over and above whatever security mechanisms the service vendor (i.e. SiteB in this scenario) has had to configure to make their service available on the Web in the first place. My feeling is that there is a 'pure client side' solution here and that specifying this sort of capability is within the purview of this group. Thoughts? Cheers, - Bill On May 11, 2010, at 8:53 AM, Boris Zbarsky wrote: That's a different situation. That would require explicit opt-in from the user. In fact, imo it would require explicit opt-in to even see the question being asked. -Boris
Re: [widgets] Widgets URI scheme... it's baaaack!
Arve - Getting the value of 'src' here using 'document.images[0].getAttribute(src)' should return the relative path. The Microsoft guys made a big deal out of the fact that IE8 (in IE8 'strict standards' mode) will now properly return the relative path when 'getAttribute()' is used, but the full path (as you state), when the 'property access' version of the call is used. In IE 8, some extra JS to determine base path and then relativize the value would be necessary in those browsers. Cheers, - Bill On May 22, 2009, at 2:22 PM, Arve Bersvendsen wrote: On Fri, 22 May 2009 20:21:56 +0200, Mark Baker dist...@acm.org wrote: I thought he had (somewhat grudgingly) accepted that way (the use of relative references) forward, as IIRC, the widget: scheme idea was dropped about that time. Has some new requirement emerged since then that makes relative references an undesirable option? The problem here is that no user agent implementation I am aware of uses 'relative' URIs when resolving nodes. If you provide img src=foo/bar/baz.png / - they all compose an absolute URI from the string representing the relative URI, and expose that when you query for the attribute value, so putting my markup fragment into a document at the root of http://example.com/: html img src=foo/bar/baz.png / script // The following Outputs http://example.com/foo/bar/baz.png alert(document.images[0].src); /script -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
CORS for file-based web apps
Folks - First, my apologies if this topic has been discussed before. If so, just point me to the relevant part of the spec or discussion and I'll go away :-). I also apologize if this is the wrong group for this question. If so, point me to the correct one. I haven't been able to find any information on my question in either the spec or in multiple web searches. In our customer base, we're increasingly seeing the following scenario. By way of introduction, I need to impart that these folks are looking to use a web browser, with its attendant well-known technologies, as a replacement for writing apps in tools such as VB or Delphi. In other words, to them, a web app might or might not have anything to do with loading the app from an HTTP server - to them a 'web app' is one authored with the technologies a browser innately understands - JS, CSS, HTML, XML. So, the scenario is a user who has a full copy of their app as a set of pages / JavaScript on their hard drive. They launch their app by double-clicking on an 'index.html' from the file system and the app runs. The app has now been loaded from a 'file://' URL. The user would then like to access data from an http:// URL. This is currently possible from both Mozilla/Firefox and IE, via proprietary mechanisms that allow 'cross-domain' access (i.e. in this case from a 'file://' domain to an 'http://' domain). It is understood and accepted by the user base that they may see a security prompt in this scenario. So, the question is how CORS might work in such a scenario. For the Webkit/Safari/Chrome class of browsers, there is currently no equivalent proprietary 'cross-domain' functionality, thus hampering our ability to deploy to these browsers. I've tried a few of the CORS examples out there, and they all fail in this scenario (load the page containing the JS code from the 'file://' system and try to access the test server). Any thoughts or assistance here would be greatly appreciated! Cheers, - Bill
