| 02:43 | <crocket> | TabAtkins, Is it written in a specification? |
| 07:35 | <Ms2ger> | Pilgrim was back? Was that for April Fools? |
| 08:45 | <hsivonen> | MikeSmith: have you followed the validator impact of the delta Steve has introduced in W3C HTML over WHATWG HTML? |
| 08:47 | <hsivonen> | MikeSmith: I don't like the idea of following a W3C fork of HTML in the validator. |
| 08:50 | <kochi> | MikeSmith: yt? |
| 09:22 | <SteveF> | hsivonen: which particular chnage are you concerned about? |
| 09:23 | Ms2ger | thought the HTMLWG had convergence in its charter |
| 09:24 | <SteveF> | Ms2ger: luckily authority based arguments don't count |
| 09:24 | <Ms2ger> | In the WHATWG? Yeah, I agree |
| 09:25 | <Ms2ger> | That's one of the bigger issues of the HTMLWG |
| 09:25 | <SteveF> | Ms2ger: tehe your'e funny :-) |
| 09:29 | <SteveF> | /me I must have missed the non-authority based arguments for the defintion of <main> in the WHATWG spec |
| 09:30 | <SteveF> | me/ me too |
| 09:31 | <hsivonen> | SteveF: I've noticed activity around <hgroup>, <section>, <header> and <footer>. |
| 09:31 | <Ms2ger> | "It's been implemented by multiple browsers" |
| 09:31 | <hsivonen> | SteveF: I haven't reviewed if the changes are good or bad, which is why I asked MikeSmith if he has followed what's been going on |
| 09:32 | <hsivonen> | SteveF: longdesc argumentation in bugzilla.mozilla.org seems to appeal to the authority of stuff drafted at the W3C |
| 09:33 | <SteveF> | hsivonen: no normative changes around header and footer that would effect conformance checkers |
| 09:34 | <SteveF> | hsivonen: there have been changes in ARIA implementation requirements to match reality |
| 09:34 | <hsivonen> | SteveF: ok |
| 09:35 | <SteveF> | hsivoen: discussion around section but no changes to spec as yet |
| 09:35 | <SteveF> | hsivonen: hgroup as yet unknown |
| 09:36 | <hsivonen> | SteveF: is there an easy way to see the delta? |
| 09:36 | <hsivonen> | easier than checking out the source of both specs and diffing myself |
| 09:37 | <hsivonen> | whoa. looks like mpilgrim actually let the registration of diveintomark.org expire |
| 09:39 | <SteveF> | hsivonen: not that i know of aprt from looking at the commits, I could make a practice of adding a comment to indicate normative changes that effect conformance if that would help |
| 09:39 | <annevk> | hsivonen: it's still registered |
| 09:41 | <hsivonen> | annevk: oh right. parked page. I should have read the GoDaddy thing more carefully. |
| 09:41 | <hsivonen> | boo for registering domains with GoDaddy, though |
| 09:41 | <SteveF> | hsivonen: longdesc hmm thats unsurprsing as most of the people arguing think that's useful |
| 09:44 | <SteveF> | hsivonen: my current take is that as there has been 2 new implementations in the past few months (NVDA and Chromevox) it don't seem like its going away whatever people think and therefore would like to actually be useful, whether that is possible is a different question |
| 09:51 | <SteveF> | hsivonen: so in Mozilla's case I would prefer that UI is implemented for it or support removed altogether so it doesn't continue to be a time sink |
| 09:52 | <hsivonen> | SteveF: UI as in non-AT-provided UI? |
| 09:53 | <SteveF> | hsivonen:yes |
| 09:54 | <SteveF> | hsivonen:otherwise when used it will continue to hide content from users |
| 09:56 | <SteveF> | hsivonen: which is why i never advise its use |
| 10:11 | <MikeSmith> | hsivonen: I've not been tracking the differences closely, except in cases where it does actually affect the validator |
| 10:12 | <MikeSmith> | and there are only two new cases so far where there is such a difference -- longdesc and hgroup |
| 10:15 | <MikeSmith> | in case of longdesc, I put it in under the W3C flag, so the default behavior for that remains the same. That is, longdesc will still get reported as an error except by the W3C service or except if a third-party user feeds the W3C flag to an instance at runtime |
| 10:17 | <MikeSmith> | and note that the way I landed it, all I did was change the assertions code so that it the "this element is obsolete" assertion for longdesc only gets emitted if the W3C flag is not set |
| 10:18 | <MikeSmith> | because in the schema we already had longdesc as valid, in legacy.rnc |
| 10:20 | <MikeSmith> | hmm though I did also change the legacy.rnc file to change the datatype for the longdesc value from "string" to common.data.uri |
| 10:22 | <MikeSmith> | so for a non-W3C user who has a document with longdesc that also has a non-URL value for longdesc, they will now see two errors instead of just the "this is obsolete" one |
| 10:23 | <SteveF> | MikeSmith: what about <main>? |
| 10:24 | <MikeSmith> | anyway, I didn't add longdesc to the W3C service because I thought it was a good idea. I added it to preempt the lobbying about it that I knew was going to be coming, after the HTML WG decision to publish the longdesc spec |
| 10:24 | <MikeSmith> | SteveF: ah yeah that too |
| 10:24 | <MikeSmith> | hsivonen: so, three things: <main>, longdesc, and <hgroup> |
| 10:25 | <MikeSmith> | hsivonen: in that case of main, I added some additional assertions to match the more restrictive contraints in the W3C spec |
| 10:25 | <SteveF> | MikeSmith: we don't know yet what will happen with hgroup (conformance wise) |
| 10:25 | <MikeSmith> | SteveF: really? |
| 10:26 | <MikeSmith> | SteveF: I though the WG decision requires it to be non-conforming |
| 10:26 | <MikeSmith> | as far as document conformance goes |
| 10:27 | <SteveF> | MikeSmith: maybe that's the case |
| 10:27 | <MikeSmith> | yeah I think it is |
| 10:27 | <SteveF> | OK |
| 10:27 | <MikeSmith> | I think it doesn't have any effect on implementations |
| 10:28 | <MikeSmith> | in that UAs are still required to support it |
| 10:28 | <MikeSmith> | anyway, about <main> the two changes for that to the assertions code are |
| 10:29 | <SteveF> | MikeSmith: yes thats true, but not required to implement the acc layer stuff (as it is not yet implemented) |
| 10:29 | <MikeSmith> | + registerProhibitedAncestor("article", "main"); |
| 10:29 | <MikeSmith> | + registerProhibitedAncestor("aside", "main"); |
| 10:29 | <MikeSmith> | + registerProhibitedAncestor("header", "main"); |
| 10:29 | <MikeSmith> | + registerProhibitedAncestor("footer", "main"); |
| 10:29 | <MikeSmith> | + registerProhibitedAncestor("nav", "main"); |
| 10:29 | <MikeSmith> | SteveF: OK |
| 10:30 | <MikeSmith> | so that addition above is for having <main> reported as an error if it's a descendant of article, aside, header, footer, nav |
| 10:30 | <MikeSmith> | the other one is: |
| 10:30 | <MikeSmith> | + } else if ("main" == localName) { |
| 10:30 | <MikeSmith> | + if (hasMain) { |
| 10:30 | <MikeSmith> | + err("A document must not include more than one" |
| 10:30 | <MikeSmith> | + + " \u201Cmain\u201D element."); |
| 10:30 | <MikeSmith> | + } |
| 10:30 | <MikeSmith> | + hasMain = true; |
| 10:31 | <MikeSmith> | hsivonen: so I could put those under the W3C flag as well |
| 10:32 | <zcorpan> | Hixie_: if something gets copied from the spec and pasted into the feedback form, most likely that text has been selected, and the selection is exposed to javascript. you can just save the current selection in an array in onmouseup/onkeyup |
| 10:33 | <MikeSmith> | hsivonen: though in this case, those seem to me like sane constraints that ideally the HTML LS spec should converge on as well |
| 10:35 | <zcorpan> | Hixie_: String(getSelection()) |
| 10:36 | <MikeSmith> | hsivonen: anyway, <main> and longdesc are the only ones with new spec differences that I've landed so far (and the only other existing difference we had before that which comes to mind is for the "ping" attribute). I've not done anything with hgroup yet |
| 10:39 | <SteveF> | MikeSmith: there are differences around conforming use of title attribute on <img>, which have been around since before LC but i don't know if you have implemented those |
| 10:40 | <MikeSmith> | SteveF: have not, I don't think |
| 10:40 | <SteveF> | MikeSmith: something for me to bug you about |
| 10:41 | <MikeSmith> | SteveF: well I think we have always not followed the LS spec on that |
| 10:41 | <MikeSmith> | in that it makes an exception if a doc has an img with title |
| 10:41 | <MikeSmith> | we have never implemented that exception |
| 10:42 | <SteveF> | MikeSmith:OK |
| 10:42 | <MikeSmith> | we only implemented the figcaption exception and, previously, the meta@name=generator one |
| 10:42 | <MikeSmith> | and as you know the meta@name=generator one is gone now |
| 10:43 | <SteveF> | right |
| 10:43 | <SteveF> | thanks |
| 10:44 | <MikeSmith> | kochi: here now (though maybe you're away for the day) |
| 10:45 | <MikeSmith> | kochi: about the IME API publication, it's likely I may need to change the pubdate to Thursday |
| 10:49 | <zcorpan> | no progress for webapps testsuite being on github? |
| 10:51 | <odinho> | zcorpan: Depends on what timeframe you're coming from :] |
| 10:51 | <odinho> | zcorpan: If you mean since last time we were high-fiving at the CfC passing through, -- I think not. -- tobie and darobin were busy till over easter. |
| 10:51 | <zcorpan> | odinho: from "CfC has passed but the work hasn't been done yet" |
| 10:52 | <zcorpan> | ok |
| 10:57 | <Ms2ger> | zcorpan, you're good with git? :) |
| 11:01 | <SteveF> | MikeSmith: right about <img title="poot"> throws an error |
| 11:01 | <MikeSmith> | yeah |
| 11:02 | <SteveF> | MikeSmith: says error: "poot" is not an appropriate word to use... |
| 11:04 | <odinho> | It clearly isn't. |
| 11:05 | <odinho> | woot would be better imho ^>^ |
| 11:05 | <SteveF> | odnho: ;-) |
| 12:03 | <MikeSmith> | just found https://www.rfc-editor.org/rfc/rfc6919.txt |
| 12:10 | <hsivonen> | MikeSmith: oh no. I've used "ought to" in non-normative text I've proposed in order to avoid triggering any RFC key word meaning. What do I do now? |
| 12:10 | <MikeSmith> | hsivonen: you're SOL man. You're now non-conforming |
| 12:12 | <MikeSmith> | "This command really should not be used" is good |
| 12:13 | <Ms2ger> | "There is no requirement for implementations to be reasonable." |
| 12:13 | <MikeSmith> | as is "behavior that is clearly morally right, and thus does not require substantiation" |
| 12:51 | <zcorpan> | so on github, to make multiple pull requests of another repo, do i need to create multiple branches in my fork? or fork again? |
| 12:52 | <odinho> | zcorpan: Yeah, you should always create topic branches, and do PR's on those. |
| 12:52 | <Ms2ger> | Multiple branches, I suspect |
| 12:53 | <zcorpan> | ok |
| 12:53 | <odinho> | Even a small bugfix on master is irritating for yourself, -- because in the PR page, whenever you push something new to master, suddenly that comes up in that PR. |
| 12:54 | <odinho> | zcorpan: Not unlike we do it for reviews internally :P |
| 13:08 | <zcorpan> | odinho: when i do the pull request, should it be to master on w3c/web-platform-tests? |
| 13:09 | <Ms2ger> | Yes |
| 13:09 | <zcorpan> | ok |
| 13:10 | <zcorpan> | hmmm. my previous pull request was on master (in my fork), so now this pull request has those commits in as well |
| 13:12 | <zcorpan> | what should i do about that? do a new fork? |
| 13:15 | <odinho> | zcorpan: ... No, just do a new branch. Which sits on top of upstream/master. |
| 13:15 | <odinho> | zcorpan: So that the only diff between upstream/master and my_cool_fix is everything that is supposed to be in my_cool_fix :-D |
| 13:16 | <odinho> | zcorpan: You can rebase your branch on top of upstream/master. |
| 13:16 | <odinho> | zcorpan: `git rebase -i upstream/master` might do it. If you have the upstream remote configured. |
| 13:17 | <odinho> | zcorpan: If not, you can change upstream/master with the sha of the HEAD of w3c/web-platform-tests. |
| 13:17 | <zcorpan> | $ git rebase -i upstream/master |
| 13:17 | <zcorpan> | fatal: Needed a single revision |
| 13:17 | <zcorpan> | invalid upstream upstream/master |
| 13:23 | <zcorpan> | odinho: how? |
| 13:24 | <odinho> | zcorpan: I guess the remote upstream does not exist. So, you can do: |
| 13:24 | <odinho> | git rebase -i ee01592c95 |
| 13:25 | <odinho> | (on your topic/bugfix branch) |
| 13:25 | <zcorpan> | i get the same error (except different upstream) |
| 13:26 | <odinho> | Then you can just skip/drop (remove the lines of) those commits that should not be included. |
| 13:29 | <zcorpan> | https://github.com/zcorpan/web-platform-tests/commits/submission/opera-web-messaging - the last 6 commits are included, but only the last one is what i want |
| 13:31 | <zcorpan> | i suspect i will be better off doing a new fork. then i won't have the same problem with future submissions, too |
| 13:32 | <Philip`> | If git complains it can't find ee01592c95, that probably means you need to do a "git fetch" from the w3c/web-platform-tests repository |
| 13:33 | <Philip`> | (which probably means you need to add it as a remote, if you haven't already) |
| 13:34 | <odinho> | zcorpan: Heh, you will have theh same problem over and over. You should first check that you have ee01592c95: git show ee01592c95 |
| 13:35 | <odinho> | zcorpan: If you don't have it, -- then do what Philip` said. |
| 13:35 | <odinho> | zcorpan: Then you can try the rebase again. |
| 13:35 | <zcorpan> | and what if i don't want to have this problem over and over? |
| 13:35 | <odinho> | zcorpan: Create branches for each of your commits, and reset your master branch. |
| 13:36 | <zcorpan> | my first pull request hasn't been merged yet |
| 13:36 | <odinho> | zcorpan: You can do a git checkout -b master-backup; git branch -d master; git branch master ee01592c95 |
| 13:37 | <odinho> | If I wrote everything correctly :] |
| 13:37 | <zcorpan> | will it screw up the first pull request if i reset master? |
| 13:39 | <Ms2ger> | If not that, it'll probably screw up critic |
| 13:40 | <zcorpan> | is there any downside with creating a new fork? |
| 13:40 | <Ms2ger> | You can't |
| 13:40 | <odinho> | Getting a non-obvious name? :-) |
| 13:40 | <Ms2ger> | You can only have one fork per user |
| 13:40 | <odinho> | Anyway, -- everything is fixable. |
| 13:40 | <zcorpan> | i can create a new user :-P |
| 13:40 | <odinho> | Is there valuable stuff in the reviews? |
| 13:41 | <Philip`> | You could create a new master branch that's not called "master", if you don't want to disturb your current branches |
| 13:41 | <Ms2ger> | There's nothing in the review |
| 13:42 | <zcorpan> | Philip`: aha |
| 13:42 | <Philip`> | (There's nothing special about the name "master", it's just a convention) |
| 13:43 | <zcorpan> | so how do i do that? |
| 13:45 | <odinho> | zcorpan: Call it something you like, and push it. And let that forever be your chosen name ;-) |
| 13:46 | <Ms2ger> | odinho, commands... |
| 13:46 | <odinho> | Well, you don't even need to push it. |
| 13:46 | <Philip`> | git remote add upstream https://github.com/w3c/web-platform-tests.git |
| 13:46 | <Philip`> | git fetch upstream |
| 13:46 | <Philip`> | git checkout upstream/master |
| 13:46 | <Philip`> | git checkout -b my-new-branch-name |
| 13:46 | <Philip`> | I think |
| 13:46 | <odinho> | the last two might give you an error. Prolly better to: |
| 13:47 | <odinho> | git branch my-new-branch-name upstream/master |
| 13:47 | <Philip`> | Maybe I meant "git checkout remotes/upstream/master" or something |
| 13:51 | <zcorpan> | ok i did what Philip` said |
| 13:52 | <zcorpan> | what do i do next? |
| 13:55 | zcorpan | is tempted to delete his fork and start over |
| 14:03 | <Philip`> | Were you wanting to create a new branch that is just upstream plus the one latest commit from your submission/opera-web-messaging? |
| 14:10 | <zcorpan> | Philip`: yeah i guess |
| 14:13 | <Philip`> | In that case, I guess you want something like |
| 14:14 | <Philip`> | git branch submission/topic-branch-name my-new-branch-name # where my-new-branch-name is the one based on upstream/master |
| 14:14 | <Philip`> | git cherry-pick 33096b2 # which is the commit you want on this branch |
| 14:14 | <Philip`> | Oops, do a "git checkout submission/topic-branch-name" before the cherry-pick |
| 14:15 | <Philip`> | git push origin HEAD:submission/topic-branch-name # to push your current branch onto the remote submission/topic-branch-name |
| 14:17 | <Philip`> | (cherry-pick seems easier than "rebase -i" if you just want to copy a single commit onto the current branch) |
| 14:19 | <zcorpan> | thanks Philip`! |
| 14:20 | <Philip`> | It actually worked? |
| 14:20 | <zcorpan> | yep. https://github.com/w3c/web-platform-tests/pull/46 |
| 14:21 | <zcorpan> | how are critic reviews created? |
| 14:56 | <MikeSmith> | zcorpan: right now I think jgraham has to set it up |
| 14:56 | <zcorpan> | MikeSmith: ok |
| 15:36 | <elmimmo> | Hi. I just read that "hgroup removed from the HTML5 specification" http://www.iandevlin.com/blog/2013/04/html5/hgroup-removed-from-the-html5-specification |
| 15:36 | <Ms2ger> | Not from the HTML specification |
| 15:37 | <Ms2ger> | Which is the one you'd look at for all intents and purposes |
| 15:37 | <elmimmo> | I am not too familiar with how the W3C and WHATWG specs relate to each other. |
| 15:41 | <elmimmo> | So does that mean WHATWG is keeping it in their HTML spec while W3C is dropping it from their HTML5 spec? |
| 15:41 | <Ms2ger> | Yes |
| 15:41 | <elmimmo> | Thanks |
| 15:42 | <elmimmo> | Is there any debate dumped somewhere on the different views between W3C and WHATWG on this topic? |
| 15:48 | <elmimmo> | Or is there a place where I can expect someone participating in WHATWG expressing his/her view on W3C dropping group (nd WHATWG not doing so? |
| 15:48 | <elmimmo> | hgroup, not group |
| 15:49 | <Ms2ger> | I bet the subject has come up on the whatwg list, and you could search for Hixie's reply |
| 15:51 | <elmimmo> | I did search for hgroup at http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ and the list of results was rather anemic. Last result from Sep 2012. |
| 15:51 | <annevk> | Am I missing something or does http://dev.w3.org/2011/webrtc/editor/getusermedia.html#stream-api not say what happens when there's multiple consumers? |
| 15:51 | <annevk> | Is that generally assumed to work in a stream-based API? |
| 15:52 | <elmimmo> | Is that the wrong ML? |
| 15:52 | <Philip`> | elmimmo: I'd guess some people's view might be that the matter was settled years ago through the WHATWG processes, and no new technical information has been provided since then, so there's no reason for Hixie to reconsider the decisions, and everyone has given up caring what the W3C does |
| 15:53 | <Philip`> | elmimmo: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/ is the right one |
| 15:53 | <elmimmo> | Oops. Thanks, will check again |
| 15:59 | <elmimmo> | Well, no luck. Again, most recent result is Dec 2012. I understand what you mean that the debate may have been years ago, but I wondered that the WHATWG would comment on W3C's edit of their spec, even if it was to express disagreement… |
| 16:00 | <Ms2ger> | "... everyone has given up caring what the W3C does" |
| 16:00 | <Ms2ger> | That's my position, at least |
| 16:00 | <elmimmo> | I see. Well, thanks for the clarification! |
| 16:01 | Philip` | has also mostly given up caring what the WHATWG does, so he's equally apathetic |
| 16:39 | <mounir> | slightlyoff: now that we have a Future spec'd, what is going to happen with the repository? especially with the spec there |
| 16:40 | <mounir> | slightlyoff: I actually want to write a comment regarding the spec but I do not know if it's worth creating a GH issue or not |
| 16:40 | <mounir> | both spec are slightly diverging too |
| 16:49 | <annevk> | GPHemsley: any way we can make MediaWiki:Anonnotice less intrusive? Surprisingly often I'm not logged in and it's bugging me. |
| 16:56 | <GPHemsley> | annevk: It's intrusive on purpose. ;) |
| 16:56 | <GPHemsley> | If it wasn't intrusive, no one would read it |
| 16:56 | <annevk> | GPHemsley: maybe we can remove the red note? |
| 16:56 | <annevk> | GPHemsley: I don't think there was ever confusion about that |
| 16:57 | <GPHemsley> | everything in that message was placed there because something caused it to be |
| 16:57 | <annevk> | Is there a link to some data to back that up? |
| 16:58 | <annevk> | It might very well have happened, but this is an enormous amount of boilerplate, especially on a phone. |
| 16:58 | <GPHemsley> | well, there's the page history |
| 16:58 | <GPHemsley> | http://wiki.whatwg.org/index.php?title=MediaWiki:Anonnotice&action=history |
| 16:58 | <annevk> | "Some people are still not getting it." is not really what I was hoping for |
| 16:59 | <GPHemsley> | people were e-mailing admin@ to get an account so they could propose features to specs |
| 16:59 | <annevk> | Again, I can believe a thing like that has happened, but in my memory it has not happened nearly enough to bother every visitor with it |
| 16:59 | <GPHemsley> | or e-mailing admin@ to discuss adding features to specs |
| 16:59 | <annevk> | It seems the note is about the wiki, not admin@ |
| 17:00 | <GPHemsley> | see the first of the two things I said, then ;) |
| 17:33 | <Hixie_> | hsivonen, MikeSmith: re the validator deltas from the whatwg spec, do file bugs if you think something is too relaxed or too strict and thus you end up implementing something different. |
| 17:34 | <Hixie_> | hsivonen, MikeSmith: (i'm not following your implementation details closely so i don't necessarily know when you diverge) |
| 17:36 | <MikeSmith> | Hixie_: will do |
| 17:38 | <MikeSmith> | Hixie_: btw about the tag-omission and attribute-descriptions enhancements to the spec, I'm not using them myself for anything specific, but in general I think a lot of Web authors reading the spec are going to be happy to have those |
| 17:40 | <Hixie_> | MikeSmith: cool |
| 17:52 | <MikeSmith> | Hixie_: OK just filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=21553 for strictifying <main> constraints |
| 18:03 | <MikeSmith> | and also for hgroup https://www.w3.org/Bugs/Public/show_bug.cgi?id=21554 (though hgroup is still handled as conforming in the validator code and I'm personally not in any hurry to change that) |
| 18:04 | <MikeSmith> | I won't be filing a similar one for longdesc, despite having already made the W3C validator behavior for it different |
| 18:04 | <MikeSmith> | if I thought I could get away with having the W3C validator continue to report longdesc as an error, that's what I'd be doing |
| 18:05 | <Hixie_> | i thought there was data showing hgroup was used quite a bit? |
| 18:05 | <Hixie_> | i mean, it's not going to be used THAT much |
| 18:05 | <Hixie_> | it's only for subtitles |
| 18:06 | <MikeSmith> | Hixie_: I have to admit I've not followed the hgroup discussions so closely, so for all I know there it could be used a lot more than I'm aware of |
| 18:07 | <MikeSmith> | but personally it kind of seems like overkill if the main purpose (or only purpose) is to hide the subtitle from the outline algorithm |
| 18:08 | <MikeSmith> | I wouldn't think most authors would be too upset about the outline showing the subtitle as a child of section for the main heading it follows, rather than supressing it |
| 18:13 | <Hixie_> | well, it'd be wrong, right |
| 18:14 | <Hixie_> | i mean, none of the w3c specs do that in their outline, for example |
| 18:14 | <Hixie_> | and i expect we would be upset if they did |
| 18:17 | <MikeSmith> | I guess I see using of an h2-h6 heading for a subtitle as an anti-pattern that we should be trying to discourage rather facilitate |
| 18:18 | <MikeSmith> | I think an alternative best practice is for authors to just use a color or some other punctuation, optionally with a <br>, to separate the subheading from the heading |
| 18:19 | <MikeSmith> | s/color/colon/ |
| 18:20 | <MikeSmith> | and if they want the subheading in a smaller font size or otherwise rendered differently from the heading, put <span class=subheading> around it |
| 18:21 | <Ms2ger> | "The spec says A, we do B, and Chrome does C. |
| 18:21 | <Ms2ger> | "What we do is silly, what Chrome does is dumb, and what the spec says is ok-ish but underdefined." |
| 18:21 | <MikeSmith> | s/discourage rather facilitate/ discourage rather than facilitate/ |
| 18:29 | jwalden | observes, responding to scrollback, that if Scheme/lisp/etc. can have eq? eqv? and equal?, JS can have three ;-) |
| 18:30 | <hober> | jwalden: see also http://www.nhplace.com/kent/PS/EQUAL.html |
| 18:31 | <jwalden> | :-) |
| 18:32 | <jwalden> | of course, if we could go back in time, == would have been ===-style strict equality from the start |
| 18:32 | <jwalden> | although that might have had its own problems, like document.all bustifying of the only good equality operator |
| 18:32 | <jwalden> | incidentally, Presto (so it goes) had document.all === undefined and document.all === null, as I recall |
| 18:33 | <jwalden> | I have vaguely on my todo list to write a blog post/article/whatever talking about the equality operations to describe/distinguish them |
| 18:34 | GPHemsley | uses hgroup |
| 20:01 | <jgraham> | Hmm, if zcorpan was here I would tell him that his review has been created, and apologise for the problem which was caused by some untested changes in the github / critic integration |
| 20:01 | <jgraham> | Which I think is now done enough to get review from jl |
| 20:58 | <zcorpan> | jgraham: thanks, and good night :-) |
| 21:22 | <rillian> | nessy, Hixie_: webvtt question. It seems like the parser doesn't strip or collapse whitespace between tags |
| 21:22 | <rillian> | but we have an |
| 21:23 | <rillian> | is that just a linebreaking hint? |
| 21:30 | <crocket> | Is there any problem with having "queryString" as a query parameter? |
| 21:30 | <crocket> | play framework complains if I have this. |
| 21:30 | <crocket> | an HTTP query parameter I mean. |
| 22:42 | <rillian> | window 11 |
| 23:12 | <MikeSmith> | rillian: option+q :) |
| 23:31 | <rillian> | MikeSmith: hah. sadly on this machine that online prints 'œ' |
| 23:50 | <zewt> | rillian: same purpose nbsp always has, to insert a space that doesn't break a word for wrapping |
| 23:50 | <MikeSmith> | rillian: oh then meta+q or alt+q I thnk |
| 23:53 | <Hixie_> | MikeSmith: why would using <h2> be an antipattern? with <section>, <h2> doesn't really have any other use :-) |
| 23:53 | <Hixie_> | rillian: not sure i understand the question |
| 23:55 | <rillian> | zewt: ok, that's reasonable, thanks |
| 23:56 | <rillian> | Hixie_: someone had a theory was tied to whitespace collapse, which the webvtt parser doesn't have. It confused me. |
| 23:56 | <MikeSmith> | Hixie_: because of the fact that h2 (normally) creates a new (abstract) section. That's what it's for. What it's been for in HTML since the beginning. The language has never defined h2-h6 had being for the purpose of marking up subheadings, afaik. At least implicitly, it's always been that h2-h6 are for marking up section headings. |
| 23:57 | <MikeSmith> | so to bless the usage of h2-h6 as markup for subheadings seems to me an unnecessary complication |
| 23:57 | <Hixie_> | rillian: whitespace collapsing happens via CSS |
| 23:57 | <Hixie_> | rillian: 'white-space' property |
| 23:58 | <Hixie_> | MikeSmith: well, i'd agree with you, except Tim and the rest of the W3C has been using <h2> for subheadings since the dawn of time, so... :-) |
| 23:59 | <rillian> | Hixie_: aha. so that's intended to apply to webvtt layout as well |
| 23:59 | <Hixie_> | rillian: i think so, yeah. check the rendering section for details. |
| 23:59 | <rillian> | but the webvtt parser still produces TextNodes containing only white space, if that's what's in the file |