W3C home > Mailing lists > Public > www-style@w3.org > April 2018

[CSSWG] Minutes Telecon 2018-04-25 [css-contain] [CSS2]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 25 Apr 2018 20:04:39 -0400
Message-ID: <CADhPm3uMZDrKPPvcwmxpPUH=4b9hMPDicKpk1KYv=rggLn_Zrw@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.

CSS Contain

  - RESOLVED: Publish updated CR of css-contain-1.

CSS 2.1

  - The group began by discussing issue #2542 (Should we add
      scientific notation to CSS 2.1?) where an unintended consequence
      of a previous decision was to add a new feature to CSS 2.1.
  - There was general agreement that there was no intent to introduce
      a new feature, but the larger question came to how to handle the
      Syntax section in CSS 2.1 (Issue #2224).
  - Originally there were several proposals including removing the
      section, just adding notes, only changing the error handling
      portion, or turning the section informative and adding notes.
  - Many of the suggestions raised process concerns as the group did
      not want to bring CSS 2.1 back to a WD, however after re-reading
      the process document it was clarified that feature removal would
      only require returning to CR.

  - RESOLVED: Take 4.1, 4.2 and 4.4, change them to informative notes,
              and add notes to those sections + appendix G showing
              where the newer work is being done. Links to newer works
              are informative notes. (Issue #2224)
  - RESOLVED: We add a note to CSS 2.1 noting the presence of at least
              one new feature in the informative reference. We intend
              not to add any new features to CSS2. (Issue #2542)
  - RESOLVED: Take current draft and revert to 2011 anchors. (Issue
  - RESOLVED: Take dated 2011 rec and revert link changes. (Issue
  - RESOLVED: http://www.w3.org/TR/TR/2016/REC-CSS2-20160412/ is what
              is currently at http://www.w3.org/TR/2011/REC-CSS2-20110607
              and /TR/CSS2/ redirects to
              and ChrisL may add a warning note about the 2016 links
              as he sees necessary (Issue #2551)


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Apr/0019.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Garrett Berg
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Vlad Levantovsky
  Peter Linss
  Michael Miller
  Anton Prowse
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Dirk Schulze
  Alan Stearns
  Majid Valipour

  Lea Verou
  Greg Whitworth

Scribe: dael

  astearns: We have enough people to get going. Does anyone have
            something to add to the agenda?
  florian: I sent one by email
  astearns: I noted it. Let's do that first.

Updated CR of css-contain-1
  <florian> https://www.w3.org/mid/8A8F922A-7A5D-479D-9B35-A31982967736@rivoal.net
  florian: As listed on that email ^ there's a complete DoC and change
           section. We have tests for every change since last CR.
  * DoC: https://drafts.csswg.org/css-contain/issues-2017-cr
  * Change section: https://drafts.csswg.org/css-contain/#2017-08-08-changes
  * Open issues: none, see
  * Tests since last CR: All normative changes covered, linked to from
      the Changes section, see also
  florian: Should we publish CR again?
  astearns: Sounds good to me.
  astearns: You've been very through.
  astearns: Objections to publish updated CR of css-contain-1?

  RESOLVED: publish updated CR of css-contain-1

  florian: Since I don't think we have 2 implementations we're not
           close to existing CR. Do we still need minimum transition
  astearns: What's standard?
  florian: 4 weeks?
  gsnedders: It's 60 days standard.
  astearns: Is that first CR or every?
  gsnedders: Every I believe.
  florian: We won't exit in 60 days anyhow so we should just state
  astearns: Let's go with 60 days.
  florian: We do not have tests for everything in the spec so tests
           are welcome.

CSS 2.1

Syntax section readded despite WG resolution
  github: https://github.com/w3c/csswg-drafts/issues/2224

  [Note: This began as a discussion of issue #2542: Should we add
         scientific notation to CSS 2.1? however it was later switched
         the larger topic covered in issue #2224]

  gsnedders: We accidentally agreed to add scientific notification to
             CSS L2. Do we want to do that for real?
  florian: When did we agree?
  gsnedders: Agreed before the reset but after the rec. We said we'd
             normatively reference CSS 3 syntax which added a new
  florian: Is the CSS 3 Syntax reference separate?
  gsnedders: Yes, next.
  gsnedders: Do we want to add a new feature to CSS 2?
  <ChrisL> I'm not sure it is a new feature, given it is not
           independently testable
  astearns: I think no. Anyone disagree?
  ChrisL: Disagree. This is not a new feature, it's a new way of
          expressing something. You can't test the syntax without
          testing an app or a value. It's an internal spec matter.
  florian: Defining the syntax is, but pointing to the spec that does
           new things isn't new?
  ChrisL: We point to the syntax but the features are in the things in
          2.1 We don't take advantage of the extra features.
  florian: I think we need to overflow into the other agenda topic to

  gsnedders: Relevant thing is the definition of number, right?
  fantasai: There was an issue around URLs too, right?
  gsnedders: We have errata for that.
  florian: gsnedders your question is not just do we want to introduce
           a new feature but also do we want to introduce a new
           feature independently of if we reference the new syntax.
  florian: I think the only reason is if we see value and cannot
           reference syntax 3 without adding it.

  ChrisL: Is this a true superset or an incompatible change? Is it
          possible to support both?
  gsnedders: You can support both it's new syntax for the addition a
  ChrisL: So just the subset in 2.1.
  TabAtkins: I'm sorry if this was covered already, I just joined. We
             could subset css 3 syntax but that's a bag of worms where
             to do correctly is substantial effort with no benefit. No
             one is impl css2.1. What is wrong with just normatively
             undefining css syntax for 2.1.
  florian: gsnedders wants to discuss possible scientific notation
           before discussing the link to syntax.
  TabAtkins: We either undefine it or we link to Syntax. Those are
             only 2 options besides doing a lot of work to carve out a
             subset of what matches in css 2.1.

  tantek: I think there's a number of difficult options. I'm not
          convinced of any one and trying to understand trade offs.
          For CSS 2 work we have the most important thing gsnedders
          and I are trying to do is keep the edits rolling in and go
          through CR/REC alternating process. In my opinion that's the
          primary driver of where we try and nudge decisions.
  tantek: Ideally we'd like to not introduce any new features. Even if
          it's inconvenient I'd like to see us do the work rather then
          compromise on that since we promised to ourselves and the
          community no new features. That's my preference.
  astearns: I suggest we table scientific notation and go straight to
            the first topic.
  tantek: I'm concerned we're ducking the hard question of not adding
          new features. That's a design principle where as what
          reference we make is different.
  florian: I agree with tantek we should stick to the process, but I
           don't think that means we have to subset syntax 3. For this
           section I think I'm with TabAtkins and we should gut out
           the section that defines syntax and replace it with a note
           that says previous versions tried to do syntax, was proved
           incorrect, and we informatively reference the known better
           work in Syntax. Recognize we had a definition, it wasn't
           good, and here's what we have that's better.
  TabAtkins: florian's suggested wording sounds perfect.
  <tantek> so we can't actually do that without going back to WD,
           because technically it's normative feature *removal*
  fantasai: My concern is it makes the spec mostly non-nonsensical.
  fantasai: I'm not saying we need to keep grammar the way it is, but
            things like this is how you parse css in general makes the
            rest of the spec make sense.
  florian: We still point to syntax non-normative to there's sense.

  <dbaron> I think one could also add to the wording a note that the
           new module has a new feature: support for scientific

  TabAtkins: No one is adhering to CSS2, we can just point
             non-normatively to where the definitions are.
  florian: Alternatively we keep the old section, put a note saying
           this is incorrect and put the rest as suggested. So if
           you're trying to make internal sense of the spec you don't
           need to go to another. I don't think that's more useful the
           just the note.
  fantasai: We'll have notes in all sections pointing to new sections.
            Reason we're stuck is an inconsistency between L2 and L3
            that means L3 implementation is non-conformant to L2.
  TabAtkins: Yep, but we don't care about L2 impl. No on impl 2.1 at
  <ChrisL> agree with Tab

  tantek: The first suggestion to remove the syntax section for CSS 2
          and replace with an informative reference to CSS 3 is
          untenable because that's a normative feature removal and we
          can't do that because we're not going back to WD as per the
          plan we agreed to.
  <florian> it is not a feature removal, we're not saying that CSS2
            should not have a syntax, just saying that that syntax is
  tantek: I understand and accept the issue that CSS 2 syntax is not
          something we want people to impl. I don't think there's
          debate on that guidance. We're debating how to provide the
          guidance so that's it's clear to webdev and lets us iterate
          on 3.
  astearns: I think your process point...is that because syntax is not
            marked as at risk?
  tantek: Syntax section, nothing in css 2 is marked at risk.
  astearns: We remove normative features, it's just usually that
            they're at risk.
  florian: I disagree this is feature removal. We're normatively
           undermining it.
  tantek: Same thing.
  florian: It's not.
  <tantek> removing something normatively removes it from IP as well
  <tantek> from a process perspective, removing or undefining it
           normatively is a removal of an *essential feature*

  gsnedders: My understanding of changes in syntax 3 are that mostly
             they relate to error handling. If we simply undefine the
             error handling would that work?
  <fantasai> gsnedders++
  TabAtkins: Let's see. Only positive feature is scientific notation.
             Rest is error handling...yeah...normatively no longer
             have U range token. Yes, it's technically right. But you
             cannot impl error handling correctly as described in 2.1
  fantasai: Error handling is a separate process and go look at this
            doc, then.
  TabAtkins: You can't impl with anything remotely like what looks in
  florian: If you take it as a list of things that are correct the
           grammar is fine. You can use it for a validator.
  TabAtkins: How to validate? Nothing is defined in terms of it.
  <fantasai> TabAtkins, CSS2.1 stuff is defined in terms of it.

  ChrisL: Normally when publishing updated REC it's Edited REC and you
          don't go to WD. I think we can change things and mark things
          at risk and later remove. I also remain unconvinced that
          this is a feature, it's just how the syntax is expressed.
  TabAtkins: Agree.

  <dbaron> I'd note that you can't go directly from REC->WD, but you
           can go REC->CR->WD. I think it's a bug in the process,
           though. (And I filed it.)
  <tantek> dbaron huh? pretty sure you have to go REC->WD per current
           process with new features (and I think for removed features
           too - checking now)
  <gsnedders> tantek: Process doesn't say, just for "new features"
  <dbaron> tantek, the process for revising a REC doesn't allow
           transitions other than REC->REC, REC->PR, or REC->CR, IIRC
  <gsnedders> dbaron: https://www.w3.org/2018/Process-20180201/#rec-modify
  <gsnedders> dbaron: it's REC->REC, REC->CR, or REC->FPWD
  <tantek> dbaron, gsnedders is right - see flow chart
  <tantek> REC -> substantive changes? -> yes -> new features? -> yes
           -> FPWD
  <tantek> looks like we can technically skip WD for *removing*
  <dbaron> tantek, gsnedders: on the other hand, see the "next steps"
           in https://w3c.github.io/w3process/#rec-publication
  <gsnedders> dbaron: yes, I think REC->FPWD is expected to be a new
              REC-track document
  <dbaron> gsnedders, yes, that's what the last sentence of
           https://w3c.github.io/w3process/#revised-rec says
  <tantek> dbaron, looks like those "next steps" are not
           comprehensive, good catch. please cc me on the issue you
           filed on the process per that section
  <dbaron> tantek, my issue was https://github.com/w3c/w3process/issues/103
  <dbaron> tantek, And the "go to FPWD" option isn't, I believe, part
           of the Edited/Amended Recommendation process -- it seems to
           be for a new recommendation

  astearns: As you spoke I was thinking this is something we'll have
            to deal with in the future for CSS 2. Coming up with a
            proper way to remove something from CSS 2 to point at a
            more accurate version is something we'll have to deal with
  gsnedders: I don't think other cases will be as bad as this. Things
             like properties we can just say L2 accepts these
             properties, see L3 for definition.
  florian: We can defer to L3 as REC.
  fantasai: My preference would be not to remove the section because
            it's a gaping hole. We can remove error handling and we
            can add a reference to CSS 3 and we can add a statement at
            the top saying you can be conformant by impl here or L3.
            But ripping out the whole section I'm not comfortable.
            Internally CSS2 is defined in terms with its own grammar.
  fantasai: In that error handling we can say this is not correct,
            there is error handling and it means these things and the
            details are in L3, but it leaves us some overall syntax.
            Then we also have a reference for if you want to impl a
            parser go look over there.
  florian: You don't want to break internal links?
  TabAtkins: Semantic links.
  florian: Sure.
  TabAtkins: My challenge to that is what's better? A spec that points
             to a broken incorrect issue or a spec that is hand wavy.
             No one prefers the pointing to a broken thing.
  <tantek> so now I'm ok with first Florian proposal, turning current
           section informative (thus normatively undefining), and
           adding informative reference to CSS3 Syntax

  florian: Entry point of Syntax and CSS 2 grammar are they the same?
  TabAtkins: That concept isn't in CSS 2.
  florian: Terms CSS 2 uses other than grammar still need to make
           sense. Need to understand what the spec is talking about.
  TabAtkins: In terms of property we use the same terms. CSS2 uses a
             token scheme, but it's the same terminals.
  fantasai: I'm suggesting the hand wavy thing isn't a giant gaping
            hole. We take that section, the error handling is where
            the problems and that small section can be turned into
            something more hand wavy and let's say it's less tight but
            have the rest of the section intact.
  TabAtkins: You have to go read other things. You can't read that
             grammar and impl CSS.
  fantasai: I'm not necessarily an impl!
  TabAtkins: If you're not impl you're not looking at tokenization
  <fantasai> TabAtkins, afaict you're not asking to remove
             tokenization, you're asking to remove all of Chapter 4

  tantek: I double checked the process. It looks like if we add
          features we have to go to WD, but not for removing features.
          Removing a new CR was sufficient. It lets us mark the whole
          CSS2 section as informative and then add informative
          reference to CSS 3 to give impl guidance. So welcome to
          syntax and if you're impl you have to go here. Remaining
          text is informative because it's out of date.
  <ChrisL> that would work for me!
  <gsnedders> fantasai, TabAtkins: and presumably Appendix G
  tantek: I think we can do that and continue with our work mode.
          Assuming florian and TabAtkins are good with that, fantasai
          does that sound good to you?
  florian: My initial proposal was gut the section, but I updated to
           do exactly what you said.
  TabAtkins: I'm okay if it's there if it's in some big colored box to
             show it's wrong.
  fantasai: Section?
  TabAtkins: Appendix G grammar. And a chapter that defined
  gsnedders: Chapter 4.1 and 4.2
  gsnedders: Values section I think we still want.
  tantek: I think not.
  gsnedders: 4.3 values is replaced by values & units. So it's just
             4.1, 4.2 and 4.4
  florian: And appendix G
  gsnedders: Yes.
  florian: Turn all of that into notes and add an introductory note
           that it's for reference but known as not fully correct.

  fantasai: Why appendix G? I understand the 4.x
  TabAtkins: It's a big set of grammar defined in terms of
  fantasai: It's not error handling It's a valid CSS2 doc conforms to
  TabAtkins: There are some that don't because changes to CSS2 that's
             not backwards compat.
  fantasai: Example?
  TabAtkins: URL syntax changed. You can conform to CSS grammar...
  fantasai: Example of URL that's valid now and wasn't before.
  <tantek> "This appendix is non-normative. "
  florian: Appendix G states it's non-normative but section 4 refers
           to appendix G as normative.
  gsnedders: Yes, 4.1
  florian: [reads]
  tantek: Assuming we make 4.1 informative that becomes informative
          and it's fixed. We don't have to touch G.
  florian: Just adding a note on top is nice to do.
  TabAtkins: Yes, I'd recommend a note.
  <fantasai> +1 to note
  gsnedders: If we believe G is capricious we should remove.

  astearns: Proposal is take 4.1, 4.2 and 4.4, change them to
            informative notes, and add notes to those sections +
            appendix G showing where the newer work is being done.
            Those are informative notes.
  florian: Agree.
  TabAtkins: Fine with that
  astearns: Objections?
  <ChrisL> fine by me
  tantek: Clarify that references to CSS 3 syntax are informative and
          I'm good.
  astearns: Yes, that's the last clause. "Those" being link to newer
  fantasai: We might want to tweak intro text in chapter 4.
  tantek: That's editorial.
  fantasai: I still want an example.
  TabAtkins: Don't have one off the top of my head.
  astearns: Given you wanted the example as to why we want to change G
            and we're not do you need it?
  fantasai: Not to block a resolution. Still want the example though.
  <gsnedders> fantasai: http://w3c-test.org/css/CSS2/syntax/uri-013.xht
  <gsnedders> fantasai: that passes per 2.1 and fails per Syntax, AFAIK
  <fantasai> gsnedders, that's error-handling
  <gsnedders> fantasai: I haven't looked at that test in a long while
  <fantasai> gsnedders, it's not supposed to be a valid document.
  <TabAtkins> Example that fails 2.1 and passes Syntax: url("foo.txt"
  <fantasai> TabAtkins, that's invalid in CSS2 regardless
  <fantasai> TabAtkins, it's another error-handlign example
  <fantasai> TabAtkins, the error-handling is different in
             css-syntax-3, but it's not valid in L3 (yet) nor in L2.

  astearns: Objections?

  RESOLVED: Take 4.1, 4.2 and 4.4, change them to informative notes,
            and add notes to those sections + appendix G showing where
            the newer work is being done. Links to newer works are
            informative notes.

Should we add scientific notation to CSS 2.1?
  github: https://github.com/w3c/csswg-drafts/issues/2542

  astearns: Back to scientific notation?
  tantek: I think it's still open.
  florian: There's a previous resolution.
  astearns: objections to...
  gsnedders: Previous resolution was in 2016. [reads]
  <gsnedders> "RESOLVED: Remove CSS grammar section in CSS 2.2 and
              have a pointer to CSS syntax", 2016-10-12
  <gsnedders> (previous resolution)
  tantek: There was unintended consequence. Previous to that we
          resolved no new features.

  astearns: Proposal: We are not linking normatively to syntax. We
            will informatively link to syntax and thus no new syntax
            added to 2.1 include scientific notation
  tantek: If we're trying to get to point that we normatively
          reference syntax 3 we need to solve for this.
  TabAtkins: I'm willing to promise we won't normatively reference
             from 2.1.
  tantek: Not a goal?
  TabAtkins: No, 2.1 doesn't have to care about definition.
  tantek: Then I'd like to add a note stating that css3 has a new
          feature impl should be aware of.
  fantasai: That should be in syntax spec. Changes. Other than we
            re-wrote error handling we added this.
  ChrisL: Makes sense, changes from 2.1
  <fantasai> https://drafts.csswg.org/css-syntax-3/#changes-css21
  fantasai: It's here ^
  astearns: dbaron can you type into IRC?

  tantek: I'm okay resolve no changes but I'd like to leave the issue
          open until we get a CR. I'd like to leave this open.
          Resolve, leave the issue open and not it's pending
          successful CR.

  <dbaron> I think the note we added in the previous resolution should
  <dbaron> that css-syntax adds a new feature, scientific notation,
           that was not a feature in level 2.
  <dbaron> (and that should just be a note)
  astearns: [reads dbaron ]
  astearns: I'm thinking it should be more general that CSS Syntax
            adds at least 1 new feature that's not in L2.
  <ChrisL> sounds good, Alan
  <fantasai> can link to CHanges section :)

  astearns: Proposal: We add a note to CSS 2.1 noting the presence of
            at least one new feature in the informative reference. We
            intend not to add any new features to CSS2.
  tantek: I like linking to CSS 3 syntax changes section.
  astearns: Obj?

  RESOLVED: We add a note to CSS 2.1 noting the presence of at least
            one new feature in the informative reference. We intend
            not to add any new features to CSS2.

Anchors changed in CSS 2 in-place edit in 2016
  github: https://github.com/w3c/csswg-drafts/issues/2551

  gsnedders: When CSS 2.1 was edited in place in 2016 all anchors were
             changed. This is bad.
  gsnedders: Because it was an in-place edit the old 2011 URLs point
             to the 2016 copy of the spec. There's noting in TR space
             with old anchors.

  gsnedders: Question is do we want the pre or post 2016 anchors when
             we edit.
  florian: Pre or both
  ChrisL: Pre. Old links will be to pre ones. We should pretend this
          didn't happen.
  florian: Both in case new links.
  TabAtkins: Agree. Both is easy.
  ChrisL: Is it?
  gsnedders: Not too bad
  ChrisL: Messy, but okay.
  gsnedders: Pre is easy.
  tantek: Editors prefer pre.
  gsnedders: I think we should look at how hard for both.
  florian: I suspect most newer links might be ones we made from
           bikeshed so if can scan draft for new links and fix that's
  tantek: That's the theory.
  <dbaron> I think whatever we do, we should publicly archive the two
           copies of the spec rather than just overwriting.
  TabAtkins: A lot of 2.1 links are manual.

  fantasai: Are all links broken? Looks like not all.
  fantasai: When we link to 2.1 we do to section headings and those
            were manual chosen IDs.
  florian: There's links to definitions.
  gsnedders: Only manually specified ones have not changed.
  fantasai: We rarely link to those so revert should be fine.
  fantasai: Most links have been to section headings.
  fantasai: 2.1 didn't have rigorous mark-up or auto cross references
            so I think it's safe to revert.
  plinss: True for test links?
  fantasai: prop def I'm guessing didn't change.
  florian: I don't think there's a lot of new 2.1 tests since 2016.
  florian: Probably a handful of places but edit those is easier then
           reference both.
  fantasai: prop def & section headings have not changed.

  astearns: If we revert there's a statement on IRC from dbaron that
            we should publicly archive a copy of the spec with these
            links. Will we have that?
  ChrisL: Dated version was edited in place which should never have
          been done.
  tantek: We're undoing damage to dated version.
  gsnedders: 2011 dated will have 2016 anchors.
  florian: Not ideal.
  gsnedders: So we edit in place the 2011 to undo the anchors change?
  tantek: Yes. Because they were around from 2011-2016 and referenced
  fantasai: You might...if you want a copy of 2016 anchors then maybe
            ChrisL can you get exception to normal process and get
            2016 date that corresponds.
  ChrisL: Might be. No promise.
  fantasai: In that case you can copy and then revert.

  astearns: 3 things. 1st is take current draft and revert to 2011 anchors. Obj?

  RESOLVED: Take current draft and revert to 2011 anchors.

  astearns: Take dated 2011 draft and revert link changes.
  astearns: Objections?
  gsnedders: Draft or rec?
  astearns: 2011 dated rec.

  RESOLVED: Take dated 2011 rec and revert link changes.

  astearns: 3rd is produce a 2016 dated doc that retains those links.
  gsnedders: Change 2011 back to original copy?
  ChrisL: Think so.
  florian: Difference other then link?
  gsnedders: Notice that we're working on other things, changes to
             process that effect PDF copy.
  dbaron: Big obsoletion notice?
  gsnedders: That's the big 2016 change.
  florian: Want to keep that.
  gsnedders: Add fixup.js that everything else uses.
  ChrisL: Yes.
  gsnedders: Other small editorial changes made in 2016, but very
  ChrisL: Why were changes made?
  gsnedders: There's a min-height that in 2011 cross-ref to height and
             now it's correct.
  ChrisL: Fixing broken link. I'd like to keep if can.
  ChrisL: Revert, add js, patch in small editorial fix ups?
  gsnedders: Sure.

  astearns: Preference to 2011?
  ChrisL: 2016 dated.
  ChrisL: 2011 should also have js added.
  florian: Slightly confused. If we're adding 2016 dated I thought
           goal was preserve the new links. If it's later then 2011
           the fixed is hidden by broken. Useful?
  tantek: A new 2016 dated version will have 0 links so it doesn't
          matter fragments.
  florian: New [missed]
  gsnedders: Depends where /CSS2 goes
  tantek: We won't link /CSS2 to that.
  tantek: It's to keep an archival copy. Not refer to that as latest.
  florian: Okay with it under assumption that not latest can be where
           the undated link goes. If that's not possible then no.
  dbaron: It wasn't a request to have it in TR space, but somewhere so
          you can figure out where a link went.
  fantasai: I think having it in TR space is okay and you don't link
            to it.
  astearns: Might be easier in draft space then deal with TR
  fantasai: Leave it to ChrisL because it's much easier for him to do

  florian: Can we resolve on having an archival copy on TR or on
           drafts depending on ease?
  ChrisL: Make sure there's good minutes and I'll discuss all of this
          with plh.

  astearns: We want a dated 2011 document with the js that says it's
            old and with the original links. We also want a 2016 dated
            document with the original links and all the changes that
            went into 2016. And we want a dated doc somewhere that
            isn't the latest and has the weird links for posterity.
  astearns: Correct?
  florian: Seems acceptable. DOn't know if we need 11 and 16 on TR.
           What you said is okay.

  <gsnedders> proposal: http://www.w3.org/TR/2011/REC-CSS2-20110607
              has fixup.js and the original pre-2016 links
  <gsnedders> proposal: http://www.w3.org/TR/TR/2016/REC-CSS2-20160412/
              is what is currently at
  <gsnedders> proposal: /TR/CSS2/ redirects to

  fantasai: I think what gsnedders said is more sensible. We just have
            2011 draft restored and a copy of 2016 somewhere.
  fantasai: I'd resolve on gsnedders in IRC.
  astearns: Is http://www.w3.org/TR/TR/2016/REC-CSS2-20160412/ is what
            is currently at http://www.w3.org/TR/2011/REC-CSS2-20110607
            enough for you?
  ChrisL: Yes.
  tantek: If you want to add a warning to 2016 TR version noting
          fragments are different, that's okay.

  RESOLVED: http://www.w3.org/TR/TR/2016/REC-CSS2-20160412/ is what is
            currently at http://www.w3.org/TR/2011/REC-CSS2-20110607
            and /TR/CSS2/ redirects to
            and ChrisL may add a warning note about the 2016 links as
            he sees necessary

  <gsnedders> https://gist.githubusercontent.com/gsnedders/56d1415b998c1e6b0291316bc93b5a57/raw/5c1632be167de430f3917df7acdb75cb1165e758/2011-new-anchors-2016.diff
              is a complete diff of 2011 to 2016 excluding the anchor
  <gsnedders> tantek, ChrisL, fantasai: I seem to have mispoken, there
              are no minor editoral changes in 2016
  <gsnedders> it's literally: a) stylesheet URL changed to https; b)
              add the warning; c) add a link to the ED; d) add one
              class to the TOC (?!); e) change anchors
  <tantek> good to know
Received on Thursday, 26 April 2018 00:05:42 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:07 UTC