On 01/13/2012 03:45 PM, Ian Hickson wrote:
On Thu, 15 Dec 2011, Boris Zbarsky wrote [edited for context]:
On 12/15/11 3:10 PM, Ian Hickson wrote [edited for context]:
I might be open to changing the current spec text -- presumably to
just definewbr as follows, or something similar (though
On Thu, 15 Dec 2011, Boris Zbarsky wrote [edited for context]:
On 12/15/11 3:10 PM, Ian Hickson wrote [edited for context]:
I might be open to changing the current spec text -- presumably to
just define wbr as follows, or something similar (though using
U+200B would probably affect text
On Wed, 14 Dec 2011, Boris Zbarsky wrote:
On 12/14/11 8:05 PM, Ian Hickson wrote:
it was with respect tonobr, which we now
define in terms of 'white-space'.
Maybe that needs to change?
How else would we define it?
Whether it's wbr or nobr that gets defined in terms that violate CSS,
the
On 12/15/11 3:10 PM, Ian Hickson wrote:
Whether it'swbr ornobr that gets defined in terms that violate CSS,
the result is the same as far as I can tell.
Fair. We may need changes or extensions to CSS if nothing else works.
If we make a change here it seems better to move towards just
On Fri, 13 May 2011, Boris Zbarsky wrote:
http://www.w3.org/TR/html5/rendering.html#punctuation-and-decorations
says this:
The wbr element is expected to override the 'white-space' property and
always provide a line-breaking opportunity.
Why is this desirable? [...]
In terms of
On 12/14/11 8:05 PM, Ian Hickson wrote:
it was with respect tonobr, which we now
define in terms of 'white-space'.
Maybe that needs to change?
-Boris
On 5/17/11 6:48 PM, Aryeh Gregor wrote:
On Tue, May 17, 2011 at 12:37 AM, Robert O'Callahan
rob...@ocallahan.org wrote:
Amazingly, our line breaking rationale is actually quite well documented!
https://wiki.mozilla.org/Gecko:Line_Breaking
Some comments on UAX#14:
On 05/14/2011 12:41 AM, Boris Zbarsky wrote:
On 5/14/11 3:29 AM, Jukka K. Korpela wrote:
For example, when mentioning URLs in the text of a document, you
normally want to prevent line breaks in them by default and only allow
line breaks at specific points, as in
On 5/14/11 2:06 PM, Jukka K. Korpela wrote:
I don't think HTML specs should say whether it does; they should just
specify what wbr means, and in the case of rendering affected by CSS,
it's up to CSS specs to define the effects of CSS rules.
OK, good, we agree.
And as far as I
can see, the
On Sat, 14 May 2011 05:49:11 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
http://www.w3.org/TR/html5/rendering.html#punctuation-and-decorations
says this:
The wbr element is expected to override the 'white-space' property and
always provide a line-breaking opportunity.
Why is this
On 5/16/11 11:27 AM, Simon Pieters wrote:
IIRC Gecko matched the spec at the time wbr was specced.
This testcase:
!DOCTYPE html
html style=width: 0; white-space:nowrap
Will thiswbrwrap?
/html
does not wrap in Gecko 2.0, 1.9.2, 1.9.1, 1.9.0, or 1.8.1. Gecko 1.8.1
was released in October
On 5/16/11 12:44 PM, Boris Zbarsky wrote:
On 5/16/11 11:27 AM, Simon Pieters wrote:
IIRC Gecko matched the spec at the time wbr was specced.
This testcase:
!DOCTYPE html
html style=width: 0; white-space:nowrap
Will thiswbrwrap?
/html
does not wrap in Gecko 2.0, 1.9.2, 1.9.1, 1.9.0, or
On 05/16/2011 06:50 AM, Boris Zbarsky wrote:
another would be adding a new text-wrap value that means exactly that, leaving
it
up to the markup language to identify the allowed breakpoints.
I would prefer not to do this, if it's not necessary.
When I wish to say that characters like the
On Mon, 16 May 2011 18:44:11 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/16/11 11:27 AM, Simon Pieters wrote:
IIRC Gecko matched the spec at the time wbr was specced.
This testcase:
!DOCTYPE html
html style=width: 0; white-space:nowrap
Will thiswbrwrap?
/html
does not wrap in Gecko
On 5/16/11 5:26 PM, fantasai wrote:
No, because browsers treat a large number of non-whitespace characters
as allowing line breaks after them. Authors need something to prevent
ridiculous and distorting line breaks in, say, -1, %5, and f(1).
OK. I think that something belongs in CSS (or, going
On Mon, May 16, 2011 at 7:27 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Whether to prioritize is a CSS issue. Whether there's a breakpoint at all
after the 'f' in the string y = f(1) is a quality of implementation issue,
imo.
Slightly tangential, but I once saw a page that displayed fine in
On Mon, May 16, 2011 at 5:34 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
On Mon, May 16, 2011 at 7:27 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Whether to prioritize is a CSS issue. Whether there's a breakpoint at all
after the 'f' in the string y = f(1) is a quality of implementation
On 5/16/11 8:34 PM, Aryeh Gregor wrote:
On Mon, May 16, 2011 at 7:27 PM, Boris Zbarskybzbar...@mit.edu wrote:
Whether to prioritize is a CSS issue. Whether there's a breakpoint at all
after the 'f' in the string y = f(1) is a quality of implementation issue,
imo.
Slightly tangential, but I
Amazingly, our line breaking rationale is actually quite well documented!
https://wiki.mozilla.org/Gecko:Line_Breaking
Some comments on UAX#14:
http://www.cs.tut.fi/~jkorpela/unicode/linebr.html
Rob
--
Now the Bereans were of more noble character than the Thessalonians, for
they received the
14.5.2011 10:41, Boris Zbarsky wrote:
But why should this [wbr] override CSS that says do not break at any break
opportunities?
I don't think HTML specs should say whether it does; they should just
specify what wbr means, and in the case of rendering affected by CSS,
it's up to CSS specs to
20 matches
Mail list logo
