- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 24 May 2016 19:35:17 -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. ========================================= Counters -------- - RESOLVED: Add new syntax (TBD) to control counter scoping and consider reversing too. - TabAtkins will write a proposal for this new syntax. Values & Units -------------- - plinss will file an issue with TAG to fix the general pushState/ url reference problem in the DOM. - RESOLVED: Add hidden state to hash-reference-only URLs so that they can always resolve locally in presence of pushState - RESOLVED: Adapt the element() function so that it can be used to refer to always-local references ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics Scribe: Shane Counters -------- <astearns> https://lists.w3.org/Archives/Public/www-style/2016Apr/0364.html TabAtkins: Ran into a fun example, author commented on what he thought was a mistake in list spec. [TabAtkins] draws a diagram <fantasai> Tab writes: <fantasai> <ol> <fantasai> <li> <fantasai> <li> <fantasai> </ol> <fantasai> <div> <fantasai> <ol> <fantasai> <li> <fantasai> </ol> <fantasai> </div> TabAtkins: interesting thing is if you manually set up counters TabAtkins: and use the counters() function dbaron: You're supposed to counter reset on ol:before, not ol. I think that avoids the bug you're about to describe. TabAtkins: IT DOES! [the crowd goes wild] <SimonSapin> dbaron: even if ::before has display: none? <SimonSapin> or content:none TabAtkins: So we should just adjust the spec to say ol:before instead of ol? dbaron: Assuming :before exists though. TabAtkins: Counter established by counter-reset on the first ol counts its siblings until the first one that resets but the next ol is a cousin, so it nests instead. TabAtkins: Few ways around it. (1) instead counter-reset on first li or on :before. Then scope only covers the list. TabAtkins: (2) explicitly resetting a counter when it came from something that wasn't in the ancestor chain then reset instead of nesting. Florian: Wouldn't that fail with headings? TabAtkins: No? dbaron: Yes. dbaron: The rule is that a later sibling replaces an earlier sibling's counter, but not if it's a descendant of the later sibling. TabAtkins: If you're using heavy sectioning content then you've got nesting and it'd probably break. dbaron: With sections you should be fine, as long as sections & headings line up. dbaron: There was another problem, solution was counter-set property. dbaron: I don't remember the problem. TabAtkins: The value attribute on li. Already in spec. dbaron: I was trying to remember if other problem relates to this one, it doesn't. ekimber: Question: what's the use case for having the counter apply to following siblings? TabAtkins: Headings. You set up one counter at the top of the document and run it right down through the whole thing. If you have a flat document structure where headings are siblings then you can reset H1 and H2 counters, which will operate until next H1, next H2, etc. dbaron: You reset your H2 counter *at* your H1. ekimber: Given that, response would be "HTML is broken, so what." ekimber: So this is user error. ekimber: This is an unavoidable consequence of having to support this flat list. TabAtkins: Not necessarily, only if you want to support *all* of what HTML can do. TabAtkins: If you have an H1 as a child of body, and a div wrapper around the H2 that sets up a subsection. TabAtkins: Then that would break with the suggestion I'm making. ekimber: Implication seems to be - be consistent, otherwise things will mess up. Florian: Also the header element, can use for header of page OR title with subtitle. Florian: Not consistent, so nesting will be varying, esprehn: This change would be observable, right? esprehn: ol resets the counter. If you put the value attribute on an li which lets you explicitly number, then there's a reset there too. dbaron: That's a set. TabAtkins: Something something bug. esprehn: Does anyone implement? esprehn: We support counter but both value and reset are the same. So doing this changes the behavior. TabAtkins: But current behavior is very unexpected dbaron: <li><li><li value=5> - counter value inside each one, without set you'd have 1, 2, 2.5 TabAtkins: So yeah it'll fix it to 1, 2, 5, which is actually good. Florian: Given earlier thing with header, does that rule out solution? TabAtkins: Makes it less attractive. Another option: add a property to counter-reset or another property that changes scope TabAtkins: to descendants only instead of descendants & siblings. TabAtkins: Problem with :before is that it may not get created. dbaron: I like the new value or property idea plinss: Putting the :before rule with reset property doesn't trigger :before? TabAtkins: Nope. <zcorpan> "This specification does not yet define the CSS-specific rules for rendering li elements, because CSS doesn't yet provide sufficient hooks for this purpose." https://html.spec.whatwg.org/multipage/rendering.html#lists zcorpan: Question: is it possible with counter spec to specify how <ol> and <li> are supposed to work? TabAtkins: You can as long as nesting isn't observable. TabAtkins: Except for reverse TabAtkins: but if nesting is exposed somehow then the naive mapping is wrong and can't be done in CSS. zcorpan: I think we should make the counter spec usable by <ol>, <li> TabAtkins: Yup. fantasai: Yup. TabAtkins: Shall we go with the idea of a new value or property that scopes only to descendants? <TabAtkins> ol > :first-child <zcorpan> including <ol reversed> (ideally) Florian: but we can just ol :first-child { counter-reset: blah }. [Tab draws a waaay better diagram] <shane> https://usercontent.irccloud-cdn.com/file/HwvTalBE/IMG_20160509_115341.jpg Scribe: fantasai Florian: So one proposal was use ::before if it exists, or :first-child of the list Florian: to reset the counter. TabAtkins: It works for HTML, but it is weird overall, because you have to be concerned with the first child who is being set. TabAtkins: Setting on the container is much cleaner. TabAtkins: So one proposal is to cut counter [...] TabAtkins: Better one from dbaron is we have some syntax for indicating on counter-reset that counter will only scope to its descendants. TabAtkins: The counter would then end its scope at the end of the </ol> Florian: Seems a lot cleaner, but worried it will be very obscure and nobody would know about it. Florian: Is it better to have a simple system with ::before or a complex system with lots of switches? Scribe: shane TabAtkins: I wouldn't have designed counters this way. fantasai: One use case that should work - sometimes you start a list, then close and want to continue later. <zcorpan> <ol start> dauwhe: This is super important for us. Florian: Can't just use a class? TabAtkins: You need to establish counter in ancestor. dbaron: dauwhe, does it sound OK if browsers implement list numbering using counters, you could do it by having a div higher up that contains all the lists you want to number together dbaron: explicitly resetting list counter on that div, then removing on individual lists. Would this work for you? dauwhe: That makes sense to me and I think I can explain it OK to people too. <TabAtkins> https://drafts.csswg.org/css-flexbox/#main-sizing TabAtkins: This is explicitly what we use in the flex algorithm. TabAtkins: Multiple OLs crossing sections that number subsequently, put a counter on body and use that one instead. Florian: Either if we have a simple but surprising system, or a complex system, people aren't going to understand and will need to look at stack overflow. TabAtkins: Can put into UA stylesheet and make prominent in spec TabAtkins: if you're doing headings, do it like this, etc. Florian: Probably cleaner with complex but unsurprising system. fantasai: If it's a syntactic switch then it'll be in the spec. fantasai: People who are using counters are going to look it up. It'll be fairly obvious fantasai: so add a keyword to counter-reset? TabAtkins: We can't extend counter-reset. It's multi-valued without commas between each value. TabAtkins: Can't tell whether a keyword is a second counter or not. Florian: So multiple counters, might want to scope each one differently. So need a list in the parallel property too? fantasai: Can have a second property which does the same as counter-reset but with the other behavior. OR a property that switches the behavior. dbaron: Want other options too, in particular reversing. TabAtkins: Currently can't be expressed in the counter model. RESOLVED: Add new syntax to control counter scoping and consider reversing too. (Syntax TBD.) <dbaron> (Tab to propose syntax) <zcorpan> (This needs to be directly usable by HTML spec's UA stylesheet for <ol>, <ol start>, <li value>, <ol reversed>...) [discussion about resolutions, resolution reversion, and contradictions] <dbaron> (and counter-resolutions) Values and Units ---------------- TabAtkins: Say you have a background image 'url(#svgfrag)'. TabAtkins: Clearly points to something local. TabAtkins: Once you absolutize the url TabAtkins: you notice it points to same doc, go find it, everything's cool. TabAtkins: But say you do push-state to update the URL, the page changes it's URL TabAtkins: we don't go an re-absolutize the images TabAtkins: (in all browsers, interoperably). TabAtkins: So that's an issue. pushState means the reference is no longer local. <zcorpan> history.pushState() <zcorpan> or insert a <base href> <SimonSapin> this is an inline stylesheet, right? <SimonSapin> <style> not <link> dbaron: Why didn't that change when the document's URI changes? TabAtkins: Because everyone absolutizes at parse time and nobody changes it. fantasai: Can't we fix it? TabAtkins: No. It's good behavior. TabAtkins: If the ref is relative to to the slash path then do pushState that just changes local position in doc tree would result in local references being probably wrong. TabAtkins: If you start out at http://example.com and reference foo.svg TabAtkins: then pushState to http://example.com/startMyApp/ TabAtkins: then we're now referencing http://example.com/startMyApp/foo.svg, which probably doesn't exist. TabAtkins: So don't want to update in this case. fantasai: This is super messed up. Could have 2 different refs to same target that point to different things because of statefulness of pushState. zcorpan: I think it's too expensive to re-resolve all the urls in the universe when a pushState happens. plinss: If you pushState to a new URL then you should be able to reload from that URL and get back to exactly the same state. TabAtkins: In practice doesn't always work, and can use middleware to fix the problem anyway. plinss: I'm not concerned about case where middleware masks a bug. TabAtkins: I don't think it's a bug that you should have to rewrite references on pushState. plinss: But it is a bug that you can't reload a pushState and get back to the same state. plinss: I want to see data that we can't fix that bug. TabAtkins: Someone should say we *can* do it first. TabAtkins: It's an HTML problem. plinss: It's a cross-spec problem really. zcorpan: From browser vendor's POV the burden of proof is in other direction. Won't risk breaking pages without data saying it won't break pages. plinss: If it was a minor change that's fine. But fundamental architectural issue so different stance. hober: Would love to see data on compat issue, but given that absent data implementors are unlikely to change, who's volunteering to collect data? TabAtkins: I want to move on to issue. Not absolutizing is bad for local references that become remote. TabAtkins: So e.g. pushState from http://example.com to http://example.com/foo. #svgFrag no longer resolves as local because the URLs don't match. TabAtkins: My proposal: '#' is a very clear indication that you're doing a local reference. So if a url is JUST a hashref then we store state that indicates the reference is definitely local, and never absolutize. TabAtkins: If we can solve the more general problem then we don't need to do this. plinss: Sounds like a hack on a hack. * glazou agrees with plinss [A general rehashing occurs. Rehashing. Hah] astearns: If there is a compat issue with fixing this the right way, isn't this going to trigger that too? TabAtkins: No. This definitely always wants to be local. Florian: But it's not clear for files because you don't know whether they want to be relative or relative relative hober: Are you proposing that hidden state be exposed to CSSOM? Or via syntax to explicitly opt in? Or via URL object? TabAtkins: Currently just if URL string starts with '#'. Can detect by asking for computed value because it should serialize back to just a '#' instead of abs value for round tripping purposes. plinss: In general, TAG is facing another issue where we need to assign additional information to a URL to make it useful. Tim hates this. Fundamentally URLs should be standalone, without magic. This is going to <elided> Tim. TabAtkins: We could introduce new function that is identical to url but only accepts local references TabAtkins: but that doesn't fix existing pages TabAtkins: or upon parsing this could computed value to local only function. plinss: Yuck. plinss: Shouldn't make an assumption based on presence or absence of parts of the url. TabAtkins: There's a couple of options; we need to fix it somewhere. TabAtkins: (A) get DOM to fix everything TabAtkins: (B) hidden state on urls TabAtkins: (C) new local-only url function fantasai: How is that better than fixing A? TabAtkins: Because A will break things TabAtkins: e.g. your URL is "foo.svg" and you pushState to something with a different URL segment then your page will break. plinss: But right now it'll break on reload anyway. TabAtkins: We should decide on (A) assume DOM will fix everything and make no change or (B) make *some* sort of change. fantasai: What about (D) try to get (A) to work and in the meantime do (B). fantasai: I prefer (D) astearns: Me too, but I don't know how fixing the actual problem is going to happen? hober: Comes back to: "who's going to provide the data"? Haven't heard any volunteers. fantasai: If you do it correctly, relative URLs aren't going to change unless you wanted them to change. If you're depending on the broken-ness then it's going to change and you'll need to fix your URLs. plinss: I'll file (A) as an issue with the TAG. It's bigger than CSS. astearns: Does anyone object to pursuing a temporary solution while that happens? <fantasai> Proposed resolution: Make local fragment URLs magically always relative; file issue against TAG to fix this generally. Florian: (B) is a temporary solution that silently disappears if we fix (A) so it's better than (C) fantasai: yeah, agreed. plinss: I'd rather have a different function - i.e. (C) Florian: Why would you prefer a different function? plinss: So you can say what you mean. getElementByID should be a new thing, not the existing thing, plinss: and the parameter should be an ID, not a URL fragment. hober: I think esprehn's saying that functionally, fragment references currently are getElementByID. esprehn: Right. It's already live in that we can swap out elements and the reference updates. zcorpan: Special casing URLs with only a fragment already exists. Navigating special-cases fragment changes vs. other changes. Florian: In this case we specialize fragment behavior to do the right thing. So fixing behavior in the subcase. i.e. like (B). dbaron: One of the other cases for having something that isn't url function is to be able to move styles that reference an ID in a document into an external stylesheet. dbaron: We added an element() function as an image value. Is basically this. TabAtkins: element() might be a reasonable choice then. hober: This is a garbage fire. Browsers screwed up AND authors screwed up. (B) seems reasonable then but both plinss and dbaron have made reasonable arguments for adding (C) *as well*. ChrisL: SVG has a concept of a URL that's restricted to the local document. Originally had idref but the TAG told us to stop. TabAtkins: Current proposal: Add hidden state to URL *and* make sure element() can be used to just refer to local references. hober: I'm a little unsure about expanding element() beyond existing use as an image source. Probably fine. ACTION: Peter Linss to file an issue against the TAG to fix the general pushState / url reference problem <trackbot> Created ACTION-769 RESOLVED: Add hidden state to hash-reference-only URLs so that they can always resolve locally in presence of pushState RESOLVED: Adapt the element() function so that it can be used to refer to always-local references <br type=lunch>
Received on Tuesday, 24 May 2016 23:36:16 UTC