I agree, I thought we had made this change already but it seems we didn't.

https://github.com/w3c/webcomponents/commit/f7945a427e467285902951336f5b963682e01875

That's not the right fix. You're pointing to a document that defines behavior for when a Document is set to quirks mode. You're not actually preventing a document from being set to quirks mode. You need a particular HTML parser invocation and everything else is not needed.

(In reply to Anne from comment #3)
> That's not the right fix. You're pointing to a document that defines
> behavior for when a Document is set to quirks mode. You're not actually
> preventing a document from being set to quirks mode. You need a particular
> HTML parser invocation and everything else is not needed.

OK, so here is another attempt: https://github.com/w3c/webcomponents/commit/38326f265eecee0c9455e7884a2504796fb5b819

As the spec already has aparser invocation, I added a tweak there.
I wonder this hits the reasonable extension point of the parser though.
Feedback and reopen welcome!

Sorry, I should have done some more research.

What I think we want is for the HTML parser to accept an override for quirks mode just as it has for encoding. HTML can then use that override for <iframe srcdoc> (rather than special casing that in the parser) and then HTML imports and other specifications that need to parse HTML can use it too.

(In reply to Anne from comment #5)
> Sorry, I should have done some more research.
> 
> What I think we want is for the HTML parser to accept an override for quirks
> mode just as it has for encoding. HTML can then use that override for
> <iframe srcdoc> (rather than special casing that in the parser) and then
> HTML imports and other specifications that need to parse HTML can use it too.

Does this problem go away if we switch to using DocumentFragments?

(In reply to Dimitri Glazkov from comment #6)
> 
> Does this problem go away if we switch to using DocumentFragments?
I think so. 

The spec [1] tells that the quirks mode of the fragment is inherited from the owner of the context element. 

At the same time, I think it's reasonable to have a know for quirks mode override as Anne suggested. It'd be nice to have and doesn't add complexity of the HTML spec that much even if we decide to go the fragment path eventually. 

Will file a bug for that.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#parsing-html-fragments

(In reply to Morrita Hajime from comment #7)
> At the same time, I think it's reasonable to have a know for quirks mode
s/know/knob/

I realize I'm coming late to the discussion, but I was thinking of implementing this in Blink and I'm confused as to the motivation. Wouldn't it make more sense to have imports get their quirks-mode but from their host document? That's where the <style> blocks in them are going to apply, anyway...

(In reply to Adam Klein from comment #9)
> I realize I'm coming late to the discussion, but I was thinking of
> implementing this in Blink and I'm confused as to the motivation. Wouldn't
> it make more sense to have imports get their quirks-mode but from their host
> document? That's where the <style> blocks in them are going to apply,
> anyway...

Good point. We saw similar problem when we were thinking about CSP,
that is, there are two documents, but there is only one context.

For example, it makes sense to give per-document quirks mode when thinking about parsing. But it makes less sense when thinking about how style is computed. The quirks mode affects many aspect of HTML and we cannot easily decide which bits are related the context and which are purely for the document.

Probably we should just let imports get the mode overridden, as if innerHTML does. If imports were DocumentFragmetns, it would behave like that.

The spec still says that the document is in "no quirks mode", should that be removed?

(In reply to Adam Klein from comment #11)
> The spec still says that the document is in "no quirks mode", should that be
> removed?

Let me update this, as well as encoding part.

(In reply to Morrita Hajime from comment #12)
> Let me update this, as well as encoding part.

What does this mean? We always want to decode imported documents using utf-8.

OK, this was also discussed briefly at F2F, and I don't see any objection in either way. Basically, people like quirks mode.

I made a change that the quirks mode is inherited from the master document
and let the document ignore signals from the parser.

https://github.com/w3c/webcomponents/commit/38dd0c811f224a389947359fbceeec5cacc6d762

I think this behavior is reasonable, but how it is written can be better.
Feel free to reopen/file new bug to discuss more.

I was under the impression that the f2f decided to make imports always Standards Mode.  Did I hear incorrectly?

(In reply to Tab Atkins Jr. from comment #15)
> I was under the impression that the f2f decided to make imports always
> Standards Mode.  Did I hear incorrectly?

You're right.

I don't think there are little difference here though once we agreed that
the mode can be given from outside. In many case the master is in standard mode.

I'd like to take this approach since mixing modes can be tricky to implement
and having imports standard-mode while the master quirks-mode doesn't make sense anyway.

> mixing modes can be tricky to implement

Why exactly, as long as all quirks define which document they base their quirkiness on?

(In reply to Boris Zbarsky from comment #17)
> > mixing modes can be tricky to implement
> 
> Why exactly, as long as all quirks define which document they base their
> quirkiness on?

Implementation wise, style engine mixes rules from multiple sheets whose owners are documents.

Another concern is not about implementation, but from author's perspective, it might be confusing because if the main document is in quirks mode, the custom elements defined in an import (that is in standard mode) is rendered in quirks way, because the element is put into the quirk main document to be shown.

(In reply to Morrita Hajime from comment #18)

> Implementation wise, style engine mixes rules from multiple sheets whose
> owners are documents.
s/are documents/different documents/

So one place where mode can mix is in style engine.

The style engine should inherit the mode from a given document. That document already needs to be clear, otherwise referrer and such will be unclear.

(In reply to Anne from comment #20)
> The style engine should inherit the mode from a given document. That
> document already needs to be clear, otherwise referrer and such will be
> unclear.

Yes. I agree this is the expected behavior.

In this case, I'm solely talking about implementation, and I expect there are a few places in style resolution code which assume that there is only one document associated to the resolution. HTML Imports breaks this assumption and causes subtle and hard to diagnose bug. That's what I want to avoid.

That being said, I don't have strong opinion here. We can fix implementation bugs after all and it seems like always no-quirks have strong supporters. So I'll revise that part.

(In reply to Morrita Hajime from comment #21)
> (In reply to Anne from comment #20)
> > The style engine should inherit the mode from a given document. That
> > document already needs to be clear, otherwise referrer and such will be
> > unclear.
> 
> Yes. I agree this is the expected behavior.
> 
> In this case, I'm solely talking about implementation, and I expect there
> are a few places in style resolution code which assume that there is only
> one document associated to the resolution. HTML Imports breaks this
> assumption and causes subtle and hard to diagnose bug. That's what I want to
> avoid.
> 
> That being said, I don't have strong opinion here. We can fix implementation
> bugs after all and it seems like always no-quirks have strong supporters. So
> I'll revise that part.

I don't think we want that complexity in blink. At resolution time we don't have any knowledge about the document where the CSS rules we're applying came from, only where the rules are being applied.

We shouldn't make this change if we need to expose the quirks state of the document with the definition. I don't think we need to though...

No, you need a "mode" when parsing a style sheet and a "mode" when applying a style sheet. These are input parameters to the algorithms. Ideally we specify things so that the same is used.

How about this: HTML Imports doesn't work with master documents in quirks mode.

Then we guarantee to the master being standard mode, so imports are
standard mode as well regardless of proposed models here.

How is this destructive? I hope it isn't.

I know JavaScript actively tries to avoid such differences in exposed feature sets. So far we have limited the differences between standards and quirks mode as well to a couple of conditionals.

I still don't really see the issue.

(In reply to Morrita Hajime from comment #24)
> How about this: HTML Imports doesn't work with master documents in quirks
> mode.

That's not a good idea. That would in itself be a new quirk, and as Anne said we try to minimize the number of quirks.

Inheriting the quirkiness is unprecedented which means it's a risk for new bugs, so I don't think that's a good idea either.

As such I see two reasonable options:

(a) Always use standards mode for imported docs. (Like iframe srcdoc.)
(b) Use the mode resulting from the parser. (Like iframe src.)

OK, let's do always standard path.
https://github.com/w3c/webcomponents/commit/e5c1417f687843eafd38a894d9378f2287a9f793

As Anne mentioned, there are two case to use the mode, and even in Blink, these two are distinguished relatively clearly: The resolution is done by main document's StyleResolver, the parsing is par-document CSSParser.

I am still a bit concerning that there could be hacks to break this design discipline, but they are hacks and I'm convinced that paying another complexity for existing complexity is not good idea.