00:26:46 RRSAgent has joined #css 00:26:46 logging to http://www.w3.org/2009/03/05-css-irc 00:27:01 trackbot, start meeting 00:27:03 RRSAgent, make logs member 00:27:03 Zakim has joined #css 00:27:05 Zakim, this will be Style_CSS FP 00:27:05 I do not see a conference matching that name scheduled within the next hour, trackbot 00:27:06 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 00:27:06 Date: 04 March 2009 00:27:16 Zakim, remind us in 8 hours to go home 00:27:16 ok, dbaron 00:27:23 RRSAgent, make logs public 00:27:35 Meeting: Cascading Style Sheets (CSS) Working Group Meeting 00:27:50 Date: 05 March 2009 00:30:49 shinyu has joined #css 00:31:13 anne has joined #css 00:31:34 howcome has joined #css 00:38:31 Topic: Grouping Page Selectors 00:39:04 howcome: With regular selectors you can group them by comma, but with page selectors you can't do that 00:39:11 p, div { ... } is valid 00:39:16 @page foo, bar { ... } is not 00:42:04 Agreement that this is a sensible thing to do and we should add it to CSS 00:42:43 fantasai: I'm not sure if Melinda would be ok with adding this to level 3 00:43:03 Murakami-san: Our new version supports this 00:43:47 RESOLVED: Add to CSS3 Page as at-risk feature, if Melinda objects make it a note that we will add it in the future 00:44:50 Topic: Values and Units 00:45:11 howcome: What's the interface between the syntax module and the values and units module? 00:45:18 dbaron: I think it's ok as the draft is now 00:45:30 howcome: There's a couple of things I'd like to update in the syntax module 00:45:45 dbaron: Update what? 00:45:56 dbaron: I don't think we have much to put in it other than what's in 2.1 00:46:39 howcome: fantasai wanted to copy over the value definition syntax 00:47:05 http://www.w3.org/TR/CSS21/about.html#property-defs 00:48:32 dbaron: why not reference 2.1? 00:48:36 fantasai: I wanted to add && 00:52:37 http://howcome.gotdns.com/img/2009/03-04-tokyo/ 00:53:02 MikeSmith has joined #css 00:57:13 dbaron: I don't know that we even want &&; might be better to just write things out, potentially with sub-productions. 01:04:28 dbaron: Or just use || and say one of the parts is mandatory. 01:05:04 dbaron: (say via prose or via other syntax) 01:08:10 ||+ 01:13:50 dbaron: Could we put && in 2.1 even though 2.1 doesn't use it? 01:14:49 ACTION: fantasai to send message to www-style to explain rationale for && and see if somebody can come up with something better 01:14:49 Created ACTION-126 - Send message to www-style to explain rationale for && and see if somebody can come up with something better [on Elika Etemad - due 2009-03-12]. 01:15:08 RESOLUTION: Add && to 2.1 unless somebody comes up with something better, to avoid having to publish a syntax module for just that one new feature. 01:15:54 dbaron: My other comment on values and units was the cycle() feature 01:16:02 dbaron: I'm pretty sure we resolved to add it 01:21:23 howcome: ok, so it's my action point to add that 01:21:33 howcome: can you have recursive cycles? 01:21:57 dbaron: well, you /could/. In my message I explained how it would work. You can create a state machine with that, although it's not the best syntax 01:23:42 http://lists.w3.org/Archives/Public/www-style/2009Jan/0104.html has references to the proposed text 01:24:46 howcome: any other issues? 01:24:52 fantasai: Do you define whitespace? 01:25:01 howcome: yes, I added S tokens 01:25:06 http://dev.w3.org/csswg/css3-values/#the-calc-function 01:25:06 fantasai: whitespace should be required 01:26:01 fantasai: at least around the + - signs, because otherwise you have to retokenize inside calc() 01:32:09 dbaron: retokenizing in our implementation isn't that hard, because it's a hand-coded recursive descent parser and we can be mean to our tokenizer and send back pieces of tokens 01:32:42 dbaron: but if you are using a parser generator it's not so easy 01:32:49 dbaron: I think WebKit uses a parser generator 01:32:55 we implemented calc() allowing non-whitespace around + or - 01:35:02 fantasai: I'm concerned also about what we might want to allow inside calc() in the future. If we don't require spaces, that restricts our options. 01:35:27 dbaron: Yeah, so in our implementation we push pieces of tokens back to the tokenizer 01:35:36 our implementation of :nth-child() 01:35:49 dbaron: I suspect Webkit tokenizes :nth-child() as one token, and then hand parses that token 01:35:56 dbaron: which would be much harder to do with calc() 01:36:36 howcome: I suggest we put in the required spaces now. We can take them out later if we need to. 01:38:08 howcome: ok, so it's in the dev version now. Is anyone planning to implement this? 01:38:18 dbaron: in the medium term 01:38:30 Murakami-san: I'm ok with requiring or not requiring white space 01:38:52 Murakami-san: we implement this feature. We allow whitespace around the operators 01:39:10 Murakami-san: or no whitespace 01:40:40 Attendees: jdagget, dbaron, anne, mikesmith, sylvain, howcome, steve, fantasai, Murakami-san 01:41:22 two t's please 01:41:53 break 01:41:58 Present+ Masataka_Yakura 01:42:29 s/jdagget,/jdaggett,/ 01:50:33 Topic: Page and Column Breaking 01:50:45 howocome draws three boxes side-by-side on the board 01:50:55 The first box has an M followed by lines representing text 01:51:05 The second box has lines of text followed by a return arrow sign 01:51:17 The third box has an M followed by lines of text 01:51:54 Howcome labels the boxes 1,2,3 01:52:06 Howcome writes a small m at the top of 2 and crosses it out 01:52:33 Howcome: I think we need to resolve the page issue before deciding on the column break properties 01:52:47 howcome: The issue is, where to eliminate the top margin 01:53:09 Howcome: I don't think it should be eliminated at the start of the document 01:53:39 Howcome: The spec says the margins are eliminated at page breaks. 01:53:56 Howcome: The question is should it be eliminated at forced breaks 01:54:04 Steve: THere are three cases of page breaks. 01:54:11 Steve: page-break-before, page-break-after, and named pages 01:54:54 Howcome: I would be so confused by having different behavior for page-break-before and page-break-after 01:55:20 Steve: I am convinced that we should preserve margin on page-break-before 01:56:42 Steve: but not page-break-after 01:58:02 fantasai agrees with howcome 01:58:34 Murakami-san: I agree with howcome. Page-break-before and page-break-after should behave the same. 01:58:40 Steve: I want a use case for page-break-after 01:58:57 fantasai: Suppose I want to print CSS2.1 with breaks between sections and chapters 01:59:58 fantasai: I want page-break-before on each chapter, to separate out the chapters from each other and from the cover pages 02:00:20 fantasai: but I select page-break-after for the sections, because the beginning of the chapter is usually so short, just a title and maybe a paragraph or two 02:01:14 discussion of use cases and margins and breaking 02:03:27 Steve: Ok, I can live with it 02:03:44 Anne: It's really annoying for projection mode that the margin is collapsed at breaks 02:04:25 RESOLVED: margins kept at forced breaks for page-break-before and page-break-after 02:05:57 what about named pages? 02:06:39 if we collapse there, you always have the option of forcing the break to keep the margin 02:07:02 and you're not guaranteed a break, because elements assigned to the same name do not break in betweenm 02:09:12 one of the main use cases for named pages is e.g. putting a wide table onto a landscape page 02:12:34 RESOLVED: If a page-break-before, page-break-after, or use of named page forces a page break, then the margin top is preserved after the break. 02:24:42 Discussion of use cases for preserving margins at unforced breaks 02:24:51 there definitely seem to be some, e.g. for headings 02:25:09 Murakami-san proposes margin-before-conditionality: auto | discard | retain 02:26:34 howcome mentions that registration (preserving line alignment) might solve some of these problems 02:26:47 general agreement that this problem exists and we should solve it, but not for 3.0 02:27:01 margin-before-conditionality.. howcome objects to 'before' 02:28:21 suggestion margin-conditionality, can be treated as shorthand later if we need separate controls 02:28:31 Steve: 'conditionality' is hard to spell 02:28:55 Howcome: 'keep' instead of 'retain'? 02:29:00 seem to have agreement on that 02:29:05 discard seems to be ok 02:29:13 Other names: margin-collapse, margin-break 02:30:46 Looking at margin-break: auto | discard | keep 02:31:34 Murakami-san: what about the margin-after? 02:31:35 myakura has joined #css 02:33:11 fantasai draws margin-break: [ auto | discard | keep ] keep? 02:33:45 (well, first draws margin-break: [ auto | discard | keep]{1,2} but refines to above since margin is always discarded at bottom by default ) 02:34:29 Second value applies to margin-after. Defaults to discarding margin if not specified. 02:34:47 Murakami-san notes that this control also applies to the first margin in the document. 02:35:05 ACTION howcome add to GCPM draft as a holding place until next Paged Media draft is started 02:35:05 Created ACTION-127 - Add to GCPM draft as a holding place until next Paged Media draft is started [on Håkon Wium Lie - due 2009-03-12]. 02:36:20 LUNCH BREAK 02:36:53 margin-break: auto | discard | keep | keep-all ? 03:48:01 dbaron has joined #css 03:48:09 myakura has joined #css 03:51:21 howcome: the page-break properties control breaking across pages 03:51:34 howcome: the multicol draft has column-breamk proeprties to control breaking across columns 03:51:56 howcome: Some people have suggested to just use the page-break properties to control column breaks 03:51:58 s/breamk/break/ 03:52:06 howcome: this has two advantages. One it saves us two properties 03:52:07 s/proeprties/properties/ 03:52:29 howcome: and second it avoids having to discuss what happens when they conflict 03:53:02 fantasai: A third advantage is that the author only has to set things once 03:53:16 fantasai: e.g. want to avoid breaking between header and 1st paragraph, only set page-break-after: avoid; 03:53:43 howcome writes page-break-before: column 03:54:03 howcome: my main objection to this is aesthetic 03:54:38 howcome: so we could either have column break properties, or move to this here 03:54:47 sylvaing has joined #css 03:58:23 howcome: on the aesthetic side we also have everything match, since -inside is page-break-inside 03:59:10 Murakami-san: avoid affects only page breaks? 03:59:17 fantasai, howcome: should affect both column and page breaks 03:59:36 fantasai: If we need more fine-tuned controls, then we can add e.g. avoid-page in the future to avoid page breaks but allow column breaks 04:06:41 steve: don't like name 'avoid-page' 04:07:15 howcome: 'column-only' 04:07:27 howcome: page-break-inside: column-only 04:07:33 not much happiness about this 04:07:39 Steve brings up the XSL names 04:07:49 keep-inside: page | column | spread | auto 04:08:56 RESOLVED: page-break-before, page-break-after: column to force column breaks, other values apply to column breaking as well as pages 04:15:16 Topic: GCPM 04:15:29 howcome: we have two implementations of a significant subset of GCPM 04:15:37 howcome: there are certainly things that aren't implemented 04:15:58 howcome: So I propose splitting out the implemented bits and creating something more formal 04:19:13 howcome: named strings and leaders for example 04:19:59 fantasai: we could cut down the css3-content draft into the minimum things, then add those two and create a module from that 04:20:09 howcome: we need an editor 04:20:18 fantasai: well, I have to finish css3-page first, but it's next on my list 04:20:53 howcome: I'm not sure that's fast enough, prince and antenna house have shipping implementations 04:21:44 howcome: maybe we need a new official working draft 04:22:02 fantasai: How about marking the stable sections as stable, and the unstable experimental parts as such, and then publish it as a working draft 04:22:09 howcome and Murakami-san seem ok with this 04:25:00 RESOLVED: howcome to clearly distinguish features that are moving forward, then propose publishing a new WD 04:25:15 howcome: It would be good to know which features are in Antenna House's latest beta 04:25:33 howcome asks when fantasai can work on css3-content 04:26:03 fantasai: Selectors and css3-background are almost done, css3-page will take awhile, maybe 3 weeks full-time.. but I have other things to work on too. Let's check back end of April? 04:29:06 Murakami-san: We implemented named strings, leaders, cross-references, footnotes, hyphenation, new counter styles, character substitution, image-resolution and background-image-resolution, page-markes and bleed area, bookmarks, cmyk colors, page floats but limited to value top bottom page and footnote and inside and outside 04:29:15 Murakami-san: named page lists 04:29:22 Murakami-san: that's all 04:32:45 fantasai: wrt image-resolution, I think it should set the default image resolution for everything and not have background-image-resolution 04:32:56 fantasai: we use images lots of places, not just backgrounds 04:33:04 fantasai: border-image, list-style-image, content, etc. 04:33:08 fantasai: this solution doesn't scale 04:33:24 fantasai: if we need more fine-tuned control, then we can introduce a function 04:33:36 fantasai: that takes an image url and an image-resolution value 04:35:29 Steve doesn't understand the use cases 04:35:35 howcome: I was compiling a document for a conference 04:35:49 howcome: the images came from all over 04:35:55 howcome: I needed some way to set the resolutions 04:36:10 steve: So if you had a tool like Photoshop that lets you go in and set the resolutions 04:36:22 howcome: but i don't want to edit the image file, I just want to make sure the dpi is 04:36:40 dbaron: On the Web we pretty much have to ignore image data about resolution 04:36:58 dbaron: Raster images on the web are 1px - 1px 04:37:09 s/1px/1 image pixel/ 04:38:54 fantasai: I don't think this syntax makes much sense 04:39:10 fantasai: The only value that can have a fallback is auto, the comma isn't much necessary 04:39:44 fantasai: image-resolution: [ normal | ] || auto 04:41:06 Murakami-san: In our implementation the resolution can have two values, horizontal and vertical 04:43:54 fantasai proposes syntax: [normal || ?] || auto 04:46:02 szilles: I do not like 'auto' here; the keyword should indicate the purpose 04:46:09 anne: intrinsic ? 04:47:50 fantasai: normal | [ ? || auto] 04:49:12 howcome: do you often need two resolutions? 04:49:22 Murakami-san: we have some, but I don't know how necessary it is 04:49:32 howcome: would you like to see it in the spec? 04:51:04 Murakami-san: we would have it in Antenna House's implementation 04:51:22 general skepticism about whether images with non-square pixels are common enough 04:51:35 and whether image-resolution is in fact needed 04:51:54 i.e. the image itself could be fixed 04:52:31 Murakami-san agrees with the syntax change 04:52:48 RESOLVED: image-resolution: normal | [ || auto ] 04:53:29 fantasai: ok, wrt background-image-resolution 04:53:39 howcome: it's there because prince implemented it. I agree it's not a scalable solution 04:54:13 fantasai: Does image-resolution affect only images in the content, or also images specified in CSS? 04:54:17 howcome: I don't know 04:54:24 anne: what about video and stuff? 04:58:26 Sylvain and Anne are confused about normal and auto as names 04:58:32 Steve had suggested intrinsic 04:58:49 Anne: if there's an auto value it's usually the initial value 05:03:41 howcome: I could live with from-image instead of auto 05:04:21 fantasai: internal? 05:04:28 howcome: internal to what? 05:06:46 howcome: so from-image? 05:06:50 no comment 05:06:54 back to background-image-resolution 05:07:29 url-with-resolution("url", ) 05:08:30 fantasai: we dont' need a separate property for every CSS property that takes an image 05:08:43 fantasai: one that affects content and one that affects all CSS-specified images would be enough 05:09:19 suggestion to use a functional notation that would allow setting the dpi on a per-declaration level 05:11:45 howcome writes image("http...", 94dpi) 05:13:00 fantasai: my concern with the image() notation is that there are a lot of other things we've wanted to do with this, such as image slices and fallbacks 05:14:07 fantasai and others: shouldn't require url() notation, string is enough, for when you expect urls inside a function 05:14:20 anne and others: can allow it, but just not require it, like for @import 05:14:25 fantasai: but don't use it in any examples! 05:15:59 discussion around other gcpm properties 05:16:05 anne: it seems simpler to not allow it 05:16:41 anne: but for consistency's sake, we should allow it 05:17:40 RESOLVED: URLs inside functional notation where URL is expected should be able to take either url() or bare strings (like @import), preference for examples is bare strings 05:19:11 Review of auto vs. from-image 05:19:19 RESOLVED: image-resolution: from-image instead of auto 05:21:15 Options for getting rid of the background-image-resolution approach of exploding properties 05:21:28 1. image-resolution applies to both CSS images and content images 05:21:41 2. image-resolution takes two sets of values, one for content images and one for CSS images 05:22:14 3. create a new property that applies to all CSS-based images (not just backgrounds) 05:22:40 4. create a value-based syntax (functional notation) that sets the dpi on a per-image basis 05:22:50 5. Combine 4 with 1-3. 05:23:38 0. Do nothing (keep background-image-resolution) 05:23:48 6. Encourage Prince to remove backgorund-image-resolution but provide no alternative 05:30:14 discussion of various options and what they mean 05:30:30 Straw poll: 05:30:39 Mike: no opinion 05:30:44 Anne: 4 05:30:48 dbaron: 4 05:30:59 howcome: anyone volunteering for 4 has to do the work :) 05:31:57 jdaggett: no opinion 05:32:33 Yakura-san: I like 3 05:32:44 Yakura-san: You could expand the property by saying which properties it applies to 05:35:06 fantasai: I like 3+4, where 3 sets the default 05:50:15 discussion and whiteboard doodling 05:50:33 image-resolution-content and image-resolution-decoration in place of image-resolution and background-image-resolution 05:50:40 where image-resolution-decoration applies to all css-based images 05:50:51 background images, border-image, list-style-image, etc. 05:54:23 Proposal use 3 with 4 as the way forward 05:54:35 Counter-proposal to use 1 with 4 as the way forward 05:56:01 Murakami-san points out the distinction between list-style-image and ::marker { content: url(); } 05:56:24 Then the distinction between ::marker { content: url(); } and img { content: attr(href, url); } 05:57:41 There's no clear distinction between content and style 05:58:16 s/href/src/ 05:59:12 howcome: Ok, so I think we're down to one image-resolution property and 4 as the way forward 05:59:24 howcome: Implementations will do background-image-resolution, but that will not be part of the spec 06:01:35 Murakami-san: Prince's image-resolution only applies to all images 06:01:49 s/all/content/ 06:03:11 Murakami-san: The image-resolution and background-image-resolution pair is better for our implementation 06:03:54 Murakami-san: The content property with url() that replaces the element 06:04:48 Murakami-san: image-resolution-content applies to images specified by the content property with image URI 06:05:17 dbaron: There's also a distinction in CSS3 between a single image and multiple images 06:09:29 BREAK 06:24:13 melinda has joined #CSS 06:25:37 Topic: Multicol 06:25:48 howcome: I propose publishing css3-multicol as LC 06:26:46 howcome: understandable. Would like to smoke out any comments, get a sense that everything is pretty good 06:27:07 howcome: aside from today there've been no changes in syntax or functionality, just a lot of clarifications 06:28:01 fantasai: I think the functionality is quite stable, but it needs another round of review for clarifications etc. 06:28:16 fantasai: So if we're going to Last Call, then I would suggest at least 8 weeks rather than 4 06:28:19 howcome: ok 06:28:41 howcome: I will make those changes, prepare the draft for Last Call, then we can make the final decision once that's done 06:29:09 Topic: Media Queries 06:29:15 Anne: I made all the changes to Media Queries 06:29:20 Anne: So I would like to go to CR 06:29:27 Disposition of Comments: http://dev.w3.org/csswg/css3-mediaqueries/disposition.html 06:29:32 Draft: http://dev.w3.org/csswg/css3-mediaqueries/ 06:29:46 Topic: Multicolumn 06:29:57 Murakami-san: I feel there's a problem with the margins in multicol 06:30:33 A multi-column element establishes a new block formatting context, as per CSS 2.1 section 9.4.1. However, the top margin of the first element and the bottom margin of the last element collapse with the margins of the multi-column element as per the normal rules for collapsing. 06:30:38 http://dev.w3.org/csswg/css3-multicol/#the-multi-column-model 06:30:39 "" 06:34:31 Murakami draws on the board 06:42:24 Murakami shows some examples 06:42:41 He says that the margins should not collapse through the multicol element 06:42:51 Sylvain: Alex was concerned about this, too. 06:43:22 fantasai explains that this behavior was put there because in the past there was no value-based distinction between a multicol element with one column and a normal element, and we didn't want to introduce a discontinuity there 06:43:52 but since there's now a default auto value for column-count instead of 1, this problem doesn't exist 06:44:49 http://dev.w3.org/csswg/css3-gcpm/#creating 06:46:11 sylvain: Alex had some concerns about overflow 06:46:15 howcome: we discussed that at tpac 06:46:27 howcome: resolved to keep things as-is, and discussed adding overflow-style: paged 06:46:46 howcome: we also discussed creating stacks of column rows 06:47:49 fantasai: e.g. with a column-length property 06:48:03 fantasai: but we decided to defer that until later 06:48:31 ChrisL has joined #css 06:48:51 rrsagent, here 06:48:51 See http://www.w3.org/2009/03/05-css-irc#T06-48-51 06:50:19 glazou has joined #css 06:50:23 hello 06:50:25 morning! 06:50:52 Topic: Media Queries 06:50:56 where are the photos taken by Hakon Molly mentioned ? 06:51:05 fantasai: Any objections to publishing CR of Media Queries? 06:51:17 RESOLVED: publish Media Queries as CR 06:51:34 Chris: It would help if in the disposition of comments you had some color coding 06:51:40 glazou:http://howcome.gotdns.com/img/2009/03-04-tokyo/ 06:51:41 glazou: http://howcome.gotdns.com/img/2009/03-04-tokyo/ 06:52:18 MikeSmith has joined #css 06:52:24 dbaron: When I did the comments for CSS3 Color I colored rejected feature requests differently from other rejected comments 06:52:44 steve: what you really want to note is which resolutions the commentor didn't agree with 06:53:14 I received a request by email to extend MQ to detection of implementation of a pair (property, values) 06:53:32 glazou, we've heard that before 06:54:03 yes 06:54:03 glazou, too late for this level, anyway, as we just discussed :-) 06:54:15 dbaron: oh sure, I was just mentioning it 06:55:07 Topic: Backgrounds and Borders 06:55:27 http://www.w3.org/Style/CSS/Tracker/products/11 06:57:24 http://lists.w3.org/Archives/Public/www-style/2009Feb/0179.html 06:57:44 Whether various border shorthands should reset border-image 06:57:57 in order to give the author a blank canvas to set borders on 06:58:22 dbaron: Also a question is whether border-style should reset border-image 06:58:54 dbaron: since border-image is kind of like a border style 07:00:15 fantasai: I think the 'border' shorthand should reset border-image. Not sure about others 07:00:41 dbaron: complication is that border is no longer border-top+border-left+border-right+border-bottom 07:03:44 anne: why not just have border-image always override border-style? 07:04:08 dbaron: That's the current behavior. The concern is in complicated style sheets you won't always remember to reset border-image every time you use border-style 07:05:30 ... 07:05:34 +1 07:06:05 what dbaron said just above 07:06:51 fantasai: I think the two reasonable options here are to either have only 'border' reset border-image, or have any shorthand that sets border-style turn off the image 07:07:50 dbaron: or potentially any property that touchs the border-style, not just any shorthand 07:08:32 Steve: If only the shorthand turns it off, then to do something like change one value then I have to use the shorthand to get rid of the image 07:10:23 discussion of how authors in complicated style sheets set borders 07:12:56 anne: The resetting behavior seems like quite a bit of complexity for something the author can easily solve by resetting border-image 07:13:29 I also said that I expect sites that use border-image to use it consistently throughout and probably also specify border for backwards compatibility anyway 07:14:00 ... 07:16:07 fantasai: So, the advantage of having 'border' reset the border-image is that we can encourage authors to use it as a way to get a blank border canvas 07:16:25 fantasai: And this will work also in the future when we add more border properties: 'border' will always get you a blank canvas 07:16:52 fantasai: The advantage of having any shorthand that touches border-style reset the border image is that the process is pretty much invisible to the author 07:24:56 Options: 07:25:01 1. Do nothing. border-image always overrides 07:25:08 2. 'border' shorthand resets border-image 07:25:15 (and in the future, any other border-tweaking things) 07:25:35 3. any shorthand that touches the border-style properties resets border-image 07:27:35 Anne: was it considered to make border-image part of the border shorthand? 07:29:12 Straw poll: 07:29:14 howcome: 2 07:29:16 anne: 2 or 1 07:29:19 dbaron: 2 07:29:22 jdagget: 2 07:29:32 Yakura-san: 2 07:29:37 Murakami-san: 2 07:29:38 fantasai: 2 07:30:51 Steve: I dislike how border-image and border-style are independently turned on 07:31:02 Steve: If I add border-characters as my next property, how does it interact? 07:31:12 Steve: It seems like this isn't going to scale 07:31:53 jdaggett: Maybe for the example in the spec, have a use case that is closer to what people are actually requesting? 07:32:26 fantasai: I'm not a graphics person, we'd have to ask Brad Kemper to come up with one 07:32:56 fantasai: Anne's comment, should border-image be part of the border shorthand? 07:35:03 fantasai: We /can/ do that syntactically, if we place after any style/width/color bits 07:37:03 fantasai: So we can do either border: [ || || ] | ; 07:37:47 fantasai: Or we can do border: [ || || ] ; 07:42:49 fantasai: So we can do either border: [ || || ] || ; 07:43:35 [ || || ]?