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
Ian Hickson (2010-12-07): > On Thu, 26 Aug 2010, Christoph Päper wrote: Sorry for replying late. >> 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. >>> (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.
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: > P. Sherman > 42 Wallaby Way > Sydney > > 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=19100182&mediaId=95100765 > (Note, by the by, that , despite its name, is about page contact information, not about postal addresses.) > > NameP. Sherman > Street42 Wallaby Way > CitySydney > > That would be fine, but isn't how you write an address. > Or just: > > > P. Sherman > 42 Wallaby Way > Sydney > > 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 . > 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 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: > 34 comments. > Add a comment. > > 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: > Name: > Address: > > 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 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 via a new style property. That's already what it is. I've added a note to make this clearer.
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 s with >display: none, which is unreasonable. Aryeh wrote: >Every group must have a 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: P. Sherman 42 Wallaby Way Sydney Doing the same with explicit line breaks is awkward if you want to use microformats. P. Sherman 42 Wallaby Way Sydney 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 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 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 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 , 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 tag to be too different from something like . 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: >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 , 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
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 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 / 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
On Fri, Aug 6, 2010 at 4:29 PM, Aryeh Gregor wrote: > > On Thu, Aug 5, 2010 at 2:53 PM, Bryce Fields wrote: > > Why not just list 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 ? The HTML5 spec says of : "The pre element represents a block of preformatted text, in which structure is represented by typographic conventions rather than by elements." sounds ideal for both examples to me (in conjunction w/ the 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
On Thu, Aug 5, 2010 at 2:53 PM, Bryce Fields wrote: > Why not just list 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 ?
Re: [whatwg] [br] element should not be a line break
On Thu, Aug 5, 2010 at 1:48 PM, Ryosuke Niwa wrote: > That's totally incorrect in HTML5 as Thomas has pointed out. As I pointed out, it's only theoretically incorrect. still means "something that's conventionally boldface", and 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 , 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 5:24 AM, Thomas Koetter 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 s 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 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 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 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 Wed, Aug 4, 2010 at 7:03 PM, Jeremy Keith wrote: > This is no longer true. The semantics of and 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 / 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 1:24 PM, Christoph Päper wrote: > Jeremy Keith: > > > > The element is currently defined as "a paragraph-level thematic > break." I think 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 along with the other obsolete elements instead of trying to rebrand it semantically? Let's face it. 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
Re: [whatwg] [br] element should not be a line break
On Wed, Aug 4, 2010 at 2:31 PM, Aryeh Gregor > wrote: > On Wed, Aug 4, 2010 at 8:56 AM, 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. > > Anything else is impossible in this case. and 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
Jeremy Keith: > > The element is currently defined as "a paragraph-level thematic break." > I think 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 Thu, Aug 5, 2010 at 2:24 AM, Thomas Koetter wrote: > Aryeh wrote: >>That's invalid markup. The first child of a (if any) must be a >>. I don't know what the semantics of are supposed to be with >>no . > > 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 s and one or more s. On Thu, Aug 5, 2010 at 8:24 AM, Kit Grose 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
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. > > > > P. Sherman > 42 Wallaby Way > Sydney > > > > 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
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. P. Sherman 42 Wallaby Way Sydney 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 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 , 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 NameStreetCity example). So why should the semantics change from input to output? >> >> >>NameP. Sherman >>Street42 Wallaby Way >>CitySydney >> >> Aryeh wrote: > That requires hiding all the 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. >> >> >> P. Sherman >> 42 Wallaby Way >> Sydney >> >> Aryeh wrote: >That's invalid markup. The first child of a (if any) must be a >. I don't know what the semantics of are supposed to be with >no . 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 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: is just a workaround for the fact that HTML >ignores newlines in markup. It could have just been 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
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 (, , and , specifically). It seems logical to me that 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. and are also > presentational, but the presentation cannot be separated from the > semantics. This is no longer true. The semantics of and 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 element is currently defined as "a paragraph-level thematic break." I think could be defined as "a text-level thematic break." Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] [br] element should not be a line break
On Wed, Aug 4, 2010 at 8:56 AM, 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. Anything else is impossible in this case. and 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: > P. Sherman > 42 Wallaby Way > Sydney > > 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 , or would not display as desired, or would require hiding some elements arbitrarily. > > > NameP. Sherman > Street42 Wallaby Way > CitySydney > > That requires hiding all the elements to achieve the same display, which is kind of ridiculous. > > > P. Sherman > 42 Wallaby Way > Sydney > > That's invalid markup. The first child of a (if any) must be a . I don't know what the semantics of are supposed to be with no . 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 refers to one particular way, no other. Look at it this way: is just a workaround for the fact that HTML ignores newlines in markup. It could have just been 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 , , , , and , among others.
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 w/ whatever I like.
bz indicates that I can't do that in Gecko because is a replaced something.
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
On Wed, Aug 4, 2010 at 3:56 PM, Thomas Koetter 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
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 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: > P. Sherman > 42 Wallaby Way > Sydney > > 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. > > > >NameP. Sherman >Street42 Wallaby Way >CitySydney > > > > Or just: > > >P. Sherman >42 Wallaby Way >Sydney > > > > 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: > 34 comments. > Add a comment. > > 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: > Name: > Address: > > 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 > > > >
[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: P. Sherman 42 Wallaby Way Sydney 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. NameP. Sherman Street42 Wallaby Way CitySydney Or just: P. Sherman 42 Wallaby Way Sydney 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: 34 comments. Add a comment. 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: Name: Address: 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
