On 2/4/11 11:20 PM, Adam Barth wrote:
I'm not sure what else is exposed on Crypto, but having this available
to workers certainly make sense.
I was assuming that the crypto object in workers wouldn't have anything
else on it, for now.
-Boris
On 2/5/11 1:55 AM, Roger Hågensen wrote:
On 2011-02-05 04:39, Boris Zbarsky wrote:
In general, I suspect creating a good definition for the float version
of this API may be hard.
Not really, usually it is a number from 0.0 to 1.0, which would map to
say the same as 0 to whatever max 64bit
On 2/5/11 9:08 PM, Roger Hågensen wrote:
If you really wanted a float, and really wanted minimal issue with float
behavior then creating a random um... mantissa.?... should allow a
better 0.0 to 1.0 than the divide shown further up.
That's the thing. The valid mantissas for IEEE floats are
On 2/8/11 3:56 PM, Kyle Simpson wrote:
Yes, it's important to note that it's not even the *execution* of
JavaScript code that's actually the particular issue, but rather just
the parsing of it (even if invoking of the functionality is deferred
until later) that causes the biggest slowdown, in
On 2/8/11 4:13 PM, Boris Zbarsky wrote:
On 2/8/11 3:56 PM, Kyle Simpson wrote:
Yes, it's important to note that it's not even the *execution* of
JavaScript code that's actually the particular issue, but rather just
the parsing of it (even if invoking of the functionality is deferred
until later
On 2/8/11 4:21 PM, John Tamplin wrote:
I think it is useful to provide ignorable hints to browser to indicate
that you want this downloaded but you don't need it parsed right away.
Yes, that's fine. As long as we're not adding some sort of new hard
requirements on actual behavior here, all's
On 2/8/11 7:31 PM, Kyle Simpson wrote:
No, frankly it isn't. No matter how good the implementation of the
JavaScript engine on mobile, the mobile device will always be much more
limited in processing power than a desktop browser environment.
That's not what the question was about.
It's also
On 2/8/11 11:04 PM, Kyle Simpson wrote:
No, frankly it isn't. No matter how good the implementation of the
JavaScript engine on mobile, the mobile device will always be much more
limited in processing power than a desktop browser environment.
That's not what the question was about.
The
On 2/9/11 12:27 AM, Kyle Simpson wrote:
I can't speak definitively as to how the JavaScript engine is
implemented (and if the code is significantly different between mobile
and desktop).
In Gecko's case, it's identical (modulo the different JIT backends for
ARM and x86 and x86-64, of course).
On 2/9/11 2:19 AM, John Tamplin wrote:
I am not sure I understand why you are so opposed to providing a
mechanism for an application to tell the browser it would like the
parsing to not necessarily be performed immediately on a downloaded script.
I'm not opposed to that, as should be clear if
On 2/9/11 10:37 AM, Kyle Simpson wrote:
I think you're assuming a uniformity to browser implementations that's
simply not there.
No, I'm relying on the growing trend of more and more web authors being:
1) aware of performance issues, especially initial page-load performance
2) able to use more
On 2/9/11 10:12 PM, Ian Hickson wrote:
On Mon, 15 Nov 2010, Boris Zbarsky wrote:
On 11/15/10 8:15 PM, Ian Hickson wrote:
Gecko's currently-intended behavior is to do what [the spec]
describes in all cases except:
iframe src=javascript:
object data=javascript:
embed src=javascript
On 2/10/11 1:38 PM, Adam Barth wrote:
The connection is that these features are unlikely to get implemented
in WebKit anytime soon. To the extent that we want the spec to
reflect interoperable behavior across browsers, speccing things that
aren't (and aren't likely to become) interoperable is a
On 2/10/11 3:23 PM, Bjoern Hoehrmann wrote:
There are multiple phases between receiving bytes on the wire and having
executed the code they represent. Parsing would seem unlikely to be the
main problem here (parsing is mainly checking for syntax errors while or
after removing the character
On 2/10/11 5:09 PM, Bjoern Hoehrmann wrote:
And constructing whatever output model (AST, bytecode, whatever) your
parser produces.
I can grant you persisting information about the structure to some point
but generating byte code is not the job of the parser
Well, the parser has to output
On 2/10/11 11:54 PM, James Robinson wrote:
The version of WebKit used by Safari 5.0.3 is rather antiquated at this
point. Using the latest WebKit nightly build, or Chrome 10.0.648.45
dev (which has a significantly newer version of WebKit), I get #ff
and rgba(0, 0, 0, 0.0) on the first test
On 2/11/11 3:34 PM, Ian Hickson wrote:
I'm assuming you're not suggesting changing the alpha=1 case (which is
also different between CSS and canvas). Is that right?
Sadly, probably right. For the alpha=1 case, I would expect there to be
sites depending on this...
-Boris
On 2/11/11 5:12 PM, Ian Hickson wrote:
I tried testing this but I couldn't actually find a modern browser where
there was a way to put content into a sidebar, so I'm not sure how to
test it.
Bookmark something in Firefox. Open the Bookmarks menu, select the
Show All Bookmarks option.
On 2/13/11 8:22 PM, Adam Barth wrote:
It seems likely that window.crypto will continue to grow more quality
cryptographic APIs, not all of which will be appropriate at the
ECMAScript level.
Sure; the question is whether this _particular_ API would be more
appropriate at the language level.
On 2/14/11 11:31 AM, Mark S. Miller wrote:
On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth w...@adambarth.com
mailto:w...@adambarth.com wrote:
That's a pretty long time horizon. You're going to start discussing
it in 2-4 months? That seems a bit overwrought for what amounts to
four
On 2/17/11 8:37 AM, Matthew Raymond wrote:
label
input type='radio' name='a'
textarea/textarea
/label
The label doesn't specify which control is the one it's labeling.
But the spec does:
If the for attribute is not specified, but the label element has a
labelable
On 2/17/11 8:15 AM, Anne van Kesteren wrote:
If you nest elements with activation behavior only the innermost is
activated.
textarea doesn't have activation behavior. So if I have:
labeltextarea/textarea/label
and I click the textarea, then the label will be activated unless we
add some
On 2/17/11 11:07 AM, Nicholas Zakas wrote:
With regards to #1, I do think it could be user-agent defined if
agreement can’t be reached on the correct default behavior (so in IE
preload would default to true while in FF it would default to false).
That seems like a reasonable first step.
CCing
On 2/17/11 11:39 AM, Kyle Simpson wrote:
Memory leak in the sense that the page is holding onto more memory than
it *potentially* needs to. But not memory leak in the sense that this
memory stays around after the page unloads/reloads, right?
Right.
I dunno if
I'd call that a memory leak as
On 2/17/11 12:23 PM, Kyle Simpson wrote:
My worries are cases where a page inadvertently makes you hold on to
tens or hundreds of megabytes of js, not about the 200k case.
Do you have any example where hundreds of megabytes of JavaScript is
being loaded onto pages? Even tens of megabytes seems
On 2/17/11 2:38 PM, Kyle Simpson wrote:
I don't know of any browsers which are set to download more than 8
parallel connections.
You don't need it, if the content is cached, right?
I can't imagine that you'd have 10,000 separate
downloads of the same resource. Depending on race conditions,
On 2/17/11 4:15 PM, Glenn Maynard wrote:
Boris: The 2.0 preload proposal--not 2.1--avoids the preload issues
you're worried about, right? With that version, only script nodes in
the DOM tree are loaded.
I've lost track of the various proposals, honestly. If only nodes in
the DOM are
On 2/22/11 1:25 PM, Will Alexander wrote:
On Thu, 2011-02-17 at 15:24 -0500, Boris Zbarsky wrote:
1) If your script is no-cache, or max-age:0, does IE make a new
request for it for everyscript element?
For the most part this seems to be the case but there are two exceptions
On 2/22/11 1:50 PM, Kyle Simpson wrote:
1) If your script is no-cache, or max-age:0, does IE make a new
request for it for everyscript element?
For the most part this seems to be the case but there are two
exceptions:
a) Before a URL loads, if it's assigned to another script, only one
request
On 2/22/11 3:07 PM, Kyle Simpson wrote:
Look above at what Will says... he says before a URL loads in (a). I
interpreted that to mean that if I make two requests in rapid fire
succession, and the browser hasn't yet gotten the response headers (from
the first request) to tell it not to cache,
On 2/22/11 6:21 PM, Will Alexander wrote:
Would a means by which authors can mark a pre-fetched script as
stale allay some of your concerns?
I wouldn't expect anyone to actually use such a means.
Is there some way to accomplish this in Gecko now for a pre-fetched Image?
If you hold a
On 2/22/11 6:39 PM, Kyle Simpson wrote:
This seems strange to me. Generated images (like in captchas, etc) have
to be common enough
The captchas I just looked at use different URIs for different captcha
images.
I oversimplified a bit: the image cache in Gecko does do some http-like
stuff,
On 2/22/11 7:19 PM, Kyle Simpson wrote:
For #1, I think we've established this is probably true (for those rare
corner cases). Perhaps a more sophisticated in-memory content-uniqueness
cache could be constructed, but it may be more work than it's worth. To
push the ball forward, in a rough
On 2/22/11 8:05 PM, Will Alexander wrote:
I ask because at one point you stated if DOM attachment triggers the
pre-load (instead of src assignment), that would address the memory
consumption.
Well, more precisely it would make it less likely that someone would
accidentally author broken
On 2/22/11 8:14 PM, Kyle Simpson wrote:
First of all, which two proposals are we talking about here?
1. Nicholas' proposal, which is currently to preload a script if its
script element is marked with a `preload` attribute, before the setting
of the `src` property. To execute the script, you
On 2/22/11 8:54 PM, Glenn Maynard wrote:
3. My (and Nicholas's previous) proposal: Script elements are fetched when
inserted into the DOM[1]. An event is dispatched when the script has been
fetched, eg. onfetch or onpreload[2]. A preload attribute is added;
when true, the script will not be
On 2/22/11 9:55 PM, Glenn Maynard wrote:
The main arguments for the readyState approach over this have been: it's
what IE does now, and the preloading when src is set has precedent with
images.
I sympathize with that, since they're aiming to improve the likelihood of
being implemented--but the
On 2/22/11 10:42 PM, Glenn Maynard wrote:
Including execute() being synchronous, raising SyntaxError exceptions
for parse errors, and uncaught exceptions from the script being
propagated up through execute() to its caller?
Hmm. That last one might take some work in Gecko, if it's even sanely
On 2/23/11 4:16 AM, Jorge wrote:
Wouldn't this :
HTMLScriptElement.prototype.execute= function execute () {
// ...
return (1, eval)( this.innerText ); // global eval
}
do it ?
No. First of all, the script can be an external script, so innerText
doesn't do the right thing.
(only
On 2/23/11 8:33 AM, Kyle Simpson wrote:
I'm curious if we could apply some limit to the number of scripts that
will be simultaneously preloaded, at say 100 scripts for instance?
I would be fine with that from an implementation standpoint; not sure
about the author-facing aspect of it.
On 2/23/11 9:14 AM, Kyle Simpson wrote:
The goal (from my perspective) is to come up with the simplest proposal
that serves the use-cases. Simplest being defined in this particular
situation as the least amount of change to the spec, AND the least
amount of change to the browser that has by far
On 2/25/11 3:56 PM, r...@ratherodd.com wrote:
I realise this is a niche scenario that is not often encountered, but I'd
be interested in the rationale behind not implementing it, or whether
others think it would be a good idea to add this feature. Boris Zbarsky
indicated something about contexts
On 2/27/11 2:10 PM, Diego Perini wrote:
Firefox 3.6.13 already returns 4 for window.prompt.length.
Are the 2 extra parameters already known/used ?
From the source:
128 DOMStringprompt([optional] in DOMString aMessage,
129 [optional] in DOMString aInitial,
130
On 2/28/11 2:13 PM, Alexandre Morgaut wrote:
When I read: Any arguments are passed straight through to the handler.
I wonder if it does not mean that I should pass one parameter per argument to
pass to the handler
- setTimeout( myhandler, 1000, arg1, arg2, arg3);
Yes.
But well, the
On 3/1/11 4:37 AM, Alexandre Morgaut wrote:
No. If there were only one parameter, the signature would say |in any
args|. It actually says |in any... args| which means any number of
arguments. See http://www.w3.org/TR/WebIDL/#dfn-variadic-operation
Thanks for highlighting that, I see it more
On 3/1/11 5:29 PM, Ian Hickson wrote:
I am still faced with the fact that there is no way to clear the HTTP
authentication credentials cache.
To some extent that's up to the browser. It logs you in, it can offer the
ability to log you out.
For what it's worth, Firefox even has UI for
On 3/3/11 5:20 AM, Henri Sivonen wrote:
Are there the known to be pages that users frequently encounter that create and
set src on a large number of script nodes without inserting them?
Not known to me, no. I've seen pages that create lots of scripts (one
per each dynamic action they want
On 3/7/11 3:11 PM, Michal Zalewski wrote:
In my opinion, the preferred outcome would be to make type=
authoritative when specified, or provide an alternative way of
ensuring specific routing of the retrieved content on markup level.
For what it's worth, I would be _very_ much in favor of
On 3/11/11 11:56 AM, Tab Atkins Jr. wrote:
I suspect it wouldn't be too difficult to do this better - we can know
ahead of time whether the window contains any cross-origin resources
that aren't cleared by CORS.
There are lots of loads that can be cross-origin but aren't subject to
CORS at
On 3/20/11 3:52 AM, David Singer wrote:
You could help the CSS group move faster? They (we) are nice people, with a
large list of things to work on. There's even a public mailing list.
If you have ideas, they are pretty open to them, also. Before you give up, I'd
give them a try.
Just to
On 3/21/11 8:05 AM, Philip Jägenstedt wrote:
On http://foolip.org/microdatajs/live/#json I have a Download it!
function which uses data: URLs to save JSON generated by JavaScript. The
only real limitation with this approach is that one cannot suggest a
file name, so in Opera the suggested file
On 3/24/11 9:29 PM, Nicholas Zakas wrote:
div
style.foo { color: red; }/style
/div
works just fine in browsers today
and the style information is applied to the entire document.
And it continues to work when they implement the proposed spec, yes.
This is considered invalid HTML5
On 3/25/11 12:53 PM, Nicholas Zakas wrote:
The part of the spec that defines what browsers are supposed to do
already reflects current browser behavior.
Can you point me to that?
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-style-scoped
second paragraph:
On 3/25/11 9:49 PM, Nils Dagsson Moskopp wrote:
More precisely, under what circumstances does
an author have control over the very start ofbody, but not over
head?
I can see how some sort of template setups might have that, where the
head is controlled by the overall site but the body is
On 3/27/11 3:21 AM, Jukka K. Korpela wrote:
It is a rather common setup in websites that offer the public an
opportunity to publish for free. I've been told eBay is an example of
that: you can only affect some parts of the body.
If you can only affect _some_ parts of the body you should in
On 3/28/11 3:28 PM, Aryeh Gregor wrote:
If a node is moved to a position immediately before its original
position
One problem here is that there is not a concept of moved in the DOM.
There's just removed and inserted. Trying to insert something that
already has a parent will remove it and
On 3/29/11 2:19 PM, Aryeh Gregor wrote:
It would be possible to work around it by requiring that
insertBefore() and similar methods do special magic for Ranges
independent of the actual DOM mutations done, however.
In theory, yes. In practice, you have to cover various edge cases (like
what
On 3/29/11 2:37 PM, Boris Zbarsky wrote:
That already has to happen for
insertData()/deleteData()/appendData(), right? All browsers treat
those differently from just setting the data to the equivalent
string.
Those map directly to atomic operations on CharacterData, for what it's
worth.
Oh
On 3/29/11 5:53 PM, Aryeh Gregor wrote:
So is anyone planning on actually trying to remove DOM mutation events, or not?
I think Jonas is still planning on it; we just need to implement a
replacement for them first...
Just something simple like running execCommand(bold) when bar is
selected
On 3/30/11 1:50 PM, Aryeh Gregor wrote:
Hmm, wait a sec. I just reviewed the spec for insertBefore(), and I
don't see any way this could happen. If anything would prevent it
from completing successfully, an exception is supposed to be thrown
before anything else is done. Under what conditions
On 4/1/11 3:26 AM, Alexandre Morgaut wrote:
It is neither part of HTML5
Sadly, it is. Kyle linked to the relevant spec bit.
Let's imagine the effects of existing HTMLElements with id like location, document, event,
toolbar, or even window...
The id lookup happens after all other property
On 4/3/11 12:53 PM, Alexandre Morgaut wrote:
The id lookup happens after all other property resolution in browsers
(but NOT in the current spec text, note), so if you haddiv
id=location and accessed window.location you would get a Location
object, not thediv.
So you can not rely on being able
On 4/6/11 3:43 PM, Jonas Sicking wrote:
What are the use cases for readonly oninput type=text?
The primary one I've seen is to have a non-editable text input that the
user can still select-and-copy from.
-Boris
On 3/30/11 10:50 AM, Aryeh Gregor wrote:
That would result in
pbFoo/bbbar/b/p
but actually, the result in Gecko is
pbFoobar/b/p
So I looked into this. It looks like Gecko does move the text node
containing bar to be a child of the b and tracks which selection
ranges are in the node
On 4/8/11 1:54 PM, Tab Atkins Jr. wrote:
In the legacy color parsing algorithm
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value,
steps 5 and 6 concern CSS color names - 'transparent' should raise an
error, and color
On 4/11/11 11:47 AM, Juriy Zaytsev wrote:
There is a somewhat similar issue for Mozilla about named form controls
shadowing members of HTMLFormElement interface, etc. —
https://bugzilla.mozilla.org/show_bug.cgi?id=322488 I'd love to see that
fixed too; not sure how compat-breaking that would be.
On 4/12/11 12:06 AM, Ian Hickson wrote:
Now, that's a problem for WebGL, because it's not possible to tell in
advance whether the underlying rendering context can be created.
It would be helpful if someone could explain what conditions could lead to
a situation where getContext() could fail to
On 4/30/11 2:24 PM, Michal Zalewski wrote:
Note that somewhat counterintuitively, there would be some security
concerns with markup-level content disposition controls (or any JS
equivalent). For example, consider evil.com doing this:
a
On 5/2/11 7:26 PM, Ian Hickson wrote:
That makes sense, though I think it'd be better for that to be a style
scoped to the binding that defines theselect, personally.
OK, but more on this below.
I would clearly prefer that the behavior be defined in terms of CSS; UAs
that under the hood want
On 5/4/11 6:58 PM, Alexey Proskuryakov wrote:
script
window.print();
/script
pPrint me/p
Safari 5 prints a blank page, while other IE and Firefox print Print me. WebKit nightly
builds print Print me, too.
Notably, we've seen different results in Firefox when printing file: vs. http:
On 5/8/11 12:11 AM, Ian Hickson wrote:
On Mon, 24 Jan 2011, Boris Zbarsky wrote:
https://bugzilla.mozilla.org/show_bug.cgi?id=627361
The conclusion seems to have been to attempt to keep the spec as it
stands, and try to get the remaining problems addressed via evangelism.
I approve
On 5/9/11 6:44 PM, Ian Hickson wrote:
For this reason I think we need to keep CanvasPixelArray distinct. I
certainly hope that Web IDL does not change its conversion rules to
mimic the clamping behavior in CanvasPixelArray. Right now Web IDL
delegates to the ECMA-262 specification for primitive
On 5/12/11 2:25 AM, Robert O'Callahan wrote:
On Thu, May 12, 2011 at 4:45 PM, Jer Noblejer.no...@apple.com wrote:
And your geolocation example actually argues the other way: the existing
geolocation API includes an asynchronous error handler that is explicitly
called when a request is denied.
On 5/12/11 3:24 AM, Jer Noble wrote:
A) If an author calls requestFullScreen(), at some point in the future they will receive either a
fullscreenchanged event or a fullscreendenied event.
B) If an author calls requestFullScreen(), at some point in the future they may receive a
On 5/12/11 3:54 AM, Jer Noble wrote:
No, that still doesn't make sense. At the time when the user decides to allow
or deny full screen access
The point is this may be never. They might just wake forever to make a
decision.
Saying that fullscreendenied will confuse users is akin to
On 5/12/11 4:12 AM, Jer Noble wrote:
- Add a new boolean Element property canRequestFullScreen. This would map to Firefox's
Never permission choice.
- Add the fullscreendenied event. This would map to Firefox's Not now
permission choice.
So if the user just dismisses the notification
On 5/12/11 12:48 PM, Jer Noble wrote:
I'm saying that if authors expect to get one or the other but then never do,
that will confuse authors.
Again, I fail to see how this is a problem for the denial event but not for the
change event.
The problem is not for any particular event. The
On 5/12/11 1:16 PM, Jer Noble wrote:
On May 12, 2011, at 5:47 AM, Boris Zbarsky wrote:
On 5/12/11 4:12 AM, Jer Noble wrote:
- Add a new boolean Element property canRequestFullScreen. This would map to Firefox's
Never permission choice.
- Add the fullscreendenied event. This would map
On 5/12/11 1:43 PM, Aryeh Gregor wrote:
On Thu, May 12, 2011 at 2:25 AM, Robert O'Callahanrob...@ocallahan.org wrote:
It seems rational to me: click on fullscreen, the video fills the entire
window (but not the screen), and some browser UI appears to suggest going
the rest of the way.
This
On 5/12/11 4:28 PM, Aryeh Gregor wrote:
* Firefox 4.0 just usesbr _moz_dirty= for Enter and Shift-Enter,
always. (What's _moz_dirty for?)
It's used when serializing: things with _moz_dirty are prettyprinted
even if the serialization is trying to preserve the original whitespace
layout of
On 5/12/11 6:15 PM, Jer Noble wrote:
I understand what you're saying. By making the error case deliberately
ambiguous, you're trying to force the author to behave in a certain way.
Not quite. I think Robert handled this in his response to this mail, so
I'll just stick to following that
On 5/12/11 8:29 PM, Aryeh Gregor wrote:
If we can figure out in advance what UIs browsers will want to use in
practice, though, that should inform what API we settle on.
Generality is not always good.
Yes.
If it turns out no one wants to ask the user before fullscreening
I'm 99% sure that
On 5/13/11 4:52 AM, Maciej Stachowiak wrote:
I'm not sure extensions like NoScript alone are sufficient reason to impose the
additional complexity required by a user prompting model.
My point was that someone authoring a browser intended to be more secure
against phishing attempts may want
On 5/13/11 12:14 PM, Aryeh Gregor wrote:
On Thu, May 12, 2011 at 5:15 PM, Tim Downtimd...@gmail.com wrote:
I did some simple tests yesterday that confirm that Gecko generally
acts only the first range, and was slightly surprised. I would expect
it to affect all ranges in the selection.
On 5/13/11 1:26 PM, Aryeh Gregor wrote:
So it's an attribute that affects serialization in a nonstandard way?
Far as I can tell, yes.
What sort of serialization does it affect?
Gecko has way too many serialization modes, most of them not web-exposed
(to support writing decent HTML editors
On 5/13/11 2:52 PM, Aryeh Gregor wrote:
Yes, I know. But the specific way Gecko handles multi-Range
Selections often doesn't make sense.
Oh, sure.
So if I get around to speccing all this, I'm going to spec something
in these cases that makes more sense than what Gecko does, since it's
not
On 5/13/11 3:26 PM, Aryeh Gregor wrote:
א --br-- ב
In IE and WebKit the arrows point right, in Gecko and Opera they point
left.
I _think_ we consider that a bug in Gecko.
Hmm, okay. So it's not an issue I have to care about. (Although of
course when I eventually write a real test suite,
On 5/13/11 3:45 PM, Ian Hickson wrote:
If the links open by default in the main content area, there's no need to
have an explicit way to do this, I guess. So I haven't added a term for this.
Note that the by default open in the main content area thing is not
spec-compliant at the moment, as
On 5/13/11 4:46 PM, Ian Hickson wrote:
The sum total of what the spec has to say on the matter is User agents
may support secondary browsing contexts, which are browsing contexts that
form part of the user agent's interface, apart from the main content
area; I think it's perfectly reasonable for
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 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 1.8.1
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 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 5/17/11 11:23 AM, Tab Atkins Jr. wrote:
On Tue, May 17, 2011 at 1:09 AM, Markus Ernstderer...@gmx.ch wrote:
Special cases:
- If the linked CSS document contains declarations for the body element,
they are applied to the contenteditable element itself. (This could be
necessary in case of
On 5/17/11 2:40 PM, Tab Atkins Jr. wrote:
Doesn't really matter to me; either seems sensical. :root has the
benefit of existing. ^_^
:scope has the benefit of making more sense (and happens to exist in my
tree, is used in the proposed selectors API, etc).
-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 5/18/11 6:57 PM, Tim Down wrote:
On 18 May 2011 19:32, Aryeh Gregorsimetrical+...@gmail.com wrote:
Another argument against wrapping whitespace is that it can have an
unwelcome visual effect if, for example, the wrapping elements have a
CSS border applied.
Borders only apply to boxes, and
On 5/26/11 12:53 PM, Ryosuke Niwa wrote:
And WebKit is also a part of Mac OS X framework and native applications that
use WebKit as
a part of their applications have no incentive to support Trident, Gecko, or
Opera behaviors.
I think this particular argument should have next to no weight when
On 5/26/11 1:25 PM, Ryosuke Niwa wrote:
On Thu, May 26, 2011 at 10:13 AM, Boris Zbarsky bzbar...@mit.edu
mailto:bzbar...@mit.edu wrote:
On 5/26/11 12:53 PM, Ryosuke Niwa wrote:
And WebKit is also a part of Mac OS X framework and native
applications that use WebKit
501 - 600 of 1308 matches
Mail list logo
