mozilla :: #layout

14 Mar 2017
00:11fantasaibz: github is fine, it's just the most recent writing-modes drafts predate using GitHub
00:11fantasaibz: But no worries, I'll pull in your www-style comments :)
00:12* fantasai uses plaintext issue tracking so as to span all the tracking systems :p
00:30fantasaidholbert: When you get a chance, would you mind looking into https://lists.w3.org/Archives/Public/www-style/2017Jan/0068.html ?
00:30fantasaidholbert: It's a flexbox issue wrt definiteness (percentage resolution) vs auto flex-basis.
00:30fantasaidholbert: My current official opinion on this is to defer to implementers :)
00:31* fantasai will check in with Tab on that later this week, probably
00:32dholbertfantasai: will do
00:32fantasaidholbert: thanks :)
00:32* fantasai compiling DoC atm
00:32* fantasai :)
00:37dholbertfantasai: yeah, this is https://bugzilla.mozilla.org/show_bug.cgi?id=1092007
00:37firebotBug 1092007 NEW, nobody@mozilla.org For flex items in a vertical flex container, only treat heights as definite (for resolving % heights
00:37dholbertfantasai: still needs implementing. :-/
00:37dholbert(sorry)
00:37dholbertfantasai: I agree the Chrome (red) behavior is correct per spec there
00:38fantasaidholbert: np, just want to make sure you don't think the spec needs fixing
00:38fantasaidholbert: (which if it does, please let us know
00:38fantasai)
00:38dholbertfantasai: IIRC that behavior makes sense... reduces the need for multi-pass layout
00:38dholberts/that/the specced/
00:39fantasaidholbert: That was the goal.
00:39fantasaidholbert: I think Tab and I aren't going to push back if implementations have a preference for multipass layout, though :p
00:39dholbertheh
01:37dbaronfantasai: see my recent commits to https://hg.csswg.org/drafts/ related to Issue Tracking lines, which fixed bz's issue
03:32fantasaidbaron: Cool, thanks!
15:06bz_sleepDid people know that Safari messes up "display: contents"?
15:54matsbz: I didn't know they even implemented it... what do you mean by "messes up"?
16:11bzmats: "computes to inline"
16:17bzmats: Parses as "contents", looks like
16:17matsbz: oh, that's so wrong... :(
16:17matsbz: maybe some temporary measure for web-compat? or perhaps just a mistake?
16:18matsbz: do you know if they are currently trying to implement it?
16:23bzmats: no idea. I'm trying to find their relevant code here.
16:24bzmats: e.g. where CSSValueContents is defined. But not succeeding so far
16:25matsbz: don't waste time on it - we should just file a bug on WebKit. I can do that unless you already did?
16:25bzI haven't yet
16:25bzIf you're willing, to awesome
16:26bzfwiw, the info I do have is...
16:26bzin CSSParserFastPaths.cpp they have:
16:26matsbz: it seems Chrome Canary is actually implementing display:contents now - yay :-)
16:26bz case CSSPropertyDisplay:
16:26bz .. big comment
16:26bz return (valueID >= CSSValueInline && valueID <= CSSValueContents) || valueID == CSSValueNone
16:26bz || (RuntimeEnabledFeatures::sharedFeatures().isCSSGridLayoutEnabled() && (valueID == CSSValueGrid || valueID == CSSValueInlineGrid))
16:26bzin CSSParserFastPaths::isValidKeywordPropertyAndValue
16:26bzSo that&#39;s presumably the bug
16:27bzTestcase I was using is:
16:27bz<div id=&quot;x&quot; style=&quot;display: contents; border: 1px solid red&quot;>aaa</div>
16:27bz<pre><script>
16:27bz document.writeln(x.style.display);
16:27bz document.writeln(getComputedStyle(x).display);
16:27bz</script>
16:28* bz didn&#39;t see display:contents in chrome dev, tries canary
16:28bzDoesn&#39;t seem to support it over here....
16:28bzMy testcase above shows empty string and &quot;block&quot;
16:29bzin Chrome canary
16:29bz&quot;Version 59.0.3041.0 (Official Build) canary (64-bit)
16:29bzGet help with Chrome
16:29bzReport an issue
16:31bzmats: hyatt introduced this bug recently
16:31bzmats: https://trac.webkit.org/changeset/209021/trunk/Source/WebCore/css/parser/CSSParserFastPaths.cpp
16:32bzmats: sadly, it looks like it made it into shipping safari....
16:32* bz could be wrong about this being the relevant codepath, of course
16:35matsbz: your test prints &quot;console console&quot; for me in Chrome - I guess I have &quot;experimental web features&quot; enabled or something...
16:35matss/console/contents/
16:35mats:)
16:37matsbz: they still seem to have a few bugs, but it it looks like it&#39;s mostly working when I try it on our reftests...
16:38* mats looks at hyatt&#39;s changeset...
16:40bzmats: can you check how their impl interacts with first-letter?
16:40bzmats: (Chrome&#39;s)
16:40bzmats: <style>
16:40bz div::first-letter { color: red; }
16:40bz</style>
16:40bz<div id=&quot;x&quot; style=&quot;display: contents; border: 1px solid red&quot;>aaa</div>
16:40matsbz: sure, one sec...
16:41matsbz: the commit message says &quot;bugs in Blink that need to be fixed&quot; so I&#39;m leaning toward this was an unintentional side-effect for Safari
16:43matsbz: I see &quot;aaa&quot; on one line with no red
16:45matsbz: oh, and no border
16:53bzmats: the question is whether the first letter is red
16:53bzmats: in Chrome.
16:53bzmats: that is, do they apply the first-letter style for the display:contents thing?
16:53bzmats: (we do not)
16:54matsbz: they don&#39;t either, there is no red letter
17:00matsbz: fyi, &quot;Experimental Web Platform features&quot; in chrome://flags/ to enable it
17:24matsbz: filed https://bugs.webkit.org/show_bug.cgi?id=169612
18:38kekatweb-platform linter throws error from python on windows
18:39kekat&quot;WindowsError: [Error 193] <no description>&quot; details @ https://pastebin.mozilla.org/8982033
18:42kekatis it a known issue?
18:48kekatnvm bug 1336857
18:48firebothttps://bugzil.la/1336857 NEW, nobody@mozilla.org mach lint -l wpt fails on Windows with &quot;WindowsError: [Error 193] <no description>&quot;
15 Mar 2017
No messages
   
Last message: 159 days and 19 hours ago