OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[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

--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms      
http://www.maxprograms.com

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Lieske, Christian
Sent: Wednesday, February 22, 2012 12:22 PM
To: XLIFF TC
Subject: [xliff] HTML attributes for at-a-glance feature - CSS-based Approach

 

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,

Christian

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Arle Lommel
Sent: Dienstag, 21. Februar 2012 19:01
To: XLIFF TC
Subject: [xliff] HTML attributes for at-a-glance feature

 

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]