| 00:25 | <jpwhiting> | hey all, I'm trying to use a local copy of validator.nu to validate against a custom schema, but haven't found how to enter the custom schema into the web service |
| 00:25 | <jpwhiting> | is this the right place to ask about it? |
| 00:26 | <jpwhiting> | hmm, the irc page says many of you share my timezone -0700 interesting |
| 00:26 | <jpwhiting> | anyone around by chance? |
| 00:28 | <Hixie> | this is a reasonable place to ask |
| 00:28 | <Hixie> | you want MikeSmith or hsivonen |
| 00:28 | <Hixie> | they're both probably asleep right now |
| 00:28 | <jpwhiting> | ok, thx |
| 00:28 | <jpwhiting> | ah, europeans? |
| 00:28 | <Hixie> | hsivonen: is in europe and MikeSmith in japan |
| 00:28 | <Hixie> | er |
| 00:29 | <jpwhiting> | np, I'll hang out here for the next week or so probably |
| 00:29 | <Hixie> | s/ hsivonen / jpwhiting |
| 00:29 | <jpwhiting> | hehe |
| 00:29 | <Hixie> | or no, just remove the colon |
| 00:29 | <Hixie> | what am i saying |
| 00:29 | <jpwhiting> | I've already messed up your tab completion hehe |
| 00:29 | <Hixie> | i'm clearly too tired to be working |
| 00:29 | <Hixie> | time to edit the spec |
| 00:33 | <Hixie> | ap: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=18460 |
| 00:34 | <ap> | Hixie: looking |
| 00:37 | <ap> | Hixie: I don't have a proposed verbiage for the spec. All I know is that XSLT spec requires producing <br></br>, and that this is bad for HTML |
| 00:38 | <ap> | Hixie: Simon Pieters appears to know more, having said "If you're going to fix it, why not fix it properly?" |
| 00:39 | <ap> | Hixie: whether we can get XSLT spec to change, I also don't know |
| 00:39 | <Hixie> | surely XSLT outputs XML |
| 00:39 | <Hixie> | if it outputs </br> in text/html then it's just wrong |
| 00:39 | <Hixie> | which doesn't seem like an HTML bug |
| 00:40 | <ap> | Hixie: they wrote their spec under the assumption that HTML elements have an empty namespace |
| 00:40 | <ap> | Hixie: and then HTML changed |
| 00:41 | <ap> | Hixie: HTML spec already patches the XSLT spec, http://www.w3.org/TR/html5/dom.html#interactions-with-xpath-and-xslt |
| 00:41 | <Hixie> | woah, man, don't like to the TR/ page :-) |
| 00:41 | <Hixie> | http://whatwg.org/#interactions-with-xpath-and-xslt |
| 00:41 | <Hixie> | er |
| 00:42 | <Hixie> | http://whatwg.org/html#interactions-with-xpath-and-xslt |
| 00:42 | <zewt> | it's a trap |
| 00:42 | <ap> | Hixie: sorry, didn't mean to offend :). just copied the link from https://www.w3.org/Bugs/Public/show_bug.cgi?id=18460 |
| 00:42 | <Hixie> | ap: sure, i'm happy to patch it more. i just need to know what to say. |
| 00:43 | <Hixie> | anyway, i'll ping zcorpan again |
| 01:23 | <MikeSmith> | jpwhiting: hi. Looking now |
| 01:25 | <MikeSmith> | jpwhiting: ok, you need to use the "schema" parameter |
| 01:25 | <MikeSmith> | http://wiki.whatwg.org/wiki/Validator.nu_Common_Input_Parameters#schema |
| 01:26 | <MikeSmith> | "This parameter takes a space-separated list of schema IRIs (http or https). The schemas can be RELAX NG 1.0 schemas, Schematron 1.5 schemas or identifiers for built-in non-schema-based checkers." |
| 01:29 | <jpwhiting> | MikeSmith: yeah, I'd like to embed mine into the validator.nu itself running locally, but haven't been able to yet |
| 01:30 | <MikeSmith> | ah |
| 01:30 | <jpwhiting> | I've also found two places within the tool that have schemas, both syntax/relaxng and validator/schema |
| 01:30 | <jpwhiting> | not sure which location is used |
| 01:31 | <jpwhiting> | I've copied my schema .rnc file to both places and it includes other .rnc files also, but I get an error http://paste.kde.org/687836/ |
| 01:31 | <jpwhiting> | and have added it to both validator/entity-map.txt and validator/presets.txt |
| 01:32 | <jpwhiting> | it's a copy of syntax/relaxng/html5.rnc with some things commented out like ruby and svg |
| 01:35 | <MikeSmith> | jpwhiting: if you go into the validator/src/nu/validator/localentities/files directory, do you see a corresponding file there? |
| 01:36 | <jpwhiting> | MikeSmith: nope |
| 01:36 | <jpwhiting> | no *sta* in there |
| 01:36 | <jpwhiting> | I am trying to run with build/build.py --local run |
| 01:37 | <MikeSmith> | did you already do a "build/build.py build" after you added the scheam? |
| 01:37 | <MikeSmith> | *schema |
| 01:37 | <jpwhiting> | ah, no |
| 01:37 | jpwhiting | tries |
| 01:39 | <jpwhiting> | ok, then if I run it gives a different error, Syntax error File: http://s.validator.nu/common.rnc Line: 1 Col: 0 |
| 01:40 | <jpwhiting> | is it not expecting rnc format? |
| 01:42 | <jpwhiting> | http://paste.kde.org/687854/ |
| 01:42 | <MikeSmith> | jpwhiting: Reference to undefined pattern “html.elem”. |
| 01:42 | <MikeSmith> | appsears to be the root cause |
| 01:43 | <MikeSmith> | your schema seems to be using the html.elem pattern before it's defined |
| 01:43 | <jpwhiting> | ah, that appears after include "common.rnc" |
| 01:43 | <jpwhiting> | just like in syntax/relaxng/html5.rnc |
| 01:44 | <jpwhiting> | do I need to move start = html.elem above it? |
| 01:44 | <jpwhiting> | does it use the rnc files from syntax/relaxng? or from validator/schema I guess |
| 01:45 | jpwhiting | moves it in validator/schema/sta.rnc |
| 01:45 | <jpwhiting> | and rebuilds |
| 01:45 | <MikeSmith> | yeah that's probably what you want |
| 01:46 | <MikeSmith> | I think what those errors indicate is that it's not finding a common.rnc file a tall |
| 01:46 | <MikeSmith> | *at all |
| 01:46 | <MikeSmith> | nor any of the other includes |
| 01:46 | <jpwhiting> | ah, because that's in syntax/relaxng but not validato/schema |
| 01:46 | <jpwhiting> | ok, /me copies |
| 01:51 | <MikeSmith> | yeah that may work |
| 01:51 | <MikeSmith> | it's seems to be finding the "meter.rnc" file OK |
| 01:51 | <MikeSmith> | which I assume is a file you added |
| 01:51 | <jpwhiting> | yep |
| 01:52 | <MikeSmith> | so if you put copies of the other files in the same place where that one is, you should be OK |
| 02:19 | <MikeSmith> | hsivonen: http://validator.nu/ not responding (though http://html5.validator.nu/ is responding fine) |
| 02:39 | <MikeSmith> | jgraham: https://code.google.com/p/pywebsocket/issues/detail?id=101 is the same as what's causing the websocket test problems, I think |
| 02:39 | <MikeSmith> | fix is https://code.google.com/p/pywebsocket/source/detail?r=552 "Support Python 2.7" |
| 02:39 | <MikeSmith> | I think I just need to update the pywebsocket install on w3c-test.org and that should fix it |
| 02:40 | <MikeSmith> | hopefully |
| 02:43 | <MikeSmith> | hmm no |
| 02:43 | <MikeSmith> | unfortunately |
| 02:44 | <MikeSmith> | we already have that fix |
| 02:57 | <jpwhiting> | MikeSmith: ok, another question, validator/entity-map.txt has html5/html5full.rnc and such but there's no html5 folder in validator/schema |
| 02:58 | <jpwhiting> | where do those files come from? |
| 02:58 | <MikeSmith> | from syntax/relaxng |
| 02:59 | <MikeSmith> | that "html5/" basically is an alias for syntax/relaxng |
| 03:00 | <MikeSmith> | sorry for the hairiness of this but it's not something that's really designed to be user-hackable very easily |
| 03:00 | <jpwhiting> | ah, so I don't need to copy these files from syntax/relaxng to validator/schema, just need to make my schema use html5/blah for it's includes |
| 03:00 | <jpwhiting> | makes sense |
| 03:00 | <MikeSmith> | even when I go in and touch that stuff I have to re-learn where everything is |
| 03:00 | <jpwhiting> | ah, np I didn't expect it to be simple (for a project that use a build script for running a web service too) :) |
| 03:00 | <jpwhiting> | yep, np |
| 03:04 | <jpwhiting> | sweet, that worked :) |
| 03:12 | <jpwhiting> | hmm, seems to get stuck on the initial html tag though :/ |
| 03:13 | <jpwhiting> | http://pastebin.com/dkW3xxFV says unnamespaced html element as the first and only error |
| 03:13 | <jpwhiting> | when using my schema or html5+svg+mathml schema |
| 03:13 | jpwhiting | checks the html5.rnc that's used in the presets, maybe I'm missing something |
| 04:23 | <MikeSmith> | jpwhiting: that would seems to indicate that it's going through the XML parser for some reason |
| 04:24 | <MikeSmith> | ah yeah I think I know why |
| 04:24 | <MikeSmith> | you have to tell that code that's an HTML-compatiable schema |
| 04:24 | <MikeSmith> | I think otherwise it assumes XML |
| 04:24 | <MikeSmith> | gimme a minute |
| 04:27 | <MikeSmith> | ah no |
| 04:28 | <MikeSmith> | it's in the JS for the UI |
| 04:29 | <MikeSmith> | jpwhiting: validator/site/script.js you have to add your schema URI to that list of isHtmlCompatiblePreset URIs |
| 04:30 | <MikeSmith> | otherwise the validator is going to assume it's XML |
| 04:54 | <esprehn_> | hmm, how do you do a createPattern but with image scaling? |
| 04:54 | <esprehn_> | drawImage takes a dh and dw |
| 04:56 | <esprehn_> | oh sigh, you need to drawImage() it into another canvas :( |
| 07:26 | <annevk> | Hixie: :-( |
| 07:28 | <annevk> | Hixie: It's really simple. XHR invokes fetch, asynchronously for the purposes of this discussion. Fetch queues tasks. XHR needs to piggyback on those tasks to do various things. If we can label the tasks somehow, that would make the piggybacking easier as the relationship between the tasks queued and what XHR is doing would be perfectly clear. |
| 07:30 | <annevk> | Hixie: And as far as I can tell there's a couple of such points: data is being transmitted to the server, header data has been received from the server, body data is being received from the server, everything is in |
| 07:32 | <annevk> | So the HTML WG does really copy the WHATWG, including typos in my last name: https://github.com/w3c/html/commit/b2e4d7e252df4c1be9e71666ec794ab0b2fa3a3e |
| 07:32 | <annevk> | Glad to see they're also adopting the URL Standard though, that's nice. |
| 07:33 | <annevk> | Also amusing that Microsoft would make such a commit. Maybe they didn't pay attention to what was going on? With DOM Parsing & Serialization they were all over it. |
| 08:54 | <annevk> | I guess I'll go with both tasks and callback like things like DOM has. E.g. such as http://dom.spec.whatwg.org/#node-is-inserted |
| 09:23 | <SteveF> | MikeSmith: https://twitter.com/brucel/status/308862208396386305 |
| 09:25 | <annevk> | source code of opera.com looks pretty buggy |
| 09:26 | <marcosc> | annevk: is ok, it works in webkit :) |
| 09:27 | <annevk> | and it has <main>, prolly all good |
| 09:27 | <marcosc> | heh |
| 09:28 | <odinho> | Hmm. Should have a tidy post-processing step probably. |
| 09:29 | <odinho> | Just because, strange people like annevk takes a look at the source without using an inspector which does it for you P: |
| 09:30 | <annevk> | You make me feel like an endangered species |
| 09:30 | <SteveF> | so question is does opera mini beta for android expose acc layer provided in webkit? |
| 09:31 | <SteveF> | will test and find out... |
| 09:32 | <gsnedders> | SteveF: There is no Opera Mini Beta — there is just "Opera", with both the Chromium-based renderer and the Presto-based "off-the-road mode". |
| 09:33 | <SteveF> | gsnedders: OK so same question diff name |
| 09:34 | <jgraham> | SteveF: I think gsnedders answered the question :) |
| 09:34 | <gsnedders> | The OBML impl is largely the same, so change there won't exist. The Chromium-based renderer I don't know about here. |
| 09:35 | <SteveF> | "Chromium-based renderer" may equal acc layer exposed |
| 09:36 | <odinho> | SteveF: Waiting for it ;-) |
| 09:36 | <SteveF> | odinho: so is that a not yet? |
| 09:36 | <odinho> | SteveF: Waiting for you to test it, that is :D |
| 09:37 | <asmodai> | I must say, Opera 14 on my mobile works nicely so far. |
| 09:37 | <SteveF> | odinho: OK am firing up nexus now |
| 09:56 | <SteveF> | and nexus won't fire up... |
| 09:57 | <odinho> | :/ |
| 10:07 | <SteveF> | some bug when the battery is low, now how to fix |
| 10:09 | <annevk> | http://lists.w3.org/Archives/Public/www-international/2013JanMar/0327.html "The web site uses its own non-standard tags, tc and sc. Instead, they should be using the BCP 47 tags zh-Hant and zh-Hans (or zh-Hant-HK and zh-Hans-HK)." |
| 10:10 | <annevk> | Given that people already do simple stuff like lang=nl incorrectly, asking them to go to those extremes... |
| 10:10 | <annevk> | I think that's basically asking for people to give up on correct annotation. |
| 10:15 | <mounir> | annevk: lang=nl is incorrect? |
| 10:15 | <annevk> | mounir: no, but people forget to tag it as such or use lang=en instead due to copypasta, etc. |
| 10:18 | <mounir> | "tag it as such"? |
| 10:18 | <SimonSapin> | mounir: forget to have a lang attr at all? |
| 10:19 | <Ms2ger> | <html>Stroopwafels |
| 10:19 | <Ms2ger> | <html lang=en>Stroopwafels |
| 10:19 | <mounir> | I guess I just should sleep more during the night... |
| 10:19 | <annevk> | mounir: http://www.answers.com/topic/tag 11.1 ;-) |
| 10:19 | <SimonSapin> | sleeping during the day is fine too |
| 10:20 | <annevk> | sleep all the things |
| 10:20 | <annevk> | Ms2ger: yum |
| 10:32 | <mounir> | SimonSapin: indeed, the main issue is that not everybody agrees with that |
| 10:38 | <annevk> | If you have a class that has a couple of subclasses. How do you refer to the class excluding the subclasses? |
| 10:39 | <annevk> | And how would you refer to the class including the subclasses? |
| 11:24 | <marcosc> | mmm... copypasta |
| 11:27 | <marcosc> | annevk: about the classes, are you speaking generally or in some particular language? |
| 11:31 | <annevk> | Is https://groups.google.com/forum/?fromgroups=#!forum/jquery-standards dead? |
| 11:31 | <annevk> | marcosc: language is English |
| 11:36 | <marcosc> | annevk: argh, that's hard as it's context dependent. And gets into taxonomies. |
| 11:36 | <annevk> | marcosc: you have a response |
| 11:36 | <jgraham> | onology! |
| 11:36 | <annevk> | marcosc: a response can be a redirect or network error any other response, named response |
| 11:36 | jgraham | wins the thread |
| 11:37 | <annevk> | or any other response* |
| 11:37 | <jgraham> | Or I would if I could type |
| 11:37 | <jgraham> | sigh |
| 11:37 | <annevk> | sometimes you want to refer to response and include redirects and network errors, sometimes you don't |
| 11:37 | <jgraham> | *ontology |
| 11:38 | <marcosc> | ./ban jgraham "forbidden word used!" |
| 11:38 | <annevk> | lets owl it up |
| 11:38 | <marcosc> | heh |
| 11:38 | <annevk> | but really, none of this is helping |
| 11:38 | <marcosc> | annevk: you might make a group just for those cases |
| 11:39 | <annevk> | marcosc: name it |
| 11:40 | marcosc | runs bikeshed.js |
| 11:43 | <marcosc> | argh. That's a hard one. I wonder if you are just better off listing them as you do above. |
| 11:45 | <marcosc> | given that you have response already cleanly defined; then you just include x, and exclude y, as you just did. That was making pretty good sense to me. |
| 11:45 | <marcosc> | even jgraham could follow along! :) |
| 11:45 | <annevk> | okay, so that's what I've done so far |
| 11:46 | jgraham | isn't following :p |
| 11:47 | <marcosc> | heh |
| 12:09 | <annevk> | Okay, so http://html5.org/temp/fetch.html is a bit clearer now... Now I guess I need to define "request" and remove some of those red boxes... |
| 12:12 | <hsivonen> | oh. lovely. Thunderbird uses a different encoding detector interface than Firefox |
| 12:13 | <hsivonen> | but we are building that code for Firefox, too |
| 12:14 | <annevk> | Meaning we just have some additional dead code? |
| 12:14 | <hsivonen> | annevk: well, it's not dead in TB. but dead in FF, yeah |
| 12:26 | <hsivonen> | annevk: I wonder if we have use cases for the CJK detector... |
| 13:07 | <smaug____> | annevk: so what did you decide? HEADERS_RECEIVED + LOADING in the same task or separate ? |
| 13:08 | <smaug____> | ah, perhaps no decision yet. fetch.html doesn't mention either one |
| 13:14 | <SteveF> | odinho: browser chrome is usable with talkback on android can't get anything from web content, but that maybe just me as I am not overly familiar with AT on android |
| 13:27 | <mounir> | annevk: ping |
| 13:32 | <annevk> | mounir: yo |
| 13:32 | <annevk> | smaug____: can you think of a way to make that detectable? |
| 13:33 | <annevk> | smaug____: if not, it probably does not make sense to make requirements either way |
| 13:33 | <annevk> | smaug____: I will make it more explicit in what order headers -> loading -> progress -> done happens though via some kind of English version of callbacks |
| 13:33 | <smaug____> | annevk: it is detectable with nested event loop spinning. |
| 13:34 | <annevk> | jamesr: ^ |
| 13:34 | <mounir> | annevk: refresh my memory: if I have a connnection from my laptop (like file:///) to a server, the CORS request will use "Origin: null"? |
| 13:34 | <annevk> | mounir: yes, if that works at all |
| 13:35 | <mounir> | what do you mean? |
| 13:35 | <annevk> | mounir: well UAs might disallow outgoing requests from file: as that could be a privacy concern of sorts |
| 13:36 | <mounir> | ok |
| 13:36 | <annevk> | smaug____: so during headers_received you invoke showModalDialog or some such and then what? I always forget how this works |
| 13:37 | <mounir> | so if UA allows it, we have "Origin: null" and should "Access-Control-Allow-Origin: *" makes "Origin: null" allowed? |
| 13:37 | <mounir> | (on the server side) |
| 13:39 | <smaug____> | annevk: right. if state is changed twice during the same task and first change spins event loop, the second state change happens only after nested spinning ends... and in fact it would be possible to get ordering wrong. 11243, I think |
| 13:40 | <annevk> | smaug____: so once data: URL fetching works, everything will be fetched at once basically |
| 13:41 | <annevk> | smaug____: (just saying as another data point) |
| 13:41 | <smaug____> | does data: fetching need to work that way? |
| 13:42 | <annevk> | we're going to define how it works, it could queue 3 networking tasks |
| 13:45 | <annevk> | smaug____: so I think what you're saying makes me think we should always have at least 4 tasks |
| 13:45 | <annevk> | 1. headers are in |
| 13:45 | <annevk> | 2. part of the body is in or there is no body |
| 13:45 | <annevk> | 3. progress is made (repeat) |
| 13:45 | <annevk> | 4. teehee |
| 13:46 | <odinho> | I like the teehee-part. |
| 13:46 | <annevk> | mounir: euhm, yes |
| 13:46 | <annevk> | mounir: but if there's credentials in the request, it needs to be spelled "null" on the server |
| 13:46 | <annevk> | mounir: and there'd need to be a Access-Control-Allow-Credentials header |
| 13:46 | <smaug____> | annevk: well, 3 is optional |
| 13:47 | <hsivonen> | annevk: is the right way to do encoding alias resolution from JS to do (new TextDecoder(label)).encoding ? |
| 13:47 | <annevk> | smaug____: so sometimes we'd not dispatch progress at all? even though we'd dispatch loadstart and loadend? (works for me btw) |
| 13:47 | <annevk> | hsivonen: yes |
| 13:48 | <hsivonen> | annevk: except that returns in lower case rather than Gecko-canonical case, right? |
| 13:48 | <annevk> | hsivonen: yes and it also does not work for replaced |
| 13:48 | <mounir> | annevk: didn't catch that |
| 13:48 | <annevk> | mounir: is this a fetch via XHR? |
| 13:48 | <hsivonen> | annevk: sigh. I guess we'll need some xpconnected goo for getting the pref UI right |
| 13:49 | <annevk> | mounir: if so, server requirements depend on the withCredentials attribute |
| 13:49 | <annevk> | hsivonen: it seems kinda odd to put such a thing in the standard |
| 13:49 | <mounir> | annevk: yes, it's trough XHR |
| 13:49 | <annevk> | hsivonen: but implementing the requirements from the standard is trivial just in JS too... |
| 13:49 | <annevk> | hsivonen: although someone would have to keep it in sync |
| 13:50 | <annevk> | mounir: so what's unclear? |
| 13:50 | <smaug____> | annevk: oh, right, there would be the final progress event, maybe |
| 13:50 | <annevk> | mounir: * on the server works, if the request has the withCredentials set to true, the server needs null and the ...-Allow-Credentials: true header |
| 13:51 | <mounir> | if the request hasn't withCredentals set to true? |
| 13:51 | <annevk> | smaug____: oooh, but that means you're right :) |
| 13:51 | <hsivonen> | annevk: I'm not suggesting putting the Gecko-canonical case in the spec for now |
| 13:51 | <annevk> | smaug____: as the final progress event is dispatched in the same task that dispatches loadend |
| 13:52 | <smaug____> | *of course* I'm right :p |
| 13:53 | <annevk> | smaug____: if only you realized it :p |
| 14:29 | <zewt> | annevk: we were trying to guarantee that an onprogress at 100% would always happen, iirc |
| 14:30 | <annevk> | zewt: yeah, I forgot it was there |
| 14:41 | <annevk> | Hmm, <track> inherits crossorigin from the parent media element? |
| 14:51 | <zcorpan> | annevk: yes |
| 14:52 | <zcorpan> | annevk: we considered using <track crossorigin> instead but in the end decided against it |
| 14:53 | <zcorpan> | annevk: for reasons involving author expectation, redundancy, and lack of use cases for different crossorigin settings for each track, iirc |
| 14:53 | <zcorpan> | and that it's relatively trivial to inherit in the impl |
| 15:48 | <jpwhiting> | MikeSmith: still around? |
| 15:49 | <jpwhiting> | I added my rnc file to the list of isHtmlCompatiblePreset URIs and now it says " Schema Error: The chosen preset schema is not appropriate for HTML." |
| 15:51 | <jpwhiting> | maybe because I created it in build.py with the same lines as html5core but used schemaDriverToggle_Html5 instead of HtmlCore |
| 15:51 | <jpwhiting> | ah, /me missed a line though |
| 15:52 | <MikeSmith> | jpwhiting: looking now |
| 15:54 | <jpwhiting> | I would send you a diff but your build system uses many svn and mercurial instances to checkout, so it's very tricky to make a patch... |
| 15:54 | <MikeSmith> | jpwhiting: yeah as I first thought earlier it's not enough to add your schema to the JS file |
| 15:54 | <jpwhiting> | ah |
| 15:55 | <MikeSmith> | you have to add your schema URL to validator/servlet/VerifierServletTransaction.java |
| 15:55 | <MikeSmith> | line 807 or so |
| 15:55 | <MikeSmith> | schemaUrls.startsWith |
| 15:55 | <jpwhiting> | I don't have a servlet folder under validator here |
| 15:56 | <MikeSmith> | private boolean isHtmlUnsafePreset |
| 15:56 | <jpwhiting> | ah, src/nu/validator/servlet? |
| 15:56 | <MikeSmith> | ah yeah that |
| 15:56 | <MikeSmith> | (shouldda copied the whole path) |
| 15:57 | <jpwhiting> | np, ok, I'll try with that too |
| 15:57 | <jpwhiting> | thanks |
| 15:57 | <jpwhiting> | perfect, thanks |
| 16:03 | <mounir> | darobin: could you have a look at https://github.com/darobin/respec/pull/156 ? |
| 16:23 | <darobin> | mounir: LGTM |
| 16:23 | <darobin> | do you need this in a build soon? |
| 16:23 | <jgraham> | darobin: Wrong browser |
| 16:23 | <darobin> | jgraham: huduhwha? |
| 16:24 | <jgraham> | LGTM = WebKit, r+ = Mozilla, Accepted = Opera (Critic) |
| 16:24 | <jgraham> | Dunno what Microsoft use |
| 16:24 | <TabAtkins> | jgraham: You're thinking Chrome, maybe? WebKit is r+ |
| 16:24 | <jgraham> | We could probably have an uncharitable competition |
| 16:24 | <darobin> | heh |
| 16:25 | <jgraham> | Oh, Chrome then |
| 16:25 | <TabAtkins> | We use bugzilla just like Moz does. |
| 16:25 | <jgraham> | Sure, but I hear WebKit people say LGTM in bugzilla |
| 16:25 | <jgraham> | Or see, really |
| 16:25 | <darobin> | I really meant Let's Go Troll Mounir |
| 16:25 | <darobin> | but hey |
| 16:26 | <jgraham> | darobin: You mean we weren't supposed to start until now? |
| 16:26 | <TabAtkins> | jgraham: Sure, it sounds weird to r+ something in chat. |
| 16:26 | <darobin> | jgraham: I thought we were missing some oomph in our trolling |
| 16:27 | <jgraham> | TabAtkins: I am clearly not an expert here, but I'm pretty sure I see Moz. people say r+ outside of the status field |
| 16:28 | <TabAtkins> | Eh, they could. |
| 16:29 | <mounir> | darobin: i need that to get FPWD for the runtime spec |
| 16:29 | <mounir> | so if it could be in a build soon that would be great |
| 16:29 | <mounir> | but no rush |
| 16:29 | <darobin> | is soon == today or soon == tomorrow? |
| 16:30 | <mounir> | darobin: as you prefer, really |
| 16:30 | <annevk> | no rush means in 5 min typically |
| 16:31 | <darobin> | mounir: well, if I preferred today I'd JFDI instead of asking you :) |
| 16:32 | <mounir> | darobin: I meant the "no rush" :) |
| 16:33 | <mounir> | so do it tomorrow |
| 16:33 | <annevk> | So I think we should have three CORS modes |
| 16:33 | <annevk> | taint / no / yes |
| 16:33 | <darobin> | mounir: coolness then |
| 16:33 | <annevk> | and then the other stuff Hixie invented is some kind of cross-origin setting for cookies and such |
| 16:34 | <jgraham> | Not :I'm confused", "Seriously WTF" and "I'm going to hunt down the persaon that invented this piece of shit and kill them with a spoon"? |
| 16:34 | <darobin> | ~~/ Oooh my baby CORS, now it's a yes, now it's a no, really taint what it used to beeee /~~ |
| 16:34 | <jgraham> | Or am I confusing it with appcache? |
| 16:34 | <darobin> | jgraham++ |
| 16:35 | <jgraham> | Anyway, sorry I think annevk was makign a sensible point… |
| 16:36 | <TabAtkins> | annevk: Are those modes that the server opts into, or that the client requests? |
| 16:36 | <annevk> | darobin: not sure if joking or expressing an opinion by means of ? |
| 16:36 | <TabAtkins> | Or that the fetch algorithm uses? |
| 16:36 | <annevk> | TabAtkins: fetch |
| 16:36 | <TabAtkins> | Ah, okay. Yeah, enough things taint that it would be useful to capture that in the algo directly. |
| 16:37 | <annevk> | CORS no could then be used instead of the force same-origin flag |
| 16:37 | <darobin> | annevk: I was just singing |
| 16:37 | <darobin> | probably something sounding like Abba |
| 16:38 | <annevk> | and CORS no / CORS taint is what the potentially CORS fetch thing goes into depending on the value of the crossorigin attribute |
| 16:39 | <annevk> | and then I guess I'd write some kind of wrapper text that allows Hixie to use the old calling conventions for fetch...? |
| 16:40 | <TabAtkins> | Also: write some goddam explanatory text so the rest of us can actually figure out how to invoke your spec. ^_^ |
| 16:44 | <annevk> | which spec? |
| 16:44 | <TabAtkins> | Last time I looked at CORS to try and use it (I forget for which spec), I couldn't figure out what to actually *do* with it. |
| 16:45 | <annevk> | there's text on what specifications are supposed to do |
| 16:45 | <TabAtkins> | I knew I had to do something with forming a request, and handling it somehow, but that was all I could get without a really deep reading. |
| 16:45 | <annevk> | not that specifications did that |
| 16:46 | <annevk> | but then specifications were typically not even using fetch to begin with |
| 16:47 | <annevk> | so if from a situation without fetch you're also trying to tackle CORS, well, yeah, it's gonna be icky |
| 16:47 | <annevk> | also, nobody ever gives written feedback on that |
| 16:48 | <TabAtkins> | Heh. |
| 16:49 | <TabAtkins> | For example, reading the CORS section, I can't actually find any mention of the fetch algorithm. |
| 16:50 | <annevk> | If you search in the CORS specification you'll find that the two relevant fetch instances are linked (and another one that's not so relevant is too) |
| 16:50 | <annevk> | Now, this is going to change |
| 16:50 | <TabAtkins> | Sure, but why should I know about that? I'm just a dude trying to write a spec, and someone told me to use CORS. I look in the section about Specification Advice, and I'm not enlightened. |
| 16:50 | <annevk> | http://html5.org/temp/fetch.html is my draft for Fetch, which encompasses both HTML fetch and CORS and will give a single entry point with ideally sensible defaults |
| 16:51 | <annevk> | TabAtkins: for starters, there's no such thing as "a dude trying to write a spec" :p |
| 16:51 | <TabAtkins> | That's me! |
| 16:52 | <annevk> | TabAtkins: it says quite clearly how to construct a cross-origin request though |
| 16:52 | <annevk> | TabAtkins: "For all cross-origin requests that APIs can make for which the resource sharing policy in this specification is supposed to apply, the CORS API specification needs to reference the cross-origin request algorithm and set the following input variables appropriately: ..." |
| 16:53 | <annevk> | Now this is fairly low-level, but then CORS is fairly low-level. Fetch will make it slightly higher-level. |
| 16:53 | <TabAtkins> | I think you and I have different definitions of the word "clearly". |
| 16:53 | <TabAtkins> | ^_^ |
| 16:53 | <TabAtkins> | Personally, I'd love something that just started like "To make a request using CORS, ..." |
| 16:53 | <annevk> | That's what it says :-) |
| 16:53 | <TabAtkins> | Instructions for me, not descriptions of the things I have to produce. |
| 16:54 | <annevk> | It's an instruction to reference that algorithm, set the variables correctly, and handle whatever it returns as appropriate... |
| 16:55 | <annevk> | In any event, ideally it's obsolete within a month |
| 16:58 | <annevk> | TabAtkins: while we're at it, is the box model defined yet? Can I reference some concept defined in CSS for what fullscreen calls "top layer"? |
| 16:58 | <TabAtkins> | Hey, I don't live in a glass house. |
| 17:00 | <SimonSapin> | annevk: AFAIK "top layer" is a new concept that we have yet to define |
| 17:00 | <SimonSapin> | it’s kind of a super-z-index |
| 17:00 | <annevk> | SimonSapin: tell me more ;) |
| 17:01 | <SimonSapin> | Fullscreen needs us to define something |
| 17:01 | <annevk> | SimonSapin: I wrote Fullscreen ;) |
| 17:01 | <SimonSapin> | we discussed it at the last f2f |
| 17:02 | <SimonSapin> | annevk: http://lists.w3.org/Archives/Public/www-style/2013Feb/0392.html "Top layer positioning" |
| 17:02 | <annevk> | (well, the W3C copy, roc did a bunch of it iirc and Hixie gave input on the top layer bit as it's used by dialog too) |
| 17:02 | <annevk> | did I just say W3C copy? |
| 17:02 | <annevk> | wow, I meant spec copy |
| 17:02 | <SimonSapin> | ? |
| 17:03 | <SimonSapin> | does spec copy means whatwg? |
| 17:03 | <annevk> | SimonSapin: http://fullscreen.spec.whatwg.org/#new-stacking-layer |
| 17:04 | <annevk> | surprised that reference was not part of the discussion |
| 17:06 | <SimonSapin> | annevk: are :fullscreen and ::backdrop implemented? |
| 17:06 | <annevk> | SimonSapin: dunno |
| 17:07 | <annevk> | been working on low-level stuff mostly apart from fixing minor bugs there |
| 17:09 | <SimonSapin> | so, fullscreen is two things: 1. hide the browser chrome and extend the viewport to be as big as possible, preferably the whole screen 2. Move an element to the top layer and maybe set its width/height to 100% |
| 17:10 | <SimonSapin> | annevk: 2. is kind of magic, we discussed having it in CSS even for non-fullscreen stuff |
| 17:10 | <SimonSapin> | and make it not magic |
| 17:11 | <annevk> | it's needed for <dialog> too |
| 17:11 | <annevk> | it's not really magic |
| 17:11 | <annevk> | it's just a new stacking layer |
| 17:11 | <annevk> | the only problem is that it's monkey patching |
| 17:11 | <TabAtkins> | That's magic. :/ |
| 17:11 | <dglazkov> | good morning, Whatwg! |
| 17:12 | <TabAtkins> | The big problem is that <dialog> doesn't just need a new layer - it needs positioning too. And you don't want to prevent the under-layer from scrolling. |
| 17:12 | <SimonSapin> | annevk: yes, basically we want something in csswg space that describes this new stacking layer, and maybe a property/value to put stuff there |
| 17:12 | <TabAtkins> | For example, most popup-style tips want to be on the top layer, but they just want to scroll with the page normally. |
| 17:16 | <annevk> | So it's been almost a year now since this text has been out there. I made the request for something better around the same time I drafted this and around the time the CSS WG gave feedback. I might have said something in November 2011 too during one of my last CSS WG F2F meetings. |
| 17:17 | <annevk> | I don't feel this is really up to me. Maybe we can change this a year after the fact, maybe we can't. I guess we'll see, but thus far I don't see a replacement. |
| 17:17 | <TabAtkins> | Yup, and it's one of many important things I've been working on. |
| 17:21 | <SimonSapin> | annevk: change what after the fact? |
| 17:26 | <annevk> | SimonSapin: details |
| 17:36 | <TabAtkins> | Adding a top-layer to fixpos is easy enough, because fixpos doesn't do anything fancy in the first place. |
| 17:37 | <TabAtkins> | <dialog>'s complexity is enough to tip it into the "new feature" bucket, though - special-casing it wouldn't make it any simpler, and would shut out a bunch of nearly identical things. |
| 18:07 | <jamesr> | anyone around involved with indieui? |
| 18:07 | <jamesr> | it's serving from https and trying to load respec from http |
| 18:07 | <Ms2ger> | Dunno, tantek? |
| 18:08 | <jamesr> | tantek, ^^ |
| 18:08 | <jamesr> | it's just not the same without respec's familiar FOUC |
| 18:09 | <TabAtkins> | On that subject, I just added command-line options to my preprocessor. I feel like a big boy now. |
| 18:27 | <jamesr> | https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html#UIValueChangeRequestEvent |
| 18:27 | <jamesr> | is that an enum? |
| 18:30 | <Ms2ger> | jamesr, no |
| 18:30 | <jamesr> | what is it? |
| 18:30 | <Ms2ger> | Stupid |
| 18:30 | <jamesr> | or rather, is it *trying* to be an enum? |
| 18:30 | <Ms2ger> | No |
| 18:30 | <TabAtkins> | Argh, someone needs to review that spec. And someone shouldn't be me. |
| 18:30 | <annevk> | jamesr: fwiw, see whatwg list for why tasks are important |
| 18:30 | <TabAtkins> | It's *trying* to do the stupid "hack an enum as a manual set of integers" thing. |
| 18:30 | <Ms2ger> | Note that it doesn't even allow you to see which of these ints apply |
| 18:31 | tantek | scrolls up |
| 18:32 | <tantek> | am not involved with indieui |
| 18:32 | <tantek> | the name is a bit of a misnomer too |
| 18:33 | <jamesr> | maybe if respec would load i could see contact info |
| 18:33 | <tantek> | it's more about "hardware independent events" |
| 18:33 | <tantek> | not really what people think of with the term "indie" |
| 18:33 | <tantek> | this is my kind of indie: #indiewebcamp |
| 18:34 | <Ms2ger> | James Craig, Apple Inc. |
| 18:34 | <Ms2ger> | Michael Cooper, W3C |
| 18:34 | <Ms2ger> | jamesr, ^ |
| 18:34 | <tantek> | jamesr - googling for IndieUI gives: http://www.w3.org/WAI/IndieUI/ |
| 18:34 | <Ms2ger> | And apparently sangwhan and Lachy are involved |
| 18:34 | <Ms2ger> | And hober |
| 18:35 | <tantek> | email addresses here: http://www.w3.org/WAI/IndieUI/#contacts |
| 18:35 | <tantek> | I've chatted a bit with James Craig and hober about it |
| 18:35 | <tantek> | conceptually it seems worth exploring - though from my own previous experience with attempting such events I know it's a nontrivial problem so I'm not holding my breath |
| 18:35 | <tantek> | or rather, attempting such abstractions |
| 18:38 | <annevk> | we haven't even specced the actual events correctly |
| 18:38 | <annevk> | building abstractions on top of a turd is unlikely to yield good results |
| 18:41 | <tantek> | annevk - that seems like an accurate assessment of the situation. |
| 18:43 | <annevk> | I told some people, but people love building turds, so they don't listen. Or maybe it's more that people love building sand castles, which are kinda the same, and wash away just as easily. |
| 18:44 | <Ms2ger> | But they look nicer |
| 18:45 | <annevk> | Also, the message "build this instead" doesn't work. If I think they should do that instead, I should do that instead, and then yell at them once I'm done. But fixing user interaction events seems even less rewarding than fixing fetching. |
| 18:49 | <marcosc> | arg, I wonder if Respec supports given a spec a sub-title. |
| 19:09 | <hober> | jamesr: i'll ping jcraig re: his respec bug |
| 19:12 | <jamesr> | hober, thanks |
| 19:12 | <jamesr> | hober, while you're at it, want to ask him about those ghetto enums? |
| 19:15 | <hober> | jamesr: sure. :) |
| 19:16 | <esprehn_> | jamesr: that spec needs help |
| 19:16 | <Ms2ger> | Or a grave |
| 19:17 | <jamesr> | i'd be happy for just loading up the ED with proper styling |
| 19:51 | <ojan> | Hixie: this thing of not being able to round-trip the DOM through serialization really sucks for editing code. Any ideas on a solution or are we just doomed? |
| 19:52 | <ojan> | Hixie: a thought i had is that you could somehow mark a part of your HTML/DOM as using E4H parsing. |
| 19:52 | <ojan> | It's not a great solution because you then need to use E4H parsing wherever you display the content. |
| 19:53 | <ojan> | but, then we could also make it so that whenever you copy, we put a text/e4h or something on the clipboard in addition to the text/html |
| 19:53 | <ojan> | so that round-tripping through copy-paste could at least be made to work well |
| 20:23 | <Hixie> | annevk: i don't understand what's not clear. you call fetch. fetch queues up some tasks for you, including a final task. so you just say "when the task is queued" or "when the final task is queued" or whatever. |
| 20:24 | <annevk> | Hixie: okay, maybe that kind of implicit association works |
| 20:25 | <annevk> | Hixie: feel free to ignore that part of the email |
| 20:25 | <Hixie> | ojan: there are things in the source the DOM can't represent and vice versa; i don't think anyone has made any attempt at fixing that. it's not clear what the use case is. What are you finding hard in editing code? |
| 20:26 | <Hixie> | annevk: heh k |
| 20:26 | <Hixie> | annevk: i mean, it's always possible that i'm wrong, but then the html spec has a number of problems, since i use that style througout... :-) |
| 20:26 | <Hixie> | nobody seems to have had troubles implementing it so far |
| 20:27 | <Hixie> | anyone around who's a whatwg blog adminy type person? i have someone who has sent me a link to a translation of some blog entry that they'd like linked to |
| 20:27 | <annevk> | Hixie: it's just that if you look at it in the abstract there's a whole number of places that can queue tasks on that networking queue, so how do you know it's yours is kinda undefined / implicit |
| 20:27 | <annevk> | Hixie: sounds like SEO scam |
| 20:29 | <Hixie> | could be seo spam, but i'm fine with it being linked to with rel=nofollow :-) |
| 20:30 | annevk | updates blog |
| 20:30 | <Hixie> | annevk: how do you envisage making it explicit? |
| 20:30 | <annevk> | Hixie: I've got admin btw |
| 20:30 | <Hixie> | the html spec uses terminology like "Fetching an external script must delay the load event of the element's document until the task that is queued by the networking task source once the resource has been fetched (defined above) has been run" |
| 20:30 | <Hixie> | which doesn't seem ambiguous at all |
| 20:31 | <Hixie> | hm yeah, actually, this page does seem like seo spam |
| 20:31 | <Hixie> | nevermind |
| 20:32 | <annevk> | I think maybe I just misunderstood that concept entirely... E.g. XHR ended up (in part based on comments too iirc) with a task source per object. |
| 20:32 | <annevk> | So you could easily clear all tasks for one instance. |
| 20:32 | <Hixie> | that means that each XHR's events are ordered with respect to the other events for that XHR object, but not with respect to any other events |
| 20:33 | <Hixie> | which sounds legit |
| 20:33 | <Hixie> | task sources are just a way to make sure things that should be ordered relative to each other, are ordered relative to each other |
| 20:34 | <annevk> | But should e.g. img loads be ordered relative to each other or should each img have its own network task source? |
| 20:35 | <Hixie> | well it's kind of academic since the order they're put in the task source is dependent on how the UA deals with network traffic |
| 20:38 | <ojan> | Hixie: when you copy and then paste in a contentEditable region, we round-trip through an HTML string |
| 20:38 | <ojan> | Hixie: so, if you create a DOM that can't be represented by HTML, then your copy-paste doesn't actually end up pasting in the same content |
| 20:39 | <ojan> | Hixie: similarly, when you are done with your rich text editing and you serialize the content for showing in a different context (e.g. you send your rich-text email) |
| 20:39 | <ojan> | Hixie: the sent result would be different from the result the user saw |
| 20:45 | <TabAtkins> | Quick, somebody help me come up with names for a property that suppresses box generation (the thing that display:none does). |
| 20:45 | <TabAtkins> | Current candidates are "box" and "show". We hate these. |
| 20:46 | <annevk> | so what's wrong with display:none? |
| 20:46 | <TabAtkins> | The current values for the property will be "normal", "none", "contents", and "hide"/"collapsed"/something. These are up for debate. |
| 20:46 | <TabAtkins> | annevk: Whole lots. |
| 20:47 | <TabAtkins> | annevk: Ask jQuery, for one - call .hide(), then .show(). What's its display? |
| 20:47 | <TabAtkins> | What if it started as display:none, and then they just call .show()? |
| 20:47 | <TabAtkins> | Additionally, the hidden attribute. |
| 20:47 | <TabAtkins> | Authors need to be able to tweak it (use transitions, etc), so you can't put its effect in the UA !important level. |
| 20:48 | <TabAtkins> | But it's way too easy to accidentally override if put in the UA or pres-hint level. |
| 20:48 | <yroc> | Hixie: regarding this point: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-February/038973.html, is the fact that nested articles could be something other than comments not a compelling enough reason to add a <comment> element? (e.g., Silvia would have to show that this is a significant problem?) |
| 20:48 | <annevk> | TabAtkins: box-tree? |
| 20:48 | <TabAtkins> | A completely separate property wouldn't be accidentally overriden by someone setting "display: flex;". |
| 20:50 | <Hixie> | ojan: ok but what kind of stuff can't you represent that is user-visible? do you mean like form controls' current values and canvas element's images? or something else? |
| 20:51 | <Hixie> | yroc: how could nested <article>s be anything other than comments? |
| 20:51 | <ojan> | Hixie: the bug in question involved nested <p>s |
| 20:52 | <Hixie> | ah, well, if the DOM is bogus in the first place, yeah... |
| 20:52 | <yroc> | Hixie: personally, I don't know, but Silvia seems to think it's possible (without specifying an example) |
| 20:52 | <ojan> | i mean...you can create the DOM...so... |
| 20:52 | <Hixie> | yroc: the spec says "When article elements are nested, the inner article elements represent articles that are in principle related to the contents of the outer article." |
| 20:52 | <ojan> | call it bogus of you like...but in practice, the user experience is busted |
| 20:52 | <Hixie> | yroc: i haven't yet dealt with that thread though |
| 20:52 | <Hixie> | ojan: sure |
| 20:53 | <Hixie> | ojan: i just meant it's not a valid document in the first place |
| 20:53 | <Hixie> | ojan: and we make things invalid when they're going to break |
| 20:53 | <Hixie> | ojan: as a warning to people that things will break |
| 20:53 | <Hixie> | ojan: but sure, some people will do it anyway... |
| 20:54 | <Hixie> | ojan: hmm |
| 20:54 | <ojan> | i mean...i guess it's not a tragedy for us to break on invalid content. |
| 20:54 | <Hixie> | ojan: how did they end up with nested <p>s in the case in question? explicit dom manipulation? |
| 20:54 | <ojan> | in this case, funny enough it was WebKit creating the nested paragraphs :( |
| 20:55 | <Hixie> | d'oh |
| 20:55 | <ojan> | so, we just fixed that |
| 20:55 | <esprehn_> | editing code! |
| 20:55 | <ojan> | but, explicit DOM manipulation or E4H was what i had in mind |
| 20:55 | <Hixie> | if it's just copy-and-paste, i guess one way would be for browsers to have a copy-and-paste format |
| 20:55 | <Hixie> | that describes the DOM to be copied somehow |
| 20:55 | <ojan> | esprehn_: webkit's editing code is one of those bits of the codebase that falls in that rare category of deserving a full-rewrite IMO. |
| 20:56 | <Hixie> | is anyone actually interested in e4h? when i wrote the strawman spec, nobody seemed to want to implement it |
| 20:56 | <ojan> | Hixie: yeah, that's what i had in mind with the suggestion to put e4h on the clipboard |
| 20:56 | <ojan> | Hixie: I'm interested in solving that problem |
| 20:56 | <ojan> | E4H sounds like a fine solution to me. |
| 20:57 | <yroc> | Hixie: How about, a nested article could be a chapter of a book *if* the chapter is syndicatable. |
| 20:57 | <ojan> | just need someone with the time and skills to implement it |
| 20:57 | <esprehn_> | ojan: perhaps even in JS |
| 20:57 | <ojan> | anyways... the problem is that it's not just copy-paste |
| 20:57 | <Hixie> | yroc: why would it be nested? what's the outer <article>? |
| 20:58 | <ojan> | Hixie: think of the case where your sending an email or publishing a blog post |
| 20:58 | <ojan> | Hixie: then the server needs a serialized form to serve up |
| 20:58 | <yroc> | Hixie: The outer article is the whole book. The inner article is a chapter (again, if the chapter is standalone). There are books like that. |
| 20:59 | <ojan> | esprehn_: i could imagine rewriting it in JS if we expose some extra hooks |
| 21:00 | <yroc> | Hixie: I'm not talking about most fiction novels, where one chapter doesn't really make sense on its own, and isn't intended to be read by itself. |
| 21:00 | <ojan> | and eventually, we could probably standardize those hooks and expose them to web content |
| 21:00 | <ojan> | it'd be kind of awesome if contentEditable just became a builtin JS library that all browsers shared |
| 21:01 | <Hixie> | ojan: well i wouldn't want people to serve up nested <p>s |
| 21:01 | <Hixie> | ojan: but yeah |
| 21:02 | <esprehn_> | nested divs and spans though... |
| 21:02 | <Hixie> | ojan: i'm skeptical about exposing a third format for the DOM (not counting JS), it's bad enough that we have 2 |
| 21:02 | <Hixie> | ojan: but yeah |
| 21:02 | <Hixie> | ojan: dunno what to tell you exactly :-) |
| 21:02 | <Hixie> | yroc: i don't see why you'd wrap the book in an <article> |
| 21:02 | <Hixie> | yroc: it's just the page |
| 21:03 | <Hixie> | yroc: unless we're talking about a page with multiple books each of which has multiple sub-books? this seems rather hypothetical |
| 21:03 | <Hixie> | yroc: anyway, feel free to continue commenting on that thread. like i said, i haven't read it or dealt with it yet. |
| 21:03 | <ojan> | Hixie: yeah...it's gross. but...if we were to implement E4H, then we essentially have that 3rd format already, no? |
| 21:03 | <Hixie> | gotta go to lunch |
| 21:03 | <esprehn_> | where is the E4H spec? |
| 21:04 | <esprehn_> | /strawman |
| 21:04 | <ojan> | http://www.hixie.ch/specs/e4h/strawman |
| 21:04 | <ojan> | esprehn_: i think it's great and we should implement it. |
| 21:05 | <jgraham> | Hixie: Since 100% of the attempts to implemnt the navigation part of the spec have failed, it isn't really clear to me that you can infer anything about the success of the design from the lack of complaints so far |
| 21:05 | <ojan> | I used to be a fan of http://wiki.ecmascript.org/doku.php?id=harmony:quasis for this |
| 21:05 | <annevk> | quasis doesn't do the runtime thing |
| 21:06 | <ojan> | but abarth convinced me that quasis are a much scarier solution than e4h from a security perspective because you have to roundtrip through strings |
| 21:06 | <ojan> | runtime thing? |
| 21:06 | <annevk> | parse time, sorry |
| 21:06 | <annevk> | nobody likes E4H though |
| 21:06 | <ojan> | i like E4H! |
| 21:07 | <ojan> | who doesn't like it? |
| 21:07 | jgraham | uses logic to deduce that ojan is nobody |
| 21:07 | <annevk> | ojan: http://lists.w3.org/Archives/Public/public-script-coord/2011OctDec/thread.html#msg65 |
| 21:08 | <esprehn_> | ojan: we should probably add the ? syntax for mdv |
| 21:08 | <ojan> | It's so insane that $('<div>my random' + randomvar + ' html</div>') is the state of the art for generating DOMs |
| 21:08 | <esprehn_> | ojan: checked?={checked} aklein |
| 21:08 | <annevk> | ojan: http://lists.w3.org/Archives/Public/public-script-coord/2011OctDec/thread.html#msg33 |
| 21:08 | <ojan> | rafaelw___: ^^^^ |
| 21:09 | <annevk> | ojan: http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/thread.html#msg1067 (latest attempt, this time by Hixie with aforementioned strawman) |
| 21:11 | <jgraham> | annevk: That is like 3 people and you don;t really follow up with advantages compared to quasis, so I don't think it says much one way or another |
| 21:11 | <ojan> | slightlyoff-- for speaking for the Chrome team on that thread |
| 21:12 | <annevk> | jgraham: if you don't think it's an uphill battle, go for it! :-) |
| 21:12 | <jgraham> | I think everything involving TC39 is an uphill battle |
| 21:13 | <jgraham> | But I am also the wrong person to advocate E4H because I don't really know if it's a good design |
| 21:15 | <annevk> | I'm not sure anyone involved in platform design really knows what they're doing. |
| 21:19 | <ojan> | annevk: hah! that's probably true...but someone has to do it. |
| 21:19 | <ojan> | annevk: or we're stuck with jquery forever |
| 21:25 | <annevk> | ojan: so if quasis are not going to get through security review we should give this another go maybe |
| 21:26 | <annevk> | ojan: having node-primitives in JavaScript is still a good idea I think |
| 21:28 | <jpwhiting> | hsivonen: good evening |
| 21:29 | <jpwhiting> | is there a way I can make my local validator.nu only use my own schema? |
| 21:29 | <jpwhiting> | it's already a choice in the presets, but I want to make it the default also somehow |
| 21:30 | jpwhiting | tries removing the other presets for now |
| 21:33 | <jgraham> | jpwhiting: I doubt hsivonen will answer now |
| 21:33 | <jpwhiting> | yeah, pretty late there, true |
| 21:34 | <jgraham> | Try again in 9-10 hours, perhaps? |
| 21:34 | <jpwhiting> | yep, will do |
| 21:34 | <jpwhiting> | or wait for MikeSmith to come around |
| 21:36 | <jgraham> | MikeSmith never sleeps |
| 21:36 | <jgraham> | As far as I can tell |
| 21:36 | <jgraham> | I think he might be bionic |
| 21:36 | <nimbu> | much like CityBank™ |
| 21:42 | <ojan> | abarth: you around? |
| 21:42 | <abarth> | ojan: hi |
| 21:43 | <abarth> | ojan: what can I do for you? |
| 21:52 | <ojan> | abarth: do you remember this quasis vs E4H discussion? |
| 21:53 | <abarth> | yes |
| 21:53 | <ojan> | abarth: do you still believe quasis have security issues? |
| 21:54 | <abarth> | ojan: I don't remember all the details anymore |
| 21:54 | <abarth> | ojan: I remember that some of the choices were bad and some were good |
| 21:54 | <ojan> | I want us to solve this issue of being able to create DOM in a concise way...i don't feel terribly strongly about E4H vs quasis...but i want one of them to happen and right now i think the feature is in limbo because of disagreement about which is better |
| 21:54 | <ojan> | abarth: what i remember is that you disliked quasis because they roundtrip through strings |
| 21:55 | <abarth> | yes, you don't want to send any strings that contain untrusted data through the HTML parser |
| 21:55 | <abarth> | that means you've lost from a security PoV |
| 21:55 | <ojan> | abarth: well...these wouldn't go through the HTML parser |
| 21:55 | <abarth> | what happens to the strings? |
| 21:55 | <jgraham> | Hmm, I thought that was the point? |
| 21:55 | <ojan> | oh...well...the E4H version doesn't |
| 21:56 | <jgraham> | Right |
| 21:56 | <ojan> | in theory, quasis could use the same sort of parsing the E4H does |
| 21:56 | <jgraham> | But html`some string` is syntax sugar for creating a document fragment and setting its innerHTML to some string, with substitutions based on some special syntax, right? |
| 21:56 | <ojan> | jgraham: yeah, that's the current proposal |
| 21:57 | <ojan> | abarth: what's special about the HTML parser vs. an XML parser? |
| 21:58 | <jgraham> | (I think quasis are a bit ugly, but I don't understand the security argument. Or at least I don't see how it is worse than innerHTML which is the defacto solution for this problem today) |
| 21:58 | <ojan> | i'd like to restart this discussion on public-script-coord so that we can actually make forward progress here...but i feel like i need to understand the security side of it better to make an argument one way or the other |
| 21:59 | <ojan> | jgraham: it's definitely not worse than innerHTML, but if we're designing a new API, we can do better. |
| 22:00 | <abarth> | jgraham: innerHTML is a security disaster |
| 22:01 | <ojan> | abarth: alternately, if i start a discussion on public-script-coord, would you be willing to chime in with the security argument? |
| 22:01 | <ojan> | abarth: that way you don't have to convince me and then later convince everyone else :) |
| 22:03 | <jgraham> | OK, well if the argument is that we should do better with new APIs and try to educate people that current best-practice is a security disaster, I can live with that |
| 22:04 | <ojan> | jgraham: whatever new API we come up with ideally will be easier to use and more secure. in either case, people will have to learn a new thing to use. |
| 22:07 | <abarth> | ojan: sure |
| 22:10 | <ojan> | abarth++ thanks |
| 23:23 | <Hixie> | ojan: e4h is just javascript |
| 23:24 | <Hixie> | ojan: i dunno that i'd want to use JS as a data exchange format |
| 23:24 | <Hixie> | ojan: and i'm 100% sure it can't roundtrip everything in the DOM (e.g. you can't roundtrip the current <canvas> state) |
| 23:24 | <Hixie> | (using e4h) |
| 23:26 | <Hixie> | ojan: (re e4h, if there's anything i can do to help you get it implemented, let me know) |
| 23:35 | <ojan> | Hixie: the thing to do is to get other browser vendors vaguely positive about it. if we could get Mozilla to voice support for it, that'd be enough for me to feel comfortable shipping it in Chrome... |
| 23:35 | <ojan> | Hixie: i plan to start another thread on public-script-coord |
| 23:36 | <ojan> | Hixie: please chime in if i leaving anything important out. |
| 23:39 | <Hixie> | roger |
| 23:39 | <Hixie> | you got the link to the spec? |
| 23:39 | <Hixie> | ("spec") |
| 23:39 | <JonathanNeal> | has anyone here written up (or knows of) a good article on navigation markup, including sub-navigation, recommended class names, aria, etc? |
| 23:39 | <Hixie> | JonathanNeal: what do you mean by "navigation markup"? |
| 23:40 | <JonathanNeal> | Just, someone demonstrating best practices, including their own opinion on what roles to throw in even. |
| 23:40 | <JonathanNeal> | For instance, there are times when you can use classnames that are sympathetic with aria roles. |
| 23:41 | <JonathanNeal> | Or, you could look at a large group of websites, and arrive at a general consensus (or a few consensuses) of what markup people prefer. |
| 23:43 | <ronaldmansveld> | I don't know about an article, but my gut tells me that currently a nav with an ul, where li's contain the anchors is considered the way to go. (Just a gut-feeling, no proof for this) |
| 23:43 | <Hixie> | JonathanNeal: that seems to be what you mean by "article", not what you mean by "navigation markup" :-) |
| 23:44 | <Hixie> | JonathanNeal: do you mean like the links on the side of a page that get you to the home page or whatever? |
| 23:45 | <JonathanNeal> | the html markup of a navigation list, where some items may themselves contain sub-navigation lists. |
| 23:46 | <Hixie> | i would recommend using <a href="...url...">...label...</a> for the links, and either <p> or <ul><li> for the markup around it |
| 23:46 | <Hixie> | no need for any other attributes |
| 23:47 | <ronaldmansveld> | BTW Hixie: may I compliment you on the readability of the specs you produce |
| 23:47 | <Hixie> | ronaldmansveld: thank you sir |
| 23:47 | <Hixie> | though i fear if you find my specs readable you may have just not read much of them :-) |
| 23:48 | <ronaldmansveld> | I'm currently plowing through the ECMAScript 5 spec, but in comparison that feels like being forcefed a box of dry biscuits, and then be told to whistle :P |
| 23:48 | <JonathanNeal> | Hixie: something deeper, that covers the situation where an item in the navigation list is also the current page. |
| 23:49 | <Hixie> | ronaldmansveld: ah well i will definitely agree that my specs tend to be more entertaining :-) |
| 23:49 | <Hixie> | especially if you read the examples :-) |
| 23:49 | <ronaldmansveld> | Hixie: absolutely :) |
| 23:50 | <Hixie> | JonathanNeal: i'd either just link to the current page and not worry about it, or use <a>...label...</a> and style using :not([href]) |
| 23:50 | <Hixie> | ronaldmansveld: i'm glad to hear somebody appreciates it. i actually just do it to alleviate my own boredom. :-) |
| 23:51 | <ronaldmansveld> | JonathanNeal: I'm pretty sure links to the current page in most case get a class="active". Maybe in some cases the anchor gets replaced by a span as well |
| 23:52 | <Hixie> | replacing the <a> by a <span> is an equally valid solution, though maybe more complicated than necessary |
| 23:52 | <JonathanNeal> | Hixie, ronaldmansveld, I wasn't sure if either "current" or "active" had more meaning, or what to call it if a link is for a parent page which contains the current page. |
| 23:52 | <Hixie> | using a class is almost certainly more complicated than necessary |
| 23:53 | <Hixie> | JonathanNeal: well, technically, class names are opaque. You could use class=green or class='***' and it'd be no less reasonable, per the spec. |
| 23:53 | <Hixie> | JonathanNeal: for links to parent pages, i would recommend rel="up", for grandparent pages, rel="up up", etc |
| 23:53 | <ronaldmansveld> | Hixie: I haven't tried writing specs myself (unless you count functional designs as specs), but I'm sure it's a tough job, where we (as a community) don't show enough appreciation for |
| 23:53 | <JonathanNeal> | Oh, I thought rel="up" and such were dropped. |
| 23:54 | <ronaldmansveld> | JonathanNeal: classes don't contain meaning, apart from the meaning for the author of the code ;) |
| 23:55 | <Hixie> | JonathanNeal: they were dropped by the w3c, but i expect i'll bring them back when i get around to shaking up how the rel values are handled in the spec |
| 23:55 | <JonathanNeal> | ronaldmansveld: i understand, which is why i mentioned using classnames that are sympathetic with other known standards. |
| 23:55 | <ronaldmansveld> | Hixie: if you can decide (usually serverside) if a link should get a class 'active', it's equally easy to decide to use a span instead |
| 23:55 | <JonathanNeal> | For example, ARIA or Microformats. |
| 23:55 | <Hixie> | JonathanNeal: in the meantime you could always just register them in the wiki |
| 23:55 | <JonathanNeal> | ronaldmansveld: is that how you would do it in a <template>? |
| 23:56 | <Hixie> | ronaldmansveld: depends on your templating language, but sure |
| 23:56 | <ronaldmansveld> | JonathanNeal: As far as I know, no good spec will use classnames to base actions upon (at least in my opinion) (and yes, CSS is the only exception to the rule :P) |
| 23:57 | <ronaldmansveld> | JonathanNeal: if you refer to the html <template>: I wouldn't know, I haven't had time to read up on that |