[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] HTML attributes for at-a-glance feature - CSS-based Approach
There is no need to change anything in XLIFF 2.0 to use CSS or XSL stylesheets for previewing XLIFF files as HTML. This possibility existed before and is still valid. Bryan’s goal, as I see it, is to have the ability to specify when the XLIFF is created the desired HTML elements to use for rendering as HTML. That is quite different from using CSS or XSL stylesheets. Regards, Rodolfo -- From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Lieske, Christian Dear TC, I attach a sample XLIFF and a CSS which might help to better understand my suggestion to investigate a CSS-based approach. Of course, this toy example has not been tested in all browsers ;-) Cheers, From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Arle Lommel Bryan, I really like the idea of being able to store information about HTML preview in the XLIFF file. I think it would be tremendously useful since you cannot, in many cases, reconstruct the rendering intent from the XLIFF file. For example, if I am working with a custom XML format, even encapsulating a tag like <productCode> in the XLIFF is useless unless you have some predefined rendering intent. On the other hand, if the importing tool knows to map that code to a particular, limited set of elements, it would be very useful for everyone downstream. My thought is that we would need to limit the allowable HTML elements to those that can exist independently within the context of <p>. This would exclude items like <li> that cannot exist in a <p> tag. It would also eliminate <div>, <table>, and many other important HTML elements. My rationale for this scope limitation is that the goal should properly be to provide some idea of formatting to the translator within the segment, not of the whole document structure. Trying to move up the ladder to show more structure would open a can of worms in terms of complexity and requirements for the interpreting agent. Best, Arle |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]