[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-econtracts] CSS - "hanging indent" attempts
here you go Jason --- and successfully tested with Mozilla 5.0 -- the solution i shared before works only for IE, but the solution attached works for both browsers. Same drill -- the css goes with the xml version. For the html version, the css is embedded. Responses to other memos: >My contention was that John is saying we absoutely must design our XML >so that CSS is able to style it perfectly. Jason, that's not what I am saying, nor is it the question for today. I say our specification must accommodate the final XML presentation of the contract, not a precursor to the presentation -- people sign the presentation, not the precursor. Framing the issue in terms of "perfection of browser support for CSS" as you do throughout this memo, unnecessarily boxes this TC into just one solution: an XML dialect for a contract. Sure, if our specification is for an XML dialect, then the only way that it may presented as the contract artifact itself is by use of CSS. However as you are well aware, I support other presentation dialects, eg XHTML, XSL-FO and SVG, being annointed by this group as just as valid as XML/CSS, and have shown repeatedly how to annotate them in a manner that relates explicitly to an XML dialect crafted specifically for contract information. I don't recall that you've ever addressed how someone can exchange an XML version of the final contract, one that achieves the "presentation perfection" you're looking for. I think this is the fundamental question for today - are we exchanging a 'real' contract or not? ===================================================== Observation 1: Depth of Nesting. Jason has it nested in 5 containers, John has it nested in 10 containers. Response: True, because the markup considered the issue of presentation containers, that is, the "BlockBody"... if those are removed, and they can be in a default case I guess, then we have the same number, right? ===================================================== Observation 2: <en> tag: Each piece of text in John's markup is surrounded by the <en> tag. This extra container is annoying to have to keep adding when one is using an XML editor, and something end users will complain about. Response: You have not said what your alternative is for identifying text strings within a Paragraph that has specific styling attached to it. While you complain about the perceived redundancy, you fail to explore why it's there. ===================================================== Observation 3: <BlockCaption> and <BlockBody>: <BlockCaption> and <BlockBody> are sometimes present in John's markup, and sometimes absent. It seems the <BlockCaption> element is used whenever there is a <CaptionTitle> (although there is an empty CaptionTitle on 6.4(a)(1) - why is that?) Response: It depends on whether the CaptionTitle is layed-out with the BlockCaption, or whether it is actually a part of the BlockBody. The empty one is clearly redundant -- I was modifying another file for the benchmark challenge. ===================================================== Jason: Sometimes you don't need a <BlockBody> - there isn't one in <FirstParagraph> or <FirstSubPart>. I'm not sure when you do, and when you don't. Response: BlockCaptions and BlockBodys only apply to Article, Section, and Clause elements. Because Paragraphs (and SubParts) are not caption-able, then there is no need for a BlockCaption or, hence, BlockBody. ===================================================== Observation 4: Recursive use of Clause element: Confusing for users, i think. Response: This occurs at level 4 and below. I am not worried about this, since the great majority of docs will only use 3 levels (important note: I don't view or handle Lists as you do). It's ironic you complain about a hybrid model that includes the approach that you wanted originally -- recursion. I think it's a very savvy way to address the deep nesting requirements that some users will have, that some applications will accommodate. In my product, I simply call these "SubClauses" but then again, I don't expose users to the DTD. Those that wish to use a DTD-driven entry application I think won't be so terribly confused -- if they are, they'll undoubtedly rearrange their content so that there's 3 or fewer levels. Not a problem in my mind. ===================================================== Observation 5: <FirstParagraph>, <FirstSubPart>. John's XML distinguishes the FirstParagraph from a subsequent Paragraph; similarly for FirstSubPart. Jason's XML makes no such distinction. This might not be necessary if you assume complete browser support for CSS2 selectors - John what has been your experience with web browser support for CSS2 selectors? Sometimes the element in <FirstParagraph> is called <FirstSubPart>, sometimes its called <SubPart>. I'm not sure whether this distinction is made for styling purposes? Response: CSS only supports a selector for 1st child, not for first child of a type. And yes - the FirstSubPart is equally distinguished from SubPart as FirstPara is from Para, for styling purposes. I have no requirement that FirstSubPart or FirstPara must be used if one does not need to distinguish the styling of a subsequent SubPart or Para. I have been thinking that a FirstArticle, FirstSection, and FirstClause are equally needed. BTW, thanks to Dave Marvitt for SubPart -- it's really very handy. >-----Original Message----- >From: Jason Harrop [mailto:jharrop@speedlegal.com] >Sent: Wednesday, April 23, 2003 3:52 AM >To: legalxml-econtracts@lists.oasis-open.org >Subject: [legalxml-econtracts] CSS - "hanging indent" attempts > > >Hi > >Please find attached various attempts to get hanging indents to work >using CSS2 stuff. > >Apparently, example 3 works in Internet Explorer (6?), though I don't >have IE running on this computer. > >None of them work well enough in Mozilla 1.2.1 to amount to a >presentable "presentation format", although some of them come close. > >cheers, > >Jason >(a) The Tenant's request for remittance shall be accompanied by (A) a certificate of Tenant (in form reasonably satisfactory to Landlord) stating that an amount at least equal to the Reimbursement Amount has been paid to contractors, subcontractors, materialmen, engineers, architects or other persons (whose names and addresses and a description of the work involved shall be stated) who have furnished labor, materials, supplies, permits or services for the work in question (collectively, "Contractors") and that to Tenant's best knowledge (after due inquiry) there is no outstanding indebtedness due for labor, materials, supplies, permits or services in any manner connected with the work in question which if unpaid might be the basis for any type of lien on the Leased Premises or any part thereof, and (B) a certificate of the architect or engineer who prepared the related Plans and Specifications (in form reasonably
LEGALXML {display:block} Clause {display:block} BlockBody {position:absolute;left:5%;} BlockCaption {position:absolute;width:5%}
<?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/css" href='hangingindent.css'?> <LEGALXML> <Clause> <BlockCaption><en>(a)</en></BlockCaption> <BlockBody><en> The Tenant's request for remittance shall be accompanied by (A) a certificate of Tenant (in form reasonably satisfactory to Landlord) stating that an amount at least equal to the Reimbursement Amount has been paid to contractors, subcontractors, materialmen, engineers, architects or other persons (whose names and addresses and a description of the work involved shall be stated) who have furnished labor, materials, supplies, permits or services for the work in question (collectively, "Contractors") and that to Tenant's best knowledge (after due inquiry) there is no outstanding indebtedness due for labor, materials, supplies, permits or services in any manner connected with the work in question which if unpaid might be the basis for any type of lien on the Leased Premises or any part thereof, and (B) a certificate of the architect or engineer who prepared the related Plans and Specifications (in form reasonably </en></BlockBody> </Clause> </LEGALXML>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]