Bug 24349 - [imports]: Import documents should always be in no-quirks mode
Summary: [imports]: Import documents should always be in no-quirks mode
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on: 24667
Blocks: 20683
  Show dependency treegraph
 
Reported: 2014-01-22 01:39 UTC by Daniel Freedman
Modified: 2014-04-17 17:59 UTC (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Freedman 2014-01-22 01:39:36 UTC
HTML Imports can provide a clean break from the subtle differences between quirks and no-quirks modes by enforcing no-quirks mode for all imported documents.
Effectively, this would be saving developers from having to type <!doctype html> at the beginning of each and every import.
Comment 1 Elliott Sprehn 2014-01-22 01:57:25 UTC
I agree, I thought we had made this change already but it seems we didn't.
Comment 3 Anne 2014-02-13 10:01:48 UTC
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.
Comment 4 Morrita Hajime 2014-02-13 22:29:34 UTC
(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!
Comment 5 Anne 2014-02-14 11:15:12 UTC
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.
Comment 6 Dimitri Glazkov 2014-02-14 18:23:23 UTC
(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?
Comment 7 Morrita Hajime 2014-02-14 19:31:38 UTC
(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
Comment 8 Morrita Hajime 2014-02-14 19:36:02 UTC
(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/
Comment 9 Adam Klein 2014-02-24 22:36:34 UTC
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...
Comment 10 Morrita Hajime 2014-02-24 22:52:10 UTC
(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.
Comment 11 Adam Klein 2014-03-13 20:41:41 UTC
The spec still says that the document is in "no quirks mode", should that be removed?
Comment 12 Morrita Hajime 2014-03-13 21:52:29 UTC
(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.
Comment 13 Anne 2014-03-16 08:19:52 UTC
(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.
Comment 14 Morrita Hajime 2014-04-14 23:54:01 UTC
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.
Comment 15 Tab Atkins Jr. 2014-04-14 23:58:39 UTC
I was under the impression that the f2f decided to make imports always Standards Mode.  Did I hear incorrectly?
Comment 16 Morrita Hajime 2014-04-15 00:20:56 UTC
(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.
Comment 17 Boris Zbarsky 2014-04-15 02:54:58 UTC
> mixing modes can be tricky to implement

Why exactly, as long as all quirks define which document they base their quirkiness on?
Comment 18 Morrita Hajime 2014-04-15 17:00:02 UTC
(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.
Comment 19 Morrita Hajime 2014-04-15 20:35:04 UTC
(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.
Comment 20 Anne 2014-04-15 22:23:38 UTC
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.
Comment 21 Morrita Hajime 2014-04-15 22:40:01 UTC
(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.
Comment 22 Elliott Sprehn 2014-04-16 06:29:55 UTC
(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...
Comment 23 Anne 2014-04-16 10:20:52 UTC
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.
Comment 24 Morrita Hajime 2014-04-16 17:38:20 UTC
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.
Comment 25 Anne 2014-04-16 19:29:07 UTC
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.
Comment 26 Simon Pieters 2014-04-17 11:01:25 UTC
(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.)
Comment 27 Morrita Hajime 2014-04-17 17:59:31 UTC
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.