[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: QUESTION: picture behaviors -- corrections and critiques
Ref: http://lists.oasis-open.org/archives/cgmo-webcgm/200509/msg00093.html Comments: 23 ========== Dieter writes a multi-part comment: Part 1 (suggestion): ----- >"'The following Picture Behavior values, except for _replace, are defined >per HTML 4.01'. This is incorrect. HTML 4.01 does not define any picture >behaviors. It defines keywords, and the definition is different from what >we show here in all cases (e.g. using user agent vs. viewer, _parent is >differently worded. Suggestion: change first phrase to indicate that 4.01 >defines keywords that we use as picture behaviors?" I propose a rewording in the spirit of but slightly different from Dieter's proposal, "The following Picture Behavior values, except for _replace, are based on @@Frame Target Names@@ of html." Part 2 (question): ----- >"Or don't we really define them all here as picture behaviors?" I'm not sure I understand this part. We call them picture behaviors. We define the effect when the content type (to load) is CGM and when the content type (to load) is HTML. It is based on HTML 4.01 keywords. In the case of (loading) HTML, I believe the specified effect is the same as defined in HTML 4.01 (even if the words don't match precisely to the words in HTML 4.01). Part 3 (critique): ----- >"Do I have to say, I hate picture behaviors?" We might have done things differently, if we were starting over. But given 5 years of legacy ... I guess we have to make the best of it in the least disruptive way. >"What is it, if they show up in the third param of a linkURI? picture >behaviors if the target is a CGM," Yes. >"frame target names if the target is non-CGM?" When you say "frame target names", I assume that are you including the reserved keywords (like "_blank") in "frame target names"? As I read it: the reserved keywords except _replace, or a name beginning with a-zA-Z. In summary, ignoring the fact that we might have done things differently if we were starting over to design 1.0, I think that the pieces of the picBehavior puzzle are accurately enough specified for implementation. It is possible that we could, without making substantive changes, improve the presentation by moving tables to different places, splitting / merging text, etc. I would be happy to consider a comprehensive (non-substantive) rewrite. But ... without such a proposal, I'm inclined to leave it alone and move on to other stuff. RECOMMENDATION: none, except the proposed improvement of wording of part 1 above. Thoughts? Proposals? Regards, -Lofton.