W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2010

[Bug 10828] i18n comment 4 : new attribute: bidibreak

From: <bugzilla@jessica.w3.org>
Date: Wed, 06 Oct 2010 22:51:50 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1P3cpy-00042J-28@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10828

--- Comment #4 from Maciej Stachowiak <mjs@apple.com> 2010-10-06 22:51:49 UTC ---
(In reply to comment #3)
> (In reply to comment #1)
> > If this really needs to be expressed in markup, perhaps a new element would be
> > better.
> > 
> > In particular, having a markup attribute that doesn't correspond to a CSS
> > property but still inherits and affects rendering of other elements is an
> > unusual pattern and would be awkward to implement.
> > 
> > Is there a Unicode character that creates a line break but has Unicode class WS
> > instead of B? If so, that would make it easier to define what happens for the
> > proposed "soft" line breaks.
> 
> The equivalent "soft" line break Unicode character is LINE SEPARATOR, U+2028.
> 
> Regarding doing this through a new element, it would get the job done, but I
> have been warned that new elements are problematic in terms of support from
> existing software (e.g. how would an existing browser know that the new element
> does not need a closing tag?) and generally very hard to get in.

New global attributes are also hard to get in. And in this case, I think an
inheriting global attribute is not as clean an approach.

Question: does including U+2028, either as a literal unicode character or as a
numeric character reference, get the job done? Or does that character get
affected by whitespace collapsing?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 6 October 2010 22:51:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:30 UTC