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

Options:

# Session Start: Mon Feb 09 00:00:00 2015
# Session Ident: #css
# [00:00] <tantek> plinss: css-sizing?
# [00:00] <tantek> tantek: put it overflow
# [00:00] <tantek> Rossen: put sizing Monday afternoon
# [00:01] <tantek> plinss: Ruby?
# [00:01] <tantek> glazou: upcoming meetings end of Tue afternoon
# [00:02] <tantek> glazou: new publication system before that
# [00:02] <tantek> plinss: visible control characters?
# [00:03] <tantek> gregwhitworth: visible control characters part of text
# [00:03] <tantek> plinss: we have an agenda?
# [00:03] <tantek> glazou: how much time for 2.1 issues
# [00:03] <tantek> Rossen: 11 years
# [00:03] <tantek> … give or take
# [00:04] <tantek> (display futzing)
# [00:05] <tantek> glazou: first topic, 2.1 issues
# [00:05] <tantek> fantasai: first issue, who will make the edits?
# [00:05] <tantek> TabAtkins: it's in github now so anyone can do it
# [00:05] <tantek> fantasai: I nominate SimonSapin
# [00:05] <tantek> glazou: that's it?
# [00:05] <tantek> dbaron: I had an issue I meant to send email about
# [00:05] <tantek> … just sent 30 seconds ago
# [00:06] <tantek> dbaron: I don't know if anyone would have understood it anyway
# [00:06] <tantek> … since it is margin collapsing
# [00:06] <tantek> glazou: do we need to call Håkon?
# [00:06] <dbaron> https://lists.w3.org/Archives/Public/www-style/2015Feb/0189.html
# [00:06] <tantek> dbaron: let's try to talk about this
# [00:06] <Florian> s/Håkon/Anton/
# [00:06] <tantek> … one of the discussions about margin collapsing
# [00:06] <tantek> … we decided the prose in the spec was not very clear about transitivity
# [00:07] <tantek> … e.g. if A collapse with B, and B collapse C, then A collapse with C
# [00:07] <tantek> … if that's not true we need to define what it means
# [00:07] <tantek> ???: what makes you think it is not true?
# [00:07] <tantek> dbaron: this guy writing reftest for margin collapsing daniels
# [00:07] * Joins: hyojin (~hyojin@public.cloak)
# [00:07] <tantek> … does not believe this is true
# [00:07] <tantek> … and a bunch of his tests match browser behavior
# [00:07] <tantek> … I was trying to fix a bug
# [00:08] <tantek> … that said min-height and max-height do not break margin-collapsing between the last child of a block and the ...
# [00:08] * astearns we should find more testers that disbelieve common assumptions
# [00:08] <tantek> … min-height and max-height, even when they change the height, do not break margin-collapsing between the bottom margin of the last child of the block, and the bottom margin of the block
# [00:08] <tantek> … I wrote a patch that fixed that
# [00:08] <tantek> … it fixed those tests, but broke one other test
# [00:09] <tantek> … that was interop in all engines
# [00:09] <tantek> … however I could not figure out how the spec justifies that result
# [00:09] <tantek> … What I'd like to know is, why does this test behave the way it does?
# [00:09] <tantek> … either in engines or in the spec
# [00:09] <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Feb/0189.html
# [00:09] <dbaron> https://lists.w3.org/Archives/Public/www-style/2015Feb/att-0189/block-no-content-8.html
# [00:09] <tantek> … test: https://lists.w3.org/Archives/Public/www-style/2015Feb/att-0189/block-no-content-8.html
# [00:10] <tantek> … reference: https://lists.w3.org/Archives/Public/www-style/2015Feb/att-0189/block-no-content-8-ref.html
# [00:10] <tantek> dbaron: key question is gap between 2 and 3rd block
# [00:10] <tantek> … 60 px between blocks 1,2
# [00:10] <tantek> … 40 px between blocks 2, 3
# [00:10] <tantek> … my patch makes it 60 px between blocks 2, 3
# [00:10] <tantek> … but spec appears to say it should be -20px between blocks 2,3
# [00:11] <tantek> … every margin in the test should collaps
# [00:11] <tantek> s/collaps/collapse
# [00:11] <tantek> dbaron: the interesting question is what happens between the green blocks
# [00:12] <tantek> … blue has a min-height and a child
# [00:12] <tantek> … spec says if it did not have a child, it's top / bottom margins would not collapse
# [00:12] <tantek> … if you have a non-zero min-height and no children then margins do not collapse
# [00:13] <tantek> … but in this case we have a block with min-height with a child
# [00:13] <tantek> … all have top/bottom margins
# [00:13] <tantek> … spec says they should all collapse
# [00:13] <tantek> TabAtkins: is the confusing line why min-height has an effect with no children?
# [00:13] <tantek> dbaron: spec's wording is weird, but I think I understand why
# [00:14] <tantek> fantasai: (reads from 2.1 spec re: margin-collapsing)
# [00:15] <tantek> dbaron: the thing with the min-height only applies when there's no children
# [00:16] <tantek> florian: I'm actually confused, what can it mean for the top/bottom margin of the parent to collapse?
# [00:16] <tantek> dbaron: there's a rule elsewhere that says where the block is when its top & bottom margins collapse
# [00:16] <tantek> florian: is this useful for a block of non-zero height?
# [00:16] <tantek> florian: that seems just weird
# [00:17] <tantek> dbaron: yes. I would go further, not clear any use of top/bottom margins of the same block ever collapsing. but we're stuck with that
# [00:17] * astearns wants new shmargins that do not collapse
# [00:17] <tantek> florian: to do so when the block has non-zero height is even worse
# [00:17] * glazou wonders if we should apologize to observers for such a first ftf topic :-D
# [00:17] * tantek glazou "initiation"
# [00:18] * tantek glazou "And then we told them, let's talk about margin collapsing."
# [00:18] * tantek glazou "I have been discussing margin collapsing since before your sun burned in the sky"
# [00:18] * Rossen the real hazing will begin when the float and overflow topic comes
# [00:18] * glazou tantek: hazing ?-)
# [00:18] <tantek> dbaron: (reads from 2.1 spec re: margin-collapsing)
# [00:18] <tantek> … (bullet 1, bullet 2)
# [00:19] * TabAtkins approves of the shm* naming pattern for new properties that are more rational versions of old ones.
# [00:19] * glazou « i was allowed to observe their meeting and then all my margins suddenly collapsed »
# [00:19] * TabAtkins is still angling for shmotate and shmansform.
# [00:20] * shane is concerned that 'shm*' suddenly means 'rational'
# [00:20] * glazou TabAtkins ROFL !!! « margins, shmargins » could be Spaceballs’ sequel by Mel Brooks
# [00:21] * shane Shmaceballs...
# [00:21] * TabAtkins by Shmel Brooks.
# [00:21] * tantek suggests we add 'border-padding' that goes outside the border, and does not collapse
# [00:21] * glazou shane or shmace-balls ?-)
# [00:22] <tantek> fantasai: the issue is we did not want to do partial collapsing (re: min-height), and decided to just do the stupid (obvious) thing instead
# [00:22] * glazou tantek, wikipedia says « In Australian English, hazing is called bastardisation. »
# [00:22] <tantek> dbaron: I should do more playing around with this test case to see what happens in other browsers
# [00:22] <tantek> fantasai: what is the interop on?
# [00:23] <tantek> dbaron: this test case. 60 px above, 40px below
# [00:23] <tantek> dbaron: margins 3 & 4 are not collapsing
# [00:23] <tantek> fantasai: spec should say non-zero min-height means top/bottom margins do not collapse
# [00:23] <tantek> florian: partial collapsing?
# [00:23] * dauwhe Prince is not matching browers on this
# [00:23] <tantek> dbaron: I would fine if we modified the rule that ...
# [00:24] <tantek> dbaron: It would be consistent to modify the 3rd bullet point in the nested list
# [00:24] <tantek> … to say what it says already
# [00:24] * astearns margins, collapsing, partial collapsing, sub-partial collapsing epicycles
# [00:24] <tantek> … but add and "and the parent has zero computed min-height, or the bottom margin of the last inflow child does (not) collapse with the top margin of the element"
# [00:24] <tantek> s/top/bottom
# [00:25] <tantek> dbaron: 3rd bullet point
# [00:25] <tantek> … bottom margin of last inflow child
# [00:25] <tantek> … bottom margin of parent
# [00:25] <tantek> … no longer collapse
# [00:25] <tantek> … if the parent has non-zero min-height
# [00:25] * zcorpan 3rd bullet point is currently "bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height "
# [00:25] <tantek> … and the bottom margin of the last inflow child collapses with the top margin of the parent
# [00:25] * astearns and mercury is in retrograde
# [00:25] * tantek astearns not helping!
# [00:26] * tantek :P
# [00:26] * TabAtkins astearns: shmercury
# [00:26] * glazou remember, dbaron said “I just sent email about an issue… I don’t know if anyone would have understood it anyway, since it’s margin collapsing.”
# [00:26] <tantek> fantasai: (explores another possibility)
# [00:26] * tantek still has memories of the great margin collapse discussions of 2008
# [00:26] * tantek or was it 2002?
# [00:26] * liam wonders whether the XQuery/XSL f2f meetings in Prague he's also missing this week might be less shminsane than this one :)
# [00:27] <tantek> fantasai: there's two definitions
# [00:27] * glazou tantek don’t go that way, or you’ll be memed about 1978 too
# [00:27] <tantek> … there's a definition for collapsing
# [00:27] * dauwhe waves at liam
# [00:27] <tantek> … and a definition for adjoining
# [00:27] <tantek> dbaron: no that sentence below makes adjoining transitive
# [00:27] * liam waves back :)
# [00:28] <tantek> fantasai: we know what we want to say now
# [00:28] <tantek> … just need to work on phrasing it
# [00:28] <tantek> dbaron: I think agreeing on what we want to say should involve more testing of what browsers do
# [00:28] <tantek> fantasai: whatever it is it is an improvement over what's there
# [00:28] <tantek> … (in the spec)
# [00:28] <tantek> glazou: what is the resolution?
# [00:28] <tantek> fantasai: what dbaron said
# [00:29] <tantek> dbaron: we should tentatively agree to do that, but do more testing
# [00:29] <tantek> glazou: what do people think? there were only 3 people discussing
# [00:29] <tantek> glazou: any objection?
# [00:30] <tantek> RESOLVED: tentatively do what we agreed, pending more testing
# [00:30] <tantek> dbaron: I think the edit you fantasai proposed to make is already in the spec, the 3rd bullet.
# [00:30] <tantek> dbaron: the way this is written is unclear
# [00:30] <tantek> glazou: we have to move on
# [00:31] <tantek> glazou: continue working on the issues
# [00:31] <tantek> … or next topic
# [00:31] <tantek> … in terms of 2.1 issues, what else?
# [00:31] <tantek> glazou: dbaron @charset tests?
# [00:31] <glazou> https://lists.w3.org/Archives/Public/public-css-testsuite/2015Jan/0016.html
# [00:31] <tantek> dbaron: this was a message from hsivonen
# [00:32] <tantek> … syntax level 3 changes rules for @charset
# [00:32] <tantek> … there are tests in 2.1 repository
# [00:32] <tantek> … that now test incorrect behavior
# [00:32] <tantek> … we should fix the tests to match level 3
# [00:32] <tantek> … and errata 2.1 as well
# [00:32] <tantek> … it seems bad to have tests in the repo that are telling people to behave in a way not compat with level 3 latest spec
# [00:32] <tantek> glazou: I agree let's fix both
# [00:32] <tantek> fantasai: yes fix both
# [00:33] <tantek> ACTION dbaron: propose errata for @charset in 2.1 that brings it into alignment with CSS3 Syntax
# [00:33] * RRSAgent records action 1
# [00:33] * trackbot is creating a new ACTION.
# [00:33] <trackbot> Created ACTION-665 - Propose errata for @charset in 2.1 that brings it into alignment with css3 syntax [on David Baron - due 2015-02-15].
# [00:33] <fantasai> ACTION fantasai: propose errata for margin collapsing issue
# [00:33] * RRSAgent records action 2
# [00:33] * trackbot is creating a new ACTION.
# [00:33] <trackbot> Created ACTION-666 - Propose errata for margin collapsing issue [on Elika Etemad - due 2015-02-15].
# [00:33] <tantek> glazou: will hsivonen fix the tests?
# [00:33] <tantek> dbaron: probably?
# [00:33] <tantek> jet: he has an open question at the bottom
# [00:34] <tantek> fantasai: basically what we should be doing is errata'ing 2.1
# [00:34] <tantek> … and fixing the tests
# [00:34] <tantek> … backporting from 3 to 2
# [00:34] <tantek> … fixing the ones in 2
# [00:34] <tantek> … or getting rid of them
# [00:34] <tantek> glazou: we have versions
# [00:34] <tantek> fantasai: no we have levels
# [00:34] <tantek> glazou: anything else on the 2.1 radar?
# [00:34] <tantek> fantasai: dbaron?
# [00:35] <tantek> dbaron: just a possible tornado and a few thunderstorms
# [00:35] <tantek> SimonSapin: we discussed
# [00:35] <tantek> … links to that spec
# [00:35] <tantek> florian: so we should switch to snapshot topic
# [00:36] <SimonSapin> SimonSapin: In CSS 2.x sections, add links to newer specs that replace them
# [00:36] <tantek> zcorpan: anyone volunteer to edit the tests?
# [00:36] <tantek> florian: you just did
# [00:36] <tantek> zcorpan: I did? Ok I can do that
# [00:36] <tantek> ACTION zcorpan edit CSS 2.1 @charset tests to make them compliant with CSS3 syntax
# [00:36] * trackbot is creating a new ACTION.
# [00:36] <trackbot> Created ACTION-667 - Edit css 2.1 @charset tests to make them compliant with css3 syntax [on Simon Pieters - due 2015-02-15].
# [00:36] <glazou> Topic: Font Loading API
# [00:36] <tantek> heycam: test and tasks?
# [00:36] <astearns> http://dev.w3.org/csswg/css-font-loading/
# [00:36] <tantek> … (missed part of question)
# [00:37] <tantek> TabAtkins: good question
# [00:37] <tantek> heycam: there are many places in the spec where it says to queeue a task, and does not say why it is necessary, aor what the reuls are for why this operation should be done
# [00:37] <tantek> s/reuls/rules
# [00:37] <tantek> s/aor/or
# [00:38] <tantek> TabAtkins: every time I do something it is observable, so it doesn't happen in the middle of some script
# [00:38] <tantek> TabAtkins: you can't edit the font-faces attribute at some time because JS might be looking at that
# [00:38] <tantek> heycam: for operations that are definitely going to wait for the network that makes sense
# [00:38] <tantek> … but there are uses of that beyond wait for the network
# [00:38] <tantek> TabAtkins: in the font-face loading algorithm
# [00:38] <tantek> … we have two uses of delay task until parsing the font-data is done
# [00:39] <tantek> … or parsing of strings too
# [00:39] <tantek> heycam: parsing strings is pretty weak(?)
# [00:39] <tantek> TabAtkins: I purposely moved those into the async section of the algorithm, and from the async section I cannot sync update something that is script visible.
# [00:39] <tantek> TabAtkins: I have to queue a task
# [00:39] <astearns> s/weak/quick/
# [00:40] <zcorpan> s/weak(?)/quick/
# [00:40] <tantek> heycam: can we discuss open issues in the spec?
# [00:40] <tantek> heycam: issue 1: is about promise objects and internal set objects
# [00:40] <tantek> … pristine copies of things
# [00:40] <astearns> issue 1: http://dev.w3.org/csswg/css-font-loading/#issue-531209c4
# [00:40] * trackbot doesn't understand that ISSUE command.
# [00:40] <tantek> heycam: that is not something the webIDL spec says ...
# [00:40] <tantek> heycam: should happen automatically(?)
# [00:41] <tantek> heycam: the other three issues I don't have an opinion on so we don't have to discuss them
# [00:41] <tantek> heycam: another thing - question the usefulness of font-face-set being constructable, why you would want to do it?
# [00:41] <tantek> TabAtkins: I know I had reasons for it, I think related to workers
# [00:41] <tantek> TabAtkins: someone internally gave me a use case recently
# [00:41] <tantek> … stash a bunch of fonts into a font-face-set, tell when they're ready,
# [00:42] <tantek> … all the fonts loaded at the same time
# [00:42] <tantek> heycam: could you not do that by creating separate font face objects
# [00:42] <tantek> … do a promise.all?
# [00:42] <tantek> TabAtkins: maybe?
# [00:42] <tantek> … if there's no reason not to make something constructable, there's no reason to make it constructable
# [00:42] <tantek> heycam: it would complicate my implementation
# [00:42] <tantek> TabAtkins: so basically I should look for more use-cases for it
# [00:42] <tantek> zcorpan: queue and task discussion
# [00:43] * glazou « CSS extensions to support rounded display » added as 1st item for tomorrow morning
# [00:43] <tantek> … if you select one, if it fails to parse, spec says to reject and set status to error
# [00:43] <tantek> … then step 2, if it fails to parse, it says to queue a task
# [00:43] <tantek> TabAtkins: because step 2 is async
# [00:43] <tantek> zcorpan: should step 2 queue a task to reject?
# [00:43] <tantek> TabAtkins: Rejection isn't observable to script until safe times anyway
# [00:44] <tantek> zcorpan: what is the ordering between observing the rejection and the queuing … ?
# [00:44] <tantek> … otherwise you can't read the status...
# [00:44] <tantek> TabAtkins: this is true I should re-order those
# [00:44] <tantek> zcorpan: there might be similar ordering issues elsewhere
# [00:44] <tantek> TabAtkins: no the rest are fine
# [00:45] <tantek> heycam: are any other implementers interested in this API?
# [00:45] <tantek> TabAtkins: beyond google and mozilla?
# [00:45] <tantek> heycam: this is based on an old draft right?
# [00:45] <tantek> TabAtkins: no I don't think so
# [00:45] * glazou shane, the guy who made the air conditioner’s UI is probably a colleague of the guy who sold projectors to Google :-)
# [00:46] <tantek> … someone recently changed … (?)
# [00:46] <tantek> … if you know of anything not matching the spec or not matching your implementation, let us know
# [00:46] <tantek> heycam: that's all I had
# [00:46] <tantek> TabAtkins: ok
# [00:46] <tantek> glazou: break. 15 min. no more.
# [00:46] <tantek> glazou: we'll start again with selectors.
# [00:50] * Quits: hyojin (~hyojin@public.cloak) (Ping timeout: 180 seconds)
# [00:55] * Quits: kwkbtr (~kwkbtr@public.cloak) (Client closed connection)
# [01:02] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [01:05] <dbaron> ScribeNick: dbaron
# [01:05] <dbaron> glazou: first topic is :for selector by Florian
# [01:05] <glazou> https://lists.w3.org/Archives/Public/www-style/2014Dec/0064.html
# [01:05] <dbaron> :for()
# [01:05] <dbaron> Florian: spun out of earlier discussion on :focus-within
# [01:06] * Joins: johanneswilm (~johannes@public.cloak)
# [01:06] <dbaron> Florian: when writing form controls in HTML, can hav labels associated with inputs, either by putting input inside label, or using for attributeand pointing to id of form element
# [01:06] <dbaron> Florian: there's a bunch of state the form input can be in that you use for styling, e.g., invalid
# [01:06] <dbaron> Florian: demand from authors to also style label that goes with the form, based on these states (focus, active, disabled, invalid, etc.)
# [01:07] <dbaron> Florian: proposal is to have a functional pseudo-class that lets you point "label for this contnorl :disabled"
# [01:07] <dbaron> Florian: then can style label
# [01:07] <dbaron> Florian: last time wasn't clear authors wanted it, went and found requests on stackoverflow for it
# [01:07] <dbaron> fantasai: why can't we just propagate the state to the label?
# [01:07] * Joins: jdaggett (~jdaggett@public.cloak)
# [01:07] <dbaron> Florian: because that is defined in HTML and Hixie's not interested
# [01:07] <dbaron> fantasai: that's ridiculous
# [01:08] <dbaron> Simon: I don't that's the best reason; another reason is that content today uses the pseudo-classes and expects it to apply only to the inputs and not the lables
# [01:08] <dbaron> Florian: also there's a small but worrying-to-some performance impact
# [01:08] <dbaron> Florian: which makes only the people interested in using this bear this cost
# [01:08] <dbaron> Florian: you can potentially associate a thousand labels with a single form element
# [01:09] <fantasai> fantasai, tantek^: that's a much better reason
# [01:09] <dbaron> Florian: corner case ...
# [01:09] <dbaron> Tantek: otherwise difficult to describe with existing selectors
# [01:09] <dbaron> Florian: people sometimes use hacks to put label after, use + selector, and then float to put label where they want it
# [01:09] <dbaron> Tantek: corrupts the natural order of the marku, which we should seek to avoid
# [01:09] <dbaron> Tantek, glazou: I support this
# [01:10] <fantasai> dbaron: What is the syntax?
# [01:10] <fantasai> dbaron: :for(<selector>)?
# [01:10] <dbaron> fantasai: don't want an ID
# [01:10] <fantasai> florian: Could do that, or just put an ID
# [01:10] <dbaron> fantasai: You want to style these things generically.
# [01:10] * Joins: andreyr_ (~andreyr@public.cloak)
# [01:10] <dbaron> Tantek: doesn't have to be a label?
# [01:11] <dbaron> Florian: for attribute only exists on labels
# [01:11] * Quits: AndreyR (~AndreyR@public.cloak) ("Page closed")
# [01:11] * Rossen is now known as Rossen_away
# [01:11] <dbaron> Tantek: doesn't have to...
# [01:11] <dbaron> PeterL: could define more generically
# [01:11] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [01:11] <dbaron> Florian: The way :for() associates is up to the host language.
# [01:11] <dbaron> fantasai: for HTML, it's the for attribute or containment
# [01:12] <dbaron> Florian: yes, HTML does by nesting or attribute; other languages can do as they want
# [01:12] <dbaron> peterl: we should leave it defined by the host language
# [01:12] <dbaron> peterl: if it's not clear enough for HTML we should say what HTML does, but leave it defined by host language
# [01:12] <dbaron> gregwhitworth: IE already does this, and we've gotten no bugs
# [01:13] <glazou> s/peterl/plinss
# [01:13] <dbaron> Florian: In IE, :active and :focus propagate from HTML to control. IE does that *and* the other way around.
# [01:13] <dbaron> s/In IE/In HTML spec/
# [01:13] <dbaron> Florian: we previously resolved the IE way was good, I was actioned to go to Hixie, he disagreed
# [01:14] <dbaron> Florian: :hover and :active (not :focus?)
# [01:14] <dbaron> Florian: I don't think IE does it for :invalid, :disabled, and all the others
# [01:14] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [01:15] <dbaron> glazou: I didn't get an answer to question: :for() pseudo that initially works only in HTML because knowledge of the for atttribute comes from above and will not appear in the UA stylesheet or anywhere.
# [01:15] <dbaron> glazou: Two ways to do that: more generic, or with for attribute mentioned.
# [01:15] <dbaron> glazou: My opinion is for attribute mentioned is better because applies to more languages.
# [01:15] <dbaron> glazou: I want to avoid the mess of the class selector where class was originally defined only for HTML and not other languages.
# [01:16] <dbaron> Florian: Should be at least for attribute in HTML
# [01:16] <dbaron> fantasai: and containment
# [01:16] <dbaron> Florian: Could also extend in HTML where a form control is for its form.
# [01:16] <dbaron> fantasai: or fieldset
# [01:16] <dbaron> fantasai: Initial preference would be to propagate state out to fieldset, label, form
# [01:17] <dbaron> fantasai: If we can't do that b/c of web compat then I'd support other syntax
# [01:17] * Joins: johanneswilm (~johannes@public.cloak)
# [01:17] <dbaron> fantasai: I think :for() syntax is vague and confusing, but in favor of solving problem
# [01:17] <dbaron> glazou: agreed
# [01:17] <dbaron> Florian: I don't think syntax is so ugly, but not married to it.
# [01:17] <dbaron> glazou: :for() seems to me confusing, esp. if generic enough that it could be an attribute other than for
# [01:17] <dbaron> Florian: If you don' tthink of attribute for, but just the English word, "the label for invalid things".
# [01:18] <dbaron> Simon: why are we discussing extending this to fieldset and form as well?
# [01:18] <dbaron> fantasai: You might want to style form / fieldset if any control is invalid
# [01:18] <dbaron> Simon: the research was for labels, not fieldsets and forms
# [01:18] <dbaron> Florian: But styling form that contains something invalid is not science fiction.
# [01:19] <dbaron> Tantek: need for something to change somewhere else -- label is most obvious example. Focus in text input-- label most obvious, but might also have help text that showsup. Having that trigger without JS is helpful; can't do that right now.
# [01:19] <dbaron> Tantek: My concern is that feature is too limited in scope to just handling HTML Label for.
# [01:19] <dbaron> Tantek: Other use cases in forms: help text, hover causing information to show up elsewhere. I don't want to preclude those with narrow definition.
# [01:20] <dbaron> Florian: If we define it to work #1 for for attribute #2 for nesting control in label, fieldset, and then leave room for future extensions maybe through @-rule.
# [01:20] <dbaron> Tantek: Already have selector in :for()
# [01:20] <dbaron> Florian: One part is state, other part is associating element.
# [01:20] <dbaron> Florian: Current proposal relies on association being done already.
# [01:20] <dbaron> Tantek: Don't need association; could just apply to all labels.
# [01:21] <dbaron> fantasai, Florian: You need an association.
# [01:21] <dbaron> Florian: Which label is for the form control.
# [01:21] <dbaron> fantasai: Don't want to make the associated between the label and the input in the CSS file, with separate rules for each form control.
# [01:21] <dbaron> s/ated/ation/
# [01:22] <dbaron> Florian: There are 2 levels, a mechanism for associating. We currently have a label<->control mechanism. Other is using existing associated to match states and propagate states along existing association. I'm only talking about altter.
# [01:22] <dbaron> Florian: That said, happy to use combinator instead of pseudo, etc. Just functionality I'm after.
# [01:22] <dbaron> Florian: In previous life existing as /for/.
# [01:22] <dbaron> Florian: confused by what other word could go there
# [01:23] * Rossen_away is now known as Rossen
# [01:23] <dbaron> fantasai: That wasn't for any attribute; it was for an idref attribute.
# [01:23] <tantek> Florian, the link from your email for TabAtkins's example is 404: https://www.dropbox.com/s/cyu9je5a6cvolyf/Screenshot%202014-12-03%2023.51.47.png?dl=0
# [01:23] <dbaron> Tantek: let's look at your real-world example
# [01:24] <TabAtkins> http://www.xanthir.com/recipes/showrecipe.php?id=55
# [01:24] <dbaron> Florian: In Tab's site in the example, he has convoluted markup because he doesn't have this.
# [01:24] <dbaron> Tab: If you click on ingredients they get crossed out, done through CSS; had to do weird things.
# [01:24] <dbaron> Tantek: label around input isn't weird
# [01:25] <dbaron> Tab: I forget what was weird.
# [01:25] <dbaron> Florian: There was something wrong; maybe fixed since?
# [01:25] * glazou suggest a functional notation with 1 or 2 parameters, first being a state like :disabled, optional second being an attribute name
# [01:25] <dbaron> (multiple conversations)
# [01:26] <dbaron> Florian: I think we can put an action on this to construct a document that would benefit.
# [01:26] <dbaron> Tab: there are tons of examples on stackoverflow
# [01:26] <dbaron> Tab: I don't think there's a need for more discovery.
# [01:26] <dbaron> Tantek: I'm just looking for a sample simple document that would benefit.
# [01:27] <dbaron> glazou: I'd rather see Florian spend time on the technical proposal and us on reviewing and getting feedback.
# [01:27] <andreyr_> +1 for technical proposal
# [01:27] <dbaron> glazou: I almost see it as a blocking tactic.
# [01:27] <dbaron> Tantek: It's not a blocking tactic. If we don't have a markup to look up then we don't know if it can be solved with existing selcetors or others that are being proposed.
# [01:27] <dbaron> Florian: Last time I proposed this, it stopped with request to go look up examples. I did.
# [01:28] <dbaron> glazou: Tantek, let's try to find the best design without looking at the markup.
# [01:28] <dbaron> Tantek: ok
# [01:28] <dbaron> fantasai: resolution is we agree we should do something, not convinced about this particular proposal. Maybe come up with something easier to understand?
# [01:29] * gregwhitworth Here is a good case for IEs bubbling example http://jsfiddle.net/jonathansampson/a9uqzd0g/3/
# [01:29] <dbaron> glazou: Florian was looking for approval to continue working
# [01:29] <dbaron> glazou: I think discussion shows interest from WG. Doesn't say we'd eventually accept poposal.
# [01:29] <dbaron> Tantek: I think can make stronger statement: best proposal we've seen so far. If a better alternative shows up we can debate that later.
# [01:29] <dbaron> glazou: Any objection to Florian spending time spec'ing this?
# [01:30] <tantek> +1 on more formal proposal
# [01:30] <dbaron> fantasai: This would go in selectors level 4.
# [01:30] <dbaron> fantasai: This would go in selectors level 5.
# [01:30] <dbaron> fantasai: Level 4 needs to be trimmed down and pushed out.
# [01:30] <dbaron> RESOLUTION: Florian to work on :for() or whatever it is.
# [01:30] <dbaron> zcorpan: for :active and :hover, we have 2 behaviors. We have IE going 2 ways and others going 1 way (with HTML spec).
# [01:31] <dbaron> Florian: We previously resolved it should go 2 ways but failed to convince Hixie.
# [01:31] <dbaron> zcorpan: Then the correct next spec is violating the HTML spec in other browsers and then getting the spec changed.
# [01:31] <dbaron> Tantek: Other step is to propose patch to HTML.
# [01:31] <dbaron> Tantek: Could submit that to the HTML Working Group. I could help liaison that.
# [01:32] <dbaron> Tantek: If there's consensus there...
# [01:32] <dbaron> Florian: Does it help in the WHATWG to get HTMLWG to accept it?
# [01:32] <dbaron> Tantek: sometimes
# [01:32] <dbaron> Tantek: If browsers respond to that, Hixie will likely spec it.
# [01:33] <glazou> Topic: Prev-sibling and parent combinators - allow :has() with some combinators in fast profile?
# [01:33] <dbaron> glazou: Next, previous-sibling and parent combinators - [copy above]
# [01:33] <dbaron> Tab: say you have elements #foo and #bar
# [01:33] <dbaron> Tab: Can already select #bar if it has #foo as previous sibling
# [01:33] <dbaron> Tab: with :has combinator
# [01:33] <fantasai> Tab: #foo ~ #bar
# [01:34] <fantasai> Tab: #foo:has(~#bar)
# [01:34] <dbaron> Tab: if we allow :has can select #foo if bar as a following sibling, though only in fast profile
# [01:35] <dbaron> Tab: Benjamin came up with a fun example, which is that you can write :nth-last-child(2 of #foo, #foo ~ bar), which is equivalent
# [01:36] <dbaron> Tab: (explains how these are equvialent)
# [01:36] <dbaron> Tab: not quite a general previous-sibling combinator; we're back-dooring it in in the fast profile
# [01:36] <fantasai> ScribeNick: fantasai
# [01:37] <fantasai> dbaron: I'm skeptical about moving too quickly here
# [01:37] <fantasai> dbaron: You have one impl that has done this
# [01:37] <fantasai> dbaron: The other thing I'm worried about is I would like the perf characteristics of selectors to be visible to authors when they're using them
# [01:38] <fantasai> dbaron: Some of them look scarier than others, and you want the slow things to look scarier than the fast things.
# [01:38] <fantasai> TabAtkins: :has() with combinator is not available in CSS, only for querySelector
# [01:38] <fantasai> TabAtkins: But you can do the :nth-last-child( of ) today in CSS
# [01:38] <fantasai> dbaron: This is only :has() for siblings, not for descendants
# [01:39] <fantasai> dbaron: Which is the more expensive case
# [01:39] <fantasai> TabAtkins: bzbarsky said looking for a parent shouldn't be too expensive
# [01:39] <fantasai> TabAtkins: Just going to the parent addresses the vast majority of cases
# [01:39] <fantasai> Florian: What is your proposal for this? Allow general syntax, or having special syntax?
# [01:39] <fantasai> TabAtkins: Allowing special-cased things might also be okay
# [01:39] <fantasai> TabAtkins: e.g. :hasChild()
# [01:40] <fantasai> dbaron: If I wanted to implement :has() for selector matching
# [01:40] <fantasai> dbaron: I'd probably want to rewrite it internally to look like the subject indicator
# [01:40] <fantasai> dbaron: Although I'm not sure
# [01:40] <fantasai> dbaron: I don't know if that has too many implications
# [01:40] <fantasai> dbaron: subject indicator is more straightforward
# [01:41] <fantasai> dbaron: doesn't allow branching
# [01:41] <fantasai> TabAtkins: Does in combination in :matches()
# [01:41] <fantasai> dbaron: Lots of new stuff without much impl experience...
# [01:41] <fantasai> TabAtkins: People really want prev sibling and parent
# [01:41] * glazou wants to hug TabAtkins now :-D
# [01:41] <fantasai> TabAtkins: Arbitrary ancestor is kindof not great, but the other two are not too bad perf-wise
# [01:41] <fantasai> TabAtkins: I think we should llow them
# [01:42] <fantasai> TabAtkins: At least direct previous direct sibling
# [01:42] * zcorpan foo < bar as parent combinator?
# [01:42] <fantasai> dbaron: Having some reasonable syntax that allows just parent and sibling doesn't seem too bad
# [01:42] <fantasai> TabAtkins: ... specialized syntax like :hasSibling :hasChild
# [01:43] <fantasai> fantasai: I don't like that, I think we should just say that you have to have a combinator at the beginning of :has()
# [01:43] <fantasai> zcorpan: a < foo
# [01:43] <fantasai> fantasai: Um, no I don't think that's great
# [01:43] <fantasai> TabAtkins: a - foo
# [01:43] <fantasai> TabAtkins: it's got parsing issues, have to require white space.
# [01:44] * glazou an April Fool with the < combinator http://perishablepress.com/awesome-new-css3-selectors/
# [01:45] <fantasai> [discussion of syntax]
# [01:45] <dbaron> astearns: problem with :has is you have to explain which versions of :has() work in a stylesheet and which don't
# [01:45] <dbaron> ScribeNick: dbaron
# [01:45] <dbaron> Florian: ?
# [01:45] <dbaron> fantasai: people will end up chaining to multiple levels of :has-child
# [01:46] * dbaron wonders if fantasai can write what's on the whiteboard
# [01:46] * fantasai will do so
# [01:46] <fantasai> Whiteboard says:
# [01:46] <fantasai> #foo:has(~#bar)
# [01:46] <fantasai> :nth-last-child(2 of #foo, #foo~bar)
# [01:46] <dbaron> Florian: we just discovered that this part of :has() is fast enough to be in the fast profile. If we've already allowed :has(), changing which subset sounds...
# [01:46] <fantasai> 1) a:has(> foo) a:has(+foo)
# [01:47] <fantasai> 2) a:has-child(foo) a:has-next-sibling(foo)
# [01:47] <dbaron> Tab: I doubt there's such subdivisiions. ??? ???
# [01:47] <fantasai> a:has(>foo>bar) vs a:has-child(foo:has-child(bar))
# [01:47] <dbaron> Tab: I don't know if we want to first poll to see if we want to allow this, which syntax we prefer
# [01:47] <dbaron> Florian: Do we have hope we'll one day we'll make :has fast enough.
# [01:47] <dbaron> fantasai: Totally possible, just have to do some fancy caching
# [01:47] <dbaron> dbaron: disagree
# [01:48] <dbaron> Florian: if people write uses that don't work and depend that they don't work then we can't activate it anymore
# [01:48] <dbaron> fantasai: as long as you put a combinator in the front then you're in one of the safe cases
# [01:48] <dbaron> Tab: no, you have to require all combinators on restricted list
# [01:48] <dbaron> SimonSapin: do we allow more combinators inside ??? with (2)
# [01:48] <dbaron> Tab: maybe lalow child combinators in :has-child() and sibling combinators in :has-sibling()
# [01:49] <dbaron> Tab: or maybe just disallow nesting of :has-pseudoclasses
# [01:49] <dbaron> Tab: dunno if looking arbitrariryl far distance into ancestorswith terrible selectors is something we want to allow
# [01:49] <dbaron> Florian: for future-compat I'm not in favor of option (1)
# [01:50] <dbaron> fantasai: selectors are agressive about being invalid; throws out entire rule...
# [01:50] <dbaron> fantasai: you'd notice
# [01:50] <SimonSapin> s/inside ???/inside the parentheses/
# [01:50] <dbaron> Florian: wouldn't count on that; definitely wouldn't want to make that rule start matching later
# [01:50] <dbaron> Tab: objections to concept still?
# [01:50] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [01:51] <fantasai> dbaron: I want to think about it more
# [01:51] <fantasai> dbaron: There's a lot of stuff with a lot of interesting per fimplications in selectors currently, not much use/testing/impl yet
# [01:51] <fantasai> dbaron: I'm not okay with it yet, I might after thinking about it some more
# [01:52] <fantasai> fantaai: I also think you shoudl get some authors to look into this
# [01:52] <fantasai> fantasai: The syntax proposed looks horrible
# [01:52] <dbaron> Tab: dbaron and bz review for performance characteristics?
# [01:53] <dbaron> Tab: we discussed before, but wasn't seriously proposing it before; now I'm seriously proposing it
# [01:54] <dbaron> ACTION dbaron review performance characteristics of parent and previous-sibling combinator, potentially combinable
# [01:54] * trackbot is creating a new ACTION.
# [01:54] <trackbot> Created ACTION-668 - Review performance characteristics of parent and previous-sibling combinator, potentially combinable [on David Baron - due 2015-02-16].
# [01:54] <fantasai> Agenda+ <custom-ident> please :)
# [01:54] * Zakim notes agendum 1 added
# [01:54] * fantasai forgot that one,
# [01:54] <dbaron> glazou: Next item on agenda is ::marker
# [01:54] <dbaron> fantasai: been in lists spec for a while. Don't have concrete lists spec. A lot of issues on positioning; not well nailed down.
# [01:54] <dbaron> fantasai: 2 main use cases for ::marker are changing color and font
# [01:55] <dbaron> fantasai: I think those are reasonable without entire spec, could define in pseudo-elements spec without colors and fonts
# [01:56] <dbaron> fantasai: proposal is add ::marker to pseudo-elements spec, takes properties from color module and fonts module (color, font-*, and opacity)
# [01:56] <dbaron> roc: why not opacity?
# [01:56] <dbaron> s/not //
# [01:56] <dbaron> fantasai: Can just do rgba()
# [01:56] * shane why not zoidberg?
# [01:56] <dbaron> fantasai: color property and font properties
# [01:57] <dbaron> Tantek: people want marker closer, etc.
# [01:57] <dbaron> fantasai: We just want to postpone that.
# [01:57] <fantasai> fantasai: Involves kspeccing the layout details
# [01:58] * astearns we'll definitely need to eventually add margins, so we can have marker margin collapsing epicycles
# [01:58] <dbaron> RESOLVED: Add ::marker with font properties and color to pseudo-elements spec (and still plan to do more later in the lists spec).
# [01:58] * glazou astearns hours of fun in sight :-D
# [02:00] <dbaron> dbaron: want to defer transitions, fx day is fine
# [02:00] <dbaron> glazou: text level 4, text-wrap: balance
# [02:00] <fantasai> http://dev.w3.org/csswg/css-text-4/
# [02:00] <dbaron> fantasai: astearns and I drafted a placeholder for text level 4. We pasted in stuff that was pulled out of level 3.
# [02:00] <dbaron> fantasai: These are all pretty fuzzy.
# [02:00] <dbaron> fantasai: The stuff that's in there is basically splitting whitespace into 2 separate properties: text-space-collapse and text-wrap.
# [02:00] <dbaron> fantasai: and adding a new text-space-trim property
# [02:01] <dbaron> fantasai: features that were deferred are ability to discard whitespace and ability to trim whitespace just inside element, or just before/after element (needed for footnote formatting).
# [02:01] <dbaron> fantasai: a couple issues on last line length that were requested, extra hyphenation controls (hyphenate-limit-{zone,chars,lines,last})
# [02:01] * Joins: johanneswilm (~johannes@public.cloak)
# [02:02] <dbaron> fantasai: string justification for tables deferred from level 3
# [02:02] <dbaron> fantasai: text-spacing property that deals with East Asian stuff not fully worked out yet
# [02:02] <dbaron> fantasai: and text-wrap property has 2 new values
# [02:02] <astearns> http://dev.w3.org/csswg/css-text-4/#text-wrap
# [02:02] <dbaron> fantasai: one ofthem proposed is text-wrap: avoid value, which says please don't break me, but if I don't fit on the line, then break
# [02:02] <dbaron> fantasai: allows more controlled breaking with phrase-sensitivity
# [02:03] * zcorpan how should i fix the at-charset tests? make a copy in work-in-progress? fix the main tests in a branch?
# [02:03] <dbaron> Florian: example using it on an Address
# [02:03] <dbaron> (rapid conversation)
# [02:03] <dbaron> fantasai: more control than just <wbr> inside of nowrap; here you can use nesting to provide prioritization)
# [02:03] <dbaron> fantasai: was in level 3, were some issues, maybe w.r.t. inheritance
# [02:03] * tantek zcorpan branch probably makes sense - since the goal is to update them in-place when the errata for 2.1 goes through.
# [02:03] * zcorpan plinss ^
# [02:04] <dbaron> fantasai: so needs to be pulled into separate property
# [02:04] * zcorpan ok
# [02:04] <dbaron> fantasai: then there's the text-wrap: balance property, which only works onblocks with direct line box descendants
# [02:04] <dbaron> fantasai: and inherits
# [02:04] <dbaron> astearns: whole spec is a diff spec
# [02:04] <dbaron> fantasai: There's stuff here that definitely needs work. Feedback: what to do with it? Suggestions on directions?
# [02:05] <dbaron> Florian: for balance specifically, had comments,but spec now took feedback
# [02:05] <dbaron> Florian: havn't reviewed rest
# [02:05] <dbaron> Florian: this should slowly be worked on
# [02:05] * plinss zcorpan, just fix them in place
# [02:05] <dbaron> astearns: of all the things in the spec at the moment, text-wrap avoid and balance are the ones developers are calling for most strongly
# [02:06] <dbaron> fantasai: A related issue is dealing with break-inside/break-after.
# [02:06] * zcorpan plinss ok
# [02:06] <dbaron> astearns: one issue with text-wrap: avoid is whether it should be tied in with break-avoid properties which have a few more settings that you can use
# [02:07] <dbaron> astearns: my take is that block breaking and inline breaking should be separately controllable things, because inline breaking almost always has to do with text-wrap, it's not a great thing to graft the same block-avoid/break properties onto inline wrapping
# [02:07] <dbaron> astearns: if anyone has contrary idea, we should discuss
# [02:07] <dbaron> fantasai draws:
# [02:07] <dbaron> text-wrap: avoid vs. break-inside: avoid vs. new property
# [02:08] * Joins: xidornq (~upsuper@public.cloak)
# [02:08] <dbaron> inheritance BAD traditionally for block axis
# [02:08] <dbaron> fantasai: I think we can't use text-wrap: avoid because text-wrap inherits
# [02:09] <dbaron> fantasai: so I think it has to be break-inside: avoid or a new property
# [02:09] <dbaron> fantasai: astearns, you're suggesting don't want break-inside:avoid
# [02:09] <dbaron> fantasai: so we need a new property; don't know the name. wrap-inside?
# [02:09] <dbaron> astearns: I'm not sure text-wrap: avoid inheriting is a terrible thing.
# [02:10] <dbaron> fantasai: text-wrap: avoid inheriting means that with <span> ... <em>Yo!</em> ... </span>, means that breaks not inside the em will be preferred over breaks inside the em.
# [02:11] <dbaron> astearns: the example you added relies on inheriting, so in some cases it's good
# [02:11] <dbaron> johanneswilm: so avoid doesn't actually mean avoid, it means ...
# [02:11] <dbaron> fantasai: it means avoid, not forbidden
# [02:11] <dbaron> fantasai: we have that, it's called nowrap
# [02:12] <tantek> dbaron: my understanding is you want something where nested avoids increase the priority
# [02:12] <tantek> dbaron: and you can't do that with inheritance
# [02:12] <tantek> fantasai: you do want nesting to increase the priority
# [02:12] <tantek> TabAtkins: I can see math structures wanting to do that
# [02:12] <tantek> dauwhe: would you need to set explicit priorities on various things?
# [02:12] <tantek> TabAtkins: you just wrap extra wrappers
# [02:12] <dbaron> johanneswilm: couldn't you have numbers on it?
# [02:13] <dbaron> fantasai: then you have the z-index problem with really big numbers
# [02:13] * Quits: xidorn (~upsuper@public.cloak) (Ping timeout: 180 seconds)
# [02:13] <dbaron> fantasai: and most cases with this sort of wrapping, there's a hierarchical structure, where using avoid takes care of it for you
# [02:13] <dbaron> fantasai: we might need priorities in addition to nesting, but nesting takes care of most cases
# [02:14] <dbaron> johanneswilm: so if I have a span and would prefer no breaks inside of it, but inside the em, I'd prefer the break inside the em, how would I express that?
# [02:14] <dbaron> Tab: could put avoid on spans that are siblings of the em
# [02:14] * Quits: cyril (~cyril@public.cloak) (Ping timeout: 180 seconds)
# [02:15] <dbaron> fantasai: inheritance makes it convenient, says every additional element increases avoidance
# [02:15] <dbaron> fantasai: in simple cases like a headline, don't have any extra markup
# [02:16] <dbaron> fantasai: if you have a footer on a slideshow: date, location, talk title: each individually should stay together, but links inside that shouldn't increase avoidance
# [02:16] <dbaron> astearns: definitely cases where it's convenent to inherit, but might be inconvenient
# [02:17] <dbaron> s/might/not where might/
# [02:17] * dauwhe text-wrap: avoid !inherit;
# [02:17] <dbaron> fantasai: because most markup corresponds to things that mean things
# [02:17] <dbaron> SteveZ: (something about a URL)
# [02:17] <dbaron> SteveZ: but in that case can also label the URLs as text-wrap: ???
# [02:18] <dbaron> s/???/normal/
# [02:18] <dbaron> fantasai: so should either be text-wrap: avoid or a separate property
# [02:19] <dbaron> SteveZ: turning it the other way around, why do I need the other property
# [02:19] <dbaron> fantasai: easier to turn on inheritance than it is to turn it off
# [02:20] <fantasai> dbaron: Weird to inherit
# [02:20] * xidornq is now known as xidorn
# [02:20] <fantasai> dbaron: MOdel we have is that adding inlines or blocks with no styling is essentially a no-op
# [02:20] * Rossen break-inside: text-wrap-avoid
# [02:20] <fantasai> dbaron: This breaks that model
# [02:21] <dbaron> astearns: haven't specified that it increases
# [02:21] <dbaron> dbaron: yeah, if there's only one level of avoidance it's not a problem
# [02:21] <dbaron> johanneswilm: say I have a book title with subtitle. I'd prefer whole thing not to be broken, but if it needs to be broken, I'd prefer break between title and subtitle. How would I do that.
# [02:21] <dbaron> fantasai: mark up title and subtitle in separate spans
# [02:22] <dbaron> fantasai: and a span around both
# [02:22] <dbaron> astearns: so should specify priority increases
# [02:22] <dbaron> astearns: and then question of whether that requires text-wrap: avoid at the top, or in 3 places
# [02:23] <dbaron> fantasai: I think dbaron's point important, and requires a separate property.
# [02:23] <dbaron> astearns: text-wrap is a new property -- why can't it just not inherit?
# [02:23] <dbaron> fantasai: wrap value and nowrap value must inherit
# [02:23] * zcorpan think of poor <wbr>
# [02:23] <dbaron> fantasai: or we could just stick with white-space, and have text-wrap only controlling avoidance behavior
# [02:24] <dbaron> Florian: {asks question}
# [02:24] <dbaron> fantasai: text-wrap is a longhand of shorthand white-space
# [02:24] <dbaron> fantasai: and 'none' value should have been 'nowrap'
# [02:24] * zcorpan is http://dev.w3.org/csswg/css-syntax/ down for everyone or just me? "Proxy Error"
# [02:25] <astearns> http://dev.w3.org/csswg/css-text-4/#white-space-property
# [02:25] <sgalineau> zcorpan: fails for me too
# [02:25] * tantek zcorpan checking
# [02:25] <dbaron> astearns: there's handwaving about the shorthand in the intro section; I'd be happy not making shorthand
# [02:25] * Zakim dbaron, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [02:25] <glazou> zcorpan: seems down for me too
# [02:25] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [02:25] * tantek zcorpan not loading for me either.
# [02:25] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [02:25] <glazou> zcorpan, tantek: ERROR 503: Service Temporarily Unavailable
# [02:25] * tantek zcorpan though: http://downforeveryoneorjustme.com/http://dev.w3.org/csswg/css-syntax/ ?
# [02:26] <dbaron> drafts.csswg.org seems to be down, peterl?
# [02:26] <dbaron> fantasai: You don't want to define one property that always overrides another
# [02:26] * tantek dbaron plinss but: http://downforeveryoneorjustme.com/drafts.csswg.org
# [02:26] <dbaron> SteveZ: dbaron's principle requires that nowrap inherit and requires that avoid not inherit
# [02:26] <dbaron> fantasai: I think we need a sepraate property for avoid
# [02:26] * zcorpan http://drafts.csswg.org/css-syntax/ wfm
# [02:26] <dbaron> seems up now, though
# [02:26] * plinss just kicked the server
# [02:27] * zcorpan thx
# [02:28] <dbaron> SteveZ: part of problem is that we can't use avoid-break in -- two breaks that could avoid, blocks or lines, and don't know which is intended.
# [02:28] <dbaron> SteveZ: With the fragmenting spec, we've been trying to get generic terminology that applies, and here that doesn't quite work.
# [02:28] <dbaron> SteveZ: I wonder if there are other places where there are multiple possible fragmentations at the same time.
# [02:28] <dbaron> fantasai: yes, flexbox has lines
# [02:28] <dbaron> fantasai: we could use same properties for flex lines as for text
# [02:28] <dbaron> SteveZ: introduce a new property that had more than one use?
# [02:29] <dbaron> fantasai: wrap-inside wrap-before wrap-after?
# [02:29] <dbaron> dauwhe: that sounds almost useful to me
# [02:29] <dbaron> fantasai: works for me
# [02:29] <dbaron> astearns: try fleshing it out?
# [02:29] <dbaron> fantasai: we'll take an action to update spec
# [02:30] <dbaron> ACTION fantasai and astearns to try fleshing out spec for wrap-inside wrap-before wrap-after in css-text-4
# [02:30] * trackbot is creating a new ACTION.
# [02:30] <trackbot> Created ACTION-669 - And astearns to try fleshing out spec for wrap-inside wrap-before wrap-after in css-text-4 [on Elika Etemad - due 2015-02-16].
# [02:30] <dbaron> fantasai: Topic: white-space
# [02:30] * glazou dino, no martial law apparently :-)
# [02:31] <dbaron> fantasai: white-space: normal | nowrap | pre | pre-line
# [02:31] * dino yeah, a much worse outcome - we keep the PM :(
# [02:31] <dbaron> fantasai: |-- text-wrap: nowrap | normal
# [02:31] * TabAtkins is now known as ShmabShmatkins
# [02:31] <dbaron> fantasai: |-- text-space-collapse: collapse | discard | preserve | preserve-breaks
# [02:32] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [02:32] <dbaron> fantasai: text-space-trim: none | trim-inner || consume-after || consume-before
# [02:32] <dbaron> fantasai: white-space controls two different things, collapsing and whether text is allowed to wrap
# [02:32] * shane dino, glazou #ImStickingWithTony -- hilarious trending topic on twitter
# [02:33] <dbaron> fantasai: we split this into 2 diferent properties
# [02:33] <dbaron> fantasai adds balance to text-wrap
# [02:33] <dbaron> fantasai: discard is new value, throws out all whitespace
# [02:33] <dbaron> fantasai: preserve is pre, preserve-breaks is pre-line
# [02:33] <dbaron> fantasai: the 2 new subproperties inherit since white-space inherits
# [02:34] <dbaron> fantasai: text-space-trim needs to not inherit, so pulled into separate property
# [02:34] <dbaron> fantasai: was in level 3
# [02:34] <dbaron> fantasai: trim-inner gets rid of space that's just inside the beginning and end of the element
# [02:34] * dino shane "#ImStickingWithTony because I've already seen the Great Barrier Reef." hahahahaha cry
# [02:34] * Quits: roc (~chatzilla@public.cloak) (Client closed connection)
# [02:35] * Joins: roc (~chatzilla@public.cloak)
# [02:35] * shane dino ouch .. that one bites
# [02:35] <dbaron> fantasai: consume-after ... pulling a footnote out, don't want to format source code so markup is right up against last letter, but want the footnote marker to have no space before it.
# [02:35] <dbaron> fantasai: or if you format it with parentheses, you want the space before the opening parenthesis
# [02:36] <dbaron> s/consume-after/consume-before/
# [02:36] * glazou dino seems you have your own Sarkozy but just worse :-D
# [02:36] <dbaron> fantasai: That's the set of whitespace stuff pulled in from old level 3 ideas. What do you all think?
# [02:36] <dbaron> Rossen: (question)
# [02:37] <dbaron> fantasai: line-break and word-break control where linebreaking opportunities are in the text
# [02:37] <astearns> s/(question)/where is word-break in this?/
# [02:37] <dbaron> fantasai: this controls whether or not you're wrapping
# [02:37] * sgalineau lol did he really say he went to 'Canadia'?
# [02:37] <dbaron> heycam: consume and discard seem to be similar things, so maybe should use the same names?
# [02:37] <dbaron> fantasai: discard-after and discard-before?
# [02:38] <dbaron> heycam: in SVG, we're making SVG text be defined in terms of CSS text layout
# [02:38] <dbaron> heycam: one of the weirdo things about SVG text is that if you use the old mechanism to say preforatted text, with xml:space=preserve, it preserves all the spaces within lines but discards newlines
# [02:38] <dbaron> heycam: so we have a special value in Gecko that's like pre, but discards newlines
# [02:39] <dbaron> fantasai: text-space-collapse: discard-breaks -- implies you preserve the other things
# [02:39] * Quits: jet (~uid49872@public.cloak) (Ping timeout: 180 seconds)
# [02:39] <dbaron> SteveZ: if that, then poetry one should be discard-extra-whitespace
# [02:40] * sgalineau oh noes, he really did
# [02:40] <dbaron> fantasai: I think it's clear enough...
# [02:40] * Quits: amtiskaw (~sid19262@public.cloak) (Ping timeout: 180 seconds)
# [02:40] * Quits: mihnea_____ (~sid16310@public.cloak) (Ping timeout: 180 seconds)
# [02:40] <dbaron> SteveZ: ???
# [02:40] * Quits: ato (~sid16069@public.cloak) (Ping timeout: 180 seconds)
# [02:40] <dbaron> heycam: you could have separate values for breaks and the inline things
# [02:40] <dbaron> fantasai: feels unnecessary
# [02:41] <dbaron> SteveZ: suggestions: either preserve-non-breaks parallel to preserve ...
# [02:41] <dbaron> fantasai: Do you discard the breaks or collapse them?
# [02:41] <dbaron> heycam: they get discarded
# [02:42] <dbaron> johanneswilm: (something about whitespace at start and end of line)
# [02:42] <dbaron> heycam: let me just confirm that it doesn't convert the newline into a single space
# [02:42] <dbaron> fantasai: any other comments?
# [02:42] <dbaron> fantasai: ok, go with this then
# [02:43] <dbaron> fantasai: thoughts on turning this into an editor's draft when we have this in?
# [02:43] <dbaron> various: yes
# [02:43] <tantek> definitely editor's draft
# [02:43] <fantasai> Edits to do
# [02:43] <fantasai> 1. consume-before/after -> discard-before/after
# [02:43] <fantasai> 2. add discard-breaks (or collapse-breaks, as appropriate) for SVG
# [02:44] <fantasai> 3. spec wrap-before/after/inside
# [02:44] <fantasai> (and remove 'avoid'
# [02:44] <fantasai> )
# [02:44] * Joins: sgalineau_ (~sgalineau@public.cloak)
# [02:44] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [02:44] <dbaron> heycam: actually it looks like implementations turn newlines into spaces, and not collapse consecutive ones, except in IE
# [02:45] * Quits: sgalineau_ (~sgalineau@public.cloak) ("Page closed")
# [02:45] <dbaron> heycam: maybe IE doesn't implement xml:space=preserve
# [02:45] <dbaron> fantasai: so we need a new name, say spacify-breaks for now
# [02:45] * dauwhe spacifyification?
# [02:45] <glazou> http://glazman.org/tmp/IMG_0153.JPG
# [02:45] <tantek> how about 'breaks-to-spaces'
# [02:45] <dbaron> RESOLUTION: Make css-text-4 an editor's draft (currently a diff spec)
# [02:45] <ShmabShmatkins> fyif
# [02:46] <dbaron> RESOLUTION: fantasai and astearns to edit
# [02:46] * glazou is now known as shmazou
# [02:46] * tantek is now known as shmantek
# [02:46] * Joins: mihnea_____ (~sid16310@public.cloak)
# [02:47] * shmantek is now known as tantek
# [02:47] <tantek> tomorrow we're in 1 Darling rd.
# [02:47] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [02:48] * heycam is now known as heycam|away
# [02:48] * Quits: kwkbtr (~kwkbtr@public.cloak) (Client closed connection)
# [02:48] <tantek> break for lunch til 14:18 (90min)
# [02:49] * Joins: amtiskaw (~sid19262@public.cloak)
# [02:49] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [02:49] * Joins: jet (~uid49872@public.cloak)
# [02:50] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [02:51] * Joins: ato (~sid16069@public.cloak)
# [02:58] * Rossen is now known as Rossen_away
# [02:58] * Quits: andreyr_ (~andreyr@public.cloak) (Ping timeout: 180 seconds)
# [03:01] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [03:16] * Joins: dauwhe (~dauwhe@public.cloak)
# [03:39] * Joins: Florian (~Florian@public.cloak)
# [03:51] * Joins: zcorpan (~zcorpan@public.cloak)
# [03:54] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [03:54] * Joins: zcorpan (~zcorpan@public.cloak)
# [03:57] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [03:58] * Joins: johanneswilm (~johannes@public.cloak)
# [03:58] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [04:01] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [04:06] * heycam|away is now known as heycam
# [04:12] * Joins: estellevw (~estellevw@public.cloak)
# [04:13] * leaverou is now known as leaverou_away
# [04:14] <fantasai> astearns: I don't think breaking flex items across flex-lines makes sense
# [04:14] <fantasai> astearns: I think flex just needs wrap-before+wrap-after, not wrap-inside
# [04:15] * fantasai wonders where ChrisL is
# [04:15] * Florian same here
# [04:15] <astearns> fantasai: right - I was thinking of a range of flex items not getting a wrap, but that doesn't quite work
# [04:15] * Joins: AndreyR (~AndreyR@public.cloak)
# [04:16] * Parts: jet (~uid49872@public.cloak)
# [04:16] * Joins: jet (~uid49872@public.cloak)
# [04:17] <fantasai> koji?
# [04:18] <tantek> 14:18 resume
# [04:18] <tantek> Topic: sizing
# [04:18] * Joins: murakami (~murakami@public.cloak)
# [04:19] <fantasai> RESOLVED: Add gregwhitworth as editor to Sizing
# [04:20] <fantasai> ACTION: fantasai figure out what it was wrt percentage sizing
# [04:20] * trackbot is creating a new ACTION.
# [04:20] * RRSAgent records action 3
# [04:20] <trackbot> Created ACTION-670 - Figure out what it was wrt percentage sizing [on Elika Etemad - due 2015-02-16].
# [04:21] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [04:22] <fantasai> fantasai: We were discussing the two different concepts of "max-content" sizing: the size that the thing wants to be (e.g. for multicol, col-width * col-count) vs. the width at which it will be the shortest and not waste space horizontally
# [04:22] <fantasai> (which for multicols is col-count*max-content of the content)
# [04:23] <fantasai> fantasai: Conclusion was that 'max-content' keyword would refer to the first concept, since that's what authors really need for stuff
# [04:23] * koji fantasai: yes?
# [04:23] <fantasai> fantasai: in the cases where we need the second concept, we'll call it the super-max-content for now, probably won't be exposed to authors
# [04:23] <shmazou> koji: want to call in?
# [04:23] * fantasai want to discuss text later?
# [04:23] * shmazou is now known as glazou
# [04:24] * Rossen_away is now known as Rossen
# [04:24] <fantasai> dbaron: This is the thing where the only difference between them is multicol
# [04:24] <SimonSapin> fantasai, What's the intrinsic size of div in <div style="width: auto"><p style="width: 100px; margin: 10%"></div> ?
# [04:24] * koji fantasai: yeah, today is good. Wed is also good
# [04:24] <fantasai> fantasai: I think so. ALthough gregwhitworth's case is one that might be relevant, too
# [04:25] <fantasai> dbaron: I don't think there's a case fo rhaving this extra spec concept
# [04:25] * koji shmazou: thanks, not for sizing ;)
# [04:25] <tantek> dbaron: there are lots of concepts that exist that we don't write code for
# [04:26] <fantasai> dbaron: putting it in a spec creates a risk that somebody ends up implementing the concept that isn't used
# [04:26] <fantasai> TabAtkins: So we define max-content, put a note in the spec saying that we might need this extra concept
# [04:27] * tantek what about max-headroom?
# [04:27] <fantasai> TabAtkins makes an example
# [04:27] <fantasai> multicol element w/ columsn: 2 200px
# [04:27] <fantasai> TabAtkins: It will lay itself out at 400px
# [04:28] <fantasai> TabAtkins: suppose you have an unbreakable word
# [04:28] <fantasai> fantasai: Could be breakable
# [04:28] <fantasai> fantasai: Actually, that's an issue, if it's unbreakable, you'll have min-content > max-content
# [04:29] <fantasai> dbaron: That is severely broken
# [04:29] <dbaron> dbaron: It's a spec bug if max-content < min-content
# [04:29] * dauwhe Baron's Law: the minimum should never be greater than the maximum
# [04:29] <fantasai> TabAtkins: You'll get 2 cols 300px each
# [04:29] <tantek> fantasai: we're mixing up a bunch of different concepts
# [04:29] <tantek> scribenick: tantek
# [04:29] <tantek> fantasai: (goes to whiteboard)
# [04:30] <tantek> … if container is 600px
# [04:30] <tantek> … multicol element will layout 300px wide columns
# [04:30] <tantek> … but at 400px, 200px each col, the first line would wrap
# [04:30] <tantek> … in the 300px case it doesn't wrap because it fits
# [04:30] <tantek> … and the height of my thing is going to be 1em
# [04:30] <tantek> … this got shorter, I'm wasting 58px of space
# [04:31] <tantek> … (…) so 500 px is a point in the layout that stuff changes
# [04:31] <tantek> … you have unwrapped all of the lines
# [04:31] <tantek> … beyond 500px you start getting extra space
# [04:31] <tantek> … so this is kind of like a breakpoint in the layout
# [04:31] <tantek> … if you make the thing any narrower than 400px
# [04:31] <tantek> … then you're going to drop down to 1 column
# [04:31] <tantek> … then you have another concept
# [04:31] <tantek> … What is the minimum size that you don't get overflow?
# [04:32] <tantek> … take the length of the longest word
# [04:32] <tantek> … mutiply it by the number of columns
# [04:32] <tantek> … the longest word basically
# [04:32] <tantek> … whatever that is is the min content size
# [04:32] <tantek> SteveZ: I think I get min content and unwrapped lines
# [04:32] <tantek> … but it's this funny thing in between that I don't get
# [04:32] <tantek> fantasai: this size, which is I want to be that size, that one could be in the middle or smaller than the min content size, or larger than the intrinsic max size
# [04:33] <tantek> Rossen: let's go one column
# [04:33] <tantek> … you have 1 col with 200px
# [04:33] <tantek> … you have min content 100
# [04:33] <tantek> Rossen: (draws on white board)
# [04:33] <tantek> … your content inside is 100
# [04:33] <tantek> … you max is 150
# [04:33] <tantek> … let's say 2 words
# [04:33] <tantek> … in this case you're happy
# [04:33] <tantek> … you're going to have 200px content width
# [04:33] <tantek> … I think there are three cases
# [04:34] <tantek> … 1) both min & max > 200
# [04:34] <tantek> … 2) or only max > 200
# [04:34] <tantek> … 3) happens when you start multiplying the columns
# [04:34] <tantek> … what doesn't currently work, what are you proposing to change
# [04:34] <tantek> … for case #1: both min & max are strictly > col size
# [04:34] <tantek> … case #2: only max > col size
# [04:35] <tantek> … case #3: … um
# [04:35] <tantek> … is you have more than one column
# [04:35] <tantek> … for completeness
# [04:35] <tantek> … same as above but with the opposite sign.
# [04:35] <tantek> fantasai: so the question we have is
# [04:35] <tantek> … when you have a multicol element that is shrink to fit
# [04:35] <tantek> … what size does it end up being
# [04:35] <tantek> Rossen: let's answer 1 col question first
# [04:35] <tantek> … before multicol
# [04:36] <tantek> dbaron: isn't 1 col equivalent to non multicol
# [04:36] <tantek> Rossen: exactly
# [04:36] <tantek> fantasai: a non-multicol doesn't have a column width
# [04:36] <tantek> dbaron: I am not at all convinced that we should considr the col width at all for any intrinsic size computation
# [04:36] <tantek> Rossen: you're saying 1 col is equivalent of having a block
# [04:36] <tantek> dbaron: yes
# [04:37] <tantek> Rossen: when I have a block with 200px, what it reports to a float trying to wrap around it, it will report 200px min & max
# [04:37] <tantek> Rossen: for single col width 200px, it shouldn't honor the 200px
# [04:37] <tantek> dbaron: col width is a minimum, or more like minimum
# [04:37] <tantek> Rossen: same as a table cell
# [04:37] <tantek> fantasai: no it is different
# [04:37] <tantek> fantasai: if you have a block
# [04:37] <tantek> … if col width is 200px
# [04:37] <tantek> … if my block is 50px
# [04:37] <tantek> … my col will be 50 px
# [04:37] <tantek> … the col width is a suggestion
# [04:38] <tantek> dbaron: column width is merely a hint for determining the column count
# [04:38] <tantek> fantasai: yes
# [04:38] <tantek> dbaron: although i don't quite remember…
# [04:38] <tantek> … the formula for when both col count and col width are specified
# [04:38] <tantek> … it takes the smaller of the two numbers
# [04:38] <tantek> fantasai: yeah
# [04:38] <tantek> … if your container is 150px wide, the col will be 150px wide
# [04:39] <tantek> … if your container is 250px… col will be 250px
# [04:39] <tantek> … if your container is 400px, your col will be 2 cols of 200px each
# [04:39] <tantek> … we had (…) but we ran into the shrink to fit sizing in the multicol spec says if you have a float, and you have enough space, then the multicol will be columns * colwidth
# [04:39] <tantek> … and that's implemented
# [04:39] <tantek> … if as an author I specify hey, I want you to shrink to fit around this thing
# [04:40] <tantek> … that's what they expect
# [04:40] <tantek> … if they have a long line of content, they don't expect the cols to get wide
# [04:40] <tantek> … we have a problem here
# [04:40] <tantek> … it's really important that the shrink to fit max is, is …
# [04:40] <tantek> … it's important that the shrink to fit max include the maximum of the min content size, and then col count * col width
# [04:40] <tantek> … that way you're maintaining that invariant
# [04:41] <tantek> … you're also getting the thing the author asked for
# [04:41] <tantek> … we have this other concept of unwrapped
# [04:41] <tantek> … authors will not want that
# [04:41] <tantek> … you will have layout land at that answer for certain cases
# [04:41] <tantek> … that's a break point in the layout where it won't get shorter
# [04:41] <tantek> … it might become a useful concept if for example
# [04:41] <tantek> … if you have tables and you're doing orthogonal flows
# [04:41] <tantek> … you might want things to be as few lines as possible
# [04:41] <tantek> … without orthogonal flows it's not that interesting as a concept
# [04:42] <tantek> … we also have a similar issue
# [04:42] <tantek> … the shrink to fit sizing should be x
# [04:42] <tantek> … and if the box is wider it will be wider
# [04:42] <tantek> … like Greg brought up
# [04:42] <tantek> … the shrink to fit expectation is narrower than (...)
# [04:42] <tantek> … that's a concept that we don't have a clear idea where it would be used
# [04:42] <tantek> … but I have a feeling it will show up
# [04:42] <tantek> Rossen: go back to .(…) what are we calling it?
# [04:42] <tantek> fantasai: max conent
# [04:42] <tantek> s/conent/content
# [04:43] <tantek> fantasai: we have 3 concepts
# [04:43] <tantek> … small concept
# [04:43] <tantek> … two big concepts
# [04:43] <tantek> … the author gets exposed to these through shrink to fit sizing and the max content keyword
# [04:43] <tantek> … when the author is doing grid layout for example
# [04:43] <tantek> … then they're going to expect to be this size and not wrap the text
# [04:43] <tantek> Rossen: in this case, 600px, 2 cols
# [04:43] <tantek> … 300px cols each
# [04:43] <tantek> fantasai: where is 600px coming from
# [04:44] <tantek> Rossen: min content
# [04:44] <tantek> fantasai: if you have a really long unbreakable line or an image, then it will be wide enough to fit that image without overflow
# [04:44] <tantek> Rossen: in this case it will overflow
# [04:44] <tantek> fantasai: it won't
# [04:44] <tantek> Rossen: you will have two columns
# [04:44] <tantek> fantasai: when you layout a multicol element at 600px with 2 cols, each will be 300 px wide
# [04:45] <tantek> Rossen: your col count has to be driven by the max of (...)
# [04:45] <tantek> TabAtkins: this is not the size of the largest word
# [04:45] <tantek> dbaron: maybe we should take some of this offline
# [04:45] <tantek> … not sure what we're trying to solve right now
# [04:46] <tantek> TabAtkins: (...)
# [04:46] <tantek> dbaron: the thing you just said, you implicitly assumed two concepts
# [04:46] <tantek> … I don't think you have to assume that
# [04:46] <tantek> fantasai: for the purposes of this discussion there are 2 concepts
# [04:46] <tantek> dbaron: there are potentially many more concepts
# [04:46] <tantek> TabAtkins: we need to be ok with multicol having a different answer for that
# [04:46] <tantek> SteveZ: you're just defining what max content means in a multicol situation
# [04:47] <tantek> fantasai: the other case is you have a bunch of floats
# [04:47] <tantek> … and you shrinkwrap a bunch of floats
# [04:47] <tantek> … you could have this (…) but you actually get this (...)
# [04:47] <tantek> … the floats (3) could fit next to each other
# [04:47] <tantek> … but since you asked it to shrinkwrap, current implementations shrink them to one on a line each
# [04:47] <tantek> gregwhitworth: it is weird and we'll try to spec it
# [04:48] <tantek> fantasai: more fun times
# [04:48] <tantek> TabAtkins: resolutions
# [04:48] <tantek> … can we get a resolution that we should define max content of multicol this way
# [04:48] <tantek> dbaron: I think I object to a big part of that
# [04:48] <tantek> fantasai: which part
# [04:48] <tantek> dbaron: most of it
# [04:48] <tantek> dbaron: and I want to propose an alternative
# [04:48] <tantek> SteveZ: the piece that confuses me with a 600px image
# [04:48] <tantek> … I would expect multicol to go away in that case
# [04:49] <tantek> Rossen: you specified the number col count 2
# [04:49] <tantek> TabAtkins: multicol assume if you specify count that you meant it
# [04:49] <tantek> fantasai: so we need to make this correction
# [04:49] <tantek> TabAtkins: so we fix this in sizing now
# [04:49] <tantek> … dbaron can suggest whatever he wants
# [04:49] <tantek> … and we can resolve differences later
# [04:49] <tantek> gregwhitworth: we need to discuss per the mail thread what does "min content" really mean
# [04:49] <tantek> … we can take it offline
# [04:50] <tantek> TabAtkins: (…) ?
# [04:50] <tantek> fantasai: the intrinsic size
# [04:50] <tantek> Rossen: so if it's the only thing you're going to get the specified size
# [04:50] <tantek> fantasai: no there is a min content size and a min content contribution
# [04:50] <tantek> … there are two separate concepts
# [04:50] <tantek> dbaron: one of the reasons for that is that we want the width property to accept values
# [04:50] <tantek> … that says use the min or max content
# [04:51] <SimonSapin> q+ about percentage margins in intrinsic sizing
# [04:51] * Zakim SimonSapin, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [04:51] <tantek> … the min content size does not include the (...)
# [04:51] <tantek> … you have to factor that into the contribution (...)
# [04:51] <tantek> gregwhitworth: both of your guys implementations you could make an argument for
# [04:51] <SimonSapin> q+
# [04:51] * Zakim sees SimonSapin on the speaker queue
# [04:51] <tantek> gregwhitworth: you guys (Moz) if you have a really long line ...
# [04:51] <tantek> gregwhitworth: but blinks will shrink to the size of the longest word
# [04:51] <tantek> dbaron: I think this is very differen than what Rossen and I were talking about
# [04:52] <tantek> fantasai: it is full defined and mozilla's implementation matches what it is defined as
# [04:52] <tantek> SimonSapin: I missed this earlier
# [04:52] <tantek> … can we got back to percentages?
# [04:52] <plinss> zakim, ack SimonSapin
# [04:52] <Zakim> I see no one on the speaker queue
# [04:52] <tantek> scribenick: fantasai
# [04:52] <fantasai> SimonSapin: Intrinsic size computation for blocks
# [04:52] <fantasai> SimonSapin: You account for margin/padding/border of children
# [04:53] <fantasai> SimonSapin: But it's unclear what happens if these contain percentages or auto values
# [04:53] <fantasai> SimonSapin: If you compare with width of children, we have specific text that says it's indefinite, do something else
# [04:53] <fantasai> TabAtkins: But for margin/border/padding we don't say
# [04:53] <fantasai> Rossen: No interop here
# [04:54] <fantasai> dbaron: Auto isn't interesting. just treat as zero
# [04:54] <fantasai> TabAtkins: yeah
# [04:54] <fantasai> SimonSapin: Put that in the spec
# [04:54] <fantasai> dbaron: In gecko we do the reverse computation
# [04:55] <fantasai> fantasai: I think this discussion was super-useful, I understand what's going on here much better thanks to the discussion
# [04:55] <fantasai> fantasai: Let's get together and update the spec before we lose all the context again
# [04:56] <fantasai> RESOLVED: auto margins assumed to be zero for intirnsic size computation
# [04:56] <dbaron> SimonSapin, fwiw, http://dbaron.org/css/intrinsic/#outer-intrinsic did define it :-P
# [04:56] <fantasai> dbaron: Did we come to a conclusion on percentages?
# [04:56] <glazou> http://glazman.org/tmp/IMG_0154.JPG
# [04:56] <fantasai> Rossen: We discussed computing to zero
# [04:57] <fantasai> dbaron: I think trying to do something useful with percentages is good
# [04:57] <SimonSapin> dbaron, great! Let’s copy that in Sizing
# [04:57] <fantasai> dbaron: We were unable to do for width
# [04:57] <fantasai> fantasai: I agree we should do something useful and not stupid here
# [04:57] <fantasai> fantasai: Shouldn't create overflow artificially
# [04:57] <fantasai> Rossen talks about stacking percentages
# [04:57] <fantasai> dbaron: Tables already do this
# [04:58] <fantasai> dbaron: Tables do inverting of percentages
# [04:58] <gregwhitworth> Here is the min-content issue we need to discuss: http://dabblet.com/gist/599a04c05a22f48a292d
# [04:58] <gregwhitworth> Discussion is here: https://lists.w3.org/Archives/Public/www-style/2015Jan/0022.html
# [04:58] <fantasai> dbaron: At some point your perferred width becomes infinite, but you never use it directly, you always min it with something
# [04:59] <fantasai> fantasai: With width percentages, you treat as auto for both intrinsic size computation and for final layout
# [05:00] <fantasai> fantasai: with percentage padding, you treat as zero for intrinsic size computation, but then honor it for layout, which results in overflow and bad layout
# [05:00] <fantasai> fantasai: I think this is worth fixing
# [05:00] <fantasai> Rossen says something about making things better for flex, but wasn't sure what he said
# [05:00] <fantasai> ACTION: fantasai, Tab, SimonSapin, Rossen , gregwhitworth , dbaron to figure this all out and spec it.
# [05:00] * trackbot is creating a new ACTION.
# [05:00] * RRSAgent records action 4
# [05:00] <trackbot> Error finding 'fantasai,'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [05:00] <fantasai> Rossen: tonight.
# [05:00] <fantasai> plinss: or else.
# [05:01] <fantasai> Topic: Text
# [05:01] <fantasai> koji?
# [05:02] <plinss> zakim, room for 3?
# [05:02] <Zakim> ok, plinss; conference Team_(css)04:01Z scheduled with code 26631 (CONF1) for 60 minutes until 0501Z
# [05:03] <koji> can I call in?
# [05:03] <plinss> yes ^
# [05:03] <plinss> zakim, code?
# [05:03] <Zakim> the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), plinss
# [05:04] <Zakim> Team_(css)04:01Z has now started
# [05:04] <Zakim> +??P0
# [05:04] <plinss> zakim, ??P0 is MeetingRoom
# [05:04] <Zakim> +MeetingRoom; got it
# [05:06] <ShmabShmatkins> ScribeNick: ShmabShmatkins
# [05:06] <ShmabShmatkins> SchmibeNick: ShmabShmatkins
# [05:06] <Zakim> -MeetingRoom
# [05:06] <Zakim> Team_(css)04:01Z has ended
# [05:06] <Zakim> Attendees were MeetingRoom
# [05:07] <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0080.html
# [05:07] <ShmabShmatkins> Topic: Text
# [05:07] <ShmabShmatkins> fantasai: First issue is about line-breaking around emoji/etc
# [05:07] <ShmabShmatkins> fantasai: There was some bakc-and-forth in the thread
# [05:07] <ShmabShmatkins> fantasai: The best option is to treat images as ideographic chars for linebreaking.
# [05:07] <ShmabShmatkins> fantasai: It solves linebreaking problems when images are used as emoji.
# [05:08] <ShmabShmatkins> fantasai: And gives better behavior than the current spec in general.
# [05:08] <ShmabShmatkins> fantasai: So this doesn't cause breaks right before an end paren, etc.
# [05:08] <ShmabShmatkins> fantasai: Main concern is, is this web compatible?
# [05:08] <ShmabShmatkins> fantasai: Right now everyone breaks around images.
# [05:08] <ShmabShmatkins> fantasai: But Presto treats images as ideographic chars.
# [05:08] <Zakim> Team_(css)04:01Z has now started
# [05:08] <Zakim> +??P0
# [05:08] <ShmabShmatkins> fantasai: The critical piece is that the iamges will break between each other if they're siblings, which is handled by this suggested rule.
# [05:08] <plinss> zakim, ??P0 is MeetingRoom
# [05:08] <Zakim> +MeetingRoom; got it
# [05:09] <Zakim> -MeetingRoom
# [05:09] <Zakim> Team_(css)04:01Z has ended
# [05:09] <Zakim> Attendees were MeetingRoom
# [05:09] <ShmabShmatkins> fantasai: Only behavior change is a few restrictions we add for ideographic chars.
# [05:09] * koji hm, I'm the only participant in CONF1...
# [05:09] <ShmabShmatkins> fantasai: Which you probably meant to work in the first place.
# [05:09] * heycam plinss do you need to re-dial in? ^
# [05:09] <ShmabShmatkins> fantasai: We're taking Presto as an example of webcompat.
# [05:09] <Zakim> Team_(css)04:01Z has now started
# [05:09] * plinss we’re working on redialing…
# [05:09] <Zakim> +MeetingRoom
# [05:09] <ShmabShmatkins> fantasai: We're hoping this is worth giving a shot at fixing to be sane.
# [05:10] <zcorpan> line breaking around images is a bit different in quirks mode: https://quirks.spec.whatwg.org/#the-table-cell-width-calculation-quirk
# [05:10] <ShmabShmatkins> fantasai: We need to hear back from impls to see if they're willing to implement.
# [05:10] <ShmabShmatkins> szilles: What unicode categories are these?
# [05:10] <ShmabShmatkins> fantasai: Proposal is to treat as the ID class (ideographic).
# [05:10] <Zakim> +??P1
# [05:10] <ShmabShmatkins> fantasai: Current behavior is not actually expressible in teh unicode spec.
# [05:10] <koji> zakim, +??p1 is me
# [05:10] <Zakim> sorry, koji, I do not recognize a party named '+??p1'
# [05:10] <koji> zakim, ??p1 is me
# [05:10] <Zakim> +koji; got it
# [05:10] <ShmabShmatkins> fantasai: Unicode puts "glue" (nbsp, etc) as a higer priority as nearly anything else.
# [05:11] <ShmabShmatkins> fantasai: But images apparently decided they ahve a higher priority than forced non-breaking.
# [05:11] <ShmabShmatkins> fantasai: So this change'll bring us *more* in line with the unicode spec.
# [05:11] <ShmabShmatkins> fantasai: Any comments, or should we make the fix?
# [05:11] <ShmabShmatkins> zcorpan: I don't understand the consequences?
# [05:11] <ShmabShmatkins> fantasai: Example: "<img> foo", you can't break after the img any more.
# [05:12] <ShmabShmatkins> fantasai: Or "(<img>)", you can't break in the parens anymore, they'll stay with the image.
# [05:12] <Zakim> -koji
# [05:12] <ShmabShmatkins> zcorpan: I'll search if Presto has any open compat bugs for it.
# [05:12] <ShmabShmatkins> zcorpan: I also posted a link to Quirks Mode. Line-breaking there is a bit different, at least for table cells.
# [05:12] <ShmabShmatkins> zcorpan: If we change how linebreaking works around images, it might need to be adjusted in Quirks.
# [05:13] * Quits: stryx` (~stryx@public.cloak) (Ping timeout: 180 seconds)
# [05:13] <ShmabShmatkins> zcorpan: When you calculate the minimum width of the table cell, you act like there's no breaking opportunity around images.
# [05:13] <koji> are you proposing to fix just for images and leave other replaced elements?
# [05:13] <ShmabShmatkins> zcorpan: But when you actually lay out there might be linebreaks there.
# [05:13] * koji can't call in...
# [05:13] <ShmabShmatkins> fantasai: For all replaced elements.
# [05:13] <ShmabShmatkins> fantasai: And for U+FFFC
# [05:14] <koji> I'm negative, at least for <input>, that'll break too much
# [05:14] <koji> I'm not sure how much we'd break for <img> though
# [05:14] * fantasai checks presto
# [05:14] <ShmabShmatkins> fantasai: What would it break for <input>?
# [05:15] <ShmabShmatkins> zcorpan: Looks like Presto has at least one bug about "<img> foo" breaking a website due to non-breaking.
# [05:15] <koji> Preseto being bugged from users indicates that there are legacy such content
# [05:15] <rbyers> koji: I'm checking it now to see if I can dial in alright.
# [05:16] <Florian> koji: yes, but it depends how much content this breaks. Hopefully not much.
# [05:16] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cstyle%3E%0Ahtml%20%7B%20font-size%3A%203em%3B%20%7D%0A%3C%2Fstyle%3E%0A(%3Cinput%3E)%3Cbr%3E%0A%3Cinput%3E.%3Cbr%3E%0A%3Cinput%3Eabc%3Cbr%3E%0A%3Cinput%3E%26nbsp%3Bfoo
# [05:16] <zcorpan> "There are cases where the total width of the images exceeds that of the containing <div> block and instead of creating a line break, Opera displays the image outside of the block." - url was http://www.clasohlson.se/product/category.aspx?category=kroppsv%c3%a5rd:tandv%c3%a5rd&id=88753177&_path=251882;85177601;88752827;88753177 but probably the site has changed
# [05:16] <koji> In HTML4, I believe, authors used to use   as a non-collapsible spaces
# [05:17] <koji> and used <input>  <input>
# [05:17] <koji> not sure how much such content survive today though
# [05:17] <Zakim> + +1.415.231.aaaa
# [05:18] <koji> zakim, +1.415.231.aaaa is me
# [05:18] <Zakim> +koji; got it
# [05:19] <ShmabShmatkins> koji: The bug was reported to Presto by a user; that indicates at leaest some users believe there should be forced break opportunities between   and <input>.
# [05:20] <ShmabShmatkins> Florian: It's definitely a breaking change; the question is if it's breaking too much.
# [05:20] <ShmabShmatkins> Florian: Not surprising that Presto gets a bug if everyone else does something different.
# [05:20] <ShmabShmatkins> Florian: Unsure that one single bug is enough evidence to rule it out. Presto survived for a while without fixing this.
# [05:21] * dauwhe please, everyone, vaccinate your browser today!
# [05:21] <rbyers> koji, dial-in working OK for you now?
# [05:21] * koji rbyers: yes, thank you!
# [05:22] * ShmabShmatkins Thanks, Rick!
# [05:22] <rbyers> ok, np - feel free to ping me on hangouts or IRC if it goes out again.
# [05:22] * zcorpan runs an httparchive search
# [05:22] <ShmabShmatkins> fantasai: So it sounds like Greg will look into actual websites and see what may or might not break.
# [05:22] <ShmabShmatkins> fantasai: Anything else to do?
# [05:23] <ShmabShmatkins> koji: I have seen editors that, when I type two spaces at the end of a sentence, converts it into multiple  
# [05:23] <fantasai> koji: treats nbsp as non-collapsible space
# [05:24] <ShmabShmatkins> murakami: I think the emoji and gaiji should be treated same as ideographic chars, and do linebreaking correctly.
# [05:24] <zcorpan> 16,311 pages in httparchive match REGEXP_MATCH(body, r'(\ <img\s|<img[^>]+>\ )')
# [05:24] <ShmabShmatkins> murakami: I don't understand why people wouldn't expect nbsp to not break.
# [05:25] <fantasai> murakami: That makes no sense and is a bug that we should fix
# [05:25] <ShmabShmatkins> zcorpan: I checked httparchive for nbsp before/after an image, and there were 16k matches.
# [05:25] <ShmabShmatkins> zcorpan: ABout 130k pages in the set, so about 12% of all the pages match the query.
# [05:26] <ShmabShmatkins> zcorpan: Haven't analyzed whether they're broken in Presto or not, but there's a lot of pages.
# [05:26] <ShmabShmatkins> plinss: So we'll come back to this with data?
# [05:26] <ShmabShmatkins> johanneswilm: This applies to <canvas> and <svg> and similar too?
# [05:26] <ShmabShmatkins> fantasai: Yes.
# [05:27] <ShmabShmatkins> fantasai: Another thing to consider is if nbsp is a big issue, but nothing else is -- nbsp isn't a big deal for emoji, they're mostly concerned about punctuation being correct.
# [05:27] <ShmabShmatkins> fantasai: We could just say that it behaves as an ideographic char *except* it still has a break opportunity between it and an nbsp.
# [05:27] <ShmabShmatkins> fantasai: It woudl be stupid, but it would fix all the other cases.
# [05:28] <fantasai> TabAtkins: Suggest we resolve to do ideographic change, and based on data may or may not do nbsp tweak to it
# [05:28] <ShmabShmatkins> fantasai: zcorpan, can you run a query with parens, or a period after the image?
# [05:28] <ShmabShmatkins> zcorpan: Sure.
# [05:29] * Joins: myakura (~myakura@public.cloak)
# [05:29] * koji that sounds like a reasonable approach
# [05:29] * dauwhe if there were 666 pages, I would not make the change
# [05:29] <zcorpan> r'(\(<img\s|<img[^>]+>[\)\.])' 999 matches
# [05:29] <ShmabShmatkins> RESOLVED: Treat replaced elements as ideographic chars for line-breaking. Based on data, possible add an exception for nbsp.
# [05:30] <Rossen> 999 out of 1000?
# [05:30] * Quits: myakura (~myakura@public.cloak) ("Page closed")
# [05:30] <zcorpan> out of ~130k
# [05:31] <fantasai> plinss: We need a really-non-breaking-space
# [05:31] <fantasai> fantasai: <img>&zwsp; 
# [05:31] <Rossen> zakim who is noisy
# [05:31] <ShmabShmatkins> dbaron: nbsp changed meaning between original (just a char that didn't add a breaking opportunity) and unicode later meaning (inhibits breaking around it).
# [05:31] * astearns tab vocalizing &zwsp;  made me concerned he'd had a stroke
# [05:31] <gregwhitworth> http://i.imgur.com/N8ouTs8.png
# [05:32] <gregwhitworth> https://lists.w3.org/Archives/Public/www-style/2014Nov/0282.html
# [05:32] <ShmabShmatkins> gregwhitworth: We had a bug a while ago (^^^ pic above) showing hex boxes.
# [05:32] <ShmabShmatkins> gregwhitworth: I brought it up on the list, asking Text to specify that control chars get shown.
# [05:32] <ShmabShmatkins> gregwhitworth: FF actually did this, but everyone assumed they were broken.
# [05:32] <ShmabShmatkins> gregwhitworth: So we all need to coordinate our release, to avoid getting inundated with bugs.
# [05:33] <ShmabShmatkins> gregwhitworth: And coordinate with, say, a 6-month period to give devs warning.
# [05:33] <ShmabShmatkins> gregwhitworth: So let's agree to make the change in, say, September?
# [05:33] <ShmabShmatkins> dbaron: Did we back it out?
# [05:33] <ShmabShmatkins> gregwhitworth: Yeah, the bug is in the discussion.
# [05:34] <ShmabShmatkins> gregwhitworth: roc is the one that suggested the coordination day.
# [05:34] <ShmabShmatkins> [greg goes to fetch roc]
# [05:34] * Joins: stryx` (~stryx@public.cloak)
# [05:35] <ShmabShmatkins> gregwhitworth: roc, we're trying to coordinate the visible-control-chars release.
# [05:35] * dauwhe http://en.wikipedia.org/wiki/Flag_Day_(United_States)
# [05:35] <ShmabShmatkins> roc: We alreayd have it implemented, we just need to flip a UA property.
# [05:35] <jet> Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1099557
# [05:36] <ShmabShmatkins> RESOLVED: Everyone go coordinate on Sep being when control characters become visible.
# [05:38] <Rossen> zakim, who is noisy?
# [05:38] <fantasai> fantasai: Okay, so MSFT, Blink, and WebKit need ot implement behind a flag, preferably by June, and report back if sooner so we can coordinate
# [05:38] <Zakim> Rossen, listening for 10 seconds I heard sound from the following: MeetingRoom (4%)
# [05:38] <Rossen> zakim, mute MeetingRoom
# [05:38] <Zakim> MeetingRoom should now be muted
# [05:38] <Rossen> zakim, unmute MeetingRoom
# [05:38] <Zakim> MeetingRoom should no longer be muted
# [05:39] <ShmabShmatkins> [alan summons Dean]
# [05:39] <ShmabShmatkins> [alan begins by drawing a pentagram on the floor]
# [05:39] <ShmabShmatkins> [Dean curses us all]
# [05:41] <ShmabShmatkins> Dean: I can't control when an iPhone releases, so...
# [05:41] <ShmabShmatkins> gregwhitworth: As long as we have enough.
# [05:42] <ShmabShmatkins> Dean: If we committed to doing it...
# [05:42] <ShmabShmatkins> fantasai: Just impl behind a flag, and flip it at the same time as everyone else. Everyone else might get it out sooner, but we all know it's coming out in Safari too.
# [05:43] <ShmabShmatkins> Dean: Okay.
# [05:43] <ShmabShmatkins> gregwhitworth: Chrome and FF are the main ones that can just ship it whenever. MS and Apple will have to just commit to it.
# [05:44] <ShmabShmatkins> [alan erases pentagram]
# [05:44] <ShmabShmatkins> [Dean returns to whence he came]
# [05:44] <zcorpan> ACTION Dean break the web behind a flag in webkit
# [05:44] * trackbot is creating a new ACTION.
# [05:44] <trackbot> Created ACTION-671 - Break the web behind a flag in webkit [on Dean Jackson - due 2015-02-16].
# [05:45] <ShmabShmatkins> johanneswilm: I hope I'm not using those chars that'll become visible after.
# [05:45] <ShmabShmatkins> gregwhitworth: We'll put out PR to help people figure this out.
# [05:45] <ShmabShmatkins> Topic: Writing Modes
# [05:46] <ShmabShmatkins> fantasai: Writing modes!
# [05:46] <ShmabShmatkins> fantasai: We dont' hav eimpls of the sideways-left value.
# [05:46] <ShmabShmatkins> fantasai: 1) leave it as is
# [05:46] <ShmabShmatkins> fantasai: 2) mark it as at-risk, and note that if someone implements just sideways-right, don't implement sideways
# [05:46] * zcorpan notes that the HTML parser removes U+0000 in most places (instead of turning to U+FFFD) exactly because people don't expect it to be visible garbage
# [05:46] <ShmabShmatkins> fantasai: 3) punt it to level 4
# [05:47] <ShmabShmatkins> fantasai: I think we should do #2 because it's important for non-CJK upright scripts.
# [05:47] <ShmabShmatkins> fantasai: LIke a caption on the left side of a table, or table column headers that are vertical in English, you need this value.
# [05:47] <ShmabShmatkins> fantasai: So I don't think we should remove it.
# [05:47] <ShmabShmatkins> fantasai: But if it's the only thing blocking writing modes from exitting CR, it might be worth dropping it.
# [05:48] <ShmabShmatkins> Tab: I say keep it in until CR-exit is immanent.
# [05:48] <ShmabShmatkins> koji: I say move it to Level 4.
# [05:49] <ShmabShmatkins> koji: Concerns about how it is designed today were raised, and I'd like further discussion.
# [05:49] <ShmabShmatkins> koji: So punting is appropriate.
# [05:49] <astearns> s/immanent/imminent/
# [05:49] <ShmabShmatkins> fantasai: Nobody ahs raised an issue with the design afaik.
# [05:49] <ShmabShmatkins> fantasai: People have said "I don't like this, it's confusing and complicated".
# [05:49] <ShmabShmatkins> koji: Rossen suggested rotating the line 180deg inline
# [05:49] <ShmabShmatkins> fantasai: We could make it apply to blocks only if that's the issue.
# [05:50] * ShmabShmatkins No, I meant immanent.
# [05:50] * astearns CR-exit does not permanently pervade and sustain the universe
# [05:50] * ShmabShmatkins Immanentize the CR-Exitchon
# [05:51] * koji can you hear me?
# [05:51] <ShmabShmatkins> plinss: I don't see the harm in marking it at-risk versus punting it for now.
# [05:51] * ShmabShmatkins Yeah, we can hear you koji.
# [05:51] * ShmabShmatkins We were all quietly contemplating.
# [05:51] <ShmabShmatkins> plinss: Has anyone implemented sideways-right but not sideways-left?
# [05:51] <ShmabShmatkins> fantasai: Yeah, because sideways-right is needed for CJK.
# [05:52] <ShmabShmatkins> astearns: At-risk seems the right thing to do for now.
# [05:52] <koji> AH, Blink, and WebKit does
# [05:52] <ShmabShmatkins> Rossen: We can alway spush it to 4 later.
# [05:52] <ShmabShmatkins> plinss: Any objections?
# [05:53] <ShmabShmatkins> RESOLVED: Keep sideways-left, mark as at-risk, possibly punt if it threatens CR-exit.
# [05:53] <ShmabShmatkins> fantasai: Next is propagation of writing-mode and direction from <body>
# [05:54] <ShmabShmatkins> koji: Did we decide on 'sideways'?
# [05:54] <ShmabShmatkins> fantasai: Same deal - if you can't do sideways-left, you can't do sideways.
# [05:54] <ShmabShmatkins> koji: Okay.
# [05:54] <ShmabShmatkins> fantasai: Right now in HTML we prop from root to the ICB, and the proposal is to ignore the value on the root and propagate from the body to both the root and the ICB. Ignore the root's value entirely.
# [05:54] <ShmabShmatkins> Rossen: So if you have <html dir=rtl><body dir=ltr>, it's ltr?
# [05:55] <ShmabShmatkins> Rossen: Is that a good idea?
# [05:55] <ShmabShmatkins> fantasai: We need to do something like this. For background, we can do the "check to see if root has it specified, if not, check body".
# [05:55] <ShmabShmatkins> fantasai: But this is inherited - there is always a valid value. So you have to choose one or the other unconditionally.
# [05:56] <ShmabShmatkins> Florian: I believe direction is a web-compat issue; it's been that way forever. We'd prefer it inherit normally, but we probably can't change it.
# [05:56] <ShmabShmatkins> Florian: And writing-mode should act similarly.
# [05:56] <ShmabShmatkins> Rossen: We have logic that doesn't match that since IE6.
# [05:56] <ShmabShmatkins> Rossen: We take root if specified, and use body otherwise.
# [05:57] <ShmabShmatkins> Rossen: Same for overflow.
# [05:57] <ShmabShmatkins> Rossen: This suggestion may have compat issues in cases where both html and body specify a direction.
# [05:58] <ShmabShmatkins> Rossen: Before we decide how to spec this, we need to udnerstand how we're all doing.
# [05:58] <ShmabShmatkins> Rossen: I hope this is something we can keep consistent for overflow too.
# [05:59] <fantasai> testcase: data:text/html;charset=utf-8,<!DOCTYPE html>%0D%0A<title>..]<%2Ftitle>%0D%0A<style>%0D%0A%0D%0A head%2C title { display%3A block%3B }%0D%0A body { border%3A solid%3B width%3A 150%25%3B text-align%3A center%3B }%0D%0A<%2Fstyle>%0D%0A<body dir%3Drtl>%0D%0A..]
# [05:59] <ShmabShmatkins> zcorpan: In Blink it used to use the root element if it was specified on both, but it was changed to always use <body>, claiming compat with Gecko and IE.
# [05:59] <ShmabShmatkins> fantasai: Gecko seems confusing...
# [05:59] <ShmabShmatkins> dbaron: Gecko is inconsistent based on what is happening.
# [06:01] <ShmabShmatkins> dbaron: You can test how direction behaves on root by...
# [06:01] <ShmabShmatkins> dbaron: 1) Which side you can scroll to when there's overflow from the viewport.
# [06:01] <ShmabShmatkins> dbaron: 2) If the root element is relpos and has both left and right set, which one wins.
# [06:02] <ShmabShmatkins> dbaron: 3) If the root element has overconstrained margins, which gets ignored.
# [06:02] <ShmabShmatkins> dbaron: 4) if the root or body is abspos, which position gets used for hypothetical box calcs.
# [06:03] <ShmabShmatkins> dbaron: Probably most likely to cause breakage is scroll direction.
# [06:03] <fantasai> dbaron: data:text/html;charset=utf-8,<!DOCTYPE html>%0D%0A<title>..*<%2Ftitle>%0D%0A<style>%0D%0A%0D%0A head%2C title { display%3A block%3B }%0D%0A html { border%3A solid silver%3B width%3A 80%25%3B margin%3A 0%3B }%0D%0A body { border%3A solid%3B width%3A 150%25%3B text-align%3A center%3B }%0D%0A<%2Fstyle>%0D%0A<body dir%3Drtl>%0D%0A..*
# [06:04] <ShmabShmatkins> [some discussion about <title> direction]
# [06:04] <fantasai> Presto scrolls as LTR (follows root)
# [06:04] <fantasai> Gecko aligns as LTR, but scrolls as RTL
# [06:04] <fantasai> which is not helpful at all
# [06:04] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ctitle%3E..*%3C%2Ftitle%3E%0A%3Cstyle%3E%0A%0A%20%20head%2C%20title%20{%20display%3A%20block%3B%20}%0A%20%20html%20{%20border%3A%20solid%20silver%3B%20width%3A%2080%25%3B%20margin%3A%200%3B%20}%0A%20%20body%20{%20border%3A%20solid%3B%20width%3A%20150%25%3B%20text-align%3A%20center%3B%20}%0A%3C%2Fstyle%3E%0A%3Cbody%20dir%3Drtl%3E%0A..*
# [06:05] <zcorpan> <title> seems like UI QoI
# [06:05] <fantasai> Blink aligns and scrolls as RTL
# [06:05] * fantasai asks about IE
# [06:05] * zcorpan fantasai use "save" next time :-)
# [06:06] * dbaron wonders if it's time for the afternoon break soon
# [06:07] * plinss after this
# [06:07] <fantasai> IE shows the whole canvas and can scroll to it, and aligns per RTL, but the initial scroll position is per LTR
# [06:07] * tantek wonders with dbaron
# [06:07] <tantek>
# [06:07] * dauwhe wouldn't it be easier to just change html? <body><html><p>Hello, World</p></html></body>
# [06:07] * astearns cameron's pretty sure it is time for the break
# [06:07] * tantek break++
# [06:07] * heycam :)
# [06:07] <ShmabShmatkins> Florian: So more testing to see what exactly is happening, and which is interoperable?
# [06:08] <ShmabShmatkins> fantasai: Whichever one is less likely to cause breakage is what we should do.
# [06:08] * dauwhe if we don't get a break soon I'll type a br tag in the XML serialization.
# [06:08] <ShmabShmatkins> dbaron: Fixing the spec might make things inconsistent too.
# [06:08] <ShmabShmatkins> dbaron: You'll need to make up some new term, not computed value, and you'll need to make sure everything refers to this new term, not "computed value".
# [06:11] <tantek> scribenick: ShmabShmatkins
# [06:11] <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jan/0272.html
# [06:11] <fantasai> 710 pages with <body dir=rtl> and not <html dir=rtl>. (0.24%)
# [06:11] <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=1071098#c16 is where I got the list of ways to test direction on the root
# [06:12] <dbaron> fantasai: could propagate from the HTML attribute on the body, but not propagate CSS 'direction'
# [06:12] <ShmabShmatkins> html:has-child(body[dir=rtl]) { direction: rtl; }
# [06:12] <ShmabShmatkins> DONE
# [06:14] <ShmabShmatkins> ACTION Greg to figure out what options are sensible for the html/body dir thing.
# [06:14] * trackbot is creating a new ACTION.
# [06:14] <trackbot> Created ACTION-672 - Figure out what options are sensible for the html/body dir thing. [on Greg Whitworth - due 2015-02-16].
# [06:14] <ShmabShmatkins> <br dur=15m>
# [06:14] * Quits: kwkbtr (~kwkbtr@public.cloak) (Client closed connection)
# [06:18] * Rossen is now known as Rossen_away
# [06:21] <Zakim> -koji
# [06:26] <Zakim> disconnecting the lone participant, MeetingRoom, in Team_(css)04:01Z
# [06:26] <Zakim> Team_(css)04:01Z has ended
# [06:26] <Zakim> Attendees were MeetingRoom, koji
# [06:43] <ShmabShmatkins> </br>
# [06:44] <jdaggett> next topic is?
# [06:44] <ShmabShmatkins> jdaggett: Finishing up some comments about direction/writing-mode.
# [06:44] <ShmabShmatkins> Then the SVG1.1 keywords.
# [06:44] <jdaggett> ok
# [06:46] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [06:46] <ShmabShmatkins> dbaron: Xidorn tried to implement something, and we found a problem.
# [06:47] <ShmabShmatkins> dbaron: In CSS sometimes the process of computing one proeprty depends on another one.
# [06:47] <ShmabShmatkins> dbaron: And we need to keep these in a partial order, so no loops.
# [06:47] <ShmabShmatkins> dbaron: We discovered that Ruby and Writing Modes added a loop.
# [06:47] <ShmabShmatkins> dbaron: It's between 'display' and 'writing-mode'.
# [06:48] <ShmabShmatkins> dbaron: There's also an influence from 'ruby-position'.
# [06:48] * Rossen_away is now known as Rossen
# [06:48] <ShmabShmatkins> dbaron: display:ruby-text-container && ruby-position:inter-character => writing-mode computes to vertical-rl
# [06:49] <ShmabShmatkins> dbaron: Because intercharacter ruby needs to be drawn that way.
# [06:49] <ShmabShmatkins> dbaron: I've seen elevator signs in Taipei look like this.
# [06:50] <ShmabShmatkins> dbaron: When writing-mode changes between parent and child, and display is inline, it's changed to inline-block.
# [06:50] <ShmabShmatkins> dbaron: Because you can't really display a writing mode change unless the parent establishes a block
# [06:50] <ShmabShmatkins> dbaron: I think most of us agree that writing-mode has to mess with display.
# [06:50] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [06:51] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [06:51] <ShmabShmatkins> dbaron: So it's not strictly a loop, but this still doesn't work in our architecture.
# [06:51] <ShmabShmatkins> dbaron: roc suggested that the vertical-lr change be triggered by something else that display:ruby-text-container elements have.
# [06:53] * zcorpan rbyers gecko currently uses long for scrollTop, so NaN/Infinity converts to 0
# [06:53] <ShmabShmatkins> ShmabShmatkins: So our problem here is that we have a strict separation of properties into "levels" that compute in order.
# [06:53] <ShmabShmatkins> dbaron: Ours isn't strict, but we do have a strict ordering of inherited vs non-inherited properties, which ends up being the same thing.
# [06:54] * rbyers zcorpan: thanks. We were ignoring NaN and converting Infinity to scrollHeight, but I've filed a bug to change blink to convert to 0 as per the spec.
# [06:54] <ShmabShmatkins> fantasai: We could make the inline->inline-block a used value.
# [06:54] <ShmabShmatkins> dbaron: Making the computed value out of sync with the real value will be a security issue.
# [06:57] <ShmabShmatkins> [dang, missing some minuting]
# [06:57] <ShmabShmatkins> ShmabShmatkins: I think roc's suggestion can work. Add a magic property to <rtc> and anonymous ruby text containers. Authors have to add it manually if they're making their own.
# [06:58] <ShmabShmatkins> fantasai: Can this just be an implementation issue?
# [06:58] <ShmabShmatkins> [dbaron's thinks furiously]
# [06:59] <ShmabShmatkins> dbaron: What does it look like in inter-character ruby when there is an <rtc> with multiple <rt>s?
# [06:59] <ShmabShmatkins> fantasai: Each rt is after each rb. The rtc and rbc both encircle the entire thing.
# [06:59] <ShmabShmatkins> dbaron: That makes it sound like it's the rt that's vertical-rl, not the rtc.
# [07:00] <ShmabShmatkins> dbaron: If so, can we fix by changing the condition to "my parent's display is rtc and my ruby-position is inter-character"?
# [07:00] <ShmabShmatkins> fantasai: Or parent's ruby-position is inter-character.
# [07:00] <ShmabShmatkins> dbaron: If it's the ruby-text that becomes vertical-lr, I think that's okay.
# [07:00] <ShmabShmatkins> fantasai: Sounds good.
# [07:01] <fantasai> RESOLVED: writing-mode: vertical-lr on the <rt> based on parent's 'display' & 'ruby-position'
# [07:01] <ShmabShmatkins> heycam: The 'all' shorthand is desgined to exclude direction and unicode-bidi.
# [07:01] <ShmabShmatkins> heycam: Why?
# [07:02] <ShmabShmatkins> fantasai: direciton and unicode-bidi should never have existed. They're not stylistic, they're content properties.
# [07:02] <ShmabShmatkins> fantasai: So when resetting stylistic stuff, they shouldn't be reset.
# [07:02] <ShmabShmatkins> fantasai: But writing-mode *is* a stylistic choice.
# [07:02] <ShmabShmatkins> heycam: And text-orientation too?
# [07:02] <ShmabShmatkins> fantasai: Yes.
# [07:02] <ShmabShmatkins> Topic: SVG Keywords - kill them?
# [07:03] <ShmabShmatkins> heycam: There are some svg-specific keywords in writing modes.
# [07:03] <ShmabShmatkins> heycam: text-orientation:use-glyph-orientation, which means "do what the SVG-specific glyph-orientation-vertical/horizontal properties say".
# [07:03] <ShmabShmatkins> heycam: I was going to suggest to SVGWG to just drop those, since nobody implements them.
# [07:03] <ShmabShmatkins> heycam: Presumably you'd drop the value if we drop the proeprties.
# [07:03] <ShmabShmatkins> fantasai: Yes.
# [07:04] <ShmabShmatkins> heycam: Next is some writing-mode values, coming from XSL.
# [07:04] <ShmabShmatkins> heycam: We're going to drop all of those, and just refer to current CSS spec.
# [07:04] <ShmabShmatkins> heycam: So I suggest they get dropped from CSS.
# [07:04] <ShmabShmatkins> fantasai: Can you actually drop them?
# [07:04] <ShmabShmatkins> fantasai: It's reasonably likely there's no web content that uses them, but may be off-web content that uses them.
# [07:06] <ShmabShmatkins> ShmabShmatkins: Can we just death-pact with the SVGWG and choose to drop them if they do?
# [07:06] <ShmabShmatkins> heycam: AT least we'll drop them from SVG2.
# [07:06] <ShmabShmatkins> fantasai: But you'll still need the definition.
# [07:06] <ShmabShmatkins> fantasai: We might deprecate and define them simultaneously.
# [07:07] <ShmabShmatkins> heycam: In WM atm, there's wording that says "if you support these values, do XXX".
# [07:07] <ShmabShmatkins> heycam: We'll let you know what we decide.
# [07:07] <ShmabShmatkins> heycam: I found an old email of mine saying that some browsers do ipmlement glyph-orientation-*, but they didn't do it interoperably.
# [07:08] <ShmabShmatkins> fantasai: If the values only show up in attributes, you can use UA CSS to convert it to the proper values.
# [07:08] <ShmabShmatkins> fantasai: But if the existing content uses the CSS syntax, you need to keep it.
# [07:10] <ShmabShmatkins> RESOLVED: Drop the values if the SVGWG drops the values/properties, otherwise keep them.
# [07:10] <ShmabShmatkins> Topic: Multi-line/block ellipsis
# [07:10] <krit> This is exported from Photoshop:
# [07:10] <ShmabShmatkins> Florian: Not the first time we've discussed this.
# [07:10] <krit> .cls-15 {
# [07:10] <krit> writing-mode: tb;
# [07:10] <krit> glyph-orientation-vertical: 0;
# [07:10] <krit> }
# [07:10] <ShmabShmatkins> Florian: To refresh everyone, we have ellipsis.
# [07:11] * krit heycam --^
# [07:11] <heycam> krit, ok, that is interesting
# [07:11] <ShmabShmatkins> Florian: It only works in in the inline dimension. If a given line is overflowing, it gets ellipsized.
# [07:11] <dbaron> https://lists.w3.org/Archives/Public/www-style/2015Jan/0357.html
# [07:11] <ShmabShmatkins> Florian: Most people want something at the end of the last line of a block that's too long in the block direction.
# [07:11] <heycam> krit, can you write vertical text in photoshop? :)
# [07:11] <ShmabShmatkins> Florian: We actually ahve a resolution to add it to the spec, without specifying what's getting added.
# [07:11] * krit hey cam you can do far more with text than you can represent in SVG :)
# [07:11] <ShmabShmatkins> Florian: So I was looking into this...
# [07:12] * krit heycam in Photoshop
# [07:12] * Quits: dino (~textual@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [07:12] <ShmabShmatkins> Florian: I have some ideas, but while working on this, I figured this was a problem that should be unified with something similar, and so I'll be talking more about fragmentation than ellipsis.
# [07:12] * heycam krit ok
# [07:12] <ShmabShmatkins> Florian: When you say "I want ellipsis at the end of the last line", what does that mean? Last totally-fitting line? Does ink(shadow) count?
# [07:12] <ShmabShmatkins> Florian: Or do we just use fragmentation, which defines all of this?
# [07:13] <ShmabShmatkins> Florian: There's a property in the REgions spec called region-fragment.
# [07:13] <astearns> http://dev.w3.org/csswg/css-regions/#the-region-fragment-property
# [07:13] <ShmabShmatkins> Florian: It has 'auto' or 'break'. If the last region of the region chain overflows, and it says "auto", it overflows like normal. If 'break', it acts like there's another region, but just drops the rest.
# [07:13] <ShmabShmatkins> fantasai: This sounds like another value for overflow-y.
# [07:14] * Joins: cyril (~cyril@public.cloak)
# [07:14] <ShmabShmatkins> Florian: The REgions spec shows why that's not true; it's independent of overflow.
# [07:14] <fantasai> This is overflow-y: paged-hidden
# [07:14] <ShmabShmatkins> astearns: overflow-x/y can have effects independently of region-fragment
# [07:15] <ShmabShmatkins> ShmabShmatkins: Regardless, I think you're not invoking the property itself, just its concept?
# [07:15] <ShmabShmatkins> Florian: I think we can generalize this concept.
# [07:16] <ShmabShmatkins> Florian: [described the definition of the property again]
# [07:16] <ShmabShmatkins> fantasai: So you have overflow:scroll and hidden.
# [07:16] <ShmabShmatkins> fantasai: Same, but hidden just stops it rather than exposing the rest.
# [07:17] <ShmabShmatkins> fantasai: Similarly, this is like paged and "paged-hidden" - "page me, but don't expose the rest".
# [07:17] <tantek> q?
# [07:17] * Zakim sees no one on the speaker queue
# [07:17] <ShmabShmatkins> dbaron: I agree with florian.
# [07:17] <ShmabShmatkins> dbaron: When I was writing the Overflow spec, I found this awkward.
# [07:17] <ShmabShmatkins> dbaron: It was trying to put two different concepts in the Overflow property, one about visual overflow and one about pagination.
# [07:18] <ShmabShmatkins> dbaron: It was awkward that there were 'overflow' values (page and fragments) that were about how to paginate, so when you had those values, you had to arbitrarily pick what to do with the visual overflow that visible/hidden handled normally.
# [07:18] <ShmabShmatkins> fantasai: So that makes sense to me; maybe different properties for visual vs pagination overflow.
# [07:18] <ShmabShmatkins> fantasai: I'm okay with that.
# [07:18] <ShmabShmatkins> fantasai: As long as pagination and hiding pagination are in the same control.
# [07:19] <ShmabShmatkins> Florian: That's chapter 5 of my very long mail.
# [07:19] <ShmabShmatkins> [[Presumably a new book out this summer.]]
# [07:19] <ShmabShmatkins> Florian: So my new proposal is a 'fragmention' property.
# [07:19] <ShmabShmatkins> Florian: With values auto/none/break/paged/clone
# [07:20] <ShmabShmatkins> Florian: auto is "do the right thing in the middle of a region chain", etc
# [07:20] <fantasai> break is region-break: break behavior
# [07:20] <ShmabShmatkins> Florian: Should we explain regular pagination in terms of this?
# [07:20] <fantasai> paged is overflow: paged
# [07:20] <fantasai> clone is overflow: fragment
# [07:20] <tantek> s/fragmention/fragmentation
# [07:20] <ShmabShmatkins> Florian: By having this property on the page box, having "auto" compute to "paged", which lets you turn off pagination on a page and let things overflow.
# [07:20] <ShmabShmatkins> Florian: Dunno if that's useful.
# [07:21] <ShmabShmatkins> Florian: Reason this ties into ellipsis is that we have an issue about block ellipsis, and another issue about "how can we write 'continue on page 3'", we can unify these.
# [07:21] <ShmabShmatkins> Florian: So we'd solve the "put ... at the end of a block" the same way as "put ... at the end of a region that continues elsewhere", and eventually "put (page 3) at the end of a region" when we have those tools.
# [07:22] <ShmabShmatkins> tantek: When I've seen "include the first 3 lines" behavior, it's usually on social networks with a "more" link.
# [07:22] <ShmabShmatkins> tantek: I don't know how to combine auto-ellipsizing that and adding a link.
# [07:22] <ShmabShmatkins> Rossen: We discussed this in Seoul.
# [07:22] <fantasai> s/link/link that you can attach some other behavior to/
# [07:22] <ShmabShmatkins> Rossen: Talked about what to do with ellipsed behavior.
# [07:23] <ShmabShmatkins> Rossen: We added the "fade" ellipsis behavior, and there was talk about styling it, so it should be a pseudo-element.
# [07:23] <ShmabShmatkins> Rossen: So the ellipsed block is actually interactive. You can attach event handlers to the pseudo-element.
# [07:24] <ShmabShmatkins> Florian: Another possibility is adding a "fragment: into(<sel>)" that we could use later.
# [07:24] <ShmabShmatkins> tantek: I think I'm okay with unifying
# [07:25] <ShmabShmatkins> tantek: So we need a string, not just "ellipsis".
# [07:25] <fantasai> fantasai^: Bert had a pull model that I think makes more sense than into(<sel>)
# [07:26] <ShmabShmatkins> ShmabShmatkins: You can attach an event listener to the parent of the ::ellipsis pseudo, and do the "more" handling there.
# [07:26] <ShmabShmatkins> tantek: So one approach is an expansion when you click "more".
# [07:26] <ShmabShmatkins> tantek: Another is "more" being a link to another page.
# [07:27] <ShmabShmatkins> tantek: Third is "continued on page 3", where it loads totally different content, maybe saying "continued from page 1".
# [07:27] <dbaron> And some websites use both, and you can't tell which you're going to get until after you click it.
# [07:27] <fantasai> tantek^: another scrolls down to another part of the page
# [07:27] <ShmabShmatkins> tantek: I'd like to at least capture those.
# [07:27] <ShmabShmatkins> ShmabShmatkins: First two can be done with JS now; doing it CSS requires reviving the Hyperlink module. Third can be done as Region expansions in the future.
# [07:28] <ShmabShmatkins> Florian: My basic point is that if we try to solve block ellipsis separately from fragmentation, we'll have to solve these problems twice.
# [07:29] <ShmabShmatkins> johanneswilm: As I understand it, if you can have an ::after pseudoel that you put the ellipsis in, you can use JS to figure out what page something shows up on, and set 'content' appropriately.
# [07:29] <ShmabShmatkins> tantek: It's def solvable in JS today. Just want to let there be less JS, or no JS.
# [07:31] <ShmabShmatkins> Rossen: If your container is actually constrained so there's only two lines visually, you say max-lines:3, the behavior is still bad.
# [07:31] <ShmabShmatkins> Florian: No, max-lines:3 just puts a break opportunity after the 3rd line.
# [07:31] <ShmabShmatkins> Florian: Currently max-lines only applies to overflow:fragments; it should apply to any fragmentainer.
# [07:31] <ShmabShmatkins> ShmabShmatkins: Yes, assuming we have these new fragment values.
# [07:32] <ShmabShmatkins> Florian: So, proposal is we remove region-fragment property, replace it with the 'fragmentation' property.
# [07:32] <ShmabShmatkins> dbaron: I'm okay for now, haven't looked into the details.
# [07:33] <ShmabShmatkins> tantek: I agree with the general scop eof the proposal.
# [07:33] <ShmabShmatkins> RESOLVED: Replace region-fragment with 'fragmentation', written by Florian, determine where it belongs.
# [07:33] <ShmabShmatkins> fantasai: Why is max-lines only usable on fragmentainers? Should be on all containers.
# [07:33] <ShmabShmatkins> fantasai: block containers.
# [07:36] <ShmabShmatkins> [discussion over this]
# [07:37] <ShmabShmatkins> [???]
# [07:37] <tantek> (unminuted discussion about fragmentainers)
# [07:37] <ShmabShmatkins> [?????????]
# [07:37] <tantek> (height, fragment or not, making breaks)
# [07:37] <ShmabShmatkins> [?????????????????????????]
# [07:37] <astearns> s/[?????????]/[????????????????]/
# [07:39] * tantek plinss glazou we may be too tired to capture productive discussion / resolutions right now.
# [07:39] <ShmabShmatkins> Florian: So right now, if you say max-lines:3 on a <p> in the middle of a page, it'll break the page after the third line.
# [07:39] <ShmabShmatkins> Florian: Which is silly, so we need the <p> to be a fragmentainer.
# [07:39] * glazou tantek I think ShmabShmatkins captures pretty well question marks :-p
# [07:40] <ShmabShmatkins> Florian: To be automatic, maybe max-lines:non-none causes fragmentation:auto to compute to 'break'.
# [07:40] <ShmabShmatkins> fantasai: 'break' is a non-obvious name.
# [07:40] <ShmabShmatkins> ShmabShmatkins: Maybe 'discard'.
# [07:40] * tantek fantasai with value 'dance' ?
# [07:40] <ShmabShmatkins> Rossen: So max-lines is non-inherited.
# [07:40] * glazou tantek but yes, time to adjourn IMHO
# [07:40] <ShmabShmatkins> Rossen: So what if you have <div style="max-lines:3;"><div>...</div></div>
# [07:41] <ShmabShmatkins> Florian: Well, regardless of that answer, max-lines should apply to any block.
# [07:41] <fantasai> fantasai^: So, what I understnad is that the proposal is to take the values of 'overflow' that deal with fragmentation andmake them into a separate property, and add a value that does fragmentation but hides the overflow instead of continuing it on another page/clone
# [07:41] * tantek glazou agreed. I suggest resuming discussion of this in morning with specific proposed resolution from Florian
# [07:41] <ShmabShmatkins> astearns: David defined this well in the Overflow spec where he tries to take your case into account.
# [07:41] * tantek is trying to buy Florian some time to propose a specific resolution for this.
# [07:41] <ShmabShmatkins> astearns: We can resolve the issue over there.
# [07:41] <astearns> http://dev.w3.org/csswg/css-overflow/#max-lines
# [07:41] * glazou tantek why not ; but after first item (LG’s rounded display, they come specifically for that from korea)
# [07:41] * tantek glazou WFM
# [07:42] <ShmabShmatkins> astearns: But the discussion is about fragmentation.
# [07:42] <tantek> q?
# [07:42] * Zakim sees no one on the speaker queue
# [07:42] <ShmabShmatkins> Florian: So do we want to do regular pagination with this fragmentation property?
# [07:42] <ShmabShmatkins> fantasai: I was thinking paging was overflow:paged on the root element.
# [07:43] <ShmabShmatkins> fantasai: overflow:paged creates pages the same way that scrollbox creates a scrollable canvas in the viewport. Instead of scrolls, you get pages.
# [07:43] <ShmabShmatkins> fantasai: Each of those pages are styable with an @page rule, regardless of whether the whole doc is paged, or a small section.
# [07:44] <ShmabShmatkins> Florian: So in some contexts, auto becomes paged, and maybe 'break' becomes 'overflow:hidden' or whatever on the root element.
# [07:45] <ShmabShmatkins> RESOLVED: Split fragmentation values of 'overflow' into a separate property. Further develop this in the overflow module.
# [07:45] <johanneswilm> Has it been defined what kinds of elements each of those pages has?
# [07:45] * tantek has an early evening proposal (TabAtkins, fantasai, anyone else that wants) zombie tiki bar: ~18:30 Papa Gede's bar, 348 Kent Street.
# [07:45] <johanneswilm> (header, body element, footnote area, page number area, page float area?)
# [07:46] <ShmabShmatkins> Florian: That property that gets separated out, is the region-fragment property. So pull it out.
# [07:46] <johanneswilm> Or can it be definable by the user?
# [07:47] <ShmabShmatkins> RESOLVED: region-break gets folded into the new property, too.
# [07:47] <ShmabShmatkins> astearns: If this goes into Overflow, add Florian as an editor?
# [07:47] <ShmabShmatkins> dbaron: Yes.
# [07:47] <ShmabShmatkins> RESOLVED: Florian added as editor to Overflow.
# [07:48] <ShmabShmatkins> fantasai: Do we have a def of overflow-x/y?
# [07:48] <ShmabShmatkins> dbaron: Kinda, in Overflow.
# [07:48] <ShmabShmatkins> fantasai: Gonna say that when we have that, we cut that as Overflow 3 and have everything new in Overflow 4.
# [07:49] <ShmabShmatkins> Florian: I think region is the only fragmentainer that have ::before/after, but now you can.
# [07:49] <ShmabShmatkins> astearns: We needed ::before/after in our processing model to see how they work in named flows.
# [07:50] <ShmabShmatkins> astearns: If we assume that ::before/after are always blocks in a fragmentainer (what we currently do), then we'd want to extend that.
# [07:50] <ShmabShmatkins> fantasai: What if the remaining space is negative?
# [07:50] <ShmabShmatkins> Rossen: Defined in the region spec.
# [07:51] <ShmabShmatkins> fantasai: Can they turn into runins?
# [07:51] <ShmabShmatkins> Florian: I'd like to.
# [07:51] <ShmabShmatkins> Florian: When you're doing ::after on fragmentainer, there are cases you want to only do ::after if you're fragmenting.
# [07:52] <ShmabShmatkins> Florian: So maybe have an ::ellipsis-like thing to help handle that.
# [07:53] <ShmabShmatkins> fantasai: Then we have the remaining issue about how to make it interactive.
# [07:53] <fantasai> florian: That's a general pseudo-element issue
# [07:54] <fantasai> fantasai: yes, but it's a core part of these use cases; not so much for other pseudos
# [07:54] <ShmabShmatkins> heycam: How do you align the ::ellipsis? For the block one, does it appear as a block right below?
# [07:54] <ShmabShmatkins> Florian: The way I remember it is "you know how wide this thing is, so you can lay out your ::after".
# [07:55] <ShmabShmatkins> johanneswilm: I tried to do footnotes with regions, and ::before/after were problematic.
# [07:55] <ShmabShmatkins> johanneswilm: I couldn't have a footnote marker get left behind, etc.
# [07:56] * dbaron worries we might have a bit of a run-in over display:run-in :-P
# [07:56] <ShmabShmatkins> [?????????????????]
# [07:58] <ShmabShmatkins> dbaron: I initially wanted [it] that way...
# [07:58] <ShmabShmatkins> dbaron: We realized there was a rpoblem that you design some style with overflow:fragments, style each fragment,
# [07:58] <ShmabShmatkins> dbaron: Then fragment 2 gets a page break in it.
# [07:59] <ShmabShmatkins> dbaron: You don't want your styles to be one off because you fragment3 styles get applied to the second half of what was originally fragment 2.
# [07:59] <dauwhe> s/[?????????????????]/johanneswilm and dauwhe got distracted by footnotes and went off-topic/
# [07:59] <ShmabShmatkins> dbaron: Probably a way around that, but we're getting complicated.
# [07:59] * ShmabShmatkins Thanks, dauwhe/
# [07:59] <ShmabShmatkins> <br dur="til morning">
# [08:00] <dbaron> Florian: do we want a one-off fragmentation value for columns, or use 'clone'
# [08:00] <dbaron> fantasai: use a magic value
# [08:00] <dbaron> dbaron: not so sure, I wouldn't want to have to explain what that magic does elsewhere
# [08:00] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [08:01] * Quits: kwkbtr (~kwkbtr@public.cloak) ("")
# [08:01] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [08:01] * Quits: glazou (~glazou@public.cloak) (glazou)
# [08:01] * heycam is now known as heycam|away
# [08:01] <tantek> TabAtkins, fantasai: Tiki Bar: ~18:30 Papa Gede's bar, 348 Kent Street.
# [08:02] * Quits: xidorn (~upsuper@public.cloak) (Client closed connection)
# [08:03] * Quits: tantek (~tantek@public.cloak) (tantek)
# [08:05] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [08:07] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [08:07] * Quits: AndreyR (~AndreyR@public.cloak) (Ping timeout: 180 seconds)
# [08:07] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [08:08] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [08:09] * Quits: cyril (~cyril@public.cloak) (Ping timeout: 180 seconds)
# [08:14] * Rossen is now known as Rossen_away
# [08:14] * Quits: roc (~chatzilla@public.cloak) (Client closed connection)
# [08:14] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [08:21] * Joins: tantek (~tantek@public.cloak)
# [08:23] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [08:25] * Quits: tantek (~tantek@public.cloak) (tantek)
# [08:47] * leaverou_away is now known as leaverou
# [09:06] * Joins: svillar (~sergio@public.cloak)
# [09:09] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [09:18] * Joins: rego (~smuxi@public.cloak)
# [09:26] * Quits: antonp1 (~Thunderbird@public.cloak) (Client closed connection)
# [09:26] * Joins: antonp (~Thunderbird@public.cloak)
# [10:11] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [10:29] * Quits: jet (~uid49872@public.cloak) ("Connection closed for inactivity")
# [10:49] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [11:07] * Joins: lajava (~javi@public.cloak)
# [11:09] * Rossen_away is now known as Rossen
# [11:18] * Rossen is now known as Rossen_away
# [12:19] * Joins: zcorpan (~zcorpan@public.cloak)
# [12:29] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [12:56] * Joins: dbaron (~dbaron@public.cloak)
# [13:08] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [13:10] * Joins: Florian (~Florian@public.cloak)
# [13:18] * Joins: dauwhe (~dauwhe@public.cloak)
# [13:20] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [13:24] * Joins: jdaggett (~jdaggett@public.cloak)
# [13:44] * Joins: Florian_ (~Florian@public.cloak)
# [13:50] * Quits: lajava (~javi@public.cloak) ("Leaving")
# [13:50] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [13:51] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
# [13:52] * Joins: Florian (~Florian@public.cloak)
# [14:00] * Joins: antonp (~Thunderbird@public.cloak)
# [14:09] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [14:12] * Rossen_away is now known as Rossen
# [14:16] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [14:17] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [14:18] * Joins: tantek (~tantek@public.cloak)
# [14:18] * Quits: tantek (~tantek@public.cloak) (tantek)
# [14:24] * Rossen is now known as Rossen_away
# [14:35] * Quits: svillar (~sergio@public.cloak) (Ping timeout: 180 seconds)
# [14:36] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [14:36] * Joins: lajava (~javi@public.cloak)
# [14:49] * Joins: svillar (~sergio@public.cloak)
# [15:11] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [15:26] * Joins: johanneswilm (~johannes@public.cloak)
# [15:33] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [15:56] * Joins: johanneswilm (~johannes@public.cloak)
# [16:19] * Joins: thinkxl (~thinkxl@public.cloak)
# [16:29] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [16:34] * Joins: lajava (~javi@public.cloak)
# [16:41] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [16:51] * Quits: svillar (~sergio@public.cloak) (Ping timeout: 180 seconds)
# [17:05] * Joins: johanneswilm (~johannes@public.cloak)
# [17:17] * Rossen_away is now known as Rossen
# [17:18] * Joins: Florian (~Florian@public.cloak)
# [17:25] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [17:27] * Rossen is now known as Rossen_away
# [17:36] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [17:47] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [17:52] * Joins: bkardell_ (~uid10373@public.cloak)
# [17:54] <bkardell_> anyone with practical implementation knowledge handy atm?
# [17:54] <bkardell_> have a simple question
# [18:12] * Joins: estellevw (~estellevw@public.cloak)
# [18:13] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [18:24] * Joins: johanneswilm (~johannes@public.cloak)
# [18:28] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [18:30] * Joins: adenilson (~anonymous@public.cloak)
# [18:35] <Ms2ger> shepazu, around?
# [18:35] <shepazu> hey, Ms2ger
# [18:35] <Ms2ger> shepazu, I'm hearing that the ED link on http://www.w3.org/TR/webmidi/ is broken; is that something you could get fixed in-place?
# [18:36] <shepazu> Ms2ger, I can ask... it's not normally something we do :(
# [18:37] <Ms2ger> I'd appreciate that
# [18:37] * shepazu wonders if maybe we should publish a new TR draft, it's been a while...
# [18:37] <Ms2ger> If not, can you keep an eye on it for the next pub?
# [18:37] <Ms2ger> Also, don't we run linkcheckers anymore?
# [18:37] <Ms2ger> Oh
# [18:37] <Ms2ger> Wrong link, not broken link
# [18:38] <shepazu> right
# [18:40] <shepazu> should be http://webaudio.github.io/web-midi-api/
# [18:42] * Joins: lajava (~javi@public.cloak)
# [18:48] <shepazu> Ms2ger, current policy is to publish a new draft, still can't update in place :( (though apparently that might be changing soon)
# [18:49] <Ms2ger> Ah, W3C slowly being dragged into the last century? :)
# [18:50] <shepazu> Ms2ger, don't get me started :P
# [18:51] <shepazu> Ms2ger, but I'm starting the process to publish a new draft, anyway... it needs one, after 1.3 years
# [18:51] <Ms2ger> You're right, I'd rather not :)
# [18:51] <Ms2ger> wfm
# [18:52] <shepazu> bkardell_, everyone's in Australia, so you should ask time-shiftedly
# [18:52] <Ms2ger> Thanks
# [18:52] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [18:52] <Ms2ger> shepazu, (mumble mumble heartbeat)
# [18:54] <shepazu> Ms2ger, yeah, I should crack the whip a bit more... I don't know what the changes to the spec would be... it's mostly waiting on implementations, I think
# [18:59] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [19:02] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [19:07] * Joins: johanneswilm (~johannes@public.cloak)
# [19:09] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [19:12] * Joins: lajava (~javi@public.cloak)
# [19:47] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [19:49] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [19:59] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [20:02] * Joins: dauwhe (~dauwhe@public.cloak)
# [20:07] * Joins: johanneswilm (~johannes@public.cloak)
# [20:17] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [20:23] * Rossen_away is now known as Rossen
# [20:34] * Rossen is now known as Rossen_away
# [20:37] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [20:42] * Joins: johanneswilm (~johannes@public.cloak)
# [20:52] * Quits: bkardell_ (~uid10373@public.cloak) ("Connection closed for inactivity")
# [21:03] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [21:04] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [21:09] * Joins: dauwhe (~dauwhe@public.cloak)
# [21:17] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [21:21] * Joins: johanneswilm (~johannes@public.cloak)
# [21:23] * Joins: glazou (~glazou@public.cloak)
# [21:26] * Joins: plh (plehegar@public.cloak)
# [21:33] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [21:39] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [21:39] * Joins: dauwhe (~dauwhe@public.cloak)
# [22:06] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [22:06] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [22:13] * Quits: glazou (~glazou@public.cloak) (glazou)
# [22:16] * Joins: glazou (~glazou@public.cloak)
# [22:22] * Quits: glazou (~glazou@public.cloak) (glazou)
# [22:44] * Joins: zcorpan (~zcorpan@public.cloak)
# [22:50] * Joins: glazou (~glazou@public.cloak)
# [22:52] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
# [22:58] * Joins: hyojin (~hyojin@public.cloak)
# [23:05] * Joins: dbaron (~dbaron@public.cloak)
# [23:06] * Joins: smfr (~smfr@public.cloak)
# [23:07] * Joins: dauwhe (~dauwhe@public.cloak)
# [23:07] * heycam|away is now known as heycam
# [23:08] * Joins: roc (~chatzilla@public.cloak)
# [23:09] <smfr> plinss: is csswg.org going to come back?
# [23:09] <smfr> oh there it is
# [23:09] <plinss> it just seems to be running slow this morning, not sure why...
# [23:12] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [23:18] <liam> speed: molasses | glacial | intercontinental-drift | galactic-formation
# [23:18] <liam> | initial | inherit | auto :)
# [23:20] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [23:20] * zcorpan gregwhitworth: http://w3c-test.org/html/semantics/embedded-content/the-img-element/ (ignore img.complete.html )
# [23:21] * zcorpan gregwhitworth: e.g. http://w3c-test.org/html/semantics/embedded-content/the-img-element/srcset/parse-a-srcset-attribute.html although this assumes 'w' is supported
# [23:22] * Joins: xidorn (~upsuper@public.cloak)
# [23:22] * zcorpan gregwhitworth: repo is https://github.com/w3c/web-platform-tests/
# [23:22] * Joins: Florian (~Florian@public.cloak)
# [23:28] * Rossen_away is now known as Rossen
# [23:29] * Joins: AndreyR (~AndreyR@public.cloak)
# [23:34] * ShmabShmatkins is now known as TabAtkins
# [23:35] <TabAtkins> Scribenick: TabAtkins
# [23:35] <TabAtkins> Topic: Rounded displays (sponsored by LG®)
# [23:35] <glazou> https://www.w3.org/wiki/TPAC2014/SessionIdeas#CSS_Extensions_to_support_a_round_display
# [23:35] * Joins: dino (~textual@public.cloak)
# [23:35] <glazou> http://www.w3.org/2014/10/29-rounddisplay-minutes.html
# [23:35] <glazou> http://www.w3.org/wiki/images/8/84/141029_W3C_TPAC_Breakout_Session_Round_Display.pdf
# [23:35] <TabAtkins> Hyojin: My name is Hyojin Song, working at LG's Software Platforms Lab.
# [23:36] * Joins: murakami (~murakami@public.cloak)
# [23:36] <TabAtkins> hyojin: This is the first time for LG to present something to the CSSWG.
# [23:37] <TabAtkins> hyojin: We have WebOS, embedded in TVs and watches.
# [23:37] <fantasai> ScribeNick: fantasai
# [23:37] <TabAtkins> hyojin: LG personally released a watch with WebOS last Jan.
# [23:37] <TabAtkins> hyojin: The platform is the web.
# [23:37] <TabAtkins> hyojin: Like HTML, CSS.
# [23:37] <fantasai> hyojin: HTML and CSS should support some requirements to present web content to web-based device
# [23:37] <fantasai> hyojin: LG smart watch display is round
# [23:37] <fantasai> hyojin: When developing apps, we have some difficulty aligning content sin the device this way
# [23:37] <fantasai> hyojin: So we would like to propose some ideas for orund display
# [23:38] <fantasai> hyojin: This is a slide presented last TPAC
# [23:38] <fantasai> hyojin: I'm going to briefly show you the concepts of our ideas using this slide
# [23:38] <fantasai> hyojin: New devices with ar round screen are emerging
# [23:38] <fantasai> hyojin: Here are 4 devices: ASUS ZenWatch, Moto360 LG G Watch R LG G3 when cover is close
# [23:38] <fantasai> closed
# [23:38] * liam Zakim, who is on the phone?
# [23:38] * Zakim apparently Team_(css)04:01Z has ended, liam
# [23:38] * Zakim sees on irc: murakami, dino, AndreyR, Florian, xidorn, gregwhitworth, kwkbtr, roc, dauwhe, smfr, dbaron, hyojin, glazou, zcorpan, plh, adenilson, thinkxl, rego, stryx`, ato,
# [23:38] * Zakim ... amtiskaw, mihnea_____, vollick_, heycam, RRSAgent, Zakim, dwim1, hgl, fantasai, ojan, krijnhoetmer, Rossen, shane, rbyers, dstockwell, krit, mvujovic______, ppk___,
# [23:38] * Zakim ... CSSWG_LogBot, liam, Rossen_, iank, abucur___, birtles, robertknight_clo, renoirb, koji, cabanier, astearns, sgalineau, slightlyoff, hober, shepazu, logbot, JonathanNeal_,
# [23:38] * Zakim ... timeless, jumland, nikos
# [23:38] <fantasai> hyojin: Web was designed for a rectangular screen, especially CSS
# [23:38] * Joins: tantek (~tantek@public.cloak)
# [23:39] * Joins: jet (~uid49872@public.cloak)
# [23:39] <fantasai> hyojin: Here are some LG watch appplications [phtographs]
# [23:39] <fantasai> compass app, weather app, phoe dialer, etc.
# [23:39] <fantasai> hyojin: CSS should make these applications
# [23:39] <fantasai> hyojin: We have 4 ideas
# [23:39] <fantasai> hyojin: First is extension of media query
# [23:39] <fantasai> hyojin: Detect a round display
# [23:39] <fantasai> hyojin: Defined a 'device-radius' property, inspired by border-radius
# [23:40] <fantasai> hyojin: We made a specification like this. Very immature, but we have summarized here
# [23:40] <fantasai> [projects spec draft]
# [23:40] <fantasai> hyojin: Takes same syntax as border-radius
# [23:40] * Joins: jaredwy (~uid2122@public.cloak)
# [23:40] <dbaron> is there a URL for that spec?
# [23:40] <fantasai> hyojin: 0% is rectangular display
# [23:40] <fantasai> hyojin: Round display
# [23:41] <fantasai> hyojin: Can dtect the shape of the display
# [23:41] * Joins: sanja (~sanja@public.cloak)
# [23:41] <fantasai> Florian: I think the MQ is quite reasonable
# [23:41] <fantasai> Florian: How complicated or simple do we want to be?
# [23:41] <fantasai> Florian: There's a clear real use case for rounded display
# [23:41] <fantasai> Florian: what do we do about e.g. triangle display or whatever?
# [23:42] <dbaron> fantasai: we have proposals for addressing this for borders, triangles for example, changing the shape for the corners
# [23:42] <dbaron> fantasai: this approach is fine and we can extend as we need
# [23:42] <fantasai> glazou: Devices fo rmobile are changing very rapidly
# [23:43] <fantasai> glazou: Change shapes in 2d, but also in 3d, e.g. rounded surface. Display is different on the curve
# [23:43] <fantasai> glazou: First bendable screen just appeared
# [23:43] <fantasai> glazou: Will reach a completely new set of characteristics of screens that we will need to cover in the future
# [23:43] * heycam imagines octagonal screens, just like Battlestar Galactica; appropriate we're meeting in Cylon today
# [23:43] <fantasai> Florian: Works for rect, rounded rect, ellipses, but what else?
# [23:44] <fantasai> roc: Do we have the goal of only detecting what shape it is and use MQ to create different layouts for each shape
# [23:44] <fantasai> roc: Or create layouts that will adapt to any shape
# [23:44] <fantasai> roc: MQ will help with the first, not the second
# [23:44] <fantasai> roc: Need to decide on goal, one or other or both.
# [23:44] <fantasai> hyojin: device-radius is limited in expressivity
# [23:44] * liam was thinking about square with curved corners, like old CRT tubes, but why not pyramidical 3d?
# [23:44] <fantasai> hyojin: Next topic is content alignment
# [23:45] <fantasai> hyojin: CSS shape-inside
# [23:45] <fantasai> hyojin: In rectangle display like this [floats and text in rectangle]
# [23:45] <fantasai> hyojin: If you put it on a round display, the corners cannot be shown on the display
# [23:45] <fantasai> hyojin: We want the content to flow inside the shape, like this [photo]
# [23:45] <fantasai> hyojin: We extended shape-inside like this: add value 'display'
# [23:46] <fantasai> hyojin shows content flowed into a circle
# [23:46] <fantasai> hyojin shows content that starts partway down the screen, wraps into the semicircle of the bottom of the screen
# [23:47] <fantasai> hyojin: We didn't implement in browsers, we automatically generate the shape like this [shows code]
# [23:47] <fantasai> hyojin: Next topic is border
# [23:47] <fantasai> hyojin: Borders extend outward from the edge of the screen, want it to fit in the screen.
# [23:48] <fantasai> hyojin: So we defined new 'border-boundary' property, values 'none' or 'display'
# [23:49] <fantasai> Florian: Did you consider keyword to make shape-inside and border-boundary to match?
# [23:49] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [23:49] <fantasai> astearns: I think it's a different problem they're trying to solve
# [23:49] <fantasai> astearns: They're trying to ge tthe childrens border to match the contours of a parent's shape-inside
# [23:49] <fantasai> Florian: Exactly. Parent has hape-inside: display
# [23:49] <fantasai> Florian: The children match the shape-inside of the parent
# [23:50] <fantasai> tantek: This feels like a position: fixed approach
# [23:50] <fantasai> tantek: relative to display
# [23:50] <fantasai> tantek: vs. position: absolute, where relative to some other block
# [23:50] <fantasai> dbaron I think it would also be possible to inset the borders as you go down the tree
# [23:51] <fantasai> dbaron: propagating the shape down based on margin/pdding/border
# [23:51] <fantasai> rossen: You gotta be able to find the shape going down. Display is only oneof the shapes as you're going down
# [23:51] <fantasai> hyojin: Many issues, something to consider, so we wrote the issue sin the spec
# [23:51] <fantasai> hyojin: I will share these materials into the CSS mailing list
# [23:51] <fantasai> hyojin: We can discuss topics of round display issues
# [23:52] <fantasai> hyojin: Last one is about layout features
# [23:52] <fantasai> Rossen: back on the borders
# [23:52] <fantasai> Rossen: This is easy to explain for solid borders
# [23:52] <fantasai> Rossen: What do you expect the behavior to be for, e.g. border -styles other than solid
# [23:52] <fantasai> Rossen: say I have a dashed border-right and a dotted border-top border
# [23:53] * Joins: dbaron (~dbaron@public.cloak)
# [23:53] <fantasai> fantasai: Probably same way as you solve it for border-radius
# [23:53] * Quits: jumland (~sid26952@public.cloak) (Ping timeout: 180 seconds)
# [23:53] <fantasai> Rossen: If it's round-ish, that works, what if it's a star?
# [23:53] * krit new lumina devices with star shape.... looking forward to it :P
# [23:53] <fantasai> Florian: Will require wordsmithing, but not an unsolvable issue
# [23:54] <fantasai> fantasai: Take 45deg from center, find that point on the shape, or some other formula
# [23:54] * Joins: johanneswilm (~johannes@public.cloak)
# [23:54] <fantasai> hyojin: Using canvas, I can draw differnet border shapes
# [23:54] * fantasai notes that those dashed lines look better than a lot of browsers' dashed lines
# [23:54] <fantasai> hyojin: Last one is layout
# [23:55] <fantasai> hyojin: We propose polar coordinates, to position around circle like this
# [23:55] <fantasai> hyojin: polar-angle and polar-distance properties with position: polar
# [23:55] * Joins: SteveZ (~SteveZ@public.cloak)
# [23:55] <fantasai> e.g. 'polar-angle: 225deg; polar-distance: 100%'
# [23:56] <fantasai> dirk: Positioning only, or other layout?
# [23:56] * heycam wonders if this could be done as part of transform
# [23:56] <fantasai> hyojin: Just positioning
# [23:56] <fantasai> TabAtkins: Other than the fact that 'position: polar' would go on the children, not on the container (be just like alternate version of abspos), looks good to me
# [23:57] * dauwhe looking forward to polar regions spec
# [23:57] <fantasai> dean: Which point is positioned at that point?
# [23:57] * astearns polar positioning with distance of 0 for centering
# [23:57] <fantasai> fantasai: polar-origin property to determine it
# [23:58] <fantasai> It should take an 'auto' value maybe that does automatic anchoring like backgrounds do
# [23:58] <dbaron> heycam: maybe better as a transform item, an alternate way of specifying a translate
# [23:58] * Joins: jumland (~sid26952@public.cloak)
# [23:58] <fantasai> glazou: Rounded display on a sphere, turning, ...
# [23:58] * fantasai missed a comment or two there
# [23:58] <fantasai> glazou: Why polar coordinates instead of transforms?
# [23:58] <fantasai> hyojin: We developed this using transforms
# [23:59] <fantasai> hyojin: I think the developer cna make applications like this easilky
# [23:59] <fantasai> TabAtkins: One nice thing about this is that you can animate this very nicely
# [23:59] <fantasai> TabAtkins: E.g. spiraling outward much easier.
# [23:59] <fantasai> tantek: This example makes it looks like the distance: 80% was very carefully chose to make it look like there is padding is on the parent that the children bump up against
# [23:59] <fantasai> tantek: Feels like a very fragile way of doing it
# Session Close: Tue Feb 10 00:00:00 2015

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