[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Behavior of <q> element
But we have established that there are some basic rendition expectations that need to be defined as at least expected default behaviors, such as enumeration of ordered lists and whatnot. I don't see why having <q> generate quotes is not clearly in that same category. Of course we should not mandate that as the only allowed behavior, but I think having it be the expected default behavior is entirely appropriate and consistent both with the original design intent and typical user expectation. Cheers, E. On 1/6/09 12:37 PM, "Grosso, Paul" <pgrosso@ptc.com> wrote: > But the point is that a user cannot do anything about > browser behavior, so it is appropriate for that to be > standardized. > > However a user is supposed to be in charge of what style > is applied to their DITA content. A large part of the > whole thrust of SGML/XML and structured content for > decades has been the separation of format (and other > application-specific processing) from the content. > This improves reusability and makes localization > easier (because different uses and locales can apply > different stylesheets to the same content). > > It is wrong for the DITA standard to be standardizing > format or any behavior beyond the basics that make > DITA DITA. > > If we start talking about how to format the <q> element, > then where do we stop? I don't see that we need to say > anything here about format in the DITA language reference. > We aren't supposed to be documenting how the toolkit > formats DITA, we're supposed to be writing a specification > for how to create DITA content. > > paul > >> -----Original Message----- >> From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com] >> Sent: Tuesday, 2009 January 06 11:48 >> To: dita >> Subject: RE: [dita] Behavior of <q> element >> >> This could be in the form of a recommendation against additional >> quotation marks, coupled with the observation that if you do elect to >> add your own quote marks, you must of course not render <q>...</q> as >> quotation marks, and that there is an overhead cost for >> localization and >> portability (one of Gershon's points). >> >> Of course <lq> like <BLOCKQUOTE> shouldn't have this issue, >> but I -have >> seen people put quotation marks around an indented paragraph, so there >> could be an educational aspect to this. >> >> The W3C/HTML language has to deal with inconsistent browser behavior >> (Microsoft is noncompliant until IE-8), whereas we have inconsistent >> stylesheet behavior to consider. >> >> /BN >> >>> -----Original Message----- >>> From: Grosso, Paul [mailto:pgrosso@ptc.com] >>> Sent: Tuesday, January 06, 2009 10:59 AM >>> To: dita >>> Subject: RE: [dita] Behavior of <q> element >>> >>> I'd rather not say this. It's a style question that may >>> differ from one house to another as to whether they want to >>> author the quotes or not and/or how the quote is to be presented. >>> >>> The determination of what text may be generated for a given >>> element in a given context and/or what other formatting it >>> gets for a given output (e.g., one may format things >>> differently for PDF output and HTML >>> output) should be left to the style specification, however >>> such is provided to a given composition system. >>> This is outside the scope of the DITA specification. >>> >>> So the answer to how <q> should be processed is that it >>> should be processed however its style specification indicates >>> for a given application. >>> >>> paul >>> >>>> -----Original Message----- >>>> From: Robert D Anderson [mailto:robander@us.ibm.com] >>>> Sent: Tuesday, 2009 January 06 9:44 >>>> To: dita >>>> Subject: [dita] Behavior of <q> element >>>> >>>> >>>> Hello, >>>> >>>> Going through the review comments to the specification, I >>> found that >>>> somebody asked for examples of how <q> should be processed. >>>> Generally, we >>>> try to stay away from processing behaviors, but this one >> may be an >>>> exception. The current description gives no suggestions as >>> to whether >>>> or not quotes should be generated. I checked the HTML 4.01 >>>> specification to see what they say; that specification >> says that q >>>> must be rendered with quotations, and that users should not >>> add their >>>> own quotes. >>>> It goes on to >>>> say that the quotes should be rendered in a >>> language-sensitive manner. >>>> See the section on rendering quotations: >>>> http://www.w3.org/TR/REC-html40/struct/text.html#edef-Q >>>> >>>> Should we make a similar statement? I do not want to add >> behaviors >>>> that MUST be done without consulting the full TC, so - this is my >>>> consultation. >>> >>> >> --------------------------------------------------------------------- >>> To unsubscribe from this mail list, you must leave the OASIS >>> TC that generates this mail. Follow this link to all your >>> TCs in OASIS at: >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr >>> oups.php >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr >> oups.php >> >> > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]