Re: [whatwg] video ... script race condition
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 basic problem is that it isn't sloppy code: it's correct for almost all events. It's just wrong for events that are fired as part of loading, which is what makes it so easy to get wrong. It also means that these events don't work well with deferred scripts. For the simple cases I'd probably do: video.addEventListener(canplay, func, false); if(video.readyState = HAVE_FUTURE_DATA) func.apply(video); // missed the first one 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 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267 -- Simon Pieters Opera Software
Re: [whatwg] Javascript: URLs as element attributes
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 in this thread. This intentionally doesn't match what the spec says. (Disclaimer: this is only my opinion on something that isn't really my area of expertise, so others at Opera might decide that the spec is great and push in the opposite direction. It seems unlikely at this point, though.) [...] Of what has been brought up so far, javascript: as an inline resource is not very useful at all, so IMO the only reason to keep it would be for legacy compat. I'll follow up on this again once the change to block inline javascript: URLs in Opera has been in the wild for a while, hopefully reporting that no compat issues have arisen. Since only Firefox now supports this, I've removed support for it from the spec. (It's just commented out for now; we can put it back if someone makes a compelling argument.) Great! I can report that the changes to block inline javascript: URLs went into Opera 11.10 and so far I'm not aware of any site compat issues having being caused by it. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Interaction of wbr and CSS white-space
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
http://www.whatwg.org/wbrspecs/wbrweb-apps/wbrcurrent-work/wbrmultipage/
Oops, my newsreader introduced a line break after a hyphen. And such
behavior is common in web browsers as well. So it is natural to wrap
urls in text in span class=url.../span with CSS rule .url {
white-space: nowrap; }.
Except that browsers don't support that, for the most part.
The problem you describe is one of breakpoint prioritization. I have no problem with
wbr getting priority over breakpoints
that the browser determines itself. CSS3 Text has explicit language to the
effect that not all breakpoint opportunities are
equal in section 7.1.
Anyway, the idea is to disallow line breaks (that would otherwise be
allowed by line breaking rules, whatever they might be in each
situation) _except_ where explicitly allowed by wbr.
This can be done by simply using white-space: normal and having UAs prioritize
breaks at wbr over other linebreaks, no?
Yes, but you'd get unexpected breaks where nowrap isn't used.
IIRC (this is going back 10 yrs) wbr isn't supposed to have
a higher priority than spaces.
The HTML specs cannot dictate what CSS specs do
They're trying to, is my point. As an implementor I then have to reconcile the
conflict somehow. My current plan if it's up to
me is to do so by completely ignoring the part of HTML5 that's conflicting with
CSS here.
I agree that the HTML spec should not be trying to contradict or override
the CSS specs, and suggest that the HTML editor make a habit of posting
such issues to www-style to bring them to the CSS spec editors' attention
instead of merely writing overrides into the HTML spec...
So maybe the best way to convey the message is to remove the reference
to white-space and add a note on the _HTML_ element nobr (even if it
is kept as obsolete - the spec should still specify its meaning):
The wbr element specifies a line breaking opportunity even when used
inside a nobr element.
I would be fine with that, if it's useful. Is it useful?
Yes, if you wanted to control breakpoints, nobr...wbr.../nobr
was very useful.
I think it's possible to deal with the rendering requirements by
specifying
wbr { content: '\8203' /* zwsp */;
text-wrap: normal; }
Slightly off-topic: in CSS3, there is an 'avoid' value for 'text-wrap',
which is designed to solve problems similar to those currently dealt
with by using nobr/wbr combinations.
~fantasai
[whatwg] More HTML Editing Commands questions
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 boundaries denoted by pipes: p|One/p pTwo|/p ... in Chrome 10 you get p|bOne/b/p pbTwo|b/p The whitespace between the p elements has been ignored. This also leads to a bug, since it seems the check for whether the selection content is already completely bold does take into account the whitespace node and rerunning the command now has no effect. Opera surrounds the whitespace node within a styling element, while Firefox seems to have some voodoo magic to decide whether or not to surround a whitespace node. In the simple case above, it leaves it alone so long as I haven't previously manipulated the DOM manually with my own script. 2) Will the spec specify what happens when executing commands on an insertion point/caret? Tim
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
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 what people know from MS Word, too, and thus it should be
considered as a de-facto standard. I don't have current versions of
other office text editors installed right now, but I assume they will
behave the same, or at least provide a setting to make them behave like
that.
I have seen content management systems where text editors tweak the
enter key to behave the same also in non-IE UAs (e.g. if you use
Contenido with TinyMCE, Firefox produces the same output as IE when you
hit enter).
I'd strongly suggest to spec this behaviour, or at least provide some
kind of setting to force it.
* Firefox 4.0 just usesbr _moz_dirty= for Enter and Shift-Enter,
always. (What's _moz_dirty for?)
* Chrome 12 dev doesn't wrap a line when you start typing, but when
you hit Enter it wraps the new line in adiv. Hitting Enter
multiple times outputsdivbr/div, and Shift-Enter always inserts
br.
* Opera 11.10 wraps inp like IE, but for blank lines it uses
pbr/p instead of justp/p (they render the same).
What behavior do we want?
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 rich-text editor for this reason, and translatesp and
div to line breaks on the server side. The usual convention in text
editors is that hitting Enter only creates one line break, although
Word 2007 seems to do two by default.
This is very presentational thinking. If you write a text, it should be
possible to produce paragraphs by default. If you use div instead of
p, there would be extra coding needed to make paragraphs available.
Another problem withp is that it's very easy to create
unserializable DOMs with it. I've seen cases where at least some
browsers will put things insidep that will break out of thep,
and I've done it myself by mistake too.
The same applies e.g. for list items, UAs have to solve this problem
anyway. One approach that I could imagine is to close and re-open the
paragraph (resp. list item) at the boundaries of the element which is
put inside it.
Re: [whatwg] Interaction of wbr and CSS white-space
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 current CSS specs don't make it crystal clear what the
values of white-space mean in each case.
CSS 3 Text is pretty clear as far as I can tell. Granted, it's still a
draft.
Except that browsers don't support that, for the most part.
They mostly support white-space: nowrap well.
Yes.
The part that causes problems is that some new versions of browsers support it
all too well,
ignoring wbr markup.
Again, imo wbr should NOT cause line-breaks inside white-space:
nowrap. That's the wrong solution to the problem you're trying to solve.
The problem you describe is one of breakpoint prioritization.
I don't think so. I think the primary issue is specifying allowed
breakpoints.
So what you really want is a way to say the only breakpoints are ones I
allow. That's not the same thing as white-space: nowrap which means
no breakpoints).
fantasai posted one possible solution here; 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. Note that such an
implementation would be web-page-observable: setting wbr {
whites-space: nowrap} would prevent breaks at wbr. Would that be
reasonable?
A thought experiment, by the way: should shy; be treated the same way
as wbr? Why or why not? It's an explicitly inserted break
opportunity
When I wish to say that characters like the hyphen - and
the percent sign % are not to be treated as breakpoints, as browsers
may treat them by default, what can I do?
Nothing at the moment, but that seems like something to specify via CSS
text-wrap, not via markup.
As the default treatment of characters varies by browser, and the characters in
notations like URLs
vary, there is need for being able to say in this piece of text,
suppress all breakpoints you might imply, and obey only explicit
indications of line breaks or line break opportunities.
Right. I'd be fine with that. But again, would shy; be considered
such an explicit indication?
This is what nobr and wbr were created for
It sounds like half the problem here is that nobr is defined as just
mapping to white-space:nowrap, right? And the other half is that wbr
is then not defined usefully at all.
Snipped the history since I'm honestly not interested in that. I'm
intested in what the goals are (which is only tangentially related to
what they were 12 years ago) and how we get there.
This can be done by simply using white-space: normal and having UAs
prioritize breaks at wbr over other linebreaks, no?
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 out on a limb,
should just be considered a quality-of-implementation issue). This is
not an HTML-specific problem.
Breaking a URL after - is particularly confusing
Why? It seems no more confusing than breaking after '/' unless the
implication is that people will think the '-' is inserted by a
hyphenation algorithm and isn't part of the url.
Note that RFC 3986 Appendix C is NOT relevant here. That talks about
line-breaking URLs by inserting whitespace (like actual newline
characters) into the URL string. We're talking about purely visual
line-breaking that does not modify the content in any way; if you select
and copy the url there will NOT be a newline in the result. The
situation is fundamentally different from plaintext wrapping as talked
about in RFC 3986 Appendix C.
Breaking after % in a URL is absurd, as it breaks a %-encoding of a
character.
Uh... how does it break it? Am I just missing something?
Is this the same confusion as above for '-', where you think there's
whitespace being introduced after the '%' or something?
Yes, that's what text-wrap: none means. Right now the HTML spec
explicitly says that this setting should be ignore for wbr, which is
what make no sense.
The statement is in section 13 Rendering, which in non-normative,
Then why is it present at all? I think it should just be removed.
And it refers to white-space, not text-wrap. Whether white-space: nowrap
implies something for text-wrap depends on the definition of CSS
I think talking about anything other than CSS3 Text is pointless here;
by the time this part of HTML5 reaches anything resembling stability
CSS3 Text will have too. Furthermore, CSS2.1 and earlier don't really
define how breaking happens (past saying that white-space: nowrap
prevents it).
Weird. Anyway, white-space there links to CSS 2.1, and the
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
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 rich-text editor for this reason, and translatesp and
div to line breaks on the server side. The usual convention in text
editors is that hitting Enter only creates one line break, although
Word 2007 seems to do two by default.
I am sorry I overread this last sentence when writing my previous
message. I have a swiss-german installation of Word 2007, I did not
change the settings. Hitting enter produces paragraphs here, and applies
the spaces above and/or below that are specified in the paragraph style.
This is the behaviour I have known from Word for years. Maybe there are
regional differences in the defaults of Word.
This is very presentational thinking.
Re-reading my message I am afraid this sentence could be read as an
offense. There was absolutely no offense intended (I am sorry I had to
go pick up my daughter and sent too quickly). I wanted to state that
what CSS people apply should not matter to the question of creating p,
div or br.
The vBulletin example shows that there is a use case for applying br.
I state that there is a use case for applying p for enter and br for
shift-enter.
IMO an ideal solution would provide both (or, if there are use cases for
div, all three) possibilities, settable with a flag or an attribute.
The standard should be what office users expect from their everyday
experience.
Re: [whatwg] Interaction of wbr and CSS white-space
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 desirable? IIRC Gecko matched the spec at the time wbr was specced. Personally I don't mind changing the spec. -- Simon Pieters Opera Software
Re: [whatwg] video ... script race condition
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, whoever pointed out the 7am alarm example, if you attach the event too late, then you'll miss the boat. However, it's a chicken an egg situation. You don't have the DOM so you can't attach the event handler, and if you do have the DOM, the damn event has fired already. What's the fix? Well, the work arounds are certainly viable, again from an everyman developer point of view: 1) Attach higher up, on the window object and listen for the canplay/loadedmetadata/etc and check the event.target 2) Attach an inline event handler (not nice, but will do) The fix? Since ultimately we have exactly the same potential bug with image load events, is to update the specification and make it clear: that depending on the speed of the connection and decoding, the following xyz events can fire **before** your script runs. Therefore, here's a couple of work arounds - or just be aware. Any objections? At the same time, does someone want to raise this as a bug? Cheers folks, Remy Sharp / everyman developer :) On 16 May 2011, at 08:20, Simon Pieters wrote: 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 basic problem is that it isn't sloppy code: it's correct for almost all events. It's just wrong for events that are fired as part of loading, which is what makes it so easy to get wrong. It also means that these events don't work well with deferred scripts. For the simple cases I'd probably do: video.addEventListener(canplay, func, false); if(video.readyState = HAVE_FUTURE_DATA) func.apply(video); // missed the first one 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 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267 -- Simon Pieters Opera Software
Re: [whatwg] Interaction of wbr and CSS white-space
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 2006. So unless this section of the spec is at least that old, I think you recall incorrectly... Personally I don't mind changing the spec. Good, good. ;) -Boris
Re: [whatwg] Interaction of wbr and CSS white-space
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 1.8.1. Gecko 1.8.1 was released in October 2006. So unless this section of the spec is at least that old, I think you recall incorrectly... Fwiw, I spot checked and it also doesn't wrap in Gecko builds from 2006-10-01, 2005-10-01, 2004-10-01, 2004-03-02. I'd need to install some old linux distributions to run older nightlies than that looks like, so I'm not going to worry about it. ;) -Boris
Re: [whatwg] video ... script race condition
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 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267 That's a pretty nasty API bug; hopefully that gets fixed. This thread's issue is bad enough without problems like this overlaid on top of it breaking the sane solutions. -- Glenn Maynard
[whatwg] Browser full screen and CSS media types
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 have any interaction between the full screen API and the browser full screen mode? For example, Opera switches the CSS media type to @projection and I believe is the only browser to do so. Andrew [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031538.html [2] https://wiki.mozilla.org/Gecko:FullScreenAPI
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
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 to add a paragraph most of the time? Probably, yes. I think this is a problem that we should solve anyway, since we can't avoid splitting nodes in the general case. Once we have an algorithm for that, we can just use it wherever necessary, right? You can look at the nsEditor::SplitNodeImpl algorithm used in Gecko here: http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/base/nsEditor.cpp#2698. I'm sure WebKit includes a similar algorithm... I've got an algorithm, but since it can cause problems, I'd prefer to use it only where really necessary. So far I've gone to some pains to avoid it, and for inline markup I've succeeded across the board. E.g., if you run bold on b id=xfoo[bar]baz/b then in Firefox 4.0 and Opera 11.10 you get b id=xfoo/bbarb id=xbaz/b (duplicate id), in Chrome 12 dev you get b id=xfoo/bbarbbaz/b (id lost on one element), and in IE9 you get strongfoo/strongbarstrongbaz/strong (both id's lost). The spec's algorithm produces span id=xbfoo/bbarbbaz/b/span, which I think preserves the markup about as well as you possibly could, although of course it's a bit longer. But to be honest, the only way to decide correct behavior here is to try figuring out what authors are using these extra attributes for, and what they expect to happen. I can't imagine it's common to use id's in contenteditable, and I don't really know what the expected behavior is if you do. Maybe we shouldn't worry about it. I don't really think we want to nest stuff here, it leads into weird markups and most likely werid layouts (think of an editable area with a margin-left for paragraphs/divs.) Adding margins to paragraphs and divs wouldn't behave very reliably unless they were inserted around text very consistently. Otherwise you'd have some text indented and some not. So I guess we can ask a further question: if we use div or p, do we want to try guaranteeing that all runs of text will be wrapped in the chosen element? For instance, WebKit doesn't wrap in div very consistently at all, IE and Opera don't nest p inside li. So you can't depend on all your text being wrapped in the element anyway. * If you give the inputp[foo]/p to Chrome 12 dev and run insertOrderedList, it produces the DOM (expressed in XML) polli[foo]br //li/ol/p, which when you serialize to text/html and unserialize becomesp/polli[foo]br //li/olp/p. Firefox generates ollifoo/li/ol. [etc.] Yes, Firefox generates serializable DOMs in every p-related case I've seen. If you do createLink with value def on a href=abcbfoo[bar]baz/b/a it produces a href=abcbfooa href=defbar/abaz/b/a, though, which becomes a href=abcbfoo/b/aba href=defbar/abaz/b when you serialize and unserialize it. So the general problem of unserializable DOMs occurs in some cases in all browsers. That's not a great reason by itself for not using p, but it's something to hold against it. I guess I don't understand your reasoning. If you're saying that existing implementations have bugs on this sort of thing, for sure, no discussion about that. But I don't know if we can draw the conclusion that it's not possible to generate an HTML5 valid DOM if we used p. It is possible, it's just more likely to cause bugs. I think the right way to decide between p and div is to ask ourselves this question: What is the correct element to use?. Isn't that circular? On Fri, May 13, 2011 at 6:35 PM, Ehsan Akhgari eh...@mozilla.com wrote: This is a very good point. I know that p constitutes a UBA paragraph. Does the same apply to div as well? All CSS block boundaries constitute UBA paragraph breaks: User agents that support bidirectional text must apply the Unicode bidirectional algorithm to every sequence of inline-level boxes uninterrupted by a forced (bidi class B) break or block boundary. This sequence forms the paragraph unit in the bidirectional algorithm. http://www.w3.org/TR/CSS21/visuren.html#direction On Mon, May 16, 2011 at 9:33 AM, Markus Ernst derer...@gmx.ch wrote: This is what people know from MS Word, too, and thus it should be considered as a de-facto standard. I don't have current versions of other office text editors installed right now, but I assume they will behave the same, or at least provide a setting to make them behave like that. I'm almost sure that wasn't the standard in older versions of Word, like 1997. I don't have any on hand to test, though. OpenOffice.org Writer (3.2.1, Ubuntu 10.10 version) inserts only a single line break when you hit Enter. I have seen content management systems where text editors tweak the enter key to behave the same also in non-IE UAs (e.g. if you use Contenido with TinyMCE,
Re: [whatwg] Interaction of wbr and CSS white-space
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 hyphen - and
the percent sign % are not to be treated as breakpoints, as browsers
may treat them by default, what can I do?
Nothing at the moment, but that seems like something to specify via CSS
text-wrap, not via markup.
Actually something to consider for 'line-break: strict', maybe.
Jukka, can you post to www-style about your considerations on
that point? It's rather off-topic here. (Add [css3-text] to the
subject.)
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 out on a limb,
should just be considered a quality-of-implementation issue). This
is not an HTML-specific problem.
CSS3 Text does recommend doing some kind of prioritization when allowing
breaks at punctuation other than spaces, so it is both a CSS issue and
a quality-of-implementation issue. :)
http://www.w3.org/TR/css3-text/#text-wrap
Another thing to ponder: I accept that wbr inside nobr should allow
breaking. Should wbr inside pre allow breaking?
That's an interesting one. I'd have to test like Netscape 4 to find out.
If wbr doesn't break in pre, then it seems the rule we want is either
wbr { content: '\8203' /* zwsp */ }
nobr wbr { text-wrap: normal; }
or
wbr { content: '\8203' /* zwsp */; text-wrap: normal; }
pre wbr { content: none; }
I'm leaning somewhat towards the second option.
~fantasai
Re: [whatwg] Interaction of wbr and CSS white-space
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 2.0, 1.9.2, 1.9.1, 1.9.0, or 1.8.1. Gecko 1.8.1 was released in October 2006. So unless this section of the spec is at least that old, I think you recall incorrectly... Sorry. Then it must have been IE instead. :-) IE9 seems to wrap in IE5.5 mode and IE7 mode but not IE9 mode. Personally I don't mind changing the spec. Good, good. ;) -Boris -- Simon Pieters Opera Software
Re: [whatwg] More HTML Editing Commands questions
(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 text nodes? I notice that WebKit leaves them alone. For example, running document.execCommand(bold, false, null) for the following HTML with selection boundaries denoted by pipes: p|One/p pTwo|/p ... in Chrome 10 you get p|bOne/b/p pbTwo|b/p The whitespace between the p elements has been ignored. This also leads to a bug, since it seems the check for whether the selection content is already completely bold does take into account the whitespace node and rerunning the command now has no effect. Opera surrounds the whitespace node within a styling element, while Firefox seems to have some voodoo magic to decide whether or not to surround a whitespace node. In the simple case above, it leaves it alone so long as I haven't previously manipulated the DOM manually with my own script. Whitespace-only text nodes will probably need special handling for a bunch of things. This is one of the issues I list: I need to pay more attention to whitespace-only nodes. In most cases these will have no visual effect, but they'll make many algorithms behave differently: decomposing a range, block-extending, etc. http://aryeh.name/spec/editcommands/editcommands.html#issues But I'm not sure I see any need for special handling here. Currently the algorithm will produce p|bOne/b/pb /bpbTwo|b/p If you don't wrap the whitespace, the user might put their cursor there and it won't be bold when they start typing and they'll be confused. In a quick test, IE and Opera seem to wrap the node, Gecko and WebKit don't (but you say that Gecko even does, in some cases). I'd be inclined to stick to current behavior. It will make the serialization a bit messier, it's true, but not bolding it at all seems like it poses bigger problems. Unless it's impossible for the user to put the cursor in that particular whitespace node, I guess -- then it would make sense not to bold it. Perhaps that's actually the case here. Quick testing seems to show that I can't actually get the cursor in such a text node in the browsers I tested. Thanks for bringing this to my attention, I expanded my existing issue a bit to remind me to look at it later: http://aryeh.name/gitweb.cgi?p=editcommands;a=commitdiff;h=0f2f379f 2) Will the spec specify what happens when executing commands on an insertion point/caret? You mean, with a collapsed selection? I did write tests for that, but found that browsers do nothing special for collapsed selections. But now I see that it's because I was only looking at the DOM. It seems that when you run a command like bold on a collapsed selection, it doesn't do anything to the DOM, but it sets some internal flag or other that creates or splits or whatever the element when the user starts typing, and also changes the answer that queryCommandState() returns. I guess this is to avoid leaving useless elements littered around if the user decides not to type something after all. The more obvious thing would be to create an empty tag and move the selection inside it. But if this is what browsers do, I'll have to spec it. Thanks for pointing it out to me, I've added it as an issue to the spec: http://aryeh.name/gitweb.cgi?p=editcommands;a=commitdiff;h=08c5d27
[whatwg] Fixing activeElement spec to match IE
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 in it and a frame contains the focused element, the activeElement of the HTMLDocument should return the frame element which contains the focus. I have a patch for WebKit [2] to match IE's behavior as described above. [1] http://dev.w3.org/html5/spec/Overview.html#document-level-focus-apis [2] https://bugs.webkit.org/show_bug.cgi?id=49509 erik
Re: [whatwg] Interaction of wbr and CSS white-space
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 out on a limb,
should just be considered a quality-of-implementation issue). This
is not an HTML-specific problem.
CSS3 Text does recommend doing some kind of prioritization when allowing
breaks at punctuation other than spaces, so it is both a CSS issue and
a quality-of-implementation issue. :)
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.
Another thing to ponder: I accept that wbr inside nobr should allow
breaking. Should wbr inside pre allow breaking?
That's an interesting one. I'd have to test like Netscape 4 to find out.
If wbr doesn't break in pre, then it seems the rule we want is either
wbr { content: '\8203' /* zwsp */ }
nobr wbr { text-wrap: normal; }
or
wbr { content: '\8203' /* zwsp */; text-wrap: normal; }
pre wbr { content: none; }
I'm leaning somewhat towards the second option.
Well, it doesn't interact well with replacing pre with div and some
styles Hence the question, in fact.
-Boris
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
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, there are two obstacles to this: 1. The search engine may not be able to detect that it already is the default, so it would offer this too broadly. 2. When a user decides to use it, they have to follow a set of complex instructions (http://www.google.com/search?q=switch+default+search+engines) Proposal Add two apis to window.external: IsSearchProviderInstalled AddSearchProvider These appear to be implemented by IE, Chrome (partly on Windows only), and Firefox (though IsSearchProviderInstalled is stubbed only). IsSearchProviderInstalled(string url) returns * 2 if the origin in the given url is the default search provider * 1 if the origin in the given url is a search provider but not the default. * 0 otherwise If the given url doesn�t have the same security origin as the page, this api throws an access denied exception. (This makes the url redundant but it is kept to be consistent with the method exposed by IE 7.) I have specified this, except instead of throwing an exception it returns 0. This means that stubbing out this method is easy and doesn't require complicated origin checks to be compatible with full implementations. 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 specified the asDefault argument since it isn't implemented anywhere except Chrome, but other than that I have specified it. The UI is left very open-ended. Note that there is already an equivalent declarative feature in HTML: link rel=search. On Tue, 15 Feb 2011, Bjartur Thorlacius wrote: This seems like a slight privacy violation. Not a serious one, but nothing I'd like to be explicitly exposed. It's mitigated to some extent by being limited to same-domain checks (you can't check if someone has made another search engine their default), since frankly if you've made a particular search engine your default they can already tell pretty easily just by looking at your usage, if they really wanted to violate your privacy. However, I have made sure to allow UAs to lie and always return 0. Developing an discoverable UI that'll be consistent between pages seems more important than implementing an API and using complicated heuristics so that it'll hopefully seem not be abused significantly. I've left the UI entirely open. On Fri, 18 Feb 2011, Bjartur Thorlacius wrote: I don't believe that the best solution to that is to implement a cross browser API to allow sites to create their own inconsistent UI to make themselfes default. A user who knows how to make Google default, should be able to make Bing default using the same procedure. Thus the UI has to be implemented by the browser. I agree that a good UA would make this easy and consistent. Why not just have a link rel=search href=#searchform id=searchinput type=text/form? I'm not sure I understand how this would work. Can you elaborate? On Sat, 19 Feb 2011, timeless wrote: Spammers and other fraudsters seem to be perfectly happy with things where they capture things like the default search engine of normal users w/o the users really understanding the consequences. Oddly, even major companies seem willing to risk the wrath of customers. Some seem to enjoy tacking on toolbars to other random apps which make them the default search engine, etc.. Indeed. On Tue, 15 Feb 2011, Kornel Lesi�~Dski wrote: Change of default search provider is a big thing. You don't change that often, and there are only few search engines that make sense to be set as the default one. Browsers can simply ship with predefined set of engines, and that may be easiest and safest option for users. There are many many sites that dream they were used as a default search engine, but their use of this API is only going to annoy or confuse users. Change of default search engine may have security implications — there are less tech-savvy people who rely on search engine for *everything* they do on the net and blindly trust the results (see famous facebook login case). Malicious sites could try to trick people into setting them as default in order to inject links into (proxied) search results. This seems reasonable, indeed. There's already link rel=search that allows browsers discreetly integrate site's search in the UI, without having sites clutter layout with yet another begging button. All the like-me, digg-me tweet-me buttons are awful enough ;) True. -- Ian Hickson U+1047E)\._.,--,'``.fL
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
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 specified the asDefault argument since it isn't implemented anywhere except Chrome, but other than that I have specified it. The UI is left very open-ended. Note that there is already an equivalent declarative feature in HTML: link rel=search. (First, I like that asDefault hasn't been specified yet.) 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 user who simply clicks yes to evil.com's request to change default search provider. Will they even know what that means? Will they care at the time of the dialog? How will they revert back? 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.) -- Adam Shannon Web Developer University of Northern Iowa Sophomore -- Computer Science B.S. http://ashannon.us
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
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 user who simply clicks yes to evil.com's request to change default search provider. Will they even know what that means? Will they care at the time of the dialog? How will they revert back? 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 agree. Note that the spec doesn't say there should be a dialog box at all; it's left entirely up to the UAs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fixing activeElement spec to match IE
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: http://www.google.com/codesearch/p?hl=en#epIciakqvFc/trunk/closure/goog/ui/popupbase.jsq=activeElement%20package:http://closure-library%5C.googlecode%5C.coml=477 . On Mon, May 16, 2011 at 3:39 PM, Erik Arvidsson a...@chromium.org wrote: 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 in it and a frame contains the focused element, the activeElement of the HTMLDocument should return the frame element which contains the focus. I have a patch for WebKit [2] to match IE's behavior as described above. [1] http://dev.w3.org/html5/spec/Overview.html#document-level-focus-apis [2] https://bugs.webkit.org/show_bug.cgi?id=49509 erik
Re: [whatwg] [html5] r5883 - [giow] (2) Make a parser-inserted script not run if it is moved to another docum [...]
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 not run if it is moved to another document before it executes (and not even fetch if it is parsed into another document than its parser's document). Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=11323 These examples http://www.whatwg.org/specs/web-apps/current-work/complete/the-end.html#scripts-that-modify-the-page-as-it-is-being-parsed http://www.whatwg.org/specs/web-apps/current-work/complete/the-end.html#the-execution-of-scripts-that-are-moving-across-multiple-documents need updating Done. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLElement.onreadystatechange
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 for web compatibility? For consistency, all the event handler attributes on HTMLDocument and HTMLElement are the same now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
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 work and users skip past them. Think of the non-techy user who simply clicks yes to evil.com's request to change default search provider. Will they even know what that means? Will they care at the time of the dialog? How will they revert back? 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 agree. Note that the spec doesn't say there should be a dialog box at all; it's left entirely up to the UAs. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' Perhaps it would be better for the group to send a proposal for a UI (or at least guidelines) that's acceptable both from a realistic usability and security standpoint? -- Adam Shannon Web Developer University of Northern Iowa Sophomore -- Computer Science B.S. http://ashannon.us
Re: [whatwg] [br] element should not be a line break
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. Speaking of breaks on line or paragraph level therefore makes more sense to me. I don't really understand the difference. Here comes a *line break* that always means a visual *new line* like here, whereas a *break on line level* // may look differently – and may actually be rendered with orthographic possibilities (dashes, parentheses etc.) instead of markup, when they’re textual content, not structure. I still don't understand what you mean here. (A minor logical break inside a paragraph is not generally represented by a line break, at least not in any typographic conventions I've seen; usually, in my experience, those are denoted either using ellipses, em-dashes, or parentheses.) That’s true for real paragraphs, but not for most “non-paragraphic” texts, e.g. addresses. The lines in an address are separate oral lines, not minor logical breaks inside a pragraph. Addresses (with multpile lines) are a concept native to written, not to spoken language. Certainly addresses are, for their intended purpose, always written down, but that doesn't mean they're never read out. But I don't see how this affects this discussion. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
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 agree. Note that the spec doesn't say there should be a dialog box at all; it's left entirely up to the UAs. Then why add an API when we've already got (IMO superior) declarative markup? The user has to consent. Even confirmation prompts may not be a usable authorization mechanism (as most users generally don't understand them). Use case: User wants to add a search provider. Requirements: A GET form from a site user's consent The chosen solution should be easily adaptable if not usable for publishing as well as searching. Creating a hyperlink to a POST form (without the search relation) should be suitable for microblogging. Solutions: A document advertises a form to the browser; if not installed: the browser advertises the form to the user; the user commands the browser to install the form. document - browser browser - user -- the site is never informed A document ask the browser if the user has installed the form; if not: begs the user to install it; the user asks the document to ask the browser to install the form; the document ask the browser; the browser asks the user whether it should proceed; the user consents. Or do you mean that a script is to ask the browser without user interaction? document - browser document - user browser - user Security considerations: In the case of an API a script bundled with a document may at any point ask for form installation, irrespective of isSearchProviderInstalled making isSearchProviderInstalled redundant, as if it's installed (or blacklisted as in explicit user refusal to install) the call would be ignored anyway. Also, my UA would probably always act as if the form was installed, to protect agaisnt blackmailing á la Facebook scams and sites funded by getting money for endorsing (unwanted) forms.
Re: [whatwg] Interaction of wbr and CSS white-space
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 Gecko but broke horribly in WebKit because of the difference in line-breaking algorithms. There was a really long string in a user comment which Gecko broke over multiple lines but WebKit treated as unbreakable, with the result that WebKit stretched the page so it was unreadable. I think it would be pretty nice if we were to spec line-breaking behavior -- UAX#14 specifies an algorithm that, as far as I can tell, is reasonably simple and much better than any browser now has. (Although I can't say whether it would be acceptable for performance or other considerations.)
Re: [whatwg] Interaction of wbr and CSS white-space
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 issue, imo. Slightly tangential, but I once saw a page that displayed fine in Gecko but broke horribly in WebKit because of the difference in line-breaking algorithms. There was a really long string in a user comment which Gecko broke over multiple lines but WebKit treated as unbreakable, with the result that WebKit stretched the page so it was unreadable. I think it would be pretty nice if we were to spec line-breaking behavior -- UAX#14 specifies an algorithm that, as far as I can tell, is reasonably simple and much better than any browser now has. (Although I can't say whether it would be acceptable for performance or other considerations.) I suspect you're thinking of the site I filed a bug against Webkit for: https://bugs.webkit.org/show_bug.cgi?id=41103 ~TJ
Re: [whatwg] Interaction of wbr and CSS white-space
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 once saw a page that displayed fine in Gecko but broke horribly in WebKit because of the difference in line-breaking algorithms. There was a really long string in a user comment which Gecko broke over multiple lines but WebKit treated as unbreakable, with the result that WebKit stretched the page so it was unreadable. I think it would be pretty nice if we were to spec line-breaking behavior -- UAX#14 specifies an algorithm that, as far as I can tell, is reasonably simple and much better than any browser now has. (Although I can't say whether it would be acceptable for performance or other considerations.) I'm not a line-breaking expert. I'm pretty sure that the people who wrote the Gecko line-breaking code are very familiar with UAX#14, though, based on their code comments and bug comments. I'd suggest asking for their input on why Gecko does something different from UAX#14 if we're considering specifying it. -Boris
Re: [whatwg] Browser full screen and CSS media types
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 chromeless / F11 key full screen mode? Do we care to have any interaction between the full screen API and the browser full screen mode? For example, Opera switches the CSS media type to @projection and I believe is the only browser to do so. I believe the correct list for this discussion would be www-st...@w3.org, with [mediaqueries] in the subject line. ~fantasai
Re: [whatwg] Interaction of wbr and CSS white-space
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 message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
