- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 29 Aug 2011 01:26:11 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary: - RESOLVED: publish CSS3 Text and CSS3 Writing Modes as WDs with updates mentioned in minutes - Deferred Selectors 4 publication until Selectors 3 hits REC in a couple weeks - RESOLVED: use flow-from property to enable regions, mark interaction with 'content' and 'display' as an issue - RESOLVED: CSS Regions has a region break like multicol and start on css3 pagination module and Mozilla/Adobe/MS would sort out the editorship of that spec - RESOLVED: TabAtkins to create a proposal for print bgs ====== Full minutes below ====== Present: Tab Atkins Arron Eicholz Elika Etemad Arno Gourdol John Jansen Peter Linss Divya Manian Alex Mogilevsky Edward O'Connor Florian Rivoal David Singer Alan Stearns Steve Zilles <RRSAgent> logging to http://www.w3.org/2011/08/24-css-irc Administrative -------------- plinss: anyone else has anything to add to the agenda? Publishing Writing Modes and Text --------------------------------- plinss: bunch of publishing requests plinss: css3-texts and writing modes. SteveZ: John sent a note about writing modes florian: the wording is not strong enough about being an unresolved problem here and he put out an alternative wording fantasai: is that something I can fix and publish? or should I hold off? SteveZ: the wording was only two sentences. Cant speak for John florian reads from the email fantasai: that is not actually possible. we can get close to it but there is a problem with characters like quotes, where default orientation needs to be upright if the font supports vertical and sideways otherwise stevez: that is not how vertical tables work stevez: that is separate. you can't expect a vertical table to tell you what to do for the orientation florian: we agree there is a difficult problem here, rather than saying we "may" try we should say we "will" try. florian: it is not guaranteed that we will successfully find a solution. stevez: John publsihed a test case that shows that there is no uniform implementation across browsers, and none of the existing unicode properties would allow you to map to the upright characters. The point being there is no simple solution and can't say what the browsers do, and cant say do what unicode does. stevez: there is a separate effort to define a unicode property to define implementation, but thats separate. fantasai: we currently use Unicode properties to group most characters fantasai: but we have a very long list of exceptions. fantasai: and in some cases we do not have a good answer yet. plinss: are we in agreement with John's sentiment here? plinss: anyone opposed to that. plinss: I take that as a consensus florian: I am not sure about how to resolve the issue, but I am with him on the concern on that. fantasai: I would like to take a quick look at florian's issue. fantasai: I have a patch for that I want to check with the rest of the people here before I check that in. florian: I have not been able to look at my mail last weekend fantasai: I linked to it from my message requesting publication. <florian> http://lists.w3.org/Archives/Public/www-style/2011Aug/0427.html florian: there are 2 types of values in text-combine-horizontal property. florian: I am suggesting we can split these into two properties. The visual effect of squeezing text in is likely to be the same across document florian: but not what is being squeezed florian: if you split them it would reduce repetition florian: I do not have a good name for that. florian: what do people think about the idea. szilles: I have not thought about it, what you are saying makes sense. I prefer in general binary switch for turning things off and on, and a different property for the variance florian: that's my idea as well plinss: do we have any suggestions on this? florian: so we agree to split? fantasai: I put 'text-combine-mode' in my draft florian: it's better than what I said plinss: are we happy to publish with that change? szilles: yeah, it is still a draft szilles: I think the principle that florian is espousing is a good principle RESOLVED: publish CSS3 Text and CSS3 Writing Modes as WDs with updates mentioned florian: Wrt details of text-combine, I am convinced the wording we now have is a good representation of the conclusion we reached at F2F. so that is solved as far as I am concerned. Selectors 4 ----------- plinss: when are we going to publish the first draft of Selectors 4. W3C decided to wait until namespaces is out. Should we wait until selectors 3 is a REC or decide to publish it now? Anyone has strong opinions on that? arronei: with selectors 3 is it just held up by namespaces right now? szilles: you get less confusion if you wait and publish selectors 4 after the 3 REC goes out plinss: I agree, but I am not sure if its that big of a deal florian: I think we said the same thing at last f2f. as long as selectors 3 went to REC quickly then we have no issue, how long as we willing to wait. plinss: did you see note about updating drafts for epub? fantasai: I don't know if fonts draft needs to be published or not. plinss: we will discuss those two over email and get some feedback from the editors (who are not here) Regions ------- plinss: display-inside and content property plinss: where are we on this alexmog: we had a conversation with vhardy we have not agreed on a resolution. alexmog: my issue is using content it has a lot of meaning and behaviour in generated content as it interacts with model of ::before and ::after. alexmog: the use of that kind of content, might change the meaning of the element it is in and blows away before and after and we do not mean that content property alexmog: display property could be one way to do that or a separate from-flow property alexmog: if we had a display-inside property it would say display-inside: region and something else that would say where content comes from. It may be content property szilles: we have talked about having a region be a multicol, which is why I am not happy about display-inside: region. I like the principle of having a separate property that turns something into region and then say what properties apply to region rather than putting of content in it turning on. alexmog: multicol will be display-inside if display-inside existed szilles: why not create a diff property with region yes/no with no as default vhardy: we could also go with the option of alexmog which is you have a flow-from property which would be what you are asking for and also say which region you are applying content form. The only tweak from your proposal, alex, is that ::before and ::after work on a region vhardy: we would be okay using flow-from proposal as it is close to what szilles is saying szilles: yes and no. it is using to say where text comes from to turn it into a region and I was trying to separate those two, but I am not strongly of any position. I can live with either alexmog: similar to float: positioned which we used to trigger exclusions and appears redundant as you also have to use wrap-type everytime you use that property. alexmog: so we ended up adopting adobe's solution, and here we use the same szilles: it is a valid point, and I can live either way fantasai: I think having two properties seems like too many levels of indirection. vhardy: I propose we try to resolve on flow-from and having before and after work with current pseudo selectors TabAtkins: what happens when you do flow-from form elements that is also a grid or flexbox vhardy: we have a resolution that says you can only turn something into a region if it is a block container box TabAtkins: the reason I wanted display-inside was to prevent unwanted interactions. TabAtkins: it is similar to what columns do. fantasai: still concerned about the interaction but have nothing concrete to say fantasai: interaction with display, and the content property as we are overriding with a different property alexmog: flow-from has a very diff meaning from content alexmog: content overrides WITHIN the element. <bradk> What if we had content:flow-from() take the children of the named element, instead of the item itself? alexmog: flow-from overrides everything. alexmog: that is inside this element. it does not change the meaning of content. it just replaces everything within. fantasai: content property was intended to control what the contents are, and now we have another property that does essentially the same thing. fantasai: the most obvious thing that is changing is the contents of the element are not being displayed in favour of something else. fantasai: seems like a problem to me. * hober agrees with fantasai vhardy: I think it is slightly different vhardy: you specify what content goes into the element vhardy: pull the content and this will be figured out at layout. alexmog: what content property does is replaces the content of the element alexmog: flow-from does is what the box is showing plinss: I had a proposal in kyoto we use flow-from property and then use content property plinss: maybe we need another keyword to access actual content of the element rather than the flow content fantasai: the initial value of content property is normal, so normal computes to diff things depending on what the element is fantasai: it computes to list marker on a list marker, etc <bradk> content:flow-from() could replaces the content of the element with the contents of the flow. plinss: normal could compute to flow-from on elements that have a flow-from vhardy: I am not sure I understand what this means szilles: the normal behaviour of content could be if you have flow-from, use it. plinss: if you say flow-from and content, content wins so you have a keyword within content. alexmog: I think flow-from should win fantasai: I don't want to hold off progress on resolving other issues. I don't want to consider this resolved, but I am fine with picking a solution and working with it. vhardy: what is the solution we are going for? alexmog: I completely disagree with that * nimbupani agrees with alexmog szilles: if you want to be able to use ::before and ::after you want to fit it into the model alexmog: ::before and ::after does not feed into region flow szilles: vhardy said he would like to feed into the regions model alexmog: I don't know what it would mean to have content ::before that is float right and have that merge with multicol flow vhardy: the feedback I got was that we should specify the behavior of ::before and ::after when element is a region alexmog: for ::before and ::after that would be special meaning do something different when they apply to a region szilles: it isn't completely different which is why people suggest we use it vhardy: can we go with doing a new iteration on ED using flow-from and trying to resolve what we can do with before/after vhardy: plinss you talked about using another keyword to define actual content. vhardy: plinss you talked about using another keyword to define actual content. plinss: the proposal in kyoto, there is a separate proposal on adding a 'contents' keyword so you can combine the content that is already there. plinss: I dont know if we need that, that was a separate proposal vhardy: for now we can live without that. szilles: I think it would be useful to put the issue under flow from that we need to clarify the interaction between the fow from and the content property. vhardy: I was proposing to say something in the draft vhardy: we iterate on the draft and have a new ED proposed for the next F2F, and we can have an issue on the review of the new WD. alexmog: lets keep it an issue. <alexmog> have we resolved "use 'flow-from' property to enable regions, add an issue to the draft to define interaction with 'content' and 'contents'" ? RESOLVED: use flow-from property to enable regions, mark interaction with 'content' and 'display' as an issue vhardy: following the resolution about breaks to be container specific or region specific as decided on Seattle, I aligned it with multicol. vhardy: issues I raised on seattle meeting are not region specific they affect multicol pagination as one thing vhardy: how do breaks work in nested regions, multicol and when you start combining different kinds of break. it spans regions multicol and pagination vhardy: I dont think this is the right place to handle in the regions spec. what do we do about it? do we have a separate spec for breaks? alexmog: my biggest concern with region break was that while behavior of page-break is undefined we would be creating a separate syntax for something that means something exactly same as page break or has same effect in same media plinss: we redefined breaking property in multicol vhardy: we already resolved to have a region break florian: when we want diff kind of break for diff kind of thing and we need to think about carefully. fantasai: we need a css3 pagination module? vhardy: maybe. alexmog: yeah that would be great to have one. we can ask for volunteers to write it. fantasai: there is some interaction with Paged Media spec. fantasai: we might want to sync paged media spec to css 2.1 and push that out and have css3 pagination and then add whatever we need to add fantasai: the multicol spec defines aliases it was kinda expecting paged media to do that definition fantasai: maybe we can pull that into a separate module vhardy: sgtm plinss: who is going to work on the pagination module fantasai: I probably should do that fantasai: I hope its okay if I don't start until sept or oct fantasai: will be working more on pagination stuff this fall in either case. alexmog: MS and Adobe are most motivated people so maybe we and you should talk about it and figure out who should write the spec vhardy: yeah fantasai: Paged Media needs to go to CR mostly as-is, featurewise. fantasai: But I can copy out various pieces we need from paged media and create a framework RESOLVED: CSS Regions has a region break like multicol and start on css3 pagination module and Mozilla/Adobe/MS would sort out the editorship of that spec <vhardy> http://dev.w3.org/csswg/css3-regions/#region-flow-break-properties-break-before-break-after-break-inside Topic Switch ------------ plinss: Conformance markup within the spec TabAtkins: can we talk about print backgrounds fantasai: can we talk about css 2.1 test suites? plinss: whats the issue? fantasai: apparently Gérard Talbot filed a bunch of issues but has not received a response about getting them fixed fantasai: is MS planning to maintain those tests or do we need to find a new owner? arronei: I can make changes whenever we feel its right plinss: no reason not to make updates. arronei: I can start working on it then Printing Backgrounds -------------------- <florian> http://wiki.csswg.org/ideas/print-backgrounds plinss: TabAtkins is saying if we can get a resolution in printing bg last week TabAtkins: wiki page did not facilitate new discussion TabAtkins: 1. do nothing 2. add a hint that lets author provide extra info so UA can make a better choice florian: 1 and then come up with a UI that lets user switch based. TabAtkins: are you asking me to come up with a new browser UI for all browsers florian: seems like browsers have not made effort on print yet. Option 1 is not silly and use ?? as heuristics it is not that silly plinss: there is no way we can get reasonable heuristics. And there are print scenarios that do not have a direct user interaction ??? I like whats in 3 alexmog: using !important TabAtkins: !important is already doing wrong things and it is not just bgs. alexmog: printing bgs is unique situation where browser refuses to display something that was specified. it is a special feature alexmog: there is no other issue like that. we can create !print fantasai: we should have the principle that if someone has done the right thing, they should do one simple thing and it should just work fantasai: they should not have to rewrite the stylesheet fantasai: !important does not fit that bill alexmog: what is your preferred answer, TabAtkins florian: are we aligning with prop 7? <florian> I was just asking fantasai's position, not everybody's plinss: print media stylesheet is not sufficient TabAtkins: 2 to 6 are unusable TabAtkins: I am for option 7 alexmog: is this for document or elements TabAtkins: either way TabAtkins: putting on doc is 7.1 TabAtkins: individual pages is 7.2 TabAtkins: any of them works. alexmog: it could be a meta tag arronei: print or anything like that says we know better than you. the user needs to decide. arronei: as vendors we decided not to print bgs by default. if we decide to print bgs by default, we need to engage the community and teach authors that they need to author good stylesheets for print TabAtkins: we will not be changing browsers to print bgs by default arronei: now you need to provide a notification that you will be printing insane amount of stuff on these pages. ???: we need people to write good stylesheet alexmog: if we add an option to print bg we will never need user override with that. <dsinger> printed backgrounds sometimes make the print unreadable alexmog: browser it is okay to print what the author has done that. the lack of the property means this is the old page and use it the old way. <dsinger> making users miserable with the default is no way to educate site authors to make better stylesheets fantasai: an interesting heuristic to check would be if canvas has a bg that is not white then probably the page is not designed to print with ink plinss: I dont think the simple heuristic is good enough. <oyvind> I'm sure plenty of pages have white/transparent html/body and put everything in some div TabAtkins: I have designed pages with no canvas bgs and elements that span the canvas having bg dsinger: bg by default would make users miserable <alexmog> <meta http-equiv="X-UA-Print-Background" content="always"/> <szilles> I support Alex's point: that adding a flag, probably on the document, that says honor the style, would allow migration to using suitable 'print' stylesheets TabAtkins: are we going to make a decision or are we going to continue be undefined TabAtkins: we are unable to make any decision on this whatsoever alexmog: we are closer to a decision TabAtkins: don't do it at all or do it with a property, there is no useful conversation out of this. I am not sure how to proceed. TabAtkins: I am not seeing any progress towards a conclusion alexmog: you have proposal on the wiki alexmog: we can have things that are not in css but apply to whole doc TabAtkins: if we decide there is a mechanism for this, that would be sufficient for my needs. TabAtkins: can we assume 7 covers all variations on this idea? plinss: I propose we elect to do something plinss: I think we should move forward anyway. plinss: tab should work on a concrete proposal get some implementation experience and if folks hate it we can revisit <szilles> +1 for Peter's proposal TabAtkins: cool for me RESOLVED: TabAtkins to create a proposal for print bgs
Received on Monday, 29 August 2011 08:27:11 UTC