On May 29, 2007, at 18:10, Maciej Stachowiak wrote:
I don't know of any ISO-8859 encodings requiring this, but for all
unicode encodings and numeric entity references compatibility
requires interpreting this range of code points in the WinLatin1 way.
Any test cases for the all unicode
On May 16, 2007, at 20:00, Geoffrey Sneddon wrote:
Including it in a few encoding detection algorithms is no big deal
on us implementers: as the spec stands we aren't required to
support it anyway. All the spec requires is that we include it
within our encoding detections (so, if we don't
On Mon, 04 Jun 2007 12:34:56 +0200, Henri Sivonen [EMAIL PROTECTED] wrote:
Including it in a few encoding detection algorithms is no big deal on
us implementers: as the spec stands we aren't required to support it
anyway. All the spec requires is that we include it within our encoding
Jerason Banes wrote:
That effectively restricts the storage to a single domain and is in line
with how cookies work today.
Yes, it does. But I don't think I have been insufficiently clear.
My issue is not with the idea of DOM Storage as a whole, but with the
idea of sharing information
Maciej Stachowiak wrote:
On Jun 1, 2007, at 6:03 PM, Ian Hickson wrote:
On Fri, 23 Mar 2007, Anne van Kesteren wrote:
Wouldn't it be better if no INDEX_SIZE_ERR was raised but instead the
previous value was retained? For consistency with
CanvasRenderingContext2D.globalAlpha for instance.
On Jun 4, 2007, at 14:17, Alexey Feldgendler wrote:
Also, even for those encodings for which a single-byte encoding
like Windows-1252 can be a reasonable fallback, it's doesn't seem
wise to me to mandate the use of Windows-1252 (or any other fixed
encoding) as the fallback. Some software,
On Mon, 04 Jun 2007 15:15:06 +0200, Henri Sivonen [EMAIL PROTECTED] wrote:
I think it is perfectly reasonable to make support for UTF-8 and
Windows-1252 part of UA conformance requirements. After all, a piece of
software that doesn't support those two really has no business
pretending to
On May 29, 2007, at 18:10, Maciej Stachowiak wrote:
I don't know of any ISO-8859 encodings requiring this, but for all
unicode encodings and numeric entity references compatibility
requires interpreting this range of code points in the WinLatin1 way.
I tested with Firefox 2.0.4, Minefield,
On 4 Jun 2007, at 7:14PM, Henri Sivonen wrote:
On May 29, 2007, at 18:10, Maciej Stachowiak wrote:
for all unicode encodings [...] compatibility requires interpreting [C1]
in the WinLatin1 way.
Only Safari 2.0.4 gives the DWIM treatment the C1 code point range
in UTF-8 and UTF-16.
What
Anne van Kesteren wrote:
On Thu, 31 May 2007 01:44:57 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
I would be hesitant to drop support for multiple bases in firefox
actually. Implementation wise it was very easy to implement, and it is
known that many pages out there break, though the
On Tue, 05 Jun 2007 00:23:54 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Please don't introduce more quirks mode nonsense. We have more than
enough already as it is.
I'm not saying that we should add it to the spec. I'm saying that
firefox might be able to remove support for the weird
2006/5/8, Arve Bersvendsen [EMAIL PROTECTED]:
Opera applies stylesheets with 'media=projection' when it goes in to
fullscreen (projection) mode, so in one sense the resulting document is
different. On the other hand, detecting this on resize is fairly trivially
acheived by checking the style of
On Tue, 27 Mar 2007, Kristof Zelechovski wrote:
I understand that the async attribute must depend on the src attribute
because it is needed and meaningful only when the script element is
loaded from an external source; however, the advantage of using the
defer attribute is not limited to
On Thu, 29 Mar 2007, Matthias Bauer wrote:
What about the DOMContentLoaded event? It is supported by Mozilla and,
apparently, Opera 9. Dean Edwards has a technique to make it work on IE,
and jQuery supports it on Safari [1].
Is there any chance DOMContentLoaded will be part of HTML5?
On
On 6/4/07, Jonas Sicking [EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
For .innerHTML = null Opera and Internet Explorer act as if the literal
string null was used. Firefox acts as if was used.
For .innerHTML = undefined Opera, Firefox and Internet Explorer act as
if the literal string
On 05/06/07, Michael A. Puls II [EMAIL PROTECTED] wrote:
On 6/4/07, Jonas Sicking [EMAIL PROTECTED] wrote:
I'd really dislike having to have this one property behave differently
than other text properties in the DOM. How do opera/ie deal with other
text properties like .src, .id,
On 05/06/07, Martijn [EMAIL PROTECTED] wrote:
So 'media=projection' == fullscreen mode?
In Opera yes.
I also noticed there is no fullScreen property to detect whether the
window is in full screen mode.
I see a potential, albeit small, problem here. What if a browser has
one full screen
On Jun 4, 2007, at 5:45 PM, liorean wrote:
On 05/06/07, Michael A. Puls II [EMAIL PROTECTED] wrote:
On 6/4/07, Jonas Sicking [EMAIL PROTECTED] wrote:
I'd really dislike having to have this one property behave
differently
than other text properties in the DOM. How do opera/ie deal with
On Sun, 15 Apr 2007, Geoffrey Garen wrote:
Some of the algorithms in this specification, for historical
reasons, require the user agent to pause until some condition has
been met. While a user agent is paused, it must ensure that no
scripts execute (e.g. no event handlers, no timers,
On Thu, 17 May 2007, Hallvord R M Steen wrote:
if WHATWG is defining document.activeElement, perhaps the WHAT spec
should match IE's behaviour more closely on some points. I refer to:
http://www.whatwg.org/specs/web-apps/current-work/#activeelement
* when the document is loaded, before
On Sat, 19 May 2007, Maciej Stachowiak wrote:
May I suggest reproposing [DOMContentLoaded] for DOM 3 Events, then,
since your former objection to it is withdrawn?
I can if you want, but I don't really see it as a feature that would be
expected in DOM3 Events. DOM Events defines the event
On Wed, 30 May 2007, Jonas Sicking wrote:
The reason I designed it this way was that it felt like the least
illogical behavior. In general a document behaves according to its
current DOM. I.e. it doesn't matter what the DOM looked like before, or
how it got to be in the current state, it
On Sat, 2 Jun 2007, Anne van Kesteren wrote:
* tabindex - tabIndex
Fixed.
* contenteditable - contentEditable
Fixed.
* The irrelevant DOM attribute currently doesn't link because
there's no dfn around its definition.
Fixed.
--
Ian Hickson U+1047E
On Fri, 1 Jun 2007, Maciej Stachowiak wrote:
I basically see two options: HTMLDocument.title always wins, and you
can get the other one using getFeature(), or, they both get redefined
to check the root element and dispatch to the other one if
appropriate. Suggestions?
I like the
24 matches
Mail list logo
