| 00:02 | <ccat> | jgraham: is this considered HTML namespace <HTML> here? <HTML> |
| 00:07 | <jgraham> | ccat: If you don't understand namespaces, then it's not surprising you're having difficulty with all of this. |
| 00:08 | <jgraham> | http://en.wikipedia.org/wiki/XML_namespace might be some good background reading |
| 00:09 | <jgraham> | The important thing to know is that although HTML is not XML, the HTML DOM still has a concept of namespaces, and under normal circumstances, all elements in a HTML document end up in the HTML namespace |
| 00:33 | <ccat> | jgraham: the difference between R in insulation, R in chemestry, and R in electronics, but again... |
| 00:33 | <ccat> | jgraham: is this considered HTML namespace <HTML> here? <HTML> |
| 00:34 | <ccat> | jgraham: (sorry, was called away) |
| 00:54 | <MikeSmith> | ccat: for text/html documents, the notion of the HTML namespace has relevance only after the document is parsed |
| 00:54 | <ccat> | MikeSmith: ohhh, ok |
| 00:55 | <MikeSmith> | there's no way to specify the HTML namespace in the serialized document, and no need to |
| 00:56 | <MikeSmith> | the parser automatically just puts all the elements into the HTML namespace in the DOM |
| 00:57 | <ccat> | MikeSmith: so this is NOT considered to create HTML namespace <HTML> here? <HTML> |
| 00:58 | <MikeSmith> | man read what I said there and what jgraham said above |
| 00:58 | <MikeSmith> | that question basically doesn't mean anything |
| 00:58 | <MikeSmith> | that question you just asked |
| 01:00 | <ccat> | MikeSmith: sorry, the "parser" sentence was not on the screen yet |
| 01:04 | <ccat> | MikeSmith: the problem is: "collection = document . getElementsByTagName(localName) ... (Matches case-insensitively against elements in the HTML namespace within an HTML document.) --- which means getE("TAG") will find element <tag> |
| 01:23 | <MikeSmith> | ccat: why is that a problem |
| 01:27 | <ccat> | MikeSmith: ok, think the real problem is that the doc starts by referring to an HTML doc with JS code getE(), which SOUNDS like user's point of view -- but then instead of just specifying returned results as tag-examples, it abruptly "switches" to engine's point of view and describes them by NAMESPACE |
| 01:45 | <ccat> | jgraham: ^^ ? |
| 02:05 | <ccat> | MikeSmith: jgraham : sorry if you responded -- irc webclient reloaded and lost all info |
| 02:06 | <MikeSmith> | ccat: didn't respond |
| 02:07 | <ccat> | MikeSmith: did you see the problem with the description though? |
| 02:08 | <MikeSmith> | ccat: no I don't really. This stuff is pretty fundamental to understanding the entire spec. If a reader doesn't understand how this works, then there are lots of other places in the spec that are going to seem confusing I guess |
| 02:09 | <MikeSmith> | ccat: so I don't know what else to add except that if you think the spec doesn't make all this clear enough, the thing to do is to propose some specific wording that you think would make it more clear |
| 02:13 | <ccat> | MikeSmith: trying to do that, but first needed to understand what was the intended meaning of the doc-note. Think i got that now |
| 02:18 | <ccat> | MikeSmith: "Thus, in an HTML document," if you follow the <<HTML document>> link back 2 levels it goes to Node -- so what is a file of HTML called in the docs if not a HTML document? |
| 02:21 | <MikeSmith> | ah |
| 02:21 | <MikeSmith> | so yeah, it's probably not called anything in the spec |
| 02:22 | <MikeSmith> | ccat: this is the DOM spec, you mean? |
| 02:23 | <MikeSmith> | at least I know in the HTML spec, there's really know term defined for "a file of HTML" |
| 02:23 | <MikeSmith> | both specs pretty much entirely refer to the DOM representation of a document |
| 02:24 | <MikeSmith> | "HTML document" in the HTML spec certainly always means the parsed document in the DOM |
| 02:24 | <MikeSmith> | I guess it would be an improvement if it were to define the term "serialized HTML document" |
| 02:26 | <ccat> | https://dom.spec.whatwg.org/#dom-document-getelementsbytagname -- y, dom... and THAT is probably the whole issue -- dom is internal (i.e namespace) -- though html-doc to normal reader is a text file |
| 02:27 | <MikeSmith> | ccat: true |
| 02:27 | <MikeSmith> | but the specs are not written for normal readers |
| 02:27 | <MikeSmith> | not by a long shot |
| 02:27 | <MikeSmith> | this is the problem with trying to write a spec that caters both the implementors and to authors |
| 02:28 | <MikeSmith> | the authors lose |
| 02:28 | <MikeSmith> | the result is tons of confusion on the part of authors because of stuff like this |
| 02:28 | <ccat> | MikeSmith: so it is NOT an HTML ref for the USER (html writer) but for the IMPLEMENTER (html engine maker) |
| 02:29 | <MikeSmith> | yes |
| 02:29 | <MikeSmith> | Hixie might try to tell you otherwise |
| 02:29 | <ccat> | MikeSmith: author meaning html-user |
| 02:29 | <MikeSmith> | ccat: yeah you're much better off using guides like MDN |
| 02:31 | <MikeSmith> | ccat: and also you can contribute to MDN to help make it better |
| 02:32 | <MikeSmith> | for specific cases like this, you can make refinements to MDn |
| 02:32 | <MikeSmith> | directly, because it's just a Wiki basically |
| 02:33 | <MikeSmith> | and it has experienced people who are editors and can review the changes and make fixes is something you contributed is wrong in some way |
| 02:35 | <ccat> | MikeSmith: well... tried mdn (mozilla?) but that's not an Authority, w3 but too in-progress, then found whatwg who says w3 has gone astray and isn't up to date with the world -- and now back to MDN :D |
| 02:39 | <Domenic> | My strategy is to just learn how to read implementation terms |
| 02:41 | <MikeSmith> | Domenic: I'm not sure I'd recommend that strategy to most authors. I'm not sure how much benefit it buys them relative to the cost in time needed to learn it |
| 02:41 | <MikeSmith> | but I could be wrong |
| 02:41 | <Domenic> | Yeah, I think it only makes sense if you're the kind of nerd who would enjoy the learning experience anyway |
| 02:42 | <Domenic> | Not for just getting your job done |
| 02:42 | <MikeSmith> | ccat: http://discourse.specifiction.org/ is another really good discussion forum for asking questions and making proposals and getting feedback |
| 02:42 | <MikeSmith> | Domenic: sure |
| 02:43 | <ccat> | i tried to do that with table "sortable" and got nowhere... unless that is because "sortable" is not yet widely supported so i'm told :D -- i.e doomed from the start? |
| 02:43 | <MikeSmith> | I think there are plenty of people like that, who value having the knowledge and like spending time on the learning |
| 02:43 | <MikeSmith> | ccat: yeah sortable is a fiction at this point |
| 02:43 | <ccat> | a belated aggggggg |
| 02:44 | <MikeSmith> | I personally like sortable a lot but for browser vendors it's not a priority to implement it |
| 02:45 | <MikeSmith> | I think it's safe to say at this point that it's very unlikely to get implemented natively in any browser any time soon |
| 02:45 | <ccat> | consider: "Thus, in an HTML document, document.getElementsByTagName("FOO")" -- so is document.getElementsByTagName() "supposed" to mean a root node with child f()? |
| 02:45 | <MikeSmith> | sorry I don't know what that question means |
| 02:47 | <MikeSmith> | ccat: btw http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ is very much worth reading |
| 02:47 | <MikeSmith> | and approachable |
| 02:48 | <MikeSmith> | "As a web developer, learning the internals of browser operations helps you make better decisions and know the justifications behind development best practices." |
| 02:52 | <ccat> | MikeSmith: nm the q. Conclusion is the doc is just awkwardly worded unless you know what it means. --- ...in which case you don't need it anyway :D |
| 02:53 | <MikeSmith> | fair enough |
| 02:53 | <ccat> | when was this decided: "Document nodes are simply known as documents" |
| 02:54 | <MikeSmith> | in the 1990s |
| 02:54 | <MikeSmith> | as far as discussions about the specs goes |
| 02:54 | <MikeSmith> | ccat: anyway the thing is you really do have to read the entire spec |
| 02:55 | <MikeSmith> | the parts of the spec aren't meant to be completely clear to a reader who hasn't done that |
| 02:57 | <MikeSmith> | and the spec can't really repeat clarifying statements in every single section to remind readers what's meant by, e.g., "document" |
| 02:58 | <MikeSmith> | it would just be annoyingly repetitive and unwieldy |
| 03:03 | <ccat> | MikeSmith: true, but saying "in the html doc the function docu.F() returns.." really does imply a text html doc because where else can docu.F() exist? (unless as a node with function-object?) |
| 03:25 | <ccat> | where is the tag-type, the zzz in <ZZZ>, in this IDL? - https://html.spec.whatwg.org/multipage/dom.html#elements-in-the-dom |
| 03:29 | <MikeSmith> | ccat: I don't know what "tag-type" is |
| 03:29 | <MikeSmith> | nor what you mean by "the zzz in <ZZZ>" |
| 03:30 | <MikeSmith> | but IDL pretty much has nothing to do with start tags or end tags |
| 03:31 | <MikeSmith> | ... and dunno what else you might mean by "tag" |
| 03:37 | <ccat> | MikeSmith: the type of tag, like br, a, li, -- (sorry forgot HTML tags are all LC ....now) |
| 03:39 | <ccat> | -- interface HTMLElement : Element --- "which all the HTML elements' interfaces inherit" |
| 03:40 | <ccat> | MikeSmith: the IDL in question ^^ |
| 03:49 | <MikeSmith> | yeah still I have no idea what you mean by "the type of tag" |
| 03:50 | <MikeSmith> | the HTMLElement interface doesn't expose any information about the name of element |
| 03:50 | <MikeSmith> | other interfaces inherit from HTMLElement |
| 03:53 | <MikeSmith> | e.g, when the parser encounter a <meta> tag in serialized document, it creates an HTMLMetaElement instance in the DOM |
| 03:57 | <MikeSmith> | maybe what you're looking for is .tagName? |
| 03:57 | <MikeSmith> | or .nodeName |
| 03:58 | <MikeSmith> | lor lcoalname |
| 03:58 | <MikeSmith> | localName |
| 04:02 | <ccat> | MikeSmith: kind of tag? in <p> sometext <br> moretext <p> the p's are different tags; the p's and br are different kinds/types of tag? --- y, tag-name or node-name |
| 04:03 | <MikeSmith> | "the p's are different tags"? different from what? different from each other? different from the <br> tag? |
| 04:05 | <MikeSmith> | in HTML a "<p>" in serialized document is just called "a start tag named p" |
| 04:05 | <MikeSmith> | the spec doesn't talk anywhere about the "type" of the tag |
| 04:06 | <MikeSmith> | it's either a start tag or an end tag, with a name |
| 04:08 | <MikeSmith> | looking now, I see「A start tag whose tag name is "meta"」is the exact verbatim formulation the spec uses |
| 04:09 | <MikeSmith> | "Tags contain a tag name, giving the element's name. HTML elements all have names that only use alphanumeric ASCII characters. In the HTML syntax, tag names, even those for foreign elements, may be written with any mix of lower- and uppercase letters that, when converted to all-lowercase, matches the element's tag name; tag names are case-insensitive." |
| 04:09 | <MikeSmith> | from https://html.spec.whatwg.org/multipage/syntax.html#elements-2 |
| 04:14 | <ccat> | MikeSmith: as in... an html webpage uses many different kinds of tags --- sorry, should have used the proper term tagName in the first place, but it did not come to mind and used the informal description "type of tag" |
| 04:16 | <ccat> | MikeSmith: -- maybe because that IDL does have an (unrelated?) itemType |
| 04:25 | <ccat> | -- either way, cant find it on the IDL |
| 04:54 | <MikeSmith> | ccat: huh I have no idea what itemType is |
| 04:55 | <MikeSmith> | for teh ELement interface? |
| 04:55 | <MikeSmith> | ah |
| 04:55 | <MikeSmith> | HTMLElement I see |
| 04:56 | <MikeSmith> | I don't think UAs support that |
| 04:56 | <MikeSmith> | the microdata api |
| 04:56 | <MikeSmith> | or maybe gecko still ships it |
| 04:57 | <MikeSmith> | another example of something that personally seems really useful to me but that browser projects don't care much about |
| 04:58 | <ccat> | MikeSmith: y, the element IDL -- but for tagName, did not see where tagName is specified, and was just wondering |
| 04:59 | <ccat> | MikeSmith: oops, the HTMLelement IDL -- a different thing :) |
| 07:55 | <zcorpan> | https://www.chromestatus.com/metrics/feature/timeline/popularity/195 \o/ |
| 07:58 | <Domenic> | itshappening.gif |
| 08:17 | <annevk> | nice |
| 08:18 | <annevk> | chromestatus always fails on first load in Firefox, seems like you need to have some resources cached... |
| 08:26 | <roc> | jgraham: If I was to add a web-platform test for MouseEvent.offsetX/Y, where would I add it and what would I call it? |
| 08:44 | <annevk> | roc: you could add one here https://github.com/w3c/web-platform-tests/tree/master/DOMEvents |
| 08:44 | <annevk> | roc: mouseevent-offsetxy.html or some such I guess |
| 08:44 | <annevk> | And at some point we should rename DOMEvents to ui-events |
| 10:17 | <jgraham> | roc: annevk's suggestions seem reasonable |
| 10:29 | <roc> | jgraham: are the comments in README.md still true, that to get web-platform tests into the tree we have to submit to the W3C first and then wait for an import? |
| 10:32 | <Ms2ger> | No |
| 10:35 | <jgraham> | roc: No, if you want to commit directly to the gecko tree we have a script to upstream those changes. It will be more widely advertised once it has proven itself a little better ;) |
| 11:23 | <ccat> | . |
| 11:24 | <ccat> | jgraham: Hixie: re: https://dom.spec.whatwg.org/#dom-document-getelementsbytagname -- Conclusion: ok, the note is about the HTML dom-doc and NAMESPACE, not the HTML text-doc, but saying it like " IN the html document the function docu.getE("<FOO>") will..." really does imply the text html-doc because what else could docu.getE() exist IN ? (unless it's a node with child function-object?) -- Good Luck! |
| 11:24 | <ccat> | . |
| 11:25 | <ccat> | PS: thanks for the time MikeSmith and jgraham :) |
| 11:25 | <ccat> | . |
| 11:42 | <MikeSmith> | ccat: cheers |
| 11:43 | <ccat> | MikeSmith: :) -- BTW what about https://www.webplatform.org/ docs? |
| 12:29 | <beverloo> | annevk, fwiw, we have implementation storage limits on pretty much anything |
| 12:29 | <beverloo> | it'll be very high and unlikely to get in the developer's way |
| 12:29 | <beverloo> | and we'll have data on how often people hit it |
| 12:30 | <annevk> | Yeah I don't really see the problem, as in that it's already a thing you need to account for with structured clones in various APIs |
| 12:30 | <beverloo> | I don't think we have a problem :) |
| 12:30 | <beverloo> | I'm OK with a no-change solution |
| 12:30 | <annevk> | good |
| 12:33 | <jgraham> | annevk: BTW I didn't really feel like people addressed Aryeh's concern about the persistent permission thing. If a site uses these permissions all the time for something rather normal then users will expect to be granting them all the time so lack of persistance won't change much (even moreso if the permissions last for a whole session rather than a single API call; do they?) So it seems like the only real value of this change is making the UX for p |
| 12:33 | <jgraham> | ... bad that sites feel like they have to use HTTPS instead. Which is a valid strategy ofc, albeit a risky one |
| 12:36 | <annevk> | jgraham: yeah that is a valid point, hmm |
| 12:46 | <annevk> | jgraham: a bit of that sentence got dropped btw |
| 12:47 | <jgraham> | "So it seems like the only real value of this change is making the UX for permissions over HTTP so...", perhaps? |
| 12:56 | <annevk> | jgraham: I think for geolocation Aryeh might be correct, not convinced for Fullscreen and Pointer Lock |
| 12:57 | <annevk> | jgraham: for geolocation the attacker would just inject a side channel, but exploiting Fullscreen and Pointer Lock actually requires a different site to be presented |
| 13:01 | <jgraham> | If you have something like a game running in fullscreen you can probably replace the "end game" function with something that doesn't actually exit fullscreen. I'm not sure how to get people to go from there to the fake site though. |
| 13:02 | <jgraham> | I mean the fake banking site or whatever |
| 13:15 | <zcorpan> | jgraham: maybe it could have a browser written in JS to let the user continue browsing |
| 13:22 | <jgraham> | Haha, just compile Firefox in emscripten :) |
| 14:04 | <adrianr1> | hiya |
| 14:16 | <MikeSmith> | jgraham: Ms2ger so the w3c systeam is trying to install the needsinfo-flag extension but they ran into an error |
| 14:16 | <MikeSmith> | who should we talk to? |
| 14:17 | <jgraham> | MikeSmith: glob, I guess |
| 14:17 | <MikeSmith> | hai |
| 14:17 | <Ms2ger> | ^ |
| 14:17 | <MikeSmith> | can I ping glob on #developers? |
| 14:17 | <jgraham> | MikeSmith: Yeah, or there's a bugzilla channel somewhere |
| 14:20 | <jgraham> | #bugzilla in fact |
| 14:20 | jgraham | decides it probably wasn't to blame for the random kernel panic he got the moment he switched to it |
| 14:45 | <beverloo> | annevk, let me know if there's anything I can do to make the anolis->bikeshed move easier. It's near impossible to review |
| 14:48 | <annevk> | beverloo: can you put up a copy somewhere or did you already do that? |
| 14:50 | <beverloo> | https://secure.peter.sh/notifications.html |
| 14:50 | <Ms2ger> | peter.sh? Why not peter.py? |
| 14:50 | <beverloo> | less exploitable? |
| 14:52 | <MikeSmith> | heh |
| 14:54 | <annevk> | beverloo: it seems dfn.js does not work though that's a general bikeshed problem |
| 14:54 | <annevk> | beverloo: although actually, we made that work for url.spec.whatwg.org |
| 14:54 | <beverloo> | I don't know what dfn.js does? |
| 14:55 | <beverloo> | I looked at the url spec quite a bit, happy to try to figure out how it's working there |
| 14:55 | <annevk> | beverloo: when you click on a definition, it shows you a popup with links to where the definition is used |
| 14:55 | <beverloo> | aah, I see. yeah, I did notice that |
| 15:09 | <annevk> | "The data attribute's getter must return a structured clone of notification's data." seems like this needs some caching to be defined... |
| 15:10 | <annevk> | beverloo: other than dfn.js I can't spot anything obviously wrong |
| 15:11 | <beverloo> | I'll have a look at the dfn.js issue later today |
| 15:11 | <annevk> | beverloo: at the top it says "Version History" and doesn't use a distinct <dd> for the Twitter account |
| 15:41 | <MikeSmith> | thanks mathiasbynens |
| 15:42 | <MikeSmith> | annevk: so it looks like we got the needsinfo flag working now in w3c bugzilla |
| 15:42 | <MikeSmith> | thanks to glob and to laurent from the w3c systems team |
| 15:43 | <MikeSmith> | mathiasbynens and I just tested it |
| 15:43 | <annevk> | cool beans |
| 15:43 | <mathiasbynens> | MikeSmith: \o/ |
| 15:44 | <MikeSmith> | so once y'all use it for real, if you notice any problems lemme know |
| 22:12 | <Ms2ger> | Wow, I never knew cheilmann was this clueless: http://christianheilmann.com/2015/03/09/advancing-javascript-without-breaking-the-web/ |
| 22:13 | <Hixie> | which part in particular? |
| 22:14 | <Ms2ger> | The "let's do browser-sniffing and make it look like feature-detection" bit |
| 22:15 | <Hixie> | oh ok good, that's the part that stood out to me |
| 22:16 | <Ms2ger> | I stopped reading after that |
| 22:23 | <gsnedders> | wait what |
| 22:23 | <gsnedders> | that's crazy |
| 22:23 | <gsnedders> | le sigh |
| 22:23 | <gsnedders> | people! |