- From: Bert Bos <bert@w3.org>
- Date: Fri, 14 Oct 2005 18:40:06 +0200
- To: public-tt@w3.org
Hello TT WG,
Excuses for the delay, but here are the reactions from the CSS WG on
your responses to our comments.
> *********************************************************************
>***
>
> Citations:
>
> [1] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0039.html
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 5.1) Why six different namespaces in one document format? It doesn't
> seem like you can use any of them on its own.
>
> Response:
>
> In the context of TT AF, the division of namespaces is intended to
> provide distinct name spaces in order to avoid collisions and to
> provide functional context for a name. In this context, these
> namespaces are designed to interoperate. In a more general context,
> one could make use of the same namespaces in other contexts outside
> of DFXP. There is no technical issue here.
It seems unlikely that elements designed for this format will be usable
without modification in a hypothetical other format. At least that
should not be a reason to complicate this format.
Also, it seems easier to reuse elements in another format if the names
of those elements are fixed, but the namespace prefix means they are
variable.
In short, the namespaces seem to make DFXP more complex than necessary,
but they don't reduce its functionality, so we can accept the response.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 5.2) If it is important for an implementation to know the profile a
> document conforms to, shouldn't the profile name be passed out of
> band (as a MIME type parameter), instead of inside the document? A
> profile is usually something you author to, but then neither the
> client nor the server need to know that you do so; or it is something
> a client uses for content negotiation (e.g., HTTP Accept header or
> TYPE attribute on an HTML LINK element). It is not useful inside the
> document, except perhaps for the Unix "file" command...
>
> Response:
>
> A "profile" or "version" could be passed out-of-band, but since DFXP
> does not define a transport mechanism, such definition is more
> appropriately defined in another specification in order to suit the
> needs of that specification.
So if I understand correctly, the word "profile" doesn't mean "subset"
in this case, but merely an arbitrary, user-defined flag, that can be
put in the document. That is fine, but then shouldn't it start with a
user-defined domain-name as well, instead of www.w3.org?
Anyway, as long as the profile doesn't influence what is a valid DFXP
document, it should be fine.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 5.2) In fact, the spec doesn't say what an implementation does with
> profiles. I assume it doesn't do anything with it (unless perhaps if
> the program is a validator).
>
> Response:
>
> DFXP explicitly does not specify a schema binding mechanism.
> Conformance clause 3.2 sub-item 1 places this responsibility on a TT
> AF Content Processor. Nevertheless, we recognize that some guidance
> be provided to processor implementers; therefore, we will add
> informative language suggesting that a processor may make use of the
> ttp:profile parameter as a means for identifying the declared
> language subset (profile).
That doesn't explain much... Whatever the profile attribute, the
processor has to be prepared to handle all legal DFXP elements. It
seems the profile attribute is meant more to select what the processor
*does* with those elements. For example, maybe an author could
define a "-x-simple" profile for a transformation of his where several
features are ignored or mapped to the same target.
But any explanation of the purpose is better than none, so it seems the
issue will be solved.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 5.3.1) Why lowerCamelCase even for names that are borrowed from other
> specifications? XML names can contain dashes.
>
> Response:
>
> The TT WG has adopted a consistent convention for all names, and will
> provide an informative annex indicating heritage of tokens and names,
> indicating whether they had camel case normalization applied.
As for the comment on 5.1 above, reuse of code, documentation and
knowledge is probably easier if things that are the same are called the
same. So, again, the response is somewhat disappointing, but camelCase
doesn't block reuse, so the response is acceptable.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 6.2.1) EDITORIAL: s/express number/express the number/
>
> Response:
>
> Will fix.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 6.2.1 until 6.2.13) All (not sure about one or two) of these
> attributes can only occur on one element, viz., <tt>. So why are they
> defined as global attributes (with a prefix)?
>
> Response:
>
> It is expected that these attributes may be used in different
> contexts in AFXP; it is also possible that some of these may be
> useful in other host languages that may choose to adopt features from
> TT AF.
That seems speculative at best. It is not obvious that these attributes
are reusable (and evidence so far suggests that "global attributes"
don't work, except perhaps for xml:lang, which isn't even a real global
attribute, but part of XML). Without evidence that they can be reused
and that reuse is in any way made easier by the prefix, I'd suggest
taking care of DFXP itself first and doing what is simplest, i.e.,
defining them as plain attributes of <tt>.
So, again, disappointed, but as the prefixes only increase the cost of
processing, but don't affect the features as such, the response seems
acceptable.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 6.2.2) Where is the syntax of GPS time coordinates defined? I
> couldn't find the definition in the spec and there is no reference
> either.
>
> Response:
>
> The phrase "time expressions" is formally defined in section 10.3. A
> cross-reference will be added to make it clear that all time
> expressions, whether GPS or not, make use of a consistent syntax. An
> appropriate reference will also be added to permit semantic
> interpretation of time expressions in the GPS time space.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 6.2.2) Are GPS time coordinates really needed? Their semantics are
> the same as UTC, aren't they? What is the use case?
>
> Response:
>
> The semantics of GPS are distinct from UTC. The primary difference is
> that UTC is adjusted for leap seconds, and may have seconds labeled
> 23:59:60 and may have minutes that are missing the second labeled
> 23:59:59. As of January 1, 1999, GPS - UTC = 13s. The use case for
> GPS involves the fact that GPS is widely used in television broadcast
> in the US for synchronization purposes. For example, the ATSC A/65
> Program and System Information Protocol (PSIP) standard is used to
> transmit television program schedule information via terrestrial
> digital transmission in the US, and PSIP makes use of GPS time
> coordinates to express begin and end times for programming.
OK, that explains it.
But maybe something like this could be added as a note. Not many people
know what you just wrote. The grammar in 10.3 also doesn't say that
23:59:60 is illegal for GPS. Without some explanation, you risk that
programmers will just do "#define GPS UTC" and save themselves some
coding.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 6.2.2) It seems that there may be only one clockMode attribute per
> document (if I interpret the note at the end of 6.2.13 correctly),
> but unlike for the other attributes, there is no paragraph in this
> section that says that clockMode may only occur on the <tt> element.
>
> Response:
>
> This was an oversight. An appropriate constraint will be added to be
> constent with other time related attributes.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 6.2.3) Is the defaultLengthUnit attribute needed? In CSS, we found it
> useful to have unitless numbers mean something specific, different
> from a length, e.g., as a multiplier. That possibility is removed
> when there is a default unit. Also, in a typical document there
> probably aren't more than a dozen or so length values, so declaring a
> default doesn't actually make the document shorter.
>
> Response:
>
> After careful consideration, the TT WG has agreed to remove both the
> ttp:defaultLengthUnit and the ttp:defaultTimeMetric attributes and
> instead require lengths and offet times to specify an explicit
> metric.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 6.2.3) The default is "pixels," but are they device pixels or px
> units, as in XSL/CSS?
>
> Response:
>
> No longer applicable due to removal of ttp:defaultLengthUnit;
> however, the larger question of what does "px" mean when specified in
> a length will be addressed by adding language indicating that the XSL
> definition applies.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 6.2.4) Same question: is defaultTimeMetric necessary?
>
> Response:
>
> After careful consideration, the TT WG has agreed to remove both the
> ttp:defaultLengthUnit and the ttp:defaultTimeMetric attributes and
> instead require lengths and offet times to specify an explicit
> metric.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 6.2.5) EDITORIAL: s/of document instance/of a document instance/
>
> Response:
>
> Will fix.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 6.2.6) Is NTSC the only case where a frameRateMultiplier is
> necessary? If so, then maybe a single keyword ("NTSC" on the
> frameRate attribute) is enough, and a general multiplier is overkill.
>
> Response:
>
> NTSC is not the only case; furthermore, there are a variety of
> operational usages in studios and in broadcast where
> frameRateMultiplier may effectively be a continuous function. Use of
> an enumeration would be overly restrictive and require constant
> updating.
OK
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 6.2.6) EDITORIAL: s/MHz/Hz/ for the first occurrence in the note.
>
> Response:
>
> Will fix.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 7.1.1) Why must xml:lang be specified? Isn't omitting it the same as
> defining it to be the empty string?
>
> Response:
>
> The goal is to strongly encourage authors and authoring systems to be
> explicit about language. Specifying xml:space="" is not the same as
> not specifying xml:space. The former is an explicit authorial
> expression of "no default language"; the latter leaves authorial
> intention unexpressed. We wish to enforce some intentional expression
> even if it is "no default language".
OK
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 7.1.1) Is xml:space necessary? You'll have to have style attributes
> for space handling anyway, so why complicate matters by doing a half
> job in XML?
>
> Response:
>
> We are not sure what is meant by "doing ... [the] job in XML". Our
> understanding is that a compliant XML processor must always "pass all
> characters in a document that are not markup through to the
> application". Our understanding of xml:space is it permits the author
> to express whether the application should use its "default
> white-space processing mode" or should "preserve all white-space".
> Since we have not introduced the full range of whitespace processing
> style properties into DFXP, such as XSL's linefeed-treatment,
> white-space-collapse, white-space-treatment, and
> suppress-at-line-break properties, we instead rely upon use of
> xml:space as an alternative mechanism for specifying authorial
> intention regarding whitespace preservation. Nevertheless, we believe
> it may be useful to re-express the algorithm specifying the meaning
> of xml:space="default" to instead normatively reference the semantics
> of the above mentioned XSL properties.
Having just two keywords (default and preserve) probably doesn't allow
the author to express everything he wants (such as preserve spaces and
still allow line breaks, or vice versa). CSS at first also had just
those two values (called 'normal' and 'pre', resp.). So we expect that
there will be demand for more values...
xml:space itself is not extensible, because its syntax is defined by
XML. If white space handling is made more flexible, DFXP will need a
new attribute. It might be better to drop xml:space and use a
white-space attribute right away.
But defining xml:space in terms of the features of XSL (or the newer
ones of CSS[1] currently under development), will at least make
xml:space=default do something useful in all languages & scripts.
The meaning of xml:space=preserve is currently not defined and should
also be defined, maybe in a similar way. In particular, does wrapOption
override xml:space=preserve or the other way round?
In conclusion: using the 'white-space' property from CSS/XSL would be
better, especially in view of future extensions; if you define
xml:space as you say you will, the response is acceptable. Don't forget
to define xml:space=preserve as well!
[1] http://www.w3.org/Style/Group/css3-src/css3-text
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 7.1.3) Attributes begin, dur and end are on <tt> and on <body>. Are
> they needed on both?
>
> Response:
>
> Distinct timing context is required on <tt> as opposed to <body> in
> order to provide a timing container for <head> and thence to <layout>
> and <region>, the latter of which can be animated.
Regions that may or may not exist at the time some content is available
for it... sounds like a headache for authors. All the timing info on
the content, as in SMIL, seems much more manegable.
But we'll take your word for it...
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 7.1.7) Is the <br> needed? You can also use two <p> elements if you
> need two lines.
>
> Response:
>
> In XSL, <fo:block/> does not produce a block area since it has empty
> content. Since TT AF maps <p/> to <fo:block/> semantics, two empty
> <p/> elements from the TT namespace would map to:
>
> <fo:block/> <fo:block/>
>
> and thus not produce any visible side effect.
>
> In contrast,
>
> <p> <br/> </p>
>
> is defined to produce the same result as
>
> <fo:block> <fo:character character="
"
> suppress-at-line-break="retain"/> </fo:block>
>
> We will review if additional clarification is required to express
> these intentions.
The question was why
<p>First line.<br>
Second line.</p>
instead of
<p>First line.</p>
<p>Second line.</p>
It still seems there is no need for the <br> element, neither to start a
new line nor to create empty space (the latter can be done with
padding, e.g.).
But it doesn't matter.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 7.1.7) What happens if you put two <br> elements in a row, do you get
> an empty line or not?
>
> Response:
>
> Given
>
> <p> <br/> <br/> </p>
>
> a compliant presentation processor produces the same results as:
>
> <fo:block> <fo:character character="
"
> suppress-at-line-break="retain"/> <fo:character character="
"
> suppress-at-line-break="retain"/> </fo:block>
So the intention is that <br> is a hard line break. Fine.
But are you sure that U+2028 produces a line break? It doesn't in CSS.
(It wasn't explicit before, but in CSS 2.1 it is.)
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 7.1.7) Why does the <br> element have an xml:space attribute? Empty
> elements don't contain spaces...
>
> Response:
>
> It was specified for symmetry sake (in order to be uniform on all
> content elements). We will add an informative note that indicates
> that it is effectively ignored if specified.
Why not simply remove it?
But the response is OK.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 7.2.3) Rule three seems to imply that the mark-up
>
> <p>one<span> two </span>three</p>
>
> is displayed as "onetwothree" without any spaces. Maybe you meant to
> omit leading and trailing spaces from the <p> element only?
>
> Response:
>
> Based on a comment above, we believe it may be useful to re-express
> the algorithm specifying the meaning of xml:space="default" to
> instead normatively reference the semantics of the above mentioned
> XSL properties. We will eiother re-express thus or correct the
> algorithm (which we copied from SVG).
OK
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.1.1) What happens if a DFXP document has a style PI? I assume a
> DFXP application will ignore it (just like a generic XML viewer will
> ignore the <styling> elements).
>
> Response:
>
> No normative semantic has been defined for any processing
> instruction; therefore, a compliant presentation processor may
> ignore.
Might be useful to say somewhere that DFXP doesn't use the style PI, but
it's up to you.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.2.1) The bullet list of elements that accept style attributes
> should be non-normative (i.e., a note), because that information is
> already known from earlier sections.
>
> Response:
>
> We believe there is no inconsistency in presenting the same normative
> requirements twice, given the different contexts of the
> specification, provided that there is no inconsistency between the
> requirements. We believe there is no inconsistency at this time.
They may well be consistent, but it is always better to not tempt fate.
Imagine, for example, that you update the spec in the future and forget
that the same text occurs somewhere else as well...
Just an advice. Up to you.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.2.10) The note says that a horizontal font-size is useful in
> systems that have two fonts: normal and double-width. But do you
> expect a horizontal font-size to work on any other system? or with
> any other value than "1c" or "2c"?
>
> Response:
>
> We believe that specifying both horizontal and vertical sizes may
> produce a continuously varying anamorphoic transformation on devices
> capable of rasterizing fonts in a rectangular EM square. We do intend
> to mandate that a given compliant presentation processor must support
> either continuous anamorphic scaling of EM square or support some
> discrete set of anamorphically-transformed font sizes.
>
> We also recongize that this feature constitutes an extension not
> presently supported in XSL, and isn't adequately addressed by section
> 9.3.2 sub-items 6 and 7 (pertaining to populating XSL style
> properties). Therefore, we will add additional normative language to
> 8.2.10 that expresses the intended semantics.
We hope that that additional language is easier to understand than this
response, though :-)
>
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.2.16) The note says that a <p> is displayed on one line, unless a
> <br> is used. But doesn't that also depend on wrapOption?
>
> Response:
>
> Good catch. Will fix.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.2.16) overflow in CSS/XSL has a value "scroll" but here it is
> renamed to "dynamic." Why? An automatic scroll, such as the marquee
> effect of "dynamicFlow," is a valid "scrolling mechanism" in XSL/CSS
> terms.
>
> Response:
>
> We weren't certain if we could define "scroll" to mean "apply the
> dynamic flow semantics defined in DFXP"; but given that you suggest
> this we will change to using "scroll" and define "scroll" semantics
> according to the dynamic flow features.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.2.17) "padding" allows one, two or four values. Why not three, as
> in XSL/CSS?
>
> Response:
>
> We did not find the use of three values to be a particularly useful
> feature, and did not need to support the limited subset of TT AF
> expressed by DFXP. It is possible that AFXP will support the larger
> subset.
It's certainly less often used than the others, but if the feature is
meant to be the same it is good if the syntax is the same, too. It
makes sharing code and experience easier.
Please consider adding the missing syntax and especially don't make the
syntax different between DFXP and AFXP.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.2.18) "showBackground" appears to be similar to 'empty-cells' in
> CSS. Is there no way to merge them?
>
> Response:
>
> Perhaps, but we feel comfortable basing the usage in DFXP on the
> current SMIL attribute whose name is "showBackground" [1].
>
> [1]
> http://www.w3.org/TR/2005/REC-SMIL2-20050107/layout.html#adef-showBac
>kgr ound
OK
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.2.19) "textAlign" doesn't allow values "left" and "right" as in
> XSL/CSS, although it is much easier for an author to write "left"
> than "start" (or "end") when he means "left." Also, when converting
> from/to other formats, it is easier if the value for textAlign in
> DFXP is a direct translation of the corresponding value in the other
> format, rather than a function of that other value and the
> "direction" property.
>
> Response:
>
> We think that when at author writes "left" in a LRTB writing mode,
> that they actually mean "start". We want to encourage the author to
> express their logical intention. We are not certain if there is a
> strong use-case for specifiying non-relative (absolute) text
> alignment.
It's doubtful there is a use-case, even a weak one, for
context-dependent keywords. Imagine somebody asks you: "How do I
right-align my text?" You answer: "Simple. textAlign=end."
Unfortunately, some or all of his text was in Arabic...
The claim that relative keywords are better is based on the assumption
that style sheets for one script can be re-used for another. It's
doubtful that that assumption holds, even for trivial style sheets. And
in the case of DFXP, there isn't even a style sheet; the alignment and
the text are specified together. Why would you make it difficult for
somebody who just wants his text on the right?
99.9% of the DFXP documents will be in only one script.
And, in fact, people who write documents with both a ltr and a rtl
scripts will have an even more difficult time. Not only do they have to
translate in their mind right/left to start/end, but they will have to
change that mapping when they change scripts. To right-align an English
paragraph, they will have to use textAlign=end, but to right-align a
Hebrew paragraph, they will have to use textAlign=start.
Also, DFXP is meant to be transformed to other formats, depending on the
software or hardware that actually displays the text. There are dozens
of timed text formats, but none that support script-relative text
alignment. So all converters will have to implement a translation from
start/end to left/right, which is an extra risk of bugs.
You can simulate left and right with start and end, but it is an extra
hurdle for users. We strongly advice you to add left and right.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.2.20) CSS3 proposes a 'font-effect: outline' property to create
> outline fonts, but it doesn't give control over the thickness of the
> outline, let alone the amount of blur. Isn't 'font-effect: outline'
> enough?
>
> Response:
>
> A number of TT WG members have a strong preference for providing the
> ability to specify blur radius. There has been a request for
> expressing separately the inner and outer color of the blur and
> possibly gradient parameters to apply at the transition boudnary; we
> chose a simple compromise that was modeled closely on the text-shadow
> property of CSS2.
OK.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.2.22) The example is supposed to show that "visibility" can hide
> text, but there is no text to hide... The first text only appears
> after 1 second.
>
> Response:
>
> As it turns out, (1) the intent of this example was not "to show that
> 'visibility' can hide text", and (2) there is a bug in the example,
> in that tts:visibility="false" on the paragraph means the paragraph
> (and its children) will never be visible. The example DFXP document
> should have read:
>
> <p region="r1" dur="4"> <span tts:visibility="hidden"> <set begin="1"
> tts:visibility="visible"/> Curiouser </span> <span
> tts:visibility="hidden"> <set begin="2" tts:visibility="visible"/>
> and </span> <span tts:visibility="hidden"> <set begin="3"
> tts:visibility="visible"/> curiouser! </span> </p>
>
> We will fix.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.3.6) The generic font family names suggest specific kinds of fonts,
> but the spec effectively says to expect nothing. In that case, why
> aren't they called "font1" to "font5"? Some help for implementers
> seems useful. If an implementation has different fonts available, I
> think users would like it if the fonts are mapped somewhat
> intelligently.
>
> Response:
>
> Well it is either implementation dependent or not. We really want the
> former. We prefer to let the market decide whether an implementation
> does something sensible or not. To do something formal would require
> introducing PANOSE concepts or equivalent which doesn't seem
> particularly worthwhile.
There is a middle ground between not specifying anything and specifying
every last bit. The names clearly suggest that the font families are
neither arbitrary nor fully specified, but the definition fails to
follow up on that. Whether the "market" will solve it depends on how
open that market is. If there is a dominant implementation that fails
to do something reasonable, then the result is effectively that the
feature disappears, independent of whether users want it or not.
But we won't insist. Let's just hope that by the time the spec is
updated the "market" will not have made it impossible to fix this.
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.3.6) The generic font families are different from those in XSL/CSS.
> Maybe DFXP doesn't need "fantasy" and "cursive," but it could have
> kept
>
> "sans-serif" and "serif" without renaming them. Also, is the
> difference "monospace-sans-serif" vs "monospace-serif" really needed?
> Just one monospace font has been enough for all my uses (which
> weren't subtitles, I admit).
>
> Response:
>
> The TT WG believes there are a number of examples of all combinations
> of {monotype,proportional} x {sans-serif,serif} in use in
> international subtitling applications that justify labeling all
> combinations.
That sounds like a contradiction with the previous issue: it is
important to distinguish serif monospace from sans-serif monospace, but
it is not important to define that 'monospace-sans-serif' and
'monospace-serif' are different (where possible)?
It is a bad idea to use a feature that exists in CSS/XSL (apart from the
CamelCase) but change the values.
If you are keen on re-use (as your answer to the first issue, on
namespaces, indicates), then you should not throw away people's
knowledge so easily. There is no reason to rename sans-serif to
proportional-sans-serif and serif to proportional-serif.
What to do? Clearly, it is possible to define those keywords, but the
fact that CSS and DFXP are different for no apparent reason will look
bad...
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.3.11) The units px, em and c are defined syntactically, but what do
> they mean? I assume px is as in XSL/CSS and em is the font-size,
> because 8.2.10 mentions an "EM square" in relation to font-size. "c"
> is probably the cell as defined by 6.2.1 cellResolution.
>
> Response:
>
> We will add a cross-reference to XSL definitions and expand further
> on the definition of "c". But see more below on "em".
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.3.11) Is the em unit the vertical font size or the horizontal one?
> Or does that depend on whether the length is used to measure
> something horizontal or vertical?
>
> Response:
>
> We will elaborate that "em" in the context of a font that expresses
> an anamorphic size has two interpretations depending on the context
> of usage, i.e., depending on whether the length is being used to
> express a distance along the block or inline progression dimensions.
You mean that "extent='1em 1em' is not necessarily square? That's the
answer we hoped not to hear...
Why not simply say that 1em is the height of the font? Then you also
avoid any future problems if you want to use ems in diagonals or in
rotated things.
We think you will regret the definition you are going to add, but at
least there is a definition now, so the issue is solved...
>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 10.1.2) begin, end and dur attributes: what happens if they conflict?
>
> Response:
>
> At present, section 10.4 normatively references the semantics of SMIL
> 2 for the purpose of interpreting these attributes, as well as
> dealing with possible conflicts (over-constraint scenarios). We are
> considering fully inlining the timing interval semantics into the
> spec, which is a greatly reduced subset of SMIL 2 timing semantics;
> if we do this, then the usage and constraints on these attributes
> will be fully articulated.
OK
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
Received on Friday, 14 October 2005 16:40:22 UTC