Re: [whatwg] HTML 5: The l (line) element
On Wed, 23 Apr 2008, Christoph Päper wrote: Ian Hickson schrieb: On Wed, 23 Apr 2008, Christoph Päper wrote: there are probably worse compatibility issues with older specs and browsers than extra blank lines. Hopefully not in HTML5. :-) Isn't wrong numbering worse? HTML4 UA HTML5 UA ol reversed liThird1. Third 3. Third liSecond 2. Second 2. Second liFirst3. First 1. First /ol I don't think wrong numbering is especially serious, no. In important cases, you can always use value=. The difference is that this is a new attribute. Using br/br is something we can never do because there are pages that rely on the /br handling. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5: The l (line) element
On Sun, 17 Feb 2008, Dave Hodder wrote: Please consider adding the 'l' element (as found in XHTML 2). The 'l' element can be used to break up text into separate lines, in a similar manner to the existing 'br' element. Unlike 'br', it is a container element; instead of pLine 1brLine 2/p, one would type plLine 1/llLine 2/l/p. The main advantage of 'l' is presentational -- it becomes much easier to colour lines differently, to add automatic line numbers, etc. While I understand your request, I don't think the use cases you raise are really compelling enough reasons to add a new element to do this. br works, and people have already proposed ways to extend CSS to do line-by-line styling that would work without an explicit line element. On Tue, 19 Feb 2008, Christoph P�per wrote: We could also consider to reuse |br| for this purpose and thus make it magic, i.e. it is empty by default and works like it has always done, but if /br is encountered it turns the preceding br... (but not br.../) on the same nesting level from an empty into a start tag. (If there is no start tag, it is an authoring mistake.) In XHTML5 this would be easy. One problem of this idea is the backwards compatibility for the first line, because |br| traditionally generates a line break immediately, i.e. before not after the logical line. brfirst line/br brsecond line/br ... brn-1th line/br brnth line/br becomes in current implementations zeroth linebr first linebr second linebr ... n-1th linebr nth line Another problem are multiple (adjacent) empty/start tags, where you probably would have to disallow nesting of lines to describe current rendering of multiple (consecutive) line breaks, which is not conformant with HTML4. Actually it's worse, /br is actually handled as br in browsers, so you'd end up with blank lines if we did this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5: The l (line) element
Ian Hickson: On Tue, 19 Feb 2008, Christoph P�per wrote: brfirst line/br Actually it's worse, /br is actually handled as br in browsers, so you'd end up with blank lines if we did this. Yeah, someone already told me by now. On the other hand, there are probably worse compatibility issues with older specs and browsers than extra blank lines.
Re: [whatwg] HTML 5: The l (line) element
On Wed, 23 Apr 2008, Christoph Päper wrote: Ian Hickson: On Tue, 19 Feb 2008, Christoph P�per wrote: brfirst line/br Actually it's worse, /br is actually handled as br in browsers, so you'd end up with blank lines if we did this. Yeah, someone already told me by now. On the other hand, there are probably worse compatibility issues with older specs and browsers than extra blank lines. Hopefully not in HTML5. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5: The l (line) element
Ian Hickson schrieb: On Wed, 23 Apr 2008, Christoph Päper wrote: there are probably worse compatibility issues with older specs and browsers than extra blank lines. Hopefully not in HTML5. :-) Isn't wrong numbering worse? HTML4 UA HTML5 UA ol reversed liThird1. Third 3. Third liSecond 2. Second 2. Second liFirst3. First 1. First /ol
Re: [whatwg] HTML 5: The l (line) element
Christoph Päper writes: Ian Hickson schrieb: On Wed, 23 Apr 2008, Christoph Päper wrote: there are probably worse compatibility issues with older specs and browsers than extra blank lines. Hopefully not in HTML5. :-) Isn't wrong numbering worse? HTML4 UA HTML5 UA ol reversed liThird1. Third 3. Third liSecond 2. Second 2. Second liFirst3. First 1. First /ol That _would_ be a worse example of this if there are existing pages which have ol reversed and which are relying on it doing absolutely nothing. Do you know of any such pages? Note there is a difference between: * Existing content + HTML 5 browser -- an existing page (possibly written years ago, possibly unmaintained) displays consistently in existing browsers, but a browser following HTML 5 would display it differently. * Existing browser + HTML 5 content -- HTML 5 introduces a new feature, not implemented in current browsers. An HTML-5-aware author can choose to use this or not; he'd probably want to take into account his audience and whether there are any work-arounds for older browsers (such as JavaScript which spots 'reversed' attributes and re-orders lis accordingly). Smylers
Re: [whatwg] HTML 5: The l (line) element
On Tue, 19 Feb 2008 11:22:32 +0100, Christoph Päper [EMAIL PROTECTED] wrote: We could also consider to reuse |br| for this purpose and thus make it magic, i.e. it is empty by default and works like it has always done, but if /br is encountered it turns the preceding br... (but not br.../) on the same nesting level from an empty into a start tag. Actually, we can't. /br is a br start tag because of legacy. I don't see why l is so compelling by the way. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] HTML 5: The l (line) element
Christoph Päper wrote: Dave Hodder: Please consider adding the 'l' element (as found in XHTML 2). I think this has been discussed (much) earlier. Anyhow. We could also consider to reuse |br| for this purpose and thus make it magic, i.e. it is empty by default and works like it has always done, but if /br is encountered it turns the preceding br... (but not br.../) on the same nesting level from an empty into a start tag. That's not possible. /br already has magic processing, at least in quirks mode. It's treated the same as br. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
