| 04:11 | <MikeSmith> | TabAtkins: so the HTML spec directly references the definition of the 'overflow' property in the "CSS Overflow" spec |
| 04:11 | <MikeSmith> | https://html.spec.whatwg.org/multipage/infrastructure.html#'overflow'; |
| 04:11 | <MikeSmith> | but it links to https://drafts.csswg.org/css-overflow/#propdef-overflow |
| 04:12 | <MikeSmith> | however that link is broken |
| 04:12 | <MikeSmith> | because that "CSS Overflow" doesn’t actually define the 'overflow' property |
| 04:13 | <MikeSmith> | instead it seems the definition is at https://drafts.csswg.org/css-overflow-3/#propdef-overflow |
| 04:13 | <MikeSmith> | CSS Overflow Module Level 3 |
| 04:14 | <MikeSmith> | so now I am wondering what we should do for the HTML spec |
| 04:14 | <MikeSmith> | should I change the HTML spec to reference CSS Overflow Module Level 3 instead? |
| 04:16 | <MikeSmith> | but if I do, is CSS Overflow Module Level 3 eventually going to become obsolete/stale/unmaintained, and the current/up-to-date/maintained spec will always be https://drafts.csswg.org/css-overflow and the 'overflow' property definition will eventually move back there? |
| 04:34 | <tantek> | those are good questions MikeSmith and I don't know the answer (and I feel I should) |
| 04:40 | <MikeSmith> | tantek: OK glad I’m not the only one :) |
| 04:40 | <tantek> | I figured I could help in that respect :) |
| 04:40 | <MikeSmith> | heh |
| 04:41 | <MikeSmith> | anyway in general it seems like we ideally want to be able to reference a definition at one place in a long-lived spec that’s going to continue to be maintained |
| 04:42 | <MikeSmith> | or to put it in other specific terms, ideally we don’t want the content of https://drafts.csswg.org/css-overflow to get replaced by some partial version of what was there before |
| 04:43 | <MikeSmith> | and don’t want what was there before to move to https://drafts.csswg.org/css-overflow-3 and break the references |
| 04:43 | <MikeSmith> | because I am guessing that is what has happened here |
| 04:53 | <astearns> | we shouldn't be redirecting the non-versioned link to a diff spec, which looks to be what's happening here |
| 04:55 | <astearns> | https://drafts.csswg.org/css-overflow should be the safe URL to use, and it should be going to the level 3 draft until we make the level 4 draft a strict superset of level 2 |
| 04:55 | <astearns> | s/2/3/ |
| 08:07 | <MikeSmith> | astearns: OK, thanks |
| 08:08 | <MikeSmith> | but then still not sure what I should do in order to fix the broken reference in the HTML spec |
| 08:10 | <MikeSmith> | also, anybody know why in *Value:* row of https://drafts.csswg.org/css-overflow-3/#propdef-overflow the ‘hidden’ and ‘scroll’ values are not hyperlinks? |
| 08:43 | <gsnedders> | so what makes it hard to keep one a strict superset of the other? |
| 08:43 | <gsnedders> | plenty of software projects deal fine with long-lived branches |
| 08:44 | <gsnedders> | but admittedly they use VCS branches to manage them instead of having to copy/paste patches across directories |
| 10:26 | <annevk> | rbyers: ping for https://github.com/whatwg/html/issues/3016 |
| 12:40 | <annevk> | jochen__: I filed https://github.com/w3c/webappsec-suborigins/issues/73 based on my recollection |
| 14:30 | <astearns> | gsnedders: it's mainly just to reduce copy/paste, particularly when a lower level is still going through a good rate of change. We park newer/less polished stuff in the next level as a diff of the lower level so that we don't have to make the lower level changes in two places. |
| 15:26 | <rbyers> | annevk: Sorry I missed this, will ask the input team to take a look. |
| 16:00 | <jyasskin> | MikeSmith: If HTML were a Bikeshed spec or pulled references from Shepherd, then just rebuilding would be sufficient, but of course it's not. |
| 19:59 | <TabAtkins> | MikeSmith: Yeah, Overflow 4 is currently a delta spec, only defining some new features on top of Overflow 3. When the features in 3 are stable and the spec matures, we'll move active development to 4, fleshing it out with the downlevel stuff from 3. |
| 19:59 | <TabAtkins> | (see https://www.w3.org/TR/css-overflow-4/#overflow-properties for where 'overflow' will go afterwards) |
| 20:00 | <TabAtkins> | While it's a delta spec, it probably shouldn't be the target for the unlevelled URL, tho - I'll check with Florian and get that switched, so your link will stay good. |
| 20:00 | <TabAtkins> | Ah, astearns already said that, cool. |
| 20:01 | <tantek> | TabAtkins: do we have a redirect for /TR/css-overflow setup to redirect to the latest "complete" (non-delta) version on TR? |
| 20:01 | <tantek> | so people don't have to worry about updating from css-modulename-n to css-modulename-nplus1 |
| 20:01 | <TabAtkins> | https://www.w3.org/TR/css-overflow/ 404s, so not yet |
| 20:01 | <tantek> | well then perhaps we should, for all css-modulename-n |
| 20:02 | <TabAtkins> | I guess we havent' done a pub on that in a bit, so we haven't bothered to correct the record. |
| 20:02 | <TabAtkins> | Yes, that's part of the publishing plan for all of TR - check spec-prod from I think July? |
| 20:02 | <tantek> | astearns: ^^^ would be interested in your thinking on that, use-case is being able to normatively reference a property (or value) where it is canonically defined and not having that link break over time |
| 20:04 | <TabAtkins> | Ah, a shifting link based on the property db perhaps? |
| 20:13 | <tantek> | TabAtkins: well that would be even more powerful / robust (for if/when a property moves between specs) |
| 20:19 | <TabAtkins> | tantek: I mean, that sort of thing is definitely possible. |
| 20:20 | <tantek> | https://www.w3.org/TR/css-property/color |
| 21:05 | <smaug____> | Domenic: curious, is https://github.com/w3c/webcomponents/issues/635 waiting for something? |
| 21:06 | <Domenic> | smaug____: https://github.com/w3c/webcomponents/issues/635#issuecomment-297516487 |
| 21:07 | <smaug____> | Domenic: you're still waiting for more feedback from bz? |
| 21:07 | <Domenic> | No, "This is simply because I haven't had time to get back to that general problem area and come up with any alternatives that I can compare with his proposal." |
| 21:07 | <smaug____> | ah, that, ok |
| 21:07 | <smaug____> | yeah, we're implementing something |
| 21:08 | <Domenic> | Yeah, everyone is, presumably, but in general it appears nobody agrees on error reporting in multiple globals in general |
| 21:08 | <smaug____> | it is just that I can't quite review the patch since I don't know what is the right thing to do |
| 21:08 | <Domenic> | Doing whatever feels consistent within your implementation makes sense to me for now |
| 21:08 | <Domenic> | One day we'll have time to figure it out |
| 21:10 | <smaug____> | not what I'm comfortable when reviewing patches :/ |
| 21:10 | <smaug____> | but I guess I'll have to live with that |