RE: Should <br> be removed from the HTML5 spec?



Hi, I do not mind introducing new CSS attributes as CSS attributes have been addressed for other features (I think that a break could be styled as hard or soft in css you would just need one break).
 
However the css br styling can be worked in over time . . . it will not be implemented immediately and the existing br should not be deprecated.
 
I have no trouble seeing use cases for both the hard and soft breaks.  I think break should by default be hard . . . but a soft break should be available.
 
So I like the solution we decided on.
 
Best,
 
-- C. E. Whitehead
cewcathar@hotmail.com 




----------------------------------------
> To: aronovitch@gmail.com
> CC: public-i18n-bidi@w3.org; public-i18n-bidi-request@w3.org
> From: MOHIEM@eg.ibm.com
> Date: Sun, 7 Nov 2010 13:04:06 +0200
> Subject: Re: Should 
be removed from the HTML5 spec?
>
> Hello Amit,
> I don't feel comfortable with the idea of removing 
from HTML5 spec for
> the following:
> 1- Deprecating 
will cause incompatibility issues for web pages
> supporting browsers at different HTML levels.
> 2- It will need a lot of rework from web pages and software that produce
> HTML pages to account for the new attributes.
>
> Thanks And Best regards,
> Mohamed Mohie , PMP®
> ________________________________________________
> GCoC BIDI ,
> Advisory Software Engineer, Project Manager, M.Sc.
> Cairo Technology Development Center (CTDC)
> IBM Egypt
> email : mohiem@eg.ibm.com
>
>
>
>
>
> From: Amit Aronovitch 
> To: public-i18n-bidi@w3.org
> Date: 05/11/2010 10:04 ص
> Subject: Should 
be removed from the HTML5 spec?
> Sent by: public-i18n-bidi-request@w3.org
>
>
>
> Following the correspondence on HTML5 bugs #10828 and #11211,
> I started to think that maybe a more radical approach is the way to go.
>
> Quick summary:
>
> 1) The issue at hand is the current problems and incompatibility issues
> with 
:
> * HTML4 spec (implemented by Gecko and Opera) says that 
should
> be "soft" (not introduce a bidi paragraph break).
> * Implementation by IE and Webkit (as well as common usage on
> websites) assume "hard" 
(considered bidi paragraph separator).
>
> 2) Our suggestion, originally in #10828, was split into two bugs:
> * #10828 suggests that 
should be "hard" by default (contrary to
> HTML4).
> * #11211 suggests that some way should be provided to produce a "soft
> 
".
>
> 3) While #10828 seems to be on the road to acceptance, we are having
> trouble with use cases for #11211:
> * The "natural" use case (I assume, based on old HTML tutorials, that
> this was the original purpose of 
) is poems.
> However, while there are *a lot* of websites with poems, I could
> not find an RTL poem that contains numbers and LTR words (I am sure there
> exist such sites - would appreciate a link if you find one).
> Same goes for mail addresses (they do include numbers and Latin
> words, but the 
's are normally positioned in non-sensitive places.
> * A use case brought up by Adil (comment 18 on #10828), a site
> displaying a newspaper page, in a way that should match the actual printed
> page.
> This was criticized by Ian Hickson for being "a bit of an abuse of
> HTML".
>
> Now, considering the last point, the editor does have a point. These
> linebreaks are a matter of display. However, the thing that troubles me is
> that
> *the same argument applies equally well to the "hard" 
* (bug #102828).
> As opposed to 
, which reflects a logical partition of the text into DOM
> nodes, 
is a matter of textual display.
> Since HTML5 aims to represent the pure logical structure of document, maybe
> the right place for such things is in the interaction between the contents
> (text) and CSS.
>
> Hence, the new suggestion:
>
> (1) Add mandatory entities (temporary names):
> &ps; for U+2029 (paragraph separator, replacement for "hard" 
)
> &ls; for U+2028 (line separator, replacement for "soft" 
)
>
> (2) Remove 
from HTML5 spec.
> Add a comment saying that 
was deprecated, stating explicitly that
> when upgrading from ׁ‎HTML4, 
should be replaced with &ps; if the
> intended
> use was a hard break, or with &ls; if the intended use was compliant
> with the HTML4 spec (i.e. soft break).
>
> In a private discussion with Aharon, he said that this approach might, in
> practice, work against our goal of reaching compatibility. I'm sure he can
> explain this better than me.
> The purpose of this post is trying to reach some concensus before posting
> the idea in bugzilla.
>
> thanks for taking the time to read,
> Amit A.
>
> On Thu, Oct 21, 2010 at 2:00 AM, Amit Aronovitch 
> wrote:
> (just an idea - not replying in bugzilla, because I'm not entirely sure
> it is a good one)
>
> Seems like the gatekeepers are willing to change the spec of 
to
> become "hard" (like ie/webkit),
> but are reluctant to add a new attribute, or even a new element, which
> would make the soft break functionality available,
> suggesting 
 as an alternative (i.e. adding to the spec a
> requirement that it should be supported).
>
> A possible compromise might be to add named entities, perhaps &sbr; (soft
> break) or &vbr; (visual break) for U+2028, and &br; for U+2029 (this
> might increase the chance that browser-makers would actually add support
> for these characters).
>
> Personally, I think that poetry and addresses alone (not to mention other
> use cases mentioned in the bug) are good enough use cases for adding the
> missing functionality as a 1st class citizen (element or attribute). At
> least it seems that it was important enough to be added to early versions
> of HTML.
>
> Amit
>

Received on Sunday, 7 November 2010 13:58:09 UTC