If you have a page like this:
!DOCTYPE HTML
htmlbody
font size=2 face=Verdana
p align=leftSome text
font size=2 face=Verdana
p align=leftSome text
/body/html
according to the HTML5 parser rules, I believe this should create a DOM with 3
font elements that looks something like this:
!DOCTYPE
On Mon, 12 Oct 2009 01:44:39 + (UTC), Ian Hickson i...@hixie.ch wrote:
On Tue, 6 Oct 2009, Kartikaya Gupta wrote:
[...]
Fixed the spec.
That works, thanks.
kats
On Wed, 07 Oct 2009 19:34:18 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/7/09 7:12 PM, Kartikaya Gupta wrote:
If a document is served as text/html, but contains an XML prolog with an
encoding attribute, it seems that all Firefox, Opera, and Chrome all pick
up the encoding from
On Wed, 07 Oct 2009 20:04 -0400 L. David Baron wrote:
Maybe you've configured UTF-8 as the fallback encoding? It's a preference
(and its default value varies between localizations).
Tools - Options - Content - Fonts Colors - Character Encoding
- Default Character Encoding. (For other
On Wed, 07 Oct 2009 20:23:35 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/7/09 7:51 PM, Kartikaya Gupta wrote:
I tried it again in Chrome and if I paste the above in the address bar I
get US-ASCII. But if I save it to a file and then load it I get UTF-8. I
checked the headers being
On Wed, 07 Oct 2009 21:35:00 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/7/09 9:29 PM, Kartikaya Gupta wrote:
Using document.inputEncoding:
http://stakface.com/pub/mango/fakexml.html
http://stakface.com/pub/mango/fakexml_iso.html
Using a degree symbol in UTF-8:
http
In this case, though, it's totally my fault: I just forgot that I had
the HTML5 parser turned on locally. Turning that off, I do get UTF-8,
because of
http://hg.mozilla.org/mozilla-central/file/603759afc77a/parser/htmlparser/src/nsParser.cpp#l2553
and following. That code is just
If we have this page:
htmlbody
input type=hidden value=foo id=i
script type=text/javascript
var i = document.getElementById('i');
i.value = 'bar';
alert( i.getAttribute('value') );
/script
/body/html
What should the alert display? From my reading of the spec I believe it should
display
It seems that most browsers do some sort of newline and tab removal from URI
attributes. For example, if you have
img src=foo
bar.jpg
browsers will still render the image called foobar.jpg despite the CRLF pair
in the middle of the src attribute. The behavior actually seems a bit more
The algorithm for stepUp() and stepDown() doesn't seem to take into account the
n parameter to those methods. The delta value used is the allowed step value;
shouldn't delta actually be the allowed step value multiplied by n? Or am I
missing something here?
Cheers,
kats
The description for what to do on setting valueAsNumber doesn't fully cover
error conditions. It's not clear to me, for instance, what's supposed if you
have an input type=date or type=number and try to set valueAsNumber to NaN.
The description there (for date) just says ... passing it a Date
James Graham wrote:
Is there any good reason to worry about languages other than javascript?
Writing APIs that work well in the one language implemnented in web
browsers seems better than writing mediocre APIs that can be used in
many other languages. I'm not sure what is needed for IDL
According to this section 9.4, any descendant text node of a style element
should be outputted literally, rather than being escaped. However, this doesn't
seem to match what Opera/Chrome/FF do. Test case:
html
body
style id=test
/style
script type=text/javascript
var test =
On Mon, 6 Jul 2009 09:02:51 + (UTC), Ian Hickson i...@hixie.ch wrote:
On Mon, 6 Jul 2009, Kartikaya Gupta wrote:
You've expressed something similar in a couple of the other threads as
well, and I find it puzzling. It's true that if you spec things that
will never be implemented
On Mon, 6 Jul 2009, Ian Hickson wrote:
On Mon, 6 Jul 2009, Robert O'Callahan wrote:
Specs do generate demand --- by creating author expectation that a
feature will be supported, by adding a well-known brand, and because
test suites get created which vendors then compete on.
On
On Mon, 6 Jul 2009 04:06:25 + (UTC), Ian Hickson i...@hixie.ch wrote:
On Mon, 6 Jul 2009, Kartikaya Gupta wrote:
Or do you think it is better to pick a side that has a good shot at
winning, even if it means that some vendors may be non-compliant with
the spec?
I think it would
There's a page
(http://www.microsoft.com/windowsmobile/mobile/en-us/totalaccess/software/software/eula-sw-netflix.mspx
specifically) that has a Content-Type header of text/html; charset=utf-16
and has no BOM. The references I've seen (RFC2781, as well as
I have a question about section 3.7.2. Under step 5, it says that it is
considered a reentrant invocation of parser if the document.write() method was
called from script executing inline. Does this include document.write() calls
invoked from user actions (e.g. onclick)? I assume not, but I'm
On Tue, 28 Apr 2009 01:15:30 + (UTC), Ian Hickson i...@hixie.ch wrote:
The behavior HTML5 requires is thus intentional for compat with IE.
We could avoid cloning quite as many by eating whitespace after a
table-related tag (tr, td, etc) by resetting the table taint flag at
those
I ran the spec through a typo-finder program I cooked up and it found these
among lots of false positives.
altogther (4.8.2.1.13)
approprate (5.8.4)
argments (4.8.11.1.10)
asychronously (5.8.4)
attribue's (2 in 4.6.12)
attrbutes (4.10.4)
constaints (4.10.14.2, 2 in 4.10.14.3)
elemnt (4.10.14.3)
On Fri, 27 Mar 2009 21:53:48 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
Kartikaya Gupta wrote:
The empty string falls under the anything else case in my suggestion
above and would work as you expect.
Null and empty string should, imo, have the same behavior here. It
doesn't make
On Thu, 26 Mar 2009 23:01:34 -0400, Biju bijumaill...@gmail.com wrote:
On Thu, Mar 26, 2009 at 5:26 PM, Kartikaya Gupta
This behavior seems rather inconsistent and possibly buggy.
At first look I also thought it is inconsistent
But later I found Firefox is very consistent.
I think reason
On Fri, 27 Mar 2009 14:14:35 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
This case is more fun. It's an unknown scheme, so it's assumed to be a
no-authority non-hierarchical scheme and the URI is parsed that way.
This does cause issues, since RFC 3986 says that i there is no authority
On Fri, 27 Mar 2009 17:40:08 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
Kartikaya Gupta wrote:
- Attempts to set pathname to null should throw, since the path is a
required
component of a URI. Setting pathname to anything else should be allowed
and
should update the path component
It seems that major browsers all support URL decomposition on
HTMLAnchorElement, but this doesn't seem to be stated anywhere in the HTML5
spec. The jQuery/tabs library seems to depend on this (specifically, on the
hash property) being available. Could the HTMLAnchorElement interface be
updated
Boris wrote:
If you specify the setters then you also need to specify how this
affects the value of the href attribute in the DOM. For example, in
Gecko if you have an a href=foo#bar which has base URI
http://example.com/; and you set anchor.hash on that anchor to baz,
then the attribute
I have a question about how formatting elements are reconstructed when dealing
with tainted tables. Specifically, the fine folks running westjet.com stuck
some malformed HTML on their site that I've boiled down to the following
snippet:
table
tr
a href=footd/a/td
td /td
/tr
/table
When
On Wed, 11 Feb 2009 15:03:01 -0800, Darin Adler da...@apple.com wrote:
On Feb 11, 2009, at 12:14 PM, Kartikaya Gupta wrote:
I updated to Safari 3.2 on Windows (which looks it also has WebKit
525.27.1) and you're right, it is now showing number instead of
object. I guess
On Thu, 12 Feb 2009 07:03:22 +0100, Simon Pieters sim...@opera.com wrote:
On Wed, 11 Feb 2009 21:14:44 +0100, Kartikaya Gupta
lists.weba...@stakface.com wrote:
I updated to Safari 3.2 on Windows (which looks it also has WebKit
525.27.1) and you're right, it is now showing number
On Thu, 12 Feb 2009 06:55:18 + (UTC), Ian Hickson i...@hixie.ch wrote:
Could you reannotate the above but with the script nesting level
explicitly given at each step?
Below is an updated annotation including all the script nesting level and
parser pause flag changes.
(Original
On Wed, 11 Feb 2009 10:06:14 -0800, Darin Adler da...@apple.com wrote:
However, when I do this:
var e = document.createEvent('Events');
alert( typeof e.timeStamp );
I get number in Opera and Firefox, and object in Webkit.
I get number in WebKit.
-- Darin
On Wed, 11 Feb 2009 10:58:00 -0800, Darin Adler da...@apple.com wrote:
On Feb 11, 2009, at 10:51 AM, Kartikaya Gupta wrote:
Interesting. What version did you try on? I used Chrome 1.0.154.48
and Safari 3.1 (525.13) on Windows.
The relevant version is the WebKit version rather than
I have a test case that works in major browsers (FF, Opera, Safari, IE6) but
that I don't think would work if the they followed the behavior as currently
specified in HTML5. I've put the test case online:
http://stakface.com/pub/mango/ext7.html
The assertion
On Mon, 12 Jan 2009 20:10:41 +, Kartikaya Gupta lists.wha...@stakface.com
wrote:
code is listed in the formatting category of elements, but isn't dealt with
in the same way as other
formatting elements when in the in body insertion mode. Currently it will
fall through to the any
I have a question about when scripts execute. From my reading of section 4.3.1
it seems like if script elements are created and added to the DOM via DOM
operations, then they should NOT be marked as parser-inserted, and should get
run immediately (assuming no defer/async stuff). However, a page
code is listed in the formatting category of elements, but isn't dealt with
in the same way as other formatting elements when in the in body insertion
mode. Currently it will fall through to the any other start tag case, so the
note in that case that says This element will be a phrasing element
Are there any plans to add the width/height attributes for the input element to
the HTML5 spec? It seems that all browsers (Opera, FF, Safari, IE) support
width/height on input type=image in both quirks and standards mode. There
are websites that depend on this behavior (the
On Tue, 23 Dec 2008 15:57:06 -0500, Douglas Mayle doug...@openplans.org wrote:
What's the problem with specifying that as style attributes?
I don't have a problem with it, and I think that's how authors should be doing
it. However, I thought HTML5 was supposed to be describing existing
On Wed, 24 Dec 2008 00:12:56 +0100, Anne van Kesteren ann...@opera.com
wrote:
Note that much of the obsolete stuff that browsers have to support is not
yet defined in detail, especially things that affect rendering.
Fair enough. Just wanted to make sure it wasn't getting forgotten.
For the steps under 'A start tag whose tag name is textarea' in 8.2.5.10 (in
body insertion mode), step 3 seems wrong to me, since step 1 already includes
an append operation. As specified now, it will cause two textarea elements to
be added (assuming new element refers to the textarea).
Section 8.2.4.1, for the '' input, says:
When the content model flag is set to either the RCDATA state or the CDATA
state and
the escape flag is false: switch to the tag open state.
I think the lack of commas in this sentence makes it ambiguous: it can either
be interpreted as (cmf ==
41 matches
Mail list logo
