| 00:08 | <MikeSmith> | Domenic: does wattsi actually do syntax-highlighting for ABNF blocks as expected? |
| 00:10 | <MikeSmith> | nm |
| 00:10 | <MikeSmith> | looking at https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address, I see that it does |
| 00:25 | <TabAtkins> | heck yeah pygments |
| 00:26 | <MikeSmith> | :) |
| 00:28 | <MikeSmith> | now I’m struggling to remember how the Free Pascal HTTP client code in wattsi actually works.. |
| 01:14 | <MikeSmith> | TabAtkins: as far as I can tell, invalid WebIDL does not seem to cause the highlighter server to respond with a 400 |
| 01:16 | <MikeSmith> | testing with some invalid WebIDL, it does as expected emit an error message: |
| 01:16 | <MikeSmith> | > IDL SYNTAX ERROR LINE: 4 - skipped: "readonly attribute unsiggned long length" |
| 01:16 | <MikeSmith> | but the HTTP response code is still 200 |
| 01:17 | <MikeSmith> | (this is after pulling the latest highlighter code, with the response-code change) |
| 01:19 | <MikeSmith> | does the syntaxError function in highlighter/widlparser/widlparser/tokenizer.py actually cause an exception to be thrown? or does it just report an error? |
| 08:55 | <andreubotella> | Hi |
| 08:55 | <andreubotella> | I just raised my first issue for the encoding standard and I'd like to work on the PR |
| 08:55 | <andreubotella> | but I have a couple questions about the contributor agreement |
| 09:55 | <annevk> | TabAtkins: oh my, I need to write another bikeshed PR as the <img> does not have a width and height |
| 09:56 | <annevk> | TabAtkins: though maybe the gigantic notice at https://whatpr.org/infra/115.html#tracking-vector is what the web needs... hmm |
| 10:05 | <Ms2ger> | Fwiw, I'll be taking the rest of the month off |
| 10:06 | <annevk> | Ms2ger: enjoy / take care |
| 15:30 | <TabAtkins> | annevk: put a width/height on the svg file? |
| 15:31 | <annevk> | TabAtkins: bad for various reasons, no? |
| 15:31 | <TabAtkins> | No |
| 15:31 | <annevk> | Progressive rendering? |
| 15:32 | <annevk> | Also what if it was not SVG? |
| 15:32 | <TabAtkins> | It's completely fine, doesn't make it less flexible. The paining is assumed to be abspos, so the sizing doesn't affect layout. If it's not svg I expect the image to be sized correctly in the first place too |
| 15:33 | <annevk> | Why not 2x or 3x? |
| 15:33 | <annevk> | This seems like a weird thing to object to |
| 15:33 | <annevk> | And we might not want abspos forever |
| 15:33 | <TabAtkins> | If it's 2x it should be in srcset not "big src, force it small" |
| 15:34 | <TabAtkins> | (which I'm happy to adjust for fwiw) |
| 15:35 | <TabAtkins> | If you ever don't want it abspos I'm happy to discuss new features to make it work better at that point, but all the renderings over seen so far are abspos. |
| 15:38 | <annevk> | TabAtkins: I don't see what the big deal is with adding width/height |
| 15:39 | <TabAtkins> | More controls piling into the feature without a current need. |
| 15:39 | <annevk> | TabAtkins: it'd be rather inconsistent for WHATWG to have an SVG with intrinsic width/height |
| 15:39 | <TabAtkins> | I don't understand. |
| 15:39 | <annevk> | TabAtkins: can we then just switch to have a single WHATWG toggle? |
| 15:39 | <annevk> | TabAtkins: and the default is the inline SVG? |
| 15:40 | <TabAtkins> | There's nothing wrong with an svg having a width/height. |
| 15:40 | <annevk> | TabAtkins: because isn't that all that's been requested so far? |
| 15:40 | <annevk> | TabAtkins: there's also nothing wrong with an SVG without that |
| 15:40 | <TabAtkins> | Except for default sizing, sure. |
| 15:40 | <annevk> | which we don't want for our images |
| 15:40 | <annevk> | see https://resources.whatwg.org/ |
| 15:43 | <TabAtkins> | So stepping back a second, you're requesting a way to specify the size of your img. That's reasonable. There are two ways to do this - specify width/height on the <svg>, or on the <img> pointing to the SVG. On the img requires more work from me (impl, test, docs, future people having to read the docs and consider if they need to do something with that metadata), the other requires five seconds from you. |
| 15:44 | <TabAtkins> | They're otherwise identical in behavior given current styling. |
| 15:44 | <TabAtkins> | I don't understand the pushback, then. |
| 15:45 | <TabAtkins> | (I think it's actually considered a best practice to put a width/height on an svg, precisely to avoid this kind of "omg it's so big" sizing problem. It has no effect on the scalability of the svg, after all.) |
| 15:45 | <annevk> | TabAtkins: I supplied the PR |
| 15:45 | <annevk> | TabAtkins: I can also write a PR that reduces the amount of metadata as suggested above |
| 15:47 | <annevk> | And again, all I'm trying to ensure is consistency with our established practice of doing images |
| 15:48 | <annevk> | Having to revisit that because of tooling limitations that are easily addressed (there's a working patch) seems very strange |
| 15:50 | <annevk> | TabAtkins: I'll also volunteer to document the other Tracking Vector metadata thingies, if that helps at all |
| 15:50 | <annevk> | (from a simple grep they don't seem to be documented at least) |
| 15:51 | <TabAtkins> | Overall it's not a big deal, it's just that putting width/height on the svg itself is an easier, better idea most of the time anyway. |
| 15:52 | <annevk> | I'd love to understand why that's better than putting it on <img> directly |
| 15:52 | <annevk> | Seems to be that in general the opposite is true |
| 15:55 | <TabAtkins> | Viewing the image directly shows it at intended size (not fullscreen); it gives the <img> intrinsic dimensions; it means casual reference of it in an <img> won't break your layout until you remember to re-add width/height; it means (very slightly) less bytes sent to the user if you use the image more than once ^_^ |
| 15:55 | <TabAtkins> | Unrelated: OMG i can't figure out which keyboard layout i used to use, this current one is fucking KILLING ME with its dead keys |
| 15:56 | <annevk> | I guess we disagree on good/bad for some of these and I wonder if compression doesn't solve the last one |
| 15:57 | <TabAtkins> | Thus the "very slightly", yes ^_^ |
| 16:02 | <TabAtkins> | annevk: Related, aren't y'all using the exact same SVG that I'm inserting by default? Why customize it? |
| 16:04 | <TabAtkins> | (I used that specific SVG *because* it was the one suggested by zcorpan for WHATWG's use.) |
| 16:06 | <annevk> | TabAtkins: that came up in the original issue somewhere iirc, we don't want inlined SVG |
| 16:06 | <TabAtkins> | Oh, I must have missed that. |
| 16:09 | <TabAtkins> | Hm, that thread was in infra, right? |
| 16:10 | <annevk> | Maybe? |
| 16:10 | <annevk> | TabAtkins: https://github.com/whatwg/infra/issues/20#issuecomment-289709903 |
| 16:11 | <TabAtkins> | Ah, caching, right. |
| 16:53 | <annevk> | TabAtkins: anyway, it'd be great if we could agree on a way forward; would adding documentation help? Would you prefer a simple switch that has inline by default and otherwise enables a WHATWG mode? Or perhaps we could have a one line setting where we include the HTML to be inserted literally? Spitballing here... |
| 16:53 | <TabAtkins> | Yeah I'm just gonna accept it later today |
| 16:57 | <TabAtkins> | screenshot showing the tracking vector image overlapping the text on a narrow phone screen https://usercontent.irccloud-cdn.com/file/EplnfaoQ/Screenshot_20200114-073026.png |
| 16:58 | <TabAtkins> | This convinced me that we will want to have it inline sometimes, and so <img width height> is desirable |
| 16:58 | <annevk> | That's probably a better idea than what we are trying to do today |
| 16:58 | <annevk> | (making the image smaller) |
| 16:58 | annevk | files an issue |
| 17:03 | <TabAtkins> | Since it is before the text, a `float: right` should do the job quite nicely. |
| 21:54 | <tejr> | Can anyone tell me if it would be appropriate to ask for advice on good semantic markup practices in here, if I'm unsure about something even having read the spec? |
| 21:54 | <tejr> | (Well, what I think are the relevant parts of the spec, anyway...) |
| 22:01 | <TabAtkins> | yeah this place is fine to ask that sort of question |
| 22:49 | <tejr> | OK. I note that WHATWG's specification for <cite> seems to differ from the W3C one I was used to, in that it says e.g. an author's name should not be part of the citation. |
| 22:49 | <tejr> | Is there a recommended pattern of markup for a full citation of a work--author, title, edition, year of publication, ISBN number...? Have I missed it in the spec's recommendations? |
| 22:50 | <tejr> | My markup works fine and I'm happy enough with it; I am simply curious to know if there is a typical pattern for semantic markup for this |
| 22:52 | <tejr> | Here is what I'm doing: http://ix.io/27qw/html |
| 23:12 | <a-ja> | tejr, i think intent is to cite a work rather than its author |
| 23:18 | <a-ja> | have a look at https://schema.org/citation and https://schema.org/CreativeWork |
| 23:42 | <tejr> | Thank you |
| 23:51 | <tejr> | a-ja: On reading this, it's exactly what I needed, and something very useful to learn in general; thanks very much |
| 23:53 | <a-ja> | no prob, also do a search on "citation styles"...not that they're any help with markup |
| 23:54 | <tejr> | Yeah, I'm aware of those, I thought I was following one correctly there--I'll double-check that, too |
