These are the collected Last Call comments on SMIL 2.0 Last Call WD that were sent to the SMIL mailing list (www-smil@w3.org), and responses to those comments. Comments include:
Notification of these Last Call responses was sent to all of the commentors and the SYMM list: http://lists.w3.org/Archives/Member/symm/2000Nov/0207.html
Subject: The XML Namespace Identifier for the SMIL 2.0
Modules in 2.3.2 is given to be http://www.w3.org/TR/REC-smil/2000/SMIL20/LC/
but the examples in 13.3.2 make use of
http://www.w3.org/TR/REC-smil/2000/SMIL20 .
Which one of these does the SYMM Working Group intends to follow?
Thanks. Pankaj Kamthan
The "LC" is just to distinguish the last call draft from the final, because the W3C requires that we use different normative URL's for each public released document. The Candidate Rec version will use "CR". The final recommendation will use the URL's without an "LC" or "CR" suffix. [http://www.w3.org/TR/REC-smil/2000/SMIL20/]
The discussion and resolution is archived at:
http://lists.w3.org/Archives/Public/www-smil/2000JulSep/0045.html
Subject: Currently, there is no way for a SMIL 2.0 player to react to the end user closing a viewport window prior to the media playing within the window finishing its active duration. The layout spec says that the closing of a viewport has no effect on the timing of the presentation. Therefore, if a viewport window is closed early, a means of reacting to this within the SMIL is needed. A solution would be to add the "viewportClosedEvent" that gets raised by the window when it closes, regardless of why it closes.
We have discussed this and determined that this is indeed an omission, and
have added 'viewportOpenEvent' and viewportClosedEvent' to the layout module
so that authors can take into account this behavior in their presentations.
These event will be added to the SMIL 2.0 language profile as well.
The discussion and resolution is archived at:
http://lists.w3.org/Archives/Member/symm/2000Oct/0045.html
Subject: If for no better reason than to test the sensitivity of everyone's "no new features" trigger, here's a modest proposal: adding the value "tile" to the fit attribute. This applies when an image is smaller its region in one or both dimensions. When this occurs, a copies of the image are place next to or around it, repeatedly if necessary, in a "tiled" fashion, until the region is filed. This should be easy to implement. It would enable the use of background patterns that are common in HTML documents, but for which there is currently no easy way to encode in SMIL.
The WG put significant time into this request to define and size its complexity.
The final proposal is archived at:
http://lists.w3.org/Archives/Member/symm/2000Sep/0536.html
It was decided that the feature is useful, but it is not of high enough priority
and the user demand has not been high enough to add to SMIL 2.0 at this late
date. We will definitely consider it for a future version of SMIL.
The discussion and resolution (including Lloyd's acceptance of the resolution)
is archived at:
http://lists.w3.org/Archives/Member/symm/2000Oct/0045.html
Subject: XHTML Basic[XHTMB] use the XHTML namespace name, but has its own
DTD.
Should not a valid SMIL Basic document also be a valid SMIL 2.0 document?
With the solution in the working draft it will not.
[XHTMB] http://www.w3.org/MarkUp/Group/2000/PR-xhtml-basic-20000824/
This is an excellent question. Originally we thought that SMIL Basic would have it's own DTD and Schema, and that this would be a starting point for others to define there own profiles. Several people have remarked that SMIL Basic documents should be legal SMIL 2.0 language documents. Some have stated that SMIL Basic is too simple and others said that it is too complex. After discussing this within the group, we agree that it makes the sense to both enable re-purposing of content, and to allow a wide variety of complexity in client implementations. Therefore we have redesigned SMIL Basic to be not a specific language but instead a means of authoring scalable SMIL that will work on user agents with a wide variety of capabilities. SMIL Basic is now an authoring guide describing how to use content control functionality to enable playback scalability, and a set of conformance guidelines for user agents that implement a subset of smil 2.0 functionality.
In short, suggestion accepted, now SMIL 2.0 and "SMIL Basic" have the same namespace.
The discussion and resolution is archived at: http://lists.w3.org/Archives/Member/symm/2000Oct/0340.html
Subject: The content model for override is shown in the DTD as (allowed
|not-allowed) 'not-allowed'.
Shouldn't it be (allowed | not-allowed | uid-only) 'not-allowed', per the
text of 4.3.2?
Your comment is correct. This will be fixed in the next version.
Subject: Content Control DTD - ENTITY %customAttributes.content
In the Content Control DTD, the content model for ENTITY
%customAttributes.content is "EMPTY".
Shouldn't it be "(customTest)+" instead?
Yes, the only content in <customAttributes> are <customTest>
elements.
In fact, the SMIL language profile DTD defines the content model correctly,
but I agree with you that it makes more sense to do this in the Content Control
DTD.
This too will be fixed in the next version.
Michael found his comments adequately addressed: http://lists.w3.org/Archives/Member/symm/2000Nov/0299.html
Subject: Two reviewers reviewed this draft on behalf of the DOM WG and we have no comments on it.
Thank you for your review.
Subject: Based on discussions with designers, we would like:
1- to allow the use of 'height' and 'width' attributes on in-line sub-region positioning (in addition to "bottom" and 'right'). Justification: in placing media objects, people often know the media dimensions of the object being placed. Forcing them to use 'bottom/right' specifications make things unnecessarily complex.
2- In order to facilitate layout needs, the user should also be able to specify the z-index attribute on in-line sub-region positioning.
In both cases, we feel that leaving these attributes out of the current draft was simply an editorial omission.
items 1 and 2: These are indeed oversights and do not require any additional semantics or implementation complexity. We will add these in the next public version of the draft. The working group discussion (and Dick's agreement) is archived at: http://lists.w3.org/Archives/Member/symm/2000Oct/0498.html
Subject: comments on the SMIL 2.0 Language Profile and one comment on Timing.
SMIL 2.0 Language Profile:
1. "Conforming SMIL 2.0 Documents" vs. "User Agent Conformance"
- The names of these two sections are potentially confusing.
- Suggested titles: "Conforming SMIL 2.0 Documents" and "Conforming SMIL
2.0 User Agents". It may be useful to put these in a single list called "SMIL
2.0 Language Conformance", with these two as major top-level divisions.
- Recommendation: unify outline/numbering of sections
2. "SMIL player" vs. "user agent"
- Both terms are used. We should pick one and use it.
3. "Namespaces in XML [[XML-NS]], we require at least the support for the
default namespace declaration. "
- implies that <smil xmlns:foo="http://www.example.com" ... > can be
rejected by an implementation
- Recommendation: we should remove this clause, and state that full namespace
support is required.
- See thread:
http://lists.w3.org/Archives/Member/symm/2000Oct/0128.html
4. "Default namespace prefix recognized. If the default namespace is not
recognized in its entirety by the player but it includes the prefix
"http://www.w3.org/TR/REC-smil/"
the document will be processed as if the default namespace declaration were
"http://www.w3.org/TR/REC-smil/".
This means that the document will be processed as a SMIL 1.0 document, and
handle fully namespace qualified extension elements either by recognizing
the elements or applying the skip-content rules to the unknown extension
elements. Unqualified elements not part of the SMIL 1.0 namespace are illegal
and will result in an error."
- Forces an implementation to treat documents as SMIL 1.0 when an error should
be issued or the document should be played as some future version of SMIL
- Either strike or change "the document will be" to "the document may be"
- If kept, this item belongs in "User Agent Conformance" section
5. "For an attribute with an unknown attribute value, the player substitutes
the default attribute value if any, or ignores the attribute if the attribute
has no default value."
- Need to modify to be in line with Resolution 6 from NYC f2f:
"6. RESOLUTION: Add note to profile saying that SMIL language profile errors
are strict. This is an action item for SMIL language profile editors."
- Need to replace "unknown attribute value" with "syntactically invalid"
7. " The animation target elements supported in the SMIL 2.0 Profile are
the region element defined in the Layout Modules, the area element defined
in the Linking Modules and the ref, img, video, text, and textstream defined
in the Media Objects modules."
- Typo: animation should be in list of media elements
8. In the Specifying the target attribute of the animation table.
- we should consider adding regionName to the list of Target Attributes for
animate and set
- this could be both interesting and useful to authors
9. In Supported Event Symbols, an event to detect when/if buffering occurs
during playback would be useful:
- bufferingInEvent, bufferingOutEvent or bufferingStartedEvent,
bufferingEndedEvent
Timing:
10. "Times are expressed in UTC (Coordinated Universal Time)."
- We should add UTC to the glossary: "Universal Time" (abbreviated UT) which
is sometimes referred to, now colloquially, as "Greenwich Mean Time" (abbreviated
GMT). The two terms are often used loosely to refer to time kept on the Greenwich
meridian (longitude zero), five hours ahead of Eastern Standard Time. Times
given in UT are almost always given in terms of a 24-hour clock. Thus, 14:42
(often written simply 1442) is 2:42 p.m., and 21:17 (2117) is 9:17 p.m. Sometimes
a Z is appended to a time to indicate UT, as in
0935Z.http://aa.usno.navy.mil/AA/faq/docs/UT.html
- or how to convert from timezones
http://aa.usno.navy.mil/AA/faq/docs/us_tzones.html
item 1: Good suggestion. We have incorporated this into the draft.
item 2: Good suggestion. We have chosen to use the term "user agent". Thank you.
item 3: Agreed, full namespace support is now required in the SMIL 2.0 Language.
items 4, 5, and 6: At the November 2000 face2face, the group examined these points and we have revised the smil 2.0 document and user agent conformance sections of the smil 2.0 language profile. The discussion is archived at: http://lists.w3.org/Archives/Member/symm/2000Nov/0019.html . The next draft will incorporate these changes.
item 7: Thanks for catching this typo.
item 8: We discussed animating regionName at the November 2000 face2face and agreed that this should be included. The discussion is archived at: http://lists.w3.org/Archives/Member/symm/2000Nov/author.html . The next draft will incorporate these changes.
item 9: We discussed buffering events at length during the November 2000 face2face. The group resolution was that this is a worthwhile feature, but the semantics are not obvious and it will take some time and effort to define. The feature is simply too new to put in at this time. We would like to consider adding buffering events to a future version of smil.
item 10: Good suggestion. We have incorporated explanatory text on UTC into the draft.
Subject: a page where I have tried to list all the known WAI/SMIL issues -
http://www.w3.org/WAI/CG/Group/symm-liaison
Some of them I believe are resolved already, But I haven't yet put in the solution information. I will try to do that over the weekend.
for example I don't think there are outstanding issues with layout beyond the possibility to describe it (which is part of the general description issue, and in any case seems like a very low priority thing since it could be presented direct by a user agent based on the layout markup and the titles of things as identifiers for people to read)
We have reviewed the issues listed on the symm-liaison page during SYMM telecons, at the November 2000 face2face, and during two WAI/SYMM telecons. SYMM and WAI have agreed on resolutions covering the outstanding issues:
We have reviewed the available system test attributes. They do cover the necessary use cases. See Geoff Freed's email: http://lists.w3.org/Archives/Member/symm/2000Oct/0598.html
SMIL supports multiple simultaneous system languages. The user agent can provide an interface allowing the user to specify this. SYMM requests feedback from WAI for suggestions on how a user agent should implement this.
SYMM and WAI have worked together to produce language stating the implemention requirements for the accesskey feature. See: http://lists.w3.org/Archives/Member/symm/2000Nov/0019.html
SYMM has agreed to include alt/longdesc on every element in the SMIL 2.0 language to improve accessibility. The suggestion was made that SMIL 2.0 include title and desc elements, like in SVG, but it was mutually agreed that the interactions between the attributes and the rest of SMIL 2.0 is too complex to add at this late date. SYMM will closely consider adding accessibility elements to the next version of smil.
The SMIL 2.0 specification defers most user agent accessibility issues to the WAI guidelines. The need to review and pay close attention to the WAI User Agent guidelines now in last call has been established.
Additionally, the SYMM Working Group has agreed to work with WAI on two topics of mutual interest, separate from the process of the SMIL 2.0 advancing forward to Recommendation. First, the SYMM WG will provide feedback to WAI on a method of WAI's design to enhance the functionality and flexibility of system test and custom test attributes using metadata. The SYMM WG also will work with them on finding implementers to produce trial implementations of this method.
Second, the SYMM Working Group will work in parallel with WAI to produce a combined set of multimedia authoring/presentation and accessibility requirements for a general and reusable timed text format. After assembling and discussing the requirements, we will mutually decide on appropriate next steps.
The XML Linking WG recently reviewed the Last Call version of the SMIL 2.0 specification at http://www.w3.org/TR/2000/WD-smil20-20000921/ (http://www.w3.org/AudioVideo/Group/ version was also checked).
Due to the size of the specification, only the parts likely to be related to linking were reviewed, more specifically the Linking Module, the Language Profile and the Basic Language Profile.
First we would like to report our appreciation for your making the namespace declaration required in the Profile. There are, however, three points which would have to be checked or modified in the process of going to Candidate Recommendation and further:
1 - SMIL is not requiring XPointer and is making heavy use of fragment
identifiers in URI References to parts of SMIL documents. Hence it must register
its own MimeType and not be delivered as text/xml nor application/xml.
It seems that, since this registration is a work in progress, it must be
made sure that it has attained a sufficient standard level at the IETF before
asking for PR.
2 - The Linking module suffers (as I reported back in March) some namespaces
deficiencies:
3 - The status of the use of XML Base is unclear. As explained in the XML
Base specification, the deployment strategy for XML Base is by reuse in other
XML specifications. Though there is a reference to it in the Appendix
B, it is unclear if it is normative.
There is also no reference to it in the Linking module. We hope you intent
to use XML Base and make it clear in the Linking Module.
We thank you in advance for the clarification those changes would make.
item 1: The SYMM and XML Linking WG members have discussed this issue at length. We agree that restricting the types of XPointers supported to fragments is correct for SMIL user agents processing application/smil content. This restriction does not apply to the processing of other media or to other applications of XML.
item 2 : We have added language to make clear that the linking attributes
are part of the SMIL namespace, and not a general xml or xlink
namespace.
a- Changed the line as you suggest to clarify the situation
"These attributes can be applied to linking elements from other namespaces
if allowed by the language profile." by
"These attributes pertains to the SMIL namespace http://www.w3.org/TR/REC-smil
but can be applied to linking elements from other namespaces if allowed by
the language profile."
b-We will also also fix the examples so that the smil20 namespace is made explicit and obvious.
item 3: We have modified the language to state that the SMIL 2.0 language supports XML Base, and have added supportive text in the linking draft as well.
These responses have been found acceptable by Eve and Daniel: http://lists.w3.org/Archives/Member/symm/2000Oct/0600.html
Subject: me and my colleague have been reading the latest smil draft version very enthusiastic and are beginning to understand it's full potential. Especially we have evaluated it in couple of real-life usage scenarios to see more clearly, whether it could be usable in our future projects. One thing, however, doesn't come out from the document:
How to control content loading dynamically with Timing Attributes without scripting of any kind (without programming against DOM)? And all of this during playback?
All the examples in the draft are dealing only with static content.
By static content we mean, that the SMIL presentation is always loaded as
a whole and then played. There's no "reloading" of anykind during playback.
It seems, that this kind of functionality is not "built-in" in SMIL?
Even though, SMIL is designed to be reusable in the module level (you can
create your own markups using these modules), this kind of functionality
must definitely be in the SMIL itself.
Here is a couple of examples where we could utilize this kind of behaviour:
1. "Real-time" view of stock exchange (textual or graphical view)
Let's say I want to have a window open on my desktop, which shows the values
of the stocks I own. As we all know, "real-time" view for stock value is
essential. It should be obvious that I don't want to "refresh" the view myself
- it should executed automatically (updating itself while I work).
One solution could be that you add an element called <fetch> (to the
Content Control Module), which could be used for "timed loading" of SMIL
content.
Something like the following:
<fetch dur="10s" repeatDur="indefinite">
<text id="text1" src="stockvalues.txt"...>
</fetch>
In here a text file "stockvalues.txt" is assumed to be created on the server side. The fetch module reloads it's contents on every 10 seconds.
2. "Real-time" view of Vote Counts in presidential election
This is much like the first example, but now I want to follow some presidential
election process in "real-time".
<fetch dur="60s" repeatDur="09:00pm">
<img id="image1" src="progressbar_candidate1.jpg"...>
<img id="image2" src="progressbar_candidate2.jpg"...>
</fetch>
Again, in here we are assuming that the progressbar images are updated regularly on the server side. The fetch module reloads it's contents on every 60 seconds and stops reloading after 9 pm.
Is there some way to do this, that we are not able to see? Is there a way
to do this without scripting? If not, we think that this kind of functionality
must definitely be supported in the SMIL 2.0. If we want to minimize the
need for scripting why not minimize it even further?
Note, that the examples above are just to demonstrate the problem we have
been encountering. We are sure that you can come up with much more finer
solution.
These are more authoring questions than comments about the specification. However, we thank you for the opportunity to describe how smil 2.0 supports these use cases. The short answer is that to use the HTTP protocol and cache management to send updated media. See the reply at: http://lists.w3.org/Archives/Public/www-smil/2000OctDec/0025.html . We do not have record of a further response from Max.
Subject: Layout is shown as an EMPTY element in the Layout Module DTD, which contradicts the examples in the spec itself.
Most elements are defined as EMPTY in their module DTDs.
These are just simple default values which are used to keep the module DTDs
independent from one another. The actual content model of elements like layout
depends on the profile that is in use. For the SMIL language profile this
is defined in the file smil-model-1.mod. There the content model of layout
is defined as:
<!ENTITY % layout.content "(region|viewport|root-layout|regPoint)*">
The SMIL Basic profile's layout content model, however, is defined in smilbasic-model-1.mod as:
<!ENTITY % layout.content "(root-layout?,(region)*)">
Subject: The transitions draft currently specifies no method that allows
to avoid nameclashes for "private" transistions:
http://www.w3.org/TR/2000/WD-smil20-20000921/smil-transitions.html#TransitionEffects-Extending
In other words, two implementations can use the same name for a new transition,
but they would result in completely different transitions.
This can be resolved by using a namespace-based solution, which is already
used for events
http://www.w3.org/TR/2000/WD-smil20-20000921/smil20-profile.html#q21
The SYMM WG discussed this at the November 200 face2face and agreed. We will avoid nameclashes on extension transitions using the name namespace prefix qualification mechanism as we have already specified for events. See the minutes in the face2face discussion at http://lists.w3.org/Archives/Member/symm/2000Nov/0019.html. This will appear in the next version of the draft.
Subject: My questions concern the use of SMIL for developing auditory descriptions for multimedia presentations.
The Web Content Accessibility Guidelines (WCAG) version 1.0 of W3C/WAI indicates the possibility of using speech synthesis for providing auditory descriptions for multimedia presentations. Specifically, checkpoint 1.3 of WCAG 1.0 reads:
"1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. [Priority 1] Synchronize the auditory description with the audio track as per checkpoint
1.4. Refer to checkpoint 1.1 for information about textual equivalents for visual information." (WCAG 1.0, checkpoint 1.3).
In the same document in the definition of "Equivalent", we read:
"One example of a non-text equivalent is an auditory description of the key visual elements of a presentation. The description is either a prerecorded human voice or a synthesized voice (recorded or generated on the fly). The auditory description is synchronized with the audio track of the presentation, usually during natural pauses in the audio track. Auditory descriptions include information about actions, body language, graphics, and scene changes."
My questions are as follows:
1. Does SMIL 2.0 support the development of synthesized speech auditory descriptions?
2. If the answer to question #1 is "Yes", then briefly describe the support that is provided.
3. If the answer to question #1 is "No", then please describe any plans for providing such support in the future.
Thanks very much for your consideration.
We had a detailed discussion of this on the mailing list. In summary, SMIL 2.0 supports synthesized speech as media, and it also allows a user agent to provide synthesized speech for rendering including rendering of the accessibility attributes such as alt/longdesc. The smil 2.0 test attributes support selecting content based on the standard accessibility preference and also based on author specified selection criteria.
The point was made however, that there is a need for a standard location for synthesized speech text to provide maximum accessibility at minimal author effort. It was agreed that this is a general topic of interest for XML languages and is not specific to smil, and that the WAI group will consider what feature would be of general utility and provide feature requests to SYMM for a future version of smil.
It was agreed that the support in SMIL 2.0 is the current state of the art, and that future work will need to be done to specify what more support is needed.
However, the problem has been found to be sufficiently important that the SYMM and WAI groups have agreed to work together to further define the problem and to determine an appropriate course of action. Please see the response to the WAI comments listed as WAI/SMIL issues.
A detailed email thread discussing this issue can be found at: http://lists.w3.org/Archives/Member/symm/2000Nov/0036.html
Subject: We have 2 scheduling needs that do not appear to be covered in SMIL 2.0
Can anyone explain how to accomplish these requirements within the SMIL 2.0 specification?
1) Our Scheduling Module creates many different SMIL schedule documents for our "Player" that are active throughout a month. Due to a high volume and complex business requirements, it is not feasible to combine all of the different SMIL schedules created for a month into one SMIL schedule.
How can we indicate the active date range and timeframe of each SMIL document?
For example, SMIL schedule document #1 is active from 11/1 - 11/30, with a daily active timeframe
of 8:00 AM - 10:00 AM. Schedule #2 is active from 11/1 - 11/15, with a daily active timeframe of 5:00 PM - 10:00 PM. Schedule #3 is active from 11/5 - 11/5, with a daily active timeframe of 10:00 AM - 12:00 PM.
2) Our Scheduling Module needs the ability to schedule a sequence of media elements and indicate the active timeframe of each element. Is this possible in SMIL?
For example, in the element sequence below, we need the ability to indicate that sm5v.jpg should only be played during 11/5 - 11/6.
<img id="Logo" region="Image-1" src="Assets/euro/euro52x51.gif"
dur="5s"/>
<img id="Five" region="Image-1" src="Assets/euro/sm5v.jpg"
dur="10s"/>
<img id="Ten" region="Image-3" src="Assets/euro/sm10v.jpg"
dur="10s"/>
Thank you for a very interesting question! SMIL 2.0 supports wallclock begin times that provide support for this kind of thing. However, getting the expected behavior is more complicated and involves use of other language features such as beginEvent and max to provide the correct sync and additional constraints. The working group produced an example that implements the requested behavior, see: http://lists.w3.org/Archives/Member/symm/2000Oct/0608.html
We agree that this may not be intuitive to new smil authors. We suggest that you gain experience with wallclock and other supporting features and then provide SYMM with feature requests for additional desired support.
Jeff agreed to pursue the solutions that we discussed on the mailing list: http://lists.w3.org/Archives/Member/symm/2000Nov/0275.html
Subject: Last call comments HTML WG
Apologies for the slight delay in these notes.
1- Comment regarding Section 2.5 item 2; "SMIL supports module level
INCLUDE/IGNORE instead of XHTML's element/attlist level. This prohibits profiles
from importing only part of a module -- they have to support either all the
elements and attributes or none."
Since XHTML also prohibits importing only part of a module, we think this
comment is misleading and would like it removed.
2- Comment regarding media types: for interoperability we strongly urge a minimal list of required media types, with at least one per media type. We strongly urge the use of xhtml for text.
3- Comment regarding namespaces in attribute values: Xlink had this and dropped them after last call as a response to last call comments. The Namespaces REC does not mention this usage; please ensure community consensus in this usage before going to CR.
Best wishes, Steven Pemberton
First issue: You are right. I'll change the language to remove the
mistaken implication.
How about: SMIL supports module level INCLUDE/IGNORE instead of XHTML's
element/attlist level. Similar to XHTML, this prohibits profiles from importing
only part of a module -- they have to support either all the elements and
attributes or none.
Second issue: Philipp pointed out that I missed your comment on requiring
XHTML as a supported media type (thanks Philipp). Philipp suggested this
at our Grenoble face2face, and after some discussion, the group rejected
the idea as too heavy a requirement, especially for "smil basic" type players.
Also note that there is signifant interest in the W3C (WAI, SYMM) for a light
weight timed text format. At some future date, it may make sense to require
such a format in smil.
From the Grenoble face2face minutes at:
http://www.w3.org/AudioVideo/Group/2000/f2f-grenoble/minutes.html
In general, agreeing on a required set of media types is difficult or impossible,
as people have a very wide range of uses in mind. Even the few types that
we have are only "should" not "must". AFAIK, XHTML does not have this either,
and I suspect for the same reasons.
RESOLUTION: SMIL Boston language profile will include section on recommended baseline media formats including audio/basic, img/png, and img/jpeg. No text and no video formats.
Third issue: We've gone around this quite a bit. The use of namespaces
in attribute values is confined to event names and transition names, and
the colon is specifically reserved in these attribute values to be used to
support an open extension mechanism using namespaces.
XML Schemas also uses namespace prefixed attribute values as a core part
of the technology, so it seems that it's now okay.
I hope that this is sufficent to close these issues. Please let me know. -Aaron
Steven has accepted our comments, with one point where we agree that we'd both like something that we cannot have: http://lists.w3.org/Archives/Member/symm/2001Jan/0175.html
Subject: Viewport issues
A. Discussed "placeholder" elements and viewports at UI-Tech telecon. CSS
and XSL promise to spend some cycles on this and approve or suggest changes
by next Monday's Hypertext Coordination Group meeting.
B. Viewport issues
1. Open/close may have conflicting semantics. We need to decide and make some language changes in the draft.
2. The term "viewport" was discussed at at UI-Tech telecon. It probably conflicts with some conceptual terms in XSL.
SYMM WG Response:
By: Aaron COHEN (aaron.m.cohen@intel.com ) and Thierry MICHEL (tmichel@w3.org)
Last Updated:$Date: 2001/01/24 14:17:21 $