webcomponents: import instead of link
Just after started prototyping HTML Imports on Blink, this idea comes to my mind: Why not have import for HTML Imports? The good old link has its own semantics which allows users to change the attributes dynamically. For example, you can change @href to load other stylesheets. @type can be dynamically changed as well. In contrast, importing HTML document is one-shot action. We don't allow updating @href to load another HTML. (We cannot do that anyway since there is no de-register of custom elements.) This difference will puzzle page authors. And an implementer (me) is also having troubles... Current link implementation is all about dynamic attribute changes. disabling its dynamic nature only with @rel=import seems tricky. Well, yes. I can just refactor the code. But this complication implies that making it interoperable will be a headache. There will be many hidden assumptions which come from underlying link implementation. For example, what happens if we update @rel from import to style after the element imported document or vice versa? We need to clarify all these cases if we choose link as our vehicle. It seems burden for me. Using new element like import doesn't have such issues. We can just define what we need. Also, we'll be able to introduce import-specific attributes like @defer, @async or even something like @sandbox without polluting link vocabulary. One downside is that we'll lose the familiarity of link. But having indirection like the Import interface smells like we're just abusing it. What do you think? Is this reasonable change or am I just restarting something discussed before? -- morrita
Re: A very preliminary draft of a URL spec
On Mon, 13 May 2013 17:25:23 +0100, Anne van Kesteren ann...@annevk.nl wrote: On Sun, May 12, 2013 at 8:34 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: So far I have done nothing at all about an API, and am waiting for some formal confirmation from people who implement stuff that they would like to standardise an API for dealing with URLs. It seems to be a common task, judging from the number of people who seem to have some scrap of code lying around for it, so I expect to hear people say Yes, great idea - although I have been surprised before. Given that you're questioning this, I am not questioning whether it is a good idea. I am checking that it will actually get implementation - since a spec of things we think people should do, but they don't and probably won't is just an idea written down. Personally I don't think the Web is just what browsers will implement, since there are things (like microdata) that don't really need the browser at all in order to be important to the web. But in this case, as with most APIs I think browser implementations are particularly important. maybe you want to study HTML's dependencies. Sure, but making life easier for spec authors is not directed at the highest priority group in the hierarchy of audiences (much as I want to do it). It seems that's a problem overall. This draft doesn't go into detail about any of the problems for which HTML started defining URLs by itself in the first place. Sure. As I noted, it is extremely rough, and it is definitely missing more than it includes at this stage. What's wrong with the http://url.spec.whatwg.org/ URL standard. 1. It is apparently not intended to become a stable reference that can be used in situations where fixing every edge case is less important than fixing the content we agree we are looking at. 2. It provides extremely detailed algorithms that certain classes of tools require to work with URLs, at the expense of an easily-read explanation of what is and isn't a URL. 3. It does not provide any kind of license commitment from anyone likely to have patents on the technology described. The first two of these are only problems from a specific set of perspectives, but those perspectives happen to be ones that match real existing needs. I believe that the third is a non-issue in practical terms, given that most of what is specified has been around for long enough to ensure the existence of prior art, but it doesn't hurt to be surer about this. Not invented here? Ironically (given the history of URLs as used on the Web today), that is indeed a defensible explanation of one issue. For reasons including stability of the document content, WHAT-WG living standards are not suitable as normative references for W3C Recommendations. As you note, HTML essentially depends on having a sound reference. (For other mostly technical reasons I believe that RFC 3986 and perhaps to a lesser extent RFC 3987 are not especially suitable either, because the question is equally valid as to what is wrong with them). It is quite possible that the whole problem will go away, and one or more of these specifications will just happily disappear in deference to the rest. However, that's not currently the world we live in, and meeting W3C's interim need seemed a useful investment of some time. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
[Bug 22028] New: Consider adding hasComposition() in InputMethodContext
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22028 Bug ID: 22028 Summary: Consider adding hasComposition() in InputMethodContext Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: IME API Assignee: m...@w3.org Reporter: ko...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org As proposed by Microsoft: https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html#methods-1 consider adding hasComposition() interface in InputMethodContext. One clarification: If compositionText is empty, hasComposition() return true? If so, hasComposition() may not be necessary and you can only need compositionText. If not, in what case compositionText is empty but hasComposition() returns true, or compositionText is non-empty but hasComposition() returns false? -- You are receiving this mail because: You are on the CC list for the bug.
Re: Re: [XHR] anonymous flag
Does anyone have real, non-contrived use cases for the anonymous flag?
The basic idea was preventing confused deputy attacks by not exposing
any information that could be used as such. So no credentials and no
data about where the request originated from, forcing the architecture
to be token-based effectively.
I think the strongest use-case that I've been able to think of is to
enable a website to take a URL from an untrusted source and then
interact with that URL over HTTP.
I can see this as a conceptual or theoretical use case, but I'm not sure I can
come up with a real-life scenario where one might want to do this. I can see
some non-XHR use cases for expecting users to supply an un-trusted URL (Over
there is the custom style sheet or background image I want on my blog), but I
can't see any realistic XHR-based use case.
Say, for example, OpenID is a setup where the user might provide an untrusted
URL to a third-party web site (Here's the service that can authenticate me),
and XHR might be involved - but the Open ID *provider* would of course want to
know what site it is interacting with, to present some information about what
authenticating means to the user..
By removing both user credentials and website credentials the website
doesn't have to worry about confused-deputy problems. I.e. if website
A gets a URL from untrusted source B, A can then interact with that
URL without having to worry about that the server that it's
interacting with will think oh, this request is coming from A, it's
fine to trust it then. I.e. it doesn't have to worry about B tricking
it into taking actions which A has access to, but that B doesn't.
Let's call the third party site C, to go with the alphabet. C serves resources
with Access-Control-Allow-Origin: A.
B wants to either carry out an action or get content which B is not
authenticated to do, but C might be set up to allow for requests originating
from A. A already knows that B's cookies/HTTP auth/SSL credentials won't be
sent by default with the XHR request to the foreign URL. However, we expect A
to figure out and implement that it should also add an anonymous flag to its
XHR requests, to preemptively avoid attacks against C. How do you even start
explaining to authors when to use anonymous mode? Why doesn't the attacker B
simply type or paste a bookmarklet that triggers a non-anonymous XHR (or trick
the authenticated user of A into pasting one and sending the results)? Why
doesn't B just write a PHP script that fakes the Referer and Origin headers in
a request to C without involving A at all?
This doesn't need to be obviously harmful permanently delete files
types of actions. For those A would likely need to include some form
of credentials anyway since any server-to-server communication can
claim to be from A using origin/referer headers.
Indeed.
It can also be simpler things like throttling bandwidth if it's
getting too many requests from a particular source.
AFAIK here your assumption is that
- C is getting too many requests from B, starts blocking/throttling
- C still accepts requests from A (but not anonymous requests)
- A lets some user input a URL that it will *hammer* with XHR requests
- The developer working on A realises there is an exploit potential and
preemptively adds an anonymous flag
- C no longer accepts the requests B makes A make
Yay, all problems are resolved!? Hm.. My assumptions:
- Quite likely some or all of the resources A want to fetch are now unable to
detect that requests come from A, and hence stop serving them (or don't know
what value to put in the Allow-Origin header, amounting to the same thing),
- A's service becomes crippled.
- A developer gets support requests, regrets, and removes the anonymous flag
If C accepts anonymous requests in the first place, B can do anonymous requests
from its own site when C starts throttling based on origin. Or indeed do
backend requests with fake headers.
As far as I can tell, the problem we're trying to solve with the anonymous flag
is for all practical scenarios already solved by withCredentials. Any service
that's only protected by checking Referer and/or Origin header is already
really flawed and vulnerable to server-to-server attacks. These are much easier
to carry out than a try to find a web site that accepts third-party URLs for
XHR requests and has access to the 'protected' resources scheme.
Server-to-server attacks would not care about Access-Control-Allow-Origin
limitations either (indeed might just use the value as a source of information
when implementing the attack).
An {anonymous:true} flag in A's JS code is simply the wrong place to attempt to
fix any such vulnerabilities. We pay implementation complexity and gain, IMHO,
no protection.
Finally, I believe it's going to be virtually impossible to teach developers
how to use the anonymous flag, if our understanding of realistic (ab)use
Kickoff application manifest work
While we transition the application manifest spec from SysApps to WebApps, I'd like to kick off discussion by encouraging people to either discuss the current proposal here or over on GitHub. The current proposal can be found here: http://manifest.sysapps.org/ Repo is here: https://github.com/sysapps/manifest Things that we need to discuss: * what's the problem we are trying to solve? (scope for the work). * what actual manifest properties are useful? are any missing? * do any members need to be refactored to better meet the use cases? * how do we associate a manifest with a web page? * More open issues: https://github.com/sysapps/manifest/issues Following in the footsteps of Navigation Controller and DOM Futures, it would be ideal to have a core group of individuals helping out with this effort. If you want to be part of a core team, please let me know and I can add you on GitHub (or just add your self to watch the repository on https://github.com/sysapps/manifest) and file bugs/ask questions as you see fit. If you want to discuss the proposal directly with me, I'm marcosc IRC on both freenode (#whatwg) and w3c (#webapps). Kind regards, Marcos -- Marcos Caceres
Re: [widgets] Does anyone still care about Widget Updates?
Scott indicated [1] Wookie implemented Widget Updates and Chaals indicated [2] he would followup with Opera but I couldn't find a response from them in the list archive. Do we have two (complete?) implementations of the spec? Opera, Richard? It's not clear to me if we should drop this spec (i.e. publish as a WG Note) or if there are sufficient resource commitments to continue to advance it along the REC track. Marcos - what is the status of the test suite http://dev.w3.org/2006/waf/widgets-updates/test-suite/? (The Implementation Report doesn't look good http://dev.w3.org/2006/waf/widgets-updates/imp-report/.) -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0256.html [2] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0261.html On 10/20/12 8:12 AM, ext Arthur Barstow wrote: For various reasons, a Candidate Recommendation of Widget Updates was never published, although the CfC to do so passed and the ED is prepared as such [widget-updates]. Since no one has raised this as an issue, I would like feedback on what we should do with this spec. The main options are: 1) to stop work (and publish a WG Note); 2) to move forward with the CR. I don'tthink it makes much sense to move the spec to CR if we do not have commitments for at least two independent implementations of the CR. Therefore, Implementors should please speak up if they willcommit to implementing this CR. -Thanks, AB [widget-updates] http://dev.w3.org/2006/waf/widgets-updates/ Original Message Subject: CfC: publish Candidate Recommendation of Widget Updates; deadline May 2 Resent-Date: Thu, 26 Apr 2012 16:42:00 + Resent-From: public-native-web-a...@w3.org Date: Thu, 26 Apr 2012 12:41:34 -0400 From: ext Arthur Barstow art.bars...@nokia.com To: public-webapps public-webapps@w3.org CC: public-native-web-a...@w3.org The comment deadline for the Widget Updates LCWD ended April 19. No comments were submitted for that document so this is a Call for Consensus to publish a Candidate Recommendation of the spec using the LC as the basis http://www.w3.org/TR/2012/WD-widgets-updates-20120322/. The Exit Criteria for the CR will be the same as that used for the other widget specs, namely that two or more implementations must pass each test case. This CfC satisfies: a) the group's requirement to record the group's decision to request advancement to CR; and b) General Requirements for Advancement on the Recommendation Track as defined in the Process Document: http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs Positive response is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is May 2 and all comments should be sent to public-webapps at w3.org. -Thanks, AB
Re: [widgets] Does anyone still care about Widget Updates?
On Tuesday, 14 May 2013 at 14:32, Arthur Barstow wrote: Scott indicated [1] Wookie implemented Widget Updates and Chaals indicated [2] he would followup with Opera but I couldn't find a response from them in the list archive. Do we have two (complete?) implementations of the spec? Opera, Richard? It's not clear to me if we should drop this spec (i.e. publish as a WG Note) or if there are sufficient resource commitments to continue to advance it along the REC track. Marcos - what is the status of the test suite http://dev.w3.org/2006/waf/widgets-updates/test-suite/? (The Implementation Report doesn't look good http://dev.w3.org/2006/waf/widgets-updates/imp-report/.) -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0256.html [2] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0261.html Unless someone else wants to take this, I suggest we just publish as a note. -- Marcos Caceres
Re: CfC - working on manifest
On Tue, 14 May 2013 17:28:58 +0400, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi, at the face to face meeting we agreed to take back the work on a manifest specification for apps, based on the current manifest draft from sysapps [1] that was developed from the proposal [2] included in our charter [3], and to leave the runtime part of the work with Sysapps. This is a formal Call for Consensus on that resolution. Silence will be taken as assent. Responses will be accepted up to the end of the day Tuesday 21 May. Yandex (still) supports this... cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
RE: CfC - working on manifest
Chaals, Overall, I think we support this proposal but have some questions I would like to get clarifications on: Maybe I don't recall but is SysApps asking Webapps to take the manifest aspect? Or is this something Webapps thinks is its right because of the prior focus on Widgets packaging? I don't recall case of a group unilaterally taking back something similar to something else it had worked on in the past. If SysApps did approve but in the end disapproved with the result, what recourse would they have? Woudnt it be better to have this as a joint deliverable then? Thanks, Bryan Sullivan -Original Message- From: Charles McCathie Nevile [mailto:cha...@yandex-team.ru] Sent: Tuesday, May 14, 2013 6:29 AM To: public-webapps WG Subject: CfC - working on manifest Hi, at the face to face meeting we agreed to take back the work on a manifest specification for apps, based on the current manifest draft from sysapps [1] that was developed from the proposal [2] included in our charter [3], and to leave the runtime part of the work with Sysapps. This is a formal Call for Consensus on that resolution. Silence will be taken as assent. Responses will be accepted up to the end of the day Tuesday 21 May. for the chairs Chaals [1] http://manifest.sysapps.org/ [2] http: 404 (and people ask me why I care where things get published) [3] http://www.w3.org/2012/webapps/charter/Overview.html -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC - working on manifest
On Tue, 14 May 2013 18:39:34 +0400, SULLIVAN, BRYAN L bs3...@att.com wrote: Chaals, Overall, I think we support this proposal but have some questions I would like to get clarifications on: Minutes of the discussion, to help jog your memory: http://www.w3.org/2013/04/25-webapps-minutes.html#item04 (I apoogise for not linking those from the original CfC message). Maybe I don't recall but is SysApps asking Webapps to take the manifest aspect? Yes. Or is this something Webapps thinks is its right because of the prior focus on Widgets packaging? I don't recall case of a group unilaterally taking back something similar to something else it had worked on in the past. No, the idea is that we all agree on this. If SysApps did approve but in the end disapproved with the result, what recourse would they have? Comment on the spec and say that's terrible, it should be If necessary as formal objections to moving forward. As a practical matter I think nearly all of sysapps members are also represented in webapps. So I would be surprised if there were a real issue. Woudnt it be better to have this as a joint deliverable then? No, there is a handful of frustrating overhead to do that which, if it is as unnecessary as it seems in this case, the people who would have to deal with it (chairs, editors, staff contacts) preferred to avoid. Thanks, Bryan Sullivan -Original Message- From: Charles McCathie Nevile [mailto:cha...@yandex-team.ru] Sent: Tuesday, May 14, 2013 6:29 AM To: public-webapps WG Subject: CfC - working on manifest Hi, at the face to face meeting we agreed to take back the work on a manifest specification for apps, based on the current manifest draft from sysapps [1] that was developed from the proposal [2] included in our charter [3], and to leave the runtime part of the work with Sysapps. This is a formal Call for Consensus on that resolution. Silence will be taken as assent. Responses will be accepted up to the end of the day Tuesday 21 May. for the chairs Chaals [1] http://manifest.sysapps.org/ [2] http: 404 (and people ask me why I care where things get published) [3] http://www.w3.org/2012/webapps/charter/Overview.html -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
RE: CfC - working on manifest
Thanks for the clarifications - we support it. And I will try to do less multitasking at F2F's! Thanks, Bryan Sullivan -Original Message- From: Charles McCathie Nevile [mailto:cha...@yandex-team.ru] Sent: Tuesday, May 14, 2013 7:47 AM To: public-webapps WG; SULLIVAN, BRYAN L Subject: Re: CfC - working on manifest On Tue, 14 May 2013 18:39:34 +0400, SULLIVAN, BRYAN L bs3...@att.com wrote: Chaals, Overall, I think we support this proposal but have some questions I would like to get clarifications on: Minutes of the discussion, to help jog your memory: http://www.w3.org/2013/04/25-webapps-minutes.html#item04 (I apoogise for not linking those from the original CfC message). Maybe I don't recall but is SysApps asking Webapps to take the manifest aspect? Yes. Or is this something Webapps thinks is its right because of the prior focus on Widgets packaging? I don't recall case of a group unilaterally taking back something similar to something else it had worked on in the past. No, the idea is that we all agree on this. If SysApps did approve but in the end disapproved with the result, what recourse would they have? Comment on the spec and say that's terrible, it should be If necessary as formal objections to moving forward. As a practical matter I think nearly all of sysapps members are also represented in webapps. So I would be surprised if there were a real issue. Woudnt it be better to have this as a joint deliverable then? No, there is a handful of frustrating overhead to do that which, if it is as unnecessary as it seems in this case, the people who would have to deal with it (chairs, editors, staff contacts) preferred to avoid. Thanks, Bryan Sullivan -Original Message- From: Charles McCathie Nevile [mailto:cha...@yandex-team.ru] Sent: Tuesday, May 14, 2013 6:29 AM To: public-webapps WG Subject: CfC - working on manifest Hi, at the face to face meeting we agreed to take back the work on a manifest specification for apps, based on the current manifest draft from sysapps [1] that was developed from the proposal [2] included in our charter [3], and to leave the runtime part of the work with Sysapps. This is a formal Call for Consensus on that resolution. Silence will be taken as assent. Responses will be accepted up to the end of the day Tuesday 21 May. for the chairs Chaals [1] http://manifest.sysapps.org/ [2] http: 404 (and people ask me why I care where things get published) [3] http://www.w3.org/2012/webapps/charter/Overview.html -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [widgets] Does anyone still care about Widget Updates?
On May 14, 2013, at 11:00 PM, Marcos Caceres w...@marcosc.com wrote: On Tuesday, 14 May 2013 at 14:32, Arthur Barstow wrote: Scott indicated [1] Wookie implemented Widget Updates and Chaals indicated [2] he would followup with Opera but I couldn't find a response from them in the list archive. Do we have two (complete?) implementations of the spec? Opera, Richard? It's not clear to me if we should drop this spec (i.e. publish as a WG Note) or if there are sufficient resource commitments to continue to advance it along the REC track. Marcos - what is the status of the test suite http://dev.w3.org/2006/waf/widgets-updates/test-suite/? (The Implementation Report doesn't look good http://dev.w3.org/2006/waf/widgets-updates/imp-report/.) -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0256.html [2] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0261.html Unless someone else wants to take this, I suggest we just publish as a note. Publishing this as a WG note works for me. - Rich
Re: A very preliminary draft of a URL spec
On Tue, May 14, 2013 at 4:24 AM, Charles McCathie Nevile cha...@yandex-team.ru wrote: I am checking that it will actually get implementation - since a spec of things we think people should do, but they don't and probably won't is just an idea written down. Yeah, I think this shows that you have not actually checked HTML's dependencies and what is implemented today. a.protocol and such most definitely exist today and the way that is defined is through the URL Standard. And FWIW, the whole point of doing STD66 again is precisely about fixing edge cases and having that extremely detailed algorithm. If those did not matter we could just use STD66. -- http://annevankesteren.nl/
Re: webcomponents: import instead of link
On Tue, May 14, 2013 at 12:45 AM, Hajime Morrita morr...@google.com wrote: Just after started prototyping HTML Imports on Blink, this idea comes to my mind: Why not have import for HTML Imports? Because changing parsing for head is not done, basically. rel=import not being dynamic kinda sucks though. Maybe we should consider using meta? It has a bunch of uses that are non-dynamic. -- http://annevankesteren.nl/
Re: CfC: Face to face meeting on Components, 21 June
Thanks for the announcement, Chaals! Since we will only have a day for this Awesome Web Components Party (even less than a full day, technically), I want to narrow the topic down a bit to Shadow DOM and CSS interaction. Here's a quick problem statement. There are currently several places where Shadow DOM and CSS interact with each other: * The shadow tree encapsulation boundaries affect style resolution * There are switches, such as resetStyleInheritance that provide controls of how the style is affected * There's a new @host at-rule, which provides a way for a shadow tree to affect styling of the shadow host * There's a new ::distributed() pseudo-element function, which provides a way for a shadow tree to affect style of the elements, distributed into insertion points * There's a method for defining custom pseudo-elements As real Web developers started poking around the spec and implementation, a new set of questions/ideas arose (listed in no particular order): https://www.w3.org/Bugs/Public/show_bug.cgi?id=21391 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21486 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21959 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20600 https://www.w3.org/Bugs/Public/show_bug.cgi?id=18435 I thought it would be good to throw some CSS, Shadow DOM, and Web developer peeps into one large cauldron, season with whiteboards and felt markers, and stir it vigorously--while maniacally cackling, of course!--to see what new ideas could come out. :DG On Tue, May 14, 2013 at 6:19 AM, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi folks, Dmitry started talking to people about getting together in the Bay Area to talk through components, and ended up with a number of people interested. Although we are past the deadline for a normal meeting announcement, unless anybody objects it is still possible to hold an official meeting. This would let us use Zakim to provide remote dial-in, and the chairs feel that this is far better than simply having the meeting go ahead pretending not to be a webapps meeting. We are therefore calling for consensus to let this meeting go ahead despite the short notice. Silence will be considered assent, and responses will be taken up to the end of the day (midnight in the last timezone) Tuesday 21 May. Assuming we get the go-ahead, an agenda, dial-in details, etc will be made available, but the topic for the meeting is the Web Components work. for the chairs Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: webcomponents: import instead of link
On the second thought: why not make imports dynamic, just like stylesheets? :DG On Tue, May 14, 2013 at 11:29 AM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, May 14, 2013 at 9:35 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 14, 2013 at 12:45 AM, Hajime Morrita morr...@google.com wrote: Just after started prototyping HTML Imports on Blink, this idea comes to my mind: Why not have import for HTML Imports? Because changing parsing for head is not done, basically. rel=import not being dynamic kinda sucks though. Maybe we should consider using meta? It has a bunch of uses that are non-dynamic. I used link primarily because most of the link rel=stylesheet plumbing seems to fit best with link rel=import. Interesting idea about meta... :DG
Re: webcomponents: import instead of link
On Tue, May 14, 2013 at 12:42 PM, Dimitri Glazkov dglaz...@google.com wrote: On the second thought: why not make imports dynamic, just like stylesheets? Hajime seemed to have some concerns with unloading components. Kinda depends on how component construction is defined I suppose. -- http://annevankesteren.nl/
Re: webcomponents: import instead of link
http://w3cmemes.tumblr.com/post/34633601085/grumpy-old-maciej-has-a-question-about-your-spec On Tue, May 14, 2013 at 12:42 PM, Dimitri Glazkov dglaz...@google.com wrote: On the second thought: why not make imports dynamic, just like stylesheets? :DG On Tue, May 14, 2013 at 11:29 AM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, May 14, 2013 at 9:35 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 14, 2013 at 12:45 AM, Hajime Morrita morr...@google.com wrote: Just after started prototyping HTML Imports on Blink, this idea comes to my mind: Why not have import for HTML Imports? Because changing parsing for head is not done, basically. rel=import not being dynamic kinda sucks though. Maybe we should consider using meta? It has a bunch of uses that are non-dynamic. I used link primarily because most of the link rel=stylesheet plumbing seems to fit best with link rel=import. Interesting idea about meta... :DG
Re: webcomponents: import instead of link
I can't think of any reason I would want to be able to mess with an import link ex-post-facto and have it do anything. I would also expect any registrations to be final and have no particular connection to the link tag itself. Now, this may be tangential, but users definitely need a way of loading imports dynamically. I believe the current gambit would be to inject a fresh link tag into head, which seems like the long way around Hogan's barn. I've been meaning to ask about the possibility of an imperative 'import' method. On Tue, May 14, 2013 at 12:53 PM, Jonas Sicking jo...@sicking.cc wrote: http://w3cmemes.tumblr.com/post/34633601085/grumpy-old-maciej-has-a-question-about-your-spec On Tue, May 14, 2013 at 12:42 PM, Dimitri Glazkov dglaz...@google.com wrote: On the second thought: why not make imports dynamic, just like stylesheets? :DG On Tue, May 14, 2013 at 11:29 AM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, May 14, 2013 at 9:35 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 14, 2013 at 12:45 AM, Hajime Morrita morr...@google.com wrote: Just after started prototyping HTML Imports on Blink, this idea comes to my mind: Why not have import for HTML Imports? Because changing parsing for head is not done, basically. rel=import not being dynamic kinda sucks though. Maybe we should consider using meta? It has a bunch of uses that are non-dynamic. I used link primarily because most of the link rel=stylesheet plumbing seems to fit best with link rel=import. Interesting idea about meta... :DG
Re: webcomponents: import instead of link
On Tue, May 14, 2013 at 4:01 PM, Scott Miles sjmi...@google.com wrote: I can't think of any reason I would want to be able to mess with an import link ex-post-facto and have it do anything. I would also expect any registrations to be final and have no particular connection to the link tag itself. Now, this may be tangential, but users definitely need a way of loading imports dynamically. I believe the current gambit would be to inject a fresh link tag into head, which seems like the long way around Hogan's barn. I've been meaning to ask about the possibility of an imperative 'import' method. import is a FutureReservedWord that will be a Keyword as of ES6, so this import method would have to be a method of some platform object and not a method on [[Global]] object. Rick
Re: webcomponents: import instead of link
It's not clear to me why link rel=import can't be dynamic. As long as the previous document isn't somehow banished, I don't see the problem (admittedly, looking through a keyhole). On Tue, May 14, 2013 at 2:21 PM, Simon Pieters sim...@opera.com wrote: On Tue, 14 May 2013 23:13:13 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: On Tue, May 14, 2013 at 2:08 PM, Simon Pieters sim...@opera.com wrote: I have proposed script import=url/script instead of link rel=import href=url before. http://lists.w3.org/Archives/**Public/public-webapps/** 2013AprJun/0009.htmlhttp://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0009.html http://lists.w3.org/Archives/**Public/public-webapps/** 2013AprJun/0024.htmlhttp://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0024.html Benefits: * Components can execute script from an external resource, which script src can do as well, so that seems like a good fit in terms of security policy and expectations in Web sites and browsers. * script src is not dynamic, so making script import also not dynamic seems like a good fit. * script can appear in head without making changes to the HTML parser (in contrast with a new element). To pre-empt confusion shown last time I suggested this: * This is not script src. * This is not changing anything of the component itself. Both meta and script somewhat fail the taste test for me. I am not objecting, just alerting of the weakness of stomach. link rel=import has near-perfect semantics. It fails in the implementation specifics (the dynamic nature). Both meta and script are mis-declarations. An HTML Import is neither script nor metadata. That seems to be an argument based on aesthetics. That's worth considering, of course, but I think is a relatively weak argument. In particular I care about the first bullet point above. link is not capable of executing script from an external resource today. What are the implications if it suddenly gains that ability? -- Simon Pieters Opera Software
Re: webcomponents: import instead of link
I really didn't mean to suggest any particular name, just that an imperative form should be provided or every lib will roll their own. On Tue, May 14, 2013 at 1:45 PM, Rick Waldron waldron.r...@gmail.comwrote: On Tue, May 14, 2013 at 4:01 PM, Scott Miles sjmi...@google.com wrote: I can't think of any reason I would want to be able to mess with an import link ex-post-facto and have it do anything. I would also expect any registrations to be final and have no particular connection to the link tag itself. Now, this may be tangential, but users definitely need a way of loading imports dynamically. I believe the current gambit would be to inject a fresh link tag into head, which seems like the long way around Hogan's barn. I've been meaning to ask about the possibility of an imperative 'import' method. import is a FutureReservedWord that will be a Keyword as of ES6, so this import method would have to be a method of some platform object and not a method on [[Global]] object. Rick
Re: webcomponents: import instead of link
On Tue, 14 May 2013 09:45:01 +0200, Hajime Morrita morr...@google.com wrote: Just after started prototyping HTML Imports on Blink, this idea comes to my mind: Why not have import for HTML Imports? The good old link has its own semantics which allows users to change the attributes dynamically. For example, you can change @href to load other stylesheets. @type can be dynamically changed as well. In contrast, importing HTML document is one-shot action. We don't allow updating @href to load another HTML. (We cannot do that anyway since there is no de-register of custom elements.) This difference will puzzle page authors. And an implementer (me) is also having troubles... Current link implementation is all about dynamic attribute changes. disabling its dynamic nature only with @rel=import seems tricky. Well, yes. I can just refactor the code. But this complication implies that making it interoperable will be a headache. There will be many hidden assumptions which come from underlying link implementation. For example, what happens if we update @rel from import to style after the element imported document or vice versa? We need to clarify all these cases if we choose link as our vehicle. It seems burden for me. Using new element like import doesn't have such issues. We can just define what we need. Also, we'll be able to introduce import-specific attributes like @defer, @async or even something like @sandbox without polluting link vocabulary. One downside is that we'll lose the familiarity of link. But having indirection like the Import interface smells like we're just abusing it. What do you think? Is this reasonable change or am I just restarting something discussed before? I have proposed script import=url/script instead of link rel=import href=url before. http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0009.html http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0024.html Benefits: * Components can execute script from an external resource, which script src can do as well, so that seems like a good fit in terms of security policy and expectations in Web sites and browsers. * script src is not dynamic, so making script import also not dynamic seems like a good fit. * script can appear in head without making changes to the HTML parser (in contrast with a new element). To pre-empt confusion shown last time I suggested this: * This is not script src. * This is not changing anything of the component itself. -- Simon Pieters Opera Software
Re: webcomponents: import instead of link
Thanks for your feedback, folks. I presumed that link rel=import is one-shot just because it is how element works and I felt both are analogous, but apparently this is not a common perception. It seems like making link rel=import dynamically-updatable isn't that controversial. I'll try that way. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20683
Re: webcomponents: import instead of link
Apparently I wasn't clear enough before. We shouldn't add dynamically updating imports of components just because we're choosing to reuse link. We add dynamic imports if there are use cases. So far no-one has presented any use cases. And IMO we shouldn't treat link rel=import as dynamic by enabling it to point to new URLs to import additional components while still leaving the old components in place. That seems like very confusing behavior and introduces a lot of edge cases. We (or at least I) did intentionally not make script src work this way since it just felt confusing. It's not a lot of overhead to ask people to simply create a new link element. / Jonas On Tue, May 14, 2013 at 7:49 PM, Hajime Morrita morr...@google.com wrote: Thanks for your feedback, folks. I presumed that link rel=import is one-shot just because it is how element works and I felt both are analogous, but apparently this is not a common perception. It seems like making link rel=import dynamically-updatable isn't that controversial. I'll try that way. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20683
