- From: Ernest Cline <ernestcline@mindspring.com>
- Date: Wed, 11 Feb 2004 21:54:19 -0500
- To: "Boris Zbarsky" <bzbarsky@MIT.EDU>, "BIGELOW,JIM (HP-Boise,ex1)" <jim.bigelow@hp.com>
- Cc: www-style@w3.org, "Michael Day" <mikeday@yeslogic.com>
> [Original Message] > From: Boris Zbarsky <bzbarsky@MIT.EDU> > > So if in the future you introduce a meaningful (in that it has special > semantics) identifier other than "auto" here, pages that use that as a > page name break? > > Is there a reason not to just use strings for page names and auto be an > identifier? That is: > > page: auto | <string> > > That would be much more future-proof. Agreed, but the 'page' property while not part of CSS2.1 is part of CSS2. If the list of allowable values were switched as Boris suggested we would need to do one of the following 1) Use a kludge like that used with the 'font-family' property. 2) Deprecate page and use a different property name such as 'page-name'. 3) Make a break with CSS2. I don't like kludges. Deprecating 'page' won't affect any of the major browsers AFAIK, but there is at least one UA that is using 'page' already. Ditto for making a break with CSS 2. If there wasn't at least one implementation, I could see doing as Boris suggests and change <identifier> to something else, but there is one. Unless you can think of a better reason than there might be another keyword that would be useful without a suggestion of what it might be, I think it would be best to keep 'page' as either "auto | <identifier>" or "<identifier>" for now and reserve option 2 above for when someone can come up with a good keyword. that only makes sense for the 'page' property.
Received on Wednesday, 11 February 2004 22:10:05 UTC