leaverou / css3test Goto Github PK

As the CSS3Test seems to be the most comprehensive online test available, it would be good to have the ability to compare your results with other browsers, much like on HTML5Test.

I've been searching everywhere for some sort of summary of the collected data on Browserscope but without much luck.

Also there seems to be quite a lot of data on Browserscope, however I'm unable to find any way to download/analyse this data myself, and much of it seems to conflict with one another. Is there any way to actually do this?

I'll just fill one issue, but all your projects are affected :)

See w3c/csswg-drafts@5a98e20 and mdn/browser-compat-data@10c92d6.

The descendant combinator >> was removed again from the spec (see the resolution at w3c/csswg-drafts#641).

So, the change done in #138 needs to be reverted.

Sebastian

E.g. half the % given.

Opening this as response to the closed #132, to have a bug tracking this (rather than removing the points entirely, which that PR did)

Firefox already has support (hidden behind the layout.css.vertical-text.enabled preference) for the properties defined in the 'Logical Page Classifications' in the CSS Logical Properties specification.

So should the tests for these properties already be added? What about the properties that are currently not supported?

I can create a pull request for this.

Sebastian

Not only the whole specifcation should be linked but also each individual feature that is tested.

For example, the box-sizing property should have a link to https://drafts.csswg.org/css-ui-3/#box-sizing, maybe also to https://www.w3.org/TR/css-ui-3/#box-sizing. This link might be implemented as a text or image badge shown when hovering the entry.

Sebastian

Mozilla Developer Network, Chrome Platform Status etc...

http://dev.w3.org/csswg/css-position/

For example:

position:sticky; /* Firefox，WebKit already supports.*/
position:center;

Sometimes I think CSS3Test is misleading because makes it look like browsers are expected to have these abilities implemented. Especially as more early stage standards are being added (scroll snaps was added within days of the 1st working draft being released).

I think it would be wise to group these tests by the same categories W3C uses at http://www.w3.org/Style/CSS/current-work :: Completed, Testing, Refining, etc. or Recommendation, Proposed Rec, Candidate Rec, Last Call, Working Draft (the second set is probably more clear language).

Simply grouping these spec tests by those categories would give people a lot more clear idea as to what they should be expecting browsers to have implemented in the first place and what to be watching for in the near future as opposed to thinking, "why doesn't my browser have scroll snaps implemented yet? what a horrible browser!"

Originally posted by @LeaVerou in #169 (comment)

You've still not understood the definition of "compatible" units which is a core part of SVG (and then of CSS by later reference). Compatible means that there exists a function transforming one to another but this transform is NOT necessarily unique. In SVG this transform changes when you change the CTM: there's NO single "constant" that allows converting them directly by a simple scalar product. This conversion passes through the CTM which is changed in various ways in SVG (and CSS) !!!

I've never said that conversions between "cm", "in", "px" were "incompatible" as you think (or if you misread me). That's the opposite: not only they are compatible but they are statically defined with a constant (because they are on the same group, they are ALL in the gorup of "absolute" units. But this is NOT the case for other units.

SVS and CSS in fact are working with a combination of at least FIVE transform matrixes which allows mapping

• "line-height relative" units to font-relative units (two variants depending on which unit it used to define the line-height, the font will be the first one specified for the current element if this font-size is unit-less, or for the first ancestor element whose font-size is not unit-less, or for the default font-size of the document's root otherwise).
• "font relative" units to other relative units or absolute units (depending on how fonts are sized with their own unit)
• "view relative" units to other relative units or absolute units (depending on how views are sized with their own unit)
• "absolute" units to document-root relative units
• "document-root relative" units to media/page units.

All these 5 groups are composable recursively and each one has its own transform matrix ! But there's NO unique conversion factor between these units belonging to distinct groups. So SVG and CSS have to handle 5 matrixes simultaneously and update them where needed for each element to reflect the matrix to use in their children elements.

All units in these 5 groups are "compatible" if they are in the same dimension (e.g. units of length). But they have simple conversion factors only if the two units to convert from/to belong exactly to the same group.

So I maintain that you're wrong. And it's a fact that it is perfectly testable in a QUICK test in Javascript. And a proof is that there are other "benchmark" tests that properly test if the renderer are correctly "nesting" their conversions, without incorrectly assuming that the 5 groups (for length units) are convertible with the same conversion matrix or a static conversion factor (this is completely wrong).

This is not a problem for the CSS WG, because this is a standard that existed in SVG since the begining (except early versions of SVG where the only units supported were dimension-less, i.e. reduced only to numbers with units, and they were then only relative to the immediate parent element, and all others were in a single group "absolute" units...) long before CSS was integrated ("absolute" is a old bad/confusive terminology of SVG, when "absolute" units are in fact always relative to another base defined by a selected element in the SVG tree, but not necessarily the same element throughout the SVG DOM tree; but this terminology was kept; the only really "absolute" units are those used for the @media queries in CSS, not defined at all in SVG itself!)

But I'm NOT asking you to test CSS @media queries immediately; but at least test units that are part of SVG independantly of CSS media queries.

But remember that your test suite is named "CSS3test" and should then test also the @media queries and their related units (like dpx). This is exactly what your test is suppose to track ! It is directly a goal of your test.

All this is already defined by the CSS WG. I cannot ask them to change or discuss changes when all is already precisely defined by them (and not jsut for CSS3, as it is already standard since CSS 1.0 and has not changed in CSS 2.0), and it's up to you to support their existing and well defined standard, only because you misinterepreted some specs you found in SVG (where the 5 groups of units are clearly an unambiguously defined and already said to be "compatible", which does not indicate that they are linked by a single universal static scaling factors between all pairts of "compatible" units).

Reread the standar scrupulously ! You'll see the confusion or incorrect assumption you made with the term "compatible" (which is accurately and unambiguously defined in SVG and CSS, but not by the simple way you think, i.e. NOT by a single universal scaling factor).

So THis is the CORRECT place to discuss it: this is a RFE (Request for enhancement) only for YOUR test. There's nothing to change in CSS or SVG. This is only something that for now you do not test at all (even if it's really easy to do!), but which is absolutely needed for CSS3 conformance (what your benchmark is supposed to test).

I claim that your test offers only partial converage for a fundamental module used in both CSS and SVG (all versions! and now HTML5 as well!) that is much simpler to test than all your very useful but complex tests, whose accuracy may then be fooled if the essential "units module" is not first tested properly.

According to the spec, there's nothing syntactically wrong with this selector, true.

But the spec also says: The value a can be negative, but only the positive values of an+b, for n≥0, may represent an element in the document tree.

The example that follows is: html|tr:nth-child(-n+6) /* represents the 6 first rows of XHTML tables */

Thus, though the syntax is correct, the selector results in no positive values. Browsers (like Chrome, which currently fails this test) don't need to support input that has no representation in the document tree. I feel this selector test (it happens 4 times in the CSS3Test) should be removed as invalid.

The layout of the page could be improved in several ways.

• The list of tests is very long.
• It's a bit hard to distinguish headlines from subheadlines.
• Smiley's while a nice idicator for the implementation status, don't look professional.

Because I like the layout used at html5test.com, I've created a new layout (including changes in the data structure), which aligns with the layout of that website.

The related files generating that layout are attached.
Note: The layout is not complete. It is missing a few things like e.g. the hint about feature recognition and the specs list.

Sebastian

layout.zip

For the values "space" and "round" for background-repeat, WebKit triggers a false positive. You can see this demonstrated in this old JSBin:

http://jsbin.com/uzesun/3/edit

Notice the message displayed in the red box. If you view it in any version of Chrome or Safari (maybe not Safari 6?), you'll see the message "This browsers supports space and round" but, as shown by the fact that the background images aren't displayed properly, those browsers don't support space and round.

Compare to Opera and IE10, which display the same message, and they both display the background properly. Firefox doesn't support space and round, but it has the correct message.

I've filed bug reports with WebKit (a year ago) as well as Chrome but no one seems to be following up on those. I've also tested on Chrome Canary, with the same results.

With the flex shorthand property set to flex: auto, the result should be the same as flex: 1 1 auto. In the current stable version of Chrome (23), flex: auto doesn't seem to do anything, as you can see here. It would be nice if css3test would include a test demonstrating this failure.

The latest CSS Values and Units Module (8 March 2012) removes min() and max(). They need to be deleted from the test.

So far, no browser supports it according to caniuse.com, though once they do, a test should be added for it.

Sebastian

Browserscope's API is admittedly limited (you can finally deleted defunct tests, but you cannot add new tests, reset changed tests, or group tests into categories). As a result, its records for the CSS3Test are not reflecting the actual results (says Chrome18 gets a 63 when my Chrome18 consistently gets a 56).

Based on those limits, one of two things needs to happen:

1. Simple solution is to reset or build a new user test on browserscope that will take in all the new / different data in the CSS3Test as it currently stands. Some form of versioning for the CSS3Test would aid the reality that this test will continually have to be rebuilt from time to time.
2. The more complex solution would be to use some of the backend built for the HTML5Test (with permission, of course), which is built in such a way that it could be relatively easily borrowed, and build a custom results page for the CSS3Test. This would require database access.

Css3test seems to not working in latest Chrome Canary (21.0.1156.1). Page simply freezes and refuses to load.

http://dev.w3.org/csswg/css-box/

For example added:

margin: fill;

width: [border-box | content-box]? | available | min-content | max-content | fit-content;

alignment: top | right | bottom | left | center;

child-align: top | middle | bottom | left | right | auto;

I sometimes get certificate/redirect errors when connecting to the website. I checked the DNS settings and noticed 1 IP address is not correct. These are the current A records:

css3test.com.	1799	IN	A	192.30.252.154
css3test.com.	1799	IN	A	185.199.109.153
css3test.com.	1799	IN	A	185.199.110.153
css3test.com.	1799	IN	A	185.199.111.153

The first IP address is causing the issues and according to Github's help page 192.30.252.154 should be replaced with 185.199.108.153

The tests for the mask property have invalid url() values, which cause them to fail.

Sebastian

While the orphans and widows properties are not yet implemented in Gecko it already exposes them, so they get incorrectly marked as supported.

The Cheaters section should mention that circumstance.

Sebastian

A test should be added for the @counter-style rule.

Sebastian

It's still a draft see here

• http://dev.w3.org/csswg/css3-fonts/#font-feature-settings-prop and
• http://www.w3.org/TR/css3-fonts/#propdef-font-feature-settings here

but Firefox and IE10 already supports it, and webkit is planning to support it as well in the future https://bugs.webkit.org/show_bug.cgi?id=63618

So what do you think Lea, is it worth a mention?

Commit d908aba added the CSS Grid Module. The test for display: grid and display: inline-grid succedes for Firefox, however it does not trigger CSS3 Grid Layout but XUL Grid layout (via display: -moz-grid; etc., see https://bugzilla.mozilla.org/show_bug.cgi?id=616605#c10).

See https://bugzilla.mozilla.org/show_bug.cgi?id=914360 – if that bug does not get fixed, I'd add another disclaimer to the page. Thanks!

The current certificate has expired : Monday, March 20, 2017 - Tuesday, April 7, 2020
@LeaVerou, is it possible to renew it ?

The CSS3Test link currently goes to a page that lists individual results one-by-one.

The HTML5Text goes to the following page: http://www.browserscope.org/user/tests/table/agt1YS1wcm9maWxlcnINCxIEVGVzdBjn37IMDA, which lists top browser results.

Change the CSS3Test link to http://www.browserscope.org/user/tests/table/agt1YS1wcm9maWxlcnINCxIEVGVzdBidzawNDA to display a summary of results. Sometimes this link has had a hard time loading results, but I got it to load today.

The CSS Masking spec. replaced the auto value for the mask-mode property by the value match-source.
So, the test should be adjusted accordingly.

Sebastian

The cursor values grab and grabbing are currently missing. They should be added.

Sebastian

Per the top-listed change at http://dev.w3.org/csswg/css-flexbox/#changes ,the CSS3 Flexbox Spec has removed the chunk about "min-width:auto" and "min-height:auto". So, those values are no longer valid.

We've implemented this change in Firefox Nightly (removing support for "auto") -- but css3test.com still checks for "auto" and counts its absence against us as a test failure (as noted in https://bugzilla.mozilla.org/show_bug.cgi?id=666041#c135 ).

I'm filing this issue on updating the testsuite (either to remove this check, or to reverse the polarity of the check to make "auto" considered incorrect), to reflect the updated flexbox spec.

Due to success === 1 and success === 0 being treated specially, the output of passclass() is distorted.

You can see that at the test for 'calc()' on Firefox 43.0:

Only one of seven tests failed, though the assigned class is slightly-buggy, while it should actually be almost-pass.

Sebastian

https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#the-touch-action-css-property

This is a really nice CSS3 test and it has some great features. The only issue that I have is that there is no licence file (that I can find) in the repository. This probably isn't a huge problem most of the time but I am working on a project that is very strict about making sure that everything used in the project has proper licences and that includes a licence file that can be pointed to. If you could add the MIT licence file to the repository with your name and the year in the right places at the top (http://opensource.org/licenses/MIT) that would be very helpful. Thanks!

Chrome (webkit bug https://bugs.webkit.org/show_bug.cgi?id=68128), MSIE and opera don't apply transition and animation to pseudoelements.
Can this bug be handled in tests?

I'm trying to make sense of the specs, but it seems to me the following test may no longer be valid:
transform-origin: right 10px bottom 20px

This test was valid in http://dev.w3.org/csswg/css3-2d-transforms/#transform-origin-property but the new css-transforms module combines 2d and 3d transforms into one document http://dev.w3.org/csswg/css3-transforms/#abstract and based on the current description of transform-origin http://dev.w3.org/csswg/css3-transforms/#transform-origin I don't think this test is valid. Am I reading this right?

However, it could be replaced by a test like "10px 45% 22px"?

would be nice to add a favicon.ico to the site so it displays it in my bookmarks.

The modules on the CSS3Test are rather stable, but sometimes minor or even major changes occur with a new working draft. Whether just in the code or on the CSS3Test page, it would be helpful to display which module revision the tests were derived from, if for no other reason that providing a means to track when tests might be out-of-date and the latest module revision needs to be consulted to determine if changes are needed.

Basically, something somewhere that says, in not so many words, "Backgrounds tests based on DEV module, revision date 15 February 2011." Or "Background tests based on TR module, revision date 14 February 2012." If they were based on the DEV module, this simple line would indicate that the tests are out-of-date and need to be revised, as a new background DEV module is out.

Maybe it's time? IE10 and Chrome already support some properties of this new layout system. Safari 7 announces it too.

What do you think?

None of your tests show if absolute units (independant of the viewport or viewbox and scaling, but only dependant on the root element) are supported.

These absolute units are relative to the user's view: m, cm, mm, in...

Most browsers for now do not support them (not even Chrome). Instead they map them as multiples of relative units, i.e. relative to the viewport metrics (such as px, pc) or to the 1st current font metrics (em, rem), either in the root element or the current element, which are scaled by the font-size measured relatively to the viewport metrics, or relative to the line-heigh (lh, rlh) which are relative to the font-size.

This makes for example impossible to properly scale sizes according to user's experience: all generated images are necessarily adjusted proportionally to the viewport or viewbox, and if the viewport size changes, all thin strokes or small text for example will be rescaled, maning them unreadable.

For accessibility, we need to be able to use absolute heights, independantly of viewports and viewboxes. Then we an adapt the viexbox content by altering the shapes when needed (this means for example that a round button containing text may become a rounded rectangle, borders will will not be rescaled but the content of borders will have to be adapted (e.g. dimensioning correctly a legend on top of a scalable image).

As well bitmap images are always scaled in relative units (px), and they are scaled relatively to the viewport and not relatively to user's visibility/readability demand (which is determined by the default units of the root element). We should be able to scale these images according to user's preferences to show effective details. But most browsers do not support it, even if absolute units (like mm, in, or viewing angle in steradians) are in CSS since ever (browsers still don't correctly estimate these units and do not even use units of the root element, but incorrectly emulate them using the current element, which is obviously completely wrong: for example they assume that 96px (relative to the current element) = 1in (absolute size estimated from the root element) which is obviously completely wrong (because the measure "1in" will vary visually depending on each element if they use different scales, when the mesure should ALWAYS be invariant throughout the document)!

There should be a way to restrict the tests to only cover stable features.

By stable, I mean all specifications listed in the latest CSS snapshot released by the CSS Working Group. When using the snapshot specifications as a reference, the option could even cover multiple of those specifications to allow the user to see the progress a browser made through the years.

Another definition of stable might be the release of a feature in two different browser engines, though that's probably harder to maintain.

Sebastian

Selectors Level 4 introduced >> as descendant combinator additionally to the existing whitespace form.

WebKit already has support for it in a technical preview, Blink and Gecko have related bug reports.

Sebastian

Noticed that paint() and layout() tests from Painting & Layout APIs are failing, because these features are allowed only on https.

Forcing https on the URL makes tests OK, but certificate is invalid.

This is just a minor detail!

The bullet-points (▶) from the effects list shine through the main heading.

Adding a z-index of 1 on body > h1 and 2 on #mark img seems to do the trick.

The CSS Transforms Module Level 1 defines a transform-box property specifying the layout box used as reference for the transform and transform-origin properties, which just got implemented by Mozilla.

Sebastian

CSS pseudo-elements don't seam to works on <img> elements on some browser

test:
http://dabblet.com/gist/5714359

In the Writing Modes spec text-combine-horizontal was renamed to text-combine-upright.
The test should be changed accordingly.

Sebastian

"Image Values and Replaced Content" is a long title, resulting in the floated score being bumped down. Reducing
body > section section section h1 {
font-size: 200%;
}
would fix this in most browsers on normal zoom without losing much visual emphasis on the titles (I actually think it looks better)

Excellent work on this tool!

Now, to make it really useful cross platform, it would be smart to add a structured export option so developers can diff features between platforms.

I gamble that most devs are using this tool to figure out how to retrofit their code to be compatible for the test browser; offering an export and potential diff would create itemized lists of what features are available where.

Not a P1 since talented devs can write their own extractor.