| 05:55 | <hsivonen> | Hixie: TimBL calls us your tribe? Or Tim Bray? |
| 05:56 | <Hixie> | bray |
| 05:59 | <hsivonen> | ok |
| 05:59 | <Hixie> | nn. |
| 06:05 | <hsivonen> | nn |
| 06:28 | <hsivonen> | annevk: seems like a bad idea to investigate what browsers are doing without having a Windows license to investigate IE |
| 06:47 | <hsivonen> | The uri discussion is pretty firmly in the “the point, you are proving it” department. |
| 06:48 | <wirepair_> | hsivonen: where is this discussion occuring? |
| 06:51 | <annevk> | hsivonen: I'll fix it once I'm no longer draining my savings account |
| 07:01 | <hsivonen> | wirepair_: http://lists.w3.org/Archives/Public/uri/2012Oct/ |
| 07:03 | <wirepair_> | cheers |
| 07:21 | <annevk> | sorry about the hg mess I left Anolis in Ms2ger; I'm that dog that has no idea what he's doing |
| 07:23 | <annevk> | Ms2ger: glad you fixed it |
| 07:28 | <hsivonen> | TabAtkins: thanks for fixing the character encoding stuff in CSS3 Syntax. |
| 07:32 | Ms2ger | was surprised to see someone from "China Unicorn" introduce themselves |
| 07:33 | <hsivonen> | Ms2ger: keming? |
| 07:34 | <Ms2ger> | For some reason, thunderbird displays e-mails encoded in one of the cjk encodings in variable-width, and everything else in monospace |
| 07:34 | <Ms2ger> | So yes, more keming than I'm used to :) |
| 07:58 | <hsivonen> | dbaron: I couldn’t find proper data about which systems used the SEN_850200_B encoding, but old usenet postings suggest VAX/VMS used it. |
| 07:59 | <hsivonen> | SEN_850200_B being a 7-bit modification of ASCII used for Swedish and Finnish |
| 07:59 | <dbaron> | hsivonen, well, glad it's gone now :-) |
| 08:00 | <hsivonen> | me too |
| 08:02 | <hsivonen> | surprisingly, http://wiki.whatwg.org/wiki/Web_Encodings says IE supports it |
| 08:15 | <MikeSmith> | in the outline algorithm what exactly does "create an implied heading" mean? |
| 08:16 | <MikeSmith> | I assume it means, leave a spot in the outline for that section (which lacks a heading) |
| 08:19 | <Ms2ger> | It's like <h1>[Something the UA thinks makes sense here]</h1> |
| 08:22 | <jgraham> | Right, exactly |
| 08:25 | <jgraham> | So, someone remind me what the argument is that the outline algorithm is a candidate for removal? |
| 08:25 | <jgraham> | Is it "we don't need a well defined way to do this at all" or "this particular algorithm has known problems"? |
| 08:25 | <annevk> | not implemented? |
| 08:26 | <jgraham> | That's not really true |
| 08:26 | <jgraham> | Unless the only value of "implemented" that counts is "by default in browsers" |
| 08:26 | <annevk> | hsivonen: Gecko and IE support a lot of weird stuff :/ |
| 08:27 | <jgraham> | (at least, I think there are browser extensions that add the functionality. I don't know if there are also authoring tools or ATs that implement it) |
| 08:27 | <annevk> | Microsoft and IBM shitting all over the web :p |
| 08:28 | <jgraham> | For example http://o-extensions.y2-game.de/toc/ |
| 08:30 | <jgraham> | http://code.google.com/p/h5o/ |
| 08:32 | <MikeSmith> | I don't know who thinks the outline algorithm should be a candidate for removal |
| 08:32 | <MikeSmith> | somebody added it to the Wiki page |
| 08:33 | <MikeSmith> | but I don't remember any discussion about it |
| 08:33 | <jgraham> | istr that othermaciej and hsivonen do |
| 08:34 | <MikeSmith> | oh |
| 08:34 | <jgraham> | I might be wrong though |
| 08:34 | <jgraham> | And I don't remember their reasoning in detail |
| 08:34 | <MikeSmith> | hmm |
| 08:35 | <MikeSmith> | I should talk to hsivonen I guess |
| 08:36 | <MikeSmith> | because I have a validator contributor who's offered to implement support for an outline feature in the validator code |
| 08:36 | <MikeSmith> | and I'm asking him to implement it according to the outline algorithm in the spec |
| 08:37 | <MikeSmith> | that's one of the features the legacy W3C validator provides that validator.nu doesn't have yet |
| 08:39 | <jgraham> | Sounds pretty neat |
| 08:40 | <jgraham> | But yeah, talk to hsivonen :) |
| 08:40 | <MikeSmith> | yeah |
| 08:41 | <MikeSmith> | btw what does "istr" mean? |
| 08:42 | <jgraham> | I seem to recall |
| 08:42 | <jgraham> | But maybe no one else says that :) |
| 08:43 | <hsivonen> | MikeSmith: the CR exit criteria requires two browser implementations. for the outline algorithm, those don’t seem forthcoming |
| 08:44 | <annevk> | s/istr that/iirc/ ;) |
| 08:44 | <othermaciej> | MikeSmith: it seems unlikely that any browser will implement the outline algorithm to me |
| 08:44 | <othermaciej> | let alone two |
| 08:44 | <MikeSmith> | hsivonen, othermaciej: are you sure that outline algorithm requires it on the browser conformance class? |
| 08:44 | MikeSmith | looks |
| 08:44 | <othermaciej> | it may be that some interesting non-browser consumers will implement it but I don't see evidence of that either |
| 08:44 | <annevk> | doesn't AT support something like it already? |
| 08:44 | <othermaciej> | the outline algorithm isn't part of any conformance class iirc |
| 08:45 | <hsivonen> | validator code demonstrating implementability using SAX without full tree access could be good input for efficient selector impl, too |
| 08:45 | <MikeSmith> | hsivonen: hmm yeah |
| 08:46 | <MikeSmith> | hsivonen: but I think the guy i've been talking with who's offered to implement it may not understand how much work it is to implement in SAX |
| 08:47 | <othermaciej> | I don't know if any screen readers or other assistive technologies aim to implement the html5 outline algorithm |
| 08:47 | <othermaciej> | from what I can tell, html5 does not require any conformance class to implement the outline algorithm, but it does appear to forbid generating a document outline that does not match the outline algorithm |
| 08:48 | <othermaciej> | thus, an AT with a "jump to next heading" that doesn't match the outline algorithm would be nonconforming per the current draft |
| 08:50 | <othermaciej> | I am curious if anyone has attempted to implement the implied lower heading levels for h1 with sectioning ancestors |
| 08:50 | <othermaciej> | though that seems much simpler than implementing the outline algorithm |
| 08:51 | <MikeSmith> | there are browser plugins that generate outlines and that follow the spec |
| 08:51 | <MikeSmith> | or claim to |
| 08:52 | <jgraham> | So, it seems kind of absurd to me that we would have all this machinary for creating tree-structured documents and not have any defined mapping between the markup and the tree structure it generates |
| 08:52 | <MikeSmith> | http://code.google.com/p/h5o/ |
| 08:52 | <jgraham> | On the other hand, I am not particularly wedded to the current algorithm |
| 08:53 | <MikeSmith> | that would seem to be a good feature to add to developer tools in browsers in some form |
| 08:53 | <MikeSmith> | *this would seem to be |
| 08:53 | <jgraham> | It would for-sure be nice if there was something fast enough to use with a notional ::heading(n) selector |
| 08:54 | <hsivonen> | MikeSmith: creating a tree just for the outline would be kinda uncool considering that we are supposed to be on track to removing Schematron and, therefore, trees |
| 08:55 | <MikeSmith> | hmm yeah |
| 08:56 | <MikeSmith> | hsivonen: it would be an option though |
| 08:56 | <MikeSmith> | or could be implemented that way I mean |
| 09:00 | <MikeSmith> | hsivonen: is TreeDumpContentHandler not also creating a tree? |
| 09:01 | <hsivonen> | MikeSmith: it’s not on its own |
| 09:01 | <hsivonen> | It can be used with the treeless mode, too |
| 09:01 | <MikeSmith> | ah |
| 09:02 | <hsivonen> | one possibility is creating a redacted tree that throws away stuff that doesn’t affect the outline |
| 09:02 | <hsivonen> | but I think implementation without a tree would give the most insight into whether the outline algorithm is ever going to find its way into a selector |
| 09:08 | <hsivonen> | I wonder if this is XML 5th ed. sending fun my way or something else: https://bug804116.bugzilla.mozilla.org/attachment.cgi?id=673828 |
| 09:08 | <hsivonen> | well-formed in Chrome. Ill-formed in Firefox and Opera. |
| 09:09 | <MikeSmith> | hsivonen: maybe I should write the outline code myself instead of expecting that the guy who volunteered will be able to do it the way we need |
| 09:11 | <MikeSmith> | hsivonen: the point where it fails in Firefox is odd |
| 09:11 | <MikeSmith> | if that marker is correct |
| 09:11 | <MikeSmith> | oh it fails at different point in Opera |
| 09:11 | <MikeSmith> | if the marker is correct there |
| 09:12 | <hsivonen> | yeah. more investigation needed. |
| 09:12 | <hsivonen> | I can’t tell if it succeeds or fails in IE10, since I don’t know what success and failure are supposed to look like |
| 09:40 | <Stevef_> | annevk: JAWS implements the outline algorithm sans hgroup, but the implementation is borked see my comment here for details http://www.netmagazine.com/tutorials/html5-ranked-headings-screen-readers#comments |
| 09:47 | <Stevef_> | on the subject I note that there is no longer a requirement for UAs to hide the subheadings in hgroup from generated outlines, which was the only use case put forward for hgroup |
| 09:50 | <Stevef_> | also looking a usage data and how hgroup is defined a simple rule for indicating subheadings for the purpose of outline generators could be that if a hx has a sibling hx then its a subheading |
| 09:55 | <Stevef_> | hgroup usage examples: http://html5accessibility.com/HTML5data/hgroup.html |
| 10:06 | <Stevef_> | othermaciej: it seems apparent that browsers would need to implement the outline algorithm and provide that correct heading levels via accessibility APIs as the heading levels indicated in the element names can no longer be relied upon. |
| 10:07 | <jgraham> | Stevef_: Excluding hgroup, do you have any feedback indicating that these aren't exposed due to a problem in the algorithm, or simply because people haven't got that far yet? |
| 10:12 | <Stevef_> | jgraham: well freedom scientific have tried to implement the algorithm and can't seem to get it right, reason unknown, probably incompetence. Haven't seen any indication from browser implementers that they plan to implement the accessibility mapping, probably because there are other more important things to implement. the sane approach (i think) would be for browsers to provide the adjusted... |
| 10:12 | <Stevef_> | ...heading structure via the acc APIs for ATs to consume |
| 10:12 | <MikeSmith> | Stevef_: in the current outline algorithm, I think if hx has a sibling hx that's of lower rank, then it has a nested subsection |
| 10:14 | <Stevef_> | mikesmith: ok what i meant was direct sibling (don't know if that is meaningful) as in <h1></h1><h2> rather than <h1></h1> <elementx> <h2> |
| 10:15 | <MikeSmith> | yeah I know |
| 10:15 | <Stevef_> | mikesmith: only hx are allowed in hgroup so where it is used conformingly that is the pattern you get |
| 10:16 | <MikeSmith> | the current spec for the outline algorithm doesn't treat those to cases differently, I don't think |
| 10:17 | <MikeSmith> | of course it could be changed if a good rationale is made |
| 10:17 | <Stevef_> | mikesmith: the oultine algorithm is not set in stine right? |
| 10:17 | <MikeSmith> | right, sure |
| 10:17 | <MikeSmith> | nothing is |
| 10:17 | <MikeSmith> | well nothing that's not already implemented widely |
| 10:17 | <jgraham> | Kind of seems weird if you can't do |
| 10:18 | <jgraham> | <h2>Introduction</h2> |
| 10:18 | <jgraham> | <h3>Outline of the problem</h3> |
| 10:18 | <jgraham> | And then later |
| 10:18 | <jgraham> | <h3>Previous work</h3> |
| 10:18 | <jgraham> | Without the first <h3> and the second being treated equally |
| 10:21 | <Stevef_> | jgraham: right, throw that idea away :-) |
| 10:22 | <MikeSmith> | I think that's a bad pattern |
| 10:22 | <MikeSmith> | though I know people do it |
| 10:22 | <jgraham> | What's a bad pattern? |
| 10:22 | <MikeSmith> | there rightly should be some text between the Introduction heading and the next subheading |
| 10:22 | <MikeSmith> | to introduce the introduction |
| 10:23 | <MikeSmith> | "This section provides an outline of the problem and then discusses previous work." |
| 10:23 | <MikeSmith> | Otherwise when it's rendered it in fact just looks like a subheading anyway |
| 10:24 | <MikeSmith> | in the rendering the reader has no way to tell if the author meant it as a subheading or as a subsection heading |
| 10:24 | <MikeSmith> | a reader could read the title of the whole section as "Introduction: Outline of the problem" |
| 10:26 | <Stevef_> | mikesmith: so its back to the issue of how to indicate subheadings |
| 10:26 | <jgraham> | MikeSmith: It seems like my thesis (which just happened to be on this machine and so easy to look at) mostly agrees with you, but sometimes doesn't |
| 10:26 | <MikeSmith> | I guess I'm not convinced the issue of how to indicate subheadings is really an important problem to solve |
| 10:27 | <jgraham> | e.g. \subsection{Properties of a Plasma} |
| 10:27 | <jgraham> | \subsubsection{Debye Radius} |
| 10:27 | <MikeSmith> | jgraham: fix the places where it doesn't agree with me :) |
| 10:27 | <MikeSmith> | LaTeX should enforce this for you |
| 10:27 | <MikeSmith> | I know it doesn't |
| 10:28 | <MikeSmith> | I'm saying it should |
| 10:28 | <jgraham> | MikeSmith: I'll need to borrow a DeLorean :p |
| 10:28 | <MikeSmith> | hah |
| 10:29 | <MikeSmith> | you could just add "5th Edition" to your thesis after you make the changes |
| 10:29 | <MikeSmith> | and then everything will be OK |
| 10:29 | <jgraham> | heh |
| 10:30 | <Stevef_> | MikeSmith: "I guess I'm not convinced the issue of how to indicate subheadings is really an important problem to solve" agreed, but the problem is there due to a feature being added to do it |
| 10:30 | <MikeSmith> | anyway I think because of the way authors (mis)use section titles, readers would not be able unambiguously know whether something is intended as a subheading or a subsection heading even if we have a way to mark it up explicitly |
| 10:30 | <MikeSmith> | Stevef_: yeah I hear you |
| 10:31 | <MikeSmith> | paved with good intentions |
| 10:32 | <Stevef_> | MikeSmith: but i suppose the problem is moot if the feature isn't implemented |
| 10:33 | <MikeSmith> | well hgroup is implemented in the parser |
| 10:33 | <MikeSmith> | and in the default UA stylesheet |
| 10:33 | <MikeSmith> | as Henri's pointed out |
| 10:34 | <Stevef_> | MikeSmith: I mean meaningfull implementation as it catually has an effect on something rather than rendering right |
| 10:34 | <MikeSmith> | yeah |
| 10:35 | <MikeSmith> | I don't think browsers are ever going to do what's shown in the example in the spec |
| 10:36 | <MikeSmith> | as far as the default rendering |
| 10:36 | <MikeSmith> | or I dunno maybe it's not the intent of the spec to suggest that they do |
| 10:37 | <MikeSmith> | that is, rendering <h1>The reality dysfunction</h1> <h2>Space is not the only void</h2> as "The reality dysfunction: Space is not the only void" |
| 10:38 | <annevk> | MikeSmith: I don't think the rendering section suggests doing that |
| 10:38 | <annevk> | MikeSmith: maybe for AT? |
| 10:38 | <MikeSmith> | I think if somebody wants that rendering, they're just going to mark it up as <h1>The reality dysfunction: Space is not the only void</h1> anyway |
| 10:38 | <MikeSmith> | annevk: that example is from http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-hgroup-element |
| 10:38 | <Stevef_> | Mikesmith: agreed |
| 10:39 | <annevk> | MikeSmith: yeah that's not about browsers |
| 10:39 | <Stevef_> | the requirement for acc mapping is that this <h1>The reality dysfunction</h1> <h2>Space is not the only void</h2> becomes <h1>The reality dysfunction Space is not the only void</h1> |
| 10:40 | <MikeSmith> | Stevef_: why is that the requirement? |
| 10:40 | <Stevef_> | MikeSmith: the ARIA mapping |
| 10:40 | <MikeSmith> | OK |
| 10:41 | <Stevef_> | or rather the default implied mapping |
| 10:41 | <MikeSmith> | is the requirement literally that? no punctuation at all between the two? e.g., no colon character? |
| 10:44 | <Stevef_> | MikeSmith: no the requirment is that the indovidual heading levels are removed and the hgroup becomes the heading, so in acc mapping they would not add colons or other things |
| 10:44 | <MikeSmith> | that don't seem so great |
| 10:45 | <MikeSmith> | in that example it obviously changes that meaning |
| 10:46 | <MikeSmith> | Stevef_: why can't the acc mapping be changed to require putting some character in between there? |
| 10:46 | <Stevef_> | MikeSmith: thats what i have been arguing about for ever, I originally just wanted to get some sanity in the hgroup mapping as it removes differentiation |
| 10:47 | <MikeSmith> | ok |
| 10:48 | <Stevef_> | MikeSmith: well an answer is because "How a user agent exposes such multi-level headings in user interfaces (e.g. in tables of contents or search results) is left open to implementors, as it is a user interface issue. " |
| 10:49 | <Stevef_> | Mikesmith: also what character would be always appropriate? |
| 10:50 | <MikeSmith> | whatever character is appropriate to the locale |
| 10:50 | <MikeSmith> | or actually, the equivalent of a full stop |
| 10:51 | <Stevef_> | MikeSmith: what I mean is there always a character that provides the intended meaning depenedning on the content of the heading and subheading? |
| 10:53 | <MikeSmith> | Stevef_: in the case of AT it would be preferable to not have it read out the character literally, right? |
| 10:54 | <MikeSmith> | so given that I think it should just be a period |
| 10:54 | <MikeSmith> | or whatever the full stop is for the localte |
| 10:54 | <MikeSmith> | *locale |
| 10:55 | <MikeSmith> | e.g., "。" for Japanese |
| 10:55 | <MikeSmith> | because I would think that all that you would want to voice to do is to stop between those two parts |
| 10:55 | <MikeSmith> | in the same way it would normally stop between sentences |
| 10:57 | <Stevef_> | Mikesmith: i think its better to provide a semantic that indicates its a subheading in acc mapping then let the AT and the AT user decide how they want the semantics indicated or not |
| 10:58 | <Stevef_> | MikeSmith: and better to let the author do it <h1>The reality dysfunction: Space is not the only void</h1> or <h1>The reality dysfunction</h1> <p>Space is not the only void<p> |
| 11:00 | <Stevef_> | MikeSmith: but will float with marco and the mozilla acc engineers to see what they think |
| 11:00 | <MikeSmith> | Stevef_: sounds right to me |
| 11:20 | <Stevef_> | on another note, reviewing a web site found this onchange="VBSCRIPT:ImgNavJump()" ... |
| 11:26 | <annevk> | look harder, there's weirder stuff out there :) |
| 11:30 | <Stevef_> | yeah, just hadn't seen vbscript in the wild for a while |
| 11:48 | <hsivonen> | yes, it was indeed XML 1.0 5th ed. wasting my time today |
| 12:32 | <annevk> | hmm |
| 12:32 | <annevk> | <!DOCTYPE html> |
| 12:32 | <annevk> | <style> :target { background:yellow } </style> |
| 12:32 | <annevk> | <a href="#%b1">test</a> |
| 12:32 | <annevk> | <div id=%b1>test</div> |
| 12:32 | <annevk> | why would that not match? |
| 12:32 | <benschwarz> | Hixie: when you're back — https://github.com/benschwarz/developers.whatwg.org/issues/69 |
| 12:41 | <annevk> | benschwarz: are you then also going to make it the full specification rather than a subset? |
| 12:41 | <benschwarz> | annevk: It'll still bare the title "Web developer edition" |
| 12:42 | <annevk> | I meant including Web Workers and such |
| 12:42 | <annevk> | fwiw, your chapter nine has been long gone from the real spec |
| 12:43 | <benschwarz> | annevk: hmm. thats something we should raise with Hixie |
| 12:43 | <benschwarz> | annevk: I could see value in adding the full specification |
| 12:44 | <benschwarz> | I need to catch Hixie when he is online, clearly |
| 12:44 | <annevk> | that'd be about 7 hours from now for about 9 hours |
| 13:01 | <benschwarz> | right when I sleep :) |
| 13:07 | <zcorpan> | Stevef_: that's not actually vbscript though. event handler attributes are always javascript. in javascript, the thing before the colon is called a label and can be an arbitrary identifier |
| 13:07 | <Stevef_> | zcorpan, right thanks |
| 13:09 | <zcorpan> | hsivonen: chrome implements 5th ed? |
| 13:11 | <annevk> | libxml2 prolly does and WebKit updated to the latest |
| 13:12 | <zcorpan> | booo |
| 13:12 | <annevk> | XML 5th is a step towards XML 5 |
| 13:12 | <zcorpan> | now cue 6th ed with LEIRI support |
| 13:12 | <zcorpan> | (i recall the xml core wg actually working on that) |
| 13:23 | <annevk> | but that's not going to impact behavior |
| 14:06 | <GPHemsley> | FTR, r3580 was when the references were added. |
| 14:06 | <GPHemsley> | Which means anything before that is difficult to find what I'm looking for. |
| 14:07 | <GPHemsley> | (Though probably not impossible.) |
| 14:08 | <GPHemsley> | BTW, giving the HTML5 Tracker different titles on different pages would be super helpful. |
| 14:12 | <GPHemsley> | It sure would be nice if there were such thing as forward blame, to answer the question "When does this line get changed next or removed?" |
| 14:13 | <annevk> | GPHemsley: http://code.google.com/p/html5/source/browse/#svn%2Ftrunk%2Fweb-apps-tracker |
| 14:13 | <annevk> | GPHemsley: not entirely sure if that's in sync with the code online |
| 14:13 | <GPHemsley> | eww, icky |
| 14:13 | <annevk> | what is icky? the Python? |
| 14:14 | <GPHemsley> | SVN + Google Code |
| 14:14 | <annevk> | oh |
| 14:15 | <annevk> | I'm happy to move the web-apps-tracker code elsewhere |
| 14:15 | <annevk> | maybe that should become a GitHub repo as well |
| 14:15 | GPHemsley | thinks so |
| 14:17 | <hsivonen> | annevk: fwiw, I said I think we should not implement 5th ed. without going all the way to XML-ER/XML5. |
| 14:27 | <hsivonen> | I was wrong the other day when I claimed that Gecko fails to handle buffer boundaries within the BOM in CSS or within the CSS @charset rule. |
| 14:32 | <GPHemsley> | WebVTT uses CVS?? @_@ |
| 14:35 | <GPHemsley> | Actually, I quite like the old CVSWeb/ViewVC interface, so I won't complain too much. |
| 15:01 | GPHemsley | can't believe it's almost two years since WebSRT was renamed to WebVTT. |
| 15:15 | <annevk> | is there a way you can import part of an SVN repository into GitHub? |
| 15:15 | <annevk> | or should I not bother preserving history? |
| 15:15 | <annevk> | (not sure if I'm going to do it now btw) |
| 15:15 | GPHemsley | wonders why the WebRTC spec doesn't list all the previous versions on the same page. |
| 15:16 | <jgraham> | annevk: Define "part"? git-svn will allow you to import anything that you can express as a partial checkout (i.e. a particular directory) |
| 15:17 | <annevk> | jgraham: I guess I'm thinking contents of a directory |
| 15:17 | <jgraham> | Then yes, use git-svn |
| 15:18 | <annevk> | jgraham: if you have it installed, can you do it for me? |
| 15:19 | <jgraham> | Yeah, probably |
| 15:19 | <annevk> | I'll create a repo |
| 15:20 | <annevk> | jgraham: https://github.com/whatwg/web-apps-tracker |
| 15:21 | <annevk> | jgraham: http://code.google.com/p/html5/source/browse/#svn%2Ftrunk%2Fweb-apps-tracker are the folder contents that need to end up there |
| 15:26 | GPHemsley | wonders if web-apps-tracker is still an appropriate name |
| 15:30 | <annevk> | GPHemsley: when Hixie moves the spec to html.spec.whatwg.org we can have that discussion |
| 15:30 | <GPHemsley> | heh |
| 15:30 | <GPHemsley> | can't wait |
| 15:31 | <annevk> | would you more commonly want a URL serialized including or without fragment? |
| 15:31 | <annevk> | I'm going for with |
| 15:33 | <gavinc> | annevk: +1 to including fragment |
| 15:33 | <GPHemsley> | annevk: If I were to take over mimesniff, how would that work? |
| 15:33 | <jgraham> | annevk: Done |
| 15:33 | <annevk> | I'll also have without, for HTTP |
| 15:33 | <annevk> | jgraham: sweet |
| 15:34 | <gavinc> | annevk: I think you'd mentioned before changing hierarchical to relative? |
| 15:34 | <annevk> | GPHemsley: talk to abarth maybe about issues, email the WHATWG list for issues, and fix things and ask for review |
| 15:34 | <annevk> | gavinc: in the parser? |
| 15:35 | <annevk> | gavinc: does it make sense to talk about "relative schemes"? |
| 15:35 | <annevk> | gavinc: I guess then we could avoid all usage of hierarchical |
| 15:36 | <gavinc> | annevk: I just found it hard to read those parts coming from the existing language around "relative" and "resolve" the lack of those words got me good and lost on my first reading |
| 15:37 | <gavinc> | purely an editorial thing, in general once I got that sorted out I found it far simpler to read and understand then the old RFCs |
| 15:39 | <annevk> | sure, I was just wondering whether the wording "relative scheme" makes sense; I guess about as much as "hierarchical scheme" |
| 15:40 | <annevk> | gavinc: can you pm me your name for the acknowledgments (unless you want to go as gavinc); for when I make that change |
| 15:44 | <gavinc> | oh, and some comment that EOF code point is the "" null string? again, confused for a few moments before getting it |
| 15:44 | <annevk> | well it could be anything really, it's a conceptual thing |
| 15:45 | <gavinc> | ... yeah ... perhaps a bit too abstract given the concreteness of all the other switches in the hierarchical parsing section |
| 15:46 | <annevk> | gavinc: would it help if I clarified it signifies end-of-input? |
| 15:46 | <gavinc> | Yes! |
| 15:54 | <annevk> | GPHemsley: there's some cleanup to be done too, e.g. one of the references is not present last I checked |
| 15:54 | <annevk> | GPHemsley: and the text could use some of the <dfn>/<span> hyperlinking other specs have |
| 15:55 | <annevk> | GPHemsley: and personally I think we want to define how to parse MIME types; as well as which are conforming, how to extract certain parameters, etc. |
| 15:56 | <annevk> | GPHemsley: that would require some studying of other specifications that depend on MIME types, such as XMLHttpRequest / HTML / etc. |
| 15:56 | <annevk> | gavinc: done |
| 15:59 | <Hixie> | benschwarz: pong |
| 16:00 | <Hixie> | GPHemsley: why are the references interesting, anyway? |
| 16:01 | <Hixie> | benschwarz: (did the renames, should be up soon) |
| 16:01 | <Hixie> | benschwarz: (oh actually it might take a few days unless you want me to force it, since i only update that weekly iirc) |
| 16:02 | <gavinc> | annevk: thanks! |
| 16:04 | <annevk> | Hixie: made the changes you asked for, still a bit unsure about URL conformance with respect to having it tied down |
| 16:04 | <annevk> | Hixie: e.g. we could forbid <a href="/<>">test</a> but is there really any point if <> are going to be escaped anyway? |
| 16:05 | <annevk> | Hixie: and although STD 66 does not allow [] anywhere allowing them seems harmless and useful for mailto:whatwg⊙wo?subject[URL] |
| 16:05 | <Hixie> | annevk: the reason for conformance criteria is to steer authors away from stuff that could be confusing or likely indicates author error |
| 16:06 | <Hixie> | annevk: given that people like to mark URLs by putting them between <...>, it seems reasonable to exclude < > from URLs |
| 16:06 | <annevk> | Hixie: and with URLs whose relative flag is false, such as data:, UAs do not even escape %20 |
| 16:06 | <annevk> | and forbidding it gives ugly URLs |
| 16:07 | <Hixie> | data:,where does this URL end? here? here? has it ended yet? |
| 16:07 | <Hixie> | how about now, has it ended? :-) |
| 16:07 | <annevk> | well you put these URLs in place with clear defined delimiters |
| 16:08 | <Hixie> | like spaces? :-) |
| 16:08 | <annevk> | if you're going to put URLs in plain text, you're gonna have a bad time anyway |
| 16:08 | <Hixie> | not if i use IRIs or STD66 |
| 16:08 | <Hixie> | also, space-separated URLs are used in the spec in various places |
| 16:08 | <Hixie> | e.g. imgsrc="" delimits URLs on spaces |
| 16:09 | <annevk> | yeah in those contexts you'd have to constrain your URL somehow |
| 16:09 | <annevk> | you're gonna have the same problem in a language where : has special meaning |
| 16:09 | <Hixie> | if i could "constrain my URL" i would have banned commas |
| 16:10 | <Hixie> | you can't tell people the URL syntax is different here than there |
| 16:10 | <Hixie> | that's just silly |
| 16:12 | <gavinc> | MAY or MAY NOT ... aka do whatever the f**k you want why the heck am I adding that to a spec?! |
| 16:37 | <annevk> | gavinc: you're bound by the laws of consensus? :p |
| 16:38 | <gavinc> | annevk: indeed |
| 16:39 | <annevk> | uri⊙wo is now bikeshedding what we could call URLs if we're not calling them URLs |
| 16:39 | <annevk> | we're gonna call them URLs though |
| 16:40 | <gavinc> | Oh don't worry I'm calling them IRIs |
| 16:40 | gavinc | goes and cries |
| 16:41 | <GPHemsley> | Hixie: Generally, when a portion of HTML was spun-off as a separate spec, it got referenced in the References section. So when trying to track down when it first got spun off, I could use its (non-)presence which direction in history to go. |
| 16:42 | <Hixie> | GPHemsley: interesting |
| 16:42 | <Hixie> | GPHemsley: did anything get spun off before then? |
| 16:43 | <Hixie> | before the refs section i mean |
| 16:43 | <annevk> | XHR |
| 16:43 | <annevk> | but that might even predate SVN |
| 16:43 | <Hixie> | true, but that didn't get a ref anyway |
| 16:43 | <Hixie> | though i guess it does now have one |
| 16:43 | <annevk> | Selectors API too I guess, but that was never more than a note |
| 16:44 | <Hixie> | yeah that was wishful thinking before lachlan worked on it |
| 16:44 | <GPHemsley> | If it predates SVN, is it really a spin-off? |
| 16:44 | <annevk> | bbl |
| 16:44 | <GPHemsley> | If it was nothing more than a note, is it really a spin-off? |
| 16:45 | <Hixie> | xhr was definitely a spinoff |
| 16:45 | <Hixie> | selectors api, not really |
| 16:45 | <Hixie> | i mean, kinda |
| 16:45 | <Hixie> | i was going to have to do work, and lachlan made it so that i didn't have to do work |
| 16:45 | <Hixie> | but i wouldn't claim any credit |
| 16:45 | <Hixie> | unlike on xhr, where obviously i did all the hard work and anne just had to fix some typos |
| 16:45 | Hixie | runs away |
| 16:46 | <GPHemsley> | My definition of a spinoff is whether it was if conformance/specification requirements were once in HTML and are now elsewhere. |
| 16:46 | <GPHemsley> | So, hypotheticals are not really spinoffs, IMO. |
| 16:46 | <Hixie> | xhr had conformance requirements for sure |
| 16:46 | <Hixie> | but selectors had nothing |
| 16:46 | <GPHemsley> | So, what was the file before SVN? |
| 16:47 | <Hixie> | just, uh, a file |
| 16:47 | <GPHemsley> | how long did that last? |
| 16:47 | <Hixie> | more than it had any right to |
| 16:47 | <Hixie> | (started late 2003) |
| 16:47 | <Hixie> | (svn started what, 2006?) |
| 16:48 | <Hixie> | march 2006 |
| 16:48 | <Hixie> | so all of 2004 and 2005 plus about six months |
| 16:48 | <Hixie> | i was young! we didn't know what we were doing! :-P |
| 16:48 | <GPHemsley> | heh |
| 16:49 | <Hixie> | there's some snapshots from before then, see http://www.whatwg.org/specs/web-apps/ |
| 16:49 | <Hixie> | back then http://www.whatwg.org/specs/web-forms/ was the main thing being worked on |
| 16:49 | <Hixie> | which later got "spun in" |
| 16:50 | <Hixie> | http://www.whatwg.org/specs/web-forms/2004-06-27-call-for-comments/ has some links to even earlier versions |
| 16:50 | <Hixie> | in the header |
| 16:50 | <Hixie> | https://lists.w3.org/Archives/Member/w3c-archive/2003Sep/att-0014/hfp.html is the earliest spec that later turned into what is now the HTML Living Standard |
| 16:50 | <Hixie> | wrote that in about a week or something |
| 16:51 | <Hixie> | i had no idea what i was getting into |
| 16:51 | <GPHemsley> | well, it was still in on 2006-01-01 |
| 16:51 | <GPHemsley> | so that narrows it down |
| 16:51 | GPHemsley | doesn't have W3C access. |
| 16:51 | <Hixie> | wow there's still stuff that i wrote in that 2003 september draft that lives on in today's version! |
| 16:52 | <Hixie> | appendix B for example |
| 16:52 | <Hixie> | uh, let me copy that to somewhere more public |
| 16:53 | <Hixie> | http://www.hixie.ch/specs/html/forms/hfp.html |
| 16:54 | <GPHemsley> | Could you get me that list of available blames? |
| 16:54 | <GPHemsley> | again |
| 16:54 | <Hixie> | yeah one sec |
| 16:58 | <Hixie> | GPHemsley: http://www.whatwg.org/specs/web-apps/current-work/blames-list.cgi |
| 16:58 | <GPHemsley> | Ah, thanks. |
| 17:07 | <GPHemsley> | Hixie: Do you have an exact date for that first draft? |
| 17:08 | <Hixie> | for when i sent it to w3c-archive? or for when i started working on it? or? |
| 17:09 | <GPHemsley> | sure, the date you sent it would be fine |
| 17:09 | <MikeSmith> | GPHemsley: http://platform.html5.org/history/ might be useful to you some |
| 17:09 | <MikeSmith> | 2003-09-05 was the date it was posted I think |
| 17:10 | <Hixie> | Fri, 5 Sep 2003 11:28:31 +0000 (UTC) |
| 17:10 | <Hixie> | https://lists.w3.org/Archives/Member/w3c-archive/2003Sep/0014.html |
| 17:10 | <GPHemsley> | ah, ok, thanks |
| 17:18 | <MikeSmith> | about the @uri discussion I wonder how many other specs if any actually normatively refer to the definition of URL in RFC 3986 |
| 17:18 | <say2joe> | 9 years for new (HTML5) input attributes! unbelievable… what's worse is IE still barely supports them. |
| 17:18 | <MikeSmith> | RFC 3986 itself never even refers back to that definition. The term is used exactly once in the whole spec, in the sentence that defines it |
| 17:19 | <MikeSmith> | so there's really not much to conflict with there |
| 17:28 | <GPHemsley> | Alright, I put all those links on the wiki: http://wiki.whatwg.org/wiki/HTML_snapshots |
| 17:29 | <GPHemsley> | Hixie, MikeSmith: ^^ |
| 17:37 | <annevk> | Hixie: hey, I did Selectors API first :p |
| 17:37 | <Hixie> | oh, right |
| 17:38 | <annevk> | Hixie: and yeah, fixed thousands of "typos" in XHR |
| 17:38 | <Hixie> | :-P :-P |
| 17:40 | <jgraham> | Wow, Firefox is pushing through a change to the UA string despite having a list of 14 known bank sites that break. That seems... odd |
| 17:42 | <annevk> | are they making it shorter? |
| 17:42 | <jgraham> | A little |
| 17:42 | <annevk> | yay |
| 17:43 | <Hixie> | jgraham: not even putting in hacks for those sites? |
| 17:43 | <gavin> | they are site-specific UA changes |
| 17:44 | <gavin> | oh, I misread jgraham's statement |
| 17:44 | <gavin> | the current plan is to keep the UA change, and put in hacks for the broken sites |
| 17:44 | <Hixie> | aah |
| 17:44 | <gavin> | but it's still early in the cycle |
| 17:44 | <gavin> | so those plans might change |
| 17:45 | <gavin> | the set of people involved in making changes on trunk and the set of people involved in letting those changes ship in release are different :) |
| 18:02 | <GPHemsley> | hmm... the change tracker doesn't show the diff for r1 |
| 18:03 | <GPHemsley> | possibly because the to=1 is not treated as an integer |
| 18:03 | <GPHemsley> | or, because from=0 is no good |
| 18:09 | <annevk> | GPHemsley: it's in GitHub now |
| 18:09 | <GPHemsley> | annevk: Should I take that as a hint? :P |
| 18:09 | <annevk> | uhuh |
| 18:12 | <annevk> | I remember I used to download web-apps every now and then and just diff it locally |
| 18:17 | <annevk> | just learned how jQuery names "relative references": "url" |
| 18:20 | <GPHemsley> | Hixie: Wouldn't it be best to move http://www.whatwg.org/specs/web-forms/current-work/ to http://www.whatwg.org/specs/web-forms/2009-01-05/ and then redirect the former to http://www.whatwg.org/specs/web-apps/current-work/ ? |
| 18:22 | <Hixie> | GPHemsley: "best" in what sense? |
| 18:22 | <GPHemsley> | Hixie: In whatever sense makes the answer "yes" ;) |
| 18:22 | <Hixie> | in the sense that "it would be work Hixie has to do that doesn't help anyone ever", yes :-P |
| 18:23 | <GPHemsley> | meh |
| 18:23 | <Hixie> | the spec is pretty clear that it's dead, i'm happier letting it rot in peace |
| 18:23 | <Hixie> | maybe "rest in peace" would be a better way to put it |
| 18:23 | <GPHemsley> | well, it just makes it a little odd to link to, that's all |
| 18:31 | <Hixie> | yeah |
| 18:31 | <Hixie> | i think we'll live with that :-) |
| 18:40 | <Hixie> | hey we crossed the 2000-subscriber mark recently |
| 18:40 | <Hixie> | we're at 2006 now |
| 18:41 | <jgraham> | Does the 2012th subscriber get a WHATWG soft toy? |
| 18:41 | <Hixie> | if you wish to send one to them, sure |
| 18:41 | <jgraham> | If you wish to get them made, sure |
| 18:41 | <jgraham> | I suggest the logo from the encoding spec for the design |
| 18:42 | <Hixie> | i just got done writing someone an e-mail explaining how at the whatwg things get done because motivated people do what they want rather than relying on others :-P |
| 18:42 | <Hixie> | bbiab |
| 20:37 | <annevk> | Hixie: tweeted that XHTML Module link, nice that you made it public |
| 20:38 | <zcorpan> | annevk: did someone test text/css charset further? |
| 20:39 | <annevk> | zcorpan: no sorry, forgot about it, but I think you're right that we need to check at each step |
| 20:39 | <annevk> | zcorpan: whether it's a valid label to begin with |
| 20:40 | <zcorpan> | ok. i can probably test it tomorrow when i'm on the train |
| 20:41 | <annevk> | zcorpan: if you have ideas how to rephrase my algorithm without making it longer and without introducing new terminology that'd be cool |
| 20:41 | <annevk> | I have a way with new terminology |
| 20:41 | <zcorpan> | i don't see the problem with making it longer |
| 20:41 | <zcorpan> | just state what you have to implement |
| 20:41 | <zcorpan> | and let the implementor worry about optimizations |
| 20:41 | <annevk> | but I think browsers just check whether it's a valid label at first, don't actually get the corresponding encoding |
| 20:42 | <zcorpan> | that's optimzation |
| 20:42 | <annevk> | well I guess, but if the algorithm is needlessly longer and complicated I don't like it |
| 20:42 | <zcorpan> | and anyway, if it's a valid label, you stop there and need to get the encoding for that label anyway, so what's the difference? |
| 20:43 | <annevk> | you don't stop there |
| 20:43 | <annevk> | anyway, bbl |
| 20:55 | <annevk> | GPHemsley: fyi, there were several Web Forms 2.0 publications here as well: http://www.w3.org/TR/web-forms-2/ |
| 20:55 | <annevk> | GPHemsley: I cannot find the older versions though unfortunately |
| 21:44 | <annevk> | Hixie: fwiw URL serializing is now defined |
| 21:45 | <annevk> | Hixie: are there any contexts for which a parse and then serialize shortcut would be useful? |
| 21:52 | <annevk> | http://www.reddit.com/r/IAmA/comments/120oqd/i_am_south_korean_singer_rapper_composer_dancer/ |
| 21:57 | <annevk> | "You have been banned from r/pyongyang." haha |
| 22:28 | <Hixie> | annevk: dunno (i saw there was a serialise argument in the api section already) |
| 22:57 | <zewt> | dreaming of the day sites don't have file download "links" as form submit buttons with onclick handlers that call window.open |
| 23:20 | <GPHemsley> | annevk: I found this, but it seems like it might be identical to the WHATWG one: http://dev.w3.org/html5/web-forms-2/ |
| 23:21 | <GPHemsley> | annevk: Ah, I think there may have only been one before it was superseded: http://www.w3.org/TR/2006/WD-web-forms-2-20060821/ |
| 23:25 | GPHemsley | would just like to say that he thinks the separation between W3C HTML5 and WHATWG HTML is a good one. The latter should be implemented unprefixed and on by default; the latter should be prefixed and/or preffed off by default. |
| 23:25 | <GPHemsley> | (In terms of features.) |
| 23:26 | <GPHemsley> | I don't know if that's a controversial opinion or not... |
| 23:51 | <zewt> | ... where they disagree, nobody's ever going to implement both, heh |
| 23:57 | <Hixie> | why would things in the WHATWG spec be prefixed? Prefixing is to avoid conflicts with specs, and I guarantee that I won't spec something that conflicts. |
| 23:57 | <Hixie> | (unless doing so is considered ok, e.g. because the code never shipped or was never used or whatever) |