W3C home > Mailing lists > Public > www-style@w3.org > May 2016

[CSSWG] Minutes San Francisco F2F 2016-05-09 Part II: Counters, Values & Units [css-lists] [css-values]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 24 May 2016 19:35:17 -0400
Message-ID: <CADhPm3vWONw==4XPcr-473bbzLDhoqKuYhcNbf9C=EWYcGnSuA@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 24 May 2016 23:36:16 UTC