| 05:02 | <annevk> | jyasskin: ta, wonder if that is something we should offer control over at some point |
| 06:54 | <zcorpan> | TabAtkins: i now get a link error in cssom-view that https://w3c.github.io/uievents/#idl-mouseeventinit isn't marked for export, but it looks like it should be? |
| 07:13 | <TabAtkins> | zcorpan: Looks good to me with a fresh update? |
| 07:15 | <zcorpan> | Simons-MBP:cssom-view zcorpan$ bikeshed |
| 07:15 | <zcorpan> | LINK ERROR: No 'dictionary' refs found for 'MouseEventInit' that are marked for export. |
| 07:15 | <zcorpan> | TabAtkins: i just updated |
| 07:34 | <zcorpan> | wonder what's up with this id: <p id="date-state-%28type=date%29">When an <code>input</code> element's <code data-x="attr-input-type">type</code> attribute is in |
| 07:34 | <zcorpan> | (only id with % in source) |
| 07:43 | <annevk> | zcorpan: would ( and ) trip something up? |
| 07:45 | <zcorpan> | annevk: a few lines above has <h6 id="date-state-(type=date)"><dfn data-x="attr-input-type-date">Date</dfn> state (<code data-x="">type=date</code>)</h6> |
| 07:45 | zcorpan | runs a blame |
| 07:47 | <annevk> | oh, I wonder if it's a workaround for crappy browsers |
| 07:50 | <zcorpan> | b29fb58ce6139a1e297a915e7291e637c3e1b561 added these ids |
| 07:51 | <zcorpan> | the link on caniuse is https://html.spec.whatwg.org/multipage/forms.html#date-state-(type=date) - not percent-escaped |
| 08:44 | <zcorpan> | TabAtkins: https://drafts.csswg.org/bikeshed/cssom-view/ |
| 08:49 | <MikeSmith> | do we have branch snapshots for HTML? |
| 08:50 | <annevk> | MikeSmith: I don't think so, we should probably start poking at the tooling again a bit and maybe move more of it to Travis |
| 08:51 | <MikeSmith> | annevk: OK |
| 08:51 | <MikeSmith> | is there a way I can force a snapshot build for a PR? |
| 08:51 | <MikeSmith> | that is, by hacking on the .travis.yml on the branch maybe? |
| 08:51 | <MikeSmith> | or deploy.sh on the branch? |
| 08:52 | MikeSmith | looks while he’s waiting |
| 08:53 | <annevk> | MikeSmith: no, just locally |
| 08:53 | <MikeSmith> | oh I see no deploy stuff gets called from Travis for the HTML spec |
| 08:53 | <MikeSmith> | OK |
| 08:53 | <annevk> | MikeSmith: right |
| 08:53 | <annevk> | MikeSmith: it's the only spec we build on the server making it a bit of a liability |
| 08:54 | <MikeSmith> | OK |
| 08:54 | <MikeSmith> | well for now I just want to be able to generate multipage output with a change for y’all to look at |
| 08:55 | <MikeSmith> | I guess I can just scp it to my own server |
| 09:07 | <annevk> | Ah yeah, that's what I do |
| 09:23 | MikeSmith | adds a bunch of hashes to his CSP policy for all the inline style elements the HTML spec has |
| 10:13 | MikeSmith | finaally had to resort to 'unsafe-inline" and 'unsafe-eval' |
| 11:21 | <timwis> | morning folks. had a thought regarding custom elements.. couldn't i theoretically make my own custom elements via $('my-el-name').html('....') ? and maybe set some css on it to display: inline-block etc. |
| 11:22 | <timwis> | i know custom element spec provides more features but for basic stuff like abstracting a complex widget's html, it seems like this is a much lighter solution with a lot of browser support, no? |
| 11:26 | <annevk> | timwis: if you don't need complexity then you don't need it... |
| 11:27 | <timwis> | annevk: it being custom element spec? |
| 11:30 | <annevk> | timwis: yeah, there's always multiple ways to do things, what is best depends on the requirements and use cases |
| 11:31 | <timwis> | annevk: i guess my question is whether there's anything bad about using a fake tag. pretty sure that's an HTMLUnknownElement. and just adding functionality to it |
| 11:32 | <annevk> | timwis: can't think of much right now |
| 11:59 | <timwis> | thanks annevk. Just threw together a proof of concept: https://github.com/timwis/standards-components/tree/unknown-element (demo: http://phl-standards-unknown-elements.surge.sh/) |
| 12:48 | <Domenic> | timwis: it's confusing for other developers looking at your code. If you're just using a glorified div, then you should use the div tag. |
| 12:49 | <annevk> | That was the one thing I could think of, but I figured it might be fine since the semantics are locally-bound anyway |
| 12:53 | <annevk> | web-platform-tests doesn't appear to have tests for Navigator objects... |
| 12:56 | <Domenic> | It does |
| 12:56 | <Domenic> | annevk: https://github.com/w3c/web-platform-tests/tree/master/html/webappapis/system-state-and-capabilities/the-navigator-object |
| 12:57 | <annevk> | Oh right, I somehow skipped right over that in my grep results |
| 12:57 | <annevk> | Thanks |
| 13:16 | <annevk> | Domenic: so the way we deal with tearoff objects from Window seems really quite bad, they all have their own language and model, some based on document, some on the Window object, but no consistent language |
| 13:36 | <Domenic> | annevk: agreed |
| 13:36 | <timwis> | Domenic: ah, you mean like <div data-component="phl-button"></div> |
| 13:37 | <Domenic> | timwis: sure, or just use class="" |
| 13:37 | <Domenic> | or data-button |
| 13:37 | <timwis> | is the only downside to using <phl-button> instead that it's less obvious what's going on to people reading the code? |
| 13:37 | <Domenic> | There are probably a few other minor ones, including it being non-conformant HTML, but that's the major one. |
| 13:38 | <Domenic> | annevk: the one thing I'm on sure on is whether there should be a central location saying "Window has an associated X, Y, and Z" or if each object should define that in its definition. |
| 13:38 | <timwis> | Domenic: sorry if this is an obvious answer, but what's wrong with it being non-conformant HTML? |
| 13:39 | <annevk> | Domenic: not sure on? |
| 13:40 | <annevk> | Domenic: I'm fairly convinced still we want formalized slots and informal slots until that day comes |
| 13:40 | <annevk> | Domenic: the current haphazard way of describing relations between objects and state makes that very clear to me |
| 13:42 | <Domenic> | annevk: not sure whether WIndow should describe all its slots, or if e.g. Navigator should say "each window has an associated Navigator object" |
| 13:45 | <annevk> | Domenic: I think the latter style is confusing |
| 13:46 | <annevk> | Domenic: it's acceptable, but not how I'd like things to be |
| 13:47 | <annevk> | Domenic: what might work is that IDL takes care of most of it once we have formalized slots as I proposed long ago |
| 13:47 | <Domenic> | I'm still unclear on the benefits of formalized ones over informal ones. |
| 13:47 | <annevk> | Domenic: so that when a Window object is allocated, IDL allocates a Navigator and Location object as well |
| 13:47 | <annevk> | Domenic: in the same global |
| 13:48 | <annevk> | Domenic: and then puts them in their respective slots, which navigator and location would end up returning from |
| 13:48 | <Domenic> | Hmm, I never realized there was an implicit allocation of slot values implied. |
| 13:48 | <annevk> | (most of that could effectively be codegen at that point) |
| 13:49 | <annevk> | That's an idea for extending formal slots |
| 13:49 | <annevk> | And making things easier to define and more robust by default |
| 14:10 | <jyasskin> | Why is it easier to auto-create Navigator and Location into a formal slot than into their readonly attributes? |
| 14:15 | <annevk> | jyasskin: the latter doesn't work? That's just a getter |
| 14:17 | <jyasskin> | annevk: It seems like the same sort of webidl wording that would auto-create into slots could also specify that readonly attributes, maybe marked by an [ExtendedAttribute], have an instance in an implicit slot by default. |
| 14:17 | <annevk> | jyasskin: sure, that's a valid impl of formalized slots |
| 14:17 | <jyasskin> | Ah, SG. |
| 14:18 | <annevk> | jyasskin: I'm just talking at a higher-level here |
| 16:04 | <Domenic> | TabAtkins: what would be a good way to get https://github.com/w3c/web-platform-tests/issues/5625 on the CSSWG's radar? File an issue on https://github.com/w3c/csswg-drafts/issues maybe? Mailing list? Trying to get some broad discussion. |
| 17:59 | <jsbell> | annevk: Since it's part of the Blink ship process I filed a TAG spec review request for Storage. Hopefully any feedback given will be useful/constructive. |
| 18:05 | <annevk> | jsbell: I thought we already did that once? |
| 18:05 | <annevk> | jsbell: https://github.com/w3ctag/spec-reviews/issues/85 |
| 18:05 | <annevk> | jsbell: nothing really changed since then |
| 18:06 | <jsbell> | annevk; Oh! Hrm.... |
| 18:08 | <jsbell> | annevk: Huh... for some reason I thought I saw a note saying we intentionally hadn't. Maybe I was dreaming. :P Awesome, I'll close, never mind and thx |
| 21:58 | <astearns> | Domenic: I'll add 5625 to today's meeting agenda (TabAtkins) |