- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Mar 2016 17:32:01 -0400
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Snap Points ----------- - RESOLVED: The only pseudo elements that snap points apply to are ::before/::after but add a note that suggest there "might" be a future pseudos that can support snap points. - There needs to be more use cases before deciding how to behave with snapping to unreachable elements. - Still no decision on renaming proximity and mandatory. Current suggestions are near|always, force|allow, force|proximity, force|near or keep the original names. - RESOLVED: Defer 2D snap to the next module level of snap points bookmark-level: auto -------------------- - bookmark-level will stay the same in CSS Break. Sizing ------ - gregwhitworth will investigate if min-width on tables is possible. ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/sydney-2016 Scribe: gregwhitworth Snap Points =========== Applicability to pseudo-elements -------------------------------- florian: Not sure how much we can do without Matt R. and Tab <astearns> https://lists.w3.org/Archives/Public/www-style/2016Jan/0193.html florian: The snap points spec does not say whether pseudo elements can have snap points or not. florian: The pseudo spec implies that everything should work unless there is an exception. florain: Snap points not having an exception they should apply. florian: There are many specs that say it one way, others another and some don't at all - so assumptions are made and at times are incorrect. rossen: This is in context of snap points why? florian: Because I wasn't sure. dbaron: The way to solve this is to find a spec that should have a definition for this and assign the all elements and hyperlink to a definition to that. <dbaron> i.e., there should be a hyperlink in Applies to: <a>all elements</a> with the anchor linking to something that says "all elements" includes ::before and ::after. fantasai: Any spec that states specifically applying to ::before ::after should be removed unless it's stating that it's excluded. ACTION TabAtkins to change bikeshed to: there should be a hyperlink in Applies to: <a>all elements</a> with the anchor linking to something that says "all elements" includes ::before and ::after <trackbot> Created ACTION-753 <tantek> question, what do implementations do with snappoints on :before and :after? florian: The second part of the question is can you have snap points on other pseudo elements other than ::before/::after - TabAtkins said no astearns: Usecase is to snap to spelling errors. rossen: There's scrollTo for that type of thing, tantek: ::first-line you wouldn't. tantek: It's not cut and dry. fantasai: There has to be a clear use case as it's significant implementation cost to achieve this. fantasai: I'm not convinced to add this to the spec unless there is author demand. fantasai: You might want to have it snap into the viewport, but that's an edge value. florian: I think ::before/::after are compelling. fantasai: For consistency sake. rossen: Even they're on the border. plinss: I'm confused about future things, and I don't like constricting it pointlessly. florian: It's due to implementation complexity. plinss: Think about pseudos for columns, paged etc - we shouldn't set a precedent. fantasai: I would happily introduce a ::column pseudo that takes only the scroll-snap properties. rossen: It's most useful on structural elements. plinss: If it's a big barrier I'm ok with a should. rossen: For us it is. fantasai: I would prefer not to add it now, because of the additional testing. fantasai: The pseudo draft says whether it applies or not, and when we add more we can add them in. astearns: That means in the future if we have compelling use cases for this we can bring them back in to have support. astearns: In general closing them off now, does this close them off forever. rossen: No - just for this version of the spec. esprehn: I don't think you're ever stuck, we can just add more properties if necessary. esprehn: As an implementor, anything other than ::before/::after is really hard. tantek: There has to be a way to spec an opening for more pseudos. plinss: I'm open to a note that says we may apply this to new pseudos in the future. tantek: I'm ok with an informative note, I don't want to mislead people. RESOLVED: The only pseudo elements that snap points apply to are ::before/::after but add a note that suggest there "might" be a future pseudos that can support snap points. Snappability of unreachable elements ------------------------------------ Scribe: ewilligers florian: If a snap point has always been beyond reach, and you scroll beyond, Florian: (draws on board) [Florian draws a scroller, with snap-padding on the top and bottom.] [There's a large element, fills the size of the viewport] [There's also a tiny element, at the bottom of the scrollable area] [Both request center snapping] <alancutter> Photo of Florian's diagram: http://imgur.com/27CdHCU Florian: It has a somewhat large snap-padding area. Florian: We have a large element with a center snappoint, some margin, Florian: a small element with a center snappoint, Florian: the snappadding is larger than the small element. Florian: There is no way that you can scroll the small element into the center. Florian: The spec is vague / contradicting itself - two parts of the spec. fantasai: That is a valid snap point. Florian: One: things that are unreachable would be the most appropriate to snap to, you must snap to them. Florian: Spec does not clarify "most appropriate" Florian: Second part of spec: if an element is entirely outside the scrollsnap area, it is not considered. Florian: Suspect was intended for 1d scrolling. Florian: Lots of things should be up to UA, but not this. Florian: Making things reachable should not be UA dependent. Florian: Spec is ambiguous. "Must" part relies on ambiguous term. fantasai: We should reorder the paragraph. Expected snap position is bottom of screen. Florian: The part of spec that says you must snap to it use ambiguous words. Other part of spec contradicts: part that speaks about corridor, Florian: accidentally contradicts "if you never enter the scroll area, not considered." esprehn: As a user, what do you want to have happen? Florian: I think it is a wording issue. fantasai: We need a specific wording proposal. astearns: The next step is for Florian to propose a wording change, send to the list. Florian: Based on tab's answer, I thought there was actual disagreement. Florian: Spec describes 3 types of scrolling, ... semantic scrolling, inertial scrolling, 4th type: indirect scrolling: move focus, or change carat. no wording in spec. fantasai: Explicit scrolling is scroll to specific position. Florian: You are not scrolling to specific position. On focus, scroll is a side effect. Do we have invisible carat / focus button. It is not clear. fantasai: There is a section in spec that Tab and I added, dealt with target case. <fantasai> "If a page is navigated to a fragment that defines a target element (one that would be matched by :target), and that element defines some snap positions, the user agent should snap to one of that element’s snap positions. The user agent may do this even when the scroll container has scroll-snap-type: none." fantasai: The user agent should snap... So should we apply this to more cases like :focus? Florian: What happens if container has mandatory snapping and element does not have a snappoint? fantasai: You need to be careful with mandatory snap position. Authors need to be careful. Florian: Other option: things that match the target pseudo class and focusable things and editable things in a mandatory scroll container if they are not within things that have a mandatory snappoint, have a snappoint. hober: I prefer first option. Florian: In that case, the magic is not that hard, but if we want to go without, make clear to authors. Scribe: ewilligers, alancutter esprehn: I want to talk to accessibility people. Florian: As currently defined it will not. Florian: I think the magic is something we can work and and will be useful. zcorpan: Web authors will hate this. zcorpan: It gives behavior they didn't ask for. zcorpan: In general we should avoid magic stuff. gregwhitworth: While I sympathize with authors, end users will expect endpoints when they hit tab. gregwhitworth: I would prefer accessible users to see input that is selected over the preferred behavior of web authors. esprehn: People make their browser different sizes that produces bad situations. zcorpan: You are talking about keyboard navigation. zcorpan: When navigate by keyboard, user tabs between form controls. zcorpan: I would expect snapping to not happen. gregwhitworth: I think that's what we're saying, we should put together a bunch of test cases. gregwhitworth: We could potentially fake it in some cases. gregwhitworth: I don't know if we can resolve but it's worth testing. Florian: We need to eventually resolve this, gregwhitworth: Sure. Indirect scrolling ------------------ Florian: I have a related other topic, also about indirect scrolling. Florian: Focus on something, moving the carat, proximity snapping. We have a button with no snappoint. Florian: There's nothing to prevent scrolling into visible area. astearns: If this is the email that you sent on the mailing list we should wait for editors to respond. Florian: If this in not a good time to talk let's talk later. Naming of proximity/manditory ----------------------------- Scribe: ewilligers, alancutter, esprehn fantasai: There was a bikeshedding discussion to have, about the naming of proximity/mandatory astearns: What are the proposed names? fantasai: The proposal was "near" and "always". Any other ideas? esprehn: Sounds great. Florian: I prefer the current one. astearns: The benefit to near and always is shortness and we use it in other CSS things. Florian: We removed them. Rossen: I prefer proximity and mandatory. <zcorpan> have these shipped? <fantasai> yes, but we removed everything that shipped <zcorpan> ok astearns: Sometimes it's good to have bikeshedding face to face but it seems like it's not working right now. fantasai: force / allow? <fantasai> scroll-snap-type: none | force | allow 2-d snapping keep or push out ----------------------------- esprehn: We support shipping a minimal subset. dbaron: Not sure what we currently implement. ojan: Our people working on snapshots are not here. esprehn: They're interested in shipping an interoperable implementation. Rossen: Is there an official resolution to this in Sapporo? Rossen: Can we put this for resolution? hober: We didn't have an exact resolution in Sapporo. Florian: If this is something we all agree on at-risk is fine. At risk is the wrong tool and we should remove it. dino: We don't want to be the trail blazers and implement it and find it's not useful. Florian: At Risk allows you to do that. dino: If the other implementors don't want to do it what's the point? rossen: This is a really awesome feature, when we ship it would be great if we can without prefix/holding back. Florian: We don't want to drop it and end up with a spec we can't add it back to. hober: We have version control. <zcorpan> hober++ fantasai: We already accounted for this in the text. dino: We appreciate the great work from TabAtkins and fantasai, dino: but we want the spec to be merged soon so we can implement soon, dino: not saying keep it out forever. fantasai: Florian is saying we don't want to make changes in the merge that make it impossible to go back to the 2d design later. fantasai: I don't think that'll be a problem. fantasai: That's not what we resolved on, but I don't think that'll be a problem. astearns: I think we have consensus? RESOLVED: Defer 2D snap to the next module level of snap points Naming of proximity/manditory ----------------------------- astearns: Force and allow snapping, much shorter words. SteveZ: Doesn't say the same thing. Florian: Permit is a good synonym for allow. SteveZ: Force is a verb, it needs to be a verb... esprehn: What's the default value? Florian: None. esprehn: Why not auto? <zcorpan> none | force | auto Florian: Proximity is auto? Rossen: Auto is the default word for magic. Florian: It's hard to guess what it does from the name, proximity is more clear. <zcorpan> none | force | proximity dbaron: Near and exact? Rossen: Force and proximity sounds good. Florian: Force and proximity makes force sound like a noun when it is a verb. shans: What about exact? Florian: Exact is bad, it sounds like you have to go exactly to that point. dbaron: We seem to be happier with nouns and adjectives than verbs. <Rossen> none | force | near bookmark-level: auto ===================== astearns: Next thing, bookmark level auto. <astearns> https://lists.w3.org/Archives/Public/www-style/2015Nov/0310.html Florian: I want to talk about bookmark-level. Florian: There is a set of properties, bookmark-level. When you generate PDF, Florian: The bookmark you get in PDFs that take you to certain parts of the document. Florian: The nesting of your sections seem like something derive from the structure of the document instead of Florian: requiring authors to define it. Florian: "auto" could derive this structure for the author. esprehn: Which thing does not exist? Florian: Bookmark-level: auto, this should be something you can figure out from the structure of the document. Florian: Instead of manually specifying it. Florian: Things could get out of sync. esprehn: Does any one implement bookmark-level? Florian: Print formatters do. Florian: This will lower the work required to take a document for the screen to a PDF with bookmarks. Florian: I don't think we can do this with selectors. Florian: I tried existing selectors including non-implemented ones and failed. esprehn: auto doesn't seem very hard to implement this (as an implementer that doesn't implement bookmark-level) esprehn: As long as it's not like counters in CSS I support this. plinss: I kind of have a fundamental issue of why are we reinventing hyperlinks? esprehn: I don't want reset, skip, increment, etc. again. Florian: I don't mean we should mandate how a sidebar works. plinss: This whole feature smells like something very specific to PDF and has nothing to do with the web platform. astearns: dpub folks have been talking about an explicit <nav> element with links. astearns: I don't think it's adding a random feature it's streamlining a process. fantasai: There are multiple implementations of bookmark-level. Florian: Viviostyle has it in their roadmap to implement this for screens. esprehn: I think this is part of CSS and shouldn't be treated as a separate focus group. esprehn: Thinking of Houdini this is not the way we want to go with CSS. esprehn: We want to add extensibility points instead of magic. Florian: What is magic about it? SteveZ: It's a table of contents. plinss: If you want an element that generates a table of contents that should be part of the document not CSS. Florian: Our engine needs to implement this to be compatible with existing content. plinss: Table of contents is content, not styling. SteveZ: A table of contents is a relabeling of content. It's presentational. plinss: I disagree. SteveZ: It's taking existing content and putting it elsewhere in the display. skk: The bookmark sounds like a data structure and not like styling. esprehn: With custom properties you can define the bookmark level property to do whatever you want and we don't have to talk about this. Florian: It has three interoperable implementations, it's not a new feature. tantek: Let's see the usage numbers, if it's like 10... Florian: Should I go to WHATWG for this, is the CSSWG not allowing this? Florian: I can't do this with houdini with current browsers. esprehn: I don't think this fight is productive, there's an out now for this. Florian: This is a request for a new keyword for an existing property. Florian: Not about removing this property from CSS. astearns: We are not going to resolve modifying or removing this property today. <zcorpan> in httparchive 470k pages i see one page matching bookmark-level in css (actually prince-bookmark-level:1) http://www.wowrean.es/ http://eu.wowrean.es/public/print-default.css Fragmentation and Transforms ---------------------------- <Florian> http://jsbin.com/fuloge/edit?output Florian: If you open this, it appears that Chrome and Webkit do one thing. Florian: Other browsers, and print formatters, do something else. Florian: Chrome and WebKit are the only ones that get this right. Florian: It's a list of numbers positioned relative down. dbaron: You have to use frame source. It doesn't work in jsbin. dbaron: The question is "does position relative work across pagination?" Florian: I think the spec says... <Florian> https://drafts.csswg.org/css-break/#transforms dbaron: Is this CSS break? This is a new spec, newer than the implementations. Florian: Am I correctly understanding that the spec is asking for Chrome's behavior? astearns: The spec is a bit older than David represented. <dbaron> OK, the spec is 4 years old <dbaron> still newer than all implementations astearns: It ended up this way so we would not lose content when paginating with relatively positioned content. dbaron: Does Chrome get this right because it gets all the other parts of this section wrong and it gets this right? Florian: We're wondering what our implementation should match. esprehn: Firefox looks like it's moving all the content down in each column. astearns: Both behaviors have their uses. astearns: Either in printing or in scrollable situations. astearns: I think Firefox's behavior looks nicer in this case. esprehn: We implement this section of the spec wrong. Florian: So after fixing you're likely to match Firefox? fantasai: This rule is only about pagination, not about columns. fantasai: The reason for that is if you don't do that you lose content. fantasai: We recommend that for printing we do this slicing after having transforming stuff. esprehn: I suspect our response is we will not implement this, multicol implementors have said this seems very complicated. <gregwhitworth> In addition, I opened a bug on Chrome that deals with multicol that got duped to this one, and it's assigned - they may be able to address this while they're in this code: https://code.google.com/p/chromium/issues/detail?id=223068 <gregwhitworth> not be there should not be an option IMO Florian: I'm not happy about the "should", some browsers will behave different. fantasai: I would rather a should than nothing at all. dbaron: I'm skeptical about "should" because it takes a lot of energy to implement this and browsers are probably going to implement something else. dbaron: I'd rather not add complicated things to specs for things no one implements. <fantasai> "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." <fantasai> RFC2119 esprehn: We are interested in an interoperable version of multicol, we're not interested in anything fancy. Florian: Once that happens all browsers and print formatters will do the same thing. hober: We don't want to regress with regards to the epub corpus; too much there. Florian: I have my answer regardless of what the spec ends up saying. astearns: Sounds like a good place to leave this. fantasai: If Hyatt has a *better* solution, be happy to consider that for the spec. astearns: Shane wants to have a talk about scroll linked animations. astearns: The second thing is koji had an additional topic if you're ready. astearns: We have <30min left. [Discussion of word-break: break-word; moved to CSS3 Text section of minutes.] Sizing ====== fantasai: Do we know whether we can switch table cells to honor the min-width property? gregwhitworth: I don't have data but I'm shocked that you can't use it. gregwhitworth: We can gather data. fantasai: Proposal if it's possible: min-width applies to table cells. dbaron: We could add properties that set the intrinsic widths, unlike the min/max-width properties that set constraints on the width ... useful outside of tables. ACTION gregwhitworth: look into allowing min-width on tables to work, and auto to work like it currently does - will require test cases for L2 of tables and possibly sizing as dbaron said it's helpful for intrinsic sizing beyond tables. <trackbot> Created ACTION-754 fantasai: Let's switch to sizing. fantasai: Was talking to Tab about sizing module. fantasai: Our proposal: Taking keywords that we have and define them in terms of CSS2.1 (which makes them mostly undefined) instead of trying to define thme fully. fantasai: ... This would let us trim down the spec a lot. astearns: Sounds like a fine plan, make the edits, send to working group and see what feedback you get. <fantasai> https://drafts.csswg.org/css-sizing/ fantasai: Dropping chapter 4 and 5, and fill-available keyword astearns: Anyone object to this idea? Florian: Does this limit us to refer to these concepts? fantasai: No you can still refer to them in Sizing 4. astearns: I'm not comfortable with resolving on this strategy just yet as we've only had 5 minutes to think about it. fantasai: I have an issue with alignment but I'll talk to dbaron first. astearns: Adjourned.
Received on Wednesday, 23 March 2016 21:32:59 UTC