| 00:27 | <GPHemsley> | annevk: Really? There are *more* contexts? |
| 06:38 | <TheSuoX> | hey all, what's new? |
| 06:43 | <annevk> | GPHemsley: https://fetch.spec.whatwg.org/#concept-request-context |
| 07:39 | <zcorpan> | https://lists.w3.org/Archives/Public/public-whatwg-archive/ doesn't have messages from before 2012? :-( |
| 07:47 | <annevk> | zcorpan: it does |
| 07:47 | <annevk> | zcorpan: for some reason those months are not listed |
| 07:47 | <annevk> | MikeSmith: ^ |
| 07:48 | <annevk> | zcorpan: but you can browse to e.g. https://lists.w3.org/Archives/Public/public-whatwg-archive/2004May/ and find the first set of messages |
| 07:48 | <zcorpan> | annevk: thx |
| 07:52 | <frivoal> | annevk http://dev.w3.org/csswg/css-egg/ is up, with a nice reference to https://fetch.spec.whatwg.org/#unicorn |
| 08:04 | <zcorpan> | MikeSmith: ok went through my bugs. closed most of them. feel free to reopen any INTENTIONAL if you want to fix them |
| 09:18 | <MikeSmith> | zcorpan: thanks |
| 09:19 | <MikeSmith> | zcorpan: would love to fix them all but right now just trying to figure out which of the long-open bugs might still be a priority for any odd the original commenters |
| 09:21 | <MikeSmith> | I think the biggest open issue that the most people care about is the error reported for ampersands in URLs |
| 09:22 | <MikeSmith> | which, were still not conforming to the spec there |
| 09:23 | <MikeSmith> | but that's complicated by the fact it's actually a parser issue |
| 09:25 | <MikeSmith> | hsivonen: it'd be nice if we could get that error-reported-for-ampersand thing resolved; last I recall I had a parser patch out top you for review |
| 09:26 | <MikeSmith> | annevk: I'll open a sysreq for that mailing-list archive index-page problem |
| 09:42 | <MikeSmith> | frivoal++ |
| 09:57 | <roc> | how I loathe April 1 |
| 09:59 | <annevk> | I would actually like to see about:unicorn irrespective of April 1, it's been a comment in the source of the specification for ages |
| 10:02 | <jgraham> | roc++ |
| 10:05 | <roc> | it doesn't help that April 1 effectively lasts for two days for me |
| 10:08 | <annevk> | roc: are we working on http://dev.w3.org/csswg/css-containment/#containment ? |
| 10:09 | <annevk> | roc: Firefox OS devs wants it, reportedly |
| 10:09 | <annevk> | want* |
| 10:09 | annevk | enjoys April 1, playing Pac Man on Google Maps is rather fun |
| 10:22 | <roc> | annevk: no |
| 10:22 | <roc> | what for? |
| 10:23 | <annevk> | roc: it allows you to give elements the same kind of isolation <iframe>s have and thereby improving perf (is the hope) |
| 10:23 | <annevk> | roc: and it would allow for resize events for those elements most likely |
| 10:26 | <roc> | I know what it does |
| 10:26 | <roc> | but what do they want it for? |
| 10:26 | <roc> | any specific case? |
| 10:27 | <annevk> | Probably best to ask Wilson Page directly, I suspect for the various components they create |
| 10:27 | <annevk> | He doesn't seem to be online atm :/ |
| 10:32 | <annevk> | roc: I'll find out and have him file a bug |
| 11:17 | <annevk> | JakeA: the links at the end of https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0003.html do suggest that we need to think harder about these permission requests we keep asking for |
| 11:18 | <annevk> | JakeA: we also got feedback from the game community that even by giving users incentive to e.g. grant the game fullscreen permission or some such, users end up ignoring the dialogs |
| 11:19 | <annevk> | JakeA: unfortunately I still don't have any great ideas, the bundling that some seem to argue for only seems to make things worse |
| 11:22 | <JakeA> | annevk: yeah, I'm nervous about bundling given the situation on Android |
| 11:22 | <JakeA> | Although Chrome bundles push messaging & notifications, which I think is fine |
| 11:23 | <JakeA> | annevk: I like your idea on the one-off sync thing (although it could get a bit onbeforeunload), but it's not what I was getting at in that thread |
| 11:24 | <annevk> | I don't like the way Chrome bundles push and notifications, since push really ought to be a distinct thing from displaying notifications |
| 11:25 | <annevk> | Well, I can see allowing push would also allow for notifications I guess. I don't like that it's currently required to show a notification. |
| 11:26 | <beverloo> | What we shipped is a first step, we're fully committed to getting "silent" push out of the door as well |
| 11:26 | <beverloo> | it's just much harder to convey to users what's going on |
| 11:26 | <annevk> | JakeA: my idea is that whenever you want to do synchronization traffic you'd request a one-off sync and do it from there |
| 11:26 | <annevk> | JakeA: that would avoid any kind of racing |
| 11:26 | <JakeA> | annevk: yeah, will reply to the thread |
| 11:26 | <beverloo> | so rather than making all kinds of decisions based on hunches, we may as well gather data and learn from developers about how they want to use the features |
| 11:27 | <annevk> | beverloo: so mt gave me the impression that Google's UX ideas influenced the spec, but maybe that's not really the case? |
| 11:27 | <beverloo> | The ideas were mostly driven by my team, but definitely influenced by UX as well |
| 11:28 | <annevk> | beverloo: I mean, in a way that prevents others from not having that coupling |
| 11:29 | <beverloo> | we worked that out with Martin / slightlyoff last week |
| 11:29 | <beverloo> | also, doug mentioned it wasn't completely crazy based on his firefox implementation :) |
| 11:29 | <annevk> | okay |
| 11:29 | <annevk> | ta |
| 11:40 | <JakeA> | annevk: Any idea why errors aren't structured-clonable? |
| 11:42 | <annevk> | JakeA: seems worth filing a bug on |
| 11:49 | <annevk> | So I tried requesting a resource of which the status was 101 and it seems what happens is that the browser just does another request hoping to get something back that is not 101 |
| 11:49 | <annevk> | Though I'm not entirely sure |
| 11:52 | <annevk> | Hmm actually, XMLHttpRequest towards it seems to work fine |
| 11:53 | <annevk> | And you get back the 101 etc. |
| 11:53 | <annevk> | But no body |
| 12:09 | <GPHemsley> | annevk: Oh my... And those are all necessarily distinct? |
| 12:32 | <annevk> | GPHemsley: yep |
| 12:34 | <GPHemsley> | annevk: Are their uses defined somewhere? |
| 12:35 | <annevk> | GPHemsley: not really, just the examples for now, until specs are updated to use Fetch |
| 12:36 | <annevk> | Hmm, 103 response results in a network error afaict |
| 12:36 | <GPHemsley> | annevk: Hmm... do you have notes as to why you split up ones that I had grouped together? |
| 12:37 | <annevk> | GPHemsley: basically we want all contexts to be unique, more or less |
| 12:37 | <annevk> | GPHemsley: for service workers, CSP, and Mixed Content |
| 12:37 | <annevk> | and anything else that might come along at some point |
| 12:37 | <GPHemsley> | hmm |
| 12:42 | <annevk> | GPHemsley: your grouping might still be adequate for sniffing purposes btw |
| 12:43 | <annevk> | GPHemsley: we don't necessarily want to have different handling for all of these contexts, we just want to allow for it and give a very granular context to developers |
| 12:46 | <GPHemsley> | sure |
| 12:46 | <GPHemsley> | for some reason, favicon keeps sticking out to me |
| 12:46 | <GPHemsley> | IDK if that's rational |
| 13:15 | <annevk> | zcorpan: what happens with a stylesheet if Content-Type is missing |
| 13:19 | <zcorpan> | annevk: the spec doesn't seem to be obviously clear about that |
| 13:19 | <zcorpan> | annevk: i seem to recall that missing content-type or content-type without a slash should mean text/css, but not sure |
| 13:20 | <zcorpan> | annevk: i'll file a bug to look into it |
| 13:22 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=28391 |
| 14:02 | <wilsonpage> | roc ping |
| 14:03 | <jgraham> | wilsonpage: I think it's like 3am for roc |
| 14:03 | bradleymeck | is confused and interested that fet has a read stream but not the streams API full in Chrome Canary |
| 14:03 | <bradleymeck> | fetch* |
| 14:03 | <wilsonpage> | jgraham oh, thanks |
| 14:03 | <wilsonpage> | jgraham what time-zone is he on? |
| 14:03 | <jgraham> | He's in NZ |
| 14:03 | <jgraham> | Usually |
| 14:04 | <wilsonpage> | Ah ok |
| 14:04 | <jgraham> | So NZDT apparently |
| 14:13 | <wanderview> | JakeA: can I have a ServiceWorker registered for scope ./a perform a network requests to ./b/foo.html and have that intercepted by a separate ServiceWorker registered for scope ./b? |
| 14:14 | wanderview | will probably be claiming "not enough coffee" shortly... |
| 14:14 | <JakeA> | wanderview: nah, requests from a page go through the serviceworker at navigator.serviceWorker.controller only |
| 14:14 | <wanderview> | right |
| 14:14 | <JakeA> | Which is registration.active on the registration that covers that scope |
| 14:15 | <wanderview> | JakeA: oh... but what about if the first ServiceWorker was only spawned to handle a background sync? |
| 14:15 | <annevk> | wilsonpage: did you get my email? |
| 14:15 | <wanderview> | JakeA: the background sync SW is not controlling the page, right? |
| 14:16 | <wanderview> | "the page" doesn't exist I guess |
| 14:16 | <wanderview> | JakeA: trying to think of a way to spawn a secondary SW for this issue: https://github.com/slightlyoff/BackgroundSync/issues/70 |
| 14:17 | <wanderview> | JakeA: this might be a good case for just having a ServiceWorker constructor... times when you want a SharedWorker like thing, but no document exists |
| 14:17 | <JakeA> | wanderview: the SW spawns in time to receive events such as "fetch", "sync", "push", "install" etc |
| 14:17 | <JakeA> | It can already spawn without a document |
| 14:18 | <JakeA> | Eg, browser receives a push message, it spins up the related SW & fires the push event |
| 14:18 | <wanderview> | JakeA: right... but in this case the web dev needs to do large amounts of sync work in response to the "sync" event... where should they do that? they cannot spawn a worker |
| 14:19 | JakeA | goes to read the issue |
| 14:19 | <wanderview> | wanderview: I guess if they just have a separate SW registration for the "sync" and a separate SW registration for "fetch", then they could just do all the synchronous work inline and not delay fetch events |
| 14:22 | wanderview | steps away for a bit |
| 14:37 | <JakeA> | wanderview: I don't think doing the email work in there is going to be a problem for fetches |
| 14:37 | <JakeA> | in the SW I mean |
| 15:05 | <wanderview> | JakeA: it does a lot of synchronous, blocking work to merge snippets together... on low end devices |
| 15:05 | <wanderview> | it was moved to a Worker previously due to jank |
| 15:05 | <JakeA> | wanderview: shouldn't it defer that until first view? |
| 15:06 | <wanderview> | JakeA: well... I guess that would jank the user experience |
| 15:06 | <wanderview> | or doing it earlier would help avoid janking user experence |
| 15:07 | <wanderview> | JakeA: its basically a pre-render thing, right? |
| 15:07 | <JakeA> | wanderview: hm, I guess I'm worried about sync being used for heavy processing due to battery. But yeah, it should be possible to create workers or connect to shared workers in a serviceworker. The |
| 15:08 | <wanderview> | JakeA: I don't know how creating a worker from ServiceWorker would work (alliteration!)... there is no document and other worker types require a document |
| 15:09 | <wanderview> | JakeA: I think the only worker type a ServiceWorker could reliably use is another ServiceWorker |
| 15:10 | <wanderview> | also, I thought chrome did not have nested workers implemented |
| 15:10 | <JakeA> | we don't |
| 15:11 | <JakeA> | wanderview: but I want to be able to get a request for an image, fetch it, create a worker, send the image into the worker, create a canvas worker, so some sync pixel work, send the result back, resolve respondWith |
| 15:11 | <JakeA> | If we can't have workers in SW, we should fix that |
| 15:11 | <wanderview> | JakeA: for fetch event the document exists... thats easier to handle I think... but for BG sync there is no document |
| 15:12 | <JakeA> | wanderview: why does a document need to exist? Couldn't the ServiceWorker itself (or any environment settings object) do the job? |
| 15:13 | <wanderview> | JakeA: if we can have a separate bg sync SW than the fetch event SW, then I think that is fine... but if they must be the same (I'm unsure of the API), then this would introduce network jank |
| 15:14 | <wanderview> | if fetch events start happening while the bgsync work is still being performed |
| 15:16 | <JakeA> | Although separate SWs are possible today, I really think workers within a single SW is the better approach for the edge cases where there's sync processing |
| 15:16 | <wanderview> | JakeA: I say we need a document for other Worker types because the spec says "Document" |
| 15:16 | <wanderview> | maybe that can be changed... but I bet it has all kinds of implications |
| 15:16 | <JakeA> | wanderview: The HTML spec has been fixed before :D |
| 15:17 | <wanderview> | JakeA: if we change SharedWorker not to need a Document... why do we have a ServiceWorker type? :-) |
| 15:18 | <JakeA> | wanderview: because .port doesn't make sense on ServiceWorker due to the lifecycle |
| 15:20 | <wanderview> | JakeA: well... there is gunk the ServiceWorker inherits from Worker now that we just throw in... seems similar... the distinguishing feature of ServiceWorker in my mind was "doesn't need a document" |
| 15:24 | <JakeA> | wanderview: looking through the spec, it seems like the document dependency is used to decide the worker's lifecycle. Seems like this should be allowed to include serviceworker clients, or be made to be client-generic. What do you think annevk? |
| 15:25 | <annevk> | JakeA: I agree, document is already pretty much irrelevant except for a few things |
| 15:25 | <wanderview> | JakeA: I think it will be easier to fix in the spec than the implementation |
| 15:27 | <JakeA> | Given that Chrome doesn't allow workers in workers, I imagine it's true there too |
| 15:27 | <wanderview> | JakeA: annevk: I think we should asking sicking about this... I believe he has opinions on ServiceWorker vs SharedWorker |
| 15:29 | <wanderview> | annevk: what do you think about my question above regarding why ServiceWorker type at all if SharedWorker won't need a Document any more? |
| 15:31 | <annevk> | wanderview: I think we discussed that |
| 15:32 | <annevk> | wanderview: I think the primary motivation is lifetime and persistence |
| 15:33 | <annevk> | wanderview: but they are very close |
| 15:33 | <wanderview> | the persistence seems a property of the registration to me |
| 15:33 | <annevk> | wanderview: I don't think we should have had both, but I don't really see a way out now |
| 15:33 | <wanderview> | and lifetime can be described via references to the SharedWorker (like it is today) |
| 15:33 | <annevk> | wanderview: only to perhaps deprecate SharedWorker over time |
| 15:34 | <wanderview> | like "FetchEvent holds a reference to the SharedWorker until respondWith() is called, etc." |
| 15:34 | <wanderview> | annevk: why deprecate SharedWorker? wouldn't it deprecate ServiceWorker? |
| 15:35 | <annevk> | wanderview: I don't think we can kill ServiceWorker |
| 15:40 | <wanderview> | JakeA: can you explain the problems you are worried about when you wrote: "Although separate SWs are possible today, I really think workers within a single SW is the better approach for the edge cases where there's sync processing" |
| 15:41 | <JakeA> | wanderview: To have two service workers you need separate registrations, you'll need to keep their updates in sync etc |
| 15:42 | <JakeA> | Btw, I'm open to the idea of allowing the browser to spin up multiple instances of the same serviceworker if there's a performance benefit, but I imagine that being difficult to debug. |
| 15:43 | <JakeA> | As in, in the same way a server will spin up multiple instances of node for multi-core concurrency |
| 15:43 | <wanderview> | JakeA: personally I'm coming around to having an API like new ServiceWorker() for spinning up an extra worker-without-document... |
| 15:45 | <wanderview> | JakeA: I don't think having the exact same SW script is important in this case... it seems you could have one script install call .update() on the other registrations |
| 15:46 | <wanderview> | or just make SharedWorker accessible without a document I guess... |
| 15:46 | <wanderview> | this API mismatch between ServiceWorker and other worker types seems more obvious to me now |
| 15:48 | <JakeA> | wanderview: I kinda like the idea of new ServiceWorker(). Bascially like SharedWorker but with the lifecycle of ServiceWorker |
| 15:49 | <JakeA> | So new ServiceWorker() couldn't open a websocket and monitor it in the way SharedWorker can, but it's more memory efficient than a sharedworker |
| 15:50 | <wanderview> | JakeA: sorry if this is obvious, but what makes a ServiceWorker more memory efficient than a SharedWorker? |
| 15:50 | <JakeA> | wanderview: it shuts down when it isn't in use |
| 15:51 | <JakeA> | whereas a sharedworker is alive while the parent document is alive |
| 15:51 | <wanderview> | JakeA: so holding the var sw = new ServiceWorker() would not hold it alive? |
| 15:52 | <wanderview> | in this hypothetical future universe |
| 15:52 | <JakeA> | well, that's the case today |
| 15:52 | <JakeA> | Having a reference to navigator.serviceWorker.controller does not stop it terminating |
| 15:52 | <wanderview> | JakeA: I guess it comes down to what event is firing in the ServiceWorker when you ask it do something... onmessage? |
| 15:52 | <JakeA> | wanderview: yeah, it'd absolutely be postMessage and onmessage |
| 15:53 | <wanderview> | so it would spin up for the onmessage event? |
| 15:53 | <JakeA> | wanderview: yep, that's what happens today |
| 15:53 | <wanderview> | JakeA: would the message event have waitUntil() as well? |
| 15:53 | <wanderview> | when waitUntil() is spec'd for fetch event |
| 15:54 | <wanderview> | or maybe it exists for message event already... I'm obviously ignorant of this part of the spec |
| 15:55 | <JakeA> | wanderview: it doesn't exist yet, but good point, it should. Or we have a global self.waitUntil - that's been suggested a couple of times |
| 15:55 | <wanderview> | yea, that would be more future proof as features are added |
| 15:57 | <JakeA> | wanderview: https://github.com/slightlyoff/ServiceWorker/issues/400 |
| 15:57 | <JakeA> | although it's confusing. If you do waitUntil(stuff) instead of event.waitUntil(stuff) in your install event, it appears to work, but if 'stuff' fails your serviceworker will still install |
| 15:59 | <wanderview> | JakeA: the name could be changed to disambiguate with the event.waitUntil() |
| 15:59 | <JakeA> | true |
| 16:00 | <zcorpan> | gsnedders: cssom specifies el.style.background http://dev.w3.org/csswg/cssom/#dom-cssstyledeclaration-_camel_cased_attribute |
| 16:00 | <wanderview> | JakeA: I don't understand slightlyoff's "it creates more questions than it answers" in that issue... it seemed most of the issues were around naming or method-vs-function... were there more serious internal google concerns? |
| 16:00 | <JakeA> | Not that I'm aware of |
| 16:01 | <wanderview> | JakeA: also, the event-specific waitUntil could be spec'd such that it uses the global wait-until-thing... but also mix in its extra install success/failure logic |
| 16:03 | <JakeA> | wanderview: https://github.com/slightlyoff/ServiceWorker/issues/669 |
| 16:03 | <JakeA> | wanderview: gotta run |
| 16:05 | <wanderview> | thanks! |
| 16:05 | <gsnedders> | zcorpan: oh that's just weird |
| 16:05 | <gsnedders> | zcorpan: like, in how it's spec'd, having IDL like that |
| 16:06 | <zcorpan> | gsnedders: yeah it's a bit weird. dunno how to make it less so |
| 16:07 | <gsnedders> | zcorpan: can you not just used named property getters/setters per WebIDL and then have a separate bit of magic? |
| 16:07 | <gsnedders> | makes the IDL less weird |
| 16:08 | <zcorpan> | gsnedders: is it black box equivalent? |
| 16:08 | <gsnedders> | zcorpan: I think it should be |
| 16:08 | <gsnedders> | zcorpan: will check once I get home |
| 16:08 | gsnedders | -> home |
| 16:09 | <zcorpan> | k |
| 16:11 | <gsnedders> | zcorpan: what level of black-box equiv. do we need? inc. whether the properties are data properties or getter/setter pairs? |
| 16:14 | <zcorpan> | gsnedders: getter/setter on the prototype i think. it's not strictly necessary for web compat but i think it's what we wanted to have here |
| 16:14 | <bradleymeck> | getters and setter :( |
| 16:15 | <gsnedders> | zcorpan: because oddly the catch-all getters/setters in WebIDL expose themselves as data properties. weird. |
| 16:33 | <zcorpan> | gsnedders: i would expect an implementation to just have a webidl file with all the css properties dumped, rather than magic like the spec |
| 16:44 | <JonathanNeal> | Standalone, which HTML element best represents a physical location? |
| 16:45 | <zcorpan> | JonathanNeal: <p>? |
| 16:48 | <JonathanNeal> | zcorpan: I wonder. <p> represents a run of text with one or more sentences that discuss a particular topic. It’s usually distinguished from labeling content. |
| 16:49 | <JonathanNeal> | I wish we had something like <location>, in the same way we have <time>. |
| 16:54 | <Domenic> | Why? What difference would it make? Is this about a hypothetical world where we have software that's interested in finding all web pages that have physical locations, but is not smart enough to do its own text parsing? |
| 16:56 | <zcorpan> | i wish we had <banana> to mark up physical bananas :-) |
| 16:58 | <jgraham> | Dammit zcorpan now I'm hungry |
| 16:58 | <zcorpan> | mohahaha |
| 17:03 | <annevk> | zcorpan: btw, I'll test that stylesheet thing for you |
| 17:04 | <zcorpan> | annevk: thanks! |
| 17:04 | annevk | is trying to figure out nosniff |
| 17:04 | <JonathanNeal> | Domenic, zcorpan: is this a minimalist argument? Like, why even have a <time> element? |
| 17:05 | <zcorpan> | JonathanNeal: we don't add anything without a compelling use case |
| 17:05 | <zcorpan> | JonathanNeal: "i want X" is not good enough |
| 17:05 | <zcorpan> | JonathanNeal: see https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F |
| 17:05 | <annevk> | JonathanNeal: in particular, don't forget about step 1 https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F |
| 17:05 | <annevk> | maha |
| 17:05 | zcorpan | win |
| 17:06 | <JonathanNeal> | We redefined <address> to the point that it can almost never represent a physical location. |
| 17:06 | <JonathanNeal> | Now we’re missing the ability to markup a location associated with content. |
| 17:06 | <Ms2ger> | Microformats |
| 17:06 | <botie> | Microformats is fairly focused around the development of microformats (specs) and everything related - so you're likely right there |
| 17:06 | <zcorpan> | <address> was never a location |
| 17:06 | <annevk> | HTML6 |
| 17:07 | annevk | would have expected an entry |
| 17:07 | <jgraham> | XHTML! |
| 17:07 | <annevk> | Looks like Ms2ger has some work to do |
| 17:07 | <jgraham> | <JonathanNeal:location> |
| 17:07 | <JonathanNeal> | I believe the answer is found later in that faq, zcorpan: “In the future, it is expected that the <time> element will be dropped.” |
| 17:07 | <Ms2ger> | Lol |
| 17:08 | <zcorpan> | when the <time> is right |
| 17:08 | <Ms2ger> | When <plaintext> is gone |
| 17:09 | <zcorpan> | that section can probably be removed, i think it's basically fixed now |
| 17:09 | <JonathanNeal> | zcorpan: <address> very name suggests a physical location, and it’s original definition was ambigiously against such a definition at best http://www.w3.org/MarkUp/html-spec/html-spec_5.html#SEC5.5.3 |
| 17:10 | <zcorpan> | JonathanNeal: the tag name is irrelevant, it's the element's definition that defines what the element means |
| 17:11 | <JonathanNeal> | zcorpan: which is why I shared that definition for you. |
| 17:11 | <zcorpan> | TODO(zcorpan): clean up FAQ, removing old stuff |
| 17:12 | <zcorpan> | JonathanNeal: "contains such information as address, signature and authorship" - ok, i stand corrected |
| 17:12 | <JonathanNeal> | I’m fine with the minimalist argument. I reject the idea that <time> is somehow valid but location is not. We have an API for time and location. We markup time and location as it results to a document or a section within a document. We even had an element, <address>, that was often used to markup location, and allowed for this in its original definition, |
| 17:12 | <JonathanNeal> | by the account I’ve shared above. |
| 17:13 | <zcorpan> | but in html4 it's not an address |
| 17:14 | zcorpan | gotta go |
| 17:14 | <JonathanNeal> | Its definition changes often. Even HTML5 Doctor has an outdated, vague definition and it claims to be for HTML5 http://html5doctor.com/the-address-element/ |