 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / CSS / August 2007Force split of unique long word in a narrow TD
I have a narrow TD in a TABLE. It has a width=SomeNumberpx constraint. SomeNumber is much less than the width of a unique word. I would like to split within the TD, according to the width of the TD. The width of the TD is not know at priori but it is only know that it can be smaller than the word I need to fit. There are no restriction to the TD's height. I cannot change the TD to a DIV. My question: is there a way to split the word so that it "wrappes" up in the the TD ?? Example: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http:// www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head> <title>Example</title> </head> <body> <table><tr><td style="width:5"> Precipitevolissimevolmente</td></tr></ table> <table><tr><td style="width:10"> Precipitevolissimevolmente</td></tr></ table> </body> </html> Any hint? PS The solution should work for any TD width. Forgot the unit in my example. Here it is: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http:// www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head> <title>Example</title> </head> <body> <table><tr><td style="width:5px"> Precipitevolissimevolmente</td></ tr></table> <table><tr><td style="width:10px"> Precipitevolissimevolmente</td></ tr></table> </body> </html> I would like the TDs have the **actual** width 5, 10 pixels. -P Scripsit pamela fluente: > I have a narrow TD in a TABLE. It has a width=SomeNumberpx > constraint. So remove the constraint. Problem solved. Or, rather, undone. There was a problem just because you created it that way. > SomeNumber is much less than the width of a unique word. > I would like to split within the TD, according to the width of the > TD. This is discussed in various WWW authoring groups rather regularly, if not weekly. Did you check past discussions before posting? > My question: is there a way to split the word so that it "wrappes" up > in the the TD ?? Absolutely maybe. > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" That's commonly regarded as bogosity alert in WWW authoring groups. Did you check past discussions before posting? > <table><tr><td style="width:5"> Precipitevolissimevolmente</td></tr></ > table> Sorry, but that's really ridiculous. Even if you fix 5 to 5px, making the CSS code conformant, it's really ridiculous. Why would you use a single-cell table that way, and why would you allow only 5 pixels width. Even a single character requires more width than that under fairly normal circumstances; "i" might fit, but "W" probably won't. So what are you really doing? If you really have a situation where data should be handled that way, and I doubt it*), then you need to define _how_ the string should be broken: a) by hyphenation, adding a hyphen at the end of a line; never mind asking "by which language's rules", since you need to specify hyphenation points manually anyway b) at specified points of division without inserting a hyphen c) as emergency breaks where a string may be broken at any point without inserting any hyphen (and making the user wonder whether "foo" on one line and "bar" on the next really means "foo bar" or "foobar") *) Problems like this typically emerge when people try to set up discussion forums, then find out that users can spoil them by sending very long "words", by accident or by malevolence. The real solution is to handle the issue server-side. If you have no idea of what this means, don't try to create a forum. There is no global shortage of web-based forums; their average amount of users is probably below 1.  SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > Scripsit pamela fluente: > Sorry, but that's really ridiculous. Even if you fix 5 to 5px, making the > CSS code conformant, it's really ridiculous. Why would you use a single-cell > table that way, and why would you allow only 5 pixels width. Even a single > character requires more width than that under fairly normal circumstances; > "i" might fit, but "W" probably won't. So what are you really doing? Thank you Yukka. I have my precise reasons form my question. 5 or 10 are just examples. Let's assume. if you like, that the minumum width will fit at least on character of the current font. Do not care about doctype. See my other post. I will be using html 4.01 in my code: .Append("<!DOCTYPE HTML PUBLIC ""-//W3C//DTD HTML 4.01// EN"" ""http://www.w3.org/TR/html4/strict.dtd"">") .Append(vbCrLf & "<html>") The point here is: can I split a word in a TD yes or no? Usually when there are replies in your style, the reasons can be 2: - it is not possible: so answer is NO - who answers does not know how to do it > If you really have a situation where data should be handled that way, and I > doubt it*), then you need to define _how_ the string should be broken: > a) by hyphenation, adding a hyphen at the end of a line; never mind asking > "by which language's rules", since you need to specify hyphenation points > manually anyway I am not caring about hyphenation. I am trying to render a design that someone can have done in an arbitrary way. And I have to render that design precisely, splitting the words the same way as they appear in the design (no care about meaning: these words can be codes). I am doing this programmatically. I am aware that I am missing some well know resource but I come here only rarely to ask some doubt. -P PS btw: What "bogosity" means? Scripsit pamela fluente: > I have my precise reasons form my question. Without disclosing those reasons, and illustrating them with a URL, you can hardly expect to find a correct solution (though you might find a solution that pleases you, for the time being). > 5 or 10 are just examples. But hardly by accident. Besides, the point is setting a fixed width, not the specific with, though 5 or 10 pixels were... maybe just particularly bad examples, maybe symptomatic. > Let's assume. if you like, that the minumum width will fit at least > on character of the current font. We can't assume anything like that. The font size is ultimately under user's control. I just had some conversation with a guy who helps visually impaired people and told me that many of them prefer using a visual browser with huge font size (perhaps so that just a few letters fit on the screen) to using a screen reader. > The point here is: can I split a word in a TD yes or no? As I wrote, absolutely maybe. You didn't answer my crucial questions. > Usually when there are replies in your style, the reasons can be 2: > - it is not possible: so answer is NO > - who answers does not know how to do it Babbling like that does not help you. Neither of the assumed reasons is correct, except relative to the vagueness of the question. It is impossible to answer correctly your question when the question is so imprecise, in a manner that I described previously. > I am not caring about hyphenation. Oh. In another post here, you seem to be interested in ­, which is all about hyphenation. > I am trying to render a design > that someone can have done in an arbitrary way. And I have to [quoted text clipped - 3 lines] > codes). > I am doing this programmatically. This is still all too vague. You are sending mixed messages about the nature of the desired splitting. Words or codes? Can a code be split without losing information? Can it be split at any point? And if you want to "render that design precisely", why don't you include just forced line breaks? > I am aware that I am missing some well know resource but I come here > only rarely to ask some doubt. You're supposed to read the group for a while before posting. You can act otherwise, but then you might end up with lots of unnecessary rounds of discussions, making people exhausted just before they might finally have access to your actual problem and could start answering it. > btw: What "bogosity" means? It's a derivative of "bogus". SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > Scripsit pamela fluente: > > It's a derivative of "bogus". It's a recursive answer Jukka :-))) You are absolutely right. I am well aware it's not completely clear why I need that. I a going to post a few sample pages with a more explanation of the problematic I am encountering. I need a little to place the web pages on line because I am finishing to write the export routine to generate them right now . I will be back in a while. Dont' go away! :-) Thanks a lot. -P > I have a narrow TD in a TABLE. It has a width=SomeNumberpx > constraint. SomeNumber is much less than the width of a unique word. > I would like to split within the TD, according to the width of the > TD. 1. Leave this to the browser to handle. It will do a better job than you can, because it knows things you cannot ever know, such as the _current_ width of the user's windows and the size of the table cell in terms of the user's _current_ choice of font size. This stuff just isn't settable at design time. 2. If you're going to impose restrictions on the width of blocks of text, then do it with em units rather than pixels. 3. Don't impose limits like this. Use a fluid design instead. Setting narrow columns is obviously problematic, and that's also an indication it's a bad idea a priori. 4. Don't impose limits on overall page layout. I suspect that you _think_ you need to do this because of some idea that you must limit your page content to a narrow stripe down the user's window, regardless of how the user sizes that window. That in itself is wrong. If you don't understand the reasoning behind all of these recommendations, and can't provide a valid argument as to why they don't apply to your page (your page is Special and not like any other page on the web), then you shouldn't do it. > 2. If you're going to impose restrictions on the width of blocks of > text, then do it with em units rather than pixels. I fully understand and agree what you say. However my current work is on an export routine of some design done by a user with a graphic tool. So at least the first shot must be equal to his design. The challenge is to produce a result that is equal to his design, but also allowing to be smehow "fluid". Ok one corrections can do is to covert the font size (px) in em as you suggest. How can I convert precisely px in em ? ... > If you don't understand the reasoning behind all of these > recommendations, and can't provide a valid argument as to why they > don't apply to your page (your page is Special and not like any other > page on the web), then you shouldn't do it. The argument is that I am doing a web rendering of something designed with another graphic tool. The effort is to produce a result that is as close as possible to the user design (which will also be exported by other means such as PDF). But also, after exportation, be a meaningful web page. It's not easy at all. -P > How can I convert precisely px in em ? By dividing the width in pixels by 12.000, rather then the terribly imprecise value of merely 12. I suspect you mean "accurate" here rather than "precise". The question is meaningless (and rightly so) because the whole point of sizing in ems is that they don't correspond to a known number of pixels, _except_ for a particular user with particular settings. That's their very benefit - by tracking the thing you care about (how wide is this thing compared to the text?) you can set the width in a way that's stable for all users. A word will take just about the same number of ems to display reasonably well for all users, but it will vary radically as to how many pixels. As a starter, just assume 12 pixels is about an em. That's OK. What would be wrong would be to go the other way and to convert an em measurement into pixels. > The argument is that I am doing a web rendering of something designed > with another graphic tool. As the web is a declarative medium, not a graphical medium, why do you think this is a good idea? Why use an inappropriate graphical tool for a non-graphical medium? The web can of course be a graphical medium. Render eveything to a bitmap first, then just serve JPGs instead of HTML. If you think that's a bad idea (and obviously it is) then ask yourself why trying to emulate it with pixel-rigid design is any better? The web (used correctly) doesn't deliver precise bitmaps of pages. Instead it delivers a set of requirements for how to diisplay the page, expressed as a set of statements. 'Draw the text "Foo"', 'Put this text after that other text', 'Make this text bigger than some other text', 'Surround this text with a border'. The browser then takes these requests and tries to achieve all of them simultaneously. Often it can do, often it can't. If your page requests "Make the text big" and the user requests "Make the window this size", then something has to give -- and it ought to be the design rigidity, not the user's window size. Client-side rendering is all about compromise. > The effort is to produce a result that is as close as possible to This is the single most bogus design concept in web design. (The second most bogus concept is that the rendering of a page should be identical between browsers) > the user design What's a "user design" ? Now unless you've asked the users, and unless you've found out their browser settings, then you have no such thing. If you did have such a thing, then you'd need multiple copies of it (thousands of 'em!) to cope with users re-sizing their windows and changing font sizes. This design is a "designer's design", not a user's design. Recognise its limitations, most obviously being that the designer can never know how each particular user is accessing it. The choice is to either be fluid, or to be wrong for many of them. You can't force "the right design" down their throats. The only thing worse than this is when the designer _does_ know the user's display characteristics, because they've taken steps to force them upon the user. The common result here is to find yourself with no user, rather than a suffering and compliant user. > (which will also be exported by other means such as PDF). PDF is generally more likely to be "pixel-fixed" compared to HTML, but even there it (fortunately) permits some flexibiliy. A PDF with rigid bitmaps embedded also makes users suffer. > > How can I convert precisely px in em ? > [quoted text clipped - 69 lines] > even there it (fortunately) permits some flexibiliy. A PDF with rigid > bitmaps embedded also makes users suffer. Thank you Andy for your advice. I do agree with all you say. The point here is that there is a tool which makes documents destined to be printed. And the user has a designer to make these reports. Imagine Quark Xpress or Publisher or whatever. When one has designed a report sometimes he wants also to export it as PDF or WEB pages. Now I understand all your beautiful concepts, but when my export routine spits out the html export I *cannot* reinvent the user design. I am expected to be *as close as possible* , at least at the *first* rendering. The challenge is to be initially precise while allowing a fluid layout. It's quite difficult. (If not impossible). I will post later a few links to show the problems so you can provide some advice to this purpose. So my goal is: first shot equal to user layout but using all features which allow the layout to float or at least not be completely nailed. A big problem is also that some items must maintain relative position otherwise the report messes up. -P > I do agree with all you say. The point here is that there > is a tool which makes documents destined to be [quoted text clipped - 3 lines] > When one has designed a report sometimes he wants also to export > it as PDF or WEB pages. > A big problem is also that some items must maintain > relative position otherwise the report messes up. I think this is like asking directions of a stranger in Dublin: traveller: "How do I get to Trinity College?" local: "I wouldn't start from here." From your description above, you are being asked to do something crazy. The sane way of dealing with this sort of problem (where the data are complex and presentation is vital) is to store the data in some sensible format and output it in different ways using different designs for different media. You have my commiserations. SignatureJón Fairbairn Jon.Fairbairn@cl.cam.ac.uk >I do agree with all you say. The point here is that ... As soon as I read that I knew that you hadn't listened to a word 8-( > there is a tool which makes documents destined to be printed. Print. It does it onto paper, which is fixed. So why are you using it for a web page which isn't ? >When one has designed a report sometimes he wants also to export >it as PDF or WEB pages. You can use HTML + CSS as a format for fixed-layout printing onto paper. This is different to a "web page" though. >So my goal is: first shot equal to user layout but >using all features >which allow the layout to float or at least not be completely nailed. This is simply the wrong way to do it. Scripsit Andy Dingley: > As a starter, just assume 12 pixels is about an em. Sorry, but that's very wrong advice. Especially to novices. Even if it were true in the average in some situation, it would be as wrong as saying that a metro trip costs 5 kopecks. (Things used to be that way in Moscow for a long time - I have been told -, but it was never safe to assume that as a general, universal rule, or even its local applicability through all ages.) Moreover, the browser default for an em - in the absence of any user or author settings - is most often 16 pixels, not 12. That means 12 _points_ probably more often than anything else. But it could be anything. Even within a single computer, when its monitor resolution is changed. SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ >Sorry, but that's very wrong advice. Especially to novices. Don't be such a pinhead as to take one line entirely out of context so as to reverse the meaning of the entire post. Scripsit Andy Dingley: >> Sorry, but that's very wrong advice. Especially to novices. > > Don't be such a pinhead as to take one line entirely out of context so > as to reverse the meaning of the entire post. "Just assume 12 pixels is about an em" is simply wrong. The context was teaching basics of CSS to novices, and in that context it was very wrong. Whatever the post might otherwise contain does not change that. SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > "Just assume 12 pixels is about an em" is simply wrong. Of course it is, in isolation as general advice about CSS. That's not what it was though, and the context made that clear. If you have old px-based CSS to convert, then an early task is to map the units from one to the other. For this you need to assume (with all the implications of "assume") some ratio for the conversion. Perhaps 16 is a better number than 12. As assuming 12 gives you larger results than 16, then I'd suggest using 12 for starters (it'll give you something lumpy, not something invisible). You'll need to rework it afterwards anyway. Refactoring code is a gradual process of small steps (read Martin Fowler's books, the principals work just as well in markup as they do for procedural code). By making small changes with known side-effects of manageable consequence, you can gradually rework a design from bad to good, without needing to throw the whole thing away and start from scratch. It's not always possible, but it usually is, and this appears to be such a case. Part of that process may be to take a rigid pixel-sized design and re- code it, such that the sizes are now in the right units, even if their values are arbitrary and no longer ideal (in any window size). At least they're a readable presentation of an intermediate step that allows you to carry out the next step, that of adjusting the sizes to more appropriate values. As usual, you would rather fabricate some nit-pick over an irrelevance than you would advise the OP how to actually get their task completed by the best manner. How would _you_ convert "width: 200px;" into a more fluid design? Scripsit Andy Dingley: > If you have old px-based CSS to convert, Pixel-based CSS needs no conversion but redesign, and it _cannot_ be converted to em based CSS, any more than you can convert sheep to cows. You might pick up a ratio like 12 sheep = 1 cow, but that's quite arbitrary. > then an early task is to map > the units from one to the other. Nope. No matter how much you want to map sheep to cows, there is no conversion factor that you should or could "assume". But if you want to convert in the sense that the page looks roughly the same _under common browser defaults_, then the mapping is 1em = 16px. Using 12px is simply a wrong figure. > Perhaps 16 is a better number than 12. All numbers are equal, though some numbers are more equal to others. But the common default is 16px, not 12px. There's no "perhaps" about it. > As assuming 12 gives you larger results > than 16, then I'd suggest using 12 for starters (it'll give you > something lumpy, not something invisible). You'll need to rework it > afterwards anyway. That's pointless. If the purpose is to redesign the page, then all the px values should simply be forgotten. It's not self-evident at all that _any_ width should be set for a table cell, for example. If you set a width, you should set it for a reason, not because someone else had set it to some px value. > Refactoring code is a gradual process of small steps And pointless when applied to CSS code. > By making small changes with known side-effects > of manageable consequence, you can gradually rework a design from bad > to good, without needing to throw the whole thing away and start from > scratch. Even in the rare cases where that might be true, it's probably _faster_ to start from scratch. Poorly written CSS code probably has lots of pitfalls. > It's not always possible, but it usually is, and this appears > to be such a case. I haven't seen the case presented. Have you? Just saying there's a narrow td, with some px width, which wasn't the real width, is not a case description. So far we only know that the width created the problem. Replacing it by an em valued width creates a different problem, but why would we do that without having the slightest idea of what is going on? > As usual, you would rather fabricate some nit-pick over an irrelevance > than you would advise the OP how to actually get their task completed > by the best manner. I'd rather nitpick than point a newbie into a wrong direction and waste of time. > How would _you_ convert "width: 200px;" into a more fluid design? I wouldn't. And neither would you. It's not a matter of conversion. If you want fluid design, you simply remove that declaration, instead of converting anything. SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ Jukka K. Korpela schrieb: > But if you want to convert in the sense that the page looks roughly the > same _under common browser defaults_, then the mapping is 1em = 16px. > Using 12px is simply a wrong figure. If the pixel-based version uses a font-size of 12px, then the OP will use 12em/16 = 0.75em instead. I don't think we like that, do we? SignatureJohannes Koch In te domine speravi; non confundar in aeternum. (Te Deum, 4th cent.) Scripsit Johannes Koch: > If the pixel-based version uses a font-size of 12px, then the OP will > use 12em/16 = 0.75em instead. It gives the same rendering in typical default conditions. In that limited sense, it means _conversion_. > I don't think we like that, do we? If you want to convert, that's the closest to a conversion that there is. I have mentioned that such conversions are pointless, but that's a different issue. SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > Scripsit Johannes Koch: > [quoted text clipped - 13 lines] > -- > Jukka K. Korpela ("Yucca")http://www.cs.tut.fi/~jkorpela/ It's not important if the conversion is complicate, because it is programmed in the generator of HTML code. It's important that be correct (precise). -P PS. Still struggling with the generator code... > It's not important if the conversion is complicate, because it is > programmed in the generator of HTML code. Then that would be clearly and totally wrong, for all the reasons that Jukka correctly cites. I don't disagree with Jukka's point, merely about the scope of his literalist reading. I never intended (and you shouldn't try to implement) a live conversion where "12/14/16px = 1 em", merely a starting point for a one-off conversion process. > Pixel-based CSS needs no conversion but redesign, and it _cannot_ be > converted to em based CSS, "Cannot be done" > @cs.tut.fi And a .ac hostname. These two things are related. Those of us from the .com world don't have the luxury "We shouldn't do that" as an option, we just have to get on and do it. Sometimes one's lucky enough to get to do it right, but it _must_ get done, and if you aren't going to do it yourself correctly, there's always someone prepared to do it quickly and badly. Scripsit Andy Dingley: >> Pixel-based CSS needs no conversion but redesign, and it _cannot_ be >> converted to em based CSS, > > "Cannot be done" Is there an echo here? >> @cs.tut.fi > > And a .ac hostname. I think you missed some of the content of Internet 101. > These two things are related. You seem to build up rather odd relations. > Those of us from the .com world don't have the luxury "We shouldn't do > that" as an option, we just have to get on and do it. Oh, you're from the Real World, Inc.? And shouting that your boss or customer requires you to construct a perpetuum mobile magically implies that those who tell it _cannot_ be done (as separate from "it should not be done") are academic nerds, right. > Sometimes one's > lucky enough to get to do it right, but it _must_ get done, and if you > aren't going to do it yourself correctly, there's always someone > prepared to do it quickly and badly. How entertaining. Though such rants were more amusing for the first 100 times I read them. You seem to have diverged from all connections to CSS authoring here, apparently because you have nothing to disprove the simple fact that a conversion from px to em cannot be made. Besides, it was I who correctly told the size of em in pixels in common, real-world browser practice. It was who you (apparently intentionally) wanted to make the OP use a wrong correspondence (12px vs. 16px, which is a considerable difference), probably due to your design agenda. I have an agenda too, a better one, and I'm honest about it. SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > Oh, you're from the Real World, Inc.? And shouting that your boss or > customer requires you to construct a perpetuum mobile magically implies > that those who tell it _cannot_ be done (as separate from "it should not > be done") are academic nerds, right. The problem with saying that something cannot be done is that you can only ever be proven wrong. That never stops me. Asserting (in public) that something cannot be done is one of the best ways of finding out how it can be done. Let's put this theory to the test: "There is absolutely no way to achieve in Firefox(<3) precisely the effect that ­ has in Opera/Internet Explorer" SignatureSteve Swift http://www.swiftys.org.uk/swifty.html http://www.ringers.org.uk > > Oh, you're from the Real World, Inc.? And shouting that > > your boss or customer requires you to construct a [quoted text clipped - 4 lines] > The problem with saying that something cannot be done is > that you can only ever be proven wrong. Nonsense. There are lots of things that provably cannot be done. SignatureJón Fairbairn Jon.Fairbairn@cl.cam.ac.uk > > > Oh, you're from the Real World, Inc.? And shouting that > > > your boss or customer requires you to construct a [quoted text clipped - 7 lines] > Nonsense. There are lots of things that provably cannot be > done. Like... a male electrician at a nunnery expecting to be able to get away with demonstrating the Lambada to some novice nuns without being ticked off by senior nuns that are watching? Signaturedorayme > > > The problem with saying that something cannot be done is > > > that you can only ever be proven wrong. [quoted text clipped - 5 lines] > get away with demonstrating the Lambada to some novice nuns > without being ticked off by senior nuns that are watching? :-), no, that's more open-ended than the kind of thing I had :in mind... SignatureJón Fairbairn Jon.Fairbairn@cl.cam.ac.uk > > Like... a male electrician at a nunnery expecting to be able to > > get away with demonstrating the Lambada to some novice nuns > > without being ticked off by senior nuns that are watching? > > :-), no, that's more open-ended than the kind of thing I had > :in mind... I dunno, it is an open and shut case, I would bet against it with the same odds given as your two positive non-unit whole numbers that multiply together to give seventeen. But don't worry, I know what you mean. I think you are almost certainly right. <g> Signaturedorayme > Nonsense. There are lots of things that provably cannot be > done. Such as proving to you the fallacy of that statement. SignatureSteve Swift http://www.swiftys.org.uk/swifty.html http://www.ringers.org.uk > > Nonsense. There are lots of things that provably cannot be > > done. > > Such as proving to you the fallacy of that statement. True enough. For seconds, how about giving me two positive non-unit whole numbers that multiply together to give seventeen? SignatureJón Fairbairn Jon.Fairbairn@cl.cam.ac.uk > True enough. For seconds, how about giving me two positive > non-unit whole numbers that multiply together to give > seventeen? Not having used my degree-level mathematics† since 1981 I'm not up to this challenge, because I don't recognise the term "non-unit". I'm sure the problem would be trivial in non base-10 though. Also, they're probably teaching mathematics capable of answering your question in primary schools these days; have you hear Bob Newhart's "New Math"? :-) However, this is out of context - we are talking about things that can be done with a computer, and how effects can be achieved with HTML/CSS/JavaScript etc. If I say "x cannot be done" then its only a matter of time before someone more skilled than I comes up with a solution. That's why I'm learning "C" at this late stage, so that I too can do the impossible. † My degree was in Physics, which included a very substantial proportion of (old) mathematics. SignatureSteve Swift http://www.swiftys.org.uk/swifty.html http://www.ringers.org.uk > > True enough. For seconds, how about giving me two positive > > non-unit whole numbers that multiply together to give [quoted text clipped - 3 lines] > not up to this challenge, because I don't recognise the term > "non-unit". As a physicist you would have been taught, and been proficient in certain areas of mathematics (the ones useful to your subject), but probably not number theory or proof theory... non-unit just means "not 1"¹ in this context. > I'm sure the problem would be trivial in non > base-10 though. No. We're not talking about the representation, so the base is completely irrelevant. Unless you think that it's possible for two positive whole numbers bigger than 17 to multiply together to give 17, there are only sixteen possible candidates for each of the two numbers, so you can go through all the possible cases. > Also, they're probably teaching mathematics capable of > answering your question in primary schools these days; Maybe they are; if they're being tought mathematics, the answer they'll come up with is "no". > However, this is out of context - we are talking about > things that can be done with a computer, But things that can be done with a computer are exactly the type of thing to which this sort of argument can apply. > and how effects can be achieved with HTML/CSS/JavaScript > etc. Leaving aside Javascript (as off topic), the point of the argument is that effects cannot be achieved with HTML+CSS. I could froth at the mouth at considerable length about the vacuity of and lack of formal definition² in the CSS "standards", but the relevant sentence from the CSS 2.1 document is this: 6. The UA must allow the user to turn off the influence of author style sheets. If anyone was hoping for a particular effect, that's "game over", even before we consider the question of whether any "conforming user agents" actually exist. > If I say "x cannot be done" then its only a matter of time > before someone more skilled than I comes up with a > solution. That's why I'm learning "C" at this late stage, so > that I too can do the impossible. A bit of computation theory wouldn't hurt. No one who does not understand the proof of the halting theorem can really call themselves a programmer. C doesn't allow one to do the impossible; it just allows one to be impossible. [1] or anything that behaves like 1 as far as multiplication is concerned [2] which, I admit, neatly prevents any real proofs about CSS SignatureJón Fairbairn Jon.Fairbairn@cl.cam.ac.uk px --> em I began changing the font size to EM, by multiplying the values of the font size for 1 / 16, and using 3 maximum decimals, and removing "px". [I am leaving other things alone for the moment] I do not get the same layout. The fonts are much bigger. What's wrong here ? -P > px --> em > > I began changing the font size to EM, Set the font-size to body { font-size: 1em; } DON'T CHANGE THIS. Don't EVER set font-sizes to anything other than this one default for the whole page, unless you know all the accessibility issues involved in doing so (this ng is a good resource). You just don't need to modify this: if you think you do then you're probably wrong, if you really do, then you should still only change it by a small fraction. Remove all the attempts to set the height of elements. Just let the browser deal with it. Change some padding or margin settings if you need to make tables clearer to read. Convert the width settings you currently have in px into ems, using a ratio of 12 or maybe 16. Then adjust the actual values to fit. Don't worry that things "look different", because this is only a starting point, and they already looked different anyway - you just hadn't realised it. "Pixel perfect" web design is a misleading goal. > > px --> em > [quoted text clipped - 20 lines] > starting point, and they already looked different anyway - you just > hadn't realised it. "Pixel perfect" web design is a misleading goal. Ok I will try. Since the user can make a very precise layout, what I wish is that at least the first generation is exactly what he designed. If he then change the font size or styles or whatever is his business. I just want to make sure he can do it without problems. The "designer" gives the "first-shot" rules, the the user can do whatever he wants with his browser. As to the height, the user could have dragged for some special reasons some rows so that they can be taller than others. Please no not assume that the grid is formatted tightly around the values, because that is only a special case. For this reason I am not currently thinking I can remove the cell heights. Unless I got convinced :-)) Thanks a lot for your continued support. You are very helpful. I will be doing more attempts following your suggestions. I am still missing to see an easy way to eliminate the style repetition. The repetition ALWAYS is as follows (as you can see there are couples of styles): .StyleComplete .... .OnlyTextPropertiesOfAbove .... Is there a way not to repeate the "OnlyTextPropertiesOfAbove" within StyleComplete as I am currently doing ? example: .cellStyle0{background:#f0fff0;border-width:1px;border- style:outset;padding-top:4px;padding-left:4px;padding-bottom: 4px;padding-right:4px;color:#000000;text-align:left;vertical- align:middle;font-family:"Arial";font-size:12px;font-weight:bold} .cellStyle0fg{color:#000000;text-align:left;vertical-align:middle;font- family:"Arial";font-size:12px;font-weight:bold} where this: color:#000000;text-align:left;vertical-align:middle;font- family:"Arial";font-size:12px;font-weight:bold is in common. -P > Set the font-size to > body { font-size: 1em; } Better is body { font-size: 100%; } That avoids a known problem WinIE has with bizarre scaling of ems. SignatureBerg In article <1187886749.978715.199670@q4g2000prc.googlegroups.com>, > Set the font-size to > body { font-size: 1em; } [quoted text clipped - 5 lines] > then you're probably wrong, if you really do, then you should still > only change it by a small fraction. Or body {font-size: 100%;} to deal with a little peccadillo in IE 6 if I recall? Signaturedorayme pamela fluente schrieb: > px --> em [...] > I do not get the same layout. The fonts are much bigger. Adjust the font-size in _your_ browser. SignatureJohannes Koch Spem in alium nunquam habui praeter in te, Deus Israel. (Thomas Tallis, 40-part motet) Thu, 23 Aug 2007 05:25:17 +0100 from Steve Swift <Steve.J.Swift@gmail.com>: > > True enough. For seconds, how about giving me two positive > > non-unit whole numbers that multiply together to give > > seventeen? > > Not having used my degree-level mathematics? since 1981 I'm not up to > this challenge, because I don't recognise the term "non-unit". I think that by "non-unit" Jon meant "other than 1". I don't know whether I'd have been able to figure that out if I didn't already know the definition of a prime number. :-) SignatureStan Brown, Oak Road Systems, Tompkins County, New York, USA http://OakRoadSystems.com/ HTML 4.01 spec: http://www.w3.org/TR/html401/ validator: http://validator.w3.org/ CSS 2.1 spec: http://www.w3.org/TR/CSS21/ validator: http://jigsaw.w3.org/css-validator/ Why We Won't Help You: http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you > Thu, 23 Aug 2007 05:25:17 +0100 from Steve Swift > <Steve.J.Swift@gmail.com>: [quoted text clipped - 8 lines] > whether I'd have been able to figure that out if I didn't already > know the definition of a prime number. :-) To be perfectly honest, I don't know why, given the audience I didn't just say "other than 1"! But we're side-tracked enough here already. My point was that insofar as CSS is defined, being a computational sort of thing, it is something about which one can prove things. It's a great shame that the way it is defined makes this generally infeasible. After all, if you can prove that something someone wants is impossible, you have an excellent case for doing something else. SignatureJón Fairbairn Jon.Fairbairn@cl.cam.ac.uk > 4. Don't impose limits on overall page layout. I suspect that you > _think_ you need to do this because of some idea that you must limit > your page content to a narrow stripe down the user's window, > regardless of how the user sizes that window. That in itself is wrong. What exactly is wrong? I am inclined to set a "max-width:48em;" for paragraphs on pages with much text on it in order to avoid wide paragraphs where the focus of the eye gets lost when searching the beginning of the next line. As it is a *max*-width, the text wraps correctly when the screen is smaller or when the script size selected by the user is larger. As the width is specified in em, the used portion of the screen grows with the script size, which is important especially for sight-impaired persons selecting extraordinary large script. So what is wrong? When I do a stylesheet at all, I impose my ideas on readability (font-style, color, indentation, ...) on the reader of my page anyway -- ideas he can follow or override to the extent the browser allows him. One idea on readability is a certain ratio of paragraph length to paragraph width for the avarage paragraph. What is so special about that ratio that I must not make a suggestion about the value I consider optimal? SignatureHelmut Richter > > 4. Don't impose limits on overall page layout. I suspect that you > > _think_ you need to do this because of some idea that you must limit [quoted text clipped - 3 lines] > What exactly is wrong? I am inclined to set a "max-width:48em;" for > paragraphs on pages with much text on it in order to avoid wide paragraphs Yes, I do that too. However: * It's in ems, not pixels. The real enemy here is "best viewed at 800x600" design. * That's applied to one element of the page, where you can reasonably express a valid reason to limit that element. It's not a crude overall blanket setting across the entire page. If there's a sidebar with an image in it, then I trust that you'd let me see that image at a useful size. * max-width isn't always supported (unfortunately). Using "width" here would be wrong. * 48em isn't "narrow". It might be narrow for some font settings, for other settings it will be appropriately wide. I'm not against restricting the size of design elements in any way when it's justifiable, just the crude blanketting of settings for no good reason. > My question: is there a way to split the word so that it "wrappes" up > in the the TD ?? Nothing to do with stylesheets, but you can insert ­ at the point where you'd like the word to split. If the cell is wide enough, it won't split, but if things get too narrow, it will split the word, inserting a "-" where it split. So "dis­associate" appears either as: disassociates - or - dis- associates I'm not sure about browser support though. It worked for me in Opera and IE but failed in FireFox SignatureSteve Swift http://www.swiftys.org.uk/swifty.html http://www.ringers.org.uk > > My question: is there a way to split the word so that it "wrappes" up > > in the the TD ?? [quoted text clipped - 19 lines] > -- > Steve Swifthttp://www.swiftys.org.uk/swifty.htmlhttp://www.ringers.org.uk Hmm. Yes that could be a solution, I could determine programmatically where is the initial potential split is and insert that symbol. Do we have something which works with both FF and MSIE at least ? -P > Do we have something which works with both FF and MSIE at least ? Yes, ­ - providing you require your users to use FireFox 3 :-) See bug 333659. I had to wait for this answer from my companies internal newsgroups. SignatureSteve Swift http://www.swiftys.org.uk/swifty.html http://www.ringers.org.uk Mon, 20 Aug 2007 14:18:30 +0100 from Steve Swift <Steve.J.Swift@gmail.com>: > Nothing to do with stylesheets, but you can insert ­ at the point > where you'd like the word to split. > > If the cell is wide enough, it won't split, but if things get too > narrow, it will split the word, inserting a "-" where it split. How nearly universal is browser support? SignatureStan Brown, Oak Road Systems, Tompkins County, New York, USA http://OakRoadSystems.com/ HTML 4.01 spec: http://www.w3.org/TR/html401/ validator: http://validator.w3.org/ CSS 2.1 spec: http://www.w3.org/TR/CSS21/ validator: http://jigsaw.w3.org/css-validator/ Why We Won't Help You: http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you >> Nothing to do with stylesheets, but you can insert ­ at the point >> where you'd like the word to split. [quoted text clipped - 3 lines] > > How nearly universal is browser support? Nowhere near. I'm obliged to support IE6 and FireFox, the only browsers my employer supports. So ­ is out, as FireFox ignores it. Apparently FireFox 3 will fix this. Anyone working in a closed environment which tolerated only Internet Explorer and/or Opera would be OK. Corporate environments are often stultifying, but they sometimes can save you a lot of effort. I code to my employers standards during my employers time, then to my own standards in my own time. SignatureSteve Swift http://www.swiftys.org.uk/swifty.html http://www.ringers.org.uk Scripsit Steve Swift: >>> Nothing to do with stylesheets, but you can insert ­ at the >>> point where you'd like the word to split. [quoted text clipped - 3 lines] >> >> How nearly universal is browser support? I'd like to repeat that the original question was - despite the Subject line formulation - about splitting a string, not hyphenation. Whether the question was the one that really corresponds to OP's situation cannot be decided, but probably it wasn't. Hyphenation is interesting in other contexts and for other purposes, of course, including situations where a long word should be hyphenated inside a table cell. > Nowhere near. I'm obliged to support IE6 and FireFox, the only > browsers my employer supports. So ­ is out, as FireFox ignores > it. Apparently FireFox 3 will fix this. On the other hand, Firefox 2 _ignores_ it, unlike some previous browsers that display it as a visible hyphen in all situations, which is much worse if you meant it to be an invisible hyphenation hint. > Anyone working in a closed environment which tolerated only Internet > Explorer and/or Opera would be OK. Well, probably, if he uses the soft hyphen in English text only, or in other languages that have similar rules for what happens when a word is divided at an allowed hyphenation point. The soft hyphen looks problematic in many ways, but it's actually much more problematic than it looks like. I just added some notes on mismatch between specifications into my page "Soft hyphen - a hard problem?", at http://www.cs.tut.fi/~jkorpela/shy.html#sem By the Unicode standard, the soft hyphen is "an invisible format character that merely indicates a preferred intraword line break position" and that needs to be handled in a language-specific manner. From this perspective, it violates the character semantics to just break a word at a soft hyphen adding a hyphen at the end of a line. Such behavior is permissible only if the language and the word are known to require such processing, instead of e.g. breaking without a visible hyphen or modifying the spelling of the word when it is divided. The HTML 4.01 specification, on the other hand, requires (with "must") such behavior, if a browser supports the soft hyphen. Thus, HTML assigns to the soft hyphen a semantic definition that differs from the Unicode definition. However, the HTML spec does not require support to soft hyphen in that sense. It allows it to be ignored. I conclude that actually Firefox 2 is the conforming browser, in the sense that it conforms to the HTML spec in this issue as well as to the Unicode semantics of the soft hyphen (where it's just an indicator for an _allowed_ word division position). ObCSS: Although the ­ entity or the soft hyphen character are not CSS issues, it might be a job for CSS to specify how soft hyphens are treated, somewhat analogously with the white-space property that affects handling of some whitespace characters. But there's hardly even any work in progress in that direction. SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > The soft hyphen looks problematic in many ways, but it's actually much more > problematic than it looks like. I just added some notes on mismatch between > specifications into my page "Soft hyphen - a hard problem?", at > http://www.cs.tut.fi/~jkorpela/shy.html#sem Now, this longish article, which I read in its entirety, focusses on giving a meaning to the indeed rather obscure sentence A graphic character that is imaged by a graphic symbol identical with, or similar to, that representing HYPHEN, for use when a line break has been established within a word. which is found in the ISO 8859-1 standard. I take it as an exercise in logic to attribute any meaning to this sentence in the case when no line break has been established within a word. In my understanding, it has none. And so it has none under any circumstances because the decision which characters to write in the source text is with the author but the decision where to "establish" line breaks that were not in the source text is with the rendering engine. Now, the rendering engine cannot have an effect on the occurrence of a SHY character in the source text. Insofar, given the illogical nature of this sentence, I would not go so far as to say that "SHY shall definitely be presented as a hyphen, either identical with or similar to hyphen, in all positions". After all, it makes a statement only "when" the character appears in a certain position. Your interpretation is possible but not cogent. In other words, the Unicode standard yields a differing, but also possible, interpretation of the obscure ISO 8859-1 standard. In Unicode lingo, a "graphical symbol" would have been called "glyph", and the specification of which glyph to use for hyphenation, or none in some script, is again a question of rendering. But for Unicode, the use of the SHY character is adequately defined. And it seems the only useful interpretation, even though there are applications that have interpreted it otherwise. The statement "The Unicode character 00AD is defined to be invisible, except at the end of a line, where it may or may not be visible, depending on the script" appears clear to me, with the necessary addition that the visibility depends not only on the script but can also, within the same script, depend on the characters in the neighbourhood: Visible in: relation­ship relation- ship Invisible in: counter-­example counter- example What about: http://www.cs.tut.fi/­~jkorpela/­shy.html#sem http://www.cs.tut.fi/ ~jkorpela/shy.html#sem Whether the function of a discretionary hyphen should better have been the task of a tag instead of a character is a matter of taste. Bidi issues are tackled by both tags and characters, and I see some similarity with these. SignatureHelmut Richter Scripsit Helmut Richter: >> The soft hyphen looks problematic in many ways, but it's actually >> much more problematic than it looks like. I just added some notes on [quoted text clipped - 9 lines] > > which is found in the ISO 8859-1 standard. Well, that was part of the hystorical*) starting point, which is largely water under the bridge now. Newer considerations relate to the semantic complexity and vagueness of the Unicode definition of soft hyphen, its relation to HTML specs, and processing of soft hyphen in existing software (browsers, indexing robots, Word, etc.). There's nothing really directly CSS-related here, since CSS has no tools for affecting word hyphenation at present, though there is work in progress in the CSS 3 drafts that could, or rather should, take such things into consideration. *) "Hystorical" is a contamination of "hysterical" and "historical". > I take it as an exercise in logic to attribute any meaning to this > sentence in the case when no line break has been established within a > word. The natural interpretation is that the soft hyphen has been meant "for use when a line break has been established within a word", i.e. when a possible hyphenation opportunity has been found _and_ applied, _before_ the text was created (by a human being or by a program). Other occurrences of the soft hyphen would then simply be data errors. But as I said, this is just hystorical, though it may help us to see some of the reasons why the soft hyphen became a hard problem. > In > other words, the Unicode standard yields a differing, but also > possible, interpretation of the obscure ISO 8859-1 standard. No, it gives a different definition for the soft hyphen character. It does not yield an interpretetation of ISO 8859-1. However, you're right in the sense that Unicode identifies its soft hyphen with that of ISO 8859-1. That was a mistake, but it's too late to try to fix that. > The statement "The Unicode character 00AD is defined to be invisible, > except at the end of a line, where it may or may not be visible, > depending on the script" appears clear to me, Yes, but it's no longer true. The Unicode standard has changed quite a lot in this respect. > counter-­example That would be madness in practical authoring, since it may result in counter-- example Try it on IE! For further madness, IE _may_ (depending on available width etc.) _also_ render it as > counter- > example which might be regarded as appropriate by the Unicode semantics (since it's so vague that it allows many interpretations) but which definitely violates HTML specifications. > What about: > > http://www.cs.tut.fi/­~jkorpela/­shy.html#sem Simply wrong. It's not a _word_. Under the Unicode definition, you are using a word divisibility indicator inside a string that surely ain't no word. Under the HTML definition, you are not asking for... > http://www.cs.tut.fi/ > ~jkorpela/shy.html#sem but for http://www.cs.tut.fi/- ~jkorpela/shy.html#sem which is simply wrong, bad, naughty, anathema, foolish. And that's what you get on IE at least. Your _question_ was a very good one, of course. It's just the expression that it asks about that is wrong. > Whether the function of a discretionary hyphen should better have > been the task of a tag instead of a character is a matter of taste. In ISO 8859 and in Unicode, there was no choice: they are character standards, intended for plain text. In the design of HTML, <shy> would have been a better _practical_ choice, since it would automatically be ignored by browsers that don't recognize it, just as <wbr> is.*) It could _still_ be added to HTML, though it won't. It even looks better. It even allows the use of attributes that might affect the rendering, e.g. by specifying that a hyphen be displayed, or not be displayed, or that the spelling of the word be changed if a division takes place. *) Naturally, <wbr> (word break) would have been a suitable tag for indicating a word break opportunity in the sense currently assigned to the soft hyphen in the Unicode standard. But it was already taken into use as a nonstandard but widely supported tag for an allowed _string_ break to be handled without ever inserting any hyphen, corresponding to the semantics of the zero-width space U+200B (which can be used in HTML authoring but has unspecified effect by HTML specs and is poorly supported). > Bidi issues are tackled by both tags and characters, and I see some > similarity with these. ObCSS: For further confusion, bidi issues can also be tackled by CSS. :-( SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ >> The soft hyphen looks problematic in many ways, but it's actually much more >> problematic than it looks like. I just added some notes on mismatch between [quoted text clipped - 9 lines] > > which is found in the ISO 8859-1 standard. Is that obscure? Consider a program like fmt. fmt's input and output are both plain text. The difference is that the output may have some of the '\n' characters moved around and some of the spaces removed. Conceivably, a different version of fmt could additionally modify the text by inserting or removing soft hyphen characters. So if the input was "algorithm", and fmt was invoked with -w 5 ("format to a width of 5 columns"), it might output "al-\ngo-\nrithm" where "-" is the soft-hyphen character. We could then run fmt again on that output, to reformat it back to 80 columns, e.g., something like: echo "al-\ngo-\nrithm" | fmt -w 80 This time fmt would remove both the soft hyphens and the \n characters, and output "algorithm". But fmt would never touch "hard" hyphens. So formatting the string "walking-\nstick" (this time the "-" is a normal hard hyphen) would result in "walking-stick", never in "walkingstick". This was my understanding of what Jukka was saying the article anyway. > I take it as an exercise in logic to attribute any meaning to this sentence > in the case when no line break has been established within a word. Simple: if you haven't established a line break in a word, then you don't put a soft hyphen in it. > In my understanding, it has none. And so it has none under any > circumstances because the decision which characters to write in the > source text is with the author but the decision where to "establish" > line breaks that were not in the source text is with the rendering > engine. That's exactly the point. The confusion is the extent to which plain text is formatted. Look at newlines in emails. Sometimes authors insert them by pressing RETURN when they want a line break; other times the editor puts them in to keep the width to about 72 columns. It's all a bit annoying. The soft hyphen (ISO-8859-1 interpretation) is just like the collapsed newline. Conceivably an author of a fussy disposition might put them in to make his _source_ more readable in his text editor, expecting the CSS renderer to collapse them away just it like does his newlines. Perhaps for the values of the white-space property that don't collapse '\n' (pre, pre-line and pre-wrap I think) the renderer might render soft hyphen like a hyphen rather than as nothing, and maybe tut-tut at the author in a hidden warning window somewhere if it ever found soft hyphen not followed by newline. But if soft hyphen means a hyphenation hint instead, which in HTML it apparently does, then that's a completely different matter, and has a different use in HTML (or in CSS). All this is explained much better in Jukka's article. [...] > Whether the function of a discretionary hyphen should better have been the > task of a tag instead of a character is a matter of taste. Bidi issues are > tackled by both tags and characters, and I see some similarity with these. I think the point is that Unicode is what primarily defines the bidi algorithm, and therefore provides characters like RLO and RLE for inputs to that algorithm. CSS provides a representation in terms of properties (unicode-bidi and direction) that can be applied to HTML elements just for the hell of it really. There is an obvious practical benefit: suppose you write an Arabic page and use Windows-1256: you can't represent RLE in Windows-1256, but you can write <span style="unicode-bidi: embed"> in it. > There is an obvious practical benefit: suppose you write an Arabic page > and use Windows-1256: you can't represent RLE in Windows-1256, ‫ Wed, 22 Aug 2007 09:38:52 +0100 from Steve Swift <Steve.J.Swift@gmail.com>: > >> Nothing to do with stylesheets, but you can insert ­ at the point > >> where you'd like the word to split. [quoted text clipped - 6 lines] > Nowhere near. I'm obliged to support IE6 and FireFox, the only browsers > my employer supports. So ­ is out, as FireFox ignores it. Thanks; that's what I was wondering. Presumably that means no Mozilla support either. > Apparently FireFox 3 will fix this. "A bird in the hand..." SignatureStan Brown, Oak Road Systems, Tompkins County, New York, USA http://OakRoadSystems.com/ HTML 4.01 spec: http://www.w3.org/TR/html401/ validator: http://validator.w3.org/ CSS 2.1 spec: http://www.w3.org/TR/CSS21/ validator: http://jigsaw.w3.org/css-validator/ Why We Won't Help You: http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you Thank you guys for the very interesting discussion I am following. I have just uploaded a demo of the new HTML *export* routine I am rewriting. If you go to the page: http://151.100.3.84/DataTimeReportPortal/Example3.aspx and click on the REGENERATE button, you will run my current routine to export the report Layout created on a designer. The HTML will be created on the fly (it's a big file, for test). You may experience some slowness because I am doing experiments on this machine. Take this a starting point for the discussion and advice. So far I have been taking your advice about the doctype and html. My difficulty arises in the cases the user formats its grids in such a way to wrap some string. He can do that in the designer because the reports are meant for printing or PDF also, and especially. In such cases, since the TD wont' break I am having hard time to keep the objects in the relative position the user has designed. Ya, I could imposeto the user to format grids before outputting to the web. But the challenge is to deal with complexity, not to impose restrictions :-) Feel free to make all the workable suggestion, I will include them in the code immediately (if I can). So far I am restricting to FF and IE, but it wont be bad to have to thing working in general. -P PS. This is a FREE open solution (src code included). Hey do not make crash the machine I am working on it right now :-)) > The HTML will be created on the fly > (it's a big file, for test). Make it much, much smaller -- take out the inlined CSS and use a stylesheet. Hint: If you've repeated CSS rules all over the place, then your structure of CSS blocks is poor and isn't giving you the benefits you ought to get. Lose the media="screen" on the stylesheet you do have. Just use the default of not specifying it, maybe use screen=print or @media print if you have a print-specific stylesheet. Set a background color on <body>. Lots of developers have their browser default set to "ugly pink" to indicate this when they view a site. Your pages aren't improved by this. As to the tables, then GET RID OF THOSE PIXEL SIZES. Absolute classic worst case for them, tabular text data. Use ems insted. Lose the table row heights. You certainly don't need to set these on every cell or row - just let the browser deal with it. You don't even care if they vary between rows or tables (much). An appropriate per- row choice looks better than a meaningless consistency. Keep the table cell widths (but use ems!). Keeping the columns widths consistent between tables is (unlike row heights) important to attractive design. > > The HTML will be created on the fly > > (it's a big file, for test). > > Make it much, much smaller -- take out the inlined CSS and use a > stylesheet. Thanks you Andy for visiting :-)) Sorry about the big page. I t's mainly for test. Actually I had been thinking about the possibility to create an external stylesheet. I was unsure wheter was more practical and compact to have the syles inside . But if - none has objections - (we are in a democratic country) I will spit the CSS class to an external file, following your suggestion ... > Hint: If you've repeated CSS rules all over the place, then your > structure of CSS blocks is poor and isn't giving you the benefits you > ought to get. Ya, also the validator said so. Could you please make an actual example of restructuration possibily using my style, so that I will program it in the export routine ? > Lose the media="screen" on the stylesheet you do have. Just use the > default of not specifying it, maybe use screen=print or @media print > if you have a print-specific stylesheet. Ah. Ok I was unsure about the meaning of this. I will then remove it. > Set a background color on <body>. Lots of developers have their > browser default set to "ugly pink" to indicate this when they view a > site. Your pages aren't improved by this. Very good trick! I will. > As to the tables, then GET RID OF THOSE PIXEL SIZES. Absolute classic > worst case for them, tabular text data. Use ems insted. Yes I have to work on this. I will try a few formulas to see the best fit to the original px design. > Lose the table row heights. You certainly don't need to set these on > every cell or row - just let the browser deal with it. You don't even > care if they vary between rows or tables (much). An appropriate per- > row choice looks better than a meaningless consistency. I have to make experiments on this. > Keep the table cell widths (but use ems!). Keeping the columns widths > consistent between tables is (unlike row heights) important to > attractive design. Ok I will try the conversion to em. I hope it's not a pain! Thanks a lot for now. I will go back to coding, but I will continue reading all your advice. -T > Actually I had been thinking about the possibility to create an > external stylesheet. There are two issues here: stylesheet vs. inlined styles (style attributes) also internal stylesheet vs. external stylesheet. Your immediate problem is the inlined style attributes. These repeat a whole load of CSS properties (many of them trivial) onto every element. This is sheer pointless bloat. Internal vs. external stylesheets are unimportant as yet. Internal is often more convenient to work on, especially during development on a static page. External shows benefits when you're sharing it between several pages in production, or sometimes from dynamic page generation, if you can't easily embed an internal stylesheet in the dynamic source. > > Actually I had been thinking about the possibility to create an > > external stylesheet. [quoted text clipped - 13 lines] > generation, if you can't easily embed an internal stylesheet in the > dynamic source. Hi Andy What I do here is a scansion of the report cell to determine the group of cells which have similar meaning (measures and dimensions) and create distinct styles by comparing the style strings. The inline CSS is only for width and height. And that cannot probably be completely eliminated because necessary to ensure precise output. If you see how to eliminate it, please advice. But must be some way programmable. The class instead contain cell properties. There is a duplication because I replicate for each style the Textual properties (fonts, etc.) but could not manage to do differently to render the cells precisely. What bothers are the images within the cells. The procedure is made to work in any case with or without the possible other <table> nested in the <td>'s. I struggled a lot with this and can be probably optimized. But I need to do a little change at a time, otherwise I can mess up everything easily. If you are willing you could select a small portion of a grid (with and without cell images) and show your suggested changes and improvements. Thanks a LOT -P Scripsit pamela fluente: > If you go to the page: > > http://151.100.3.84/DataTimeReportPortal/Example3.aspx > > and click on the REGENERATE button, I get a colorful report, too colorful. But where is the problem you originally asked about? > My difficulty arises in the cases the user formats its grids in such a > way to > wrap some string. What? Where? > In such cases, since the TD wont' break I am having hard time to keep > the objects > in the relative position the user has designed. Huh? Table cell contents wrap as needed unless you prevent that, though they normally wrap at whitespace only. But where's the problem? SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > Scripsit pamela fluente: > [quoted text clipped - 22 lines] > -- > Jukka K. Korpela ("Yucca")http://www.cs.tut.fi/~jkorpela/ You cannot see the problem because TD does not wrap the *whole words*. If the user designed a report where a word or some long code is wrapped it get unwrapped in the web rendering. That's why I was asking your opinion: to maintain the original user design. Anyway for a little while I will be preoccupied doing the code changes you guys have been suggesting. I will be back in a while. Thanks a lot for so much help. You all are really supporting and helpful. I will struggle also with the em question, and then we will see what is the best conversion. A presto, -P > So ­ is out, as FireFox ignores it. "Ignore" here means that e.g. "style­sheet" is simply shown as "stylesheet" without a possible break. But that's not too bad! Bad would be to show *always* "style-sheet". > "Ignore" here means that e.g. "style­sheet" is simply shown > as "stylesheet" without a possible break. But that's not too bad! > > Bad would be to show *always* "style-sheet". I meant "ignore" in the sense that I could see no difference at all between style­sheet and stylesheet. It is as if the "­" wasn't there. Firefox renders symbols that it doesn't recognise verbatim, so "style&shi;sheet" comes out unaltered. So it clearly recognises "­" as something valid, it just doesn't do anything with it, except pretend that it wasn't there. SignatureSteve Swift http://www.swiftys.org.uk/swifty.html http://www.ringers.org.uk > I meant "ignore" in the sense that I could see no difference at all between > style­sheet and stylesheet. It is as if the "­" wasn't there. > Firefox renders symbols that it doesn't recognise verbatim, so > "style&shi;sheet" comes out unaltered. So it clearly recognises "­" as > something valid, it just doesn't do anything with it, except pretend that it > wasn't there. Yes - and that is *not bad*. It does no harm. |
Enable EMail Alerts
Start New Thread
Reply to this Message