Re: [whatwg] Quirks Mode Standard
On Mon, 20 Feb 2012 11:01:06 +0100, Simon Pieters sim...@opera.com wrote: ... The draft is now in a more complete state: all quirks have been specified. http://simon.html5.org/specs/quirks-mode -- Simon Pieters Opera Software
Re: [whatwg] Quirks Mode Standard
On Fri, 17 Feb 2012 15:45:37 +0100, Simon Pieters sim...@opera.com wrote:
I did some quick and dirty research on dotnetdotcom's web200904 data,
I also searched for braces in style attribute:
grep -iaPo [a-z]+\s[^]*style\s*=\s*[\']{[^\']+ web200904
style-braces.txt
6556 matches
WebKit and IE9 in non-compat view don't support this quirk.
Then I searched for space before unit:
$ grep -iaPo
([a-z]+-)*(position|spacing|width|bottom|clip|size|height|left|right|top|bottom|margin|padding|indent|align|width|end|start|columns|border|shadow)\s*:\s*-?([1-9][0-9]*(\.[0-9]+)?|[0-9]?\.[0-9]+)\s+(px|em|ex|cm|mm|in|pt|pc)
web200904 space-before-unit.txt
6265 matches
Firefox doesn't support this quirk. Opera used to, but we have now dropped
it because supporting it broke some sites.
Can we also drop the braces in style attribute quirk? (Note that the data
does not include external style sheets, so the second quirk might have
more usage than the first.)
http://simon.html5.org/specs/quirks-mode#the-braces-in-style-attribute-quirk
--
Simon Pieters
Opera Software
Re: [whatwg] Quirks Mode Standard
On Wed, 15 Feb 2012 19:42:39 +0100, Simon Pieters sim...@opera.com wrote:
I have changed the spec for hashless hex color and unitless length to be
closer to reality (I hope). I have limited the them to the properties in
CSS2.1 that have colors or lengths but aren't in the list above. I made
support hashless hex colors match IE instead of the other browsers,
since IE was stricter (even in compat view). I still haven't figured out
'font', but I'll get to it.
I did some quick and dirty research on dotnetdotcom's web200904 data, and
based on my findings, I removed outline-color, background-position,
border-spacing, bottom, font, max-height, max-width, min-height,
min-width, text-indent and vertical-align from the spec.
outline-color and font I found *no* occurrences that needed these quirks
(although I didn't run through the whole file when searching for 'font').
For the others, I applied an arbitrary threshold of usage and made cut-off
to make the list of properties a bit shorter.
Now follows the scripts I used and some notes.
$ grep -iaPo
([a-z]+-)?color\s*:\s*[0-9a-f]{3}([0-9a-f]{3})?(\s|\|\'|;|$) web200904
color.txt
f = open('color.txt', 'r')
props = {}
for line in f:
prop = line.split(':')[0].rstrip().lower()
if prop in props:
props[prop] += 1
else:
props[prop] = 1
f.close()
for prop in props:
print prop + ':' + str(props[prop])
:28
border-color:2515
color:40731
backgound-color:1
backgroun-color:13
dshadow-color:1
nbackground-color:6
00;:1
shadow-color:242
face-color:230
text-color:2
dlight-color:216
bottom-color:543
tbackground-color:1
highlight-color:239
arrow-color:228
right-color:326
top-color:304
track-color:272
left-color:330
background-color:8658
font-color:73
darkshadow-color:217
base-color:85
light-color:15
Obviously I made a mistake in the regexp and so e.g. border-right-color
shows up as right-color.
Other than typos and scrollbar-* properties, the ones that are used are
the ones that are specced.
In particular, outline-color did not show up at all.
$ grep -iaPo
([a-z]+-)*(position|spacing|width|bottom|clip|size|height|left|right|top|bottom|margin|padding|indent|align|width|end|start|columns|border|shadow)\s*:\s*([1-9][0-9]*(\.[0-9]+)?|[0-9]?\.[0-9]+)(\s|\|\'|;|$|\/|)
web200904 lengths.txt
^C
(see script in hex color quirk section)
:315
x-start:2
3.00:1
pagging-left:8
min-height:38
border-top:842
v-text-spacing:1
2:1
scrollbar-size:2
line-width:1
24;:1
border-right:1100
columns:5
border-bottom:1725
border-spacing:7
21:1
shadow:3
text-align:8
1/:1
e-height:1
8.75:1
750:1
xxpadding-top:2
marging-bottom:2
line-spacing:7
x-archive-position:1
line-height:7209
5:1
font-size:35296
right:1226
cell-spacing:2
100:1
908:1
word-spacing:381
mso-columns:2
padding-top:8168
border-left-size:1
scrollbar-border:2
bottom:101
fp-font-size:362
mmargin-left:1
padding-right:9159
7:1
text-size:2
spacing:243
xxpadding-left:2
tab-width:8
max-width:285
30:1
paddin-top:1
content-size:1
border-right-width:1891
y-position:1
w:1
padding-left:16898
1.50:1
6':1
border-bottom-width:3505
height:31132
max-height:95
margin-right:8283
border-top-width:2438
size:5022
left-margin:1
start:49
bottom-margin:1
top:10483
border-width:5602
min-width:219
width:46530
background-position:135
border-left:887
padding:18278
2:1
border-height:31
5:1
margin:5331
border-left-width:2384
letter-spacing:874
vertical-align:47
clip:5
0.0:1
margin-left:11565
padding-bottom:5279
week-end:1
border:4664
end:68
installed-size:1
margin-bottom:11898
lin-height:12
102:1
4:1
nfont-size:10
z-position:1
text-indent:378
midlet-jar-size:1
one-day-left:1
margin-top:11393
position:80
left:9219
Forgot to include - before the number in the regex (e.g. text-indent
accepts negative values).
$ grep -iaPo
([a-z]+-)*(position|spacing|width|bottom|clip|size|height|left|right|top|bottom|margin|padding|indent|align|width|end|start|columns|border|shadow)\s*:\s*-([1-9][0-9]*(\.[0-9]+)?|[0-9]?\.[0-9]+)(\s|\|\'|;|$|\/|)
web200904 negative-lengths.txt
^C
(see script in hex color quirk section)
:1
letter-spacing:31
right:3
bottom:2
top:56
margin-right:4
padding-left:1
margin-bottom:33
word-spacing:1
margin-top:68
margin-left:61
padding-top:1
size:2
margin:6
left:16
'clip'
$ grep -iaPo clip\s*:\s*rect\([^\)]+\) web200904 clip.txt
^C
Looks like 'clip' is used with and without commas, with and without units.
'font'
$ grep -iaPo font\s*:\s*[^;\}]+ web200904 font.txt
^C
I appended
Re: [whatwg] Quirks Mode Standard
On Mon, 13 Feb 2012 13:38:49 +0100, L. David Baron dba...@dbaron.org wrote: On Monday 2012-02-13 09:00 +0100, Simon Pieters wrote: Exactly. My proposal, again, is that neither of these quirks apply inside a shorthand. But this is not what Gecko does. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1339 I don't know how much content uses unitless lengths or hashless colors in shorthands in quirks mode. We will need to research both implementations and content to inform what the spec should say here, I think. To be exact, they don't apply inside the following shorthands: -moz-border-end -moz-border-start -moz-columns background border border-bottom border-image border-left border-right border-top the size/weight/style and family parts of 'font' list-style outline and also don't apply inside the following complex properties: box-shadow text-shadow I suspect that the bit that was documenting an exception for font-size was documenting the exception (that the quirk *does* apply) for *within* the 'font' shorthand. I have changed the spec for hashless hex color and unitless length to be closer to reality (I hope). I have limited the them to the properties in CSS2.1 that have colors or lengths but aren't in the list above. I made support hashless hex colors match IE instead of the other browsers, since IE was stricter (even in compat view). I still haven't figured out 'font', but I'll get to it. cheers -- Simon Pieters Opera Software
Re: [whatwg] Quirks Mode Standard
On Fri, 10 Feb 2012 16:37:24 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 2/10/12 2:57 AM, Simon Pieters wrote: 1) I'm fairly certain the Images (img elements) without alt attributes sometimes display placeholder icons in quirks mode. quirk cannot be dropped. ... The HTML specification specifies this quirk in the Rendering section. http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#images-0 Ah, excellent. ;) 4) The CSS parsing quirks need to define behavior for shorthands. Other than the behavior for 'font' (assuming 'font-size' is on the list), what's missing? (My idea was that shorthands that reference other properties (or value productions from other properties) in their Value: specification would automatically support unitless lengths, e.g. 'background' where only position gets rewritten to use quirklength because 'background-position' is in the list but 'background-size' is not.) I agree that having the list for lengths reduces the scope of the problem somewhat. But the color quirk means that any shorthand that includes colors will run into ambiguity issues if any keywords for any subproperty only use letters in the range a-f. I _think_ we can't hit that case now, but going forward that will either place a restriction on keyword values or we'll need to define how to resolve the ambiguity somehow. Even for lengths, if we ever add any new subproperties to border, say, that happen to take numbers we would run into trouble. I'd rather not overconstrain future development of CSS by how we define quirks behavior. So I would prefer to avoid the problem as Gecko does, frankly. Of course I'm biased. ;) This discussion is probably worth taking to www-style. It's interesting that 'font-size' is not in the list I trusted https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior which says The CSS parser interprets unitless numbers as px (except for font-size because that was what Netscape Navigator 4 did :-) Huh. That's a blatant lie! I fixed the page. Now added, but I'm not sure right now how to spec how the 'font' shorthand is handled. Exactly. My proposal, again, is that neither of these quirks apply inside a shorthand. But this is not what Gecko does. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1339 I don't know how much content uses unitless lengths or hashless colors in shorthands in quirks mode. We will need to research both implementations and content to inform what the spec should say here, I think. -- Simon Pieters Opera Software
Re: [whatwg] Quirks Mode Standard
On Monday 2012-02-13 09:00 +0100, Simon Pieters wrote: Exactly. My proposal, again, is that neither of these quirks apply inside a shorthand. But this is not what Gecko does. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1339 I don't know how much content uses unitless lengths or hashless colors in shorthands in quirks mode. We will need to research both implementations and content to inform what the spec should say here, I think. To be exact, they don't apply inside the following shorthands: -moz-border-end -moz-border-start -moz-columns background border border-bottom border-image border-left border-right border-top the size/weight/style and family parts of 'font' list-style outline and also don't apply inside the following complex properties: box-shadow text-shadow I suspect that the bit that was documenting an exception for font-size was documenting the exception (that the quirk *does* apply) for *within* the 'font' shorthand. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] Quirks Mode Standard
On Mon, 13 Feb 2012 13:38:49 +0100, L. David Baron dba...@dbaron.org wrote: On Monday 2012-02-13 09:00 +0100, Simon Pieters wrote: Exactly. My proposal, again, is that neither of these quirks apply inside a shorthand. But this is not what Gecko does. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1339 I don't know how much content uses unitless lengths or hashless colors in shorthands in quirks mode. We will need to research both implementations and content to inform what the spec should say here, I think. To be exact, they don't apply inside the following shorthands: -moz-border-end -moz-border-start -moz-columns background border border-bottom border-image border-left border-right border-top the size/weight/style and family parts of 'font' list-style outline and also don't apply inside the following complex properties: box-shadow text-shadow I suspect that the bit that was documenting an exception for font-size was documenting the exception (that the quirk *does* apply) for *within* the 'font' shorthand. -David Thanks! You say that it doesn't apply for the size of 'font'. The link above uses font:60 serif and has a 60px font size in Firefox Nightly for me. These also get applied: font:101 serif font:100 60 serif font:100 100 serif font:bold 100 serif font:normal normal normal 100 serif These don't: font:100 serif font:100/1 serif font:normal 100 serif font:normal normal 100 serif -- Simon Pieters Opera Software
Re: [whatwg] Quirks Mode Standard
On Monday 2012-02-13 14:03 +0100, Simon Pieters wrote: You say that it doesn't apply for the size of 'font'. The link above uses font:60 serif and has a 60px font size in Firefox Nightly for me. These also get applied: font:101 serif font:100 60 serif font:100 100 serif font:bold 100 serif font:normal normal normal 100 serif These don't: font:100 serif font:100/1 serif font:normal 100 serif font:normal normal 100 serif I believe they don't because the '100' gets consumed as a valid value of font-weight (since the shorthand parser assumes there's no ambiguity to be handled between font-weight and font-size), and then the shorthand is syntactically invalid because it doesn't have a font-size. I don't see any reason to fix that. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] Quirks Mode Standard
On 2/13/12 3:00 AM, Simon Pieters wrote: Exactly. My proposal, again, is that neither of these quirks apply inside a shorthand. But this is not what Gecko does. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1339 As I said earlier, I have no idea what's going on with 'font' specifically there. It looks like it's only being treated as a shorthand after we've already parsed the size... David might know what's going on with that. -Boris
Re: [whatwg] Quirks Mode Standard
On Friday 2012-02-10 10:37 -0500, Boris Zbarsky wrote: I agree that having the list for lengths reduces the scope of the problem somewhat. But the color quirk means that any shorthand that includes colors will run into ambiguity issues if any keywords for any subproperty only use letters in the range a-f. I _think_ we can't hit that case now, but going forward that will either place a restriction on keyword values or we'll need to define how to resolve the ambiguity somehow. For the record, Gecko doesn't implement any CSS keywords or units that contain only the characters a-f (treating any -moz- prefixes as not present). However, if I double the search range to a-l, then Gecko implements the following units: ch deg and the following keywords: all cell deck field fill hide So I don't think it's an unrealistic worry that we might have some such keywords in the future. (Consider, for example, 'fade'.) More importantly, though, if Gecko encounters an ambiguity between color and keyword in a property that accepts both, it will pick the keyword. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] Quirks Mode Standard
On 2/10/12 2:57 AM, Simon Pieters wrote: 1) I'm fairly certain the Images (img elements) without alt attributes sometimes display placeholder icons in quirks mode. quirk cannot be dropped. ... The HTML specification specifies this quirk in the Rendering section. http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#images-0 Ah, excellent. ;) 4) The CSS parsing quirks need to define behavior for shorthands. Other than the behavior for 'font' (assuming 'font-size' is on the list), what's missing? (My idea was that shorthands that reference other properties (or value productions from other properties) in their Value: specification would automatically support unitless lengths, e.g. 'background' where only position gets rewritten to use quirklength because 'background-position' is in the list but 'background-size' is not.) I agree that having the list for lengths reduces the scope of the problem somewhat. But the color quirk means that any shorthand that includes colors will run into ambiguity issues if any keywords for any subproperty only use letters in the range a-f. I _think_ we can't hit that case now, but going forward that will either place a restriction on keyword values or we'll need to define how to resolve the ambiguity somehow. Even for lengths, if we ever add any new subproperties to border, say, that happen to take numbers we would run into trouble. I'd rather not overconstrain future development of CSS by how we define quirks behavior. So I would prefer to avoid the problem as Gecko does, frankly. Of course I'm biased. ;) This discussion is probably worth taking to www-style. It's interesting that 'font-size' is not in the list I trusted https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior which says The CSS parser interprets unitless numbers as px (except for font-size because that was what Netscape Navigator 4 did :-) Huh. That's a blatant lie! I fixed the page. Now added, but I'm not sure right now how to spec how the 'font' shorthand is handled. Exactly. My proposal, again, is that neither of these quirks apply inside a shorthand. -Boris
Re: [whatwg] Quirks Mode Standard
On Fri, Feb 10, 2012 at 10:37 AM, Boris Zbarsky bzbar...@mit.edu wrote: I agree that having the list for lengths reduces the scope of the problem somewhat. But the color quirk means that any shorthand that includes colors will run into ambiguity issues if any keywords for any subproperty only use letters in the range a-f. I _think_ we can't hit that case now, but going forward that will either place a restriction on keyword values or we'll need to define how to resolve the ambiguity somehow. Even for lengths, if we ever add any new subproperties to border, say, that happen to take numbers we would run into trouble. I'd rather not overconstrain future development of CSS by how we define quirks behavior. Why not just say that these quirks only apply to existing syntaxes, not new ones? I was quite surprised to find that unitless numbers worked for 'transform-origin' in quirks mode.
Re: [whatwg] Quirks Mode Standard
On 2/10/12 11:23 AM, Aryeh Gregor wrote: On Fri, Feb 10, 2012 at 10:37 AM, Boris Zbarskybzbar...@mit.edu wrote: I agree that having the list for lengths reduces the scope of the problem somewhat. But the color quirk means that any shorthand that includes colors will run into ambiguity issues if any keywords for any subproperty only use letters in the range a-f. I _think_ we can't hit that case now, but going forward that will either place a restriction on keyword values or we'll need to define how to resolve the ambiguity somehow. Even for lengths, if we ever add any new subproperties to border, say, that happen to take numbers we would run into trouble. I'd rather not overconstrain future development of CSS by how we define quirks behavior. Why not just say that these quirks only apply to existing syntaxes, not new ones? Simon's proposal does that, but it's not good enough to avoid all the problems. For example, border-bottom-width is in the list of properties that has the quirk apply to it, as is border-bottom. If we add a border-bottom-count property for some sort of multiple border setup and allow setting it via border-bottom, then you suddenly have a parsing ambiguity for border-bottom, right? -Boris
[whatwg] Quirks Mode Standard
Hi Today I started working on a spec for quirks mode. I used https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior as a starting point. The draft is here: http://simon.html5.org/specs/quirks-mode It is very likely that more quirks need to be added, but as I went through the list I was surprised about how many of them were *not* widely implemented across browsers, and so may not be needed for Web compat and can be dropped. I'm happy for the spec to be moved somewhere, and I can volunteer to edit it, but I can't promise to spend a lot of time on it. It would be useful if browser implementors could review the draft, consider dropping quirks, give feedback about quirks that can't be dropped, and consider aligning with other implementations for quirks that are here to stay. cheers -- Simon Pieters Opera Software
Re: [whatwg] Quirks Mode Standard
On Thursday 2012-02-09 15:51 +0100, Simon Pieters wrote: Today I started working on a spec for quirks mode. I used https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior as a starting point. The draft is here: http://simon.html5.org/specs/quirks-mode I'd note that the item All of the style rules in layout/style/quirk.css apply. probably needs to be expanded, and items analyzed individually. It is very likely that more quirks need to be added, but as I went through the list I was surprised about how many of them were *not* widely implemented across browsers, and so may not be needed for Web compat and can be dropped. I'm happy for the spec to be moved somewhere, and I can volunteer to edit it, but I can't promise to spend a lot of time on it. It would be useful if browser implementors could review the draft, consider dropping quirks, give feedback about quirks that can't be dropped, and consider aligning with other implementations for quirks that are here to stay. I'd note that there are sometimes messy interactions between behaviors. For example, if my memory is correct, implementing the HTML5 parsing algorithm required that we implement a text-decoration quirk that we previously didn't have (but WebKit did), as described in https://bugzilla.mozilla.org/show_bug.cgi?id=572713 . (Speaking of which, I'm curious why that quirk, on propagation of text-decoration into tables, didn't make it from the developer.mozilla.org URL you gave into your document. That makes me think the document isn't quite ready for review yet.) There may be cases where only some browsers have a described quirk, but other browsers have a different behavior that provides the same compatibility. That said, I agree it's likely that many of the quirks can be removed. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] Quirks Mode Standard
On Thu, 09 Feb 2012 19:15:43 +0100, L. David Baron dba...@dbaron.org wrote: On Thursday 2012-02-09 15:51 +0100, Simon Pieters wrote: Today I started working on a spec for quirks mode. I used https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior as a starting point. The draft is here: http://simon.html5.org/specs/quirks-mode I'd note that the item All of the style rules in layout/style/quirk.css apply. probably needs to be expanded, and items analyzed individually. Sure. I think however that that has partially already been done as part of Hixie writing HTML's Rendering section, and so is probably out of scope for this document. It is very likely that more quirks need to be added, but as I went through the list I was surprised about how many of them were *not* widely implemented across browsers, and so may not be needed for Web compat and can be dropped. I'm happy for the spec to be moved somewhere, and I can volunteer to edit it, but I can't promise to spend a lot of time on it. It would be useful if browser implementors could review the draft, consider dropping quirks, give feedback about quirks that can't be dropped, and consider aligning with other implementations for quirks that are here to stay. I'd note that there are sometimes messy interactions between behaviors. For example, if my memory is correct, implementing the HTML5 parsing algorithm required that we implement a text-decoration quirk that we previously didn't have (but WebKit did), as described in https://bugzilla.mozilla.org/show_bug.cgi?id=572713 . (Speaking of which, I'm curious why that quirk, on propagation of text-decoration into tables, didn't make it from the developer.mozilla.org URL you gave into your document. That makes me think the document isn't quite ready for review yet.) It's in a comment in the source. I noticed that it was missing in HTML's Rendering section and filed a bug. https://www.w3.org/Bugs/Public/show_bug.cgi?id=15941 There may be cases where only some browsers have a described quirk, but other browsers have a different behavior that provides the same compatibility. Yeah. In such cases, we need to pick one quirk and spec that. That said, I agree it's likely that many of the quirks can be removed. One form of removing quirks is to propagate them to also apply in standards mode, which is doable if standards mode Web content doesn't rely on the quirk being *absent*, and is something the HTML spec has done for many things (e.g. parsing of legacy colors). -David -- Simon Pieters Opera Software
Re: [whatwg] Quirks Mode Standard
On 2/9/12 9:51 AM, Simon Pieters wrote: It is very likely that more quirks need to be added, but as I went through the list I was surprised about how many of them were *not* widely implemented across browsers, and so may not be needed for Web compat and can be dropped. It's worth keeping in mind that the IE9 mode relevant for quirks web compat is the compat view quirks mode, as far as I can tell... It would be useful if browser implementors could review the draft, consider dropping quirks, give feedback about quirks that can't be dropped, and consider aligning with other implementations for quirks that are here to stay. 1) I'm fairly certain the Images (img elements) without alt attributes sometimes display placeholder icons in quirks mode. quirk cannot be dropped. The real point of that quirk is that this markup: img width=100 height=100 src=404.html which links to some non-existent image needs to result in a box of width 100 and height 100 in quirks mode; not doing that breaks all the various pages that (still) use spacer gifs pointing to bogus URIs. I believe some UAs have this behavior in all modes; in Gecko the behavior is restricted to quirks mode. 2) The fixed width specified on a table cell resets the nowrap attribute. quirk seems to be implemented by everyone, effectively. I would be really surprised if it can be dropped. 3) Likewise for the tables with no rows/rowgroups have zero height even when a height is specified quirk. 4) The CSS parsing quirks need to define behavior for shorthands. How was the list of properties for the unitless px quirk generated, by the way? It's interesting that 'font-size' is not in the list -Boris
Re: [whatwg] Quirks Mode Standard
On Fri, 10 Feb 2012 08:18:40 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 2/9/12 9:51 AM, Simon Pieters wrote: It is very likely that more quirks need to be added, but as I went through the list I was surprised about how many of them were *not* widely implemented across browsers, and so may not be needed for Web compat and can be dropped. It's worth keeping in mind that the IE9 mode relevant for quirks web compat is the compat view quirks mode, as far as I can tell... OK. It would be useful if browser implementors could review the draft, consider dropping quirks, give feedback about quirks that can't be dropped, and consider aligning with other implementations for quirks that are here to stay. 1) I'm fairly certain the Images (img elements) without alt attributes sometimes display placeholder icons in quirks mode. quirk cannot be dropped. The real point of that quirk is that this markup: img width=100 height=100 src=404.html which links to some non-existent image needs to result in a box of width 100 and height 100 in quirks mode; not doing that breaks all the various pages that (still) use spacer gifs pointing to bogus URIs. I believe some UAs have this behavior in all modes; in Gecko the behavior is restricted to quirks mode. The HTML specification specifies this quirk in the Rendering section. http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#images-0 2) The fixed width specified on a table cell resets the nowrap attribute. quirk seems to be implemented by everyone, effectively. I would be really surprised if it can be dropped. IE9 in non-compat view doesn't have it. OK, so then either we limit this to quirks mode like Opera/Gecko or we also do it in standards mode like WebKit/IE9 compat view. 3) Likewise for the tables with no rows/rowgroups have zero height even when a height is specified quirk. OK. 4) The CSS parsing quirks need to define behavior for shorthands. Other than the behavior for 'font' (assuming 'font-size' is on the list), what's missing? (My idea was that shorthands that reference other properties (or value productions from other properties) in their Value: specification would automatically support unitless lengths, e.g. 'background' where only position gets rewritten to use quirklength because 'background-position' is in the list but 'background-size' is not.) How was the list of properties for the unitless px quirk generated, by the way? I went through CSS2.1's property index manually. It's interesting that 'font-size' is not in the list I trusted https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior which says The CSS parser interprets unitless numbers as px (except for font-size because that was what Netscape Navigator 4 did :-) Now added, but I'm not sure right now how to spec how the 'font' shorthand is handled. -Boris Thanks! -- Simon Pieters Opera Software
