[whatwg] The target= attribute
Summary: * Added name= to object and iframe as a hook for target=. * Made _blank legal again. Hallvord R M Steen wrote: often a page needs to interact with a plugin and tell it to load another file. Today this is of course done with JavaScript, which is difficult because most plugins have different JS interfaces, and there are also differences between the plugins' ActiveX based interfaces in IE and the NPAPI plugin ones. Hence I thought it would be a great simplification if we could do the following: object type=application/x-shockwave-flash id=myMedia data=init.swf /object a href=animation1.swf target=myMedia load movie 1 /a A compliant UA would detect that the target was a plugin and not a window, and call the plugin's NPP_NewStream method (I think, I don't know NPAPI well at all) to notify it of the new file to load. I think backwards compatibility is pretty good since a non-compliant UA would open a new window for the new file. What do you think of this idea? I think this is an interesting idea, though I don't know how much demand there is for this. I would recommend following this up with the group documenting the NPAPI. On Fri, 2 Mar 2007, Michael Enright wrote: If this is commonly done with just one line of JS then a bot could probably find a significant number of pages with that one-liner in the 'a' element's attributes. By one line, I mean a simple unwrapped property change or invocation of a standard method, not through a wrapper. It would be worth spec'ing in HTML5 if it applies to plugins that don't obey the NPAPI. I'm not sure how we could spec something without referencing the plugin API itself. What woudl it mean? Also it is a little troublesome because the proposal messes with the namespace that the target attribute applies to. Currently there is no reason to worry about a clash between the names of the windows and the ids in the current page. To refine the proposal this potential clash would have to be addressed. Could the target attribute in the example be #myMedia to refer to the id on the current page? In general to change the media on plugin P on window W you write 'target=W#P'? And target=_blank#something has no defined resolution. Yeah, there's no clash the way the spec is defined now. On Sun, 8 Apr 2007, Georges MARZIN wrote: I have a suggestion to submit : Look at this piece of code : !-- look at the sharp in the target property -- a href=inc/foo.frg target=#main_area Click here to dynamicaly load a text/html piece of code into the main_area identified dom node /a !-- somewhere in the same document -- div id=main_area/div The content of inc/foo.frg in not a complete html page but only a well formed xhtml piece of code like : div this content is dynamically loaded into a dom node, like ajax, but with a html extended syntax of the target property. /div - With this extension of the target attribute, it might be possible to make some ajax kind of work without javascript enable. - Second: developers don't need to know anything about xmlHttpRequest. - Third avantage: with this syntaxe, a robot can parse the href content to indexe it. Remember that html purist don't like ajax because it use javascript and is not indexable by robots. It is possible to do the same with the target attribute of form element. So the result of submission will appear in a dom element and not cover the whole page. Why not just use iframe? On Sun, 8 Apr 2007, Kornel Lesinski wrote: IMHO it isn't much better than: a href=inc/foo.frg target=main_area iframe name=main_area/iframe It's still as evil as frames - subpages can't be used as standalone documents (thus bookmarked, returned by search engines, etc), because they lack proper navigation menus and in your example they're not even proper documents. Indeed. I think that much better and more powerful solution are ID overlays. The idea is to merge documents instead of completly including one into another. XUL has something like that: http://developer.mozilla.org/en/docs/XUL_Tutorial:Overlays Yes, various suggestions along these lines have been made. I'm thinking maybe the best way forwards is to make the spec support these various proposals, but not implement any particular one proposal. (Similarly, Web Forms 2's repetition model, and HTML5's template model, should both probably be removed in favour of simply a supporting infrastructure that allows them to be implemented by script.) On Sun, 8 Apr 2007, Georges MARZIN wrote: When using iframe, the content is treated like a complete and separate html page. So you have in your document a second page completely different from the main document. So, if you want for this sub-page the same comportment and appearance as the main page, you need to write a complete head section with
Re: [whatwg] The target= attribute
Ian Hickson wrote: On Sat, 28 Apr 2007, Bill Mason wrote: 3) The back button is not considered reliable as a navigation aid if target=_blank is not in use. Can you elaborate on why this is? I don't particularly believe that this is true. I made that statement in accepting for the sake of argument someone else's assertion from earlier in the thread: [1] Because the Back button is a horribly awkward interface for navigating, especially for getting back to pages you visited a few minutes ago. (In some browsers the Back button has a visible associated menu, but it's hard to open -- and it relies on page titles, which readers probably didn't notice when first scanning those pages, again because of poor browser design.) [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/011104.html -- Bill Mason Accessible Internet [EMAIL PROTECTED] http://accessibleinter.net/
Re: [whatwg] Anchor target-attribute extension to enable dom targeting
Kornel Lesinski wrote: I was just referring to the concept. Something similar could be made for HTML. It has been, albeit requiring script at the moment: http://disruptive-innovations.com/zoo/20040830/HTMLoverlays.html Gerv
[whatwg] Anchor target-attribute extension to enable dom targeting
Hello. This is my first post in whatwg mailing list for technical discussion of WHAT Working Group specifications. Please pardon my english, I'm french. I have a suggestion to submit : Look at this piece of code : !-- look at the sharp in the target property -- a href=inc/foo.frg target=#main_area Click here to dynamicaly load a text/html piece of code into the main_area identified dom node /a !-- somewhere in the same document -- div id=main_area/div The content of inc/foo.frg in not a complete html page but only a well formed xhtml piece of code like : div this content is dynamically loaded into a dom node, like ajax, but with a html extended syntax of the target property. /div - With this extension of the target attribute, it might be possible to make some ajax kind of work without javascript enable. - Second: developers don't need to know anything about xmlHttpRequest. - Third avantage: with this syntaxe, a robot can parse the href content to indexe it. Remember that html purist don't like ajax because it use javascript and is not indexable by robots. It is possible to do the same with the target attribute of form element. So the result of submission will appear in a dom element and not cover the whole page. Here is an example : http://lomago.com/xhtarget/formulaire.html For french readers, a demo : http://lomago.com/xhtarget
Re: [whatwg] Anchor target-attribute extension to enable dom targeting
On Sun, 08 Apr 2007 19:17:55 +0100, Georges MARZIN [EMAIL PROTECTED] wrote: a href=inc/foo.frg target=#main_area Click here to dynamicaly load a text/html piece of code into the main_area identified dom node /a !-- somewhere in the same document -- div id=main_area/div The content of inc/foo.frg in not a complete html page but only a well formed xhtml piece of code like : div this content is dynamically loaded into a dom node, like ajax, but with a html extended syntax of the target property. /div IMHO it isn't much better than: a href=inc/foo.frg target=main_area iframe name=main_area/iframe It's still as evil as frames - subpages can't be used as standalone documents (thus bookmarked, returned by search engines, etc), because they lack proper navigation menus and in your example they're not even proper documents. I think that much better and more powerful solution are ID overlays. The idea is to merge documents instead of completly including one into another. XUL has something like that: http://developer.mozilla.org/en/docs/XUL_Tutorial:Overlays -- regards, Kornel Lesiński
[whatwg] Anchor target-attribute extension to enable dom targeting
Le dimanche 08 avril 2007 à 20:27 +0100, Kornel Lesinski a écrit : On Sun, 08 Apr 2007 19:17:55 +0100, Georges MARZIN [EMAIL PROTECTED] wrote: a href=inc/foo.frg target=#main_area Click here to dynamicaly load a text/html piece of code into the main_area identified dom node /a !-- somewhere in the same document -- div id=main_area/div The content of inc/foo.frg is not a complete html page but only a well formed xhtml piece of code like : div this content is dynamically loaded into a dom node, like ajax, but with a html extended syntax of the target property. /div IMHO it isn't much better than: a href=inc/foo.frg target=main_area iframe name=main_area/iframe It's still as evil as frames - subpages can't be used as standalone documents (thus bookmarked, returned by search engines, etc), because they lack proper navigation menus and in your example they're not even proper documents. I think that much better and more powerful solution are ID overlays. The idea is to merge documents instead of completly including one into another. XUL has something like that: http://developer.mozilla.org/en/docs/XUL_Tutorial:Overlays When using iframe, the content is treated like a complete and separate html page. So you have in your document a second page completely different from the main document. So, if you want for this sub-page the same comportment and appearance as the main page, you need to write a complete head section with scripts and css, and to be careful to have compatibility with the main page head section. With iframe, again, you need to set width and height and the content is usually displayed with scroll-bars, and it is awful. If you just need to modify a small part of your document like displaying pictures or response coming back a form php script, the iframe solution is a heavy and ugly solution. It's why I thought about another way with a very small modification of the syntaxe of the target attribute : why not specify a dom id with a #, so it is easy to read and to understand. The # symbol mean id in css stylesheet. There is no possible confusion with targeting names of frames or targeting _blank or _top... The small html fragment can be a seperate static file, or contextual php results, like : div id=responseThe response is : /div a href=answer.php?question=somethingparam=someparam target=#responseclick!/a When the response will arrive, css rules will apply to the new content, and the result will be smart. Usually to do this you must use onclick and xmlHttpRequest. You have to define functions to create the object, choose GET or POST, define a callback function, and so on.. With the syntaxe I propose it is really easier. (a have write a small script which implement this syntaxe. The html code is quite simpler with it). A demo is (in french) at this address : http://lomago.com/xhtarget I am interested with your solution of xul-like id overlay for merging documents. But I know this for xul, but not for html. How can it work ? Thank you very much, and read you soon...
Re: [whatwg] Anchor target-attribute extension to enable dom targeting
On Sun, 08 Apr 2007 22:22:20 +0100, Georges MARZIN [EMAIL PROTECTED] wrote: IMHO it isn't much better than: a href=inc/foo.frg target=main_area iframe name=main_area/iframe It's still as evil as frames - subpages can't be used as standalone documents (thus bookmarked, returned by search engines, etc), because they lack proper navigation menus and in your example they're not even proper documents. When the response will arrive, css rules will apply to the new content, and the result will be smart. Yes, in this regard it's much better than iframe. However it doesn't solve the worst problem of frames - that subpages become separated from essential parts of the document. I am interested with your solution of xul-like id overlay for merging documents. But I know this for xul, but not for html. How can it work ? I was just referring to the concept. Something similar could be made for HTML. I think there should be an additional requirement that every subpage specifies its parent page. This would allow user agents to reconstruct full document from any subpage. How about that? index.html: h1My page/h1 a href=subpage.html rel=overlayopen subpage/a div id=mainhello world/div I've used rel=overlay since you don't need to specify where should supage be included (elements with same IDs will be replaced). subpage.html: a href=index.html rev=overlaymy parent/a div id=mainsubpage/div This page has reV=overlay, which specifies the parent document. This has two roles: - a fallback that allows users and bots to find parent page that contains navigation and rest of the content - allows UAs that support overlays to rebuild complete page using this reference resulting DOM would be: h1My page/h1 a href=subpage.html rel=overlayopen subpage/a div id=mainsubpage/div It should be enforced that subpages contain rev=overlay link and that parent pages and subpages are mutually connected: If there's no rev=overlay link in the subpage or it has rev=overlay link that points to URL other than that of current page, browser should normally open subpage instead of overlaying it. For example if index.html contains: a rel=overlay href=orphaned.html and orphaned.html does not contain a rev=overlay href=index.html, browser should not overlay it (ignore the rel=overlay). When opening a page that has rev=overlay link, browser should load referenced page and overlay the current one on top of it. For example if user opens subpage.html as a standalone document (types the address, opens a bookmark) and the document contains: a rev=overlay href=index.html browser should load index.html and overlay subpage.html on it. And of course since DOM of pages gets shared, overlay should be subject to the same origin policy. -- regards, Kornel Lesiński
