#css IRC Log

Index

IRC Log for 2011-10-30

Timestamps are in PDT.

[00:04] * heycam is now known as heycam|away

[00:19] * Ms2ger has joined #css

[01:15] * plinss Quit (Quit: plinss)

[04:07] * jdaggett Quit (Ping timeout)

[04:14] * jdaggett has joined #css

[06:11] * casper has joined #css

[06:12] * casper has left #css

[07:58] * arronei_ has joined #css

[08:33] * arronei_ Quit (Ping timeout)

[08:49] * TabAtkins_ has joined #css

[08:50] * arno has joined #css

[09:08] * plinss has joined #css

[09:08] * dbaron has joined #css

[09:09] <arno> ping

[09:09] <Ms2ger> Pong?

[09:10] <arno> Whoo-hoo

[09:10] * sylvaing has joined #css

[09:10] * JohnJansen has joined #css

[09:10] <arno> ScribeNick arno

[09:10] * stearns has joined #css

[09:10] * RRSAgent has joined #css

[09:10] <RRSAgent> logging to http://www.w3.org/2011/10/30-css-irc

[09:10] * szilles has joined #css

[09:10] * Zakim has joined #css

[09:11] <Ms2ger> ScribeNick arno

[09:11] * TabAtkins_ Quit (Quit: leaving)

[09:11] * TabAtkins_ has joined #css

[09:11] * glazou has joined #css

[09:12] <Ms2ger> RRSAgent, make logs public

[09:12] <RRSAgent> I have made the request, Ms2ger

[09:12] <arno> vincent: 3d interest group requested to meet w/ us

[09:12] <arno> not on the agenda?

[09:12] <Bert> The snow in the NE has made one victim: Florian not sure he can make today (see e-mail I just forwarded)

[09:12] <arno> :(

[09:13] * mollydotcom has joined #css

[09:13] <arno> Daniel: will add to agenda for Tuesday morning

[09:13] * vhardy has joined #css

[09:13] <arno> Tab: variables and hierarchy

[09:14] <arno> (nesting selectors)

[09:14] * arronei_ has joined #css

[09:14] <arno> Tab: I have a proposed spec and would like sign off on "yes, we're going to do these"

[09:14] <arno> Tab: asking on behalf of shane and luke.

[09:14] <arno> Daniel: adding to agenda, but gut feeling: "you are going too fast"

[09:14] * shepazu has joined #css

[09:15] * kojiishi has joined #css

[09:15] * jarek has joined #css

[09:16] <arno> Peter: I have a joint meeting w/ web apps at 11am

[09:16] <arno> ??: discussion on CSS OM on tuesday morning would require david and tab, will they be there?

[09:16] <arno> tab: yes, there's a conflict w/ a fx meeting

[09:17] <arno> peter: no, fx meeting is on thursday

[09:17] <arno> daniel: please update wiki accordingly

[09:17] <arno> daniel: I did the schedule based on interest and joint meetings, it wasn't an easy task.

[09:18] <arno> daniel: any other extra items?

[09:18] <arno> everyone: no.

[09:18] * jdaggett_ has joined #css

[09:18] <dbaron> Should we do a brief round of introductions?

[09:18] <arno> daniel: first, a request from sylvain: "how should wg handle issues?"

[09:18] * Rossen has joined #css

[09:18] <arno> daniel: yes, let's start with intros

[09:20] <dbaron> Luke McPherson (Google), Shane Stevens (Google), Steve Zilles (Adobe), Molly Holzschlag (Invited Expert), Mark Silverman (Adobe), Deepa Subramanian (Adobe), Bert Bos (W3C), Alan Stearns (Adobe), Arno Gourdol (Adobe), Brad Kemper (Invited Expert), Tab Atkins (Google), Elika Etemad (Mozilla), Daniel Glazman (Disruptive Innovations), Koji Ishii (Invited Expert), John Daggett (Mozilla)

[09:21] <dbaron> David Baron (Mozilla), Arron Eicholz (Microsoft), Sylvain Galineau (Microsoft), John Jansen (Microsoft), H��kon Lie (Opera), Peter Linss (HP), Chris Lilley (W3C), Vincent Hardy (Adobe), Rossen Atanassov (Microsoft)

[09:21] <dbaron> (hopefully I kept to under 10 spelling mistakes)

[09:21] <arno> daniel: back to first issue

[09:21] * ChrisL has joined #css

[09:21] <arno> sylvain: we implement a spectrum of specs at different levels

[09:22] * shans has joined #css

[09:22] <arno> sylvain: when something is not Last Call, questions get asked

[09:22] <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Apr/0359.html

[09:22] <arno> the question above was asked, but not answered

[09:23] <arno> "how much normative info is laying around in the mailing list that's not incorporated"

[09:23] <sylvaing> https://docs.google.com/spreadsheet/ccc?key=0Akz3Ts2PEQF2dEdQMEtSMXFFMWJyYkVpdUtrWDB4Z3c&hl=en_US#gid=1

[09:23] <arno> sylvain: I replied "I don't know" and people freaked out.. :)

[09:23] <arno> sylvain: did an analysis of discussion threads, and it turns out that many did not got concluded and getting it back into the spec

[09:24] <arno> sylvain: we did that with css 2.1 where fantasai went through 10 years of archives to make sure that everything was taken into account

[09:24] <arno> sylvain: we shouldn't have to do this. we should have a better organized way of tracking issues.

[09:25] <arno> dagett: we already have a tracker, no?

[09:25] * TabAtkins_ Quit (Ping timeout)

[09:25] <arno> fantasai: but the editor does not keep up with the feedback

[09:25] * TabAtkins_ has joined #css

[09:25] <arno> sylvain: difficult to resolve differences between implementations...

[09:25] * ChrisL saw dino yesterday, wonders whether he will be here later

[09:25] <arno> sylvain: when we get to module, we should have a link of issues

[09:25] <fantasai> dbaron: Of all the specs I've implemented, CSS Animations has been in the worst state

[09:26] <arno> vincent: would be nice to have one common way. i liked the suggestion to have an annotation in the spec that incorporates a link to the wiki

[09:26] <arno> vincent: not a big fan of the wiki because it's a bit too fragile, would like better method

[09:27] <arno> daniel: it's a human process, the editor still has to do the right thing

[09:27] <arno> fantasai: we have multiple ways

[09:27] <dbaron> (I think there are also a bunch of animations issue that I didn't even bother to bring up on the mailing list.)

[09:27] * bradk has joined #css

[09:27] <arno> fantasai: different editors like different systems

[09:27] <arno> fantasai: i use to track issues in a plain text file, and that worked great for me

[09:28] <arno> vincent: i like steve's suggestion to incorporate it in the spec, because as you read the spec you can see where there are issues

[09:28] <arno> howcome: i think email works pretty well

[09:28] <fantasai> fantasai: The problem is that if the editor is not tracking issues, the issues aren't being tracked. Period.

[09:29] <arno> sylvain: when it come to disposition of comments, you shouldn't have to go through email archives

[09:29] * szilles Quit (Ping timeout)

[09:29] <arno> howcome: it's not a lack of mechanical solution, the problem is the editor needs to do the tracking

[09:29] <arno> dbaron: i like the idea of having it in the spec

[09:30] <fantasai> dbaron: Not nessarily as the only place to track it but as a place to track it

[09:30] <arno> dbaron: but that doesn't mean there shouldn't be some other way of tracking it

[09:30] <arno> steve: we may need a mechanism to collect in a list all the issues and what their status is, and we need a way to track what the issue actually is (email, etc.. anything with a URL)

[09:31] <fantasai> Steve: First issue I see is showing in the spec, at that place, that there is an issue there. Second we need some place that collects all the issues and tells you the status of the issues. Third is we need a way to document what the issue actually is

[09:31] <arno> steve: putting open issues in the document is pretty important, as it allows people to do something about it. but we probably to have somewhere else also to keep track of all issues

[09:32] <arno> chris: it's useful to be able to track issues over a long period of time, with a tracker or something else

[09:33] <arno> jdaggett: we don't need to track all issues, especially at the very beginning of a spec, but bug tracking does make sense when you get to the end

[09:33] <fantasai> jdaggett++

[09:33] <arno> fantasai: i agree with this, that's what i've done

[09:33] <arno> fantasai: but the editor still needs to response to feedback. if it doesn't happen, it doesn't matter what tracking system we have

[09:34] <arno> fantasai: specs currently don't link to issues

[09:34] <arno> (in general, a few do)

[09:35] <arno> fantasai: it's unfair to expect that others will do the work of identifying issues that need to be tracked

[09:35] * jarek Quit (Quit: jarek)

[09:35] <JohnJansen> note: this is not just a problem with one spec, but is a more general issue

[09:35] <arno> daggett: how to we deal w/ feature request which the editor think should be dealt with later?

[09:36] <arno> fantasai: i dump it into tracker

[09:36] <arno> alan: there's also some wiki pages that include level 4 ideas

[09:36] <arno> tantek: i like wiki pages better, because it's easier to aggregate requests together, "since the future is fuzzier, a fuzzier mechanism helps"

[09:37] * tantek has joined #css

[09:37] <arno> daniel: any concrete proposal?

[09:37] <tantek> is this on? 1 10 11 check

[09:37] <arno> sylvain: when dino is around we should discuss w/ him

[09:37] <Ms2ger> tantek, it is :)

[09:38] <arno> tab: should we introduce an issue tracker so that if you file an issue via email you also have to file it into the tracker?

[09:38] <arno> tantek: it depends on where you constraint is. If it's editor's time, that's going to be the bottleneck

[09:38] <Ms2ger> Might as well go to filing directly in bugzilla, then

[09:39] <arno> dbaron: if there are multiple requirements to track issues (tracker, email, bugzilla, etc���) some people might use the wrong mechanism and issues may end up dropped on the floor

[09:39] <arno> tantek: it's already in the spec: send a message to wwwstyle

[09:39] <JohnJansen> ms2ger, the argument against that is that when a spec is young, bugzilla is too much overhead

[09:40] <arno> tantek: i think it's up to the editor to track the messages to wwwstyle and track it

[09:40] * Ms2ger doesn't care much about young specs

[09:41] <arno> tantek: however the editor track the issue, it should be public and others should be able to add issues

[09:41] <arno> moly: what about using some tools like stackoverflow, etc��� to track?

[09:41] <arno> tantek: there's only a handful of mechanism other than bugzilla, tracker, wiki

[09:41] <arno> fantasai: i've used CVS/plaintext

[09:41] <arno> tantek: someone could add to it?

[09:42] <arno> fantasai: yes, a bit more cumbersome, though

[09:42] <arno> chris: as long as it's publicly available

[09:42] <arno> fantasai: yes, a local text file, spreadsheet, etc��� would not work

[09:42] <glazou> s/moly/molly

[09:43] <arno> molly: each editor has process, but we need to communicate where the info is. the disparate methodology is creating a disparate problem in which we're not able to have this coalesced

[09:43] <tantek> molly is talking about a discovery problem ("where are the issues?") rather than a diversity of mechanisms problem.

[09:44] <tantek> what Steve Zilles said

[09:44] <arno> steve: as part of the status section of a spec, we should include where the issues are being tracked, so that you can know where the editor tracks issues

[09:44] <tantek> one single place to track where the issues are, not one single issue tracker

[09:44] <arno> steve: i.e. that's a per spec issue, not an issue for all specs, right?

[09:44] <arno> steve: i propose we have, for each spec, a clear indication of where the issues are tracked

[09:44] <tantek> fantasai - you said there are some specs that have links from their header to their issues?

[09:45] <tantek> examples?

[09:45] <Ms2ger> HTML has that

[09:45] <tantek> i.e.. which spec(s)

[09:45] <fantasai> tantek, http://www.w3.org/TR/css3-background/

[09:45] <dbaron> For http://dev.w3.org/csswg/css3-conditional/ I've just been tracking all the issues in <p class=issue>s in the editor's draft.

[09:46] <arno> steve: if there's a clear list of issues, people could find out what the status is and have the group (or the chair) do the policing if necessary

[09:46] <tantek> so none of those have links from the header

[09:46] <tantek> proposal: just as each spec must have a link to the editor's draft, right underneath that, it should link to where it tracks issues

[09:46] <arno> fantasai: so, each spec must have a clear, publicly accessible way of tracking issues

[09:46] <arno> fantasai: each module

[09:47] <Ms2ger> And note that nobody reads the SotD :)

[09:47] <fantasai> RESOLVED: Each module must have one publicly-accessible, CSSWG-editable way of tracking issues.

[09:47] <sylvaing> http://dev.w3.org/csswg/css3-positioning/

[09:47] <arno> tantek: the examples above are burried in the spec

[09:48] <fantasai> RESOLVED: Add link to issues list from spec header

[09:48] <arno> daniel: who's in favor of the RESOLVED issue above

[09:48] <arno> ?

[09:49] <arno> daniel: (from show of hands): OK, resolved

[09:49] <arno> daniel: i'm not satisfied with a different system for each spec

[09:49] <arno> daniel: you have to adapt yourself for each one, and it's difficult when you're tracking 30 specs

[09:50] <arno> steve: building o the idea that there are 4 systems in use right now, could we restrict the list of acceptable issue tracking system

[09:50] <arno> daniel: that's a good compromise

[09:50] <arno> steve: we have 3: wiki, tracker and bugzill

[09:50] <Ms2ger> And plaintext in CVS

[09:51] <arno> dbaron: and there's another one: track everything in the draft

[09:51] <arno> alan/tantek: do you keep a log of the resolved issues

[09:52] <arno> dbaron: no, the CVS log is the log...

[09:52] <arno> daniel: <squirms>

[09:52] <arno> tantek: so you're saying that twitter is the log, then...

[09:52] <tantek> here's an example of a spec which has links in the header to both editor's draft and issues list: http://dev.w3.org/csswg/css3-ui/

[09:52] <arno> tab: i use the same system as david, and it works for me

[09:52] <arno> alexm: with multiple editors it can get complicated

[09:53] <arno> fantasai: i use different systems, depending on the lifecycle of the spec.

[09:53] <arno> fantasai: when we need to resolve a bunch of issues as a group, i make a list and use it in tracker for easier resolution

[09:53] * plinss Quit (Client exited)

[09:53] * plinss has joined #css

[09:53] <arno> fantasai: at the end, i use a plaintext file

[09:54] <arno> daniel: let's close on steve's proposal

[09:54] <tantek> I use the wiki to track issues, and have been putting links from the document like: "Related open issue: 1. " (where "1." is hyperlinked to the issue)

[09:54] <arno> daniel: when using inline issue tracking, still indicate that in the header

[09:55] * plinss__ has joined #css

[09:55] <arno> fantasai: we have the WD and the Editor's draft.

[09:56] <arno> fantasai: they may have separate issues list

[09:56] <arno> vincent: the current list of issues is related to the ED, not the WD

[09:56] <arno> fantasai: it's snapshotted if you track it inline, but otherwise the link to a separate issue tracker may get out of sync

[09:57] <arno> fantasai: maybe only have the link on the ED

[09:57] <arno> steve: no, too many people get to the WD than the ED, and then you will end up in the wrong issue list

[09:57] <arno> molly: agree, we need to coalesce, rather than fragment

[09:57] * plinss Quit (Ping timeout)

[09:57] * plinss__ is now known as plinss

[09:58] <arno> vincent: if you do inline issue tracking, that resolves it

[09:58] <arno> fantasai: could be resolved if the link to issues in the WD point to the ED issues list

[09:59] * alexmog has joined #css

[09:59] <arno> molly: the ED is the up to date version of issues are tracked. so we could just have a link that points to the ED to find out what the current issues are

[10:00] <arno> tantek: maybe we need a warning in the WD that makes it clear it's out of date...

[10:00] <arno> chris: when it's published as a TR it should not include the list of issues anymore

[10:01] <Ms2ger> Why not?

[10:01] * alexmog has left #css

[10:01] <arno> daniel: a TR has a date, so having issues there would be appropriate to reflect what the issues were for *that* version of the document

[10:02] <arno> daniel: i don't know how to tweet this

[10:02] <ChrisL> @ms2ger I was arguing against a static,out of date copy of the state of issues in a /TR published draft, if the editors draft has a more up to date list

[10:02] <arno> daniel: issue trackers used: bugzilla, wiki, tracker, inline

[10:03] <arno> RESOLVED: use one of bugzilla, wiki, tracker or inline to track issues.

[10:04] <arno> fantasai: it was really hard with CSS 2.1

[10:04] <arno> tantek: let's not have big specs like that anymore

[10:04] <tantek> :)

[10:04] * alexmog- has joined #css

[10:05] <arno> fantasai: how do we track 300 issues on one wiki page? doesn't seem to scale

[10:05] <tantek> we can cross that bridge when we reach it

[10:05] <arno> johnjansen: that's why i like bugzilla better to do the tracking

[10:06] <arno> vincent: maybe it depends on the lifecycle, later on in the spec's life, using bugzilla may be better

[10:07] <arno> fantasai: not asking for a WG resolution, but sharing my experience

[10:07] <arno> steve: we have these discussions where we agree on a particular strategy, recorded in the minute, and then it slowly gets out of memory as time goes on

[10:07] <arno> steve: could we have this recorded in the wiki or somewhere

[10:07] <arno> daniel: i agree that best practices are needed

[10:08] <tantek> here: http://wiki.csswg.org/spec#specification-editing

[10:08] <arno> daniel: what should happen if an editor doesn't track issues?

[10:08] <arno> daniel: spanking the editor?

[10:08] <arno> steve: the chair has multiple paths: talk to the editor, talk to the AC rep, raise it to the group and replace the editor

[10:09] <arno> tantek: after step 1 (talking to the editor), you could also suggest adding a co-editor

[10:09] <arno> tantek: or even assign a co-editor

[10:09] <arno> tantek: that's worked in the past

[10:09] <arno> daniel: you need to know there's an issue with the issue tracking

[10:10] <arno> tantek: if the ED gets more than 1 year out of date...

[10:10] <arno> tantek: there are past signals and procedure that seem to have fixed it

[10:10] <arno> tab: re: issue tracking and bugzilla, there's only 5 components in it right now. could we add all components?

[10:11] <arno> johnjansen: yeah, how do we do that

[10:11] <arno> solution: mail mike smith (or bert) to ask the components to be added in bugzilla

[10:12] <arno> sylvain: we have 1 hour tomorrow for animation

[10:12] <arno> sylvain: i have some technical discussion that needs to hapen

[10:13] <arno> bert: maybe that's a topic for the plenary

[10:13] <arno> tantek: there are several issue re: specs

[10:13] <arno> tantek: sounds like you want to lead a discussion

[10:13] <arno> bert: no, not really...

[10:13] <arno> daniel: anything else about spec editing/tracking?

[10:14] <arno> plinns: that makes me want to build a tool. would people use it?

[10:14] <arno> tantek: might be worth looking at hixie's tool'

[10:14] <arno> tab: it's easy to deal with

[10:15] <arno> daniel: yes, select all and resolve as invalid :)

[10:15] * Bert Tracker itself came out of Dean Jackson feeling like Peter feels now. :-)

[10:15] <arno> fantasai: you could improve tracker, most of its problems are UI issues

[10:15] <arno> fantasai: we have so many systems because all of them kinda suck

[10:15] <arno> tantek: who does the IT for bugzilla/tracker?

[10:16] <arno> chris: it's the systems team

[10:16] <tantek> URL?

[10:16] * tantek wouldn't mind seeing tracker's source/deployment moving to github.

[10:16] <arno> daniel: let's close this agenda item and move on the next one

[10:16] <arno> daniel: let's move to css regions

[10:18] <arno> vincent: <showing slides>

[10:18] <arno> my.adobe.acrobat.com/silverman

[10:18] <arno> vincent: css regions (alex and vincent)

[10:18] <arno> css exlcusions (rossen and vincent)

[10:19] <arno> css fragmentations (eliak and rossen)

[10:19] <arno> vincent: ED after the tokyo meeting

[10:19] * howcome has joined #css

[10:19] <dbaron> Is positioned floats part of one of those three parts?

[10:19] <arno> vincent: most issues have been worked out, except the ones to review today

[10:19] <arno> vincent: 2 implementations in progress (IE and WebKit)

[10:20] <arno> vincent: would like to resolve some issues today and publish a new WD

[10:20] <arno> vincent: positioned floats is another module (not the three parts above)

[10:20] <dbaron> vincent: positioned floats is a 4th part

[10:21] * szilles has joined #css

[10:21] * sylvaing Skype access to the meeting available at w3c-csswg

[10:21] <arno> vincent: issue tracked in the spec, and the wiki has a list of resolved issues and no longer in the spec

[10:21] <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-19special-behavior-of-iframe-flow

[10:23] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-19special-behavior-of-iframe-flow

[10:23] <arno> howcome: i have concerns with the current regions approach

[10:23] <arno> howcome: we need them, but it doesn't discuss two issues that seem important: pagination and auto-generation of boxes

[10:23] <arno> max: currently done by script, using OM

[10:24] <arno> alan: to have the entire content displayed, you need a page template mechanism

[10:24] <arno> howcome: multicol is already doing auto-generation

[10:24] <arno> alex: we use at multiple use cases, and there are so many cases that you need script anyway

[10:25] <arno> howcome: i'd love to see the use cases.

[10:25] <arno> alex: for some use cases you need script, but maybe we can have a subset that does auto-generation

[10:25] <stearns> you can display the entire content (by having the last region overflow)

[10:26] <arno> steve: you are correct that some of the problem have do with pages. you can't know ahead of time how many pages you need. rather than picking up on region, it seems like this is something that should be handled by pages instead

[10:27] <fantasai> didn't Bert have a proposal in css3-template that solved this kind of problem?

[10:27] <arno> steve: some way of having master pages that can be combined through an auto-generation mechanism to do this

[10:27] <Bert> q+

[10:27] * Zakim sees Bert on the speaker queue

[10:27] <arno> steve: multicol seems too weak to deal with this

[10:28] <arno> howcome: i'd like to approach this by looking at use cases

[10:29] <arno> vincent: we looked at what's needed for magazine, but regions are one the building blocks that's needed. pagination is useful as well.

[10:30] <arno> vincent: there's a lot that can be done with regions, and we'd like to work on pagination as well

[10:30] <arno> vincent: regions was a common denominator across all the use cases we looked at

[10:31] <arno> howcome: i think two things regions must address are pagination and auto-generation

[10:31] <arno> steve: i'm confused: neither of these things have to do with pages, pages is a separate module

[10:31] <arno> howcome: i think we're using the terms differently

[10:32] * alexmog- proposes action for Hakon and Alex to propose a mechanizm for autogeneration

[10:32] <fantasai> howcome: If I take a stylesheet from one document and apply it to another that has more content, I should be able to *see the content*

[10:32] <arno> howcome: when you apply a style sheet to another document, you should still be able to see the content

[10:33] <arno> steve: regions doesn't resolve all problems. it's one building block, that can be chained with others.

[10:34] <arno> steve: the intent was that the auto-generation would be done over a collection of regions, called a page, that would get auto-generated. you're correct this is not correctly specified, but it makes more sense to deal with it in the context of pages, rather than regions

[10:34] <arno> howcome: i dont think we fundamentally disagree. we both want to do regions. i think it's possible to latch onto the multicol model with does auto-generation and paginations

[10:35] <arno> howcome: if you can have selectors for each column, and column on each page, maybe layout-wise it's as powerful, it solves the use cases but gives you pagination and auto-generation

[10:36] <dbaron> ack Bert

[10:36] * Zakim sees no one on the speaker queue

[10:36] <arno> bert: I did some work past few days to integrate regions spec in template layout

[10:37] <arno> bert: for repeating, not completely worked out, but should possible to put a template in a column.

[10:37] <Bert> -> https://www.w3.org/Style/Group/css3-src/css3-layout/Overview.html#repeating-templates note about combining columns and regions (i.e., templates)

[10:37] <arno> bert: all w/ same mechanism, you only need a selector to select a column and a column in a page

[10:38] <arno> howcome: can we see the use cases?

[10:39] <arno> daniel: have them in the spec

[10:39] <Bert> action bert: move template layout to dev.w3.org

[10:39] * trackbot noticed an ACTION. Trying to create it.

[10:39] * RRSAgent records action 1

[10:39] <trackbot> Created ACTION-374 - Move template layout to dev.w3.org [on Bert Bos - due 2011-11-06].

[10:39] <arno> vincent: we don't have use cases in specs in general

[10:39] <arno> daniel: maybe in an appendix

[10:39] <fantasai> fantasai: Can we have this draft on dev.w3.org? Bert: It's convenient to have it internal. fantasai: It's more convenient for us to have it public. Bert: I'd rather publish a WD. fantasai: Yes, let's do both. :)

[10:40] <Ms2ger> fantasai++

[10:40] <arno> molly: there's a convention in publishing, if it's a screenshot it's not considered proprietary

[10:40] * Bert thanks fantasai for recording that.

[10:40] * fantasai welcome

[10:40] * tantek agrees with daniel

[10:41] <arno> howcome: we need to see the use cases

[10:41] <arno> howcome: we need to support auto-generation

[10:41] <tantek> would be useful to capture/see the use-cases in the spec that drove the design. in an Appendix is fine.

[10:41] <arno> howcome: we need pagination

[10:41] <fantasai> hwocome^: Shouldn't have to resort to scripting.

[10:41] * sylvaing dreams of specs with uses-cases appendices

[10:42] <arno> vincent: agree with it, but our take was that pagination and auto-generation were not going to be covered in regions spec

[10:42] <arno> steve: shouldn't it be in the paginated media module?

[10:42] <arno> howcome: that would be fine, but the specs should evolve at the same time

[10:43] <arno> alex: i think you're trying to do a simple page flipper, it would be great to support that

[10:44] <fantasai> howcome: My use case is to have a fancy first page of an article, and then second and subsequent pages flow as multi-col

[10:44] <arno> vincent: multicol serves multiple purpose, it's both a template and a way to paginate

[10:44] <fantasai> vincent: That's issue 12, whether to have multicol as regions

[10:45] <arno> alex: i think we need to talk about it and decide which spec it belongs to

[10:45] <fantasai> vincent: auto-generation goes much further than just that

[10:45] <arno> steve: i think we should record the issue that howcome is raising

[10:46] <arno> alex: i think pagination/fragmentation is a fundamental feature of layout. the region spec is about how to provide this boundary

[10:47] <arno> howcome: i just want to know how to print documents with regions on them

[10:47] <arno> daniel: we have 15min remaining. let's move one.

[10:47] <arno> s/one/on/

[10:47] <glazou> http://wiki.csswg.org/spec/css3-regions?&#issue-19special-behavior-of-iframe-flow

[10:47] <arno> vincent: do we want multicol elements to be regions or not

[10:48] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-12should-we-allow-multi-column-elements-to-be-regions

[10:48] <arno> fantasai: i'm in favor

[10:49] <arno> alex: i like that idea too, add very little complexity to implementation

[10:50] <arno> alex: if there's a region and you set column = 2, you get a region with two columns

[10:50] <ChrisL> rrsagent, here

[10:50] <RRSAgent> See http://www.w3.org/2011/10/30-css-irc#T17-50-04

[10:50] <tantek> <aside> just stubbed http://wiki.csswg.org/spec/issue-tracking - please review and feel free to improve </aside>

[10:50] <arno> rossen: overflow would be interesting in that case

[10:51] <arno> rossen: this would lead to introducing fragmentation

[10:51] <arno> steve: seems like the AI is "how should it be done or why it shouldn't be done"

[10:52] * szilles Quit (Ping timeout)

[10:52] <arno> jdaggett: is the question something with both multi-column and region, what happens?

[10:52] <arno> jdaggett: where does the spec forbid it?

[10:53] <arno> section 4.2

[10:53] <tantek> <aside> also lurking in #tpac as a general back-channel for this week </aside.

[10:53] <vhardy> http://dev.w3.org/csswg/css3-regions/#the-flow-from-property

[10:53] <arno> howcome: multicol only changes how things are laid out inside the element

[10:54] <arno> howcome: i don't understand how multicol would be any harder...

[10:54] <arno> alex: some work needs to happen, because overflow behavior is different

[10:55] <arno> howcome: i don't understand why we need a proposal

[10:55] <arno> daniel: we need a proposal, alex/vincent come back to the group when you have one

[10:55] <arno> action vincent: bring a proposal for interaction between multicol and region

[10:55] * trackbot noticed an ACTION. Trying to create it.

[10:55] * RRSAgent records action 2

[10:55] <trackbot> Created ACTION-375 - Bring a proposal for interaction between multicol and region [on Vincent Hardy - due 2011-11-06].

[10:55] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-19special-behavior-of-iframe-flow

[10:56] <arno> alex: issue 19: special behavior of iframe.

[10:56] <arno> alex: two implementations (IE and webkit) have different behavior. need to reconcile.

[10:56] * shepazu Quit (Quit: shepazu)

[10:57] <arno> alex: need some sort of indirection mechanism

[10:57] <arno> fantasai: how does it related to the seamless attributes in HTML5

[10:57] <arno> ??: seems like allowing flowing of content is not specific to regions

[10:57] <fantasai> s/??/hober/

[10:58] <fantasai> alex: seamless also allows transparency wrt scripting and style rules

[10:58] <arno> alex: once the flow is picked up from iframe, not relevant to iframe either. maybe have a link element referring to a url with the external flow

[10:58] <arno> alex: i would like advice

[10:58] <arno> tab: i am scared of this, esp. re: security

[10:59] <arno> tab: this would allow arbitrary interaction with layout

[10:59] <arno> alex: currently restricted to same origin

[10:59] <arno> fantasai: seems like the switch should be at the HTML level

[10:59] <dbaron> hober: certainly not at the regions level

[11:00] <arno> tab: i don't think we should tie a "transclusion" property with regions

[11:00] <arno> molly: i think it should be in html5

[11:00] <dbaron> http://dev.w3.org/html5/spec/the-iframe-element.html#attr-iframe-seamless

[11:00] <Bert> (Sounds like this already exists: XInclude)

[11:00] <arno> tab: we should make a separate spec for it

[11:01] <fantasai> s/it/transclusions/

[11:01] <arno> steve: you can put the iframe in the flow, but not the content of the iframe

[11:01] <arno> tab: the content of iframes are a black box to css

[11:02] <arno> johnjansen: you get the security protection by using iframe

[11:02] <fantasai> tab: the security concern is in the other direction

[11:02] <arno> rossen: the core of the problem is do we allow external content to flow through regions? if we do, we need a way

[11:02] <arno> daniel: what's the use case

[11:03] <arno> rossen: digital publishing that pick up articles from various sources, and aggregates them

[11:03] <arno> daniel: seems like it could be a feature we add later

[11:03] <arno> dbarron: doesn't seem specific to Regions

[11:03] <fantasai> s/dbarron/dbaron/

[11:03] <arno> molly: or CSS at all. seems like HTML

[11:04] <arno> alex: looks like we don't have a proposal, and that's what IE is going to ship

[11:04] <arno> hober: it could be anywhere it's appropriate

[11:04] <Bert> (B.t.w., https://www.w3.org/Style/Group/css3-src/css3-box/Overview.html#the-width-and-height-properties defines 'height: complex' to deal with SEAMLESS (although it predates the invention of that attribute.)

[11:05] <arno> daniel: it reminds of the time when features where implemented before discussions

[11:05] <arno> daniel: and it gives me a bad feeling

[11:06] <arno> daniel: i have the gut feeling you're going too fast. there's no agreement between parties it should be the spec and you say: "it's in IE"

[11:06] <arno> alex: i disagree w/ the statement that we don't care about it

[11:06] * tantek agrees with daniel. this feels like we (the working group) are racing towards shipping incompatibility and legacy compat issues.

[11:06] <fantasai> +!

[11:06] * Zakim wonders where ! is

[11:06] <fantasai> +1

[11:07] <arno> action alex: remove text about special iframe behavior and alex to write proposal about the behavior of iframe

[11:07] * trackbot noticed an ACTION. Trying to create it.

[11:07] * RRSAgent records action 3

[11:07] <trackbot> Created ACTION-376 - Remove text about special iframe behavior and alex to write proposal about the behavior of iframe [on Alex Mogilevsky - due 2011-11-06].

[11:11] * tantek Quit (Quit: tantek)

[11:12] * TabAtkins_ Quit (Ping timeout)

[11:13] * plinss Quit (Quit: plinss)

[11:25] * tantek has joined #css

[11:26] <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-10should-the-regionlayoutupdate-event-by-sync-or-async

[11:26] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-10should-the-regionlayoutupdate-event-by-sync-or-async

[11:26] <fantasai> ScribeNick: fantasai

[11:26] <fantasai> vhardy: Should this event be synchronous or asynchronous

[11:26] <fantasai> vhardy: IE implemented as async, seemed to work with demos they built

[11:26] <fantasai> alex: Not sure how to make it synchronous

[11:26] * Bert to Daniel: can we find 2 minutes somewhere on the agenda to decide to publish a new Template Layout WD (probably conditionally, with a week's delay, so people can raise objections if needed)?

[11:27] <fantasai> vhardy: If no convincing argument for sync, then making it async

[11:27] <fantasai> dbaron: Are you defining exactly how it's async?

[11:27] * glazou Bert yes, right after lunch?

[11:27] <fantasai> alex: Sync would be defining exactly in what order it happens

[11:27] * Bert OK

[11:27] <fantasai> alex: async means that some layout process has happened in this region, and you're notified of that

[11:27] * plinss has joined #css

[11:27] <fantasai> dbaron: i agree with making it async. Might need more detail at some point

[11:28] <fantasai> RESOLVED: regionLayoutUpdate is an asynchronous event

[11:28] <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-18interplay-of-flow-from-and-content

[11:28] <fantasai> vhardy: interplay of flow-from and content

[11:28] <fantasai> vhardy: which one has precedence?

[11:28] <fantasai> vhardy: We had resolved to say that flow from property gets used in place of ocntent for associating an element with a flow

[11:29] <fantasai> vhardy: We moved from using 'content' to 'flow-from', there was issue raised during meeting that not sure this was quite the right decision

[11:29] <fantasai> vhardy: My request is to close the issue unless we have a problem to discuss?

[11:29] <fantasai> vhardy: I'd rather close it, and reopen if you have a specific objection

[11:30] <fantasai> fantasai: I'm ok with that.

[11:30] <fantasai> Bert: flow-from is on regions, content is on elements. So they don't interact.

[11:30] <fantasai> vhardy: flow-from makes something a region

[11:31] <fantasai> Bert: There are various ways to make regions, but content is on an element.

[11:31] <fantasai> vhardy: Right now if you wnat to flow content into an area, then you'll pick a flow and then put it in an element, which makes it into a region

[11:32] <fantasai> howcome: Bert's point is that you're using an element to create a region. You could create a region without an element

[11:32] <fantasai> RESOLVED: close issue 18, reopen if needed later

[11:32] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-23should-regions-be-non-breakable

[11:32] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-22content-vs-flow-from-precedence

[11:33] <fantasai> vhardy: content vs. flow-from precedence

[11:33] <fantasai> vhardy: On mailing list there was overwhelming preference for 'content' to take precedence

[11:34] <fantasai> fantasai: The 'normal' value of 'content' would compute to using flow-from when available

[11:35] <fantasai> discussion of using 'content' to override content

[11:36] <fantasai> alex: flow-from blows away whatever content is there. Why shouldn't it be more important than 'content'.

[11:36] * TabAtkins_ has joined #css

[11:37] <fantasai> vhardy: So we have a proposal from several to have 'content' != 'normal' override, and other is to have 'flow-from' always override.

[11:37] <fantasai> alex: If we had display-inside: region, then 'content' would be irrelevant

[11:38] <fantasai> alex: flow-from is two properties in one

[11:39] <fantasai> fantasai: 'content' property is supposed to be the master switch for what the contents of this element ar.

[11:39] * tcelik has joined #css

[11:39] * szilles has joined #css

[11:40] <dbaron> fantasai: I don't like having properties that unilaterally override other properties.

[11:41] <dbaron> fantasai: That always leads to problems.

[11:41] <fantasai> fantasai: we have this problem with 'border-image', where if someone sets 'border-image' further up in the cascade, my 'border-style: dashed' inexplicably has no effect

[11:42] <fantasai> Bert: A different solution, apart from needing two properties, the model doesn't have to be one overriding the other.

[11:42] <fantasai> Bert: In Template module, if two pieces of content go into the same slot, they add up

[11:42] <fantasai> alex: So if there's content in the region, then it's appended to the flow?

[11:43] <fantasai> vincent: You would include the element's content, and the append the flow

[11:43] * szilles Quit (Ping timeout)

[11:43] <fantasai> molly: from a developer perspective, 'content' should be about the content.

[11:45] <fantasai> discussion of applying 'content' to an image

[11:45] <fantasai> fantasai: if you write img { content: "foo" } the <img> element will cease to be a replaced element and will become an inline element containing the string "foo"

[11:46] <fantasai> RESOLVED: If 'content' computes to 'normal', then the element takes the flow

[11:48] * TabAtkins_ Quit (Quit: leaving)

[11:48] * szilles has joined #css

[11:48] * TabAtkins_ has joined #css

[11:50] <fantasai> fantasai explains the 'content' property and its various values and effects on elements, pseudo-elements, replaced elements, etc.

[11:50] <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-20list-of-region-style-properties

[11:50] <vhardy> http://dev.w3.org/csswg/css3-regions/#the-at-region-style-rule

[11:51] <fantasai> vhardy: The @region doesn't have the pseudo-selector ppl didn't like

[11:51] <fantasai> vhardy: The number of properties that apply listed in that link, font proeprties, background properties, simple rendering properties

[11:51] <fantasai> vhardy: Also includs borders/marginsp/adding,

[11:51] <fantasai> vhardy: We explain why some things that apply to layout might make sense here

[11:52] <fantasai> vhardy: there's a simplified list of properties that can apply to regions, but it's now more than ::first-line

[11:52] <fantasai> vhardy: In our impl experience, this has been ok

[11:53] <fantasai> alex: multi-col properties?

[11:53] <fantasai> vhardy: The multi-col isn't on the flow content, it's on the region itself

[11:53] <fantasai> alex: We should have an element there, say <article> as 3 columns... flows into a 1 column region

[11:53] <fantasai> alex: Could choose to have 1 col in one region and 3 col in another region

[11:53] * fantasai doesn't understand this issue at all and need to read the spec before making any comment

[11:53] <fantasai> vhardy: You can't change the layout nature, e.g. display/position

[11:54] <fantasai> vhardy: multicol... I guess it's halfway

[11:54] <fantasai> vhardy: I guess we could add it

[11:54] <fantasai> dbaron: Does this specify somewhere how the cascading and inheritance works?

[11:55] <fantasai> vhardy: yes, somewhere there

[11:55] <fantasai> dbaron: .... specificity isn't the issue

[11:55] <fantasai> howcome: It's multiple inheritance, isn't it.

[11:55] <fantasai> Bert: It's the ::first-line problem.

[11:55] <fantasai> fantasai: Can we put ::first-line into the regions spec so you can solve all the problems at the same time? :)

[11:56] <fantasai> vhardy: If there's an issue with cascading/inheritance then I'm happy to take that as a separate issue. This one is about the list of properties.

[11:56] <fantasai> ...

[11:56] <fantasai> howcome: if you set 1.2em on something inside a region, what does it refer to?

[11:57] <fantasai> vhardy: If you set the font size on the region itself, it has no effect on the content just on the layout of the region

[11:57] <fantasai> howcome: I have a region, and I set font-size on that. And it's applied

[11:57] <fantasai> howcome: And I have a span inside it that sets 1.2em. What is it relative to?

[11:58] <fantasai> vhardy: If you set it on the region then it doesn't inherit

[11:58] <fantasai> Steve: You can't have it both ways.

[11:58] * heycam|away is now known as heycam

[11:58] <fantasai> Steve: If you set it on the region and it affects the text, it inherits into that element

[11:58] <fantasai> howcome: What if you set 'inhert'?

[11:59] <fantasai> Steve: I wouldn't answer that question hastily...

[11:59] <fantasai> Steve: ::first-line has the same problem

[11:59] <fantasai> dbaron: This is very different from ::first-line actualy

[11:59] <fantasai> dbaron: I'd like the example in the spec to not use pseudo-syntax, use real syntax

[11:59] <fantasai> jdaggett agrees

[11:59] <fantasai> jdaggett: I'd like the examples to show what an author might use, not just region1 region2

[12:00] <fantasai> Steve: dbaron, I thought you said ::first-line effectively introduced an element around that thing, so inheritance would go to the first line

[12:00] <fantasai> dbaron: ::first-line introduces an additional pseudo-element around it, and I forget the wording around inheritnace 'cuz we changed it so many times

[12:00] <fantasai> dbaron: But this also has selectors inside the region rules, so you can have an element that picks up different selectors based on where it breaks.

[12:01] * glazou we're breaking for lunch in 10mins from now

[12:01] <fantasai> howcome: It says font size in percentages refers to inherited font-size

[12:01] <fantasai> dbaron: I think the model here is actually relatively simple. I think it's simpler than ::first-letter. However it doesn't agree at all with the spec's existing terminology. So it's sort of hard to write about.

[12:01] <fantasai> dbaron: This model gives elements multiple styles essentially.

[12:01] * tcelik is a bit confused about the distinction between the "current" font-size and the "inherited" font-size.

[12:02] <fantasai> dbaron: And 2.1 is writen assuming that an element has *a* computed value for a property

[12:02] <fantasai> Tab: All the specs are written with that assumption

[12:02] <fantasai> dbaron: This is more box tree stuff

[12:03] <fantasai> fantasai: We're introducing the term "fragment" to talk about pieces of the box in the box tree when it's broken

[12:03] <fantasai> fantasai: might help with discussing this

[12:03] <fantasai> Bert: I also have 'vertical-align', works like in table cells

[12:04] <fantasai> Bert: I also have 'overflow': if contents put in the region are too wide for the region, where does it go? Is it visible at all?

[12:04] <fantasai> (talking about properties that are set on the region)

[12:04] <fantasai> Rossen: This is about the properties that are propagated to the contents of the region

[12:05] <fantasai> Rossen: Back to howcome's example, when you compute fonts you always have a resolved font-size no matter where you are in the tree

[12:05] <fantasai> Rossen: If we allow regions to specify font-size, this would be equivalent to changing initial font size on the fly

[12:05] * umbridge has joined #css

[12:05] <fantasai> Rossen: Once you're inside, you start again from the root

[12:05] <fantasai> Rossen: Like howcome pointed out, this is multiple inheritance, no kidding

[12:06] <fantasai> Rossen: you won't know your font size until you lay out the part of the element that you're computing

[12:06] <fantasai> Rossen: Simplest example is body with 100em width

[12:06] <fantasai> Rossen: It appears in 2 regions, one with 10px font size and one with 100px fontsize

[12:06] <fantasai> Rossen: In this model you will have to recompute the body size

[12:06] * umbridge has left #css

[12:06] <fantasai> vhardy: No, right now all inheritance happens through the element tree

[12:07] <fantasai> vhardy: you're adding selectors that apply to fragments

[12:07] <fantasai> ...

[12:07] <fantasai> vhardy: In our model, you'll set a selector: if my H1 is in this region, here's the font size that applies

[12:07] <fantasai> howcome: in that sense you don't have multiple inheritance

[12:08] <fantasai> Steve: the multiple inheritance is when you have different pieces of the block that get different styling

[12:08] <fantasai> CHrisL: Similar to ::first-letter multiple inheritance

[12:08] <fantasai> dbaron: no, I don't think it is

[12:08] <fantasai> dbaron: Wanted to bring up 2 other things

[12:08] <fantasai> dbaron: Thing you said about percentages relative to the original, that sounded wrong to me.

[12:08] <fantasai> dbaron: I'd think if you have separate styles for stuff in the region, you'd compute styles in a consistent model within that tree

[12:08] <fantasai> dbaron: Percentages etc. would compute relative to those styles until you're back outside of that region

[12:09] <fantasai> dbaron: I don't think multiple inheritance is the right way to think about that.

[12:09] <fantasai> dbaron: Other thing I wanted to mention is, if we think about it that way

[12:09] <fantasai> dbaron: Then any property that takes lengths can change as a result of font-size changes.

[12:09] <fantasai> dbaron: It seems silly to restrict that then, i.e. only allow changes as a result of font-size but not arbitrarily otherwise.

[12:10] * heycam is now known as heycam|away

[12:10] <fantasai> dbaron: Basically if you have @region head { body {font-size: 2em; }}

[12:10] <fantasai> s/}}/}/

[12:10] <fantasai> }

[12:10] <fantasai> h1 { height: 2em; }

[12:11] <fantasai> dbaron: Your body font size is going to be double your HTML font size as it flows into this region.

[12:11] <fantasai> dbaron: your h1 initial font size is specifid in ems

[12:11] <fantasai> dbaron: If you accept what steve and I say, then the h1 is going to be proportionally larger

[12:11] <fantasai> dbaron: but what you said earlier is that it wouldn't be

[12:11] <fantasai> Steve: So I thought what yoy said is that you're overlaying styles on these elements using selectors

[12:12] <fantasai> Steve: so you'd walk up the tree and see the overlaid styles

[12:12] <fantasai> vhardy: ... this is why the properties only make sense ..

[12:12] <fantasai> vhardy: height doesn't make sense to apply to different fragments of the div

[12:12] <fantasai> steve: height has to look somewhere for its value

[12:12] <fantasai> vhardy: So that's something you'd have to compute relative to the parent element

[12:13] <fantasai> vhardy: If my h1 is in the head region, will it be base don that value or the other one

[12:13] <fantasai> vhardy: I'll take an action item on that.

[12:13] <fantasai> howcome: We all wanted to have a use case appendix, wasn't recorded as an action item.

[12:13] <fantasai> ACTION vhardy: Make a use case appendix

[12:13] * RRSAgent records action 4

[12:13] * trackbot noticed an ACTION. Trying to create it.

[12:13] <trackbot> Created ACTION-377 - Make a use case appendix [on Vincent Hardy - due 2011-11-06].

[12:13] <fantasai> <br type=lunch>

[12:14] <glazou> br is empty :-)

[12:14] * bradk Quit (Quit: Computer has gone to sleep)

[12:14] <mollydotcom> but lunch is presentational :P

[12:15] <ChrisL> <br type="lunch" dur="60min" />

[12:16] * arronei_ Quit (Ping timeout)

[12:18] * sylvaing Quit (Ping timeout)

[12:27] * tcelik Quit (Quit: tcelik)

[12:28] * szilles Quit (Ping timeout)

[12:33] * szilles has joined #css

[12:37] * arronei_ has joined #css

[12:43] * sylvaing has joined #css

[12:43] * tantek Quit (Quit: tantek)

[12:50] * szilles Quit (Ping timeout)

[12:55] * bradk has joined #css

[12:58] * guacamole has joined #css

[12:59] * guacamole has left #css

[13:04] <dbaron> ScribeNick: dbaron

[13:04] <dbaron> Topic: Orientation and unicode properties for vertical text layout

[13:04] * szilles has joined #css

[13:04] <jdaggett_> http://www.unicode.org/reports/tr50/

[13:04] <glazou> "Orientation and Unicode properties for vertical text layout"

[13:04] * tantek has joined #css

[13:05] <dbaron> jdaggett: I put this on the wiki. Based on discussions from the summer. Current writing modes spec doesn't have an entirely normative defintion of orientation.

[13:05] <dbaron> jdaggett: So it wasn't clear what exactly the default orientation should be. This means that in vertical text layout, some characters, e.g. ideographic, stay upright, whereas roman characters are rotated on their side. The question is which characters go which way.

[13:06] <dbaron> jdaggett: The current spec has an appendix which gives an algorithm; I don't know whether it's currently marked as normative.

[13:06] <dbaron> jdaggett: But the question is what the right way to do this is. In talking with Eric Muller (sitting in the back), it would make sense to make a Unicode property for this specifically.

[13:06] <dbaron> jdaggett: This proposal is to make an additional property for Unicode that would specify the default orientation that the writing-modes spec could normatively reference.

[13:07] <dbaron> jdaggett: There's a comment period now, and there will be another review period.

[13:07] <jdaggett_> http://wiki.csswg.org/spec/utr50

[13:07] <dbaron> Eric: Process-wise, UTC meets next week. Then produce a draft version of the TR and have another round of review.

[13:07] <dbaron> jdaggett: These http://wiki.csswg.org/spec/utr50 are Elika's and Koji's comments as to different issues.

[13:08] <dbaron> jdaggett: Very clear for ideographic and alphabetic characters, but there are a number of character ranges where it's more difficult to decide.

[13:08] <jdaggett_> http://www.unicode.org/reports/tr50/bycp.html

[13:08] <dbaron> jdaggett: http://www.unicode.org/reports/tr50/bycp.html is the proposed list of codepoints and how they change

[13:08] <jdaggett_> http://lists.w3.org/Archives/Public/www-archive/2011Sep/att-0010/defaultorientation.pdf

[13:09] <dbaron> jdaggett: http://lists.w3.org/Archives/Public/www-archive/2011Sep/att-0010/defaultorientation.pdf is a PDF that shows ... scroll down to U+2000 ...

[13:09] * Bert daniel, don't forget the 2 minutes on the agenda for publishing css3-layout (and css3-regions, because I think Vincent had that on his agenda as well)

[13:09] <dbaron> jdaggett: These are some general punctuation characters. Green column shows the vertical alternate that exists in the font (Hiragino Mincho, Kozuka Mincho, Meiryo).

[13:10] <dbaron> jdaggett: Where the character in the green column is different it means there's a vertical alternate for that codepoint.

[13:10] <dbaron> jdaggett: U+2014, em-dash, no fonts have vertical alternates for it

[13:10] <dbaron> ?: Using the VERT feature for this?

[13:10] <dbaron> ?: In Kozuka font, U+2014 is proportional -- covered by VRT2 but not by VERT.

[13:11] <dbaron> ?: In vertical, you do want U+2014 rotated to go along with other Latin characters that get rotated as well.

[13:11] <dbaron> jdaggett: On the Mac it's natural to use U+2014, on Windows it's natural to use U+2015.

[13:11] <dbaron> ?: In our fonts it's also a distinction between proportional and full-width.

[13:12] <dbaron> jdaggett: When you say proportional, the expectation is that it will be set sideways.

[13:12] <dbaron> ?: do that with VRT2

[13:12] <dbaron> jdaggett: scroll down to the arrows... high U+2190s

[13:13] <dbaron> jdaggett: See that the arrows are ... U+2190 pointing to the text that's coming before it

[13:13] <dbaron> jdaggett: I also have how the current IE and WebKit implementations handle this.

[13:13] <dbaron> jdaggett: These may not be totally accurate because it's a little tricky to figure out.

[13:13] <ChrisL> http://www.microsoft.com/typography/otspec/features_uz.htm#vert http://www.microsoft.com/typography/otspec/features_uz.htm#vrt2

[13:13] <dbaron> jdaggett: The problem we want to solve is that we don't want different implementations handling this differently.

[13:14] <dbaron> jdaggett: Once Unicode has a property that establishes this we have firmer ground to make text-orientation consistent across implementations.

[13:14] <dbaron> jdaggett: We won't get a solution that works 100% of the time, but we'll get a good default that authors can still change when they need to.

[13:15] * tcelik has joined #css

[13:15] * Liam has joined #css

[13:16] <dbaron> Bert: Looks like an issue for Unicode, not us.

[13:16] <dbaron> jdaggett: Right now our spec is defining an equivalent of this.

[13:16] <dbaron> fantasai: Yes, once Unicode defines this we will reference it.

[13:17] <dbaron> jdaggett: When you go into the details there are still questions as to what the OpenType layout model is for vertical text, and questions for which way specific code ranges should go.

[13:17] <dbaron> fantasai: Details of code ranges don't need the whole room.

[13:17] <dbaron> SteveZ: In other words, if you think you care, look at these documents (wiki, tr50) and comment.

[13:17] <dbaron> jdaggett: We have two browser implementations of vertical text, and it would be nice if the implementors ...

[13:18] <dbaron> fantasai: ... looked at this and made comments as appropriate.

[13:18] <dbaron> jdaggett: There's wide variation between existing implementations.

[13:19] <dbaron> SteveZ: One thing that's important as a principle: we're trying to do it so the choice of whether something is rotated or upright can be made without looking at the font data. One reason for that is that it's expensive or impossible given how the font data are encoded in OpenType (and may be impossible through some OS interfaces). But it must work in the context where the fonts do things in certain circumstances, so it's a slightly messy problem.

[13:19] <dbaron> Topic: Gradients

[13:20] <bradk> http://wiki.csswg.org/ideas/radial-gradients

[13:20] <dbaron> ACTION hober to review Unicode TR50 and compare to existing implementation

[13:20] * trackbot noticed an ACTION. Trying to create it.

[13:20] <trackbot> Created ACTION-378 - Review Unicode TR50 and compare to existing implementation [on Edward O'Connor - due 2011-11-06].

[13:20] <dbaron> ACTION sylvain to review Unicode TR50 and compare to existing implementation

[13:20] * trackbot noticed an ACTION. Trying to create it.

[13:20] <trackbot> Created ACTION-379 - Review Unicode TR50 and compare to existing implementation [on Sylvain Galineau - due 2011-11-06].

[13:21] <dbaron> Topic: ?

[13:21] <dbaron> Bert: You said you wanted to publish regions as well?

[13:21] <jdaggett_> s/TR/UTR/

[13:21] <dbaron> Bert: I also wanted to ask if we could publish a new template layout module.

[13:22] <dbaron> glazou: A little more than a week -- let's say two weeks to look at this, and then make a decision in 2 weeks?

[13:22] <dbaron> H��kon: Can we do the action points first before we publish? I think it would be helpful for the specs to have code examples.

[13:22] <dbaron> jdaggett: replacing the pseudo-code with real code

[13:22] <dbaron> H��kon: maybe put in a couple of use cases

[13:22] <dbaron> s/Topic: ?/Topic: publishing template and regions/

[13:23] <dbaron> SteveZ (?): There are use cases on the wiki.

[13:23] <dbaron> RESOLVED: publish regions and template if there are no objections in 2 weeks

[13:23] <dbaron> Topic: Gradients

[13:23] <dbaron> Tab: I assume everybody has read all the mailing list discussion on the subject. :-)

[13:23] <dbaron> http://wiki.csswg.org/ideas/radial-gradients

[13:24] <dbaron> Tab: We have 2 proposed syntaxes for radial gradients. The one in the draft and brad's simplification of it.

[13:24] <dbaron> Tab: The differences between them at this point are that:

[13:24] <dbaron> - draft allows arbitrary position; brad allows center/side/corners only

[13:24] <dbaron> - draft allows more options sizing the gradient; Brad has just circle or ellipse that fills the box

[13:24] <dbaron> Tab: The question is which one we're going to keep.

[13:25] <dbaron> Tab: This is the only remaining issue with css3-images; want to move to LC.

[13:25] <dbaron> fantasai: Do a pre-LC TR draft first.

[13:25] <dbaron> Brad: When we did linear gradients, we simplified it and made it easy to understand and learn.

[13:26] <dbaron> Brad: I think all the options in the draft are confusing and overcomplicated, and I think the way people use those options is really confusing.

[13:26] <dbaron> Brad: I think the layering of different properties that affect the length of the gradient line in different ways.

[13:26] <dbaron> Brad: In some cases position makes the gradient line larger or smaller.

[13:26] <dbaron> Brad: To understand what's going on you have to understand what wins when background-position and background-size change it

[13:27] <dbaron> Brad: The arguments for all this extra control seem to be centered around non-background use of radial gradients, which are, imo, edge cases.

[13:27] <dbaron> Brad: If you want to use a radial gradient as a list-style-image, and you can't get the clipping/styling/positioning you want, I think that's a minor issue that shouldn't drive the syntax.

[13:28] <dbaron> Tab: I disagree with that. Making all the other image-bearing properties have properties analogous to background-position and background-size (list-style-image, border-image, masks) ...

[13:29] <dbaron> Tab: While you can do without it for the most part in backgrounds.

[13:29] <dbaron> Tab: I think what's there isn't that hard and is sufficiently useful to justify itself.

[13:30] <dbaron> Tab: There are 3 bits that require thinking about with a radial gradient: if you're using a position other than center then all the implicit sizing keywords and ? and ? are relatively simple to think about if you're only using 1 or 2 of them together.

[13:30] <dbaron> Tab: The one in Lea Verou's gallery that used all 3 and was very confusing was done that way because existing browsers don't have explicit sizing.

[13:30] <dbaron> Tab: This is the Hearts Grid example.

[13:31] <dbaron> Tab: You can do the "Syntax A" version

[13:31] <dbaron> Elika: Which is the position and which is the size?

[13:31] <dbaron> Tab: position, then size

[13:32] <dbaron> Brad: That's my whole point: we're saying that if you want explicit sizing you have to put in a value for the position, since you need that comma in there to distinguish.

[13:32] <dbaron> Tab: The problem of positions and sizes looking similar is also in the background shorthand.

[13:32] <dbaron> Brad: slash there, comma here?

[13:32] <dbaron> Elika: I'd prefer something that didn't involve comma-separating everything so we could tell what's what.

[13:32] <dbaron> Tab: Unless we did a slash I'm not sure what we'd do.

[13:32] <dbaron> Daniel: no slash

[13:33] <dbaron> Brad: ...

[13:33] <dbaron> Brad: If it's a problem that we can't size images for list-style-image then it's a problem for all images, not just gradients.

[13:33] <dbaron> Arron: It's the intrinsic size of the image.

[13:33] <dbaron> Tab: With a gradient you can't control the intrinsic size.

[13:34] <dbaron> Chris: I don't agree that non-background cases are minority: I think we're going to see more of that. I'm reluctant to see a solution that doesn't give full functionality to non-background images.

[13:34] * Zakim excuses himself; his presence no longer seems to be needed

[13:34] * Zakim has left #css

[13:34] <dbaron> Brad: Won't those types of images need that functionality anyway?

[13:34] <dbaron> Chris: There are things that know how to size themselves that are not background images.

[13:34] <dbaron> Elika: With a PNG image, you have the same problem.

[13:35] <dbaron> Elika: Wouldn't it be better to have a mechanism general enough to handle non-gradient images?

[13:35] <dbaron> Brad: Better not to have to use the gradient functions to solve that problem.

[13:35] <dbaron> Chris: Things I'm thinking of don't have that problem -- they know how big they are.

[13:36] <dbaron> Chris: The syntax that requires background-size and background-position, then we'd be very limited using CSS gradients for 'fill' and 'stroke'.

[13:36] <fantasai> radial-gradient(<size> <shape> from <position> as <color-stop>, <color-stop>, ...)

[13:36] <fantasai> <size> would be one of the keywords

[13:36] <dbaron> Chris: existing syntax has % and absolute, corresponding to SVG's userSpaceOnUse and boundingBoxRelative

[13:37] <dbaron> (minute taker has trouble keeping up)

[13:37] <dbaron> Brad: simplicity is a feature, makes CSS easier to learn

[13:38] <dbaron> Elika: I'd prefer a halfway point between the two.

[13:38] <dbaron> Brad: I already went a little towards Tab's with putting center on edge/corner.

[13:39] <dbaron> Elika: farthest-corner, etc., make it easier for me to think about

[13:39] * JohnJansen Quit (Quit: Page closed)

[13:39] <dbaron> Brad: ... other colors going on past ...

[13:39] <dbaron> Elika: put a color stop at the nearest corner?

[13:39] <dbaron> Brad: That seems more complicated than just saying 142%

[13:40] <dbaron> Brad: When I'm desiging things I'm doing it visually.

[13:41] <dbaron> 1.4142135623730951

[13:41] <tcelik> would this qualify as an irrational discussion?

[13:41] <stearns> (that will be the tattoo for Tab's other arm)

[13:41] <dbaron> Brad: It's can be important to hit the edges exactly when getting a circle, but matters less to be exact at the corners.

[13:41] <dbaron> Molly: None of this makes any sense to designers/developers -- I don't think this belongs in CSS.

[13:42] <dbaron> Molly: ok, let's leave the second point for dinner conversation

[13:42] <dbaron> Daniel: I implemented a visual editor for the gradient proposal -- it's very complicated because of the syntax.

[13:43] <dbaron> Daniel: I did the original WebKit proposal and the WG one afterwards.

[13:43] <dbaron> Tab: It should be a lot easier now with explicit sizing.

[13:43] <dbaron> Brad: I made a list of all the details I had to learn about how these parameters interact with each other.

[13:43] <dbaron> Brad: linear gradients are simple, one side to the other

[13:43] <dbaron> Brad: With this simplification, you're either going from one side to the other or center to the side

[13:44] <dbaron> Brad: keeping it simple makes it much more understandable

[13:45] <dbaron> Tab: Linear gradients are easier because it's one-dimensional.

[13:45] <dbaron> Tab: Any linear gradient can be represented using the current syntax. Can't do that with radial gradient -- many can't be expressed in simpler form.

[13:46] * JohnJansen has joined #css

[13:46] <dbaron> Brad: I'd want things more towards the simple side.

[13:47] <dbaron> Molly: Agree. This is really SVG. We're putting it in CSS because designers want it right now. I think we need to keep it simple and respect what's in SVG.

[13:47] <Bert> +1 to Molly

[13:48] * Bert doesn't feel so alone anymore :-)

[13:48] <dbaron> Molly: Designers would love the perfect WYSIWYG. As implementors you may be able to understand something, but putting it in language that people with less experience can explain... Trying to stopgap a need from designers. Concerned about simplicity and relation to SVG.

[13:48] <dbaron> Tab: Remember, the majority of gradient usage won't use the functionality we're talking about.

[13:49] <dbaron> Sylvain: We have 4 implementations.

[13:49] <dbaron> Daniel: Opinions of those who make tools that design gradients?

[13:49] * Liam Quit (Ping timeout)

[13:50] <dbaron> Daniel: we have to reach a consensus

[13:50] <dbaron> Arno: I'd lean towards the simpler syntax.

[13:50] <dbaron> John: I would too

[13:50] <dbaron> Alan: There is an SVG fallback.

[13:51] <dbaron> Sylvain: Authors I've talked to have been more bothered by the change to bearing angles than by the complexity. What seems complex now may not in the future.

[13:51] <dbaron> Brad: I don't think complexity goes away.

[13:52] <dbaron> Elika: I'm confused by both syntaxes. I'd want something more readable.

[13:52] <dbaron> Elika: How can we make it obvious which part means what?

[13:52] <dbaron> Elika: Get away from commas, use keywords.

[13:53] <dbaron> Elika: linear-gradient(from left as red, blue, green)

[13:53] <dbaron> Elika: radial-gradient(circle from top left as red, blue, green)

[13:53] <dbaron> Elika: radial-gradient(<shape>? from <position> as <color-stop-list>)

[13:55] <dbaron> Brad: I do have the 'from' keyword, optional if not starting from the center.

[13:55] <dbaron> Bert: Why 'circle' at all?

[13:55] <dbaron> Elika: Otherwise it's an ellipse.

[13:56] <dbaron> Elika: gradients have no intrinsic ratio

[13:57] <dbaron> Elika: You can do Tab's set of functionality or Brad's with this syntax, but I think it'll be understandable

[13:57] <dbaron> Brad: I have the idea that if you specify 'circle' it does have an intrinsic ratio.

[13:58] <dbaron> Brad: That solves the what if you want a non-distorted circle that fills to the corners.

[13:59] <fantasai> dbaron: I don't think giving it an intrinsic ration solves what you think it solves

[13:59] <fantasai> dbaron: I think what you were saying is that if you want a circle that fills out to the corners of a non-square box

[14:00] <fantasai> dbaron: so you want somehting where the extent of the graident is that *draws rectangle inscribed in an ellipse*

[14:00] <fantasai> Brad: sorry, should have said "background-size: cover"

[14:00] <fantasai> dbaron: that'll be smaller than what you want

[14:01] <fantasai> Brad: I have a circle, used the circle keyword, and draw gradient to 142%

[14:01] <fantasai> Brad: and then ..

[14:01] <fantasai> dbaron: I don't know if we need to dig into this too much, though.

[14:01] <fantasai> Steve: You would get what you want if the diameter of the circle covers the box.

[14:01] <fantasai> Steve: Which is another way of saying...

[14:02] <fantasai> dbaron: Tab's syntax has keywords for those four possibilities.

[14:02] <fantasai> daniel: we've been working on gradient syntax for months withouth conclusion

[14:02] <fantasai> steve: one reason we might not have a conclusions is that neither are acceptable yet

[14:03] <fantasai> steve: there are good ideas in both, but still haven't gotten one that people understand and can communicate

[14:03] <fantasai> daniel: Both solutions are okay. That's the problem.

[14:03] <fantasai> daniel: But we need a resolution, and designers need this to ship

[14:04] <fantasai> sylvain: People are using this today.

[14:04] <fantasai> dbaron: And they're using it enough that this might wind up being the first -moz-prefixed thing we are unable to drop, given the number of changes.

[14:05] <fantasai> fantasai: I really want to go in this direction. I can't read this stuff.

[14:05] <fantasai> (this == using keywords)

[14:05] <fantasai> Tab: I want to resolve on this asap.

[14:05] <fantasai> Tantek: You're saying taking longer hurts more than complexity

[14:05] <Ms2ger> Don't we all?

[14:06] <fantasai> Molly: And then educators are stuck with this for eternity

[14:06] <fantasai> daniel: What's the plan?

[14:07] <fantasai> fantasai: I would like 24 hours with Brad and Tab and come back here tomorrow.

[14:07] <fantasai> Tab: What I want more than anything else for my birthday is to close this issue.

[14:07] <tantek> Dante's Inferno would have used radial gradients.

[14:08] * hober the 9 color stops of Hell

[14:08] <arno> :)

[14:08] <dbaron> the closest-side, etc. could be following a 'to'

[14:08] <dbaron> Tab: Brad's concern about complication is about position of the gradient line.

[14:09] <dbaron> Bert: What's the difference if it's not the syntax?

[14:10] <dbaron> fantasai: The ability to do arbitrary center, and the {farthest,closest}-{corner,side}, and explicit sizing of the ellipse.

[14:10] * drublic has joined #css

[14:10] * hober an example of brad's gradient: http://media-cdn.tripadvisor.com/media/photo-s/01/c4/e1/5f/guinness-storehouse.jpg

[14:11] <dbaron> Brad: And the fact that I'm starting from edge or center means I can go from corner to the full width of the element maintaining a circle.

[14:11] <dbaron> dbaron: Isn't that farthest-side?

[14:11] <dbaron> Tab: My syntax gives you the option.

[14:11] <dbaron> Daniel: We are running in circles.

[14:11] <dbaron> (Aren't we running in ellipses?)

[14:12] <dbaron> Daniel: Straw poll, syntax A (Atkins) vs. syntax B (Brad)

[14:12] <dbaron> Luke MacPherson: A

[14:12] <dbaron> Shane: A

[14:12] <dbaron> Steve: no comment

[14:12] <dbaron> Molly: abstain

[14:13] <dbaron> Bert: B (set of features, not syntax)

[14:13] <dbaron> Stearns: abstain

[14:13] <dbaron> Alex: to Sylvain

[14:13] <dbaron> Arno: A

[14:13] * heycam|away is now known as heycam

[14:13] <dbaron> Brad: B

[14:13] <dbaron> Tab: A

[14:14] <dbaron> Elika: abstain

[14:14] <dbaron> Daniel: B

[14:14] <dbaron> Koji: A

[14:14] <dbaron> John Daggett: don't like either, so abstain

[14:14] <dbaron> David: I guess A.

[14:14] <dbaron> Arron: A

[14:14] <dbaron> Sylvain: A

[14:14] <dbaron> John: I'll have to learn A.

[14:14] <dbaron> H��kon: abstain

[14:14] <dbaron> Peter: abstain

[14:14] <dbaron> Chris: A

[14:14] <dbaron> Vincent: A

[14:14] <dbaron> Rossen: A

[14:15] <dbaron> Tantek: A

[14:15] <dbaron> Hober: A

[14:15] <dbaron> Resolved: Stick with Tab's set of features.

[14:16] <dbaron> ACTION Tab and Elika: discuss improvements to syntax within this set of features

[14:16] * trackbot noticed an ACTION. Trying to create it.

[14:16] <trackbot> Created ACTION-380 - And Elika: discuss improvements to syntax within this set of features [on Tab Atkins Jr. - due 2011-11-06].

[14:16] <dbaron> Can we teach tracker to give actions to 2 people?

[14:17] <fantasai> ACTION plinss: teach Tracker to give actions to multiple people

[14:17] * trackbot noticed an ACTION. Trying to create it.

[14:17] * RRSAgent records action 5

[14:17] <trackbot> Created ACTION-381 - Teach Tracker to give actions to multiple people [on Peter Linss - due 2011-11-06].

[14:17] <fantasai> :P

[14:17] <Ms2ger> ACTION Elika and Tab: discuss improvements to syntax within this set of features

[14:17] * trackbot noticed an ACTION. Trying to create it.

[14:17] <trackbot> Created ACTION-382 - And Tab: discuss improvements to syntax within this set of features [on Elika Etemad - due 2011-11-06].

[14:17] <Ms2ger> :)

[14:17] * bradk Quit (Quit: Computer has gone to sleep)

[14:21] * tcelik Quit (Quit: tcelik)

[14:22] * JohnJansen Quit (Quit: Page closed)

[14:26] * tantek Quit (Quit: tantek)

[14:26] * plinss Quit (Quit: plinss)

[14:45] * bradk has joined #css

[14:46] <dbaron> Topic: CSS Object Model

[14:47] * BradK_ has joined #CSS

[14:47] <fantasai> [side-note wrt writing-modes] fantasai: we might want to discuss property to tailor UTR50 to handle e.g. greek/cyrillic being upright, but we can discuss that offline

[14:47] * bradk Quit (Quit: Computer has gone to sleep)

[14:47] * BradK_ is now known as BradK

[14:47] <dbaron> H��kon: Anne will be at TPAC Monday and Tuesday.

[14:47] <fantasai> jdaggett: Shouldn't Anne be here?

[14:47] <dbaron> Daniel: Originally Scheduled for Tuesday at 9am.

[14:47] <fantasai> howcome: I can inform him that we'll discuss this Tuesday at 9am

[14:48] <fantasai> glazou: if he's not going to show up to discussions...

[14:48] <fantasai> glazou: Ok, next topic

[14:48] <fantasai> Topic: CSS Exclusions and Shapes

[14:49] <Rossen> http://dev.w3.org/csswg/css3-exclusions

[14:49] <dbaron> http://dev.w3.org/csswg/css3-exclusions/

[14:50] <fantasai> Rossen: there were two independent spec works being done by MS and Adobe before we even brought any of this to the WG, and at some point Adobe brought in original Regions and Exclusions spec, and that was halfway when almost done with our part and getting ready to propose working on Floats

[14:50] <fantasai> Rossen: At that time we decided to see what the differences and similarities are and come up with one single spec

[14:50] <fantasai> Rossen: CSS Exclusions was split from CSS Regions

[14:50] <fantasai> Rossen: And since last F2F in Seattle our one major action was to redo the spec combine, css exclusions and positioned floats and present that

[14:50] <fantasai> Rossen: And get that towards WD

[14:51] <fantasai> Rossen: So CSS Exclusiosn and Shapes we are talking about today

[14:51] <fantasai> Rossen: We're going to see what CSS Exclusions are and how to use them, and what the CSS Shapes are and how to use them

[14:51] <fantasai> Rossen: The two concepts are currently separate concepts, but they actually work really well together. So keeping them in same spec for now

[14:51] * JohnJansen has joined #css

[14:51] <fantasai> Rossen: CSS Exclusions

[14:52] <fantasai> Rossen: Baic definition, it's an area that you want to preserv clear from any inline-flow layout

[14:52] * tantek has joined #css

[14:52] <fantasai> Rossen: Many example sof this in magazine layouts: pull-quotes, figures with type wrapped around them, etc.

[14:52] <vhardy> s/Baic/Basic

[14:52] <fantasai> Rossen: In CSS we already have floats, which are like exlcusions, but we lack the ability to position them precisely

[14:52] <fantasai> Rossen: Currently we allow exclusions to be applied to any block-level element

[14:52] <fantasai> Rossen: so an exclusion can be any block-level element

[14:53] * ChrisL such as ins and del

[14:53] <fantasai> Rossen: Combined with abpso you can create some really magazine-like layouts.

[14:53] <fantasai> Rossen: I will show slides and spec side-by-side

[14:54] <fantasai> Rossen: So, declaring exclusions is done with the 'wrap-flow' property

[14:54] <fantasai> Rossen: Setting it to anything other than 'auto' creates an exclusion

[14:54] <fantasai> Rossen: 'auto' in this case is special because for regular flow elements the 'auto' value doesn't change the behavior of floats

[14:55] <fantasai> Rossen: Exclusions can be applied on the left, right, or both sides

[14:55] <BradK> Exclusions apply to block only, but floats turn inclines into blocks. Shouldn't they behave similarly?

[14:55] <fantasai> Rossen: maximum picks the left or right, whichever has the most space left

[14:55] <fantasai> Rossen: Last one is clear, which clears wrapping on both left and right

[14:56] <TabAtkins_> scribenick: TabAtkins_

[14:57] <TabAtkins_> jdaggett_: Is there a typo with the maximum example showing up twice?

[14:57] <TabAtkins_> Rossen: No, the example shows what 'maximum' does when there's more room on one space or the other.

[14:57] <TabAtkins_> szilles: 'left' and 'right' don't work vertically.

[14:58] <TabAtkins_> fantasai: It would probably map to line-left and line-right, but it should probably just be 'start' and 'end'.

[14:58] <TabAtkins_> fantasai: Or have them both, since they do slightly different things.

[14:58] <TabAtkins_> jdaggett_: Why not just start and end?

[14:59] <TabAtkins_> fantasai: If you have a design that doesn't depend on the writing direction, frex.

[14:59] <TabAtkins_> howcome: Are there any restrictions on what elements can affect other things?

[15:00] <TabAtkins_> Rossen: Next slide, containing model.

[15:00] <TabAtkins_> Rossen: We're not changing things beyond what 2.1 already specifies.

[15:00] <TabAtkins_> Rossen: We find the containing block, and that's the exclusion container too.

[15:00] <TabAtkins_> scribenick: fantasai

[15:00] <fantasai> Rossen: The definition we have for wrapping context is simply a collection of exclusion elements.

[15:00] <fantasai> s/elements/areas/

[15:01] <fantasai> Rossen: An exclusion area is the area defined by the element. Initially this is the border-box of the element

[15:01] <fantasai> Rossen: As we'll see later on, this can be changed into a shape

[15:01] <fantasai> howcome: I can't really parse this text here

[15:01] <fantasai> howcome: If an abspos comse from outside, will it affect layout of a deeply-nested <p> element?

[15:01] <fantasai> Rossen: Does everyone understand the containing model?

[15:02] <fantasai> Rossen: You have somewhere in a subtree of an element an abpsos element, and it positions to a containing block.

[15:02] <fantasai> Rossen: The scope of the exclusion is the entire subtree of the containing block.

[15:02] <fantasai> howcome: Then you have 'wrap-through' property.

[15:03] <fantasai> Rossen: You can use that property to stop the propagation of wrap context at any level of the subtree. But in the subree only

[15:03] * tcelik has joined #css

[15:03] <fantasai> Rossen shows the example of 'wrap-through' right above the 'wrap' shorthand definition

[15:03] <fantasai> jdaggett: ...

[15:04] <fantasai> Rossen: It's positioned and sized following CSS2.1 rules.

[15:04] <fantasai> Rossen: Once it is positioned, it is registered as an exclusion, and the flow layout will continue from that point on, respecting that exclusion

[15:04] <fantasai> jdaggett: The content of the exclusionary is what?

[15:04] <fantasai> jdaggett: What goes in that div that you're absolutely positioning?

[15:04] <TabAtkins_> Shane suggests a 'rap' property to complement 'flow'.

[15:04] <fantasai> howcome: So 'wrap-through', it's similar to 'float-through'

[15:05] <fantasai> Bert: No, that's different

[15:05] * mouse has joined #css

[15:05] <fantasai> dbaron: That's propagation to ancestors, not descendants

[15:05] <fantasai> howcome: If you have a <p> and you have a float on the side, you end the element, the float continues

[15:05] <fantasai> dbaron: Wrap through is about going through to descendants

[15:05] <fantasai> dbaron: This model can't describe float, basically

[15:06] <fantasai> howcome: But you're introducing a different concept.

[15:06] <fantasai> howcome: Could we not latch onto one of the other contexts that we have?

[15:06] <fantasai> howcome: I'm wary of introducing yet another reference model

[15:06] * szilles Quit (Ping timeout)

[15:06] <fantasai> vhardy: We've been bounching around on this for several months, this is what we ended up with

[15:06] <fantasai> Rossen: We started with floats, but it had a lot of issues that we were not able to solve.

[15:07] <fantasai> Bert: I think you're talking about something else, howcome.

[15:07] <fantasai> Bert: The second paragraph that you (howcome) didn't draw. The wrap-through property isn't about whether the float goes through, but whether the line boxes in the second <p> wrap around it

[15:07] <fantasai> howcome: It's so similar to floats, we should extend floats

[15:08] <fantasai> Rossen: .. they do create exclusions, and in this respect they're the same

[15:08] <fantasai> Rossen: In this respect they're not completley normal. But it is the positioning that we want to address.

[15:08] <fantasai> Rossen: Do people understand 'wrap-through'?

[15:08] <fantasai> Rossen draws a diagram:

[15:08] <fantasai> circle marked CB at the top

[15:08] <fantasai> triangle extending down from it

[15:09] <fantasai> a squiggly line extending from the circl down to a small circle inside the diagram

[15:09] <fantasai> which then connects to the left corner of the big triangle and the middle of its base

[15:09] <fantasai> this part is shaded

[15:09] <fantasai> a thing on the base line on the non-shaded part points back up to the CB circl

[15:09] * mouse has left #css

[15:10] <fantasai> Rossen: wrap-through opts out of the wrapping. It's an opt-out model rather than an opt-in model.

[15:10] <fantasai> howcome: How common is this?

[15:10] <fantasai> howcome: If you have an exclusion, can't it just be an exclusion?

[15:10] <fantasai> Rossen: We did have use cases for this

[15:11] <fantasai> Bert: Say you have in that tree you draw there, the small black thing that's abspos, it pushes everything else aside.

[15:11] <fantasai> Bert: It has wrap-flow something.

[15:11] <fantasai> Bert: When you say wrap-trhough on the other circle, then you set wrap-flow on it.

[15:11] <fantasai> Rossen: Then you have multiple exclusions

[15:11] * dino has joined #css

[15:11] <fantasai> Alan: There was a bunch of discussion about overlapping and combining exlcusion shapes and having portions be affected by this exclusion shape and not that one, to build up more complicated layouts that have that feature that was requested.

[15:12] <fantasai> dbaron: wrap-trhough is an attempt to do that?

[15:12] <fantasai> Alan: You don't do it by itself, you use it with other exclusion shapes, to chose which ones you'd be affected by

[15:12] <fantasai> Alex: ... my content doesn't wrap to anything, so the exlusions overlap but hte content flows around

[15:13] <fantasai> Bert: THe problem I see with wrap-through, if you have a floating element there, you still want to wrap around that floating element

[15:13] <fantasai> vhardy: Your question is if I have a float before here *draws a circle before the small circle*

[15:13] <fantasai> vhardy: Is that float still affecting wrpaping

[15:13] <fantasai> vhardy: In our model, we have just one wrapping context, and if you exclude them [...]

[15:14] <fantasai> Rossen: We can scope the opt-out wrapping so that floats are not affected by it

[15:14] <fantasai> Rossen: In otherwords, floats would still contribute as they do today

[15:14] <fantasai> Bert: I'm still brainstorming here.

[15:14] <fantasai> Bert: You might also on this subtree set a z-index at a high value. And then you'd be in front of the exclusion. That seems easier.

[15:14] <fantasai> Alex: I think wrap-trhough needs a better name. I was confused for the longest time what it does.

[15:15] <fantasai> Alex: The meaning of the property is "make this container avoid wrapping anything"

[15:15] <fantasai> 'wrap-off'?

[15:15] * fantasai thinks the name is fine

[15:16] <fantasai> Rossen: wrap-through means stop the propagation of wrapping context

[15:16] <fantasai> howcome: So it's the same as this thing I'm describing here. I'd like to have it for floats.

[15:16] <fantasai> dbaron: What's the use case for floats?

[15:16] <fantasai> dbaron: Why do you want this, and why do you want this here?

[15:17] <vhardy> http://wiki.csswg.org/ideas/css3-exclusions-use-cases

[15:18] <fantasai> Rossen shows UC2

[15:18] <fantasai> Rossen: In this case we have 2 exclusions affecting each other as well as the context around them

[15:18] <fantasai> *shows example of two columns of black text, wrapped around: a red circle of text in the center, which has a blue square text intersecting with it; none of the text overlaps*

[15:19] * fantasai wants to know what happens when you increase the font size of that red circle

[15:19] <fantasai> Rossen: One use case not in the wiki was to have for example tables, where data is really supposed to be prsented in some manner, if you want to pop out of exclusion so that the table's contents aren't affected by it

[15:20] <fantasai> Rossen: There are layouts for which you don't want to have exclusions.

[15:20] <fantasai> jdaggett: How does z-index affect this?

[15:20] <fantasai> Rossen: thanks for moving us ahead

[15:21] <fantasai> Rossen: So, once you have a wrapping context computed for an element, you have ca collection of many elements that want to be exclusions

[15:21] <fantasai> Rossen: we need to compute their order

[15:21] <fantasai> Rossen: By default the last item in the document will be on top of everything else

[15:21] <fantasai> Rossen: Naturally we'd want everything else would be affected

[15:21] <fantasai> Rossen: Ordering of exlcusions is done in painting order. And you can use z-index to reorder them

[15:22] <fantasai> Rossen: Doing this work, at first it seemed kind of hard to wrap our heads around would z-index just work

[15:22] <fantasai> Rossen: Interesting thing is that all of the sorting is doable just locally on that element

[15:23] <fantasai> Rossen: You don't have to sort the entire document and figure out all of the stacking contexts in order to apply this, simply because the scope of exclusions is basically limited to the containing block

[15:23] <fantasai> dbaron: But it covers all descendants too

[15:23] <fantasai> dbaron: So it's not a local process. You still have to perform layout between each one.

[15:23] <fantasai> Rossen: Not a local process. It is a two-pass layout

[15:23] <fantasai> Rossen: in which you first lay out all of the descendants

[15:24] <fantasai> Rossen: Not abpsos though

[15:24] <fantasai> dbaron: Yes you do, because [...]

[15:25] <fantasai> dbaron: because there might be an abpsos descendant that creates an exclusion, but that that abspos descendant's containing block is still a descendant of your current context, and your current context has another descendant after that also establishing an exclusion

[15:26] <fantasai> Rossen: This second exclusion that you just discovered, its scope will be [...]

[15:26] <fantasai> Rossen: So this exclusion cannot affect any of the sibling exclusions

[15:26] <fantasai> dbaron: We have two abpsos containing blocks, one inside the other.

[15:26] <fantasai> dbaron: You have an exclusion inside the first, that affects the size of it

[15:27] <fantasai> Rossen: assume they're all abspos for simplicity

[15:27] <fantasai> dbaron: That's one of the problems, the spec assumes that but allows for things that aren't

[15:27] <fantasai> Rossen: Let's say that you ahve an abspos element that propagates up to this CB in the hierarchy

[15:27] <fantasai> Rossen: These are both position absolute *dras siblings*

[15:27] <fantasai> Rossen: And this one is also an exclusion (second one)

[15:28] <fantasai> Rossen: When the two are to be laid out on the elvel of this containing block

[15:28] <fantasai> Rossen: Your statement was that I also need to lay out everything inside the first abspos in rder to figure out the stacking context

[15:28] <fantasai> dbaron: If you're doing this 2-pass thing, you just do 2 passes and get the wrong result.

[15:28] <fantasai> Arron: The first pass finds the static position of everything.

[15:28] <fantasai> dbaron: The static position will be wrong once you've done the second pass

[15:29] <fantasai> dbaron: It's not just static position, it's anything that creates an exclusion that's not absoluely positioned

[15:29] <fantasai> fantasai: Also if you position to the bottom, and your height depends on the contents.

[15:29] <fantasai> Rossen: Oh yeah, this is a known issue.

[15:30] <fantasai> dbaron: Fundamentally I think the absolute positioning model is the wrong thing to tie exclusions to. I'd rather connect them to the floats model.

[15:30] <fantasai> Steve: But that gives the wrong answer

[15:30] <fantasai> howcome: I think I support you (dbaron)

[15:30] <fantasai> howcome: You've introduced a bunch of wrap propertis, but it doesn't affect floats, and I think it should do.

[15:31] <fantasai> Steve: That's a separate question. Let's look at this and then see how it affects floats.

[15:31] <fantasai> dbaron: One of the other problems with this, it sort of assumes you can apply it to things that aren't absolutely positioned.

[15:31] <fantasai> dbaron: But if you do, that won't work well because it only affects things inside the parent

[15:31] * fantasai didn't quite catch that

[15:32] <fantasai> Rossen: If you want to have an exclusion which is part of the flow, say a centered float

[15:32] <fantasai> Rossen: Today you have left float and right float, say you want a centered float.

[15:32] <fantasai> howcome: You add float: center;

[15:32] <fantasai> Rossen: That brings other problems. How do you interact with left and right floats?

[15:32] <fantasai> Rossen: Right now we have left and right areas of the float which compete for space with text in the center. Now you have a region in between?

[15:33] <fantasai> howcome: Don't you have that problem anyway?

[15:33] <fantasai> howcome draws.

[15:33] <fantasai> howcome: You have an exclusion here. Then you have a left float that doesn't fit. What happens?

[15:33] <fantasai> howcome: Do you have a clear ?

[15:34] <fantasai> howcome: By having a model that kindof interacts with floats and kindof interacts with abspos, you create all these problems in the wake

[15:34] <fantasai> Steve: The current definition of float moves the float down until it will fit

[15:35] <fantasai> Steve: The barrier just doesn't allow any text to appear there. So lines dont' break, but flow across it, and don't render inside it

[15:35] <fantasai> howcome: Still sems like a viable option to me, don't see why it's not

[15:35] <fantasai> Steve: don't have enough control over positioning

[15:35] <fantasai> Steve: If you break it down, bunch of considerations about where things are

[15:35] <fantasai> Steve: Takes abspos items and make them behave like floats

[15:35] <fantasai> howcome: Why not extend floats?

[15:36] <fantasai> Steve: Because I don't want them to move

[15:36] <fantasai> Steve: Makes more sense to make abspos elements exclude

[15:36] <fantasai> vhardy: A positioned float is kindof an oxymoron.

[15:36] <fantasai> howcome: Want to explore doing it the float way

[15:37] <fantasai> jj: that's what we've done

[15:37] <fantasai> dbaron: Something Steve said I disagreed with

[15:37] <fantasai> Tantek: The whole expand float vs new feature. THere are a couple methodologies to apply to think about.

[15:37] * dino Quit (Ping timeout)

[15:37] <fantasai> Tantek: From author's perpsective, there's a transition period. How will this behave during the transition period?

[15:37] * bradk_ has joined #css

[15:37] <fantasai> Tantek: What's the fallback behavior?

[15:38] <fantasai> Tantek: One way to explore this problem space is to consider that.

[15:38] <fantasai> Tantek: Want to do this new exclusion thing, but not suck on these old browsers.

[15:38] <fantasai> Tantek: Without using css-conditional, if you had two float values you can have a fallback value

[15:39] <fantasai> Tantek: If you don't ahve a fallback, it will slow adoption.

[15:39] <fantasai> Tantek: Other quesiton is, if new feature B is similar to old feature A. How complex is old feature A?

[15:39] <fantasai> Tantek: If it took only a few years to do old feature A, then building on it for B make ssense.

[15:39] <dbaron> q+ to respond to Steve's assertion that authors want it where they position it

[15:40] <fantasai> Tantek: But if old feature A took years and years and years to get it right, then it's naive ot think new feature B can be completed quickly.

[15:40] <fantasai> Steve: I'm wondering which of abpos and floats you think is simpler. :)

[15:41] <fantasai> Rossen: We don't want to mess with positioning complexity of floats today. Don't want to produce yet another layer of complexity

[15:41] <fantasai> Alex: I wanted this to CSS3 Floats module, and we should have one that includes new floats and page floats.

[15:41] <fantasai> Alex: This spec is scoped in a way that when this new floats spec appears, it doesn't need to say anything new about exclusions.

[15:41] <fantasai> Alex: This describes how objects with exclusions itneract with content and each other.

[15:41] <fantasai> Alex: When we find smarter way to position floats, this should all apply.

[15:42] <fantasai> Alex: Should be able to implement just this, and then get smarter floats.

[15:42] <fantasai> Alex: Might be things here, like 2-pass algorithm, which is really about [...]

[15:42] <fantasai> vhardy: One big difference with floats is that floats assume rectangular shapes, so margin collapsing [..]

[15:42] <fantasai> fantasai: floats don't collapse margins with anything.

[15:43] <fantasai> Steve: Point you made earlier with overlays. These are positioned. If they overlap, one takes chunk out of the other.

[15:43] <fantasai> Steve: Simpler model, but gives you something you can't get with floats

[15:43] <fantasai> Bert: I wonder how that example works.

[15:43] <fantasai> Bert: The blue one is not in the flow of the containing block of the red one. The blue one has its own flow

[15:44] <fantasai> Rossen: Wrapping context is that of the *containing block* of the exclusion.

[15:44] <fantasai> Rossen: In this case they both hvae same containing block, so they're in the same wrapping context.

[15:45] <fantasai> ...

[15:45] <fantasai> howcome: So in this example, if the blue comes on top

[15:45] <fantasai> Rossen: Then the red will wrap around it

[15:46] <fantasai> ...

[15:46] <fantasai> Tantek: Is the circle a fixed size? What happens to overflow?

[15:46] * Liam has joined #css

[15:46] <fantasai> Rossen: haven't talked about shapes yet.

[15:47] <fantasai> Rossen: All three elements here are exclusions, all in same containing block *shows example of three overlapping squares*

[15:47] <fantasai> Tantek: How adaptive is this to different amounts of content?

[15:47] <fantasai> Rossen: This one is done with overflow: hidden

[15:48] <fantasai> howcome: If you have a newspaper article, and you want to highlight the quote, you want to make sure the full quote appears.

[15:48] <fantasai> howcome: Your examples look good, but they cut off the text.

[15:48] <fantasai> Tantek: So the request is to us econtent and grows it

[15:49] <fantasai> Rossen: If the element is width or height auto, and you start excluding it, its size will change to accommodate the content.

[15:49] <fantasai> Rossen: If the size is fixed, then it will overflow.

[15:49] <fantasai> Tantek: I think the examples should show what designers will want, i.e. not clipping the content.

[15:49] <fantasai> dbaron: I'd like to go back to the point Steve made about 11 minutes ago

[15:49] * tantek wants to avoid more unintended cases of http://dev.w3.org/csswg/css3-ui/cssisawesome.png

[15:50] <fantasai> dbaron: So, when we were talkinga bout differences btw floats and positioning, Steve made the assertion that authors want things where they've positioned it.

[15:50] <fantasai> dbaron: but thinking back to the examples Adobe showed when we met at Mozilla in the spring

[15:50] <fantasai> dbaron: I think in a bunch of those examples, you don't want that.

[15:50] <fantasai> dbaron: You will wind up in many cases where you're overlapping where you don't want overlap

[15:51] <fantasai> dbaron: For example, pull quotes in the middle of a page.

[15:51] <fantasai> dbaron: You're fine if the author can look at the resulting page on all the devices on which it will appear, and make sure there aren't two pull-quotes on the same page

[15:52] <fantasai> dbaron: But if you have different font sizes or different page sizes and you're doing a layout like that, you don't want two pull quotes that wind up on the same page to overlap each other.

[15:52] <fantasai> dbaron++

[15:52] <fantasai> Steve: I agree with your example. I don't think floats do a better job, though.

[15:52] <fantasai> Steve: If I wind up with two pull-quotes, I might want to only show one of them

[15:53] <fantasai> Rossen and howcome discuss how to position the pull-quote

[15:54] <fantasai> howcome: I want to put a pull-quote between 1st and 2nd column, 30% down from the top

[15:54] <fantasai> Rossen: How many columns?

[15:54] <fantasai> howcome: Depends on width of the screen

[15:54] <fantasai> Steve: that gets us more into grid-addressing issue

[15:54] * dino has joined #css

[15:56] <fantasai> howcome explains his use case in more detail

[15:56] <fantasai> howcome: You have the gr unit, yes.

[15:57] <fantasai> Steve: There's a separation between the positioning model and the ability to exclude

[15:57] <fantasai> Tantek and howcome discuss the issue, howcome says you can do this with gcpm

[15:58] * Ms2ger Quit (Quit: nn)

[15:58] <fantasai> Rossen: That solves horizontal position, but not vertical

[15:58] * tantek was wondering if/how you can set a float to have a margin-right of -50% of its width

[15:58] <tantek> and H��kon claims GCPM has the ability to do this.

[15:58] <fantasai> Rossen: If you can do something with abspos today, you can exclude it

[15:58] <fantasai> vhardy: We're not talking about positioning, just the exclusions aprt

[15:59] <fantasai> s/aprt/part/

[15:59] <fantasai> howcome: We have an opportunity to make floats better

[15:59] <fantasai> Tantek: floats are so fragile, we shouldn't touch them

[15:59] * pudgetta has joined #css

[15:59] <fantasai> howcome: We need floats to the top/bottom of the colu,n

[15:59] <fantasai> Rossen: You could have 'float' value to top/bottom/left/right

[15:59] <fantasai> Rossen: But that's orthogonal to what we're doing here

[16:00] * pudgetta Quit (Quit: http://www.mibbit.com ajax IRC Client)

[16:00] <fantasai> howcome: This case is the most common case for pull-quotes in newspapers

[16:01] <fantasai> ...

[16:01] <fantasai> Tantek: I'm willing to accept that examples exist, but I want documentation that they're common

[16:01] * plinss has joined #css

[16:01] <fantasai> Steve: I can provide examples in multiple scripts

[16:02] <fantasai> howcome: go to wikipedia and search for pull-quote

[16:02] <ChrisL> http://en.wikipedia.org/wiki/Pull_quote

[16:02] <fantasai> Alan: This spec is about, not where the pull quote is, but how things wrap aorundit

[16:03] <ChrisL> http://en.wikipedia.org/wiki/File:Pull-Quote.PNG

[16:03] <fantasai> Tantek: My experience is that pull-quotes are positioned relative to the page, not the columns

[16:03] <fantasai> dbaron: Does somebody have the Sunday NYT?

[16:04] <fantasai> howcome: You can do this already

[16:04] * szilles has joined #css

[16:04] <bradk_> http://blog.psprint.com/wp-content/uploads/2009/01/pull-quote.jpg

[16:05] <fantasai> ...

[16:05] <fantasai> vhardy: Positioning is in a separate module. We're not trying to improve positioning at all.

[16:05] <tantek> nice example bradk

[16:05] <fantasai> dbaron: I'm suspicious of the claim that we should think about positioning separately because the whole multi-pass layout issue is very tied into the positionng model we're using

[16:06] <fantasai> dbaron: Using a 2-pass approach will have different amounts of approximaion error. In some models it'll be close, in others your content will be somewhere completely unrelated.

[16:06] <fantasai> Rossen: We had this note about 2-pass implementation. Almost all of the concerns I saw on the mailing list was about scaling this for interactive media

[16:06] <stearns> the wikipedia pull quote example is incredibly ugly

[16:07] <fantasai> Rossen: Based on that, Dave Hyatt and you were asking how do we make this not exponential ...

[16:07] <fantasai> Rossen: because abspos elements' positions, once they're exclusions, can be affected by themselves.

[16:07] <fantasai> Rossen: We're proposing this approximation to solve the exponential problem.

[16:07] <fantasai> Rossen: Can it be improved, sure. Would like to keep running times fairly linear and keep approximation better.

[16:08] <tantek> does "how do we make this not exponential���" mean "how do we make this not max out the CPU and fans on our laptops" ?

[16:08] <fantasai> dbaron: I agree that we shouldn't have an exponential performance problem. But I'd rather solve that by coming up with a system that doesn't need it than by coming up with the wrong results.

[16:08] <fantasai> dbaron: ... If people want to z-index things, they'll use relpos ...

[16:09] <fantasai> dbaron: If you use exclusions with in-flow things, you'll still end up off.

[16:09] <fantasai> ...

[16:09] * Liam Quit (Ping timeout)

[16:09] <fantasai> Alex: Better algorithm is known to exist, but isn't used due to perf.

[16:10] <fantasai> Alex: For exmaple if you do layout for floats, you can have O(n) or more than that.

[16:10] <fantasai> Alex: I'm still worried about it.

[16:10] <fantasai> vhardy: Maybe best way is to publish WD and collect issues

[16:10] <fantasai> vhardy: There were 3 proposals that were considered, we went over them in Seattle, and this is the result of consolidating

[16:11] <fantasai> vhardy: Our request is to publish as WD so we can have comments and iterate on it

[16:11] <fantasai> vhardy: People say its hard or complicated, put it to the test by implementing.

[16:12] <fantasai> dbaron: Basically once we decide to publish something as a WD, it keeps moving whether we like it or not. So to some extent, that's the point we decide whether this a model that we want.

[16:12] <fantasai> dbaron: And I'm not at all convinced that this is a model that we want.

[16:12] <fantasai> Steve: What exactly are you not convinced about?

[16:12] <fantasai> dbaron: Largely the tie-in to the abpos model

[16:12] <fantasai> Molly: Is that a preference for a float model, or not specific?

[16:12] <fantasai> Rossen: What's the alternative?

[16:13] <fantasai> Alex: Would you prefer this kind of exclusions to only apply a new kind of floats and define that to have a better behavior?

[16:13] <fantasai> dbaron: I would like to see some of this stuff work in terms of new types of floats, like what howcome's done with page floats.

[16:13] <fantasai> Alex: this doesn't do anything about float collisions, they overlap

[16:13] <fantasai> Alex: There are issues with error accumulation

[16:14] <fantasai> Alex: I think both are really almost out of scope of the exclusions spec. they define what happens with shapes

[16:14] <fantasai> Alex: If we define new kind of layout, still have to figure out these problems of overlap and positioning backwards.

[16:15] <fantasai> Alex: There are problems in the spec. If the things exclusions apply to, if they were not anything including abspos. If they only applied e.g. to page floats, it would still have these problems, right?

[16:15] <fantasai> dbaron: Not exactly, because the page float model still has places in document order I believe

[16:15] <fantasai> Alex: can you have them overlap?

[16:15] <fantasai> howcome: Only if you do negative margins. By nature they avoid each other

[16:15] <fantasai> Rossen: Would they affect each others' wrapping?

[16:15] <fantasai> howcome: no

[16:16] <fantasai> Bert: All the examples of exclusions seem to be doable with shapes

[16:16] <fantasai> Bert: maybe you only need shapes

[16:16] <fantasai> vhardy: ...

[16:16] <fantasai> Bert: assume this is one <p> element with 2 columns. THe shape is a donut shape, but it's still the shape of the <p> itself. don't need any other elements for it

[16:17] <fantasai> Bert: Advantage of that is you don't need to invent some pseudo-element to create that circle.

[16:17] <fantasai> Bert: oh, you're using an empty element. Oh that is a no-no. Don't create elements just to create shapes.

[16:18] * heycam is now known as heycam|away

[16:18] <fantasai> several: It's just an example

[16:18] <fantasai> Bert: In the next example, you don't need exclusions, you just need three shapes

[16:19] <fantasai> Rossen: What you're suggesting was also suggested by glazou. He suggested using bg image as exclusion.

[16:19] <fantasai> Arno: Works for static layout only

[16:19] <fantasai> dbaron: I don't think this works for interactive media either.

[16:19] <fantasai> Bert: The circle there is not expanding.

[16:19] <fantasai> Rossen: It's percent sized

[16:20] <fantasai> Tantek: In terms of content.

[16:20] <fantasai> fantasai: So I see several concerns here.

[16:20] <fantasai> fantasai: One is error accumulation vs. performance

[16:20] <TabAtkins_> scribenick: TabAtkins_

[16:21] <TabAtkins_> fantasai: Another one is the actual fluidity of the layout with respect to different amts of content, different font sizes, page sizes, etc.

[16:21] <TabAtkins_> fantasai: I see a lot fo example here that have fixed sizes, that wouldn't work well if you increased the font size.

[16:21] <TabAtkins_> arno: That's just an example with the examples, though, right?

[16:22] <TabAtkins_> fantasai: Not necessarily. A circle would have an explicit size in real content. You may need a shrink-to-fit circle.

[16:22] <TabAtkins_> fantasai: To see that the spec authors aren't considering this kind of concerns me, because you have to make sure that dynamic unpredictable content is handled.

[16:22] * heycam|away is now known as heycam

[16:22] <TabAtkins_> Rossen: We're not doing anything to prevent shrink-to-fit. Any abspos will, by default, be shrink-to-fit.

[16:23] <TabAtkins_> Rossen: So making it an exclusion won't change that.

[16:23] <TabAtkins_> Rossen: What you may be actually concerned about is a problem with *shapes*, not exclusions.

[16:23] <fantasai> fantasai^: because that's the kind of environment we operate in

[16:23] * szilles Quit (Ping timeout)

[16:24] <TabAtkins_> Topic: CSS Shapes

[16:25] <TabAtkins_> Rossen: Shapes are a way to define geometry for exclusions (how stuff outside the element wraps around it) or the inside (how contents are wrapped inside of it).

[16:25] <fantasai> Note, shouldn't the term "flow container" be "block container" per 2.1?

[16:25] <TabAtkins_> Rossen: We are proposing 2 ways to define the shape itself.

[16:26] <TabAtkins_> Rossen: An SVG-like syntax, with functions matching the SVG geom primitives.

[16:26] <TabAtkins_> Rossen: And a way to reference an image (raster or SVG) that defines the shape automatically.

[16:26] <TabAtkins_> Rossen: The idea here is that wrapping around elements becomes quickly boring if done solely around rectangles.

[16:27] <ChrisL> Chris: can it point to path in that case

[16:27] <ChrisL> Rossen: yes

[16:27] <TabAtkins_> Rossen: So for that, we're introducing 'shape-outside', which can be applied to exclusions.

[16:27] <TabAtkins_> Rossen: Initial value is 'auto', which computes to the box of the element.

[16:27] * tantek is very happy to finally see CSS Shapes formally proposed.

[16:27] <TabAtkins_> Rossen: 'shape-inside' has the same values plus one, ''outside-shape'', which refers to the outer shape.

[16:28] * BradK Quit (Quit: Buh bye)

[16:28] * tantek refers to circa 2001 example: http://tantek.com/CSS/Examples/shapes.html

[16:28] * shepazu has joined #css

[16:28] <TabAtkins_> Rossen: By default, we want content that is nicely wrapped around as a circle to also wrap its contents as a circle.

[16:28] <tantek> developed soon after / based on: http://tantek.com/CSS/Examples/polygons.html

[16:28] <TabAtkins_> Rossen: You can do that, or define an entirely new shape.

[16:29] <TabAtkins_> Rossen: -inside and -outside are coupled by default, but you can give different values if you want.

[16:29] <TabAtkins_> jdaggett_: With 'shape-inside', if you have a donut, does text flow around the hole?

[16:29] * fantasai supposes we'll need 'outside-shape' and 'inside-shape' keywords for 'background-clip', too

[16:30] <TabAtkins_> fantasai: The 'outside shape' represents the border box/margin box.

[16:30] <TabAtkins_> fantasai: Shape-inside shapes the content box.

[16:31] <fantasai> fantasai^: outside shape shapes the impact of the element on surrounding content

[16:31] <fantasai> fantasai^: inside shape affects the containing block shape for the content of the element

[16:31] <TabAtkins_> Rossen: [shows an example from the spec with "C" shapes and content flowing into the "space".

[16:32] <TabAtkins_> vhardy: [explains the example in more detail]

[16:32] * gamakichi has joined #css

[16:33] * gamakichi has left #css

[16:34] <TabAtkins_> Rossen: The contents of an element with a donut shape fill in the entire area of the shape.

[16:34] <TabAtkins_> jdaggett_: I'd like to use this with a type shape, like having a giant A with text flowing around and through the holes.

[16:34] <TabAtkins_> Rossen: Yes, that can be done if you extract the shape.

[16:35] <TabAtkins_> jdaggett_: It would be nice to have text as a built-in shape.

[16:35] <TabAtkins_> Bert: Q about shape-outside.

[16:35] <dbaron> q+ to ask about commas

[16:35] <TabAtkins_> Bert: Some time ago we came up with the case that the shape to wrap around is an image.

[16:37] <TabAtkins_> Bert: So it looks like you'd have to repeat the url of the image both in <img> and in 'shape-outside'. We previously had a value called 'contour' that would automatically grab the image when specified on an image.

[16:37] <ChrisL> If you point to a raster image, does it threashold the alpha map to get the image shape?

[16:37] <TabAtkins_> <img id=shape-me url=foo><style>#shape-me { shape-outside: contour; }</style> //equal to 'shape-outside: url(foo)'

[16:38] <ChrisL> Vincent: Yes there is a threashold

[16:39] <fantasai> ACTION: Make attr() function do the right thing wrt resolving relative URLs

[16:39] * trackbot noticed an ACTION. Trying to create it.

[16:39] * RRSAgent records action 6

[16:39] <trackbot> Sorry, couldn't find user - Make

[16:39] <fantasai> ACTION fantasai: Make attr() function do the right thing wrt resolving relative URLs

[16:39] * trackbot noticed an ACTION. Trying to create it.

[16:39] * RRSAgent records action 7

[16:39] <trackbot> Created ACTION-383 - Make attr() function do the right thing wrt resolving relative URLs [on Elika Etemad - due 2011-11-06].

[16:39] <TabAtkins_> So that would be shape-outside: attr(src as url);

[16:40] * shepazu Quit (Quit: shepazu)

[16:40] <TabAtkins_> bradk_: Another feature request - have a keyword to grab the background image, rather than repeating yourself.

[16:40] <TabAtkins_> Bert: What about if there are multiple background images?

[16:41] <TabAtkins_> Rossen: Daniel brought that up in the last f2f - there were a lot of limitations.

[16:41] <TabAtkins_> dbaron: In CSS2 there was a property called 'clip', where the examples had commas and the formal syntax didn't. We resolved that by allowing both.

[16:42] <TabAtkins_> dbaron: This spec has the same problem, but the other way around.

[16:42] * szilles has joined #css

[16:43] <TabAtkins_> TabAtkins_: I'd prefer to match SVG and make commas optional.

[16:44] <TabAtkins_> Rossen: Our preference now is to move forward on a WD.

[16:44] <TabAtkins_> howcome: What if we throw out shapes and only do images?

[16:45] <fantasai> Tab: I'll note the spec is silent on what to do for animated GIFs

[16:45] <TabAtkins_> Rossen: We looked at a lot of examples in print media, where wrapping around images was used a lot.

[16:45] <TabAtkins_> Rossen: Like SI with lots of athletes with text around them.

[16:46] <TabAtkins_> Rossen: But with shapes, it makes it nice to have a really simple way to do this.

[16:46] <TabAtkins_> ChrisL: Agreed.

[16:46] <TabAtkins_> Rossen: Maybe we could reduce the set of types to circle, maybe polygon?

[16:48] <TabAtkins_> TabAtkins_: While hakon was joking about animated gifs, I'm not. That needs to be defined. Maybe first frame?

[16:48] * JohnJansen Quit (Quit: Page closed)

[16:48] <TabAtkins_> jdaggett_: What about animating shapes in Transitions?

[16:48] <TabAtkins_> TabAtkins_: SVG knows how to animate shapes, so we can do that.

[16:48] <TabAtkins_> ChrisL: I'd like to see this pushed out for wider review at this point.

[16:49] <TabAtkins_> dbaron: I'm scared that what's happened lately is that pushing something to TR means we're calling for implementations.

[16:50] <fantasai> TabAtkins_: Could we address dbaron's concern by adding a scary notice?

[16:51] <fantasai> glazou: It's a Working Draft. It's already a *Draft*.

[16:51] <fantasai> glazou: Proposal is to publish FPWD provided the issues list is updated

[16:52] * szilles Quit (Ping timeout)

[16:52] <fantasai> RESOLVED: Publish FPWD of Exclusions

[16:52] <fantasai> Topic: Style Attributes

[16:53] <fantasai> Arron: I didn't finish the implementation report yet, but I ran all the tests, all three of them.

[16:53] <fantasai> Arron: There needs to be three other tests, but all browsers pass except one case which is passed by 2

[16:53] * JohnJansen has joined #css

[16:53] <fantasai> dbaron: Is there a test for rejecting if there are braces around it?

[16:53] * szilles has joined #css

[16:53] <fantasai> fantasai: yes.

[16:53] <fantasai> Arron: I'll try to finish off tonight.

[16:54] <fantasai> ACTION Arron: finish implementation report and tests

[16:54] * trackbot noticed an ACTION. Trying to create it.

[16:54] * RRSAgent records action 8

[16:54] <trackbot> Created ACTION-384 - Finish implementation report and tests [on Arron Eicholz - due 2011-11-06].

[16:54] <fantasai> ACTION fantasai: Publish test suite and implementation report on w3.org

[16:54] * trackbot noticed an ACTION. Trying to create it.

[16:54] * RRSAgent records action 9

[16:54] <trackbot> Created ACTION-385 - Publish test suite and implementation report on w3.org [on Elika Etemad - due 2011-11-06].

[16:55] <fantasai> Topic: Selectors 4

[16:55] <fantasai> glazou: Selectors L4 triggered a major reaction from web designer community because of subject selector and :matches()

[16:55] <fantasai> glazou: I can see that people don't really understand that presence of a feature in a WD doesn't mean it will be in an implementation

[16:56] <fantasai> glazou: I would like us to, at least for :matches() and subject selector, to clean up things asap

[16:56] <fantasai> glazou: If it's not going to be implemented by browser vendors because it doesn't fit into your strategy or impl architecture,

[16:56] <fantasai> glazou: then remove it from the spec quickly

[16:57] <fantasai> fantasai: :matches() is already implemented

[16:57] <TabAtkins_> glazou: My fear is just that if we have something nice on paper that we find is too expensive to code, we should remove it quickly.

[16:58] <TabAtkins_> fantasai: I think trying to cut off brainstorming work because people will interpret it wrong is bad.

[16:59] <fantasai> fantasai: the subject indicator may wind up in batch processors

[16:59] <TabAtkins_> glazou: I'm not saying that, just that if our brainstorming finds something isn't implementable we should remove it as quickly as possible.

[16:59] <fantasai> fantasai: could be done in browsers, but will require careful optimization work

[16:59] <fantasai> fantasai: so may take awhile to find out

[16:59] <TabAtkins_> arno: Do we know if anyone's currently planning to implement it?

[17:00] <TabAtkins_> fantasai: There are tons of features - it's a very early stage draft - so we don't know that yet.

[17:00] <TabAtkins_> glazou: I just didn't expect such a massively positive reaction to it as we got.

[17:00] <TabAtkins_> szilles: So this falls into "careful what you promise, they might ask for it".

[17:01] <TabAtkins_> glazou: So I'm specifically asking for devs to evaluate implementability as soon as possible on that feature.

[17:02] <TabAtkins_> fantasai: What's in :matches() is absolutely implementable, since it's just syntactic sugar.

[17:02] <TabAtkins_> fantasai: So we don't need feedback on that.

[17:02] <TabAtkins_> fantasai: (At least, not immediately.)

[17:02] * BradK has joined #CSS

[17:02] <TabAtkins_> fantasai: It's the subject indicator that needs feedback.

[17:02] * Bert to fantasai: typo in selectors4: ':dir' and ':any-link' are not marked as level 4.

[17:02] <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=418039 is the Mozilla bug on :subject

[17:02] <TabAtkins_> tantek: What about :has()?

[17:03] <arno> indicator -> selector

[17:03] <TabAtkins_> tantek: It's in jQuery, it's been adopted and liked.

[17:04] <TabAtkins_> fantasai: I specifically went away from that because it's harder to ipmlement.

[17:04] <TabAtkins_> TabAtkins_: Simple useful example: "label:has(:checked) + p"

[17:05] <TabAtkins_> fantasai: You can use :matches() and the subject indicator to do the same.

[17:05] <Bert> (Tab's example doesn't work, does it? The p is not a sibling of the label, but a sibling of the labels's parent.)

[17:07] <TabAtkins_> fantasai: "label:matches(? > :checked) + p"

[17:07] * kermit has joined #css

[17:08] <TabAtkins_> fantasai: [explains her example further]

[17:08] <dbaron> Clearly we should just use the ��� operator or the �� or �� operator.

[17:08] <tcelik> please no more symbols with strange meanings

[17:08] * tcelik prefers to avoid CSS hieroglyphics

[17:08] * hober CSS IS *&@%#&*%^ AWESOME!

[17:09] <dbaron> ok, how about the ��� symbol :-)

[17:09] * szilles Quit (Ping timeout)

[17:11] <TabAtkins_> dbaron: The spec should say that using the subject indicator twice in a selector makes it invalid.

[17:12] <TabAtkins_> tantek: I still think :has() is a superior syntax. If you want to put restrictions on its functionality to match the subject indicator, fine, but use the better syntax.

[17:13] <dbaron> Let's avoid Dr. Streetmentioner's 1001 Tenses for Time Travelers

[17:13] * szilles has joined #css

[17:13] <TabAtkins_> fantasai: The interesting cases that :has() allows are precisely those that are much harder to implement.

[17:14] <TabAtkins_> fantasai: Selectors *never* go down multiple branches when matching, right now.

[17:14] <TabAtkins_> fantasai: Tab's example requires going down one branch and then going down another.

[17:15] <TabAtkins_> Bert: The XPath syntax may be eaiser here, where it has an explicit ancestor selectors.

[17:15] <TabAtkins_> dbaron: It's less hard to implement, than that it's hard to track dynamic changes.

[17:16] <TabAtkins_> dbaron: For example, if you're selecting (in Tab's example), when the input is checked or not, you need to quickly figure out which elements need to be restyled, without redoing the entire page's layout.

[17:17] * szilles Quit (Ping timeout)

[17:17] <TabAtkins_> RESOLVED: Publish Style Attribute PR as soon as we have the impl reports.

[17:17] * anne has joined #css

[17:22] <TabAtkins_> Topic: GCPM

[17:22] <TabAtkins_> howcome: I'd like to talk about what's new.

[17:22] * kermit Quit (Quit: http://www.mibbit.com ajax IRC Client)

[17:22] <TabAtkins_> howcome: Most of this is based on page flaots, but also paged overflow.

[17:23] <TabAtkins_> howcome: You can tell an element to overflow into pages.

[17:23] <TabAtkins_> tantek: So it's a manual <marquee>?

[17:23] <TabAtkins_> howcome: The other thing from GCPM is page floats. These photos [in his slides] are floats spanning multiple columns.

[17:24] <TabAtkins_> howcome: It works even better on a tablet.

[17:24] <TabAtkins_> howcome: So basically we can create an e-reader.

[17:25] <TabAtkins_> howcome: Paged layouts have been used forever in real life. Also in lots of apps, like flipboard.

[17:25] <TabAtkins_> howcome: [shows an example of paged wikipedia]

[17:25] <TabAtkins_> howcome: It has a lot of nice properties.

[17:25] * drublic Quit (Client exited)

[17:25] <TabAtkins_> howcome: It avoids cut lines on the top and bottom of the screen when scrolling, frex.

[17:26] <TabAtkins_> howcome: Some things were *designed* for paged presentations, like children's book.

[17:27] <TabAtkins_> howcome: There's tons of gutenberg text, for example, that nobody will read because it's not paged.

[17:27] <TabAtkins_> [shepazu objects]

[17:27] <TabAtkins_> howcome: We've ipmlemented it in Opera, and have a shadow DOM for it.

[17:27] <TabAtkins_> s/shadow DOM/OM/

[17:27] <TabAtkins_> howcome: [shows example of some presentation showing the current page, etc.]

[17:28] <TabAtkins_> howcome: It's very simple. The basic setup is with a 'paged' value for overflow, and the nav is done through an at-rule.

[17:28] <TabAtkins_> plinss: How does it print?

[17:29] <TabAtkins_> howcome: Quite well. Opera doesn't print well, but if you pipe it to a good printing tool, it works well.

[17:29] <TabAtkins_> plinss: When you're doing pagination of an element in the page, what happens when you print the whole page? Where's the overflow?

[17:30] <TabAtkins_> howcome: [shows the code example to set it up]

[17:30] <TabAtkins_> fantasai: Since the overflow property on <html> is propagated to the viewport, you don't need the height:100% there.

[17:30] <TabAtkins_> fantasai: Last time, we were thinking of having 'paged' be a value for overflow-style.

[17:30] <TabAtkins_> howcome: Yes, 'overflow' is a shorthand. The value can go anywhere, it doesn't matter right now.

[17:31] <TabAtkins_> howcome: You can distinguish between pages being side-by-side, or below each other.

[17:31] <TabAtkins_> tantek: In Japanese, you get pages right to left.

[17:31] <TabAtkins_> fantasai: So you also have to check writing-mode, not just direction.

[17:32] <TabAtkins_> howcome: Right. If I say "paged-x", I take whichever logical direction is horizontal.

[17:32] * heycam is now known as heycam|away

[17:32] <TabAtkins_> shepazu: The scrollbar gives nice discoverability of how much content is left. Is that still there?

[17:33] <TabAtkins_> shepazu: Could there be a property that adds an indicator of the expected flow left?

[17:33] <TabAtkins_> shepazu: "If there's another page, put an indicator there"

[17:33] <TabAtkins_> plinss: There's an example in the spec with "paged-x-controls" for that, I guess.

[17:33] <TabAtkins_> glazou: How does this interact with @page rules?

[17:34] <TabAtkins_> howcome: Right now, our impl doesn't pay attention. In the future, if you set the viewport to be overflow:scroll, it'll interact.

[17:34] <TabAtkins_> howcome: If a line runs over the page (in the direction perpendicular from the main scrolling direction), it just gets cut (you can't see it in any way).

[17:34] <TabAtkins_> howcome: Same as with multicol.

[17:35] <fantasai> Tab: These us multicol, so you have columns: 3 or whatever.

[17:35] <fantasai> Tab: If you're using columns, the overflow columns are to the side.

[17:35] * heycam|away is now known as heycam

[17:36] * dino Quit (Quit: dino)

[17:36] <fantasai> fantasai: The columns are not overflowing the box. They're overflowing the page, and go to the next page. It just happens that the next page is physically placed to the side rather than below in this case.

[17:36] <fantasai> howcome: you see this in tablet apps, that do this repeatedly

[17:37] <fantasai> howcome: This is a very simple sketch.

[17:37] <fantasai> howcome shows page shift effects

[17:37] <fantasai> Brad: I think that should be up to the UA, so the UA can provide a consistent interface

[17:38] <fantasai> glazou: I don't see it as only for tablets. It's a wonderful spec to match the effects of switching slides in a powerpoint

[17:38] <fantasai> glazou: I think the primary usage of that will be slideshows, much more than tablet browsing

[17:38] <fantasai> molly: possibly, but I can see designers really loving it

[17:38] <fantasai> glazou: You can define navigation between 2 pages in same document, or between 2 documents.

[17:39] <fantasai> glazou: One issue we have with slideshows to dissolve one slide and show the next slide; we don't have the next slide yet when we load the document.

[17:39] <fantasai> molly: I want to make the case for this and not just slide shows.

[17:39] <fantasai> molly: Anyone read the NYT? Exactly what people are doing in NYT reader

[17:39] * myakura has joined #css

[17:39] <fantasai> molly: it's being adopted a lot esp by older users who are not computer-savvy

[17:40] <fantasai> howcome: Met with NYT last week, who are doing all this in JS. They are saying please save us from the javaScript

[17:40] <fantasai> howcome: I'm really euphoric about this. I think it's the best thing that's happened in a long time.

[17:40] <fantasai> sylvaing: Since the Romans!

[17:41] <fantasai> howcome: It's so simple. No new properties, just new values on existing properties

[17:41] <fantasai> howcome: And then it's the at-page tihng, which attaches to link elements in HTML

[17:41] <fantasai> howcome: here we tie thse relationships to the directions with an at-rule

[17:41] <fantasai> howcome shows example of @navigation using link-rel() notation

[17:41] <fantasai> howcome: If we want to compete with the apps here, I think we need to provide this form of interaction

[17:42] <fantasai> plinss: I think it's great on the root element

[17:42] <fantasai> plinss: When its on the child element, and you turn the page, what happens?

[17:42] <fantasai> howcome: Here it's on the child element

[17:42] <fantasai> plinss: Now hit print.

[17:42] <fantasai> howcome: I see your point.

[17:43] <fantasai> fantasai: I think you should print the page over again with the next child page until you run out of content in the child

[17:43] <fantasai> fantasai: Would solve lots of problems with fixed positioning

[17:43] <fantasai> fantasai: Although it would be weird if you had more than one paged child

[17:44] <fantasai> Tantek: Shouldn't print starting at what you're looking at, should print the entire document.

[17:44] <fantasai> Tantek: Wrt slideshows, it's horrible because then you don't get anchors to the slides

[17:45] <fantasai> tantek: If you do it with anchors tags, HTML5 history, fine. I've built that.

[17:45] <fantasai> Tantek: But you can't do dynamic paging with anchors

[17:45] <fantasai> plinss: It's the same problem of scrolling down to a page and wanting to point someone at that point.

[17:46] <fantasai> Tantek: yes, but the expectation is different: if I'm on a page, I expect to send a link to the page. If I'm in a scrolling document, I expect a link to that page to point at the top

[17:46] <fantasai> ...

[17:46] <fantasai> howcome: If I'm at the end of the document, it goes to the next one

[17:47] <fantasai> Doug: How do you know what's the next document?

[17:47] <fantasai> howcome: with HTML <link> tags

[17:47] <fantasai> howcome: you tie them to the navigation like this

[17:47] <fantasai> Doug: As you go to a new page with a fragment identifier, you update to that fragment identifier. That solves Tantek's problem.

[17:48] <fantasai> Tantek: Multiple navigation with a child?

[17:48] <fantasai> jdaggett: If you have 2 elements that are paginated

[17:48] <fantasai> Tantek: You'd have to scope per fragment the navigation rules if you have a paged child inside a paged document

[17:49] <fantasai> glazou: Just use a page break there. Define a page break after your sldies

[17:49] <fantasai> howcome: For slides that's fine. But for a newspaper article you don't want all the newspaper articles in one document.

[17:50] <fantasai> howcome explains url-doc()

[17:50] <fantasai> glazou: I think you shoudl resurrect selectors on the right-hand side. This is too specific to HTML. Should be able to do this in any kind of markup

[17:50] * anne Quit (Quit: anne)

[17:50] <fantasai> glazou: Should be able to retrieve URLs from link anywhere in the prose.

[17:50] <fantasai> glazou: Smells like selector on right-hand side of property

[17:51] <TabAtkins_> We have an existing function that can be used here - element()

[17:51] <fantasai> glazou: Looks like attr(link[rel=index], href)

[17:51] <fantasai> Doug: there's nothing HTML-specific about link relationships

[17:51] * myakura Quit (Connection reset by peer)

[17:52] * myakura has joined #css

[17:52] <fantasai> glazou: Next step that you are going to take H��kon is showing multiple pages into one single viewport

[17:52] <fantasai> glazou: To be able to select 5th page directly for example.

[17:52] <fantasai> glazou: So I suggest you think about this andput it in your proposal

[17:53] <fantasai> howcome: I'm going ot show you a book I printed in CSS.

[17:54] <fantasai> howcome: This is a replication of {...} from 1879. Each word on exactly the same page.

[17:55] <fantasai> Bert: If I swipe right to the next document, expect that going left brings me back. But that depends on the navigation styles in the other document

[17:55] <fantasai> Steve: I think it's a mistake to put the navigation in the style here. If you want to link together a bunch of document, should have some kind of manifest.

[17:55] <fantasai> plinss: this is outside the scope of CSS, but yes there's a use case for some kind of manifest that expresses these relationships

[17:57] <fantasai> fantasai: The links among documents can be expressed in HTML. The bit that's out-of-scope is mapping those to navigation gestures

[17:57] <fantasai> ...

[17:57] <fantasai> plinss: It should be next and previous

[17:58] <fantasai> howcome: That's already in the HTML, don't need the CSS.

[17:58] <fantasai> Tantek: Request to add a photo of the folks that were here 7 years ago

[17:59] * jdaggett_ Quit (Quit: jdaggett_)

[17:59] * ChrisL Quit (Ping timeout)

[17:59] <fantasai> Steve: I think there's a difference between what happens in a document, which you specify wiht paged-x and paged-y, and what happens across documents, where I don't think it's the role of CSS to say. But getting to the end of a document is an event, and you could say what happens when you get to that event.

[17:59] <fantasai> glazou: I have a lot of comments on your document.

[17:59] * vhardy Quit (Quit: vhardy)

[17:59] * JohnJansen Quit (Quit: Page closed)

[17:59] <fantasai> howcome: Email probably works better if we want others to participate as well.

[17:59] <fantasai> howcome: So this is most of what's new in the GCPM. Maybe continue tomorrow?

[17:59] <fantasai> Meeting closed.

[17:59] * glazou Quit (Quit: glazou)

[18:00] * stearns Quit (Quit: stearns)

[18:00] <fantasai> book was Digte by Henrik Ibsen

[18:00] * bradk_ Quit (Quit: Computer has gone to sleep)

[18:02] * howcome Quit (Ping timeout)

[18:02] * plinss Quit (Quit: plinss)

[18:02] * Rossen Quit (Ping timeout)

[18:02] * TabAtkins_ Quit (Ping timeout)

[18:02] * alexmog- Quit (Ping timeout)

[18:02] * arronei_ Quit (Ping timeout)

[18:02] * mollydotcom Quit (Quit: mollydotcom)

[18:03] * sylvaing Quit (Ping timeout)

[18:04] * kojiishi Quit (Ping timeout)

[18:05] * heycam is now known as heycam|away

[18:05] * tcelik Quit (Quit: tcelik)

[18:09] * arno Quit (Quit: Leaving.)

[18:09] * tantek Quit (Quit: tantek)

[18:09] * dbaron Quit (Ping timeout)

[18:11] * shans Quit (Ping timeout)

[18:12] * BradK_ has joined #CSS

[18:14] * kojiishi has joined #css

[18:15] * BradK Quit (Ping timeout)

[18:15] * BradK_ is now known as BradK

[18:17] * kojiishi Quit (Ping timeout)

[18:22] * arronei_ has joined #css

[18:23] * arronei Quit (Ping timeout)

[18:29] * BradK Quit (Quit: Buh bye)

[20:04] * myakura Quit (Client exited)

[20:50] * stearns has joined #css

[20:53] * dbaron has joined #css

[20:57] * stearns Quit (Client exited)

[20:57] * stearns has joined #css

[20:59] * sylvaing has joined #css

[21:04] * glazou has joined #css

[21:04] * glazou Quit (Quit: glazou)

[21:16] * arronei has joined #css

[21:23] * arronei Quit (Ping timeout)

[21:24] * shepazu has joined #css

[21:28] * arronei has joined #css

[21:28] <arronei> fantasai: you mentioned the template that I should use for the IR. Can you point me to it?

[21:31] * shepazu Quit (Quit: shepazu)

[21:35] * dino has joined #css

[21:46] * arno has joined #css

[21:46] * arno Quit (Quit: Leaving.)

[21:53] * dbaron Quit (Quit: 8403864 bytes have been tenured, next gc will be global.)

[22:11] <arronei> fantasai: ping

[22:14] * dino Quit (Quit: dino)

[22:24] * heycam|away is now known as heycam

[22:42] * sylvaing Quit (Ping timeout)

[22:50] <fantasai> arronei: pong

[22:51] <fantasai> arronei: http://www.w3.org/Style/CSS/Test/CSS3/Namespace/20090210/reports/implement-report.html

[22:51] <fantasai> arronei: sorry, was studying gradient syntax

[22:58] * arronei Quit (Ping timeout)

[22:58] * florian has joined #css

[23:02] * florian has left #css

[23:27] * florian has joined #css

[23:28] * florian has left #css

[23:31] * arronei has joined #css

[23:44] * arronei Quit (Ping timeout)

These logs were automatically created by CSSWG_LogBot on irc.w3.org using the Java IRC LogBot.