[whatwg] Spec error: UTF-16LE BOM for content-type sniffing

There seems to be a typo in the table used for the "unknown type" part of the content-type sniffing algorithm, as found at http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#content-type-sniffing:-unknown-type Specifically, the row with the comment "UTF-16LE BOM" list

[whatwg] "Official type" used before definition in spec

The "Web pages" part of the Content-Type sniffing algorithm[1] has a list of steps beginning: > 1. If the user agent is configured to strictly obey Content-Type >headers for this resource, then jump to the last step in this set >of steps. The last step in that list reads: > 8. The sniffe

Re: [whatwg] optgroup element used for selection

Randy Drielinger schrieb: Currently (HTML4.01) and in the near-future HTML5 spec optgroup elements are used to group options (hence the name :-) and amongst others allow us to disable a group of option elements at once. Personally, I think it would make sense to add the ability to make an opt

[whatwg] Nested optgroups

I found a message in the list archives from July 2004, where Ian announced to put nested optgroups back into the spec: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-July/001200.html Anyway in the current spec, the optgroup element is not allowed inside another optgroup element: http

Re: [whatwg] optgroup element used for selection

Personally i'd rather that a UA be able to choose to do this on its own. I don't think it requires a change to the specification. you're talking more about a behavior (clicking X triggers Y and Z) than how the web page sees what happened (either way it only sees triggers on Y and Z). I've actuall

Re: [whatwg] optgroup element used for selection

Markus Ernst schrieb: Randy Drielinger schrieb: Currently (HTML4.01) and in the near-future HTML5 spec optgroup elements are used to group options (hence the name :-) and amongst others allow us to disable a group of option elements at once. Personally, I think it would make sense to add the

Re: [whatwg] Spec error: UTF-16LE BOM for content-type sniffing

Thanks. This will be fixed in the next version of draft-abarth-mime-sniff. Adam On Mon, Apr 13, 2009 at 3:49 AM, Aaron Crane wrote: > There seems to be a typo in the table used for the "unknown type" part > of the content-type sniffing algorithm, as found at > > http://www.whatwg.org/specs/web

Re: [whatwg] "Official type" used before definition in spec

Thanks. I'll make this change in the next version of draft-abarth-mime-sniff. Adam On Mon, Apr 13, 2009 at 4:09 AM, Aaron Crane wrote: > The "Web pages" part of the Content-Type sniffing algorithm[1] has a > list of steps beginning: > >> 1. If the user agent is configured to strictly obey Cont

Re: [whatwg] Worker lifecycle

OK, here's a more focused question - let's imagine that one is implementing SharedWorkers in a new browser. One seemingly reasonable way to proceed would be to have a Worker stay alive as long as there are *any* reachable entangled ports between any window and that worker. Does this cause some kind

Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]

This e-mail is an attempt to give a relatively concise yet reasonably complete overview of non-Unicode character sets and encodings for `Chinese characters', excluding those which are not supported by at least one of the four browsers IE, Safari, Firefox and Opera (henceforth `all browsers'