Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need to define quirks mode interactions for constructable stylesheets #59

Open
bzbarsky opened this issue Oct 24, 2018 · 10 comments
Open

Comments

@bzbarsky
Copy link

Stylesheet parsing is affected by quirks mode. Should constructable stylesheets always be parsed in standards mode? Should they pick up the quirks mode of a document (which)?

@tabatkins @annevk @domenic @rakina

@tabatkins
Copy link
Contributor

Definitely always Standards mode; I see no reason to further expose quirks mode.

@annevk
Copy link

annevk commented Oct 24, 2018

I agree.

(Note that the mismatch of document and style sheet quirks mode can already be done using the Link header and document.open(). It's a little unclear if all the specifications are clear on which quirks mode they mean though.)

cc @zcorpan

@zcorpan
Copy link

zcorpan commented Oct 25, 2018

Also agree with @tabatkins

@bzbarsky
Copy link
Author

Fwiw, I also think they should always be standards mode. We just need to specify this.

@rakina
Copy link
Member

rakina commented Oct 25, 2018

How do we define that? Just add "in no-quirks mode" to the end of "Parse a stylesheet from text"?

@bzbarsky
Copy link
Author

bzbarsky commented Oct 25, 2018

Good question. There's no actual entrypoint to stylesheet parsing that takes a mode as an argument, and the quirks mode bits are comefrom-monkeypatched in by https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk and https://quirks.spec.whatwg.org/#the-unitless-length-quirk

Maybe the right thing for now is to just add text to the ends of those sections (akin to the existing "must apply" and "must not be supported" bits). Sort of up to @tabatkins and @zcorpan who maintain the relevant specs how they think this should best be done.

@zcorpan
Copy link

zcorpan commented Oct 25, 2018

I'd be happy to have this more explicit as a flag on the stylesheet or so and use that in the quirks standard. @tabatkins ?

@pygy
Copy link

pygy commented Feb 2, 2020

How much of the Web still uses quirks mode?

Wouldn't it make sense to discourage its use by disabling the new features when rendering in quirks mode (as in, either don't provide the APIs, or provide them, but throw on call/getter access)?

It would reduce the accidental use of quirks mode in new pages/apps, and would not break Web CompatTM.

@zcorpan
Copy link

zcorpan commented Feb 2, 2020

@pygy 4.85% of httparchive https://twitter.com/zcorpan/status/1205242913908838400

Disabling or changing features in quirks mode is effectively adding more quirks. In the past, we have instead tried to remove quirks to reduce complexity in the implementation.

Feel free to create a new issue in https://github.com/whatwg/quirks if you'd like to discuss the idea more.

@bzbarsky
Copy link
Author

bzbarsky commented Feb 3, 2020

How much of the Web still uses quirks mode?

A ton, because about:blank is in quirks mode and lots of sites create blank iframes and then add content to them...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants