IRC log of css on 2015-02-08

Timestamps are in UTC.

00:30:26 [tommyjtl]
tommyjtl has joined #css
00:47:49 [ojan]
ojan has joined #css
01:09:41 [florian]
florian has joined #css
01:16:47 [tantek]
tantek has joined #css
01:17:58 [tantek]
Greetings from outside 48
01:18:48 [tantek]
Inside now
01:20:38 [florian]
florian has joined #css
01:36:01 [florian]
florian has joined #css
01:36:14 [tantek]
tantek has joined #css
02:06:14 [florian]
florian has joined #css
02:50:04 [florian]
florian has joined #css
03:09:06 [tommyjtl]
tommyjtl has joined #css
03:09:22 [Florian_]
Florian_ has joined #css
03:15:04 [tantek]
tantek has joined #css
03:53:11 [SimonSapin]
plinss: could http://dev.w3.org/csswg/ be 301 redirects to https://drafts.csswg.org/ instead of a proxy?
03:53:21 [SimonSapin]
also, could http://drafts.csswg.org/ have HSTS?
03:54:17 [plinss]
SimonSapin: it’s possible to set up, but it’s better to keep the drafts in the w3.org URL space for persistence
03:54:43 [plinss]
the next option is to get css.w3.org … (which may be possible soon)
03:55:36 [plinss]
I can add HSTS but I need to be sure the dev.w3.org proxy is using https first
03:55:37 [SimonSapin]
apparently it’s hard to have HTTPS on dev.w3.org
03:57:05 [plinss]
yeah, the TAG has been discussing the issues with moving all of w3.org to https, too many existing links. But maybe we can get dev.w3.org moved
03:59:13 [SimonSapin]
Quoting: <MikeSmith> I'd rather we just quit using dev.w3.org altogether
04:18:21 [tommyjtl]
tommyjtl has joined #css
04:25:07 [fantasai]
Wait why is it a problem?
04:25:26 [fantasai]
Is it not possible to have http://dev.w3.org/ redirect to https://dev.w3.org?
04:28:09 [plinss]
yes, it can redirect, the problem is the millions of existing links to http://*.w3.org that will never get updated and will double the number of http roundtrips
04:28:25 [plinss]
for just dev.w3.org it shouldn’t be as big of a deal as all of w3.org
04:28:53 [plinss]
(if found out the other day the dev.w3.org/csswg is half the traffic of dev.w3.org)
04:29:04 [plinss]
s/if/I/
04:32:57 [liam]
with existing documents people would get stuck in redirect loops
04:33:02 [liam]
(it's been tried too)
04:33:54 [SimonSapin]
I also remember something about the hardware that runs dev.w3.org being old and dying, but I don’t see why it couldn’t be replaced
04:33:57 [liam]
we could have an outgoing apache filter that replaced https with https in static files but not in js so easily
04:34:07 [liam]
SimonSapin, given grants from Members, yes
04:34:25 [liam]
iirc the current hardware was supplied by HP in fact, although i might be a generation behind
04:35:12 [liam]
(or non-Members i suppose!)
04:36:35 [SimonSapin]
if it’s really a money question, I’d consider giving 10$ a month out of pocket for a Linode box
04:36:56 [liam]
no, not only $
04:37:14 [liam]
although that's kind of you :)
04:37:47 [fantasai]
csswg.org runs out of a linode box
04:38:19 [SimonSapin]
(my point was surprise that it would be a money question, given the price of servers these days)
04:39:24 [fantasai]
if people link to both equally, does it prefer https or http?
04:39:56 [SimonSapin]
http://googlewebmastercentral.blogspot.com.au/2014/08/https-as-ranking-signal.html
04:40:26 [plinss]
liam: FWIW, HP recently offered to donate a rack full of servers, and was politely refused… they went into the recycling bin
04:40:30 [liam]
SimonSapin, no, it's not even primarily money
04:40:37 [liam]
plinss, :( i'd have had them! :)
04:40:58 [liam]
(I don't know about that, so don't know why)
04:41:21 [liam]
fantasai, google has a guide on how to migrate from http to https
04:41:41 [liam]
they say you have to use redirects or you risk getting penalized for duplicate content
04:41:52 [liam]
but yes, prefer https
04:42:02 [liam]
(and what they say isn't necessarily the full sotry of course)
04:43:15 [liam]
the laptop i'm keeping going as long as possible though
04:45:04 [liam]
timbl did an experiment with an http header recently, the consequence of which is that anyone who read his email ended up getting blocked automatically from w3.org even if they didn't explicitly visit the test page
04:45:23 [liam]
(unclear if it was because browsers have a shared database, or ebcause of readahead)
04:51:07 [plinss]
heh, I was there. He added an HSTS header to a page, and that page redirected https to http
04:51:42 [plinss]
so every browser that visited the page would only visit the https url for the next year (until the hsts expired)
04:51:50 [liam]
yes
04:55:07 [fantasai]
liam: I think Google should just collapse the links on their own, it's silly not to
04:55:38 [fantasai]
liam: Theoretically one could serve different content to each, but it doesn't really make sense unless the http one is a redirect to the https :)
05:04:56 [SimonSapin]
fantasai: http://dev.w3.org/csswg/css-values/#custom-idents what does "positionally-ambiguous" mean compared to just "ambiguous"?
05:10:43 [tantek]
tantek has joined #css
05:17:20 [fantasai]
SimonSapin: I think it should say "positionally-variable values" instead of "positionally-ambiguous keywords"
05:17:31 [fantasai]
SimonSapin: Does that make sense? Should I make that change?
05:18:00 [SimonSapin]
fantasai: what does that mean? :)
05:18:10 [fantasai]
Means if you parse
05:18:16 [fantasai]
keyword || <custom-ident>
05:18:21 [fantasai]
or
05:18:25 [fantasai]
keyword && <custom-ident>
05:18:35 [fantasai]
order is not defined in these cases
05:18:53 [SimonSapin]
ok
05:19:26 [fantasai]
Feel free to suggest a better sentence :)
05:20:11 [SimonSapin]
is "positionally-variable" when the order *is* significant?
05:20:25 [SimonSapin]
unlike keyword || <custom-ident> or keyword && <custom-ident>
05:21:42 [SimonSapin]
or the opposite?
05:22:53 [fantasai]
opposite
05:24:31 [fantasai]
where the values can vary in their position
05:29:01 [SimonSapin]
Ok. I think what’s in the ED now contradicts what I remembered we discussed.
05:30:47 [fantasai]
I think we discussed a lot of things
05:31:06 [fantasai]
what do you think it should say?
05:38:53 [florian]
florian has joined #css
07:24:19 [fantasai]
fantasai has joined #css
07:28:47 [liam]
fantasai, agree re. http/https, and also not sure whether that was the main google crawlaer (i think so) or the adsense one
08:07:22 [antonp]
antonp has joined #css
08:11:07 [fantasai]
fantasai has joined #css
08:20:04 [antonp]
antonp has joined #css
08:36:24 [SimonSapin]
fantasai: In the same series: http://www.amazon.com/gp/aw/d/B002RI9VFI/
08:50:16 [dauwhe]
dauwhe has joined #css
10:01:54 [florian]
florian has joined #css
10:08:23 [florian]
florian has joined #css
10:09:51 [Florian_]
Florian_ has joined #css
10:17:34 [florian]
florian has joined #css
10:27:35 [Florian_]
Florian_ has joined #css
10:33:03 [Florian_]
Florian_ has joined #css
11:13:24 [Florian_]
Florian_ has joined #css
11:21:58 [Florian_]
Florian_ has joined #css
11:27:12 [Florian_]
Florian_ has joined #css
11:35:24 [florian]
florian has joined #css
11:52:07 [Florian_]
Florian_ has joined #css
12:18:22 [Florian_]
Florian_ has joined #css
12:29:45 [tantek]
tantek has joined #css
12:43:59 [zcorpan]
zcorpan has joined #css
12:44:35 [zcorpan]
hello sydney
13:28:07 [dael]
dael has joined #css
14:42:36 [Ms2ger]
Ms2ger has joined #css
15:06:56 [antonp1]
antonp1 has joined #css
21:33:06 [RRSAgent]
RRSAgent has joined #css
21:33:06 [RRSAgent]
logging to http://www.w3.org/2015/02/08-css-irc
21:33:14 [johanneswilm]
johanneswilm has joined #css
21:33:39 [glazou]
rrsagent, this meeting spans midnight
21:33:52 [glazou]
RRSAgent, make logs public
21:44:38 [cyril]
cyril has joined #css
21:44:52 [dino]
dino has joined #css
21:45:36 [xidorn]
xidorn has joined #css
21:49:55 [heycam]
heycam has joined #css
21:52:17 [glazou]
krit: you’re cheating ; I saw you have a bkfast at the bar downstairs :-)
21:59:38 [dbaron]
dbaron has joined #css
22:02:05 [kwkbtr]
kwkbtr has joined #css
22:03:43 [zcorpan]
zcorpan has joined #css
22:16:21 [heycam]
glazou, if there is space on the agenda today or tomorrow can we talk about the Font Loading API spec (status, discuss the current spec open issues)?
22:16:42 [glazou]
heycam: could you please add it to the agenda on the wiki?
22:17:24 [Florian]
Florian has joined #css
22:18:04 [dauwhe]
dauwhe has joined #css
22:18:12 [heycam]
glazou, oh, I can log into the wiki. ok :)
22:33:33 [cyril]
cyril has joined #css
22:34:16 [tantek]
tantek has joined #css
22:38:09 [jet]
jet has joined #css
22:38:14 [gregwhitworth]
gregwhitworth has joined #css
22:38:17 [glazou]
Steve Zilles, Adobe
22:38:23 [astearns]
Alan Stearns, Adobe
22:38:40 [gregwhitworth]
Greg Whitworth, Microsoft
22:38:55 [cyril]
Cyril Concolato, Telecom ParisTech, Observer
22:38:57 [johanneswilm]
johanneswilm has joined #css
22:39:01 [SteveZ]
SteveZ has joined #css
22:39:02 [dbaron]
Shinyu Murakami, Vivliostyle
22:39:06 [SteveZ]
Steve Zilles
22:39:06 [zcorpan]
Simon Pieters, Opera Software
22:39:08 [dauwhe]
Dave Cramer, Hachette Livre, interested in books
22:39:26 [AndreyR]
AndreyR has joined #css
22:39:34 [dino]
Dean Jackson, Apple
22:39:37 [Florian]
Florian Rivoal, Invited Expert
22:39:39 [glazou]
Daniel Glazman, Disruptive Innovations, co-chair
22:39:42 [AndreyR]
Andrey Rybka Bloomberg
22:39:50 [dbaron]
David Baron, Mozilla
22:39:51 [krit]
Dirk Schulze, Adobe
22:39:52 [johanneswilm]
Johannes Wilm
22:39:55 [tantek]
Tantek Çelik, Mozilla
22:39:55 [kwkbtr]
Toru Kawakubo, Vivliostyle
22:39:57 [jet]
Jet Villegas, Mozilla
22:40:06 [fantasai]
fantasai, Invited Expert
22:40:06 [TabAtkins]
Tab Atkins, Google
22:40:06 [Rossen]
Rossen Atanassov, Microsoft
22:40:08 [plinss]
Peter Linss, HP, co-chair
22:40:09 [dbaron]
Toru Kawakubo, Vivliostyle
22:40:19 [heycam]
Cameron McCormack, Mozilla
22:40:19 [xidorn]
Xidorn Quan, Mozilla
22:40:26 [birtles]
Brian Birtles, Mozilla
22:40:31 [rbyers]
Rick Byers, Google
22:40:33 [roc]
roc has joined #css
22:40:47 [roc]
Robert O'Callahan, Mozilla
22:40:59 [murakami]
murakami has joined #css
22:41:15 [tantek]
scribenick: tantek
22:41:16 [glazou]
https://wiki.csswg.org/planning/sydney-2015#proposed-agenda-topics
22:41:36 [iank]
Ian Kilpatrick, Google
22:41:49 [tantek]
glazou: first thing is figuring out the agenda for MT
22:41:57 [tantek]
W is for the FX task force
22:42:27 [tantek]
glazou: W is for the FX task force
22:42:35 [tantek]
glazou: I suggest we sort by priority
22:43:06 [tantek]
Dirk: what is closest to CR?
22:43:09 [tantek]
glazou: CSS3-UI?
22:43:16 [tantek]
dbaron: transitions
22:43:51 [tantek]
tantek: suggest prioritize things that require in-person diagrams
22:43:58 [tantek]
florian: maybe CSS inline
22:44:12 [vollick_]
vollick_ has joined #css
22:44:38 [tantek]
dauwhe: can we do that Tuesday?
22:44:58 [tantek]
glazou: there were people that wanted to discuss rounded display
22:45:10 [tantek]
glazou: watchfaces
22:45:51 [tantek]
tantek: CSS3-UI box-sizing intrinsic size would be good to discuss with SVG folks on Wednesday
22:46:06 [tantek]
glazou: CSS3 Text and Writing modes this afternoon (Monday)
22:46:18 [tantek]
florian: block ellipsis and fragmentation links?
22:46:45 [tantek]
tantek: ok with CSS3-UI tomorrow (Tuesday)
22:46:51 [tantek]
fantasai: dbaron had some 2.1 issues
22:47:04 [dbaron]
fantasai, which issues? The margin-collapsing one I haven't even sent email about yet?
22:47:12 [tantek]
glazou: heycam you had font-loading issues
22:47:28 [tantek]
heycam: wanted to ask the questions, updates, 20 min this morning on font-loading
22:47:46 [tantek]
glazou: 2.1, snapshot, 2.2 first public WD
22:47:56 [tantek]
fantasai: 2.1 technical issues and snapshot are separate topics
22:48:23 [tantek]
florian: media queries? not sure my priority
22:48:29 [fantasai]
s/snapshot/2.1+2.2+snapshot/
22:48:29 [tantek]
TabAtkins: yeah
22:48:47 [Florian]
s/not sure my/not super high/
22:48:51 [tantek]
glazou: TabAtkins you wanted to discuss ...
22:48:57 [tantek]
TabAtkins: I need 30-45 min on ...
22:49:13 [tantek]
glazou: Tuesday morning for @extend (?)
22:49:20 [tantek]
s/.../@extend
22:50:05 [tantek]
florian: multiline block ellipsis
22:50:13 [tantek]
florian: preferably not this morning
22:50:49 [tantek]
glazou: form styling controls - tomorrow afternoon
22:51:12 [tantek]
glazou: something for RoC
22:51:20 [tantek]
glazou: :for() for this morning
22:51:24 [heycam]
FYI, other FX topics have been gathered by the SVG WG here: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Agenda_proposals
22:51:32 [tantek]
glazou: prev-sibling and parent combinators also this morning
22:51:44 [tantek]
fantasai: ::marker pseudo-element 15 min
22:51:57 [tantek]
glazou: dbaron margin-collapsing part of 2.1
22:52:08 [tantek]
glazou: tab order display switch
22:52:18 [tantek]
astearns: I did that, does not really need discussion
22:52:45 [tantek]
glazou: flex-break topics?
22:53:00 [tantek]
astearns: tab order put it on overflow
22:53:07 [tantek]
plinss: 2.1 issues ?
22:53:19 [tantek]
fantasai: 2.1 issues let's do that this morning
22:53:21 [tantek]
tantek: agreed
22:53:40 [tantek]
florian: text-wrap balance ?
22:54:05 [tantek]
fantasai: css3 text level 4? 30 min?
22:54:13 [tantek]
fantasai: when doesn't matter
22:54:38 [tantek]
glazou: let's do that today
22:54:47 [tantek]
glazou: what is the agenda so far?
22:56:22 [tantek]
(lots of quiet typing)
22:57:05 [tantek]
fantasai: visible control characters falls under text
22:57:12 [tantek]
fantasai: margin-collapsing is part of 2.1 issues
22:57:40 [tantek]
astearns: flex-break controls could be part of text 4 discussion
22:58:16 [tantek]
fantasai: text-wrap balance should also be part of text level 4
22:58:29 [tantek]
Zakim, who is here?
22:58:29 [Zakim]
sorry, tantek, I don't know what conference this is
22:58:31 [Zakim]
On IRC I see vollick_, murakami, roc, AndreyR, SteveZ, johanneswilm, gregwhitworth, jet, tantek, cyril, dauwhe, Florian, zcorpan, kwkbtr, dbaron, heycam, xidorn, dino, RRSAgent,
22:58:31 [Zakim]
... Zakim, glazou, dwim1, hgl, antonp1, fantasai, ojan, krijnhoetmer, Rossen, shane, rbyers, dstockwell, krit, mvujovic______, ppk___, CSSWG_LogBot, liam, Rossen_, mihnea_____,
22:58:35 [Zakim]
... amtiskaw, iank, abucur___, birtles, robertknight_clo, ato, renoirb, koji, cabanier, astearns, sgalineau, slightlyoff, hober, shepazu, logbot, JonathanNeal_, timeless, jumland,
22:58:35 [Zakim]
... nikos
22:58:42 [tantek]
fantasai: css 2.2 should go with the snapshot
22:58:55 [tantek]
florian: can we put form controls in the overflow
22:59:34 [tantek]
tantek: form controls Tue PM?
22:59:55 [tantek]
plinss: css-sizing?
23:00:34 [tantek]
tantek: put it overflow
23:00:42 [tantek]
Rossen: put sizing Monday afternoon
23:00:55 [tantek]
plinss: Ruby?
23:01:39 [tantek]
glazou: upcoming meetings end of Tue afternoon
23:01:50 [tantek]
glazou: new publication system before that
23:02:32 [tantek]
plinss: visible control characters?
23:03:02 [tantek]
gregwhitworth: visible control characters part of text
23:03:20 [tantek]
plinss: we have an agenda?
23:03:25 [tantek]
glazou: how much time for 2.1 issues
23:03:28 [tantek]
Rossen: 11 years
23:03:37 [tantek]
… give or take
23:04:00 [tantek]
(display futzing)
23:04:45 [tantek]
glazou: first topic, 2.1 issues
23:04:55 [tantek]
fantasai: first issue, who will make the edits?
23:05:03 [tantek]
TabAtkins: it's in github now so anyone can do it
23:05:11 [tantek]
fantasai: I nominate SimonSapin
23:05:28 [tantek]
glazou: that's it?
23:05:37 [tantek]
dbaron: I had an issue I meant to send email about
23:05:42 [tantek]
… just sent 30 seconds ago
23:05:55 [tantek]
dbaron: I don't know if anyone would have understood it anyway
23:06:00 [tantek]
… since it is margin collapsing
23:06:08 [tantek]
glazou: do we need to call Håkon?
23:06:11 [dbaron]
https://lists.w3.org/Archives/Public/www-style/2015Feb/0189.html
23:06:13 [tantek]
dbaron: let's try to talk about this
23:06:22 [Florian]
s/Håkon/Anton/
23:06:26 [tantek]
… one of the discussions about margin collapsing
23:06:39 [tantek]
… we decided the prose in the spec was not very clear about transitivity
23:06:54 [tantek]
… e.g. if A collapse with B, and B collapse C, then A collapse with C
23:07:01 [tantek]
… if that's not true we need to define what it means
23:07:09 [tantek]
???: what makes you think it is not true?
23:07:22 [tantek]
dbaron: this guy writing reftest for margin collapsing daniels
23:07:23 [hyojin]
hyojin has joined #css
23:07:26 [tantek]
… does not believe this is true
23:07:34 [tantek]
… and a bunch of his tests match browser behavior
23:07:39 [tantek]
… I was trying to fix a bug
23:07:55 [tantek]
… that said min-height and max-height do not break margin-collapsing between the last child of a block and the ...
23:08:28 [tantek]
… min-height and max-height, even when they change the height, do not break margin-collapsing between the bottom margin of the last child of the block, and the bottom margin of the block
23:08:36 [tantek]
… I wrote a patch that fixed that
23:08:44 [tantek]
… it fixed those tests, but broke one other test
23:08:51 [tantek]
… that was interop in all engines
23:09:01 [tantek]
… however I could not figure out how the spec justifies that result
23:09:16 [tantek]
… What I'd like to know is, why does this test behave the way it does?
23:09:20 [tantek]
… either in engines or in the spec
23:09:22 [fantasai]
https://lists.w3.org/Archives/Public/www-style/2015Feb/0189.html
23:09:39 [dbaron]
https://lists.w3.org/Archives/Public/www-style/2015Feb/att-0189/block-no-content-8.html
23:09:39 [tantek]
… test: https://lists.w3.org/Archives/Public/www-style/2015Feb/att-0189/block-no-content-8.html
23:09:50 [tantek]
… reference: https://lists.w3.org/Archives/Public/www-style/2015Feb/att-0189/block-no-content-8-ref.html
23:10:04 [tantek]
dbaron: key question is gap between 2 and 3rd block
23:10:16 [tantek]
… 60 px between blocks 1,2
23:10:23 [tantek]
… 40 px between blocks 2, 3
23:10:33 [tantek]
… my patch makes it 60 px between blocks 2, 3
23:10:43 [tantek]
… but spec appears to say it should be -20px between blocks 2,3
23:11:07 [tantek]
… every margin in the test should collaps
23:11:15 [tantek]
s/collaps/collapse
23:11:34 [tantek]
dbaron: the interesting question is what happens between the green blocks
23:11:55 [tantek]
… blue has a min-height and a child
23:12:12 [tantek]
… spec says if it did not have a child, it's top / bottom margins would not collapse
23:12:28 [tantek]
… if you have a non-zero min-height and no children then margins do not collapse
23:12:49 [tantek]
… but in this case we have a block with min-height with a child
23:12:55 [tantek]
… all have top/bottom margins
23:13:07 [tantek]
… spec says they should all collapse
23:13:21 [tantek]
TabAtkins: is the confusing line why min-height has an effect with no children?
23:13:35 [tantek]
dbaron: spec's wording is weird, but I think I understand why
23:13:53 [tantek]
fantasai: (reads from 2.1 spec re: margin-collapsing)
23:15:36 [tantek]
dbaron: the thing with the min-height only applies when there's no children
23:15:53 [tantek]
florian: I'm actually confused, what can it mean for the top/bottom margin of the parent to collapse?
23:16:11 [tantek]
dbaron: there's a rule elsewhere that says where the block is when its top & bottom margins collapse
23:16:23 [tantek]
florian: is this useful for a block of non-zero height?
23:16:28 [tantek]
florian: that seems just weird
23:16:50 [tantek]
dbaron: yes. I would go further, not clear any use of top/bottom margins of the same block ever collapsing. but we're stuck with that
23:17:16 [tantek]
florian: to do so when the block has non-zero height is even worse
23:18:40 [tantek]
dbaron: (reads from 2.1 spec re: margin-collapsing)
23:18:45 [tantek]
… (bullet 1, bullet 2)
23:22:00 [tantek]
fantasai: the issue is we did not want to do partial collapsing (re: min-height), and decided to just do the stupid (obvious) thing instead
23:22:18 [tantek]
dbaron: I should do more playing around with this test case to see what happens in other browsers
23:22:43 [tantek]
fantasai: what is the interop on?
23:22:50 [tantek]
dbaron: this test case. 60 px above, 40px below
23:23:00 [tantek]
dbaron: margins 3 & 4 are not collapsing
23:23:17 [tantek]
fantasai: spec should say non-zero min-height means top/bottom margins do not collapse
23:23:31 [tantek]
florian: partial collapsing?
23:23:40 [tantek]
dbaron: I would fine if we modified the rule that ...
23:23:53 [tantek]
dbaron: It would be consistent to modify the 3rd bullet point in the nested list
23:24:00 [tantek]
… to say what it says already
23:24:41 [tantek]
… but add and "and the parent has zero computed min-height, or the bottom margin of the last inflow child does (not) collapse with the top margin of the element"
23:24:41 [tantek]
s/top/bottom
23:25:03 [tantek]
dbaron: 3rd bullet point
23:25:09 [tantek]
… bottom margin of last inflow child
23:25:11 [tantek]
… bottom margin of parent
23:25:14 [tantek]
… no longer collapse
23:25:18 [tantek]
… if the parent has non-zero min-height
23:25:28 [tantek]
… and the bottom margin of the last inflow child collapses with the top margin of the parent
23:26:13 [tantek]
fantasai: (explores another possibility)
23:26:53 [tantek]
fantasai: there's two definitions
23:26:58 [tantek]
… there's a definition for collapsing
23:27:02 [tantek]
… and a definition for adjoining
23:27:21 [tantek]
dbaron: no that sentence below makes adjoining transitive
23:27:59 [tantek]
fantasai: we know what we want to say now
23:28:05 [tantek]
… just need to work on phrasing it
23:28:17 [tantek]
dbaron: I think agreeing on what we want to say should involve more testing of what browsers do
23:28:27 [tantek]
fantasai: whatever it is it is an improvement over what's there
23:28:35 [tantek]
… (in the spec)
23:28:42 [tantek]
glazou: what is the resolution?
23:28:44 [tantek]
fantasai: what dbaron said
23:28:52 [tantek]
dbaron: we should tentatively agree to do that, but do more testing
23:29:19 [tantek]
glazou: what do people think? there were only 3 people discussing
23:29:28 [tantek]
glazou: any objection?
23:29:52 [tantek]
RESOLVED: tentatively do what we agreed, pending more testing
23:30:29 [tantek]
dbaron: I think the edit you fantasai proposed to make is already in the spec, the 3rd bullet.
23:30:36 [tantek]
dbaron: the way this is written is unclear
23:30:43 [tantek]
glazou: we have to move on
23:30:50 [tantek]
glazou: continue working on the issues
23:30:53 [tantek]
… or next topic
23:31:00 [tantek]
… in terms of 2.1 issues, what else?
23:31:16 [tantek]
glazou: dbaron @charset tests?
23:31:17 [glazou]
https://lists.w3.org/Archives/Public/public-css-testsuite/2015Jan/0016.html
23:31:44 [tantek]
dbaron: this was a message from hsivonen
23:31:55 [tantek]
… syntax level 3 changes rules for @charset
23:32:00 [tantek]
… there are tests in 2.1 repository
23:32:06 [tantek]
… that now test incorrect behavior
23:32:11 [tantek]
… we should fix the tests to match level 3
23:32:14 [tantek]
… and errata 2.1 as well
23:32:31 [tantek]
… it seems bad to have tests in the repo that are telling people to behave in a way not compat with level 3 latest spec
23:32:38 [tantek]
glazou: I agree let's fix both
23:32:41 [tantek]
fantasai: yes fix both
23:33:02 [tantek]
ACTION dbaron: propose errata for @charset in 2.1 that brings it into alignment with CSS3 Syntax
23:33:03 [trackbot]
Created ACTION-665 - Propose errata for @charset in 2.1 that brings it into alignment with css3 syntax [on David Baron - due 2015-02-15].
23:33:16 [fantasai]
ACTION fantasai: propose errata for margin collapsing issue
23:33:17 [trackbot]
Created ACTION-666 - Propose errata for margin collapsing issue [on Elika Etemad - due 2015-02-15].
23:33:26 [tantek]
glazou: will hsivonen fix the tests?
23:33:29 [tantek]
dbaron: probably?
23:33:36 [tantek]
jet: he has an open question at the bottom
23:33:48 [tantek]
fantasai: basically what we should be doing is errata'ing 2.1
23:33:52 [tantek]
… and fixing the tests
23:33:55 [tantek]
… backporting from 3 to 2
23:34:00 [tantek]
… fixing the ones in 2
23:34:04 [tantek]
… or getting rid of them
23:34:41 [tantek]
glazou: we have versions
23:34:41 [tantek]
fantasai: no we have levels
23:34:41 [tantek]
glazou: anything else on the 2.1 radar?
23:34:42 [tantek]
fantasai: dbaron?
23:34:48 [tantek]
dbaron: just a possible tornado and a few thunderstorms
23:35:02 [tantek]
SimonSapin: we discussed
23:35:07 [tantek]
… links to that spec
23:35:31 [tantek]
florian: so we should switch to snapshot topic
23:35:51 [SimonSapin]
SimonSapin: In CSS 2.x sections, add links to newer specs that replace them
23:35:56 [tantek]
zcorpan: anyone volunteer to edit the tests?
23:35:58 [tantek]
florian: you just did
23:36:03 [tantek]
zcorpan: I did? Ok I can do that
23:36:17 [tantek]
ACTION zcorpan edit CSS 2.1 @charset tests to make them compliant with CSS3 syntax
23:36:17 [trackbot]
Created ACTION-667 - Edit css 2.1 @charset tests to make them compliant with css3 syntax [on Simon Pieters - due 2015-02-15].
23:36:34 [glazou]
Topic: Font Loading API
23:36:37 [tantek]
heycam: test and tasks?
23:36:41 [astearns]
http://dev.w3.org/csswg/css-font-loading/
23:36:44 [tantek]
… (missed part of question)
23:36:52 [tantek]
TabAtkins: good question
23:37:26 [tantek]
heycam: there are many places in the spec where it says to queeue a task, and does not say why it is necessary, aor what the reuls are for why this operation should be done
23:37:31 [tantek]
s/reuls/rules
23:37:35 [tantek]
s/aor/or
23:37:49 [tantek]
TabAtkins: every time I do something it is observable, so it doesn't happen in the middle of some script
23:38:05 [tantek]
TabAtkins: you can't edit the font-faces attribute at some time because JS might be looking at that
23:38:16 [tantek]
heycam: for operations that are definitely going to wait for the network that makes sense
23:38:22 [tantek]
… but there are uses of that beyond wait for the network
23:38:27 [tantek]
TabAtkins: in the font-face loading algorithm
23:38:36 [tantek]
… we have two uses of delay task until parsing the font-data is done
23:38:48 [tantek]
… or parsing of strings too
23:38:58 [tantek]
heycam: parsing strings is pretty weak(?)
23:39:33 [tantek]
TabAtkins: I purposely moved those into the async section of the algorithm, and from the async section I cannot sync update something that is script visible.
23:39:43 [tantek]
TabAtkins: I have to queue a task
23:39:44 [astearns]
s/weak/quick/
23:39:45 [zcorpan]
s/weak(?)/quick/
23:40:02 [tantek]
heycam: can we discuss open issues in the spec?
23:40:12 [tantek]
heycam: issue 1: is about promise objects and internal set objects
23:40:18 [tantek]
… pristine copies of things
23:40:18 [astearns]
issue 1: http://dev.w3.org/csswg/css-font-loading/#issue-531209c4
23:40:31 [tantek]
heycam: that is not something the webIDL spec says ...
23:40:41 [tantek]
heycam: should happen automatically(?)
23:40:56 [tantek]
heycam: the other three issues I don't have an opinion on so we don't have to discuss them
23:41:16 [tantek]
heycam: another thing - question the usefulness of font-face-set being constructable, why you would want to do it?
23:41:25 [tantek]
TabAtkins: I know I had reasons for it, I think related to workers
23:41:31 [tantek]
TabAtkins: someone internally gave me a use case recently
23:41:43 [tantek]
… stash a bunch of fonts into a font-face-set, tell when they're ready,
23:41:48 [tantek]
… all the fonts loaded at the same time
23:42:00 [tantek]
heycam: could you not do that by creating separate font face objects
23:42:03 [tantek]
… do a promise.all?
23:42:07 [tantek]
TabAtkins: maybe?
23:42:22 [tantek]
… if there's no reason not to make something constructable, there's no reason to make it constructable
23:42:29 [tantek]
heycam: it would complicate my implementation
23:42:37 [tantek]
TabAtkins: so basically I should look for more use-cases for it
23:42:44 [tantek]
zcorpan: queue and task discussion
23:43:04 [tantek]
… if you select one, if it fails to parse, spec says to reject and set status to error
23:43:15 [tantek]
… then step 2, if it fails to parse, it says to queue a task
23:43:21 [tantek]
TabAtkins: because step 2 is async
23:43:31 [tantek]
zcorpan: should step 2 queue a task to reject?
23:43:42 [tantek]
TabAtkins: Rejection isn't observable to script until safe times anyway
23:43:59 [tantek]
zcorpan: what is the ordering between observing the rejection and the queuing … ?
23:44:07 [tantek]
… otherwise you can't read the status...
23:44:13 [tantek]
TabAtkins: this is true I should re-order those
23:44:38 [tantek]
zcorpan: there might be similar ordering issues elsewhere
23:44:38 [tantek]
TabAtkins: no the rest are fine
23:45:11 [tantek]
heycam: are any other implementers interested in this API?
23:45:16 [tantek]
TabAtkins: beyond google and mozilla?
23:45:28 [tantek]
heycam: this is based on an old draft right?
23:45:33 [tantek]
TabAtkins: no I don't think so
23:45:45 [tantek]
… someone recently changed … (?)
23:46:02 [tantek]
… if you know of anything not matching the spec or not matching your implementation, let us know
23:46:05 [tantek]
heycam: that's all I had
23:46:06 [tantek]
TabAtkins: ok
23:46:24 [tantek]
glazou: break. 15 min. no more.
23:46:31 [tantek]
glazou: we'll start again with selectors.
00:05:12 [dbaron]
ScribeNick: dbaron
00:05:23 [dbaron]
glazou: first topic is :for selector by Florian
00:05:26 [glazou]
https://lists.w3.org/Archives/Public/www-style/2014Dec/0064.html
00:05:29 [dbaron]
:for()
00:05:41 [dbaron]
Florian: spun out of earlier discussion on :focus-within
00:05:51 [johanneswilm]
johanneswilm has joined #css
00:06:02 [dbaron]
Florian: when writing form controls in HTML, can hav labels associated with inputs, either by putting input inside label, or using for attributeand pointing to id of form element
00:06:14 [dbaron]
Florian: there's a bunch of state the form input can be in that you use for styling, e.g., invalid
00:06:31 [dbaron]
Florian: demand from authors to also style label that goes with the form, based on these states (focus, active, disabled, invalid, etc.)
00:06:52 [dbaron]
Florian: proposal is to have a functional pseudo-class that lets you point "label for this contnorl :disabled"
00:06:57 [dbaron]
Florian: then can style label
00:07:17 [dbaron]
Florian: last time wasn't clear authors wanted it, went and found requests on stackoverflow for it
00:07:23 [dbaron]
fantasai: why can't we just propagate the state to the label?
00:07:32 [jdaggett]
jdaggett has joined #css
00:07:32 [dbaron]
Florian: because that is defined in HTML and Hixie's not interested
00:07:39 [dbaron]
fantasai: that's ridiculous
00:08:01 [dbaron]
Simon: I don't that's the best reason; another reason is that content today uses the pseudo-classes and expects it to apply only to the inputs and not the lables
00:08:16 [dbaron]
Florian: also there's a small but worrying-to-some performance impact
00:08:24 [dbaron]
Florian: which makes only the people interested in using this bear this cost
00:08:33 [dbaron]
Florian: you can potentially associate a thousand labels with a single form element
00:08:53 [fantasai]
fantasai, tantek^: that's a much better reason
00:09:00 [dbaron]
Florian: corner case ...
00:09:09 [dbaron]
Tantek: otherwise difficult to describe with existing selectors
00:09:21 [dbaron]
Florian: people sometimes use hacks to put label after, use + selector, and then float to put label where they want it
00:09:31 [dbaron]
Tantek: corrupts the natural order of the marku, which we should seek to avoid
00:09:37 [dbaron]
Tantek, glazou: I support this
00:09:50 [fantasai]
dbaron: What is the syntax?
00:09:55 [fantasai]
dbaron: :for(<selector>)?
00:10:11 [dbaron]
fantasai: don't want an ID
00:10:12 [fantasai]
florian: Could do that, or just put an ID
00:10:26 [dbaron]
fantasai: You want to style these things generically.
00:10:34 [andreyr_]
andreyr_ has joined #css
00:10:42 [dbaron]
Tantek: doesn't have to be a label?
00:10:48 [dbaron]
Florian: for attribute only exists on labels
00:10:55 [dbaron]
Tantek: doesn't have to...
00:11:00 [dbaron]
PeterL: could define more generically
00:11:10 [kwkbtr]
kwkbtr has joined #css
00:11:22 [dbaron]
Florian: The way :for() associates is up to the host language.
00:11:34 [dbaron]
fantasai: for HTML, it's the for attribute or containment
00:11:49 [dbaron]
Florian: yes, HTML does by nesting or attribute; other languages can do as they want
00:11:55 [dbaron]
peterl: we should leave it defined by the host language
00:12:13 [dbaron]
peterl: if it's not clear enough for HTML we should say what HTML does, but leave it defined by host language
00:12:41 [dbaron]
gregwhitworth: IE already does this, and we've gotten no bugs
00:12:51 [glazou]
s/peterl/plinss
00:13:01 [dbaron]
Florian: In IE, :active and :focus propagate from HTML to control. IE does that *and* the other way around.
00:13:13 [dbaron]
s/In IE/In HTML spec/
00:13:25 [dbaron]
Florian: we previously resolved the IE way was good, I was actioned to go to Hixie, he disagreed
00:13:58 [dbaron]
Florian: :hover and :active (not :focus?)
00:14:24 [dbaron]
Florian: I don't think IE does it for :invalid, :disabled, and all the others
00:14:52 [dbaron]
glazou: I didn't get an answer to question: :for() pseudo that initially works only in HTML because knowledge of the for atttribute comes from above and will not appear in the UA stylesheet or anywhere.
00:15:15 [dbaron]
glazou: Two ways to do that: more generic, or with for attribute mentioned.
00:15:26 [dbaron]
glazou: My opinion is for attribute mentioned is better because applies to more languages.
00:15:42 [dbaron]
glazou: I want to avoid the mess of the class selector where class was originally defined only for HTML and not other languages.
00:15:54 [dbaron]
Florian: Should be at least for attribute in HTML
00:15:57 [dbaron]
fantasai: and containment
00:16:15 [dbaron]
Florian: Could also extend in HTML where a form control is for its form.
00:16:20 [dbaron]
fantasai: or fieldset
00:16:36 [dbaron]
fantasai: Initial preference would be to propagate state out to fieldset, label, form
00:16:48 [dbaron]
fantasai: If we can't do that b/c of web compat then I'd support other syntax
00:16:53 [johanneswilm]
johanneswilm has joined #css
00:16:57 [dbaron]
fantasai: I think :for() syntax is vague and confusing, but in favor of solving problem
00:16:59 [dbaron]
glazou: agreed
00:17:07 [dbaron]
Florian: I don't think syntax is so ugly, but not married to it.
00:17:21 [dbaron]
glazou: :for() seems to me confusing, esp. if generic enough that it could be an attribute other than for
00:17:40 [dbaron]
Florian: If you don' tthink of attribute for, but just the English word, "the label for invalid things".
00:17:49 [dbaron]
Simon: why are we discussing extending this to fieldset and form as well?
00:18:00 [dbaron]
fantasai: You might want to style form / fieldset if any control is invalid
00:18:11 [dbaron]
Simon: the research was for labels, not fieldsets and forms
00:18:24 [dbaron]
Florian: But styling form that contains something invalid is not science fiction.
00:19:01 [dbaron]
Tantek: need for something to change somewhere else -- label is most obvious example. Focus in text input-- label most obvious, but might also have help text that showsup. Having that trigger without JS is helpful; can't do that right now.
00:19:13 [dbaron]
Tantek: My concern is that feature is too limited in scope to just handling HTML Label for.
00:19:32 [dbaron]
Tantek: Other use cases in forms: help text, hover causing information to show up elsewhere. I don't want to preclude those with narrow definition.
00:19:56 [dbaron]
Florian: If we define it to work #1 for for attribute #2 for nesting control in label, fieldset, and then leave room for future extensions maybe through @-rule.
00:20:04 [dbaron]
Tantek: Already have selector in :for()
00:20:12 [dbaron]
Florian: One part is state, other part is associating element.
00:20:21 [dbaron]
Florian: Current proposal relies on association being done already.
00:20:36 [dbaron]
Tantek: Don't need association; could just apply to all labels.
00:20:58 [dbaron]
fantasai, Florian: You need an association.
00:21:04 [dbaron]
Florian: Which label is for the form control.
00:21:23 [dbaron]
fantasai: Don't want to make the associated between the label and the input in the CSS file, with separate rules for each form control.
00:21:28 [dbaron]
s/ated/ation/
00:22:02 [dbaron]
Florian: There are 2 levels, a mechanism for associating. We currently have a label<->control mechanism. Other is using existing associated to match states and propagate states along existing association. I'm only talking about altter.
00:22:24 [dbaron]
Florian: That said, happy to use combinator instead of pseudo, etc. Just functionality I'm after.
00:22:34 [dbaron]
Florian: In previous life existing as /for/.
00:22:44 [dbaron]
Florian: confused by what other word could go there
00:22:54 [dbaron]
fantasai: That wasn't for any attribute; it was for an idref attribute.
00:23:06 [tantek]
Florian, the link from your email for TabAtkins's example is 404: https://www.dropbox.com/s/cyu9je5a6cvolyf/Screenshot%202014-12-03%2023.51.47.png?dl=0
00:23:32 [dbaron]
Tantek: let's look at your real-world example
00:24:07 [TabAtkins]
http://www.xanthir.com/recipes/showrecipe.php?id=55
00:24:15 [dbaron]
Florian: In Tab's site in the example, he has convoluted markup because he doesn't have this.
00:24:29 [dbaron]
Tab: If you click on ingredients they get crossed out, done through CSS; had to do weird things.
00:24:40 [dbaron]
Tantek: label around input isn't weird
00:25:00 [dbaron]
Tab: I forget what was weird.
00:25:06 [dbaron]
Florian: There was something wrong; maybe fixed since?
00:25:39 [dbaron]
(multiple conversations)
00:25:49 [dbaron]
Florian: I think we can put an action on this to construct a document that would benefit.
00:25:57 [dbaron]
Tab: there are tons of examples on stackoverflow
00:26:27 [dbaron]
Tab: I don't think there's a need for more discovery.
00:26:39 [dbaron]
Tantek: I'm just looking for a sample simple document that would benefit.
00:26:52 [dbaron]
glazou: I'd rather see Florian spend time on the technical proposal and us on reviewing and getting feedback.
00:26:53 [andreyr_]
+1 for technical proposal
00:27:02 [dbaron]
glazou: I almost see it as a blocking tactic.
00:27:25 [dbaron]
Tantek: It's not a blocking tactic. If we don't have a markup to look up then we don't know if it can be solved with existing selcetors or others that are being proposed.
00:27:44 [dbaron]
Florian: Last time I proposed this, it stopped with request to go look up examples. I did.
00:28:16 [dbaron]
glazou: Tantek, let's try to find the best design without looking at the markup.
00:28:22 [dbaron]
Tantek: ok
00:28:45 [dbaron]
fantasai: resolution is we agree we should do something, not convinced about this particular proposal. Maybe come up with something easier to understand?
00:29:00 [dbaron]
glazou: Florian was looking for approval to continue working
00:29:14 [dbaron]
glazou: I think discussion shows interest from WG. Doesn't say we'd eventually accept poposal.
00:29:31 [dbaron]
Tantek: I think can make stronger statement: best proposal we've seen so far. If a better alternative shows up we can debate that later.
00:29:44 [dbaron]
glazou: Any objection to Florian spending time spec'ing this?
00:29:48 [tantek]
+1 on more formal proposal
00:29:54 [dbaron]
fantasai: This would go in selectors level 4.
00:29:56 [dbaron]
fantasai: This would go in selectors level 5.
00:30:06 [dbaron]
fantasai: Level 4 needs to be trimmed down and pushed out.
00:30:18 [dbaron]
RESOLUTION: Florian to work on :for() or whatever it is.
00:30:38 [dbaron]
zcorpan: for :active and :hover, we have 2 behaviors. We have IE going 2 ways and others going 1 way (with HTML spec).
00:30:52 [dbaron]
Florian: We previously resolved it should go 2 ways but failed to convince Hixie.
00:31:05 [dbaron]
zcorpan: Then the correct next spec is violating the HTML spec in other browsers and then getting the spec changed.
00:31:16 [dbaron]
Tantek: Other step is to propose patch to HTML.
00:31:45 [dbaron]
Tantek: Could submit that to the HTML Working Group. I could help liaison that.
00:31:57 [dbaron]
Tantek: If there's consensus there...
00:32:07 [dbaron]
Florian: Does it help in the WHATWG to get HTMLWG to accept it?
00:32:10 [dbaron]
Tantek: sometimes
00:32:26 [dbaron]
Tantek: If browsers respond to that, Hixie will likely spec it.
00:32:47 [glazou]
Topic: Prev-sibling and parent combinators - allow :has() with some combinators in fast profile?
00:33:01 [dbaron]
glazou: Next, previous-sibling and parent combinators - [copy above]
00:33:10 [dbaron]
Tab: say you have elements #foo and #bar
00:33:30 [dbaron]
Tab: Can already select #bar if it has #foo as previous sibling
00:33:39 [dbaron]
Tab: with :has combinator
00:33:44 [fantasai]
Tab: #foo ~ #bar
00:33:58 [fantasai]
Tab: #foo:has(~#bar)
00:34:19 [dbaron]
Tab: if we allow :has can select #foo if bar as a following sibling, though only in fast profile
00:34:50 [dbaron]
Tab: Benjamin came up with a fun example, which is that you can write :nth-last-child(2 of #foo, #foo ~ bar), which is equivalent
00:36:20 [dbaron]
Tab: (explains how these are equvialent)
00:36:20 [dbaron]
Tab: not quite a general previous-sibling combinator; we're back-dooring it in in the fast profile
00:36:45 [fantasai]
ScribeNick: fantasai
00:37:15 [fantasai]
dbaron: I'm skeptical about moving too quickly here
00:37:20 [fantasai]
dbaron: You have one impl that has done this
00:37:40 [fantasai]
dbaron: The other thing I'm worried about is I would like the perf characteristics of selectors to be visible to authors when they're using them
00:37:52 [fantasai]
dbaron: Some of them look scarier than others, and you want the slow things to look scarier than the fast things.
00:38:20 [fantasai]
TabAtkins: :has() with combinator is not available in CSS, only for querySelector
00:38:34 [fantasai]
TabAtkins: But you can do the :nth-last-child( of ) today in CSS
00:38:44 [fantasai]
dbaron: This is only :has() for siblings, not for descendants
00:38:50 [fantasai]
dbaron: Which is the more expensive case
00:39:02 [fantasai]
TabAtkins: bzbarsky said looking for a parent shouldn't be too expensive
00:39:11 [fantasai]
TabAtkins: Just going to the parent addresses the vast majority of cases
00:39:29 [fantasai]
Florian: What is your proposal for this? Allow general syntax, or having special syntax?
00:39:37 [fantasai]
TabAtkins: Allowing special-cased things might also be okay
00:39:44 [fantasai]
TabAtkins: e.g. :hasChild()
00:39:52 [fantasai]
dbaron: If I wanted to implement :has() for selector matching
00:40:04 [fantasai]
dbaron: I'd probably want to rewrite it internally to look like the subject indicator
00:40:08 [fantasai]
dbaron: Although I'm not sure
00:40:19 [fantasai]
dbaron: I don't know if that has too many implications
00:40:36 [fantasai]
dbaron: subject indicator is more straightforward
00:40:52 [fantasai]
dbaron: doesn't allow branching
00:41:00 [fantasai]
TabAtkins: Does in combination in :matches()
00:41:10 [fantasai]
dbaron: Lots of new stuff without much impl experience...
00:41:17 [fantasai]
TabAtkins: People really want prev sibling and parent
00:41:32 [fantasai]
TabAtkins: Arbitrary ancestor is kindof not great, but the other two are not too bad perf-wise
00:41:37 [fantasai]
TabAtkins: I think we should llow them
00:41:50 [fantasai]
TabAtkins: At least direct previous direct sibling
00:42:29 [fantasai]
dbaron: Having some reasonable syntax that allows just parent and sibling doesn't seem too bad
00:42:39 [fantasai]
TabAtkins: ... specialized syntax like :hasSibling :hasChild
00:42:51 [fantasai]
fantasai: I don't like that, I think we should just say that you have to have a combinator at the beginning of :has()
00:43:18 [fantasai]
zcorpan: a < foo
00:43:27 [fantasai]
fantasai: Um, no I don't think that's great
00:43:33 [fantasai]
TabAtkins: a - foo
00:43:42 [fantasai]
TabAtkins: it's got parsing issues, have to require white space.
00:44:58 [fantasai]
[discussion of syntax]
00:45:01 [dbaron]
astearns: problem with :has is you have to explain which versions of :has() work in a stylesheet and which don't
00:45:06 [dbaron]
ScribeNick: dbaron
00:45:14 [dbaron]
Florian: ?
00:45:23 [dbaron]
fantasai: people will end up chaining to multiple levels of :has-child
00:46:08 [fantasai]
Whiteboard says:
00:46:15 [fantasai]
#foo:has(~#bar)
00:46:24 [fantasai]
:nth-last-child(2 of #foo, #foo~bar)
00:46:39 [dbaron]
Florian: we just discovered that this part of :has() is fast enough to be in the fast profile. If we've already allowed :has(), changing which subset sounds...
00:46:42 [fantasai]
1) a:has(> foo) a:has(+foo)
00:46:52 [fantasai]
2) a:has-child(foo) a:has-next-sibling(foo)
00:46:58 [dbaron]
Tab: I doubt there's such subdivisiions. ??? ???
00:47:06 [fantasai]
a:has(>foo>bar) vs a:has-child(foo:has-child(bar))
00:47:09 [dbaron]
Tab: I don't know if we want to first poll to see if we want to allow this, which syntax we prefer
00:47:18 [dbaron]
Florian: Do we have hope we'll one day we'll make :has fast enough.
00:47:30 [dbaron]
fantasai: Totally possible, just have to do some fancy caching
00:47:32 [dbaron]
dbaron: disagree
00:47:47 [dbaron]
Florian: if people write uses that don't work and depend that they don't work then we can't activate it anymore
00:48:02 [dbaron]
fantasai: as long as you put a combinator in the front then you're in one of the safe cases
00:48:12 [dbaron]
Tab: no, you have to require all combinators on restricted list
00:48:22 [dbaron]
SimonSapin: do we allow more combinators inside ??? with (2)
00:48:43 [dbaron]
Tab: maybe lalow child combinators in :has-child() and sibling combinators in :has-sibling()
00:48:55 [dbaron]
Tab: or maybe just disallow nesting of :has-pseudoclasses
00:49:16 [dbaron]
Tab: dunno if looking arbitrariryl far distance into ancestorswith terrible selectors is something we want to allow
00:49:33 [dbaron]
Florian: for future-compat I'm not in favor of option (1)
00:49:46 [dbaron]
fantasai: selectors are agressive about being invalid; throws out entire rule...
00:49:50 [dbaron]
fantasai: you'd notice
00:49:59 [SimonSapin]
s/inside ???/inside the parentheses/
00:50:00 [dbaron]
Florian: wouldn't count on that; definitely wouldn't want to make that rule start matching later
00:50:38 [dbaron]
Tab: objections to concept still?
00:51:02 [fantasai]
dbaron: I want to think about it more
00:51:19 [fantasai]
dbaron: There's a lot of stuff with a lot of interesting per fimplications in selectors currently, not much use/testing/impl yet
00:51:32 [fantasai]
dbaron: I'm not okay with it yet, I might after thinking about it some more
00:51:52 [fantasai]
fantaai: I also think you shoudl get some authors to look into this
00:52:09 [fantasai]
fantasai: The syntax proposed looks horrible
00:52:43 [dbaron]
Tab: dbaron and bz review for performance characteristics?
00:52:57 [dbaron]
Tab: we discussed before, but wasn't seriously proposing it before; now I'm seriously proposing it
00:53:46 [dbaron]
ACTION dbaron review performance characteristics of parent and previous-sibling combinator, potentially combinable
00:53:46 [trackbot]
Created ACTION-668 - Review performance characteristics of parent and previous-sibling combinator, potentially combinable [on David Baron - due 2015-02-16].
00:53:47 [fantasai]
Agenda+ <custom-ident> please :)
00:54:16 [dbaron]
glazou: Next item on agenda is ::marker
00:54:36 [dbaron]
fantasai: been in lists spec for a while. Don't have concrete lists spec. A lot of issues on positioning; not well nailed down.
00:54:44 [dbaron]
fantasai: 2 main use cases for ::marker are changing color and font
00:55:00 [dbaron]
fantasai: I think those are reasonable without entire spec, could define in pseudo-elements spec without colors and fonts
00:55:56 [dbaron]
fantasai: proposal is add ::marker to pseudo-elements spec, takes properties from color module and fonts module (color, font-*, and opacity)
00:55:59 [dbaron]
roc: why not opacity?
00:56:03 [dbaron]
s/not //
00:56:08 [dbaron]
fantasai: Can just do rgba()
00:56:39 [dbaron]
fantasai: color property and font properties
00:56:52 [dbaron]
Tantek: people want marker closer, etc.
00:56:58 [dbaron]
fantasai: We just want to postpone that.
00:57:07 [fantasai]
fantasai: Involves kspeccing the layout details
00:58:12 [dbaron]
RESOLVED: Add ::marker with font properties and color to pseudo-elements spec (and still plan to do more later in the lists spec).
00:59:34 [dbaron]
dbaron: want to defer transitions, fx day is fine
00:59:40 [dbaron]
glazou: text level 4, text-wrap: balance
00:59:55 [fantasai]
http://dev.w3.org/csswg/css-text-4/
01:00:00 [dbaron]
fantasai: astearns and I drafted a placeholder for text level 4. We pasted in stuff that was pulled out of level 3.
01:00:11 [dbaron]
fantasai: These are all pretty fuzzy.
01:00:32 [dbaron]
fantasai: The stuff that's in there is basically splitting whitespace into 2 separate properties: text-space-collapse and text-wrap.
01:00:40 [dbaron]
fantasai: and adding a new text-space-trim property
01:01:07 [dbaron]
fantasai: features that were deferred are ability to discard whitespace and ability to trim whitespace just inside element, or just before/after element (needed for footnote formatting).
01:01:39 [dbaron]
fantasai: a couple issues on last line length that were requested, extra hyphenation controls (hyphenate-limit-{zone,chars,lines,last})
01:01:43 [johanneswilm]
johanneswilm has joined #css
01:01:53 [dbaron]
fantasai: string justification for tables deferred from level 3
01:02:04 [dbaron]
fantasai: text-spacing property that deals with East Asian stuff not fully worked out yet
01:02:10 [dbaron]
fantasai: and text-wrap property has 2 new values
01:02:16 [astearns]
http://dev.w3.org/csswg/css-text-4/#text-wrap
01:02:27 [dbaron]
fantasai: one ofthem proposed is text-wrap: avoid value, which says please don't break me, but if I don't fit on the line, then break
01:02:38 [dbaron]
fantasai: allows more controlled breaking with phrase-sensitivity
01:02:47 [dbaron]
Florian: example using it on an Address
01:03:01 [dbaron]
(rapid conversation)
01:03:20 [dbaron]
fantasai: more control than just <wbr> inside of nowrap; here you can use nesting to provide prioritization)
01:03:29 [dbaron]
fantasai: was in level 3, were some issues, maybe w.r.t. inheritance
01:03:47 [dbaron]
fantasai: so needs to be pulled into separate property
01:04:02 [dbaron]
fantasai: then there's the text-wrap: balance property, which only works onblocks with direct line box descendants
01:04:05 [dbaron]
fantasai: and inherits
01:04:09 [dbaron]
astearns: whole spec is a diff spec
01:04:40 [dbaron]
fantasai: There's stuff here that definitely needs work. Feedback: what to do with it? Suggestions on directions?
01:05:00 [dbaron]
Florian: for balance specifically, had comments,but spec now took feedback
01:05:04 [dbaron]
Florian: havn't reviewed rest
01:05:12 [dbaron]
Florian: this should slowly be worked on
01:05:29 [dbaron]
astearns: of all the things in the spec at the moment, text-wrap avoid and balance are the ones developers are calling for most strongly
01:05:51 [dbaron]
fantasai: A related issue is dealing with break-inside/break-after.
01:06:11 [dbaron]
astearns: one issue with text-wrap: avoid is whether it should be tied in with break-avoid properties which have a few more settings that you can use
01:06:45 [dbaron]
astearns: my take is that block breaking and inline breaking should be separately controllable things, because inline breaking almost always has to do with text-wrap, it's not a great thing to graft the same block-avoid/break properties onto inline wrapping
01:06:54 [dbaron]
astearns: if anyone has contrary idea, we should discuss
01:07:24 [dbaron]
fantasai draws:
01:07:44 [dbaron]
text-wrap: avoid vs. break-inside: avoid vs. new property
01:08:16 [xidornq]
xidornq has joined #css
01:08:16 [dbaron]
inheritance BAD traditionally for block axis
01:08:39 [dbaron]
fantasai: I think we can't use text-wrap: avoid because text-wrap inherits
01:08:49 [dbaron]
fantasai: so I think it has to be break-inside: avoid or a new property
01:09:05 [dbaron]
fantasai: astearns, you're suggesting don't want break-inside:avoid
01:09:14 [dbaron]
fantasai: so we need a new property; don't know the name. wrap-inside?
01:09:25 [dbaron]
astearns: I'm not sure text-wrap: avoid inheriting is a terrible thing.
01:10:28 [dbaron]
fantasai: text-wrap: avoid inheriting means that with <span> ... <em>Yo!</em> ... </span>, means that breaks not inside the em will be preferred over breaks inside the em.
01:10:56 [dbaron]
astearns: the example you added relies on inheriting, so in some cases it's good
01:11:14 [dbaron]
johanneswilm: so avoid doesn't actually mean avoid, it means ...
01:11:19 [dbaron]
fantasai: it means avoid, not forbidden
01:11:32 [dbaron]
fantasai: we have that, it's called nowrap
01:11:57 [tantek]
dbaron: my understanding is you want something where nested avoids increase the priority
01:12:04 [tantek]
dbaron: and you can't do that with inheritance
01:12:15 [tantek]
fantasai: you do want nesting to increase the priority
01:12:25 [tantek]
TabAtkins: I can see math structures wanting to do that
01:12:34 [tantek]
dauwhe: would you need to set explicit priorities on various things?
01:12:40 [tantek]
TabAtkins: you just wrap extra wrappers
01:12:43 [dbaron]
johanneswilm: couldn't you have numbers on it?
01:12:53 [dbaron]
fantasai: then you have the z-index problem with really big numbers
01:13:14 [dbaron]
fantasai: and most cases with this sort of wrapping, there's a hierarchical structure, where using avoid takes care of it for you
01:13:26 [dbaron]
fantasai: we might need priorities in addition to nesting, but nesting takes care of most cases
01:13:50 [dbaron]
johanneswilm: so if I have a span and would prefer no breaks inside of it, but inside the em, I'd prefer the break inside the em, how would I express that?
01:14:21 [dbaron]
Tab: could put avoid on spans that are siblings of the em
01:15:30 [dbaron]
fantasai: inheritance makes it convenient, says every additional element increases avoidance
01:15:41 [dbaron]
fantasai: in simple cases like a headline, don't have any extra markup
01:16:21 [dbaron]
fantasai: if you have a footer on a slideshow: date, location, talk title: each individually should stay together, but links inside that shouldn't increase avoidance
01:16:36 [dbaron]
astearns: definitely cases where it's convenent to inherit, but might be inconvenient
01:16:58 [dbaron]
s/might/not where might/
01:17:12 [dbaron]
fantasai: because most markup corresponds to things that mean things
01:17:21 [dbaron]
SteveZ: (something about a URL)
01:17:43 [dbaron]
SteveZ: but in that case can also label the URLs as text-wrap: ???
01:17:58 [dbaron]
s/???/normal/
01:18:42 [dbaron]
fantasai: so should either be text-wrap: avoid or a separate property
01:18:56 [dbaron]
SteveZ: turning it the other way around, why do I need the other property
01:19:17 [dbaron]
fantasai: easier to turn on inheritance than it is to turn it off
01:19:59 [fantasai]
dbaron: Weird to inherit
01:20:14 [fantasai]
dbaron: MOdel we have is that adding inlines or blocks with no styling is essentially a no-op
01:20:21 [fantasai]
dbaron: This breaks that model
01:20:55 [dbaron]
astearns: haven't specified that it increases
01:21:02 [dbaron]
dbaron: yeah, if there's only one level of avoidance it's not a problem
01:21:33 [dbaron]
johanneswilm: say I have a book title with subtitle. I'd prefer whole thing not to be broken, but if it needs to be broken, I'd prefer break between title and subtitle. How would I do that.
01:21:41 [dbaron]
fantasai: mark up title and subtitle in separate spans
01:21:57 [dbaron]
fantasai: and a span around both
01:22:28 [dbaron]
astearns: so should specify priority increases
01:22:44 [dbaron]
astearns: and then question of whether that requires text-wrap: avoid at the top, or in 3 places
01:22:53 [dbaron]
fantasai: I think dbaron's point important, and requires a separate property.
01:23:02 [dbaron]
astearns: text-wrap is a new property -- why can't it just not inherit?
01:23:14 [dbaron]
fantasai: wrap value and nowrap value must inherit
01:23:28 [dbaron]
fantasai: or we could just stick with white-space, and have text-wrap only controlling avoidance behavior
01:23:54 [dbaron]
Florian: {asks question}
01:24:01 [dbaron]
fantasai: text-wrap is a longhand of shorthand white-space
01:24:10 [dbaron]
fantasai: and 'none' value should have been 'nowrap'
01:24:47 [astearns]
http://dev.w3.org/csswg/css-text-4/#white-space-property
01:24:57 [sgalineau]
zcorpan: fails for me too
01:25:02 [dbaron]
astearns: there's handwaving about the shorthand in the intro section; I'd be happy not making shorthand
01:25:05 [glazou]
zcorpan: seems down for me too
01:25:19 [gregwhitworth]
gregwhitworth has joined #css
01:25:38 [glazou]
zcorpan, tantek: ERROR 503: Service Temporarily Unavailable
01:25:49 [dbaron]
drafts.csswg.org seems to be down, peterl?
01:26:05 [dbaron]
fantasai: You don't want to define one property that always overrides another
01:26:25 [dbaron]
SteveZ: dbaron's principle requires that nowrap inherit and requires that avoid not inherit
01:26:30 [dbaron]
fantasai: I think we need a sepraate property for avoid
01:26:37 [dbaron]
seems up now, though
01:27:45 [dbaron]
SteveZ: part of problem is that we can't use avoid-break in -- two breaks that could avoid, blocks or lines, and don't know which is intended.
01:28:03 [dbaron]
SteveZ: With the fragmenting spec, we've been trying to get generic terminology that applies, and here that doesn't quite work.
01:28:18 [dbaron]
SteveZ: I wonder if there are other places where there are multiple possible fragmentations at the same time.
01:28:22 [dbaron]
fantasai: yes, flexbox has lines
01:28:31 [dbaron]
fantasai: we could use same properties for flex lines as for text
01:28:42 [dbaron]
SteveZ: introduce a new property that had more than one use?
01:28:47 [dbaron]
fantasai: wrap-inside wrap-before wrap-after?
01:29:02 [dbaron]
dauwhe: that sounds almost useful to me
01:29:23 [dbaron]
fantasai: works for me
01:29:26 [dbaron]
astearns: try fleshing it out?
01:29:37 [dbaron]
fantasai: we'll take an action to update spec
01:30:14 [dbaron]
ACTION fantasai and astearns to try fleshing out spec for wrap-inside wrap-before wrap-after in css-text-4
01:30:15 [trackbot]
Created ACTION-669 - And astearns to try fleshing out spec for wrap-inside wrap-before wrap-after in css-text-4 [on Elika Etemad - due 2015-02-16].
01:30:28 [dbaron]
fantasai: Topic: white-space
01:30:56 [dbaron]
fantasai: white-space: normal | nowrap | pre | pre-line
01:31:09 [dbaron]
fantasai: |-- text-wrap: nowrap | normal
01:31:32 [dbaron]
fantasai: |-- text-space-collapse: collapse | discard | preserve | preserve-breaks
01:32:16 [dbaron]
fantasai: text-space-trim: none | trim-inner || consume-after || consume-before
01:32:30 [dbaron]
fantasai: white-space controls two different things, collapsing and whether text is allowed to wrap
01:32:45 [dbaron]
fantasai: we split this into 2 diferent properties
01:32:50 [dbaron]
fantasai adds balance to text-wrap
01:33:00 [dbaron]
fantasai: discard is new value, throws out all whitespace
01:33:17 [dbaron]
fantasai: preserve is pre, preserve-breaks is pre-line
01:33:30 [dbaron]
fantasai: the 2 new subproperties inherit since white-space inherits
01:33:47 [dbaron]
fantasai: text-space-trim needs to not inherit, so pulled into separate property
01:33:50 [dbaron]
fantasai: was in level 3
01:34:15 [dbaron]
fantasai: trim-inner gets rid of space that's just inside the beginning and end of the element
01:34:47 [roc]
roc has joined #css
01:35:19 [dbaron]
fantasai: consume-after ... pulling a footnote out, don't want to format source code so markup is right up against last letter, but want the footnote marker to have no space before it.
01:35:38 [dbaron]
fantasai: or if you format it with parentheses, you want the space before the opening parenthesis
01:36:03 [dbaron]
s/consume-after/consume-before/
01:36:36 [dbaron]
fantasai: That's the set of whitespace stuff pulled in from old level 3 ideas. What do you all think?
01:36:44 [dbaron]
Rossen: (question)
01:36:55 [dbaron]
fantasai: line-break and word-break control where linebreaking opportunities are in the text
01:37:06 [astearns]
s/(question)/where is word-break in this?/
01:37:06 [dbaron]
fantasai: this controls whether or not you're wrapping
01:37:27 [dbaron]
heycam: consume and discard seem to be similar things, so maybe should use the same names?
01:37:32 [dbaron]
fantasai: discard-after and discard-before?
01:37:45 [dbaron]
heycam: in SVG, we're making SVG text be defined in terms of CSS text layout
01:38:14 [dbaron]
heycam: one of the weirdo things about SVG text is that if you use the old mechanism to say preforatted text, with xml:space=preserve, it preserves all the spaces within lines but discards newlines
01:38:37 [dbaron]
heycam: so we have a special value in Gecko that's like pre, but discards newlines
01:39:23 [dbaron]
fantasai: text-space-collapse: discard-breaks -- implies you preserve the other things
01:39:44 [dbaron]
SteveZ: if that, then poetry one should be discard-extra-whitespace
01:39:56 [dbaron]
fantasai: I think it's clear enough...
01:40:28 [dbaron]
SteveZ: ???
01:40:37 [dbaron]
heycam: you could have separate values for breaks and the inline things
01:40:40 [dbaron]
fantasai: feels unnecessary
01:40:56 [dbaron]
SteveZ: suggestions: either preserve-non-breaks parallel to preserve ...
01:41:10 [dbaron]
fantasai: Do you discard the breaks or collapse them?
01:41:16 [dbaron]
heycam: they get discarded
01:42:08 [dbaron]
johanneswilm: (something about whitespace at start and end of line)
01:42:25 [dbaron]
heycam: let me just confirm that it doesn't convert the newline into a single space
01:42:37 [dbaron]
fantasai: any other comments?
01:42:40 [dbaron]
fantasai: ok, go with this then
01:42:51 [dbaron]
fantasai: thoughts on turning this into an editor's draft when we have this in?
01:42:55 [dbaron]
various: yes
01:42:56 [tantek]
definitely editor's draft
01:43:11 [fantasai]
Edits to do
01:43:19 [fantasai]
1. consume-before/after -> discard-before/after
01:43:30 [fantasai]
2. add discard-breaks (or collapse-breaks, as appropriate) for SVG
01:43:45 [fantasai]
3. spec wrap-before/after/inside
01:43:49 [fantasai]
(and remove 'avoid'
01:43:50 [fantasai]
)
01:44:06 [sgalineau_]
sgalineau_ has joined #css
01:44:41 [dbaron]
heycam: actually it looks like implementations turn newlines into spaces, and not collapse consecutive ones, except in IE
01:44:52 [dbaron]
heycam: maybe IE doesn't implement xml:space=preserve
01:44:59 [dbaron]
fantasai: so we need a new name, say spacify-breaks for now
01:45:22 [glazou]
http://glazman.org/tmp/IMG_0153.JPG
01:45:24 [tantek]
how about 'breaks-to-spaces'
01:45:28 [dbaron]
RESOLUTION: Make css-text-4 an editor's draft (currently a diff spec)
01:45:30 [ShmabShmatkins]
fyif
01:45:46 [dbaron]
RESOLUTION: fantasai and astearns to edit
01:46:25 [mihnea_____]
mihnea_____ has joined #css
01:47:08 [tantek]
tomorrow we're in 1 Darling rd.
01:48:06 [tantek]
break for lunch til 14:18 (90min)
01:49:13 [amtiskaw]
amtiskaw has joined #css
01:49:40 [jet]
jet has joined #css
01:50:57 [ato]
ato has joined #css
02:16:33 [dauwhe]
dauwhe has joined #css
02:38:46 [Florian]
Florian has joined #css
02:50:53 [zcorpan]
zcorpan has joined #css
02:54:42 [zcorpan]
zcorpan has joined #css
02:57:31 [gregwhitworth]
gregwhitworth has joined #css
02:58:31 [johanneswilm]
johanneswilm has joined #css
03:00:56 [gregwhitworth]
gregwhitworth has joined #css
03:12:42 [estellevw]
estellevw has joined #css
03:14:19 [fantasai]
astearns: I don't think breaking flex items across flex-lines makes sense
03:14:31 [fantasai]
astearns: I think flex just needs wrap-before+wrap-after, not wrap-inside
03:15:16 [astearns]
fantasai: right - I was thinking of a range of flex items not getting a wrap, but that doesn't quite work
03:15:16 [AndreyR]
AndreyR has joined #css
03:15:50 [jet]
jet has left #css
03:16:06 [jet]
jet has joined #css
03:17:38 [fantasai]
koji?
03:18:13 [tantek]
14:18 resume
03:18:31 [tantek]
Topic: sizing
03:18:38 [murakami]
murakami has joined #css
03:19:37 [fantasai]
RESOLVED: Add gregwhitworth as editor to Sizing
03:20:35 [fantasai]
ACTION: fantasai figure out what it was wrt percentage sizing
03:20:35 [trackbot]
Created ACTION-670 - Figure out what it was wrt percentage sizing [on Elika Etemad - due 2015-02-16].
03:21:06 [kwkbtr]
kwkbtr has joined #css
03:22:25 [fantasai]
fantasai: We were discussing the two different concepts of "max-content" sizing: the size that the thing wants to be (e.g. for multicol, col-width * col-count) vs. the width at which it will be the shortest and not waste space horizontally
03:22:37 [fantasai]
(which for multicols is col-count*max-content of the content)
03:22:53 [fantasai]
fantasai: Conclusion was that 'max-content' keyword would refer to the first concept, since that's what authors really need for stuff
03:23:10 [fantasai]
fantasai: in the cases where we need the second concept, we'll call it the super-max-content for now, probably won't be exposed to authors
03:23:15 [shmazou]
koji: want to call in?
03:24:15 [fantasai]
dbaron: This is the thing where the only difference between them is multicol
03:24:17 [SimonSapin]
fantasai, What's the intrinsic size of div in <div style="width: auto"><p style="width: 100px; margin: 10%"></div> ?
03:24:42 [fantasai]
fantasai: I think so. ALthough gregwhitworth's case is one that might be relevant, too
03:24:51 [fantasai]
dbaron: I don't think there's a case fo rhaving this extra spec concept
03:25:23 [tantek]
dbaron: there are lots of concepts that exist that we don't write code for
03:25:47 [fantasai]
dbaron: putting it in a spec creates a risk that somebody ends up implementing the concept that isn't used
03:26:11 [fantasai]
TabAtkins: So we define max-content, put a note in the spec saying that we might need this extra concept
03:27:21 [fantasai]
TabAtkins makes an example
03:27:27 [fantasai]
multicol element w/ columsn: 2 200px
03:27:42 [fantasai]
TabAtkins: It will lay itself out at 400px
03:28:28 [fantasai]
TabAtkins: suppose you have an unbreakable word
03:28:31 [fantasai]
fantasai: Could be breakable
03:28:43 [fantasai]
fantasai: Actually, that's an issue, if it's unbreakable, you'll have min-content > max-content
03:28:48 [fantasai]
dbaron: That is severely broken
03:29:06 [dbaron]
dbaron: It's a spec bug if max-content < min-content
03:29:07 [fantasai]
TabAtkins: You'll get 2 cols 300px each
03:29:28 [tantek]
fantasai: we're mixing up a bunch of different concepts
03:29:31 [tantek]
scribenick: tantek
03:29:43 [tantek]
fantasai: (goes to whiteboard)
03:29:53 [tantek]
… if container is 600px
03:29:59 [tantek]
… multicol element will layout 300px wide columns
03:30:18 [tantek]
… but at 400px, 200px each col, the first line would wrap
03:30:26 [tantek]
… in the 300px case it doesn't wrap because it fits
03:30:33 [tantek]
… and the height of my thing is going to be 1em
03:30:39 [tantek]
… this got shorter, I'm wasting 58px of space
03:30:52 [tantek]
… (…) so 500 px is a point in the layout that stuff changes
03:30:57 [tantek]
… you have unwrapped all of the lines
03:31:03 [tantek]
… beyond 500px you start getting extra space
03:31:10 [tantek]
… so this is kind of like a breakpoint in the layout
03:31:17 [tantek]
… if you make the thing any narrower than 400px
03:31:22 [tantek]
… then you're going to drop down to 1 column
03:31:34 [tantek]
… then you have another concept
03:31:43 [tantek]
… What is the minimum size that you don't get overflow?
03:31:47 [tantek]
… take the length of the longest word
03:31:55 [tantek]
… mutiply it by the number of columns
03:31:58 [tantek]
… the longest word basically
03:32:03 [tantek]
… whatever that is is the min content size
03:32:15 [tantek]
SteveZ: I think I get min content and unwrapped lines
03:32:22 [tantek]
… but it's this funny thing in between that I don't get
03:32:44 [tantek]
fantasai: this size, which is I want to be that size, that one could be in the middle or smaller than the min content size, or larger than the intrinsic max size
03:32:51 [tantek]
Rossen: let's go one column
03:32:57 [tantek]
… you have 1 col with 200px
03:33:03 [tantek]
… you have min content 100
03:33:12 [tantek]
Rossen: (draws on white board)
03:33:16 [tantek]
… your content inside is 100
03:33:20 [tantek]
… you max is 150
03:33:26 [tantek]
… let's say 2 words
03:33:31 [tantek]
… in this case you're happy
03:33:37 [tantek]
… you're going to have 200px content width
03:33:44 [tantek]
… I think there are three cases
03:33:50 [tantek]
… 1) both min & max > 200
03:33:53 [tantek]
… 2) or only max > 200
03:34:08 [tantek]
… 3) happens when you start multiplying the columns
03:34:37 [tantek]
… what doesn't currently work, what are you proposing to change
03:34:37 [tantek]
… for case #1: both min & max are strictly > col size
03:34:37 [tantek]
… case #2: only max > col size
03:34:49 [tantek]
… case #3: … um
03:34:54 [tantek]
… is you have more than one column
03:35:01 [tantek]
… for completeness
03:35:07 [tantek]
… same as above but with the opposite sign.
03:35:12 [tantek]
fantasai: so the question we have is
03:35:22 [tantek]
… when you have a multicol element that is shrink to fit
03:35:27 [tantek]
… what size does it end up being
03:35:33 [tantek]
Rossen: let's answer 1 col question first
03:35:36 [tantek]
… before multicol
03:35:46 [tantek]
dbaron: isn't 1 col equivalent to non multicol
03:35:51 [tantek]
Rossen: exactly
03:35:58 [tantek]
fantasai: a non-multicol doesn't have a column width
03:36:13 [tantek]
dbaron: I am not at all convinced that we should considr the col width at all for any intrinsic size computation
03:36:24 [tantek]
Rossen: you're saying 1 col is equivalent of having a block
03:36:26 [tantek]
dbaron: yes
03:36:52 [tantek]
Rossen: when I have a block with 200px, what it reports to a float trying to wrap around it, it will report 200px min & max
03:37:03 [tantek]
Rossen: for single col width 200px, it shouldn't honor the 200px
03:37:12 [tantek]
dbaron: col width is a minimum, or more like minimum
03:37:16 [tantek]
Rossen: same as a table cell
03:37:20 [tantek]
fantasai: no it is different
03:37:25 [tantek]
fantasai: if you have a block
03:37:29 [tantek]
… if col width is 200px
03:37:34 [tantek]
… if my block is 50px
03:37:39 [tantek]
… my col will be 50 px
03:37:43 [tantek]
… the col width is a suggestion
03:37:53 [tantek]
dbaron: column width is merely a hint for determining the column count
03:37:56 [tantek]
fantasai: yes
03:38:04 [tantek]
dbaron: although i don't quite remember…
03:38:13 [tantek]
… the formula for when both col count and col width are specified
03:38:19 [tantek]
… it takes the smaller of the two numbers
03:38:21 [tantek]
fantasai: yeah
03:38:36 [tantek]
… if your container is 150px wide, the col will be 150px wide
03:38:46 [tantek]
… if your container is 250px… col will be 250px
03:39:00 [tantek]
… if your container is 400px, your col will be 2 cols of 200px each
03:39:30 [tantek]
… we had (…) but we ran into the shrink to fit sizing in the multicol spec says if you have a float, and you have enough space, then the multicol will be columns * colwidth
03:39:33 [tantek]
… and that's implemented
03:39:45 [tantek]
… if as an author I specify hey, I want you to shrink to fit around this thing
03:39:49 [tantek]
… that's what they expect
03:40:02 [tantek]
… if they have a long line of content, they don't expect the cols to get wide
03:40:08 [tantek]
… we have a problem here
03:40:20 [tantek]
… it's really important that the shrink to fit max is, is …
03:40:36 [tantek]
… it's important that the shrink to fit max include the maximum of the min content size, and then col count * col width
03:40:44 [tantek]
… that way you're maintaining that invariant
03:40:50 [tantek]
… you're also getting the thing the author asked for
03:40:56 [tantek]
… we have this other concept of unwrapped
03:40:59 [tantek]
… authors will not want that
03:41:06 [tantek]
… you will have layout land at that answer for certain cases
03:41:12 [tantek]
… that's a break point in the layout where it won't get shorter
03:41:19 [tantek]
… it might become a useful concept if for example
03:41:24 [tantek]
… if you have tables and you're doing orthogonal flows
03:41:32 [tantek]
… you might want things to be as few lines as possible
03:41:41 [tantek]
… without orthogonal flows it's not that interesting as a concept
03:41:46 [tantek]
… we also have a similar issue
03:41:51 [tantek]
… the shrink to fit sizing should be x
03:42:01 [tantek]
… and if the box is wider it will be wider
03:42:09 [tantek]
… like Greg brought up
03:42:18 [tantek]
… the shrink to fit expectation is narrower than (...)
03:42:25 [tantek]
… that's a concept that we don't have a clear idea where it would be used
03:42:29 [tantek]
… but I have a feeling it will show up
03:42:39 [tantek]
Rossen: go back to .(…) what are we calling it?
03:42:42 [tantek]
fantasai: max conent
03:42:45 [tantek]
s/conent/content
03:42:50 [tantek]
fantasai: we have 3 concepts
03:42:52 [tantek]
… small concept
03:42:55 [tantek]
… two big concepts
03:43:09 [tantek]
… the author gets exposed to these through shrink to fit sizing and the max content keyword
03:43:15 [tantek]
… when the author is doing grid layout for example
03:43:23 [tantek]
… then they're going to expect to be this size and not wrap the text
03:43:33 [tantek]
Rossen: in this case, 600px, 2 cols
03:43:37 [tantek]
… 300px cols each
03:43:44 [tantek]
fantasai: where is 600px coming from
03:43:47 [tantek]
Rossen: min content
03:44:04 [tantek]
fantasai: if you have a really long unbreakable line or an image, then it will be wide enough to fit that image without overflow
03:44:09 [tantek]
Rossen: in this case it will overflow
03:44:11 [tantek]
fantasai: it won't
03:44:37 [tantek]
Rossen: you will have two columns
03:44:37 [tantek]
fantasai: when you layout a multicol element at 600px with 2 cols, each will be 300 px wide
03:44:54 [tantek]
Rossen: your col count has to be driven by the max of (...)
03:45:08 [tantek]
TabAtkins: this is not the size of the largest word
03:45:27 [tantek]
dbaron: maybe we should take some of this offline
03:45:34 [tantek]
… not sure what we're trying to solve right now
03:45:46 [tantek]
TabAtkins: (...)
03:45:55 [tantek]
dbaron: the thing you just said, you implicitly assumed two concepts
03:45:59 [tantek]
… I don't think you have to assume that
03:46:08 [tantek]
fantasai: for the purposes of this discussion there are 2 concepts
03:46:15 [tantek]
dbaron: there are potentially many more concepts
03:46:30 [tantek]
TabAtkins: we need to be ok with multicol having a different answer for that
03:46:42 [tantek]
SteveZ: you're just defining what max content means in a multicol situation
03:46:49 [tantek]
fantasai: the other case is you have a bunch of floats
03:46:55 [tantek]
… and you shrinkwrap a bunch of floats
03:47:05 [tantek]
… you could have this (…) but you actually get this (...)
03:47:18 [tantek]
… the floats (3) could fit next to each other
03:47:36 [tantek]
… but since you asked it to shrinkwrap, current implementations shrink them to one on a line each
03:47:45 [tantek]
gregwhitworth: it is weird and we'll try to spec it
03:47:51 [tantek]
fantasai: more fun times
03:47:54 [tantek]
TabAtkins: resolutions
03:48:08 [tantek]
… can we get a resolution that we should define max content of multicol this way
03:48:15 [tantek]
dbaron: I think I object to a big part of that
03:48:18 [tantek]
fantasai: which part
03:48:20 [tantek]
dbaron: most of it
03:48:30 [tantek]
dbaron: and I want to propose an alternative
03:48:37 [tantek]
SteveZ: the piece that confuses me with a 600px image
03:48:43 [tantek]
… I would expect multicol to go away in that case
03:48:52 [tantek]
Rossen: you specified the number col count 2
03:49:03 [tantek]
TabAtkins: multicol assume if you specify count that you meant it
03:49:08 [tantek]
fantasai: so we need to make this correction
03:49:14 [tantek]
TabAtkins: so we fix this in sizing now
03:49:20 [tantek]
… dbaron can suggest whatever he wants
03:49:26 [tantek]
… and we can resolve differences later
03:49:40 [tantek]
gregwhitworth: we need to discuss per the mail thread what does "min content" really mean
03:49:44 [tantek]
… we can take it offline
03:49:55 [tantek]
TabAtkins: (…) ?
03:50:01 [tantek]
fantasai: the intrinsic size
03:50:12 [tantek]
Rossen: so if it's the only thing you're going to get the specified size
03:50:23 [tantek]
fantasai: no there is a min content size and a min content contribution
03:50:26 [tantek]
… there are two separate concepts
03:50:37 [tantek]
dbaron: one of the reasons for that is that we want the width property to accept values
03:50:43 [tantek]
… that says use the min or max content
03:50:46 [SimonSapin]
q+ about percentage margins in intrinsic sizing
03:50:52 [tantek]
… the min content size does not include the (...)
03:50:59 [tantek]
… you have to factor that into the contribution (...)
03:51:09 [tantek]
gregwhitworth: both of your guys implementations you could make an argument for
03:51:15 [SimonSapin]
q+
03:51:19 [tantek]
gregwhitworth: you guys (Moz) if you have a really long line ...
03:51:28 [tantek]
gregwhitworth: but blinks will shrink to the size of the longest word
03:51:43 [tantek]
dbaron: I think this is very differen than what Rossen and I were talking about
03:51:57 [tantek]
fantasai: it is full defined and mozilla's implementation matches what it is defined as
03:52:04 [tantek]
SimonSapin: I missed this earlier
03:52:12 [tantek]
… can we got back to percentages?
03:52:22 [plinss]
zakim, ack SimonSapin
03:52:22 [Zakim]
I see no one on the speaker queue
03:52:30 [tantek]
scribenick: fantasai
03:52:38 [fantasai]
SimonSapin: Intrinsic size computation for blocks
03:52:45 [fantasai]
SimonSapin: You account for margin/padding/border of children
03:52:55 [fantasai]
SimonSapin: But it's unclear what happens if these contain percentages or auto values
03:53:11 [fantasai]
SimonSapin: If you compare with width of children, we have specific text that says it's indefinite, do something else
03:53:23 [fantasai]
TabAtkins: But for margin/border/padding we don't say
03:53:27 [fantasai]
Rossen: No interop here
03:53:47 [fantasai]
dbaron: Auto isn't interesting. just treat as zero
03:53:52 [fantasai]
TabAtkins: yeah
03:53:57 [fantasai]
SimonSapin: Put that in the spec
03:54:14 [fantasai]
dbaron: In gecko we do the reverse computation
03:55:14 [fantasai]
fantasai: I think this discussion was super-useful, I understand what's going on here much better thanks to the discussion
03:55:31 [fantasai]
fantasai: Let's get together and update the spec before we lose all the context again
03:55:54 [fantasai]
RESOLVED: auto margins assumed to be zero for intirnsic size computation
03:56:13 [dbaron]
SimonSapin, fwiw, http://dbaron.org/css/intrinsic/#outer-intrinsic did define it :-P
03:56:19 [fantasai]
dbaron: Did we come to a conclusion on percentages?
03:56:25 [glazou]
http://glazman.org/tmp/IMG_0154.JPG
03:56:29 [fantasai]
Rossen: We discussed computing to zero
03:56:50 [fantasai]
dbaron: I think trying to do something useful with percentages is good
03:56:51 [SimonSapin]
dbaron, great! Let’s copy that in Sizing
03:56:55 [fantasai]
dbaron: We were unable to do for width
03:57:18 [fantasai]
fantasai: I agree we should do something useful and not stupid here
03:57:27 [fantasai]
fantasai: Shouldn't create overflow artificially
03:57:36 [fantasai]
Rossen talks about stacking percentages
03:57:39 [fantasai]
dbaron: Tables already do this
03:57:50 [fantasai]
dbaron: Tables do inverting of percentages
03:58:03 [gregwhitworth]
Here is the min-content issue we need to discuss: http://dabblet.com/gist/599a04c05a22f48a292d
03:58:07 [gregwhitworth]
Discussion is here: https://lists.w3.org/Archives/Public/www-style/2015Jan/0022.html
03:58:08 [fantasai]
dbaron: At some point your perferred width becomes infinite, but you never use it directly, you always min it with something
03:59:25 [fantasai]
fantasai: With width percentages, you treat as auto for both intrinsic size computation and for final layout
03:59:53 [fantasai]
fantasai: with percentage padding, you treat as zero for intrinsic size computation, but then honor it for layout, which results in overflow and bad layout
03:59:56 [fantasai]
fantasai: I think this is worth fixing
04:00:06 [fantasai]
Rossen says something about making things better for flex, but wasn't sure what he said
04:00:36 [fantasai]
ACTION: fantasai, Tab, SimonSapin, Rossen , gregwhitworth , dbaron to figure this all out and spec it.
04:00:36 [trackbot]
Error finding 'fantasai,'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
04:00:39 [fantasai]
Rossen: tonight.
04:00:42 [fantasai]
plinss: or else.
04:01:10 [fantasai]
Topic: Text
04:01:12 [fantasai]
koji?
04:01:59 [plinss]
zakim, room for 3?
04:02:00 [Zakim]
ok, plinss; conference Team_(css)04:01Z scheduled with code 26631 (CONF1) for 60 minutes until 0501Z
04:03:01 [koji]
can I call in?
04:03:16 [plinss]
yes ^
04:03:21 [plinss]
zakim, code?
04:03:21 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), plinss
04:04:09 [Zakim]
Team_(css)04:01Z has now started
04:04:16 [Zakim]
+??P0
04:04:27 [plinss]
zakim, ??P0 is MeetingRoom
04:04:27 [Zakim]
+MeetingRoom; got it
04:06:02 [ShmabShmatkins]
ScribeNick: ShmabShmatkins
04:06:16 [ShmabShmatkins]
SchmibeNick: ShmabShmatkins
04:06:22 [Zakim]
-MeetingRoom
04:06:23 [Zakim]
Team_(css)04:01Z has ended
04:06:23 [Zakim]
Attendees were MeetingRoom
04:06:46 [fantasai]
https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0080.html
04:07:02 [ShmabShmatkins]
Topic: Text
04:07:08 [ShmabShmatkins]
fantasai: First issue is about line-breaking around emoji/etc
04:07:15 [ShmabShmatkins]
fantasai: There was some bakc-and-forth in the thread
04:07:25 [ShmabShmatkins]
fantasai: The best option is to treat images as ideographic chars for linebreaking.
04:07:37 [ShmabShmatkins]
fantasai: It solves linebreaking problems when images are used as emoji.
04:07:46 [ShmabShmatkins]
fantasai: And gives better behavior than the current spec in general.
04:07:56 [ShmabShmatkins]
fantasai: So this doesn't cause breaks right before an end paren, etc.
04:08:03 [ShmabShmatkins]
fantasai: Main concern is, is this web compatible?
04:08:11 [ShmabShmatkins]
fantasai: Right now everyone breaks around images.
04:08:20 [ShmabShmatkins]
fantasai: But Presto treats images as ideographic chars.
04:08:28 [Zakim]
Team_(css)04:01Z has now started
04:08:35 [Zakim]
+??P0
04:08:41 [ShmabShmatkins]
fantasai: The critical piece is that the iamges will break between each other if they're siblings, which is handled by this suggested rule.
04:08:45 [plinss]
zakim, ??P0 is MeetingRoom
04:08:45 [Zakim]
+MeetingRoom; got it
04:08:46 [Zakim]
-MeetingRoom
04:08:47 [Zakim]
Team_(css)04:01Z has ended
04:08:47 [Zakim]
Attendees were MeetingRoom
04:08:58 [ShmabShmatkins]
fantasai: Only behavior change is a few restrictions we add for ideographic chars.
04:09:06 [ShmabShmatkins]
fantasai: Which you probably meant to work in the first place.
04:09:25 [ShmabShmatkins]
fantasai: We're taking Presto as an example of webcompat.
04:09:33 [Zakim]
Team_(css)04:01Z has now started
04:09:40 [Zakim]
+MeetingRoom
04:09:42 [ShmabShmatkins]
fantasai: We're hoping this is worth giving a shot at fixing to be sane.
04:09:48 [zcorpan]
line breaking around images is a bit different in quirks mode: https://quirks.spec.whatwg.org/#the-table-cell-width-calculation-quirk
04:09:55 [ShmabShmatkins]
fantasai: We need to hear back from impls to see if they're willing to implement.
04:10:04 [ShmabShmatkins]
szilles: What unicode categories are these?
04:10:12 [ShmabShmatkins]
fantasai: Proposal is to treat as the ID class (ideographic).
04:10:18 [Zakim]
+??P1
04:10:22 [ShmabShmatkins]
fantasai: Current behavior is not actually expressible in teh unicode spec.
04:10:30 [koji]
zakim, +??p1 is me
04:10:30 [Zakim]
sorry, koji, I do not recognize a party named '+??p1'
04:10:37 [koji]
zakim, ??p1 is me
04:10:37 [Zakim]
+koji; got it
04:10:37 [ShmabShmatkins]
fantasai: Unicode puts "glue" (nbsp, etc) as a higer priority as nearly anything else.
04:10:50 [ShmabShmatkins]
fantasai: But images apparently decided they ahve a higher priority than forced non-breaking.
04:10:58 [ShmabShmatkins]
fantasai: So this change'll bring us *more* in line with the unicode spec.
04:11:08 [ShmabShmatkins]
fantasai: Any comments, or should we make the fix?
04:11:21 [ShmabShmatkins]
zcorpan: I don't understand the consequences?
04:11:37 [ShmabShmatkins]
fantasai: Example: "<img>&nbsp;foo", you can't break after the img any more.
04:11:54 [ShmabShmatkins]
fantasai: Or "(<img>)", you can't break in the parens anymore, they'll stay with the image.
04:11:57 [Zakim]
-koji
04:12:11 [ShmabShmatkins]
zcorpan: I'll search if Presto has any open compat bugs for it.
04:12:29 [ShmabShmatkins]
zcorpan: I also posted a link to Quirks Mode. Line-breaking there is a bit different, at least for table cells.
04:12:45 [ShmabShmatkins]
zcorpan: If we change how linebreaking works around images, it might need to be adjusted in Quirks.
04:13:06 [ShmabShmatkins]
zcorpan: When you calculate the minimum width of the table cell, you act like there's no breaking opportunity around images.
04:13:11 [koji]
are you proposing to fix just for images and leave other replaced elements?
04:13:14 [ShmabShmatkins]
zcorpan: But when you actually lay out there might be linebreaks there.
04:13:28 [ShmabShmatkins]
fantasai: For all replaced elements.
04:13:34 [ShmabShmatkins]
fantasai: And for U+FFFC
04:14:04 [koji]
I'm negative, at least for <input>, that'll break too much
04:14:17 [koji]
I'm not sure how much we'd break for <img> though
04:14:34 [ShmabShmatkins]
fantasai: What would it break for <input>?
04:15:06 [ShmabShmatkins]
zcorpan: Looks like Presto has at least one bug about "<img>&nbsp;foo" breaking a website due to non-breaking.
04:15:15 [koji]
Preseto being bugged from users indicates that there are legacy such content
04:15:30 [rbyers]
koji: I'm checking it now to see if I can dial in alright.
04:16:09 [Florian]
koji: yes, but it depends how much content this breaks. Hopefully not much.
04:16:26 [fantasai]
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cstyle%3E%0Ahtml%20%7B%20font-size%3A%203em%3B%20%7D%0A%3C%2Fstyle%3E%0A(%3Cinput%3E)%3Cbr%3E%0A%3Cinput%3E.%3Cbr%3E%0A%3Cinput%3Eabc%3Cbr%3E%0A%3Cinput%3E%26nbsp%3Bfoo
04:16:41 [zcorpan]
"There are cases where the total width of the images exceeds that of the containing <div> block and instead of creating a line break, Opera displays the image outside of the block." - url was http://www.clasohlson.se/product/category.aspx?category=kroppsv%c3%a5rd:tandv%c3%a5rd&id=88753177&_path=251882;85177601;88752827;88753177 but probably the site has changed
04:16:41 [koji]
In HTML4, I believe, authors used to use &nbsp; as a non-collapsible spaces
04:16:52 [koji]
and used <input>&nbsp;&nbsp;<input>
04:17:04 [koji]
not sure how much such content survive today though
04:17:43 [Zakim]
+ +1.415.231.aaaa
04:18:03 [koji]
zakim, +1.415.231.aaaa is me
04:18:03 [Zakim]
+koji; got it
04:19:24 [ShmabShmatkins]
koji: The bug was reported to Presto by a user; that indicates at leaest some users believe there should be forced break opportunities between &nbsp; and <input>.
04:19:46 [ShmabShmatkins]
Florian: It's definitely a breaking change; the question is if it's breaking too much.
04:20:12 [ShmabShmatkins]
Florian: Not surprising that Presto gets a bug if everyone else does something different.
04:20:43 [ShmabShmatkins]
Florian: Unsure that one single bug is enough evidence to rule it out. Presto survived for a while without fixing this.
04:21:25 [rbyers]
koji, dial-in working OK for you now?
04:22:09 [rbyers]
ok, np - feel free to ping me on hangouts or IRC if it goes out again.
04:22:14 [ShmabShmatkins]
fantasai: So it sounds like Greg will look into actual websites and see what may or might not break.
04:22:19 [ShmabShmatkins]
fantasai: Anything else to do?
04:23:22 [ShmabShmatkins]
koji: I have seen editors that, when I type two spaces at the end of a sentence, converts it into multiple &nbsp;
04:23:38 [fantasai]
koji: treats nbsp as non-collapsible space
04:23:52 [ShmabShmatkins]
murakami: I think the emoji and gaiji should be treated same as ideographic chars, and do linebreaking correctly.
04:23:59 [zcorpan]
16,311 pages in httparchive match REGEXP_MATCH(body, r'(\&nbsp;<img\s|<img[^>]+>\&nbsp;)')
04:24:19 [ShmabShmatkins]
murakami: I don't understand why people wouldn't expect nbsp to not break.
04:24:49 [fantasai]
murakami: That makes no sense and is a bug that we should fix
04:25:11 [ShmabShmatkins]
zcorpan: I checked httparchive for nbsp before/after an image, and there were 16k matches.
04:25:27 [ShmabShmatkins]
zcorpan: ABout 130k pages in the set, so about 12% of all the pages match the query.
04:25:47 [ShmabShmatkins]
zcorpan: Haven't analyzed whether they're broken in Presto or not, but there's a lot of pages.
04:26:14 [ShmabShmatkins]
plinss: So we'll come back to this with data?
04:26:39 [ShmabShmatkins]
johanneswilm: This applies to <canvas> and <svg> and similar too?
04:26:41 [ShmabShmatkins]
fantasai: Yes.
04:27:11 [ShmabShmatkins]
fantasai: Another thing to consider is if nbsp is a big issue, but nothing else is -- nbsp isn't a big deal for emoji, they're mostly concerned about punctuation being correct.
04:27:29 [ShmabShmatkins]
fantasai: We could just say that it behaves as an ideographic char *except* it still has a break opportunity between it and an nbsp.
04:27:36 [ShmabShmatkins]
fantasai: It woudl be stupid, but it would fix all the other cases.
04:28:01 [fantasai]
TabAtkins: Suggest we resolve to do ideographic change, and based on data may or may not do nbsp tweak to it
04:28:20 [ShmabShmatkins]
fantasai: zcorpan, can you run a query with parens, or a period after the image?
04:28:23 [ShmabShmatkins]
zcorpan: Sure.
04:28:52 [myakura]
myakura has joined #css
04:29:22 [zcorpan]
r'(\(<img\s|<img[^>]+>[\)\.])' 999 matches
04:29:45 [ShmabShmatkins]
RESOLVED: Treat replaced elements as ideographic chars for line-breaking. Based on data, possible add an exception for nbsp.
04:29:53 [Rossen]
999 out of 1000?
04:30:13 [zcorpan]
out of ~130k
04:30:51 [fantasai]
plinss: We need a really-non-breaking-space
04:31:00 [fantasai]
fantasai: <img>&zwsp;&nbsp;
04:31:23 [Rossen]
zakim who is noisy
04:31:26 [ShmabShmatkins]
dbaron: nbsp changed meaning between original (just a char that didn't add a breaking opportunity) and unicode later meaning (inhibits breaking around it).
04:31:40 [gregwhitworth]
http://i.imgur.com/N8ouTs8.png
04:31:52 [gregwhitworth]
https://lists.w3.org/Archives/Public/www-style/2014Nov/0282.html
04:31:59 [ShmabShmatkins]
gregwhitworth: We had a bug a while ago (^^^ pic above) showing hex boxes.
04:32:17 [ShmabShmatkins]
gregwhitworth: I brought it up on the list, asking Text to specify that control chars get shown.
04:32:26 [ShmabShmatkins]
gregwhitworth: FF actually did this, but everyone assumed they were broken.
04:32:38 [ShmabShmatkins]
gregwhitworth: So we all need to coordinate our release, to avoid getting inundated with bugs.
04:32:51 [ShmabShmatkins]
gregwhitworth: And coordinate with, say, a 6-month period to give devs warning.
04:33:01 [ShmabShmatkins]
gregwhitworth: So let's agree to make the change in, say, September?
04:33:33 [ShmabShmatkins]
dbaron: Did we back it out?
04:33:43 [ShmabShmatkins]
gregwhitworth: Yeah, the bug is in the discussion.
04:33:55 [ShmabShmatkins]
gregwhitworth: roc is the one that suggested the coordination day.
04:34:07 [ShmabShmatkins]
[greg goes to fetch roc]
04:34:08 [stryx`]
stryx` has joined #css
04:34:48 [ShmabShmatkins]
gregwhitworth: roc, we're trying to coordinate the visible-control-chars release.
04:34:59 [ShmabShmatkins]
roc: We alreayd have it implemented, we just need to flip a UA property.
04:35:15 [jet]
Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1099557
04:36:04 [ShmabShmatkins]
RESOLVED: Everyone go coordinate on Sep being when control characters become visible.
04:37:46 [Rossen]
zakim, who is noisy?
04:37:53 [fantasai]
fantasai: Okay, so MSFT, Blink, and WebKit need ot implement behind a flag, preferably by June, and report back if sooner so we can coordinate
04:38:02 [Zakim]
Rossen, listening for 10 seconds I heard sound from the following: MeetingRoom (4%)
04:38:30 [Rossen]
zakim, mute MeetingRoom
04:38:30 [Zakim]
MeetingRoom should now be muted
04:38:42 [Rossen]
zakim, unmute MeetingRoom
04:38:42 [Zakim]
MeetingRoom should no longer be muted
04:39:01 [ShmabShmatkins]
[alan summons Dean]
04:39:17 [ShmabShmatkins]
[alan begins by drawing a pentagram on the floor]
04:39:21 [ShmabShmatkins]
[Dean curses us all]
04:41:31 [ShmabShmatkins]
Dean: I can't control when an iPhone releases, so...
04:41:41 [ShmabShmatkins]
gregwhitworth: As long as we have enough.
04:41:49 [ShmabShmatkins]
Dean: If we committed to doing it...
04:42:29 [ShmabShmatkins]
fantasai: Just impl behind a flag, and flip it at the same time as everyone else. Everyone else might get it out sooner, but we all know it's coming out in Safari too.
04:43:02 [ShmabShmatkins]
Dean: Okay.
04:43:27 [ShmabShmatkins]
gregwhitworth: Chrome and FF are the main ones that can just ship it whenever. MS and Apple will have to just commit to it.
04:44:06 [ShmabShmatkins]
[alan erases pentagram]
04:44:11 [ShmabShmatkins]
[Dean returns to whence he came]
04:44:29 [zcorpan]
ACTION Dean break the web behind a flag in webkit
04:44:29 [trackbot]
Created ACTION-671 - Break the web behind a flag in webkit [on Dean Jackson - due 2015-02-16].
04:45:10 [ShmabShmatkins]
johanneswilm: I hope I'm not using those chars that'll become visible after.
04:45:19 [ShmabShmatkins]
gregwhitworth: We'll put out PR to help people figure this out.
04:45:35 [ShmabShmatkins]
Topic: Writing Modes
04:45:48 [ShmabShmatkins]
fantasai: Writing modes!
04:45:56 [ShmabShmatkins]
fantasai: We dont' hav eimpls of the sideways-left value.
04:46:00 [ShmabShmatkins]
fantasai: 1) leave it as is
04:46:18 [ShmabShmatkins]
fantasai: 2) mark it as at-risk, and note that if someone implements just sideways-right, don't implement sideways
04:46:25 [ShmabShmatkins]
fantasai: 3) punt it to level 4
04:47:01 [ShmabShmatkins]
fantasai: I think we should do #2 because it's important for non-CJK upright scripts.
04:47:15 [ShmabShmatkins]
fantasai: LIke a caption on the left side of a table, or table column headers that are vertical in English, you need this value.
04:47:20 [ShmabShmatkins]
fantasai: So I don't think we should remove it.
04:47:32 [ShmabShmatkins]
fantasai: But if it's the only thing blocking writing modes from exitting CR, it might be worth dropping it.
04:48:04 [ShmabShmatkins]
Tab: I say keep it in until CR-exit is immanent.
04:48:10 [ShmabShmatkins]
koji: I say move it to Level 4.
04:48:55 [ShmabShmatkins]
koji: Concerns about how it is designed today were raised, and I'd like further discussion.
04:48:59 [ShmabShmatkins]
koji: So punting is appropriate.
04:49:04 [astearns]
s/immanent/imminent/
04:49:06 [ShmabShmatkins]
fantasai: Nobody ahs raised an issue with the design afaik.
04:49:14 [ShmabShmatkins]
fantasai: People have said "I don't like this, it's confusing and complicated".
04:49:32 [ShmabShmatkins]
koji: Rossen suggested rotating the line 180deg inline
04:49:42 [ShmabShmatkins]
fantasai: We could make it apply to blocks only if that's the issue.
04:51:04 [ShmabShmatkins]
plinss: I don't see the harm in marking it at-risk versus punting it for now.
04:51:39 [ShmabShmatkins]
plinss: Has anyone implemented sideways-right but not sideways-left?
04:51:45 [ShmabShmatkins]
fantasai: Yeah, because sideways-right is needed for CJK.
04:52:07 [ShmabShmatkins]
astearns: At-risk seems the right thing to do for now.
04:52:09 [koji]
AH, Blink, and WebKit does
04:52:13 [ShmabShmatkins]
Rossen: We can alway spush it to 4 later.
04:52:17 [ShmabShmatkins]
plinss: Any objections?
04:52:52 [ShmabShmatkins]
RESOLVED: Keep sideways-left, mark as at-risk, possibly punt if it threatens CR-exit.
04:53:16 [ShmabShmatkins]
fantasai: Next is propagation of writing-mode and direction from <body>
04:53:48 [ShmabShmatkins]
koji: Did we decide on 'sideways'?
04:53:58 [ShmabShmatkins]
fantasai: Same deal - if you can't do sideways-left, you can't do sideways.
04:54:01 [ShmabShmatkins]
koji: Okay.
04:54:25 [ShmabShmatkins]
fantasai: Right now in HTML we prop from root to the ICB, and the proposal is to ignore the value on the root and propagate from the body to both the root and the ICB. Ignore the root's value entirely.
04:54:45 [ShmabShmatkins]
Rossen: So if you have <html dir=rtl><body dir=ltr>, it's ltr?
04:55:08 [ShmabShmatkins]
Rossen: Is that a good idea?
04:55:26 [ShmabShmatkins]
fantasai: We need to do something like this. For background, we can do the "check to see if root has it specified, if not, check body".
04:55:44 [ShmabShmatkins]
fantasai: But this is inherited - there is always a valid value. So you have to choose one or the other unconditionally.
04:56:11 [ShmabShmatkins]
Florian: I believe direction is a web-compat issue; it's been that way forever. We'd prefer it inherit normally, but we probably can't change it.
04:56:16 [ShmabShmatkins]
Florian: And writing-mode should act similarly.
04:56:26 [ShmabShmatkins]
Rossen: We have logic that doesn't match that since IE6.
04:56:43 [ShmabShmatkins]
Rossen: We take root if specified, and use body otherwise.
04:57:04 [ShmabShmatkins]
Rossen: Same for overflow.
04:57:26 [ShmabShmatkins]
Rossen: This suggestion may have compat issues in cases where both html and body specify a direction.
04:57:50 [ShmabShmatkins]
Rossen: Before we decide how to spec this, we need to udnerstand how we're all doing.
04:58:01 [ShmabShmatkins]
Rossen: I hope this is something we can keep consistent for overflow too.
04:58:59 [fantasai]
testcase: data:text/html;charset=utf-8,<!DOCTYPE html>%0D%0A<title>..]<%2Ftitle>%0D%0A<style>%0D%0A%0D%0A head%2C title { display%3A block%3B }%0D%0A body { border%3A solid%3B width%3A 150%25%3B text-align%3A center%3B }%0D%0A<%2Fstyle>%0D%0A<body dir%3Drtl>%0D%0A..]
04:59:17 [ShmabShmatkins]
zcorpan: In Blink it used to use the root element if it was specified on both, but it was changed to always use <body>, claiming compat with Gecko and IE.
04:59:35 [ShmabShmatkins]
fantasai: Gecko seems confusing...
04:59:42 [ShmabShmatkins]
dbaron: Gecko is inconsistent based on what is happening.
05:01:11 [ShmabShmatkins]
dbaron: You can test how direction behaves on root by...
05:01:24 [ShmabShmatkins]
dbaron: 1) Which side you can scroll to when there's overflow from the viewport.
05:01:38 [ShmabShmatkins]
dbaron: 2) If the root element is relpos and has both left and right set, which one wins.
05:01:51 [ShmabShmatkins]
dbaron: 3) If the root element has overconstrained margins, which gets ignored.
05:02:11 [ShmabShmatkins]
dbaron: 4) if the root or body is abspos, which position gets used for hypothetical box calcs.
05:02:47 [ShmabShmatkins]
dbaron: Probably most likely to cause breakage is scroll direction.
05:03:38 [fantasai]
dbaron: data:text/html;charset=utf-8,<!DOCTYPE html>%0D%0A<title>..*<%2Ftitle>%0D%0A<style>%0D%0A%0D%0A head%2C title { display%3A block%3B }%0D%0A html { border%3A solid silver%3B width%3A 80%25%3B margin%3A 0%3B }%0D%0A body { border%3A solid%3B width%3A 150%25%3B text-align%3A center%3B }%0D%0A<%2Fstyle>%0D%0A<body dir%3Drtl>%0D%0A..*
05:03:49 [ShmabShmatkins]
[some discussion about <title> direction]
05:03:50 [fantasai]
Presto scrolls as LTR (follows root)
05:04:03 [fantasai]
Gecko aligns as LTR, but scrolls as RTL
05:04:09 [fantasai]
which is not helpful at all
05:04:28 [fantasai]
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ctitle%3E..*%3C%2Ftitle%3E%0A%3Cstyle%3E%0A%0A%20%20head%2C%20title%20{%20display%3A%20block%3B%20}%0A%20%20html%20{%20border%3A%20solid%20silver%3B%20width%3A%2080%25%3B%20margin%3A%200%3B%20}%0A%20%20body%20{%20border%3A%20solid%3B%20width%3A%20150%25%3B%20text-align%3A%20center%3B%20}%0A%3C%2Fstyle%3E%0A%3Cbody%20dir%3Drtl%3E%0A..*
05:04:46 [zcorpan]
<title> seems like UI QoI
05:05:05 [fantasai]
Blink aligns and scrolls as RTL
05:06:53 [fantasai]
IE shows the whole canvas and can scroll to it, and aligns per RTL, but the initial scroll position is per LTR
05:06:54 [tantek]
05:07:35 [ShmabShmatkins]
Florian: So more testing to see what exactly is happening, and which is interoperable?
05:07:46 [ShmabShmatkins]
fantasai: Whichever one is less likely to cause breakage is what we should do.
05:08:12 [ShmabShmatkins]
dbaron: Fixing the spec might make things inconsistent too.
05:08:40 [ShmabShmatkins]
dbaron: You'll need to make up some new term, not computed value, and you'll need to make sure everything refers to this new term, not "computed value".
05:10:58 [tantek]
scribenick: ShmabShmatkins
05:11:20 [fantasai]
https://lists.w3.org/Archives/Public/www-style/2015Jan/0272.html
05:11:24 [fantasai]
710 pages with <body dir=rtl> and not <html dir=rtl>. (0.24%)
05:11:36 [dbaron]
https://bugzilla.mozilla.org/show_bug.cgi?id=1071098#c16 is where I got the list of ways to test direction on the root
05:12:12 [dbaron]
fantasai: could propagate from the HTML attribute on the body, but not propagate CSS 'direction'
05:12:13 [ShmabShmatkins]
html:has-child(body[dir=rtl]) { direction: rtl; }
05:12:14 [ShmabShmatkins]
DONE
05:13:26 [ShmabShmatkins]
ACTION Greg to figure out what options are sensible for the html/body dir thing.
05:13:26 [trackbot]
Created ACTION-672 - Figure out what options are sensible for the html/body dir thing. [on Greg Whitworth - due 2015-02-16].
05:14:14 [ShmabShmatkins]
<br dur=15m>
05:21:23 [Zakim]
-koji
05:26:23 [Zakim]
disconnecting the lone participant, MeetingRoom, in Team_(css)04:01Z
05:26:25 [Zakim]
Team_(css)04:01Z has ended
05:26:25 [Zakim]
Attendees were MeetingRoom, koji
05:43:23 [ShmabShmatkins]
</br>
05:43:57 [jdaggett]
next topic is?
05:44:20 [ShmabShmatkins]
jdaggett: Finishing up some comments about direction/writing-mode.
05:44:25 [ShmabShmatkins]
Then the SVG1.1 keywords.
05:44:28 [jdaggett]
ok
05:46:45 [ShmabShmatkins]
dbaron: Xidorn tried to implement something, and we found a problem.
05:47:03 [ShmabShmatkins]
dbaron: In CSS sometimes the process of computing one proeprty depends on another one.
05:47:11 [ShmabShmatkins]
dbaron: And we need to keep these in a partial order, so no loops.
05:47:21 [ShmabShmatkins]
dbaron: We discovered that Ruby and Writing Modes added a loop.
05:47:35 [ShmabShmatkins]
dbaron: It's between 'display' and 'writing-mode'.
05:47:52 [ShmabShmatkins]
dbaron: There's also an influence from 'ruby-position'.
05:48:40 [ShmabShmatkins]
dbaron: display:ruby-text-container && ruby-position:inter-character => writing-mode computes to vertical-rl
05:48:53 [ShmabShmatkins]
dbaron: Because intercharacter ruby needs to be drawn that way.
05:49:14 [ShmabShmatkins]
dbaron: I've seen elevator signs in Taipei look like this.
05:49:52 [ShmabShmatkins]
dbaron: When writing-mode changes between parent and child, and display is inline, it's changed to inline-block.
05:50:16 [ShmabShmatkins]
dbaron: Because you can't really display a writing mode change unless the parent establishes a block
05:50:29 [ShmabShmatkins]
dbaron: I think most of us agree that writing-mode has to mess with display.
05:50:45 [kwkbtr]
kwkbtr has joined #css
05:50:47 [gregwhitworth]
gregwhitworth has joined #css
05:50:55 [ShmabShmatkins]
dbaron: So it's not strictly a loop, but this still doesn't work in our architecture.
05:51:15 [ShmabShmatkins]
dbaron: roc suggested that the vertical-lr change be triggered by something else that display:ruby-text-container elements have.
05:53:25 [ShmabShmatkins]
ShmabShmatkins: So our problem here is that we have a strict separation of properties into "levels" that compute in order.
05:53:45 [ShmabShmatkins]
dbaron: Ours isn't strict, but we do have a strict ordering of inherited vs non-inherited properties, which ends up being the same thing.
05:54:18 [ShmabShmatkins]
fantasai: We could make the inline->inline-block a used value.
05:54:29 [ShmabShmatkins]
dbaron: Making the computed value out of sync with the real value will be a security issue.
05:56:48 [ShmabShmatkins]
[dang, missing some minuting]
05:57:14 [ShmabShmatkins]
ShmabShmatkins: I think roc's suggestion can work. Add a magic property to <rtc> and anonymous ruby text containers. Authors have to add it manually if they're making their own.
05:57:46 [ShmabShmatkins]
fantasai: Can this just be an implementation issue?
05:58:31 [ShmabShmatkins]
[dbaron's thinks furiously]
05:58:50 [ShmabShmatkins]
dbaron: What does it look like in inter-character ruby when there is an <rtc> with multiple <rt>s?
05:59:13 [ShmabShmatkins]
fantasai: Each rt is after each rb. The rtc and rbc both encircle the entire thing.
05:59:26 [ShmabShmatkins]
dbaron: That makes it sound like it's the rt that's vertical-rl, not the rtc.
06:00:04 [ShmabShmatkins]
dbaron: If so, can we fix by changing the condition to "my parent's display is rtc and my ruby-position is inter-character"?
06:00:13 [ShmabShmatkins]
fantasai: Or parent's ruby-position is inter-character.
06:00:23 [ShmabShmatkins]
dbaron: If it's the ruby-text that becomes vertical-lr, I think that's okay.
06:00:28 [ShmabShmatkins]
fantasai: Sounds good.
06:01:07 [fantasai]
RESOLVED: writing-mode: vertical-lr on the <rt> based on parent's 'display' & 'ruby-position'
06:01:25 [ShmabShmatkins]
heycam: The 'all' shorthand is desgined to exclude direction and unicode-bidi.
06:01:33 [ShmabShmatkins]
heycam: Why?
06:01:46 [ShmabShmatkins]
fantasai: direciton and unicode-bidi should never have existed. They're not stylistic, they're content properties.
06:01:53 [ShmabShmatkins]
fantasai: So when resetting stylistic stuff, they shouldn't be reset.
06:01:59 [ShmabShmatkins]
fantasai: But writing-mode *is* a stylistic choice.
06:02:09 [ShmabShmatkins]
heycam: And text-orientation too?
06:02:12 [ShmabShmatkins]
fantasai: Yes.
06:02:33 [ShmabShmatkins]
Topic: SVG Keywords - kill them?
06:02:48 [ShmabShmatkins]
heycam: There are some svg-specific keywords in writing modes.
06:03:11 [ShmabShmatkins]
heycam: text-orientation:use-glyph-orientation, which means "do what the SVG-specific glyph-orientation-vertical/horizontal properties say".
06:03:26 [ShmabShmatkins]
heycam: I was going to suggest to SVGWG to just drop those, since nobody implements them.
06:03:34 [ShmabShmatkins]
heycam: Presumably you'd drop the value if we drop the proeprties.
06:03:35 [ShmabShmatkins]
fantasai: Yes.
06:03:47 [ShmabShmatkins]
heycam: Next is some writing-mode values, coming from XSL.
06:03:58 [ShmabShmatkins]
heycam: We're going to drop all of those, and just refer to current CSS spec.
06:04:05 [ShmabShmatkins]
heycam: So I suggest they get dropped from CSS.
06:04:10 [ShmabShmatkins]
fantasai: Can you actually drop them?
06:04:30 [ShmabShmatkins]
fantasai: It's reasonably likely there's no web content that uses them, but may be off-web content that uses them.
06:05:56 [ShmabShmatkins]
ShmabShmatkins: Can we just death-pact with the SVGWG and choose to drop them if they do?
06:06:03 [ShmabShmatkins]
heycam: AT least we'll drop them from SVG2.
06:06:08 [ShmabShmatkins]
fantasai: But you'll still need the definition.
06:06:21 [ShmabShmatkins]
fantasai: We might deprecate and define them simultaneously.
06:06:51 [ShmabShmatkins]
heycam: In WM atm, there's wording that says "if you support these values, do XXX".
06:06:56 [ShmabShmatkins]
heycam: We'll let you know what we decide.
06:07:37 [ShmabShmatkins]
heycam: I found an old email of mine saying that some browsers do ipmlement glyph-orientation-*, but they didn't do it interoperably.
06:08:18 [ShmabShmatkins]
fantasai: If the values only show up in attributes, you can use UA CSS to convert it to the proper values.
06:08:32 [ShmabShmatkins]
fantasai: But if the existing content uses the CSS syntax, you need to keep it.
06:10:02 [ShmabShmatkins]
RESOLVED: Drop the values if the SVGWG drops the values/properties, otherwise keep them.
06:10:28 [ShmabShmatkins]
Topic: Multi-line/block ellipsis
06:10:34 [krit]
This is exported from Photoshop:
06:10:34 [ShmabShmatkins]
Florian: Not the first time we've discussed this.
06:10:38 [krit]
.cls-15 {
06:10:38 [krit]
writing-mode: tb;
06:10:38 [krit]
glyph-orientation-vertical: 0;
06:10:38 [krit]
}
06:10:40 [ShmabShmatkins]
Florian: To refresh everyone, we have ellipsis.
06:10:53 [heycam]
krit, ok, that is interesting
06:10:55 [ShmabShmatkins]
Florian: It only works in in the inline dimension. If a given line is overflowing, it gets ellipsized.
06:10:56 [dbaron]
https://lists.w3.org/Archives/Public/www-style/2015Jan/0357.html
06:11:09 [ShmabShmatkins]
Florian: Most people want something at the end of the last line of a block that's too long in the block direction.
06:11:17 [heycam]
krit, can you write vertical text in photoshop? :)
06:11:32 [ShmabShmatkins]
Florian: We actually ahve a resolution to add it to the spec, without specifying what's getting added.
06:11:41 [ShmabShmatkins]
Florian: So I was looking into this...
06:12:03 [ShmabShmatkins]
Florian: I have some ideas, but while working on this, I figured this was a problem that should be unified with something similar, and so I'll be talking more about fragmentation than ellipsis.
06:12:24 [ShmabShmatkins]
Florian: When you say "I want ellipsis at the end of the last line", what does that mean? Last totally-fitting line? Does ink(shadow) count?
06:12:32 [ShmabShmatkins]
Florian: Or do we just use fragmentation, which defines all of this?
06:12:48 [ShmabShmatkins]
Florian: There's a property in the REgions spec called region-fragment.
06:13:06 [astearns]
http://dev.w3.org/csswg/css-regions/#the-region-fragment-property
06:13:25 [ShmabShmatkins]
Florian: It has 'auto' or 'break'. If the last region of the region chain overflows, and it says "auto", it overflows like normal. If 'break', it acts like there's another region, but just drops the rest.
06:13:40 [ShmabShmatkins]
fantasai: This sounds like another value for overflow-y.
06:13:54 [cyril]
cyril has joined #css
06:14:02 [ShmabShmatkins]
Florian: The REgions spec shows why that's not true; it's independent of overflow.
06:14:36 [fantasai]
This is overflow-y: paged-hidden
06:14:38 [ShmabShmatkins]
astearns: overflow-x/y can have effects independently of region-fragment
06:15:11 [ShmabShmatkins]
ShmabShmatkins: Regardless, I think you're not invoking the property itself, just its concept?
06:15:39 [ShmabShmatkins]
Florian: I think we can generalize this concept.
06:15:51 [ShmabShmatkins]
Florian: [described the definition of the property again]
06:16:17 [ShmabShmatkins]
fantasai: So you have overflow:scroll and hidden.
06:16:36 [ShmabShmatkins]
fantasai: Same, but hidden just stops it rather than exposing the rest.
06:16:48 [ShmabShmatkins]
fantasai: Similarly, this is like paged and "paged-hidden" - "page me, but don't expose the rest".
06:16:53 [tantek]
q?
06:16:58 [ShmabShmatkins]
dbaron: I agree with florian.
06:17:07 [ShmabShmatkins]
dbaron: When I was writing the Overflow spec, I found this awkward.
06:17:21 [ShmabShmatkins]
dbaron: It was trying to put two different concepts in the Overflow property, one about visual overflow and one about pagination.
06:18:14 [ShmabShmatkins]
dbaron: It was awkward that there were 'overflow' values (page and fragments) that were about how to paginate, so when you had those values, you had to arbitrarily pick what to do with the visual overflow that visible/hidden handled normally.
06:18:26 [ShmabShmatkins]
fantasai: So that makes sense to me; maybe different properties for visual vs pagination overflow.
06:18:29 [ShmabShmatkins]
fantasai: I'm okay with that.
06:18:38 [ShmabShmatkins]
fantasai: As long as pagination and hiding pagination are in the same control.
06:18:46 [ShmabShmatkins]
Florian: That's chapter 5 of my very long mail.
06:18:53 [ShmabShmatkins]
[[Presumably a new book out this summer.]]
06:19:05 [ShmabShmatkins]
Florian: So my new proposal is a 'fragmention' property.
06:19:27 [ShmabShmatkins]
Florian: With values auto/none/break/paged/clone
06:19:46 [ShmabShmatkins]
Florian: auto is "do the right thing in the middle of a region chain", etc
06:19:49 [fantasai]
break is region-break: break behavior
06:19:52 [ShmabShmatkins]
Florian: Should we explain regular pagination in terms of this?
06:19:53 [fantasai]
paged is overflow: paged
06:19:59 [fantasai]
clone is overflow: fragment
06:20:08 [tantek]
s/fragmention/fragmentation
06:20:13 [ShmabShmatkins]
Florian: By having this property on the page box, having "auto" compute to "paged", which lets you turn off pagination on a page and let things overflow.
06:20:21 [ShmabShmatkins]
Florian: Dunno if that's useful.
06:20:48 [ShmabShmatkins]
Florian: Reason this ties into ellipsis is that we have an issue about block ellipsis, and another issue about "how can we write 'continue on page 3'", we can unify these.
06:21:23 [ShmabShmatkins]
Florian: So we'd solve the "put ... at the end of a block" the same way as "put ... at the end of a region that continues elsewhere", and eventually "put (page 3) at the end of a region" when we have those tools.
06:21:46 [ShmabShmatkins]
tantek: When I've seen "include the first 3 lines" behavior, it's usually on social networks with a "more" link.
06:21:56 [ShmabShmatkins]
tantek: I don't know how to combine auto-ellipsizing that and adding a link.
06:22:04 [ShmabShmatkins]
Rossen: We discussed this in Seoul.
06:22:10 [fantasai]
s/link/link that you can attach some other behavior to/
06:22:16 [ShmabShmatkins]
Rossen: Talked about what to do with ellipsed behavior.
06:22:56 [ShmabShmatkins]
Rossen: We added the "fade" ellipsis behavior, and there was talk about styling it, so it should be a pseudo-element.
06:23:20 [ShmabShmatkins]
Rossen: So the ellipsed block is actually interactive. You can attach event handlers to the pseudo-element.
06:24:24 [ShmabShmatkins]
Florian: Another possibility is adding a "fragment: into(<sel>)" that we could use later.
06:24:28 [ShmabShmatkins]
tantek: I think I'm okay with unifying
06:24:50 [ShmabShmatkins]
tantek: So we need a string, not just "ellipsis".
06:25:03 [fantasai]
fantasai^: Bert had a pull model that I think makes more sense than into(<sel>)
06:26:01 [ShmabShmatkins]
ShmabShmatkins: You can attach an event listener to the parent of the ::ellipsis pseudo, and do the "more" handling there.
06:26:13 [ShmabShmatkins]
tantek: So one approach is an expansion when you click "more".
06:26:22 [ShmabShmatkins]
tantek: Another is "more" being a link to another page.
06:26:53 [ShmabShmatkins]
tantek: Third is "continued on page 3", where it loads totally different content, maybe saying "continued from page 1".
06:26:54 [dbaron]
And some websites use both, and you can't tell which you're going to get until after you click it.
06:27:07 [fantasai]
tantek^: another scrolls down to another part of the page
06:27:20 [ShmabShmatkins]
tantek: I'd like to at least capture those.
06:27:44 [ShmabShmatkins]
ShmabShmatkins: First two can be done with JS now; doing it CSS requires reviving the Hyperlink module. Third can be done as Region expansions in the future.
06:28:07 [ShmabShmatkins]
Florian: My basic point is that if we try to solve block ellipsis separately from fragmentation, we'll have to solve these problems twice.
06:28:49 [ShmabShmatkins]
johanneswilm: As I understand it, if you can have an ::after pseudoel that you put the ellipsis in, you can use JS to figure out what page something shows up on, and set 'content' appropriately.
06:29:43 [ShmabShmatkins]
tantek: It's def solvable in JS today. Just want to let there be less JS, or no JS.
06:30:47 [ShmabShmatkins]
Rossen: If your container is actually constrained so there's only two lines visually, you say max-lines:3, the behavior is still bad.
06:30:59 [ShmabShmatkins]
Florian: No, max-lines:3 just puts a break opportunity after the 3rd line.
06:31:20 [ShmabShmatkins]
Florian: Currently max-lines only applies to overflow:fragments; it should apply to any fragmentainer.
06:31:33 [ShmabShmatkins]
ShmabShmatkins: Yes, assuming we have these new fragment values.
06:32:37 [ShmabShmatkins]
Florian: So, proposal is we remove region-fragment property, replace it with the 'fragmentation' property.
06:32:43 [ShmabShmatkins]
dbaron: I'm okay for now, haven't looked into the details.
06:32:48 [ShmabShmatkins]
tantek: I agree with the general scop eof the proposal.
06:33:24 [ShmabShmatkins]
RESOLVED: Replace region-fragment with 'fragmentation', written by Florian, determine where it belongs.
06:33:37 [ShmabShmatkins]
fantasai: Why is max-lines only usable on fragmentainers? Should be on all containers.
06:33:41 [ShmabShmatkins]
fantasai: block containers.
06:36:25 [ShmabShmatkins]
[discussion over this]
06:37:19 [ShmabShmatkins]
[???]
06:37:20 [tantek]
(unminuted discussion about fragmentainers)
06:37:26 [ShmabShmatkins]
[?????????]
06:37:35 [tantek]
(height, fragment or not, making breaks)
06:37:42 [ShmabShmatkins]
[?????????????????????????]
06:37:42 [astearns]
s/[?????????]/[????????????????]/
06:39:11 [ShmabShmatkins]
Florian: So right now, if you say max-lines:3 on a <p> in the middle of a page, it'll break the page after the third line.
06:39:25 [ShmabShmatkins]
Florian: Which is silly, so we need the <p> to be a fragmentainer.
06:39:49 [ShmabShmatkins]
Florian: To be automatic, maybe max-lines:non-none causes fragmentation:auto to compute to 'break'.
06:39:53 [ShmabShmatkins]
fantasai: 'break' is a non-obvious name.
06:40:01 [ShmabShmatkins]
ShmabShmatkins: Maybe 'discard'.
06:40:10 [ShmabShmatkins]
Rossen: So max-lines is non-inherited.
06:40:33 [ShmabShmatkins]
Rossen: So what if you have <div style="max-lines:3;"><div>...</div></div>
06:40:51 [ShmabShmatkins]
Florian: Well, regardless of that answer, max-lines should apply to any block.
06:41:03 [fantasai]
fantasai^: So, what I understnad is that the proposal is to take the values of 'overflow' that deal with fragmentation andmake them into a separate property, and add a value that does fragmentation but hides the overflow instead of continuing it on another page/clone
06:41:16 [ShmabShmatkins]
astearns: David defined this well in the Overflow spec where he tries to take your case into account.
06:41:26 [ShmabShmatkins]
astearns: We can resolve the issue over there.
06:41:26 [astearns]
http://dev.w3.org/csswg/css-overflow/#max-lines
06:41:53 [ShmabShmatkins]
astearns: But the discussion is about fragmentation.
06:42:05 [tantek]
q?
06:42:15 [ShmabShmatkins]
Florian: So do we want to do regular pagination with this fragmentation property?
06:42:22 [ShmabShmatkins]
fantasai: I was thinking paging was overflow:paged on the root element.
06:42:47 [ShmabShmatkins]
fantasai: overflow:paged creates pages the same way that scrollbox creates a scrollable canvas in the viewport. Instead of scrolls, you get pages.
06:43:02 [ShmabShmatkins]
fantasai: Each of those pages are styable with an @page rule, regardless of whether the whole doc is paged, or a small section.
06:43:48 [ShmabShmatkins]
Florian: So in some contexts, auto becomes paged, and maybe 'break' becomes 'overflow:hidden' or whatever on the root element.
06:45:05 [ShmabShmatkins]
RESOLVED: Split fragmentation values of 'overflow' into a separate property. Further develop this in the overflow module.
06:45:20 [johanneswilm]
Has it been defined what kinds of elements each of those pages has?
06:45:44 [johanneswilm]
(header, body element, footnote area, page number area, page float area?)
06:46:07 [ShmabShmatkins]
Florian: That property that gets separated out, is the region-fragment property. So pull it out.
06:46:17 [johanneswilm]
Or can it be definable by the user?
06:46:58 [ShmabShmatkins]
RESOLVED: region-break gets folded into the new property, too.
06:47:17 [ShmabShmatkins]
astearns: If this goes into Overflow, add Florian as an editor?
06:47:19 [ShmabShmatkins]
dbaron: Yes.
06:47:28 [ShmabShmatkins]
RESOLVED: Florian added as editor to Overflow.
06:48:04 [ShmabShmatkins]
fantasai: Do we have a def of overflow-x/y?
06:48:08 [ShmabShmatkins]
dbaron: Kinda, in Overflow.
06:48:32 [ShmabShmatkins]
fantasai: Gonna say that when we have that, we cut that as Overflow 3 and have everything new in Overflow 4.
06:48:59 [ShmabShmatkins]
Florian: I think region is the only fragmentainer that have ::before/after, but now you can.
06:49:19 [ShmabShmatkins]
astearns: We needed ::before/after in our processing model to see how they work in named flows.
06:50:15 [ShmabShmatkins]
astearns: If we assume that ::before/after are always blocks in a fragmentainer (what we currently do), then we'd want to extend that.
06:50:36 [ShmabShmatkins]
fantasai: What if the remaining space is negative?
06:50:40 [ShmabShmatkins]
Rossen: Defined in the region spec.
06:50:48 [ShmabShmatkins]
fantasai: Can they turn into runins?
06:50:52 [ShmabShmatkins]
Florian: I'd like to.
06:51:30 [ShmabShmatkins]
Florian: When you're doing ::after on fragmentainer, there are cases you want to only do ::after if you're fragmenting.
06:52:09 [ShmabShmatkins]
Florian: So maybe have an ::ellipsis-like thing to help handle that.
06:52:47 [ShmabShmatkins]
fantasai: Then we have the remaining issue about how to make it interactive.
06:53:38 [fantasai]
florian: That's a general pseudo-element issue
06:53:50 [fantasai]
fantasai: yes, but it's a core part of these use cases; not so much for other pseudos
06:53:53 [ShmabShmatkins]
heycam: How do you align the ::ellipsis? For the block one, does it appear as a block right below?
06:54:31 [ShmabShmatkins]
Florian: The way I remember it is "you know how wide this thing is, so you can lay out your ::after".
06:55:11 [ShmabShmatkins]
johanneswilm: I tried to do footnotes with regions, and ::before/after were problematic.
06:55:32 [ShmabShmatkins]
johanneswilm: I couldn't have a footnote marker get left behind, etc.
06:56:42 [ShmabShmatkins]
[?????????????????]
06:58:05 [ShmabShmatkins]
dbaron: I initially wanted [it] that way...
06:58:19 [ShmabShmatkins]
dbaron: We realized there was a rpoblem that you design some style with overflow:fragments, style each fragment,
06:58:29 [ShmabShmatkins]
dbaron: Then fragment 2 gets a page break in it.
06:58:47 [ShmabShmatkins]
dbaron: You don't want your styles to be one off because you fragment3 styles get applied to the second half of what was originally fragment 2.
06:58:53 [dauwhe]
s/[?????????????????]/johanneswilm and dauwhe got distracted by footnotes and went off-topic/
06:58:55 [ShmabShmatkins]
dbaron: Probably a way around that, but we're getting complicated.
06:59:41 [ShmabShmatkins]
<br dur="til morning">
07:00:01 [dbaron]
Florian: do we want a one-off fragmentation value for columns, or use 'clone'
07:00:07 [dbaron]
fantasai: use a magic value
07:00:21 [dbaron]
dbaron: not so sure, I wouldn't want to have to explain what that magic does elsewhere
07:01:39 [tantek]
TabAtkins, fantasai: Tiki Bar: ~18:30 Papa Gede's bar, 348 Kent Street.
07:21:17 [tantek]
tantek has joined #css
08:06:17 [svillar]
svillar has joined #css
08:17:55 [rego]
rego has joined #css
08:26:37 [antonp]
antonp has joined #css
09:10:55 [Ms2ger]
Ms2ger has joined #css
10:07:24 [lajava]
lajava has joined #css
11:19:33 [zcorpan]
zcorpan has joined #css
11:55:57 [dbaron]
dbaron has joined #css
12:10:18 [Florian]
Florian has joined #css
12:18:01 [dauwhe]
dauwhe has joined #css
12:24:02 [jdaggett]
jdaggett has joined #css
12:44:14 [Florian_]
Florian_ has joined #css
12:52:39 [Florian]
Florian has joined #css
13:00:46 [antonp]
antonp has joined #css
13:17:55 [tantek]
tantek has joined #css
13:36:45 [lajava]
lajava has joined #css
13:49:06 [svillar]
svillar has joined #css
14:26:15 [johanneswilm]
johanneswilm has joined #css
14:56:21 [johanneswilm]
johanneswilm has joined #css
15:19:16 [thinkxl]
thinkxl has joined #css
15:34:25 [lajava]
lajava has joined #css
16:05:03 [johanneswilm]
johanneswilm has joined #css
16:18:08 [Florian]
Florian has joined #css
16:52:19 [bkardell_]
bkardell_ has joined #css
16:53:47 [bkardell_]
anyone with practical implementation knowledge handy atm?
16:53:56 [bkardell_]
have a simple question
17:12:10 [estellevw]
estellevw has joined #css
17:12:59 [Ms2ger]
Ms2ger has joined #css
17:24:32 [johanneswilm]
johanneswilm has joined #css
17:30:10 [adenilson]
adenilson has joined #css
17:34:55 [Ms2ger]
shepazu, around?
17:35:04 [shepazu]
hey, Ms2ger
17:35:38 [Ms2ger]
shepazu, I'm hearing that the ED link on http://www.w3.org/TR/webmidi/ is broken; is that something you could get fixed in-place?
17:36:32 [shepazu]
Ms2ger, I can ask... it's not normally something we do :(
17:36:52 [Ms2ger]
I'd appreciate that
17:37:08 [Ms2ger]
If not, can you keep an eye on it for the next pub?
17:37:23 [Ms2ger]
Also, don't we run linkcheckers anymore?
17:37:37 [Ms2ger]
Oh
17:37:45 [Ms2ger]
Wrong link, not broken link
17:37:54 [shepazu]
right
17:39:51 [shepazu]
should be http://webaudio.github.io/web-midi-api/
17:41:48 [lajava]
lajava has joined #css
17:48:27 [shepazu]
Ms2ger, current policy is to publish a new draft, still can't update in place :( (though apparently that might be changing soon)
17:49:11 [Ms2ger]
Ah, W3C slowly being dragged into the last century? :)
17:50:23 [shepazu]
Ms2ger, don't get me started :P
17:50:52 [shepazu]
Ms2ger, but I'm starting the process to publish a new draft, anyway... it needs one, after 1.3 years
17:51:00 [Ms2ger]
You're right, I'd rather not :)
17:51:15 [Ms2ger]
wfm
17:52:09 [shepazu]
bkardell_, everyone's in Australia, so you should ask time-shiftedly
17:52:09 [Ms2ger]
Thanks
17:52:35 [Ms2ger]
shepazu, (mumble mumble heartbeat)
17:53:53 [shepazu]
Ms2ger, yeah, I should crack the whip a bit more... I don't know what the changes to the spec would be... it's mostly waiting on implementations, I think
18:07:45 [johanneswilm]
johanneswilm has joined #css
18:09:14 [Ms2ger]
Ms2ger has joined #css
18:12:17 [lajava]
lajava has joined #css
18:59:27 [Ms2ger]
Ms2ger has joined #css
19:01:59 [dauwhe]
dauwhe has joined #css
19:07:29 [johanneswilm]
johanneswilm has joined #css
19:42:12 [johanneswilm]
johanneswilm has joined #css
20:09:03 [dauwhe]
dauwhe has joined #css
20:21:23 [johanneswilm]
johanneswilm has joined #css
20:23:47 [glazou]
glazou has joined #css
20:26:32 [plh]
plh has joined #css
20:39:18 [dauwhe]
dauwhe has joined #css
21:05:53 [dauwhe_]
dauwhe_ has joined #css
21:16:38 [glazou]
glazou has joined #css
21:44:11 [zcorpan]
zcorpan has joined #css
21:49:49 [glazou]
glazou has joined #css
21:58:40 [hyojin]
hyojin has joined #css
22:05:31 [dbaron]
dbaron has joined #css
22:06:36 [smfr]
smfr has joined #css
22:07:03 [dauwhe]
dauwhe has joined #css
22:08:25 [roc]
roc has joined #css
22:09:02 [smfr]
plinss: is csswg.org going to come back?
22:09:14 [smfr]
oh there it is
22:09:32 [plinss]
it just seems to be running slow this morning, not sure why...
22:12:13 [kwkbtr]
kwkbtr has joined #css
22:17:58 [liam]
speed: molasses | glacial | intercontinental-drift | galactic-formation
22:18:08 [liam]
| initial | inherit | auto :)
22:19:51 [gregwhitworth]
gregwhitworth has joined #css
22:22:11 [xidorn]
xidorn has joined #css
22:22:29 [Florian]
Florian has joined #css
22:29:26 [AndreyR]
AndreyR has joined #css
22:34:49 [TabAtkins]
Scribenick: TabAtkins
22:35:02 [TabAtkins]
Topic: Rounded displays (sponsored by LG®)
22:35:07 [glazou]
https://www.w3.org/wiki/TPAC2014/SessionIdeas#CSS_Extensions_to_support_a_round_display
22:35:13 [dino]
dino has joined #css
22:35:13 [glazou]
http://www.w3.org/2014/10/29-rounddisplay-minutes.html
22:35:19 [glazou]
http://www.w3.org/wiki/images/8/84/141029_W3C_TPAC_Breakout_Session_Round_Display.pdf
22:35:34 [TabAtkins]
Hyojin: My name is Hyojin Song, working at LG's Software Platforms Lab.
22:35:52 [murakami]
murakami has joined #css
22:36:41 [TabAtkins]
hyojin: This is the first time for LG to present something to the CSSWG.
22:36:49 [TabAtkins]
hyojin: We have WebOS, embedded in TVs and watches.
22:36:58 [fantasai]
ScribeNick: fantasai
22:36:58 [TabAtkins]
hyojin: LG personally released a watch with WebOS last Jan.
22:37:04 [TabAtkins]
hyojin: The platform is the web.
22:37:07 [TabAtkins]
hyojin: Like HTML, CSS.
22:37:21 [fantasai]
hyojin: HTML and CSS should support some requirements to present web content to web-based device
22:37:28 [fantasai]
hyojin: LG smart watch display is round
22:37:39 [fantasai]
hyojin: When developing apps, we have some difficulty aligning content sin the device this way
22:37:47 [fantasai]
hyojin: So we would like to propose some ideas for orund display
22:37:53 [fantasai]
hyojin: This is a slide presented last TPAC
22:38:02 [fantasai]
hyojin: I'm going to briefly show you the concepts of our ideas using this slide
22:38:09 [fantasai]
hyojin: New devices with ar round screen are emerging
22:38:26 [fantasai]
hyojin: Here are 4 devices: ASUS ZenWatch, Moto360 LG G Watch R LG G3 when cover is close
22:38:30 [fantasai]
closed
22:38:40 [fantasai]
hyojin: Web was designed for a rectangular screen, especially CSS
22:38:45 [tantek]
tantek has joined #css
22:38:51 [jet]
jet has joined #css
22:38:52 [fantasai]
hyojin: Here are some LG watch appplications [phtographs]
22:39:01 [fantasai]
compass app, weather app, phoe dialer, etc.
22:39:06 [fantasai]
hyojin: CSS should make these applications
22:39:16 [fantasai]
hyojin: We have 4 ideas
22:39:21 [fantasai]
hyojin: First is extension of media query
22:39:28 [fantasai]
hyojin: Detect a round display
22:39:39 [fantasai]
hyojin: Defined a 'device-radius' property, inspired by border-radius
22:39:59 [fantasai]
hyojin: We made a specification like this. Very immature, but we have summarized here
22:40:03 [fantasai]
[projects spec draft]
22:40:13 [fantasai]
hyojin: Takes same syntax as border-radius
22:40:14 [jaredwy]
jaredwy has joined #css
22:40:28 [dbaron]
is there a URL for that spec?
22:40:30 [fantasai]
hyojin: 0% is rectangular display
22:40:42 [fantasai]
hyojin: Round display
22:40:48 [fantasai]
hyojin: Can dtect the shape of the display
22:40:57 [sanja]
sanja has joined #css
22:41:11 [fantasai]
Florian: I think the MQ is quite reasonable
22:41:18 [fantasai]
Florian: How complicated or simple do we want to be?
22:41:26 [fantasai]
Florian: There's a clear real use case for rounded display
22:41:37 [fantasai]
Florian: what do we do about e.g. triangle display or whatever?
22:42:09 [dbaron]
fantasai: we have proposals for addressing this for borders, triangles for example, changing the shape for the corners
22:42:15 [dbaron]
fantasai: this approach is fine and we can extend as we need
22:42:27 [fantasai]
glazou: Devices fo rmobile are changing very rapidly
22:42:48 [fantasai]
glazou: Change shapes in 2d, but also in 3d, e.g. rounded surface. Display is different on the curve
22:42:54 [fantasai]
glazou: First bendable screen just appeared
22:43:06 [fantasai]
glazou: Will reach a completely new set of characteristics of screens that we will need to cover in the future
22:43:30 [fantasai]
Florian: Works for rect, rounded rect, ellipses, but what else?
22:43:53 [fantasai]
roc: Do we have the goal of only detecting what shape it is and use MQ to create different layouts for each shape
22:43:59 [fantasai]
roc: Or create layouts that will adapt to any shape
22:44:08 [fantasai]
roc: MQ will help with the first, not the second
22:44:23 [fantasai]
roc: Need to decide on goal, one or other or both.
22:44:41 [fantasai]
hyojin: device-radius is limited in expressivity
22:44:47 [fantasai]
hyojin: Next topic is content alignment
22:44:55 [fantasai]
hyojin: CSS shape-inside
22:45:05 [fantasai]
hyojin: In rectangle display like this [floats and text in rectangle]
22:45:17 [fantasai]
hyojin: If you put it on a round display, the corners cannot be shown on the display
22:45:28 [fantasai]
hyojin: We want the content to flow inside the shape, like this [photo]
22:45:41 [fantasai]
hyojin: We extended shape-inside like this: add value 'display'
22:46:21 [fantasai]
hyojin shows content flowed into a circle
22:46:45 [fantasai]
hyojin shows content that starts partway down the screen, wraps into the semicircle of the bottom of the screen
22:47:11 [fantasai]
hyojin: We didn't implement in browsers, we automatically generate the shape like this [shows code]
22:47:25 [fantasai]
hyojin: Next topic is border
22:47:46 [fantasai]
hyojin: Borders extend outward from the edge of the screen, want it to fit in the screen.
22:48:06 [fantasai]
hyojin: So we defined new 'border-boundary' property, values 'none' or 'display'
22:48:48 [fantasai]
Florian: Did you consider keyword to make shape-inside and border-boundary to match?
22:48:58 [fantasai]
astearns: I think it's a different problem they're trying to solve
22:49:11 [fantasai]
astearns: They're trying to ge tthe childrens border to match the contours of a parent's shape-inside
22:49:26 [fantasai]
Florian: Exactly. Parent has hape-inside: display
22:49:36 [fantasai]
Florian: The children match the shape-inside of the parent
22:49:56 [fantasai]
tantek: This feels like a position: fixed approach
22:50:03 [fantasai]
tantek: relative to display
22:50:11 [fantasai]
tantek: vs. position: absolute, where relative to some other block
22:50:45 [fantasai]
dbaron I think it would also be possible to inset the borders as you go down the tree
22:50:55 [fantasai]
dbaron: propagating the shape down based on margin/pdding/border
22:51:10 [fantasai]
rossen: You gotta be able to find the shape going down. Display is only oneof the shapes as you're going down
22:51:22 [fantasai]
hyojin: Many issues, something to consider, so we wrote the issue sin the spec
22:51:38 [fantasai]
hyojin: I will share these materials into the CSS mailing list
22:51:45 [fantasai]
hyojin: We can discuss topics of round display issues
22:51:51 [fantasai]
hyojin: Last one is about layout features
22:51:59 [fantasai]
Rossen: back on the borders
22:52:05 [fantasai]
Rossen: This is easy to explain for solid borders
22:52:15 [fantasai]
Rossen: What do you expect the behavior to be for, e.g. border -styles other than solid
22:52:39 [fantasai]
Rossen: say I have a dashed border-right and a dotted border-top border
22:52:56 [dbaron]
dbaron has joined #css
22:52:56 [fantasai]
fantasai: Probably same way as you solve it for border-radius
22:53:37 [fantasai]
Rossen: If it's round-ish, that works, what if it's a star?
22:53:46 [fantasai]
Florian: Will require wordsmithing, but not an unsolvable issue
22:53:59 [fantasai]
fantasai: Take 45deg from center, find that point on the shape, or some other formula
22:54:10 [johanneswilm]
johanneswilm has joined #css
22:54:12 [fantasai]
hyojin: Using canvas, I can draw differnet border shapes
22:54:35 [fantasai]
hyojin: Last one is layout
22:54:50 [fantasai]
hyojin: We propose polar coordinates, to position around circle like this
22:55:15 [fantasai]
hyojin: polar-angle and polar-distance properties with position: polar
22:55:22 [SteveZ]
SteveZ has joined #css
22:55:32 [fantasai]
e.g. 'polar-angle: 225deg; polar-distance: 100%'
22:55:54 [fantasai]
dirk: Positioning only, or other layout?
22:55:57 [fantasai]
hyojin: Just positioning
22:56:28 [fantasai]
TabAtkins: Other than the fact that 'position: polar' would go on the children, not on the container (be just like alternate version of abspos), looks good to me
22:57:29 [fantasai]
dean: Which point is positioned at that point?
22:57:41 [fantasai]
fantasai: polar-origin property to determine it
22:57:57 [fantasai]
It should take an 'auto' value maybe that does automatic anchoring like backgrounds do
22:58:00 [dbaron]
heycam: maybe better as a transform item, an alternate way of specifying a translate
22:58:09 [jumland]
jumland has joined #css
22:58:20 [fantasai]
glazou: Rounded display on a sphere, turning, ...
22:58:41 [fantasai]
glazou: Why polar coordinates instead of transforms?
22:58:47 [fantasai]
hyojin: We developed this using transforms
22:58:55 [fantasai]
hyojin: I think the developer cna make applications like this easilky
22:59:07 [fantasai]
TabAtkins: One nice thing about this is that you can animate this very nicely
22:59:13 [fantasai]
TabAtkins: E.g. spiraling outward much easier.
22:59:37 [fantasai]
tantek: This example makes it looks like the distance: 80% was very carefully chose to make it look like there is padding is on the parent that the children bump up against
22:59:43 [fantasai]
tantek: Feels like a very fragile way of doing it
22:59:56 [fantasai]
tantek: If you change the font size, or the radius of theelements, it will no longer fit nicely
23:00:14 [fantasai]
tantek: I wonder if percentage-based distance abspos is what you want, or some model of polar box model
23:00:46 [fantasai]
TabAtkins: You can always do calc(100% - half-of radius).
23:00:47 [fantasai]
q+
23:00:59 [fantasai]
Florian: Yes if you know your radius
23:01:08 [glazou]
Zakim, ack fantasai
23:01:08 [Zakim]
I see no one on the speaker queue
23:01:19 [JonathanNeal_]
Ya keep sayin’ ma name, Zakim. What is up?
23:01:19 [JonathanNeal_]
Hello
23:02:04 [fantasai]
fantasai: if you have the ability to set origin the way backgrounds do, then you cna take the size into account as positioning
23:02:23 [fantasai]
tantek: abspos does a nice job of taking into account borders/padding
23:02:41 [fantasai]
tantek: I would challenge this to be as simple as abspos
23:03:37 [zcorpan]
q+
23:03:51 [dbaron]
q+
23:03:54 [roc]
roc: q+
23:03:57 [roc]
oops
23:03:59 [roc]
q+
23:04:00 [fantasai]
fantasai: You might want to have border/padding consideration, yes, but if you can do positioning like backgrounds then you can do offsets and positioning that take into account the size of the item
23:04:14 [johanneswilm]
johanneswilm has joined #css
23:04:29 [fantasai]
tantek^: abspols lets you do positioning from the edge without doing calc etc.
23:04:57 [fantasai]
fantasai: Abspos doesn't do e.g. centering without knowing the size of the box. background positioning can do offsets, but also more than that
23:05:02 [dbaron]
dbaron: Absolute positioning is pretty fragile in most cases.
23:05:06 [tantek]
the example shown looks like it is pushing the child elements to the edge of the padding of the parent - automatically - without having to magically pick 80%
23:05:10 [zcorpan]
ack me
23:05:21 [tantek]
I would like to NOT have to pick 80% based on the radius of the child, parent etc.
23:05:31 [fantasai]
zcorpan: My point was already said by fantasai: background-positioning can do offsets
23:05:33 [SteveZ]
q+
23:05:39 [glazou]
Zakim, ack dbaron
23:05:39 [Zakim]
I see roc, SteveZ on the speaker queue
23:05:50 [fantasai]
dbaron: I would not want to follow abspos as a model
23:05:54 [tantek]
and rather do it like abspos where you it takes into account both the padding of the containing block, and the border of the child
23:06:02 [fantasai]
dbaron: We've done a lot of things with layout systems that do more flexible and produce better results
23:06:10 [glazou]
Zakim, ack roc
23:06:10 [Zakim]
I see SteveZ on the speaker queue
23:06:16 [tantek]
my point was it should be NO WORSE than abspos
23:06:17 [cyril]
cyril has joined #css
23:06:20 [tantek]
if we can do better, great
23:06:22 [fantasai]
roc: Since this ise easily fpolyfillable in its current form
23:06:37 [fantasai]
roc: Mabye we produce better custom layout and style integration
23:06:46 [fantasai]
roc: do this insteadof adding it to the CSS core
23:06:53 [fantasai]
roc: If this has to go into CSS core, then what wouldn't?
23:07:02 [roc]
ack me
23:07:09 [fantasai]
glazou: Even for polyfills, 2 different editors of polyfill for this would like to rely on the spec
23:07:26 [fantasai]
roc: Could have a spec for feature sthat are implemented in polyfill rather than in browsers
23:07:36 [glazou]
Zakim, ack SteveZ
23:07:36 [Zakim]
I see no one on the speaker queue
23:07:43 [fantasai]
roc: Need to be clear about which it is, makes a big difference to constraints around the design
23:07:50 [fantasai]
szilles:...
23:08:02 [fantasai]
SteveZ: If I consider a center an edge and an angle, it has all of the properties that you want
23:08:07 [fantasai]
SteveZ: Could talk about edge shape
23:08:13 [ChrisL]
ChrisL has joined #css
23:08:33 [fantasai]
SteveZ: Adjusting along an angle-line, either toward the center or toward the ege, and has exactly the same set of properties abspos has to day, and you could even use it for squares
23:08:43 [fantasai]
SteveZ: So you could use it for better positioning
23:08:51 [fantasai]
tantek: Goal is to avoid collisions by default
23:09:07 [fantasai]
SteveZ: If you wnat it to touch the outer edge, you say 0 on the outer edge, same as you do with picking left/right/top/bottom
23:09:15 [fantasai]
SteveZ: same rules as abspols
23:09:26 [fantasai]
SteveZ: Center, you may want a different rule, e.g. center me on the center
23:09:38 [fantasai]
SteveZ: Tab's point was that it generalizes the same way
23:09:55 [fantasai]
hyojin: In future, need extensions for smart watch
23:10:03 [fantasai]
hyojin: I think these are reasonable
23:10:24 [fantasai]
hyojin: Will send this to CSS ML, and will collect problems from developers making round dsiplay. I will share wtih CSS WG.
23:10:27 [fantasai]
hyojin: Thank you
23:10:32 [fantasai]
glazou: Thank you for the presentation
23:10:39 [fantasai]
glazou: The way you are expcting to contribute to the document
23:10:48 [fantasai]
glazou: Are you requesting an Editors Draft at this point?
23:10:52 [fantasai]
hyojin: Yes, we'd like to publish this
23:11:07 [fantasai]
Florian: I'm happy about including these ideas, but many of these look like they belong in existing documents
23:11:16 [fantasai]
Florian: E.g. put rounded display MQ into the MQ spec
23:11:34 [fantasai]
glazou: We could do that, or until things stabilize a bit more, keep them in a separate document
23:11:40 [fantasai]
glazou: A partial solution is not enough for LG
23:11:57 [fantasai]
glazou: So I think for the time being, keep it all into single editors draft, and as soon as they stabilize dispatch them.
23:12:11 [fantasai]
glazou: Proposal is new ED with editor as LG
23:12:14 [fantasai]
fantasai: Shortname?
23:12:20 [tantek]
agreed with keeping it all together in a first editor's draft
23:12:34 [fantasai]
roc: Might be good to have a spec for all of coordinate layout
23:12:47 [fantasai]
roc: If it's not in a browser, then doesn't need to go through W3C
23:13:13 [fantasai]
glazou: We have a way to say a spec is not required
23:13:29 [fantasai]
roc: Could have the polyfillers sstandardize in a decentralized way
23:13:53 [fantasai]
roc: CSSWG's expertise is useful, but that is also useful
23:14:00 [ChrisL]
q+
23:14:20 [fantasai]
glazou: LG is leading the effort, but it is clear that other vendors with rounded display watchs will have exactly the same issue
23:14:51 [fantasai]
glazou: Application authors wanting to address these devices will want a standardized way to develop apps
23:14:58 [glazou]
Zakim, ack ChrisL
23:14:58 [Zakim]
I see no one on the speaker queue
23:15:01 [SteveZ]
q+
23:15:12 [fantasai]
ChrisL: W3C is about interop and getting people to work together. It's not about browsers only.
23:15:42 [fantasai]
ChrisL: It's better that people liaise with us, and it's better that we can comment and say in f5 minutes "no, no don't do that! do it this way"
23:15:53 [fantasai]
ChrisL: than they continue down
23:16:04 [fantasai]
ChrisL: They've taken initiative to come here, we should reciprocate.
23:16:09 [fantasai]
...
23:16:13 [glazou]
Zakim, ack SteveZ
23:16:13 [Zakim]
I see no one on the speaker queue
23:16:21 [fantasai]
SteveZ: First, there is a cost to doing this, which is it takes us time to review each of these specs
23:16:22 [glazou]
glazou: and the expertise on CSS is here
23:16:24 [fantasai]
SteveZ: not zero cost
23:16:29 [ChrisL]
open source round display watch (failed kickstarter) https://www.kickstarter.com/projects/958981650/the-pi-watch-a-programmable-open-source-smartwatch
23:16:39 [fantasai]
SteveZ: There is also a benefit, which is people here have knowledge about how to put thing sinto CSS in a CSS-like way
23:17:12 [fantasai]
SteveZ: We've had several discussions through the day,where people make comments on how ... e.g. dbaron's comment about unstled divs and spans being no-ops
23:17:14 [RRSAgent]
I'm logging. Sorry, nothing found for 'where'
23:17:18 [RRSAgent]
I'm logging. I don't understand 'link', dino. Try /msg RRSAgent help
23:17:22 [RRSAgent]
I'm logging. Sorry, nothing found for 'link'
23:17:23 [fantasai]
SteveZ: It's good to discuss these so that we don't make it difficult to extend CSS in the future
23:17:24 [Florian]
q+
23:17:25 [tantek]
q+
23:17:37 [fantasai]
SteveZ: I'm of the opinion that we should do the spec, and don't care how it's implemented
23:17:40 [glazou]
Zakim, ack Florian
23:17:40 [Zakim]
I see tantek on the speaker queue
23:17:52 [tantek]
q+ to partially agree with SteveZ, and partially to encourage experimentation to learn from use-cases
23:18:04 [fantasai]
Florian: Just as MQ spec editor, I just wnat to say I'm happy with either approach.
23:18:16 [glazou]
Zakim, ack tantek
23:18:16 [Zakim]
tantek, you wanted to partially agree with SteveZ, and partially to encourage experimentation to learn from use-cases
23:18:18 [Zakim]
I see no one on the speaker queue
23:18:23 [fantasai]
Florian: If you would like in MQ draft, would be happy to help
23:18:25 [ChrisL]
q?
23:18:39 [fantasai]
tantek: Would partially agree with Steve's observation that our review is beneficial
23:18:50 [fantasai]
tantek: Part of me also wants to see more rapid experimentation, even if solutions are imperfect
23:18:54 [glazou]
q+
23:18:54 [fantasai]
tantek: To use that to learn from the use cases
23:19:07 [fantasai]
tantek: To experiment e.g. how do we get things to not overlap
23:19:17 [fantasai]
tantek: Learning how prolbems occur in this kind oflayout is itself valuable
23:19:24 [fantasai]
tantek: I want to avoid discouraging experimentation
23:19:38 [fantasai]
tantek: Specifically avoid scenario of numerous webkit properties being thrown out there
23:19:42 [krit]
q+
23:19:56 [fantasai]
tantek: without any discussion with WG
23:20:13 [fantasai]
dirk: Do we have a way for extending MQ?
23:20:20 [fantasai]
TabAtkins: yes
23:20:34 [fantasai]
ChrisL: You can link thigs up by having a note in MQ pointing ot the other draft
23:20:35 [dbaron]
ack krit
23:20:35 [krit]
q-
23:20:43 [fantasai]
glazou: This only raises one question about what we call an implementation
23:20:50 [fantasai]
glazou: We shall now consider a polyfill as an implementation
23:21:29 [fantasai]
...
23:21:47 [fantasai]
ChrisL: So you think the wording needs clarification that it qualifies
23:21:53 [roc]
q+
23:22:04 [fantasai]
dbaron: I think that maybe requires more clarity bout which specs are expected to be implemented in browsers vs. polyfills
23:22:22 [fantasai]
dbaron: polyfill should be a valid implementation for the latter type of spec
23:22:29 [fantasai]
fantasai: I don't see why there needs to be a distinction
23:22:52 [fantasai]
dino: How many browsers does it have to work in?
23:23:01 [zcorpan]
q+
23:23:14 [dbaron]
ack roc
23:23:15 [fantasai]
roc: Implementation in a browser uncovers more interaction problems, that a polyfill might not notice or might not even run into
23:23:46 [fantasai]
Florian: As an answer to this, when we count a browser to continue passing previously-passing tests
23:23:49 [glazou]
Zakim, ack glazou
23:23:49 [Zakim]
I see zcorpan on the speaker queue
23:24:21 [fantasai]
roc: The issue is with interaction of features, e.g. combine multico with X and it explodes
23:24:31 [fantasai]
roc: Feature A and Feature B both work, but A+B explodes
23:24:34 [jdaggett]
jdaggett has joined #css
23:24:37 [dbaron]
ack zcorpan
23:24:40 [fantasai]
zcorpan: There are also different constraints between browser and polyfill
23:24:46 [glazou]
Zakim, ack zcorpan
23:24:46 [Zakim]
I see no one on the speaker queue
23:24:49 [glazou]
hi jdaggett
23:24:52 [fantasai]
zcorpan: A polyfill doesn't have t o care about optimization sin the browser, like the preloader
23:24:59 [fantasai]
zcorpan: If it does all of its work after all the document is loaded
23:25:09 [jdaggett]
glazou: morning!
23:25:18 [fantasai]
zcorpan: A native implementation might want to do the work during parsing, when element is inserted into DOM
23:25:22 [vollick__]
vollick__ has joined #css
23:25:35 [fantasai]
glazou: Would it be acceptable to say that for now a document that is aimed only at polyfills accept polyfills as a valid implementation
23:26:47 [krit]
q+
23:26:49 [dino]
q+ dino
23:26:54 [dino]
q-
23:27:09 [fantasai]
fantasai: I'm concerned that if we design specs only for polyfills, we will end up with specs that *can't* be implemented in browsers, should we decide it ought to be folded into the core
23:27:19 [fantasai]
...????
23:27:21 [dbaron]
Florian: ???
23:27:51 [fantasai]
ChrisL: Sounds like we had weak consensus on allowing polyfills as implementations, then discussed having polyfill-sepcific spec,...
23:27:54 [dbaron]
dbaron: If a REC says it's designed for polyfills, then sure, we might need to change it in order to produce a REC that can be implemented in browsers.
23:27:59 [fantasai]
ChrisL: You really odn't wnat to have to move around your code
23:28:13 [fantasai]
ChrisL: we run into the prefixing issue again
23:28:19 [tantek]
wow how did we descend in to details of polyfilling vs. process?
23:28:34 [fantasai]
TabAtkins: Polyfilled properties are --foo anyway, so you have the prefixing built into the polyfilling
23:28:40 [fantasai]
...
23:28:48 [fantasai]
heycam: standardized version in a browser isn't triggered by that property
23:28:56 [fantasai]
dirk: We do not have custom layout
23:29:08 [fantasai]
dirk: We have to dcide on this propsal right now. Very interesting discussion, but doesn't help LG right now
23:29:25 [krit]
q-
23:29:26 [fantasai]
TabAtkins: Custom layout will be the hardest part of Houdinin, so a long time from now
23:29:42 [fantasai]
TabAtkins: If ucstom layout existed today, mabye different approach, but doesn't exit right now
23:29:50 [fantasai]
TabAtkins: Let's do this simple stuff
23:30:00 [fantasai]
glazou: Sounds like return to LG, push other stuff to ML
23:30:24 [fantasai]
Florian: What does LG want wrt splitting?
23:30:28 [fantasai]
dirk: I thin kit should saty the same
23:30:32 [fantasai]
glazou: I'd like to review that document
23:30:39 [dbaron]
The part of the document I'm most concerned about is the polar coordinate layout bits.
23:30:49 [fantasai]
glazou: New editors draft for this?
23:30:52 [fantasai]
fantasai: I'm in favor
23:30:53 [tantek]
+1 new editor's draft
23:30:54 [fantasai]
tantek: me too
23:31:05 [fantasai]
dbaron: I'm in favor, but I'm concerned about polar coordinates
23:31:11 [fantasai]
fantasai: Yes, I think it needs work
23:31:22 [fantasai]
tantek: Decide on a place for issue to be capture, and ed to link to that
23:31:24 [fantasai]
glazou: In the document
23:31:45 [fantasai]
tantek: File issues and not block publication
23:31:56 [fantasai]
Florian: send mail to www-style
23:32:06 [fantasai]
ChrisL, glazou: Don't see how this is different from previous docs
23:32:09 [fantasai]
tantek: ...
23:32:20 [fantasai]
ChrisL: So you're encouraging use of that existing rule [ to indicate tracker ]
23:32:21 [tantek]
Florian: this has nothing to do with sending email
23:32:32 [fantasai]
[bikeshedding shortname]
23:32:44 [fantasai]
css-round
23:32:47 [fantasai]
css-rounded-display
23:32:54 [fantasai]
Rossen: css-o
23:33:00 [dbaron]
dbaron: it's a focused-enough specification that it should have a longer shortname
23:33:25 [tantek]
this has to do with requiring a link from the editor's draft to a *specific* place for tracking issues, e.g. W3C Bugzilla, Tracker, or a Wiki page
23:33:31 [fantasai]
+1 to css-roundisplay
23:33:44 [tantek]
css-polar?
23:33:44 [ChrisL]
+1
23:33:45 [fantasai]
RESOLVED: Add css-round-display as ED
23:38:07 [johanneswilm]
johanneswilm has joined #css
23:41:39 [estellevw]
estellevw has joined #css
23:42:14 [timeless]
timeless has joined #css
23:48:35 [ojan]
ojan has joined #css
23:48:55 [jdaggett]
break?
23:49:25 [glazou]
just ended, about to resume
23:49:50 [JonathanNeal_]
JonathanNeal_ has joined #css
23:51:18 [fantasai]
Topic: CSS UI
23:51:23 [fantasai]
tantek: In pretty good shape with CSS Ui
23:51:25 [tantek]
https://wiki.csswg.org/spec/css3-ui#steps-to-pr
23:51:28 [fantasai]
tantek: Set of steps to get to PR
23:51:40 [murakami]
murakami has joined #css
23:51:45 [fantasai]
tantek: We're down to about 7 semi-substatial or substantial issues, resolutions on most of them
23:51:59 [fantasai]
tantek: Steps to PR we've go tset of drafts to publish, one queued up
23:52:04 [fantasai]
tantek: fixes to issue sat this meeting
23:52:17 [fantasai]
tantek: Interest in testcases? spec is probably stable
23:52:26 [fantasai]
tantek: features is stable, cutitng things, not adding things
23:52:44 [fantasai]
ChrisL: Coudln't run the first test
23:52:58 [fantasai]
ChrisL: for directional navigation
23:54:00 [fantasai]
fantasai: I would like to see a WD of what you think should be going to LCCR, i.e. after you've fixed the oustanding issues, and then request a review of that. You haven't demonstrated wide review
23:54:14 [glazou]
jdaggett: we’ll set that up for next topic, css inline, ok,
23:54:35 [jdaggett]
ah, ok
23:55:02 [tantek]
Current issues: https://wiki.csswg.org/spec/css3-ui#current-issues
23:55:39 [fantasai]
tantek: Issue 47
23:55:46 [fantasai]
tantek: Objection from Tab to resolution, +1 from smfr
23:55:47 [tantek]
https://wiki.csswg.org/spec/css3-ui#issue-47
23:56:09 [fantasai]
tantek summarizes the issue
23:56:19 [fantasai]
original spec talked about a "resize factor" that was maintained
23:56:45 [fantasai]
implementations instead modify 'width/height' inline styles directly
23:57:09 [fantasai]
tantek: downside of speccing that is that it limits how you handle e.g. resizing of the window by the user
23:57:21 [fantasai]
tantek: You rob the author and user of having interfaces that dynamically resize in a sensible manner
23:57:34 [fantasai]
tantek: Resolution at last telecon was to change "factor" to "function"
23:57:42 [fantasai]
tantek: and allows for more intelligent resizing
23:57:57 [fantasai]
tantek: The point here is t not restirct the web platform in ways that preven tit from being competitive with native platforms
23:58:13 [fantasai]
tantek: That's the goal of sticking with the function wording, rather than rtificially restricting to style attrs
23:58:32 [fantasai]
Florian: Current behavior with browsers does fall short where we could do better
23:58:51 [fantasai]
Florian: I disagree that the funciton is a good way to solve this, because it's so generic, better ones and worse ones, could be conformant
23:59:18 [fantasai]
Florian: Also, I think it's reasonable to spec in adetailed way what is currently implemented, but also to extend it
23:59:37 [fantasai]
Florian: e.g. say "resize me, but do so in percent, rather ahn in pixels" or "resize me in ems rather than in pixels"
23:59:58 [fantasai]
Florian: The function that you allow is undefined, which is good because it allows good behavior, but is also bad because it also allows bad behaviors
00:00:07 [SimonSapin]
+1 Florian
00:00:15 [fantasai]
Florian: Would rather spec what browsers are actually doing, and allow extending
00:00:20 [glazou]
Dean also said +1
00:00:35 [dbaron]
I think the underlying problem with 'resize' is that the feature was specified at the wrong layer of the platform (too low).
00:00:36 [AndreyR]
+1
00:00:41 [fantasai]
fantasai: What would would be worse than the current behavior?
00:01:43 [fantasai]
Florian: ... not ineroperable
00:02:16 [fantasai]
fantasai: So your issue is that non-interoperable is bad. I'm asking, what is a specific behavior that is worse than the curent behavior? Because I think the current bheavior is the worst tha I can think of that isn't pathological (e.g. semi-random output on resize)
00:02:33 [fantasai]
dbaron: I think the underlying problem with this feautre is that it was designed at the wrong layer of the platform
00:02:47 [fantasai]
dbaron: Was trying to hookinto low-level CSS width funcitons what should have been a hgher function
00:03:03 [fantasai]
dbaron: It's a lot of work for something that shows up in hgh-evel controls
00:03:20 [fantasai]
dbaron: Implementations proxy it down to a lower level, using what authors could use to do it
00:03:41 [fantasai]
dbaron: reue their existing code rather than changing width/height computation for everything else in their codebase
00:03:46 [fantasai]
dbaron: We have a legacy feature
00:03:51 [fantasai]
dbaron: We should just spec it better
00:04:09 [zcorpan]
q+
00:04:11 [fantasai]
dbaron: And figure out a better way to have the feature that doesn't go poking in low-level CSS calculations
00:04:20 [fantasai]
tantek: The intent was to keep it high-level from the start
00:04:41 [fantasai]
tantek: that's how it started, trying to specify purely as a high-level feature, not imposing at all on how impl implemented it
00:04:49 [fantasai]
tantek: The factor was a possible case, generalize dto function
00:05:03 [fantasai]
tantek: There seems to be that even that is specifying too much
00:05:12 [fantasai]
TabAktkins: Not specifying enough
00:05:20 [fantasai]
tantek: Goal was to make this a high-level feature for authors
00:05:29 [fantasai]
tantek: Not sure what different approach could be takn
00:05:36 [TabAtkins]
TabAtkins has joined #css
00:05:53 [fantasai]
Florian: What we have now is extensible
00:05:59 [fantasai]
tantek: By specifying new values
00:06:44 [fantasai]
fantasai: The default behavior would still be the stupid behavior, that doesn't resize well. Even if you add more keywords, the number of people who use it would be negligible
00:06:55 [fantasai]
tantek: Should do the right thing by default
00:07:23 [fantasai]
Florian: I have wording for the current interop behavior
00:07:33 [fantasai]
Florian: Blink and webkit differ from FF in a couple cases
00:07:49 [fantasai]
Florian: I propose to spec this and see if anyone disagrees
00:07:55 [fantasai]
Florian: built up from tests
00:08:11 [fantasai]
zcorpan: When and if we do come up with a successor of this feature, that can provide better behavior
00:08:29 [fantasai]
zcorpan: I thin kit is good to not let the different browsers choose different behaviors for the same request from teh authors
00:08:40 [fantasai]
zcorpan: bad if .e.g one browser uses pixels and other uses percents
00:09:44 [fantasai]
fantasai: The author doesn't notice any problems or differences in behavior because they're designing in a single size
00:10:12 [fantasai]
fantasai: The differences in behavior only show up when you resize the window
00:10:31 [fantasai]
tantek: Resizing the window is pretty common *rotates his phone* This is resizing the window
00:10:37 [achicu_____]
achicu_____ has joined #css
00:10:48 [fantasai]
Tab, florian: You just resize it again.
00:11:00 [fantasai]
tantek: If the sceen gets narrow I can't get to the resie handle
00:11:05 [fantasai]
tab: scroll an resize again
00:11:22 [fantasai]
[basically user has sucky experience because we have interop, and we don't give a shit]
00:11:44 [fantasai]
tantek: You want to make the poor behavior a must?
00:11:55 [JonathanNeal_]
JonathanNeal_ has joined #css
00:11:59 [JonathanNeal_]
hola
00:12:16 [lmclister______]
lmclister______ has joined #css
00:13:04 [fantasai]
fantasai: So I don't unerstand the suggestions to create a new feature that does better
00:13:15 [fantasai]
fantasai: Either you are happy with the existing behavior, or you want a better behavior.
00:13:29 [fantasai]
fantasai: if you want a better behavior, you could do it by adding a new feature, or you can do it by improving the existing one
00:13:42 [fantasai]
fantasai: The only reason to create a new feature rather than imprving the existing one is if you have a legacy problem
00:13:49 [fantasai]
fantasai: I don't think we have a legacy problem
00:13:56 [fantasai]
s/problem/problem here
00:13:58 [jdaggett]
heycam: thanks!
00:14:18 [fantasai]
[...]
00:14:37 [fantasai]
tabatkins: floating first letter is an example where we had bad behavior, couldn't improve it so made new feature
00:15:29 [fantasai]
tantek: Did design methodology change?
00:15:54 [fantasai]
ChrisL: Must is what you should say in all cases where you know what is the right hting to do
00:16:05 [fantasai]
ChrisL: Should allows you to not o that if you have a good reason, but good reason is not defined
00:16:35 [fantasai]
SteveZ: Should was being used often in cases where there was not interop, and we didn't expect interop in the timeframe of getting the spec out, but there was at least one version that people could match over time to get interop
00:16:53 [fantasai]
SteveZ: So we used should in context of saying, you're not going to be an invalid implementation just ecause of the fact you don't match it now, but this i where we want people to be going
00:17:11 [fantasai]
tantek: So if there was in implementation of resize of good behavior, we could put a should
00:17:20 [fantasai]
SteveZ: Yes, and we could spe cthat particular one as a should
00:17:57 [fantasai]
fantasai: And we use d'may' in cases where we didn't have an implementation, but we knew which direction we wanted to go to
00:18:12 [fantasai]
tantek: My memory agrees with what steve was saying
00:18:36 [fantasai]
tantek: I'm oky with speccing style attr in pixels, and nobody shows any intent to make it better.
00:19:10 [tantek]
https://wiki.csswg.org/spec/css3-ui#issue-48
00:19:10 [fantasai]
RESOLVED: spec sucky behavior because we have interop and nobody wants to make it better
00:19:22 [fantasai]
Florian: cursor: auto is vaguely defined
00:19:54 [fantasai]
RESOLVED: spec resize property to inject 'width/height' style attr values in pixels
00:19:57 [dbaron]
I guess my opinion about it being badly designed might not be as strong as it was 10 minutes ago, after looking at our code.
00:20:15 [fantasai]
tantek: We had a group discussio non auto cursor, to try to restrict auto value as much as possible
00:20:24 [fantasai]
tantek: define specifics instead
00:20:37 [fantasai]
tantek: issue wrt resze areas and scollbars
00:20:44 [fantasai]
tantek: proposal handles this, but may need additional wording
00:21:08 [dbaron]
though I still don't know how resizing the old way would interact with something like flexbox
00:21:12 [fantasai]
Florian: dbaron's original proposal of switching between switching between text vs. default
00:21:19 [dbaron]
(old way being as a resize factor)
00:21:25 [fantasai]
Florian: either out of scope for CSS, or expressable in a UA style sheet
00:22:03 [fantasai]
Florian: We decided that resize cursor for the resize handler is an override over whatever cursor value tha author chose, not specific to auto
00:22:22 [fantasai]
Florian: You can do magic over links for auto, but don't have to
00:22:36 [fantasai]
Florian: The only thing that needs to be magic inside auto is text vs. empty space
00:22:54 [fantasai]
ChrisL: Should we have some way to know whether you're empty space or text
00:23:07 [fantasai]
tantek: Don't have a way to detect scrollbars or ersize handlers either
00:23:14 [fantasai]
Florian: We don't have a ::cursor pseudo
00:23:42 [fantasai]
ChrisL: So proposal is to have auto switch between 'default' and 'text' base don whether you're over text
00:24:07 [fantasai]
tantek: and text already hadles horizontal vs vertical text cursors
00:24:34 [fantasai]
ChrisL: what about links?
00:24:41 [fantasai]
Florian: You hae a ua style rule for that
00:24:53 [fantasai]
zcorpan: If you specify auto on a link, then you get a text cursor
00:25:03 [fantasai]
zcorpan: html style sheet requires UA to specify pointer on links
00:25:18 [fantasai]
tantek: Possible regression if people have written * { cursor: auto; }
00:25:32 [fantasai]
Florian: Matches what firefox does, webkit does more magic
00:25:46 [fantasai]
RESOLVED: auto cursor switches between default/text whether you're over text. No other magic
00:26:02 [tantek]
Issue 55: https://wiki.csswg.org/spec/css3-ui#issue-55
00:26:03 [fantasai]
Topic: outline
00:26:18 [fantasai]
Florian: Simple cases, everyone understands outline, but aside from that there's no interop
00:26:25 [fantasai]
Florian: Not possible to spec it all in Level 3 timeframe
00:26:44 [fantasai]
Florian: Would like group to sanction having a very loose spec for outline in L3
00:26:51 [fantasai]
tantek^: In some cases we can't spec
00:26:56 [AndreyR]
agree
00:27:00 [fantasai]
Florian: And clarify in L4
00:27:10 [jumland]
jumland has joined #css
00:27:13 [fantasai]
Florian: E.g. what do you do if element is tranformed? Do you transform the outline or not?
00:27:39 [fantasai]
Florian: If children overflow, do you extend outline to include them? Is the outline a rectange or weird shape in that case?
00:27:51 [fantasai]
tantek: Contrary to resize, this is a feature wher we've seen a lot of innovation in browsers
00:28:03 [fantasai]
tantek: It is an area that is so diverse that we don't want to pick any favorites righ tnow, because we don't know how to specify those
00:28:12 [fantasai]
tantek: We've sene some nice stuff, and want to see what hte market comes up with
00:29:06 [fantasai]
tantek: issue 55 and 51 close as no change
00:29:11 [fantasai]
fantasai: agree with closing 55
00:29:19 [fantasai]
Florian: 51 is transforming outline
00:29:32 [fantasai]
fantasai: If you have interop on something you don't want, then need to speak up about it
00:29:35 [AndreyR]
no obj
00:29:49 [fantasai]
...
00:29:50 [nikos]
nikos has joined #css
00:30:13 [fantasai]
Florian: Need to answer question of whether outline is supposed to be a focus indicator or a border that doesn't take up layout
00:30:58 [ChrisL]
fantasai: whether it rounds on radius, z-inex
00:31:14 [ChrisL]
s/inex/index
00:31:18 [fantasai]
fantasai: I'm concerned that if you don't deal with this now, you'll end up not having a choice
00:31:45 [ChrisL]
fantasai: you need to address hte transform issue
00:32:24 [ChrisL]
... must do it now or its too late
00:32:52 [ChrisL]
... do we want to transform the outline or not
00:33:23 [fantasai]
fantasai: would like to know what other people think, because my opinion is completely worthless here
00:33:44 [fantasai]
dbaron: If you're in a 3d schene, there isn't necessarily a decent definition of what era is covered by your children
00:33:57 [fantasai]
Florian: If you wnat outline to be a focus indicator, you put outline around the projected result
00:34:02 [fantasai]
Florian: We haven't specified this
00:34:25 [tantek]
52: https://wiki.csswg.org/spec/css3-ui#issue-52
00:34:28 [fantasai]
dbaron; Think we can't specify now
00:34:30 [fantasai]
tantek: Objections?
00:34:46 [fantasai]
RESOLVED: Don't specify anything for how outline sactually work other than what's there already
00:35:20 [fantasai]
tantek: No interop on pseudo-elements
00:35:28 [fantasai]
tantek: Suggest to say that they don't apply to pseudo-elements
00:35:31 [nduca]
nduca has joined #css
00:36:05 [fantasai]
Florian: I don't think you can say that it does not apply and then make it apply later
00:36:19 [fantasai]
dbaron: What we do is say the applies to line, and then have a note saying that in the future we might extend things
00:36:38 [fantasai]
tantek: proposal is resize doesn't apply to pseudos, and add a note that it may apply in the future
00:37:15 [fantasai]
fantasai: Wouldn't say where it's going to be solved, just say it may be solved in the future
00:37:33 [fantasai]
RESOLVED: resize doesn't apply to pseudos. Note that this may change in the fuutre
00:38:13 [tantek]
https://wiki.csswg.org/spec/css3-ui#issue-68
00:38:38 [fantasai]
Florian: Initial version of text overflow required overfow ~= visible and line would overflow its containing block
00:38:51 [fantasai]
Florian: This is unfortunate if you have a float in the way. You'd overlap the float
00:39:01 [fantasai]
Florian: spec is changed to elide before the float
00:39:05 [fantasai]
Florian: Which is what Webkit does
00:39:30 [fantasai]
tantek: Suggestion to reuqest that text-overfow apply even when overflow is visible
00:39:47 [fantasai]
rossen: prolematic
00:40:00 [tantek]
I think generalizing to regardless of overflow value is too big of a change
00:40:10 [fantasai]
rosen: What would a block with text-overflow: ellipsis would report for its main content size, if all lines are llipsized?
00:40:16 [fantasai]
fantasai: text-overflow does not affect sizing
00:40:44 [fantasai]
...
00:41:04 [fantasai]
Florian: What was specced was firefox's behavior. now specced webkit's behavior.
00:41:14 [fantasai]
Florian: Firefox also asked for not requiring the overflow rule
00:41:35 [fantasai]
tantek: We dont' have an implementation yet, though
00:41:42 [AndreyR]
agree with Tantek
00:41:54 [tantek]
fantasai: main concern I have with the overflow issue is web compat
00:43:17 [fantasai]
RESOLVED: leave spec as-is, don't apply text-overflow when overflow: visible
00:43:26 [tantek]
https://wiki.csswg.org/spec/css3-ui#issue-76
00:43:49 [fantasai]
tantek: Request made over twitter to allow implementations to elllipse for text overflow not at a character break boundary but at a line break opportunity
00:43:59 [fantasai]
tantek: Seems like a reasonable request, not sure if anyone would ever do it, so I put it in as a may
00:44:03 [fantasai]
tantek: One request ot revert it
00:44:34 [fantasai]
tantek: Text overflow, when you get to point where it overflows, isntead of clipping you back off the number of characters to have ellipsis and not partial characters
00:44:45 [fantasai]
tantek: Proposal is to ellipse at a word boundary, line-wrapping opportunity
00:45:01 [fantasai]
Florian: I have a few probems with this problems
00:45:11 [fantasai]
Florian: What looks better depends a lot on the context
00:45:20 [tantek]
dino: we would do that, ellipse at a line-wrap opportunity
00:45:32 [fantasai]
Florian: If you're in a mixed directionality context, starting elingsh, Hebrew going the other way around. Now what exactly are you doing? You don't want ellipsis in the middle of the line
00:45:40 [fantasai]
TabAtkins: Ellipsis is visual
00:45:55 [fantasai]
Florian: Another issue is do you know enough about wrapping opportunities to do it at the visual layer when you're doing the ellipsis
00:46:07 [fantasai]
Florian: Another isue is scrolling. If you scroll, upposed to reveal more content as you go
00:46:19 [fantasai]
Florian: really weird to dro pin word sas you scroll
00:46:47 [fantasai]
tantek: Behvior for scrolling is already looser than wording for not scrolling
00:47:17 [tantek]
fantasai: I disagree with this change, if you want this change it should be a separate property and/or keyword
00:47:30 [tantek]
… to allow ellipsing at a word / line-wrap opportunity
00:47:32 [zcorpan]
q-
00:47:54 [zcorpan]
Zakim, ack fantasai
00:47:54 [Zakim]
I see no one on the speaker queue
00:48:43 [fantasai]
RESOLVED: Drop wording allowing word-drops, add as a new feature in L4 e.g. as a new keyword or something
00:49:21 [glazou]
Zakim, room for 3?
00:49:21 [dbaron]
Zakim, room for 3?
00:49:22 [Zakim]
ok, glazou; conference Team_(css)00:49Z scheduled with code 26631 (CONF1) for 60 minutes until 0149Z
00:49:22 [Zakim]
dbaron, an adhoc conference was scheduled here less than 2 minutes ago
00:49:37 [dbaron]
jdaggett, ^
00:49:56 [jdaggett]
dbaron: got it
00:50:28 [Zakim]
Team_(css)00:49Z has now started
00:50:36 [Zakim]
+ +61.2.956.6.aaaa
00:50:36 [Zakim]
+[IPcaller]
00:51:03 [jdaggett]
ok, muted
00:51:15 [jdaggett]
zakim, +ipcaller is me
00:51:15 [Zakim]
sorry, jdaggett, I do not recognize a party named '+ipcaller'
00:51:25 [dbaron]
Zakim, aaaa is MeetingRoom
00:51:25 [Zakim]
+MeetingRoom; got it
00:51:27 [jdaggett]
zakim, +[IPcaller] is me
00:51:27 [Zakim]
sorry, jdaggett, I do not recognize a party named '+[IPcaller]'
00:51:39 [dbaron]
Zakim, [IPcaller] is jdaggett
00:51:39 [Zakim]
+jdaggett; got it
00:51:39 [heycam]
Zakim, [IPCaller] is jdaggett
00:51:40 [Zakim]
sorry, heycam, I do not recognize a party named '[IPCaller]'
00:51:53 [heycam]
Zakim, you have a short memory
00:51:53 [Zakim]
I don't understand 'you have a short memory', heycam
00:52:00 [jdaggett]
hehe
00:52:11 [fantasai]
Topic: CSS Inline
00:52:24 [fantasai]
dauwhe: Wanted to go over some issues with inital letters
00:52:40 [fantasai]
dauwhe: Then wanted to review css-linebox stuff
00:52:48 [fantasai]
dauwhe: Florian raised various issues, here's the first one
00:53:17 [fantasai]
dauwhe: Where initial letter is part of the same word, we want at least Latin text to kern back a little bit so that there istn' a break within teh word
00:53:45 [fantasai]
dauwhe: but don't want to do that for CJK
00:54:25 [fantasai]
[sending slides over]
00:54:44 [fantasai]
SteveZ: There are examples where you want to kern the second line as well
00:54:51 [fantasai]
SteveZ: You want to follow the shape of the outline
00:54:59 [fantasai]
dauwhe: We do want that, but the full effect of that would be the next level
00:55:08 [fantasai]
SteveZ: By specifying what your'e doing, you screw up the extension
00:55:28 [Zakim]
+Liam
00:57:13 [jdaggett]
is this discussion about the illustration in 2.9? http://dev.w3.org/csswg/css-inline/#initial-letter-position
00:57:16 [fantasai]
fantasai: yes, we want to do kerning around the shape of the letter eventually, but that's a stylistic choice: we decided to do the rectangular version first
00:57:44 [glazou]
liam: shoot
00:57:52 [fantasai]
fantasai: We're not going to allow various behaviors, have to define one or the other, shouldn't be up to the UA
00:57:53 [glazou]
Zakim, unmute liam
00:57:53 [Zakim]
Liam should no longer be muted
00:58:01 [fantasai]
SteveZ: ...
00:58:27 [fantasai]
Liam: There are examples that don't kern the first line of text, but they're not good examples, should try to do it if we can
00:58:48 [fantasai]
...
00:59:10 [fantasai]
jdaggett: It think this is a feature that needs more work
00:59:18 [liam]
[not good - there were technological limitations in the past]
00:59:19 [fantasai]
jdaggett: e.g. distance from glyph outline to text needs to be controllable
00:59:49 [heycam]
jdaggett, slides here: https://lists.w3.org/Archives/Public/www-archive/2015Feb/0004.html
01:00:05 [fantasai]
fantasai: I think for controlling the distance you can use the padding/margin on that side of the glyph
01:01:00 [tantek]
a decade ago I had proposed ::first-letter('A') to select only first letters that were a capital 'A' in order to customize styling on it
01:01:01 [dbaron]
I actually haven't found examples of follow-the-curve.
01:01:35 [Zakim]
-Liam
01:01:40 [tantek]
I found examples of follow-the-curve plenty over a decade ago
01:01:51 [fantasai]
fantasai: From what Liam and dave cramer was saying is that the common case is kerning that first line, so that should be the default.
01:01:52 [Zakim]
+Liam
01:02:05 [tantek]
q+
01:02:12 [fantasai]
fantasai: If you want a rectangle, you can add a transparent border
01:02:28 [fantasai]
s/use the padding/use the
01:03:01 [fantasai]
SteveZ: issue is should the kerning apply only on the top example, the rectangular one, or should it apply
01:03:02 [astearns]
http://graphicdesign.stackexchange.com/questions/10561/text-wrap-in-illustrator-cs6
01:03:09 [fantasai]
SteveZ: What should be tehd efault
01:03:49 [fantasai]
fantasai: the way it works right now is that you only do this kerning if you have marigns but not borders or padding
01:05:00 [tantek]
q?
01:05:02 [fantasai]
fantasai: we took the marign collapsing principle that the edges of the box are permeable if padding/border is zero
01:05:08 [fantasai]
fantasai: So you can get both behaviors
01:05:16 [fantasai]
fantasai: And I thin kthe model is fairly consistent
01:05:30 [fantasai]
[argument over which is more common, clearly not clear]
01:05:45 [dbaron]
Yeah, I've seen a lot where the first line follows the initial letter outline, but I couldn't find examples where lines other than the first do.
01:05:52 [fantasai]
fantasai: You can add margins if you want more spacing, you can add spacing if you want rectangularness
01:06:55 [fantasai]
dauwhe: We could defer if necessary for implementations
01:07:00 [fantasai]
fantasai: I would prefer to try for this
01:07:34 [fantasai]
fantasai: There is a sensical mode. Wrt implementability, you need the glyph outline (which you have to have anyway, sicne that define sthe content box of the initial letter)
01:07:41 [fantasai]
fantasai: and you need an offset control, which is provided by margin
01:07:58 [fantasai]
tantek talks about full wrapping
01:08:09 [fantasai]
dauwhe: Case #3 is much more common and simple, prefer to defer it
01:08:25 [fantasai]
Florian: Unless someone wants to argue that the bottom is undesirable or relatively bad thing that we don't want to be the default, then
01:08:33 [fantasai]
Florian: I think the model is very sane.
01:08:57 [fantasai]
SteveZ: My concerns weren't that case #3 isn't deirable, but worried about separating case #3 and full kerning
01:09:18 [fantasai]
SteveZ: Want to see how it interacts with full kerning
01:09:31 [fantasai]
tantek: I'd like to see what full kerning would look like, an dinclude it in teh draft now, before cutting it
01:09:43 [fantasai]
dauwhe: I'm okay, if that's where we want to go
01:10:00 [jdaggett]
q+
01:10:05 [fantasai]
Liam, tantek, Szilles, fantasai agree on this approach
01:10:34 [fantasai]
liam: As an implementer, think it's good to have all possibilities there, will help to organize your code appropriately
01:10:53 [tantek]
q-
01:10:56 [tantek]
ack jdaggett
01:10:59 [fantasai]
jdaggett: I want to make clear that I think the difference between the first option and the one that's in any way following the outline is an exponential order of time difference
01:11:15 [fantasai]
jdaggett: because you're looking at the glyph outline
01:11:37 [fantasai]
jdaggett: Wouldn't imagine that a mobile browser wants to do that
01:11:51 [fantasai]
dauwhe: Wouldn't it make sense to include this and then react to implementation experience later
01:12:00 [fantasai]
jdaggett: I think this should be opt-in behavior
01:12:16 [fantasai]
tantek: I think some impls have motivation to do high-fidelity rendering
01:12:30 [fantasai]
tantek: You mention mobile, I thin that's a top use case
01:12:40 [fantasai]
jdaggett: I don't think it's universally true that his is the optimal thing
01:12:44 [fantasai]
jdaggett: It depends on the use case
01:13:01 [fantasai]
jdaggett: The behavior of margins vs. padding is confusing to authors
01:13:14 [fantasai]
dbaron: I agree that doing this based on padding/border being set is confusing
01:13:19 [fantasai]
dbaron: Odd implicit thing that people won't get
01:13:56 [fantasai]
dauwhe: full kerning would need another switch
01:14:11 [fantasai]
dauwhe: I think at this poin tit's worth doing the full thing, cost mostly on editors writing spec, and then check in with implementors later
01:14:28 [SteveZ]
+1 for borders and padding being confusing in this case
01:14:31 [stryx`]
stryx` has joined #css
01:15:00 [fantasai]
RESOLVED: Add full kerning to css-inline, perhaps dropped later based on implementation experience, but try to figure out how it all fits together
01:15:03 [liam]
+1 add and solicit more feedback
01:15:06 [tantek]
+1
01:15:35 [fantasai]
dauwhe: Florian brought up issue of what if initial letter is a different script than the surrounding text.
01:15:58 [fantasai]
dauwhe: Conclusion is you use the top alignment point of each script and the bottom alignment poitn of each script
01:16:11 [tantek]
q+ to ask about leading quote
01:16:17 [fantasai]
dauwhe: E.g. A inside indic script shows cap-height to hanging-example, alphabetic to alphabetic
01:16:25 [fantasai]
dauwhe: Florian has an example of this
01:16:31 [fantasai]
Florian: Chinese-english dictionary
01:17:07 [fantasai]
RESOLVED: Choose alignment points as described above
01:17:15 [fantasai]
dauwhe: Next issue is run-in
01:17:29 [fantasai]
Florian: Combination of run-in and :first-letter
01:17:46 [fantasai]
Florian: Having ::first-letter select the first letter of the original text seems very weird
01:18:28 [fantasai]
Florian: Makes more sense to select the first letter including the run-in
01:18:35 [fantasai]
Florian: Should either select that or select nothing
01:19:01 [fantasai]
tantek: I lean towards selecting nothing, the author can select the first letter of the run-in
01:19:17 [fantasai]
dbaron: Does ::first-letter apply to run-ins? I don't think it does.
01:19:23 [Florian]
example of mixed scripts http://florian.rivoal.net/csswg/cn-en_raised-cap_shed.jpg
01:19:26 [tantek]
but it could
01:19:41 [tantek]
::first-letter *could* apply to something with display:run-in
01:20:54 [fantasai]
fantasai: I think dbaron' is right. Run-ins are defined as inlines, effectively. And you can have multiple run-ins run into the same paragraph, in which case one of them for sure won't be at the beginning of the paragraph
01:21:10 [fantasai]
fantasai: So I'm not sure we can have ::first-letter apply to run-ins.
01:21:34 [fantasai]
fantasai: In which case, you'll want to have ::first-letter select the first letter of the first run-in in a paragraph, since there's no other way to do it
01:21:48 [fantasai]
fantasai: Although I'm not a box-construction expert, so I don't know if that's sane.
01:22:46 [dbaron]
What decision are we trying to make right now?
01:23:08 [fantasai]
fantasai explaisn run-in box model: old model was run-in is a block if it doesn't run into anything; new model it's always an inline, sometimes inside an anonymous block
01:23:55 [fantasai]
Florian, fantasai: So if we want to do this, either run-ins need to accept ::first-letter, or ::first-letter needs to apply to to a run-in inside a paragraph
01:24:31 [fantasai]
SteveZ: Off-topic: the example on the screen is aligne dto the x-height, not the cap-height
01:24:49 [fantasai]
dauwhe: The box aligns to the alignment points, it has padding and a background
01:25:17 [fantasai]
Discussion moved ot ML
01:25:29 [fantasai]
dauwhe: We had a discussion wrt floats and initial letter
01:26:14 [fantasai]
SteveZ: Having a float that occurs in the 2nd line be 1 line down from teh top of the paragraph is the worst behavior
01:27:47 [dbaron]
fantasai: You run into a problem when you have a floating image somewher in lines 1-3 -- in those cases you should clear the initial letter.
01:28:15 [fantasai]
Florian: [to steve] that proposal would introduce a loop in the layout that doesn't exist
01:28:20 [astearns]
I think line 1 should be fine, floats in lines 2+ should clear
01:28:21 [fantasai]
SteveZ: No it doesn't , it alrady exists
01:28:50 [dbaron]
The static on the audio system is really getting on my nerves.
01:30:16 [fantasai]
[discussion about whether floats moving up creates a problem]
01:31:15 [fantasai]
Rossen: Do you expect your proposed algorithm to work for only left floats?
01:31:20 [fantasai]
SteveZ: yes
01:31:34 [fantasai]
Rossen: Then you're proposal only affects one side of floats
01:32:01 [fantasai]
dbaron: We only have a problem on ths side of the initial letter
01:32:03 [Zakim]
-Liam
01:32:06 [fantasai]
dbaron: And I don't belive steve. There's a problem.
01:32:48 [fantasai]
fantasai: Does anyone other than Steve think ther eis not a problem?
01:32:50 [fantasai]
[silence]
01:33:04 [fantasai]
fantasai: Okay, then I suggest someon eexplain it to seve during a break, otherwise we'll spend the rest of the presentatio neplaing how floats work
01:33:14 [fantasai]
next slide
01:33:35 [fantasai]
dauwhe: Want the ability to position the box as a whole including borders padding backgrounds
01:34:07 [fantasai]
dauwhe: florian suggested that we use box-sizing to deterine whether you align the letter or the box
01:34:28 [fantasai]
astearns: I thin it's a bit confusing to use box-sizing. might be better to have that as a keyword in the initial-letter property
01:35:14 [fantasai]
Florian: The initial letter-align property says which set of baselines to use
01:35:19 [fantasai]
Florian: Must speak eithe rof the ltter or the box
01:35:30 [fantasai]
Florian: If you're aligning a box, the baseline values mean nothing
01:35:48 [fantasai]
Florian: Other values were aobut vertical centering of box once you have the box or something
01:36:02 [fantasai]
Florian: We could have a different property for this switch
01:36:24 [fantasai]
Florian: The nice thing about box-sizing is that...
01:36:44 [fantasai]
astearns: it made a lot of sense to have hsape-outside key off of box sizing
01:36:56 [fantasai]
astearns: but we were eventually convinced that having that conflation of concerns for box-sizing was something to avoid
01:37:05 [fantasai]
astearns: and that's why we put the keyword into the shape keyword itself
01:37:15 [fantasai]
fantasai: Why not use initial-letter-align?
01:37:18 [tantek]
topic?
01:37:23 [tantek]
(is there a URL)
01:37:29 [fantasai]
Florian: What does padding do if you don't have this?
01:38:08 [fantasai]
Florian: Why not use box-sizeing, since we've changed what we're using box sizing
01:38:17 [fantasai]
fantasai: People put box-sizing on everything today, to make it border-box
01:39:24 [fantasai]
Florian: Then by default in those pages you will align the border box
01:39:30 [fantasai]
...
01:39:49 [fantasai]
dauwhe: The initial indic req doc says that the bottom alignment point of indic scripts is the text-bottom edge (base don em box)
01:39:56 [fantasai]
dauwhe: but it is definitely not correct
01:40:08 [fantasai]
dauwhe shows example
01:40:17 [fantasai]
dauwhe: You get very unrealistic results, don't seem to match examples i've seen
01:40:24 [fantasai]
dauwhe: because this alignment point is not a visible thing in the font
01:40:32 [fantasai]
dauwhe: The bototm alignment point in these scripts is in fact the alphabetic baseline
01:40:49 [fantasai]
dauwhe: Matches much more closely to real examples, and to things we can see in the fonts
01:41:00 [fantasai]
dauwhe: Still have lots of questions about CJK
01:41:11 [fantasai]
dauwhe: The top exampel here is Hebrew
01:41:21 [fantasai]
dauwhe: One problem with Hebrew is that the font metrics don't seem to have a natural alignment point
01:41:29 [fantasai]
dauwhe: There's a strong vetical rhythm along the top of the characters
01:41:46 [fantasai]
dauwhe: there is a probable top alignment point there
01:41:54 [fantasai]
dauwhe: but ti's not an existing metfic. It's not the x-height, or cpa-height
01:42:03 [fantasai]
dauwhe: Not what issue that raises for this
01:42:09 [fantasai]
dauwhe: In the case of Arabic I have no clue
01:42:36 [fantasai]
fantasai: I think the character you want to align to is the alef
01:42:48 [fantasai]
fantasai: the top of the first letter at the begining of your example
01:42:59 [fantasai]
lam has the same height (normally)
01:43:11 [fantasai]
dauwhe: projects a table of alignment points
01:43:29 [fantasai]
dauwhe: myth of hanging baseline
01:43:44 [fantasai]
dauwhe: John Hudson mad ethe point that most fonts typically don't implement the base table that specifies the position of a hanging baseline
01:43:52 [fantasai]
dauwhe: And most software doesn't actually use the hanging baseline
01:44:00 [fantasai]
dauwhe: They're not even sure if hangin base line is what happens in these scripts
01:44:11 [fantasai]
dauwhe: Here's some example sof characters i vastly different size
01:44:23 [fantasai]
dauwhe: What happens in every implementation I'm aware of is alignment at alphabetic baseline
01:44:33 [fantasai]
dauwhe: Looking at CKJ, lots of options in indesign
01:44:36 [Zakim]
+Liam
01:44:46 [fantasai]
dauwhe: Lots of questions about that
01:44:59 [fantasai]
dauwhe: And that's the intro to the next bit, the rest of CSS inline
01:45:05 [fantasai]
dauwhe: Wanted to ge ta sense of what that needs to include
01:45:12 [fantasai]
dauwhe: What needs to change from CSs2.1?
01:45:20 [fantasai]
dauwhe: Do we really need to define 20 kinds of baselines?
01:45:32 [fantasai]
dauwhe: To match bottom ideographic char frame with mathemtaic baseline???
01:45:47 [fantasai]
jdaggett: I think we have some issue with inter-group issue
01:45:52 [fantasai]
jdaggett: SVG has a bunch of stuff taken from XSL
01:46:06 [fantasai]
jdaggett: dominant-baseline and various properties
01:46:13 [fantasai]
jdaggett: huge number of values
01:46:18 [fantasai]
jdaggett: Some people say this is a compat issue
01:46:23 [ChrisL]
dominant baseline stuff was copied from xslt yes and needs to be cleaned up
01:46:25 [fantasai]
jdaggett: But need to coordinate with SVG to see who's going to do what
01:46:29 [fantasai]
jdaggett: Dunno what's actually implemented
01:46:38 [fantasai]
jdaggett: properties are parsed, but what's implemented?
01:46:45 [fantasai]
dauwhe: Yes, curious about what's happening in the wild
01:47:00 [fantasai]
SteveZ: I was going to ask, in the indic example you have there,
01:47:11 [jdaggett]
example: http://mxr.mozilla.org/mozilla-central/source/layout/svg/SVGTextFrame.cpp#328
01:47:13 [fantasai]
SteveZ: It's what browsers do today, but certainly not what happens in print
01:47:18 [murakami]
s/xslt/XSL-FO/
01:47:19 [fantasai]
SteveZ: They do use that in print
01:47:24 [jdaggett]
gecko dominant-baseline implementation
01:47:39 [fantasai]
dauwhe: I haven't actually seen an example of mixed-text sizes in the real world, other than drop-caps
01:48:08 [fantasai]
jdaggett: I think we have to temper things with actual data that we get from fonts
01:48:24 [fantasai]
jdaggett: We have to be careful of using theoretical models of what different baselines exist theoretically vs real world font metrics
01:48:34 [fantasai]
dauwhe: Yeah, I don't belive anything until I can read it out fo the font metric
01:48:41 [fantasai]
SteveZ: That leave syou with real problem with Hebrew then
01:48:54 [fantasai]
SteveZ: Sounds like you're going to end up synthesizing font metrics that you need
01:49:05 [fantasai]
SteveZ: Existing font metric principle won't work
01:49:09 [fantasai]
dauwhe: It's a starting point, not an ending point
01:49:49 [fantasai]
dauwhe: Shoudl we move forward?
01:50:05 [fantasai]
fantasai: Yes, even hav some exisitng resolutions on what to add
01:50:17 [fantasai]
jdaggett: Lots of stuff from SVG, XSL, don't want to add
01:50:24 [fantasai]
fantasai: Yeah, don't wnat to copy from XSL
01:50:51 [fantasai]
SteveZ: Text align had made some assumptions, so XSL was to make vertical-align be a shortcut
01:50:56 [fantasai]
s/text align/vertical align/
01:51:19 [fantasai]
SteveZ: Wnated to place thing,s not just glyphs, but also images
01:51:56 [fantasai]
SteveZ: The list of baelines is unimportant. There was some set that was useful that you might get at.
01:52:16 [fantasai]
RESOLVED: lunch
01:52:27 [glazou]
<br type=‘lunch’>
01:52:32 [Zakim]
-jdaggett
01:52:50 [Zakim]
-Liam
01:53:16 [Florian]
Florian has joined #css
01:53:28 [Zakim]
-MeetingRoom
01:53:29 [Zakim]
Team_(css)00:49Z has ended
01:53:29 [Zakim]
Attendees were +61.2.956.6.aaaa, MeetingRoom, jdaggett, Liam
02:09:31 [adenilson]
adenilson has joined #css
02:34:09 [xidorn]
xidorn has joined #css
02:36:28 [dauwhe]
dauwhe has joined #css
02:36:32 [dauwhe]
dauwhe has joined #css
02:37:30 [estellevw]
estellevw has joined #css
02:44:13 [johanneswilm]
johanneswilm has joined #css
02:46:18 [JonathanNeal_]
TabAtkins: awesome
02:46:29 [murakami]
murakami has joined #css
02:54:16 [Florian]
Florian has joined #css
02:54:35 [gregwhitworth]
gregwhitworth has joined #css
02:56:30 [Florian]
Florian has joined #css
02:58:19 [tantek]
tantek has joined #css
03:02:00 [shepazu]
shepazu has joined #css
03:08:42 [fantasai]
Topic: Page Floats
03:09:21 [JonathanNeal_]
I hope you all expose more CSS power to JavaScript for polyfilling.
03:09:35 [fantasai]
?: Currently spec is unmaintained
03:09:43 [murakami]
murakami has joined #css
03:09:56 [tantek]
tantek has joined #css
03:09:59 [fantasai]
?: Page floats is rule that says images/figures should go to the top, could also say they go to the top in certian circumstances in some cases, to bottom in others
03:10:13 [fantasai]
?: Right now spec that exists for it has Håkon as editor, and hasn't been working on it
03:10:25 [fantasai]
?: Contains page floats, but also exclusions, regions, etc. thatothers are working on
03:10:34 [fantasai]
?: Proposing for me to join the eidtorial team for this spec
03:10:40 [glazou]
s/?/johanneswilm
03:10:46 [fantasai]
tantek: Did you talk to hwocome about it?
03:11:08 [fantasai]
johanneswilm: Will try to engage with him, and everyone in print sector e.g. AH, PrinceXML, vivliostyle
03:11:20 [fantasai]
johanneswilm: Our goal is to create a JS polyfill to get this functionality in browsers
03:11:30 [fantasai]
johanneswilm: Getting browsers to implement was not successful
03:11:49 [fantasai]
dino: Printing might be a narrow use case, but books are not
03:11:52 [zcorpan]
i think håkon now maintains https://books.spec.whatwg.org/
03:11:53 [fantasai]
johanneswilm: Dunno why it wasn't implemented
03:11:59 [fantasai]
fantasai: Because it's vastly underspecified
03:12:05 [fantasai]
Rossen_away: You mentioned a bunch of things
03:12:19 [fantasai]
Rossen_away: What exactly did you want to take over, just page floats? Exclusions? Something else?
03:12:30 [fantasai]
johanneswilm: This is CSS Page Floats. We think that's what it should be about.
03:12:37 [fantasai]
johanneswilm: Exlusions, regions, don't want to work on it
03:12:45 [fantasai]
johanneswilm: Understand it's being worked on elsewhere
03:13:02 [fantasai]
Rossen_away: Path forward wehad agreed on was that exclusions is amodule that provides specification on what happens with exclusion areas
03:13:11 [tantek]
zcorpan: it looks like https://books.spec.whatwg.org/ has not been updated in over 2 (almost 3) months.
03:13:15 [fantasai]
johanneswilm: How these are positioned is not up to that spec, only about propagation of the geometry
03:13:18 [Florian]
q+
03:13:31 [fantasai]
s/johanneswilm/Rossen/
03:13:42 [fantasai]
Rossen: Doesn't deal with layout
03:13:45 [tantek]
and https://books.spec.whatwg.org/ does not appear to mention page-floats
03:13:50 [AndreyR]
AndreyR has joined #css
03:13:53 [fantasai]
Rossen: Are you also planning to work on exclusions, or just layout?
03:14:10 [astearns]
tantek: https://figures.spec.whatwg.org/
03:14:18 [tantek]
only thing that books whatwg spec appears to affect re: floats is float: footnote
03:14:19 [zcorpan]
https://figures.spec.whatwg.org/#page-floats
03:14:22 [fantasai]
johanneswilm: Need to investigate underlying fundamentals
03:14:30 [fantasai]
johanneswilm: Idea is not to talk about it here
03:14:43 [fantasai]
johanneswilm: Want to make it very simple to start with, so just rectangular floats that go up or down
03:14:45 [tantek]
thanks astearns zcorpan
03:14:56 [fantasai]
johanneswilm: And then in discussion with other projects that work with this, try to see what direction they want to go with it
03:15:02 [tantek]
https://figures.spec.whatwg.org/ appears to not have been updated since 2014-09-30
03:15:14 [tantek]
that is - not updated 4-5 months
03:15:16 [fantasai]
Florian: To be clear, exclusions and regions in this spec are not what we can exclusions and regions. They are howcome's counter-proposals to.
03:15:35 [fantasai]
johanneswilm: The counter-proposals, we don't really need them in there.
03:15:38 [fantasai]
dino: Can we remove them?
03:15:44 [ChrisL]
s/what we can/what we call
03:15:46 [fantasai]
dino: It's obviously confusing
03:15:55 [tantek]
agreed, remove them
03:16:04 [fantasai]
RESOLVED: Remove exclusions and regions sections from page floats spec
03:16:26 [fantasai]
RESOLVED: johanneswilm added as editor
03:17:01 [fantasai]
dino: Webkit has been interested in implementing this for awhile, for pages/columns in browser, for our ibooks product
03:17:07 [fantasai]
dino: You don't have to ask just printing companies
03:17:09 [fantasai]
johanneswilm: Sounds great
03:17:19 [fantasai]
johanneswilm: Want to work together with everyone who wants to work on this
03:17:28 [fantasai]
johanneswilm: have a specification that everybody can be proud of
03:17:40 [fantasai]
tantek: Do you have an approach in mind for keeping in sync with Figures spec?
03:17:42 [tantek]
https://figures.spec.whatwg.org/#page-floats
03:17:48 [fantasai]
johanneswilm: We will be talking to howcome and find out what is possible there
03:17:55 [fantasai]
johanneswilm: He also has his own idea of exclusions and regions
03:18:01 [fantasai]
johanneswilm: and first-letter caps
03:18:13 [fantasai]
johanneswilm: Idea is not to import another idea, but we want to try to incorporate as much as possible with howcome
03:18:30 [fantasai]
ChrisL: Anyone implementing Figures?
03:18:35 [gregwhitworth]
gregwhitworth has joined #css
03:18:47 [fantasai]
dauwhe: I'm not aware of anyone. Will have more info after I visit YesLogic this week
03:19:00 [fantasai]
dauwhe: howcome isn't involved in the WG anymore, this is the group that has to decide what gos in the spec
03:19:18 [fantasai]
ChrisL: Great that there's not just a totally-separate-from-browsers group doing this on the side
03:19:41 [fantasai]
Rossen_away: For other browsers that have expeirmental implementations of exclusions, I don't want to all of a sudden drop them and sart working on page floats and stop working on exclusions
03:19:46 [fantasai]
johanneswilm: I don't think they are exclusive
03:19:55 [fantasai]
johanneswilm: If anyone has written thesis in laTex
03:20:04 [fantasai]
johanneswilm: You can write a directive that all figure sand captions go to the top
03:20:12 [fantasai]
johanneswilm: This is the same. You define onece, wher eeverything goes
03:20:24 [fantasai]
johanneswilm: If you want more grpahic art of making books, you want to decide where each figure goes, where each whatever
03:20:33 [fantasai]
johanneswilm: text goes around in funny ways
03:20:40 [fantasai]
johanneswilm: no computer can do that automatically
03:20:57 [fantasai]
cameron: Is it in the spec to go to a new page or a named page?
03:21:20 [fantasai]
johanneswilm: Right now just want to get a simple specification that is similart to what is shipping in these implementations
03:21:29 [fantasai]
johanneswilm: that said, there are many common things not implemented anywhere
03:21:36 [fantasai]
johanneswilm: floating things on other pages, e.g.
03:21:47 [fantasai]
johanneswilm: or float imaes all to a set of 8 pages that are in color others black and white
03:21:56 [fantasai]
johanneswilm: we can grow as far as we need to, but not more than there is implemented
03:22:02 [fantasai]
dauwhe: that's a significant use case for us
03:22:52 [fantasai]
Topic: @extend
03:23:52 [JonathanNeal_]
JonathanNeal_ has joined #css
03:23:57 [fantasai]
TabAtkins: One of the most consistently popular parts of SASS is @extend rule
03:24:01 [fantasai]
TabAtkins: massive update
03:24:20 [ChrisL]
https://lists.w3.org/Archives/Public/public-houdini/2015Jan/0005.html
03:24:23 [fantasai]
TabAtkins: dbaron about 2 years ago suggested something that had almost exactly the same shape as @xtend, but with less convenient syntax
03:24:30 [fantasai]
TabAtkins: Suggested just using @extend, that's what people are used to
03:24:38 [fantasai]
TabAtkins: here's a proposal to add @extend to CSS finally
03:24:53 [TabAtkins]
http://tabatkins.github.io/specs/css-extend-rule/
03:25:12 [fantasai]
TabAtkins: Somewhat trivial example, but large corpus of examples
03:25:25 [fantasai]
TabAtkins: Say you have a bunch of styles for a .error class
03:25:34 [fantasai]
TabAtkins: Later you realize you ned to make a really serious error class
03:25:51 [fantasai]
TabAtkins: same styles, but make it red and bold as well
03:26:08 [fantasai]
TabAtkins: ways to do this now, have to make all markup using seriouserro class also have error class
03:26:12 [fantasai]
TabAtkins: Need to track in HTML
03:26:25 [fantasai]
TabAtkins: also in DOM manipulation
03:26:43 [fantasai]
TabAtkins: add and remove together, fairly error prone
03:26:56 [fantasai]
TabAtkins: alternate way is that in CSS every rule that has .error, also have a .seriouserror selector
03:27:09 [fantasai]
TabAtkins: Also not great, because have to duplicate every single selector
03:27:15 [fantasai]
TabAtkins: Also maintain that as you remove selectors
03:27:20 [fantasai]
TabAtkins: Lots o f potention for typos
03:27:32 [fantasai]
TabAtkins: Not good solutions to hadling this kind of subclassing of widgets in CSS
03:27:38 [fantasai]
TabAtkins: @extend rule captures this concept
03:27:57 [fantasai]
.seriouserror {
03:28:01 [fantasai]
@extend .error;
03:28:02 [fantasai]
}
03:28:35 [fantasai]
TabAtkins: Means that every element to which this style rule applies
03:28:45 [fantasai]
TabAtkins: also matches the .error class.
03:28:51 [fantasai]
TabAtkins: Draft as it is allows everything
03:28:56 [fantasai]
TabAtkins: e.g. use :not()
03:29:31 [fantasai]
TabAtkins: Would be fine to restrict to feature selectors: tag names, classes, attrs, IDs, stuff that's in the DOM
03:29:50 [fantasai]
TabAtkins: There are potential use cases e.g. :hover, but that makes it much more complicated
03:29:55 [fantasai]
TabAtkins: That's basically it
03:30:25 [fantasai]
TabAtkins: If you're not familiar with how insanely useful this has been, I suggest you just ask on twitter. "How useful is @extend?" You'll get "OMG, so usef, why aren't you doing it yet?"
03:30:39 [fantasai]
TabAtkins: Impleentationwise I have no idea
03:31:33 [fantasai]
fantasai: Compound or complex selectors?
03:32:12 [fantasai]
TabAtkins: compound selectors only
03:32:20 [fantasai]
TabAtkins: Don't think it's worth the complexity
03:32:34 [fantasai]
fantasai: Agree, just want to be clear
03:32:51 [fantasai]
TabAtkins: @extend rule might make it match more rules, which might themselves have @extend;
03:33:04 [fantasai]
TabAtkins: Shouldn't be a big deal, but a large number of chained extensions
03:33:11 [fantasai]
dino: loop?
03:33:20 [fantasai]
TabAtkins: Can't subtract features.
03:33:31 [fantasai]
TabAtkins: No loopse
03:33:51 [fantasai]
TabAtkins: No specificity issues.
03:34:08 [fantasai]
TabAtkins: Just behaves like it also has the .error class.
03:35:14 [fantasai]
dbaron: Are yo umatching specificity of seriouserror or error?
03:35:19 [fantasai]
fantasai makes tab write on the board:
03:35:30 [fantasai]
#serious-error { @extend .error; }
03:35:34 [fantasai]
.error { color: blue; }
03:35:44 [fantasai]
dbaron: Is color: blue class-specific or ID-specific?
03:35:51 [fantasai]
TabAtkins: class-specific
03:35:52 [dbaron]
Tab says that with #seriouserror { @extend .error } .error { color: blue} the specificity used for color:blue comes from .error
03:36:09 [fantasai]
glazou: OM to represent @extend?
03:36:26 [fantasai]
TabAtkins: We discussed this in the past, we'll add .cssRules on the stylerule interface
03:36:44 [fantasai]
cameron: Does this work across style sheets?
03:36:46 [fantasai]
TabAtkins: Yes
03:37:11 [fantasai]
cameron: Simpler mode is just single class names or single IDs only
03:37:17 [fantasai]
TabAtkins: Answer is I'm not sure
03:37:24 [fantasai]
TabAtkins: SASS allows fuller model than what I'm doing now
03:37:33 [fantasai]
TabAtkins: Might be possible to trim it down
03:37:41 [fantasai]
TabAtkins: Could put as an issue in the draft
03:37:57 [fantasai]
glazou: You allow only compound selectors in here? The other place?
03:38:02 [fantasai]
TabAtkins: selector on the rule can be anything
03:38:15 [fantasai]
roc: querySelector?
03:38:23 [fantasai]
TabAtkins: Unsure. Dunno what's useful
03:38:32 [fantasai]
dino: I really like this proposal. Wondering whether just having placeholders is enough
03:38:53 [fantasai]
TabAtkins: Placeholder selector is a concept introduced by SASS
03:39:06 [fantasai]
TabAtkins: They use the % sign. It's just like a class, just impossible to match with any feature in the DOM
03:39:38 [fantasai]
TabAtkins: The reason why this is ued is so taht when you're designing style sets you don't have to worry about accidentally clashing with stuff actually in the DOM
03:39:50 [fantasai]
TabAtkins: Quite a bit of the stuff with @extend can be used is placeholders
03:39:59 [fantasai]
TabAtkins: You might have to start with .error, and then rewrite it to %error
03:40:15 [fantasai]
TabAtkins: would want to do more research if most use cases can be done with just placeholders/classes
03:40:37 [fantasai]
fantasai: It does seem like placeholders would be a simpler model to have.
03:41:02 [fantasai]
dino: I think the placeholders will encourage peopel to code the way you said, to use semantic class names and use placeholders however is best for styling.
03:41:11 [fantasai]
dino: How does SASS do it?
03:41:31 [fantasai]
TabAtkins: They do it by selector-rewriting. This has a different selector specificity behavior; SASS authors think it's fine.
03:41:55 [fantasai]
dino: I wonder if we could just have it as a copy, copying the properties directly in. I guess it applie shte hash serious...
03:42:03 [fantasai]
dino: What would be the problems with it?
03:42:21 [fantasai]
TabAtkins: @extend has a dual form with @mixin
03:42:38 [fantasai]
TabAtkins: we could consider extending in the future
03:42:48 [fantasai]
TabAtkins: SASS shows @extend is preferred by authors, so should do it first
03:42:58 [fantasai]
dino: Awareness of specificity.. . it's a difference from the way normal CSS reads
03:43:03 [pjrm]
pjrm has joined #css
03:43:06 [fantasai]
dino: shorthand, longhand
03:43:12 [fantasai]
plinss: I'm not sure that you will be aware of the specificity
03:43:19 [fantasai]
plinss: There could be other rules somewhere in the mix, there's a .error
03:43:28 [fantasai]
dino: especially if .error extends from something
03:43:35 [fantasai]
plinss: ...
03:43:38 [fantasai]
plinss: no predictability
03:44:04 [fantasai]
TabAtkins: With a little bit of discipline, using mainly just placeholders, then will get into less trouble than that
03:44:10 [fantasai]
dino: yes, I like placeholders better
03:44:39 [fantasai]
TabAtkins: Unless we allow @extend to affect querySelector, the placeholder won't match anything aside of the querySelector call
03:44:50 [fantasai]
cameron: I think it might be useful to querySelector all my buttons
03:45:11 [fantasai]
TabAtkins: I can see it'd be useful, might be issue
03:45:29 [fantasai]
plinss: Really odd querySelector doesn't work, but also really weird that CSS affects the DOm
03:45:44 [fantasai]
TabAtkins writes
03:45:58 [fantasai]
.foo { @extend: button; }
03:46:06 [fantasai]
TabAtkins: This will pull in the UA styles for buttons
03:46:29 [fantasai]
cameron: Sounds neat, but internally we set some rule sin the UA style sheet that really can't be applied to othe relements
03:46:43 [fantasai]
cameron: due to scurity, or we make certian assumptions about what elements they apply to
03:47:11 [fantasai]
dbaron: form controls probably shoudl have been designed as values of 'display', but they're not.
03:47:23 [fantasai]
dbaron: So they require element-specific knowledge, and the Web depends on that.
03:47:36 [roc]
please add "roc's head explodes" to the minutes
03:47:43 [fantasai]
dbaron: If you put 'display: inlie' or 'display: block' on a button, it's still a button
03:48:05 [fantasai]
Florian: Have appearance property for that. The 'none' value has fair amoutn of interop, but other values work differently in different browsers
03:48:18 [fantasai]
t
03:48:46 [fantasai]
Florian: The buttonness of your button is not expressed in CSS.
03:48:57 [fantasai]
dbaron: Our buttons, for example, have 2 sets of borders instead of two.
03:49:06 [fantasai]
dbaron: If you @extend, you'll get one set but not the others.
03:49:20 [fantasai]
greg: <select> control would be even worse
03:49:32 [fantasai]
dino: I just wonder if we have a lot of power with a simpler thing
03:49:49 [fantasai]
TabAtkins: This particular case is making custom element ppl happy as well. Would like to make see if we can do better.
03:50:03 [fantasai]
dino: Really? Custom element ppl want to copy platform controls? what?
03:50:17 [fantasai]
dbaron: One of my bigger concerns about this
03:50:32 [fantasai]
dbaron: I feel like a lot of developers misunderstood what CSS rules were, and this makes it worse
03:50:38 [fantasai]
dbaron: Like what this thing at the beginning of it was
03:50:54 [fantasai]
dbaron: I feel like this part of a mental model that is different from what they actually are
03:51:00 [fantasai]
dbaron: Model is that selector is somethign that matches elements
03:51:21 [fantasai]
dbaron: I think a lot of authors feel like they are trying to do somethign that's kindof like assigning the elements to some object oriented programming hierarchy
03:51:26 [fantasai]
dbaron: and this kindof looks like that
03:51:35 [fantasai]
TabAtkins: yes, works similarly. Allows that kind of ideas to work out
03:51:46 [fantasai]
SimonSapin: Even the name seems to say that class is something that exists in yourstyle sheet
03:51:55 [fantasai]
SimonSapin: And when you have .error, and you extend the class with another class
03:51:58 [fantasai]
SimonSapin: That's object oriented
03:52:01 [zcorpan]
s/yourstyle/your style/
03:52:02 [fantasai]
SimonSapin: but that's not what's really going on
03:52:08 [fantasai]
SimonSapin: Class is one part of slector that dds the class
03:52:14 [fantasai]
SimonSapin: The main extends seems to come from a mental model that is wrong
03:52:18 [glazou]
+1 SimonSapin
03:52:20 [dbaron]
s/main/name/
03:52:26 [fantasai]
dino: Pick a name that is not @extend
03:52:35 [fantasai]
TabAtkins: Don't wantto change the name from SASS
03:52:41 [liam]
[ Liam also concerned people used to SASS will expect @extend to be 100% the same ]
03:52:43 [fantasai]
dino: ... [good thing]
03:52:50 [fantasai]
ChrisL: It's too late to change 'class'
03:52:58 [fantasai]
ChrisL: You'll see #, o that's just a hash tag
03:53:06 [dbaron]
ChrisL: people talk about "calling a class"
03:53:11 [fantasai]
ChrisL: Those people will look at extends, and will
03:53:48 [ChrisL]
and will be even more confused
03:54:01 [fantasai]
fantasai: Maybe the approach to take is to start with placeholders only.
03:54:36 [fantasai]
SimonSapin: If we go to placeholders, is this equivalent to custom selectors proposal?
03:54:54 [fantasai]
SimonSapin: Becaue you have a slector that extends a placeholder, and you can use that selector in other placeholders
03:55:03 [fantasai]
SimonSapin: Isn't that equivalent to having that placeholder expanding ot that placeholder?
03:55:20 [fantasai]
roc: Difference in that you're declaring in one place all the things that are equivalent,
03:55:33 [fantasai]
h1, h2, he ... {
03:55:38 [fantasai]
@extend %heading;
03:55:39 [fantasai]
}
03:55:45 [fantasai]
SimonSapin: How is that different from selector alias
03:55:55 [fantasai]
TabAtkins: In terms of pure aliases, this is equivalent
03:56:18 [fantasai]
@custom-selector --heading h1, h2, h3, h4;
03:56:30 [fantasai]
TabAtkins: These are equivalent, yes.
03:56:32 [dbaron]
q+
03:56:37 [fantasai]
glazou writes
03:56:38 [tantek]
tantek: or file input [said shortly after "greg: <select> control would be even worse"]
03:56:49 [fantasai]
foo:not(.error) { @extend .error; }
03:56:58 [fantasai]
glazou: That's a loop, yes?
03:57:01 [fantasai]
TabAtkins: yes.
03:57:20 [fantasai]
TabAtkins: hm, maybe have to do a loop-detection phase
03:57:25 [fantasai]
roc: Two things aren't quite the same
03:57:35 [fantasai]
roc: With custom selectors you ahve t list all the extensions in one place
03:57:49 [fantasai]
roc: With the @extend you can increase the list anywher ein the style sheets, which makes it much more useful
03:58:12 [fantasai]
dbaron: You could have something that is outside of a style rule, but still has advantage of spreading around the style sheets
03:58:19 [fantasai]
dbaron: which is what I was proposing a few years ago
03:58:31 [fantasai]
dbaron: Part of what makes me think it doesn't fit the model is putting it inside the style rule
03:58:45 [fantasai]
fantasai: Can you summarize your proposal, dbaron?
03:59:15 [tantek]
q?
03:59:20 [fantasai]
people tell fantasai to go read it. While taking minutes and trying to keep up with the discussion.
03:59:23 [dino]
q-
03:59:34 [tantek]
ack Florian
03:59:37 [heycam]
q- shorthand
03:59:39 [heycam]
q- long
03:59:42 [fantasai]
plinss: What thing, if @extend is inside the rule
03:59:43 [dino]
ack dino
03:59:48 [dino]
ack dino:
03:59:59 [fantasai]
plinss: I may have, to go back to earlier example, I may have 6 different rules that apply serious erro rwith various selectors
04:00:09 [fantasai]
plinss: If I want to include .error, have to put it in all of them
04:00:18 [gregwhitworth]
gregwhitworth has joined #css
04:00:19 [fantasai]
plinss: When any of the other smatch, then only put it here
04:00:28 [dbaron]
q+ to say I don't just want to limit it to placeholders
04:00:30 [dino]
smatch!
04:00:33 [dino]
shmatch
04:00:46 [liam]
schmelectors?
04:00:47 [dbaron]
q+ to say that a big part of what I don't like about it is the name
04:00:54 [ChrisL]
q+ to ask'); DROP TABLE queue
04:01:01 [ChrisL]
q-
04:01:04 [fantasai]
plinss: If I have 1 rule with .seriouserro:hover, and that contains @extend .error
04:01:23 [fantasai]
plinss: It may have other selectors before .ersiouserror
04:01:36 [fantasai]
plinss: If I put it in a rule that only matches sometimes.
04:01:45 [fantasai]
plinss: May be an advantage, but may be somewhat confusing
04:02:03 [fantasai]
plinss: If you don't understand cascade/specificity correctly, you might get yourself into a confused situation
04:02:13 [fantasai]
plinss: What I'm wondering is if it would be better to have it separate, not in a style rule
04:02:20 [fantasai]
plinss: This selector is equivalent to this other selctor
04:02:29 [fantasai]
plinss: Then it applies to all rueles and all style sheets
04:02:48 [fantasai]
TabAtkins: Difference between this and @extend .seriouserror .error; is literally a matter of 2 chars
04:02:53 [fantasai]
plinss: It's a big difference in behavior
04:03:07 [fantasai]
TabAtkins: it's just syntactic.
04:04:23 [dbaron]
q+ to ask about interaction with combinators
04:04:37 [dbaron]
q+ to describe previous proposal
04:04:44 [fantasai]
plinss: If you have .foo > .seriouserror
04:04:50 [fantasai]
plinss: Below that I have .bar > .seriouserror
04:04:55 [fantasai]
plinss: And in that one I didn't put @extend
04:05:10 [fantasai]
plinss: But if I have a separate rule that is @extend .seriouserror .error ti works on both
04:05:24 [fantasai]
TabAtkins: yeah, same thing. You might have to have a separate rule that just holds @extend, but it's fine.
04:05:36 [fantasai]
plinss: Oh, nevermind
04:06:15 [fantasai]
plinss: Going back to dbaron's point, I think there's a lot of ppl who don't understnad how to compose style correctly
04:06:24 [fantasai]
plinss: I think this just lets people who are doing it wrong od it wrong in more interesting ways
04:06:37 [fantasai]
TabAtkins: yes, but it also makes people who know what theyr'e doing to have much more maintainable style sheets
04:06:53 [fantasai]
plinss: I support better maintenace completely, but this feels really wrong to me.
04:06:55 [tantek]
aside: how *do* you compose styles correctly? anyone have a suggested "how to" guide? URL?
04:07:24 [fantasai]
plinss: I would like to see different ways of composing style rules, rathe rthan this.
04:07:25 [tantek]
s/aside/tantek on irc aside
04:07:31 [fantasai]
glazou: The problem is referencing a given rule from another rule.
04:07:44 [fantasai]
plinss: in my hea,d without really understnaidn this, I would rathe rit simply references the other rule
04:08:00 [fantasai]
plinss: Would rather say "what I really wanted was this set of properties, plus all the propertyies from the other rule over there"
04:08:06 [fantasai]
plinss: Not by mangling what matches what.
04:08:12 [fantasai]
TabAtkins: People don't wnat that
04:08:18 [fantasai]
plinss: Because they don't understna dhow to compose CSS
04:08:43 [fantasai]
TabAtkins: You can have a bunch of style rules that apply style rules to .error in different contexts,.
04:08:50 [fantasai]
TabAtkins: referencing a block doens't work well there
04:08:55 [dbaron]
q+ to agree with Tab about people wanting to extend one class with another being important
04:09:19 [tantek]
Tabatkins: I'm willing to let them be wrong if it helps them out
04:09:20 [fantasai]
TabAtkins: It is extermeely popular in SASS commnity, shows it's helpul to people
04:09:24 [fantasai]
plinss: But it's a model that's wrong
04:09:32 [fantasai]
TabAtkins: I'm willing ot let the be wrong if it's helfpul
04:09:46 [fantasai]
plinss: Going back to querySelector, that's really concering because selector behavior which is different from style sheets
04:10:03 [fantasai]
plinss: Doesn't fit in architectural model of the Web
04:10:12 [fantasai]
dino: I would like to not change querySelector, otherwise I don't have any problem
04:10:27 [fantasai]
dino: I think the point about CSS being able to change JS apis is good, I agree
04:10:32 [fantasai]
dino: I still like eveyrthing else
04:10:36 [dbaron]
ack dbaron
04:10:36 [Zakim]
dbaron, you wanted to say I don't just want to limit it to placeholders and to say that a big part of what I don't like about it is the name and to ask about interaction with
04:10:40 [Zakim]
... combinators and to describe previous proposal and to agree with Tab about people wanting to extend one class with another being important
04:10:45 [liam]
[ tantek - I dont believe in right or wrong in this sort of thing anyway ]
04:10:57 [ChrisL]
zakim, suggest a syntax for extending css
04:10:57 [Zakim]
I don't understand 'suggest a syntax for extending css', ChrisL
04:11:09 [tantek]
fantasai: It's in the logs
04:11:16 [fantasai]
dbaron: I agree that extending one class with another is something we should do and is important to authors
04:11:33 [fantasai]
dbaron: Authors end up writing 4 different selector sbecause buil hierarchy of stuff. So solving that point is important
04:11:41 [fantasai]
dbaron: Wanted to ask question of what this actually does
04:11:55 [fantasai]
dbaron: Suppose you have .article { @extend .section; }
04:12:27 [fantasai]
dbaron: And then .seriouserror { @extend .error; }
04:12:43 [fantasai]
dbaron: and then you have .section .error { color: whatever; }
04:13:00 [fantasai]
dbaron: This will match when you have <div class="article"><div class="seriouserror"></div></div??
04:13:04 [fantasai]
TabAtkins: yes.
04:13:05 [fantasai]
dbaron: good.
04:13:50 [fantasai]
dbaron: It follows from the fact that I think this is improtant that we shouldn't limit it to just placeholder
04:13:57 [fantasai]
dbaron: But I think a big part of my problem with it is the name.
04:14:01 [fantasai]
dbaron: It's the wrong mental model,
04:14:08 [fantasai]
glazou: More assimilate than extend
04:14:15 [fantasai]
TabAtkins: I would be somewhat unhappy if we changed the name
04:14:37 [fantasai]
TabAtkins: But has advantage that ...
04:14:39 [glazou]
s/assimilate/simulate
04:14:44 [fantasai]
dbaron: I don't believe that for a second.
04:14:53 [fantasai]
dbaron: All people whose pages are going to break aren't going to be happy.
04:14:59 [fantasai]
TabAtkins: That's SASS's responsibility.
04:15:06 [fantasai]
TabAtkins: Different name would avoid that problem
04:15:19 [fantasai]
s/.../ ... something about turning off @extend in SASS /
04:16:21 [fantasai]
plinss worries about nested selector matching
04:16:25 [estellevw]
estellevw has joined #css
04:16:32 [fantasai]
TabAtkins: You collec tthe @extend rules, iterate until stable
04:16:34 [glazou]
s/plinss/glazou and plinss
04:16:51 [fantasai]
TabAtkins: Then in addition to DOM class list, you also look in the @extend class list.
04:17:06 [fantasai]
dbaron: That assumes the @extend rule is inside a selector that is jsut a class
04:17:14 [fantasai]
TabAtkins: You match this, then you add this to extend this
04:17:31 [fantasai]
plinss: Tab hasn't actually written a selector matching algorithm...
04:17:47 [fantasai]
glazou: I'm afraid this is a feature for batch processors, not for dynamic browser. I'm worried about perf
04:17:54 [fantasai]
TabAtkins: Batch processors can't implement this ocrrectly
04:17:54 [dbaron]
about 6 lines up glazou raised the issue of performance
04:18:10 [fantasai]
s/batch /pre
04:18:36 [fantasai]
plinss: If you separate @extends out, then you can precompute it all
04:18:58 [fantasai]
fantasai: They're syntactically equivalent
04:19:31 [fantasai]
fantasai: it may not be the syntax you want, but they are equivalent
04:19:52 [tantek]
fantasai: if I can write a perl script that rewrites it then it's equivalent
04:20:33 [fantasai]
glazou: Selector matching: You try to match all of the selectors in the CSSOM against the element that you have in your hand.
04:21:42 [fantasai]
di foo .bar { ... }
04:21:50 [fantasai]
div > p > foo .section { #extend .bar }
04:22:00 [fantasai]
glazou: You run selector matching, then realize it extends, have to go run it again.
04:22:16 [fantasai]
glazou: If you have a different syntax, you can keep the @extend rules in their own list and prcess them first and then do selecto rmatching.
04:22:18 [tantek]
q?
04:22:22 [glazou]
otherwise first rule will never match
04:23:04 [fantasai]
fantasai: You could do that anyway. When you parse the rules, instead of storing @extend in the style rules list with the declarations, build up your separate @extend list.
04:23:11 [fantasai]
fantasai: They are syntactically equivalent.
04:23:25 [fantasai]
s/glazou/plinss/
04:23:26 [dbaron]
I still have no idea how we'd implement this in a browser...
04:24:03 [fantasai]
glazou: I perfectly understand usefulness, but unsure how to implement this in a browser.
04:24:23 [fantasai]
plinss: Just explode out the selectors
04:24:32 [fantasai]
TabAtkins: No, that won't get you the righ behavior
04:24:54 [fantasai]
dbaron: I think it's really useful for authors, but no idea how to implement it
04:25:03 [dbaron]
I think selector variables are much more straightforward.
04:25:16 [fantasai]
plinss: I run into this problem myself
04:25:30 [fantasai]
plinss: I'm not convicned this is the right way to solve the problem, but not sure it's the right way
04:26:26 [fantasai]
fantasai: ...
04:26:30 [tantek]
I for one like @extends
04:26:39 [fantasai]
dbaron: I had two proposals, one similar to selector variables one similar to extend
04:26:40 [tantek]
s/@extends/@extend
04:26:54 [fantasai]
dbaron: And I think I like Tab's selector variables syntax better.
04:27:01 [fantasai]
roc: if your estric tit to the placeholders version
04:27:14 [fantasai]
roc: Then you can treat it as a different syntax as alisaed selectors
04:27:29 [fantasai]
roc: And it's very clear how to implement that
04:27:33 [fantasai]
SimonSapin:... ?
04:28:01 [liam]
s/estric tit/restrict it/
04:28:04 [fantasai]
TabAtkins: %foo > .error { @extend %bar; }
04:28:28 [dbaron]
maybe s/selector variables/custom selectors/
04:28:47 [fantasai]
TabAtkins: Complex selector sare quite common in SASS like that. They have to use some heuristics for it, because can't do it quite correctly
04:29:32 [SimonSapin]
s/.../It depends on whether you allow using selector aliases before you define them/
04:29:38 [fantasai]
TabAtkins: can I have ED?
04:29:45 [fantasai]
fantasai: I don't hear agreement on the draft.
04:30:05 [fantasai]
fantasai: I don't even hear any ideas of what Tab needs to do to fix it so that we all agree it's going in the right direction.
04:30:13 [fantasai]
fantasai: So I'm not happy with an ED
04:30:26 [fantasai]
fantasai: But I also want us to tell Tab what he needs to do to get there
04:30:48 [fantasai]
glazou: My concern is that if we accept ED and then have a media storm if we reject or change significantly
04:30:51 [fantasai]
plinss: Had the same thing with variables
04:30:55 [fantasai]
glazou: Yes, and I would like to avoid that.
04:31:31 [ChrisL]
zakim, remind TabAtkins in 15 years to re-propose @extends
04:31:31 [Zakim]
I don't understand you, ChrisL
04:31:58 [fantasai]
dbaron: I'm nervous about making something an ED when more people in the room think it's not going to work than think it's going to work.
04:32:24 [roc]
hmm ... %foo > .error { @extend %foo; }
04:32:45 [fantasai]
...
04:32:45 [roc]
div { @extend %foo; }
04:32:55 [tantek]
css-as
04:32:59 [fantasai]
plinss: Call it maybe Style Rule Composition
04:33:28 [fantasai]
[random comments]
04:33:42 [fantasai]
shortname sugestions
04:33:50 [tantek]
css-subclassing
04:33:57 [dbaron]
css-bikeshedding
04:34:02 [fantasai]
css-composition
04:34:09 [roc]
so @extend is different from custom selectors because it allows defining recursive selectors
04:34:12 [tantek]
css-class-class
04:35:20 [fantasai]
proposal: Make an editor's draft with big red warning to work on the problem, called CSS Style Rule Composition, shortname tbd
04:35:25 [fantasai]
RESOLVED: Make an editor's draft with big red warning to work on the problem, called CSS Style Rule Composition, shortname tbd
04:35:29 [tantek]
is it break time yet?
04:35:55 [tantek]
tabatkins: next I'd like to present, I just want to use JavaScript instead ;)
04:36:27 [fantasai]
<br type=snacks>
04:59:17 [johanneswilm]
johanneswilm has joined #css
05:00:10 [TabAtkins]
ScribeNick: TabAtkins
05:00:26 [TabAtkins]
Topic: <custom-ident>
05:00:42 [TabAtkins]
SimonSapin: We have an issue when <custom-ident> can occur at the same position as keywords, could be amibiguous.
05:00:47 [TabAtkins]
SimonSapin: Need to define how to resolve.
05:01:17 [TabAtkins]
SimonSapin: Right now the spec says that the first occurence of something ambiguous is given to the keyword, and afterwards is <custom-ident>.
05:01:26 [TabAtkins]
SimonSapin: But that means you ahve to remember what you've parsed so far.
05:01:34 [TabAtkins]
SimonSapin: That's annoying to implement, and maybe surprising to authors.
05:01:43 [TabAtkins]
SimonSapin: If you reorder things where order normally doesn't matter, it changes the meaning.
05:02:02 [TabAtkins]
SimonSapin: Another option is to restrict <custom-ident> based on what it can be ambiguous with.
05:02:33 [vollick__]
vollick__ has joined #css
05:02:35 [TabAtkins]
SimonSapin: For example, list-style-type takes either <counter-style> | string | none
05:02:40 [TabAtkins]
SimonSapin: And <counter-style> is <custom-ident>
05:02:53 [TabAtkins]
SimonSapin: So if you specify "none", it can't be a <counter-style>, as it'll be ambiguous.
05:02:55 [TabAtkins]
SimonSapin: But that's easy.
05:03:14 [TabAtkins]
SimonSapin: In list-style, at the same position as you would have a <counter-style>, you might have "outside" keyword, a valid list-style-position value.
05:03:31 [TabAtkins]
SimonSapin: So here we should restrict <custom-ident> to not be able to be "outside".
05:03:46 [TabAtkins]
dbaron: So you'd restrict "outside" from list-style-type as well?
05:03:57 [TabAtkins]
SimonSapin: That's possible, but it's harder to maintain.
05:05:13 [TabAtkins]
TabAtkins: We explicitly rejected the "exclude keywords from all contexts it can be used", because that set is large and ever growing, and confusing to think about.
05:05:40 [TabAtkins]
TabAtkins: We also purposely moved away from the simpler "exclude keywords from the current context", because it still makes it hard to extend the set of keywords in the future; they might be used by authors.
05:05:53 [TabAtkins]
TabAtkins: We purposely moved to the current behavior, which matches animation, to avoid those problems.
05:07:03 [TabAtkins]
SimonSapin: Describe current animation behavior?
05:07:25 [TabAtkins]
TabAtkins: What the spec currently says - <animation-name> only claims unknown keywords, or known keywords that correspond to properties that are already set by earlier keywords.
05:07:51 [TabAtkins]
TabAtkins: So you can name an animation "forwards" as long as you also always specify the animation-direction part of the animation shorthand, and put the animation-name at the end.
05:08:07 [TabAtkins]
SimonSapin: That measn in a context where order normally doesn't matter, sometimes it does and you can't.
05:08:56 [TabAtkins]
TabAtkins: Rijght.
05:09:06 [TabAtkins]
TabAtkins: All new grammars should always be positionally unambiguous.
05:09:23 [dbaron]
The values spec should probably say that (i.e., give advice for spec authors).
05:10:00 [TabAtkins]
TabAtkins: The only reason we have this problem is old properties that get upgraded to <custom-ident>, so something that wasn't ambiguous becomes ambiguous.
05:10:10 [TabAtkins]
TabAtkins: Are you okay with this, given that context?
05:10:22 [TabAtkins]
SimonSapin: Okay, I can live with this. I'd like to explore other options, but maybe in a later meeting.
05:10:53 [TabAtkins]
TabAtkins: Next is global keywords - allow or exclude? I don't care.
05:11:06 [TabAtkins]
fantasai: Weak pref for excluding. I don't think there's any reason to allow them, and they cause some problems.
05:11:16 [TabAtkins]
fantasai: And we already exclude them in font-family and counter-styles.
05:11:36 [TabAtkins]
fantasai: It's better to catch errors earlier, so it's a benefit to authors and just exclude it.
05:11:43 [estellevw]
estellevw has joined #css
05:12:13 [TabAtkins]
TabAtkins: I'm fine with that - it amkes it harder to add global keywords, but we don't do those often anyway.
05:12:20 [TabAtkins]
SimonSapin: I think it's arbitrary to exclude them, but meh.
05:12:53 [TabAtkins]
RESOLVED: Exclude the global keywords from <custom-ident>.
05:13:27 [SimonSapin]
s/exclude them,/exclude them when not ambiguous,/
05:16:20 [TabAtkins]
SimonSapin: One remark about <custom-ident>.
05:17:12 [TabAtkins]
SimonSapin: The spec says that other specs must clearly say what keywords are excluded. Why normative?
05:17:14 [TabAtkins]
TabAtkins: Why not?
05:17:53 [TabAtkins]
RESOLVED: Pending edits, publish V&U as new CR.
05:18:13 [TabAtkins]
ChrisL: Remember we'll need an up-to-date DoC to republish.
05:18:29 [ChrisL]
rrsagent, here
05:18:29 [RRSAgent]
See http://www.w3.org/2015/02/08-css-irc#T05-18-29
05:18:45 [fantasai]
ScribeNick: fantasai
05:19:02 [fantasai]
Topic: Flexbox
05:19:22 [fantasai]
TabAtkins: Bug. Don't understand why Chrome and FF interoperably don't do the right thing. IE does the right thing. Pls explain it all.
05:20:46 [fantasai]
fantasai: If you have an abspols flex container, it wraps to the window width, but doesn't shrinkwrap into it.
05:21:39 [fantasai]
fantasai: We think this is wrong, just wanted to check we're not missing something.
05:22:22 [fantasai]
https://lists.w3.org/Archives/Public/www-style/2014Sep/0396.html
05:22:47 [fantasai]
fantasai: Issue about no-wrap is still open
05:22:52 [fantasai]
fantasai: and have some pagination stuff
05:22:58 [fantasai]
fantasai: then should publish
05:23:16 [fantasai]
Topic: Form Control Styling
05:23:18 [TabAtkins]
http://dev.w3.org/csswg/css-forms/
05:23:25 [fantasai]
TabAtkins: fantasai brought up form control styling
05:23:34 [fantasai]
TabAtkins: Started a nice thread
05:23:44 [fantasai]
TabAtkins: Started disagreeing on what is reasonable to allow form control styling
05:24:01 [fantasai]
TabAtkins: Have a basic exploratory draft
05:24:35 [fantasai]
TabAtkins: Writes up various proposals. We need more screenshots
05:24:45 [fantasai]
dino: Web controls are horrible on iPhone
05:25:12 [fantasai]
ACTION: florian to make page of all form controls
05:25:12 [trackbot]
Created ACTION-673 - Make page of all form controls [on Florian Rivoal - due 2015-02-17].
05:25:30 [fantasai]
fantasai: so proposal is collect screenshots
05:25:45 [fantasai]
TabAtkins: Two proposals so far, read and comment and throw out more ideas.
05:26:01 [fantasai]
TabAtkins: And really, want more screenshots. Espe. from outside Android/iOS bubble
05:26:18 [fantasai]
Topic: Snapshot
05:26:27 [TabAtkins]
ScribeNick: TabAtkins
05:26:37 [TabAtkins]
fantasai: Aaron posted a proposal for a snapshot 2015
05:26:42 [fantasai]
www.w3.org/mid/BLUPR03MB199E2D02A3708B7400C5108AD270@BLUPR03MB199.namprd03.prod.outlook.com
05:26:42 [TabAtkins]
fantasai: His proposal is:
05:26:47 [fantasai]
https://lists.w3.org/Archives/Public/www-style/2015Feb/0200.html
05:26:48 [TabAtkins]
fantasai: ^^^
05:26:58 [TabAtkins]
fantasai: We need to update the snapshot.
05:27:08 [TabAtkins]
fantasai: Intro needs reworking, change the vendor-prefix section.
05:27:14 [TabAtkins]
fantasai: But also need to decide what goes into the snapshot.
05:27:25 [TabAtkins]
fantasai: Proposal so far is everything in Rec,
05:27:46 [TabAtkins]
Florian: dbaron and I have also helped him iterate on this
05:28:02 [TabAtkins]
fantasai: Also animation, backgrounds, cascade, conditional, flexbox, fonts, images, multicol, transform, transitions, and v&u.
05:28:09 [TabAtkins]
fantasai: Some discussion about counter-styles.
05:28:13 [TabAtkins]
fantasai: And syntax.
05:28:31 [TabAtkins]
dbaron: Does anyone else implement text-decor-3?
05:28:52 [TabAtkins]
fantasai: I think apple does text-emphasis?
05:28:59 [TabAtkins]
fantasai: I'm guessing it'll wait to 2016, based on what I know.
05:29:36 [TabAtkins]
fantasai: Any other editors think their specs are ready?
05:30:18 [TabAtkins]
TabAtkins: There was a suggestion for the will-change spec. It's stable and widely implemented.
05:30:25 [TabAtkins]
tantek: I think UI meets the criteria too.
05:30:58 [TabAtkins]
TabAtkins: Did you drop all the weird stuff that nobody ipmlemented?
05:31:11 [TabAtkins]
tantek: ::value/choices not yet, but will be dropped asap. Then it's all implemented stuff.
05:32:02 [TabAtkins]
fantasai: I say we leave it out until the new draft that drops those is up.
05:32:25 [TabAtkins]
tantek: How long to do it?
05:32:36 [TabAtkins]
Florian: Several bits need to be rewritten, so won't be published for a little bit.
05:32:40 [TabAtkins]
[some discussion about UI]
05:33:20 [TabAtkins]
fantasai: I'd like will-change to move to CR, if it's ready to be included in the snapshot.
05:34:01 [TabAtkins]
dbaron: Is Syntax a yes?
05:34:04 [TabAtkins]
dbaron: I'd like to see it in.
05:34:10 [TabAtkins]
fantasai: If you say it should go in, I'll support that.
05:35:05 [TabAtkins]
TabAtkins: Everyone okay with Syntax in?
05:35:12 [TabAtkins]
[general assent/disinterest]
05:35:23 [TabAtkins]
SimonSapin: Anything we don't want that it's in CR?
05:35:26 [tantek]
I don't understand the criteria being used
05:35:29 [TabAtkins]
fantasai: Speech, because no ipmls.
05:35:34 [TabAtkins]
fantasai: Text-decor not yet.
05:35:36 [tantek]
appears to be inconsistently applied
05:35:40 [TabAtkins]
fantasai: Writing-modes not yet.
05:36:14 [TabAtkins]
fantasai: Shapes and Masking are not in yet.
05:36:34 [TabAtkins]
TabAtkins: Shapes is in two impls. Sounds like it should go in.
05:37:02 [TabAtkins]
astearns: I think Shapes is reasonably stable, but I'd still like another impl.
05:37:05 [TabAtkins]
TabAtkins: So in or not?
05:37:07 [TabAtkins]
astearns: I dunno.
05:37:31 [TabAtkins]
astearns: Let's leave it out. I don't expect to see changes, but we'll see.
05:37:39 [TabAtkins]
dbaron: I think whoever made the list didn't go through FXTF.
05:37:59 [TabAtkins]
dbaron: Compositing, Masking, Filters, what's ipml status?
05:38:04 [TabAtkins]
TabAtkins: I think they're all in Blink/WEbkit.
05:38:15 [TabAtkins]
roc: FF doesn't do Masking. We do Compositing and Filters.
05:38:42 [TabAtkins]
krit: With exception of Blending, all other specs have partial impls, but aren't implemented entirely.
05:39:07 [TabAtkins]
krit: So Blending should go in.
05:39:31 [TabAtkins]
fantasai: So, Aaron's list, plus will-change and UI once they're updated, plus compositing.
05:39:38 [fantasai]
s/Aaron/Arron/
05:39:55 [TabAtkins]
fantasai: Plus Syntax.
05:40:15 [TabAtkins]
Florian: Do we inline the intro chapters from CSS2? It has a nice introduction to CSS.
05:40:18 [tantek]
so we are including CSS3-UI?
05:40:31 [astearns]
tantek: once the edits are made, yes
05:40:37 [TabAtkins]
Florian: If the snapshot is the intro to stable CSS, seems reasonable to put that there.
05:40:49 [astearns]
tantek: same as with will-change
05:40:55 [TabAtkins]
ChrisL: It turns "a list of stuff" into "a list of stuff plus some introductory material". Do people read it?
05:40:56 [tantek]
astearns: edits we agreed to in this meeting?
05:41:07 [tantek]
because edits are going to be made for quite some time
05:41:10 [TabAtkins]
ChrisL: Will the intro be the same?
05:41:20 [tantek]
s/asterns:/astearns,"
05:41:24 [TabAtkins]
Florian: Initially could be the same, but might change too.
05:41:26 [tantek]
oops
05:41:37 [TabAtkins]
fantasai: I think we should do minimal stuff first. Update list of specs and interactions, update vendor prefixing, then publish.
05:41:44 [tantek]
astearns, edits we agreed to in this meeting? because edits are going to be made for quite some time.
05:41:57 [TabAtkins]
fantasai: I think we should include the intro from CSS2 about "this is how property tables work, etc".
05:42:04 [astearns]
tantek: I thought you had a set of edits to make before publishing
05:42:06 [TabAtkins]
fantasai: And a glossary of terms auto-genned from Shepherd for those specs.
05:42:14 [TabAtkins]
fantasai: All this latter stuff as a second pub.
05:42:28 [tantek]
astearns: nope, we already have a draft in the pipe to be published per resolution 2015-01-21
05:42:41 [TabAtkins]
TabAtkins: Sounds good. WE can do the minimal stuff by end of Feb, adtl pubs pending interest.
05:42:49 [tantek]
astearns, no, we already have a draft in the pipe to be published per resolution 2015-01-21
05:43:00 [tantek]
and I would assert event that draft is good enough to be included
05:43:00 [fantasai]
fantasai^: And a property index auto-genned by Shepherd
05:43:46 [TabAtkins]
RESOLVED: Produce the snapshot with fantasai's list, update vendor prefix policy. Group will review when finished.
05:44:37 [TabAtkins]
Topic: CSS 2 updates
05:44:56 [SimonSapin]
plinss, maybe dev.w3.org/csswg/css/ should be an alias for the snapshot rather than 2.x, to match http://www.w3.org/TR/CSS/
05:44:56 [TabAtkins]
fantasai: I think someone was proposing we should publish drafts where we remove sections of CSS2.
05:45:05 [TabAtkins]
fantasai: Unsure we can do that without a lot of overhead, and I'm not sure it's a great idea.
05:45:18 [TabAtkins]
fantasai: But we *should* put a note under every replaced subheading pointing to the replacing draft.
05:45:26 [TabAtkins]
fantasai: At some point int he future we can publish a skeleton spec.
05:45:45 [TabAtkins]
Florian: Do we put a note pointing to specs when they're Rec? Or as soon as they exist?
05:45:52 [TabAtkins]
TabAtkins: As soon as browsers accept them as definitive.
05:46:04 [TabAtkins]
fantasai: CR, definitely. Earlier on a case-by-case basis.
05:46:12 [TabAtkins]
ChrisL: You're proposing a skeletonization.
05:46:46 [fantasai]
[discussion of zombie bodies of CSS2.1]
05:46:54 [TabAtkins]
[chrisl describe Night of the Living CSS2]
05:47:20 [TabAtkins]
ChrisL: Apparently we have a bunch of errata to publish. I thought that's what CSS2.2 was about?
05:47:31 [TabAtkins]
ChrisL: Is the whole point of this to just point to the new stuff, why roll in errata in the first place?
05:47:48 [TabAtkins]
fantasai: I think there's some sections of 2.1 we don't have a replacement fo ryet.
05:48:03 [TabAtkins]
fantasai: Some have been replaced; their contents are still correct and can be used as a ref, but we should point to the newer ref.
05:48:10 [TabAtkins]
fantasai: So if we make changes, might as well keep them in sync.
05:48:18 [TabAtkins]
fantasai: But some sections have been completely gutted and redesigned, like syntax.
05:48:30 [TabAtkins]
fantasai: The warning should be more stringent and emphasize that the new ref is very important to look at.
05:48:37 [TabAtkins]
fantasai: We won't be maintaining any errata for syntax.
05:48:55 [TabAtkins]
ChrisL: ARe ther pending errata for 2.1 that need to be published?
05:49:03 [TabAtkins]
ChrisL: Where is that best going to go for people to notice it?
05:49:17 [TabAtkins]
ChrisL: The sections getting replaced should be the new stuff.
05:49:27 [TabAtkins]
Florian: If entire sections are wrong, just say "go look at the new stuff".
05:50:17 [TabAtkins]
fantasai: Part of th eproblem is that our errata maintenance process is unmanageable. It's too hard to publish our errata docs.
05:50:28 [TabAtkins]
fantasai: WE can at least publish notes saying "look over here", so we should do that.
05:50:36 [TabAtkins]
fantasai: And also solve the errata problem, but that's separable.
05:51:01 [TabAtkins]
ChrisL: I just wanted to make sure the errata moved from the errata doc to someplace people will actually look at them.
05:51:10 [TabAtkins]
SimonSapin: The editors draft contains the errata inline.
05:51:38 [TabAtkins]
ChrisL: And there's a note on 2.1 pointing to the ED.
05:52:21 [TabAtkins]
TabAtkins: So does anyone object to adding the notes to the ED, per fantasai?
05:52:34 [TabAtkins]
Florian: Is the criteria for drafts the same as the snapshot?
05:52:56 [TabAtkins]
fantasai: No. CSS2.1 might have a terrible section that's still being repalced by something better, but churning. It's still good to look at the new draft, versus the CSS2 def.
05:53:03 [TabAtkins]
fantasai: So if it's stable OR better, we should point to it.
05:53:30 [TabAtkins]
ChrisL: How to indicate it? People can deep-link.
05:53:34 [TabAtkins]
fantasai: A note on every subsection.
05:53:45 [TabAtkins]
TabAtkins: Yeah, that's probably sufficiently dense that you'll tend to see it.
05:54:44 [TabAtkins]
Florian: Bikeshed should have something for specs to indicate they replace something.
05:54:49 [TabAtkins]
TabAtkins: In time!
05:56:10 [TabAtkins]
SimonSapin: My list of replacement is my personal judgement of what people should look at for implementation.
05:56:15 [TabAtkins]
RESOLVED: Add a note to every subsection pointing to drafts that replace those parts of CSS.
05:56:28 [SimonSapin]
the list in question: https://github.com/servo/servo/wiki/Relevant-spec-links#css-2
05:56:43 [TabAtkins]
s/subsection/subsection of CSS2/
05:57:39 [TabAtkins]
Topic: Obsoleting css3-linebox
05:57:45 [dauwhe]
http://www.w3.org/TR/css3-linebox/
05:58:03 [TabAtkins]
TabAtkins: Tav from SVG keeps landing on this spec and it confuses him. Can we fix it.
05:58:10 [TabAtkins]
fantasai: We're going to redirect this to css-inline-3.
05:58:30 [TabAtkins]
fantasai: I think it was supposed to be published when we did the last draft of dropcaps, but looks like next draft.
05:58:46 [TabAtkins]
TabAtkins: So when's the timeline?
05:59:08 [TabAtkins]
TabAtkins: If it's gonna be this month, fine, otherwise do a note for now.
05:59:13 [TabAtkins]
dauwhe: Let's just do the note now.
05:59:33 [TabAtkins]
RESOLVED: Ask Chris to put an obsoletion notice on the current css3-linebox on TR.
06:00:02 [TabAtkins]
dbaron: I wish I'd at some point published the linebox edits as a WD.
06:00:06 [TabAtkins]
dbaron: No idea where it went now.
06:00:16 [TabAtkins]
dbaron: It's not in the draft repo as css-linebox.
06:01:39 [TabAtkins]
Topic: New publication system
06:02:20 [TabAtkins]
ChrisL: Existing publication system is a piece of shit.
06:02:37 [TabAtkins]
ChrisL: It takes html => tidy => xhtml => php => composter, produces error messages as a primary function
06:02:52 [TabAtkins]
ChrisL: Then when it's free of error messages, ask someone else to do the same exact thing and disagree iwth you.
06:02:58 [TabAtkins]
ChrisL: This is not a good model.
06:03:02 [TabAtkins]
ChrisL: Replacing it with echidna.
06:03:30 [TabAtkins]
ChrisL: The source tool is in github so you can look at it, change it, etc
06:03:48 [TabAtkins]
ChrisL: Been in alpha, apart to go into public beta (tomorrow, hopefully, or today in australia, who knows)
06:03:55 [TabAtkins]
ChrisL: Been testing it today with css3-ui.
06:04:02 [TabAtkins]
ChrisL: It's cursed though. Breaks everything.
06:04:26 [TabAtkins]
ChrisL: Benefits:
06:04:32 [TabAtkins]
ChrisL: Publish any day. All 7 days.
06:04:39 [tantek]
this is what happens when systems pay attention to invisible metadata :P
06:04:40 [TabAtkins]
ChrisL: Can publish multiple times per day; last per day will be retained.
06:04:49 [TabAtkins]
ChrisL: Downsides: first beta won't do CR, only WD.
06:04:58 [TabAtkins]
ChrisL: It won't do cross-WG publications yet.
06:05:02 [TabAtkins]
ChrisL: Those'll be worked on.
06:05:04 [pjrm]
pjrm has joined #css
06:05:07 [TabAtkins]
ChrisL: But no FXTF stuff yet.
06:05:19 [TabAtkins]
ChrisL: No human in the way to complain about your stylesheet.
06:05:40 [TabAtkins]
astearns: "last per day will be retained"?
06:05:51 [TabAtkins]
ChrisL: If you publish and notice a problem, you can jsut fix it and nobody will know.
06:06:09 [TabAtkins]
ChrisL: But with more than 24 hours, you're screwed.
06:06:19 [TabAtkins]
heycam: Does anyone get the right to push the button?
06:06:22 [TabAtkins]
fantasai: Everyone but Tab.
06:06:32 [TabAtkins]
ChrisL: Anyone can. There's a token system? I don't understand it well.
06:06:33 [dbaron]
Chris: Boston Time
06:06:56 [TabAtkins]
ChrisL: afaik there's nothing preventing chairs from giving it to the editors.
06:06:57 [tantek]
heycam: is there documentation?
06:06:58 [TabAtkins]
heycam: Any docs?
06:07:02 [tantek]
ChrisL: HAHAHAHA
06:07:02 [TabAtkins]
ChrisL: Yes, somewhat.
06:07:17 [TabAtkins]
ChrisL: I'll find it.
06:07:36 [dbaron]
https://github.com/w3c/echidna
06:07:40 [tantek]
ChrisL: there is a link to a link to a ^^^
06:07:48 [dbaron]
https://github.com/w3c/echidna/wiki
06:08:07 [TabAtkins]
krit: If something goes wrong, will someone fix it?
06:08:11 [Yves]
Yves has joined #css
06:08:21 [TabAtkins]
ChrisL: Yeah, it's an official systeam product, they'll fix it.
06:08:27 [Yves]
Yves has left #css
06:08:31 [TabAtkins]
SimonSapin: Does that mean we can have max-width:50em on our stylesheets?
06:08:41 [TabAtkins]
ChrisL: Don't know. As long as the checker doesn't complain, you can probably get away with it.
06:09:55 [TabAtkins]
ChrisL: Currently something we have to take out when we publish is the tests script.
06:10:12 [TabAtkins]
ChrisL: W3C is now allowing those scripts, and not under the directory it's pbulished in.
06:10:39 [TabAtkins]
ChrisL: I scared the systeam by first asking for a W3C mathjax install. When they said no, I pointed out we have 60+ individual mathjax versions all bitrotting, and they capitulated.
06:10:58 [TabAtkins]
ChrisL: Bert is maintaining mathjax, Peter will maintain the results script, and I'll talk to Lea about prism.js.
06:11:13 [TabAtkins]
ChrisL: So over time there'll be several approved scripts people can just use.
06:12:16 [TabAtkins]
krit: Can we get a `bikeshed publish` command?
06:12:24 [TabAtkins]
ChrisL: Sure, probably.
06:12:42 [TabAtkins]
tantek: When will we see the first draft?
06:12:46 [TabAtkins]
ChrisL: Maybe tomorrow.
06:13:55 [TabAtkins]
tantek: How long until we can publish CRs, joint work, etc.
06:13:59 [TabAtkins]
ChrisL: A few months.
06:14:20 [TabAtkins]
astearns: Since FPWDs trigger review too, does that mean they can't do it yet either?
06:14:24 [TabAtkins]
ChrisL: Dunno. Probably.
06:14:26 [ChrisL]
rrsagent, here
06:14:26 [RRSAgent]
See http://www.w3.org/2015/02/08-css-irc#T06-14-26
06:14:45 [TabAtkins]
Topic: Upcoming meeting dates and locations
06:14:58 [TabAtkins]
glazou: Next meeting is confirmed in New York, 18-20 May.
06:15:19 [astearns]
https://wiki.csswg.org/planning/new-york-2015
06:15:23 [TabAtkins]
glazou: We still have to discuss end of august.
06:15:27 [ChrisL]
some documentation https://github.com/w3c/echidna/wiki/How-to-use-Echidna#current-limitations
06:16:19 [TabAtkins]
TabAtkins: People tell me Zurich is a hellhole in August.
06:16:28 [TabAtkins]
dbaron: And it's gotten very expensive lately.
06:16:34 [ChrisL]
echidna on github https://github.com/w3c/echidna
06:16:38 [TabAtkins]
TabAtkins: Right. >So what about Paris?
06:16:47 [TabAtkins]
dbaron: Note that everyone leaves Paris in August.
06:16:49 [TabAtkins]
TabAtkins: So cheap hotels?
06:16:57 [TabAtkins]
dbaron: Also some restaurants will be closed.
06:17:29 [liam]
no, because people from other countries flood in, just as the French fgo to Italy and the Italians all go to Greece :)
06:18:12 [TabAtkins]
TabAtkins: So it sounds like Paris si the best idea.
06:18:14 [TabAtkins]
[general assent]
06:18:26 [ChrisL]
in case anyone wondered, our cuddly new publication system is named after this http://answersafrica.com/wp-content/uploads/2013/10/echidna2.jpg
06:18:30 [TabAtkins]
plinss: Let's nail down dates. Currently Aug 24-28 blocked out.
06:19:44 [TabAtkins]
dino: What about houdini?
06:21:06 [TabAtkins]
Rossen: 1-2 days. We'll work it out on the ML.
06:24:55 [TabAtkins]
TabAtkins: So, suggestion from Tantek is that Firefox hosts Paris August instead, and Google just does Sydney again next Feb.
06:25:18 [tantek]
TabAtkins, well, it was more of a floated idea to consider
06:27:03 [tantek]
TabAtkins, dual motion
06:27:06 [TabAtkins]
RESOLVED: Moz does August meeting in Paris.
06:27:33 [dbaron]
SimonSapin, re the room in paris, both double-check with Shannon *and* book the room in the calendar
06:28:13 [SimonSapin]
dbaron, will do
06:28:36 [TabAtkins]
TabAtkins: Dates!
06:28:48 [TabAtkins]
Florian: Suggest 24-26
06:28:58 [TabAtkins]
szilles: Possible conflict on 24, maybe do 25-27
06:29:38 [TabAtkins]
heycam: Next scheduled SVG meeting is June in Sweden.
06:29:51 [TabAtkins]
heycam: Don't think we're meeting between then and TPAC.
06:30:25 [TabAtkins]
RESOLVED: Provisionally accept Aug 25-27 (Tue-Thu) as the meeting dates.
06:30:52 [TabAtkins]
tantek: Tentatively block out next Feb meeting as first week of Feb?
06:31:16 [TabAtkins]
RESOLVED: Pencil in week of Feb 1st for 2016 meeting.
06:31:25 [TabAtkins]
SimonSapin: Feb 1st is FOSDEM.
06:31:27 [tantek]
with Google hosting in Sydney
06:31:40 [TabAtkins]
glazou: I can't do after Feb 20
06:31:51 [tantek]
getting away from Valentine's Day is a plus
06:32:20 [TabAtkins]
ChrisL: That'll conflict with my 20th wedding anniversary.
06:32:49 [TabAtkins]
dbaron: This year, the week before this week was a more expensive for flights, because of Australia flight patterns, though that went away closer in.
06:33:49 [glazou]
« girlfriend of a standards’ freak, lone evenings »
06:34:39 [glazou]
glazou has left #css
06:34:42 [TabAtkins]
ADJOURNED
06:35:08 [TabAtkins]
<br dur="until May">
06:38:04 [glazou]
glazou has joined #css
06:38:52 [Rossen]
br { @extends .break; action: resume; }
06:38:54 [shane]
ScribeNick: shane
06:39:18 [shane]
dbaron: discussion on the mailing list - agreed on line height rules. But it's not in the spec yet.
06:39:24 [shane]
fantasai: it seemed like that made sense.
06:39:38 [shane]
fantasai: will try to write it up and grasp it fully.
06:40:00 [shane]
dbaron: with some of the prose for figuring out what this means in terms of vertical placement/sizing I couldn't figure it out
06:40:36 [shane]
xidorn: open bug about how height in ruby base container can be determined
06:40:58 [shane]
dbaron: prose in spec about how this can be determined. OK for ruby text container but ruby base container should act like an inline as much as possible.
06:41:27 [shane]
fantasai: I think ruby base container in terms of how it effects line layout should be like an inline, but in terms of how it effects the spacing of ruby annotations on either size need to take into account border padding and margin
06:41:35 [shane]
dbaron: ok with that
06:41:45 [shane]
dbaron: part that's weird is sizing of the content box is not like an inline
06:42:00 [shane]
fantasai: right. Sizing of content box should include margin boxes of all of the bases
06:42:15 [shane]
dbaron: is that because you don't like how inlines work?
06:42:28 [shane]
fantasai: don't like that margins don't effect layout for those.
06:42:43 [shane]
fantasai: if you put borders on ruby bases, having that not effect position of ruby text seems wrong
06:42:54 [shane]
fantasai: how does the author get it right then? line height?
06:43:01 [shane]
dbaron: fine with it to move the ruby text
06:43:40 [shane]
fantasai: simplest way to keep things from colliding is to have the ruby base container contain all of the ruby base boxes and text container (?) contain ruby text and stack them with no gaps
06:43:53 [shane]
dbaron: if you don't want line height to effect ruby position that makes sense
06:44:05 [shane]
SteveZ: but ruby has to effect line height
06:44:08 [shane]
dbaron: I'm OK with that.
06:44:17 [shane]
xidorn: does vertical align property effect ruby text?
06:44:19 [shane]
fantasai: yes
06:44:21 [shane]
xidorn: but how?
06:44:43 [shane]
fantasai: don't remember scoping. Ruby text at same annotation level with align with each other.
06:44:57 [shane]
dbaron: so basically ruby text container acts like a line for purposes of alignment
06:45:12 [shane]
SteveZ: so what connects lines?
06:45:27 [shane]
SteveZ: will I get strange behaviour if I put non-ruby stuff between two things?
06:45:53 [shane]
SteveZ: e.g. underlines don't jump around. Concerned that ruby might act different. I don't know what should happen though.
06:46:12 [shane]
fantasai: <draws on board>
06:46:41 [shane]
SteveZ: what if one of the letters was bigger?
06:46:46 [shane]
fantasai: <more drawing>
06:47:14 [shane]
fantasai: basically you do the sizing of the characters, then the base box wraps around that, then the text sits on top so it's always aligned
06:48:01 [shane]
SteveZ: why isn't the ruby text box a line box the whole line long?
06:49:28 [shane]
xidorn: another concern is the line height of the anonymous ruby text container. In the current model it should inherit from its parent. But I don't think it is desirable.
06:50:01 [shane]
fantasai: I think you're right. We shouldn't be using properties of the ruby text container for layout. We should be using the ruby text, then wrapping the container around the result.
06:50:52 [shane]
dbaron: be careful about difference between line box and inline box. Inline box has a line height but line box wraps around a bunch of inline boxes and takes height from them.
06:51:15 [shane]
dbaron: I think what you're saying makes sense. More complicated but OK. Put in spec please?
06:51:19 [shane]
fantasai: what's not in the spec?
06:51:25 [shane]
dbaron: vertical alignmnt
06:51:29 [shane]
fantasai: I'll just check
06:52:02 [shane]
fantasai: I need to fix that then
06:52:17 [shane]
dbaron: that's biggest set of issues I was worried about.
06:52:37 [shane]
dbaron: would like to see spec edits resulting from discussion with xidorn and kochii though.
06:52:40 [shane]
fantasai: couple of hard issues
06:54:05 [shane]
fantasai: handling whitespace between ruby text. Problem is that if you've got ruby text that you've marked up but there's whitespace in-between. Want the whitespace to stay there but I size the ruby text elements to 50% of base text. But then whitespace ends up being really tall and really wide and the wrong size.
06:54:19 [shane]
Florian: that's not something we can fix
06:54:30 [shane]
fantasai: yes, HTML people don't like autogenerating tags
06:54:40 [shane]
fantasai: that's the issue I haven't really figured out how to solve.
06:55:01 [shane]
dbaron: is it possible to say that the whitespace goes away but that there are other spacing rules for ruby text?
06:55:16 [shane]
dbaron: e.g. what script they're in, whether script has a certain property.
06:55:26 [shane]
dbaron: e.g. newlines go away in Chinese
06:55:41 [shane]
SteveZ: does that mean you want to put another character than whitespace in?
06:56:06 [shane]
fantasai: I think you could reasonably argue that those rules could get rid of the whitespace but there are other cases where you don't want it too
06:56:22 [shane]
fantasai: issue is that we want font set on the outer box but instead it's set on the inner boxes
06:56:57 [shane]
Florian: can we reverse-propagate style to the parent?
06:57:00 [shane]
dbaron: never done it before
06:57:17 [shane]
astearns: any other reason we'd want to style the text container?
06:57:21 [shane]
fantasai: possibly?
06:57:40 [shane]
fantasai: we do forbid you from making ruby text and ruby base containers visible.
06:57:58 [shane]
fantasai: this is because some impls will want an internalized structure that's different from the CSS hierarchy
06:58:05 [shane]
fantasai: styling those boxes isn't an important use case.
06:58:16 [shane]
fantasai: should be fine to have different internal model
06:58:41 [shane]
fantasai: so boxes aren't directly detectable, can only inherit properties through them
06:58:59 [shane]
astearns: can you say line height of container is max line height of children?
06:59:13 [shane]
SteveZ: that doesn't work. Really want to set it to font size of children
06:59:34 [shane]
SteveZ: only concerned about whitespace between?
06:59:41 [shane]
fantasai: yeah everything else is wrapped
07:00:05 [shane]
Rossen: is this really a common use case?
07:00:13 [shane]
fantasai: it isn't an error condition but it isn't common
07:00:50 [shane]
SteveZ: classic one is where you have double ruby (english + ??). English one would need the spaces.
07:01:07 [shane]
SteveZ: would be common in English ruby
07:01:14 [shane]
fantasai: not sure what the rules are in pinyin
07:01:52 [shane]
Florian: some syllables need to be separated by an apostrophe if there isn't a space. Otherwise it's stylistic
07:02:22 [shane]
Florian: if the only purpose of propagating up is to propagate back down again that seems like the least bad idea
07:02:35 [shane]
fantasai: agreed. I'll use that for now. If anyone thinks of something better can change it.
07:03:16 [shane]
fantasai: next issue. Webkit has a special keyword for ruby-font-size. Inter-character generates smaller font than above or below.
07:03:32 [shane]
fantasai: resolved as locale-specific rule in stylesheet for ruby
07:03:48 [shane]
Florian: is by language not by script. Close enough?
07:04:10 [shane]
fantasai: can do it by lang. Can set font size explicitly if a problem. This is just for default size.
07:04:14 [shane]
Florian: OK
07:05:26 [shane]
RESOLVED: use locale-specific :lang rules instead of something like webkit-ruby-size.
07:06:47 [shane]
fantasai: next issue. Ruby-position property had 2 keywords for position in horizontal text and for vertical text.
07:07:11 [shane]
fantasai: suggestion was to simplify to a single keyword for both (over, under, inter-character)
07:07:18 [shane]
dino: we have after, before, inter-character
07:07:52 [Florian]
http://upload.wikimedia.org/wikipedia/commons/c/c7/Hunmin_jeong-eum.jpg
07:07:53 [shane]
fantasai: over means right, under left, and inter-character same as over for vertical text
07:08:08 [shane]
Florian: this example shows inter-character for vertical text
07:08:15 [shane]
fantasai: can extend back to two keywords if necessary
07:08:32 [shane]
fantasai: but this is the common case
07:08:41 [shane]
fantasai: can we resolve to do this?
07:08:57 [shane]
scribenick TabAtkins
07:09:00 [TabAtkins]
NOOOOOOOOOOOO
07:09:33 [TabAtkins]
szilles: My undesrtanding of the problem of translating above/below to vertical is that traditionally japanese does right (above) but some chinese cases go left.
07:09:46 [TabAtkins]
fantasai: That's why we had two values, but Xidorn says we dont' need them.
07:09:52 [TabAtkins]
xidorn: I don't see any left cases.
07:10:05 [TabAtkins]
xidorn: You don't have any pictures of left.
07:10:21 [TabAtkins]
xidorn: I don't know what use-cases you've found.
07:10:29 [TabAtkins]
fantasai: This is stuff I inherited from the previous editro.
07:11:00 [TabAtkins]
fantasai: The difference between over/under is.
07:11:34 [TabAtkins]
fantasai: If you have block-flow of vertical text laying out right to left, before is right, after is left. If the blocks stack left to right, vice versa.
07:11:46 [TabAtkins]
fantasai: But over/under depend on what way text is rotated, not block-flow direction.
07:12:07 [TabAtkins]
fantasai: So proposal is to knock it it down to over|under|inter-character, and we can add more in the future if needed.
07:12:14 [TabAtkins]
dbaron: What was the two-value syntax?
07:12:30 [xidorn]
[over|under|inter-character] || [left|right]
07:12:34 [TabAtkins]
fantasai: Would let you specify left|right as well, so one's for horizontal and one's for vertical writing.
07:12:45 [TabAtkins]
Florian: The current proposal combines them.
07:13:41 [TabAtkins]
RESOLVED: ruby-position simplified to over|under|inter-character
07:14:08 [TabAtkins]
fantasai: Next is default value of ruby-align
07:14:18 [TabAtkins]
fantasai: Two values are center and space-around.
07:14:21 [TabAtkins]
fantasai: space-around is a justification value.
07:14:33 [TabAtkins]
fantasai: It'd space around at the justificatoin opportunities.
07:14:48 [TabAtkins]
fantasai: So latin text would stay together, but Chinese would be able to split between each char.
07:15:03 [TabAtkins]
fantasai: So we set the initial value to space-around.
07:15:25 [TabAtkins]
fantasai: Problem is that bopomofo can be justified, but bopomofo ruby should be centered by default (due to language users preference).
07:15:39 [TabAtkins]
fantasai: 1) change initial value to center
07:15:52 [TabAtkins]
fantasai: Reset it for Japanese to be space-around in the UA stylesheet.
07:16:15 [TabAtkins]
fantasai: 2) Keep it as space-around, reset it for chinese to center.
07:16:50 [TabAtkins]
fantasai: 3) Have a value that does custom justifications - auto - which justifies between Han and Kana, and not between bopomofo.
07:17:01 [TabAtkins]
fantasai: I prefer 2
07:17:14 [TabAtkins]
s/I prefer 2/Spec is currently 2/
07:17:25 [TabAtkins]
fantasai: But multi-word ruby you may not want to justify spaces, so maybe 1/3.
07:17:32 [TabAtkins]
fantasai: It seems only Han/Kana should be justifying.
07:17:42 [TabAtkins]
TabAtkins: 1 seems simple then.
07:17:51 [TabAtkins]
szilles: 3 is the classic way we do it, but it requires magic.
07:18:02 [TabAtkins]
fantasai: I don't think 3 is too magic, but 1 is definitely simpler.
07:18:22 [TabAtkins]
fantasai: Main concern with 1 is "do we have a concern with legacy untagged content?"
07:19:15 [TabAtkins]
szilles: 3 is script-based
07:19:30 [TabAtkins]
szilles: Why is 1 better?
07:19:47 [TabAtkins]
fantasai: Simpler. 1 is just a 1-line fix to your UA stylesheet; 3 is effectively a new jsutification algo.
07:20:10 [TabAtkins]
TabAtkins: Can we just do 1 unless we see evidence of brekage in the wild?
07:20:21 [TabAtkins]
fantasai: Dunno what Koji wants. Let's do 1 unless Koji dissents.
07:21:04 [TabAtkins]
RESOLVED: Either option 1 or 3 for ruby-position, at editor's discretion.
07:21:21 [TabAtkins]
ADJOURN FOR REALZIES THIS TIME
07:21:53 [dauwhe]
dauwhe has joined #css
08:14:16 [Ms2ger]
Ms2ger has joined #css
08:29:32 [tantek]
tantek has joined #css
08:31:32 [lajava]
lajava has joined #css
08:34:43 [zcorpan]
zcorpan has joined #css
08:58:56 [lajava]
lajava has joined #css
09:19:47 [antonp]
antonp has joined #css
09:39:19 [zcorpan]
zcorpan has joined #css
10:06:11 [svillar]
svillar has joined #css
10:10:24 [zcorpan_]
zcorpan_ has joined #css
10:12:34 [koji]
fantasai: oh, noooo, please...
10:17:12 [koji]
fantasai: actually, it's an interesting question; how to justify Bopomofo in normal text, outside the ruby. In my rough understanding, it's a space-delimited writing system, no?
10:47:09 [pjrm]
pjrm has joined #css
11:12:11 [glazou]
glazou has joined #css
11:19:46 [dauwhe]
dauwhe has joined #css
11:19:53 [lajava]
lajava has joined #css
11:34:53 [dbaron]
dbaron has joined #css
12:00:22 [Florian]
Florian has joined #css
12:09:32 [tantek]
tantek has joined #css
12:10:26 [Florian]
Florian has joined #css
12:38:05 [svillar]
svillar has joined #css
12:48:40 [tantek]
tantek has joined #css
13:03:38 [plh]
plh has joined #css
13:18:14 [Florian]
Florian has joined #css
14:02:43 [tantek]
tantek has joined #css
14:08:25 [stryx`]
stryx` has joined #css
14:14:42 [koji]
fantasai: we do have rtc:lang(zh), rt:lang(zh) { ruby-align: center; } in http://dev.w3.org/csswg/css-ruby/#default-ua-ruby isn't this enough?
14:21:52 [koji]
fantasai: oh, that's what you added 3 days ago, ok...
14:25:21 [lajava]
lajava has joined #css
14:54:52 [svillar]
svillar has joined #css
15:28:48 [thinkxl]
thinkxl has joined #css
16:53:51 [Florian]
Florian has joined #css
17:05:28 [tantek]
tantek has joined #css
17:14:31 [estellevw]
estellevw has joined #css
17:39:30 [adenilson]
adenilson has joined #css
17:41:56 [lajava]
lajava has joined #css
18:49:52 [bcampbell]
bcampbell has joined #css
20:23:37 [johanneswilm]
johanneswilm has joined #css
21:20:40 [bcampbell]
bcampbell has joined #css
21:24:07 [Florian]
Florian has joined #css
21:32:19 [SimonSapin]
koji, fantasai: shouldn’t UA rules go into https://html.spec.whatwg.org/multipage/rendering.html ?
21:45:20 [tantek]
tantek has joined #css
21:50:26 [Florian]
Florian has joined #css
21:52:13 [Florian]
Florian has joined #css
22:00:47 [Florian]
Florian has joined #css
22:03:04 [glazou]
glazou has joined #css
22:03:37 [Florian]
Florian has joined #css
22:11:22 [dbaron]
dbaron has joined #css
22:14:01 [kwkbtr]
kwkbtr has joined #css
22:14:18 [ed]
we'll be using #fx today for minuting
22:14:57 [liam]
liam has changed the topic to: See also #fx for minutes - logs: http://krijnhoetmer.nl/irc-logs/css - Sydney ftf meeting https://wiki.csswg.org/planning/sydney-2015 (JS only logs: https://log.csswg.org/irc.w3.org/css/today )
22:15:33 [nikos]
nikos has joined #css
22:15:40 [dino]
dino has joined #css
22:16:32 [tantek]
tantek has joined #css
22:16:54 [Florian]
Florian has joined #css
22:17:46 [murakami]
murakami has joined #css
22:20:01 [AndreyR]
AndreyR has joined #css
22:21:49 [smfr]
smfr has joined #css
22:24:05 [johanneswilm]
johanneswilm has joined #css
22:24:58 [murakami]
murakami has joined #css
22:25:34 [roc]
roc has joined #css
22:26:00 [stakagi]
stakagi has joined #css
22:26:55 [stakagi]
stakagi has joined #css
22:27:28 [dbaron]
dbaron has joined #css
22:30:07 [xidorn]
xidorn has joined #css
22:31:15 [fantasai]
Topic: SVG Sizing and box-sizing
22:31:20 [fantasai]
ScribeNick: fantasai
22:31:25 [fantasai]
We're looking at some testcases from Tantek
22:31:45 [fantasai]
Current testcase is SVG image with width=100 viewBox="0 0 100 100"
22:31:45 [SimonSapin]
fantasai, heycam is scribing in #fx
22:31:48 [fantasai]
oh
22:31:52 [fantasai]
that' swhy I can't see anything :)
22:31:54 [jet]
jet has joined #css
22:44:52 [fantasai]
koji: ping me when you're online, let's talk about ruby :)
22:52:58 [hyojin]
hyojin has joined #css
23:04:12 [glazou]
remember, the meeting is in #fx today
23:17:10 [Florian]
Florian has joined #css
23:53:33 [sgalineau]
anything actually being minuted?
23:57:04 [smfr]
sgalineau: #fx please
23:57:44 [sgalineau]
smfr: am there. not seeing anything. maybe irccloud is being funky.
23:59:15 [liam]
sgalineau, still on break maybe?
23:59:29 [liam]
oh you said that already, sorry
23:59:34 [sgalineau]
liam: yes, as it turns out
23:59:38 [johanneswilm]
johanneswilm has joined #css
23:59:53 [sgalineau]
liam: or at the beach
00:00:53 [liam]
:D
00:00:55 [liam]
snow here.
00:03:55 [kwkbtr]
kwkbtr has joined #css
00:06:38 [stakagi]
stakagi has joined #css
00:19:32 [hyojin__]
hyojin__ has joined #css
00:23:34 [adenilson]
adenilson has joined #css
01:03:49 [tantek]
tantek has joined #css
01:10:54 [jdaggett]
jdaggett has joined #css
01:17:23 [glazou]
glazou has joined #css
01:37:31 [adenilson]
adenilson has joined #css
01:38:17 [adenilson]
adenilson has joined #css
01:39:41 [fantasai]
koji: Hi :)
01:39:57 [fantasai]
Question 1:
01:40:01 [fantasai]
'vertical-align' property
01:40:08 [fantasai]
should definitely apply to ruby container <ruby>
01:40:14 [fantasai]
but should it also apply to <rb>?
01:40:23 [shepazu_]
shepazu_ has joined #css
01:40:29 [fantasai]
I'm thining it should apply to <rt>, so you can align <rt> with respect to each other
01:40:29 [smfr]
smfr has left #css
01:40:45 [fantasai]
it makes things easier if it doesn't apply, I think
01:41:28 [koji]
fantasai: hm, that's where my understanding is a bit unreliable...
01:42:30 [koji]
when vertical-align is aligned to <ruby>, I assume its baseline is the baseline of <rb>, correct?
01:45:49 [koji]
when you say it applies to <ruby> but not to <rb>, line boxes of <rb> is not affected by the vertical-align of <ruby>?
01:47:05 [koji]
if so, that does not sound great, but I'm not sure if my understanding is accurate
02:15:10 [kwkbtr]
kwkbtr has joined #css
02:35:54 [stryx`]
stryx` has joined #css
02:38:07 [hyojin]
hyojin has joined #css
02:50:17 [stakagi]
stakagi has joined #css
02:59:23 [johanneswilm]
johanneswilm has joined #css
03:00:09 [kwkbtr]
kwkbtr has joined #css
03:02:04 [Florian]
Florian has joined #css
03:02:20 [dbaron]
fantasai, btw, regarding text-decorations and selection in Gecko -- Gecko has code specific to determining what color to use for the text-decoration when it's in selected text
03:03:51 [tantek]
tantek has joined #css
03:08:05 [krit]
TabAtkins: Bikeshed used to add a string in the console what you need to add to the spec to let Bikeshed select the right spec for a defintion. It still says which spec, type and name but you can not copy past anymore. Can this change back?
03:09:54 [TabAtkins]
krit: You have to put it into a <pre class=link-defaults> block now.
03:09:54 [TabAtkins]
krit: I stopped outputting the text for Link Defaults metadata, because it can't handle for='' values.
03:10:35 [krit]
TabAtkins: oh, but I still can copy paste from the console but into this <pre>?
03:10:49 [TabAtkins]
krit: (The message actually says that, but it's easy to skip past because it looks similar to the old message.)
03:10:51 [TabAtkins]
krit: Yeah.
03:13:53 [krit]
TabAtkins: thanks
03:15:07 [fantasai]
koji: No, <rb> would be aligned within <ruby>, but you can't align different <rb> differently
03:23:55 [tantek_]
tantek_ has joined #css
03:25:15 [adenilson_]
adenilson_ has joined #css
03:40:01 [xidorn]
fantasai, koji, I think that means we handle vertical-align on <rb> as if it is always |baseline|, right?
03:40:15 [fantasai]
yeah
03:40:30 [fantasai]
if that helps
03:40:33 [fantasai]
I'm not sure it helps
03:40:47 [fantasai]
if you increase the font-size on <rb>, you still have different alignment problems :/
03:41:21 [xidorn]
no, I don't think there would be
03:41:49 [xidorn]
but if some <span>s inside <rb> have different font-size, then there might be, I guess
03:43:58 [koji]
as long as one vertical-align value can be set to all bases in one <ruby>, I think that's sufficient
03:44:26 [koji]
does that answer?
03:44:39 [fantasai]
yeah
03:44:46 [fantasai]
too
03:44:54 [fantasai]
:)
03:45:00 [xidornq]
xidornq has joined #css
03:45:27 [fantasai]
koji: http://www.w3.org/Style/CSS/read
03:46:32 [fantasai]
xidorn: ah right the problem was top/bottom alignment of the bases.
03:46:32 [koji]
xidorn: I can think of possibilities where author wants center or text-top to base text, so I wish we allow that possibility, but can't think of any scenario where authors want different alignment within single <ruby>
03:47:35 [fantasai]
xidorn: what if we defined vertical-align: top/bottom to be within the ruby base container only?
03:48:59 [xidornq]
fantasai, let me learn what vertical-align is supposed to do for a bit
03:49:31 [fantasai]
okay
03:50:11 [xidornq]
then what would be the top/bottom of the line if there is margin on <rb>s?
03:50:36 [fantasai]
vertical align works like this:
03:50:44 [fantasai]
align everything that's not top/bottom
03:50:49 [fantasai]
measure from the top to the bottom
03:51:00 [fantasai]
max(that measurement, size of boxes that are top/bottom)
03:51:07 [fantasai]
that gets you height of line
03:51:15 [fantasai]
then shift top/bottom boxes to the top/bottom of the line
03:51:17 [fantasai]
(roughly)
03:51:22 [fantasai]
What I'm suggesting is
03:51:33 [fantasai]
that instead of vertical-align: top/bottom on <rb> pushing to top/bottom of the line
03:51:45 [fantasai]
we do a local alignment within the <rbc>
03:51:50 [xidorn]
normally, inlines do not have block-axis margin, so they can be vertical aligned
03:52:06 [fantasai]
they have it, you just don't measure it
03:52:12 [xidorn]
but if <rb>'s margin expands the height of <rbc>, what should happen
03:52:52 [fantasai]
the <rbc> gets taller
03:53:10 [fantasai]
:)
04:06:52 [krit]
TabAtkins: Why do I get this warning now and how can I get rid of it by still keeping ''none''? WARNING: Multiple possible 'maybe' refs for 'none'.
04:07:27 [TabAtkins]
fantasai: If you run into more obvious "I always want to get this term from this spec" cases, feel free to do edits on the spec-data/readonly/link-defaults.infotree file. You can do it on GitHub and submit a PR automatically, very easy.
04:07:43 [TabAtkins]
krit: Because there are a bunch of "none" values it can choose from, same as "auto". Specify the property you want.
04:08:05 [krit]
TabAtkins: So I need to add <a for... ?
04:08:20 [TabAtkins]
No, just ''foo/none''
04:08:33 [krit]
oh, ok thanks
04:08:37 [TabAtkins]
You can generally use the foo/bar syntax in the autolinking syntaxes.
04:15:27 [krit]
TabAtkins: I get "Multiple possible 'dfn' refs for 'containing block'." even though I added spec:css21; type:dfn; text:containing block already
04:15:46 [krit]
TabAtkins: there is no other choice actually
04:16:37 [krit]
TabAtkins: and last but not least: Bikeshed now prefers you specify alternate linking texts with the 'lt' attribute, not 'title'
04:16:48 [krit]
TabAtkins: which titles does Bikeshed mean?
04:17:43 [krit]
TabAtkins: found the title one (but don't understand it)
04:23:00 [xidorn]
fantasai, does that also mean descendants of <rb> will also only be aligned within <ruby>?
04:23:57 [fantasai]
xidorn: no idea, I don't have an opinion on this
04:25:51 [TabAtkins]
krit: Yeah, sorry, if a spec defines an identical term multiple times, you can't shut Bikeshed up. I'm working with plinss to fix this for specs that are auto-parsed (rather than using Bikeshed, which throws fatal errors if you duplicate definitions). You can add the term to Ignored Terms to silence the error, at least.
04:26:25 [krit]
TabAtkins: ah forgot about ignore
04:41:03 [estellevw]
estellevw has joined #css
05:02:20 [SimonSapin]
dbaron: Is "(More details here.)" at https://wiki.csswg.org/planning/hosting supposed to be a link?
05:02:44 [dbaron]
SimonSapin, I think it means "FIXME: Write more details here"
05:02:51 [SimonSapin]
ok :)
05:10:25 [willy]
willy has joined #css
05:11:06 [willy]
willy has left #css
05:20:42 [johanneswilm]
johanneswilm has joined #css
05:20:50 [kwkbtr]
kwkbtr has joined #css
05:22:55 [rego]
rego has joined #css
05:23:09 [SimonSapin]
astearns: I’m just curious: does it help to open pull requests on the draft repo rather than pushing directly?
05:23:09 [TabAtkins]
Yes, that's what it means.
05:23:16 [TabAtkins]
I also thought it was supposed to be a link at first, though.
05:23:18 [kwkbtr]
kwkbtr has joined #css
05:23:52 [astearns]
SimonSapin: I'm making changes in branches on my own fork of the repo
05:24:23 [astearns]
I suppose I could be branching from the main repo, but I've always used a separate fork with git
05:25:00 [TabAtkins]
I just push to master on the main repo.
05:25:22 [TabAtkins]
yolo
05:25:25 [Florian]
Florian has joined #css
05:25:27 [Florian]
Florian has joined #css
05:36:18 [astearns]
I just flail about in the source-control system I'm given - it would be nice to have a wiki page with recommended step-by-step instructions for editing drafts in git
05:39:03 [jdaggett]
jdaggett has joined #css
05:41:29 [SimonSapin]
The usual workflow with a single shared repository and a single branch should Just Work. When it doesn’t, nag plinss :)
05:42:25 [SimonSapin]
a pull request can be useful to get review from a (co-)editor before merging
05:47:07 [astearns]
SimonSapin: pointer to "the usual workflow"?
05:55:07 [SimonSapin]
astearns: there are tons of guides out there, with various levels of details. what are you familiar with?
05:55:08 [TabAtkins]
It should look like you did in hg. You just work in the main branch and push when you feel like.
05:55:34 [TabAtkins]
plinss: The Houdini bikeshed errors email is being sent with a subject talking about CSSWG.
05:56:11 [SimonSapin]
I don’t really want to write yet another monad^W git tutorial
05:57:03 [liam]
i found http://lea.verou.me/2011/10/easily-keep-gh-pages-in-sync-with-master/ useful fwiw
05:57:48 [estellevw]
estellevw has joined #css
06:06:37 [TabAtkins]
SimonSapin: But git is just a monad, so you can kill two birds!
06:07:30 [TabAtkins]
liam: Nah, that's overcomplicated. If you want to display your master branch, just follow http://www.xanthir.com/b4Zz0
06:07:59 [TabAtkins]
I think the instructions in my post weren't possible in 2011.
06:09:29 [liam]
i think that's a simpler way of working but not having a master doesn't suit everyone
06:09:32 [liam]
(er, so to speak)
06:11:45 [tantek]
tantek has joined #css
06:13:13 [astearns]
SimonSapin: the guides I've been following say to fork, branch, commit, push, pull request, merge
06:14:33 [SimonSapin]
I see. That is useful if you don’t have push access to the repository (and someone else merges) or if you want review from someone before merging.
06:15:04 [astearns]
might not be a bad idea to require reviews :)
06:15:30 [SimonSapin]
several WG members freaked out when I suggested this before
06:15:55 [TabAtkins]
I got shit to do, man, i can't wait for reviews
06:16:07 [astearns]
so the workflow should be clone, commit, push?
06:16:09 [liam]
and you get the problem of absent reviewers
06:16:19 [liam]
not accepting the pull requests in time
06:16:20 [tantek_]
tantek_ has joined #css
06:16:50 [SimonSapin]
astearns: right, commit+push should be enough (assuming you already have a clone)
06:17:06 [astearns]
ok
06:17:45 [astearns]
I suspect requiring reviews for Tab's commits only might get wider approval :)
06:17:47 [SimonSapin]
apparently https://mac.github.com/ is a thing, too
06:19:10 [TabAtkins]
I've used the windows github software before. Pretty decent.
06:19:32 [astearns]
I use the Mac app for some things, but mostly prefer the command line
06:26:28 [glazou]
glazou has joined #css
06:32:09 [Florian]
Florian has joined #css
06:53:25 [Florian]
Florian has joined #css
07:00:36 [Florian]
Florian has joined #css
07:04:14 [adenilson]
adenilson has joined #css
07:04:43 [estellevw]
estellevw has left #css
07:52:24 [johanneswilm]
johanneswilm has joined #css
07:54:46 [antonp]
antonp has joined #css
08:20:12 [antonp]
antonp has joined #css
08:36:06 [svillar]
svillar has joined #css
08:47:30 [estellevw]
estellevw has joined #css
09:28:57 [lajava]
lajava has joined #css
10:05:39 [Florian]
Florian has joined #css
10:43:55 [lajava]
lajava has joined #css
10:45:55 [Ms2ger]
Ms2ger has joined #css
11:02:45 [zcorpan]
zcorpan has joined #css
11:17:31 [zcorpan]
zcorpan has joined #css
11:31:45 [johanneswilm]
johanneswilm has joined #css
11:34:34 [antonp]
antonp has joined #css
11:38:53 [zcorpan]
zcorpan has joined #css
12:15:42 [Florian]
Florian has joined #css
13:14:48 [plh]
plh has joined #css
13:26:32 [plh]
plh has joined #css
13:55:29 [svillar]
svillar has joined #css
14:25:40 [zcorpan]
zcorpan has joined #css
14:50:04 [Ms2ger]
Ms2ger has joined #css
15:24:05 [antonp]
antonp has joined #css
15:29:57 [Florian]
Florian has joined #css
15:34:51 [anssik]
anssik has joined #css
15:58:51 [johanneswilm]
johanneswilm has joined #css
16:33:52 [estellevw]
estellevw has joined #css
16:34:44 [zcorpan]
zcorpan has joined #css
16:47:20 [estellevw_]
estellevw_ has joined #css