/irc-logs / w3c / #css / 2011-07-25 / end

Options:

# Session Start: Mon Jul 25 00:00:01 2011
# Session Ident: #css
# [00:00] <dbaron> fantasai: :scope, which was from selectors API 2
# [00:01] <dbaron> tantek: I think selectors 4 should be a superset of selectors 3.
# [00:02] <dbaron> tantek: I don't think it's reasonable to separate out pseudo-elements unless the splitter is writing both
# [00:02] <dbaron> fantasai: pseudo elements need a lot of work, and multiple pseudo-elements are hard
# [00:02] <dbaron> fantasai: things like querySelector also want selectors but not pseudo-elements
# [00:03] <dbaron> tantek: I think you should write up an explanation of the change in scope so we have something to point to
# [00:04] <dbaron> glazou: If selectors 4 stabilizes, do we want to release FPWD before selectors 3 is a REC, or is it a bad signal?
# [00:04] <dbaron> dbaron: I don't think we should wait
# [00:04] <dbaron> anne: XHR1 and XHR2 are released at the same time, hasn't caused problems
# [00:04] <dbaron> anne: We should publish our in-development work on TR -- otherwise people will just always read the editor's draft.
# [00:05] <dbaron> tantek: I think it's more confusing to have out-of-date specs.
# [00:05] <dbaron> fantasai: I don't think it's a problem to wait a week -- wouldn't want to wait a couple of months.
# [00:06] <dbaron> Tantek: I think it's more confusing to have out-of-date specs than to have multiple versions in different stages.
# [00:06] <dbaron> ...: levels and versions
# [00:06] <dbaron> fantasai: levels vs. versions doesn't matter here
# [00:07] <dbaron> [lots of people talking at once]
# [00:08] <dbaron> [lots of people talking at once]
# [00:08] <dbaron> tantek: I think it's important for selectors 4 to explain how it's different **and why**.
# [00:08] <dbaron> ... and how to consider it in terms of it being a draft and 3 being at PR/REC
# [00:08] <dbaron> ... a hint that says "if you want the stable thing, go here..."
# 06[00:09] * glazou thinks tantek suggest adding <blink>this is totally experimental and subject to change</blink> to the spec :-)
# [00:09] <dbaron> Steve: a marketing subcommittee to explain to the world what we're doing
# [00:10] <dbaron> Steve: I know a lot of people who think of css3 as a monolith.
# [00:10] <dbaron> fantasai: The snapshot should explain this.
# [00:10] <dbaron> glazou: anything else for selectors4?
# [00:10] <dbaron> fantasai: Anything else we need to sync with HTML5.
# 06[00:10] * tantek shudders at the use of both "marketing" and "subcommittee" in the same sentence.
# 06[00:11] * anne updated http://wiki.csswg.org/spec/reviews/html5 a bit
# [00:11] <dbaron> fantasai: I just went through backlog on www-style and added some of the requests.
# [00:11] <anne> fantasai, http://lists.w3.org/Archives/Public/www-style/2011Jul/0415.html
# [00:11] <dbaron> tantek: What about css3-ui having more UI selectors than selectors3, but selectors 4 incorporating all of the pseudo-classes but not the pseudo-elements
# [00:11] <dbaron> fantasai: I'm going to slurp in the pcs but not the pes
# [00:12] <dbaron> tantek: Need to take care to explain that.
# [00:12] <stearns> Tantek will organize the task force for selecting marketing subcommittee members
# [00:13] <dbaron> Steve: We've never documented to the outside world the process we use for making progress, how to modularize...
# [00:13] <dbaron> anne: Link to explanation of why pseudo-elements not in this draft?
# [00:13] <dbaron> Tantek: fantasai took an action to add that to the draft
# [00:14] <dbaron> [discussion of explaining modularization... in snapshot ...]
# [00:14] <dbaron> fantasai: What needs to be done before FPWD?
# [00:15] <dbaron> glazou: Add an example to :scope?
# [00:15] <dbaron> tantek: Do you want to include pseudo-classes that I'm looking into adding to css4-ui?
# [00:16] <dbaron> fantasai: Why don't you coedit this and add them
# [00:16] <dbaron> tantek: accepted
# [00:16] <dbaron> arron: What about pseudo-elements?
# [00:16] <dbaron> arron: Is anybody going to create that?
# [00:17] <dbaron> tantek: it may be one or more specs?
# [00:17] <dbaron> tantek: They may be tied to particular modules.
# [00:17] <dbaron> anne: :first-line and :first-letter could make more sense in line layout
# [00:17] <dbaron> dbaron: :before and :after in generated content
# [00:17] <dbaron> anne: :selection in UI
# [00:18] <dbaron> tantek: so, fantasai, put pointers in to these new locations?
# [00:18] <dbaron> fantasai: So pseudo-elements section here defines generic syntax and points to other modules
# 03[00:18] * Joins: shepazu (schepers@128.30.52.169)
# 02[00:18] * Quits: szilles (chatzilla@72.254.89.133) (Ping timeout)
# [00:18] <dbaron> glazou: may have to revisit second paragraph of 6.5 at some point
# [00:19] <dbaron> glazou: it makes sense to define the class attribute for all dialects rather than saying it's namespace-specific knowledge
# [00:19] <dbaron> tantek: I support Daniel's proposal.
# [00:19] <dbaron> anne: It works in SVG and MathML-- what's the problem?
# [00:19] <dbaron> glazou: Just say the 'class' attribute is always class.
# [00:19] <dbaron> peter: I don't think that will fly, and is outside of our scope.
# [00:20] <dbaron> anne: vague idea of making ID and class special in DOM core
# [00:20] <dbaron> peter: I don't think we can do this; we'd be defining XML.
# [00:20] <dbaron> anne: Can't define it here, but could define it in DOM core.
# 06[00:20] * shepazu glazou, plinss, you want a guest?
# [00:21] <dbaron> glazou: everything should have class
# [00:22] <dbaron> dbaron: I really don't want xml:class
# [00:22] <dbaron> fantasai: out of scope for us anyway
# [00:23] <dbaron> fantasai: I can make the spec say it's document-language specific, which is what it should have said.
# [00:23] <glazou> shepazu: ???
# [00:23] <glazou> shepazu: cookies are here, you're welcome
# [00:23] <shepazu> glazou: ok, cool
# [00:23] <anne> you can have a cookie
# [00:23] <anne> but not be our guest
# [00:24] <dbaron> plinss: anything else for selectors 4?
# 03[00:24] * Joins: szilles (chatzilla@72.254.89.133)
# [00:24] <dbaron> tantek: can we make the class attribute wording more encouraging "(e.g., HTML, SVG, MathML)"
# [00:24] <dbaron> fantasai: e.g., in docbook, the equivalent is the role attribute
# [00:25] <dbaron> tantek: I want the spec to suggest that if you're making a new XML language, it should use "class" as the class attribute.
# [00:25] <bradk> I had some pseudo-class ideas from 2007: http://lists.w3.org/Archives/Public/www-style/2007Nov/0108.html
# [00:25] <glazou> what about :unicorn ???
# [00:25] <dbaron> [discussion of editorial improvements]
# 06[00:26] * shepazu glazou, this is the right place? South Lake Union Mariott Courtyard
# [00:26] <glazou> shepazu: yes
# [00:26] <glazou> meeting room behind the lobby on the left hand side
# 02[00:27] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
# [00:27] <stearns> meeting room: Puget Sound
# [00:28] <dbaron> [brief discussion about placeholder styling]
# [00:28] <tantek> bradk - can you add those to http://wiki.csswg.org/spec/selectors4 ?
# [00:28] <bradk> OK
# [00:29] <dbaron> [15 minute cookie break]
# 02[00:30] * Quits: paul_irish (paul_irish@76.14.88.222) (Client exited)
# [00:32] <anne> http://search.twitter.com/search?q=%40mollydotcom
# [00:32] <mollydotcom> Thanks Anne!
# 02[00:35] * Quits: szilles (chatzilla@72.254.89.133) (Ping timeout)
# 03[00:39] * Joins: szilles (chatzilla@72.254.89.133)
# 02[00:39] * Quits: anne (annevk@72.254.92.35) (Ping timeout)
# 03[00:39] * Joins: paul_irish (paul_irish@76.14.88.222)
# 02[00:47] * Quits: sylvaing (sylvaing@72.254.95.170) (Quit: sylvaing)
# 03[00:47] * Joins: homata_ (homata_@58.158.182.50)
# 02[00:49] * Quits: vhardy (vhardy@72.254.56.182) (Quit: vhardy)
# [00:50] <TabAtkins_> ScribeNick: TabAtkins_
# [00:50] <TabAtkins_> fantasai: Just a few open issues to talk about.
# 03[00:51] * Joins: sylvaing (sylvaing@72.254.95.170)
# [00:51] <TabAtkins_> fantasai: Some we'd need jdaggett here fo.
# [00:51] <TabAtkins_> s/fo/for/
# [00:51] <fantasai> http://dev.w3.org/csswg/css3-text/#white-space-collapsing
# [00:51] <TabAtkins_> fantasai: Right now we have text-space-collapse. I wanted to see what people thought of the different values.
# [00:51] <TabAtkins_> fantasai: [explains the property values]
# [00:52] <TabAtkins_> fantasai: I think 'discard' is a bheavior in MathML.
# [00:53] <dbaron> dbaron: From TeX, I'm used to putting my footnotes exactly where I want the marker (considering whitespace).
# [00:54] <dbaron> glazou: I think the consume-* are trying to fix an error on the author side.
# [00:54] <dbaron> glazou: I think if the authors write the footnotes correctly, you don't need that.
# [00:54] <dbaron> fantasai: If you represented the footnote with parentheses, you'd want the space there.
# [00:54] <TabAtkins_> fantasai: A use-case for consume-before is footnotes - you may want whitespace between the text and the inline note, but when you use CSS to pull the footnote elsewhere, you probably want the footnote marker to be flush against the preceding text.
# [00:55] <TabAtkins_> fantasai: trim-inner is similar to the behavior of <pre> (which drops the first linebreak), but less restrictive.
# [00:55] <fantasai> glazou: Think consume-before is trying to fix an authoring error, just don't put the space there
# [00:56] <fantasai> fantasai: If you aren't styling as a footnote--if you leave the note inline -- then you want the space there.
# [00:56] <fantasai> fantasai: So it's not really an authoring error.
# [00:56] <TabAtkins_> tantek: HTML and XHTML have a slight different in whitespace processing. Could this address that?
# 02[00:57] * Quits: szilles (chatzilla@72.254.89.133) (Ping timeout)
# [00:57] <TabAtkins_> anne: I think that's handled at the parser level, so we don't have access to it.
# [00:59] <TabAtkins_> fantasai: I want trim-inner because I currently put comments in my code that just wrap whitespace, so I can indent my code how I like without extra blank lines showing up in my <pre>.
# 03[00:59] * Joins: szilles (chatzilla@72.254.89.133)
# [00:59] <dbaron> <html
# [00:59] <dbaron> ><head
# [01:00] <dbaron> ><title>...
# [01:00] <fantasai> s/want/added/
# 03[01:01] * Joins: anne (annevk@72.254.92.35)
# [01:02] <TabAtkins_> anne: What's the use-case for discard?
# [01:02] <TabAtkins_> fantasai: I think MathML discards whitespace at least some of the tiem.
# [01:02] <glazou> s/tiem/time
# [01:03] <TabAtkins_> dbaron: Our MathML impl discards a lot of whitespace.
# [01:03] <dbaron> but not all of it
# [01:03] <TabAtkins_> dbaron: I think MathML actually has trim-inner on the token elements (at least ours does)
# [01:04] <TabAtkins_> anne: Doesn't MathML have their own rendering model? Do they need CSS to solve things here?
# [01:04] <bradk> 'discard' would be useful for an element containing several buttons that are display:inline-block, and sometimes are authored with spaces and sometimes not.
# [01:05] <TabAtkins_> tantek: They're trying to move away from that and do a pure-CSS thing.
# [01:05] <bradk> Text editors that format HTML often put each button on each line
# [01:05] <TabAtkins_> Good case, bradk!
# [01:05] <bradk> :)
# [01:06] <fantasai> ACTION fantasai: list use cases for each white-space value
# 06[01:06] * trackbot noticed an ACTION. Trying to create it.
# [01:06] <trackbot> Created ACTION-345 - List use cases for each white-space value [on Elika Etemad - due 2011-07-31].
# [01:07] <TabAtkins_> fantasai: tab-size property. Brad suggested a <length>.
# [01:07] <TabAtkins_> fantasai: Also, possibly a 'sp' unit that corresponds to the width of a space.
# [01:08] <TabAtkins_> tantek: What's the use-case for brad's suggestion?
# [01:09] <TabAtkins_> bradk: The idea is that if you're formatting code, you may have bits that are different font size, but you want the tabs to all be the same size.
# [01:10] <TabAtkins_> glazou: I suggest pinging Mozilla for the "ace" project.
# [01:10] <TabAtkins_> anne: I think that's only a theoretical case.
# [01:11] <TabAtkins_> dbaron: It would be really easy for <length> to work - right now we only use the integer to multiple by the width of a space, turning it into a length.
# [01:11] <TabAtkins_> fantasai: So we can add <length> and mark it as risk.
# [01:13] <TabAtkins_> szilles: What does Word do?
# [01:13] <TabAtkins_> TabAtkins_: They have tab stops at explicit lengths.
# [01:13] <TabAtkins_> szilles: Thought so. Presumably they have a good reason?
# [01:14] <TabAtkins_> anne: If the use-cases are theoretical, we shouldn't waste time on it yet.
# [01:17] <TabAtkins_> arronei_: Different font-sizes are a use-case already. Dragonfly doesn't have multiple font sizes.
# [01:17] <TabAtkins_> anne: Doesn't everyone use monospace?
# [01:17] <TabAtkins_> [several]: No, we use variable-width.
# [01:17] <TabAtkins_> RESOLVED: Add <length> to tab-size, mark as at-risk.
# [01:17] <bradk> muting myself again
# [01:19] <TabAtkins_> fantasai: Only thing left is hyphenate-resource, but hakon isn't around right now.
# [01:19] <TabAtkins_> fantasai: Any objections to dropping it for now?
# [01:19] <TabAtkins_> RESOLVED: Drop hyphenate-resource. It can be put back if there's more impl interest.
# [01:19] <TabAtkins_> fantasai: Another issue is the underline values.
# [01:21] <TabAtkins_> fantasai: We decided to call them cancel-underline instead of no-underline, but that's inconsistent with XSL. Do we need a note?
# [01:21] <TabAtkins_> arronei_: Why did we change it from no-underline?
# [01:21] <TabAtkins_> fantasai: It doesn't actually shut down underlines; it just blocks the parent's underline and lets you set a new one.
# 03[01:22] * Joins: shepazu (schepers@128.30.52.169)
# 02[01:23] * Quits: plinss_ (plinss@72.254.91.11) (Quit: plinss_)
# [01:23] <TabAtkins_> [discussion about whether the naming is confusing]
# [01:26] <TabAtkins_> dbaron: What's the use-case for cancel-underline?
# [01:26] <TabAtkins_> TabAtkins_: One is editting - if you remove the underline from a span of underlined text, every text editor makes it easy. Right now, CSS's model means you have to do some very significant tag-juggling.
# 03[01:27] * Joins: plinss_ (plinss@72.254.91.11)
# [01:27] <TabAtkins_> fantasai: Another is having an icon in a span of underlined text that you don't want underlined.
# [01:27] <TabAtkins_> fantasai: But those use-cases have been listed previously and decided on.
# [01:27] <TabAtkins_> szilles: That doesn't answer the question at hand.
# [01:28] <TabAtkins_> TabAtkins_: suggestion - "none | [underline | cancel-underline | override-underline] | [overline | cancel-overline | override-overline] | [<line-through stuff too>]"
# 06[01:28] * glazou notes than even if we have cancel-underline, Tab's case above will still require the creation of at least a span
# 02[01:29] * Quits: szilles (chatzilla@72.254.89.133) (Ping timeout)
# [01:29] <TabAtkins_> szilles: I think that it's going to be confusing for authors that you say "underline cancel-underline" to make the underline reset.
# [01:29] <TabAtkins_> dbaron: I dont' know if that's enough of a use-case to justify three more values.
# [01:30] <TabAtkins_> szilles: Does SVG have underlined text?
# [01:30] <TabAtkins_> shepazu: We don't natively, but we'd like to follow CSS here.
# [01:31] <TabAtkins_> dbaron: SVG1.1 is just the CSS2.1 text-decoration values.
# [01:34] <dbaron> underline
# [01:34] <dbaron> no-underline cancel-underline
# [01:34] <dbaron> reset-underline new-underline replace-underline reset-underline
# [01:34] <shepazu> s/We don't natively/SVG 1.1 only uses CSS @text-decoration
# [01:36] <dbaron> Tab proposes don\'t-underline
# [01:36] <dbaron> s/Tab/Florian/
# [01:40] <fantasai> ACTION fantasai: Poll for best options on naming
# 06[01:40] * trackbot noticed an ACTION. Trying to create it.
# [01:40] <trackbot> Created ACTION-346 - Poll for best options on naming [on Elika Etemad - due 2011-07-31].
# [01:40] <TabAtkins_> RESOLVED: text-decoration uses the "none | [underline | no-underline | reset-underline] ...", exact name of the new keywords TBD.
# 03[01:41] * Joins: szilles (chatzilla@72.254.89.133)
# [01:42] <fantasai> http://dev.w3.org/csswg/css3-text/#text-decoration-skip
# [01:42] <TabAtkins_> dbaron: I think text-decoration-skip:none would be quite a bit of work to implement.
# [01:43] <TabAtkins_> fantasai: it's necessary, though.
# [01:44] <fantasai> http://dev.w3.org/csswg/css3-text/#word-wrap
# 02[01:44] * Quits: szilles (chatzilla@72.254.89.133) (Ping timeout)
# 03[01:45] * Joins: szilles (chatzilla@72.254.89.133)
# [01:45] <TabAtkins_> fantasai: It was suggested that word-wrap be an alias for "overflow-wrap" (which is a better name). If we do that, how is it done?
# [01:46] <TabAtkins_> TabAtkins_: This is the same issue with object-fit and image-fit, right?
# [01:46] <TabAtkins_> fantasai: Theoretically yes, but the impls that did image-fit were printers that didn't have JS, so you couldn't introspect and it wasn't very widespread anyway. It didn't matter how they accomplished the aliasing.
# [01:47] <TabAtkins_> fantasai: Also, Alex brought up that "word-wrap" has existed for a long time and there's a lot of documentation for it. if we change that, will that hurt authors?
# [01:48] <TabAtkins_> szilles: Any way we can find out how many docs use word-wrap?
# [01:48] <TabAtkins_> ???: A lot of Word exports.
# [01:48] <TabAtkins_> fantasai: A lot of them are using it to work around the lack of pre-wrap.
# [01:48] <TabAtkins_> fantasai: If you cross out those cases, likely very few.
# [01:50] <fantasai> plinss: every time I've seen someone look at this, they've been confused and think it should be controlling text-wrapping. So I think it's worth fixing.
# [01:50] <fantasai> discussion about what aliasing means
# [01:50] <TabAtkins_> florian: We have to be very specific about whta aliasing means. If you query for one of the names, does it grab the value when specified with the other name?
# 02[01:51] * Quits: szilles (chatzilla@72.254.89.133) (Ping timeout)
# [01:51] <TabAtkins_> plinss_: We'd just define it as "overflow-wrap" and say "browsers may, for legacy reasons, accept 'word-wrap' with the same meaning".
# [01:51] <TabAtkins_> dbaron: For this sort of property, I'm not too interested about the effect on JS.
# 03[01:52] * Joins: szilles (chatzilla@72.254.89.133)
# [01:53] <TabAtkins_> RESOLUTION: Rename word-wrap to overflow-wrap, add a note that browsers may accept word-wrap.
# [01:53] <TabAtkins_> florian: We talked last time about line-break.
# [01:53] <TabAtkins_> florian: The definitions of the values aren't specific enough to be helpful and interoperable.
# [01:54] <TabAtkins_> florian: It was stated that we can't change it because IE has had it forever.
# [01:54] <TabAtkins_> florian: But if only IE does it, and nobody really knows what they do anyway, it seems like not a problem.
# [01:55] <TabAtkins_> florian: [describes a survey of websites they did]
# [01:55] <TabAtkins_> florian: I'd prefer having "auto", along with a list of things forbidden from starting a line, a list of things forbidden from ending a line, and things that must stay together.
# 02[01:56] * Quits: szilles (chatzilla@72.254.89.133) (Ping timeout)
# [01:56] <TabAtkins_> fantasai: We resolved at the last f2f to mark "loose" as at-risk. I don't want to make authors choose only between "auto" and listing codepoints.
# [01:57] <TabAtkins_> florian: I think this only works within a walled garden, where you can guarantee a UA and learn what it means for that. But on the wider web, you wouldn't be able to depend on any of this.
# [01:57] <TabAtkins_> fantasai: You don't have that level of control currently in English either.
# [01:58] <TabAtkins_> szilles: Stated differently, in English we allow the UA to do river detection. To forbid river detection seems like locking us into bad typography, which sounds like something we don't want to do.
# [01:59] <TabAtkins_> florian: The only people that want this are the japanese publishing houses, and they want precise control. If we don't give precise control, then we're not serving anyone usefully.
# [02:00] <TabAtkins_> szilles: There's nothing stopping us from making this more complex and specific in the future.
# [02:00] <TabAtkins_> fantasai: I don't see this as a split between "I'm a publishing house that wants obsessive control" and "I'm an author and don't care".
# [02:00] <TabAtkins_> fantasai: Publishing software provides switches like this.
# [02:01] <TabAtkins_> alan: The modes there are just a particular publishing house's rules.
# [02:01] <bradk> Is it testable the way it is now?
# 06[02:01] * TabAtkins_ Brad: no
# [02:02] <bradk> Well then... it really does need to be more exact, doesn't it?
# [02:03] <TabAtkins_> alan: I don't think it's really about line-break control; the important thing is just ensuring that particular characters don't ever end a line.
# [02:03] <TabAtkins_> florian: If a publishing house cares enough about linebreaking (all their books looks a particular way), they might very well block a browser that doesn't act the way they want.
# [02:04] <TabAtkins_> florian: They'll either give up control, or just block everyone who doesn't give them the right level of control.
# [02:05] <TabAtkins_> szilles: The question here is, are we eliminating moving to that capability in the future? If we're not blocking that, it's not too bad of a problem; we can fix it later.
# 03[02:06] * Joins: szilles (chatzilla@72.254.89.133)
# [02:06] <TabAtkins_> alan: If we later make it more precise, will the existing values become obsolete?
# [02:07] <TabAtkins_> szilles: I think there's a significant group of authors who care enough about this to set the property, but not enough to dive into codepoints.
# [02:07] <TabAtkins_> szilles: This seems appropriate for "newsletter"-level support, though it's not yet good enough for precise publishing-house-level control.
# [02:09] <TabAtkins_> fantasai: We can do something like @counter-style in the future for defining more complex things.
# [02:09] <TabAtkins_> szilles: I'd like a note to say something about how additional controls may be introduced in the future to handle more precise controls.
# 02[02:09] * Quits: szilles (chatzilla@72.254.89.133) (Ping timeout)
# [02:09] <TabAtkins_> florian: Does anyone know how this would work in other languages that don't break on spaces but aren't CJK?
# [02:10] <TabAtkins_> szilles: Thai is the classic example, and there you need a dictionary to do breaking.
# 03[02:10] * Joins: szilles (chatzilla@72.254.89.133)
# [02:11] <TabAtkins_> kojiishi: In Thai, there are some places you can define as being generally very bad to linebreak on, without having to resort to a dictionary. Not perfect, but better than nothing.
# [02:12] <TabAtkins_> fantasai: The handling of codepoints was minuted in Kyoto.
# [02:13] <TabAtkins_> florian: While I don't like the current stuff, I'm okay as long as there's the possibility of additional control in the future.
# [02:13] <fantasai> ... my comment was about florian's comment about the affect outside CJK of line-break
# [02:13] <fantasai> not about codepoints
# 06[02:13] * fantasai will fix the minutes later
# [02:14] <TabAtkins_> RESOLVED: No change to current line-break property, add note about future extensions for more precise control.
# [02:14] <fantasai> ScribeNick: fantasai
# [02:15] <fantasai> TabAtkins: We have some rules for how we should serialize things in the CSSOM module
# [02:15] <fantasai> TabAtkins: I have some rules in CSS3 Images
# [02:15] <fantasai> TabAtkins: These are different in their strategy
# [02:15] <shepazu> (the term for languages that don't use spaces as word separators is "scriptio continua", and was used in Latin and Greek in the Dark Ages)
# [02:15] <fantasai> TabAtkins: CSSOM omits everything it can
# [02:15] <fantasai> TabAtkins: Mine is very verbose
# [02:15] <fantasai> TabAtkins: Would like to figure out how we want to serialize things
# [02:15] <fantasai> TabAtkins: And maybe put this all in one place
# [02:15] <fantasai> TabAtkins: Almost all the serialization things I have in css3-images depend on serializing more basic types, which aren't defined
# [02:16] <fantasai> Anne: CSSOM has a section on comment serializing idioms
# [02:16] <fantasai> Anne: Serializing characte,r identifier, string, etc.
# [02:16] <fantasai> Anne: Then there are things less well-defined
# [02:16] <fantasai> s/comment/common/
# [02:16] <fantasai> Anne: What I followed there was an old proposal by hixie on how to canonicalize CSS property values, and in that proposal he suggested omitting things
# [02:17] <fantasai> Anne: and I sortof think that makes sense
# [02:17] <fantasai> dbaron: Two general principles I think about for generalization ...
# [02:17] <dbaron> s/gneeralization/serialization/
# [02:17] <fantasai> sylvaing: One thing that's controversial was following the property definitions in terms of property order
# [02:17] <fantasai> sylvaing: I remember dbaron was uncomfortable with that
# [02:18] <fantasai> Anne: I think the properties should define that for themselves
# [02:18] <fantasai> fantasai: You were supposed to give us a template for that
# [02:18] <fantasai> dbaron: The two principles I think of
# [02:18] <fantasai> dbaron: One is, if something that can be serialized in a form that is more backwards-compatible, always prefer the older form
# [02:18] <fantasai> dbaron: This is why I serialize transparent as 'transparent' instead of 'rgba(0,0,0,0)'
# [02:19] <fantasai> dbaron: The other one is that DOM Level 2 Style does explicitly style that there should be a preference for shortest form
# [02:19] <fantasai> dbaron: Although that's specifically for serializing shorthands
# [02:19] <fantasai> dbaron: I think if we want to pick one way or the other, we might want to pick that.
# [02:19] <fantasai> dbaron: Although there's some ways where it's dangerous, e.g. animations/transitions
# [02:20] <fantasai> TabAtkins: There's 2-3 times you have to be careful about ordering there, yeah
# [02:20] <fantasai> Anne: Do all these drafts, if they want to define serialization, will they all depend on CSSOM?
# [02:20] <fantasai> Anne: How do we move forward?
# [02:20] <fantasai> Anne: I think we only want to define serializing URL once, frex
# [02:20] <fantasai> sylvaing: ... sometimes longer form is easier
# [02:21] <fantasai> ...
# [02:21] <fantasai> dbaron: I think biggest issue with serialization is question of what information is retained and what information is lost
# [02:21] <fantasai> dbaron: We have 2 different serialization.
# [02:21] <fantasai> dbaron: specified values vs. computed values
# [02:21] <fantasai> dbaron: the information lost in those two is substantially different
# [02:22] <fantasai> dbaron: For specified values, I try to mostly minimize information loss
# [02:22] <fantasai> dbaron: Some things are lost, e.g. whether double or single quotes were used
# [02:22] <fantasai> glazou: Color format?
# [02:22] <fantasai> dbaron: We may lose rgb vs hex
# [02:22] <fantasai> dbaron: but we do give back keywords
# [02:23] <fantasai> glazou brings up Web-based editors
# [02:23] <fantasai> dbaron: Another dangerous thing about loss of information issues..
# [02:23] <fantasai> dbaron: Some of these are deeply hardcoded into implementations
# [02:24] <fantasai> dbaron: Might be difficult to align implementations on this.
# [02:24] <fantasai> glazou: Some of the losses are due to performance hits.
# [02:25] <fantasai> fantasai: There was a proposal to have an API that returns the value as the string parsed in
# [02:26] <fantasai> glazou: But that's a lot of memory. For an editor, it's perfect, but for a browser it's a lot of performance problems.
# [02:26] <fantasai> dbaron: Wha did you want out of this discussion?
# [02:26] <fantasai> TabAtkins: In magical perfect world, somebody would say "here's how we shoudl serialize things", and then I can go work on that.
# [02:26] <fantasai> glazou: Timing function for transitions? What should I do? Output bezier or output keywords?
# [02:27] <fantasai> glazou: Perhaps first if you can output as a keyword, output the keyword
# [02:27] <fantasai> TabAtkins: If I want to write good serialization rules, how should I do it?
# [02:27] <fantasai> dbaron: Essentially you're specifying what information is lost and what isn't
# [02:28] <fantasai> dbaron: And when it is lost, which way do you choose to fill it back in.
# [02:28] <fantasai> dbaron: Going back.. Principle 0 of serialization -- may browsers get this wrong--
# [02:28] <fantasai> dbaron: The thing your serializer outputs should be valid input.
# [02:29] <fantasai> sylvaing: roundtripping
# [02:29] <fantasai> dbaron: Before I started writing tests for this in Gecko, there were many places where this was not true and nobody noticed.
# [02:29] <dbaron> the thing that's easily testable is that the function (parse + serialize) is idempotent
# [02:30] <fantasai> glazou talks about -webkit-gradient, Tab asserts this is out-of-scope
# [02:31] <fantasai> Tantek clarifies principle 0: The point wasn't that you roundtrip from the original. The point was that what you output, that should roundtrip exactly.
# [02:32] <fantasai> dbaron: If you parse and serialize and reparse, you should get the same results that you got the first time.
# [02:32] <fantasai> dbaron: An easy way to test that is to serialize again and check that against the first serialization.
# [02:32] <fantasai> Tantek: We're going to keep adding features to CSS.
# [02:32] <fantasai> Tantek: The serialization today will always be a subset of the serialization tomorrow. And that's okay.
# [02:33] <fantasai> glazou: One serialization to discuss -- the 'border' shorthand.
# [02:33] <fantasai> glazou: In some cases we can serialize (lists shorthand combos)
# [02:33] <fantasai> glazou: How should we do that?
# [02:33] <fantasai> glazou: Do we try to minimize number of properties we declare?
# [02:34] <fantasai> dbaron: There's question of how to serialize a particular property,
# [02:34] <fantasai> dbaron: And how to serialize a declaration block.
# [02:34] <fantasai> dbaron: That's the second quesiton
# 02[02:34] * Quits: szilles (chatzilla@72.254.89.133) (Ping timeout)
# [02:34] <fantasai> glazou: If the strategy is to minimize number of declarations, you can wind up with same number in different forms.
# [02:35] <fantasai> dbaron: I think we try shorthands in alphabetical order, and pick the first one that works.
# [02:35] <fantasai> TabAtkins: Sounds like I should make serialization rules informative in css3-images
# [02:36] <fantasai> [various side-conversations on serialization]
# [02:37] <fantasai> ACTION glazou: Write collection of serialization heuristics
# 06[02:37] * trackbot noticed an ACTION. Trying to create it.
# [02:37] <trackbot> Created ACTION-347 - Write collection of serialization heuristics [on Daniel Glazman - due 2011-08-01].
# [02:37] <fantasai> Topic: CSS3 Conditional Rules FPWD
# [02:38] <fantasai> dbaron: There's one issue left I want to solve before FPWD, but never get to, so maybe publish first.
# [02:38] <fantasai> dbaron: The issue isn't sometihng we'll find a lot of expertise on in this room.
# [02:38] <fantasai> dbaron briefly summarizes what's in css3-conditional
# [02:39] <fantasai> dbaron: The remaining issue is what normalization happens to URLs before comparison occurs
# [02:39] <fantasai> dbaron: I know some people who work on the URL spec, and therefore are likely to be able to offer concrete advice.
# [02:39] <fantasai> Anne: What do you mean by normalization?
# [02:40] <fantasai> dbaron: Defining what is the URL of the page, i.e. "this url", and how you do the comparison.
# [02:40] <fantasai> dbaron: I need to dig through the URL spec and figure this out
# [02:40] <fantasai> fantasai: I think we should mark this as an issue and publish.
# [02:41] <fantasai> dbaron: Need to know which RFC to point to, and which variation on matching rules
# [02:41] <fantasai> Anne gives some examples of what the variation sare
# [02:41] <fantasai> plinss: You could fetch the URL and see if you get redirected to something else. :)
# [02:42] <fantasai> RESOLVED: Mark this as an issue, publish FPWD of css3-conditional.
# [02:42] <fantasai> Topic: View Mode Media Feature, Media Queries, MQ test suite
# [02:42] <fantasai> Arron: John's topic
# [02:43] <fantasai> sylvaing: View Mode is in PR, and it depends on Media Queries
# [02:43] <fantasai> Anne: The only reason MQ hasn't advanced is because nobody has passed the test cases
# [02:43] <fantasai> s/nobody has passed/we don't have passes for/
# [02:43] <fantasai> ...
# 03[02:43] * Joins: szilles (chatzilla@72.254.89.133)
# [02:43] <fantasai> dbaron: Presumably they had a test suite that didn't check the parsing rules.
# [02:44] <fantasai> dbaron: Our issue blocking MQ is getting implementations to pass the tests we have
# [02:44] <fantasai> Arron: There are also bugs in the test suite. I have a list.
# [02:44] <fantasai> ACTION Arron: Send MQ test suite bugs to mailing list
# 06[02:44] * trackbot noticed an ACTION. Trying to create it.
# [02:44] <trackbot> Created ACTION-348 - Send MQ test suite bugs to mailing list [on Arron Eicholz - due 2011-08-01].
# 03[02:44] * Joins: dino (dino@72.254.63.182)
# [02:45] <fantasai> dbaron: We have one passing implementation, because I implemented and wrote the tests and passed the tests.
# [02:45] <fantasai> Anne: We added some tests from Acid3
# [02:45] <fantasai> Anne: I cross-checked with tests I already wrote.
# [02:46] <fantasai> Anne: I guess we have to wait for bug reports on MQ test suite
# [02:46] <fantasai> Arron: One case is handling of number and dpi values
# [02:46] <fantasai> Arron: dpi is supposed to be an integer, however is defined as <number>dpi, which means you can have a decimal point in dpi
# [02:46] <fantasai> Arron: Other cases here I'll list
# [02:47] <fantasai> Topic: Testing
# [02:47] <fantasai> Arron: is 92.6dpi still valid?
# [02:47] <fantasai> dbaron: yes
# [02:47] <fantasai> dbaron: You're right that there's a bug in FF on this.
# [02:48] <fantasai> dbaron: I think may have changed on this...
# [02:48] <fantasai> glazou: Back to question I asked last F2F.
# [02:48] <fantasai> glazou: I think we should spend more time on testing Transitions and Animations.
# [02:49] <anne> dbaron, I think in 2007 it was not defined
# [02:49] <anne> dbaron, whether it should be <number> or not
# [02:49] <fantasai> glazou: Web authors are relying on this a lot
# [02:49] <fantasai> sylvaing: Every time we define a new property, we need to figure out how it animates
# [02:49] <fantasai> glazou: We'd have to test every property?
# 02[02:49] * Quits: Martijnc (Martijnc@84.192.44.100) (Quit: Martijnc)
# [02:50] <fantasai> dbaron: Testing every transitionable property is easy, set a 4s transition with -1s delay
# [02:50] <fantasai> dbaron: That doesn't test the timing function, but it tests the interpolation code
# [02:50] <fantasai> dbaron: Testing the timing function is harder
# [02:51] <fantasai> Dean: I think the way to make progress is to make progress on the query animation api
# [02:51] <fantasai> Dean explains the api.
# [02:51] <fantasai> Dean: That'll make it easier to run tests.
# 02[02:51] * Quits: tantek (tantek@72.254.89.121) (Quit: tantek)
# [02:51] <fantasai> dbaron: The way I wrote our tests was to add an api that artificially advances the clock.
# [02:52] <fantasai> dbaron: Just one api
# [02:52] <fantasai> Dean: ..
# [02:52] <fantasai> dbaron: Exposing stuff isn't sufficient, because you need to be able to cause a particular change at a particular time, and test the effects of that.
# [02:52] <fantasai> dbaron: You need to test things like, what happens if I cause a property change halfway through this transition.
# [02:53] <fantasai> dbaron: With an API that just advances the clock, you can test things like that.
# [02:53] <fantasai> dbaron: Maybe I don't understand the API you're propsing
# [02:53] <fantasai> Dean: well, it doesn't exist
# 03[02:53] * Joins: tantek (tantek@72.254.89.121)
# 03[02:53] * Parts: mollydotcom (mollyh@72.254.82.56)
# [02:53] <fantasai> Dean describes how horrible WebKit's api is
# 06[02:54] * tantek suggests that we close the agenda for today with the current issue.
# [02:54] <fantasai> dbaron: Our timing code is relatively centralized, so we have some code that says "ignore the clock, just listen to the updates from me" and then "advance 1s, advance 2 s, advance 20s"
# [02:54] <fantasai> Dean describes going back in time.
# 02[02:54] * Quits: homata_ (homata_@58.158.182.50) (Client exited)
# [02:54] <fantasai> and running animations backwards
# 03[02:54] * Joins: homata_ (homata_@58.158.182.50)
# [02:55] <fantasai> Arno: When you're building an animation with a tool like our HTML5 animation authoring tool, you want to navigate a timeline
# [02:55] <fantasai> Arno: E.g. pretend the time is X, and show that
# [02:55] <fantasai> Dean: I've found it's easier to write tests that way than any purely content-based ones
# 02[02:55] * Quits: tantek (tantek@72.254.89.121) (Quit: tantek)
# [02:55] <fantasai> Dean: If we define an API and all implement it, then we can all run tests.
# [02:56] <fantasai> dbaron: An API like that doesn't work going backwards.
# [02:56] <fantasai> dbaron: Once an animation is done, it's done, and no longer animating. You can't go backwards
# [02:56] <fantasai> dbaron: For the record, I wrote our transitions tests without this API
# [02:57] <fantasai> dbaron: It's a combination test that runs over an 8s period. It uses setTimeout to get its time samples
# [02:57] <ed> http://www.w3.org/Graphics/SVG/WG/wiki/Testing_Framework#Method_2_-_spot-testing_with_pre-defined_document-times is the proposed method of testing declarative animations in SVG
# [02:57] <fantasai> dbaron: ...
# [02:57] <fantasai> Dean: ...
# [02:58] <fantasai> dbaron: When you're running the tests 100s of times a day, and you need to get the failure rate down to <1 once every 6 months ...
# [02:58] <fantasai> Vincent:... You can set timeline and pause it
# [02:58] <fantasai> glazou: We will need more things like that, e.g. when you resize Regions.
# [02:59] <fantasai> Arno: But that's not time-based.
# [02:59] <fantasai> glazou: We also have another time-based spec, CSS3 Speech
# 03[02:59] * Joins: vhardy (vhardy@72.254.56.182)
# [03:00] <fantasai> fantasai: You can do a lot of reftests with that one.
# [03:00] <fantasai> fantasai gives an example
# [03:01] <fantasai> Vincent: Did we agree on anything for testing animation?
# [03:01] <fantasai> glazou: I think we need some kind of debug API
# [03:01] <fantasai> dbaron: I think we need proposals.
# [03:01] <fantasai> Vincent: Ok, let's discuss this at hte fxtf
# [03:01] <fantasai> glazou: We have a lot of specs on the radar, and a lot will reach CR in the next 6 months
# [03:01] <fantasai> glazou: We need a lot of help on specs
# [03:01] <fantasai> sylvaing: It was suggested that each spec have a testing owner.
# [03:02] <fantasai> dbaron: The more effective step we discussed is that if you want to ship it unprefixed you have to contribute a test suite.
# [03:02] <fantasai> Steve: Separate question of when is the right time to start developing a test suite.
# [03:03] <fantasai> Steve: In some sense CR is too late, and is another sense it's when it's finally stable enough.
# [03:03] <fantasai> glazou: You should write a test as you write the spec.
# [03:03] <fantasai> dbaron: Tests are hard to maintain.
# [03:03] <fantasai> Florian: It's more overwhelming if you don't start early
# [03:04] <fantasai> dbaron: It's harder to keep the tests in sync with spec change is to test in in an implementation that supports the feature.
# [03:04] <shepazu> ]\
# [03:04] <fantasai> glazou: ...
# [03:04] <fantasai> dbaron: A problem with that is that the tester might miss something in the spec, and write the test.
# [03:05] <glazou> s/.../shrug
# 02[03:05] * Quits: szilles (chatzilla@72.254.89.133) (Ping timeout)
# [03:05] <fantasai> dbaron: And then an implementer ignores the spec in order to pass the test
# [03:05] <fantasai> dbaron: We should be careful about advertising the quality of the test suite
# [03:06] <fantasai> shepazu: SVG's tests advertise their stability level
# [03:07] <fantasai> Arron: One thing we really need is better tracking.
# [03:07] <fantasai> plinss: I'm actively developing a tracker for that. It will be online, hopefully, in a few weeks.
# [03:08] <fantasai> plinss: This is a new system, it's tightly coupled to the Mercurial repo, and tied itno test suite build system.
# [03:08] <fantasai> plinss: I'm actively working on that. It's what I'm doing now.
# 02[03:09] * Quits: paul_irish (paul_irish@76.14.88.222) (Client exited)
# 02[03:09] * Quits: nimbupani (Adium@72.254.57.153) (Quit: Leaving.)
# 02[03:09] * Quits: vhardy (vhardy@72.254.56.182) (Quit: vhardy)
# [03:09] <fantasai> Meeting closed.
# [03:09] <bradk> bye!
# 02[03:09] * Quits: bradk (bradk@99.7.175.117) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
# 02[03:10] * Quits: kimberlyblessing (Kimberly@72.254.58.198) (Quit: ChatZilla 0.9.87 [Firefox 6.0/20110713171652])
# [03:10] <fantasai> bye! thanks for joining :)
# 02[03:10] * Quits: plinss_ (plinss@72.254.91.11) (Quit: plinss_)
# 02[03:10] * Quits: dino (dino@72.254.63.182) (Quit: dino)
# 02[03:11] * Quits: stearns (qw3birc@128.30.52.28) (Quit: Page closed)
# 02[03:11] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
# 02[03:11] * Quits: arno (arno@72.254.90.86) (Quit: Leaving.)
# 02[03:11] * Quits: glazou (glazou@72.254.58.58) (Quit: glazou)
# 02[03:11] * Quits: dbaron (dbaron@72.254.82.231) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# 02[03:12] * Quits: arronei (arronei@72.254.95.172) (Ping timeout)
# 02[03:12] * Quits: anne (annevk@72.254.92.35) (Quit: anne)
# 02[03:12] * Quits: florian (florianr@72.254.58.176) (Ping timeout)
# 02[03:12] * Quits: sylvaing (sylvaing@72.254.95.170) (Ping timeout)
# 03[03:13] * Joins: szilles (chatzilla@72.254.89.133)
# 02[03:13] * Quits: kojiishi (kojiishi@72.254.62.119) (Quit: Leaving...)
# 02[03:13] * Quits: TabAtkins_ (tabatkins@72.254.60.218) (Ping timeout)
# 02[03:14] * Quits: shans (qw3birc@128.30.52.28) (Ping timeout)
# 02[03:18] * Quits: szilles (chatzilla@72.254.89.133) (Ping timeout)
# 02[03:30] * Quits: alexmog_ (alexmog@72.254.57.72) (Ping timeout)
# 03[03:49] * Joins: dino (dino@24.22.134.28)
# 02[04:03] * Quits: dino (dino@24.22.134.28) (Quit: dino)
# 03[04:34] * Joins: paul_irish (paul_irish@32.154.138.185)
# 02[04:41] * Quits: paul_irish (paul_irish@32.154.138.185) (Client exited)
# 02[05:06] * Quits: homata_ (homata_@58.158.182.50) (Client exited)
# 02[05:50] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
# 03[05:50] * Joins: karl (karlcow@128.30.54.58)
# 03[06:17] * Joins: homata (homata@58.158.182.50)
# 02[07:04] * Quits: homata (homata@58.158.182.50) (Quit: Leaving...)
# 03[08:18] * Joins: dino (dino@24.22.134.28)
# 03[08:22] * Joins: plinss_ (plinss@72.254.85.16)
# 03[08:28] * Joins: glazou (glazou@173.160.172.65)
# 02[08:28] * Quits: glazou (glazou@173.160.172.65) (Quit: glazou)
# 03[08:30] * Joins: dino_ (dino@24.22.134.135)
# 03[08:31] * Joins: dino__ (dino@24.22.134.28)
# 02[08:33] * Quits: dino (dino@24.22.134.28) (Ping timeout)
# 03[08:33] * dino__ is now known as dino
# 02[08:33] * Quits: dino_ (dino@24.22.134.135) (Ping timeout)
# 02[08:37] * Quits: konaya (konaya@83.251.16.72) (Ping timeout)
# 02[08:47] * Quits: dino (dino@24.22.134.28) (Quit: dino)
# 03[08:48] * Joins: tantek (tantek@66.87.7.52)
# 02[10:37] * Quits: tantek (tantek@66.87.7.52) (Quit: tantek)
# Session Close: Mon Jul 25 10:46:39 2011
#
# Session Start: Mon Jul 25 10:46:39 2011
# Session Ident: #css
# 02[10:46] * Disconnected
# Session Close: Mon Jul 25 10:46:41 2011
#
# Session Start: Mon Jul 25 15:36:20 2011
# Session Ident: #css
# 03[15:36] * Now talking in #css
# 03[15:36] * Topic is 'logged at http://krijnhoetmer.nl/irc-logs/'
# 03[15:36] * Set by fantasai on Wed Jun 01 09:38:26
# 03[15:38] * Joins: nimbupani (Adium@24.18.47.160)
# 03[16:16] * Joins: szilles (chatzilla@72.254.90.47)
# 02[16:24] * Quits: szilles (chatzilla@72.254.90.47) (Ping timeout)
# 03[16:25] * Joins: szilles (chatzilla@72.254.90.47)
# 02[16:28] * Quits: szilles (chatzilla@72.254.90.47) (Ping timeout)
# 03[16:29] * Joins: szilles (chatzilla@72.254.90.47)
# 02[16:37] * Quits: szilles (chatzilla@72.254.90.47) (Ping timeout)
# 03[16:39] * Joins: szilles (chatzilla@72.254.90.47)
# 02[16:44] * Quits: szilles (chatzilla@72.254.90.47) (Ping timeout)
# 03[16:46] * Joins: szilles (chatzilla@72.254.90.47)
# 03[16:50] * Joins: arronei (arronei@72.254.94.7)
# 02[16:51] * Quits: szilles (chatzilla@72.254.90.47) (Ping timeout)
# 03[16:59] * Joins: anne (annevk@72.254.94.246)
# 03[17:02] * Joins: szilles (chatzilla@72.254.90.47)
# 02[17:05] * Quits: nimbupani (Adium@24.18.47.160) (Quit: Leaving.)
# 02[17:05] * Quits: szilles (chatzilla@72.254.90.47) (Ping timeout)
# 03[17:10] * Joins: szilles (chatzilla@72.254.90.47)
# 02[17:10] * Quits: arronei (arronei@72.254.94.7) (Ping timeout)
# 03[17:13] * Joins: plinss_ (plinss@72.254.58.149)
# 02[17:16] * Quits: szilles (chatzilla@72.254.90.47) (Ping timeout)
# 03[17:19] * Joins: szilles (chatzilla@72.254.90.47)
# 03[17:20] * Joins: shepazu (schepers@128.30.52.169)
# 02[17:20] * Quits: plinss_ (plinss@72.254.58.149) (Quit: plinss_)
# 02[17:22] * Quits: szilles (chatzilla@72.254.90.47) (Ping timeout)
# 03[17:24] * Joins: szilles (chatzilla@72.254.90.47)
# 03[17:26] * Joins: arronei (arronei@72.254.94.7)
# 03[17:31] * Joins: kimberlyblessing (Kimberly@72.254.83.239)
# 02[17:32] * Quits: szilles (chatzilla@72.254.90.47) (Ping timeout)
# 03[17:33] * Joins: sylvaing (sylvaing@72.254.84.129)
# 03[17:39] * Joins: szilles (chatzilla@72.254.90.47)
# 02[17:42] * Quits: anne (annevk@72.254.94.246) (Quit: anne)
# 02[17:45] * Quits: szilles (chatzilla@72.254.90.47) (Ping timeout)
# 03[17:51] * Joins: szilles (chatzilla@72.254.90.47)
# 02[17:54] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
# 03[17:55] * Joins: nimbupani (Adium@72.254.87.49)
# 02[17:59] * Quits: szilles (chatzilla@72.254.90.47) (Ping timeout)
# 03[17:59] * Joins: dbaron (dbaron@72.254.87.122)
# 02[17:59] * Quits: kimberlyblessing (Kimberly@72.254.83.239) (Connection reset by peer)
# 03[18:03] * Joins: szilles (chatzilla@72.254.61.95)
# 03[18:03] * Joins: plinss_ (plinss@72.254.58.149)
# 03[18:05] * Joins: glazou (glazou@72.254.87.99)
# 03[18:07] * Joins: bradk (bradk@99.7.175.117)
# [18:08] <bradk> anyone there yet?
# 06[18:08] * plinss_ we're just about ready to start
# 03[18:09] * Joins: mollydotcom (mollyh@72.254.57.69)
# 06[18:09] * plinss_ baron is setting up skype
# [18:09] <plinss_> s/baron/dbaron/
# 03[18:09] * Joins: stearns (qw3birc@128.30.52.28)
# 03[18:09] * Joins: anne (annevk@72.254.94.246)
# 03[18:09] * Joins: TabAtkins_ (tabatkins@72.254.88.61)
# 03[18:10] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
# [18:10] <RRSAgent> logging to http://www.w3.org/2011/07/25-css-irc
# 03[18:10] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [18:11] <plinss_> rrsagent, make logs public
# [18:11] <RRSAgent> I have made the request, plinss_
# [18:11] <bradk> Is it david.baron on skype then?
# 03[18:11] * Joins: dino (dino@72.254.88.79)
# 03[18:11] * Joins: smfr (smfr@72.254.88.19)
# [18:11] <nimbupani> ScribeNick: nimbu
# [18:12] <dbaron> bradk, having trouble getting the thing to work
# 03[18:12] * Joins: florian (florianr@72.254.81.111)
# [18:12] <nimbupani> Topic: CSSOM
# [18:13] <bradk> dbaron, OK, will wait for further instructions.
# [18:13] <nimbupani> glazou: report whats going on with CSSOM, what are the stuff we need to add, change.
# 03[18:13] * Joins: shans (qw3birc@128.30.52.28)
# [18:13] <nimbupani> glazou: anne, tell us where you are right now, what you need to add, change, etc
# [18:14] <dbaron> bradk, see /query
# 03[18:14] * Joins: kimberlyblessing (Kimberly@72.254.83.239)
# [18:14] <nimbupani> anne: the OM covers how to serialize mediaq, selectors, stylesheets in general
# [18:14] <sylvaing> http://dev.w3.org/csswg/cssom/
# [18:14] <nimbupani> anne: it has alt stylesheet api so people can control stylesheet sets from scripts.
# 03[18:14] * Joins: JohnJansen (qw3birc@128.30.52.28)
# [18:15] <nimbupani> anne: it def processing requirements for the link header so you can associate stylesheets with documents via http
# [18:15] <nimbupani> anne: it then defines the "real" OM all the stylesheet rules and their apis
# [18:15] <nimbupani> anne: e.g. @import, @media, font-face, etc
# [18:15] <nimbupani> anne: there is a new thing called the values api, so far OM has been string based.
# [18:15] <dbaron> does somebody with a Mac want to try running skype on their machine for brad?
# [18:16] <nimbupani> anne: in 2003 we obsoleted parts of DOM level2 style that were object based but never wrote a replacement, section 6.6 in CSSOM draft sketches out how Object based API would look
# [18:16] <nimbupani> anne: lacking: implementors need to look at it to poke holes in idea before we formally define it.
# [18:16] <nimbupani> anne: this was the case a year ago, so people have not gotten around to looking at it yet
# [18:16] <arronei> http://dev.w3.org/csswg/cssom/
# 03[18:16] * nimbupani is now known as nimbu
# [18:17] <nimbu> anne: there is a priority of list of features, e.g. to get to results styles of elements.
# [18:17] <smfr> s/results/resolved
# 02[18:17] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
# 03[18:18] * Joins: konaya (konaya@83.251.16.72)
# [18:18] <nimbu> anne: I would like to not add too much features before current features are interoperably implemented.
# [18:18] <nimbu> anne: we need to find out a plan on how to, since css is fairly modularized, how we do the same for the OM
# [18:18] <nimbu> anne: if we get interfaces for components like callers, it would be best if they are defined in their respective drafts.
# [18:18] <nimbu> anne: it would mean those drafts would ahve some dependency on the OM
# [18:19] <nimbu> fantasai: could we split out the serialization into its own module
# [18:19] <nimbu> smfr: for css transforms we need to expose an api for matrix transformations.
# [18:19] <stearns> s/callers/colors
# [18:19] <nimbu> anne: the color module needs to expose an api.
# [18:20] <nimbu> anne: its not just serialisation but the whole…
# [18:20] <hober> good morning
# [18:20] <nimbu> anne: each draft that defines a "bracketed new thing", needs to define an interface to it as well.
# [18:20] <nimbu> fantasai: two ways to do that
# [18:20] <nimbu> fantasai: have it paired with the module to define OM stuff
# 03[18:20] * Joins: vhardy (vhardy@72.254.57.220)
# [18:20] <nimbu> fantasai: for drafts that are advanced publish a .1 which includes OM stuff
# [18:21] <nimbu> fantasai: e.g. css color 3.1 or css color object model.
# [18:21] <nimbu> fantasai: in some cases the editor of the module can do the OM stuff but in other cases the editor might not have the expertise, so we need two editors or more.
# [18:22] <nimbu> florian: if we have 3 3.1 and 4 some people can get confused
# [18:22] <nimbu> anne: maybe we have it into 4.
# [18:22] <nimbu> anne: i think its best if its in same module as def and such will be tightly coupled
# [18:22] <nimbu> fantasai: going forward we can do that, but for some specs we cant do that
# [18:22] <nimbu> anne: maybe put them into 4 for current specs that you cant change.
# [18:23] <nimbu> florian: it might be quite a while before it becomes stable
# 03[18:23] * Joins: arno (arno@72.254.90.86)
# [18:23] <nimbu> fantasai: anther problem with OM is that it might hold back development of rest of the spec.
# [18:23] <nimbu> anne: we might have to separate them
# [18:23] <nimbu> fantasai: we can cross-link the documents
# [18:24] <nimbu> arno: we might have conformance problem too, as OM is not necessary for implementations
# 03[18:24] * Joins: szilles (chatzilla@72.254.61.95)
# [18:24] <nimbu> s/arno/ aaronei
# [18:25] <nimbu> fantasai: suggestion to go with separate modules but paired, if we want to merge we can merge them later.
# [18:25] <nimbu> mollydotcom: what does it look like.
# [18:26] <nimbu> vhardy: for specs like css3 regions which have a little bit of OM in them, keep them in the spec rather than splitting
# [18:26] <nimbu> glazou: apart from css values, this doc is specification of current implementation, what are the plans for the future?
# [18:27] <nimbu> glazou: i am a heavy user of OM it is not practical at this point
# [18:27] <nimbu> anne: it needs improvements we need more tests for existing stuff first.
# [18:27] <nimbu> anne: it has better def for DOM level 2 styles, which lacked a lot of details
# [18:27] <florian> s/improvements we/improvements but we/
# 02[18:27] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
# [18:28] <nimbu> glazou: everybody knows that OM is resolved, its probably time to push for new things.
# [18:28] <nimbu> anne: making it more interoperably and finding more stuff …
# [18:29] <nimbu> glazou: if we do stabilization for the next 3 years, it requires commitment from editors, implementors. it would be more than 2 years before we implement the new stuff
# [18:29] <nimbu> glazou: we are not able to serialise stylesheets, css text.
# [18:29] <nimbu> anne: those are minor features its not smthing developers really want
# [18:29] <nimbu> glazou: they are not minor
# [18:29] <dbaron> s/css text/cssText/
# [18:30] <nimbu> arronei: they maybe minor for devs, but not for web browsers
# [18:30] <nimbu> glazou: people who are writing editors need to play with these things every day. we need to improve the OM for new services on the web
# 03[18:30] * Joins: szilles (chatzilla@72.254.61.95)
# [18:30] <nimbu> anne: we have not defined serialization for most of the things. Just adding new things does not seem to be a good way forward.
# [18:30] <nimbu> glazou: i know, we should start collecting new things we are doing to the OM, and what are the expectations from web authors.
# [18:31] <nimbu> anne: sure getting feedback from web authors would be great
# [18:31] <shepazu> (another interesting thing might be font/text metrics: http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/0004.html)
# [18:31] <nimbu> anne: better value api, once that is there, they want to have access to resolved vaules, there are various features browsers have added for their debugging tools, figure out which property calls current styles.
# [18:31] <nimbu> glazou: what are the rules that are being called at a given time
# [18:32] <nimbu> shepazu: in svg wg we have thought about adding font metric api, i thought it might be interesting
# [18:32] <nimbu> anne: like in canvas?
# [18:32] <nimbu> shepazu: the thing in canvas might be suitable why not generalize for genereal users
# [18:32] <nimbu> dino: you do not exactly know thats the font being used.
# [18:33] <nimbu> dino: all the canvas does is how long the piece of text was, does not tell you the ascenders,
# [18:33] <nimbu> szilles: or where the baselines are
# [18:33] <nimbu> shepazu: the things the canvas one does is useful
# [18:33] <nimbu> shepazu: i suspect chris saying web fonts working group will be interested in
# 02[18:33] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
# [18:34] <nimbu> anne: there have been requests for font loading api, but we have not figured out right way to do it
# 03[18:34] * Joins: tantek (tantek@66.87.7.52)
# [18:34] <nimbu> vhardy: how do you capture requirements? do u have a place for that?
# [18:34] <nimbu> anne: there is a page in whatwg wiki. we should probably create a place in csswg
# [18:34] <nimbu> glazou: long ago we had a list of suggestions for css3 we can have the list of suggestions for cssom
# [18:34] <anne> http://wiki.csswg.org/spec/cssom
# [18:35] <nimbu> sylvaing: do we have use cases?
# [18:35] <nimbu> anne: it does not have much yet.
# [18:35] <nimbu> florian: anne says stabilize, glazou says new features
# [18:35] <nimbu> glazou: not new features now, but soon
# [18:35] <nimbu> anne: i am also curious what implementors think, last year, we discussed this
# [18:36] <nimbu> anne: TabAtkins said google was planning on experimenting on values api
# [18:36] <nimbu> TabAtkins: we are still planning on it
# [18:36] <nimbu> anne: it kinda depends on implementors as well how fast it will move forward
# [18:36] <nimbu> anne: if there is not sufficient interest there is no point in adding a bunch of things and spend time on this if there are other things more interesting
# 03[18:37] * Joins: szilles (chatzilla@72.254.61.95)
# 03[18:37] * Joins: kojiishi (kojiishi@72.254.88.159)
# [18:37] <nimbu> vhardy: would it make sense to get a list of features and get feedback from community. we have some input and prioritize which are important
# 06[18:37] * tantek is grabbing a bite and lurking in irc.
# [18:37] <nimbu> glazou: microsoft has been doing online applications using formats that are not based on w3c standards.
# 03[18:38] * Joins: ChrisL (ChrisL@128.30.52.169)
# [18:38] <nimbu> glazou: the cost for that [feedback] is low
# [18:38] <nimbu> glazou: anything else to decide o OM
# [18:38] <ChrisL> rrsagent, here
# [18:38] <RRSAgent> See http://www.w3.org/2011/07/25-css-irc#T16-34-16
# [18:39] <nimbu> vhardy: first set of extensions and ask for feedback?
# [18:39] <nimbu> glazou: no just ask for feedback
# [18:39] <nimbu> shepazu: i would like people to see action to review it
# [18:39] <nimbu> anne: that is more problematic than community input
# [18:40] <nimbu> anne: we have got a few feedback like features like resolved value, authors want access to browser's proprietary extensions for their debugging tools
# [18:40] <nimbu> anne: problem is getting implementors attention.
# [18:40] <nimbu> anne: i work for an implementor but I dont think opera can really drive this.
# [18:40] <nimbu> glazou: user feedback can help. the feedback for css3 created traction.
# [18:41] <tantek> anne, are there particular web applications that would be helped (e.g. made faster, or new higher fidelity features) by more CSSOM features?
# [18:42] <nimbu> arronei: you have unique knowledge in the room, so your feedback would be useful
# [18:42] <nimbu> glazou: cost of a single missing feature of OM can be about 2000 likes of code. as you start duplicating the cost becomes prohibitive. 2 or 3 lines in c++ for 1000 lines of js
# [18:43] <nimbu> ACTION: glazou collect feedback from webdev community for CSSOM and put it on the wiki http://wiki.csswg.org/spec/cssom
# 06[18:43] * trackbot noticed an ACTION. Trying to create it.
# 06[18:43] * RRSAgent records action 1
# [18:43] <trackbot> Created ACTION-349 - Collect feedback from webdev community for CSSOM and put it on the wiki http://wiki.csswg.org/spec/cssom [on Daniel Glazman - due 2011-08-01].
# 03[18:43] * Joins: alexmog (alexmog@72.254.58.5)
# [18:43] <nimbu> anne: can we do one more item
# [18:43] <arno> let's get input from framework vendors as well (jQuery, Sencha, etc…)
# [18:44] <nimbu> anne: there is also the view module? can we publish it once more, so there is a link to the editor's draft
# [18:44] <nimbu> fantasai: its already in the module template
# [18:44] <nimbu> anne: since it is not published already, so it does not have that link
# [18:44] <nimbu> szilles: he says the view module does not have the new template
# [18:44] <nimbu> fantasai: we can publish then
# [18:45] <nimbu> RESOLVED: Publish the CSSOM View module
# [18:45] <nimbu> Topic: CSS Regions and CSS Exclusions Floats
# [18:46] <tantek> possible classes of use-cases to drive CSSOM evolution: web app games, where greater responsiveness (speed) and higher fidelity experience are both desired.
# [18:46] <nimbu> vhardy: last meeting we decided to name it CSS Floats not Exclusions
# 06[18:46] * hober alexmog: can you skype me in for this bit?
# [18:46] <nimbu> vhardy: there is a ED that has resolution from last f2f there is a wd that was published after f2f as well
# 06[18:46] * hober alexmog: I've just added you as a contact
# [18:46] <nimbu> vhardy: wiki has a bunch of issues and usecases that we will go over
# [18:46] <nimbu> alan hooked up the test harness and the spec references it now
# [18:47] <nimbu> vhardy: next step is to go over the bunch of issues we have and pub together a new draft
# [18:47] <nimbu> vhardy: for css exclusions we have the original fraft same as kyoto
# [18:47] <nimbu> vhardy: ms sent a proposal and glazou sent one over email
# [18:48] <nimbu> vhardy: we tried to converge on the proposals and the next step is to resolve issue sand produce new ED to propose as WD
# [18:48] <ChrisL> rrsagent, this meeting spans midnight
# [18:48] <RRSAgent> ok, ChrisL; I will not start a new log at midnight
# [18:48] <szilles> s/sand/and/
# 02[18:48] * Quits: lhnz (lhnz@188.223.83.48) (Ping timeout)
# [18:49] <smfr> http://wiki.csswg.org/spec/css3-regions
# [18:49] <nimbu> vhardy: we discussed there was no formal resolution in previous meeting. there was a q on the amiling list if css regions should allow copying from element into flow instead of moving content into flow. the editors agree this is something we should move to future release might be interesting but more complicated, so proposal is not to do it now and see if there is consensus in not adding this feature at this time
# [18:49] <nimbu> smfr: def agree on that
# [18:49] <nimbu> RESOLVED: Issue 4: Copying Flow Content is not something we are looking at right now.
# 03[18:50] * Joins: lhnz (lhnz@188.223.83.48)
# [18:50] <nimbu> vhardy: next issue is CSSOM issue. we dont have absility to find out which element is in a named flow
# [18:50] <nimbu> vhardy: there is no way to find that out right now.
# 06[18:50] * hober is alexmog there?
# 06[18:50] * dbaron hober, you can call sylvaing, I think
# [18:51] <nimbu> vhardy: our proposal is to get an action item for alexmog and me to add to the next draft unless someone thinks this feature should not be in the draft
# 06[18:51] * hober dbaron: thanks
# [18:51] <nimbu> florian: are u going to do this programmatically or declaratively
# 06[18:51] * hober sylvaing: what's your skype username?
# [18:51] <nimbu> smfr: that could be regions plural right
# [18:51] <nimbu> vhardy: programatically, plural
# 06[18:51] * sylvaing hober, sgalineau
# [18:52] <nimbu> glazou: this will be useful for debugging tools
# [18:52] <nimbu> ACTION: vhardy alexmog to add an api to find out which element is in a named flow
# 06[18:52] * trackbot noticed an ACTION. Trying to create it.
# 06[18:52] * RRSAgent records action 2
# [18:52] <trackbot> Created ACTION-350 - Alexmog to add an api to find out which element is in a named flow [on Vincent Hardy - due 2011-08-01].
# [18:53] <nimbu> vhardy: in css should you be able to set display on grid cell?
# [18:53] <nimbu> vhardy: how do we integrate with css grid
# [18:53] <nimbu> vhardy: one is to have a way to adress a gridcell to make it a region
# [18:53] <nimbu> Hixie:
# [18:53] <nimbu> vhardy: second, add an element as a child to the grid and declare it a region
# [18:54] <nimbu> alexmog: it would be interesting to have pseud elements for other virtual things like grid regions for really advanced scenarios.
# [18:55] <nimbu> alexmog: in pseudo elements you cant get a OM you need an entirely diff mechanism
# [18:55] <nimbu> alexmog: it has to be a parallel model.
# [18:55] <bradk> So one HTML element to create a grid slot, and another inside it to hold a flow?
# [18:56] <nimbu> szilles: there needs to be a CSSOM module that gives us back the faciilities
# [18:56] <JohnJansen> correct Brad
# 02[18:56] * Quits: lhnz (lhnz@188.223.83.48) (Ping timeout)
# [18:56] <nimbu> RESOLVED: Change the grid to integrate with css regions through regular elements
# [18:57] <nimbu> vhardy: if you want to grab content from flow, you use content property with from-flow.
# [18:57] <JohnJansen> (in other words, not do anything special for grid)
# [18:57] <nimbu> vhardy: there was an alt proposal you should make two properties parallel and it should be separate from content use float from and use the flow name to get the content from the flow
# [18:58] <nimbu> vhardy: should we make it through two parallel properties
# [18:58] <nimbu> vhardy: after we have had more discussions we think this is more clear use flow-form: <flow name>
# [18:58] <nimbu> smfr: would flow-from work on pseudo elemtn before / after
# [18:58] <nimbu> alexmog: vhardy yes
# [18:59] <nimbu> dbaron: i am uncomfortable making an additional property here. as it seems to do same thing as content.
# 06[18:59] * fantasai agrees with dbaron
# [18:59] <nimbu> alexmog: there are couple of considerations, content has a lot of baggage, there is content in css3 content, which is not where the spec is going.
# [19:00] <nimbu> alexmog: the flow-from applies to anything into a region.
# [19:00] <nimbu> alexmog: the content is somewhat different as it cant seem like it changes the nature of what it is applied to
# 02[19:00] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
# [19:00] <nimbu> fantasai: does that mean i cant have a table that accepts content from the region
# [19:01] <nimbu> vhardy: that is one of the issues, conceptually region is smthing that redirects content from somewhere else into this element.
# [19:01] <nimbu> s/vhardy/alexmog
# [19:01] <nimbu> fantasai: lets say i ahve a region and I want it to be a table row and I grab the contents of the table row and put it into regions what happens
# [19:01] <nimbu> alexmog: there is nothing in regions that wont work.
# [19:02] <nimbu> fantasai: so thats not display-inside region you are not overriding display inside just putting contents into it.
# [19:02] <nimbu> vhardy: we have a proposal to limit regions to display-inside block.
# [19:02] <nimbu> vhardy: otherwise it will become too complicated.
# [19:02] <nimbu> vhardy: we can resume discussion once we reach that.
# [19:03] <nimbu> alexmog: i dont feel very strongly about flow-from w.r.t content
# [19:03] <nimbu> alexmog: content has a history that does not make it designed for this.
# [19:03] <nimbu> arno: how would flow-from property how would it interact with content
# [19:03] <nimbu> alexmog: content would be overriden
# [19:04] <nimbu> vhardy: content is grabbing content from an element but flow-from is grabbing a segment not whole element. so its different
# [19:04] <nimbu> plinss: thats what you get from from-flow so i dont see why thats a problem, you just need to adapt that notion to the content.
# [19:04] <nimbu> alexmog: from the content property you can figure out what content is, from region that is not the same.
# [19:04] <nimbu> fantasai: having one property that overrides another causes problems with cascade
# [19:05] <nimbu> fantasai: which one wins? we should use the cascade as thats what it is for.
# [19:05] <nimbu> vhardy: other people felt it was good to add a property.
# [19:06] <nimbu> alexmog: content applies to inline flow-from doesn't. different compatibility. I am not sure it would always be that way. I am not sure if flow-from would always override.
# [19:06] <nimbu> vhardy: content would only apply to before and after in 2.1
# [19:06] <nimbu> fantasai: in css3 it would apply to all.
# [19:06] <nimbu> plinss: that has been the plan for 10/11 years at least
# [19:06] <nimbu> vhardy: the draft has the way you [fantasai] like it
# [19:06] <nimbu> vhardy: if majority feel we are good with content, I am okay with that.
# [19:07] <nimbu> alexmog: i dont have really strong feelings.
# [19:07] <nimbu> alexmog: having seperat property makes writing spec easier. Understanding easier. Not redefine content
# [19:08] <nimbu> RESOLVED: Stick to content property and content: from-flow(<flow-name>)
# [19:08] <nimbu> vhardy: currently to put smthing in flow you use flow: <flow-name>
# [19:08] <ChrisL> does tha mean content can have internal structure, now?
# [19:09] <nimbu> vhardy: alexmog pointed out flow could be short hand, so should we use flow-into and reserve flow for shorthand
# 06[19:09] * Zakim nimbu, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [19:09] <ChrisL> or is it flattened text?
# [19:09] <dbaron> "rename flow into flow-into" needs to be written down to be comprehensible
# [19:09] <nimbu> smfr: flow-into does not work for me, how about flow-name
# [19:10] <nimbu> szilles it is doing two things naming and adding content to flow
# [19:10] <nimbu> smfr: which property is canonical in terms of naming of the flow
# [19:10] <nimbu> vhardy: the flows get their name from the first piece of content that is moved into the flow
# [19:10] <nimbu> smfr: it is a bit too magic for me
# [19:11] <nimbu> vhardy: we iterated over that and we ended ups ettling on this way to do it.
# [19:11] <glazou> CSS _is_ magic anyway :-)
# [19:11] <nimbu> smfr: this is more like it is belonging to a flow.
# [19:11] <nimbu> smfr: make this part of a flow.
# [19:11] <bradk> I prefer just 'flow:'
# [19:11] <nimbu> alexmog: we tried things like flow-source and flow-target and those were very confusing.
# [19:12] <nimbu> glazou: we need ar esolution to move from flow to smthing
# [19:12] <nimbu> szilleswhat it actually is flow-out-to rather than into as it is taking it out of normal flow
# [19:12] <nimbu> RESOLVED: change flow from flow-smthing
# [19:13] <nimbu> vhardy: alexmog asked for renaming from-flow to flow-from
# [19:13] <nimbu> jRESOLVED: rename content: from-flow to content: flow-from
# [19:13] <nimbu> RESOLVED: rename content: from-flow to content: flow-from
# [19:14] <nimbu> dbaron: it makes more sense to me the other way
# [19:14] <nimbu> alexmog: we have border-top-right
# [19:15] <nimbu> vhardy: auto sizing of regions. this has been called as intrinsic size. i am not sure if all the history we have we are using intrinsic as a term in our discussions
# [19:15] <nimbu> vhardy: intrinsic has only been used for replaced content
# [19:15] <nimbu> fantasai: there is terminology for that in writing modes draft.
# [19:15] <fantasai> http://www.w3.org/TR/css3-writing-modes/#intrinsic-sizing
# [19:15] <nimbu> vhardy: i tried to stay clear of intrinsic size coz of possible confusion
# 03[19:15] * Joins: szilles (chatzilla@72.254.61.95)
# [19:16] <nimbu> vhardy: if we have auto-sizing in 1 or more dimensions how does it work
# [19:16] <nimbu> vhardy: we had a discussion with hyatt on mailing list, alexmog brought up more questions. this email is a summary of discussions at tha time
# [19:16] <nimbu> vhardy: the proposal was do we actually need to say anything about auto-sizing
# [19:17] <nimbu> vhardy: the main model i have been using for regions, the results should be identical if you have broken down regions into bits and pieces and moved them into regions
# [19:17] <nimbu> vhardy: so if I follow that model we dont need smthing
# [19:17] <nimbu> dbaron: the problem with that model is that the slicing depends on the size.
# [19:18] <nimbu> alan: if you have not specified height there wouldnt be any.
# [19:18] <nimbu> alexmog: paginating content in terms of flexible size is really complicated.
# [19:18] <nimbu> szilles: the two dimensions inline and block the rules are slightly different. in inline you would want it to be like a block, in block progression dimension you are going to use breaks to control…
# [19:19] <nimbu> alexmog: even more complicated is when width is undefined we can come up with a width measurement, the final layout is difficult to do if you dont know what the width to be.
# [19:19] <nimbu> alexmog: e.g. for float: right you need to figure out what the size is if it should be cleared or not.
# [19:19] <nimbu> dbaron: whats the proposal?
# [19:20] <nimbu> vhardy: start with region 1 and then put all content in region 1. if anything that does not fit, you have a first segment and reminder will flow into next regions. if you have regions with undefined height, it just gets all the content.
# [19:21] <nimbu> vhardy: at any point it would be like rest of the flow will be in the content.
# [19:21] <nimbu> smfr: say u have a bunch of ps and a 1000 px wide div.
# [19:21] <nimbu> smfr: the first region is flexible width wise
# [19:22] <nimbu> smfr: sounds like you would make first region 1000px wide
# [19:22] <nimbu> dbaron: what is the proposal for what intrinsic size would be?
# [19:22] <nimbu> dbaron: intrinsic size is not a function of layout
# [19:22] <nimbu> alexmog: intrinsic is not the right term here.
# [19:22] <hober> If the intrinsic width of a region is 0, the designer wins because their layout "fails fast" & they immediately know they need to specify a width
# [19:22] <nimbu> alan: the proposal is intrinsic size does not apply
# 02[19:23] * Quits: arronei_ (arronei@131.107.0.89) (Ping timeout)
# [19:23] <nimbu> alexmog: we should not be using the word intrinsic here.
# [19:24] <nimbu> dbaron: i sounds like you are talking about what the sizes of the regions are going to be. that is still a separate notion from intrinstic size
# [19:24] <nimbu> vhardy: intrinsic is used for replaced content 2.1
# [19:24] <nimbu> dbaron: we used for table,
# 03[19:24] * Joins: arronei_ (arronei@131.107.0.119)
# [19:24] <nimbu> dbaron: i am talking about preferred width and min width
# [19:24] <nimbu> fantasai: we call it two diff things based on if we are on tables chapter or not
# [19:25] <nimbu> szilles: there are two situations, 1. normal flow 2. out of normal flow. the rules for width and height calc are diff in those.
# [19:25] <nimbu> szilles: u use intrinsic when you are out of normal flow and simple calc in normal flow
# [19:25] <nimbu> szilles: regions behave in exact same way.
# 06[19:25] * hober claps for zero
# [19:26] <nimbu> alexmog: 3 options: 1. if region size is undefined it is zero. that option works very well the standard box model rules apply regardless of where region is.
# [19:26] <nimbu> the size will be calc using formula for box size.
# [19:26] <nimbu> problem is when accidentally size is not set on a region it has no visibility and it is difficult to understand where it is.
# [19:26] <hober> that's a feature, not a bug
# [19:27] <nimbu> 2. if it has a specific intrinsic size, 3000 by 850 it would be seful as you might have forgotten to set a size and then you can see it and then make it right size.
# [19:27] <bradk> maybe we need 'position:flow' or 'position:flow(ident)', and then all flows are non-floating blocks.
# 02[19:27] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
# [19:27] <dbaron> s/3000 by 850/300 by 150/
# [19:27] <nimbu> normal box models wont apply.
# [19:27] <nimbu> and thats not helpful.
# 03[19:28] * Joins: szilles (chatzilla@72.254.61.95)
# [19:28] <nimbu> alexmog: 3. size to content. we have to figure out what is going to fit into this region without exceeding max width max height if they are available.
# [19:29] <nimbu> alexmog: this is very complicated to implement, it would require more than 1 layout pass
# [19:29] <nimbu> alexmog: option 4. use normal box model calculations and if that ends up as still undefined with height, then use 300x850 intrinsic size.
# [19:29] <nimbu> vhardy: it is like replaced content right.
# [19:30] <nimbu> alexmog: it is not like the second option replaced content.
# [19:30] <nimbu> alexmog: the 4th option would be an implementation of normal box sizing where the box size is not considered at the point where it is on or not but at the end when it is resolved or not.
# 03[19:30] * Joins: tantek_ (tantek@76.164.21.47)
# [19:31] <hober> s/850/150/
# [19:31] <nimbu> thanks :)
# [19:32] <nimbu> i would expect devs to slice area into bunch of rectangles and use grid or flex box and then add content to the.
# [19:32] <nimbu> vhardy: the first proposal, the width and height would be set to 0 if you do not set height or width.
# 02[19:33] * Quits: tantek (tantek@66.87.7.52) (Ping timeout)
# 03[19:33] * tantek_ is now known as tantek
# [19:33] <nimbu> alexmog: this is a strong arg for default size to not be strict width/height
# [19:33] <nimbu> alexmog: if this region is going to have content in there, it wont have a size the flexbox and grid would give it.
# [19:33] <nimbu> alexmog: for the pruposes of flex or grid it has to have a default size of 0.
# [19:33] <nimbu> alexmog: then grid would give it size
# [19:36] <nimbu> ???: for e.g. auto width should be as wide as containing block so edges touch on normal flow. those rules would be ignored as per proposal 1, and width would be set to 0.
# [19:36] <nimbu> ???: the containers are typically well respected, we dont set to default size or width 0. so, which one is it that you are trying to achieve here.
# [19:36] <nimbu> vhardy: the general question is what happens with auto widths and heights on regions
# [19:37] <nimbu> vhardy: the point that smfr made is that if you layout everything then your widths maybe off.
# [19:37] <nimbu> vhardy: your usecase would naturally work, intrinsic height to default to 0 it is hard to make it work.
# [19:38] <nimbu> florian: in general resolving to 0 is smthing simple but not useful
# [19:38] <nimbu> mollydotcom: it is established and understood in devs, but now we are changing expectation.
# [19:38] <sylvaing> s/???/rossen
# [19:39] <nimbu> alexmog: 0 is logical, if a region that is part of a chain of regions if it does not have any natural content, it creates 0 new rules for sizing it.
# [19:39] <nimbu> alexmog: it is a good default.
# 02[19:39] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
# [19:39] <nimbu> mollydotcom: default to 0 sounds to be very different from what you are saying
# [19:40] <nimbu> vhardy: i propose we actually tab this discussion and go back. the default behaviour is not useful, we need to consider usecases.
# [19:40] <nimbu> phil: I thought it worked with any kind of layout, some proposals sacrifice the notion that how the child layout will make use of available space given by parent layout
# 03[19:41] * Joins: mmielke (mmielke@72.254.91.49)
# [19:41] <nimbu> dbaron: vhardy's statement intrinsic size is 0 then size is 0 is incorrect
# [19:41] <nimbu> plenty cases otherwise
# [19:42] <nimbu> dbaron: for intrinsic widths, the obv sol do the intrinsic width computation do over entire contents of the flow.
# [19:42] <nimbu> dbaron: what we have not specified we have not specified intrinsic heights in block progression dimension. flexbox and this (some degree) depends on that concept.
# [19:43] <nimbu> dbaron: problem: they are a function of width not entirely intrinsic. 1 concept that is entirely intrinsic and another that is a function of width
# [19:43] <nimbu> dbaron: i can imagine a situation where you want to build heights in region by starting either from 1st or last. splitting at breaks and using as many regions from beginning or end to build some sort of intrinsics where you need them. It might give you useful behaviour for a bunch of htem
# [19:44] <nimbu> dbaron: there is a bunch of issues being conflated.
# [19:44] <nimbu> dbaron: we need def for intrinsic sizes and we need to specify what actual resolved sizes for regions are.
# [19:44] <nimbu> szilles i heard you say the cal of size algorithm it does occasionally use intrinsic size but not necessarily use intrinsic size. That is critical to making it work, and we have a def of intrinsic size.
# 03[19:45] * Joins: cjon (cjon@72.254.88.135)
# [19:45] <nimbu> alexmog: if whereever in the cal we need the intrinsic size we consider all of the content or remainder of content from this to that. that makes it clear it might be expensive to calculate. it is really a fallback, so not going to be used all the time, so expensive should not be a problem there.
# [19:46] <nimbu> vhardy: that works for me
# [19:47] <nimbu> ACTION: vhardy Rework the issue of resolved sizes for regions and come up with an alt solution for the group along with use cases and examples
# 06[19:47] * trackbot noticed an ACTION. Trying to create it.
# 06[19:47] * RRSAgent records action 3
# [19:47] <trackbot> Created ACTION-351 - Rework the issue of resolved sizes for regions and come up with an alt solution for the group along with use cases and examples [on Vincent Hardy - due 2011-08-01].
# 02[19:47] * Quits: tantek (tantek@76.164.21.47) (Quit: tantek)
# 03[19:48] * Joins: szilles (chatzilla@72.254.61.95)
# 06[19:48] * hober imagines there's a <br duration="something">; that's what it sounds like anyway :)
# [19:48] <fantasai> <br type="coffee">
# 02[19:49] * Quits: florian (florianr@72.254.81.111) (Ping timeout)
# 06[19:49] * ChrisL Seatle, home of good coffee.. sometimes.
# 03[19:52] * Joins: tantek (tantek@66.87.7.52)
# 03[19:52] * Joins: tantek_ (tantek@66.87.7.52)
# 02[19:52] * Quits: tantek (tantek@66.87.7.52) (Connection reset by peer)
# 03[19:52] * tantek_ is now known as tantek
# 02[19:53] * Quits: mmielke (mmielke@72.254.91.49) (Ping timeout)
# 03[19:54] * Joins: tantek_ (tantek@76.164.21.47)
# 02[19:55] * Quits: nimbu (Adium@72.254.87.49) (Client exited)
# 03[19:55] * Joins: nimbupani (Adium@72.254.87.49)
# 02[19:55] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
# 02[19:57] * Quits: tantek (tantek@66.87.7.52) (Ping timeout)
# 03[19:57] * tantek_ is now known as tantek
# 03[19:59] * Joins: miketaylr (miketaylr@206.217.92.186)
# 02[20:01] * Quits: JohnJansen (qw3birc@128.30.52.28) (Quit: Page closed)
# 03[20:02] * Joins: JohnJansen1 (johnjan@72.254.58.78)
# 03[20:02] * Joins: szilles (chatzilla@72.254.61.95)
# 03[20:03] * Parts: JohnJansen1 (johnjan@72.254.58.78)
# 02[20:03] * Quits: anne (annevk@72.254.94.246) (Client exited)
# 03[20:03] * Joins: anne (annevk@72.254.94.246)
# 03[20:03] * Joins: JohnJansen1 (johnjan@72.254.58.78)
# [20:04] <JohnJansen1> JohnJansen1 is JohnJansen
# 02[20:05] * Quits: tantek (tantek@76.164.21.47) (Quit: tantek)
# 03[20:05] * Parts: JohnJansen1 (johnjan@72.254.58.78)
# 02[20:05] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
# 03[20:06] * Joins: JohnJansen (johnjan@72.254.58.78)
# 02[20:07] * Quits: plinss_ (plinss@72.254.58.149) (Quit: plinss_)
# 02[20:08] * Quits: alexmog (alexmog@72.254.58.5) (Quit: alexmog)
# 03[20:09] * Joins: szilles (chatzilla@72.254.61.95)
# 03[20:09] * Joins: florian (florianr@72.254.81.111)
# [20:09] <nimbupani> vhardy: region model, so the current spec has taken the approach that region is a general relation of an element relates to content
# 03[20:10] * Joins: plinss_ (plinss@72.254.58.149)
# 03[20:11] * Joins: mmielke (mmielke@72.254.91.49)
# [20:11] <nimbupani> vhardy: instead of working with children as source of generated boxes you would layout, you can get set of elements from source which will be used with layout algorithm
# [20:12] <nimbupani> vhardy: looking at use cases, our thinking now is 1. they are like printed pages and lay it out from page box to page box. they are different viewport areas.
# [20:12] <nimbupani> vhardy: mixing regions that have different type, region thats a table, a flex box and put them in a chain does not seem to make sense.
# [20:12] <nimbupani> vhardy: as you would not know which kind of segment you get.
# [20:12] <nimbupani> vhardy: limit regions to apply to things that are display-inside: block
# [20:13] <nimbupani> it could be table-cell or anything that has display-inside: block.
# [20:13] <nimbupani> vhardy: proposal restriction on regions to contain display-inside: block
# [20:13] <nimbupani> fantasai: i can see reasons for display-inside of flexbox.
# [20:14] <nimbupani> dbaron: the current flexbox is different from our implementation.
# [20:14] <nimbupani> fantasai: i can see wanting to have two flexbox containers and have a flow on them.
# [20:14] <nimbupani> dbaron: the way flexbox spec works is the container is display: flexbox, the items in it is display: block
# 03[20:14] * Joins: mielke (mmielke@72.254.91.49)
# 02[20:14] * Quits: mielke (mmielke@72.254.91.49) (Quit: mielke)
# [20:15] <nimbupani> vhardy: the idea is to simplify the implementation. not limit the future.
# [20:15] <nimbupani> vhardy: there are usecases for tables as well.
# [20:16] <nimbupani> vhardy: then we have to deal with mixing different float types which are much more complicated.
# [20:16] <nimbupani> fantasai: I am okay as long as we can expand it in that direction
# [20:17] <nimbupani> fantasai: I can see why you would want other display types
# [20:17] <nimbupani> alex: i want to keep the first version of spec simple.
# [20:17] <nimbupani> vhardy: what we are doing is not painting us in a corner. we should have a note saying in future we would extend it.
# [20:17] <nimbupani> RESOLVED: for this version we are limiting regions to be block containers
# [20:17] <nimbupani> ACTION: vhardy add a note to expand this in the future for different types of containers
# 06[20:17] * trackbot noticed an ACTION. Trying to create it.
# 06[20:17] * RRSAgent records action 4
# [20:17] <trackbot> Created ACTION-352 - Add a note to expand this in the future for different types of containers [on Vincent Hardy - due 2011-08-01].
# 02[20:18] * Quits: szilles (chatzilla@72.254.61.95) (Quit: ChatZilla 0.9.87 [Firefox 5.0/20110615151330])
# 03[20:18] * Joins: szilles (chatzilla@72.254.61.95)
# [20:18] <nimbupani> vhardy: region breaks. CSS 2.1 has page breaks that only work on paged media. css3 column breaks and page breaks.
# [20:19] <nimbupani> vhardy: page breaks slices a column into two, the next column box moves to next page.
# [20:19] <nimbupani> vhardy: how do you break content when you layout between regions
# 03[20:19] * nimbupani is now known as nimbu
# [20:20] <nimbu> vhardy: those questions also arise for multicol
# [20:20] <nimbu> vhardy: if u have breaks in ur content and nesting what does it mean for heirarchy
# [20:20] <nimbu> vhardy: current spec: we will add a new type of break and thats what content will honor when it lays out content. alex objected to it so we came up with alt proposals
# [20:21] <nimbu> vhardy: instead of saying i need to have a new break, state which breaks you will honour
# [20:21] <nimbu> vhardy: as a region you state which breaks you honor
# [20:21] <nimbu> vhardy: what that means is content is break aware and container aware.
# [20:22] <nimbu> vhardy: the content can annotate myself, you can then have container types and associated break types.
# [20:22] <nimbu> alex: is this clear, or do we need a picture
# [20:22] <bradk> picture
# [20:23] <ChrisL> picture and photo
# [20:23] <nimbu> alex: using either column breaks or page breaks producing multicol layout with regions there is no way to define currently contents going from one column like region to another column like region if you have a columnbreak, but if you have a page break then you need to go to a new page with a new container
# [20:24] <nimbu> alex: we need to communicate this region is a column and another region is a page.
# [20:24] <bradk> so, column-break would break to next region if both regions are each one-column blocks?
# [20:24] <nimbu> alex: if we decide we dont need that kind of precise control in regions coz that content would be designed in smaller pieces, with one kind of break. we would gravitate to never need column/page break difference. but only one kind of break.
# [20:25] <bradk> unless a block is identified as a page somehow?
# [20:25] <nimbu> vhardy: one of the extensions is to generalise ideas and do named breaks
# [20:25] <nimbu> vhardy: my content should know what kind of container it is laid out on.
# [20:26] <nimbu> vhardy: another approach is if your content just wants to know where it should break.
# [20:26] <nimbu> vhardy: second approach content does not know about container types or what kind of breaks are being used.
# [20:26] <nimbu> vhardy: second one is a simplifying assumption and want feedback.
# [20:26] <nimbu> vhardy: 1. breaks are container agnostic 2. breaks are container aware.
# [20:27] <nimbu> smfr: there has to be a precedent here? what does page layout do.
# [20:27] <nimbu> alex: yes, they do different kinds of breaks. page break and section break.
# [20:27] <nimbu> vhardy: ur q is on existing tools?
# [20:27] <nimbu> smfr: existing tools
# [20:28] <nimbu> alex: columns are onlu possible as full-page columns or full section columns, so page break is always a column break. there is no such thing as breaking multi-col block …
# [20:28] <nimbu> alan: in indesign you have a column break, page break, frame-break
# [20:28] <nimbu> alex: whats the diff between frame/page break
# [20:28] <nimbu> alan: frame break is like a region
# [20:28] <nimbu> florian: can u have nested frames
# [20:29] <bradk> frame breaks can jump across several pages to get to next frame to, right?
# [20:29] <nimbu> alan: I think so, i do not know if it makes a difference in the break scenario.
# 03[20:29] * Joins: tantek (tantek@72.254.95.69)
# [20:29] <nimbu> vhardy: frames are more like regions
# [20:29] <nimbu> alan: yes
# [20:30] <nimbu> plinss: dont confuse column breaks with region breaks as column only breaks to another col not a region
# [20:30] <nimbu> plinss: i dont see why you should respect other kinds of break.
# [20:30] <nimbu> alex: so how do you know the region is in the next page?
# [20:30] <nimbu> plinss: from the pagination model.
# [20:31] <nimbu> alex: what is a page?
# [20:31] <nimbu> fantasai: a page in css is a page box
# [20:32] <nimbu> fantasai: in mozilla those are page boxes. particular kind of css box
# [20:32] <nimbu> alex: in IE they are also kind of a box.
# [20:32] <nimbu> fantasai: a page break requests a break between page boxes.
# [20:33] <nimbu> alex: i would like to be able to write page view in a standard way not just for print preview but also for page reading (like online magazine)
# [20:33] <nimbu> plinss: if you are doing with divs you are not doing anything with css box model.
# [20:34] <nimbu> alex: you can have multiple regions in every page. if you are going to do page break in content and requires it continue to next page, no way to determine what next page is.
# [20:34] <nimbu> florian: you need something that gets you to next page
# [20:35] <nimbu> florian: if we want to support that we need something like that.
# [20:35] <nimbu> alex: if some content that you place in to region has page-break: avoid, is that smthing regions will not be capable of satisfying, or would we have smthing different.
# 02[20:35] * Quits: nimbu (Adium@72.254.87.49) (Client exited)
# [20:35] <fantasai> break-before: region(mycustompaginator)
# 03[20:35] * Joins: nimbupani (Adium@72.254.87.49)
# [20:36] <nimbupani> smfr: why dont u use normal paged media?
# [20:36] <nimbupani> alex: if nothing more adv is available we would consider every region is a page from point of view of breaking
# 03[20:36] * nimbupani is now known as nimbu
# 02[20:36] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
# [20:36] <nimbu> szilles: all the things u have said requires a content change.
# [20:37] <nimbu> szilles: the author wants to present this content if it were a page in the display he is presenting to the user
# [20:37] <nimbu> vhardy: if you want something foo, then you say break for 'foo'
# 03[20:37] * Joins: karl (karlcow@128.30.54.58)
# 03[20:38] * Joins: hyatt (hyatt@98.200.13.42)
# [20:38] <nimbu> alex: i dont get why you are objecting. moz has internally a special element to represent …
# [20:38] <nimbu> fantasai: we have a page box we have smthing in the rendering tree that represents a page box
# [20:38] <nimbu> alex: as an author how do you make an element a page box
# [20:38] <nimbu> fantasai: we cant
# [20:39] <nimbu> alex: with regions we are creating an opportunity for author to use page navigating algorithm.
# [20:39] <nimbu> plinss: do u want headers and footers to appear on random elements?
# [20:39] <nimbu> dbaron: there is an assumption that you should be able to do what you described without changing the content. i dont think thats true
# [20:40] <nimbu> florian: u might want to break sometimes on certain page breaks and not on some others.
# [20:40] <nimbu> vhardy: thats the intended functionality is to have more than 1 kind of breaks.
# [20:41] <bradk> What about regions inside regions inside regions inside regions? You need to be able to indicate level
# [20:41] <nimbu> plinss: you really are talking about a region break to a higher level (in nested regions).
# [20:41] <nimbu> fantasai: e.g. break-before: region('named flow');
# [20:42] <bradk> You might not know the region you are in, but know that you want to break 2 levels up. break-before:region(-2)
# [20:42] <nimbu> vhardy: take an action to add the usecase alex is talking about and measure up the actions
# [20:43] <nimbu> alex: only region break is also generally okay.
# 03[20:44] * Parts: mollydotcom (mollyh@72.254.57.69)
# [20:44] <nimbu> alan: before we got to pagination, it sounded like plinss was saying if we have col breaks and region breaks and i have flow going to regions that are not going to multicol elements you would prefer col break to not break to next region.
# [20:45] <nimbu> vhardy: if you got page break and not in paged media it does nothing
# [20:46] <nimbu> alan: if you have a region situation and u have a column break i prefer my text to go to next region from auth perspective each region is a single column
# [20:46] <nimbu> alan: we have usecases where regions to use multicol layout
# [20:46] <nimbu> alex: in multicol spec does it say in paged media each page should be considered a column?
# [20:47] <nimbu> ACTION: howcome to answer if paged media each page should be considered a column?
# 06[20:47] * trackbot noticed an ACTION. Trying to create it.
# 06[20:47] * RRSAgent records action 5
# [20:47] <trackbot> Created ACTION-353 - Answer if paged media each page should be considered a column? [on Håkon Wium Lie - due 2011-08-01].
# 03[20:47] * Joins: mollydotcom (mollyh@72.254.57.69)
# 03[20:47] * Joins: alexmog (alexmog@72.254.58.5)
# [20:48] <nimbu> vhardy: option1 seems to be off the table.
# [20:48] <nimbu> vhardy: we agree we need breaks that are typed.
# 03[20:48] * Joins: szilles (chatzilla@72.254.61.95)
# [20:49] <nimbu> plinss: if we have nested region flows we need ability to break a level.
# [20:50] <nimbu> plinss: the types of usecases that alex is taking about i think we should have to work on getting browsers to render a page in paginated mode.
# [20:51] <fantasai> There was a suggestion to add 'overflow-style: paged' a while ago.
# [20:51] <hober> Yes, some kind of explicit "I want paginated mode" switch is much cleaner
# [20:51] <bradk> or a section of a page in paginated mode
# [20:52] <nimbu> alex: we are making it possible to create a webpage that gives you the same experience as looking at a magazine. give it same kind of control including control of column breaks and page breaks. we would need to create new break types
# 03[20:53] * Joins: dsinger (dsinger@68.126.184.142)
# 03[20:53] * Joins: Martijnc (Martijnc@84.192.44.100)
# [20:53] <nimbu> alex: if we switch browser to switch to page mode, the ui browser provides to navigate pages is light years away from what designers would want in page navigation experience
# [20:54] <nimbu> RESOLVED: we need breaks that are specific to containers they are part of.
# [20:55] <nimbu> ACTION: vhardy come up with a proposal for breaks either a page-break or a general type of break or both and related use cases
# 06[20:55] * trackbot noticed an ACTION. Trying to create it.
# 06[20:55] * RRSAgent records action 6
# [20:55] <trackbot> Created ACTION-354 - Come up with a proposal for breaks either a page-break or a general type of break or both and related use cases [on Vincent Hardy - due 2011-08-01].
# [20:55] <nimbu> smfr: we are not happy with behavior for iframe objects in spec
# 03[20:55] * Joins: lhnz (lhnz@188.223.83.48)
# [20:55] <nimbu> smfr: issue 5
# [20:55] <hober> http://dev.w3.org/csswg/css3-regions/#the-flow-property
# [20:56] <nimbu> alex: it is not an issue any more. I added it in.
# [20:56] <hober> "For an <iframe>, an <object> or a <embed> element, the ‘flow’ property has a different behavior. The effect is similar to turning the ‘display’ property on the element to ‘none’ while moving the root element of the referenced document to the named flow."
# [20:57] <nimbu> alex: if we remove it, then it would be a non-standard thing like font-size-adjust. if it stays there, it is okay to have it optional. Another option there is to have an explicit way of saying for an element if the element that is added to flow or content added to flow.
# [20:57] <nimbu> alex: i like the second option as it is much more explicit.
# [20:57] <nimbu> smfr: you start introducing cross origin problems also q of what to do with script style elements and stuff
# [20:58] <nimbu> alex: the cross frame security does apply. We are not going to take content from iframe if its not in the same origin.
# [20:58] <nimbu> smfr: the spec should stay that.
# [20:58] <nimbu> dbaron: sounds a lot like seamless iframe stuff html5
# [20:58] <nimbu> dbaron: should we do that instead of redefining it
# [20:58] <nimbu> TabAtkins: seamless iframe becomes like an included
# [20:59] <nimbu> anne: the iframe height becomes height / width of the document. selectors bleed through.
# [20:59] <nimbu> alex: no default padding
# [20:59] <dbaron> http://dev.w3.org/html5/spec/the-iframe-element.html#attr-iframe-seamless
# [21:00] <hober> So in a region <iframe> would behave like replaced but <iframe seamless> would behave like alex has specced
# [21:00] <nimbu> ACTION: alexmog to look at seamless iframes and reconcile it with what we have in the spec. We should add the security consideration into iframe paragraph.
# 06[21:00] * trackbot noticed an ACTION. Trying to create it.
# 06[21:00] * RRSAgent records action 7
# [21:00] <trackbot> Created ACTION-355 - Look at seamless iframes and reconcile it with what we have in the spec. We should add the security consideration into iframe paragraph. [on Alex Mogilevsky - due 2011-08-01].
# [21:00] <bradk> link?
# [21:00] <nimbu> vhardy: we hve had diff proposals for floats and exclusions
# [21:01] <nimbu> vhardy: worked on a bunch of use cases.
# [21:01] <stearns> http://wiki.csswg.org/ideas/css3-floats-use-cases
# [21:01] <nimbu> vhardy: we have a model we would like to propose to the group
# [21:01] <bradk> thanks
# [21:02] <nimbu> vhardy: present this to be ready for editors draft that is a convergence of these two proposals.
# [21:02] <nimbu> ???: 2, 3,4 are essence of how we build the model and 1 is how we use it
# [21:03] <smfr> http://wiki.csswg.org/ideas/css3-floats
# [21:03] <arronei> s/???/rossen
# [21:03] <nimbu> rossen: how to create container model.
# [21:03] <nimbu> rossen: #3 how the shape gets affected by exclusion
# 02[21:04] * Quits: konaya (konaya@83.251.16.72) (Quit: Leaving)
# 03[21:04] * Joins: konaya (konaya@83.251.16.72)
# [21:04] <nimbu> rossen: in our case, we looked at a diff point of view, already have exclusions in css2 which are floats
# [21:05] <nimbu> rossen: overloading the float property was redundant. we still had to use wrap-mode in ms proposal to trigger an exclusion
# [21:05] <nimbu> rossen: in our case the wrap-type was defaulting to around. so it was enough to say float: position to create an exclusion but in reality it needs both
# [21:05] <karl> RRSAgent, minutes?
# [21:05] <RRSAgent> I'm logging. Sorry, nothing found for 'minutes'
# [21:06] <karl> RRSAgent, pointer?
# [21:06] <RRSAgent> See http://www.w3.org/2011/07/25-css-irc#T19-01-34
# [21:06] <nimbu> rossen: agreement is wrap-mode should be enough to create an exclusion as reg floats are already exclusions, we dont need another.
# [21:06] <nimbu> rossen: it would be interesting to combine what wrap mode really means outside or inside of shape
# [21:07] <nimbu> rossen: if you want table cell circular, you can apply shape on the inside of an element without affecting the outside default shape/box model
# [21:07] <nimbu> rossen: the last version of proposal we had, wrap-mode: default as if wrapping was not involved.
# [21:07] <nimbu> vhardy: this is a stub, i need more work on that.
# [21:08] <nimbu> alex: so initial is around?
# [21:08] <nimbu> rossen: initial is none
# 02[21:08] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
# [21:08] <nimbu> szilles: if its auto floats can behave the way they do today
# [21:08] <nimbu> vhardy: i propose we dont get into this. we need to work out the details. we have not discussed it.
# [21:08] <nimbu> rossen: thats fine by me
# 02[21:08] * Quits: stearns (qw3birc@128.30.52.28) (Ping timeout)
# [21:09] <nimbu> dbaron: i am uncomfortable about making resolutions about details when I do not understand the models yet
# [21:09] <nimbu> vhardy: wrap-mode: inside it will wrap inside (shows slides)
# [21:10] <nimbu> vhardy: wrap-mode: all-left would control the wrapping internally for the left side.
# [21:10] <nimbu> vhardy: we resolved having 1 property trigger an exclusion rather than 2 proposed by ms
# [21:11] <nimbu> alex: maybe we dont need resolutions on these fine grained issues.
# [21:11] <nimbu> vhardy: i think the resolution is to have a single trigger than 2.
# [21:11] <nimbu> vhardy: not on the specific properties
# [21:12] <nimbu> dbaron: it seems like you are proposing the model where anything wraps around anything. i have not seen a lot to explain how thats supposed to work. i saw the spec which says this syntax is supposed to do this thing but it is no where close to doing that thing.
# 03[21:12] * Joins: stearns (qw3birc@128.30.52.28)
# [21:12] <nimbu> vhardy: we will get to that.
# [21:13] <nimbu> ACTION: vhardy make the default value for wrap-mode be auto.
# 06[21:13] * trackbot noticed an ACTION. Trying to create it.
# 06[21:13] * RRSAgent records action 8
# [21:13] <trackbot> Created ACTION-356 - Make the default value for wrap-mode be auto. [on Vincent Hardy - due 2011-08-01].
# [21:14] <nimbu> rossen: next point is containing model for exclusions
# [21:14] <nimbu> rossen: we didnt make any change to css to containing model. based on position property containing block is computed just like css2 block.
# [21:14] <nimbu> rossen: there is one exception, that is the new position: page-value that we are adding
# [21:14] <nimbu> arronei: we can talk about that later when we get to css position
# 03[21:15] * Joins: arno1 (arno@192.150.10.201)
# 02[21:15] * Quits: mollydotcom (mollyh@72.254.57.69) (Quit: mollydotcom)
# [21:15] <nimbu> alex: what it is saying is that the scope of what an exclusion affects its containing block.
# [21:16] <nimbu> alex: the important difference this makes compared to other containing model is that it could be defined an element affects anything that it visually overlaps.
# [21:16] <nimbu> alex: it could be defined an element with exclusion affects an element further down in the content flow and nothing before it.
# 02[21:16] * Quits: arno (arno@72.254.90.86) (Ping timeout)
# [21:16] <nimbu> alex: that would be very limiting in positioning exclusions backwards and forward which is a very common use case
# 03[21:17] * Joins: szilles (chatzilla@72.254.61.95)
# [21:17] <nimbu> dbaron: so you are proposing that things that create exclusions are still positioned according to normal css rules
# [21:17] <nimbu> dbaron: 2 divs both contain text, the second div has margin-top: −5em wrap shape smthing to make a circle that is 5em radius and they both have text.
# [21:18] <nimbu> dbaron: where do you position the second text?
# [21:18] <nimbu> alex: we are getting there to describe the processing model which is where we resolve contradictory layout situation.
# [21:18] <nimbu> alex: can we go over issue 5 then issue 1 as issue 1 is most difficult issue
# [21:19] <nimbu> rossen: so, issue 5 was ordering of exclusions. both the container models is same as css2.
# [21:19] <nimbu> rossen: everything in the scope of the container will be affected by exclusion
# 03[21:19] * Joins: nmccully (nmccully@192.150.22.5)
# [21:21] <nimbu> rossen: overlapping exclusions: 1. first draft mentioned taking doc order which was not intuitive 2. we are staying with z-index ordering. that appeared as double dependency from exclusions from within the content that would influence the outer exclusions or content outside. but we are scoping the effect of exclusions to containing block then ordering per z-index becomes much more easier.
# [21:21] <nimbu> szilles: show the example.
# [21:21] <nimbu> rossen: it is visual vs. content order by default.
# [21:22] <nimbu> alex: based on z-index, if its not set, elements that over lap prev elements then later elements create exclusions over prev elements. we should try to avoid relayout.
# [21:22] <nimbu> dbaron: so when you say exclusions affect only other things in containing block I presume you mean everything descendant from containing block. It includes siblings and so on
# 02[21:23] * Quits: nmccully (nmccully@192.150.22.5) (Quit: Leaving.)
# [21:23] <nimbu> dbaron: this idea of using z-index you are potentially crossing stacking context
# [21:24] <nimbu> dbaron: with subtree model, you can be in situations where excl a should affect b but not vice versa as a is a descendant of b's containing block but b is not a descendant of a's containing block.
# [21:24] <nimbu> rossen: if u are on some level of the tree, and u have containing block which have exclusions on each side. and a set of eclusions coming from its container.
# [21:25] <nimbu> rossen: u can order the exclusions in the containing block. you can only take exclusions that are higher than your z-index. once you take those exclusions in your container then you need to resolve with exclusions inside.
# [21:26] <nimbu> rossen: even if you resolve the exclusions inside, it does not affect exclusions that are coming above the containing block.
# 03[21:27] * Joins: mollydotcom (mollyh@72.254.57.69)
# [21:27] <dbaron> just trying to figure out if this z-order model makes sense given that
# [21:28] <nimbu> phil: you have a positioned element, and it has some -ve z-index so its going to be behind rest of the content.
# 06[21:28] * nimbu alexmog goes to the board to draw
# 06[21:29] * ChrisL asks for whiteboard photos
# [21:31] <smfr> ChrisL: mollydotcom is taking some
# [21:31] <ChrisL> ty
# [21:31] <nimbu> rossen: it may or may not wrap around D depending on z-index
# [21:31] <nimbu> rossen: we know D can never wrap around C
# [21:31] <nimbu> vhardy: is D a containing block?
# [21:31] <nimbu> alex: all are abs pos
# [21:32] <nimbu> rossen: the answer here is we apply priority based on z-order at container levels
# [21:32] <nimbu> rossen: if smthing affects B based on z then everything in B would be affected by that.
# [21:32] <nimbu> rossen: there should be no way D would wrap around C, so ther eis no way C would wrap around D.
# [21:33] <nimbu> phil: what if there is opacity on D?
# [21:33] <nimbu> alex: D does not have to use wrap-mode it does not have to create an exclusion.
# [21:33] <nimbu> rossen: exclsion is only when you want to "exclude"
# [21:34] <nimbu> alex: discussion on using -index or other kind of index is a separate discussion.
# [21:34] <nimbu> alex: issue is to determine order on exclusions and we have come up with z-index.
# [21:35] <nimbu> rossen: the prev containing model was different that was exposing a number of complexities
# [21:35] <nimbu> alex: we should consider all hte complicated z-index combination and see if it works
# 06[21:35] * Zakim excuses himself; his presence no longer seems to be needed
# 03[21:35] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [21:35] <nimbu> szilles: what you saying is that the drawing order is the model of exclusions
# [21:35] <nimbu> szilles: z-index affects the drawing order.
# 06[21:36] * nimbu glazou declares a lunch break
# [21:36] <nimbu> glazou: we will continue after lunch
# 02[21:36] * Quits: dbaron (dbaron@72.254.87.122) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# 02[21:36] * Quits: nimbu (Adium@72.254.87.49) (Client exited)
# 02[21:36] * Quits: sylvaing (sylvaing@72.254.84.129) (Quit: sylvaing)
# 02[21:37] * Quits: glazou (glazou@72.254.87.99) (Quit: glazou)
# 02[21:37] * Quits: smfr (smfr@72.254.88.19) (Quit: smfr)
# [21:37] <mollydotcom> ChrisL: here's a drawing http://twitpic.com/5vs3ra
# [21:37] <ChrisL> molly, thanks!
# 02[21:38] * Quits: arronei (arronei@72.254.94.7) (Ping timeout)
# 02[21:38] * Quits: mollydotcom (mollyh@72.254.57.69) (Quit: mollydotcom)
# 02[21:38] * Quits: mmielke (mmielke@72.254.91.49) (Ping timeout)
# 02[21:38] * Quits: cjon (cjon@72.254.88.135) (Ping timeout)
# 02[21:39] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
# 02[21:39] * Quits: ChrisL (ChrisL@128.30.52.169) (Quit: Fire on main board error, client combusted)
# 02[21:39] * Quits: florian (florianr@72.254.81.111) (Ping timeout)
# 02[21:44] * Quits: tantek (tantek@72.254.95.69) (Quit: tantek)
# 02[21:46] * Quits: TabAtkins_ (tabatkins@72.254.88.61) (Ping timeout)
# 02[21:48] * Quits: arno1 (arno@192.150.10.201) (Connection reset by peer)
# 02[22:00] * Quits: kojiishi (kojiishi@72.254.88.159) (Ping timeout)
# 02[22:08] * Quits: anne (annevk@72.254.94.246) (Ping timeout)
# 02[22:10] * Quits: vhardy (vhardy@72.254.57.220) (Ping timeout)
# 03[22:16] * Joins: sylvaing (sylvaing@72.254.84.129)
# 03[22:33] * Joins: arronei (arronei@72.254.94.7)
# 06[22:34] * hober sylvaing: ping
# 03[22:35] * Joins: cjon (cjon@72.254.88.135)
# 03[22:36] * Joins: TabAtkins_ (tabatkins@72.254.88.61)
# 06[22:37] * sylvaing hober ?
# 06[22:37] * hober sylvaing: i'm not on the skype call anymore :(
# 06[22:38] * hober sylvaing: can you re-add me?
# [22:38] <sylvaing> yeah, sorry. seems you dropped
# 06[22:39] * sylvaing let me restart this call
# 03[22:39] * Joins: arno (arno@72.254.56.176)
# 06[22:39] * hober thanks!
# 02[22:41] * Quits: alexmog (alexmog@72.254.58.5) (Ping timeout)
# 03[22:42] * Joins: smfr (smfr@72.254.63.21)
# 03[22:43] * Joins: szilles (chatzilla@72.254.61.95)
# 03[22:43] * Joins: mollydotcom (mollyh@72.254.57.69)
# 03[22:44] * Joins: dbaron (dbaron@72.254.87.122)
# 03[22:44] * Joins: glazou (glazou@72.254.87.99)
# 03[22:45] * Joins: kojiishi (kojiishi@72.254.88.159)
# [22:45] <TabAtkins_> ScribeNick: TabAtkins_
# 06[22:45] * sylvaing 'there is a scribe for that'
# 03[22:46] * Joins: alexmog (alexmog@72.254.58.5)
# [22:46] <sylvaing> rossen
# [22:47] <TabAtkins_> rossen: [something about z-order] Did that make sense to everybody?
# 03[22:47] * Joins: nimbupani (Adium@72.254.58.68)
# 03[22:47] * Joins: nmccully (nmccully@72.254.59.155)
# 03[22:47] * Joins: anne (annevk@72.254.94.246)
# [22:47] <TabAtkins_> vhardy: We'll just take all the feedback and integrate it into the next draft.
# [22:48] <TabAtkins_> rossen: Back to issue 1, processing model.
# 03[22:48] * Joins: florian (florianr@72.254.81.111)
# [22:48] <TabAtkins_> rossen: Currently we take the easy way out.
# [22:48] <TabAtkins_> rossen: We treat exclusions as out-of-flow, so you lay out once to pick up any "auto" positions that exlusions may anchor to, then you position exclusions, then you fill in the rest.
# 03[22:49] * Joins: tantek (tantek@72.254.95.69)
# [22:49] <TabAtkins_> rossen: The obvious problem with this is the accumulation of error; exclusions will push around their own or other's auto positions.
# [22:49] <TabAtkins_> rossen: There are discussions about a better processing model that would keep the auto positions closer to the right place in the flow, but so far there's been nothing solid enough for us to write down.
# 03[22:49] * Parts: florian (florianr@72.254.81.111)
# 03[22:49] * Joins: florian (florianr@72.254.81.111)
# [22:50] <TabAtkins_> rossen: That is the processing model we have for oof with position:absolute|fixed|page.
# [22:50] <TabAtkins_> alexmog: The model rossen is describing, I'm proposing to have it as non-normative atm; it describes something specific enough that simple cases can be interop, but it leaves room for a more advanced processing model later.
# 03[22:50] * Joins: jdaggett (jdaggett@110.4.235.34)
# [22:51] <TabAtkins_> alexmog: We'll tighten it up as we get impl experience.
# [22:51] <TabAtkins_> arronei_: If you make it non-normative, you can't test it or depend on it.
# [22:51] <TabAtkins_> alexmog: We can make it normative to the extent of the simple bits, but I don't think we can fully fill it in yet.
# [22:53] <TabAtkins_> rossen: position:static has only one difference - you actually lay out with the flow.
# [22:54] <TabAtkins_> rossen: For position:static exclusions, they're laid out with the normal flow pass.
# [22:54] <TabAtkins_> rossen: If all you hae is static exclusions, you don't need a second pass, as they're laid out as part of the content.
# [22:54] <TabAtkins_> alexmog: What happens if they have a negative margin?
# [22:54] <TabAtkins_> rossen: Same as today - they'll overlap the previous content.
# 02[22:54] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
# [22:54] <TabAtkins_> alexmog: Doesn't that contradict what exclusions should be doing?
# [22:55] <bradk> It would be like a float, more or less, if static? Only affecting the leading edges?
# [22:55] <TabAtkins_> rossen: They only push around other stuff in the abspos case.
# 06[22:55] * TabAtkins_ bradk, yeah. Just a shaped float.
# [22:55] <TabAtkins_> rossen: [draws a diagram]
# [22:56] <bradk> Can someone post a photo once there is something to look at on the whiteboard?
# 06[22:56] * TabAtkins_ bradk, will do
# [22:57] <TabAtkins_> rossen: While laying out text, you lay out line by line. When you encounter a static exclusion, you're in the middle of layout out one line (previous lines are already done).
# [22:57] <TabAtkins_> rossen: If this was a regular div, the block would consume all the space to its sides, pushing following text below it. Exclusion just lets following text fill in space around it.
# 03[22:58] * Joins: arno1 (arno@192.150.10.200)
# [22:58] <TabAtkins_> rossen: Moving on to further issues.
# [22:59] <TabAtkins_> rossen: issue 7, what does "shrink-to-fit" mean for floats with shapes?
# 03[22:59] * Joins: szilles (chatzilla@72.254.61.95)
# [23:00] <TabAtkins_> rossen: We defined an easy way out here - use the bounding box of the exclusion shape as the "shrink-to-fit" for the floater.
# 02[23:00] * Quits: arno (arno@72.254.56.176) (Ping timeout)
# [23:00] <TabAtkins_> alexmog: Nobody really liked the idea that they have to calculate the closest intersection of arbitrary shapes - too hard of a problem.
# [23:00] <TabAtkins_> alexmog: So it should be acceptable to treat exclusions as rectangles for the purpose of shrink-to-fit.
# [23:03] <TabAtkins_> alexmog: [something explaining the above point that I missed]
# [23:03] <TabAtkins_> rossen: I think the shape doesn't correspond to the border box - it could maybe define its own bounding rect.
# 06[23:03] * mollydotcom here's a photo of the diagram when encountering static exlusion http://www.twitpic.com/5vt57v
# [23:03] <TabAtkins_> alexmog: It shouldn't get bigger than what's calculated with bounding boxes.
# [23:03] <TabAtkins_> alexmog: You can always make it smaller.
# [23:03] <TabAtkins_> szilles: I'm slightly confused. If I have a wrap-shape, it has a size. Why do I need shrinkwrap at all?
# 03[23:03] * Joins: vhardy (vhardy@72.254.57.220)
# [23:03] <TabAtkins_> rossen: We're talking about floats that are themselves shaped.
# [23:04] <TabAtkins_> dbaron: The shapes can have percenetages, so the shape is based on the size itself.
# [23:04] <TabAtkins_> dbaron: If the shape is a circle centered on the box with a radius of 50%, the shape is a function of the size.
# [23:04] <TabAtkins_> rossen: If that was a div with width:50% inside of the float, the same effect would occur.
# [23:05] <TabAtkins_> rossen: One more difference from the original exclusions spec was a property named "flow-wrap" that allowed elements to not pay attention to exclusions.
# 02[23:05] * Quits: miketaylr (miketaylr@206.217.92.186) (Quit: miketaylr)
# [23:05] <TabAtkins_> rossen: We should maybe rename it.
# 03[23:06] * Joins: miketaylr (miketaylr@206.217.92.186)
# 02[23:06] * Quits: miketaylr (miketaylr@206.217.92.186) (Quit: miketaylr)
# [23:06] <TabAtkins_> rossen: A lot of people thought it was related to a "wrap-mode" property.
# [23:07] <TabAtkins_> rossen: We also have Daniel's proposal that proposed a fairly different way to introduce exclusions.
# [23:07] <TabAtkins_> vhardy: I think your presentation is a convergence of the two proposals.
# [23:07] <TabAtkins_> rossen: Yeah, it got assimilated.
# [23:08] <TabAtkins_> vhardy: So I think the next thing is to work on a new ED.
# [23:08] <TabAtkins_> arno: And that's a wrap.
# [23:08] <stearns> perhaps the name for "ignore wrap" should follow whatever we end up with for "cancel-underline"
# [23:08] <TabAtkins_> /groan
# [23:08] <TabAtkins_> alexmog: I think we came to the conclusion that the name of the module should be "CSS3 Floats".
# [23:09] <TabAtkins_> alexmog: It eventually needs to be a bigger doc that describes much mor eof th eprocessing model,
# [23:09] <TabAtkins_> ... describing floats that don't overlap too.
# [23:11] <TabAtkins_> alexmog: [something about how extending 'float' might work]
# [23:12] <TabAtkins_> arno1: Would that be in CSS3 Floats or something else?
# [23:12] <TabAtkins_> vhardy: I think we should produce a first draft that covers what we know we want and have.
# [23:12] <TabAtkins_> vhardy: Then later figure out how we want to slice it with gcpm and other float-related things.
# [23:13] <TabAtkins_> arno1: My concern is that if this is float-related, we'd have to close on everything float-related to make this work.
# [23:13] <TabAtkins_> alexmog: I had the same concern. I think we can do Exclusions separately from Floats.
# [23:13] <TabAtkins_> alexmog: there is an issue with making Exclusions a Rec without having anything with floats.
# [23:14] <TabAtkins_> alexmog: But I think vincent has the right idea that we should write the draft now, and when we see it, it should be easy to tell what the right name is.
# [23:14] <TabAtkins_> dbaron: My general feeling about this draft is that it's very complicated to implement, and it's possible to write something much simpler to implement with most of the functionality.
# [23:14] <TabAtkins_> dbaron: I may want to look into going that way, but I haven't had a chance to do that yet.
# [23:15] <TabAtkins_> vhardy: If we produced a new draft that you could comment on, would that be ok?
# [23:15] <TabAtkins_> dbaron: I think at this point the best way forward for me is to produce a new proposal.
# [23:15] <TabAtkins_> florian: If we have proposals that look close enough, it's worth merging them. But we're early enough on right now that if there's something significantly different, it's worth exploring that separately.
# [23:16] <TabAtkins_> alexmog: I would be really glad if we could remove things from the draft and still meet the goals.
# [23:17] <TabAtkins_> florian: David, is what you have in mind the current draft with some things removed, or something totally different?
# [23:17] <TabAtkins_> dbaron: Similar things, but with a significantly different processing model.
# [23:18] <TabAtkins_> dbaron: I'm thinking that I want to separate the reordering aspects, and then not have the reordering implications within layout.
# [23:18] <TabAtkins_> dbaron: So if you need reordering, that's a separate process, and then layout is still one pass.
# [23:19] <TabAtkins_> dbaron: The part of this draft that scares me is the part that's not yet written.
# [23:19] <TabAtkins_> dbaron: It's hard to know I have comments on it before I read it. There may be a big gap somewhere that implies a big complicated chunk of processing model.
# [23:19] <TabAtkins_> dbaron: I've only thought about it for the last few days.
# [23:20] <TabAtkins_> vhardy: The processing model we've described is a bit different than what's currently in the ED.
# [23:20] <TabAtkins_> dbaron: I couldn't find much of a processing model.
# [23:20] <smfr> http://wiki.csswg.org/ideas/css3-floats-use-cases
# 02[23:20] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
# [23:20] <TabAtkins_> florian: Do you think that what you want fits within the shape of the existing proposal?
# [23:21] <arronei> http://wiki.csswg.org/ideas/css3-floats
# [23:21] <TabAtkins_> dbaron: There are some examples that I know don't fit, but they're incomplete examples right now.
# [23:21] <TabAtkins_> rossen: Have you checked out the wiki examples yet?
# [23:21] <TabAtkins_> dbaron: Not yet.
# [23:21] <TabAtkins_> rossen: If you could look, it would be great to have a review and see what's missing or whats overcomplicated.
# [23:22] <TabAtkins_> rossen: If you have an alternate proposal, I'd like to see if it solves these use-cases.
# 06[23:22] * glazou we will switch to next agenda item in 5 to 10 minutes max
# [23:22] <TabAtkins_> vhardy: We should take an action item to review this page.
# [23:23] <glazou> jdaggett: can you call in?
# 03[23:23] * Joins: szilles (chatzilla@72.254.61.95)
# [23:23] <TabAtkins_> Topic: Writing Modes
# [23:23] <glazou> jdaggett: can you hear us?
# 06[23:24] * mollydotcom taking a break find you all later!
# 02[23:24] * Quits: mollydotcom (mollyh@72.254.57.69) (Quit: mollydotcom)
# [23:24] <TabAtkins_> fantasai: I think there are several issues open right now.
# [23:24] <TabAtkins_> fantasai: One is the name of the property.
# [23:24] <TabAtkins_> fantasai: Second is the defualt orientation at a codepoint level.
# [23:24] <TabAtkins_> fantasai: The third is whether we're doing context-based resolution of punctuation, and if so, how?
# [23:25] <TabAtkins_> fantasai: The fourth is if we're giving additional controls at level 3 (beyond what you can currently do with text-orientation).
# [23:25] <TabAtkins_> jdaggett: Let's start iwth sylvain's issue.
# [23:25] <TabAtkins_> jdaggett: I think #3 and #4 are dependent on a concrete proposal for #2.
# [23:25] <TabAtkins_> szilles: Two more issues are Nat's comments on TCY
# 02[23:27] * Quits: karl (karlcow@128.30.54.58) (Client exited)
# [23:27] <TabAtkins_> szilles: I think you suggested separating the text-combine prop into one that did manual TCY and one that set up automatic TCY.
# [23:27] <TabAtkins_> szilles: They may want to be over different ranges.
# [23:27] <glazou> jdaggett: (we're in a big room, 30 people in the room, some of us are pretty far from the microphone… tell us if you don't hear us)
# [23:27] <TabAtkins_> jdaggett: Why do you need that distinction, Nat?
# [23:27] <dbaron> (TCY == Tate-chu-yoku)
# [23:27] <TabAtkins_> nat: Right now we have text-combine:horizontal, then a bunch of values for controlling the auto case, i guess.
# [23:28] <TabAtkins_> nat: Is that what we want? Just specify it on, and then specify the details (do letters, do digits, combine X many)
# [23:28] <TabAtkins_> nat: And then, if the lettes in the span meet that criteria, combine them?
# 02[23:28] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
# [23:28] <TabAtkins_> florian: One case was that, or a date, you don't wnat to have to add extra spans around the day and month and year, but rather just one aroudn th eyear.
# [23:29] <TabAtkins_> nat: The other issue I had was the defualt implied value.
# [23:29] <TabAtkins_> fantasai: The values are "none", "all" (tcy the whole span), and then various options that control what things are combined.
# [23:30] <jdaggett> nat's post: http://lists.w3.org/Archives/Public/www-style/2011Jul/0405.html
# [23:30] <dbaron> http://dev.w3.org/csswg/css3-writing-modes/#text-combine
# [23:30] <TabAtkins_> nat: I thought if I tried to implement this, it would be easier if I didin' thave to worry about having a state machine go through the text.
# [23:31] <TabAtkins_> fantasai: You can't combine, say "all" and "latin 4" - it's not syntactically valid.
# [23:31] <fantasai> ACTION fantasai: Add syntax examples
# 06[23:31] * trackbot noticed an ACTION. Trying to create it.
# 06[23:31] * RRSAgent records action 9
# [23:31] <trackbot> Created ACTION-357 - Add syntax examples [on Elika Etemad - due 2011-08-01].
# [23:31] <TabAtkins_> nat: i think some examples would help here.
# [23:31] <TabAtkins_> nat: So when it's not all, you can do auto TCY in any span.
# [23:32] <TabAtkins_> nat: A second point, why do you have, in the alphanumeric tolerance section, a "1.1em" figure. That seems arbitrary.
# [23:32] <TabAtkins_> fantasai: koji was talking with hyatt about that issue. hiragina apparently, if you ask for half-width glyphs, won't fit within 1em if you put them side-by-side.
# [23:32] <TabAtkins_> szilles: if that's true, why not just do it when they ask for it?
# [23:33] <TabAtkins_> fantasai: This is for whether you scale or not. This number is close enough that you usually won't have to scale.
# [23:33] <stearns> s/hiragina/hiragana
# [23:33] <TabAtkins_> kojiishi: The idea of scale is to compress glyphs so that they fit into 1em.
# [23:34] <TabAtkins_> kojiishi: But there are some fonts that get slightly gretaer than 1em when you set two half-width next to each other.
# [23:34] <TabAtkins_> kojiishi: So if two chars are much larger than 1em, authors would likely want to compress them. But if they're just a tiny bit over (maybe accidentally, like described here), you'd want to just leave them alone.
# [23:35] <TabAtkins_> nat: Okay. I think having the built-in tolerance is orthogonal to the scaling issue.
# [23:35] <dbaron> (not Hiragino? I think they were talking about the font)
# [23:35] <TabAtkins_> nat: If you're tolerant of the idea that you're using glyphs that odn't fit into 1em, you're probably okay with not scaling, so you should just say no scaling.
# 02[23:36] * Quits: nmccully (nmccully@72.254.59.155) (Quit: Colloquy for iPad - http://colloquy.mobi)
# [23:36] <TabAtkins_> kojiishi: Even if you do scale, though, you probably still don't want to scale if you're just very slightly over 1em.
# 03[23:36] * Joins: ChrisL (ChrisL@128.30.52.169)
# 03[23:36] * Joins: karl (karlcow@128.30.54.58)
# [23:37] <TabAtkins_> nat: But you're saying to scale it to 1.1em, not 1em.
# [23:37] <TabAtkins_> nat: You can have an "auto-scale" that has some tolerance in there.
# [23:37] <TabAtkins_> florian: Can we just have a scale with no tolerance, and let you add the tolerance in specifically?
# 02[23:37] * Quits: arronei_ (arronei@131.107.0.119) (Ping timeout)
# 03[23:38] * Joins: arronei_ (arronei@131.107.0.87)
# [23:38] <ChrisL> rrsagent, here
# [23:38] <RRSAgent> See http://www.w3.org/2011/07/25-css-irc#T21-34-01
# [23:38] <TabAtkins_> szilles: If they're images, you really notice the artifacts. If they're outlines you won't notice as much.
# [23:39] <TabAtkins_> szilles: Can we say something other than "scale"?
# [23:39] <TabAtkins_> fantasai: squish/compress/scale-x?
# [23:39] <bradk> condense, horizontal scaling
# [23:39] <TabAtkins_> fantasai: compress
# [23:40] <TabAtkins_> jdaggett: If someone wants this tolerance, they should be involved in the discussion.
# [23:40] <TabAtkins_> florian: I don't think it's useless, but it seems to be going a bit too far right now. Push it to level 4.
# [23:40] <dbaron> (above) Nat: condensed is bad because it implies a different font selection
# [23:41] <TabAtkins_> fantasai: The tolerance is used in the scaling (removed now), and also in the "used glyphs" section.
# [23:41] <TabAtkins_> fantasai: Which says to use half/third-width glyphs if available; if not available, scale.
# [23:41] <bradk> Adobe calls it "horizontal scaling" in their programs, IIRC, FWIW
# [23:41] <TabAtkins_> fantasai: What might happen is that you say you want to use third-width glyphs, but it ends up being rendered with a font without third-width glyphs.
# [23:42] <TabAtkins_> fantasai: The default action, then, should be to go ahead and scale, as that's minimally invasive to the rest of the page design.
# [23:42] <TabAtkins_> nat: Is that how it's supposed to work? I didn't get the idea that things had fallback.
# [23:42] <TabAtkins_> fantasai: You can combine "scale" and "use-glyphs".
# [23:43] <TabAtkins_> szilles: Why wouldn't you scale to 1em?
# [23:43] <TabAtkins_> florian: You'd scale to 1em, but you wouldn't scal ei fyou're "close enough" to 1em.
# 03[23:45] * Joins: szilles (chatzilla@72.254.61.95)
# [23:45] <TabAtkins_> szilles: [an example with "1.3" and TCY]
# [23:45] <bradk> Is it tragic to allow the glyphs tooverflow if they are slightly too wide?
# [23:45] <TabAtkins_> jdaggett: In the original document this was based, there's an example for that.
# [23:45] <TabAtkins_> szilles: I know that stuff like TCY'd "1.357" is actually done.
# [23:45] <jdaggett> original document == jis 4051 spec
# [23:45] <TabAtkins_> nat: I think we should just have a "use glyphs" option, and if glyphs don't exist, just do fallback.
# [23:46] <TabAtkins_> fantasai: We can say that if you find the right glyphs, just don't worry about compressing. Assume that the glyphs are the right width.
# [23:47] <TabAtkins_> kojiishi: If the first font has the glyphs (slightly off the right width) but the second font doesn't, the first font would grab the glyphs and be slightly off-width, while the second would synthesize and be exactly right.
# [23:47] <TabAtkins_> nat: I think you're far off in edge-cases here.
# [23:48] <TabAtkins_> szilles: I think it's pretty simple. If it has half-width glyphs, it has half-width glyphs. Just use them.
# 02[23:48] * Quits: szilles (chatzilla@72.254.61.95) (Ping timeout)
# [23:48] <TabAtkins_> nat: Why are we doing anything if the half-width glyphs dont' exist?
# [23:48] <TabAtkins_> szilles: CSS generally tries to best capture the authors' intent.
# 02[23:49] * Quits: konaya (konaya@83.251.16.72) (Ping timeout)
# [23:49] <TabAtkins_> kojiishi: If the author says "digits 3", and the half-widths are slightly more than half an em, you'll get slightly more than 1em-width TCY.
# [23:50] <TabAtkins_> fantasai: Is it possible to know if the font has third-width glyphs?
# [23:50] <TabAtkins_> nat: There's a feature in OT that the UA can query.
# [23:50] <TabAtkins_> jdaggett: The problem with these features is that for different features, different sets of glyphs are available.
# [23:51] <TabAtkins_> jdaggett: For third/fourth-width, often only digits are available.
# 02[23:51] * Quits: vhardy (vhardy@72.254.57.220) (Ping timeout)
# [23:51] <TabAtkins_> szilles: What about numeric punctuation (periods and commas)?
# [23:51] <TabAtkins_> nat: Generally not. Most only have half-width punctuation.
# [23:51] <TabAtkins_> szilles: So you could do years and integers, but not decimal numbers.
# [23:51] <TabAtkins_> nat: Right.
# [23:52] <TabAtkins_> szilles: I think we just need a clear processing model of whe nthings are decided.
# [23:52] <TabAtkins_> szilles: I don't think we want to say "let's make as tring, and then try to compress it". I think you want to first check for half-width glyphs or whatever, and then build out of what exists.
# [23:53] <TabAtkins_> szilles: So I want a clear statement of what you're looking for from the font, and underwhat conditions.
# [23:53] <TabAtkins_> fantasai: So what I'm hearing is that we should use the correct glyphs if the font has them, otherwise synthesize.
# [23:54] <TabAtkins_> fantasai: So if I'm doing "122", if the font has third-width glyphs, I use them. If it doesn't, I scale the "1" and "2" glyphs and then combine them, rather than making "122" and then scaling.
# [23:55] <TabAtkins_> florian: Also, the current spec specifies just that they should fit into 1em, whihc allows cherry-picking half and quarter-width glyphs and combining them, which is not what you want.
# [23:55] <bradk> Doesn't kerning and tracking affect if two 1/2-width glyphs fit into one em?
# [23:57] <TabAtkins_> fantasai: We can tell if the font has a "third-width" feature, but we don't know if individual characters have third-width glyphs. So if I wanted "IBM" in third-width glyphs, I'd request those glyphs from the font as third-width glyphs, but I may or may not actually get third-width glyphs back.
# 06[23:57] * sylvaing saying 'third-width glyph' repeatedly could be a sobriety test
# 06[23:57] * jdaggett heh...
# [23:57] <TabAtkins_> fantasai: So once I get them back, if they're wider than 1/3em, I need to scaled them to 1/3 em.
# [23:58] <TabAtkins_> fantasai: I think we can make an exception that, for half-width glyphs, don't measure and just use what you get. You may get proportional, which may be close enough.
# [23:58] <TabAtkins_> bradk: Can kerning affect this?
# [23:58] <TabAtkins_> nat: You don't kern monospace CJK fonts.
# [23:59] <TabAtkins_> jdaggett: In theory, it's an issue; in practice, you don't ever kern these types of fonts. I don't think we need to worry about it.
# [23:59] <jdaggett> ... you don't generally kern these *glyphs*
# [23:59] <jdaggett> i.e. third-width glyphs
# Session Close: Tue Jul 26 00:00:00 2011

The end :)