On Sun, 15 May 2011 19:11:09 +0200, Glenn Maynard gl...@zewt.org wrote:
On Sat, May 14, 2011 at 11:49 AM, Eric Carlson
eric.carl...@apple.comwrote:
It seems to me that the right way to fix the problem is let people
know
it is sloppy code, not to figure out a way to work around it.
The
On Sat, 14 May 2011 00:34:36 +0200, Ian Hickson i...@hixie.ch wrote:
On Mon, 14 Feb 2011, Philip Jägenstedt wrote:
For the record, I removed Opera's support (I assume it was an
unintended side-effect) for object data=javascript:... along with
the rest at the time when I wrote my previous mail
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
I have a couple of general questions about the HTML Editing Commands spec:
1) Will there be any provision for special handling of whitespace text
nodes? I notice that WebKit leaves them alone. For example, running
document.execCommand(bold, false, null) for the following HTML with
selection
Am 12.05.2011 22:28 schrieb Aryeh Gregor:
Behavior for Enter in contenteditable in current browsers seems to be
as follows:
* IE9 wraps all lines inp (including if you start typing in an
empty text box). If you hit Enter multiple times, it inserts empty
ps. Shift-Enter insertsbr.
This is
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
Am 16.05.2011 15:33 schrieb Markus Ernst:
Am 12.05.2011 22:28 schrieb Aryeh Gregor:
A problem withp is that it has top and bottom margins by default,
so hitting Enter once will look like a double line break. One
real-world execCommand() user I looked at (vBulletin) sets p { margin:
0 } for its
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
Hi all,
Since this is *my* code that we're talking specifically about, I'd like to
repeat Glenn's point that this is not sloppy code (the cheeky shit), and that
the /everyman/ developer is going to think that attaching an event is perfectly
legal and will expect it to work.
Now you're right,
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 Mon, May 16, 2011 at 3:20 AM, Simon Pieters sim...@opera.com wrote:
The state can have changed before the event has actually fired, since
state changes are sync but the events are queued. So if the script happens
to run in between then func is run twice. See
While following the other fullscreen thread [1], I remembered there was talk
of using a CSS media type for full screen.
Mozilla's proposal [2] mentions a new media type @full-screen.
Should this in any way extend to browsers that support a chromeless / F11
key full screen mode? Do we care to
On Fri, May 13, 2011 at 6:29 PM, Ehsan Akhgari eh...@mozilla.com wrote:
We're not going to add pretty-printing for the purposes of this spec, are
we?
No, I didn't realize Boris wasn't talking about web-visible features.
Sure, but how are we going to detect that? Do you agree that they intend
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
(Somehow Gmail's autodetection of from address failed, so this was
sent from the wrong address and bounced. Resending, please resend any
feedback to the list.)
On Mon, May 16, 2011 at 6:59 AM, Tim Down timd...@gmail.com wrote:
1) Will there be any provision for special handling of whitespace
Currently, the spec[1] says:
The activeElement attribute on HTMLDocument objects must return the
element in the document that is focused. If no element in the Document
is focused, this must return the body element.
This does not fully match IE, or is underspecified. If the document
has frames
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, 14 Feb 2011, David Levin wrote:
Although the default search provider may have a significant impact on a
user�s web experience, it isn�t easy for users to set this.
Ideally, a search engine should be able to offer the user the ability to
easily use it as the default. Currently,
On Mon, May 16, 2011 at 18:29, Ian Hickson i...@hixie.ch wrote:
AddSearchProvider(string openSearchUrl, [optional] bool asDefault)
retrieves the open search document from openSearchUrl and decides in a
UA specific manner whether to prompt the user about the change or
addition.
I haven't
On Mon, 16 May 2011, Adam Shannon wrote:
I don't like having the only barrier between changing the default search
engine for a user's browser be a single dialog box. This list (and
others) have repeatedly found that dialogs don't work and users skip
past them.
Think of the non-techy
IE's behavior is better than the current spec because it allows a page to
find the focused element even if the focused element is in a frame by
walking down the frame tree if the activeElement is a frame.
There is existing code that depends on this:
On Mon, 14 Feb 2011, Simon Pieters wrote:
On Mon, 14 Feb 2011 21:47:48 +0100, wha...@whatwg.org wrote:
Author: ianh
Date: 2011-02-14 12:47:46 -0800 (Mon, 14 Feb 2011)
New Revision: 5883
Modified:
complete.html
index
source
Log:
[giow] (2) Make a parser-inserted script
On Mon, 14 Feb 2011, David Flanagan wrote:
The spec says that every HTMLElement has an onreadystatechange idl
attribute. But then it never says anything about firing readystatechange
events at elements, only at the Document.
Can it be removed from HTMLElement, or does it need to be there
On Mon, May 16, 2011 at 18:39, Ian Hickson i...@hixie.ch wrote:
On Mon, 16 May 2011, Adam Shannon wrote:
I don't like having the only barrier between changing the default search
engine for a user's browser be a single dialog box. This list (and
others) have repeatedly found that dialogs don't
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.
On 5/16/11, Ian Hickson i...@hixie.ch wrote:
On Mon, 16 May 2011, Adam Shannon wrote:
I'd rather see UA's implement better controls on their end than see an
API which could be largely abused. (Drag and drop browser controls over
tons of sites asking for permission to be the default.)
I
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
On 05/16/2011 12:02 PM, Andrew Scherkus wrote:
While following the other fullscreen thread [1], I remembered there was talk
of using a CSS media type for full screen.
Mozilla's proposal [2] mentions a new media type @full-screen.
Should this in any way extend to browsers that support a
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
33 matches
Mail list logo
