[css-overflow] FPWD as a dependency for [css-contain]

[svgeesus]

From today's transition call for css-contain: what is holding us back from FPWD of css-overflow-4 (which is a normative reference from css-contain-1).

[svgeesus]

Comments from Ralph Swick:

Two questions, Chris. These are probably best addressed in WG discussion.

1. What is holding up FPWD for CSS Overflow 4? An FPWD can state what parts are less (or more) stable but a CR shouldn't depend upon something that is only an editors' draft, especially if the pertinent definitions have been improved.

2. Security considerations should include something about risks and counter-measures if a bad actor misuses these new features; e.g. to alter (and misrepresent) what is rendered to the user.

Would it be appropriate to have some test cases that misuse the features and test what the implementation does in those situations?

[svgeesus]

Second part of that question copied over to a new issue #1376

[tabatkins]

On Mon, May 15, 2017 at 8:47 AM, Chris Lilley ***@***.***> wrote: From today's transition call for css-contain: what is holding us back from FPWD of css-overflow-4 (which is a normative reference from css-contain-1).

Doesn't matter; we don't *actually* depend on anything from overflow-4, we impose a restriction on some of its features. This is just an interaction between the two specs; neither spec, on its own, depends on the other in any way. This *is* still property a normative reference; if you implement both specs, these are indeed normative requirements on the interaction. But they shouldn't count as holding back Contain. ~TJ

[svgeesus]

That doesn't answer the question of "what is holding back FPWD of overflow 4", though :)

[tabatkins]

I... don't understand the question. Who mentioned overflow-3?

If you meant overflow-4, my point is that it's irrelevant and shouldn't hold back contain-1, which is the subject of this thread.

The title of the issue and the contents of the first post do not agree on what the point of this thread is. >_<

[fantasai]

We actually have a FPWD of the features in Overflow 4: that was the original Overflow 3:
https://www.w3.org/TR/2013/WD-css-overflow-3-20130418/

We cut down the features to what's already implemented in order to get a module that actually defines overflow-x and overflow-y. However, that spec still requires a lot of work. (Primarily QA/reverse-engineering work.) We should publish an Overflow 4 draft as well, I think it hasn't been done because we're reluctant to have two early-stage Overflow WDs concurrently... and in this case the feature set in Overflow 4 isn't actively being update atm anyway.

[svgeesus]

Thanks fantasai, that helps explain the situation

[svgeesus]

Should I remove the agenda+, in that case?

[astearns]

forgot to close the logbot - here's the bit from the call today:

Topic: [css-overflow] FPWD for level 4
astearns: Is it correct that everything in 4 way already in 3?
Florian: Correct. No new features.
astearns: Any objections to FPWD of Overflow 4?
RESOLVED: FPWD of Overflow 4
Florian: I'll also make sure any L3 edits are reflected in L4.
fantasai: I'd recommend just dropping those sections.
Florian: That's better.

https://log.csswg.org/irc.w3.org/css/2017-05-17/#e810098

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow] FPWD for level 4, and agreed to the following resolutions:

• RESOLVED: FPWD of Overflow 4

The full IRC log of that discussion

<dael> Topic: [css-overflow] FPWD for level 4
<dael> github topic: https://github.com//issues/1374
<dael> astearns: Is it correct that everything in 4 way already in 3?
<dael> Florian: Correct. No new features.
<dael> astearns: Any objections to FPWD of Overflow 4?
<dael> RESOLVED: FPWD of Overflow 4
<dael> Florian: I'll also make sure any L3 edits are reflected in L4.
<dael> fantasai: I'd recommend just dropping those sections.
<dael> Florian: That's better.
<dael> astearns: We don't have time for the last item, so we'll end a minute early.
<dael> astearns: Thanks everybody.
<Florian> fantasai: Can you comment on https://github.com//issues/174#issuecomment-224735914 to say if you accept the decision?
<Florian> TabAtkins: echidna is rejecting MQ4 because of <a href=""> elements in the railroad diagrams. https://labs.w3.org/echidna/api/status?id=89b4647f-7a36-45e4-87d7-47b30f3245ec
<Florian> (if I understand the error message correctly)
<Florian> what gives?
<TabAtkins> Tell them it's broken and SVG allows those just fine.
<TabAtkins> Yay for more validation-that-is-out-of-date-and-prevents-things-from-working!
<Florian> "Tell them"? who's them?
<TabAtkins> Sorry, #pub
<Florian> on irc?
<TabAtkins> Example: <!DOCTYPE html><svg><text y=20><a href="http://example.com">foo</a></text>
<TabAtkins> Yeah
<tantek> aside: Florian, thanks very much for the issues you've opened on WPWG rechartering. Keep up the pressure.
<Florian> tantek: My pleasure :) I suppose I am somewhat masochist
<Florian> TabAtkins: it's getting late here, can you deal with the folks on #pub, and publish MQ4 if they fix echinda fast enough, or report back with if they don't?
<TabAtkins> yup
<Florian> TabAtkins: Other than changing the status to WD and pushing the draft, everything should be ready
<Florian> TabAtkins: thanks
<TabAtkins> got me a bug in my bonnet about this validation stuff anyway
<TabAtkins> i'm def in and out today - sick - but we'll see what i can do
<Florian> Well, I am definitely just out today, it's 2:45am, so you're still more active. Take good care of yourself, and if you get the chance to run bikeshed echinda, do it, and if not, I'll pick up from there
<AmeliaBR> TabAtkins: You should *probably* still be using xlink:href so that the links work in Safari. But, yes, the validator needs to be updated to allow href without xlink on SVG links. But that's probably a pull request on the Nu validator, not something specific for W3C publications team.
<Florian> Woohoo, it's so good to have someone how knows SVG inside out. Good to have you on board AmeliaBR.
<Florian> TabAtkins: can you fix bikeshed to generate that instead? with a bit of luck, that will pass the validator
<gsnedders> are table cells by default indefinitely sized?
<AmeliaBR> Also, the Nu Validator really needs to work on their error messaging: Error 1 is "href not allowed here". Error 2 is "href is required" (on the same element). Doh.
<TabAtkins> Heh, I wonder how that happens? Probably: namespaces.
<gsnedders> I'm sure I saw MikeSmith talking about this a while ago, and it was something about requiring a non-empty value
<gsnedders> https://codepen.io/gsnedders/pen/ybxbZN — how do I make that div the full height of its parent?
<gsnedders> I presume the table cell is considered indefinite hence why that isn't working
<AmeliaBR> TabAtkins: Yup. When people write a validator for HTML, and then someone goes and sneaks in some pesky XML namespaces in there. I went to file an error, but someone had beat me to it https://github.com/validator/validator/issues/511
<gsnedders> and I think this is just generally getting into the mess that is table layout :)
<AmeliaBR> @gsnedders It seems to be only looking at whether the parent has `height: auto`, regardless of the actual height. If you set `td {height: 1em;}, then then div changes height. Oh. except not in a cross-browser compatible way: Firefox adjusts it for a 1em height, Chrome and Edge adjust it to fit the actual 2-row <td> height.
<AmeliaBR> So, yes: "I think this is just generally getting into the mess that is table layout :)"
<gsnedders> :)
<gsnedders> even with table-layout: fixed spans are pretty undefined, afaict
<astearns> trackbot, end meeting