/irc-logs / w3c / #css / 2015-02-10 / end

Options:

# Session Start: Tue Feb 10 00:00:00 2015
# Session Ident: #css
# [00:00] <fantasai> tantek: If you change the font size, or the radius of theelements, it will no longer fit nicely
# [00:00] <fantasai> tantek: I wonder if percentage-based distance abspos is what you want, or some model of polar box model
# [00:00] <fantasai> TabAtkins: You can always do calc(100% - half-of radius).
# [00:01] <fantasai> q+
# [00:01] * Zakim sees fantasai on the speaker queue
# [00:01] <fantasai> Florian: Yes if you know your radius
# [00:01] <glazou> Zakim, ack fantasai
# [00:01] <Zakim> I see no one on the speaker queue
# [00:01] <JonathanNeal_> Ya keep sayin’ ma name, Zakim. What is up?
# [00:01] <JonathanNeal_> Hello
# [00:02] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [00:02] <fantasai> fantasai: if you have the ability to set origin the way backgrounds do, then you cna take the size into account as positioning
# [00:02] <fantasai> tantek: abspos does a nice job of taking into account borders/padding
# [00:02] <fantasai> tantek: I would challenge this to be as simple as abspos
# [00:03] <zcorpan> q+
# [00:03] * Zakim sees zcorpan on the speaker queue
# [00:04] <dbaron> q+
# [00:04] * Zakim sees zcorpan, dbaron on the speaker queue
# [00:04] <roc> roc: q+
# [00:04] <roc> oops
# [00:04] <roc> q+
# [00:04] * Zakim sees zcorpan, dbaron, roc on the speaker queue
# [00:04] <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
# [00:04] * Joins: johanneswilm (~johannes@public.cloak)
# [00:04] <fantasai> tantek^: abspols lets you do positioning from the edge without doing calc etc.
# [00:05] <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
# [00:05] <dbaron> dbaron: Absolute positioning is pretty fragile in most cases.
# [00:05] <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%
# [00:05] <zcorpan> ack me
# [00:05] * Zakim sees dbaron, roc on the speaker queue
# [00:05] <tantek> I would like to NOT have to pick 80% based on the radius of the child, parent etc.
# [00:05] <fantasai> zcorpan: My point was already said by fantasai: background-positioning can do offsets
# [00:05] <SteveZ> q+
# [00:05] * Zakim sees dbaron, roc, SteveZ on the speaker queue
# [00:05] <glazou> Zakim, ack dbaron
# [00:05] <Zakim> I see roc, SteveZ on the speaker queue
# [00:05] * fantasai thinks tantek shoudl reread the css3-background spec
# [00:06] <fantasai> dbaron: I would not want to follow abspos as a model
# [00:06] <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
# [00:06] <fantasai> dbaron: We've done a lot of things with layout systems that do more flexible and produce better results
# [00:06] <glazou> Zakim, ack roc
# [00:06] <Zakim> I see SteveZ on the speaker queue
# [00:06] <tantek> my point was it should be NO WORSE than abspos
# [00:06] * Joins: cyril (~cyril@public.cloak)
# [00:06] <tantek> if we can do better, great
# [00:06] <fantasai> roc: Since this ise easily fpolyfillable in its current form
# [00:06] <fantasai> roc: Mabye we produce better custom layout and style integration
# [00:06] <fantasai> roc: do this insteadof adding it to the CSS core
# [00:07] <fantasai> roc: If this has to go into CSS core, then what wouldn't?
# [00:07] <roc> ack me
# [00:07] * Zakim sees SteveZ on the speaker queue
# [00:07] <fantasai> glazou: Even for polyfills, 2 different editors of polyfill for this would like to rely on the spec
# [00:07] * Quits: achicu_____ (~sid13301@public.cloak) (Client closed connection)
# [00:07] <fantasai> roc: Could have a spec for feature sthat are implemented in polyfill rather than in browsers
# [00:07] * Quits: nikos (~uid28403@public.cloak) (Client closed connection)
# [00:07] <glazou> Zakim, ack SteveZ
# [00:07] <Zakim> I see no one on the speaker queue
# [00:07] <fantasai> roc: Need to be clear about which it is, makes a big difference to constraints around the design
# [00:08] <fantasai> szilles:...
# [00:08] * Quits: JonathanNeal_ (~sid5831@public.cloak) (Client closed connection)
# [00:08] <fantasai> SteveZ: If I consider a center an edge and an angle, it has all of the properties that you want
# [00:08] * Quits: sanja (~sanja@public.cloak) ("Page closed")
# [00:08] <fantasai> SteveZ: Could talk about edge shape
# [00:08] * Joins: ChrisL (clilley@public.cloak)
# [00:08] * Quits: TabAtkins (~sid11559@public.cloak) (Ping timeout: 180 seconds)
# [00:08] * Quits: ojan (~sid5519@public.cloak) (Ping timeout: 180 seconds)
# [00:08] <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
# [00:08] <fantasai> SteveZ: So you could use it for better positioning
# [00:09] <fantasai> tantek: Goal is to avoid collisions by default
# [00:09] <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
# [00:09] <fantasai> SteveZ: same rules as abspols
# [00:09] <fantasai> SteveZ: Center, you may want a different rule, e.g. center me on the center
# [00:09] * Quits: jumland (~sid26952@public.cloak) (Client closed connection)
# [00:09] * Quits: timeless (~sid4015@public.cloak) (Ping timeout: 180 seconds)
# [00:09] <fantasai> SteveZ: Tab's point was that it generalizes the same way
# [00:10] <fantasai> hyojin: In future, need extensions for smart watch
# [00:10] <fantasai> hyojin: I think these are reasonable
# [00:10] <fantasai> hyojin: Will send this to CSS ML, and will collect problems from developers making round dsiplay. I will share wtih CSS WG.
# [00:10] <fantasai> hyojin: Thank you
# [00:10] <fantasai> glazou: Thank you for the presentation
# [00:10] <fantasai> glazou: The way you are expcting to contribute to the document
# [00:11] <fantasai> glazou: Are you requesting an Editors Draft at this point?
# [00:11] <fantasai> hyojin: Yes, we'd like to publish this
# [00:11] <fantasai> Florian: I'm happy about including these ideas, but many of these look like they belong in existing documents
# [00:11] <fantasai> Florian: E.g. put rounded display MQ into the MQ spec
# [00:11] <fantasai> glazou: We could do that, or until things stabilize a bit more, keep them in a separate document
# [00:11] <fantasai> glazou: A partial solution is not enough for LG
# [00:12] <fantasai> glazou: So I think for the time being, keep it all into single editors draft, and as soon as they stabilize dispatch them.
# [00:12] <fantasai> glazou: Proposal is new ED with editor as LG
# [00:12] <fantasai> fantasai: Shortname?
# [00:12] <tantek> agreed with keeping it all together in a first editor's draft
# [00:12] <fantasai> roc: Might be good to have a spec for all of coordinate layout
# [00:12] <fantasai> roc: If it's not in a browser, then doesn't need to go through W3C
# [00:13] * Quits: lmclister______ (~sid13822@public.cloak) (Ping timeout: 180 seconds)
# [00:13] <fantasai> glazou: We have a way to say a spec is not required
# [00:13] <fantasai> roc: Could have the polyfillers sstandardize in a decentralized way
# [00:14] <fantasai> roc: CSSWG's expertise is useful, but that is also useful
# [00:14] <ChrisL> q+
# [00:14] * Zakim sees ChrisL on the speaker queue
# [00:14] <fantasai> glazou: LG is leading the effort, but it is clear that other vendors with rounded display watchs will have exactly the same issue
# [00:15] <fantasai> glazou: Application authors wanting to address these devices will want a standardized way to develop apps
# [00:15] <glazou> Zakim, ack ChrisL
# [00:15] <Zakim> I see no one on the speaker queue
# [00:15] <SteveZ> q+
# [00:15] * Zakim sees SteveZ on the speaker queue
# [00:15] <fantasai> ChrisL: W3C is about interop and getting people to work together. It's not about browsers only.
# [00:15] <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"
# [00:16] <fantasai> ChrisL: than they continue down
# [00:16] <fantasai> ChrisL: They've taken initiative to come here, we should reciprocate.
# [00:16] <fantasai> ...
# [00:16] <glazou> Zakim, ack SteveZ
# [00:16] <Zakim> I see no one on the speaker queue
# [00:16] <fantasai> SteveZ: First, there is a cost to doing this, which is it takes us time to review each of these specs
# [00:16] <glazou> glazou: and the expertise on CSS is here
# [00:16] <fantasai> SteveZ: not zero cost
# [00:16] <ChrisL> open source round display watch (failed kickstarter) https://www.kickstarter.com/projects/958981650/the-pi-watch-a-programmable-open-source-smartwatch
# [00:16] <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
# [00:17] <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
# [00:17] * dino RRSAgent, where?
# [00:17] <RRSAgent> I'm logging. Sorry, nothing found for 'where'
# [00:17] * dino RRSAgent, link
# [00:17] <RRSAgent> I'm logging. I don't understand 'link', dino. Try /msg RRSAgent help
# [00:17] * dino RRSAgent, link?
# [00:17] <RRSAgent> I'm logging. Sorry, nothing found for 'link'
# [00:17] <fantasai> SteveZ: It's good to discuss these so that we don't make it difficult to extend CSS in the future
# [00:17] * dbaron RRSAgent, pointer?
# [00:17] * RRSAgent See http://www.w3.org/2015/02/08-css-irc#T23-17-23
# [00:17] <Florian> q+
# [00:17] * Zakim sees Florian on the speaker queue
# [00:17] <tantek> q+
# [00:17] * Zakim sees Florian, tantek on the speaker queue
# [00:17] * dino grrr
# [00:17] <fantasai> SteveZ: I'm of the opinion that we should do the spec, and don't care how it's implemented
# [00:17] <glazou> Zakim, ack Florian
# [00:17] <Zakim> I see tantek on the speaker queue
# [00:18] <tantek> q+ to partially agree with SteveZ, and partially to encourage experimentation to learn from use-cases
# [00:18] * Zakim sees tantek on the speaker queue
# [00:18] * dino RRSAgent, here
# [00:18] * RRSAgent See http://www.w3.org/2015/02/08-css-irc#T23-17-52
# [00:18] <fantasai> Florian: Just as MQ spec editor, I just wnat to say I'm happy with either approach.
# [00:18] <glazou> Zakim, ack tantek
# [00:18] <Zakim> tantek, you wanted to partially agree with SteveZ, and partially to encourage experimentation to learn from use-cases
# [00:18] <Zakim> I see no one on the speaker queue
# [00:18] <fantasai> Florian: If you would like in MQ draft, would be happy to help
# [00:18] <ChrisL> q?
# [00:18] * Zakim sees no one on the speaker queue
# [00:18] <fantasai> tantek: Would partially agree with Steve's observation that our review is beneficial
# [00:19] <fantasai> tantek: Part of me also wants to see more rapid experimentation, even if solutions are imperfect
# [00:19] <glazou> q+
# [00:19] * Zakim sees glazou on the speaker queue
# [00:19] <fantasai> tantek: To use that to learn from the use cases
# [00:19] <fantasai> tantek: To experiment e.g. how do we get things to not overlap
# [00:19] <fantasai> tantek: Learning how prolbems occur in this kind oflayout is itself valuable
# [00:19] <fantasai> tantek: I want to avoid discouraging experimentation
# [00:19] <fantasai> tantek: Specifically avoid scenario of numerous webkit properties being thrown out there
# [00:19] <krit> q+
# [00:19] * Zakim sees glazou, krit on the speaker queue
# [00:20] <fantasai> tantek: without any discussion with WG
# [00:20] <fantasai> dirk: Do we have a way for extending MQ?
# [00:20] <fantasai> TabAtkins: yes
# [00:20] <fantasai> ChrisL: You can link thigs up by having a note in MQ pointing ot the other draft
# [00:20] <dbaron> ack krit
# [00:20] * Zakim sees glazou on the speaker queue
# [00:20] <krit> q-
# [00:20] * Zakim sees glazou on the speaker queue
# [00:20] <fantasai> glazou: This only raises one question about what we call an implementation
# [00:21] <fantasai> glazou: We shall now consider a polyfill as an implementation
# [00:21] <fantasai> ...
# [00:21] <fantasai> ChrisL: So you think the wording needs clarification that it qualifies
# [00:22] <roc> q+
# [00:22] * Zakim sees glazou, roc on the speaker queue
# [00:22] <fantasai> dbaron: I think that maybe requires more clarity bout which specs are expected to be implemented in browsers vs. polyfills
# [00:22] <fantasai> dbaron: polyfill should be a valid implementation for the latter type of spec
# [00:22] <fantasai> fantasai: I don't see why there needs to be a distinction
# [00:23] <fantasai> dino: How many browsers does it have to work in?
# [00:23] <zcorpan> q+
# [00:23] * Zakim sees glazou, roc, zcorpan on the speaker queue
# [00:23] <dbaron> ack roc
# [00:23] * Zakim sees glazou, zcorpan on the speaker queue
# [00:23] <fantasai> roc: Implementation in a browser uncovers more interaction problems, that a polyfill might not notice or might not even run into
# [00:23] <fantasai> Florian: As an answer to this, when we count a browser to continue passing previously-passing tests
# [00:24] <glazou> Zakim, ack glazou
# [00:24] <Zakim> I see zcorpan on the speaker queue
# [00:24] <fantasai> roc: The issue is with interaction of features, e.g. combine multico with X and it explodes
# [00:24] <fantasai> roc: Feature A and Feature B both work, but A+B explodes
# [00:24] * Joins: jdaggett (~jdaggett@public.cloak)
# [00:24] <dbaron> ack zcorpan
# [00:24] * Zakim sees no one on the speaker queue
# [00:24] * astearns combining tables and multicol, for instance :)
# [00:24] <fantasai> zcorpan: There are also different constraints between browser and polyfill
# [00:24] <glazou> Zakim, ack zcorpan
# [00:24] <Zakim> I see no one on the speaker queue
# [00:25] <glazou> hi jdaggett
# [00:25] <fantasai> zcorpan: A polyfill doesn't have t o care about optimization sin the browser, like the preloader
# [00:25] <fantasai> zcorpan: If it does all of its work after all the document is loaded
# [00:25] <jdaggett> glazou: morning!
# [00:25] <fantasai> zcorpan: A native implementation might want to do the work during parsing, when element is inserted into DOM
# [00:25] * Joins: vollick__ (~vollick@public.cloak)
# [00:25] <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
# [00:26] * dauwhe @page { size: circle(6in) }
# [00:26] <krit> q+
# [00:27] * Zakim sees krit on the speaker queue
# [00:27] <dino> q+ dino
# [00:27] * Zakim sees krit, dino on the speaker queue
# [00:27] <dino> q-
# [00:27] * Zakim sees krit on the speaker queue
# [00:27] <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
# [00:27] <fantasai> ...????
# [00:27] <dbaron> Florian: ???
# [00:28] <fantasai> ChrisL: Sounds like we had weak consensus on allowing polyfills as implementations, then discussed having polyfill-sepcific spec,...
# [00:28] <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.
# [00:28] <fantasai> ChrisL: You really odn't wnat to have to move around your code
# [00:28] <fantasai> ChrisL: we run into the prefixing issue again
# [00:28] <tantek> wow how did we descend in to details of polyfilling vs. process?
# [00:28] <fantasai> TabAtkins: Polyfilled properties are --foo anyway, so you have the prefixing built into the polyfilling
# [00:28] <fantasai> ...
# [00:29] <fantasai> heycam: standardized version in a browser isn't triggered by that property
# [00:29] <fantasai> dirk: We do not have custom layout
# [00:29] <fantasai> dirk: We have to dcide on this propsal right now. Very interesting discussion, but doesn't help LG right now
# [00:29] <krit> q-
# [00:29] * Zakim sees no one on the speaker queue
# [00:29] <fantasai> TabAtkins: Custom layout will be the hardest part of Houdinin, so a long time from now
# [00:29] <fantasai> TabAtkins: If ucstom layout existed today, mabye different approach, but doesn't exit right now
# [00:30] <fantasai> TabAtkins: Let's do this simple stuff
# [00:30] <fantasai> glazou: Sounds like return to LG, push other stuff to ML
# [00:30] <fantasai> Florian: What does LG want wrt splitting?
# [00:30] <fantasai> dirk: I thin kit should saty the same
# [00:30] <fantasai> glazou: I'd like to review that document
# [00:30] <dbaron> The part of the document I'm most concerned about is the polar coordinate layout bits.
# [00:31] <fantasai> glazou: New editors draft for this?
# [00:31] <fantasai> fantasai: I'm in favor
# [00:31] <tantek> +1 new editor's draft
# [00:31] <fantasai> tantek: me too
# [00:31] <fantasai> dbaron: I'm in favor, but I'm concerned about polar coordinates
# [00:31] <fantasai> fantasai: Yes, I think it needs work
# [00:31] * ChrisL looks forward to seeing the polar coordinate stuff
# [00:31] <fantasai> tantek: Decide on a place for issue to be capture, and ed to link to that
# [00:31] <fantasai> glazou: In the document
# [00:31] <fantasai> tantek: File issues and not block publication
# [00:32] <fantasai> Florian: send mail to www-style
# [00:32] <fantasai> ChrisL, glazou: Don't see how this is different from previous docs
# [00:32] <fantasai> tantek: ...
# [00:32] <fantasai> ChrisL: So you're encouraging use of that existing rule [ to indicate tracker ]
# [00:32] <tantek> Florian: this has nothing to do with sending email
# [00:32] <fantasai> [bikeshedding shortname]
# [00:32] <fantasai> css-round
# [00:32] <fantasai> css-rounded-display
# [00:33] <fantasai> Rossen: css-o
# [00:33] <dbaron> dbaron: it's a focused-enough specification that it should have a longer shortname
# [00:33] * dauwhe css-round-display
# [00:33] <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
# [00:33] <fantasai> +1 to css-roundisplay
# [00:33] <tantek> css-polar?
# [00:33] <ChrisL> +1
# [00:33] <fantasai> RESOLVED: Add css-round-display as ED
# [00:34] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [00:34] * ChrisL css-polar-bears
# [00:37] * liam glowers at ChrisL, having walked thorugh knee-deep snow today (avoiding waist-deep snow i can't walk through)
# [00:38] * Joins: johanneswilm (~johannes@public.cloak)
# [00:41] * Joins: estellevw (~estellevw@public.cloak)
# [00:42] * Joins: timeless (~sid4015@public.cloak)
# [00:43] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [00:45] * Quits: cyril (~cyril@public.cloak) (Ping timeout: 180 seconds)
# [00:48] * Joins: ojan (~sid5519@public.cloak)
# [00:49] <jdaggett> break?
# [00:49] <glazou> just ended, about to resume
# [00:50] * Joins: JonathanNeal_ (~sid5831@public.cloak)
# [00:51] <fantasai> Topic: CSS UI
# [00:51] <fantasai> tantek: In pretty good shape with CSS Ui
# [00:51] <tantek> https://wiki.csswg.org/spec/css3-ui#steps-to-pr
# [00:51] <fantasai> tantek: Set of steps to get to PR
# [00:51] * Joins: murakami (~murakami@public.cloak)
# [00:51] <fantasai> tantek: We're down to about 7 semi-substatial or substantial issues, resolutions on most of them
# [00:52] <fantasai> tantek: Steps to PR we've go tset of drafts to publish, one queued up
# [00:52] <fantasai> tantek: fixes to issue sat this meeting
# [00:52] <fantasai> tantek: Interest in testcases? spec is probably stable
# [00:52] <fantasai> tantek: features is stable, cutitng things, not adding things
# [00:52] <fantasai> ChrisL: Coudln't run the first test
# [00:52] * dauwhe glazou: do we have a phone bridge for jdaggett?
# [00:53] <fantasai> ChrisL: for directional navigation
# [00:54] * jdaggett ready whenever to dial in
# [00:54] <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
# [00:54] * heycam we need shans to come back to set up the phone
# [00:54] <glazou> jdaggett: we’ll set that up for next topic, css inline, ok,
# [00:54] * dbaron jdaggett, host is currently missing
# [00:54] <jdaggett> ah, ok
# [00:54] * ChrisL @liam scones and cream and good jam at the break
# [00:55] <tantek> Current issues: https://wiki.csswg.org/spec/css3-ui#current-issues
# [00:55] <fantasai> tantek: Issue 47
# [00:55] <fantasai> tantek: Objection from Tab to resolution, +1 from smfr
# [00:55] <tantek> https://wiki.csswg.org/spec/css3-ui#issue-47
# [00:56] <fantasai> tantek summarizes the issue
# [00:56] * Quits: thinkxl (~thinkxl@public.cloak) (Ping timeout: 180 seconds)
# [00:56] <fantasai> original spec talked about a "resize factor" that was maintained
# [00:56] <fantasai> implementations instead modify 'width/height' inline styles directly
# [00:57] <fantasai> tantek: downside of speccing that is that it limits how you handle e.g. resizing of the window by the user
# [00:57] <fantasai> tantek: You rob the author and user of having interfaces that dynamically resize in a sensible manner
# [00:57] <fantasai> tantek: Resolution at last telecon was to change "factor" to "function"
# [00:57] <fantasai> tantek: and allows for more intelligent resizing
# [00:58] <fantasai> tantek: The point here is t not restirct the web platform in ways that preven tit from being competitive with native platforms
# [00:58] <fantasai> tantek: That's the goal of sticking with the function wording, rather than rtificially restricting to style attrs
# [00:58] <fantasai> Florian: Current behavior with browsers does fall short where we could do better
# [00:59] <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
# [00:59] <fantasai> Florian: Also, I think it's reasonable to spec in adetailed way what is currently implemented, but also to extend it
# [00:59] <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"
# [01:00] <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
# [01:00] <SimonSapin> +1 Florian
# [01:00] <fantasai> Florian: Would rather spec what browsers are actually doing, and allow extending
# [01:00] <glazou> Dean also said +1
# [01:00] <dbaron> I think the underlying problem with 'resize' is that the feature was specified at the wrong layer of the platform (too low).
# [01:00] <AndreyR> +1
# [01:00] <fantasai> fantasai: What would would be worse than the current behavior?
# [01:01] <fantasai> Florian: ... not ineroperable
# [01:02] * ChrisL the group goes wild imagining worse things
# [01:02] <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)
# [01:02] <fantasai> dbaron: I think the underlying problem with this feautre is that it was designed at the wrong layer of the platform
# [01:02] <fantasai> dbaron: Was trying to hookinto low-level CSS width funcitons what should have been a hgher function
# [01:03] <fantasai> dbaron: It's a lot of work for something that shows up in hgh-evel controls
# [01:03] <fantasai> dbaron: Implementations proxy it down to a lower level, using what authors could use to do it
# [01:03] <fantasai> dbaron: reue their existing code rather than changing width/height computation for everything else in their codebase
# [01:03] <fantasai> dbaron: We have a legacy feature
# [01:04] <fantasai> dbaron: We should just spec it better
# [01:04] <zcorpan> q+
# [01:04] * Zakim sees zcorpan on the speaker queue
# [01:04] <fantasai> dbaron: And figure out a better way to have the feature that doesn't go poking in low-level CSS calculations
# [01:04] <fantasai> tantek: The intent was to keep it high-level from the start
# [01:04] <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
# [01:05] <fantasai> tantek: The factor was a possible case, generalize dto function
# [01:05] <fantasai> tantek: There seems to be that even that is specifying too much
# [01:05] <fantasai> TabAktkins: Not specifying enough
# [01:05] <fantasai> tantek: Goal was to make this a high-level feature for authors
# [01:05] <fantasai> tantek: Not sure what different approach could be takn
# [01:05] * Joins: TabAtkins (~sid11559@public.cloak)
# [01:06] <fantasai> Florian: What we have now is extensible
# [01:06] <fantasai> tantek: By specifying new values
# [01:06] <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
# [01:07] <fantasai> tantek: Should do the right thing by default
# [01:07] <fantasai> Florian: I have wording for the current interop behavior
# [01:07] <fantasai> Florian: Blink and webkit differ from FF in a couple cases
# [01:08] <fantasai> Florian: I propose to spec this and see if anyone disagrees
# [01:08] <fantasai> Florian: built up from tests
# [01:08] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [01:08] <fantasai> zcorpan: When and if we do come up with a successor of this feature, that can provide better behavior
# [01:08] <fantasai> zcorpan: I thin kit is good to not let the different browsers choose different behaviors for the same request from teh authors
# [01:08] <fantasai> zcorpan: bad if .e.g one browser uses pixels and other uses percents
# [01:09] <fantasai> fantasai: The author doesn't notice any problems or differences in behavior because they're designing in a single size
# [01:10] <fantasai> fantasai: The differences in behavior only show up when you resize the window
# [01:10] <fantasai> tantek: Resizing the window is pretty common *rotates his phone* This is resizing the window
# [01:10] * Joins: achicu_____ (~sid13301@public.cloak)
# [01:11] <fantasai> Tab, florian: You just resize it again.
# [01:11] <fantasai> tantek: If the sceen gets narrow I can't get to the resie handle
# [01:11] <fantasai> tab: scroll an resize again
# [01:11] <fantasai> [basically user has sucky experience because we have interop, and we don't give a shit]
# [01:11] <fantasai> tantek: You want to make the poor behavior a must?
# [01:12] * Quits: JonathanNeal_ (~sid5831@public.cloak) ("")
# [01:12] * Joins: JonathanNeal_ (~sid5831@public.cloak)
# [01:12] <JonathanNeal_> hola
# [01:12] * Joins: lmclister______ (~sid13822@public.cloak)
# [01:13] <fantasai> fantasai: So I don't unerstand the suggestions to create a new feature that does better
# [01:13] <fantasai> fantasai: Either you are happy with the existing behavior, or you want a better behavior.
# [01:13] <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
# [01:13] <fantasai> fantasai: The only reason to create a new feature rather than imprving the existing one is if you have a legacy problem
# [01:13] * heycam jdaggett: the phone will be set up the phone at the end of this css-ui discussion
# [01:14] <fantasai> fantasai: I don't think we have a legacy problem
# [01:14] <fantasai> s/problem/problem here
# [01:14] <jdaggett> heycam: thanks!
# [01:14] <fantasai> [...]
# [01:14] <fantasai> tabatkins: floating first letter is an example where we had bad behavior, couldn't improve it so made new feature
# [01:15] <fantasai> tantek: Did design methodology change?
# [01:16] <fantasai> ChrisL: Must is what you should say in all cases where you know what is the right hting to do
# [01:16] <fantasai> ChrisL: Should allows you to not o that if you have a good reason, but good reason is not defined
# [01:16] <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
# [01:17] <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
# [01:17] <fantasai> tantek: So if there was in implementation of resize of good behavior, we could put a should
# [01:17] <fantasai> SteveZ: Yes, and we could spe cthat particular one as a should
# [01:18] <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
# [01:18] <fantasai> tantek: My memory agrees with what steve was saying
# [01:18] <fantasai> tantek: I'm oky with speccing style attr in pixels, and nobody shows any intent to make it better.
# [01:19] <tantek> https://wiki.csswg.org/spec/css3-ui#issue-48
# [01:19] <fantasai> RESOLVED: spec sucky behavior because we have interop and nobody wants to make it better
# [01:19] <fantasai> Florian: cursor: auto is vaguely defined
# [01:20] <fantasai> RESOLVED: spec resize property to inject 'width/height' style attr values in pixels
# [01:20] <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.
# [01:20] <fantasai> tantek: We had a group discussio non auto cursor, to try to restrict auto value as much as possible
# [01:20] <fantasai> tantek: define specifics instead
# [01:20] <fantasai> tantek: issue wrt resze areas and scollbars
# [01:20] <fantasai> tantek: proposal handles this, but may need additional wording
# [01:21] <dbaron> though I still don't know how resizing the old way would interact with something like flexbox
# [01:21] <fantasai> Florian: dbaron's original proposal of switching between switching between text vs. default
# [01:21] <dbaron> (old way being as a resize factor)
# [01:21] <fantasai> Florian: either out of scope for CSS, or expressable in a UA style sheet
# [01:21] * fantasai that's why it's function
# [01:21] * fantasai asked for that change
# [01:22] <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
# [01:22] <fantasai> Florian: You can do magic over links for auto, but don't have to
# [01:22] <fantasai> Florian: The only thing that needs to be magic inside auto is text vs. empty space
# [01:23] <fantasai> ChrisL: Should we have some way to know whether you're empty space or text
# [01:23] <fantasai> tantek: Don't have a way to detect scrollbars or ersize handlers either
# [01:23] <fantasai> Florian: We don't have a ::cursor pseudo
# [01:23] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [01:23] <fantasai> ChrisL: So proposal is to have auto switch between 'default' and 'text' base don whether you're over text
# [01:24] <fantasai> tantek: and text already hadles horizontal vs vertical text cursors
# [01:24] <fantasai> ChrisL: what about links?
# [01:24] <fantasai> Florian: You hae a ua style rule for that
# [01:25] <fantasai> zcorpan: If you specify auto on a link, then you get a text cursor
# [01:25] <fantasai> zcorpan: html style sheet requires UA to specify pointer on links
# [01:25] <fantasai> tantek: Possible regression if people have written * { cursor: auto; }
# [01:25] <fantasai> Florian: Matches what firefox does, webkit does more magic
# [01:25] <fantasai> RESOLVED: auto cursor switches between default/text whether you're over text. No other magic
# [01:26] <tantek> Issue 55: https://wiki.csswg.org/spec/css3-ui#issue-55
# [01:26] * trackbot doesn't understand that ISSUE command.
# [01:26] <fantasai> Topic: outline
# [01:26] <fantasai> Florian: Simple cases, everyone understands outline, but aside from that there's no interop
# [01:26] <fantasai> Florian: Not possible to spec it all in Level 3 timeframe
# [01:26] <fantasai> Florian: Would like group to sanction having a very loose spec for outline in L3
# [01:27] <fantasai> tantek^: In some cases we can't spec
# [01:27] <AndreyR> agree
# [01:27] <fantasai> Florian: And clarify in L4
# [01:27] * Joins: jumland (~sid26952@public.cloak)
# [01:27] <fantasai> Florian: E.g. what do you do if element is tranformed? Do you transform the outline or not?
# [01:27] <fantasai> Florian: If children overflow, do you extend outline to include them? Is the outline a rectange or weird shape in that case?
# [01:28] <fantasai> tantek: Contrary to resize, this is a feature wher we've seen a lot of innovation in browsers
# [01:28] <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
# [01:28] <fantasai> tantek: We've sene some nice stuff, and want to see what hte market comes up with
# [01:29] <fantasai> tantek: issue 55 and 51 close as no change
# [01:29] <fantasai> fantasai: agree with closing 55
# [01:29] <fantasai> Florian: 51 is transforming outline
# [01:29] <fantasai> fantasai: If you have interop on something you don't want, then need to speak up about it
# [01:29] <AndreyR> no obj
# [01:30] <fantasai> ...
# [01:30] * Joins: nikos (~uid28403@public.cloak)
# [01:30] <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
# [01:31] <ChrisL> fantasai: whether it rounds on radius, z-inex
# [01:31] * ChrisL missed the first one
# [01:31] <ChrisL> s/inex/index
# [01:31] <fantasai> fantasai: I'm concerned that if you don't deal with this now, you'll end up not having a choice
# [01:31] <ChrisL> fantasai: you need to address hte transform issue
# [01:32] <ChrisL> ... must do it now or its too late
# [01:33] <ChrisL> ... do we want to transform the outline or not
# [01:33] * ChrisL does not minute the self flagellation
# [01:33] <fantasai> fantasai: would like to know what other people think, because my opinion is completely worthless here
# [01:33] <fantasai> dbaron: If you're in a 3d schene, there isn't necessarily a decent definition of what era is covered by your children
# [01:34] <fantasai> Florian: If you wnat outline to be a focus indicator, you put outline around the projected result
# [01:34] <fantasai> Florian: We haven't specified this
# [01:34] <tantek> 52: https://wiki.csswg.org/spec/css3-ui#issue-52
# [01:34] <fantasai> dbaron; Think we can't specify now
# [01:34] <fantasai> tantek: Objections?
# [01:34] <fantasai> RESOLVED: Don't specify anything for how outline sactually work other than what's there already
# [01:35] * dauwhe da mihi interop, sed noli modo
# [01:35] <fantasai> tantek: No interop on pseudo-elements
# [01:35] <fantasai> tantek: Suggest to say that they don't apply to pseudo-elements
# [01:35] * Joins: nduca (~uid66241@public.cloak)
# [01:36] <fantasai> Florian: I don't think you can say that it does not apply and then make it apply later
# [01:36] <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
# [01:36] <fantasai> tantek: proposal is resize doesn't apply to pseudos, and add a note that it may apply in the future
# [01:37] <fantasai> fantasai: Wouldn't say where it's going to be solved, just say it may be solved in the future
# [01:37] <fantasai> RESOLVED: resize doesn't apply to pseudos. Note that this may change in the fuutre
# [01:38] <tantek> https://wiki.csswg.org/spec/css3-ui#issue-68
# [01:38] <fantasai> Florian: Initial version of text overflow required overfow ~= visible and line would overflow its containing block
# [01:39] <fantasai> Florian: This is unfortunate if you have a float in the way. You'd overlap the float
# [01:39] <fantasai> Florian: spec is changed to elide before the float
# [01:39] <fantasai> Florian: Which is what Webkit does
# [01:39] <fantasai> tantek: Suggestion to reuqest that text-overfow apply even when overflow is visible
# [01:39] <fantasai> rossen: prolematic
# [01:40] <tantek> I think generalizing to regardless of overflow value is too big of a change
# [01:40] <fantasai> rosen: What would a block with text-overflow: ellipsis would report for its main content size, if all lines are llipsized?
# [01:40] <fantasai> fantasai: text-overflow does not affect sizing
# [01:40] <fantasai> ...
# [01:41] <fantasai> Florian: What was specced was firefox's behavior. now specced webkit's behavior.
# [01:41] <fantasai> Florian: Firefox also asked for not requiring the overflow rule
# [01:41] * glazou time in 4 minutes
# [01:41] <fantasai> tantek: We dont' have an implementation yet, though
# [01:41] <AndreyR> agree with Tantek
# [01:42] <tantek> fantasai: main concern I have with the overflow issue is web compat
# [01:43] <fantasai> RESOLVED: leave spec as-is, don't apply text-overflow when overflow: visible
# [01:43] <tantek> https://wiki.csswg.org/spec/css3-ui#issue-76
# [01:44] <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
# [01:44] <fantasai> tantek: Seems like a reasonable request, not sure if anyone would ever do it, so I put it in as a may
# [01:44] <fantasai> tantek: One request ot revert it
# [01:44] <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
# [01:44] <fantasai> tantek: Proposal is to ellipse at a word boundary, line-wrapping opportunity
# [01:45] <fantasai> Florian: I have a few probems with this problems
# [01:45] <fantasai> Florian: What looks better depends a lot on the context
# [01:45] <tantek> dino: we would do that, ellipse at a line-wrap opportunity
# [01:45] <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
# [01:45] <fantasai> TabAtkins: Ellipsis is visual
# [01:46] <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
# [01:46] <fantasai> Florian: Another isue is scrolling. If you scroll, upposed to reveal more content as you go
# [01:46] <fantasai> Florian: really weird to dro pin word sas you scroll
# [01:46] * fantasai q+
# [01:46] * Zakim sees zcorpan, fantasai on the speaker queue
# [01:46] <fantasai> tantek: Behvior for scrolling is already looser than wording for not scrolling
# [01:47] <tantek> fantasai: I disagree with this change, if you want this change it should be a separate property and/or keyword
# [01:47] <tantek> … to allow ellipsing at a word / line-wrap opportunity
# [01:47] <zcorpan> q-
# [01:47] * Zakim sees fantasai on the speaker queue
# [01:48] <zcorpan> Zakim, ack fantasai
# [01:48] <Zakim> I see no one on the speaker queue
# [01:48] <fantasai> RESOLVED: Drop wording allowing word-drops, add as a new feature in L4 e.g. as a new keyword or something
# [01:49] <glazou> Zakim, room for 3?
# [01:49] <dbaron> Zakim, room for 3?
# [01:49] <Zakim> ok, glazou; conference Team_(css)00:49Z scheduled with code 26631 (CONF1) for 60 minutes until 0149Z
# [01:49] <Zakim> dbaron, an adhoc conference was scheduled here less than 2 minutes ago
# [01:49] <dbaron> jdaggett, ^
# [01:50] <jdaggett> dbaron: got it
# [01:50] <Zakim> Team_(css)00:49Z has now started
# [01:50] <Zakim> + +61.2.956.6.aaaa
# [01:50] <Zakim> +[IPcaller]
# [01:51] <jdaggett> ok, muted
# [01:51] <jdaggett> zakim, +ipcaller is me
# [01:51] <Zakim> sorry, jdaggett, I do not recognize a party named '+ipcaller'
# [01:51] <dbaron> Zakim, aaaa is MeetingRoom
# [01:51] <Zakim> +MeetingRoom; got it
# [01:51] <jdaggett> zakim, +[IPcaller] is me
# [01:51] <Zakim> sorry, jdaggett, I do not recognize a party named '+[IPcaller]'
# [01:51] * heycam [IPCaller] is jdaggett
# [01:51] <dbaron> Zakim, [IPcaller] is jdaggett
# [01:51] <Zakim> +jdaggett; got it
# [01:51] <heycam> Zakim, [IPCaller] is jdaggett
# [01:51] <Zakim> sorry, heycam, I do not recognize a party named '[IPCaller]'
# [01:52] <heycam> Zakim, you have a short memory
# [01:52] <Zakim> I don't understand 'you have a short memory', heycam
# [01:52] <jdaggett> hehe
# [01:52] <fantasai> Topic: CSS Inline
# [01:52] <fantasai> dauwhe: Wanted to go over some issues with inital letters
# [01:52] <fantasai> dauwhe: Then wanted to review css-linebox stuff
# [01:53] <fantasai> dauwhe: Florian raised various issues, here's the first one
# [01:53] <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
# [01:53] <fantasai> dauwhe: but don't want to do that for CJK
# [01:54] <fantasai> [sending slides over]
# [01:54] <fantasai> SteveZ: There are examples where you want to kern the second line as well
# [01:55] <fantasai> SteveZ: You want to follow the shape of the outline
# [01:55] <fantasai> dauwhe: We do want that, but the full effect of that would be the next level
# [01:55] <fantasai> SteveZ: By specifying what your'e doing, you screw up the extension
# [01:55] * liam zakim, call liam-617
# [01:55] * Zakim ok, liam; the call is being made
# [01:55] <Zakim> +Liam
# [01:55] * ChrisL sadface, got a virus injecting adds & trackers on w3c team only pages
# [01:56] * liam zakim, mute liam
# [01:56] * Zakim Liam should now be muted
# [01:56] * glazou ChrisL uuuuuhhhh ?
# [01:56] * liam notes "wrong" is a difficult word in graphic design
# [01:57] * liam q+ to note some technology made it hard or impossible to get "right"
# [01:57] * Zakim sees liam on the speaker queue
# [01:57] <jdaggett> is this discussion about the illustration in 2.9? http://dev.w3.org/csswg/css-inline/#initial-letter-position
# [01:57] <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
# [01:57] * fantasai yes
# [01:57] <glazou> liam: shoot
# [01:58] <fantasai> fantasai: We're not going to allow various behaviors, have to define one or the other, shouldn't be up to the UA
# [01:58] <glazou> Zakim, unmute liam
# [01:58] <Zakim> Liam should no longer be muted
# [01:58] <fantasai> SteveZ: ...
# [01:58] <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
# [01:58] <fantasai> ...
# [01:59] <fantasai> jdaggett: It think this is a feature that needs more work
# [01:59] * tantek notes the irony of a visual discussion among people on the phone.
# [01:59] <liam> [not good - there were technological limitations in the past]
# [01:59] <fantasai> jdaggett: e.g. distance from glyph outline to text needs to be controllable
# [02:00] <heycam> jdaggett, slides here: https://lists.w3.org/Archives/Public/www-archive/2015Feb/0004.html
# [02:00] <fantasai> fantasai: I think for controlling the distance you can use the padding/margin on that side of the glyph
# [02:01] <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
# [02:01] <dbaron> I actually haven't found examples of follow-the-curve.
# [02:01] * liam notes dbaron isn't reading sufficiently curvaceous magazines
# [02:01] <Zakim> -Liam
# [02:01] * liam zakim, drop liam
# [02:01] * Zakim sorry, liam, I do not see a party named 'liam'
# [02:01] <tantek> I found examples of follow-the-curve plenty over a decade ago
# [02:02] * liam zakim, call liam-617
# [02:02] * Zakim ok, liam; the call is being made
# [02:02] <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.
# [02:02] <Zakim> +Liam
# [02:02] <tantek> q+
# [02:02] * Zakim sees liam, tantek on the speaker queue
# [02:02] <fantasai> fantasai: If you want a rectangle, you can add a transparent border
# [02:02] * liam suspects snow + wind are causing phone problems here
# [02:02] * liam q-
# [02:02] * Zakim sees tantek on the speaker queue
# [02:02] <fantasai> s/use the padding/use the
# [02:03] <fantasai> SteveZ: issue is should the kerning apply only on the top example, the rectangular one, or should it apply
# [02:03] <astearns> http://graphicdesign.stackexchange.com/questions/10561/text-wrap-in-illustrator-cs6
# [02:03] <fantasai> SteveZ: What should be tehd efault
# [02:04] <fantasai> fantasai: the way it works right now is that you only do this kerning if you have marigns but not borders or padding
# [02:05] <tantek> q?
# [02:05] * Zakim sees tantek on the speaker queue
# [02:05] <fantasai> fantasai: we took the marign collapsing principle that the edges of the box are permeable if padding/border is zero
# [02:05] <fantasai> fantasai: So you can get both behaviors
# [02:05] <fantasai> fantasai: And I thin kthe model is fairly consistent
# [02:05] <fantasai> [argument over which is more common, clearly not clear]
# [02:05] <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.
# [02:06] <fantasai> fantasai: You can add margins if you want more spacing, you can add spacing if you want rectangularness
# [02:07] * liam q+ to not it can be implemented just using kerning tables
# [02:07] * Zakim sees tantek, liam on the speaker queue
# [02:07] <fantasai> dauwhe: We could defer if necessary for implementations
# [02:07] <fantasai> fantasai: I would prefer to try for this
# [02:07] * zcorpan the small mics should be held at least 10cm away from the mouth
# [02:07] <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)
# [02:07] <fantasai> fantasai: and you need an offset control, which is provided by margin
# [02:08] <fantasai> tantek talks about full wrapping
# [02:08] <fantasai> dauwhe: Case #3 is much more common and simple, prefer to defer it
# [02:08] <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
# [02:08] <fantasai> Florian: I think the model is very sane.
# [02:09] <fantasai> SteveZ: My concerns weren't that case #3 isn't deirable, but worried about separating case #3 and full kerning
# [02:09] <fantasai> SteveZ: Want to see how it interacts with full kerning
# [02:09] <fantasai> tantek: I'd like to see what full kerning would look like, an dinclude it in teh draft now, before cutting it
# [02:09] <fantasai> dauwhe: I'm okay, if that's where we want to go
# [02:10] <jdaggett> q+
# [02:10] * Zakim sees tantek, liam, jdaggett on the speaker queue
# [02:10] <fantasai> Liam, tantek, Szilles, fantasai agree on this approach
# [02:10] * liam q-
# [02:10] * Zakim sees tantek, jdaggett on the speaker queue
# [02:10] <fantasai> liam: As an implementer, think it's good to have all possibilities there, will help to organize your code appropriately
# [02:11] <tantek> q-
# [02:11] * Zakim sees jdaggett on the speaker queue
# [02:11] <tantek> ack jdaggett
# [02:11] * Zakim sees no one on the speaker queue
# [02:11] <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
# [02:11] <fantasai> jdaggett: because you're looking at the glyph outline
# [02:11] <fantasai> jdaggett: Wouldn't imagine that a mobile browser wants to do that
# [02:12] <fantasai> dauwhe: Wouldn't it make sense to include this and then react to implementation experience later
# [02:12] <fantasai> jdaggett: I think this should be opt-in behavior
# [02:12] <fantasai> tantek: I think some impls have motivation to do high-fidelity rendering
# [02:12] <fantasai> tantek: You mention mobile, I thin that's a top use case
# [02:12] <fantasai> jdaggett: I don't think it's universally true that his is the optimal thing
# [02:12] <fantasai> jdaggett: It depends on the use case
# [02:13] * Quits: stryx` (~stryx@public.cloak) (Ping timeout: 180 seconds)
# [02:13] <fantasai> jdaggett: The behavior of margins vs. padding is confusing to authors
# [02:13] * sgalineau could following the outline be a special shape-outside switch? first line kerning seems more common
# [02:13] <fantasai> dbaron: I agree that doing this based on padding/border being set is confusing
# [02:13] <fantasai> dbaron: Odd implicit thing that people won't get
# [02:14] <fantasai> dauwhe: full kerning would need another switch
# [02:14] <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
# [02:14] <SteveZ> +1 for borders and padding being confusing in this case
# [02:14] * Joins: stryx` (~stryx@public.cloak)
# [02:15] <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
# [02:15] <liam> +1 add and solicit more feedback
# [02:15] <tantek> +1
# [02:15] <fantasai> dauwhe: Florian brought up issue of what if initial letter is a different script than the surrounding text.
# [02:16] <fantasai> dauwhe: Conclusion is you use the top alignment point of each script and the bottom alignment poitn of each script
# [02:16] <tantek> q+ to ask about leading quote
# [02:16] * Zakim sees tantek on the speaker queue
# [02:16] <fantasai> dauwhe: E.g. A inside indic script shows cap-height to hanging-example, alphabetic to alphabetic
# [02:16] <fantasai> dauwhe: Florian has an example of this
# [02:16] <fantasai> Florian: Chinese-english dictionary
# [02:17] <fantasai> RESOLVED: Choose alignment points as described above
# [02:17] <fantasai> dauwhe: Next issue is run-in
# [02:17] <fantasai> Florian: Combination of run-in and :first-letter
# [02:17] <fantasai> Florian: Having ::first-letter select the first letter of the original text seems very weird
# [02:18] <fantasai> Florian: Makes more sense to select the first letter including the run-in
# [02:18] <fantasai> Florian: Should either select that or select nothing
# [02:19] <fantasai> tantek: I lean towards selecting nothing, the author can select the first letter of the run-in
# [02:19] <fantasai> dbaron: Does ::first-letter apply to run-ins? I don't think it does.
# [02:19] <Florian> example of mixed scripts http://florian.rivoal.net/csswg/cn-en_raised-cap_shed.jpg
# [02:19] <tantek> but it could
# [02:19] <tantek> ::first-letter *could* apply to something with display:run-in
# [02:21] <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
# [02:21] <fantasai> fantasai: So I'm not sure we can have ::first-letter apply to run-ins.
# [02:21] * liam not sure how you would achieve the illustration if :first-letter doesn't apply to Ronin
# [02:21] <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
# [02:21] <fantasai> fantasai: Although I'm not a box-construction expert, so I don't know if that's sane.
# [02:22] <dbaron> What decision are we trying to make right now?
# [02:23] <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
# [02:24] <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
# [02:24] * ChrisL first-letter is a property of master, so clearly as ronin are masterless then .....
# [02:24] <fantasai> SteveZ: Off-topic: the example on the screen is aligne dto the x-height, not the cap-height
# [02:25] <fantasai> dauwhe: The box aligns to the alignment points, it has padding and a background
# [02:25] <fantasai> Discussion moved ot ML
# [02:25] * glazou notes dauwhe ’s example in french isn’t right and that the capital E should have had an acute accent...
# [02:25] <fantasai> dauwhe: We had a discussion wrt floats and initial letter
# [02:25] * fantasai notes that sometimes ppl drop that even though it's not technicaly correct
# [02:26] * liam whispers to glazou it might be OK in Quebec :-)
# [02:26] <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
# [02:27] * glazou fantasai: I noted it gets more and more omitted in sans-serif fonts ; it’s still present in serif fonts… at least in fr-FR, liam will clarify for fr-CA :-)
# [02:27] * glazou « Électricité de France » and « Éducation Nationale »
# [02:27] <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.
# [02:28] * liam would not dream of it :)
# [02:28] <fantasai> Florian: [to steve] that proposal would introduce a loop in the layout that doesn't exist
# [02:28] <astearns> I think line 1 should be fine, floats in lines 2+ should clear
# [02:28] <fantasai> SteveZ: No it doesn't , it alrady exists
# [02:29] <dbaron> The static on the audio system is really getting on my nerves.
# [02:29] * astearns +1 to being distracted by static
# [02:29] * liam zakim, mute liam
# [02:29] * Zakim Liam should now be muted
# [02:29] * liam does tha thelp?
# [02:29] * astearns unfortunately no
# [02:29] * liam zakim, who is noisy?
# [02:30] * Zakim liam, listening for 10 seconds I could not identify any sounds
# [02:30] * liam thinks it usually helps if I stop talking :-) :-)
# [02:30] <fantasai> [discussion about whether floats moving up creates a problem]
# [02:30] * fantasai gives up trying to minute
# [02:31] <fantasai> Rossen: Do you expect your proposed algorithm to work for only left floats?
# [02:31] <fantasai> SteveZ: yes
# [02:31] <fantasai> Rossen: Then you're proposal only affects one side of floats
# [02:32] <fantasai> dbaron: We only have a problem on ths side of the initial letter
# [02:32] <Zakim> -Liam
# [02:32] <fantasai> dbaron: And I don't belive steve. There's a problem.
# [02:32] <fantasai> fantasai: Does anyone other than Steve think ther eis not a problem?
# [02:33] <fantasai> [silence]
# [02:33] <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
# [02:33] <fantasai> next slide
# [02:33] <fantasai> dauwhe: Want the ability to position the box as a whole including borders padding backgrounds
# [02:34] <fantasai> dauwhe: florian suggested that we use box-sizing to deterine whether you align the letter or the box
# [02:34] <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
# [02:35] <fantasai> Florian: The initial letter-align property says which set of baselines to use
# [02:35] <fantasai> Florian: Must speak eithe rof the ltter or the box
# [02:35] <fantasai> Florian: If you're aligning a box, the baseline values mean nothing
# [02:36] <fantasai> Florian: Other values were aobut vertical centering of box once you have the box or something
# [02:36] * liam will try calling back in a few minutes
# [02:36] <fantasai> Florian: We could have a different property for this switch
# [02:36] <fantasai> Florian: The nice thing about box-sizing is that...
# [02:36] * fantasai didn't understand
# [02:36] <fantasai> astearns: it made a lot of sense to have hsape-outside key off of box sizing
# [02:37] <fantasai> astearns: but we were eventually convinced that having that conflation of concerns for box-sizing was something to avoid
# [02:37] <fantasai> astearns: and that's why we put the keyword into the shape keyword itself
# [02:37] * dbaron Zakim, who is on the phone?
# [02:37] * Zakim sees on the phone: MeetingRoom, jdaggett
# [02:37] <fantasai> fantasai: Why not use initial-letter-align?
# [02:37] <tantek> topic?
# [02:37] <tantek> (is there a URL)
# [02:37] <fantasai> Florian: What does padding do if you don't have this?
# [02:38] <fantasai> Florian: Why not use box-sizeing, since we've changed what we're using box sizing
# [02:38] <fantasai> fantasai: People put box-sizing on everything today, to make it border-box
# [02:38] * dbaron Zakim, who is noisy?
# [02:38] * Zakim dbaron, listening for 13 seconds I heard sound from the following: MeetingRoom (60%)
# [02:39] <fantasai> Florian: Then by default in those pages you will align the border box
# [02:39] <fantasai> ...
# [02:40] <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)
# [02:40] <fantasai> dauwhe: but it is definitely not correct
# [02:40] <fantasai> dauwhe shows example
# [02:40] <fantasai> dauwhe: You get very unrealistic results, don't seem to match examples i've seen
# [02:40] <fantasai> dauwhe: because this alignment point is not a visible thing in the font
# [02:40] <fantasai> dauwhe: The bototm alignment point in these scripts is in fact the alphabetic baseline
# [02:41] <fantasai> dauwhe: Matches much more closely to real examples, and to things we can see in the fonts
# [02:41] * Quits: vollick__ (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [02:41] <fantasai> dauwhe: Still have lots of questions about CJK
# [02:41] <fantasai> dauwhe: The top exampel here is Hebrew
# [02:41] <fantasai> dauwhe: One problem with Hebrew is that the font metrics don't seem to have a natural alignment point
# [02:41] <fantasai> dauwhe: There's a strong vetical rhythm along the top of the characters
# [02:41] <fantasai> dauwhe: there is a probable top alignment point there
# [02:42] <fantasai> dauwhe: but ti's not an existing metfic. It's not the x-height, or cpa-height
# [02:42] <fantasai> dauwhe: Not what issue that raises for this
# [02:42] <fantasai> dauwhe: In the case of Arabic I have no clue
# [02:42] <fantasai> fantasai: I think the character you want to align to is the alef
# [02:43] <fantasai> fantasai: the top of the first letter at the begining of your example
# [02:43] <fantasai> lam has the same height (normally)
# [02:43] * Rossen is now known as Rossen_away
# [02:43] <fantasai> dauwhe: projects a table of alignment points
# [02:43] <fantasai> dauwhe: myth of hanging baseline
# [02:43] <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
# [02:44] <fantasai> dauwhe: And most software doesn't actually use the hanging baseline
# [02:44] <fantasai> dauwhe: They're not even sure if hangin base line is what happens in these scripts
# [02:44] <fantasai> dauwhe: Here's some example sof characters i vastly different size
# [02:44] <fantasai> dauwhe: What happens in every implementation I'm aware of is alignment at alphabetic baseline
# [02:44] <fantasai> dauwhe: Looking at CKJ, lots of options in indesign
# [02:44] * liam zakim, call liam-617
# [02:44] * Zakim ok, liam; the call is being made
# [02:44] <Zakim> +Liam
# [02:44] <fantasai> dauwhe: Lots of questions about that
# [02:45] <fantasai> dauwhe: And that's the intro to the next bit, the rest of CSS inline
# [02:45] <fantasai> dauwhe: Wanted to ge ta sense of what that needs to include
# [02:45] <fantasai> dauwhe: What needs to change from CSs2.1?
# [02:45] <fantasai> dauwhe: Do we really need to define 20 kinds of baselines?
# [02:45] * heycam is now known as heycam|away
# [02:45] <fantasai> dauwhe: To match bottom ideographic char frame with mathemtaic baseline???
# [02:45] <fantasai> jdaggett: I think we have some issue with inter-group issue
# [02:46] <fantasai> jdaggett: SVG has a bunch of stuff taken from XSL
# [02:46] <fantasai> jdaggett: dominant-baseline and various properties
# [02:46] <fantasai> jdaggett: huge number of values
# [02:46] <fantasai> jdaggett: Some people say this is a compat issue
# [02:46] <ChrisL> dominant baseline stuff was copied from xslt yes and needs to be cleaned up
# [02:46] <fantasai> jdaggett: But need to coordinate with SVG to see who's going to do what
# [02:46] <fantasai> jdaggett: Dunno what's actually implemented
# [02:46] <fantasai> jdaggett: properties are parsed, but what's implemented?
# [02:46] <fantasai> dauwhe: Yes, curious about what's happening in the wild
# [02:47] <fantasai> SteveZ: I was going to ask, in the indic example you have there,
# [02:47] <jdaggett> example: http://mxr.mozilla.org/mozilla-central/source/layout/svg/SVGTextFrame.cpp#328
# [02:47] <fantasai> SteveZ: It's what browsers do today, but certainly not what happens in print
# [02:47] <murakami> s/xslt/XSL-FO/
# [02:47] <fantasai> SteveZ: They do use that in print
# [02:47] <jdaggett> gecko dominant-baseline implementation
# [02:47] <fantasai> dauwhe: I haven't actually seen an example of mixed-text sizes in the real world, other than drop-caps
# [02:48] <fantasai> jdaggett: I think we have to temper things with actual data that we get from fonts
# [02:48] * liam would guess Michael of RenderX would have actual real examples
# [02:48] <fantasai> jdaggett: We have to be careful of using theoretical models of what different baselines exist theoretically vs real world font metrics
# [02:48] <fantasai> dauwhe: Yeah, I don't belive anything until I can read it out fo the font metric
# [02:48] <fantasai> SteveZ: That leave syou with real problem with Hebrew then
# [02:49] <fantasai> SteveZ: Sounds like you're going to end up synthesizing font metrics that you need
# [02:49] <fantasai> SteveZ: Existing font metric principle won't work
# [02:49] <fantasai> dauwhe: It's a starting point, not an ending point
# [02:50] <fantasai> dauwhe: Shoudl we move forward?
# [02:50] <fantasai> fantasai: Yes, even hav some exisitng resolutions on what to add
# [02:50] <fantasai> jdaggett: Lots of stuff from SVG, XSL, don't want to add
# [02:50] <fantasai> fantasai: Yeah, don't wnat to copy from XSL
# [02:51] <fantasai> SteveZ: Text align had made some assumptions, so XSL was to make vertical-align be a shortcut
# [02:51] <fantasai> s/text align/vertical align/
# [02:51] * TabAtkins JonathanNeal_ We're in the middle of a CSSWG face-to-face meeting.
# [02:51] * TabAtkins tests
# [02:51] <fantasai> SteveZ: Wnated to place thing,s not just glyphs, but also images
# [02:52] <fantasai> SteveZ: The list of baelines is unimportant. There was some set that was useful that you might get at.
# [02:52] <fantasai> RESOLVED: lunch
# [02:52] <glazou> <br type=‘lunch’>
# [02:52] <Zakim> -jdaggett
# [02:52] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [02:52] * liam eating dinner :)
# [02:53] * liam zakim, drop liam
# [02:53] * Zakim Liam is being disconnected
# [02:53] <Zakim> -Liam
# [02:53] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [02:53] * Joins: Florian (~Florian@public.cloak)
# [02:53] <Zakim> -MeetingRoom
# [02:53] <Zakim> Team_(css)00:49Z has ended
# [02:53] <Zakim> Attendees were +61.2.956.6.aaaa, MeetingRoom, jdaggett, Liam
# [02:54] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [02:58] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [02:59] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [02:59] * Quits: xidorn (~upsuper@public.cloak) (Ping timeout: 180 seconds)
# [03:09] * Joins: adenilson (~anonymous@public.cloak)
# [03:11] * Quits: tantek (~tantek@public.cloak) (tantek)
# [03:24] * heycam|away is now known as heycam
# [03:34] * Joins: xidorn (~upsuper@public.cloak)
# [03:36] * Joins: dauwhe (~dauwhe@public.cloak)
# [03:36] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [03:36] * Joins: dauwhe (~dauwhe@public.cloak)
# [03:37] * Joins: estellevw (~estellevw@public.cloak)
# [03:44] * Joins: johanneswilm (~johannes@public.cloak)
# [03:45] * Quits: shepazu (schepers@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
# [03:46] <JonathanNeal_> TabAtkins: awesome
# [03:46] * Joins: murakami (~murakami@public.cloak)
# [03:47] * Quits: smfr (~smfr@public.cloak) (smfr)
# [03:54] * Joins: Florian (~Florian@public.cloak)
# [03:54] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [03:54] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [03:56] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [03:56] * Joins: Florian (~Florian@public.cloak)
# [03:57] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [03:58] * Joins: tantek (~tantek@public.cloak)
# [04:02] * Joins: shepazu (schepers@public.cloak)
# [04:06] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [04:08] <fantasai> Topic: Page Floats
# [04:09] <JonathanNeal_> I hope you all expose more CSS power to JavaScript for polyfilling.
# [04:09] * Quits: JonathanNeal_ (~sid5831@public.cloak) ("")
# [04:09] * Quits: murakami (~murakami@public.cloak) ("Page closed")
# [04:09] <fantasai> ?: Currently spec is unmaintained
# [04:09] * Joins: murakami (~murakami@public.cloak)
# [04:10] * Joins: tantek (~tantek@public.cloak)
# [04:10] <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
# [04:10] <fantasai> ?: Right now spec that exists for it has Håkon as editor, and hasn't been working on it
# [04:10] <fantasai> ?: Contains page floats, but also exclusions, regions, etc. thatothers are working on
# [04:10] <fantasai> ?: Proposing for me to join the eidtorial team for this spec
# [04:10] <glazou> s/?/johanneswilm
# [04:10] <fantasai> tantek: Did you talk to hwocome about it?
# [04:11] <fantasai> johanneswilm: Will try to engage with him, and everyone in print sector e.g. AH, PrinceXML, vivliostyle
# [04:11] <fantasai> johanneswilm: Our goal is to create a JS polyfill to get this functionality in browsers
# [04:11] <fantasai> johanneswilm: Getting browsers to implement was not successful
# [04:12] <fantasai> dino: Printing might be a narrow use case, but books are not
# [04:12] <zcorpan> i think håkon now maintains https://books.spec.whatwg.org/
# [04:12] <fantasai> johanneswilm: Dunno why it wasn't implemented
# [04:12] * Quits: jaredwy (~uid2122@public.cloak) ("Connection closed for inactivity")
# [04:12] <fantasai> fantasai: Because it's vastly underspecified
# [04:12] <fantasai> Rossen_away: You mentioned a bunch of things
# [04:12] <fantasai> Rossen_away: What exactly did you want to take over, just page floats? Exclusions? Something else?
# [04:12] <fantasai> johanneswilm: This is CSS Page Floats. We think that's what it should be about.
# [04:12] <fantasai> johanneswilm: Exlusions, regions, don't want to work on it
# [04:12] <fantasai> johanneswilm: Understand it's being worked on elsewhere
# [04:13] <fantasai> Rossen_away: Path forward wehad agreed on was that exclusions is amodule that provides specification on what happens with exclusion areas
# [04:13] * Quits: AndreyR (~AndreyR@public.cloak) ("Page closed")
# [04:13] <tantek> zcorpan: it looks like https://books.spec.whatwg.org/ has not been updated in over 2 (almost 3) months.
# [04:13] <fantasai> johanneswilm: How these are positioned is not up to that spec, only about propagation of the geometry
# [04:13] <Florian> q+
# [04:13] * Zakim sees Florian on the speaker queue
# [04:13] <fantasai> s/johanneswilm/Rossen/
# [04:13] <fantasai> Rossen: Doesn't deal with layout
# [04:13] <tantek> and https://books.spec.whatwg.org/ does not appear to mention page-floats
# [04:14] * Joins: AndreyR (~AndreyR@public.cloak)
# [04:14] <fantasai> Rossen: Are you also planning to work on exclusions, or just layout?
# [04:14] <astearns> tantek: https://figures.spec.whatwg.org/
# [04:14] <tantek> only thing that books whatwg spec appears to affect re: floats is float: footnote
# [04:14] <zcorpan> https://figures.spec.whatwg.org/#page-floats
# [04:14] <fantasai> johanneswilm: Need to investigate underlying fundamentals
# [04:14] <fantasai> johanneswilm: Idea is not to talk about it here
# [04:14] <fantasai> johanneswilm: Want to make it very simple to start with, so just rectangular floats that go up or down
# [04:14] <tantek> thanks astearns zcorpan
# [04:15] <fantasai> johanneswilm: And then in discussion with other projects that work with this, try to see what direction they want to go with it
# [04:15] <tantek> https://figures.spec.whatwg.org/ appears to not have been updated since 2014-09-30
# [04:15] <tantek> that is - not updated 4-5 months
# [04:15] <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.
# [04:15] * leaverou is now known as leaverou_away
# [04:15] <fantasai> johanneswilm: The counter-proposals, we don't really need them in there.
# [04:15] <fantasai> dino: Can we remove them?
# [04:15] <ChrisL> s/what we can/what we call
# [04:15] <fantasai> dino: It's obviously confusing
# [04:16] * leaverou_away is now known as leaverou
# [04:16] <tantek> agreed, remove them
# [04:16] <fantasai> RESOLVED: Remove exclusions and regions sections from page floats spec
# [04:16] <fantasai> RESOLVED: johanneswilm added as editor
# [04:17] <fantasai> dino: Webkit has been interested in implementing this for awhile, for pages/columns in browser, for our ibooks product
# [04:17] <fantasai> dino: You don't have to ask just printing companies
# [04:17] <fantasai> johanneswilm: Sounds great
# [04:17] <fantasai> johanneswilm: Want to work together with everyone who wants to work on this
# [04:17] <fantasai> johanneswilm: have a specification that everybody can be proud of
# [04:17] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [04:17] <fantasai> tantek: Do you have an approach in mind for keeping in sync with Figures spec?
# [04:17] <tantek> https://figures.spec.whatwg.org/#page-floats
# [04:17] <fantasai> johanneswilm: We will be talking to howcome and find out what is possible there
# [04:18] <fantasai> johanneswilm: He also has his own idea of exclusions and regions
# [04:18] <fantasai> johanneswilm: and first-letter caps
# [04:18] <fantasai> johanneswilm: Idea is not to import another idea, but we want to try to incorporate as much as possible with howcome
# [04:18] <fantasai> ChrisL: Anyone implementing Figures?
# [04:18] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [04:18] <fantasai> dauwhe: I'm not aware of anyone. Will have more info after I visit YesLogic this week
# [04:19] <fantasai> dauwhe: howcome isn't involved in the WG anymore, this is the group that has to decide what gos in the spec
# [04:19] <fantasai> ChrisL: Great that there's not just a totally-separate-from-browsers group doing this on the side
# [04:19] <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
# [04:19] <fantasai> johanneswilm: I don't think they are exclusive
# [04:20] <fantasai> johanneswilm: If anyone has written thesis in laTex
# [04:20] <fantasai> johanneswilm: You can write a directive that all figure sand captions go to the top
# [04:20] <fantasai> johanneswilm: This is the same. You define onece, wher eeverything goes
# [04:20] <fantasai> johanneswilm: If you want more grpahic art of making books, you want to decide where each figure goes, where each whatever
# [04:20] <fantasai> johanneswilm: text goes around in funny ways
# [04:20] <fantasai> johanneswilm: no computer can do that automatically
# [04:21] <fantasai> cameron: Is it in the spec to go to a new page or a named page?
# [04:21] <fantasai> johanneswilm: Right now just want to get a simple specification that is similart to what is shipping in these implementations
# [04:21] <fantasai> johanneswilm: that said, there are many common things not implemented anywhere
# [04:21] * shepazu drops a little CSS joke in for the break: https://twitter.com/shepazu/status/564987167307350016
# [04:21] <fantasai> johanneswilm: floating things on other pages, e.g.
# [04:21] <fantasai> johanneswilm: or float imaes all to a set of 8 pages that are in color others black and white
# [04:22] * tantek shepazu oh dear
# [04:22] <fantasai> johanneswilm: we can grow as far as we need to, but not more than there is implemented
# [04:22] <fantasai> dauwhe: that's a significant use case for us
# [04:23] <fantasai> Topic: @extend
# [04:23] * ChrisL tab-extends
# [04:24] * Joins: JonathanNeal_ (~sid5831@public.cloak)
# [04:24] <fantasai> TabAtkins: One of the most consistently popular parts of SASS is @extend rule
# [04:24] * glazou shmextends
# [04:24] <fantasai> TabAtkins: massive update
# [04:24] <ChrisL> https://lists.w3.org/Archives/Public/public-houdini/2015Jan/0005.html
# [04:24] <fantasai> TabAtkins: dbaron about 2 years ago suggested something that had almost exactly the same shape as @xtend, but with less convenient syntax
# [04:24] <fantasai> TabAtkins: Suggested just using @extend, that's what people are used to
# [04:24] <fantasai> TabAtkins: here's a proposal to add @extend to CSS finally
# [04:25] <TabAtkins> http://tabatkins.github.io/specs/css-extend-rule/
# [04:25] <fantasai> TabAtkins: Somewhat trivial example, but large corpus of examples
# [04:25] <fantasai> TabAtkins: Say you have a bunch of styles for a .error class
# [04:25] <fantasai> TabAtkins: Later you realize you ned to make a really serious error class
# [04:26] <fantasai> TabAtkins: same styles, but make it red and bold as well
# [04:26] <fantasai> TabAtkins: ways to do this now, have to make all markup using seriouserro class also have error class
# [04:26] <fantasai> TabAtkins: Need to track in HTML
# [04:26] * Rossen_away is now known as Rossen
# [04:26] <fantasai> TabAtkins: also in DOM manipulation
# [04:26] <fantasai> TabAtkins: add and remove together, fairly error prone
# [04:27] <fantasai> TabAtkins: alternate way is that in CSS every rule that has .error, also have a .seriouserror selector
# [04:27] <fantasai> TabAtkins: Also not great, because have to duplicate every single selector
# [04:27] <fantasai> TabAtkins: Also maintain that as you remove selectors
# [04:27] <fantasai> TabAtkins: Lots o f potention for typos
# [04:27] <fantasai> TabAtkins: Not good solutions to hadling this kind of subclassing of widgets in CSS
# [04:27] <fantasai> TabAtkins: @extend rule captures this concept
# [04:28] <fantasai> .seriouserror {
# [04:28] <fantasai> @extend .error;
# [04:28] <fantasai> }
# [04:28] <fantasai> TabAtkins: Means that every element to which this style rule applies
# [04:28] * glazou would like to see the OM for that :-)
# [04:28] <fantasai> TabAtkins: also matches the .error class.
# [04:29] <fantasai> TabAtkins: Draft as it is allows everything
# [04:29] <fantasai> TabAtkins: e.g. use :not()
# [04:29] <fantasai> TabAtkins: Would be fine to restrict to feature selectors: tag names, classes, attrs, IDs, stuff that's in the DOM
# [04:30] <fantasai> TabAtkins: There are potential use cases e.g. :hover, but that makes it much more complicated
# [04:30] <fantasai> TabAtkins: That's basically it
# [04:30] <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?"
# [04:30] <fantasai> TabAtkins: Impleentationwise I have no idea
# [04:31] <fantasai> fantasai: Compound or complex selectors?
# [04:32] <fantasai> TabAtkins: compound selectors only
# [04:32] <fantasai> TabAtkins: Don't think it's worth the complexity
# [04:32] <fantasai> fantasai: Agree, just want to be clear
# [04:33] <fantasai> TabAtkins: @extend rule might make it match more rules, which might themselves have @extend;
# [04:33] <fantasai> TabAtkins: Shouldn't be a big deal, but a large number of chained extensions
# [04:33] <fantasai> dino: loop?
# [04:33] <fantasai> TabAtkins: Can't subtract features.
# [04:33] <fantasai> TabAtkins: No loopse
# [04:34] <fantasai> TabAtkins: No specificity issues.
# [04:34] <fantasai> TabAtkins: Just behaves like it also has the .error class.
# [04:35] <fantasai> dbaron: Are yo umatching specificity of seriouserror or error?
# [04:35] <fantasai> fantasai makes tab write on the board:
# [04:35] * dauwhe The question is A or B? The answer is Yes.
# [04:35] <fantasai> #serious-error { @extend .error; }
# [04:35] <fantasai> .error { color: blue; }
# [04:35] <fantasai> dbaron: Is color: blue class-specific or ID-specific?
# [04:36] <fantasai> TabAtkins: class-specific
# [04:36] <dbaron> Tab says that with #seriouserror { @extend .error } .error { color: blue} the specificity used for color:blue comes from .error
# [04:36] <fantasai> glazou: OM to represent @extend?
# [04:36] <fantasai> TabAtkins: We discussed this in the past, we'll add .cssRules on the stylerule interface
# [04:36] <fantasai> cameron: Does this work across style sheets?
# [04:36] <fantasai> TabAtkins: Yes
# [04:37] <fantasai> cameron: Simpler mode is just single class names or single IDs only
# [04:37] <fantasai> TabAtkins: Answer is I'm not sure
# [04:37] <fantasai> TabAtkins: SASS allows fuller model than what I'm doing now
# [04:37] <fantasai> TabAtkins: Might be possible to trim it down
# [04:37] <fantasai> TabAtkins: Could put as an issue in the draft
# [04:38] <fantasai> glazou: You allow only compound selectors in here? The other place?
# [04:38] <fantasai> TabAtkins: selector on the rule can be anything
# [04:38] <fantasai> roc: querySelector?
# [04:38] <fantasai> TabAtkins: Unsure. Dunno what's useful
# [04:38] <fantasai> dino: I really like this proposal. Wondering whether just having placeholders is enough
# [04:38] * fantasai what si placeholders?
# [04:39] <fantasai> TabAtkins: Placeholder selector is a concept introduced by SASS
# [04:39] <fantasai> TabAtkins: They use the % sign. It's just like a class, just impossible to match with any feature in the DOM
# [04:39] <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
# [04:40] <fantasai> TabAtkins: Quite a bit of the stuff with @extend can be used is placeholders
# [04:40] <fantasai> TabAtkins: You might have to start with .error, and then rewrite it to %error
# [04:40] <fantasai> TabAtkins: would want to do more research if most use cases can be done with just placeholders/classes
# [04:40] <fantasai> fantasai: It does seem like placeholders would be a simpler model to have.
# [04:41] * liam reads scrollback, pleased to see page floats awoken, guesses now it's @isa or @extends or whatever
# [04:41] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [04:41] <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.
# [04:41] <fantasai> dino: How does SASS do it?
# [04:41] <fantasai> TabAtkins: They do it by selector-rewriting. This has a different selector specificity behavior; SASS authors think it's fine.
# [04:42] <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...
# [04:42] <fantasai> dino: What would be the problems with it?
# [04:42] <fantasai> TabAtkins: @extend has a dual form with @mixin
# [04:42] <fantasai> TabAtkins: we could consider extending in the future
# [04:42] <fantasai> TabAtkins: SASS shows @extend is preferred by authors, so should do it first
# [04:43] * dauwhe liam: current topic is https://lists.w3.org/Archives/Public/public-houdini/2015Jan/0005.html
# [04:43] <fantasai> dino: Awareness of specificity.. . it's a difference from the way normal CSS reads
# [04:43] * Joins: pjrm (~pjrm@public.cloak)
# [04:43] <fantasai> dino: shorthand, longhand
# [04:43] * Zakim sees Florian, dino:, shorthand, long on the speaker queue
# [04:43] * liam thanks
# [04:43] <fantasai> plinss: I'm not sure that you will be aware of the specificity
# [04:43] <fantasai> plinss: There could be other rules somewhere in the mix, there's a .error
# [04:43] <fantasai> dino: especially if .error extends from something
# [04:43] <fantasai> plinss: ...
# [04:43] <fantasai> plinss: no predictability
# [04:44] <fantasai> TabAtkins: With a little bit of discipline, using mainly just placeholders, then will get into less trouble than that
# [04:44] <fantasai> dino: yes, I like placeholders better
# [04:44] * liam thanks dauwhe, suspected so, had read the mail, liked proposal except for the colour of the bikeshed... er i mean the name
# [04:44] <fantasai> TabAtkins: Unless we allow @extend to affect querySelector, the placeholder won't match anything aside of the querySelector call
# [04:45] <fantasai> cameron: I think it might be useful to querySelector all my buttons
# [04:45] <fantasai> TabAtkins: I can see it'd be useful, might be issue
# [04:45] <fantasai> plinss: Really odd querySelector doesn't work, but also really weird that CSS affects the DOm
# [04:45] <fantasai> TabAtkins writes
# [04:46] <fantasai> .foo { @extend: button; }
# [04:46] <fantasai> TabAtkins: This will pull in the UA styles for buttons
# [04:46] <fantasai> cameron: Sounds neat, but internally we set some rule sin the UA style sheet that really can't be applied to othe relements
# [04:46] <fantasai> cameron: due to scurity, or we make certian assumptions about what elements they apply to
# [04:47] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [04:47] <fantasai> dbaron: form controls probably shoudl have been designed as values of 'display', but they're not.
# [04:47] <fantasai> dbaron: So they require element-specific knowledge, and the Web depends on that.
# [04:47] <roc> please add "roc's head explodes" to the minutes
# [04:47] * liam zakim, who is on the phone?
# [04:47] * Zakim apparently Team_(css)00:49Z has ended, liam
# [04:47] * Zakim sees on irc: pjrm, JonathanNeal_, AndreyR, tantek, murakami, shepazu, Florian, johanneswilm, estellevw, dauwhe, xidorn, stryx`, nduca, nikos, jumland, lmclister______, achicu_____,
# [04:47] * Zakim ... TabAtkins, ojan, timeless, jdaggett, ChrisL, SteveZ, dbaron, jet, dino, kwkbtr, roc, hyojin, glazou, zcorpan, rego, ato, amtiskaw, mihnea_____, vollick_, heycam, RRSAgent,
# [04:47] <fantasai> dbaron: If you put 'display: inlie' or 'display: block' on a button, it's still a button
# [04:47] * Zakim ... Zakim, dwim1, hgl, fantasai, krijnhoetmer, Rossen, shane, rbyers, dstockwell, krit, mvujovic______, ppk___, CSSWG_LogBot, liam, Rossen_, iank, abucur___, birtles,
# [04:47] * Zakim ... robertknight_clo
# [04:48] <fantasai> Florian: Have appearance property for that. The 'none' value has fair amoutn of interop, but other values work differently in different browsers
# [04:48] * fantasai roc, pls specify exactly where to inser
# [04:48] <fantasai> t
# [04:48] <fantasai> Florian: The buttonness of your button is not expressed in CSS.
# [04:49] <fantasai> dbaron: Our buttons, for example, have 2 sets of borders instead of two.
# [04:49] <fantasai> dbaron: If you @extend, you'll get one set but not the others.
# [04:49] <fantasai> greg: <select> control would be even worse
# [04:49] <fantasai> dino: I just wonder if we have a lot of power with a simpler thing
# [04:50] <fantasai> TabAtkins: This particular case is making custom element ppl happy as well. Would like to make see if we can do better.
# [04:50] <fantasai> dino: Really? Custom element ppl want to copy platform controls? what?
# [04:50] <fantasai> dbaron: One of my bigger concerns about this
# [04:50] * liam not sure " 2 sets of borders instead of two" is right
# [04:50] <fantasai> dbaron: I feel like a lot of developers misunderstood what CSS rules were, and this makes it worse
# [04:50] <fantasai> dbaron: Like what this thing at the beginning of it was
# [04:51] <fantasai> dbaron: I feel like this part of a mental model that is different from what they actually are
# [04:51] <fantasai> dbaron: Model is that selector is somethign that matches elements
# [04:51] <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
# [04:51] * ChrisL that *mostly* matches elements
# [04:51] <fantasai> dbaron: and this kindof looks like that
# [04:51] <fantasai> TabAtkins: yes, works similarly. Allows that kind of ideas to work out
# [04:51] <fantasai> SimonSapin: Even the name seems to say that class is something that exists in yourstyle sheet
# [04:52] <fantasai> SimonSapin: And when you have .error, and you extend the class with another class
# [04:52] <fantasai> SimonSapin: That's object oriented
# [04:52] <zcorpan> s/yourstyle/your style/
# [04:52] <fantasai> SimonSapin: but that's not what's really going on
# [04:52] <fantasai> SimonSapin: Class is one part of slector that dds the class
# [04:52] <fantasai> SimonSapin: The main extends seems to come from a mental model that is wrong
# [04:52] <glazou> +1 SimonSapin
# [04:52] <dbaron> s/main/name/
# [04:52] <fantasai> dino: Pick a name that is not @extend
# [04:52] <fantasai> TabAtkins: Don't wantto change the name from SASS
# [04:52] <liam> [ Liam also concerned people used to SASS will expect @extend to be 100% the same ]
# [04:52] <fantasai> dino: ... [good thing]
# [04:53] <fantasai> ChrisL: It's too late to change 'class'
# [04:53] <fantasai> ChrisL: You'll see #, o that's just a hash tag
# [04:53] <dbaron> ChrisL: people talk about "calling a class"
# [04:53] <fantasai> ChrisL: Those people will look at extends, and will
# [04:53] * fantasai sorry didn't get that :)
# [04:54] <ChrisL> and will be even more confused
# [04:54] <fantasai> fantasai: Maybe the approach to take is to start with placeholders only.
# [04:54] * astearns ...and that's how elements call their CSS classes. Now we'll scroll this web page to the top so the next person can start from the beginning
# [04:54] <fantasai> SimonSapin: If we go to placeholders, is this equivalent to custom selectors proposal?
# [04:55] <fantasai> SimonSapin: Becaue you have a slector that extends a placeholder, and you can use that selector in other placeholders
# [04:55] <fantasai> SimonSapin: Isn't that equivalent to having that placeholder expanding ot that placeholder?
# [04:55] <fantasai> roc: Difference in that you're declaring in one place all the things that are equivalent,
# [04:55] * Quits: pjrm (~pjrm@public.cloak) ("Leaving.")
# [04:55] * ChrisL proposes CSS SHARED COMMON BLOCKS like in FORTRAN
# [04:55] <fantasai> h1, h2, he ... {
# [04:55] <fantasai> @extend %heading;
# [04:55] <fantasai> }
# [04:55] * tantek slaps ChrisL with a COBOL statement
# [04:55] <fantasai> SimonSapin: How is that different from selector alias
# [04:56] <fantasai> TabAtkins: In terms of pure aliases, this is equivalent
# [04:56] * dauwhe h1 { goto: h2; }
# [04:56] * ChrisL the progrramming language of the 22nd century
# [04:56] <fantasai> @custom-selector --heading h1, h2, h3, h4;
# [04:56] <fantasai> TabAtkins: These are equivalent, yes.
# [04:56] <dbaron> q+
# [04:56] * Zakim sees Florian, dino:, shorthand, long, dbaron on the speaker queue
# [04:56] <fantasai> glazou writes
# [04:56] <tantek> tantek: or file input [said shortly after "greg: <select> control would be even worse"]
# [04:57] <fantasai> foo:not(.error) { @extend .error; }
# [04:57] <fantasai> glazou: That's a loop, yes?
# [04:57] <fantasai> TabAtkins: yes.
# [04:57] <fantasai> TabAtkins: hm, maybe have to do a loop-detection phase
# [04:57] <fantasai> roc: Two things aren't quite the same
# [04:57] <fantasai> roc: With custom selectors you ahve t list all the extensions in one place
# [04:58] <fantasai> roc: With the @extend you can increase the list anywher ein the style sheets, which makes it much more useful
# [04:58] <fantasai> dbaron: You could have something that is outside of a style rule, but still has advantage of spreading around the style sheets
# [04:58] <fantasai> dbaron: which is what I was proposing a few years ago
# [04:58] <fantasai> dbaron: Part of what makes me think it doesn't fit the model is putting it inside the style rule
# [04:58] <fantasai> fantasai: Can you summarize your proposal, dbaron?
# [04:59] <tantek> q?
# [04:59] * Zakim sees Florian, dino:, shorthand, long, dbaron on the speaker queue
# [04:59] <fantasai> people tell fantasai to go read it. While taking minutes and trying to keep up with the discussion.
# [04:59] <dino> q-
# [04:59] * Zakim sees Florian, dino:, shorthand, long, dbaron on the speaker queue
# [04:59] <tantek> ack Florian
# [04:59] * Zakim sees dino:, shorthand, long, dbaron on the speaker queue
# [04:59] <heycam> q- shorthand
# [04:59] * Zakim sees dino:, long, dbaron on the speaker queue
# [04:59] <heycam> q- long
# [04:59] * Zakim sees dino:, dbaron on the speaker queue
# [04:59] <fantasai> plinss: What thing, if @extend is inside the rule
# [04:59] <dino> ack dino
# [04:59] * Zakim sees dbaron on the speaker queue
# [05:00] <dino> ack dino:
# [05:00] * Zakim sees dbaron on the speaker queue
# [05:00] <fantasai> plinss: I may have, to go back to earlier example, I may have 6 different rules that apply serious erro rwith various selectors
# [05:00] <fantasai> plinss: If I want to include .error, have to put it in all of them
# [05:00] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [05:00] <fantasai> plinss: When any of the other smatch, then only put it here
# [05:00] * fantasai doesn't understand
# [05:00] <dbaron> q+ to say I don't just want to limit it to placeholders
# [05:00] * Zakim sees dbaron on the speaker queue
# [05:00] <dino> smatch!
# [05:00] <dino> shmatch
# [05:00] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [05:00] <liam> schmelectors?
# [05:00] <dbaron> q+ to say that a big part of what I don't like about it is the name
# [05:00] * Zakim sees dbaron on the speaker queue
# [05:01] <ChrisL> q+ to ask'); DROP TABLE queue
# [05:01] * Zakim sees dbaron, ChrisL on the speaker queue
# [05:01] <ChrisL> q-
# [05:01] * Zakim sees dbaron on the speaker queue
# [05:01] <fantasai> plinss: If I have 1 rule with .seriouserro:hover, and that contains @extend .error
# [05:01] <fantasai> plinss: It may have other selectors before .ersiouserror
# [05:01] <fantasai> plinss: If I put it in a rule that only matches sometimes.
# [05:01] <fantasai> plinss: May be an advantage, but may be somewhat confusing
# [05:01] * tantek wonders if a .black and .seriousblack example would have been better.
# [05:02] <fantasai> plinss: If you don't understand cascade/specificity correctly, you might get yourself into a confused situation
# [05:02] <fantasai> plinss: What I'm wondering is if it would be better to have it separate, not in a style rule
# [05:02] <fantasai> plinss: This selector is equivalent to this other selctor
# [05:02] <fantasai> plinss: Then it applies to all rueles and all style sheets
# [05:02] <fantasai> TabAtkins: Difference between this and @extend .seriouserror .error; is literally a matter of 2 chars
# [05:03] <fantasai> plinss: It's a big difference in behavior
# [05:03] * dauwhe tantek: how about .siriusblack?
# [05:03] <fantasai> TabAtkins: it's just syntactic.
# [05:03] * tantek dauwhe precisely :)
# [05:04] <dbaron> q+ to ask about interaction with combinators
# [05:04] * Zakim sees dbaron on the speaker queue
# [05:04] <dbaron> q+ to describe previous proposal
# [05:04] * Zakim sees dbaron on the speaker queue
# [05:04] <fantasai> plinss: If you have .foo > .seriouserror
# [05:05] <fantasai> plinss: Below that I have .bar > .seriouserror
# [05:05] <fantasai> plinss: And in that one I didn't put @extend
# [05:05] * tantek thought he heard: "listen to me because I'm trying to explain what you're not understanding"
# [05:05] <fantasai> plinss: But if I have a separate rule that is @extend .seriouserror .error ti works on both
# [05:05] * glazou tantek exactly
# [05:05] <fantasai> TabAtkins: yeah, same thing. You might have to have a separate rule that just holds @extend, but it's fine.
# [05:05] <fantasai> plinss: Oh, nevermind
# [05:05] * glazou tantek and tab listened :-)
# [05:06] <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
# [05:06] <fantasai> plinss: I think this just lets people who are doing it wrong od it wrong in more interesting ways
# [05:06] <fantasai> TabAtkins: yes, but it also makes people who know what theyr'e doing to have much more maintainable style sheets
# [05:07] <fantasai> plinss: I support better maintenace completely, but this feels really wrong to me.
# [05:07] <tantek> aside: how *do* you compose styles correctly? anyone have a suggested "how to" guide? URL?
# [05:07] <fantasai> plinss: I would like to see different ways of composing style rules, rathe rthan this.
# [05:07] <tantek> s/aside/tantek on irc aside
# [05:07] <fantasai> glazou: The problem is referencing a given rule from another rule.
# [05:07] <fantasai> plinss: in my hea,d without really understnaidn this, I would rathe rit simply references the other rule
# [05:08] <fantasai> plinss: Would rather say "what I really wanted was this set of properties, plus all the propertyies from the other rule over there"
# [05:08] <fantasai> plinss: Not by mangling what matches what.
# [05:08] * liam tantek f you find out let me know :)
# [05:08] <fantasai> TabAtkins: People don't wnat that
# [05:08] <fantasai> plinss: Because they don't understna dhow to compose CSS
# [05:08] * tantek liam I figure if we're going to be claiming people don't know how to, then we should be ready with a URL to a resource that says how to.
# [05:08] <fantasai> TabAtkins: You can have a bunch of style rules that apply style rules to .error in different contexts,.
# [05:09] * tantek do we have rules for proposing rules?
# [05:09] <fantasai> TabAtkins: referencing a block doens't work well there
# [05:09] <dbaron> q+ to agree with Tab about people wanting to extend one class with another being important
# [05:09] * Zakim sees dbaron on the speaker queue
# [05:09] * zcorpan @_@
# [05:09] <tantek> Tabatkins: I'm willing to let them be wrong if it helps them out
# [05:09] <fantasai> TabAtkins: It is extermeely popular in SASS commnity, shows it's helpul to people
# [05:09] <fantasai> plinss: But it's a model that's wrong
# [05:09] <fantasai> TabAtkins: I'm willing ot let the be wrong if it's helfpul
# [05:09] <fantasai> plinss: Going back to querySelector, that's really concering because selector behavior which is different from style sheets
# [05:10] <fantasai> plinss: Doesn't fit in architectural model of the Web
# [05:10] <fantasai> dino: I would like to not change querySelector, otherwise I don't have any problem
# [05:10] <fantasai> dino: I think the point about CSS being able to change JS apis is good, I agree
# [05:10] <fantasai> dino: I still like eveyrthing else
# [05:10] <dbaron> ack dbaron
# [05:10] <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
# [05:10] * fantasai feels sorry for spellchecker
# [05:10] <Zakim> ... combinators and to describe previous proposal and to agree with Tab about people wanting to extend one class with another being important
# [05:10] * Zakim sees no one on the speaker queue
# [05:10] <liam> [ tantek - I dont believe in right or wrong in this sort of thing anyway ]
# [05:11] <ChrisL> zakim, suggest a syntax for extending css
# [05:11] <Zakim> I don't understand 'suggest a syntax for extending css', ChrisL
# [05:11] <tantek> fantasai: It's in the logs
# [05:11] <fantasai> dbaron: I agree that extending one class with another is something we should do and is important to authors
# [05:11] <fantasai> dbaron: Authors end up writing 4 different selector sbecause buil hierarchy of stuff. So solving that point is important
# [05:11] <fantasai> dbaron: Wanted to ask question of what this actually does
# [05:12] * Rossen http://www.mememaker.net/meme/i-dont-make-errors-but-when-i-do-they-are-sirius
# [05:12] <fantasai> dbaron: Suppose you have .article { @extend .section; }
# [05:12] <fantasai> dbaron: And then .seriouserror { @extend .error; }
# [05:12] <fantasai> dbaron: and then you have .section .error { color: whatever; }
# [05:13] <fantasai> dbaron: This will match when you have <div class="article"><div class="seriouserror"></div></div??
# [05:13] <fantasai> TabAtkins: yes.
# [05:13] <fantasai> dbaron: good.
# [05:14] <fantasai> dbaron: It follows from the fact that I think this is improtant that we shouldn't limit it to just placeholder
# [05:14] <fantasai> dbaron: But I think a big part of my problem with it is the name.
# [05:14] <fantasai> dbaron: It's the wrong mental model,
# [05:14] <fantasai> glazou: More assimilate than extend
# [05:14] <fantasai> TabAtkins: I would be somewhat unhappy if we changed the name
# [05:14] <fantasai> TabAtkins: But has advantage that ...
# [05:14] <glazou> s/assimilate/simulate
# [05:14] <fantasai> dbaron: I don't believe that for a second.
# [05:15] <fantasai> dbaron: All people whose pages are going to break aren't going to be happy.
# [05:15] <fantasai> TabAtkins: That's SASS's responsibility.
# [05:15] <fantasai> TabAtkins: Different name would avoid that problem
# [05:15] <fantasai> s/.../ ... something about turning off @extend in SASS /
# [05:16] <fantasai> plinss worries about nested selector matching
# [05:16] * Joins: estellevw (~estellevw@public.cloak)
# [05:16] <fantasai> TabAtkins: You collec tthe @extend rules, iterate until stable
# [05:16] <glazou> s/plinss/glazou and plinss
# [05:17] <fantasai> TabAtkins: Then in addition to DOM class list, you also look in the @extend class list.
# [05:17] <fantasai> dbaron: That assumes the @extend rule is inside a selector that is jsut a class
# [05:17] <fantasai> TabAtkins: You match this, then you add this to extend this
# [05:17] <fantasai> plinss: Tab hasn't actually written a selector matching algorithm...
# [05:17] * liam thinks @extend is closer to @isa in non-CSS systems fwiw, thinking declaratively rather than developerishly
# [05:17] <fantasai> glazou: I'm afraid this is a feature for batch processors, not for dynamic browser. I'm worried about perf
# [05:18] * astearns terrible name alternatives: @mock, @ape, @parrot
# [05:18] <fantasai> TabAtkins: Batch processors can't implement this ocrrectly
# [05:18] <dbaron> about 6 lines up glazou raised the issue of performance
# [05:18] <fantasai> s/batch /pre
# [05:18] <fantasai> plinss: If you separate @extends out, then you can precompute it all
# [05:19] <fantasai> fantasai: They're syntactically equivalent
# [05:19] * Rossen I vote for @serious
# [05:19] <fantasai> fantasai: it may not be the syntax you want, but they are equivalent
# [05:20] <tantek> fantasai: if I can write a perl script that rewrites it then it's equivalent
# [05:20] * tantek is practicing drive-by minuting.
# [05:20] <fantasai> glazou: Selector matching: You try to match all of the selectors in the CSSOM against the element that you have in your hand.
# [05:20] * fantasai :)
# [05:21] <fantasai> di foo .bar { ... }
# [05:22] <fantasai> div > p > foo .section { #extend .bar }
# [05:22] <fantasai> glazou: You run selector matching, then realize it extends, have to go run it again.
# [05:22] <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.
# [05:22] <tantek> q?
# [05:22] * Zakim sees no one on the speaker queue
# [05:22] <glazou> otherwise first rule will never match
# [05:23] <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.
# [05:23] <fantasai> fantasai: They are syntactically equivalent.
# [05:23] * glazou the last « glazou » line is not from me, I never said that
# [05:23] <fantasai> s/glazou/plinss/
# [05:23] <dbaron> I still have no idea how we'd implement this in a browser...
# [05:24] <fantasai> glazou: I perfectly understand usefulness, but unsure how to implement this in a browser.
# [05:24] * fantasai isn't arrguing for the current syntax, just pointing out it's functionally equivalent to other syntax
# [05:24] <fantasai> plinss: Just explode out the selectors
# [05:24] <fantasai> TabAtkins: No, that won't get you the righ behavior
# [05:25] <fantasai> dbaron: I think it's really useful for authors, but no idea how to implement it
# [05:25] <dbaron> I think selector variables are much more straightforward.
# [05:25] <fantasai> plinss: I run into this problem myself
# [05:25] <fantasai> plinss: I'm not convicned this is the right way to solve the problem, but not sure it's the right way
# [05:26] <fantasai> fantasai: ...
# [05:26] <tantek> I for one like @extends
# [05:26] <fantasai> dbaron: I had two proposals, one similar to selector variables one similar to extend
# [05:26] <tantek> s/@extends/@extend
# [05:27] <fantasai> dbaron: And I think I like Tab's selector variables syntax better.
# [05:27] <fantasai> roc: if your estric tit to the placeholders version
# [05:27] <fantasai> roc: Then you can treat it as a different syntax as alisaed selectors
# [05:27] <fantasai> roc: And it's very clear how to implement that
# [05:27] <fantasai> SimonSapin:... ?
# [05:28] * liam . o O ( estric tit?? oh )
# [05:28] <liam> s/estric tit/restrict it/
# [05:28] <fantasai> TabAtkins: %foo > .error { @extend %bar; }
# [05:28] <dbaron> maybe s/selector variables/custom selectors/
# [05:28] * glazou in fact my original loop example for @extend is an heisenberg example
# [05:28] <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
# [05:29] <SimonSapin> s/.../It depends on whether you allow using selector aliases before you define them/
# [05:29] <fantasai> TabAtkins: can I have ED?
# [05:29] <fantasai> fantasai: I don't hear agreement on the draft.
# [05:30] <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.
# [05:30] <fantasai> fantasai: So I'm not happy with an ED
# [05:30] <fantasai> fantasai: But I also want us to tell Tab what he needs to do to get there
# [05:30] <fantasai> glazou: My concern is that if we accept ED and then have a media storm if we reject or change significantly
# [05:31] <fantasai> plinss: Had the same thing with variables
# [05:31] <fantasai> glazou: Yes, and I would like to avoid that.
# [05:31] <ChrisL> zakim, remind TabAtkins in 15 years to re-propose @extends
# [05:31] <Zakim> I don't understand you, ChrisL
# [05:32] <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.
# [05:32] <roc> hmm ... %foo > .error { @extend %foo; }
# [05:32] <fantasai> ...
# [05:32] <roc> div { @extend %foo; }
# [05:33] <tantek> css-as
# [05:33] * ChrisL css-stealing-from-sass-1
# [05:33] <fantasai> plinss: Call it maybe Style Rule Composition
# [05:33] <fantasai> [random comments]
# [05:33] <fantasai> shortname sugestions
# [05:33] * dauwhe CompSty
# [05:34] <tantek> css-subclassing
# [05:34] <dbaron> css-bikeshedding
# [05:34] <fantasai> css-composition
# [05:34] <roc> so @extend is different from custom selectors because it allows defining recursive selectors
# [05:34] <tantek> css-class-class
# [05:35] <fantasai> proposal: Make an editor's draft with big red warning to work on the problem, called CSS Style Rule Composition, shortname tbd
# [05:35] <fantasai> RESOLVED: Make an editor's draft with big red warning to work on the problem, called CSS Style Rule Composition, shortname tbd
# [05:35] <tantek> is it break time yet?
# [05:35] * glazou suggests a warning saying the author, in case of failure, will be exiled 6 winter months in antarctica
# [05:36] <tantek> tabatkins: next I'd like to present, I just want to use JavaScript instead ;)
# [05:36] * ChrisL http://www.w3.org/Submission/1996/1/WD-jsss-960822
# [05:36] <fantasai> <br type=snacks>
# [05:43] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [05:59] * Joins: johanneswilm (~johannes@public.cloak)
# [06:00] <TabAtkins> ScribeNick: TabAtkins
# [06:00] <TabAtkins> Topic: <custom-ident>
# [06:00] <TabAtkins> SimonSapin: We have an issue when <custom-ident> can occur at the same position as keywords, could be amibiguous.
# [06:00] <TabAtkins> SimonSapin: Need to define how to resolve.
# [06:01] <TabAtkins> SimonSapin: Right now the spec says that the first occurence of something ambiguous is given to the keyword, and afterwards is <custom-ident>.
# [06:01] <TabAtkins> SimonSapin: But that means you ahve to remember what you've parsed so far.
# [06:01] <TabAtkins> SimonSapin: That's annoying to implement, and maybe surprising to authors.
# [06:01] <TabAtkins> SimonSapin: If you reorder things where order normally doesn't matter, it changes the meaning.
# [06:02] <TabAtkins> SimonSapin: Another option is to restrict <custom-ident> based on what it can be ambiguous with.
# [06:02] * Joins: vollick__ (~vollick@public.cloak)
# [06:02] <TabAtkins> SimonSapin: For example, list-style-type takes either <counter-style> | string | none
# [06:02] <TabAtkins> SimonSapin: And <counter-style> is <custom-ident>
# [06:03] <TabAtkins> SimonSapin: So if you specify "none", it can't be a <counter-style>, as it'll be ambiguous.
# [06:03] <TabAtkins> SimonSapin: But that's easy.
# [06:03] <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.
# [06:03] <TabAtkins> SimonSapin: So here we should restrict <custom-ident> to not be able to be "outside".
# [06:03] <TabAtkins> dbaron: So you'd restrict "outside" from list-style-type as well?
# [06:04] <TabAtkins> SimonSapin: That's possible, but it's harder to maintain.
# [06:05] <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.
# [06:05] <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.
# [06:06] <TabAtkins> TabAtkins: We purposely moved to the current behavior, which matches animation, to avoid those problems.
# [06:07] <TabAtkins> SimonSapin: Describe current animation behavior?
# [06:07] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [06:07] <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.
# [06:08] <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.
# [06:08] <TabAtkins> SimonSapin: That measn in a context where order normally doesn't matter, sometimes it does and you can't.
# [06:09] <TabAtkins> TabAtkins: Rijght.
# [06:09] <TabAtkins> TabAtkins: All new grammars should always be positionally unambiguous.
# [06:09] <dbaron> The values spec should probably say that (i.e., give advice for spec authors).
# [06:10] <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.
# [06:10] <TabAtkins> TabAtkins: Are you okay with this, given that context?
# [06:10] <TabAtkins> SimonSapin: Okay, I can live with this. I'd like to explore other options, but maybe in a later meeting.
# [06:11] <TabAtkins> TabAtkins: Next is global keywords - allow or exclude? I don't care.
# [06:11] <TabAtkins> fantasai: Weak pref for excluding. I don't think there's any reason to allow them, and they cause some problems.
# [06:11] <TabAtkins> fantasai: And we already exclude them in font-family and counter-styles.
# [06:11] <TabAtkins> fantasai: It's better to catch errors earlier, so it's a benefit to authors and just exclude it.
# [06:11] * Joins: estellevw (~estellevw@public.cloak)
# [06:12] <TabAtkins> TabAtkins: I'm fine with that - it amkes it harder to add global keywords, but we don't do those often anyway.
# [06:12] <TabAtkins> SimonSapin: I think it's arbitrary to exclude them, but meh.
# [06:13] <TabAtkins> RESOLVED: Exclude the global keywords from <custom-ident>.
# [06:13] * liam wonders what happens if keywords are added in the future
# [06:13] * fantasai authors who used them are screwed
# [06:13] <SimonSapin> s/exclude them,/exclude them when not ambiguous,/
# [06:13] * SimonSapin they are screwed in many other cases where we don’t help them
# [06:16] * glazou TabAtkins should ask for a LCCRPRREC
# [06:16] * TabAtkins Let me try to pronounce that. Alan, don't call 911.
# [06:16] <TabAtkins> SimonSapin: One remark about <custom-ident>.
# [06:17] <TabAtkins> SimonSapin: The spec says that other specs must clearly say what keywords are excluded. Why normative?
# [06:17] <TabAtkins> TabAtkins: Why not?
# [06:18] <TabAtkins> RESOLVED: Pending edits, publish V&U as new CR.
# [06:18] <TabAtkins> ChrisL: Remember we'll need an up-to-date DoC to republish.
# [06:18] <ChrisL> rrsagent, here
# [06:18] <RRSAgent> See http://www.w3.org/2015/02/08-css-irc#T05-18-29
# [06:18] <fantasai> ScribeNick: fantasai
# [06:19] <fantasai> Topic: Flexbox
# [06:19] <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.
# [06:20] <fantasai> fantasai: If you have an abspols flex container, it wraps to the window width, but doesn't shrinkwrap into it.
# [06:21] <fantasai> fantasai: We think this is wrong, just wanted to check we're not missing something.
# [06:22] <fantasai> https://lists.w3.org/Archives/Public/www-style/2014Sep/0396.html
# [06:22] <fantasai> fantasai: Issue about no-wrap is still open
# [06:23] <fantasai> fantasai: and have some pagination stuff
# [06:23] <fantasai> fantasai: then should publish
# [06:23] <fantasai> Topic: Form Control Styling
# [06:23] <TabAtkins> http://dev.w3.org/csswg/css-forms/
# [06:23] <fantasai> TabAtkins: fantasai brought up form control styling
# [06:23] <fantasai> TabAtkins: Started a nice thread
# [06:23] <fantasai> TabAtkins: Started disagreeing on what is reasonable to allow form control styling
# [06:24] <fantasai> TabAtkins: Have a basic exploratory draft
# [06:24] <fantasai> TabAtkins: Writes up various proposals. We need more screenshots
# [06:24] <fantasai> dino: Web controls are horrible on iPhone
# [06:25] <fantasai> ACTION: florian to make page of all form controls
# [06:25] * trackbot is creating a new ACTION.
# [06:25] * RRSAgent records action 5
# [06:25] <trackbot> Created ACTION-673 - Make page of all form controls [on Florian Rivoal - due 2015-02-17].
# [06:25] <fantasai> fantasai: so proposal is collect screenshots
# [06:25] <fantasai> TabAtkins: Two proposals so far, read and comment and throw out more ideas.
# [06:26] <fantasai> TabAtkins: And really, want more screenshots. Espe. from outside Android/iOS bubble
# [06:26] <fantasai> Topic: Snapshot
# [06:26] <TabAtkins> ScribeNick: TabAtkins
# [06:26] <TabAtkins> fantasai: Aaron posted a proposal for a snapshot 2015
# [06:26] <fantasai> www.w3.org/mid/BLUPR03MB199E2D02A3708B7400C5108AD270@BLUPR03MB199.namprd03.prod.outlook.com
# [06:26] <TabAtkins> fantasai: His proposal is:
# [06:26] <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Feb/0200.html
# [06:26] <TabAtkins> fantasai: ^^^
# [06:27] <TabAtkins> fantasai: We need to update the snapshot.
# [06:27] <TabAtkins> fantasai: Intro needs reworking, change the vendor-prefix section.
# [06:27] <TabAtkins> fantasai: But also need to decide what goes into the snapshot.
# [06:27] <TabAtkins> fantasai: Proposal so far is everything in Rec,
# [06:27] <TabAtkins> Florian: dbaron and I have also helped him iterate on this
# [06:28] <TabAtkins> fantasai: Also animation, backgrounds, cascade, conditional, flexbox, fonts, images, multicol, transform, transitions, and v&u.
# [06:28] <TabAtkins> fantasai: Some discussion about counter-styles.
# [06:28] <TabAtkins> fantasai: And syntax.
# [06:28] <TabAtkins> dbaron: Does anyone else implement text-decor-3?
# [06:29] <TabAtkins> fantasai: I think apple does text-emphasis?
# [06:29] <TabAtkins> fantasai: I'm guessing it'll wait to 2016, based on what I know.
# [06:29] <TabAtkins> fantasai: Any other editors think their specs are ready?
# [06:30] <TabAtkins> TabAtkins: There was a suggestion for the will-change spec. It's stable and widely implemented.
# [06:30] <TabAtkins> tantek: I think UI meets the criteria too.
# [06:31] <TabAtkins> TabAtkins: Did you drop all the weird stuff that nobody ipmlemented?
# [06:31] <TabAtkins> tantek: ::value/choices not yet, but will be dropped asap. Then it's all implemented stuff.
# [06:32] <TabAtkins> fantasai: I say we leave it out until the new draft that drops those is up.
# [06:32] <TabAtkins> tantek: How long to do it?
# [06:32] <TabAtkins> Florian: Several bits need to be rewritten, so won't be published for a little bit.
# [06:32] <TabAtkins> [some discussion about UI]
# [06:33] <TabAtkins> fantasai: I'd like will-change to move to CR, if it's ready to be included in the snapshot.
# [06:34] <TabAtkins> dbaron: Is Syntax a yes?
# [06:34] <TabAtkins> dbaron: I'd like to see it in.
# [06:34] <TabAtkins> fantasai: If you say it should go in, I'll support that.
# [06:35] <TabAtkins> TabAtkins: Everyone okay with Syntax in?
# [06:35] <TabAtkins> [general assent/disinterest]
# [06:35] <TabAtkins> SimonSapin: Anything we don't want that it's in CR?
# [06:35] <tantek> I don't understand the criteria being used
# [06:35] <TabAtkins> fantasai: Speech, because no ipmls.
# [06:35] <TabAtkins> fantasai: Text-decor not yet.
# [06:35] <tantek> appears to be inconsistently applied
# [06:35] <TabAtkins> fantasai: Writing-modes not yet.
# [06:36] <TabAtkins> fantasai: Shapes and Masking are not in yet.
# [06:36] <TabAtkins> TabAtkins: Shapes is in two impls. Sounds like it should go in.
# [06:37] <TabAtkins> astearns: I think Shapes is reasonably stable, but I'd still like another impl.
# [06:37] <TabAtkins> TabAtkins: So in or not?
# [06:37] <TabAtkins> astearns: I dunno.
# [06:37] <TabAtkins> astearns: Let's leave it out. I don't expect to see changes, but we'll see.
# [06:37] <TabAtkins> dbaron: I think whoever made the list didn't go through FXTF.
# [06:37] * Quits: vollick__ (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [06:38] <TabAtkins> dbaron: Compositing, Masking, Filters, what's ipml status?
# [06:38] <TabAtkins> TabAtkins: I think they're all in Blink/WEbkit.
# [06:38] <TabAtkins> roc: FF doesn't do Masking. We do Compositing and Filters.
# [06:38] <TabAtkins> krit: With exception of Blending, all other specs have partial impls, but aren't implemented entirely.
# [06:39] <TabAtkins> krit: So Blending should go in.
# [06:39] <TabAtkins> fantasai: So, Aaron's list, plus will-change and UI once they're updated, plus compositing.
# [06:39] <fantasai> s/Aaron/Arron/
# [06:40] <TabAtkins> fantasai: Plus Syntax.
# [06:40] * astearns +
# [06:40] <TabAtkins> Florian: Do we inline the intro chapters from CSS2? It has a nice introduction to CSS.
# [06:40] <tantek> so we are including CSS3-UI?
# [06:40] <astearns> tantek: once the edits are made, yes
# [06:40] <TabAtkins> Florian: If the snapshot is the intro to stable CSS, seems reasonable to put that there.
# [06:41] <astearns> tantek: same as with will-change
# [06:41] <TabAtkins> ChrisL: It turns "a list of stuff" into "a list of stuff plus some introductory material". Do people read it?
# [06:41] <tantek> astearns: edits we agreed to in this meeting?
# [06:41] <tantek> because edits are going to be made for quite some time
# [06:41] <TabAtkins> ChrisL: Will the intro be the same?
# [06:41] <tantek> s/asterns:/astearns,"
# [06:41] <TabAtkins> Florian: Initially could be the same, but might change too.
# [06:41] <tantek> oops
# [06:41] <TabAtkins> fantasai: I think we should do minimal stuff first. Update list of specs and interactions, update vendor prefixing, then publish.
# [06:41] <tantek> astearns, edits we agreed to in this meeting? because edits are going to be made for quite some time.
# [06:42] <TabAtkins> fantasai: I think we should include the intro from CSS2 about "this is how property tables work, etc".
# [06:42] <astearns> tantek: I thought you had a set of edits to make before publishing
# [06:42] <TabAtkins> fantasai: And a glossary of terms auto-genned from Shepherd for those specs.
# [06:42] <TabAtkins> fantasai: All this latter stuff as a second pub.
# [06:42] <tantek> astearns: nope, we already have a draft in the pipe to be published per resolution 2015-01-21
# [06:42] * tantek darn it did it again
# [06:42] <TabAtkins> TabAtkins: Sounds good. WE can do the minimal stuff by end of Feb, adtl pubs pending interest.
# [06:43] <tantek> astearns, no, we already have a draft in the pipe to be published per resolution 2015-01-21
# [06:43] <tantek> and I would assert event that draft is good enough to be included
# [06:43] <fantasai> fantasai^: And a property index auto-genned by Shepherd
# [06:43] <TabAtkins> RESOLVED: Produce the snapshot with fantasai's list, update vendor prefix policy. Group will review when finished.
# [06:44] <TabAtkins> Topic: CSS 2 updates
# [06:45] <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/
# [06:45] <TabAtkins> fantasai: I think someone was proposing we should publish drafts where we remove sections of CSS2.
# [06:45] * glazou shmapshot
# [06:45] <TabAtkins> fantasai: Unsure we can do that without a lot of overhead, and I'm not sure it's a great idea.
# [06:45] <TabAtkins> fantasai: But we *should* put a note under every replaced subheading pointing to the replacing draft.
# [06:45] <TabAtkins> fantasai: At some point int he future we can publish a skeleton spec.
# [06:45] <TabAtkins> Florian: Do we put a note pointing to specs when they're Rec? Or as soon as they exist?
# [06:46] <TabAtkins> TabAtkins: As soon as browsers accept them as definitive.
# [06:46] <TabAtkins> fantasai: CR, definitely. Earlier on a case-by-case basis.
# [06:46] * glazou let skeletonize all things
# [06:46] <TabAtkins> ChrisL: You're proposing a skeletonization.
# [06:46] * astearns skeletonizing with viscera
# [06:46] * leaverou is now known as leaverou_away
# [06:46] <fantasai> [discussion of zombie bodies of CSS2.1]
# [06:47] <TabAtkins> [chrisl describe Night of the Living CSS2]
# [06:47] <TabAtkins> ChrisL: Apparently we have a bunch of errata to publish. I thought that's what CSS2.2 was about?
# [06:47] <TabAtkins> ChrisL: Is the whole point of this to just point to the new stuff, why roll in errata in the first place?
# [06:47] <TabAtkins> fantasai: I think there's some sections of 2.1 we don't have a replacement fo ryet.
# [06:48] <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.
# [06:48] <TabAtkins> fantasai: So if we make changes, might as well keep them in sync.
# [06:48] <TabAtkins> fantasai: But some sections have been completely gutted and redesigned, like syntax.
# [06:48] <TabAtkins> fantasai: The warning should be more stringent and emphasize that the new ref is very important to look at.
# [06:48] <TabAtkins> fantasai: We won't be maintaining any errata for syntax.
# [06:49] <TabAtkins> ChrisL: ARe ther pending errata for 2.1 that need to be published?
# [06:49] <TabAtkins> ChrisL: Where is that best going to go for people to notice it?
# [06:49] <TabAtkins> ChrisL: The sections getting replaced should be the new stuff.
# [06:49] <TabAtkins> Florian: If entire sections are wrong, just say "go look at the new stuff".
# [06:50] <TabAtkins> fantasai: Part of th eproblem is that our errata maintenance process is unmanageable. It's too hard to publish our errata docs.
# [06:50] <TabAtkins> fantasai: WE can at least publish notes saying "look over here", so we should do that.
# [06:50] <TabAtkins> fantasai: And also solve the errata problem, but that's separable.
# [06:51] <TabAtkins> ChrisL: I just wanted to make sure the errata moved from the errata doc to someplace people will actually look at them.
# [06:51] <TabAtkins> SimonSapin: The editors draft contains the errata inline.
# [06:51] <TabAtkins> ChrisL: And there's a note on 2.1 pointing to the ED.
# [06:52] <TabAtkins> TabAtkins: So does anyone object to adding the notes to the ED, per fantasai?
# [06:52] <TabAtkins> Florian: Is the criteria for drafts the same as the snapshot?
# [06:53] <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.
# [06:53] <TabAtkins> fantasai: So if it's stable OR better, we should point to it.
# [06:53] <TabAtkins> ChrisL: How to indicate it? People can deep-link.
# [06:53] <TabAtkins> fantasai: A note on every subsection.
# [06:53] <TabAtkins> TabAtkins: Yeah, that's probably sufficiently dense that you'll tend to see it.
# [06:54] <TabAtkins> Florian: Bikeshed should have something for specs to indicate they replace something.
# [06:55] <TabAtkins> TabAtkins: In time!
# [06:55] * astearns better than a zombie is a pretty low bar
# [06:55] * dauwhe astearns better than a zombie is a pretty AWESOME bar
# [06:56] <TabAtkins> SimonSapin: My list of replacement is my personal judgement of what people should look at for implementation.
# [06:56] <TabAtkins> RESOLVED: Add a note to every subsection pointing to drafts that replace those parts of CSS.
# [06:56] <SimonSapin> the list in question: https://github.com/servo/servo/wiki/Relevant-spec-links#css-2
# [06:56] <TabAtkins> s/subsection/subsection of CSS2/
# [06:57] <TabAtkins> Topic: Obsoleting css3-linebox
# [06:57] <dauwhe> http://www.w3.org/TR/css3-linebox/
# [06:58] <TabAtkins> TabAtkins: Tav from SVG keeps landing on this spec and it confuses him. Can we fix it.
# [06:58] <TabAtkins> fantasai: We're going to redirect this to css-inline-3.
# [06:58] <TabAtkins> fantasai: I think it was supposed to be published when we did the last draft of dropcaps, but looks like next draft.
# [06:58] <TabAtkins> TabAtkins: So when's the timeline?
# [06:59] <TabAtkins> TabAtkins: If it's gonna be this month, fine, otherwise do a note for now.
# [06:59] <TabAtkins> dauwhe: Let's just do the note now.
# [06:59] <TabAtkins> RESOLVED: Ask Chris to put an obsoletion notice on the current css3-linebox on TR.
# [07:00] <TabAtkins> dbaron: I wish I'd at some point published the linebox edits as a WD.
# [07:00] <TabAtkins> dbaron: No idea where it went now.
# [07:00] <TabAtkins> dbaron: It's not in the draft repo as css-linebox.
# [07:01] <TabAtkins> Topic: New publication system
# [07:02] * dauwhe disposition of genders?
# [07:02] <TabAtkins> ChrisL: Existing publication system is a piece of shit.
# [07:02] <TabAtkins> ChrisL: It takes html => tidy => xhtml => php => composter, produces error messages as a primary function
# [07:03] <TabAtkins> ChrisL: Then when it's free of error messages, ask someone else to do the same exact thing and disagree iwth you.
# [07:03] <TabAtkins> ChrisL: This is not a good model.
# [07:03] <TabAtkins> ChrisL: Replacing it with echidna.
# [07:03] * astearns the new process will lay eggs
# [07:03] * dauwhe http://echidneofthesnakes.blogspot.com.au
# [07:03] <TabAtkins> ChrisL: The source tool is in github so you can look at it, change it, etc
# [07:04] <TabAtkins> ChrisL: Been in alpha, apart to go into public beta (tomorrow, hopefully, or today in australia, who knows)
# [07:04] <TabAtkins> ChrisL: Been testing it today with css3-ui.
# [07:04] <TabAtkins> ChrisL: It's cursed though. Breaks everything.
# [07:04] * fantasai seriously wishes we had a tape recorder going for Chris's speech
# [07:04] <TabAtkins> ChrisL: Benefits:
# [07:04] <TabAtkins> ChrisL: Publish any day. All 7 days.
# [07:04] <tantek> this is what happens when systems pay attention to invisible metadata :P
# [07:04] <TabAtkins> ChrisL: Can publish multiple times per day; last per day will be retained.
# [07:05] <TabAtkins> ChrisL: Downsides: first beta won't do CR, only WD.
# [07:05] <TabAtkins> ChrisL: It won't do cross-WG publications yet.
# [07:05] <TabAtkins> ChrisL: Those'll be worked on.
# [07:05] * Joins: pjrm (~pjrm@public.cloak)
# [07:05] <TabAtkins> ChrisL: But no FXTF stuff yet.
# [07:05] <TabAtkins> ChrisL: No human in the way to complain about your stylesheet.
# [07:05] <TabAtkins> astearns: "last per day will be retained"?
# [07:06] <TabAtkins> ChrisL: If you publish and notice a problem, you can jsut fix it and nobody will know.
# [07:06] <TabAtkins> ChrisL: But with more than 24 hours, you're screwed.
# [07:06] <TabAtkins> heycam: Does anyone get the right to push the button?
# [07:06] <TabAtkins> fantasai: Everyone but Tab.
# [07:06] <TabAtkins> ChrisL: Anyone can. There's a token system? I don't understand it well.
# [07:06] <dbaron> Chris: Boston Time
# [07:07] <TabAtkins> ChrisL: afaik there's nothing preventing chairs from giving it to the editors.
# [07:07] * dbaron wonders which timezone it will be in if Suffolk County and Middlesex County end up in different timezones
# [07:07] <tantek> heycam: is there documentation?
# [07:07] <TabAtkins> heycam: Any docs?
# [07:07] <tantek> ChrisL: HAHAHAHA
# [07:07] <TabAtkins> ChrisL: Yes, somewhat.
# [07:07] <TabAtkins> ChrisL: I'll find it.
# [07:07] <dbaron> https://github.com/w3c/echidna
# [07:07] <tantek> ChrisL: there is a link to a link to a ^^^
# [07:07] <dbaron> https://github.com/w3c/echidna/wiki
# [07:08] <TabAtkins> krit: If something goes wrong, will someone fix it?
# [07:08] * Joins: Yves (ylafon@public.cloak)
# [07:08] * glazou notes aussies call those species of birds them kiwis not wikis, ahem
# [07:08] <TabAtkins> ChrisL: Yeah, it's an official systeam product, they'll fix it.
# [07:08] * Yves sets mode: +o glazou
# [07:08] * Parts: Yves (ylafon@public.cloak) (Yves)
# [07:08] <TabAtkins> SimonSapin: Does that mean we can have max-width:50em on our stylesheets?
# [07:08] <TabAtkins> ChrisL: Don't know. As long as the checker doesn't complain, you can probably get away with it.
# [07:10] <TabAtkins> ChrisL: Currently something we have to take out when we publish is the tests script.
# [07:10] * dauwhe actual issue title with Echidne: "Smash the pyramid of doom in app.js with a hammer"
# [07:10] <TabAtkins> ChrisL: W3C is now allowing those scripts, and not under the directory it's pbulished in.
# [07:10] <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.
# [07:11] <TabAtkins> ChrisL: Bert is maintaining mathjax, Peter will maintain the results script, and I'll talk to Lea about prism.js.
# [07:11] <TabAtkins> ChrisL: So over time there'll be several approved scripts people can just use.
# [07:12] <TabAtkins> krit: Can we get a `bikeshed publish` command?
# [07:12] <TabAtkins> ChrisL: Sure, probably.
# [07:12] <TabAtkins> tantek: When will we see the first draft?
# [07:12] <TabAtkins> ChrisL: Maybe tomorrow.
# [07:14] <TabAtkins> tantek: How long until we can publish CRs, joint work, etc.
# [07:14] <TabAtkins> ChrisL: A few months.
# [07:14] <TabAtkins> astearns: Since FPWDs trigger review too, does that mean they can't do it yet either?
# [07:14] <TabAtkins> ChrisL: Dunno. Probably.
# [07:14] <ChrisL> rrsagent, here
# [07:14] <RRSAgent> See http://www.w3.org/2015/02/08-css-irc#T06-14-26
# [07:14] <TabAtkins> Topic: Upcoming meeting dates and locations
# [07:15] <TabAtkins> glazou: Next meeting is confirmed in New York, 18-20 May.
# [07:15] <astearns> https://wiki.csswg.org/planning/new-york-2015
# [07:15] <TabAtkins> glazou: We still have to discuss end of august.
# [07:15] <ChrisL> some documentation https://github.com/w3c/echidna/wiki/How-to-use-Echidna#current-limitations
# [07:16] <TabAtkins> TabAtkins: People tell me Zurich is a hellhole in August.
# [07:16] <TabAtkins> dbaron: And it's gotten very expensive lately.
# [07:16] <ChrisL> echidna on github https://github.com/w3c/echidna
# [07:16] <TabAtkins> TabAtkins: Right. >So what about Paris?
# [07:16] <TabAtkins> dbaron: Note that everyone leaves Paris in August.
# [07:17] <TabAtkins> TabAtkins: So cheap hotels?
# [07:17] <TabAtkins> dbaron: Also some restaurants will be closed.
# [07:17] <liam> no, because people from other countries flood in, just as the French fgo to Italy and the Italians all go to Greece :)
# [07:18] <TabAtkins> TabAtkins: So it sounds like Paris si the best idea.
# [07:18] <TabAtkins> [general assent]
# [07:18] <ChrisL> in case anyone wondered, our cuddly new publication system is named after this http://answersafrica.com/wp-content/uploads/2013/10/echidna2.jpg
# [07:18] <TabAtkins> plinss: Let's nail down dates. Currently Aug 24-28 blocked out.
# [07:19] <TabAtkins> dino: What about houdini?
# [07:21] <TabAtkins> Rossen: 1-2 days. We'll work it out on the ML.
# [07:25] <TabAtkins> TabAtkins: So, suggestion from Tantek is that Firefox hosts Paris August instead, and Google just does Sydney again next Feb.
# [07:25] <tantek> TabAtkins, well, it was more of a floated idea to consider
# [07:27] <tantek> TabAtkins, dual motion
# [07:27] <TabAtkins> RESOLVED: Moz does August meeting in Paris.
# [07:27] <dbaron> SimonSapin, re the room in paris, both double-check with Shannon *and* book the room in the calendar
# [07:28] <SimonSapin> dbaron, will do
# [07:28] <TabAtkins> TabAtkins: Dates!
# [07:28] <TabAtkins> Florian: Suggest 24-26
# [07:29] <TabAtkins> szilles: Possible conflict on 24, maybe do 25-27
# [07:29] * @glazou will skip that one
# [07:29] <TabAtkins> heycam: Next scheduled SVG meeting is June in Sweden.
# [07:30] <TabAtkins> heycam: Don't think we're meeting between then and TPAC.
# [07:30] <TabAtkins> RESOLVED: Provisionally accept Aug 25-27 (Tue-Thu) as the meeting dates.
# [07:31] <TabAtkins> tantek: Tentatively block out next Feb meeting as first week of Feb?
# [07:31] <TabAtkins> RESOLVED: Pencil in week of Feb 1st for 2016 meeting.
# [07:31] <TabAtkins> SimonSapin: Feb 1st is FOSDEM.
# [07:31] <tantek> with Google hosting in Sydney
# [07:31] <TabAtkins> glazou: I can't do after Feb 20
# [07:32] <tantek> getting away from Valentine's Day is a plus
# [07:32] <TabAtkins> ChrisL: That'll conflict with my 20th wedding anniversary.
# [07:33] <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.
# [07:33] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [07:34] <@glazou> « girlfriend of a standards’ freak, lone evenings »
# [07:34] * Parts: @glazou (~glazou@public.cloak) (glazou)
# [07:34] <TabAtkins> ADJOURNED
# [07:35] <TabAtkins> <br dur="until May">
# [07:35] * liam :D
# [07:38] * Joins: glazou (~glazou@public.cloak)
# [07:39] <Rossen> br { @extends .break; action: resume; }
# [07:39] <shane> ScribeNick: shane
# [07:39] <shane> dbaron: discussion on the mailing list - agreed on line height rules. But it's not in the spec yet.
# [07:39] <shane> fantasai: it seemed like that made sense.
# [07:39] <shane> fantasai: will try to write it up and grasp it fully.
# [07:40] <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
# [07:40] <shane> xidorn: open bug about how height in ruby base container can be determined
# [07:41] <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.
# [07:41] <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
# [07:41] <shane> dbaron: ok with that
# [07:41] <shane> dbaron: part that's weird is sizing of the content box is not like an inline
# [07:42] <shane> fantasai: right. Sizing of content box should include margin boxes of all of the bases
# [07:42] <shane> dbaron: is that because you don't like how inlines work?
# [07:42] <shane> fantasai: don't like that margins don't effect layout for those.
# [07:42] <shane> fantasai: if you put borders on ruby bases, having that not effect position of ruby text seems wrong
# [07:43] <shane> fantasai: how does the author get it right then? line height?
# [07:43] <shane> dbaron: fine with it to move the ruby text
# [07:43] <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
# [07:44] <shane> dbaron: if you don't want line height to effect ruby position that makes sense
# [07:44] <shane> SteveZ: but ruby has to effect line height
# [07:44] <shane> dbaron: I'm OK with that.
# [07:44] <shane> xidorn: does vertical align property effect ruby text?
# [07:44] <shane> fantasai: yes
# [07:44] <shane> xidorn: but how?
# [07:44] <shane> fantasai: don't remember scoping. Ruby text at same annotation level with align with each other.
# [07:45] <shane> dbaron: so basically ruby text container acts like a line for purposes of alignment
# [07:45] <shane> SteveZ: so what connects lines?
# [07:45] <shane> SteveZ: will I get strange behaviour if I put non-ruby stuff between two things?
# [07:46] <shane> SteveZ: e.g. underlines don't jump around. Concerned that ruby might act different. I don't know what should happen though.
# [07:46] <shane> fantasai: <draws on board>
# [07:46] <shane> SteveZ: what if one of the letters was bigger?
# [07:46] <shane> fantasai: <more drawing>
# [07:47] <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
# [07:48] <shane> SteveZ: why isn't the ruby text box a line box the whole line long?
# [07:49] <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.
# [07:50] <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.
# [07:51] <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.
# [07:51] <shane> dbaron: I think what you're saying makes sense. More complicated but OK. Put in spec please?
# [07:51] <shane> fantasai: what's not in the spec?
# [07:51] <shane> dbaron: vertical alignmnt
# [07:51] <shane> fantasai: I'll just check
# [07:52] <shane> fantasai: I need to fix that then
# [07:52] <shane> dbaron: that's biggest set of issues I was worried about.
# [07:52] <shane> dbaron: would like to see spec edits resulting from discussion with xidorn and kochii though.
# [07:52] <shane> fantasai: couple of hard issues
# [07:54] <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.
# [07:54] <shane> Florian: that's not something we can fix
# [07:54] <shane> fantasai: yes, HTML people don't like autogenerating tags
# [07:54] <shane> fantasai: that's the issue I haven't really figured out how to solve.
# [07:55] <shane> dbaron: is it possible to say that the whitespace goes away but that there are other spacing rules for ruby text?
# [07:55] <shane> dbaron: e.g. what script they're in, whether script has a certain property.
# [07:55] <shane> dbaron: e.g. newlines go away in Chinese
# [07:55] <shane> SteveZ: does that mean you want to put another character than whitespace in?
# [07:56] <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
# [07:56] <shane> fantasai: issue is that we want font set on the outer box but instead it's set on the inner boxes
# [07:57] <shane> Florian: can we reverse-propagate style to the parent?
# [07:57] <shane> dbaron: never done it before
# [07:57] <shane> astearns: any other reason we'd want to style the text container?
# [07:57] <shane> fantasai: possibly?
# [07:57] <shane> fantasai: we do forbid you from making ruby text and ruby base containers visible.
# [07:58] <shane> fantasai: this is because some impls will want an internalized structure that's different from the CSS hierarchy
# [07:58] <shane> fantasai: styling those boxes isn't an important use case.
# [07:58] <shane> fantasai: should be fine to have different internal model
# [07:58] <shane> fantasai: so boxes aren't directly detectable, can only inherit properties through them
# [07:59] <shane> astearns: can you say line height of container is max line height of children?
# [07:59] <shane> SteveZ: that doesn't work. Really want to set it to font size of children
# [07:59] <shane> SteveZ: only concerned about whitespace between?
# [07:59] <shane> fantasai: yeah everything else is wrapped
# [08:00] <shane> Rossen: is this really a common use case?
# [08:00] <shane> fantasai: it isn't an error condition but it isn't common
# [08:01] <shane> SteveZ: classic one is where you have double ruby (english + ??). English one would need the spaces.
# [08:01] <shane> SteveZ: would be common in English ruby
# [08:01] <shane> fantasai: not sure what the rules are in pinyin
# [08:01] * Quits: hyojin (~hyojin@public.cloak) ("Page closed")
# [08:02] <shane> Florian: some syllables need to be separated by an apostrophe if there isn't a space. Otherwise it's stylistic
# [08:02] <shane> Florian: if the only purpose of propagating up is to propagate back down again that seems like the least bad idea
# [08:02] * TabAtkins will not rest until we have triple ruby (using 3d transforms?!?)
# [08:02] <shane> fantasai: agreed. I'll use that for now. If anyone thinks of something better can change it.
# [08:03] <shane> fantasai: next issue. Webkit has a special keyword for ruby-font-size. Inter-character generates smaller font than above or below.
# [08:03] <shane> fantasai: resolved as locale-specific rule in stylesheet for ruby
# [08:03] <shane> Florian: is by language not by script. Close enough?
# [08:04] <shane> fantasai: can do it by lang. Can set font size explicitly if a problem. This is just for default size.
# [08:04] <shane> Florian: OK
# [08:05] <shane> RESOLVED: use locale-specific :lang rules instead of something like webkit-ruby-size.
# [08:06] <shane> fantasai: next issue. Ruby-position property had 2 keywords for position in horizontal text and for vertical text.
# [08:07] <shane> fantasai: suggestion was to simplify to a single keyword for both (over, under, inter-character)
# [08:07] <shane> dino: we have after, before, inter-character
# [08:07] * leaverou_away is now known as leaverou
# [08:08] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [08:08] <Florian> http://upload.wikimedia.org/wikipedia/commons/c/c7/Hunmin_jeong-eum.jpg
# [08:08] <shane> fantasai: over means right, under left, and inter-character same as over for vertical text
# [08:08] <shane> Florian: this example shows inter-character for vertical text
# [08:08] <shane> fantasai: can extend back to two keywords if necessary
# [08:08] <shane> fantasai: but this is the common case
# [08:08] <shane> fantasai: can we resolve to do this?
# [08:09] <shane> scribenick TabAtkins
# [08:09] <TabAtkins> NOOOOOOOOOOOO
# [08:09] <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.
# [08:09] <TabAtkins> fantasai: That's why we had two values, but Xidorn says we dont' need them.
# [08:10] <TabAtkins> xidorn: I don't see any left cases.
# [08:10] <TabAtkins> xidorn: You don't have any pictures of left.
# [08:10] <TabAtkins> xidorn: I don't know what use-cases you've found.
# [08:10] <TabAtkins> fantasai: This is stuff I inherited from the previous editro.
# [08:11] <TabAtkins> fantasai: The difference between over/under is.
# [08:11] <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.
# [08:11] <TabAtkins> fantasai: But over/under depend on what way text is rotated, not block-flow direction.
# [08:12] <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.
# [08:12] <TabAtkins> dbaron: What was the two-value syntax?
# [08:12] <xidorn> [over|under|inter-character] || [left|right]
# [08:12] <TabAtkins> fantasai: Would let you specify left|right as well, so one's for horizontal and one's for vertical writing.
# [08:12] <TabAtkins> Florian: The current proposal combines them.
# [08:13] <TabAtkins> RESOLVED: ruby-position simplified to over|under|inter-character
# [08:14] <TabAtkins> fantasai: Next is default value of ruby-align
# [08:14] <TabAtkins> fantasai: Two values are center and space-around.
# [08:14] <TabAtkins> fantasai: space-around is a justification value.
# [08:14] <TabAtkins> fantasai: It'd space around at the justificatoin opportunities.
# [08:15] <TabAtkins> fantasai: So latin text would stay together, but Chinese would be able to split between each char.
# [08:15] <TabAtkins> fantasai: So we set the initial value to space-around.
# [08:15] <TabAtkins> fantasai: Problem is that bopomofo can be justified, but bopomofo ruby should be centered by default (due to language users preference).
# [08:15] <TabAtkins> fantasai: 1) change initial value to center
# [08:16] <TabAtkins> fantasai: Reset it for Japanese to be space-around in the UA stylesheet.
# [08:16] <TabAtkins> fantasai: 2) Keep it as space-around, reset it for chinese to center.
# [08:17] <TabAtkins> fantasai: 3) Have a value that does custom justifications - auto - which justifies between Han and Kana, and not between bopomofo.
# [08:17] <TabAtkins> fantasai: I prefer 2
# [08:17] <TabAtkins> s/I prefer 2/Spec is currently 2/
# [08:17] <TabAtkins> fantasai: But multi-word ruby you may not want to justify spaces, so maybe 1/3.
# [08:17] <TabAtkins> fantasai: It seems only Han/Kana should be justifying.
# [08:17] <TabAtkins> TabAtkins: 1 seems simple then.
# [08:18] <TabAtkins> szilles: 3 is the classic way we do it, but it requires magic.
# [08:18] * Quits: nikos (~uid28403@public.cloak) ("Connection closed for inactivity")
# [08:18] <TabAtkins> fantasai: I don't think 3 is too magic, but 1 is definitely simpler.
# [08:18] <TabAtkins> fantasai: Main concern with 1 is "do we have a concern with legacy untagged content?"
# [08:19] <TabAtkins> szilles: 3 is script-based
# [08:19] <TabAtkins> szilles: Why is 1 better?
# [08:19] <TabAtkins> fantasai: Simpler. 1 is just a 1-line fix to your UA stylesheet; 3 is effectively a new jsutification algo.
# [08:20] <TabAtkins> TabAtkins: Can we just do 1 unless we see evidence of brekage in the wild?
# [08:20] <TabAtkins> fantasai: Dunno what Koji wants. Let's do 1 unless Koji dissents.
# [08:21] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [08:21] <TabAtkins> RESOLVED: Either option 1 or 3 for ruby-position, at editor's discretion.
# [08:21] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [08:21] * heycam is now known as heycam|away
# [08:21] * Quits: dino (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
# [08:21] <TabAtkins> ADJOURN FOR REALZIES THIS TIME
# [08:22] * Joins: dauwhe (~dauwhe@public.cloak)
# [08:22] * Quits: xidorn (~upsuper@public.cloak) (Client closed connection)
# [08:22] * Quits: ChrisL (clilley@public.cloak) ("Client combusted")
# [08:23] * Quits: kwkbtr (~kwkbtr@public.cloak) ("")
# [08:23] * Quits: glazou (~glazou@public.cloak) (glazou)
# [08:28] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [08:29] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [08:29] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [08:30] * Quits: AndreyR (~AndreyR@public.cloak) (Ping timeout: 180 seconds)
# [08:30] * Rossen is now known as Rossen_away
# [08:32] * Quits: tantek (~tantek@public.cloak) (tantek)
# [08:32] * Quits: roc (~chatzilla@public.cloak) (Client closed connection)
# [08:38] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [08:39] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [09:01] * Quits: pjrm (~pjrm@public.cloak) (Ping timeout: 180 seconds)
# [09:14] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:29] * Joins: tantek (~tantek@public.cloak)
# [09:31] * Joins: lajava (~javi@public.cloak)
# [09:34] * Joins: zcorpan (~zcorpan@public.cloak)
# [09:36] * Quits: tantek (~tantek@public.cloak) (tantek)
# [09:46] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [09:54] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [09:59] * Joins: lajava (~javi@public.cloak)
# [10:08] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [10:19] * Joins: antonp (~Thunderbird@public.cloak)
# [10:39] * Joins: zcorpan (~zcorpan@public.cloak)
# [10:59] * Quits: jet (~uid49872@public.cloak) ("Connection closed for inactivity")
# [11:02] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [11:05] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [11:06] * Joins: svillar (~sergio@public.cloak)
# [11:10] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [11:10] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [11:11] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [11:12] <koji> fantasai: oh, noooo, please...
# [11:17] <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?
# [11:47] * Joins: pjrm (~pjrm@public.cloak)
# [12:07] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [12:12] * Joins: glazou (~glazou@public.cloak)
# [12:14] * Quits: glazou (~glazou@public.cloak) (glazou)
# [12:19] * Joins: dauwhe (~dauwhe@public.cloak)
# [12:20] * Joins: lajava (~javi@public.cloak)
# [12:32] * Quits: pjrm (~pjrm@public.cloak) (Ping timeout: 180 seconds)
# [12:35] * Joins: dbaron (~dbaron@public.cloak)
# [12:39] * Quits: dauwhe (~dauwhe@public.cloak) ("")
# [12:42] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [13:00] * Joins: Florian (~Florian@public.cloak)
# [13:00] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [13:09] * Joins: tantek (~tantek@public.cloak)
# [13:10] * Joins: Florian (~Florian@public.cloak)
# [13:11] * Quits: svillar (~sergio@public.cloak) ("Ex-Chat")
# [13:20] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [13:38] * Joins: svillar (~sergio@public.cloak)
# [13:44] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [13:48] * Joins: tantek (~tantek@public.cloak)
# [14:03] * Joins: plh (plehegar@public.cloak)
# [14:11] * Rossen_away is now known as Rossen
# [14:18] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [14:18] * Joins: Florian (~Florian@public.cloak)
# [14:31] * Rossen is now known as Rossen_away
# [14:53] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [15:02] * Quits: stryx` (~stryx@public.cloak) (Ping timeout: 180 seconds)
# [15:02] * Quits: tantek (~tantek@public.cloak) (Client closed connection)
# [15:02] * Joins: tantek (~tantek@public.cloak)
# [15:08] * Joins: stryx` (~stryx@public.cloak)
# [15:14] <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?
# [15:22] <koji> fantasai: oh, that's what you added 3 days ago, ok...
# [15:23] * Quits: tantek (~tantek@public.cloak) (tantek)
# [15:25] * Joins: lajava (~javi@public.cloak)
# [15:52] * Quits: svillar (~sergio@public.cloak) (Ping timeout: 180 seconds)
# [15:55] * Joins: svillar (~sergio@public.cloak)
# [15:55] * Quits: Ms2ger (~Ms2ger@public.cloak) ("bbl")
# [16:28] * Joins: thinkxl (~thinkxl@public.cloak)
# [17:25] * Rossen_away is now known as Rossen
# [17:35] * Rossen is now known as Rossen_away
# [17:54] * Joins: Florian (~Florian@public.cloak)
# [17:56] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [17:56] * Quits: svillar (~sergio@public.cloak) (Ping timeout: 180 seconds)
# [18:01] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [18:05] * Joins: tantek (~tantek@public.cloak)
# [18:11] * Quits: thinkxl (~thinkxl@public.cloak) ("Lingo: www.lingoirc.com")
# [18:14] * Quits: renoirb (renoirb@public.cloak) ("Gone AFK to take some rest")
# [18:14] * Joins: estellevw (~estellevw@public.cloak)
# [18:39] * Joins: adenilson (~anonymous@public.cloak)
# [18:42] * Joins: lajava (~javi@public.cloak)
# [18:43] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [19:50] * Joins: bcampbell (~chatzilla@public.cloak)
# [20:07] * Quits: tantek (~tantek@public.cloak) (tantek)
# [21:23] * Joins: johanneswilm (~johannes@public.cloak)
# [21:33] * Quits: bcampbell (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [22:20] * Joins: bcampbell (~chatzilla@public.cloak)
# [22:21] * Quits: bcampbell (~chatzilla@public.cloak) ("ChatZilla 0.9.91.1 [Firefox 31.4.0/20150105205548]")
# [22:24] * Joins: Florian (~Florian@public.cloak)
# [22:32] <SimonSapin> koji, fantasai: shouldn’t UA rules go into https://html.spec.whatwg.org/multipage/rendering.html ?
# [22:40] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [22:45] * Joins: tantek (~tantek@public.cloak)
# [22:45] * Quits: tantek (~tantek@public.cloak) (tantek)
# [22:50] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [22:50] * Joins: Florian (~Florian@public.cloak)
# [22:52] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [22:52] * Joins: Florian (~Florian@public.cloak)
# [22:52] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [23:00] * Joins: Florian (~Florian@public.cloak)
# [23:02] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [23:03] * Joins: glazou (~glazou@public.cloak)
# [23:03] * Joins: Florian (~Florian@public.cloak)
# [23:05] * heycam|away is now known as heycam
# [23:10] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [23:11] * Joins: dbaron (~dbaron@public.cloak)
# [23:14] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [23:14] <ed> we'll be using #fx today for minuting
# [23:15] * liam changes 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 )'
# [23:15] * Joins: nikos (~uid28403@public.cloak)
# [23:15] * Joins: dino (~textual@public.cloak)
# [23:16] * Joins: tantek (~tantek@public.cloak)
# [23:17] * Joins: Florian (~Florian@public.cloak)
# [23:17] * Joins: murakami (~murakami@public.cloak)
# [23:20] * Joins: AndreyR (~AndreyR@public.cloak)
# [23:22] * Joins: smfr (~smfr@public.cloak)
# [23:24] * Joins: johanneswilm (~johannes@public.cloak)
# [23:24] * Quits: murakami (~murakami@public.cloak) ("Page closed")
# [23:25] * Joins: murakami (~murakami@public.cloak)
# [23:25] * Joins: roc (~chatzilla@public.cloak)
# [23:26] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [23:26] * Joins: stakagi (~stakagi@public.cloak)
# [23:27] * Quits: stakagi (~stakagi@public.cloak) ("Leaving...")
# [23:27] * Joins: stakagi (~stakagi@public.cloak)
# [23:27] * Joins: dbaron (~dbaron@public.cloak)
# [23:30] * Joins: xidorn (~upsuper@public.cloak)
# [23:31] <fantasai> Topic: SVG Sizing and box-sizing
# [23:31] <fantasai> ScribeNick: fantasai
# [23:31] <fantasai> We're looking at some testcases from Tantek
# [23:31] <fantasai> Current testcase is SVG image with width=100 viewBox="0 0 100 100"
# [23:31] <SimonSapin> fantasai, heycam is scribing in #fx
# [23:31] <fantasai> oh
# [23:32] <fantasai> that' swhy I can't see anything :)
# [23:32] * Joins: jet (~uid49872@public.cloak)
# [23:35] * Quits: AndreyR (~AndreyR@public.cloak) (Ping timeout: 180 seconds)
# [23:38] * jet is now known as jet|aus
# [23:39] * jet|aus is now known as jet
# [23:45] <fantasai> koji: ping me when you're online, let's talk about ruby :)
# [23:53] * Joins: hyojin (~hyojin@public.cloak)
# Session Close: Wed Feb 11 00:00:00 2015

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn