IDE Minutes 2009 02-24
From MemberWiki
URL: http://www.openajax.org/member/wiki/IDE_Minutes_2009_02-24
Contents |
Attendees
- Jon Ferraiolo, IBM
- Javier Pedemonte, IBM
- Kin Blas, Adobe
- Lori Hylan-Cho, Aptana
- Nitin Dahyabhai, IBM
- Bertrand Le Roy, Microsoft
- Adam Peller, IBM
Minutes
(1) Adam sent the following question to the group
- I'm new here, and I know there are existing implementations that use this tag as-is, so it may not be realistic to change, but I just wanted to raise this for discussion.
- Unlike other REQUIRE tags, the REQUIRE TYPE="library" tag indicates a library definition and mapping for other require tags to use, but not an actual resource. Other REQUIRE tags then refer to the library by name. Because of this dependency, there is a special section of the spec that explains the requires tags must be scanned for library tags before any of them can be processed.
- I believe this would be more clear if libraries were indicated as a separate tag, such as LIBRARY. This would make the grammar more precise with a new type that defines the name association. It would simplify implementations and enable us to remove the ordering explanation from the spec. Thoughts? Perhaps we can discuss on the call next week?
RESOLUTION: No decision at this time. Need to research historical discussion and determine if the WG ever looked at (and then rejected) a LIBRARY element.
(2) Questions about <content>, particularly <content type="fragment" src="...">
(3) Remove <javascript> element?
(Note: The discussion of these two topics merged together)
- There are 3 new red-colored comments in the widget chapter that come from Adam's new implementation of the widget spec:
- 2009-02-20 Jon: I assume we support external references to fragments, but wanted to check one more time. In other words, OK to have type="fragment" and src="whatever". 2009-02-20 Jon: Isn't it correct that require elements must specify all of the assets needed by any of the content elements?
- 2009-02-20 Jon: In mashup workflows, Adam has discovered timing issues in certain browsers where he has to delay insertion of scripts and content. How about an informative warning about this in the spec?
Kin: Who would use <content type="fragment" src="...">?
Jon: Just a convenience for people who wanted to put their HTML in a separate file. Note that this is the only option supported by W3C Widgets.
Javier: What's the JS context with this approach?
Jon: Just two ways of getting a string that is subsequently added to the document via an innerHTML assignment
Kin: For type=page, spec needs to say that the page goes into an IFRAME
Jon: Yes, I'll do that.
Javier: I thought we had discussed 'src' only applied when type=page
Adam: Would solve the same domain problem. Also, I had to defer content loading.
Adam: What is difference between JAVASCRIPT element and a SCRIPT within CONTENT? Seems redundant.
Kin: Allowed grouping of constructors at the bottom of the generated web page. Most so you could put all of your script logic neatly at the bottom of the generated page
Jon: Note that Dreamweaver assembles a complete HTML page and then saves it to disk
Javier: Yes, somewhat redundant, but makes the code a little cleaner
Adam: No strong feelings about it. What happens if JAVASCRIPT element when content=page?
Javier: Then JAVASCRIPT is ignored
Adam: Makes the spec bigger and more complicated
Javier: I could go either way
Adam: What about 'src' attribute on JAVASCRIPT element?
Javier: JAVASCRIPT element is mainly for inline
Lori: The 'src' attribute on the JAVASCRIPT element is for shared JS, and allows you to control where it is placed on the generated HTML page
Javier: atend is equivalent to onload
Adam: I think there are timing and same domain issues when implementing in a browser
Javier: Yes
Kin: I see value in 'src' on both CONTENT and JAVASCRIPT
Javier: Hmm
(The following discussion actually happened at the end of the meeting, but is included here to make the minutes less confusing)
Kin: Any number of CONTENT and JAVASCRIPT elements?
Lori: Yes, multiple
Javier: For multiple views. Take the first content for a given view if there are multiple
Adam: How does atend work with mashups?
Javier: Similar to IDE. At onload
Adam: What if adding a widget
Javier: When done loading that widget
Adam: So, after content and atend the same?
Javeir: Not if loading multiple widgets at the same time
Jon: Your JavaScript widget metadata parser can assume the host application will tell it when various events such as atend occur
Kin: src= is not a big deal for us
Javier: Adam points out a good point about cross-domain issues
Lori: Could disallow absolute URLs
RESOLUTION: Keep 'src' attribute on both CONTENT and JAVASCRIPT, but include warning in spec that 'src' with type=fragment may be disallowed if loaded dynamically within browser because browser same-domain policy usually does not allow cross-domain file access
(4) Questions about <require>
- There are 2 new red-colored comments in the widget chapter that come from Adam's new implementation of the widget spec:
- 2009-02-20 Jon: Isn't it correct that require elements only apply when content is a fragment (versus a url reference to a complete HTML page)?
- 2009-02-20 Jon: Isn't it correct that require elements must specify all of the assets needed by any of the content elements?
Javier: REQUIRE with CONTENT TYPE=page doesn't make sense
Adam: It is unlikely but not out of the question that putting the REQUIRE contents into the HEAD of the main page might have an effect of some sort
Javier: The reference implementation looks at the first CONTENT for PAGE vs FRAGMENT, and then assumes all other CONTENT match
Jon: Note that there are two effects from REQUIRE, additions to the HEAD and file copying. The file copying aspects apply even if PAGE.
RESOLUTION: Add informative note to spec that REQUIRE additions to HEAD may not have an effect if content type==page
(5) datatype="options"
(Lori reminds Jon what this is about)
RESOLUTION: Need to research archives, particularly about how we resolved the CONFIG element
