CSS and plain text
in [CSS]
|
Prev: textarea wrap
Next: Image and Text Side By Side
From: Jón Fairbairn on 10 Sep 2006 06:22 Gus Richter <gusrichter(a)netscape.net> writes: > Jón Fairbairn wrote: > > "Michael Bulatovich" <Please(a)dont.try> writes: > > > >> Thanks Mr. Shagnasty, Jukka, and others. I think you've covered it. > >> > >> The text to which I referred could be within <body> tags, > >> but not otherwise contained by what I would recognize as > >> typical selectors for text (h#, p, blockquote, etc.) If I > >> understand correctly, it sounds like this sort of thing > >> could be influenced by using the body as selector. > > But what /is/ it? I'm finding it hard to come to terms with > > the idea of text that belongs to no semantic category. > > Anonymous Text / Anonymous Box > > <http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level> Well, that's what it ends up being called for the purposes of CSS, but what kind of thing /is/ the text? PETER: I know this English guy who was driving around in the South. And he stopped for breakfast one morning somewhere in southeast Georgia. He saw “grits” on the menu. He'd never heard of grits so he asked the waitress, “What are grits, anyway?” She said, “Grits are fifty.” He said, “Yes, but what _are_ they?” She said, “They're extra.” He said, “Yes, I'll have the grits, please.” -- from “United States”, Laurie Anderson -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2006-09-07)
From: Gus Richter on 10 Sep 2006 16:39 Jón Fairbairn wrote: > Gus Richter <gusrichter(a)netscape.net> writes: > >> Jón Fairbairn wrote: >>> "Michael Bulatovich" <Please(a)dont.try> writes: >>> >>>> Thanks Mr. Shagnasty, Jukka, and others. I think you've covered it. >>>> >>>> The text to which I referred could be within <body> tags, >>>> but not otherwise contained by what I would recognize as >>>> typical selectors for text (h#, p, blockquote, etc.) If I >>>> understand correctly, it sounds like this sort of thing >>>> could be influenced by using the body as selector. >>> But what /is/ it? I'm finding it hard to come to terms with >>> the idea of text that belongs to no semantic category. >> Anonymous Text / Anonymous Box >> >> <http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level> > > Well, that's what it ends up being called for the purposes > of CSS, but what kind of thing /is/ the text? This being a CSS NG, the answer was right on, IMHO. In HTML, it is #PCDATA - "Parsed Character Data" (text and markup). -- Gus
From: Spartanicus on 11 Sep 2006 06:18 "Jukka K. Korpela" <jkorpela(a)cs.tut.fi> wrote: >> I see nothing there that resembles what you wrote. I thought we were >> discussing rendering sans CSS, > >No, you asked about content and structure. You claimed in response to: >> For a copyright notice, rendering with a top margin is appropriate for >> non CSS rendering situations. that >such rendering would look rather foolish. with a description of the following content and structure that would demonstrate why: >a collection of miscellaneous notes at the bottom of a >page - the typical context of a copyright notice To which the Canon resource you provided has no relevance. Please provide an example of the content type and structure you alluded to. >The essential point is that a >copyright notice typically appears alone at the end of a page, often >preceded by a horizontal rule that acts as a divider. If you don't want to >count on CSS in producing the rule, you can use <hr>. In the following demo: http://homepage.ntlworld.ie/spartanicus/copyright_structure2.htm it needs to be made clear that the copyright message applies to the whole of the page, it can be argued that since it is listed under the "Notes" level 2 header, structurally the copyright message falls under that header and may structurally not be seen as applying to the entire page. It is obvious that the copyright message applies to the whole of the page in a on screen rendering with CSS enabled, not so in other rendering scenarios. This is a problem that HTML4 doesn't allow us to solve properly, that being so, using a <hr> element improves on the likely on screen sans CSS interpretation. But it only addresses a symptom in that one domain & circumstance. The only thing that can reasonably be attributed to a <hr> element is a certain visual representation, there is no justification from a semantic, structural or spec point of view for attributing <hr> with having semantic or structural significance, as a result there is no justification for expecting a non visual renderer to do anything with it. Note also that there is no justification for using a <hr> element for the original example that I provided: http://homepage.ntlworld.ie/spartanicus/copyright_structure.htm in which there is no ambiguity as to what the copyright message applies to, hence using a <hr> there would at best be superfluous, at worst it would create the illusion that the functional problem has been solved by doing so. >> It is always a bad idea to rely on the (in this case only possible) >> properties of an adjacent element to create functionality that should >> be provided by the content's own markup. > >Functionality? You mean rendering, right? I meant functionality, which is provided in different forms in different renderings. >And adjacent vertical margins are >not a casual phenomenon in CSS: they are _supposed to_ be considered >together. Again the bottom margin of the preceding element may be null. You seem to think that you can rely on the preceding element having a bottom margin equating to the applicable line height. There is no justification for this, the sample stylesheet provided with CSS 2.0 may suggest that for example a paragraph has a top and bottom margin, but there is nothing wrong with a default rendering where semantic block level elements have a non null top margin and a null bottom margin. This works fine as long as it is used for all such elements, as demonstrated by at least one browser. The same applies to the audio domain, only there instead of visual spacing it is expressed as a pause. >> I advocate always using semantic markup elements to mark up text > >Apparently that means "semantics" that consists of what you think about >rendering: > >> and my choice of what element to use is governed by real world >> functionality rather than using elements that provide no >> functionality such as div and span. >> >>> Actually you have now >>> admitted that you advocate the use of semantic markup (i.e., markup >>> that has defined semantics) _against_ its defined semantics. >> >> Indeed. > >OK, I guess we can stop here. You simply use the word "semantic" in a >private meaning that differs from its meaning in normal English - in a >rather striking way. Your "semantic" markup looks suspiciously like >procedural markup. Throughout this thread I have advocated the use of a semantic element to mark up text instead of a non semantic element. I find it bizarre how from that you are trying to make it appear that I am straying from defined appropriate markup practice. >> I'm not familiar with the phrase "procedural markup". > >Try reading the SGML Handbook. :-) I conclude that the objective of someone who uses language who's semantics can only be derived from a non publicly available source is to obscure, rather than to communicate. I also find it rather telling that you have snipped and not responded to several of the arguments I put forward. -- Spartanicus
From: Jukka K. Korpela on 11 Sep 2006 07:19 Spartanicus <invalid(a)invalid.invalid> scripsit: > You claimed in response to: > >>> For a copyright notice, rendering with a top margin is appropriate >>> for non CSS rendering situations. > > that > >> such rendering would look rather foolish. Something like that, yes, though I'm not that interested in opening all the preceding subtopics, after you have made it clear that you say that 1) people should use semantic markup for everything and 2) you regard markup as semantic if it "functionally" (= presentationally, in any reasonable interpretation I can imagine) does what you want. That's a possible approach, and I find it futile to argument against it, since you seem to have completely lost the semantics of "semantics". How could I express myself to you using words only if words have quite private meanings to you? > Throughout this thread I have advocated the use of a semantic element > to mark up text instead of a non semantic element. You have, and I have explained why semantically wrong semantic markup is much worse than non-semantic markup. Using <h6>foo bar</h6> to make foo bar appear in smaller font is much worse than <font size="2">foo bar</font>, even though the <h6> markup might "functionally" "work" for the purpose. > I find it bizarre > how from that you are trying to make it appear that I am straying from > defined appropriate markup practice. You are, because appropriate markup uses semantic elements in their _defined_ meanings. A <p> element indicates a paragraph of text, not some arbitrary block. >>> I'm not familiar with the phrase "procedural markup". >> >> Try reading the SGML Handbook. :-) > > I conclude that the objective of someone who uses language who's > semantics can only be derived from a non publicly available source is > to obscure, rather than to communicate. The SGML Handbook has been publicly available for years. Maybe you meant that it is not available to you free of charge or free of effort? I can assure that any effort in getting access to the book e.g. through a suitable library will be outweighed by the effort needed to understand its content. But anyone who seriously advocates "semantic markup" in public should really understand the difference between "procedural markup" and "descriptive markup" as described in the SGML Handbook, in one of its most readable parts. ObCSS: Both procedural markup and descriptive markup _may_ have an impact on rendering in CSS terms. For procedural markup, that would be an _essential_ impact, since procedural markup more or less _means_ controlling the rendering. For descriptive markup, the connection, if any, is coincidental. An element like <div> is descriptive markup at a rather abstract level, saying nothing except "this is a block". And that's exactly what is needed - if I may refer to our Subject - if you wish to apply CSS to a fragment of plain text that constitutes a block but without any semantic role that would be _adequately_ described using semantic elements of HTML (i.e., paragraph, heading, block quotation, or authorship information). > I also find it rather telling that you have snipped and not responded > to several of the arguments I put forward. Yes, it tells about good Usenet conduct - to quote only the parts you wish to comment on. So does the fact that in this discussion, which seems to get somewhat personal at least on your side, I am using my real name and address. -- Jukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/
From: Andy Dingley on 11 Sep 2006 09:49
Spartanicus wrote: > >Try reading the SGML Handbook. :-) > > I conclude that the objective of someone who uses language who's > semantics can only be derived from a non publicly available source is to > obscure, rather than to communicate. It's The SGML Way "If it's worth knowing, it's worth paying big money to a Consultant in a suit for it." |