whatwg / quirks Goto Github PK

View Code? Open in Web Editor NEW

27.0 17.0 16.0 713 KB

Quirks Mode Standard

Home Page: https://quirks.spec.whatwg.org/

License: Other

Makefile 0.70% HTML 99.30%

quirks whatwg standard

quirks's People

Contributors

Stargazers

Watchers

Forkers

kleopatra999 omunroe-com dalavancloud rakina alexander1984z 0xrustlang danmulvey andreubotella global-localhost global19 global19-atlassian-net oflenake is2ei seanpm2001 seanwallawalla-forks surfndez adammcclure

quirks's Issues

Percentage height calculation quirk does not seem to match implementations

The percentage height calculation quirk seems to use the initial containing block for the containing block. But actual implementations do something where they take the margins and padding of the <body> and <html> into account, as far as I can tell. This section probably needs more testing of what the actual browser behavior is, especially since some of the tests for this part of the spec are not passed by any browser per https://wpt.fyi/results/quirks/percentage-height-calculation.html

Quirky color in @supports without quirks mode

https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk

This quirk must apply inside an @supports at-rule.

Is it intended that this quirk applies inside @supports even if the document is not in quirks mode? Compare with:

In quirks mode, the following properties must […]

Should there be a quirk for the label attribute of `<option>`?

Chrome and Safari don't seem to support <option label> in quirks mode. Haven't checked limited-quirks mode...

Possibly missing quirk: "collapse top margin of BODY and TD and bottom margin of TD"

The title is what Gecko’s user-agent stylesheet calls it:

http://searchfox.org/mozilla-central/rev/944f87c575e8a0bcefc1ed8efff10b34cf7a5169/layout/style/res/quirk.css#63-152

Compare:

data:text/html,<h1>Test
data:text/html,<!doctype html><h1>Test

The latter has a top margin, but not the former.

Servo issue: servo/servo#14947

Blink implements it differently: servo/servo#14947 (comment)

Quirky colors not defined

@zcorpan #64 fails CI due to this term not being defined. Thoughts?

spec for comparing class names

Hi,

I found in DOM Living Standards the spec about comparison of class names on quirks mode.
https://dom.spec.whatwg.org/#concept-getelementsbyclassname

What about mentioning it in the quirks spec?

Those who wanna know about browsers' behavior on quirks mode may read the quirks spec. Actually, when I searched "spec for quirks mode", I found it. But they perhaps won't try to also check the dom living standards out.
So I think it would be nice to put the spec of comparison of class names on the spec of quirks mode.

Thank you for reading😊

Should we do percentage height quirk for calc()?

The spec applies percentage height quirk only when

... the specified value for the height property of element is a <percentage>, ...

which means we should apply the quirk for % heights but shouldn't for calc(length + %) heights.

Currently, only Firefox does that. Chrome, EdgeHTML and Safari apply the quirk also on calc() heights.

Should we change the spec to match the behavior of Chrome & Edge & Safari?

Also @bfgeek @bzbarsky @lilles from the related Chromium bug https://crbug.com/388892

List item forces strict line height

It seems that all browsers agree that list items disable the line height quirk [1] on ALL lines. I'm guessing this was added to make sure that there always be room for the list item marker, although that doesn't really explain why it should be like this on every line in the list item. Doing it on the first line (where the list item marker is) would have been good enough.

One implementation difference: Gecko triggers on HTML LI elements, while the others trigger on CSS display:list-item

Example:

<!-- quirks mode -->
<p>There should be a filled green square below, and no red.</p>
<div style="width:100px; height:100px; background:red;">
  <li style="line-height:50px; color:green; background:green;">
    <br>
    <div style="display:inline-block; width:1px; height:1px;"></div>
  </li>
</div>

Try changing from LI to DIV and observe the changes.

[1] https://quirks.spec.whatwg.org/#the-line-height-calculation-quirk

Change percentage height calculation quirk for flex and grid items

See w3c/csswg-drafts#5545 (comment) and https://bugzilla.mozilla.org/show_bug.cgi?id=1687557#c5

cc @dholbert @Loirooriol

Check quirks' behavior in vertical writing modes

Currently
https://quirks.spec.whatwg.org/#the-html-element-fills-the-viewport-quirk
and
https://quirks.spec.whatwg.org/#the-body-element-fills-the-html-element-quirk
consider writing modes (but possibly badly, in particular if html and body have different writing modes)

but the rest of the quirks have not been tested in vertical writing modes. Need to test what browsers do and possibly update the spec to match the majority, or what makes most sense if there's no interop.

cc @litherum

Disable percentage height quirk at flex/grid containers?

https://quirks.spec.whatwg.org/#the-percentage-height-calculation-quirk

The spec currently suggests that we "maybe [should] bail" for grids. Blink already does this, and is going to do the same for flex containers with https://chromium-review.googlesource.com/c/chromium/src/+/1459643 (EdgeHTML and Gecko already do it).

Can we clarify this behavior?

Upstreaming unitless length quirk to CSS

https://quirks.spec.whatwg.org/commit-snapshots/a71b2bf7dff6f32f7f66edbafe016d824ff2100f/#the-unitless-length-quirk

Per w3c/csswg-drafts#6100 we've upstreamed the definition of <quirky-length> to CSS Values and Units Level 4: https://www.w3.org/TR/css-values-4/#deprecated-quirky-length

If the result looks good, the spec can replace the corresponding section with a reference to V&U.

Simplifying the hover and active quirks?

What is the issue with the Quirks Mode Standard?

https://quirks.spec.whatwg.org/#the-active-and-hover-quirk has a list of conditions that doesn't keep up with new CSS features.

It seems implementations do subtly different things that end up in subtle bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=1856285:

I think Blink's behavior (which if I understand correctly is "only apply the quirk if the only thing in the selector is :hover or :active and it's not nested) is simpler, and I think we should change the spec to match that, if my understanding is correct.

@lilles / @andruud: Could you confirm my read of Blink's source is correct?
@annevk: Would WebKit be fine with that change? If so I'd be happy to send a PR.

cc @whatwg/css, I assume making stuff less quirky is generally good if we can get away with it...

Integrate with css-tables spec

https://quirks.spec.whatwg.org/#the-percentage-height-calculation-quirk
https://quirks.spec.whatwg.org/#the-table-cell-width-calculation-quirk
https://quirks.spec.whatwg.org/#the-table-cell-nowrap-minimum-width-calculation-quirk

Should specify the table quirks in terms of https://drafts.csswg.org/css-tables/ (does it define how percentage heights for table cells are calculated now?)

cc @gregwhitworth @FremyCompany

Document the table-cell-eats-margins quirk

Testcase:

<table border>
<td><h1>foo</h1><h2>bar</h2><p>baz
</table>

The h1's top margin and the p's bottom margin both get "eaten". This works in both Firefox and Chrome (didn't test others).

Wrinkles: a manually specified margin does not get eaten:

<table border>
<td><h1 style="margin-top:1em">foo</h1><h2>bar</h2><p>baz
</table>

"otherwise margins it be the sum"

https://quirks.spec.whatwg.org/commit-snapshots/cb6144cca6722f8c669539633af6d4015cb8fb08/#ref-for-vertical-writing-mode④

otherwise margins it be the sum

should be "otherwise let margins be the sum"

Revisit if "document's body element" matches impl

https://quirks.spec.whatwg.org/commit-snapshots/cb6144cca6722f8c669539633af6d4015cb8fb08/#ref-for-documents-body-element①

See web-platform-tests/wpt#9628

Replaced content percentage height resolution inside tables

There's an undocumented quirk regarding percentage block-size replaced elements inside table cells. This quirk is implemented by EdgeHTML, Chromium, and WebKit (but not Gecko, it seems, at least not with the test I'm presenting here):

<!-- quirks mode -->
<style>
  .cell {
    display: table-cell;
    width: 400px;
    height: 400px;
    background: red;
  }

  .descendant {
    display: block;
    margin: 0;
    border: none;
    padding: 0;
    width: 100%;
    height: 100%;
    background: green;
  }
</style>

<p>Green square below?</p>
<div class="cell">
  <div>
    <iframe class="descendant"></iframe>
  </div>
</div>

The percentage height specified on .cell is used to resolve the height of .descendant. This doesn't happen if .descendant is a DIV instead of an IFRAME.

This quirk is not documented at https://quirks.spec.whatwg.org/

Mention code of conduct in README

See HTML for examples.

Change percentage height calculation quirk to be explicit about writing modes

See https://bugzilla.mozilla.org/show_bug.cgi?id=1687557#c12

The text in the spec

This quirk needs to take writing modes into account.

was intended to be an inline issue note (it has class="big-issue"), but the styling disappeared at some point.

cc @MatsPalmgren @dholbert

Update tests for "html and body elements fill the viewport" spec change

Need to update http://w3c-test.org/quirks-mode/percentage-height-calculation.html

to test for this spec change: c81e2a2

commit c81e2a263fb9f89fdfc55010afe666f1711540b7
Author: Simon Pieters <[email protected]>
Date:   Tue May 3 17:43:01 2016 +0200

    Specify how html and body elements fill the viewport
    
    WebKit, Chromium and Edge implement this quirk. The spec was
    previously using Gecko's approach, but now Gecko wants to copy
    this quirk [1]. I based the spec on Chromium's implementation and
    tested in Chromium and Edge.
    
    The spec is stricter than browsers in that it requires the
    document element to be an html element, and it requires the
    body element to be "the document's body element" (as opposed to
    any body), to be consistent with e.g. 'background-color' on body.
    
    Chromium and Edge are inconsistent in their behavior when html
    and body have different writing modes:
    http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4149
    
    Other tests:
    http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4148
    http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4146
    http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4142
    http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4150
    http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4139
    http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4138
    
    [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1259924#c9

cc @dbaron

Missing tests are causing master to fail

FATAL ERROR: There are 2 WPT tests underneath your path prefix aren't in your document and must be added:
  quirks/line-height-trailing-collapsable-whitespace.html
  quirks/vertical-align-in-quirks.html

"The body element fills the html element" vs float

Emphasis added:

https://quirks.spec.whatwg.org/#the-body-element-fills-the-html-element-quirk

In quirks mode, if the document’s body element body is not null and if it matches the following conditions:

…

The computed value of the float property of body is not none.

Is it intended that this quirk only applies to floated <body>, or is that "not" a typo?

Use computed value instead of used value

https://quirks.spec.whatwg.org/#the-line-height-calculation-quirk

The border-right-width, border-left-width, padding-right and padding-left properties have a used value of zero.

Per servo/servo#11853 maybe used value here should instead be computed value.

Broken references in Quirks Mode Standard

While crawling Quirks Mode Standard, the following links to other specifications were detected as pointing to non-existing anchors:

https://drafts.csswg.org/css-multicol-1/#spanning-element

_{This issue was detected and reported semi-automatically by Strudy based on data collected in webref.}