Re: [css3-values] Browsers allow unitless lengths in quirks mode

On Thu, Feb 2, 2012 at 3:32 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> For what it's worth, the full list of CSS parser quirks-mode behaviors Gecko
> has is:
>
> 1) Unitless lengths allowed in longhands only.

What do you do about things like line-height?  Do you specifically
exempt them on a case-by-case basis, or is there some general rule
that suspends this quirk in places where both <length> and <number>
are accepted?

> 2) Hex colors without leading '#' allowed in longhands only.

It seems other browsers support both of these first two things in
shorthands too.  E.g.,

data:text/html,
<div style="height:100;width:100;background:50 50 00ff00">

"works" (displays a lime box) in IE10 Developer Preview, Chrome 18
dev, and Opera Next 12.00 alpha.  Are there specific cases you're
thinking of that might be ambiguous?  I don't see any cases offhand in
CSS2.1.

I guess there are no compat issues from your current behavior that you
know of?  Obviously we should try to get away with allowing quirks in
as few properties as possible, so if it works for Gecko . . .

> 3) Braces around the value of the "style" attribute allowed.

Quirk (3) appears to be supported by Opera, but not IE or WebKit.  Do
you know if it's really needed for compat?

On Fri, Feb 3, 2012 at 10:02 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> How much value is there in specifying crazy quirks-mode behavior and
> trying to get browsers consistent on it?

Given that browsers are already somewhat interoperable here, it seems
extremely likely to me that sites depend on this behavior or some
version of it.  So we need to spec it at some point.  It should be
particularly important to start speccing quirks now, because IE is
finally trying to align its quirks mode with other browsers.

> (I suspect that every single thing I'm interested in working on is
> higher-priority than this.)

Well, it depends on your priorities and interests, I guess.  I like
reverse-engineering, speccing, and testing existing browser behavior
much more than I like writing new features.  I'm not going to say you
have to work on it in the foreseeable future, but do make sure you
note it down somewhere so you or a co-editor or an eventual successor
will eventually look at it, and it won't just get forgotten.

(Where do you put this kind of thing, with no bug tracker?  Maybe a
note in the spec, or an issue or something?)

Received on Friday, 3 February 2012 16:55:52 UTC