- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 25 Apr 2018 20:04:39 -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.
=========================================
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
#2551)
- RESOLVED: Take dated 2011 rec and revert link changes. (Issue
#2551)
- 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
http://www.w3.org/TR/2011/REC-CSS2-20110607
and ChrisL may add a warning note about the 2016 links
as he sees necessary (Issue #2551)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Apr/0019.html
Present:
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
Regrets:
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
https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-contain-1
* Tests since last CR: All normative changes covered, linked to from
the Changes section, see also
https://github.com/w3c/web-platform-tests/pull/10549
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
period?
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
something.
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
feature.
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.
Reasonable?
florian: I think we need to overflow into the other agenda topic to
answer.
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
number.
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
notation.
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
L2.
<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
undefined.
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
spec.
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*
features
<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
generally.
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
tokenization.
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
tokenization.
fantasai: It's not error handling It's a valid CSS2 doc conforms to
this.
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
work.
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"
more-tokens-here)
<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
say
<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
okay.
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
more.
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
minor.
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
publication.
fantasai: Leave it to ChrisL because it's much easier for him to do
that.
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
http://www.w3.org/TR/2011/REC-CSS2-20110607
<gsnedders> proposal: /TR/CSS2/ redirects to
http://www.w3.org/TR/2011/REC-CSS2-20110607
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
http://www.w3.org/TR/2011/REC-CSS2-20110607
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
changes
<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