Selector for content?
in [CSS]
|
Prev: Can I refer width value not to the parent container cascade but to the current top browser window?
Next: b or strong?
From: Thomas 'PointedEars' Lahn on 9 Feb 2010 17:29 Jukka K. Korpela wrote: > Thomas 'PointedEars' Lahn wrote: >> Jukka K. Korpela wrote: >>> Note that <pre> and <code> elements are by default rendered using a >>> monospace font. There's usually no particular reason to use monospace >>> fonts for computer code, >> >> Yes, there is: all characters use the same width, > > That's what monospace means. With the advantages of that, which you don't seem to understand. >> therefore it can be seen at a glance when code reaches a certain column > > Why would that matter? Usability and interoperability. Code that exceeds 80 columns would usually need to be word-wrapped in order to be easily readable and maintainable everywhere. > Even if you're displaying FORTRAN IV, why would > that matter (when presenting a source program)? I do not know FORTRAN IV enough to answer that question. I guess it is pointless anyway. >> (as it is often going to be displayed on text terminals, too), > > And why would _that_ matter, even if it were true? It is true, so it matters. >> and source code is indented using the same width as other characters. > > Source code is indented using spaces, Not necessarily. > so why would it matter what the widths of other characters are? The width of a space should be equal to the width of non-whitespace characters to see the white-space character and the number of white-space characters easily. > (You can indent using tabs, but that's not safe, Depends. > and doesn't change this point.) True, the display width of the tab character should be measured according to the width of other characters if easily readable display of source code is to be achieved. That cannot be achieved with a proportional font because of the lack of uniform character width. >> By contrast, the width of the characters of proportial fonts vary, > > Really? :-) _Proportional_, yes. >> and their space and tab characters are considerably thinner, therefore >> [...] harder to recognize and easier to overlook. > > The width of space varies by font, Yes. However, with a fixed-width font the space is as wide as the other characters of the same font, therefore easily spotted. And two consecutive spaces will be easily distinguishable from one, four from two, and so on. > and the typically larger width in monospace fonts implies more coarseness > rather than anything else. The coarseness you are complaining about is in fact *wanted* granularity here. The characters in different lines should align if they are in the same column. Especially for source code of programming languages like Python where indentation denotes a block of statements, it is vital that this alignment can be easily spotted. > Tab characters have no width; they are control characters. As you well know, tab characters are often displayed as if they were consecutive non-breaking spaces (usually 4 or 8). >>> unless you regard tradition as a reason. >> This particular tradition has a very practical reason, though. > > You failed to give any reason, practical or theoretical. No, you only failed to recognize it. >> You haven't written much computer code lately, have you? > > If you need to know, I write computer code on a daily basis, and program > code fairly often too. I might just as well ask you how many compilers > you have written or how many books on programming you have written, but I > resist the temptation. It's really irrelevant, since we are not > discussing program _writing_ but about _displaying_ computer code on a > web page. Assuming that computer code is displayed to be to be understood without having to copy-paste it, and to be re-used afterwards, it does not make sense to display it differently than it was/is usually written. Incidentally, nobody does that, even browser vendors disagree with you in each place where source code is concerned, not only with CODE elements in HTML (consider View Source: it's Notepad with its default fixed-width font by default for IE, not WordPad with its default proportional font; fixed- width font for Geckos, Opera and WebKit-based browsers). They do so because users expect this for the reasons mentioned, not out of a weird notion of tradition as you suggested. PointedEars
From: Jukka K. Korpela on 10 Feb 2010 12:35 Thomas 'PointedEars' Lahn wrote: > The width of a space should be equal to the width of non-whitespace > characters to see the white-space character and the number of > white-space characters easily. You seem to have a fixed idea and can't get rid of it. You can see that 6 spaces are twice as wide as 3 spaces, quite independently of the relationship between the width of space and width of other characters. -- Yucca, http://www.cs.tut.fi/~jkorpela/
From: Jukka K. Korpela on 10 Feb 2010 13:10 Darin McGrew wrote: > Jukka K. Korpela <jkorpela(a)cs.tut.fi> wrote: >> Source code is indented using spaces, so why would it matter what >> the widths of other characters are? (You can indent using tabs, but >> that's not safe, and doesn't change this point.) > > The example that comes to mind is when a series of arguments won't > fit on a single line, and you want to align the first argument on the > second line with the first argument on the first line. In that particular presentation style, monospace font has a point. But that's a special case, and the usefulness of such presentation is questionable. Monospace font reduces legibility considerably. Monospace fonts, in addition to being ugly, tend to be less legible than about any other font, not counting fantasy fonts. So when presenting program code on a web page, should we really sacrifice legibility just to have argument lists aligned in a particular way. > my_function(arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, > arg10, arg11, arg12) When I have tried to use such style, I have usually made lines too long. Those nasty long argument lists have a nasty habit of appearing inside nested loops and other control structures. And the style doesn't really improve legibility. Just indenting the other lines a few spaces is sufficient and better matches the decisions one often needs to do with long statements that have no such potential "alignment point" of the start of the argument list. Personally, I have used pre, code, samp, kbd, tt { font-family : "Courier New", monospace; } on my pages, just because I, too, have been thinking the traditional way, rather pointlessly. This is a nice thing on Usenet: you often see your own thoughts, or rather habits, presented and defended with so ridiculous arguments (I don't mean your argument, it's the only sensible one presented here in favor of monospace) that you start wondering what's wrong with it. And I probably won't change much the pre and tt part, since it's part of their semantics that they are monospace, so if I have used them I probably counted on that. I might prepend Consolas to the list, since it makes a clear distinction between l and 1, unlike many other fonts (including most other monospace fonts). For code, samp, and kbd, I'll make a comparison of commonly available fonts as regards to the string 0Ol1-.,:; since it is crucial to distinguish between these characters especially in code context where we tend to have identifiers rather than words. I'm especially thinking of l vs 1 and partly "." vs. ",", since that difference may really matter in code. And on these grounds I might select Cambria, Garamond, Palatino Linotype, serif. (I won't shock you by mentioning that I even considered Georgia, with her nice lowercase digits. :-)) -- Yucca, http://www.cs.tut.fi/~jkorpela/
From: Dr J R Stockton on 10 Feb 2010 14:38 In comp.infosystems.www.authoring.stylesheets message <i1fcn.720$pL1.593 @uutiset.elisa.fi>, Tue, 9 Feb 2010 17:17:50, Jukka K. Korpela <jkorpela(a)cs.tut.fi> posted: > >> therefore it can be >> seen at a glance when code reaches a certain column > >Why would that matter? Even if you're displaying FORTRAN IV, why would >that matter (when presenting a source program)? > You evidently write from inexperience. Fortran IV is column-sensitive. I have before me an unused 80-column card, with "FORTRAN STATEMENT" printed on it. Executable code starts in column 7, with labels in 1-5 and continuation characters in 6. Code finishes after column 72, with 73-80 for program ID and/or sequencing. I recall a colleague, writing Fortran IV on the CRT console of an HP minicomputer, who was considerably perplexed with a program that appeared to be ignoring one element of a continued COMMON statement. I eventually observed that the element was dangling to the right, neatly within column 73-80, and therefore ignored. Granted, one should normally display on the Web only correct, tested Fortran IV, and human readers would assume that labels and continuation characters were correctly placed, and lines not too long. However, Web code can be copy'n'pasted for execution, and a compiler is mess naive. Additionally, monospace fonts generally distinguish similar characters better than some proportional fonts. In natural languages, context is a great help; in text, it is rare to find a decimal digit and a letter adjacent, but comparatively common in code. Code is very rarely presented other than in monospace, except in inferior Web-based substitutes for Usenet. -- (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk IE7 FF3 Op9 Sf3 news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>. <URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources. <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
From: Jukka K. Korpela on 11 Feb 2010 13:26
Dr J R Stockton wrote: >>> therefore it can be >>> seen at a glance when code reaches a certain column >> >> Why would that matter? Even if you're displaying FORTRAN IV, why >> would that matter (when presenting a source program)?> > You evidently write from inexperience. You jump into odd conclusions, and you don't answer the question that I asked and that you quoted above. > Fortran IV is column-sensitive. Everyone who has any idea of FORTRAN IV (that's the spelling we used when we used the language) knows that, and it was the very reason why I mentioned the old language, as you should have been able to figure out. Please try to make some point instead of giving a lecture. > Granted, one should normally display on the Web only correct, tested > Fortran IV, and human readers would assume that labels and > continuation characters were correctly placed, and lines not too > long. However, Web code can be copy'n'pasted for execution, and a > compiler is mess naive. When are you going to make a point? The question was: why would it matter that it can be seen at a glance when code reaches a certain column? The issue was presentation of program code on a web page, typically to illustrate or comment on a programming language or to show how some particular tasks can be coded in it. It would be foolish to complicate things by using erroneous code that tries to use comment columns for code etc. Similarly, if you need continuation lines, you would use some sensible system like using the same character as continuation character for readability. Of course, FORTRAN IV was an extreme example. For modern languages that people actually display on web pages, there are even less reasons to use monospace font. > Additionally, monospace fonts generally distinguish similar characters > better than some proportional fonts. Did you actually test this? As I wrote previously, they actually don't. If a major concern is to avoid confusing e.g. "l" with "1" or "," with ".", then monospace fonts are generally to be avoided, not favored. > Code is very rarely presented other than in monospace, There is no disagreement on that. My point is that it's a _bad_ habit, and unlike many habits, it hasn't become a good habit by becoming common. -- Yucca, http://www.cs.tut.fi/~jkorpela/ |