Re: [whatwg] [br] element should not be a line break
On Tue, 15 Feb 2011, Christoph Päper wrote: Ian Hickson (2010-12-07): On Thu, 26 Aug 2010, Christoph Päper wrote: However, I believe the underlying problem is simply that “line break” is (too) often used and understood as a synonym for “new line”, at least by non-native speakers. Speaking of breaks on line or paragraph level therefore makes more sense to me. I don't really understand the difference. Here comes a *line break* that always means a visual *new line* like here, whereas a *break on line level* // may look differently – and may actually be rendered with orthographic possibilities (dashes, parentheses etc.) instead of markup, when they’re textual content, not structure. I still don't understand what you mean here. (A minor logical break inside a paragraph is not generally represented by a line break, at least not in any typographic conventions I've seen; usually, in my experience, those are denoted either using ellipses, em-dashes, or parentheses.) That’s true for real paragraphs, but not for most “non-paragraphic” texts, e.g. addresses. The lines in an address are separate oral lines, not minor logical breaks inside a pragraph. Addresses (with multpile lines) are a concept native to written, not to spoken language. Certainly addresses are, for their intended purpose, always written down, but that doesn't mean they're never read out. But I don't see how this affects this discussion. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [br] element should not be a line break
On Thu, 26 Aug 2010, Christoph Päper wrote: Ian Hickson: On Wed, 4 Aug 2010, Thomas Koetter wrote: What strikes me though is that according to the spec The br element represents a line break. A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation. Wouldn't it make more sense to consider the br element to be just a minor logical break inside a paragraph? Calling it a line break doesn't say how it is rendered. It's just a conceptual description. It presupposes the existance of lines, though. Lines are a very visual concept, although they can be applied to oral language, as in poems and songs (where ‘//’ is often an accepted representation for line breaks in transcripts). An oral line may span several literal lines and vice versa. Right. This is about oral lines (for lack of a better term), not the literal lines. However, I believe the underlying problem is simply that “line break” is (too) often used and understood as a synonym for “new line”, at least by non-native speakers. Speaking of breaks on line or paragraph level therefore makes more sense to me. I don't really understand the difference. (A minor logical break inside a paragraph is not generally represented by a line break, at least not in any typographic conventions I've seen; usually, in my experience, those are denoted either using ellipses, em-dashes, or parentheses.) That’s true for real paragraphs, but not for most “non-paragraphic” texts, e.g. addresses. The lines in an address are separate oral lines, not minor logical breaks inside a pragraph. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [br] element should not be a line break
Ian Hickson: On Wed, 4 Aug 2010, Thomas Koetter wrote: What strikes me though is that according to the spec The br element represents a line break. A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation. Wouldn't it make more sense to consider the br element to be just a minor logical break inside a paragraph? Calling it a line break doesn't say how it is rendered. It's just a conceptual description. It presupposes the existance of lines, though. Lines are a very visual concept, although they can be applied to oral language, as in poems and songs (where ‘//’ is often an accepted representation for line breaks in transcripts). An oral line may span several literal lines and vice versa. Paragraphs (and breaks therein), of course, are also a concept of written language, as are sentences. However, I believe the underlying problem is simply that “line break” is (too) often used and understood as a synonym for “new line”, at least by non-native speakers. Speaking of breaks on line or paragraph level therefore makes more sense to me. (A minor logical break inside a paragraph is not generally represented by a line break, at least not in any typographic conventions I've seen; usually, in my experience, those are denoted either using ellipses, em-dashes, or parentheses.) That’s true for real paragraphs, but not for most “non-paragraphic” texts, e.g. addresses.
Re: [whatwg] [br] element should not be a line break
On Wed, 4 Aug 2010, Thomas Koetter wrote: In the past, there has been a lot discussion about not using br just to insert line breaks everywhere. I'm fully aware that we have lots of elements that are often a better fit and that, of course, line breaks can be achieved by blocking inline elements. What strikes me though is that according to the spec The br element represents a line break. A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation. Wouldn't it make more sense to consider the br element to be just a minor logical break inside a paragraph? Just like hr represents a thematic break on the paragraph-level. How the break would be rendered is a different matter and should be left to the designer. Calling it a line break doesn't say how it is rendered. It's just a conceptual description. (A minor logical break inside a paragraph is not generally represented by a line break, at least not in any typographic conventions I've seen; usually, in my experience, those are denoted either using ellipses, em-dashes, or parentheses.) In addition, the appropriate uses (poems, addresses) and examples currently given are not convincing. Consider this: pP. Shermanbr 42 Wallaby Waybr Sydney/p There's no reason why line breaks should be part of an address. I've seen many addresses on one line with their parts separated just by dots or pipes. Those are line breaks. Given the inherent structure of an address, a definition list with name/value pairs would also be more semantically fitting than a paragraph of text with line breaks. I don't know about that. When you look up the formal way to write an address, it's not a set of name-value pairs. It's a set of lines. For example, from the UK post office site: http://www.postoffice.co.uk/portal/po/content1?catId=19100182mediaId=95100765 address (Note, by the by, that address, despite its name, is about page contact information, not about postal addresses.) dl dtName/dtddP. Sherman/dd dtStreet/dtdd42 Wallaby Way/dd dtCity/dtddSydney/dd /dl /address That would be fine, but isn't how you write an address. Or just: address dl ddP. Sherman/dd dd42 Wallaby Way/dd ddSydney/dd /dl /address The latter is very wrong, there's no name part! Regarding poems, line breaks have conventionally been used in Western literature to aid in manifesting the rhythm. And there surely are many poems that use formatting for artistic effect. Indeed, see the example under pre. But I think it would be hard to say that *line* breaks are an inherent part of poems per se. I'd say that breaks are important means to determine structure, but line breaks are just one of many possible manifestations of such breaks. I have spoken to poets who would strongly disagree with you, but that's academic -- there's nothing that says that br has to map to a physical new line. It's just a conceptual line break. Just like in a musical score where the bar is present in sheet music but not in the actual music being played. I don't know that those are equivalent to line breaks. Interestingly, the examples given for where not to use br look like great examples to actually use a break element (not necessarily a line break). First example: pa ...34 comments./abr a ...Add a comment./a/p There are two separate pieces of text that belong together (they are both related to comments). So using one paragraph to group them is fine. But they can benefit from a separation that is a bit stronger than just punctuation since one of them is purely informational and the other is a call to action. This is where a break element is perfect. One designer might want a line break. So he should be able to set a line break property on that break. Another designer doesn't like line breaks. So let her set the break to be generated as a green, medium-sized dot. I disagree. Here the break is purely presentational and has nothing to do with the semantic of the information. Second example: plabelName: input name=name/labelbr labelAddress: input name=address/label/p Although I also prefer the version without the br element, I must say that a form is the one element where presentational markup does make sense. But br is not presentational. By its very nature a form has an explicit design, otherwise it would be called free-form. Granted, in web design there usually isn't and probably shouldn't be such a strong form character as in paper-based forms. I do not agree with the premise of this argument. So, in summary, I suggest changing the br element to just be a logical break element with the default rendition of a line break, but which could be adjusted
Re: [whatwg] [br] element should not be a line break
Aryeh wrote: It's kind of a fake, though, since the definition includes spans of text whose typical typographic presentation is boldened and other prose whose typical typographic presentation is italicized. With those semantics, there's no sensible way to render them in any medium except bold and italics. In speech, you could never present them properly based on those semantics -- you'd probably just have to ignore them. For example, even if you wanted to audibly offset italicized thoughts (which you probably don't), you can't distinguish thoughts from ship names. According to the spec the i element represents a span of text in an alternate voice or mood. It's very easy to do that in speech but very hard in writing. That's why we have emoticons and irony tags. The new semantics are pretty solid for i. Admittedly, it's harder to make the case for the b element. b is closely tied to presentation. Its purpose is to stylistically offset something. Just like the mark element is used to highlight something in a different context, b is used to highlight something in the original context. In both cases leaving the highlighting out wouldn't change the meaning. b is an accessibility feature which makes it easier to identify key parts regardless of medium. I'd agree that b has the weakest semantics of all the semantic elements in the spec. Using spans with classes would work just as well. Aryeh wrote: The presentation-independence is hollow: the semantics are such that it is correct to use b/i for exactly those things that are conventionally bolded or italicized. You're implying that these things are conventionally bolded or italicized as an end in itself. Most of the time there's a reason why things are bolded or italicized other than I don't like regular type. The restricted set of means for conveying semantics in type-setting doesn't mean we can't use a richer set of elements in HTML. Even if at the end of the day all that richness is presented in bold and italics. Google doesn't care ;-)
Re: [whatwg] [br] element should not be a line break
Aryeh wrote: No, but it's a stand-in for a class of semantics that can only fairly be summarized as the places where you would always use a line break in print. There is no single behavior that screen readers could use to correctly present br, but the same is true for any number of other cases. You're right that screen readers cannot convey line breaks in a manner suitable to the medium. Line breaks do not exist in speech. They are specific to text presentation and even there they are a concession to the physical limits of paper, stone tablets etc. and to usability concerns. In a browser, line breaks are completely unnecessary. Even the longest paragraph could be just one line. Let the user scroll! That's why I originally suggested getting rid of the line break element. It is purely presentational and doesn't make sense in speech. However, we could use a break element on the text level. Breaks are natural to any medium. In speech they are represented as pauses or changes in voice/volume or beep. In print and on screen they are represented as white space or line breaks or separator lines or dots or whatever.
Re: [whatwg] [br] element should not be a line break
On Mon, 2010-08-09 at 11:55 +0200, Thomas Koetter wrote: Aryeh wrote: No, but it's a stand-in for a class of semantics that can only fairly be summarized as the places where you would always use a line break in print. There is no single behavior that screen readers could use to correctly present br, but the same is true for any number of other cases. You're right that screen readers cannot convey line breaks in a manner suitable to the medium. Line breaks do not exist in speech. They are specific to text presentation and even there they are a concession to the physical limits of paper, stone tablets etc. and to usability concerns. In a browser, line breaks are completely unnecessary. Even the longest paragraph could be just one line. Let the user scroll! That's why I originally suggested getting rid of the line break element. It is purely presentational and doesn't make sense in speech. However, we could use a break element on the text level. Breaks are natural to any medium. In speech they are represented as pauses or changes in voice/volume or beep. In print and on screen they are represented as white space or line breaks or separator lines or dots or whatever. I still think that they are more than presentational. Consider a poem being read out; the breaks are spoken with a pause (if that's the right way to say it?!) When you print the poem onto some visual media, the breaks are usually depicted with an actual line break, or sometimes a large space. I'm not entirely sure how a Braille browser would deal with a line break though, but I would assume there is some form of identifier for a new line/line break that might be used there. I don't see the br tag to be too different from something like em. There are ways to express this both visually and in speech that are totally different yet effective. Why are emphasised words written in italics anyway? It's only convention from the history of the printing press, not through any special symbolic link that we all have between the look and sound of the words. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] [br] element should not be a line break
Aryeh wrote: It cannot be used if you don't want to include the words like Street:, which are typically omitted, unless you add the dts with display: none, which is unreasonable. Aryeh wrote: Every group must have a dt element. As Tab already pointed out, I quoted the error-recovery behavior. You were right that dl elements shouldn't be used without a dt element. So, an address could be marked up like this: address class=vcard dl class=adr dt class=fnP. Sherman/dt dd class=street-address42 Wallaby Way/dd dd class=localitySydney/dd /dl /address Doing the same with explicit line breaks is awkward if you want to use microformats. address class=vcard p class=adr span class=fnP. Sherman/spanbr span class=street-address42 Wallaby Way/spanbr span class=localitySydney/span /p /address But I'm sure somebody can explain to me why line breaks must be part of the address. Aryeh wrote: No elements do. Characters do, though. Every period, comma, semicolon, colon, and dash is a minor logical break in the paragraph, but it would be incorrect to use br for any of those. Yes, even the space character breaks up a run of characters into words. My point is not that there are no other kinds of breaks. What I'm saying is that there's a somewhat stronger text-level break. Something that falls between character-type breaks and paragraph breaks. That something is used in poems and it can be used to split up an address. But in my opinion, that's definitely not a *line* break. Otherwise, a poem couldn't really be read aloud. Aryeh wrote: So can omitting line breaks. The address 123 Imaginary Place New York, NY 12345 is not the same as 123 Imaginary Place New York, NY 12345 Absolutely! But are these different addresses? 123 Imaginary Place New York, NY 12345 123 Imaginary Place | New York, NY 12345 123 Imaginary Place * New York, NY 12345 Street number: 123 Street: Imaginary Place City: New York State: NY Zip code: 12345 I would say no. Even though the first three don't contain a line break while the last one contains three additional line breaks. How can a *line* break then be part of the content? Aryeh wrote: Indeed, the spec explicitly forbids using br where the line break is presentational: br elements must be used only for line breaks that are actually part of the content, as in poems or addresses. Now you're quoting the part of the spec that I say is wrong to prove me wrong. That's not fair! Just eliminate the word line in the spec and everything is fine.
Re: [whatwg] [br] element should not be a line break
On Wed, Aug 4, 2010 at 7:03 PM, Jeremy Keith jer...@adactio.com wrote: This is no longer true. The semantics of b and i have been changed in HTML5, specifically to separate the presentation from the meaning. Specifically, any reference to screen- or page-specific styling like bold and italic have been removed (allowing the elements to still have meaning in a medium such as audio). It's kind of a fake, though, since the definition includes spans of text whose typical typographic presentation is boldened and other prose whose typical typographic presentation is italicized. With those semantics, there's no sensible way to render them in any medium except bold and italics. In speech, you could never present them properly based on those semantics -- you'd probably just have to ignore them. For example, even if you wanted to audibly offset italicized thoughts (which you probably don't), you can't distinguish thoughts from ship names. The presentation-independence is hollow: the semantics are such that it is correct to use b/i for exactly those things that are conventionally bolded or italicized.
Re: [whatwg] [br] element should not be a line break
On Thu, Aug 5, 2010 at 5:24 AM, Thomas Koetter thomas.koet...@id-script.de wrote: That's not correct. Then give a counterexample. Actually, I shouldn't have used the term definition list as such a list type does not exist in HTML5. The meaning of the dl element has been changed to that of an association list (name/value pairs). So, it can and should be used for addresses. I maintain that it is the most semantically rich HTML5 element for addresses. It cannot be used if you don't want to include the words like Street:, which are typically omitted, unless you add the dts with display: none, which is unreasonable. According to the spec it is perfectly acceptable to leave out all dt elements: If a dl element contains only dd elements, then it consists of one group with values but no names. That says what the meaning is of a dl element with no dt elements. It doesn't say such a group is permitted. The normative authoring requirements are in the first two sentences of the element's description: The dl element represents an association list consisting of zero or more name-value groups (a description list). Each group must consist of one or more names (dt elements) followed by one or more values (dd elements). Every group must have a dt element. Which elements currently let me logically break up a paragraph? I can't think of any. There are only a handful of empty elements (like br, wbr, hr, img, input, param, embed). Except br none of them would be appropriate in such a case. No elements do. Characters do, though. Every period, comma, semicolon, colon, and dash is a minor logical break in the paragraph, but it would be incorrect to use br for any of those. I would disagree here because I don't consider punctuation to be presentational. I'd say it's content because leaving punctuation out can change the meaning. So can omitting line breaks. The address 123 Imaginary Place New York, NY 12345 is not the same as 123 Imaginary Place New York, NY 12345 Indeed, the spec explicitly forbids using br where the line break is presentational: br elements must be used only for line breaks that are actually part of the content, as in poems or addresses.
Re: [whatwg] [br] element should not be a line break
On Thu, Aug 5, 2010 at 1:48 PM, Ryosuke Niwa ryosuke.n...@gmail.com wrote: That's totally incorrect in HTML5 as Thomas has pointed out. As I pointed out, it's only theoretically incorrect. b still means something that's conventionally boldface, and i still means something that's conventionally italic. Let me ask you a question. What do you suppose non-visual user agent should do when they encounter br? Simply ignore them because it only signifies a line break? Or read out that there's a line break? Neither seems user friendly to me. If anything, a momentary pause will be appropriate because what's what we usually do when reading a book and a line break appears. This clearly isn't *line break*. No, but it's a stand-in for a class of semantics that can only fairly be summarized as the places where you would always use a line break in print. There is no single behavior that screen readers could use to correctly present br, but the same is true for any number of other cases. How to pronounce the word minute depends on context too, because the sequence of letters M-I-N-U-T-E can signify multiple concepts that happen to be represented the same way textually, but vary when spoken. There is no realistic way to avoid this kind of thing. Even if you eliminate it on the markup level, it remains on the level of text, so you haven't actually made the problem go away. Instead, we rely on the fact that a listener can usually extract the meaning pretty well even if some of the fine distinctions are lost, and focus accessibility efforts on avoiding only drastic misrepresentations (like missing content images). This discussion would not even be occurring if not for incidental choices in the underlying technology. If HTML respected Unicode line breaks, no one would propose that Unicode line breaks must be axed in favor of a semantic solution. Insisting that every single HTML element must be fully semantic and media-independent, while ignoring the fact that web pages are written in text and that is *intrinsically* not media-independent, does not make any sense.
Re: [whatwg] [br] element should not be a line break
On Thu, Aug 5, 2010 at 2:53 PM, Bryce Fields royalrod...@gmail.com wrote: Why not just list br along with the other obsolete elements instead of trying to rebrand it semantically? What markup do you propose for addresses and poems, and in what practical sense would this markup be superior to using br?
Re: [whatwg] [br] element should not be a line break
On Fri, Aug 6, 2010 at 4:29 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Thu, Aug 5, 2010 at 2:53 PM, Bryce Fields royalrod...@gmail.com wrote: Why not just list br along with the other obsolete elements instead of trying to rebrand it semantically? What markup do you propose for addresses and poems, and in what practical sense would this markup be superior to using br? The HTML5 spec says of pre: The pre element represents a block of preformatted text, in which structure is represented by typographic conventions rather than by elements. pre sounds ideal for both examples to me (in conjunction w/ the address element in the second example. It preserves the line breaks w/o adding any overhead markup to the mix. -- - Bryce Fields www.royalrodent.com Do or do not. There is no try. -- Yoda
Re: [whatwg] [br] element should not be a line break
I wrote: Given the inherent structure of an address, a definition list with name/value pairs would also be more semantically fitting than a paragraph of text with line breaks. Aryeh wrote; That would either be incorrect use of dl, or would not display as desired, or would require hiding some elements arbitrarily. That's not correct. Actually, I shouldn't have used the term definition list as such a list type does not exist in HTML5. The meaning of the dl element has been changed to that of an association list (name/value pairs). So, it can and should be used for addresses. I maintain that it is the most semantically rich HTML5 element for addresses. If you take a look at most forms where you enter an address, you'll see that there's an association between a label and an input field for the different parts of the address. It's rare that you have just a textarea to enter the entire address (which would be the equivalent of the pNamebrStreetbrCity/p example). So why should the semantics change from input to output? address dl dtName/dtddP. Sherman/dd dtStreet/dtdd42 Wallaby Way/dd dtCity/dtddSydney/dd /dl /address Aryeh wrote: That requires hiding all the dt elements to achieve the same display, which is kind of ridiculous. The first example was meant to underline the association. You're right that it would be ridiculous to insert the dt elements only to hide them (unless there was some accessibility advantage). And as Adam pointed out, following the spec the address element would not be appropriate in many cases. address dl ddP. Sherman/dd dd42 Wallaby Way/dd ddSydney/dd /dl /address Aryeh wrote: That's invalid markup. The first child of a dl (if any) must be a dt. I don't know what the semantics of dl are supposed to be with no dt. According to the spec it is perfectly acceptable to leave out all dt elements: If a dl element contains only dd elements, then it consists of one group with values but no names. Aryeh wrote: It should already be adjustable using existing style properties, so no change is needed except possibly saying it represents a logical break instead of a line break. That's all I'm suggesting. Make it a logical/thematic not a presentational break in the spec. The default rendering should still be a line break to support existing content. Aryeh wrote: This is basically wrong, though, since there are lots of ways to mark up minor logical breaks, and br refers to one particular way, no other. Which elements currently let me logically break up a paragraph? I can't think of any. There are only a handful of empty elements (like br, wbr, hr, img, input, param, embed). Except br none of them would be appropriate in such a case. Aryeh wrote: Look at it this way: br is just a workaround for the fact that HTML ignores newlines in markup. It could have just been #10; in an alternate history. It's presentational, yes, but so are periods and commas. I would disagree here because I don't consider punctuation to be presentational. I'd say it's content because leaving punctuation out can change the meaning.
Re: [whatwg] [br] element should not be a line break
Andy wrote: Far greater semantic richness is obtained by using the ADR microformat Absolutely! Good point. As I was talking about HTML5 elements, I didn't take that into consideration. But then I suggest a combination of the two is even better. address class=vcard dl class=adr dd class=fnP. Sherman/dd dd class=street-address42 Wallaby Way/dd dd class=localitySydney/dd /dl /address This way there are some semantics even if the user agent doesn't support microformats. But this seems to be a separate discussion from the br element.
Re: [whatwg] [br] element should not be a line break
I do see an advantage to permitting the arbitrary styling of the BR element. Often a series of links shown inline are separated by a pipe (|) character. In the past I've produced this effect using border-right and other such malarky on the anchors or inline LIs with the same, but I think semantically the symbol does indeed represent a break between the links and that having the ability to style the break accordingly would be terrific. —Kit On 05/08/2010, at 9:56 PM, Thomas Koetter wrote: Andy wrote: Far greater semantic richness is obtained by using the ADR microformat Absolutely! Good point. As I was talking about HTML5 elements, I didn't take that into consideration. But then I suggest a combination of the two is even better. address class=vcard dl class=adr dd class=fnP. Sherman/dd dd class=street-address42 Wallaby Way/dd dd class=localitySydney/dd /dl /address This way there are some semantics even if the user agent doesn't support microformats. But this seems to be a separate discussion from the br element.
Re: [whatwg] [br] element should not be a line break
On Thu, Aug 5, 2010 at 2:24 AM, Thomas Koetter thomas.koet...@id-script.de wrote: Aryeh wrote: That's invalid markup. The first child of a dl (if any) must be a dt. I don't know what the semantics of dl are supposed to be with no dt. According to the spec it is perfectly acceptable to leave out all dt elements: If a dl element contains only dd elements, then it consists of one group with values but no names. That's error-recovery behavior, just defining how to interpret invalid markup. The first paragraph gives the actual MUST requirements - each group must consist of one or more dts and one or more dds. On Thu, Aug 5, 2010 at 8:24 AM, Kit Grose k...@iqmultimedia.com.au wrote: Often a series of links shown inline are separated by a pipe (|) character. In the past I've produced this effect using border-right and other such malarky on the anchors or inline LIs with the same, but I think semantically the symbol does indeed represent a break between the links and that having the ability to style the break accordingly would be terrific. Bug the browsers that don't let you do so. Ideally you should be able to style it however you want. That's separate from this discussion, though. ~TJ
Re: [whatwg] [br] element should not be a line break
Jeremy Keith: The hr element is currently defined as a paragraph-level thematic break. I think br could be defined as a text-level thematic break. That makes perfect sense. The only problem I see is existing content which relies on consecutive ‘br’s producing multiple line breaks, i.e. often a paragraph-like appearance. (Although ‘br’s were always intended to be collapsed, browsers never did this.)
Re: [whatwg] [br] element should not be a line break
On Wed, Aug 4, 2010 at 2:31 PM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Wed, Aug 4, 2010 at 8:56 AM, Thomas Koetter thomas.koet...@id-script.de wrote: What strikes me though is that according to the spec The br element represents a line break. A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation. Anything else is impossible in this case. b and i are also presentational, but the presentation cannot be separated from the semantics. That's totally incorrect in HTML5 as Thomas has pointed out. Let me ask you a question. What do you suppose non-visual user agent should do when they encounter br? Simply ignore them because it only signifies a line break? Or read out that there's a line break? Neither seems user friendly to me. If anything, a momentary pause will be appropriate because what's what we usually do when reading a book and a line break appears. This clearly isn't *line break*. Best, Ryosuke Niwa
Re: [whatwg] [br] element should not be a line break
On Thu, Aug 5, 2010 at 1:24 PM, Christoph Päper christoph.pae...@crissov.de wrote: Jeremy Keith: The hr element is currently defined as a paragraph-level thematic break. I think br could be defined as a text-level thematic break. That makes perfect sense. The only problem I see is existing content which relies on consecutive ‘br’s producing multiple line breaks, i.e. often a paragraph-like appearance. (Although ‘br’s were always intended to be collapsed, browsers never did this.) Why not just list br along with the other obsolete elements instead of trying to rebrand it semantically? Let's face it. br is a pain to try to rationalize as a purely semantic element and any use you have for the element could probably easily be accomplished w/ other semantic code. Why not just call it obsolete and discourage authors and vendors from using it? (first post...be gentle...) :) - Bryce Fields www.royalrodent.com Do or do not. There is no try. -- Yoda
[whatwg] [br] element should not be a line break
Disclaimer: I'm new to this discussion list, so please excuse me if this topic has been discussed before. A quick search didn't turn up anything though. Currently, I'm writing a book on web programming and I stumbled over the specification of the br element for HTML5. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-br-element In the past, there has been a lot discussion about not using br just to insert line breaks everywhere. I'm fully aware that we have lots of elements that are often a better fit and that, of course, line breaks can be achieved by blocking inline elements. What strikes me though is that according to the spec The br element represents a line break. A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation. Wouldn't it make more sense to consider the br element to be just a minor logical break inside a paragraph? Just like hr represents a thematic break on the paragraph-level. How the break would be rendered is a different matter and should be left to the designer. In addition, the appropriate uses (poems, addresses) and examples currently given are not convincing. Consider this: pP. Shermanbr 42 Wallaby Waybr Sydney/p There's no reason why line breaks should be part of an address. I've seen many addresses on one line with their parts separated just by dots or pipes. Given the inherent structure of an address, a definition list with name/value pairs would also be more semantically fitting than a paragraph of text with line breaks. address dl dtName/dtddP. Sherman/dd dtStreet/dtdd42 Wallaby Way/dd dtCity/dtddSydney/dd /dl /address Or just: address dl ddP. Sherman/dd dd42 Wallaby Way/dd ddSydney/dd /dl /address Regarding poems, line breaks have conventionally been used in Western literature to aid in manifesting the rhythm. And there surely are many poems that use formatting for artistic effect. But I think it would be hard to say that *line* breaks are an inherent part of poems per se. I'd say that breaks are important means to determine structure, but line breaks are just one of many possible manifestations of such breaks. Just like in a musical score where the bar is present in sheet music but not in the actual music being played. Interestingly, the examples given for where not to use br look like great examples to actually use a break element (not necessarily a line break). First example: pa ...34 comments./abr a ...Add a comment./a/p There are two separate pieces of text that belong together (they are both related to comments). So using one paragraph to group them is fine. But they can benefit from a separation that is a bit stronger than just punctuation since one of them is purely informational and the other is a call to action. This is where a break element is perfect. One designer might want a line break. So he should be able to set a line break property on that break. Another designer doesn't like line breaks. So let her set the break to be generated as a green, medium-sized dot. Second example: plabelName: input name=name/labelbr labelAddress: input name=address/label/p Although I also prefer the version without the br element, I must say that a form is the one element where presentational markup does make sense. By its very nature a form has an explicit design, otherwise it would be called free-form. Granted, in web design there usually isn't and probably shouldn't be such a strong form character as in paper-based forms. So, in summary, I suggest changing the br element to just be a logical break element with the default rendition of a line break, but which could be adjusted via a new style property. I would love to hear your thoughts. -- Thomas Koetter
Re: [whatwg] [br] element should not be a line break
Hi.. I too am new to this discussion, but I thought I'd share my thoughts. Personally, I agree with you on the topic. I would dispute the use of the address tag in all circumstances, as if I remember correctly this is for marking up contact information for an author of the page? But yes, I agree. For example we should be able to disable the line-breaks' presentational effect easily through the use of a stylesheet (or indeed enable it). On 4 August 2010 13:56, Thomas Koetter thomas.koet...@id-script.de wrote: Disclaimer: I'm new to this discussion list, so please excuse me if this topic has been discussed before. A quick search didn't turn up anything though. Currently, I'm writing a book on web programming and I stumbled over the specification of the br element for HTML5. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-br-element In the past, there has been a lot discussion about not using br just to insert line breaks everywhere. I'm fully aware that we have lots of elements that are often a better fit and that, of course, line breaks can be achieved by blocking inline elements. What strikes me though is that according to the spec The br element represents a line break. A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation. Wouldn't it make more sense to consider the br element to be just a minor logical break inside a paragraph? Just like hr represents a thematic break on the paragraph-level. How the break would be rendered is a different matter and should be left to the designer. In addition, the appropriate uses (poems, addresses) and examples currently given are not convincing. Consider this: pP. Shermanbr 42 Wallaby Waybr Sydney/p There's no reason why line breaks should be part of an address. I've seen many addresses on one line with their parts separated just by dots or pipes. Given the inherent structure of an address, a definition list with name/value pairs would also be more semantically fitting than a paragraph of text with line breaks. address dl dtName/dtddP. Sherman/dd dtStreet/dtdd42 Wallaby Way/dd dtCity/dtddSydney/dd /dl /address Or just: address dl ddP. Sherman/dd dd42 Wallaby Way/dd ddSydney/dd /dl /address Regarding poems, line breaks have conventionally been used in Western literature to aid in manifesting the rhythm. And there surely are many poems that use formatting for artistic effect. But I think it would be hard to say that *line* breaks are an inherent part of poems per se. I'd say that breaks are important means to determine structure, but line breaks are just one of many possible manifestations of such breaks. Just like in a musical score where the bar is present in sheet music but not in the actual music being played. Interestingly, the examples given for where not to use br look like great examples to actually use a break element (not necessarily a line break). First example: pa ...34 comments./abr a ...Add a comment./a/p There are two separate pieces of text that belong together (they are both related to comments). So using one paragraph to group them is fine. But they can benefit from a separation that is a bit stronger than just punctuation since one of them is purely informational and the other is a call to action. This is where a break element is perfect. One designer might want a line break. So he should be able to set a line break property on that break. Another designer doesn't like line breaks. So let her set the break to be generated as a green, medium-sized dot. Second example: plabelName: input name=name/labelbr labelAddress: input name=address/label/p Although I also prefer the version without the br element, I must say that a form is the one element where presentational markup does make sense. By its very nature a form has an explicit design, otherwise it would be called free-form. Granted, in web design there usually isn't and probably shouldn't be such a strong form character as in paper-based forms. So, in summary, I suggest changing the br element to just be a logical break element with the default rendition of a line break, but which could be adjusted via a new style property. I would love to hear your thoughts. -- Thomas Koetter
Re: [whatwg] [br] element should not be a line break
On Wed, Aug 4, 2010 at 3:56 PM, Thomas Koetter thomas.koet...@id-script.de wrote: Disclaimer: I'm new to this discussion list, so please excuse me if this topic has been discussed before. A quick search didn't turn up anything though. If you haven't taken the time to read the FAQ in its entirety, I'd suggest that you take the time to do so. http://wiki.whatwg.org/wiki/FAQ#Why_are_some_presentational_elements_like_.3Cb.3E.2C_.3Ci.3E_and_.3Csmall.3E_still_included.3F The short form is that part of HTML5 is documenting how HTML1..4 works, so that browsers can support existing content by implementing the HTML5 specification. Changing how an existing entity from HTML1..4 works would result in browsers which do not properly render content from HTML1..4 which is not acceptable
Re: [whatwg] [br] element should not be a line break
-Original Message- From: timeless.b...@gmail.com [mailto:timeless.b...@gmail.com] On Behalf Of timeless Sent: Wednesday, August 04, 2010 5:07 PM If you haven't taken the time to read the FAQ in its entirety, I'd suggest that you take the time to do so. http://wiki.whatwg.org/wiki/FAQ#Why_are_some_presentational_elements_like_.3Cb.3E.2C_.3Ci.3E_and_.3Csmall.3E_still_included.3F The short form is that part of HTML5 is documenting how HTML1..4 works, so that browsers can support existing content by implementing the HTML5 specification. Changing how an existing entity from HTML1..4 works would result in browsers which do not properly render content from HTML1..4 which is not acceptable Thanks for the hint about the FAQ. Regarding the br element I believe that my suggestion does just that. It supports existing content by defaulting br to be displayed as a line break. But going forward br would be considered a minor logical break inside a paragraph. Presentation could be changed from the default line break to some generated content. Now seems to be a good time to implement such a change in the semantics. Correct me if I'm wrong, but hr went through a very similar change.
Re: [whatwg] [br] element should not be a line break
data:text/html,%3Cstyle%3Ebr%20,%20b%20{display:inline;%20content:%22x%22}b:after,br:after{content:%22%20|%20%22}%20%3C/style%3Ea%3Cbr%3Eb%3Cb%3E%3C/b%3Ec
So, in Safari, the above actually lets me replace br w/ whatever I like.
bz indicates that I can't do that in Gecko because br is a replaced something.
Re: [whatwg] [br] element should not be a line break
On Wed, Aug 4, 2010 at 8:56 AM, Thomas Koetter thomas.koet...@id-script.de wrote: What strikes me though is that according to the spec The br element represents a line break. A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation. Anything else is impossible in this case. b and i are also presentational, but the presentation cannot be separated from the semantics. Wouldn't it make more sense to consider the br element to be just a minor logical break inside a paragraph? Just like hr represents a thematic break on the paragraph-level. How the break would be rendered is a different matter and should be left to the designer. Line breaks are not used for minor logical breaks inside paragraphs. Those are typically represented by a period. Consider this: pP. Shermanbr 42 Wallaby Waybr Sydney/p There's no reason why line breaks should be part of an address. I've seen many addresses on one line with their parts separated just by dots or pipes. Given the inherent structure of an address, a definition list with name/value pairs would also be more semantically fitting than a paragraph of text with line breaks. That would either be incorrect use of dl, or would not display as desired, or would require hiding some elements arbitrarily. address dl dtName/dtddP. Sherman/dd dtStreet/dtdd42 Wallaby Way/dd dtCity/dtddSydney/dd /dl /address That requires hiding all the dt elements to achieve the same display, which is kind of ridiculous. address dl ddP. Sherman/dd dd42 Wallaby Way/dd ddSydney/dd /dl /address That's invalid markup. The first child of a dl (if any) must be a dt. I don't know what the semantics of dl are supposed to be with no dt. ul would work, if you really wanted, but I don't see how it's any more semantic. So, in summary, I suggest changing the br element to just be a logical break element with the default rendition of a line break, but which could be adjusted via a new style property. It should already be adjustable using existing style properties, so no change is needed except possibly saying it represents a logical break instead of a line break. This is basically wrong, though, since there are lots of ways to mark up minor logical breaks, and br refers to one particular way, no other. Look at it this way: br is just a workaround for the fact that HTML ignores newlines in markup. It could have just been #10; in an alternate history. It's presentational, yes, but so are periods and commas. When I type a period, I don't want the browser to interpret that as some generic separator that it might hopefully decide to render as a period, I want *a period*. Exactly that, nothing else. Likewise for newlines. We don't need to impose some abstract semantic meaning on *everything*. Some presentation is so closely tied to the meaning of the document that it can't reasonably be abstracted away. This is true for b, i, sup, sub, and br, among others.
Re: [whatwg] [br] element should not be a line break
Thomas wrote: What strikes me though is that according to the spec The br element represents a line break. A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation. I agree. Other elements have been redefined to remove medium-specific descriptions from their definitions (b, i, and hr, specifically). It seems logical to me that br should get the same treatment. timeless wrote: The short form is that part of HTML5 is documenting how HTML1..4 works, so that browsers can support existing content by implementing the HTML5 specification. The suggestion, as far as I understand it, is not to change how the element *works* in browsers, but merely to redefine its meaning as a minor logical break rather than a line break. The default browser styling would not change. Aryeh wrote: Anything else is impossible in this case. b and i are also presentational, but the presentation cannot be separated from the semantics. This is no longer true. The semantics of b and i have been changed in HTML5, specifically to separate the presentation from the meaning. Specifically, any reference to screen- or page-specific styling like bold and italic have been removed (allowing the elements to still have meaning in a medium such as audio). I like Thomas's suggestion (or, at least, I like it as much as any of the semantic redefinitions being applied to formerly-presentational elements). The hr element is currently defined as a paragraph-level thematic break. I think br could be defined as a text-level thematic break. Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
