| 02:10 | <sideshowbarker> | TabAtkins: Regarding https://github.com/w3c/csswg-drafts/issues/12054#issuecomment-3837656822 I’m trying to figure out what needs to be done — what people want to be done. |
| 02:11 | <sideshowbarker> | Question: It seems like all the auto-publishing plumbing that Andreu had originally set up has maybe subsequently been superseded by tooling you set in since then? |
| 02:12 | <sideshowbarker> | And to make auto-publishing work for the FXTF and Houdini stuff, I could replicate the workflow y’all currently have set up for the w3c/csswg-drafts repo? |
| 02:13 | sideshowbarker | waves to Andreu Botella too |
| 02:14 | <sideshowbarker> | Andreu Botella: I don’t wanna bug you with stuff if you’re swamped and I can manage to get it working without you needing take any time away from what you’re working on |
| 02:15 | <sideshowbarker> | I’m gonna need to step away now from my machine for the next 90 minutes to 2 hours anyway — but I’ll get back to this after that |
| 02:16 | <sideshowbarker> | However, if anybody else has more clear idea of what exactly the problems are that need to be solved, and you want to take a shot at doing the set up to fix them, I wouldn’t mind at all if somebody beat me to it… |
| 02:20 | <Andreu Botella> | well, currently the index of specs is still handled by plins's server, and eventually we'd want to get that also generated by the gh actions workflow |
| 02:21 | <sideshowbarker> | OK, can definitely do that — probably by end-of-day my time |
| 02:22 | <Andreu Botella> | at first bin/build-index.py would build an index, as well as create level-less shortcuts (e.g. css-fonts for whichever the current level is) |
| 02:23 | <Andreu Botella> | and for that it'd use various heuristics to figure out which is the current work, with a list of exceptions |
| 02:23 | <Andreu Botella> | in my repo there's still a version of that that does generate an index, although it looks quite different from the one in plins's server |
| 02:25 | <sideshowbarker> | OK, I’ll take a look |
| 02:25 | <sideshowbarker> | the “various heuristics” is clearly the hard part… |
| 02:26 | <sideshowbarker> | for the csswg-drafts repor, there are corresponding “various heuristics” captured in existing build stuff there? |
| 02:27 | <sideshowbarker> | I mean, I just want something I could use as a model for the “various heuristics” for the other repos |
| 02:30 | <Andreu Botella> | okay, so first I'm trying to get the shortname from bikeshed metadata, and i'm hardcoding some cases where it's wrong (where the shortname includes the level): https://github.com/w3c/csswg-drafts/blob/main/bin/build-index.py#L68-L84 |
| 02:30 | <Andreu Botella> | there's something similar for html-only specs in get_html_spec_metadata |
| 02:33 | <Andreu Botella> | and in https://github.com/w3c/csswg-drafts/blob/main/bin/build-index.py#L171-L193 I'm grouping specs by their shortname, and for each shortname, i'm picking the earliest level that isn't marked as complete – or otherwise the highest level |
| 02:33 | <Andreu Botella> | and there's the list of exceptions for cases where that's wrong |
| 02:35 | <Andreu Botella> | in the august F2F folks mentioned that (at least for csswg-drafts) you can find out which level is the current work based on the github issue labels |
| 02:35 | <Andreu Botella> | but it'd be better to maintain that as a json in the repo or something |
| 04:44 | <sideshowbarker> | Andreu Botella: got it all, thanks — that’s enough for me to work with |
| 05:26 | <sideshowbarker> | Incidentally, I’ve noticed that the toolchain seems to still be set up to add some client-side script to the output HTML to make the w3c.github.io/csswg-drafts URLs redirect to drafts.csswg.org URLs |
| 05:27 | <sideshowbarker> | …but it apparently is no longer working, and I’ve tried to figure out why, but I haven’t been able to figure it out |
| 05:28 | <sideshowbarker> | But I’m not complaining. We shouldn’t be doing those redirects, so I’m glad it’s turned off … somewhere … or else, broken. |
| 05:28 | <sideshowbarker> | If something broke it accidentally, then thank god for that happy accident. |
| 05:57 | <sideshowbarker> | TabAtkins: Question: does --md-Text-Macro="BUILTBYGITHUBCI foo" have any purpose other than making that redirect happen? (when it was actually working/enabled) |
| 06:18 | <sideshowbarker> | ok wait, only now do I notice that y’all got all the FXTF drafts moved to the csswg-drafts repo? And you’re redirecting all the old URLs? And if so, then it gets me back to my original question of, trying to figure out what actual problem people commenting in https://github.com/w3c/csswg-drafts/issues/12054#issuecomment-3837656822 want solved |
| 06:47 | <TabAtkins> | What I want solved is to take Peter's server out of the loop entirely |
| 06:47 | <TabAtkins> | Just use GitHub to host and use our domain name |
| 06:49 | <sideshowbarker> | Yeah me too |
| 06:49 | <sideshowbarker> | so, let’s do that |
| 06:50 | <sideshowbarker> | I will huddle with the systems team and get a concrete plan put together for that |
| 06:51 | <sideshowbarker> | Chris Lilley wants that too |
| 06:51 | <sideshowbarker> | (I mean, as far as I can tell from his GH issue comment — I haven’t talked to him about out directly) |
| 06:52 | <sideshowbarker> | but I will not be volunteering to replicate anything from the drafts.csswg.org server except for the actual document publishing |
| 06:53 | <sideshowbarker> | whatever else myriad features it might have, I’m not gonna try to be the one to set up some server at w3c to do any of that other stuff |
| 06:55 | <sideshowbarker> | What I want is simply that: When some implementor from a browser project is in the middle of implementing some CSS feature, they can reliably access the CSS specs, and not instead have their work blocked by the server being down/broken/wedged |
| 06:56 | <sideshowbarker> | personally I would prefer to quit using that domain name, except for to hosting 301 redirects to the GH locations. But I don’t feel strongly about it — if we could just do the CNAME thing, then, fine. |
| 06:58 | <sideshowbarker> | TabAtkins: (or anybody else who might now) Do you have any idea what is being used by that server to do the markdown-to-html conversion? If so, I will try to set up something in the GH repo to do that. But if not, then I guess for now I’ll try to … black-box reverse-engineer it. |
| 06:59 | <sideshowbarker> | will just use the python markdown thing, I guess? |
| 07:19 | <TabAtkins> | personally I would prefer to quit using that domain name, except for to hosting 301 redirects to the GH locations. But I don’t feel strongly about it — if we could just do the CNAME thing, then, fine. |
| 07:20 | <TabAtkins> | TabAtkins: (or anybody else who might now) Do you have any idea what is being used by that server to do the markdown-to-html conversion? If so, I will try to set up something in the GH repo to do that. But if not, then I guess for now I’ll try to … black-box reverse-engineer it. |
| 07:23 | <sideshowbarker> | I wouldn’t object to others setting up that stuff. But in the meantime at least, I’m personally pretty happy with GH publishing. It’s what pretty much all other projects I contribute to outside of W3C are using, so … to me it’s reliable and familiar, at least. And now I say that, I do realize that for WHATWG stuff, we do have a different non-GH thing set up. So yeah, point taken. |
| 07:34 | <sideshowbarker> | OK, for the markdown-to-HTML conversion, here’s something quick and clean and simple: https://github.com/w3c/csswg-drafts/pull/13432/files |
| 07:35 | <jebez> | You understood not... To make it simple: In HTML, why a line break, new line is not interpreted, Related to https://wiki.archlinux.org/title/Help_talk:Editing#%3Cbr%3E_works_not_well. , https://www.mediawiki.org/wiki/Project:Support_desk#Why_%3Cbr%3E_instead_of_just_a_new_line? |
| 07:40 | <jebez> | You understood not... To make it simple: In HTML, why a line break, new line is not interpreted, <br> needed? It's not WYSIWYG... E.g. needs <br> here. https://www.w3schools.com/tags/tag_br.asp Related to https://wiki.archlinux.org/title/Help_talk:Editing#%3Cbr%3E_works_not_well. , https://www.mediawiki.org/wiki/Project:Support_desk#Why_%3Cbr%3E_instead_of_just_a_new_line? |
| 08:13 | <sideshowbarker> | next bit: https://github.com/w3c/css-houdini-drafts/pull/1165/files |
| 08:31 | <sideshowbarker> | OK, and now https://github.com/w3c/csswg-drafts/pull/13433/files will give us a proper index page at w3c.github.io/csswg-drafts — rather than a redirect to the legacy server |
| 08:32 | <sideshowbarker> | (and with that, I take a break to cook dinner) |
| 08:53 | <sideshowbarker> | Andreu Botella: (or anybody else who might know) What exactly is the “issues list” that needs to be built? Is that maybe https://drafts.csswg.org/issues.html? Or something else entirely? |
| 08:55 | <sideshowbarker> | I guess for now I’m gonna just assume that’s what it is, and try to figure out how to remake that |
| 08:55 | <sideshowbarker> | oh wait is just the bikeshed issues-list thing, I guess? |
| 15:51 | <zcorpan> | Noam Rosenthal: foolip : should pseudo-attribute parsing work differently in HTML docs vs XML docs? Right now xml-stylesheet uses XML-like parsing for the pseudo-attributes, also in HTML documents. |
| 15:51 | <zcorpan> | But we can switch to HTML-like syntax for xml-stylesheet in HTML docs, because why not |
| 15:52 | <foolip> | zcorpan: I think that it should, yeah. It would be fairly inconsistent with the rest of HTML if we require double quotes |
| 15:54 | <foolip> | zcorpan: If we define this is a little parser of data, I think we'd just use a different parser depending on the node document. For XML it would be the https://www.w3.org/TR/xml-stylesheet/#NT-PseudoAtts production, and for HTML, not totally sure yet, but maybe defined in terms of "<attrs " + data + ">", because that's actually how the XML thing is implemented. |
| 15:59 | <zcorpan> | foolip: that seems somewhat bogus since the data can contain > (also in HTML with DOM API) |
| 16:00 | <zcorpan> | Not sure if something bad happens because of it |
| 16:04 | <foolip> | zcorpan: yes, but there's no parser we could reuse that would skip past a ">". I think what we could do is to truncate data at the first ">" if it's there, before parsing. |
| 16:05 | <zcorpan> | foolip: > can be in a selector and works today https://software.hixie.ch/utilities/js/live-dom-viewer/saved/14487 |
| 16:09 | <Noam Rosenthal> | yea there's no way around escaping it inside a PI, due to compat with browsers that treat it as a bogus comment |
| 16:10 | <Noam Rosenthal> | This can happen today, if you adopt an XML PI and serialize it. if you re-parse it you'd get a bogus comment and some trailing characters |
| 16:12 | <Noam Rosenthal> | e.g. if you adopt <?echo "x>1" ?> after a couple of steps of parsing and re-serialization it would be <!-- echo "x -->1" ?> |
| 16:13 | <zcorpan> | Noam Rosenthal: Right, or if you use createProcessingInstruction. The question is if it's good enough to use the fragment HTML parser or so and concat the data like how browsers implement it now for XML xml-stylesheet (which isn't quite per spec), or if the possibility of > in the data makes the approach too bogus? |
| 16:14 | <Noam Rosenthal> | I think it's OK to fragment-parse it, and only accept as attributes if it produces exactly one element |
| 16:15 | <Noam Rosenthal> | so <attribs ${data}></attribs> would produce more than one (empty) element if $(data} has a > anywhere |
| 16:16 | <zcorpan> | <?xml-stylesheet ></?> |
| 16:16 | <Noam Rosenthal> | (or we can search for > in advance, it would produce the same result) |
| 16:18 | <Noam Rosenthal> | Yea that produces a bogus comment in addition to the element |
| 16:19 | <zcorpan> | Sorry I meant ></ as data |
| 16:20 | <zcorpan> | Becomes <attribs ></></attribs> which parses fine and there are no child nodes in attribs |
| 16:20 | <zcorpan> | But I can live with weird cases being weird |
| 16:21 | <Noam Rosenthal> | yea it would have an empty attrib with name "<" |
| 16:23 | <Noam Rosenthal> | also you could only get that by adopting an XML node and then setting its data with JS. |
| 16:24 | <zcorpan> | There is no < attribute in my example though? |
| 16:27 | <Noam Rosenthal> | Well you're taking an XML PI and re-parsing its data with HTML. Anyway, I'm also OK with saying that ">" means no attributes and everything else is HTML-parsed. It's all edge cases |
| 16:30 | <zcorpan> | Noam Rosenthal: right, agreed. Maybe don't need to scan for >. I can't envision real problems with it, if you parse into an inert DocumentFragment |
| 16:31 | <zcorpan> | I guess we should standardize the approach browsers use for XML xml-stylesheet, willfully violating the xml-stylesheet spec |
| 16:32 | <Noam Rosenthal> | It's definitely simpler than trying to be specific to "pseudo-attributes" and then trying to make it apply to HTML as well |
| 16:35 | <zcorpan> | Noam Rosenthal: I think the "clean" approach is to modify the HTML parser so that it can be started in before attribute name state, and make it stop parsing when it tries to switch to a non-attribute-related state. But that doesn't exist today and is probably too much heavy lifting for pseudo-attributes |
| 16:37 | <Noam Rosenthal> | Agreed |
| 20:50 | <TabAtkins> | https://github.com/w3c/css-houdini-drafts/actions/runs/21647222016/job/62402240607 btw, an error in the script |
| 21:00 | <TabAtkins> | ah, in both of them |
| 21:36 | <sideshowbarker> | Oh. I'll take a look |
| 21:53 | <sideshowbarker> | TabAtkins: https://github.com/w3c/css-houdini-drafts/pull/1166 |
| 22:05 | <TabAtkins> | error at a later stage now, during deploy it looks like https://github.com/w3c/css-houdini-drafts/actions/runs/21649294456/job/62409406208 |
| 22:08 | <sideshowbarker> | dang looking now |
| 22:10 | <sideshowbarker> | ah huhuh, just forget to actually flip on the GH Pages stuff in the repo settings. Will do that right now |
| 22:12 | <sideshowbarker> | https://github.com/w3c/css-houdini-drafts/actions/runs/21649294456/job/62411271506 re-running right now (update: ✅) |
| 22:15 | <sideshowbarker> | TabAtkins: voilà https://w3c.github.io/css-houdini-drafts/ |
| 22:15 | <TabAtkins> | now same fix on csswg-drafts ^_^ |
| 22:19 | <sideshowbarker> | the shopt -s nullglob fix for the ./**/Overview.html thing, you mean? Or something else I missed? |
| 22:21 | <sideshowbarker> | TabAtkins: GH Pages is already on at https://github.com/w3c/csswg-drafts/settings/pages at least. And we got the purty https://w3c.github.io/csswg-drafts/ index page |
| 22:21 | <TabAtkins> | oh indeed, sorry |
| 22:22 | <TabAtkins> | I guess I accidentally was looking at the Houdini page when I said csswg-drafts was failing in the same way. (tho it will fail the same way if it ever hits the same case, I guess) |
| 22:27 | <sideshowbarker> | haha yeah I was doing the same thing earlier — I mean, looking at the Houdini repo settings when I thought I was looking at the csswg settings |
| 22:29 | <Andreu Botella> | so how are things going? |
| 22:33 | <sideshowbarker> | Andreu Botella: most-visible progress is https://w3c.github.io/csswg-drafts/. Take a look there and try out the search and push some buttons. It’s fun 😄 But also practical. With 164 specs, otherwise making everybody scroll or rely on browser find-in-page is not the most beautiful UX… |
| 22:34 | <sideshowbarker> | oh I see https://github.com/w3c/csswg-drafts/pull/13432 hasn’t been merged yet. Got a merge conflict to resolve there. (And a comment from Florian to respond to) |
| 23:11 | <sideshowbarker> | TabAtkins: merge conflict fixed at https://github.com/w3c/csswg-drafts/pull/13432 (and responded to Florian’s comment: I am confident that Python-Markdown does everything y’all need, and there’s point in using any other thing instead). |
| 23:14 | <sideshowbarker> | Andreu Botella: I think the changes I made yesterday resolved all the immediate/acute problems that had been brought up in recent comments in https://github.com/w3c/csswg-drafts/issues/12054. There’s still some room to make refinements along the lines you alluded to in some of your own comments. But it seems like this is good enough for now. |
| 23:15 | <sideshowbarker> | I guess the one biggish pending thing is the migration of the Houdini stuff. But it doesn’t seem like there’s any problems there — it’s just a matter of that work actually needing to get done. |
| 23:26 | <sideshowbarker> | 👆 I guess that’s one specific remaining refinement that could be worked on. That, and figuring out if there’s some way to “which spec is the current work” algorithm slightly smarter. But IMHO the CURRENT_WORK_EXCEPTIONS thing is just fine. It’s only 8 cases. So it’s not a big deal to maintain. |