| 00:00 | <annevk> | This exchange right here between David and Patrick: https://twitter.com/dstorey/status/290967431902543873 |
| 00:00 | <annevk> | #comedygold |
| 00:02 | <Hixie> | should we spec navigator.product? |
| 00:03 | <Hixie> | spec currently has it commented out with: <!-- product: Mozilla and Safari only; always returns "Gecko" --> |
| 00:04 | <annevk> | I'm surprised IE found out before Opera |
| 00:04 | <hober> | didn't opera ship navigator.product=="Gecko" first, before even gecko? |
| 00:04 | <annevk> | hober: sounds plausible |
| 00:06 | <gsnedders> | It was removed in 2.x.277 |
| 00:07 | <gsnedders> | But is in browser.js for a number of sites. |
| 00:08 | <annevk> | Very encouraging that Travis files such a bug though. It's awesome to hear about such issues. Especially as not having it probably increases the barrier to entry. |
| 00:11 | <gsnedders> | I wonder if navigator.productSub is needed too. |
| 00:11 | <MikeSmith> | that David and Patrick thread is good |
| 00:17 | <MikeSmith> | if any production sites were doing anything with productSub I'd wonder why |
| 00:18 | <MikeSmith> | but then I guess the same could be said about navigator.product |
| 00:19 | <gsnedders> | FCKEditor used to, at least |
| 00:19 | <gsnedders> | Like, navigator.product == "Gecko" && navigator.productSub > 20031123 or something like that |
| 00:27 | <MikeSmith> | ah |
| 00:28 | <MikeSmith> | greater than |
| 00:28 | <MikeSmith> | the whacky whacky web |
| 00:29 | <MikeSmith> | or 古怪古怪的网 as they call it in China |
| 00:31 | <abarth> | Hixie: sure |
| 00:31 | <Hixie> | every now and then i get an e-mail that i cannot make head or tails of |
| 00:31 | <Hixie> | and then i notice it was sent to a mailing list that isn't the whatwg list |
| 00:31 | <Hixie> | and i breathe a sigh of relief as i move on |
| 00:56 | <MikeSmith> | Hixie: you been reading the www-tag list too much |
| 00:57 | <MikeSmith> | either that or es-discuss |
| 00:58 | <Hixie> | i'm on es-discuss, but heavily filtered |
| 00:58 | <Hixie> | anything specific? |
| 01:00 | <MikeSmith> | no I was just being obnoxious. I imagine the es-discuss threads are clear if you take the time read up on the context |
| 01:00 | <MikeSmith> | though I can also imagine that would require a lot of time |
| 01:00 | <Hixie> | oh, sorry, didn't realise you were being a smartass regarding my last comment :-P |
| 01:01 | <MikeSmith> | I know, you're stunned because I'm usually so deadly serious |
| 01:02 | <Hixie> | :-P |
| 01:02 | <MikeSmith> | this is my new IRC persona for 2013 |
| 05:11 | <kamathln> | hi . is there a screen orientation change |
| 05:11 | <kamathln> | doh |
| 05:11 | <zewt> | presumably, if you reorient your screen |
| 05:12 | <kamathln> | hi . is there a 'screen orientation' change event like 'device orientation' change event? |
| 05:12 | <kamathln> | zewt ^^ |
| 05:13 | <kamathln> | if there is, it would be usefull in cases when we enable screen 'autorotation' like in Android |
| 05:15 | <MikeSmith> | kamathln: there's a draft spec for it |
| 05:16 | <kamathln> | MikeSmith: Cool! Thanks. |
| 05:16 | <MikeSmith> | lemme get your the URL |
| 05:16 | <MikeSmith> | not sure where it's implemented |
| 05:17 | <MikeSmith> | I think in the case of WebKit there is somebody from Samsung working on a patch but there is not agreement in the WebKit community about landing the patch |
| 05:18 | <zewt> | multiple types of orientation doesn't exactly sound promising |
| 05:19 | <MikeSmith> | well it's just the same word but two very different things |
| 05:19 | <MikeSmith> | kamathln: https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html |
| 05:20 | <MikeSmith> | the screen one could just as well be called screemode or somethig |
| 05:21 | <MikeSmith> | kamathln: for the related WebKit thread, see http://lists.webkit.org/pipermail/webkit-dev/2012-November/thread.html#22951 |
| 05:21 | <kamathln_> | it worked well, till I rotated it throughly and the screen re-oriented |
| 05:22 | <kamathln_> | thats when I realized the need |
| 05:22 | <MikeSmith> | I think it may already be Firefox |
| 05:22 | <MikeSmith> | volkmar would know |
| 05:22 | <kamathln_> | MikeSmith: Thats nice! I am trying everythign in Firefox. Personally I am a fan of Firefox and trying all these stuff there. |
| 05:23 | <kamathln_> | MikeSmith: thanks for the linkies |
| 05:23 | <MikeSmith> | Android port of Firefox is pretty nice |
| 05:23 | <MikeSmith> | kamathln_: yeah cheers |
| 06:25 | <MikeSmith> | grr I guess I need to finally upgrade to Lion. Can't even build mac port of WebKit to check layout test failures |
| 06:50 | <othermaciej> | MikeSmith: Lion? Not all the way to Mountain Lion? |
| 06:51 | <othermaciej> | MikeSmith: my understanding is that SL --> Lion is the big hardware support discontinuity |
| 06:51 | <othermaciej> | MikeSmith: but yeah, we don't really support SL any more |
| 06:56 | <MikeSmith> | yeah whatever the latest OS is |
| 07:19 | <hsivonen> | Lion supports my laptop but Mountain Lion does not. So I installed Ubuntu. |
| 07:20 | <hsivonen> | It annoys me that Apple doesn’t communicate OS support levels properly. |
| 07:20 | <hsivonen> | For example, Snow Leopard got the Java plug-in blacklisting, but it’s not clear if it otherwise gets security patches |
| 07:21 | <hsivonen> | And people who run PPC software from Adobe or even Macromedia can’t upgrade from Snow Leopard just for the price of the OS upgrade |
| 10:19 | <kamathln> | volkmar: MikeSmith: in firefox window.screen.onmozorientation=function(){blah; useforsomethign(window.screen.mozOrientation); blah;} |
| 10:40 | <annevk> | https://twitter.com/koalie/status/291132240656752641 sounds like not much has changed. |
| 10:58 | <Somatt_wrk_> | any insights about having a direct relation between a label and it's checkbox input's state ? |
| 10:59 | <Somatt_wrk_> | I mean, it seems that such a link is desirable and should exist in the html sepcifications... |
| 11:01 | <volkmar> | kamathln: Screen Orientation API is implemented in Firefox |
| 11:01 | <volkmar> | kamathln: on Desktop, it will "guess" based on your screen width/height, on Mobile (Android and FxOS), it will use the sensors |
| 11:03 | <kamathln> | volkmar: you mean window.screen.onmozorientation right? |
| 11:07 | <annevk> | Looks like that is obsolete: https://developer.mozilla.org/en-US/docs/DOM/MozOrientation |
| 11:08 | <volkmar> | annevk: MozOrientation is sensor events |
| 11:08 | <volkmar> | kamathln: yes |
| 11:09 | <volkmar> | kamathln: actually, screen.mozOrientation |
| 11:09 | <volkmar> | kamathln: and screen.onmozorientationchange |
| 11:09 | <volkmar> | screen.mozLockOrientation() |
| 11:09 | <volkmar> | and screen.mozUnlockOrientation() |
| 11:46 | <kamathln_> | volkmar: thanks! Amazing to think Firefox had it all since 3.6 ! |
| 11:47 | <volkmar> | kamathln_: not 3.6, really |
| 11:47 | <kamathln_> | oh. It says so here - https://developer.mozilla.org/en-US/docs/DOM/MozOrientation |
| 11:48 | <volkmar> | kamathln_: this is a different feature |
| 11:48 | <kamathln_> | Introduced in Gecko 1.9.2 |
| 11:48 | <volkmar> | kamathln_: the page you are looking at is about sending sensor eveteents |
| 11:48 | <volkmar> | events, even |
| 11:48 | <kamathln_> | I know. Thats why I found it strange that DeviceOrientation actually obsoleted MozOrientation |
| 11:49 | <volkmar> | it is implemented since Firefox 14 |
| 11:49 | <volkmar> | https://bugzilla.mozilla.org/show_bug.cgi?id=740188 and https://bugzilla.mozilla.org/show_bug.cgi?id=720794 |
| 11:49 | <kamathln_> | oh wait. I got my confusion. Sorry |
| 14:32 | <Ms2ger> | darobin, do you want me to go through the removed files in your PR or can I just merge? |
| 14:32 | <darobin> | Ms2ger: maybe look at the file names to double-check? I'm pretty sure it's correct |
| 14:33 | <Ms2ger> | Alright, I'll look later, then :) |
| 14:34 | <darobin> | Ms2ger: cheers mate |
| 14:34 | <Ms2ger> | Thanks for your work, too! |
| 14:35 | <darobin> | I should go to boring meetings more often, it always makes me very productive |
| 14:35 | <Ms2ger> | Do you know about w3c-test.org, btw? |
| 14:35 | <darobin> | you mean syncing to it? |
| 14:35 | <Ms2ger> | Yeah |
| 14:35 | <darobin> | MikeSmith is on that |
| 14:35 | <Ms2ger> | Or, I dunno, if someone is going to blow it up, I'd like to know too :) |
| 14:36 | <darobin> | (or at least I think that's what I understood from talking to him yesterday) |
| 14:36 | <darobin> | hahaha |
| 14:42 | <manu-db> | hey darobin (and Hixie if he's around) - we got rid of using the term IRI in the JSON-LD spec and started using URL instead - people are flipping out - is there a solid set of argumentation for why the HTML5 spec uses URL instead of IRI that I can link to? |
| 14:43 | <manu-db> | The argumentation that we used was that web developers are less familiar with IRI than they are with URL - and other people have complained when we use IRI for that very reason. |
| 14:44 | <manu-db> | Since the feedback to go from IRI to URL was your idea (passes the buck) :) - I was wondering what settled this discussion for the HTML5 spec... |
| 14:46 | <manu-db> | this also affects the Web Payments work (same complaint over the use of IRI there... folks want us to use URL) |
| 14:48 | <hsivonen> | manu-db: is this for using the *R* things as network addresses or as opaque strings that can be compared for equality? |
| 14:49 | <manu-db> | hsivonen: both :) - we had been talking about IRIs throughout the spec - those IRIs can be used opaquely, but some of them are used to identify *R* things. |
| 14:50 | <hsivonen> | hmm. URL might indeed be a harder sell for the identifier use. after all, that’s where URI came from |
| 14:50 | <hsivonen> | manu-db: good luck |
| 14:50 | <manu-db> | hsivonen: I've heard enough complaints about IRI throughout the years that I wanted to just try aligning w/ the HTML5 spec for JSON-LD - but now the RDF folks are objecting to the change, so I'm trying to find if there is a solid set of argumentation for why using the term IRI has been abandoned? |
| 14:51 | <manu-db> | hsivonen: We're trying to use a single term throughout the spec and the biggest push-back we've had on IRI was that nobody (meaning most Web developers) knows what it is. |
| 14:51 | <hsivonen> | manu-db: well, everyone out there (where “out there” does not include IETF and the RDF community) talks about URLs when they mean the addresses |
| 14:51 | <Ms2ger> | I think I see the issue |
| 14:52 | <Ms2ger> | "the RDF folks" |
| 14:52 | <hsivonen> | manu-db: not sure the WHATWG has a canned argument for the id case |
| 14:52 | <hsivonen> | but maybe I just missed the memo and will learn something when reading the logs later |
| 14:53 | <manu-db> | Is this sane spec text? "Throughout this specification, the term URL means IRI as defined in [RFC3987]. The reason we use the term URL instead is because it is more familiar to Web developers." |
| 14:53 | <manu-db> | or does that conflate the issue more? |
| 14:54 | <hsivonen> | using them as ids in the first place is what conflates the issue :-( |
| 14:54 | manu-db | thinks that ship has sailed. :) |
| 14:55 | <hsivonen> | manu-db: have you thought through why you want to refer to RFC 3987 instead of annevk's spec? |
| 14:55 | <manu-db> | hsivonen: I'd be happy to refer to annevk's spec if it is more up to date and will be normative within a couple of months? |
| 14:55 | <manu-db> | link to annevk's IRI spec? |
| 14:55 | manu-db | goes off to google it. |
| 14:55 | <Ms2ger> | url.spec.whatwg.org |
| 14:55 | <hsivonen> | http://url.spec.whatwg.org/ |
| 14:56 | <hsivonen> | but I doubt that spec cares about RDF compat for id use |
| 14:56 | <hsivonen> | it cares about the addressing case |
| 14:56 | <zewt> | (drives me nuts when people say "URI" as if any user in the world actually distinguishes it from URL; the term needs to die) |
| 14:56 | <manu-db> | Thanks - I'll raise this during the JSON-LD telecon, which starts in 3 minutes - will check back here for any addition comments... thanks hsivonen, Ms2ger :) |
| 14:57 | <Ms2ger> | Enjoy |
| 14:57 | <hsivonen> | manu-db: you’re welcome |
| 14:57 | <darobin> | manu-db: sorry, was afk |
| 14:57 | <zewt> | hsivonen: fyi you're sending angle quotes as apostrophes, heh |
| 14:58 | <darobin> | I think that the core argument in this case is basically who JSON-LD is aimed at in the first place |
| 14:58 | <zewt> | looks weird in some fonts |
| 14:58 | <darobin> | if you want to do RDF for the RDF people, then stick to RDF terminology |
| 14:58 | <hsivonen> | are you sure it’s me sending and not you receiving? |
| 14:58 | <darobin> | but AFAIK, the RDF people have RDF |
| 14:58 | <zewt> | yep |
| 14:58 | hsivonen | checks what krijnh sees |
| 14:59 | <darobin> | if instead you want something that web hackers can understand and use for linked data, which is my understanding of what JSON-LD is for, then use terminology that they're familiar with |
| 14:59 | <hsivonen> | zewt: krijnh’s logs show my apostrophes as UTF-8 apostrophes |
| 14:59 | <darobin> | beyond that, so long as you define how they're processed in your context, the terminology doesn't matter IMHO |
| 14:59 | <darobin> | you could just call them Unicorns |
| 14:59 | manu-db | oooohs. |
| 15:00 | <hsivonen> | zewt: how did you diagnose that it’s me sending instead of you receiving? |
| 15:00 | manu-db | s/URL/Unicorn/g |
| 15:00 | <zewt> | hsivonen: i think they're U+2019's ("right single quotation mark") instead of just apostrophes |
| 15:00 | <darobin> | manu-db: yeah that would make for a fun spec |
| 15:00 | <zewt> | hsivonen: because i've seen it before and I know how the font i'm using renders each |
| 15:00 | <hsivonen> | ☃ <-- does that look like a snowman to you? |
| 15:00 | <zewt> | for a very generous definition of snowman :) |
| 15:00 | <zewt> | http://i.imgur.com/WpPbH.png |
| 15:00 | <darobin> | hsivonen: does drawing quality count? |
| 15:01 | <hsivonen> | zewt: I’m trying to send U+2019 |
| 15:01 | <hsivonen> | darobin: no |
| 15:01 | <zewt> | this is a JP fixed-width font that renders ' as single-width and unicode quotes as double-width, which makes the difference easy to spot (other fonts are less dumb, but they still tend to make quotes more quote-like than apostrophe-like) |
| 15:01 | <zewt> | hsivonen: that's not an apostrophe, that's a quote |
| 15:01 | <hsivonen> | zewt: there’s your problem |
| 15:02 | <hsivonen> | (JP fixed width that is) |
| 15:02 | <zewt> | not much of a problem, but you're sending the wrong character |
| 15:02 | <hsivonen> | zewt: Gnome Character map says: “this is the preferred character to use for apostrophe” |
| 15:02 | <Ms2ger> | Unicode semantics fight... 3, 2, 1, Go! |
| 15:02 | <zewt> | Gnome Character map is wrong |
| 15:02 | <hsivonen> | zewt: [citation needed] |
| 15:02 | <zewt> | the preferred character for apostrophe is: apostrophe |
| 15:03 | <zewt> | namely, U+0027 |
| 15:03 | <hsivonen> | zewt: nope |
| 15:03 | <zewt> | yep. |
| 15:03 | <hsivonen> | zewt: it looks like a foot sign—not like an apostrophe |
| 15:04 | <zewt> | looks thoroughly like an apostrophe to me :) |
| 15:05 | <zewt> | the unicode angled quote marks tend to be styled in a way meant to be symmetric with one another, and only make sense when you actually have matching quotes, not as apostrophes |
| 15:06 | <zewt> | afk, work |
| 15:08 | <krijnh> | hsivonen: que? |
| 15:08 | <krijnh> | That's correct, right? |
| 15:08 | <hsivonen> | krijnh: yes |
| 15:09 | <krijnh> | Always using UTF-8. Always declaring that I do. |
| 15:09 | <krijnh> | Next! |
| 15:12 | <MikeSmith> | about w3c-test.org syncing from github, i'm currently at the stage of conducting a personal thought experiment on that |
| 15:13 | <MikeSmith> | wait no i'm sitting zazen and contemplating it as a koan |
| 15:13 | <darobin> | rofl |
| 15:14 | <MikeSmith> | so if somebody has some time to consider / suggest some concrete ideas on that before I reach full enlightenment, that'd be great |
| 15:14 | <hsivonen> | In a way, UTF-16 ate my day again. (been preparing test cases) |
| 15:15 | <darobin> | MikeSmith: there are two sides to this, 1) triggering the download, 2) getting the content |
| 15:15 | <darobin> | for part 2, mostly I'm guessing that something like git pull, git reset --hard would work |
| 15:15 | <darobin> | for part 1, we have a bunch of options |
| 15:16 | <darobin> | Dom has a script that triggers on GH commits over email, but I don't think it'd run on that machine |
| 15:16 | <darobin> | we can have it trigger from HTTP, too |
| 15:16 | <darobin> | or just cron |
| 15:17 | <darobin> | MikeSmith: I wonder how much we could pilfer from the existing rsync script? |
| 15:17 | <darobin> | one thing that we might want to steal from it is how it quarantines changes that involve PHP and other such executable content |
| 15:17 | darobin | isn't sure where that script is, though |
| 15:20 | <MikeSmith> | darobin: I know where the review-flagging script is |
| 15:21 | <MikeSmith> | as far as rsync, i would need to ahve somewhere to rsync from |
| 15:21 | <darobin> | MikeSmith: which is where I'm putting 2 and 2 together :) |
| 15:22 | <MikeSmith> | I would think we could avoid the rsync and just do a pull |
| 15:22 | <darobin> | MikeSmith: Dom's script has to run on jay, because that's where it can be triggered by some procmail magic using a sysbot+whatever rule |
| 15:22 | <MikeSmith> | ahah |
| 15:22 | <MikeSmith> | ok |
| 15:22 | <darobin> | yeah, but if we just do a pull, does review-flagging still work? |
| 15:22 | <MikeSmith> | I think it would be made to yes |
| 15:23 | <MikeSmith> | with an appopriate hook set up in the local clone |
| 15:23 | <MikeSmith> | umm hmm |
| 15:24 | <MikeSmith> | d'oh maybe not since the content's going to be there already if we just pull it |
| 15:25 | <MikeSmith> | darobin: you have clearly already mediated on this koan more than me, sensei |
| 15:25 | MikeSmith | heads back to the woodshed |
| 15:26 | <MikeSmith> | so yeah I think we need a new step of indirection to emualate the old step of indirection (as far as the review-filtering of PHP stuff goes) |
| 15:26 | <darobin> | heh, flattery |
| 15:26 | <darobin> | MikeSmith: I can take it over if you want, but it might have to wait a little since I've got a bunch of things to finish |
| 15:26 | <darobin> | also, last time I tinkered with that box I broke things :) |
| 15:27 | <MikeSmith> | no I'll try to get it worked out this week |
| 15:27 | <darobin> | I can give you dom's script if it's helpful |
| 15:27 | <MikeSmith> | yes please |
| 15:27 | <darobin> | sure thang |
| 15:32 | <MikeSmith> | wow here's some novel fugly http://www.magicscroll.net/ScrollTheWeb.html |
| 15:34 | <MikeSmith> | I believe the effect it's intended to introduce is technically called "instant frustration" |
| 15:40 | <MikeSmith> | woo boy only thing better than a telcon right now would be a telcon where we take the whole time to go through open action items |
| 15:41 | <darobin> | especially if half the actions are questions from the old TAG that no one wants to answer :) |
| 15:43 | <MikeSmith> | heh |
| 16:03 | <Ms2ger> | darobin, MikeSmith, starting in #HTMLT |
| 16:36 | <dglazkov> | good morning, Whatwg! |
| 17:29 | <manu-db> | darobin, hsivonen, Ms2ger, annevk: The JSON-LD group decided to use IRI instead of URL, against my pleading to use URL, (because the RDF WG would probably not go for using URL instead of IRI). Discussion can be found here - http://json-ld.org/minutes/2013-01-15/#topic-2 |
| 17:46 | <marcosc> | manu-db: What are you using to generate those minutes? |
| 18:03 | <kamathln> | manu-db: totally out of the loop, read the linky you sent just for passing time, but here is my 0.5 cents - why cant you make it that the format use URL/URI/IRI interchangeably ? |
| 18:04 | <kamathln> | doh .. never mind .. i see whats wrong with that. |
| 18:14 | <bkardell> | Hixie: re web components alternative poposal on that bug... can my-tag extend select in definition or no |
| 18:25 | <manu-db> | marcosc: sorry, was on the phone - reading backlog. |
| 18:26 | <manu-db> | marcosc: I'm using scrawl.js - something I wrote in a weekend to replace the scribe tools at W3C... let me find a couple of links for you. |
| 18:27 | <bkardell> | dglazkov: if you know the answer to my question to Hixie above, please jump in |
| 18:28 | <manu-db> | marcosc: Take this text: http://json-ld.org/minutes/2013-01-15/irc.log and dump it into the edit box at the bottom of this screen: http://json-ld.org/minutes/scribe-tool/ |
| 18:29 | <manu-db> | marcosc: As you edit the minutes, they update live (so you don't have to do the awful edit/regenerate dance you have to w/ W3C current scribe tools) |
| 18:29 | <manu-db> | marcosc: all the source is available here - https://github.com/json-ld/minutes/tree/master/scribe-tool |
| 18:31 | <manu-db> | unfortunately, I haven't had the time to improve it... it works fairly well for the JSON-LD and Web Payments stuff... it's the scribe tool that I hate the least. |
| 18:36 | <dglazkov> | bkardell: |
| 18:36 | <dglazkov> | bkardell: no, in the latest proposal, you can't make a custom tag extend from an existing element. Only Element. |
| 18:38 | <bkardell> | dglazkov: why? Can't we just say that some parsers won't know about the base element? |
| 18:38 | <dglazkov> | bkardell: we could, but then that would be not the latest proposal :) |
| 18:39 | <bkardell> | dglazkov: you can't even extend other custom components??? |
| 18:39 | <dglazkov> | bkardell: you can. But their are forever slotted to be one of the two piles: is=foo-bar or <foo-bar> |
| 18:40 | <dglazkov> | their->they |
| 18:40 | <bkardell> | What happens if I say foo-bar extends select and then use the <foo-bar form? |
| 18:40 | <bkardell> | Throws? |
| 18:47 | <bkardell> | dglazkov: sorry that was for you, I just forgot to add your name |
| 18:48 | <dglazkov> | bkardell: <foo-bar> stays HTMLUnknownElement |
| 18:49 | <dglazkov> | bkardell: iow, just ignored |
| 18:51 | <bkardell> | dglazkov: that is disappointing and I think confusing. Others will not like |
| 18:52 | <dglazkov> | yeah... it's an overconstrained problem. Something's gotta give |
| 18:54 | <Ms2ger> | Clearly you should just use least squares |
| 19:03 | <dglazkov> | Ms2ger: I dunno. everybody on this channel is pretty square. Hard to pick the least ones. |
| 19:09 | <Yuhong> | <hsivonen> For example, Snow Leopard got the Java plug-in blacklisting, but it’s not clear if it otherwise gets security patches |
| 19:09 | <Yuhong> | It does, they changed the policy with Flashback. |
| 19:09 | <Yuhong> | othermaciej: Why doesn't Safari get security updates on SL while the rest of the OS does? |
| 20:17 | <Hixie> | bkardell: yes (you then bind it as <select is="my-tag">) |
| 20:23 | <bkardell> | Hixie: but only that way.. see logs my convo with dglazkov |
| 20:24 | <bkardell> | Hixie: seems better, but confusing |
| 20:26 | <Hixie> | yeah |
| 20:26 | <Hixie> | i'm certainly open to other solutions |
| 20:27 | <Hixie> | but i don't see how to satisfy everyone's requirements here |
| 20:27 | <Hixie> | this seemed like the compromise that gave the least for each position |
| 20:27 | <bkardell> | Hixie: re: your fallback comment on the bug... you could make an agument that tag/pupose may matter. Hard to judge without data |
| 20:27 | <Hixie> | how do you mean? |
| 20:29 | <bkardell> | Hixie: Well.. for some tags maybe it is more intuitive or useful for authors |
| 20:32 | <matjas> | dglazkov: did you see http://stackoverflow.com/q/14338817/96656? |
| 20:33 | <dglazkov> | matjas: no, but I am happy people are thinking through these problems |
| 20:35 | <Hixie> | bkardell: if what you want to do is make a new tag, that's supported in the latest proposal, right? |
| 20:39 | <dglazkov> | matjas: replied |
| 20:39 | <matjas> | dglazkov: thanks |
| 21:22 | <jgraham> | I am probably not following closely enough, but the last proposal on the bug did look a lot like a no-one-likes-it design-by-consensus proposal |
| 21:22 | <jgraham> | It didn't feel like anyone could look at it and go "oh yes, I see why there are these two entirely different syntaxes for doing slight variations of the same thing" |
| 21:24 | <dglazkov> | jgraham: haha, you're like the 5th person to say it |
| 21:24 | <dglazkov> | given all of the constraints, the volume of the problem space is negative at the moment. |
| 21:26 | <jgraham> | Yes. Can we also have the constaint that there should be a single syntax for all cases? |
| 21:26 | <dglazkov> | jgraham: :) |
| 21:27 | <jgraham> | Seriously :) |
| 21:27 | <dglazkov> | jgraham: you should totally reply on bug. A proposal is an iteration |
| 21:27 | <jgraham> | Then we can talk about which constraints we are willing to bend and by how much, rather than trying to find a CSS2 style bad solution that fits all the stated constraints |
| 21:27 | <dglazkov> | iterations without feedback are not very useful |
| 21:37 | <bkardell> | Hixie: it is supported yes... I meant re your comment about fallback being inside the element...your other response |
| 21:58 | <hober> | jgraham++ for one syntax |
| 21:58 | <hober> | (another reason why i prefer is="" to /; it minimizes syntactic difference between html and xhtml for this |
| 22:06 | <dglazkov> | hober what about elements that have completely new semantics (case E in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669#c36) |
| 22:11 | <jgraham> | dglazkov: I think <a is="foo"> for that case is considerably better than multiple syntaxes |
| 22:12 | <jgraham> | Argh |
| 22:12 | <jgraham> | s/<a/<x/ |
| 22:13 | <dglazkov> | why not just <x>? |
| 22:15 | <jgraham> | That would violate "one syntax" |
| 22:16 | <jgraham> | But my browser just froze, which I think makes it time to go to sleep |
| 22:17 | <dglazkov> | jgraham: that's how I know it, too |
| 22:17 | <dglazkov> | good night |
| 22:47 | <Hixie> | bkardell: you mean why <my-map><select> is bad? |
| 23:06 | <hober> | dglazkov: <span is> or <div is> |
| 23:09 | <bkardell> | Hixie: yes. I think it might not be universally good nor bad in/of itself |
| 23:09 | <bkardell> | Hixie: in certain cases maybe more intuitive/valuable to devs |
| 23:09 | <Hixie> | bkardell: well nothing is universally good or bad in this space, but i think it has a number of problems that nothing else has, while simultaneously being less useful to authors overall |
| 23:09 | <Hixie> | bkardell: (for reasons i discussed in the bug) |
| 23:20 | <bkardell> | Hixie: seems like it has advantages that most others don't too |
| 23:21 | <Hixie> | like what? |
| 23:37 | <bkardell> | Hixie: as we discussed on the bug: known pattern, no parser changes necessary, you can falllback, inform engines, etc |
| 23:37 | <bkardell> | Hixie: btw... interesting comment there on bug just now |
| 23:44 | <tantek> | how is the is= vs new tag debate not just "Distributed Extensibility, Round N+1" ? |
| 23:49 | <Hixie> | bkardell: all the patterns we're talking about are known patterns, most don't require parser changes, the fallback thing is not a real win in practice based on lessons we've learnt with HTML additions in the past few years |
| 23:49 | <Hixie> | bkardell: (not sure what "inform engines" means) |
| 23:50 | <Hixie> | tantek: this actually defines the extensibility model, the syntax is just a minor aspect of the conversation |
| 23:50 | <Hixie> | tantek: unlike the usual discussion, where the syntax (the easiest part) is the only thing discussed |
| 23:50 | <bkardell> | Hixie: just meant search engines should be able to parse the content and get meaning |
| 23:51 | <bkardell> | Hixie: existing ones I mean |
| 23:51 | <Hixie> | bkardell: ah, then i disagree that it does that in practice |
| 23:51 | <Hixie> | bkardell: because it decouples the actual element from the semantic |
| 23:51 | <Hixie> | bkardell: you really want the semantic and the new element to be the same element, imho |
| 23:51 | <Hixie> | bkardell: otherwise links from one to the other don't work |
| 23:52 | <bkardell> | Hixie: really? It's mostly a wrapper...if wrapping element throw shit to fan, seems the whole web would be lost by now |
| 23:52 | <Hixie> | the web is remarkably resilient |
| 23:52 | <Hixie> | to failure |
| 23:52 | <Hixie> | very few things fail violently enough to destroy everything |
| 23:52 | <Hixie> | doesn't mean they're not failing though |
